BAud a écrit 12775 commentaires

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).

J2ME est-il prévu d'être disponible en libre comme java7 ? (c'est une vraie question : àmha cela peut beaucoup aider pour la modularité et la sélection du strict nécessaire pour les environnements contraints en mémoire comme de l'embarqué).

Sinon, je suppose que ce que tu appelles "PC actuel" ne recouvre pas ceux qui ont encore 256 Mo de RAM (ni même 512) ? C'est tout de même dommage, cela correspond à ce vers quoi tendent les PDA actuellement, avec un processeur encore un peu poussif par rapport aux double/quadruple coeurs "actuels" mais pas forcément par rapport aux processeurs de ce début de siècle, si tu compares http://fr.wikipedia.org/wiki/Pentium_III et http://fr.wikipedia.org/wiki/XScale pour ne citer qu'un constructeur... (je suis ouvert à d'autres comparaisons mais http://fr.wikipedia.org/wiki/N%C3%A9o1973 par exemple évoqué dans la dépêche https://linuxfr.org/2007/07/09/22714.html ne donne pas - actuellement - assez d'éléments de comparaison).

tu as une version en français en cours de traduction du Why's (poignant) guide
http://fr.poignantguide.net/

la version draft est là : http://fr-draft.poignantguide.net/ sous licence CC-by-sa

Pour le faire tourner sur un PDA, oui c'est gênant 30 Mo quand il y a 64 Mo pour faire tourner le système + les applis + le stockage (heureusement ça monte plutôt à 128 Mo maintenant voire cela peut-être mis sur une SDCard de 1 Go).

cf. ci-dessous le post sur les sites web parking qui montre que ce n'est pas une réelle montée de IIS pour faire quelque chose d'intéressant (bien au contraire).
Avoir le détail entre site web réel et site web parking serait intéressant (pas forcément évident).

ah c'est cool tu as retrouvé un journal que je cherchais (bon je ne sais pas trop pourquoi tu te fais moinsser...).

Il y a effectivement l'effet "site web parking", mais j'avais cru qu'il était distingué dans le 1er schéma entre les sites actifs et les hostnames.

Ce post https://linuxfr.org/comments/703650.html#703650 affirmait qu'il rentrait en ligne de compte dans les parts de marché, ça me paraissait déjà bizarre à l'époque : si je comprends bien, sont considérés "actifs" les serveurs qui ont une réponse HTTP code 200 - OK (que ce soit du parking ou un vrai site web réellement actif).

Donc bon, les stats de netcraft pour les hostnames ça ne doit être que des nouveaux serveurs (pas forcément pour le web) et serveur actif, c'est ayant un serveur web qui répond... c'est un peu ballot (ou en tout cas pas assez détaillé).

Les "plateaux" pour IIS correspondraient donc à des changements de techno pour les "hébergeurs parkings" et pas du tout représentatif d'un réel besoin ou d'une réelle réponse performante à de nouveaux sites webs actifs (avec de la vraie activité, pas servir une pauvre page statique). OK les stats ont encore parlé, à 72,16% fausses comme d'hab' quoi ;-)

Et sinon quelqu'un connaît-il un site qui auraient des statistiques un peu moins exhaustives mais un peu plus précises comme je m'interrogeais dans mon journal ?

Je rajoute souvent la wikipédification aux dépêches (d'autres relecteurs comme j sont aussi actifs à ce sujet), lorsque l'auteur n'y a pas pensé déjà par lui-même ; effectivement il n'y avait pas de page en français, je me suis donc abstenu (de toute façon il y aurait eu une remarque que c'était un lien en anglais :D).

Par ailleurs, dans ce cas particulier, je me suis dit : tant mieux ça en incitera à chercher par eux-mêmes (il y a aussi la possibilité de créer la page sur wikipedia).
L'intérêt de l'ajout de ces liens est aussi de faire découvrir des projets plus facilement et à ce titre wikipedia est une bonne porte d'entrée, tant mieux s'il y en a qui n'ont pas besoin d'un lien pré-mâché pour appliquer leur curiosité.

Le Bookcrossing a été évoqué sur linuxfr au moins depuis 2003 https://linuxfr.org/~nicOnicO/6084.html et https://linuxfr.org/~GruiicK/5025.html (cette initiative s'est-elle concrétisée à Lyon ?).
En 2004, dans le (dernier) commentaire de https://linuxfr.org/~EmacsFR/13023.html

En 2006, un petit passage à la sauce "social networking" http://linuxfr.org/~Jux/22194.html

En 2006, un journal parlait de l'appliquer à la musique https://linuxfr.org/~lezius/21321.html

Bizarre que ce sujet ne soit pas plus évoqué parmi tous les passionnés de livres de linuxfr ?

les dév. du pilote

ya pas une mailing-list pour les développements ? parce que bon, contacter les gens directement c'est bien souvent plus efficace et moins énervant...

Par contre, on n'a pas tous à disposition un serveur qui tourne 24h/24 :-)

Dans ce cas, il n'y a pas de raison qu'il y ait du trafic réseau. Il y a donc possibilité de conserver une base rrd minimaliste dont les infos sont récupérées et traitées côté du serveur quand il est rallumé. Cela permet quand même d'avoir un rendu graphique et des durées de conservation des données avec plus de finesse que sur le pauvre routeur qui n'est pas fait pour cela.

bin Dr Dobb's il est au format papier, je t'ai donné le site car ça permet de voir à quoi il ressemble voire de se faire une idée sur quelques articles en ligne...

Le plus pratique sur ce type d'équipement - ayant une faible capacité de stockage - n'est-il pas de déporter les informations sur un serveur qui pourra servir correctement les pages et graphismes d'utilisation réseau ?