Lorsqu'on utilise avec KVM le récent support pour les périphériques block et réseau paravirtualisés (virtio), les performances sont excellentes.
Il y a certes un léger ralentissement par rapport à une installation native, tu as raison, mais ce n'est plus de plusieurs ordre de magnitudes ("µs vs ns"). Pour ceux qui n'ont pas encore essayé, c'est bluffant, mangez-en :
- Pour utiliser le périphérique réseau haute performances paravirtualisé sous KVM : guest : avoir un 2.6.25 ou plus, et faire "modprobe virtio_net" (pour un guest sous Windows, installer le driver win32 fournis par Qumranet) host: "-net nic,model=virtio -net tap,script=/etc/kvm/qemu-ifup"
- Pour le périphérique block virtio : guest: noyau 2.6.25+, modprobe virtio_blk host: "-drive file=foo.qcow2,if=virtio"
nb: Pour le virtio block, pensez à mettre à jour le fstab du guest, car le disque est maintenant vu comme /dev/vdxy au lieu de /dev/sdxy. Je ne sais pas s'il existe un driver Windows pour le périphérique "virtio block" (le savez-vous ?), mais pour les guests sous Linux, ce n'est que du bonheur. Le support "virtio" fut mergé dans le noyau 2.6.25 standard (et backporté dans le 2.6.24 par défaut de la précédente Ubuntu, Gutsy).
Avec des fonctionalités équivalentes (hardlinks pour les fichiers identiques, y compris identiques entre plusieurs machines), mais plus carré et plus complet, il y a backuppc :
J'utilise ce dernier depuis un moment (pas encore eu le temps de changer), et je le déconseille à tout le monde (ie. ceux qui comme moi risquent d'être convaincus par http://la-samhna.de/library/scanners_2004.html ) :
- Les fonctionalités interessantes sont déportées sur une interface proprio (beltane) aux dépendances usinagazesques. Le dev. veut faire son beurre en vendant cette interface.
- Dans la version de debian etch, les outils manuels de mise à jour, checks, etc. ne marchent tout simplement pas. Il faut attendre que le daemon se debrouille :
# echo pouet > /bin/ps
# samhain --foreground -t check
# <-- rien, ni dans les logs, ni envoyé par mail, ...
À ceux qui utilisent d'autres HIDS (Aides, Osiris, ...), auriez vous des retours d'expérience à nous transmettre ?
Mais, si je peux me permettre, et pour tenter de faire avancer le schmilblick, pourrai-t-on envisager d'appliquer, les prochaines fois, cette suggestion de Wikipédia concernant la qualité du style (WP:STYLE) :
« Évitez également les formulations du type "il est à noter que", elles alourdissent inutilement la phrase et relèvent du commentaire personnel. ».
Vérifiez l'astuce avec le texte de la dépêche : on peux enlever chacun des cinq « il est à noter que » sans dévoyer le sens mais en gagnant en légèreté. Sans quoi tout les linuxfriens ne tarderont pas à adopter ce tic de langage plus geek que littéraire ;).
Pour le reste évidement, la dépêche est superbe.
Une question maintenant. Le pilote out-of-tree GSPCA était maintenu par Michel Xhaard depuis des années, comme l'indique la dépêche. Pourtant Xhaard n'a participé à aucun des commits dans le récent répertoire drivers/media/video/gspca/ du noyau standard. La plupart des commits sont « Signed-off-by » Jean-Francois Moine et Mauro Carvalho Chehab. D'autre part le ChangeLog concernant GSPCA sur le site de Xhaard ([http://mxhaard.free.fr/news.html]) s'arrête abruptement au 24 december 2007. Est-ce que Michel Xhaard a abandonné le développement ? est-il contrarié par les modifications de son travail qu'implique l'intégration dans le noyau standard, ou la collaboration avec d'autres développeurs ?
> Les deux gros consommateurs d'energie sur un portable sont l'ecran et le cpu.
Oui il ne faut pas sous-estimer l'écran.
Par exemple sur un IBM X40 (petit écran 10 pouces), l'écran consomme presque 5W lorsqu'il est en mode économique (faible luminosité).
A l'auteur de la dépêche : tu peux mesurer ça très facilement : 1) Installe et lance powertop, 2) passe ton ordinateur sur batterie (débranche l'alimentation), 3) mesure la consomation avec l'écran ouvert, 4) ferme l'écran, note la consomation, 5) fait une soustraction.
Le reste du matériel n'est pas sans importance aussi, et peut aussi bien expliquer le faible écart (20%) entre les deux ordinateurs dont parle le journal :
- Le bus USB est gourmand, les périphériques aussi (de façon variable) (et selon que support autosuspend usb ou pas...)
- Les cartes graphiques aussi. Certaines plus que d'autres. Et certains drivers (devinez lesquels) supportent certaines fonctionalités permettant l'économie d'énergie (comme la compression du framebuffer)
- Une CPU peu puissante ne parviendra jamais à passer sur un c-state bas lors de la lecture d'un divx, tandis qu'une cpu plus puissante pourra trouver un peu de temps pour se reposer (elle ne sera pas au max de son TDP, si tu veux).
- Le bus SATA (si moderne) offre des fonctions permettant d'économiser de l'énergie (par rapport au bus IDE classique) (ie. ALPM avec les controleurs AHCI, SATA AN, ...)
- Le Wifi est un grand consommateur d'énergie. Et la encore, tout les chipsets et tout les drivers ne sont pas égaux, loin s'en faut.
- La consomation d'énergie selon les disques durs (ou autre techno de stockage) est très variable
- La présence d'un lecteur CD sur un bus ne supportant pas les asynchronous notifications et avec hal qui tourne en mode polling
- Le chipset de la carte son et son driver (certains supportent un mode économe)
- Selon que la machine implémente des timers HPET ou pas, selon ses fonctionalités ACPI, ...
- La pile logiciel qui fait tourner la bête (beaucoup de travaux et progrès sur l'économie d'énerige sous Linux ces derniers mois => les noyaux plus récents sont plus efficaces, Xorg et ses drivers sont aussi très important, ainsi que hal, gnome-power-manager, la présence de beagle et consorts suffit à flinguer une batterie en un rien de temps, ...)
- ...
Je trouve au contraire que AMD s'en sort remarquablement bien, d'après ce que tu expose, et sachant à quel point Intel à mis le paquet pour que les drivers Linux pour son matériel soient les plus économes possible.
> Le cpu tourne normalement à 1.66Ghz. Je le bride à 530Mhz..
>
> Donc si le cpu n'est pas "bridé" et selon de combien tu peux diminuer
> en frequence tu peux augmenter ton autonomie de manière non negligeable.
Absolument pas, réduire manuellement la fréquence du processeur (le P-state ACPI) c'est plutôt une bonne façon de perdre de l'énergie. Ce qui est important c'est que la CPU reste le plus longtemps possible dans un C-state ACPI bas, ça ça fait économiser de l'énergie. Forcer la CPU a tourner en dessous de sa vitesse optimale la conduit à passer moins de temps dans un C-state bas.
Je croyais que cette légende urbaine était belle et bien épuisée...
svp, arrêtez de colporter ce mauvais conseil. Il est préférable de laisser la CPU s'exécuter à sa fréquence nominale lorsqu'elle a du travail à accomplir. Ou mieux, adoptez le "ondemand frequency scaling governor", soutenu par les développeurs d'Intel.
> Sinon Mandriva contribue pour 1.11%, Debian 1.35 % face à Ubuntu 0,47%.
> Ne pourrait t'on pas leur adresser le même compliment pour les stimuler aussi ?
Perso je préférerai qu'on tire à boulets rouge sur Xandros (maintenant aussi propriétaire de Linspire), qui s'en est mis plein les fouilles avec le nouveau marché des ultraportables/netbooks, à décroché ces marchés à coups de vilaines concessions (type inclusion de drivers proprios et buggués, de soft proprios installés d'emblés, accords avec Microsoft comme Novell, etc), a un modèle de développement totalement opaque et fermé, et n'a pas reversé un copec ni un patch upstream.
Certes ils développent un peu : des softs proprios qu'ils gardent pour eux...
Xandros contribue tellement peu qu'on ne pense jamais à essayer de comptabiliser leurs contributions dans ce genre de gueulantes.
> RH et Novell totalisent à eux seuls 90% des patchs
Absolument pas. Et les pourcentages de Free Tyrando indiqués ci-dessus sont faux.
En fait les chiffres reportés ici par patrick_g sont le nombre de contributions venant des principales distributions (uniquement). Et encore, lorsqu'on sait de quelle distribution un développeur se récalme (plus difficile à déterminer pour les distributions communautaires comme Debian ou Gentoo). Ne sont pas comptés, par exemple, les grosses contributions d'IBM, d'Intel, des amateurs (qui sont, en fait, les plus gros contributeurs), de personnes dont on ne sais pas trop pour qui elles travaillent, etc.
En pratique, Red Hat contribue à 11.9% des patchs du noyau, et Novell à 7.3%.
Les chiffres complets des dix plus gros contributeurs rassemblés par « groupes » sont:
1- Amateurs : 17 %
2- Red Hat : 11.9 %
3- Unknown : 8.3 %
4- IBM : 7.8 %
5- Novell : 7.3 %
6- Intel : 4.4 %
7- Consultants : 2.1 %
8- Oracle : 1.9 %
9- Linux Fundation : 1.8 %
10- SGI : 1.8 %
À mon sens c'est ce qui fait la force de Linux par rapport à la majorité des projets libres : le fait qu'aucune société ne puisse prétendre contrôler ou diriger quoi que ce soit (la première société contributrice, RH, ne produit que 12 % des patchs), et du coups l'obligation de trouver un consensus technique satisfaisant des sociétés aux exigences et aux besoins très différents, de l'embarqué aux mainframes. Le fait, aussi, que les contributeurs amateurs/indépendants continuent d'être le plus grand groupe.
> Pour finir de m'achever, NoNo m'a montré l'article SATA vs. SCSI reliability qui explique pourquoi vous allez aussi perdre des données...
Il a aussi été question de ce problème dans ces dépêches http://linuxfr.org/2006/07/23/21124.html et http://linuxfr.org/~herodiade/23833.html .
Une des conclusion des développeurs est qu'il faudrait pour Linux, et rapidement, des systèmes de fichiers plus adaptés aux gros disques (d'autant que perdre des données est un chose, perdre un superblock en est une autre). Vivement en:btrfs !
Ce qui est amusant, c'est que c'est précisément l'inverse pour les SSD : plus le disque est gros, moins on risque d'avoir des blocks corrompus.
Du moins c'est ce qui devrait arriver, en théorie, lorsque les fabriquants implémenteront le wear-leveling correctement...
Val Henson a parlé de ce problème sur les SSD hier : http://valhenson.livejournal.com/25228.html
Ils viennent de merger le support pour les transferts USB asynchrone (émul ohci je crois). Les testeurs disent que même les webcams sont censées fonctionner désormais. Contrairement à Virtualbox, c'est libre.
> Chez moi, l'user-agent est aussi bien pratique pour transmettre la langue que j'utilise au site Web
Bonjour le hack... et si mon navigateur n'est pas connu du site, le site ne sais pas où trouver le champs indiquant la langue dans la chaîne User-Agent, et il retourne une langue au pif ? Et comment le site détermine-t-il le charset que je supporte pour afficher ma langue ?
Pour transmettre *proprement* ce genre d'informations, le navigateur l'envoi normalement dans des champs dédiés de la requête. Par exemple "Accept-Language" permet d'indiquer les langues supportées, par ordre de préférence. Et tant qu'à faire, on envera aussi une en-tête "Accept-Charset" indiquant les jeux de caractères supportés par le navigateur, "Accept-Encoding" pour indiquer un éventuel support de la compression à la volée, etc...
> indiquant une correspondance de compatibilité, n'est-elle pas une manière
> élégante de permettre à un site de savoir comment gérer un nouveau navigateur
Précisément pas, puisque se baser sur le ''User-Agent" pour déterminer les fonctionnalités supportées implique de connaître par avance toutes les fonctionnalités supportées par chaque navigateur. Et si un bug est corrigé dans une mise à jour mineur du navigateur ? et si c'est un nouveau navigateur qu'on ne connais pas ? ...
Bref, en général on essaiera de déterminer *dynamiquement* si une fonctionnalité est supportée. Comme les autoconf/automake testent un par un les prérequis pour chaque ressource utile plutôt que de déterminer ce qui est disponible globalement à partir de la version de l'OS, on évitera les évaluation globales, qui aboutissent si souvent à "Ah votre navigateur n'est ni Internet Explorer 6 ou 7, ni Firefox 2, circulez nous n'avons rien à vous montrer". L'alternative consiste à construire un site conforme aux standards, dont les javascripts testent dynamiquement la présence des fonctions requises, et des <!--[if IE 7]> & co, ponctuels, autour des hacks spécifiques corrigeant les bugs (non respects des standards) connus...
C'est à cause de ce genre de raisonnements qu'on trouve encore des sites "optimisés pour Internet Explorer", ou des sites façon impots.gouv.fr qui refuse de fonctionner parce que le plugin java d'Ubuntu et Fedora a un nom qu'il ne connaît pas et considère en conséquence qu'on ne dispose pas de plugin java.
> Pour le chroot, ils appellent ça le sandboxing dans la BD et oui c'est un des but de l'utilisation de processus.
Oui bien sûr. Mais si j'évoquais SELinux, c'était pour souligner que cette architecture devrait permettre aux distributions Linux de s'éclater à blinder la sécurité aux petits oignons, depuis le système / l'extérieur du logiciel lui-même, et bien au-delà des mesures de sécurité et d'isolement (sandboxing) pré-intégrées par Google dans Chrome. Bref, c'est une mesure de sécurité qui appelle à d'autres mesures de sécurité ;)
The use of multiple processes in Chrome is just begging to have SE Linux support added. Having tabs opened with different security contexts based on the contents of the site in question and also having multiple stores of cookie data and password caches labeled with different contexts is an obvious development.
Sans rapport : la page listant les licences des logiciels inclus dans Chromium est intéressante, car elle indique les bibliothèques utilisées : http://code.google.com/chromium/terms.html
- bsdiff, bspatch : ils ont donc déjà prévu les mises à jour incrémentales
- pthreads for win32 : ça de moins à porter vers les systèmes posix
- lzma, bzip2 : ça semble un poil redondant
- tlslite (c'est une lib de crypto pour python) + le fait que python soit une des dépendances pour le build : il semblerait donc que Chrome embarque un moteur python
- WTL : c'est la mauvaise nouvelle. Ça signifie que google n'a pas fait le choix d'un toolkit portable et multiplateforme, et que le port sur Linux sera donc très divergent ; s'ils n'ont pas commencé ce port, on n'est pas prét de voir Chromium tourner sur le Desktop Linux (s'ils portent Chromium sur le googlephone, je suppose qu'ils utiliseront leur toolkit java ad hoc)... On peut aussi supposer que tout les développeurs du projet travaillent tous sous Windows, que le port Linux, quand il arrivera, sera un citoyen de seconde zone, peu testé,...
> ton OS te dit que le processus Chrome pid XXX utilise 200Mo de mémoire,
> ce n'est pas tres pratique pour relier ça a un onglet précis
Il suffit au navigateur de suffixer le nom du processus par le nom de l'onglet / la page en cours.
Comment crois-tu que, par exemple, les processus fils d'openssh indiquent leur fonction et le nom de l'utilisateur en cours ? man setproctitle(3).
Pour ma part, je suis impatient de voir ces « onglets et plugins dans des processus séparés ». Ça permettra peut-être de chrooter tout ce qui concerne les pages proprement dites (ie. sans affecter le processus qui contient les menus ouvrir/enregistrer sous).
Ou, plus encore, ça devrait permettre de faire des polices SELinux très fines et beaucoup plus sérées (qu'avec le modèle monolithique de ff) pour tout les processus qui s'occupent du parsing et du rendu des pages, de l'exécution du js ou des plugins comme flash.
Moui, le CVE-2007-4752 est un problème vraiment mineur (le root d'un serveur distant a déjà, comment dire, beaucoup de droits et d'autres méthodes sous la main pour consulter les sessions x11 en cours).
Ça explique que Red Hat ne se soit pas trop pressé pour distribuer une mise à jour : le CVE-2007-4752 date d'octobre 2007. Ils ont visiblement attendu d'avoir une vraie raison d'upgrader le paquet pour distribuer ce fix.
Je vois que tu n'a riens compris. Dans les deux cas que tu cite, le problème n'est pas une faille d'openssh.
Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.
La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.
Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.
À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).
Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...
Je déteste toujours autant le ton complaisant, enthousiaste et lèche-cul de Phoronix à l'égard des constructeurs. Surtout concernant deux ou trois améliorations mineures dans des drivers proprios et notoirement buggués.
Je suppose que c'est la condition (entretenir des bonnes relations) pour que les constructeurs leur envoi du matériel à tester, leur donne quelques informations en primeur, leur accorde des interviews, etc.
L'indépendance de la presse et l'esprit critique du journaliste, eux, repasserons. Le pôle marketing d'AMD ne pouvait espérer mieux.
> Il me semble bien quand même qu'ils suggèrent que les traductions
> pourraient être utilisées pour un projet autre que l'original.
Oui, tout à fait. C'est ce que laisse entendre leur FAQ, https://help.launchpad.net/Translations/LicensingFAQ :
« we believe that the advantage of having large translation memories for free software far outweighs the risk of having free software translations end up in proprietary software. ».
Pour ceux qui ne connaissent pas, les translation memories sont des bases de données de chaînes, expressions, mots ... déjà traduits et réutilisables. http://en.wikipedia.org/wiki/Translation_memory
Couplées à un bon logiciel (ce qui pour le moment fait plus ou moins défaut dans le monde libre), elles facilitent et accélèrent grandement le travail du traducteur, et améliorent la cohérence globale des traductions (par exemple : elles aident à faire en sorte qu'une même chaîne soit traduite identiquement, par exemple, entre plusieurs application différentes du même environnement).
Même pour un environnement constant (par exemple, gnome) on trouve des applications sous des licences très différentes et plus ou moins incompatibles (la plupart des libs de gnome sont sous LGPL, les applications sont souvent GPLv2-only, ou GPLv3, ou MPL, ...). La seule possibilité qu'ai Launchpad pour constituer une translation memory (dont on a horriblement besoin !) cohérente et réutilisable dans ces diverses applications et de la constituer sur un dénominateur commun, une licence compatible (au niveau fichier source) avec ces diverses autres licences : d'où le choix de la licence BSD.
Et on peut désormais supposer que Canonical développera prochainement un CAT ([http://en.wikipedia.org/wiki/Computer_assisted_translation]) web based, ce qui serait vraiment une très bonne chose, ... si tant est que ce soit une application libre...
> selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS,
> c'est une problématique satellite. Il existe d'autre méthodes pour transferer
> ses zones : http, rsync, ssh, par clé USB, etc...
Ah oui mais là ton transfert n'est pas interopérable entre serveurs : ça devient un transfert de fichiers au format d'une implémentation de serveur DNS. Or interop => protocole+specs, c'est donc pas plus mal que cette question soit normalisée ;)
Un autre intérêt d'AXFR, c'est que le proto est implémenté par le serveur lui-même (au lieu d'un outil externe comme rsync), et ça lui permet de savoir qu'il doit recharger la zone dès qu'elle est rafraichie (rsync, ssh ou http ne font que transférer des fichiers, sans se préoccuper de l'applicatif).
Cela dit, je suis d'accord pour le qualificatif de « problématique satellite ».
> Le QTiste que je suis a beaucoup de mal à admettre que QT s'en sorte moins
> bien qu'EFL
D'ailleurs, quelqu'un pourrait-il expliquer la raison de cet étrange,
apparement lourd, complexe et propice aux bugs mélange (Qt + X11 + EFL)
en lieu et place du de QtE/Qtopia pur (et son support framebuffer natif) ?
C'était pour faire plaisir à Rasterman et l'encourager à venir bosser sur
OpenMoko ou bien ou bien Qt ne suffit réellement pas ?
Ouais, d'après la page de man, à l'heure actuelle il semble qu'UDP soit le choix par défaut, puis que le resolver offre une option pour forcer le TCP. A moins que la phrase de WP signifie que les utilitaires systèmes d'HP-UX requètent explicitement avec le bit RES_USEVC ? http://docs.hp.com/en/B3921-90010/resolver.3N.html
> des rfcs qui n'exigent pas qu'un serveur dns accepte du tcp.
La RFC 1035 n'« exige » (must ou shall) rien mais indique, si l'on peut dire à pied d'égalité (section 4.2) « The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal) ». Et précise aussi : « Messages carried by UDP are restricted to 512 bytes ».
La RFC 1034 discute d'ailleurs brièvement de l'utilisation de TCP dans les resolvers (et précise, à toutes fins utiles que « Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. » (encore heureux)).
> Parce que TCP serait deja mieux que UDP, mais les serveurs ne tiendrait pas la charge...
Les serveurs, même de taille modeste tiendraient la charge il me semble (sauf peut-être les root servers ?). Surtout s'ils utilisent les syncookies et ont suffisamment de RAM.
Les problèmes que causeraient une utilisation systématique de TCP pour le DNS sont plutôt les risques liés aux congestion, et aux augmentations de latence.
Le premier type de problème (congestion) n'est pas insoluble. L'augmentation du débit n'a pas que des conséquences néfastes (comme la possibilité de flooder/bruteforcer les DNS), elle permet aussi de gérer un trafic légitime plus important ; les outils de routage et de QoS se sont améliorés depuis l'invention du DNS en 1983 :).
La latence des réseaux s'est aussi améliorée, mais une généralisation absolue du TCP pour le DNS n'est pas possible bien sûr. Il faudrait toujours des solution de replis pour par ex. les liaisons satellites, gprs, TOR, & co, quitte à ce que les providers leurs fournissent des caches qui fassent passerelles UDP en interne <->TCP vers le monde. Je crois - de mémoire - que MaraDNS fournis un proxy de ce type, et il y a aussi le proxy de TOR (ttdnsd).
Sinon, notez au passage que le protocole DNS prescrit _déjà_ le support TCP (utilisation obligatoire pour les paquets de plus de 512 bytes, utilisation facultative en deçà). Les serveurs DNS (et les bibliothèques de résolution des OS) implémentent ce support depuis longtemps déjà.
L'article DNS de la Wikipédia en langue anglaise dit que le resolver d'HP-UX utilise déjà systématiquement TCP pour ses requêtes DNS. J'adorerais avoir la même possibilité de forcer l'utilisation systématique de TCP sous Linux aussi (par ex. avec une option de resolv.conf). Et aussi, de pouvoir paramétrer un cache bind de la sorte (ie. "utilisation systématique de TCP pour toutes les requêtes sortantes / partout où je ne suis pas authoritative").
Ah, aussi : OpenDNS fournis des serveurs DNS récursifs publics supportant le TCP.
Enfin : TCP seul (sans crypto, ie. DNSEC )laissant la possibilité d'attaques man-in-the-middle, ce n'est pas suffisant pour se protéger des censures/redirections de traffic au niveau des opérateurs et des FAI. Je crois que c'est ainsi que l'Italie bloque l'accès à The Pirate Bay, et je ne serais pas surpris que notre gouvernement actuel (ou une loi européenne) contraigne les FAI à ce genre de cochonneries...
> Ben AMHA un NDA permettant d'écrire un pilote non obfuscé est alors une solution de repli valable.
Possible. Si cette option n'est pas contre-productive pour la possible libération de la doc. Si au moins tout à été fait pour que ça ne soit qu'un dernier recours. La tolérance aux NDA immédiatement annoncée et mise en avant par le LDP n'est - au minimum - pas forcément quelque chose qui encourage très fort les fabriquants à chercher beaucoup plus loin, par exemple.
Prenons pour exemple le support pour les contrôleurs RAID sur SCSI/SAS d'Adaptec, parce que c'est intéressant et critique (nos données peuvent en dépendre). Le pilote Linux est développé en interne par Adaptec, et est notoirement de qualité exécrable (il semblerait notamment qu'Adaptec cherche à factoriser le code du pilote pour les divers OS qu'ils supportent pour économiser de la main d'oeuvre), et peu maintenable par les développeurs extérieurs. Même Ingrid est plus libre que ça.
De plus, aucun logiciel libre ne permet de gérer les fonctionnalités des contrôleurs RAID Adaptec modernes à chaud (savoir si une array est en mode dégradé, quel disque est en panne, ajouter un hotspare, lancer une reconstruction, créer/détruire une array en RAID X, ...), ce qui rends ce matériel totalement inutile si on ne souhaite l'utiliser qu'avec du logiciel libre (sérieusement, pourquoi utiliser un contrôleur RAID qui ne permet même pas d'être alerté lorsqu'on a un disque en panne, qui accumule bugs matériel, bugs bios et bugs driver alors qu'on peux faire du RAID logiciel de bonne qualité, stable, ouvert, avec toutes les fonctionnalités utiles, gratuitement ?). On peux aussi se demander à quel point Adaptec s'efforce de corriger les bugs pour les générations de matériel qu'ils ne vendent plus...
Il y a quelques années, OpenBSD disposait d'un pilote équivalent à celui de Linux (et pour cause, c'était le même code) pour ce matériel. Ce pilote était vaguement maintenu par un ancien d'Adaptec. Las de ne pouvoir le supporter proprement (évolutions, corrections des bugs) et complètement (gestion à chaud comprise), Theo a lancé un dernier appel public pour la libération des spécifications ; Adaptec s'obstinant à ne pas livrer la doc, OpenBSD a tout simplement décidé de jeter son pilote. Ce qui est hardi pour un OS plus ou moins dédié aux serveurs.
On peux en conclure, selon son point de vue, que Theo est un grossier intégriste psychorigide qui se moque des utilisateurs, ou qu'un peu de solidarité de la part des devs noyau Linux aurait été bienvenue (parce que vue la part de marché de Linux sur les serveurs, Adaptec n'aurai pas tenu un bras de fer bien longtemps pour de telles queues de figues).
> on peut lire le source de ce pilote et en comprendre assez sur le
> fonctionnement du hardware pour écrire un pilote
Je pense que tu ne perçois pas tout le problème (d'où tes commentaires sur le reste).
Il ne s'agit pas seulement d'écrire un pilote, mais aussi de le maintenir. Soit, entre autres :
- Corriger les bugs rapidement
- Apporter de nouvelles fonctionnalités non prévues dans le pilote initial (supporter le suspend-to-ram, par exemple)
- Pouvoir facilement refactorer un sous-système (type gestion des périphériques blocs, des périphériques réseau, enlever un verrou global, changer de stack wifi, ...) sans être bloqués par ce qu'on ne sait pas quoi faire d'un pilote intouchable.
- Continuer de maintenir le pilote malgré le turn over des développeurs (et même lorsque le constructeur préférerai qu'on encourage l'achat de nouveau matériel)
Si on prends en compte ces contraintes supplémentaires (en plus de l'écriture d'un driver initial, one shot, fut-il libre), on peut affirmer qu'en effet :
- Même lorsqu'un pilote libre est intégré dans le noyau vanilla, si seule Red Hat (au hasard) dispose des docs, cette compagnie sera plus à même de servir ses clients (corriger les bugs, etc) que ne le sera SuSE (au hasard encore).
- Lorsque le constructeur souhaite pousser l'adoption d'une nouvelle génération de matériel, il est peu probable qu'il accepte de continuer à livrer les docs sous NDA pour le vieux matériel. Dès lors, on il ne nous reste qu'à croiser les doigts pour que le développeur (ou la compagnie) disposant de cette doc ne disparaisse pas.
- Et n'oublions pas que, effectivement, les distributions commerciales de Linux négocient leur bénédiction pour le support des serveurs (IBM, HP, Sun, ou Dell on généralement besoin que leurs serveurs soient "officiellements" supportés par RHEL et SuSE, mais ces dernières n'exigent pas que le matériel soit documenté de façon ouverte).
Pour finir, je continue d'être surpris par la tolérance envers les NDA dans la communauté du libre. Lorsque Greg Kroah-Hartman a lancé son Linux Driver Project en annonçant qu'il fournissait un cadre blindé pour les constructeurs souhaitant une diffusion restreinte des docs par NDA, et que c'était encouragé, j'ai sauté au plafond !
Prenez le temps de comparer avec ce qu'on (les personnes sensibles au libre) dit et pense des format ouverts et libres, des protocoles standards, ... ; à savoir : que la disponibilité d'une implémentation de référence (fut-elle libre, comme pour le .doc dans abiword, netbios dans samba, ...) ne suffit pas à rendre le format/protocole libre : il faut au moins la doc soit publiquement disponible (et c'est une condition nécessaire mais non suffisante).
Pourquoi ne pas exiger des constructeurs de matériel ce qui nous parait aller de soi pour les concepteurs de protocoles et formats de fichiers ? Theo n'a pas tort, ça fait très double standard.
[^] # Re: KVM, pas de ralentissement?!
Posté par herodiade . En réponse à la dépêche Ubuntu 8.10 : le bouquetin intrépide sort de son antre. Évalué à 1.
Lorsqu'on utilise avec KVM le récent support pour les périphériques block et réseau paravirtualisés (virtio), les performances sont excellentes.
Il y a certes un léger ralentissement par rapport à une installation native, tu as raison, mais ce n'est plus de plusieurs ordre de magnitudes ("µs vs ns"). Pour ceux qui n'ont pas encore essayé, c'est bluffant, mangez-en :
- Pour utiliser le périphérique réseau haute performances paravirtualisé sous KVM :
guest : avoir un 2.6.25 ou plus, et faire "modprobe virtio_net" (pour un guest sous Windows, installer le driver win32 fournis par Qumranet)
host: "-net nic,model=virtio -net tap,script=/etc/kvm/qemu-ifup"
- Pour le périphérique block virtio :
guest: noyau 2.6.25+, modprobe virtio_blk
host: "-drive file=foo.qcow2,if=virtio"
nb: Pour le virtio block, pensez à mettre à jour le fstab du guest, car le disque est maintenant vu comme /dev/vdxy au lieu de /dev/sdxy. Je ne sais pas s'il existe un driver Windows pour le périphérique "virtio block" (le savez-vous ?), mais pour les guests sous Linux, ce n'est que du bonheur. Le support "virtio" fut mergé dans le noyau 2.6.25 standard (et backporté dans le 2.6.24 par défaut de la précédente Ubuntu, Gutsy).
[^] # Re: Utilisable ?
Posté par herodiade . En réponse au journal Ext4 va sortir !!!. Évalué à 1.
Oui, notez qu'il s'agit de déduplication par fichier (et non par blocs comme sur du NetApp par ex.).
> rsnapshot: http://www.rsnapshot.org
Avec des fonctionalités équivalentes (hardlinks pour les fichiers identiques, y compris identiques entre plusieurs machines), mais plus carré et plus complet, il y a backuppc :
http://backuppc.sourceforge.net/
> Samhain : http://la-samhna.de/samhain/
J'utilise ce dernier depuis un moment (pas encore eu le temps de changer), et je le déconseille à tout le monde (ie. ceux qui comme moi risquent d'être convaincus par http://la-samhna.de/library/scanners_2004.html ) :
- Les fonctionalités interessantes sont déportées sur une interface proprio (beltane) aux dépendances usinagazesques. Le dev. veut faire son beurre en vendant cette interface.
- Dans la version de debian etch, les outils manuels de mise à jour, checks, etc. ne marchent tout simplement pas. Il faut attendre que le daemon se debrouille :
# echo pouet > /bin/ps
# samhain --foreground -t check
# <-- rien, ni dans les logs, ni envoyé par mail, ...
À ceux qui utilisent d'autres HIDS (Aides, Osiris, ...), auriez vous des retours d'expérience à nous transmettre ?
[^] # Re: Impressionant
Posté par herodiade . En réponse à la dépêche Nouvelle version 2.6.27 du noyau Linux. Évalué à 10.
Tout à fait d'accord.
Mais, si je peux me permettre, et pour tenter de faire avancer le schmilblick, pourrai-t-on envisager d'appliquer, les prochaines fois, cette suggestion de Wikipédia concernant la qualité du style (WP:STYLE) :
« Évitez également les formulations du type "il est à noter que", elles alourdissent inutilement la phrase et relèvent du commentaire personnel. ».
Vérifiez l'astuce avec le texte de la dépêche : on peux enlever chacun des cinq « il est à noter que » sans dévoyer le sens mais en gagnant en légèreté. Sans quoi tout les linuxfriens ne tarderont pas à adopter ce tic de langage plus geek que littéraire ;).
Pour le reste évidement, la dépêche est superbe.
Une question maintenant. Le pilote out-of-tree GSPCA était maintenu par Michel Xhaard depuis des années, comme l'indique la dépêche. Pourtant Xhaard n'a participé à aucun des commits dans le récent répertoire drivers/media/video/gspca/ du noyau standard. La plupart des commits sont « Signed-off-by » Jean-Francois Moine et Mauro Carvalho Chehab. D'autre part le ChangeLog concernant GSPCA sur le site de Xhaard ([http://mxhaard.free.fr/news.html]) s'arrête abruptement au 24 december 2007. Est-ce que Michel Xhaard a abandonné le développement ? est-il contrarié par les modifications de son travail qu'implique l'intégration dans le noyau standard, ou la collaboration avec d'autres développeurs ?
[^] # Re: Autonomie
Posté par herodiade . En réponse au journal Le éCafé: un netbook Geode LX800 sous Mandriva. Évalué à 9.
Oui il ne faut pas sous-estimer l'écran.
Par exemple sur un IBM X40 (petit écran 10 pouces), l'écran consomme presque 5W lorsqu'il est en mode économique (faible luminosité).
A l'auteur de la dépêche : tu peux mesurer ça très facilement : 1) Installe et lance powertop, 2) passe ton ordinateur sur batterie (débranche l'alimentation), 3) mesure la consomation avec l'écran ouvert, 4) ferme l'écran, note la consomation, 5) fait une soustraction.
Le reste du matériel n'est pas sans importance aussi, et peut aussi bien expliquer le faible écart (20%) entre les deux ordinateurs dont parle le journal :
- Le bus USB est gourmand, les périphériques aussi (de façon variable) (et selon que support autosuspend usb ou pas...)
- Les cartes graphiques aussi. Certaines plus que d'autres. Et certains drivers (devinez lesquels) supportent certaines fonctionalités permettant l'économie d'énergie (comme la compression du framebuffer)
- Une CPU peu puissante ne parviendra jamais à passer sur un c-state bas lors de la lecture d'un divx, tandis qu'une cpu plus puissante pourra trouver un peu de temps pour se reposer (elle ne sera pas au max de son TDP, si tu veux).
- Le bus SATA (si moderne) offre des fonctions permettant d'économiser de l'énergie (par rapport au bus IDE classique) (ie. ALPM avec les controleurs AHCI, SATA AN, ...)
- Le Wifi est un grand consommateur d'énergie. Et la encore, tout les chipsets et tout les drivers ne sont pas égaux, loin s'en faut.
- La consomation d'énergie selon les disques durs (ou autre techno de stockage) est très variable
- La présence d'un lecteur CD sur un bus ne supportant pas les asynchronous notifications et avec hal qui tourne en mode polling
- Le chipset de la carte son et son driver (certains supportent un mode économe)
- Selon que la machine implémente des timers HPET ou pas, selon ses fonctionalités ACPI, ...
- La pile logiciel qui fait tourner la bête (beaucoup de travaux et progrès sur l'économie d'énerige sous Linux ces derniers mois => les noyaux plus récents sont plus efficaces, Xorg et ses drivers sont aussi très important, ainsi que hal, gnome-power-manager, la présence de beagle et consorts suffit à flinguer une batterie en un rien de temps, ...)
- ...
Je trouve au contraire que AMD s'en sort remarquablement bien, d'après ce que tu expose, et sachant à quel point Intel à mis le paquet pour que les drivers Linux pour son matériel soient les plus économes possible.
> Le cpu tourne normalement à 1.66Ghz. Je le bride à 530Mhz..
>
> Donc si le cpu n'est pas "bridé" et selon de combien tu peux diminuer
> en frequence tu peux augmenter ton autonomie de manière non negligeable.
Absolument pas, réduire manuellement la fréquence du processeur (le P-state ACPI) c'est plutôt une bonne façon de perdre de l'énergie. Ce qui est important c'est que la CPU reste le plus longtemps possible dans un C-state ACPI bas, ça ça fait économiser de l'énergie. Forcer la CPU a tourner en dessous de sa vitesse optimale la conduit à passer moins de temps dans un C-state bas.
Je croyais que cette légende urbaine était belle et bien épuisée...
Allez hop, deux explications par des gens faisant autorité dans le domaine :
http://www.lesswatts.org/projects/applications-power-managem(...)
http://mjg59.livejournal.com/88608.html
svp, arrêtez de colporter ce mauvais conseil. Il est préférable de laisser la CPU s'exécuter à sa fréquence nominale lorsqu'elle a du travail à accomplir. Ou mieux, adoptez le "ondemand frequency scaling governor", soutenu par les développeurs d'Intel.
[^] # Re: Ah bon ?
Posté par herodiade . En réponse au journal La controverse Canonical. Évalué à 10.
> Ne pourrait t'on pas leur adresser le même compliment pour les stimuler aussi ?
Perso je préférerai qu'on tire à boulets rouge sur Xandros (maintenant aussi propriétaire de Linspire), qui s'en est mis plein les fouilles avec le nouveau marché des ultraportables/netbooks, à décroché ces marchés à coups de vilaines concessions (type inclusion de drivers proprios et buggués, de soft proprios installés d'emblés, accords avec Microsoft comme Novell, etc), a un modèle de développement totalement opaque et fermé, et n'a pas reversé un copec ni un patch upstream.
Certes ils développent un peu : des softs proprios qu'ils gardent pour eux...
Xandros contribue tellement peu qu'on ne pense jamais à essayer de comptabiliser leurs contributions dans ce genre de gueulantes.
[^] # Re: En Pourcentage (plus parlant pour certains)
Posté par herodiade . En réponse au journal La controverse Canonical. Évalué à 10.
Absolument pas. Et les pourcentages de Free Tyrando indiqués ci-dessus sont faux.
En fait les chiffres reportés ici par patrick_g sont le nombre de contributions venant des principales distributions (uniquement). Et encore, lorsqu'on sait de quelle distribution un développeur se récalme (plus difficile à déterminer pour les distributions communautaires comme Debian ou Gentoo). Ne sont pas comptés, par exemple, les grosses contributions d'IBM, d'Intel, des amateurs (qui sont, en fait, les plus gros contributeurs), de personnes dont on ne sais pas trop pour qui elles travaillent, etc.
En pratique, Red Hat contribue à 11.9% des patchs du noyau, et Novell à 7.3%.
Les chiffres complets des dix plus gros contributeurs rassemblés par « groupes » sont:
1- Amateurs : 17 %
2- Red Hat : 11.9 %
3- Unknown : 8.3 %
4- IBM : 7.8 %
5- Novell : 7.3 %
6- Intel : 4.4 %
7- Consultants : 2.1 %
8- Oracle : 1.9 %
9- Linux Fundation : 1.8 %
10- SGI : 1.8 %
cf. la conférence de GKH justement : http://www.kroah.com/log/linux/lpc_2008_keynote.html
En particulier cette diapo : http://www.kroah.com/log/images/lpc_2008_keynote_15.jpg
À mon sens c'est ce qui fait la force de Linux par rapport à la majorité des projets libres : le fait qu'aucune société ne puisse prétendre contrôler ou diriger quoi que ce soit (la première société contributrice, RH, ne produit que 12 % des patchs), et du coups l'obligation de trouver un consensus technique satisfaisant des sociétés aux exigences et aux besoins très différents, de l'embarqué aux mainframes. Le fait, aussi, que les contributeurs amateurs/indépendants continuent d'être le plus grand groupe.
[^] # Re: Ce qui change rien au fait…
Posté par herodiade . En réponse au journal ath5k : confessions intimes, astuce, et retours. Évalué à 2.
Et le CPL, il pue du bec ? ;-)
# Vivement btrfs
Posté par herodiade . En réponse au journal Je veux bénéficier du bouclier fsckal !. Évalué à 6.
Il a aussi été question de ce problème dans ces dépêches http://linuxfr.org/2006/07/23/21124.html et http://linuxfr.org/~herodiade/23833.html .
Une des conclusion des développeurs est qu'il faudrait pour Linux, et rapidement, des systèmes de fichiers plus adaptés aux gros disques (d'autant que perdre des données est un chose, perdre un superblock en est une autre). Vivement en:btrfs !
Ce qui est amusant, c'est que c'est précisément l'inverse pour les SSD : plus le disque est gros, moins on risque d'avoir des blocks corrompus.
Du moins c'est ce qui devrait arriver, en théorie, lorsque les fabriquants implémenteront le wear-leveling correctement...
Val Henson a parlé de ce problème sur les SSD hier : http://valhenson.livejournal.com/25228.html
[^] # Re: Un peu pénible
Posté par herodiade . En réponse au journal VirtualBox 2.0 is out !. Évalué à 2.
Les patchs offrant le support EHCI vient d'être proposés.
> Tu as trouvé cette info où, sur la ML ? J'aimerai bien aller voir où ils en sont ...
Sur la mailing-list de qemu : cherche les mails envoyés par Max Krasnyansky en août et septembre.
[^] # Re: Un peu pénible
Posté par herodiade . En réponse au journal VirtualBox 2.0 is out !. Évalué à 4.
# Pour le geek préssé :
Posté par herodiade . En réponse au journal Soft Maker 2008 sous Linux : un concurrent à OpenOffice ?. Évalué à 10.
[^] # Re: User-Agent
Posté par herodiade . En réponse à la dépêche Chrome, le futur navigateur de Google. Évalué à 4.
Bonjour le hack... et si mon navigateur n'est pas connu du site, le site ne sais pas où trouver le champs indiquant la langue dans la chaîne User-Agent, et il retourne une langue au pif ? Et comment le site détermine-t-il le charset que je supporte pour afficher ma langue ?
Pour transmettre *proprement* ce genre d'informations, le navigateur l'envoi normalement dans des champs dédiés de la requête. Par exemple "Accept-Language" permet d'indiquer les langues supportées, par ordre de préférence. Et tant qu'à faire, on envera aussi une en-tête "Accept-Charset" indiquant les jeux de caractères supportés par le navigateur, "Accept-Encoding" pour indiquer un éventuel support de la compression à la volée, etc...
> indiquant une correspondance de compatibilité, n'est-elle pas une manière
> élégante de permettre à un site de savoir comment gérer un nouveau navigateur
Précisément pas, puisque se baser sur le ''User-Agent" pour déterminer les fonctionnalités supportées implique de connaître par avance toutes les fonctionnalités supportées par chaque navigateur. Et si un bug est corrigé dans une mise à jour mineur du navigateur ? et si c'est un nouveau navigateur qu'on ne connais pas ? ...
Bref, en général on essaiera de déterminer *dynamiquement* si une fonctionnalité est supportée. Comme les autoconf/automake testent un par un les prérequis pour chaque ressource utile plutôt que de déterminer ce qui est disponible globalement à partir de la version de l'OS, on évitera les évaluation globales, qui aboutissent si souvent à "Ah votre navigateur n'est ni Internet Explorer 6 ou 7, ni Firefox 2, circulez nous n'avons rien à vous montrer". L'alternative consiste à construire un site conforme aux standards, dont les javascripts testent dynamiquement la présence des fonctions requises, et des <!--[if IE 7]> & co, ponctuels, autour des hacks spécifiques corrigeant les bugs (non respects des standards) connus...
C'est à cause de ce genre de raisonnements qu'on trouve encore des sites "optimisés pour Internet Explorer", ou des sites façon impots.gouv.fr qui refuse de fonctionner parce que le plugin java d'Ubuntu et Fedora a un nom qu'il ne connaît pas et considère en conséquence qu'on ne dispose pas de plugin java.
[^] # Re: Emacs est mort. Paix à son âme. Google Chrome est né ! Vive Chrom
Posté par herodiade . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 4.
Oui bien sûr. Mais si j'évoquais SELinux, c'était pour souligner que cette architecture devrait permettre aux distributions Linux de s'éclater à blinder la sécurité aux petits oignons, depuis le système / l'extérieur du logiciel lui-même, et bien au-delà des mesures de sécurité et d'isolement (sandboxing) pré-intégrées par Google dans Chrome. Bref, c'est une mesure de sécurité qui appelle à d'autres mesures de sécurité ;)
Et ça ne devrait pas traîner, tout le monde à la même idée. Russell Coker, développeur SELinux dit :
http://etbe.coker.com.au/2008/09/02/google-chrome-the-securi(...)
The use of multiple processes in Chrome is just begging to have SE Linux support added. Having tabs opened with different security contexts based on the contents of the site in question and also having multiple stores of cookie data and password caches labeled with different contexts is an obvious development.
Sans rapport : la page listant les licences des logiciels inclus dans Chromium est intéressante, car elle indique les bibliothèques utilisées : http://code.google.com/chromium/terms.html
- bsdiff, bspatch : ils ont donc déjà prévu les mises à jour incrémentales
- pthreads for win32 : ça de moins à porter vers les systèmes posix
- lzma, bzip2 : ça semble un poil redondant
- tlslite (c'est une lib de crypto pour python) + le fait que python soit une des dépendances pour le build : il semblerait donc que Chrome embarque un moteur python
- WTL : c'est la mauvaise nouvelle. Ça signifie que google n'a pas fait le choix d'un toolkit portable et multiplateforme, et que le port sur Linux sera donc très divergent ; s'ils n'ont pas commencé ce port, on n'est pas prét de voir Chromium tourner sur le Desktop Linux (s'ils portent Chromium sur le googlephone, je suppose qu'ils utiliseront leur toolkit java ad hoc)... On peut aussi supposer que tout les développeurs du projet travaillent tous sous Windows, que le port Linux, quand il arrivera, sera un citoyen de seconde zone, peu testé,...
[^] # Re: Emacs est mort. Paix à son âme. Google Chrome est né ! Vive Chrom
Posté par herodiade . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 2.
> ce n'est pas tres pratique pour relier ça a un onglet précis
Il suffit au navigateur de suffixer le nom du processus par le nom de l'onglet / la page en cours.
Comment crois-tu que, par exemple, les processus fils d'openssh indiquent leur fonction et le nom de l'utilisateur en cours ? man setproctitle(3).
Pour ma part, je suis impatient de voir ces « onglets et plugins dans des processus séparés ». Ça permettra peut-être de chrooter tout ce qui concerne les pages proprement dites (ie. sans affecter le processus qui contient les menus ouvrir/enregistrer sous).
Ou, plus encore, ça devrait permettre de faire des polices SELinux très fines et beaucoup plus sérées (qu'avec le modèle monolithique de ff) pour tout les processus qui s'occupent du parsing et du rendu des pages, de l'exécution du js ou des plugins comme flash.
[^] # Re: CERTA ...
Posté par herodiade . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 3.
Ça explique que Red Hat ne se soit pas trop pressé pour distribuer une mise à jour : le CVE-2007-4752 date d'octobre 2007. Ils ont visiblement attendu d'avoir une vraie raison d'upgrader le paquet pour distribuer ce fix.
[^] # Re: deux fois ...
Posté par herodiade . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 10.
Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.
La raison est très simple : openssh est un logiciel stratégique pour la sécurité, parce qu'il gère l'accès distant et complet au système hôte, et parce qu'il est installé sur une grande majorité de serveurs Unix (je pense que c'est le daemon le plus souvent présent sur un serveur unix, plus encore qu'apache, dovecot ou sendmail). La faille du paquet openssl de Debian affectait, en fait, beaucoup d'autres logiciels (dont OpenVPN par exemple), mais on s'est inquiété en premier lieu de ses conséquences sur openssh précisément pour ces raisons. De même, cette position « privilégiée » d'openssh explique clairement pourquoi ce logiciel a été choisi par le pirate des serveurs Red Hat : même s'il avait la possibilité de générer un binaire trafiqué puis signer n'importe quel paquet inclus dans RHEL (ce qui est probable), openssh restait en toute logique la cible de premier choix.
Les failles d'OpenSSH sont rarissimes quand on considère son exposition. Et quand elles arrivent, ce sont soit des problèmes de détail aux conséquences mineures (type vol possible d'un cookie xorg par root), soit failles très sophistiquées et complexes, mais jamais de grossières erreurs de programmation. Ce logiciel est développé par les gens d'OpenBSD, qui sont connus pour faire de leur mieux pour essayer d'éviter les problèmes de sécurité, même lorsque c'est aux dépends des fonctionnalités ou des performances. Et c'est certainement l'un des (sinon _le_) logiciels libres les plus audités : autant par les pirates (la découverte d'une faille dans ce logiciel leur assurerais une efficacité maximum), par les consultants en sécurité (une telle découverte leur garantirais une énorme promotion), par les équipes de sécurité des divers distributions et des autres unix (y compris Mac OS, AIX, Cisco, Juniper & co, qui incluent aussi ce logiciel), par les agences gouvernementales type NSA, il fait partis des programmes audités en boucle par coverty, ... C'est aussi un des premiers logiciels a avoir été mis sous la protection/surveillance de SELinux et d'AppArmor (et dans une moindre mesure, de systrace - et il est généralement compilé avec propolice/-fstack-protector), et un de ceux pour lesquels ces outils sont activés par défaut sur plusieurs distributions : un comportement "bizarre" (ie. dû à une faille encore non révélée en cours d'exploitation) dans ce logiciel se remarquerai très vite.
À mon sens, l'utilisation de serveurs ssh alternatif est moins un gain de sécurité par la diversité qu'un risque dû au manque d'audit intensif de ces derniers (autrement dit, une tentative de sécurité par l'obscurité).
Plus sérieusement, si vous vous inquiétez d'utiliser des logiciels dont le code est fagile et très régulièrement affecté par des problèmes de sécurité, regardez plutôt du coté de l'historique sécu de PHPMyAdmin ou Clamav (ps: et bravo aux distributions responsables qui ont choisi de ne _pas_ inclure cette passoire de phpmyadmin). Je crois qu'il ne se passe pas un mois sans que je soit obligé d'upgrader ces logiciels dans l'urgence sur certains serveurs...
# Le style complaisant de Phoronix
Posté par herodiade . En réponse au journal AMD Catalyst 8.8. Évalué à 10.
Je suppose que c'est la condition (entretenir des bonnes relations) pour que les constructeurs leur envoi du matériel à tester, leur donne quelques informations en primeur, leur accorde des interviews, etc.
L'indépendance de la presse et l'esprit critique du journaliste, eux, repasserons. Le pôle marketing d'AMD ne pouvait espérer mieux.
/me retourne à la lecture de lwn.net
[^] # Re: Moulinette
Posté par herodiade . En réponse au journal Coup de gueule contre Canonical. Évalué à 7.
> pourraient être utilisées pour un projet autre que l'original.
Oui, tout à fait. C'est ce que laisse entendre leur FAQ, https://help.launchpad.net/Translations/LicensingFAQ :
« we believe that the advantage of having large translation memories for free software far outweighs the risk of having free software translations end up in proprietary software. ».
Pour ceux qui ne connaissent pas, les translation memories sont des bases de données de chaînes, expressions, mots ... déjà traduits et réutilisables. http://en.wikipedia.org/wiki/Translation_memory
Couplées à un bon logiciel (ce qui pour le moment fait plus ou moins défaut dans le monde libre), elles facilitent et accélèrent grandement le travail du traducteur, et améliorent la cohérence globale des traductions (par exemple : elles aident à faire en sorte qu'une même chaîne soit traduite identiquement, par exemple, entre plusieurs application différentes du même environnement).
Même pour un environnement constant (par exemple, gnome) on trouve des applications sous des licences très différentes et plus ou moins incompatibles (la plupart des libs de gnome sont sous LGPL, les applications sont souvent GPLv2-only, ou GPLv3, ou MPL, ...). La seule possibilité qu'ai Launchpad pour constituer une translation memory (dont on a horriblement besoin !) cohérente et réutilisable dans ces diverses applications et de la constituer sur un dénominateur commun, une licence compatible (au niveau fichier source) avec ces diverses autres licences : d'où le choix de la licence BSD.
Et on peut désormais supposer que Canonical développera prochainement un CAT ([http://en.wikipedia.org/wiki/Computer_assisted_translation]) web based, ce qui serait vraiment une très bonne chose, ... si tant est que ce soit une application libre...
[^] # Re: Et SCTP ?
Posté par herodiade . En réponse au journal BIND, 2ème édition. Évalué à 2.
Ah bin oui, tu as tout à fait raison.
> selon moi les transfert de zone (AXFR) ne font pas partie du protocole DNS,
> c'est une problématique satellite. Il existe d'autre méthodes pour transferer
> ses zones : http, rsync, ssh, par clé USB, etc...
Ah oui mais là ton transfert n'est pas interopérable entre serveurs : ça devient un transfert de fichiers au format d'une implémentation de serveur DNS. Or interop => protocole+specs, c'est donc pas plus mal que cette question soit normalisée ;)
Un autre intérêt d'AXFR, c'est que le proto est implémenté par le serveur lui-même (au lieu d'un outil externe comme rsync), et ça lui permet de savoir qu'il doit recharger la zone dès qu'elle est rafraichie (rsync, ssh ou http ne font que transférer des fichiers, sans se préoccuper de l'applicatif).
Cela dit, je suis d'accord pour le qualificatif de « problématique satellite ».
[^] # Re: Des histoires de succès ?
Posté par herodiade . En réponse à la dépêche Nouvelle version Om 2008.8 pour les smartphones OpenMoko. Évalué à 1.
> bien qu'EFL
D'ailleurs, quelqu'un pourrait-il expliquer la raison de cet étrange,
apparement lourd, complexe et propice aux bugs mélange (Qt + X11 + EFL)
en lieu et place du de QtE/Qtopia pur (et son support framebuffer natif) ?
C'était pour faire plaisir à Rasterman et l'encourager à venir bosser sur
OpenMoko ou bien ou bien Qt ne suffit réellement pas ?
[^] # Re: Et SCTP ?
Posté par herodiade . En réponse au journal BIND, 2ème édition. Évalué à 1.
Ouais, d'après la page de man, à l'heure actuelle il semble qu'UDP soit le choix par défaut, puis que le resolver offre une option pour forcer le TCP. A moins que la phrase de WP signifie que les utilitaires systèmes d'HP-UX requètent explicitement avec le bit RES_USEVC ? http://docs.hp.com/en/B3921-90010/resolver.3N.html
> des rfcs qui n'exigent pas qu'un serveur dns accepte du tcp.
La RFC 1035 n'« exige » (must ou shall) rien mais indique, si l'on peut dire à pied d'égalité (section 4.2) « The Internet supports name server access using TCP [RFC-793] on server port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP port 53 (decimal) ». Et précise aussi : « Messages carried by UDP are restricted to 512 bytes ».
La RFC 1034 discute d'ailleurs brièvement de l'utilisation de TCP dans les resolvers (et précise, à toutes fins utiles que « Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests. » (encore heureux)).
[^] # Re: Et SCTP ?
Posté par herodiade . En réponse au journal BIND, 2ème édition. Évalué à 5.
Les serveurs, même de taille modeste tiendraient la charge il me semble (sauf peut-être les root servers ?). Surtout s'ils utilisent les syncookies et ont suffisamment de RAM.
Les problèmes que causeraient une utilisation systématique de TCP pour le DNS sont plutôt les risques liés aux congestion, et aux augmentations de latence.
Le premier type de problème (congestion) n'est pas insoluble. L'augmentation du débit n'a pas que des conséquences néfastes (comme la possibilité de flooder/bruteforcer les DNS), elle permet aussi de gérer un trafic légitime plus important ; les outils de routage et de QoS se sont améliorés depuis l'invention du DNS en 1983 :).
La latence des réseaux s'est aussi améliorée, mais une généralisation absolue du TCP pour le DNS n'est pas possible bien sûr. Il faudrait toujours des solution de replis pour par ex. les liaisons satellites, gprs, TOR, & co, quitte à ce que les providers leurs fournissent des caches qui fassent passerelles UDP en interne <->TCP vers le monde. Je crois - de mémoire - que MaraDNS fournis un proxy de ce type, et il y a aussi le proxy de TOR (ttdnsd).
Sinon, notez au passage que le protocole DNS prescrit _déjà_ le support TCP (utilisation obligatoire pour les paquets de plus de 512 bytes, utilisation facultative en deçà). Les serveurs DNS (et les bibliothèques de résolution des OS) implémentent ce support depuis longtemps déjà.
L'article DNS de la Wikipédia en langue anglaise dit que le resolver d'HP-UX utilise déjà systématiquement TCP pour ses requêtes DNS. J'adorerais avoir la même possibilité de forcer l'utilisation systématique de TCP sous Linux aussi (par ex. avec une option de resolv.conf). Et aussi, de pouvoir paramétrer un cache bind de la sorte (ie. "utilisation systématique de TCP pour toutes les requêtes sortantes / partout où je ne suis pas authoritative").
Ah, aussi : OpenDNS fournis des serveurs DNS récursifs publics supportant le TCP.
Enfin : TCP seul (sans crypto, ie. DNSEC )laissant la possibilité d'attaques man-in-the-middle, ce n'est pas suffisant pour se protéger des censures/redirections de traffic au niveau des opérateurs et des FAI. Je crois que c'est ainsi que l'Italie bloque l'accès à The Pirate Bay, et je ne serais pas surpris que notre gouvernement actuel (ou une loi européenne) contraigne les FAI à ce genre de cochonneries...
# « I think the OpenBSD crowd is a bunch of masturbating monkeys » (Linu
Posté par herodiade . En réponse au journal The Linux developers are selfish dickheads. Évalué à 1.
C'est de Linus Torvalds, hier, sur LKML. Moi je trouve ça rigolo.
http://kerneltrap.org/mailarchive/linux-kernel/2008/7/15/250(...)
Est-ce que patrick_g va faire un journal pour s'en offusquer au premier degré (comme à chaque vanne de TdR) ?
[^] # Re: et la maintenance du pilote ? (doubles standards)
Posté par herodiade . En réponse au journal The Linux developers are selfish dickheads. Évalué à 5.
Possible. Si cette option n'est pas contre-productive pour la possible libération de la doc. Si au moins tout à été fait pour que ça ne soit qu'un dernier recours. La tolérance aux NDA immédiatement annoncée et mise en avant par le LDP n'est - au minimum - pas forcément quelque chose qui encourage très fort les fabriquants à chercher beaucoup plus loin, par exemple.
Prenons pour exemple le support pour les contrôleurs RAID sur SCSI/SAS d'Adaptec, parce que c'est intéressant et critique (nos données peuvent en dépendre). Le pilote Linux est développé en interne par Adaptec, et est notoirement de qualité exécrable (il semblerait notamment qu'Adaptec cherche à factoriser le code du pilote pour les divers OS qu'ils supportent pour économiser de la main d'oeuvre), et peu maintenable par les développeurs extérieurs. Même Ingrid est plus libre que ça.
De plus, aucun logiciel libre ne permet de gérer les fonctionnalités des contrôleurs RAID Adaptec modernes à chaud (savoir si une array est en mode dégradé, quel disque est en panne, ajouter un hotspare, lancer une reconstruction, créer/détruire une array en RAID X, ...), ce qui rends ce matériel totalement inutile si on ne souhaite l'utiliser qu'avec du logiciel libre (sérieusement, pourquoi utiliser un contrôleur RAID qui ne permet même pas d'être alerté lorsqu'on a un disque en panne, qui accumule bugs matériel, bugs bios et bugs driver alors qu'on peux faire du RAID logiciel de bonne qualité, stable, ouvert, avec toutes les fonctionnalités utiles, gratuitement ?). On peux aussi se demander à quel point Adaptec s'efforce de corriger les bugs pour les générations de matériel qu'ils ne vendent plus...
Il y a quelques années, OpenBSD disposait d'un pilote équivalent à celui de Linux (et pour cause, c'était le même code) pour ce matériel. Ce pilote était vaguement maintenu par un ancien d'Adaptec. Las de ne pouvoir le supporter proprement (évolutions, corrections des bugs) et complètement (gestion à chaud comprise), Theo a lancé un dernier appel public pour la libération des spécifications ; Adaptec s'obstinant à ne pas livrer la doc, OpenBSD a tout simplement décidé de jeter son pilote. Ce qui est hardi pour un OS plus ou moins dédié aux serveurs.
On peux en conclure, selon son point de vue, que Theo est un grossier intégriste psychorigide qui se moque des utilisateurs, ou qu'un peu de solidarité de la part des devs noyau Linux aurait été bienvenue (parce que vue la part de marché de Linux sur les serveurs, Adaptec n'aurai pas tenu un bras de fer bien longtemps pour de telles queues de figues).
# et la maintenance du pilote ? (doubles standards)
Posté par herodiade . En réponse au journal The Linux developers are selfish dickheads. Évalué à 10.
> fonctionnement du hardware pour écrire un pilote
Je pense que tu ne perçois pas tout le problème (d'où tes commentaires sur le reste).
Il ne s'agit pas seulement d'écrire un pilote, mais aussi de le maintenir. Soit, entre autres :
- Corriger les bugs rapidement
- Apporter de nouvelles fonctionnalités non prévues dans le pilote initial (supporter le suspend-to-ram, par exemple)
- Pouvoir facilement refactorer un sous-système (type gestion des périphériques blocs, des périphériques réseau, enlever un verrou global, changer de stack wifi, ...) sans être bloqués par ce qu'on ne sait pas quoi faire d'un pilote intouchable.
- Continuer de maintenir le pilote malgré le turn over des développeurs (et même lorsque le constructeur préférerai qu'on encourage l'achat de nouveau matériel)
Si on prends en compte ces contraintes supplémentaires (en plus de l'écriture d'un driver initial, one shot, fut-il libre), on peut affirmer qu'en effet :
- Même lorsqu'un pilote libre est intégré dans le noyau vanilla, si seule Red Hat (au hasard) dispose des docs, cette compagnie sera plus à même de servir ses clients (corriger les bugs, etc) que ne le sera SuSE (au hasard encore).
- Lorsque le constructeur souhaite pousser l'adoption d'une nouvelle génération de matériel, il est peu probable qu'il accepte de continuer à livrer les docs sous NDA pour le vieux matériel. Dès lors, on il ne nous reste qu'à croiser les doigts pour que le développeur (ou la compagnie) disposant de cette doc ne disparaisse pas.
- Et n'oublions pas que, effectivement, les distributions commerciales de Linux négocient leur bénédiction pour le support des serveurs (IBM, HP, Sun, ou Dell on généralement besoin que leurs serveurs soient "officiellements" supportés par RHEL et SuSE, mais ces dernières n'exigent pas que le matériel soit documenté de façon ouverte).
Pour finir, je continue d'être surpris par la tolérance envers les NDA dans la communauté du libre. Lorsque Greg Kroah-Hartman a lancé son Linux Driver Project en annonçant qu'il fournissait un cadre blindé pour les constructeurs souhaitant une diffusion restreinte des docs par NDA, et que c'était encouragé, j'ai sauté au plafond !
Prenez le temps de comparer avec ce qu'on (les personnes sensibles au libre) dit et pense des format ouverts et libres, des protocoles standards, ... ; à savoir : que la disponibilité d'une implémentation de référence (fut-elle libre, comme pour le .doc dans abiword, netbios dans samba, ...) ne suffit pas à rendre le format/protocole libre : il faut au moins la doc soit publiquement disponible (et c'est une condition nécessaire mais non suffisante).
Pourquoi ne pas exiger des constructeurs de matériel ce qui nous parait aller de soi pour les concepteurs de protocoles et formats de fichiers ? Theo n'a pas tort, ça fait très double standard.