BAud a écrit 12786 commentaires

sur mandriva, tu mets
blacklist ehci_hcd
directement dans /etc/modprobe.conf

un man modprobe.conf te le confimera

il faudrait aussi avoir le kernel par un uname -a (c'est le 2.6.17-14mdv sur une 2007.1 après mise à jour)

c'est avec une 2007 Spring ? (aka 2007.1) ?
un lspcidrake -v permettrait d'avoir les vendor id / product id

voir le 1er commentaire, tu peux mettre le nom du processus en paramètre, ça marche pour swfdec et gnash, pour flashplayer il doit aussi y avoir un nom de processus non ?

ya des gars avec un bandeau sur l'oeil, un sabre et une jambe de bois qui obligent les artistes à vider leurs poches et rentrer à la nage en partant du galion, faut croire...
à part ça, je ne vois pas...

c'est clair qu'un peu de poudre verte aurait pu aider http://www.poudreverte.org/

la vidéo flv est directement disponible sur http://download.tuxfamily.org/perlboxfr/video/x2lnww_reconna(...) pour ceux qui ont un petit souci avec le flash (x86_64, ppc, ...)
mplayer et totem réussissent à le lire.

Si vous avez des recommandations pour le transcodage dans un format plus libre (avec la ligne de commande qui va bien), je prends.

si tu veux tester micro et haut-parleur, j'ai un petit script sur http://cookerspot.tuxfamily.org/wikka.php?wakka=Reconnaissan(...) (ça enregistre 2s de voix, la joue et fait un petit bip: cela permet de vérifier que le micro et les enceintes fonctionnent).
Bien souvent, le son est bloqué par flash ou les bouses du genre.

sur https://linuxfr.org/stats/ est fourni ce que Krunch avait effectué comme stats "Graphe anonymé des commentaires échangés entre les utilisateurs (au format Graphviz .dot)".
ça ne fait pas très plaisir aux admins de voir tourner de tels scripts... (cela remplit les logs, qui remplissent les disques, qui font planter la base MySQL quand ils sont pleins, ce qui fait que linuxfr marche moins bien...)

En tant que relecteur j'ai maintenant sur https://linuxfr.org/top.html l'accès aux 20 karmas les pires / les meilleurs... cela est volontairement restreint pour éviter les courses stériles à celui qui a la plus grosse, postez plutôt des dépêches intéressantes, ça augmente votre karma maintenant !

Pour plic, rassures-toi, tu n'es ni dans les 20 meilleurs karmas, ni dans les 20 pires karmas.
Si tu as d'autres questions, tu peux compléter http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsLecteurL(...) qui donne déjà pleins d'infos.

pour une fois l'info est dispo plus tôt sur linuxfr que sur slashdot (13:38 contre 12:14)
http://linux.slashdot.org/article.pl?sid=07/07/25/129254

vaccin c'est pas mal aussi : c'est choisir la liberté. Le virus tu ne choisis effectivement pas de l'attraper, c'est insidieux ; se faire vacciner c'est une attitude active et un choix fait en toute conscience.

je te confirmes que tu as un mauvais karma :
* -2 (en 5 commentaires) sur 31 jours
* -0.4000 (en 5 commentaires) sur 365 jours
tu posterais des choses pertinentes (et ceux qui te moinssent ne confondraient pas d'accord / pas d'accord ça aiderait aussi).
Par exemple, actuellement tu postes à -1 par défaut, il faut que quelqu'un fasse l'effort d'ouvrir ton commentaire (ou surfe à -42 avec la toolbar) et que 2 personnes trouvent ton commentaire pertinent pour qu'il apparaisse à tout le monde.

La volonté n'est pas de pénaliser "ceux qui pensent différemment" mais plutôt ceux qui n'apportent rien voire sont néfastes (plus rare heureusement). Tu peux le prendre comme les punitions quand tu te retrouves au coin pendant un petit moment : c'est chiant sur le moment, cela en amène certains à ronger leur frein, ceux qui ont compris sont ceux qui clarifient leurs propos / argumentent et apportent de l'eau au moulin (ils peuvent se permettre de troller de temps en temps même). Après, nous sommes - pour beaucoup - là pour parler de GNU/Linux et de logiciels libres, pas pour se mettre sur la gueule non plus.

ya une JEP qui normalise ce fonctionnement d'aggréger les présences de serveur en serveur plutôt que d'aller jusqu'au client (un mode push plutôt que pull coûteux) ?
àmha, cela permettrait le passage à l'échelle de l'architecture jabber et structurerait tant les serveurs que la communauté des chatrooms / utilisateurs jabber.

Nÿco avait listé pas mal de choses sur https://linuxfr.org/tracker/580.html (découpé ensuite en trackers individuels)

Pour gérer la présence, j'avais proposé sur https://linuxfr.org/tracker/587.html :
- lorsque l'on se place avec la souris sur le champ "jabber id" cela interroge le serveur pour afficher le message de présence, éventuellement l'avatar retenu
- ou alors ne proposer cela que sur la page personnelle de l'utilisateur
Éviter d'afficher la présence pour tous les commentaires pour des raisons évidentes de performance d'affichage (mieux vaut ne pas dépendre d'un serveur externe).

je crois que son merci était une manière d'encenser l'auteur de ce journal :D

et sinon en complément de la tribune et du chan irc #linuxfr il y a aussi un salon xmpp:linuxfr@chat.jabberfr.org?join

et pour ceux qui voudraient approfondir leur connaissance de la messagerie instantanée, outre http://fr.wikipedia.org/wiki/Jabber il y a la communauté jabberfr http://jabberfr.org et son wiki http://wiki.jabberfr.org

Par rapport à la floppée de nouvelles fonctionnalités de linuxfr, j'ai aussi mis à jour http://wiki.eagle-usb.org/wakka.php?wiki=SuggestionsLecteurL(...) (pour les demandes d'évol' c'est toujours dans le lien du Suivi/tracker de la barre de votre site préféré).

Il semblerait que tu as oublié le http :// devant ta page perso

j'attends avec impatience les photos (euh pas dans les piscines, plutôt les paysages toussa).

il n'y a pas d'incompatibilité particulière entre le libre et l'argent, avec le non libre en revanche...

euh, pourquoi pas l'usb, en vrac tu peux tout de même avoir :
- souris / clavier
- modem
- webcam
- clé wifi
- imprimante, scanner
- disque dur / clé usbstorage (mais aussi appareil photo...)
ça fait tout de même une palanquée de périphériques intéressants à voir s'ils sont compatibles GNU/Linux...

En bref, tout ce qui apparaît dans http://www.qbik.ch/usb/devices/ dans ces différentes catégories : http://www.qbik.ch/usb/devices/devices.php

Donc bon, même s'il est vrai que faire apparaître les ports USB et autres hubs est moyennement intéressant (cela pourrait être affiché en plus petit...) pour les périphériques en tant que tel, je ne vois pas d'intérêt de les zapper.

D'ailleurs, cela me fait penser que ce n'est pas le périphérique en tant que tel qui est affiché, mais le chipset connecté (des produits différents peuvent avoir un même chipset : c'est de la responsabilité des constructeurs d'afficher le chipset sur la boîte, des produits nommés de la même manière peuvent même avoir des chipsets différents : là c'est de la bêtise des constructeurs de ne pas renommer au moins le modèle de leur produit...)

C'est pourquoi sur ce commentaire https://linuxfr.org/comments/849113.html#849113
j'avais aussi suggéré "pourquoi ne pas faire un mix entre le fonctionnement technique et une note sur la liberté du pilote (en ajoutant des informations telles que la licence, le besoin de firmware distribuable ou pas...)."

La réponse de Frédéric est de savoir si cela peut être fait en automatique : àmha en partie oui (le volet extraction de la licence par un modinfo), pour la dépendance à un firmware il y a bien le module firmware_class qui devrait être en dépendance, mais je pense que des modérateurs pourraient aider sur le sujet (il en faudra de toute façon pour vérifier les commentaires afin d'éviter spam et bêtises en tout genre...).

Pour moi, il s'agirait bien d'une 2ème notation (d'ailleurs voilà peut-être le moyen de le faire en automatique : demander aux utilisateurs :p), plus orienté liberté que fonctionnement réel (sachant qu'au final les deux sont liés étant donné que la liberté assure bien souvent la pérennité et que des modules proprios assurent bien souvent que cela sera cassé à chaque nouvelle version de kernel).
J'avais précisé quelques cas d'utilisation sur http://dev.librehwdb.tuxfamily.org/tiki-index.php?page=Doc+D(...)

et donc cela permet d'être utilisé par kcachegrind pour faire du profiling d'appli (et optimiser son code), c'est cela ?
cf. http://sophie.zarb.org/rpm/current,i586/kdesdk-kcachegrind pour le paquet à installer

En quoi le packaging de pear est-il cassé ? De toute façon, des paquets pour chaque distribution sont aussi réalisés, non ? De même, pourquoi utiliser xamp quand les paquets de chaque distribution permettent d'installer simplement un serveur LAMP ?

toutes celles que j'avais déjà sur http://wiki.eagle-usb.org/wakka.php?wiki=HwDbExistingResourc(...) ?

préserver mon cookie de relecteur, mon mot de passe aussi ?

Pour l'AdL, mieux vaudrait ouvrir un tracker pour les compléments à l'existant actuel : en tant que relectomodérateurs nous vérifions qu'il y a bien un lien préalable dans l'AdL (ceci est généralement le cas maintenant), le site LinuxFR ajoute la possibilité de commentaires qui peut être intéressante : une case à cocher dans l'AdL "publier vers LinuxFR" et la récupération du contenu permettraient de faire des rappels 8 à 15 jours avant l'événement automatiquement par exemple (et éviter la double saisie au rédacteur).

Pour http://jeuxlibres.net : un lien est généralement fait vers la fiche concernée, cela permet d'identifier les jeux réellement libres (moteurs + artwork). Comme pour wikipedia, les relectomodérateurs de LinuxFR peuvent contribuer des soumissions de dépêches / mises à jour de fiches sur jeuxlibres.

Pour Framasoft, les messages sont généralements relayés, je ne vois pas trop ce qui peut être fait en plus ?

Il y aurait peut-être les astuces de LinuxFR à placer dans un autre cadre ? (actuellement seuls les modérateurs y ont accès, l'interface est - paraît-il - pas très pratique...). Peut-être à voir avec Lea-Linux ?

Perso, ce sur quoi je suis déçu, c'est le peu de remontées d'infos des mailings-lists de développement : j'ai parfois l'impression que la capacité de communication de LinuxFR est sous-utilisée (même si ça ne passe pas en dépêche, au moins en journal ça serait déjà pas mal et pas que les trolls hein ;-) ). Sans créer de circuit parallèle aux ML, cela pourrait être une synthèse mensuelle ou bimestrielle de quelques projets d'un même domaine (comme cela est fait pour les annonces de kernel).
L'idée d'un wiki https://linuxfr.org/tracker/605.html permettrait d'enrichir largement l'espace rédacteur https://linuxfr.org/redacteurs/index.html qui est (actuellement) surtout une liste d'url à saisir au vol : constituer des équipes ponctuelles de rédacteurs (ou au minimum faire participer à la modération le rédacteur) me semblerait intéressant.

Même si je suis un peu déçu sur le volet GNU/Linux (projets, applis) le volet libre et problématiques connexes du libre de la charte de modération https://linuxfr.org/moderateurs/moderation.html#ligne est lui bien rempli àmha (cela semblera peut-être hors-sujet pour certaines personnes cependant ou trop omniprésent entre les brevets, les licences, la vente liée, les normes et standards, les formats ouverts ?).

Comme le dit Nÿco dans un commentaire plus haut, c'est surtout de la matière première (des dépêches) dont nous avons besoin : nous n'allons pas pouvoir aller tout chercher par nous même. Tout le monde peut soumettre une dépêche, quand elles sont refusées, pas besoin de se vexer pour autant (une raison est donnée) et il est toujours possible de la recycler en journal si le sujet est bien rédigé. Actuellement, seulement 5% des visiteurs journaliers du sites sont authentifiés :
- si déjà 0,1% de ceux loggués faisait une dépêche par jour nous en aurions 5 à modérer par jour
- si 1% des loggués faisait une dépêche par mois, ça ferait un peu plus d'une dépêche par jour à modérer : ah bin c'est à peu près ça :-)

Prenons l'exemple classique de la voiture, dans un domaine où les brevets s'appliquent :
- Citroën a breveté le levier avec molette qui permet de commander essuie-glace / phares / clignotants avec un levier unique au lieu de deux : Renault ne peut pas le proposer à ses clients sans payer Citroën, donc ils ne le proposent pas, ya 2 leviers distincts derrière le volant (bon maintenant ils peuvent, visiblement le brevet a dû expirer ou un accord a été trouvé)
- Renault a breveté le déport de commande auto-radio sur le volant, cela évite de se pencher ou de tendre le bras vers l'auto-radio pour monter le son ou changer de CD/station radio : Citroën ne le propose pas à ses clients (faudrait payer Renault).

Perso, j'ai l'impression que c'est le client au final qui est perdant ? Et encore, je parle de brevets qui ont donné lieu à une réelle réalisation et utilisation, où il serait possible d'y trouver un avantage concurrentiel pour chaque constructeur (dérisoire àmha mais bon).
Beaucoup de monde focalise sur le fait de déposer un brevet ou d'être bloqué par un brevet existant : y-a-t-il des exemples d'utilisation réelle des brevets à des fins de documentation et qui ensuite servent réellement ou sont réutilisés par d'autres ? (l'obfuscation du contenu des brevets ou le vocabulaire spécieux qui leur est propre me semble aller à l'encontre de cet objectif, mais je peux me tromper).

Si quelqu'un peut confirmer ces exemples (et retrouver les brevets concernés qui datent sans doute des années 70 ou 80) ça m'intéresse ;-)

Niveaux perfs ? qui s'en soucie ?

les hébergeurs aussi peut-être justement ? :D (en plus des mécanismes de sécurité disponibles).

cf. http://faq.tuxfamily.org/WebArea/Fr#Pourquoi_TuxFamily_ne_fo(...)

php a beau être un trou de sécurité béant, il a les mécanismes autour (suphp, safe_mode) qui permettent de le déployer en protégeant a minima les données des autres utilisateurs, du système... ce que n'ont pas (encore ?) les autres.
Puis bon côté conso RAM/CPU, python, ruby et consors n'ont qu'à faire leurs preuves, c'est particulièrement important sur un hébergement mutualisé (balancez les benchmarks si vous avez).