Tu semble faire un procès d'intention basé sur tes a priori concernant Bové en général. Commente son texte précisément.
En l'occurrence, il ne dénonce pas les multinationale per se, mais leur action en rapport avec les brevets et DRM (lobbying de l'OEB et lors de la DAVDSI, déséquilibre lors de la protection contre les brevets, etc...).
Sincèrement, peut-tu soutenir que les particuliers, les assos et les PME ont eu autant de poids que les multinationales lors des décisions législatives en faveur des brevets et de la propriété intellectuelle (EUCD, DADVSI, ..) ?
Abonné de Free en dégroupage total, j'ai été décablé deux fois par France Telecom (qui continue de gérer l'arrivée de la boucle locale : ils peuvent brancher/débrancher le brin de cable qui vous relie à votre FAI).
Dans ce genre de situation, la procédure est lourde : votre FAI doit faire trois demandes successives à France Telecom (et attendre à chaque fois leur réponse) avant d'avoir le droit de venir constater, accompagné d'un ingénieur FT, l'état du cablage en salle FT. Les frais d'intervention sont à charge du FAI plaignant si le cablage est correct, de FT s'il ne l'est pas.
Un amis qui travaille au support Free m'avait expliqué que dans la grande majorité des cas, les connexions dégroupées tombent magiquement en marche la veille de l'expertise... et c'est précisément ce qui m'est arrivé.
> Fedora n'offre pas de proprio, ne supporte pas le proprio.
À ce sujet, je ne doute pas que Fedora ai des raisons valables, bien réfléchies et expliquées sans ambiguité (ps: si quelqu'un connait une URL décrivant la position de FC sur ce point ...), mais il ne faut jamais oublier que ces questions de logiciels libres implémentants des technologies brevetées sont toujours des compromis en eau trouble. Il y a mille nuances possibles, des évaluations des risques divergentes, ...
Bref, les pratiques et positions des distributions ne sont jamais tout noir ou tout blanc. Exemples :
- Fedora inclus, si je ne trompe, le support FAT32, les logiciels mono, OpenOffice.org (avec support .doc/.xls), Samba et d'autres, qui enfreignent très certainement les brevet de notre ennemi le plus acharné.
- Certains considèrent l'inclusion de firmwares binaires (dont les sources ne sont pas publiées) dans un header sous GPL inclus dans le noyau comme une entorse si grave à la GPL qu'il est exclus de redistribuer le noyau vanilla tel quel, d'autres considèrent que ce problème n'est pas prioritaire.
- Les contraintes légales sont différentes selon les pays où et d'où sont distribués les logiciels. Pour mémoire, c'est la raison pour laquelle OpenBSD, distribué depuis le Canada, a longtemps été le seul OS qui incluait des fonctions de cryptographie fortes interdites par la NSA à l'exportation depuis les USA. Les brevets logiciels ne sont pas (ou pas encore) valables en Europe. Je suis prêt à parier que la Chine impose d'autres contraintes spécifiques. Etc. Le fait de se conformer aux contraintes d'un pays plutôt qu'un autre est souvent déterminé par l'emplacement du siège social de l'éditeur plutôt que par des valeurs "universalistes".
- Debian inclus le support mp3. Pas faute d'une position ferme en faveur du libre, mais en raison d'interprétations ou de contraintes divergentes sur ces questions.
- ...
> Pour FC6 et les paquets sources :
> FC : 1155
> FE : 2794
C'est pas mal, et je ne veut pas sous estimer le travail des devs de FC.
Je voulais juste expliquer une des raisons de ma déception, moi qui venait d'une distribution concurrente mais néanmoins amie.
Les paquets sources du seul dépôt "main" de la Debian stable (Sarge, qui date presque de deux ans) :
grep ^Package: /var/lib/apt/lists/ftp.crihan.fr_debian_dists_sarge_main_source_Sources | wc -l
8728
C'est plus que le double. De ce fait, on prends des vilaines habitudes d'utilisateur gâté ;)
Basé sur ma dernière expérience, qui remonte a un an et demi environ :
- Je trouve yum insupportablement mou. C'est atroce. Apt est, comment dire, ... mieux !
- Peu de packages (la derniere fois que je l'ai testé, à l'époque de FC 4, et en comparaison avec Debian ou Ubuntu).
- Une certaine opacité (qui m'avaient semblé plus « corporate » que franchement communautaire) concernant certaines décisions, le rapport un peu compliqué à Red Hat (degré d'indépenance ? pas facile à déterminer, pour le newcomer que j'étais, et il me semble que c'était confus pour d'autres que moi) ou la documentation (en comparaison à Debian et OpenBSD, - et Ubuntu pour la doc/support communautaire). M'a semblé tout de même moins opaquo-corporate que Mandriva et SuSE, et puis ce n'est qu'une première impression.
- Plus bleeding edge que les autres (les mises a jours sont un peu dangereuses, pour un serveur - l'inverse de Debian sur ce point).
+ Plus bleeding edge que les autres, ce qui nous permet de faire notre devoir d'utilisateurs-citoyen et remonter les bugs au plus tot à l'upstream, pour les nouveaux softs ou technos. Très bien pour une utilisation desktop.
+ Sans doute la distro ayant le plus de contributions majeures upstream en particulier pour le kernel, gcc et la glibc. Les développeurs sont ultra compétents et semble vraiment coder, pour le bien de tous, et pas seulement écrire de nouveaux thèmes gnome et des wikis en python ...
+ Securité prise au serieux : -fstack-protector par defaut depuis un moment deja, SELinux, FORTIFY_SOURCE, ... (bien mieux que Debian et Ubuntu sur ces points : imaginez que etch va sortir et peut-être rester la Debian stable durant plusieurs années sans être compilée avec -fstack-protector ! )
Voila. Je l'ai abandonnée à cause de yum et parce que je ne comprenais pas bien qui décidait (entre RH et la communauté).
Il semble bien que les développeurs d'OpenBSD vont devoir changer leur fier slogan "Une seule vulnérabilité à distance dans l'installation par défaut, durant plus de 10 ans !".
C'est fait : http://www.openbsd.org/ dit maintenant « Only two remote holes in the default install, in more than 10 years! ».
Bah, je trouve justement que les clavier des stations HP-UX (style Visualize) ont un excellent toucher. Il y a écrit QWERTY sur les touches, mais rien n'empêche de le mapper en azerty (c'est précisément ce que j'utilise en ce moment, car en plus, ils ont le bon gout d'avoir une prise ps/2 et d'être compatible avec les pc !).
Une remarque en passant : sur la page du projet (comme dans le topic du canal irc #nouveau), ils se sont donné la peine d'obscurcir l'adresse email : « Just email it to renouveau dumps <åt> gmail.com. ».
Si un modérateur passe par là, pourrait-il rectifier l'adresse email de la dépêche (si possible avant que ça n'atterrisse dans les caches de google & co.) ? merci.
Dans les distributions qui contribuent, il n'y en a que deux qui sont "visibles" !
Et ça reste vrai pour la liste complète des 20 plus gros organismes contributeurs (pas seulement les 6, comme je croyais en lisant le journal) : les seules distributions listées sont Novel et Red Hat.
Je savait que les autres avaient très peu de kernel hackers, mais pas à ce point ...
Donc si je compte bien : Mandriva, SuSE et maintenant Ubuntu ont choisis compiz , c'est ça ?
Qu'en est-il de Fedora ? S'ils choisissent aussi compiz, c'est tout tranché :
- tout les grands développeurs x11 /mesa/kernel (ceux de RH + SuSE, en gros) bosseront pour des distros avec compiz (déjà que beryl semble souffir séchement de l'absence de « pointures » à la Reveman ...)
- les utilisateurs de compiz seront largement plus nombreux (donc les tests, bugs reports etc. seront massivement faits sur compiz, lequel dispose d'un code qui est à la base plus propre)
- l'effet « communauté » d'utilisateurs dont bénéficie beryl pour être plus bleeding edge risque fort de se décaler vers compiz au fur et à mesure que les grosses distros « desktop » sortiront avec un « composing window manager » pré-intégré.
Excellent, merci : ce fichier contient un lien vers un enregistrement au format mp3.
mplayer -ao pcm:file="/tmp/tmp.wav" http://www.radiofrancepodcast.net/podcast/18957-25.02.2007-I(...)
oggenc /tmp/tmp.wav -a "Michel Serres" -G "Speech" -d "20070225" -N 1 -l "Le Sens de l'info" \
-t "Michel Serres sur France-Info (Le Sens de l'info, 25 février 2007)" \
-o ~/michel_serres_sur_france_info-le_sens_de_l_info_20070225.ogg
rm /tmp/tmp.wav
Et hop, le média est libéré (quant au contenu, on a encore du travail à faire auprès de radio-france ...).
Mais comment as-tu fait pour lire ce fichier ?
$mplayer -nocache pnm://son.radio-france.fr/chaines/itema/8957/8957_25022007_2007I8957S0056.rm
[...]
Connecting to server son.radio-france.fr[195.154.101.20]: 7070...
Cache size set to 0 KBytes
input_pnm: got message from server while reading stream:
You need to obtain a new player to play this clip. Please point your web browser to http://www.real.com and download the latest RealOne Player from RealNetworks. Once you have installed it you should try this clip again.
Pas mieux avec vlc.
La diffusion en directe sur radio-france est accessible en ogg et mp3, mais pour les archives, existe-t-il une alternative qui ne m'impose pas RealOne ?
Mais ce sont des cartes mères pour serveurs (format SSI, double socket pour Opteron, etc). L'annonce pour la Gigabyte servait surtout à signaler au grand public qu'on pouvait enfin choisir des CM avec un bios libre pour son desktop (et pas qu'il s'agissait de la première CM avec un bios libre : il y en eu a d'autres avant, notammment dans l'embarqué).
Quelques trucs intéressants à noter sur ces deux CM pour serveur supportées par linuxbios :
* La K9SD Master-S2R (MS-9185) intègre un BMC (http://en.wikipedia.org/wiki/Baseboard_management_controller ) avec sa propre interface réseau. C'est surement là que le linuxbios montre toute sa pertinence. J'ai l'impression que la K9D dispose d'une fonctionalité similaire (je ne comprend pas le chinois, mais les sépcifications parlent de "1 個 RJ45 接頭 for KVM" en plus des cartes réseau normales).
* L'EEPROM de cette CM est plutôt gros : 8 Mo. Est-ce un pré-requis pour supporter linuxbios et ses fonctionalités les wizzbang ?
* Dans les deux cas, le code a été écris par MSI eux-même (et ça, c'est le pied ;)
* Petit bémol, le chipset ethernet gigabit utilisé (au moins sur la K9SD) est un Broadcom (à tout les coups un tg3, qui n'est pas spécialement LL-friendly : specs sous NDA, firmware pas très libre, ...).
* Pour la K9SD, il est dit « The code was contributed by bxshi of MSI, based on code for the NVIDIA MCP55 by Yinghai Lu of AMD. ». Ce qui est épatant dans cette affaire, c'est que le travail d'un ingénieur d'AMD sur le chipset d'un concurent (NVIDIA est concurent d'AMD depuis leur fusion avec ATI non ?) permet le support de plusieurs CM. Jolie collaboration.
* Theo de Raadt disait que les fabriquants de matériel info Taiwanais étaient désormais les plus coopératifs avec le LL, et de loin (penser à Ralink ou Realtek), là où les constructeurs américains s'emmurent dans une culture du secret et sont paralysées par l'angoisse des problèmes juridique. Les constructeurs de CM Taiwanais (MSI et Gigabyte) semblent lui donner raison. Achetons Taiwanais ! ;)
* Les deux CM intègrent un chipset graphique pour lequel on a un driver libre, le Radeon 7000 (mais pas très performant je crois).
Oui, ce que je que je voulais dire, c'est qu'il cherchait moins à comparer de façon scientifique les deux OS qu'à valider ses patches pour FreeBSD. Ses nouveaux tests (avec le 2.6.20.1 etc.) semblent plutôt motivés par l'envie d'aider les devs kernel Linux (en particulier Davej) à trouver ce qui cloche (et ça cloche, c'est certain, d'autres ont rencontré le même problème en utilisant une autre distro : http://tweakers.net/reviews/649/9 ) plutôt qu'à enfoncer Linux.
Je crois d'aileurs que le post suivant dans son blog confirme mon interprétation anti-trollistique (http://jeffr-tech.livejournal.com/ ) :
Well my last post made it to osnews.com so I'd like to say a few things about it.
1) I never declared FreeBSD the winner. I pretty much said I expect something is flawed with the test for linux to perform so poorly. The post was asking for advice and giving my early results. Without results I have nothing to base my requests for help on.
2) I realize the deck is totally stacked here. We have an avid FreeBSD kernel hacker with a few private patches on one end, and a default fedora stable install on the other. I used fedora stable because I had to install it on this box for a contract I'm working on.
I'm not trying to make a pissing contest with Linux, I'm trying to improve FreeBSD.
Ce que je résumerai par : « soyons constructifs ».
Dell vient d'annoncer qu'ils certifiraient plus de machines pour Linux (via Novell), qu'ils vont faciliter le choix des logiciels pré-installés (ou pas), etc. Youpi !
Oui, HP, IBM, Sun, les distros Linux ... même le serveur SSH de Cisco est basé sur OpenSSH.
Ce qui fait que Theo de Raadt était désolé, lorsque les finances du projet OpenBSD/OpenSSH étaient dans le rouge, qu'aucune de ces charmantes entreprises n'ai jamais fait le moindre geste de soutient (les dons viennent toujours de particuliers, de fondations comme la moz' fund' et de GoDaddy, mais pas des distros commerciales ni de Sun & co.). http://kerneltrap.org/comment/reply/6550
Je crois qu'il est déplacé d'utiliser ce graphe pour conclure que FreeBSD est plus performant que Linux ou FC6.
N'oubliez pas que ce test est mené par un développeur noyau de FreeBSD pour qui le plus important est de valider la pertinence de ses patches/améliorations : à mon avis, il exécute aussi ce test sur Linux pour donner une référence. Après tout, c'est logique : Linux est connu pour être la plateforme dont mysql tire le meilleur profit : si on se comporte aussi bien que lui, c'est qu'on est au point. L'auteur a conscience que l'optim de Linux n'est pas son domaine de compétences :
linux gets a slightly higher peak but has some horrible scalability problem after 1 thread per cpu. I fully expect someone in the audience to raise their hand and point out the kernel parameter I need to tweak to fix this.
et que le test n'est pas suffisamment « fair » pour établir une telle comparaison définitive entre OSes (différentes versions de mysqld), mais ce n'est pas son objet.
Bref, ce test a seulement pour vocation de vérifier que FreeBSD + ses patches se comporte suffisamment bien, et c'est d'ailleurs tout ce que conclus jeffr, loin des trolls évoqués dans ce journal :
At a minimum I hope this will end up showing we are performance competitive with Linux on moderately sized machines [...] I'm the first to admit it's been behind for some time.
.
Ce que l'on devrai conclure de ce benchmark, c'est que FreeBSD 7 supporte bien les montées en charge (au moins celle produite par MySQL), même lorsqu'on le compare a une excellente plateforme. Et c'est seulement ce que l'auteur cherchait à savoir.
on aurai put laisser ça au secteur privé (Emploies, argents toussa...)
Je ne comprend pas cette remarque au sujet de l'emploi : que ce soit Free et Orange qui fasse ça pour leur compte privé, ou Alcatel-Lucent pour le compte de la Mairie de Paris, il faudra dans les deux cas des admins, installateurs, etc. non ? Ou tu pense que Free/Orange ont besoin de plus d'employés qu'Alcatel pour faire la même chose ?
Comme quoi, on a tous du mal à lire correctement ;) :
La figure que tu cite est un modèle antérieur basé sur un à priori/présupposé, extrait d'un papier de Jimmy Yang et Feng-Bin Sun ; elle ne présente pas les résultats des recherches de Schroeder & al. :
« The common concern, that MTTFs do not capture infant mortality, has lead the International Disk drive Equipment and Materials Association (IDEMA) to propose a new standard for specifying disk drive reliability, based on the failure model depicted in Figure 2 [5,33]. ».
Ce qui leur permet de dire dans le résumé : « We also find evidence, based on records of disk replacements in the field, that failure rate is not constant with age, and that, rather than a significant infant mortality effect, we see a significant early onset of wear-out degradation. ».
Dans ce même sens, on trouve une (pré)étude intéressante menée par Mary Baker & al. en 2006 à l'Internet Archive, Disk Failure Investigations at the Internet Archive dans laquelle les auteurs indiquent : « Based on maintenance records, the Archive does not see systematic disk infant mortality. » (http://www.hpl.hp.com/personal/Mary_Baker/publications/wip.p(...) ).
J'aurais du faire état de l'avis divergent de Google sur ce point. Cette divergence m'a échappé parce que google en parle très incidemment, tandis que Schroeder & al. en font grand cas, au point de mettre en valeur leur trouvaille concernant la « mortalité infantile » dans leur introduction et leur conclusion. Ayant lu ce papier en second ... paf !
Cela dit, comme indiqué, Schroeder & al. parlent des pannes sur les disques en production (à vrai dire, c'est ce qui nous intéresse le plus), pas lors de l'installation ou la mise en place (le sens du mot failure diffère probablement de l'étude de Google) : « Any infant mortality failure caught in the manufacturing, system integration or installation testing are probably not recorded in production replacement logs. ». J'aurais donc du écrire : «La "mortalité infantile" [...] des disques en production n'est pas un phénomène significatif, selon Schroeder & al. ».
Exact, j'ai lu le papier de CMU en second et ne m'était pas aperçu sur le moment que les deux articles ont des conclusions opposées sur ce point. Peut-être que les méthodes d'approvisionnement (transporteurs, etc.) expliquent la différence entre les deux études sur ce point ?
Par ailleurs l'étude de la CMU considère un disque comme défectueux lorsqu'il est remplacé : on peut supposer qu'un disque pas encore en prod (qui montre ses faiblesses dès l'installation) ne rentre pas dans cette catégorie et n'est pas comptabilisé.
En fait l'article de google dit précisément l'inverse : les produits de certains constructeurs sont nettement moins fiables. L'étude porte sur des disques SATA et PATA, de divers constructeurs, utilisés chez google depuis 5 ans, sur un très grand nombre de disques. Il est donc improbable que ce soit seulement du à une mauvaise série.
Quand bien même les revendeurs de disques partageraient les mêmes usines, ils n'utilisent pas forcément les mêmes assemblages de composants, pas le même caisson (ce qui peut influer sur la température, les vibrations, etc.), pas forcément les mêmes marques de mémoire cache, de chipset PATA/SATA, ne paramètrent pas forcément le microcode de la même façon, n'ont pas forcément les mêmes tests de tests/validations avant mise sur le marché ... Et ils n'ont pas forcément le même réseau de transporteurs/logisticiens et n'emballent/empaquette pas forcément les disques de la même façon, ce qui semble influer sur la fiabilité selon ces deux sources : http://faq.storagereview.com/tiki-index.php?page=BrandMostRe(...) http://translate.google.com/translate?u=http%3A%2F%2Fpro.sun(...)
Un simple assembleur de la rue montgallet, pour peu qu'il ai des stats sur les retours depuis plusieurs années, pourrait aussi nous donner des indications valables. Si l'un d'entre vous a des entrées dans le milieu...
Sinon http://www.storagereview.com/ maintient un reliability survey dont on peut consulter les résultat (durée de vie telle qu'indiquée par les participants, constructeur par constructeur, modèle par modèle) lorsqu'on a participé (lorsqu'on indique l'état d'au moins un de ses disques). Je le consulte avant d'acheter mes disques (du coup, je n'achète pas les modèles dernier cris)...
[^] # Re: latex ?
Posté par herodiade . En réponse au journal réponses de bové à candidats.fr. Évalué à 6.
En l'occurrence, il ne dénonce pas les multinationale per se, mais leur action en rapport avec les brevets et DRM (lobbying de l'OEB et lors de la DAVDSI, déséquilibre lors de la protection contre les brevets, etc...).
Sincèrement, peut-tu soutenir que les particuliers, les assos et les PME ont eu autant de poids que les multinationales lors des décisions législatives en faveur des brevets et de la propriété intellectuelle (EUCD, DADVSI, ..) ?
[^] # Re: La réponse est dans le prix ...
Posté par herodiade . En réponse au journal Un point sur les FAI. Évalué à 5.
Abonné de Free en dégroupage total, j'ai été décablé deux fois par France Telecom (qui continue de gérer l'arrivée de la boucle locale : ils peuvent brancher/débrancher le brin de cable qui vous relie à votre FAI).
Dans ce genre de situation, la procédure est lourde : votre FAI doit faire trois demandes successives à France Telecom (et attendre à chaque fois leur réponse) avant d'avoir le droit de venir constater, accompagné d'un ingénieur FT, l'état du cablage en salle FT. Les frais d'intervention sont à charge du FAI plaignant si le cablage est correct, de FT s'il ne l'est pas.
Un amis qui travaille au support Free m'avait expliqué que dans la grande majorité des cas, les connexions dégroupées tombent magiquement en marche la veille de l'expertise... et c'est précisément ce qui m'est arrivé.
[^] # Re: =
Posté par herodiade . En réponse au journal J'aime, je n'aime pas : Fedora. Évalué à 4.
À ce sujet, je ne doute pas que Fedora ai des raisons valables, bien réfléchies et expliquées sans ambiguité (ps: si quelqu'un connait une URL décrivant la position de FC sur ce point ...), mais il ne faut jamais oublier que ces questions de logiciels libres implémentants des technologies brevetées sont toujours des compromis en eau trouble. Il y a mille nuances possibles, des évaluations des risques divergentes, ...
Bref, les pratiques et positions des distributions ne sont jamais tout noir ou tout blanc. Exemples :
- Fedora inclus, si je ne trompe, le support FAT32, les logiciels mono, OpenOffice.org (avec support .doc/.xls), Samba et d'autres, qui enfreignent très certainement les brevet de notre ennemi le plus acharné.
- Certains considèrent l'inclusion de firmwares binaires (dont les sources ne sont pas publiées) dans un header sous GPL inclus dans le noyau comme une entorse si grave à la GPL qu'il est exclus de redistribuer le noyau vanilla tel quel, d'autres considèrent que ce problème n'est pas prioritaire.
- Les contraintes légales sont différentes selon les pays où et d'où sont distribués les logiciels. Pour mémoire, c'est la raison pour laquelle OpenBSD, distribué depuis le Canada, a longtemps été le seul OS qui incluait des fonctions de cryptographie fortes interdites par la NSA à l'exportation depuis les USA. Les brevets logiciels ne sont pas (ou pas encore) valables en Europe. Je suis prêt à parier que la Chine impose d'autres contraintes spécifiques. Etc. Le fait de se conformer aux contraintes d'un pays plutôt qu'un autre est souvent déterminé par l'emplacement du siège social de l'éditeur plutôt que par des valeurs "universalistes".
- Debian inclus le support mp3. Pas faute d'une position ferme en faveur du libre, mais en raison d'interprétations ou de contraintes divergentes sur ces questions.
- ...
[^] # Re: =
Posté par herodiade . En réponse au journal J'aime, je n'aime pas : Fedora. Évalué à 2.
> FC : 1155
> FE : 2794
C'est pas mal, et je ne veut pas sous estimer le travail des devs de FC.
Je voulais juste expliquer une des raisons de ma déception, moi qui venait d'une distribution concurrente mais néanmoins amie.
Les paquets sources du seul dépôt "main" de la Debian stable (Sarge, qui date presque de deux ans) :
grep ^Package: /var/lib/apt/lists/ftp.crihan.fr_debian_dists_sarge_main_source_Sources | wc -l
8728
C'est plus que le double. De ce fait, on prends des vilaines habitudes d'utilisateur gâté ;)
# =
Posté par herodiade . En réponse au journal J'aime, je n'aime pas : Fedora. Évalué à 3.
- Je trouve yum insupportablement mou. C'est atroce. Apt est, comment dire, ... mieux !
- Peu de packages (la derniere fois que je l'ai testé, à l'époque de FC 4, et en comparaison avec Debian ou Ubuntu).
- Une certaine opacité (qui m'avaient semblé plus « corporate » que franchement communautaire) concernant certaines décisions, le rapport un peu compliqué à Red Hat (degré d'indépenance ? pas facile à déterminer, pour le newcomer que j'étais, et il me semble que c'était confus pour d'autres que moi) ou la documentation (en comparaison à Debian et OpenBSD, - et Ubuntu pour la doc/support communautaire). M'a semblé tout de même moins opaquo-corporate que Mandriva et SuSE, et puis ce n'est qu'une première impression.
- Plus bleeding edge que les autres (les mises a jours sont un peu dangereuses, pour un serveur - l'inverse de Debian sur ce point).
+ Plus bleeding edge que les autres, ce qui nous permet de faire notre devoir d'utilisateurs-citoyen et remonter les bugs au plus tot à l'upstream, pour les nouveaux softs ou technos. Très bien pour une utilisation desktop.
+ Sans doute la distro ayant le plus de contributions majeures upstream en particulier pour le kernel, gcc et la glibc. Les développeurs sont ultra compétents et semble vraiment coder, pour le bien de tous, et pas seulement écrire de nouveaux thèmes gnome et des wikis en python ...
+ Securité prise au serieux : -fstack-protector par defaut depuis un moment deja, SELinux, FORTIFY_SOURCE, ... (bien mieux que Debian et Ubuntu sur ces points : imaginez que etch va sortir et peut-être rester la Debian stable durant plusieurs années sans être compilée avec -fstack-protector ! )
Voila. Je l'ai abandonnée à cause de yum et parce que je ne comprenais pas bien qui décidait (entre RH et la communauté).
# Only two remote holes in the default install, in more than 10 years
Posté par herodiade . En réponse au journal Un exploit pour OpenBSD. Évalué à 10.
C'est fait : http://www.openbsd.org/ dit maintenant « Only two remote holes in the default install, in more than 10 years! ».
[^] # Re: Je ne comprend pas
Posté par herodiade . En réponse à la dépêche HP fait 25 millions de dollars avec Debian. Évalué à 2.
# Leur épargner le spam
Posté par herodiade . En réponse à la dépêche Aidez le projet nouveau en envoyant les dumps de votre carte nvidia. Évalué à 8.
Une remarque en passant : sur la page du projet (comme dans le topic du canal irc #nouveau), ils se sont donné la peine d'obscurcir l'adresse email : « Just email it to renouveau dumps <åt> gmail.com. ».
Si un modérateur passe par là, pourrait-il rectifier l'adresse email de la dépêche (si possible avant que ça n'atterrisse dans les caches de google & co.) ? merci.
[^] # Re: Un livre ca va ?
Posté par herodiade . En réponse au journal Programmation robuste. Évalué à 10.
[^] # Re: Et le reste?
Posté par herodiade . En réponse au journal Qui a écrit Linux 2.6.20 ?. Évalué à 2.
Et ça reste vrai pour la liste complète des 20 plus gros organismes contributeurs (pas seulement les 6, comme je croyais en lisant le journal) : les seules distributions listées sont Novel et Red Hat.
Je savait que les autres avaient très peu de kernel hackers, mais pas à ce point ...
[^] # Re: Et les autres ?
Posté par herodiade . En réponse au journal Beryl vs Compiz. Évalué à 3.
[^] # Re: Et les autres ?
Posté par herodiade . En réponse au journal Beryl vs Compiz. Évalué à 2.
# Et les autres ?
Posté par herodiade . En réponse au journal Beryl vs Compiz. Évalué à 3.
Qu'en est-il de Fedora ? S'ils choisissent aussi compiz, c'est tout tranché :
- tout les grands développeurs x11 /mesa/kernel (ceux de RH + SuSE, en gros) bosseront pour des distros avec compiz (déjà que beryl semble souffir séchement de l'absence de « pointures » à la Reveman ...)
- les utilisateurs de compiz seront largement plus nombreux (donc les tests, bugs reports etc. seront massivement faits sur compiz, lequel dispose d'un code qui est à la base plus propre)
- l'effet « communauté » d'utilisateurs dont bénéficie beryl pour être plus bleeding edge risque fort de se décaler vers compiz au fur et à mesure que les grosses distros « desktop » sortiront avec un « composing window manager » pré-intégré.
[^] # Re: Visiblement c'est plutot MSI
Posté par herodiade . En réponse à la dépêche Première carte mère équipée d'un BIOS libre. Évalué à 2.
Le support de linuxbios ne devrait pas conduire à privilégier MSI pa rapport à Tyan (encore une marque Taiwannaise, btw) : « Tyan offers LinuxBIOS on all their Opteron based products. ».
http://linuxbios.org/Products
http://linuxbios.org/index.php/Supported_Motherboards
http://www.linuxhardware.org/article.pl?sid=05/01/26/2240235(...)
[^] # Re: Et pour le lire ?
Posté par herodiade . En réponse au journal éloge au libre et au mouvement communautaire.. Évalué à 4.
mplayer -ao pcm:file="/tmp/tmp.wav" http://www.radiofrancepodcast.net/podcast/18957-25.02.2007-I(...)
oggenc /tmp/tmp.wav -a "Michel Serres" -G "Speech" -d "20070225" -N 1 -l "Le Sens de l'info" \
-t "Michel Serres sur France-Info (Le Sens de l'info, 25 février 2007)" \
-o ~/michel_serres_sur_france_info-le_sens_de_l_info_20070225.ogg
rm /tmp/tmp.wav
Et hop, le média est libéré (quant au contenu, on a encore du travail à faire auprès de radio-france ...).
# Et pour le lire ?
Posté par herodiade . En réponse au journal éloge au libre et au mouvement communautaire.. Évalué à 3.
Mais comment as-tu fait pour lire ce fichier ?
$mplayer -nocache pnm://son.radio-france.fr/chaines/itema/8957/8957_25022007_2007I8957S0056.rm
[...]
Connecting to server son.radio-france.fr[195.154.101.20]: 7070...
Cache size set to 0 KBytes
input_pnm: got message from server while reading stream:
You need to obtain a new player to play this clip. Please point your web browser to http://www.real.com and download the latest RealOne Player from RealNetworks. Once you have installed it you should try this clip again.
Pas mieux avec vlc.
La diffusion en directe sur radio-france est accessible en ogg et mp3, mais pour les archives, existe-t-il une alternative qui ne m'impose pas RealOne ?
[^] # Re: Visiblement c'est plutot MSI
Posté par herodiade . En réponse à la dépêche Première carte mère équipée d'un BIOS libre. Évalué à 4.
Mais ce sont des cartes mères pour serveurs (format SSI, double socket pour Opteron, etc). L'annonce pour la Gigabyte servait surtout à signaler au grand public qu'on pouvait enfin choisir des CM avec un bios libre pour son desktop (et pas qu'il s'agissait de la première CM avec un bios libre : il y en eu a d'autres avant, notammment dans l'embarqué).
Quelques trucs intéressants à noter sur ces deux CM pour serveur supportées par linuxbios :
* La K9SD Master-S2R (MS-9185) intègre un BMC (http://en.wikipedia.org/wiki/Baseboard_management_controller ) avec sa propre interface réseau. C'est surement là que le linuxbios montre toute sa pertinence. J'ai l'impression que la K9D dispose d'une fonctionalité similaire (je ne comprend pas le chinois, mais les sépcifications parlent de "1 個 RJ45 接頭 for KVM" en plus des cartes réseau normales).
* L'EEPROM de cette CM est plutôt gros : 8 Mo. Est-ce un pré-requis pour supporter linuxbios et ses fonctionalités les wizzbang ?
* Dans les deux cas, le code a été écris par MSI eux-même (et ça, c'est le pied ;)
* Petit bémol, le chipset ethernet gigabit utilisé (au moins sur la K9SD) est un Broadcom (à tout les coups un tg3, qui n'est pas spécialement LL-friendly : specs sous NDA, firmware pas très libre, ...).
* Pour la K9SD, il est dit « The code was contributed by bxshi of MSI, based on code for the NVIDIA MCP55 by Yinghai Lu of AMD. ». Ce qui est épatant dans cette affaire, c'est que le travail d'un ingénieur d'AMD sur le chipset d'un concurent (NVIDIA est concurent d'AMD depuis leur fusion avec ATI non ?) permet le support de plusieurs CM. Jolie collaboration.
* Theo de Raadt disait que les fabriquants de matériel info Taiwanais étaient désormais les plus coopératifs avec le LL, et de loin (penser à Ralink ou Realtek), là où les constructeurs américains s'emmurent dans une culture du secret et sont paralysées par l'angoisse des problèmes juridique. Les constructeurs de CM Taiwanais (MSI et Gigabyte) semblent lui donner raison. Achetons Taiwanais ! ;)
* Les deux CM intègrent un chipset graphique pour lequel on a un driver libre, le Radeon 7000 (mais pas très performant je crois).
[^] # Re: Mauvaises conclusions
Posté par herodiade . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 10.
Je crois d'aileurs que le post suivant dans son blog confirme mon interprétation anti-trollistique (http://jeffr-tech.livejournal.com/ ) :
Ce que je résumerai par : « soyons constructifs ».
# ... et ça marche !
Posté par herodiade . En réponse à la dépêche Dell Idea Storm : Linux pré-installé ?. Évalué à 3.
http://www.dell.com/content/topics/global.aspx/ideastorm/ide(...)
[^] # Re: Support
Posté par herodiade . En réponse au journal Que faire sans OpenSSH ?. Évalué à 2.
Ce qui fait que Theo de Raadt était désolé, lorsque les finances du projet OpenBSD/OpenSSH étaient dans le rouge, qu'aucune de ces charmantes entreprises n'ai jamais fait le moindre geste de soutient (les dons viennent toujours de particuliers, de fondations comme la moz' fund' et de GoDaddy, mais pas des distros commerciales ni de Sun & co.). http://kerneltrap.org/comment/reply/6550
# Mauvaises conclusions
Posté par herodiade . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 10.
N'oubliez pas que ce test est mené par un développeur noyau de FreeBSD pour qui le plus important est de valider la pertinence de ses patches/améliorations : à mon avis, il exécute aussi ce test sur Linux pour donner une référence. Après tout, c'est logique : Linux est connu pour être la plateforme dont mysql tire le meilleur profit : si on se comporte aussi bien que lui, c'est qu'on est au point. L'auteur a conscience que l'optim de Linux n'est pas son domaine de compétences : et que le test n'est pas suffisamment « fair » pour établir une telle comparaison définitive entre OSes (différentes versions de mysqld), mais ce n'est pas son objet.
Bref, ce test a seulement pour vocation de vérifier que FreeBSD + ses patches se comporte suffisamment bien, et c'est d'ailleurs tout ce que conclus jeffr, loin des trolls évoqués dans ce journal : .
Ce que l'on devrai conclure de ce benchmark, c'est que FreeBSD 7 supporte bien les montées en charge (au moins celle produite par MySQL), même lorsqu'on le compare a une excellente plateforme. Et c'est seulement ce que l'auteur cherchait à savoir.
[^] # Re: Quelques restrictions
Posté par herodiade . En réponse au journal [HS] Paris nous offre le Wi-Fi en toute illégalité.. Évalué à 6.
Je ne comprend pas cette remarque au sujet de l'emploi : que ce soit Free et Orange qui fasse ça pour leur compte privé, ou Alcatel-Lucent pour le compte de la Mairie de Paris, il faudra dans les deux cas des admins, installateurs, etc. non ? Ou tu pense que Free/Orange ont besoin de plus d'employés qu'Alcatel pour faire la même chose ?
[^] # Re: Mortalité infantile
Posté par herodiade . En réponse à la dépêche Deux analyses précieuses sur la fiabilité et la longévité des disques durs. Évalué à 2.
La figure que tu cite est un modèle antérieur basé sur un à priori/présupposé, extrait d'un papier de Jimmy Yang et Feng-Bin Sun ; elle ne présente pas les résultats des recherches de Schroeder & al. :
« The common concern, that MTTFs do not capture infant mortality, has lead the International Disk drive Equipment and Materials Association (IDEMA) to propose a new standard for specifying disk drive reliability, based on the failure model depicted in Figure 2 [5,33]. ».
Les graphes présentant les résultats de Schroeder & al. sur ce point sont plutôt ceux-ci : http://www.usenix.org/events/fast07/tech/schroeder/schroeder(...)
Ce qui leur permet de dire dans le résumé : « We also find evidence, based on records of disk replacements in the field, that failure rate is not constant with age, and that, rather than a significant infant mortality effect, we see a significant early onset of wear-out degradation. ».
Dans ce même sens, on trouve une (pré)étude intéressante menée par Mary Baker & al. en 2006 à l'Internet Archive, Disk Failure Investigations at the Internet Archive dans laquelle les auteurs indiquent : « Based on maintenance records, the Archive does not see systematic disk infant mortality. » (http://www.hpl.hp.com/personal/Mary_Baker/publications/wip.p(...) ).
J'aurais du faire état de l'avis divergent de Google sur ce point. Cette divergence m'a échappé parce que google en parle très incidemment, tandis que Schroeder & al. en font grand cas, au point de mettre en valeur leur trouvaille concernant la « mortalité infantile » dans leur introduction et leur conclusion. Ayant lu ce papier en second ... paf !
Cela dit, comme indiqué, Schroeder & al. parlent des pannes sur les disques en production (à vrai dire, c'est ce qui nous intéresse le plus), pas lors de l'installation ou la mise en place (le sens du mot failure diffère probablement de l'étude de Google) : « Any infant mortality failure caught in the manufacturing, system integration or installation testing are probably not recorded in production replacement logs. ». J'aurais donc du écrire : «La "mortalité infantile" [...] des disques en production n'est pas un phénomène significatif, selon Schroeder & al. ».
Voilou.
[^] # Re: Mortalité infantile
Posté par herodiade . En réponse à la dépêche Deux analyses précieuses sur la fiabilité et la longévité des disques durs. Évalué à 2.
Par ailleurs l'étude de la CMU considère un disque comme défectueux lorsqu'il est remplacé : on peut supposer qu'un disque pas encore en prod (qui montre ses faiblesses dès l'installation) ne rentre pas dans cette catégorie et n'est pas comptabilisé.
[^] # Re: A propos des marques
Posté par herodiade . En réponse à la dépêche Deux analyses précieuses sur la fiabilité et la longévité des disques durs. Évalué à 5.
Quand bien même les revendeurs de disques partageraient les mêmes usines, ils n'utilisent pas forcément les mêmes assemblages de composants, pas le même caisson (ce qui peut influer sur la température, les vibrations, etc.), pas forcément les mêmes marques de mémoire cache, de chipset PATA/SATA, ne paramètrent pas forcément le microcode de la même façon, n'ont pas forcément les mêmes tests de tests/validations avant mise sur le marché ... Et ils n'ont pas forcément le même réseau de transporteurs/logisticiens et n'emballent/empaquette pas forcément les disques de la même façon, ce qui semble influer sur la fiabilité selon ces deux sources :
http://faq.storagereview.com/tiki-index.php?page=BrandMostRe(...)
http://translate.google.com/translate?u=http%3A%2F%2Fpro.sun(...)
Un simple assembleur de la rue montgallet, pour peu qu'il ai des stats sur les retours depuis plusieurs années, pourrait aussi nous donner des indications valables. Si l'un d'entre vous a des entrées dans le milieu...
Sinon http://www.storagereview.com/ maintient un reliability survey dont on peut consulter les résultat (durée de vie telle qu'indiquée par les participants, constructeur par constructeur, modèle par modèle) lorsqu'on a participé (lorsqu'on indique l'état d'au moins un de ses disques). Je le consulte avant d'acheter mes disques (du coup, je n'achète pas les modèles dernier cris)...