> Oui mais là il n'est pas question du noyau mais de iptables et busybox non ?
iptables et busybox sont aussi sous GPLv2 (même pas « v2 et suivantes »). Pour busybox, d'ailleurs, c'est le résultat d'un gros combat entre les développeurs actuels, et Bruce Perens ressurgit de nulle part qui voulait soudainement imposer un passage très « politique » en v3.
De plus, l'autre remarque tient toujours (la FAQ indique que la version de la GPL n'aurait rien changé à la question).
Enfin, je doute que free ai eu besoin de faire des modifications sur ces deux produits, et encore plus qu'ils aient besoin de tenir de telles modifications, s'il y en a, secrètes (alors que pour le noyau, il y a surement des modules proprio pour les chipsets Broadcom et le modem, fournis sans sources ou sous NDA par les constructeurs).
Au passage, ne serait-il pas plus efficace d'attaquer directement Broadcom, Atheros & co., qui - c'est un comble - arrivent à vendre leur came sur de gros marchés linux comme les freebox, livebox et 9box (sans parler des serveurs IBM et leurs sal**peries de tg3, du Asus EEEpc, ...) en se contentant de fournir d'abominables modules propriétaires ? (ou ils ne touchent pas d'EXPORT_SYMBOL_GPL ?). Enfin, peut-être qu'un tel procès incitera Free à remonter de telles exigences à ses fournisseurs de chipsets...
> Donc tu installes une Fedora ou une RHEL (ou CentOS, etc), et voilà.
Heu, ça dépend de quoi on parle.
S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
Si on parle d'environnement serveur, où la sécurité est plus critique, c'est différent. Mis à part les serveurs d'infrastructure (mail, dns), je n'ai jamais administré des serveurs qui fassent tourner exclusivement des logiciels fournis par ma distribution. Sur mes serveurs web par exemple : certes j'utilise les apaches qu'on m'a fournis, et leurs modules. Mais il font tourner une foultitude d'application php, python, perl (cgis, applications métiers, devs maison, ...), des bloatwares en java, ... qui sont les "vrais" fonctionnalités offertes par le serveur. Vos sites web et vos applis j2ee sont fournis par Red Hat ?
Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux. Et là, la complexité est un handicap (pour revenir sur le troll de l'autre journal).
> Chroot renforcé car trop permissif par defaut (en gros qui laisse s'échapper les occupants)
Vraisemblablement pour ne pas casser le comportement standard de chroot(2), lequel est défini précisément par POSIX.1-2001.
En l'occurrence, les "problèmes" de chroot visés par grsecurity, ce n'est pas qu'il "laisse s'échapper les occupants", mais qu'il n'isole un processus du reste qu'au niveau du système de fichier, et c'est tout (les IPC fonctionnement normalement, les fd hérités restent ouverts, ...). Mais c'est ce pour quoi il a été conçu, on n'a pas menti sur la marchandise.
Chroot n'était pas prévu pour être utilisé comme un mécanisme de sécurité (cf. [http://lwn.net/Articles/252794/]), encore moins comme mécanisme d'isolation totale (à part pour le système de fichier). Des solutions parallèles sont cependant en cours de développement et intégration dans Linux (autour de la virtualisation et des espaces de nommages multiples et séparés pour les processus, par ex.) ; elles ont le mérite de présenter une architecture d'ensemble et cohérente, et de ne pas casser un appel système standard, existant et déjà largement utilisé par des milliers de logiciels.
> Cacher les process du noyau
C'est plutôt "cacher certains processus à d'autres processus". Tel que proposé par grsecurity, ce n'est pas une chose très simple (ou très saine) à intégrer dans le desktop de monsieur tout le monde. Là encore, il faut veiller à ne pas casser les standards ou l'existant. Et là encore, la virtualisation et la ségrégation de plusieurs espaces de nommages pour les processus (enfin pour le moment, seulement les pids) est une solution plus générale et en cours d'adoption.
> Logs beaucoup plus 'verbose' sur les actions des users
Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
> Protection de la pile
Si mes souvenirs sont bons, le patchset grsecurity+pax s'était vu rejeté, lorsqu'ils ont demandé l'intégration dans le noyau, notamment parce que les mécanismes de protection de pax divisaient par deux l'espace mémoire adressable par un processus donné, merci la belle régression (je dit ça de mémoire hein, c'est peut être "divisaient en quatre" ou quelque chose similaire, mais c'était bien un problème de ce type). Ce qui casse le fonctionnement d'un paquet d'applis en situation "enterprise", notamment celles qui font vendre du redhat/oracle.
Ce n'est pas la seule raison du refus, je me souvient que d'autres problèmes sans rapport direct avec la protection de la pile ont été soulevés sur lkml à l'époque (non utilisation de LSM, développeur principal qui refuse l'intégration d'une partie de son patchset parce que "la sécu c'est tout ou rien", et qui se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).
Un exemple : par rapport à Windows, dans le monde des unix libres, on place souvent les slashs dans l'autre sens (pas uniquement pour les paths ;)
Sinon, plaisanterie à part, je ne connais pas les formations existantes, mais je suis certain qu'avoir un bon bouquin sous le coude quelques semaines avant ta formation permettra de tirer le meilleur profit de celle-ci. Christophe Blaess, Programmation système en C sous Linux, ed. Eyrolles, 2005 est un très bon livre (par exemple).
Permet moi de contester ton prémisse, ou ton à priori, celui de penser que qu'ici « amateur » signifierai « celui qui n'y connaît rien » vs. l'« expert », « celui qui connaît son sujet ».
Or si l'on parle de Wikipédia ou de logiciel libre, la distinction amateur/expert ne se fait pas sur cette frontière. Dans notre cas, l'amateur est celui qui aime (étymologie du mot amateur), ou plus précisément, qui produit au nom de son amour pour le sujet (d'où l'expression « amateur éclairé »), tandis que l'expert est la voix d'autorité (celui qui est qualifié pour parler) : le professionnel, ou la personne fortement diplômée.
Aussi pourra-t-on dire que le noyau linux (comme une majorité de logiciels libres) fut initié de façon amateur (pour le simple plaisir). De même, il n'est pas rare que nous initions, dans le logiciel libre, des développements sur des sujets que nous voulons approfondir plutôt que sur ce que nous connaissons déjà (ex. un admin qui fait du dev, un dev j2ee professionnel qui pendant ses loisirs travaillent sur une application C/GTK, ...). Et puis, combien d'entre nous sommes « experts » de l'informatique, au sens de « doté d'un doctorat ou d'une voix d'autorité (prof de fac, etc.) » ?
De même, parmi les contributeurs de Wikipédia, on trouve énormément de personnes bien diplômées, mais qui ne travaillent pas au nom de leur expertise (et en fait, pas toujours dans leur champs d'expertise précis). Parmi les bloggeurs, des personnes compétentes (ou pas), qui travaillent par passion et avec honnêteté. On contribue « pour l'amour de l'art ». Et à l'inverse des experts qui travaillent comme des porcs (spam, travail bâclé, pas de sources, pov-pushing, ...).
Ce que nous reprochons aux journalistes, c'est de ne pas aimer suffisamment leur sujet pour faire leur homework. Où, comme ont dit ici aux amateurs que nous sommes, de RTFM'er.
Ce qui fait la différence de qualité, pour nous, amateurs de logiciels libres, c'est plutôt l'honnêteté avec laquelle est fait le travail (cette honnêteté fait faire de bons logiciels libres par de jeunes étudiants, de bons articles par des wikipédiens sans diplômes ou par des journalistes hors de leur champ) que le diplôme des acteurs.
> Si une autre techno entrait en mainline qui soit plus simple que SeLinux on pourrait très bien assister a un ralliement de plusieurs distros.
De fait les principales distributions ont déjà choisi :
1- Les dernières versions de Mandriva, SuSE et Ubuntu intègrent AppArmor
2- Red Hat utilise SELinux
Le 1 permet de comprendre le fait qu'a cette occasion SuSE ai licencié une partie de ses développeurs AppArmor (à mon avis un appel du pieds aux autres distribution, à la « à votre tour aussi, de participer au financement du bidule, maintenant que vous êtes dépendants »).
Le 2 permet de relativiser les prises de positions bruyantes d'Alan Cox (et de IsNotGood)...
L'intégration d'AppArmor semble imminente à présent (probablement pour le 2.6.25), je suppose que c'est pour ça que les FUDistes se réveillent... Aussi : patrick_g a totalement raison de soupçonner les devs SELinux de vouloir enlever LSM pour virer la concurrence, c'est du moins pour ça que Linus les a rappelé à l'ordre (et puis, rappelons-nous leur réaction aux besoins derrière AppArmor : « ah, mais la simplicité à la AA, il suffit de l'implémenter au-dessus de SELinux » (ce qu'ils n'ont pas fait) et à Smack (« ah, mais il n'ont qu'à réimplémenter un smack au-dessus de SELinux » (ce qui ne sera pas fait)).
Concernant les modèles de sécurité : certains spécialistes (pas moi, mais par exemple chez OpenBSD) considèrent qu'un modèle valable doit être simple, clair et auditable. Iznogood, as-tu audité les modèles de sécurité en oeuvre sur ton poste pour savoir précisément de quoi ils te protègent, et de quelle façon (par ex. s'il n'y a pas, dans une police, une bourde qui laisse une énorme brèche ouverte dans la cathédrale ? ce genres de bourdes sont courantes sur les systèmes complexes). Combien de personnes ont audité ce jeu de règles ? Les contraintes sécurité de la NSA sont autant d'ordre bureaucratiques que techniques (d'où une forme assez byzantine du machin). Pour le commun des mortels, le fait qu'un modèle et des polices de sécurité soient intégralement lisibles auditable par beaucoup de monde (et auditable plus efficacement par les spécialistes) est bénéfique à la sécurité.
Cela étant posé, on sait qu'il faut être attentifs à certaines choses en déployant du AppArmor (ne pas autoriser les processus confinés à monter des périphériques ou faire des hardlinks, faire attention aux rennomages, confiner tout les autres processus susceptibles d'échanger des file descriptors avec celui qui nous intéresse, ...). N'empêche. Sans jeter l'opprobre sur SELinux, ça laisse la place pour d'autres modèles (Tomoyo, Smack, AppArmor, ...).
Oui, et d'autre part AMD/ATI n'a libéré (sans NDA, c'est bien) qu'une toute petite partie des specs, concernant essentiellement l'initialisation du chipset et des sorties.
Si mes souvenirs sont bons, ils annonçaient « réfléchir à » (ou « travailler sur ») la façon de libérer le reste. En attendant, corrigez-moi si je me trompe, seule une infime partie de la doc a été libérée. Quand viendra le reste ? Se reposent-ils sur le succès de leur effet d'annonce ? L'ouverture des specs aurait-il pu être un pur plan marketing ? Ou est-ce que le reste des specs est déjà disponible mais de façon plus restreinte (par ex. sous NDA) ?
Pour les avantages de la BSD, je formulerai différemment :
- permet de le réutiliser partout (c'est bien pour les normes et la concurrence proprio/libre)
plutôt, pour bien montrer les priorités :
- permet de le réutiliser partout (est compatible avec les softs sous GPL, LGPL, CDDL, MPL, ... et accessoirement avec le proprio (ce qui peut être bien pour les normes))
Parce que les développeurs de logiciels sous licence MIT ou BSD, je crois qu'ils sont généralement beaucoup plus intéressés par la réutilisation de leur code sans restriction par d'autres logiciels libres, que par le proprio (qui est plutôt un « side effect » qu'on juge négligeable). La compatibilité a toujours été importante en informatique, surtout la compatibilité entre « frères du libre ». Exemple : xorg et sa licence.
Ou pour le dire autrement : en choisissant la BSD, on se prive de pouvoir punir le proprio, généralement parce qu'on juge plus important de ne pas priver nos cousins du libre, sans discrimination, que de se laisser dicter une conduire par le proprio (dont on se fiche éperdument).
À part ça, je ne remercie pas Pierre Jarillon d'avoir pourri la dépêche en lançant ce troll (dans lequel je viens de marcher, imbécile de moi).
Juste une note, pour lever le cocasse de la situation :
Robert Solé écrit, dans son article : « Wiki est un mot haïtien qui signifie "vite". ».
S'il avait lu Wikipédia, il aurait peut-être plutôt écrit : « Le mot "wiki" vient du redoublement hawaiien wiki wiki, qui signifie "rapide" ». Heureusement qu'il ne lit pas ce média si peu fiable, et qu'en journaliste à l'éthique incontestable, il vérifie ses informations et ne s'exprime que sur ce qu'il connait bien (mais où est le bouton « [Modifier] » ?).
Citation choisie :
« Cela ressemble plutôt à un journaliste qui avait une idée dans la tête, et qui a sauté sur l'opportunité de la décision de justice pour faire son papier sur le sujet. Car la thèse qu'il soutient est exactement à l'opposé de ce qui vient précisément de ce passer. ».
Oui Assouline, blogueur du Monde mais pas seulement, est une plaie : non parce qu'il critique Wikipédia (après tout, de bonnes critiques ne peuvent que faire avancer le schmilblick), mais parce qu'il est *la* voix critique (il a un bon carnet d'adresse dans la presse), complètement incompétent (pour parler des questions liées à internet/au numérique, parce que, aussi, il ne renseigne pas du tout sur le fonctionnement de wikipédia, etc.), de mauvaise fois, ... C'est malheureusement lui qu'on invite toujours pour faire « contrepoids » (selon le principe à la mode des émissions actuelles, il faut inviter un « pour » et un « contre ») à la TV, à la radio, ... quand on parle de Wikipédia.
Oui à la critique, mais donnez nous des ennemis de qualité par pitié !
> Le gros problème avec ce genre de "deamon son", c'est qu'il y'a toujours une latence plus ou moins importante.
Pour compléter la remarque de patrick_g, et comme je l'ai indiqué plus haut, les parties critiques (en termes de latence) de pulse audio tournent avec une priorité RT (temps réel)... exactement comme jackd ;) (jackd est bien la preuve qu'un daemon n'ajoute pas forcément de la latence !).
Mais à la différence de jackd, la latence n'est pas la priorité absolue de PA, il propose donc certaines facilités qui rendent son utilisation plus simple pour les applications qui veulent seulement jouer des sons (comme le support, et la conversion à la volée de diverses fréquence d'échantillonnage envoyées par les applications : ce qui peut rajouter un tout petit poil de latence, mais est tellement pratique...). Bref, PA fait un petit compromis sur la latence (mais rien à voir avec l'énorme latence de dmix, ou pire, l'intolérable décalage d'esd) pour être plus pratique à utiliser.
> Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées [...] régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, [...]
Toute ressemblance avec un personnage existant dans le coin serait le fruit du hasard :P
Il y a quelques fonctionnalités intéressantes (présentées par d'autres ici), de mémoire:
- Pouvoir enfin exploiter le surround, et les divers systèmes audio multicanaux (5.1, 7.1 etc.) correctement (éventuellement en multiplexant plusieurs cartes son)
- Hotplug de cartes audio (penser aux "skype phones usb" par ex, ou aux oreillettes bluetooth).
- Possibilité d'intervenir sur les divers flux envoyés au daemon (pour régler les volumes différemment selon l'appli source, migrer un flux sur un autre périphérique, etc.)
- La portabilité (support natif de Windows, *BSD, Linux, Solaris) (nb: sachez bien que Alsa ne supporte que Linux : même pas les BSDs, ce qui explique que les développeurs d'applis ont dans l'ensemble conservé la compat OSS sur le long terme).
- Projet de gérer le son différemment selon les "états graphiques" (?), par ex. augmenter le volume de l'appli en avant plan, et baisser le volume de l'appli dans la barre des taches (pratique, lorsqu'on switche souvent entre firefox+vidéos flash, un lecteur de musique, un client irc qui blingue, etc.)
- Le point le plus important pour moi : la possibilité d'avoir une *très faible* latence sans jitters. En effet PA tourne avec une priorité Real Time (possible parce que c'est un daemon: on ne peut pas donner une telle priorité à tout les logiciels susceptibles d'envoyer directement du son à alsa).
Ce qui, en revanche, me semble très dommageable pour la réussite de ce remarquable projet, c'est l'attitude, le style, de son leader, Lennart Poettering. Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées (« stubborn », disait un gnomiste). Il est régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, insultant à l'égard des contributeurs potentiels peu dégourdis, des décisions à la « je force rigidement et artificiellement un choix en vérouillant le périphérique », mépris total des outils aimés par les utilisateurs (« amarock -- or whatever that awful media player everyone but me loves so much is called »), etc... Bref, c'est une grande gueule aux opinions très tranchées, et pas très intéressés par la collaboration avec les outils et technos non-gnome.
C'est dommageable, parce qu'on attends vraiment d'un projet comme PA qu'il fédère, enfin, les divers projets libres autour d'une très bonne API son, à la façon d'un projet freedesktop ; qu'on se défasse enfin de la concurrence entre tout ces vieux logiciels presque non maintenus (esd, arts, lecteurs audios divers, ...) qui cherchent chacun à vérouiller la carte son en entrée, et même parfois en sortie (souvent en schuintant dmix au vol). Or s'il s'alienne déjà l'ensemble de l'environnement KDE (« I don't care about KDE »), l'objectif est déjà loupé ; nous garderons nos petits problèmes de conflits d'accès concurrent pour un bon moment encore ... :(
Bon, mais rappelons-le, l'outil est excellent (et les projets de développements annoncés sont alléchants).
Par rapport à la dépêche, il faut quand même rappeler que les têtes font un cycle load/unload si vous passez de l'activité disque à l'inactivité, puis à nouveau à l'activité, etc... en permanence. Si vous restez en activité continue, les têtes ne sont pas parquées, et si l'activité disque est bien réduite, les têtes restent parquées : dans les deux cas, le nombre de load/unload n'augmente pas.
Si les accès disques ont seulement lieu lorsque vous travaillez réellement dessus (ie. lecture d'une vidéo stockée sur le disque), et s'ils sont au repos lorsque vous ne faite quasiment rien d'autre (lire une page web, etc.), alors les têtes resteront parquées plus longtemps avec un x ("hdparm -B x") faible.
Or précisément, le laptop_mode (le mode dont on parle, qui exécute le "hdparm -B 1") vise à réduire le plus possible les activités disques non d'arrière-plan (et à regrouper les autres, etc.). Bref, le laptop_mode permet effectivement de ne pas augmenter le cycle load/unload, en restant plus longtemps avec les têtes parquées.
Précisons aussi que sous Ubuntu, le kernel est patché pour que les partitions soient montées en noatime par défaut (ce qui réduit là encore considérablement les accès hors du cache). Si vous utilisez une autre distro sur un laptop, faites un "mount -o remount,noatime /" (ou mieux, ajustes votre fstab). Aussi, le fichier de configuration /etc/laptop-mode/laptop-mode.conf (si le paquet laptop-mode est installé) permet de passer une configuration alternative à syslogd lorsqu'on est sur batterie (ie. n'écrire sur le disque que les messages critiques ou emergency, et ne flusher que rarement).
Une configuration correcte et propre, par une distribution Linux responsable, des ordinateurs portables lorsqu'ils sont sur batterie ne consiste pas à coller un hdparm conservatif (style -B 255) « et basta, on se mouille pas les mains et osef de la consommation », mais bel et bien à réduire le plus possible les accès disques inutiles (réduire le nombre de cycles load/unload en privilégiant la stagnation dans l'état "têtes parquées" et pas en privilégiant l'état "têtes actives") : c'est ça, la solution propre, à viser.
Donc oui, Matthieu Garett à raison de préciser que cette valeur d'hdparm est activée par Ubuntu seulement lorsque le laptop_mode est activé : car dans ce cas, le risque d'impact sur la durée de vie est minimisé. Et il a aussi raison de pester contre les fabriquant de disque qui mettent des valeurs très courtes par défaut : car elle seront actives telles quelles, même lorsque vous n'êtes pas en mode laptop.
nb: par contre il y a un bug d'Ubuntu qui fait que on_ac_power(1) retourne parfois 0 même sur des desktop branchés sur le secteur, et ça c'est plus embêtant.
> Ou sont passés les 2 millions d'utilisateurs d'Ubuntu ?
> Ont-ils abandonné le libre et retourné chez M$ ?
> Ont-ils changé de distribution ?
En fait - et il aurait fallu le souligner dès le départ - Mark Shuttleworth dit dans un premier temps « Il y a probablement au moins 8M utilisateurs », et dans un second temps « Il y a plus de 6M utilisateurs ». Donc, et si on prends ses propos au sérieux (manifestement, il laisse des indices pour qu'on ne le prenne pas au sérieux), on ne peut pas affirmer qu'ils ont perdu 2M utilisateurs (« plus de 6M », ça peut être 7, 8, 9 ou 10M).
Si je fait ce rappel, ce n'est pas pour chippoter sur les mots, mais ...
> La vraie réflexion serait plutôt :
... pour ramener à la vrai réflexion (selon moi) :
Pourquoi Shuttleworth reste-t-il aussi évasif sur le sujet (« plus de », « probablement », ...) ?
Pourquoi donne-t-il des chiffres si ostensiblement imprécis et inutiles, alors qu'il a sous la main des données plus fiables ?
Pourquoi affirme-t-il qu'il n'a pas de moyens de mesurer (c'est du pipeau, il en a, et le cas échéant il ne pourrait même pas donner de telles approximations) ?
Pourquoi n'encouragent-ils pas plus activement l'utilisation de popcon (ou smolt, ou autre) à l'installation et à l'upgrade ?
Si son problème est de vouloir masquer une fuite des utilisateurs, dans ce cas pourquoi aurait-il dit « plus de 6M » la seconde fois (au point ou nous en sommes, il pouvait dire : « plus de 10M » et hop) ?
Les 8M qui deviennent « plus de 6M », à mon sens, c'est plus surement un signe d'un problème avec la divulgation des chiffres que le signe clair d'un problème de fuite des utilisateurs.
C'est la question la plus importante. Si l'objectif n'est pas le Ubuntu-bashing, mais, comme l'indique GeneralZod, « d'encourager Ubuntu à rejoindre l'initiative Smolt et/ou publier des statistiques digne de confiance », il faudrait savoir pourquoi, pour commencer, MS est réticent sur ce point (perso, je n'en n'ai aucune idée, les raisons peuvent être multiples). Si on ne sait pas quel est son problème avec ces chiffres, on ne saura pas comment le faire changer d'avis, non ?
Oui ceux-là ne sont pas comptés (enfin, une seule fois pour tout les postes), mais nous ne sommes plus à l'époque du 56k, à mon avis les utilisateurs d'apt-proxy sont rares en proportion.
Idem pour ceux qui ne font pas les mises à jour (ou n'ont pas internet) : ils ne sont pas comptés. Mais il me semble que Smolt à le même problème (il faut que l'utilisateur accepte de transmettre les statistiques, et dispose d'internet), voir pire (un utilisateur à intérêt à faire les màj sécu, alors qu'envoyer des stats...).
Bref ça permet de faire une évaluation *conservative* du nombre d'utilisateurs : certains ne seront pas comptés. Mais, à mon avis, une évaluation assez proche de la réalité.
> les gens qui mettent à jour leur distro, et qui du coup sont comptés comme user de la version X et X+1
Non. Ce qu'on compte c'est « combien de personnes ont téléchargé le paquet toto_42-ubuntu2_i386.deb - récemment mis à jour pour raison de sécurité - dans le dépôt feisty-security, et dans le dépôt gutsy-security, etc. ».
Bref, on re-fait les comptes à partir de 0 pour chaque paquet proposé à la mise à jour, on n'additionne évidement pas les calculs successifs. Ainsi, celui qui upgrade est compté comme « utilisateur de feisty » lors d'une première mise à jour, et s'il upgrade, comme « utilisateur de gutsy » (mais plus utilisateur de feisty) aux màj suivantes. Et on peut ainsi, au passage, suivre l'évolution des utilisateurs des diverses versions.
> les gens qui ont un proxy chez leur fai
Un proxy configuré pour cacher des objets aussi gros qu'une mise à jour d'OOo ? tu veut dire qu'il y a des fai qui cherchent à mirrorer l'internet complet ? ou tu es de mauvaise foi ?
> les gens qui doivent utiliser un miroir.
Pour les mises à jour sécurité, par défaut, ubuntu ne place pas de mirroir dans le sources.list. C'est suffisant (en fait je ne crois pas qu'il y ai des mirroirs officiels du dépôt des mises à jours sécu).
> tu comptes quoi ? Les ips différentes (et le nat, et les ips dynamiques ) ?
Non, tu compte le nombre de téléchargements d'un paquet donné (peut importe les IP, uniques ou pas). Les outils apt ne re-téléchargent pas un paquet qu'ils ont déjà récupéré (sauf rare exception, si vous voulez chipoter). Si tu a trois postes sous Ubuntu à la maison (derrière du NAT ou pas), et que tu les maintient à jours, ils téléchargeront vraisemblablement tout les trois la dernière maj sécurité du noyau, une fois chacun.
> Le nombre de gens qui téléchargent les indexes
Non ça n'a pas d'intérêt de mesurer les téléchargements d'indexes, puisque, très souvent, on télécharge plusieurs fois le même indexe sur un même poste.
Canonical dispose déjà d'un moyen assez efficace de compter le nombre d'installations (cf. mon post plus haut : ils administrent le serveur security.ubuntu.com, ou se trouvent les mises à jours de sécurité, proposées par défaut aux utilisateurs).
Le fait est qu'ils ne les publient pas (pour une raison qui m'échappe) : c'est un choix, et je vois mal en quoi smolt aiderai à changer ce choix. Ou, et c'est où je veut en venir, ils peuvent publier des statistiques bidons : ils le font (peut-être) déjà alors qu'ils ont les informations retournées de http://security.ubuntu.com (les 8 M users puis « plus de 6 M users »). Mais s'ils administrent le serveur de stats utilisé par le smolt sous Ubuntu, qu'est-ce qui les empêche de faire de même ? Mais au fait, qu'est-ce qui empêche Red Hat / Fedora d'arranger leurs stats smolt ?
Sinon à titre d'évaluation personnelle, si Fedora dispose d'une base de 1.7 million d'utilisateurs, je m'attends à ce qu'Ubuntu ai une base d'utilisateurs 3 à 5 fois plus grande (donc bien dans les 6 à 8 millions d'utilisateurs), minimum.
Une méthode très simple, pour Canonical, pour compter le nombre d'installations actives de chaque version d'Ubuntu : compter le nombre de téléchargement de chaque mise à jour.
Les propositions de mises à jour sont activées par défaut (et probablement appliquées par la plupart des utilisateurs), et leur dépôt est placé sur le même (cluster de) serveur(s) central géré par Canonical, http://security.ubuntu.com/ubuntu . Évidement ça ne compte pas ceux qui n'appliquent pas les mises à jour (ou qui n'ont pas internet), mais j'estime ça à une proportion négligeable.
Je doute fort qu'ils (Canonical) ne fassent pas ce calcul. Je ne crois pas que Shuttleworth soit très honnête quand il dit qu'ils ne font pas de statistiques.
Quant aux bouquins je ne vois pas comment l'OLPC peut prétendre les remplacer. Wikipédia n'est pas un manuel scolaire et son contenu n'est pas plus adapté à l'éducation que n'importe quel site Web lambda.
« Pas plus adapté que n'importe que site Web lambda » : peut-être (ça se discute), mais encore faut-il avoir accès aux « sites web lambda ». Ce qui impose, pour commencer, d'avoir un ordinateur. Et une connexion à internet. D'oû un OLPC. Même sans connexion internet, les contenus éducatifs, numérisés et libres (=> qu'on peut copier sur le disque et redistribuer) sont très nombreux.
Wikipédia n'est peut-être pas ce qui se fait de plus adapté pour l'apprentissage (mais c'est tout de même bien utile, au moins en ce qui concerne la version anglophone), mais même si l'on se restreint aux projets de Wikimédia (le projet parent de Wikipédia), il y a des frères de Wikipédia pour le coups très adaptés. Je saisis l'occasion pour les présenter ici à ceux qui ne connaissent pas :
Sur gutenberg, Hamlet, compréssé pèse 75 KB. Si on considère qu'un bouquin compressé pèse en moyenne le double d'Hamlet, soit 150 KB, et qu'on peut dédier 512 Mo pour stocker des ebooks, ça permet de mettre dans l'ordinateur environ 512*1024/150, soit 3 500 livres.
Si l'argent était dépensé pour acheter directement des livres et manuels scolaires au lieu d'un ordinateur, et pour, mettons, 0.5$ par livre logistique comprise, on pourrait donner 140/0.50 soit 280 livres par enfant (ne me parlez pas de bibliothèques : la logistique est encore plus lourde, et avoir un manuel scolaire et un dico juste pour soi c'est très différent d'un manuel scolaire partagé à plusieurs !).
Ceci sans même compter sur la présence d'une connectivité internet Là, le nombre de contenus pédagogiques, de livres, etc., disponibles explose (et ne cessera d'augmenter, jour après jour, à l'opposé d'un achat de livres physique, one shot).
Bref, ce qui suffit à maintenir mon enthousiasme au sujet de l'OLPC, c'est qu'il permettrai à l'enfant d'avoir toujours sous la main une belle bibliothèque, de nombreux manuels scolaires, un dictionnaire, etc, pour un prix finalement compétitif. Et son mode réflectif de lecture à l'écran en fait un bon « multi-livre électronique ». En somme, même si tout le reste (logiciels pédagogiques, utilitaires, musique, travail et jeu en réseau, ...) échoue, cet aspect « bibliothèque » est suffisant pour justifier l'OLPC en tant qu'outil pédagogique.
Et ce, grâce aux médias et à la culture_libre (et au domaine public). Venez wikimédier, chers amis ! ;-)
Pendant des siècles les écoles ont très bien fonctionné sans accès Internet ni "ordinateur pour faire des choses compliquées" (sic !).
Tu a raison. Mais je ne crois pas (je n'y connais rien) que les écoles aient fonctionné sans livres, non ? Alors, si on garde l'équation "OLPC == plein de livres", on peut penser qu'ils nous replace, au moins, dans un schéma classique.
Et puis le monde à bien changé : apprendre à utiliser un ordinateur est en passe de devenir un apprentissage fondamental, de nos jours.
On ne peut pas encore affirmer que l'OLPC soit un échec (ou une réussite) commercial, encore moins un échec ou une réussite sur le plan éducatif : il faudra des années avant de pouvoir répondre à cette question.
Mais ce qu'on peut d'or et déjà dire, c'est que c'est une sacré réussite sur le plan de l'ingénierie.
- Un ordinateur qui ne consomme que 2 W en plein fonctionnement (pour comparaison, les meilleurs ultraportables du moment tournent autour de 10 W, idle, et si on les optimise à mort)
- Plein d'amélioration des logiciels upstream pour arriver à ces fins (sur l'économie d'énergie en particulier)
- Un driver pour le chipset wifi Marvell Libertas
- Un modèle de sécurité démentiel et inédit, qui répond à plusieurs contraintes qu'on ne savait pas gérer avant (par exemple pouvoir authentifier, solidement et pour pas cher, des gens qui ne savent pas encore lire et écrire, ou encore simultanément protéger l'utilisateur naïf contre les conneries sécu de sa part (notamment s'il est sous influence d'un adulte malveillant, ie. sur irc), et simultanément de lui permettre de totalement tweaker/tout re-développer sur son ordi (liberté logicielle oblige) ...)
- Une technique antivol originale et innovante permettant automatiquement un ordinateur volé s'il ne se présente pas authentifié sur le réseau au bout d'un laps de temps, mais ne remettant pas en cause la liberté logiciel de l'ordi (le fait de pouvoir modifier tout le logiciel)
- Un écran démentiel, qui ne consomme que très très peu d'énergie, dispose d'un mode de fonctionnement « pc éteint » qui consomme encore moins d'énergie, peut se lire en pleine exposition lumineuse (soleil), peut se rabattre en mode tablette, et est finement conçu pour la lecture à l'écran (rien que ça, et son poids, fait de l'OLPC le lecteur ebook qui tue, vous n'avez jamais révé d'avoir quelque chose comme ça pour bouquiner au lit ?).
- Des techniques de fabrication censées assurer une robustesse de fou, au chocs, à la chaleur, à l'eau/la pluie, ... sans rendre l'ordi trop lourd
- Un système sophistiqué de mesh networking permettant de distribuer de la connectivité de pair à pair sans nuir à la sécurité ni aux batteries
- Une étude pointue des différents moyens pour fournir de l'énergie humaine pour alimenter un ordinateur
- Des nouveaux logiciels (je suis mitigé sur Sugar, mais de nouveaux softs libres, c'est toujours bon à prendre)
- ...
Fut-il dirigé par une entreprise, une telle réussite, une telle somme d'innovations aurait causé la ruine des investisseurs en achats de brevets !
Quant à l'aspect bazaar du projet, il me semble un excellent signe de la vie qui l'anime. Pour un outil qui se veut élaboré sur un mode communautaire (et destiné à mettre en oeuvre des théories constructivistes/vigotskiennes), c'est le mieux qu'ils puissent faire. Vu son ampleur et la taille de l'enjeu, le projet aurait bien sur pu être noyauté par des décideurs qui n'écoutent pas / ne font aucune confiance aux développeurs, écraser la communauté du libre à l'autel de la bureaucratie (salut Java, coucou OOo), utiliser les développeur du libre comme de la main d'oeuvre gratuite à qui donner des ordres, sans leur laisser l'initiative. Et bien je les trouve très fort et admirables de n'avoir pas procédé de la sorte.
Enfin, et contrairement à ce qui est dit plus haut ici, l'article de la Wikipédia anglophone [http://en.wikipedia.org/wiki/One_Laptop_per_Child] nous indique une longue liste de pays participants, y compris les USA (l'état du Massachusetts en particulier), que le Nigeria a déja commandé 1 000 000 OLPC, 1 200 000 pour la Lybie, ...
M'enfin, vous êtes militants du pessimisme ou quoi ?
Ne pas être défaitiste ! ;). D'abord, ne pas oublier que le but de cette équipe d'Intel est avant tout de produire des patchs intégrés upstream (et des paramétrages efficaces intégrés par défauts) qui aident à l'économie d'énergie, sans intervention de l'utilisateur (autant que faire se peut). Donc même sans aucun "tweak" de la part de l'utilisateur, leur travail depuis le kernel 2.6.20 est déjà sensible en mettant simplement à jour les logiciels concernés (le kernel avant tout, mais aussi xorg, laptop-mode-tools et hal). Je crois qu'à terme ils souhaitent que toutes ces astuces pour économiser l'énergie soient effectives, sur les distribs standards, sans aucune intervention de l'utilisateur.
Bref, pour vraiment juger de leur efficacité, il faudrait comparer la consommation d'énergie entre un kernel 2.6.20 (et xorg 7.2.0) et un kernel 2.6.23-rc7 (et xorg 7.3), sur x86.
Sinon, à combien de Watt est-tu, en situation "optimisée" ? Et quelle version du noyau utilise-tu ? Sur quelle architecture ?
La plupart des conseils (au moins, ceux qui visent à réduire les réveils de la CPU) ne sont réellement pertinents qu'avec un noyau tickless (donc >= 2.6.21 et x86, le ticklesss n'étant pas encore supporté par le kernel vanilla sur x86_64 ou ppc). Avec un noyau antérieur ou non x86, c'est beaucoup moins pertinent (pour le moment).
D'autre part lesswatt.org est censé, sou peu, recevoir toutes les astuces indiquées sur http://www.linuxpowertop.org/ , mais le transfert n'est pas encore fini à cette heure.
Et pour finir, il est bien utile de compléter l'application de ces astuces par une recherche des applications gourmandes, avec powertop (parce que les gens d'Intel n'utilisent pas forcément les mêmes logiciels que toi, ou la même version de ces logiciels, ils n'ont peut-être pas noté les bugs de certaines applications que tu utilise).
> hal-disable-polling --device /dev/sr0
Éventuellement faire de même avec les lecteurs smartcard et consorts.
Note que ceci n'est effectif qu'à condition que les entrées son (micro, line in) soient coupées. Il faudrait peut-être ajouter un coups de "alsactl" ou autre ici. Dans mes scripts j'ai mis :
amixer set Line mute nocap
amixer set Mic mute nocap
> echo 1 > /dev/dsp
Pourquoi faire ?
> rovclock -c 100 -m 125
Alternativement, il y a une autre méthode pour économiser l'énergie avec les radeons (incompatible avec celle-ci) - mais je ne sais pas si elle est plus efficace ou pas (il faut comparer, en ce qui me concerne mon portable est tout Intel ;) : placer 'Option "DynamicClocks" "on"' dans son xorg.conf, et "aticonfig --list-powerstates" et "aticonfig --set-powerstate=1 --effective=now".
Aussi, le DRI et les sucreries 3D (compiz...) causent de très nombreux réveils. Un bon 'Option "NoDRI"' dans xorg suffit à calmer le jeux. Pour finir avec les cartes graphiques : Arjan indique aussi économiser 1 Watt en fermant la sortie TV de sa carte vidéo (Intel) avec un "xrandr --output TV -off", que le driver laisse malencontreusement ouvert. Je ne sait pas ce qu'il en est pour les radeons, mais ça vaut la peine d'enquêter...
Quelques pistes pouvant aider à compléter ton script (ou pas) :
# désactiver le Wake-On-Lan
ethtool -s eth0 wol d
# activer le laptop mode
echo 5 > /proc/sys/vm/laptop_mode
# si son système est stable, pas la peine de causer de nombreux
# réveils CPU avec la surveillance des "Non Maskable Interrupt".
echo 0 > /proc/sys/kernel/nmi_watchdog
# rendre l'ordonanceur CPU plus économe (nb le nom
# de ce fichier peut varier selon les phases lunaires,
# par ex. sched_smt_power_savings).
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
# tuer les divers daemons de gestion de la vitesse CPU
# (cpufreqd, cpudyn & co) et choisir un algo efficace et adapté
# aux kernels tickless :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# ceci n'est utile que si le kernel est antérieur au 2.6.22
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
# ça, uniquement si on a appliqué les patchs de gestion d'énergie
# SATA AHCI de Kristen
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
echo min_power > /sys/class/scsi_host/host1/link_power_management_policy
# réduire la fréquence d'écriture des dirty pages sur le disque
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
# ça devrait déjà être actif, mais au cas où (ce serait balot de ne
# pas l'avoir activé, ou de ne pas se rendre compte que ça ne
# marche pas !).
xset +dpms
# fermer la sortie tv (avec les drivers xrandrisés, hein)
xrandr --output TV -off
# je sait pas vous, mais je n'ai pas franchement l'utilité de faire
# tourner le bluetooth en permanence, hors ça consomme pas mal
# de jus (autant l'activer manuellement lorsque besoin). Virons-le :
hciconfig hci0 down ; rmmod hci_usb
# À la différence de l'USB2 (qui peut couper l'alimentation du bus
# s'il n'y a pas d'activité), , l'USB1 n'a pas de fonctionnalité
# d'économie d'énergie. Le virer si on n'en n'a pas réellement besoin
# (les périphériques modernes tendent à être usb-2 de tt façons).
# Perso je fait carrément
# "echo "blacklist uhci_hcd" >> /etc/modprobe.d/blacklist"
# et je charge l'usb-1 à la main lorsque (c'est rare) j'en ai besoin.
rmmod uhci_hcd
# Le wifi est très gourmand. Si on a une interface wifi et qu'on
# l'utilise, activer le mode économe :
iwpriv eth1 set_power 5
# et si on ne l'utilise pas, la couper complètement :
# for i in /sys/bus/pci/drivers/*/*/rf_kill; do echo 1> $i ; done
# Si le laptop mode ne l'a pas déjà fait, activer l'économie d'énergie
# pour chaque disque dur :
hdparm -B 1 -S 12 /dev/sda
# la mise à jour du champ "atime" des inodes est passablement
# inutile (cf. les débats récents à ce sujet sur LKML), et cause des
# rotations disques régulières pour updater les inodes (le cache
# disque, utilisé en lecture, permet pourtant souvent de tenir un
# moment sans avoir besoin d'accéder physiquement aux disques),
# bref, faire qq chose comme ça pour toutes les partitions (voir,
# placer ça une fois pour toutes dans son /etc/fstab) :
mount -o remount,noatime /
# penser à désactiver tout les services inutiles. Par exemple :
# utilisez vous réellement l'imprimante, lorsque votre portable
# est sur batterie ?
/etc/init.d/bluetooth stop
/etc/init.d/cupsys stop
/etc/init.d/hplip stop
etc.
Et il y a les conseils pas trop scriptables, indiqués sur lesswatts ou linuxpowertop, comme :
- au lieu de paramétrer un écran de veille, choisir une shutdown complet de l'écran (d'où le dpms plus haut), avec par ex un "xset dpms force standby"
- virer les cochonneries d'indexeurs de fichiers (au moins tant qu'on tourne sur batterie) : beagle & co., et les autres trucs très gourmands (network-manager, compiz, xmms, mixer_applet2, ...)
- régler le rétro-éclairage au minimum lorsqu'on est sur batterie. Après la CPU lorsqu'elle est en pleine activité (et avant le Wifi), l'écran est ce qui consomme le plus d'énergie sur un portable moderne. Il faut chercher le meilleur compromis entre lisibilité et autonomie.
- vérifier dans son BIOS qu'il n'y a pas une option qui masque ou désactive les c-states C3 ou C4 et/ou l'HPET (c'est courant, à cause de limitations de Windows...).
Et vous pouvez aussi aider (et gagner encore de l'énergie) en testant ces patchs (qui devraient aller dans le 2.6.24 si j'ai bien compris, en tout cas le patch -hrt est bien stables chez moi) :
- Activation des hrtimers sur x86_64, activation d'HPET de force sur les chipsets connus pour supporter ce timer (même si le BIOS prétant qu'HPET n'est pas supporté pour ne pas brusquer WinXP) (par Thomas Gleixner) : http://www.tglx.de/projects/hrtimers/
Et puis, c'est profitable à tout le monde, repérer les applications qui ne dorment pas lorsqu'elles le devraient (ou qui causent des accès disques, au bus USB, etc.), et reporter des bugs, avec des choses simples comme :
# l'incontournable outil de diagnostic
powertop
# mais strace suffit souvent à repérer les applis déconnantes
strace -p $(pidof tonapp) # pour tt les applis qui tournent
# ceci affiche (dans le dmesg, oui, c'est moche) toutes les applis
# qui causent des accès aux disques :
sysctl vm.block_dump=1
# ceci liste les applis qui ont utilisé bcp de temps CPU
# depuis leur lancement
ps aux | awk '{print$10,$11}' | sort -n
D'un autre coté, si j'ai bien compris, le fait qu'il soit très simple et propre est précisément la raison de l'intérêt qu'il suscite. D'une façon générale, il est courant de voir des développeurs BSD réaffirmer leur attachement à la simplicité et la petite taille du code. Nonobstant cette simplicité, il semble que pcc sache déjà compiler (presque) tout le userland de NetBSD/i386 (et produise des binaires à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas si mal à ce stade infantile de non-optimisations).
Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur le site de PCC section « Goal » : « the intention is to write a C99 compiler while still keeping it small, simple, fast and understandable ». Preuve que la sophistication n'est pas toujours (ou pas pour tous) le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un logiciel.
> (En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)
Tu a mal compris, donc.
NetBSD l'a simplement inclus dans pkgsrc (approximativement, pour rapprocher ça de quelque chose que connaissent les linuxien, ils en ont fait un package pour NetBSD).
Et OpenBSD l'a importé dans son cvs comme ils font avec tout les logiciels qu'ils veulent inclure dans le système de base (où re-travailler à partir de là). C'est leur façon de faire, je pense qu'ils trouvent cette méthode plus pratique, mais ce ne sont pas des forks : même les projets qui acceptent toutes les modifs d'OpenBSD upstream (par ex. Sendmail ou Sudo) sont inclus de la sorte dans leur cvs. Il faut garder en tête, lorsqu'on vient du monde Linux, que les *BSD ont une approche plus centrée sur le code source / le cvs (par opposition aux distributions Linux courantes, souvent plus orientées packages / bugzilla).
Bref, ça ne les empêche pas de re-synchroniser régulièrement leur copie des sources, et d'envoyer leurs modifications upstream.
En l'occurence, vous pouvez aisément voir qu'ils travaillent collaborativement, en lisant ce qui se passe sur la mailing-list de pcc. ML dont les archives viennent d'êtres incluses dans MARC, pour info : http://marc.info/?l=pcc-list&r=1&b=200709&w=2
Archive et collaboration qui me rappelle que, si on peut fortement s'inquiéter des problèmes sociaux causés par un compilo qui compilerai trop vite ( http://xkcd.com/303/ ), il ne faut pas bouder le plaisir de trouver un nouveau terrain où de nombreux devs NetBSD et OpenBSD peuvent se foutre sur la gueule collaborer publiquement. Ce qui nous offrira sans doute de superbes coups de hache dans les gencives débats pour les soirées d'un hiver qui vient à grands pas ! :)
[^] # Re: GPL V3
Posté par herodiade . En réponse à la dépêche Les auteurs d'iptable et de Busybox appellent Iliad/Free à respecter la GPL. Évalué à 2.
iptables et busybox sont aussi sous GPLv2 (même pas « v2 et suivantes »). Pour busybox, d'ailleurs, c'est le résultat d'un gros combat entre les développeurs actuels, et Bruce Perens ressurgit de nulle part qui voulait soudainement imposer un passage très « politique » en v3.
De plus, l'autre remarque tient toujours (la FAQ indique que la version de la GPL n'aurait rien changé à la question).
Enfin, je doute que free ai eu besoin de faire des modifications sur ces deux produits, et encore plus qu'ils aient besoin de tenir de telles modifications, s'il y en a, secrètes (alors que pour le noyau, il y a surement des modules proprio pour les chipsets Broadcom et le modem, fournis sans sources ou sous NDA par les constructeurs).
Au passage, ne serait-il pas plus efficace d'attaquer directement Broadcom, Atheros & co., qui - c'est un comble - arrivent à vendre leur came sur de gros marchés linux comme les freebox, livebox et 9box (sans parler des serveurs IBM et leurs sal**peries de tg3, du Asus EEEpc, ...) en se contentant de fournir d'abominables modules propriétaires ? (ou ils ne touchent pas d'EXPORT_SYMBOL_GPL ?). Enfin, peut-être qu'un tel procès incitera Free à remonter de telles exigences à ses fournisseurs de chipsets...
[^] # Re: GPL V3
Posté par herodiade . En réponse à la dépêche Les auteurs d'iptable et de Busybox appellent Iliad/Free à respecter la GPL. Évalué à 2.
heu, non.
Comme l'indique la FAQ des plaignants (du moins, de Flouzo), ça n'aurai rien changé (sans compter que le noyau est et restera en v2).
Cf. http://freebox.flouzo.fr/wiki/FAQ
[^] # Re: Pourquoi une option ?
Posté par herodiade . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 2.
Heu, ça dépend de quoi on parle.
S'il s'agit du desktop, où l'ensemble des logiciels fournis par le distributeur suffisent généralement à l'utilisateur, tout à fait (et pour les logiciels non fournis par la distribution, donc sans règles SELinux, on sera tolérant en considérant que les desktop est généralement moins critique que les serveur).
Si on parle d'environnement serveur, où la sécurité est plus critique, c'est différent. Mis à part les serveurs d'infrastructure (mail, dns), je n'ai jamais administré des serveurs qui fassent tourner exclusivement des logiciels fournis par ma distribution. Sur mes serveurs web par exemple : certes j'utilise les apaches qu'on m'a fournis, et leurs modules. Mais il font tourner une foultitude d'application php, python, perl (cgis, applications métiers, devs maison, ...), des bloatwares en java, ... qui sont les "vrais" fonctionnalités offertes par le serveur. Vos sites web et vos applis j2ee sont fournis par Red Hat ?
Ainsi les applications critiques exposés au réseau ne seront finement protégés qu'à condition que l'admin écrive ou affine lui-même ses règles SELinux. Et là, la complexité est un handicap (pour revenir sur le troll de l'autre journal).
[^] # Re: Pourquoi une option ?
Posté par herodiade . En réponse à la dépêche Dossier sur le renforcement des fonctions de sécurité du noyau sur Secuobs.com. Évalué à 9.
Vraisemblablement pour ne pas casser le comportement standard de chroot(2), lequel est défini précisément par POSIX.1-2001.
En l'occurrence, les "problèmes" de chroot visés par grsecurity, ce n'est pas qu'il "laisse s'échapper les occupants", mais qu'il n'isole un processus du reste qu'au niveau du système de fichier, et c'est tout (les IPC fonctionnement normalement, les fd hérités restent ouverts, ...). Mais c'est ce pour quoi il a été conçu, on n'a pas menti sur la marchandise.
Chroot n'était pas prévu pour être utilisé comme un mécanisme de sécurité (cf. [http://lwn.net/Articles/252794/]), encore moins comme mécanisme d'isolation totale (à part pour le système de fichier). Des solutions parallèles sont cependant en cours de développement et intégration dans Linux (autour de la virtualisation et des espaces de nommages multiples et séparés pour les processus, par ex.) ; elles ont le mérite de présenter une architecture d'ensemble et cohérente, et de ne pas casser un appel système standard, existant et déjà largement utilisé par des milliers de logiciels.
> Cacher les process du noyau
C'est plutôt "cacher certains processus à d'autres processus". Tel que proposé par grsecurity, ce n'est pas une chose très simple (ou très saine) à intégrer dans le desktop de monsieur tout le monde. Là encore, il faut veiller à ne pas casser les standards ou l'existant. Et là encore, la virtualisation et la ségrégation de plusieurs espaces de nommages pour les processus (enfin pour le moment, seulement les pids) est une solution plus générale et en cours d'adoption.
> Logs beaucoup plus 'verbose' sur les actions des users
Là je ne sait pas trop de quoi tu parle. L'accounting BSD ne remplis pas cette fonction ?
> Protection de la pile
Si mes souvenirs sont bons, le patchset grsecurity+pax s'était vu rejeté, lorsqu'ils ont demandé l'intégration dans le noyau, notamment parce que les mécanismes de protection de pax divisaient par deux l'espace mémoire adressable par un processus donné, merci la belle régression (je dit ça de mémoire hein, c'est peut être "divisaient en quatre" ou quelque chose similaire, mais c'était bien un problème de ce type). Ce qui casse le fonctionnement d'un paquet d'applis en situation "enterprise", notamment celles qui font vendre du redhat/oracle.
Ce n'est pas la seule raison du refus, je me souvient que d'autres problèmes sans rapport direct avec la protection de la pile ont été soulevés sur lkml à l'époque (non utilisation de LSM, développeur principal qui refuse l'intégration d'une partie de son patchset parce que "la sécu c'est tout ou rien", et qui se montre odieux et borné comme seuls les dévs sécu noyau savent l'être (à la hauteur des devs SELinux ou de Theo de Raadt), ...).
# les slashs et les livres
Posté par herodiade . En réponse au journal Formation Développement OpenSource\Gnu Linux. Évalué à 5.
Un exemple : par rapport à Windows, dans le monde des unix libres, on place souvent les slashs dans l'autre sens (pas uniquement pour les paths ;)
Sinon, plaisanterie à part, je ne connais pas les formations existantes, mais je suis certain qu'avoir un bon bouquin sous le coude quelques semaines avant ta formation permettra de tirer le meilleur profit de celle-ci. Christophe Blaess, Programmation système en C sous Linux, ed. Eyrolles, 2005 est un très bon livre (par exemple).
[^] # Re: Pas si sûr...
Posté par herodiade . En réponse au journal article d'arrêt sur images sur la wikipédia. Évalué à 10.
Or si l'on parle de Wikipédia ou de logiciel libre, la distinction amateur/expert ne se fait pas sur cette frontière. Dans notre cas, l'amateur est celui qui aime (étymologie du mot amateur), ou plus précisément, qui produit au nom de son amour pour le sujet (d'où l'expression « amateur éclairé »), tandis que l'expert est la voix d'autorité (celui qui est qualifié pour parler) : le professionnel, ou la personne fortement diplômée.
Aussi pourra-t-on dire que le noyau linux (comme une majorité de logiciels libres) fut initié de façon amateur (pour le simple plaisir). De même, il n'est pas rare que nous initions, dans le logiciel libre, des développements sur des sujets que nous voulons approfondir plutôt que sur ce que nous connaissons déjà (ex. un admin qui fait du dev, un dev j2ee professionnel qui pendant ses loisirs travaillent sur une application C/GTK, ...). Et puis, combien d'entre nous sommes « experts » de l'informatique, au sens de « doté d'un doctorat ou d'une voix d'autorité (prof de fac, etc.) » ?
De même, parmi les contributeurs de Wikipédia, on trouve énormément de personnes bien diplômées, mais qui ne travaillent pas au nom de leur expertise (et en fait, pas toujours dans leur champs d'expertise précis). Parmi les bloggeurs, des personnes compétentes (ou pas), qui travaillent par passion et avec honnêteté. On contribue « pour l'amour de l'art ». Et à l'inverse des experts qui travaillent comme des porcs (spam, travail bâclé, pas de sources, pov-pushing, ...).
Ce que nous reprochons aux journalistes, c'est de ne pas aimer suffisamment leur sujet pour faire leur homework. Où, comme ont dit ici aux amateurs que nous sommes, de RTFM'er.
Ce qui fait la différence de qualité, pour nous, amateurs de logiciels libres, c'est plutôt l'honnêteté avec laquelle est fait le travail (cette honnêteté fait faire de bons logiciels libres par de jeunes étudiants, de bons articles par des wikipédiens sans diplômes ou par des journalistes hors de leur champ) que le diplôme des acteurs.
[^] # Re: LSM
Posté par herodiade . En réponse au journal Le nouveau SeLinux. Évalué à 3.
De fait les principales distributions ont déjà choisi :
1- Les dernières versions de Mandriva, SuSE et Ubuntu intègrent AppArmor
2- Red Hat utilise SELinux
Le 1 permet de comprendre le fait qu'a cette occasion SuSE ai licencié une partie de ses développeurs AppArmor (à mon avis un appel du pieds aux autres distribution, à la « à votre tour aussi, de participer au financement du bidule, maintenant que vous êtes dépendants »).
Le 2 permet de relativiser les prises de positions bruyantes d'Alan Cox (et de IsNotGood)...
L'intégration d'AppArmor semble imminente à présent (probablement pour le 2.6.25), je suppose que c'est pour ça que les FUDistes se réveillent... Aussi : patrick_g a totalement raison de soupçonner les devs SELinux de vouloir enlever LSM pour virer la concurrence, c'est du moins pour ça que Linus les a rappelé à l'ordre (et puis, rappelons-nous leur réaction aux besoins derrière AppArmor : « ah, mais la simplicité à la AA, il suffit de l'implémenter au-dessus de SELinux » (ce qu'ils n'ont pas fait) et à Smack (« ah, mais il n'ont qu'à réimplémenter un smack au-dessus de SELinux » (ce qui ne sera pas fait)).
Concernant les modèles de sécurité : certains spécialistes (pas moi, mais par exemple chez OpenBSD) considèrent qu'un modèle valable doit être simple, clair et auditable. Iznogood, as-tu audité les modèles de sécurité en oeuvre sur ton poste pour savoir précisément de quoi ils te protègent, et de quelle façon (par ex. s'il n'y a pas, dans une police, une bourde qui laisse une énorme brèche ouverte dans la cathédrale ? ce genres de bourdes sont courantes sur les systèmes complexes). Combien de personnes ont audité ce jeu de règles ? Les contraintes sécurité de la NSA sont autant d'ordre bureaucratiques que techniques (d'où une forme assez byzantine du machin). Pour le commun des mortels, le fait qu'un modèle et des polices de sécurité soient intégralement lisibles auditable par beaucoup de monde (et auditable plus efficacement par les spécialistes) est bénéfique à la sécurité.
Cela étant posé, on sait qu'il faut être attentifs à certaines choses en déployant du AppArmor (ne pas autoriser les processus confinés à monter des périphériques ou faire des hardlinks, faire attention aux rennomages, confiner tout les autres processus susceptibles d'échanger des file descriptors avec celui qui nous intéresse, ...). N'empêche. Sans jeter l'opprobre sur SELinux, ça laisse la place pour d'autres modèles (Tomoyo, Smack, AppArmor, ...).
Voila ce qu'en dit Ted T'so, je souscris totalement : http://lwn.net/Articles/252588/
[^] # Re: Antonio Negri
Posté par herodiade . En réponse au journal J'ai écrit à Libé... Évalué à 2.
http://profile.myspace.com/index.cfm?fuseaction=user.viewpro(...)
[^] # Re: Intel ne donne _pas_ ses specs -> et AMD pas des masses non plus
Posté par herodiade . En réponse à la dépêche Du nouveau chez ATI. Évalué à 10.
Si mes souvenirs sont bons, ils annonçaient « réfléchir à » (ou « travailler sur ») la façon de libérer le reste. En attendant, corrigez-moi si je me trompe, seule une infime partie de la doc a été libérée. Quand viendra le reste ? Se reposent-ils sur le succès de leur effet d'annonce ? L'ouverture des specs aurait-il pu être un pur plan marketing ? Ou est-ce que le reste des specs est déjà disponible mais de façon plus restreinte (par ex. sous NDA) ?
En tout cas, on ne trouve que ces deux docs datant du 12 sept. ici :
http://www.x.org/docs/AMD/
[^] # Re: Architectures supportées
Posté par herodiade . En réponse à la dépêche Sortie d'OpenBSD 4.2. Évalué à 7.
- permet de le réutiliser partout (c'est bien pour les normes et la concurrence proprio/libre)
plutôt, pour bien montrer les priorités :
- permet de le réutiliser partout (est compatible avec les softs sous GPL, LGPL, CDDL, MPL, ... et accessoirement avec le proprio (ce qui peut être bien pour les normes))
Parce que les développeurs de logiciels sous licence MIT ou BSD, je crois qu'ils sont généralement beaucoup plus intéressés par la réutilisation de leur code sans restriction par d'autres logiciels libres, que par le proprio (qui est plutôt un « side effect » qu'on juge négligeable). La compatibilité a toujours été importante en informatique, surtout la compatibilité entre « frères du libre ». Exemple : xorg et sa licence.
Ou pour le dire autrement : en choisissant la BSD, on se prive de pouvoir punir le proprio, généralement parce qu'on juge plus important de ne pas priver nos cousins du libre, sans discrimination, que de se laisser dicter une conduire par le proprio (dont on se fiche éperdument).
À part ça, je ne remercie pas Pierre Jarillon d'avoir pourri la dépêche en lançant ce troll (dans lequel je viens de marcher, imbécile de moi).
# Une note en passant...
Posté par herodiade . En réponse au journal Wikipedia dans le collimateur du Monde. Évalué à 10.
Robert Solé écrit, dans son article : « Wiki est un mot haïtien qui signifie "vite". ».
S'il avait lu Wikipédia, il aurait peut-être plutôt écrit : « Le mot "wiki" vient du redoublement hawaiien wiki wiki, qui signifie "rapide" ». Heureusement qu'il ne lit pas ce média si peu fiable, et qu'en journaliste à l'éthique incontestable, il vérifie ses informations et ne s'exprime que sur ce qu'il connait bien (mais où est le bouton « [Modifier] » ?).
Sur le bistro de WP aujourd'hui, Anthere (c'est-à-dire Florence_Devouard, la présidente de la Wikimedia Fundation) donne quelques précisions sur la chronologie des évènements, et un commentaire sur l'édito de Solé, et sur l'étonnant timing du Monde :
http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro/2_nove(...)
Citation choisie :
« Cela ressemble plutôt à un journaliste qui avait une idée dans la tête, et qui a sauté sur l'opportunité de la décision de justice pour faire son papier sur le sujet. Car la thèse qu'il soutient est exactement à l'opposé de ce qui vient précisément de ce passer. ».
# communiqué de pressse
Posté par herodiade . En réponse au journal Wikipedia dans le collimateur du Monde. Évalué à 10.
http://wikimedia.fr/index.php/Communiqu%C3%A9s_de_presse/La_(...)
Oui Assouline, blogueur du Monde mais pas seulement, est une plaie : non parce qu'il critique Wikipédia (après tout, de bonnes critiques ne peuvent que faire avancer le schmilblick), mais parce qu'il est *la* voix critique (il a un bon carnet d'adresse dans la presse), complètement incompétent (pour parler des questions liées à internet/au numérique, parce que, aussi, il ne renseigne pas du tout sur le fonctionnement de wikipédia, etc.), de mauvaise fois, ... C'est malheureusement lui qu'on invite toujours pour faire « contrepoids » (selon le principe à la mode des émissions actuelles, il faut inviter un « pour » et un « contre ») à la TV, à la radio, ... quand on parle de Wikipédia.
Oui à la critique, mais donnez nous des ennemis de qualité par pitié !
[^] # Re: C'est bien joli tout ça...
Posté par herodiade . En réponse au journal PulseAudio. Évalué à 3.
Pour compléter la remarque de patrick_g, et comme je l'ai indiqué plus haut, les parties critiques (en termes de latence) de pulse audio tournent avec une priorité RT (temps réel)... exactement comme jackd ;) (jackd est bien la preuve qu'un daemon n'ajoute pas forcément de la latence !).
Mais à la différence de jackd, la latence n'est pas la priorité absolue de PA, il propose donc certaines facilités qui rendent son utilisation plus simple pour les applications qui veulent seulement jouer des sons (comme le support, et la conversion à la volée de diverses fréquence d'échantillonnage envoyées par les applications : ce qui peut rajouter un tout petit poil de latence, mais est tellement pratique...). Bref, PA fait un petit compromis sur la latence (mais rien à voir avec l'énorme latence de dmix, ou pire, l'intolérable décalage d'esd) pour être plus pratique à utiliser.
[^] # Re: On est presque vendredi
Posté par herodiade . En réponse au journal PulseAudio. Évalué à 4.
> Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées [...] régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, [...]
Toute ressemblance avec un personnage existant dans le coin serait le fruit du hasard :P
[^] # Re: On est presque vendredi
Posté par herodiade . En réponse au journal PulseAudio. Évalué à 10.
- Pouvoir enfin exploiter le surround, et les divers systèmes audio multicanaux (5.1, 7.1 etc.) correctement (éventuellement en multiplexant plusieurs cartes son)
- Hotplug de cartes audio (penser aux "skype phones usb" par ex, ou aux oreillettes bluetooth).
- Possibilité d'intervenir sur les divers flux envoyés au daemon (pour régler les volumes différemment selon l'appli source, migrer un flux sur un autre périphérique, etc.)
- La portabilité (support natif de Windows, *BSD, Linux, Solaris) (nb: sachez bien que Alsa ne supporte que Linux : même pas les BSDs, ce qui explique que les développeurs d'applis ont dans l'ensemble conservé la compat OSS sur le long terme).
- Projet de gérer le son différemment selon les "états graphiques" (?), par ex. augmenter le volume de l'appli en avant plan, et baisser le volume de l'appli dans la barre des taches (pratique, lorsqu'on switche souvent entre firefox+vidéos flash, un lecteur de musique, un client irc qui blingue, etc.)
- Le point le plus important pour moi : la possibilité d'avoir une *très faible* latence sans jitters. En effet PA tourne avec une priorité Real Time (possible parce que c'est un daemon: on ne peut pas donner une telle priorité à tout les logiciels susceptibles d'envoyer directement du son à alsa).
Ce qui, en revanche, me semble très dommageable pour la réussite de ce remarquable projet, c'est l'attitude, le style, de son leader, Lennart Poettering. Il est d'une grande rudesse, fort peu diplomate, voir cassant, avec des opinions très tranchées (« stubborn », disait un gnomiste). Il est régulièrement désobligeant à l'égard de Ubuntu (« that spaceboy distro »), de KDE, des *BSD, insultant à l'égard des contributeurs potentiels peu dégourdis, des décisions à la « je force rigidement et artificiellement un choix en vérouillant le périphérique », mépris total des outils aimés par les utilisateurs (« amarock -- or whatever that awful media player everyone but me loves so much is called »), etc... Bref, c'est une grande gueule aux opinions très tranchées, et pas très intéressés par la collaboration avec les outils et technos non-gnome.
C'est dommageable, parce qu'on attends vraiment d'un projet comme PA qu'il fédère, enfin, les divers projets libres autour d'une très bonne API son, à la façon d'un projet freedesktop ; qu'on se défasse enfin de la concurrence entre tout ces vieux logiciels presque non maintenus (esd, arts, lecteurs audios divers, ...) qui cherchent chacun à vérouiller la carte son en entrée, et même parfois en sortie (souvent en schuintant dmix au vol). Or s'il s'alienne déjà l'ensemble de l'environnement KDE (« I don't care about KDE »), l'objectif est déjà loupé ; nous garderons nos petits problèmes de conflits d'accès concurrent pour un bon moment encore ... :(
Bon, mais rappelons-le, l'outil est excellent (et les projets de développements annoncés sont alléchants).
[^] # Re: unixfix travaillerait pour Paris Match ?
Posté par herodiade . En réponse au journal Canonical aurait des actions de fabricants de disques durs!. Évalué à 3.
193 Load_Cycle_Count 0x0032 075 075 000 Old_age Always - 2563793638660
2563793638660 cycles de parquages de têtes sur mon HITACHI_DK13FA-40B (disque par défaut dans mon IBM Thinkpad X40) ?
Super fiable...
[^] # Re: confus pour moi
Posté par herodiade . En réponse au journal Canonical aurait des actions de fabricants de disques durs!. Évalué à 10.
Par rapport à la dépêche, il faut quand même rappeler que les têtes font un cycle load/unload si vous passez de l'activité disque à l'inactivité, puis à nouveau à l'activité, etc... en permanence. Si vous restez en activité continue, les têtes ne sont pas parquées, et si l'activité disque est bien réduite, les têtes restent parquées : dans les deux cas, le nombre de load/unload n'augmente pas.
Si les accès disques ont seulement lieu lorsque vous travaillez réellement dessus (ie. lecture d'une vidéo stockée sur le disque), et s'ils sont au repos lorsque vous ne faite quasiment rien d'autre (lire une page web, etc.), alors les têtes resteront parquées plus longtemps avec un x ("hdparm -B x") faible.
Or précisément, le laptop_mode (le mode dont on parle, qui exécute le "hdparm -B 1") vise à réduire le plus possible les activités disques non d'arrière-plan (et à regrouper les autres, etc.). Bref, le laptop_mode permet effectivement de ne pas augmenter le cycle load/unload, en restant plus longtemps avec les têtes parquées.
Précisons aussi que sous Ubuntu, le kernel est patché pour que les partitions soient montées en noatime par défaut (ce qui réduit là encore considérablement les accès hors du cache). Si vous utilisez une autre distro sur un laptop, faites un "mount -o remount,noatime /" (ou mieux, ajustes votre fstab). Aussi, le fichier de configuration /etc/laptop-mode/laptop-mode.conf (si le paquet laptop-mode est installé) permet de passer une configuration alternative à syslogd lorsqu'on est sur batterie (ie. n'écrire sur le disque que les messages critiques ou emergency, et ne flusher que rarement).
Une configuration correcte et propre, par une distribution Linux responsable, des ordinateurs portables lorsqu'ils sont sur batterie ne consiste pas à coller un hdparm conservatif (style -B 255) « et basta, on se mouille pas les mains et osef de la consommation », mais bel et bien à réduire le plus possible les accès disques inutiles (réduire le nombre de cycles load/unload en privilégiant la stagnation dans l'état "têtes parquées" et pas en privilégiant l'état "têtes actives") : c'est ça, la solution propre, à viser.
Donc oui, Matthieu Garett à raison de préciser que cette valeur d'hdparm est activée par Ubuntu seulement lorsque le laptop_mode est activé : car dans ce cas, le risque d'impact sur la durée de vie est minimisé. Et il a aussi raison de pester contre les fabriquant de disque qui mettent des valeurs très courtes par défaut : car elle seront actives telles quelles, même lorsque vous n'êtes pas en mode laptop.
nb: par contre il y a un bug d'Ubuntu qui fait que on_ac_power(1) retourne parfois 0 même sur des desktop branchés sur le secteur, et ça c'est plus embêtant.
[^] # Re: Départages nuisibles!
Posté par herodiade . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 3.
> Ont-ils abandonné le libre et retourné chez M$ ?
> Ont-ils changé de distribution ?
En fait - et il aurait fallu le souligner dès le départ - Mark Shuttleworth dit dans un premier temps « Il y a probablement au moins 8M utilisateurs », et dans un second temps « Il y a plus de 6M utilisateurs ». Donc, et si on prends ses propos au sérieux (manifestement, il laisse des indices pour qu'on ne le prenne pas au sérieux), on ne peut pas affirmer qu'ils ont perdu 2M utilisateurs (« plus de 6M », ça peut être 7, 8, 9 ou 10M).
Si je fait ce rappel, ce n'est pas pour chippoter sur les mots, mais ...
> La vraie réflexion serait plutôt :
... pour ramener à la vrai réflexion (selon moi) :
Pourquoi Shuttleworth reste-t-il aussi évasif sur le sujet (« plus de », « probablement », ...) ?
Pourquoi donne-t-il des chiffres si ostensiblement imprécis et inutiles, alors qu'il a sous la main des données plus fiables ?
Pourquoi affirme-t-il qu'il n'a pas de moyens de mesurer (c'est du pipeau, il en a, et le cas échéant il ne pourrait même pas donner de telles approximations) ?
Pourquoi n'encouragent-ils pas plus activement l'utilisation de popcon (ou smolt, ou autre) à l'installation et à l'upgrade ?
Si son problème est de vouloir masquer une fuite des utilisateurs, dans ce cas pourquoi aurait-il dit « plus de 6M » la seconde fois (au point ou nous en sommes, il pouvait dire : « plus de 10M » et hop) ?
Les 8M qui deviennent « plus de 6M », à mon sens, c'est plus surement un signe d'un problème avec la divulgation des chiffres que le signe clair d'un problème de fuite des utilisateurs.
C'est la question la plus importante. Si l'objectif n'est pas le Ubuntu-bashing, mais, comme l'indique GeneralZod, « d'encourager Ubuntu à rejoindre l'initiative Smolt et/ou publier des statistiques digne de confiance », il faudrait savoir pourquoi, pour commencer, MS est réticent sur ce point (perso, je n'en n'ai aucune idée, les raisons peuvent être multiples). Si on ne sait pas quel est son problème avec ces chiffres, on ne saura pas comment le faire changer d'avis, non ?
[^] # Re: Mesurer les téléchargement des mises à jour sur security.ubuntu.com
Posté par herodiade . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 3.
Oui ceux-là ne sont pas comptés (enfin, une seule fois pour tout les postes), mais nous ne sommes plus à l'époque du 56k, à mon avis les utilisateurs d'apt-proxy sont rares en proportion.
Idem pour ceux qui ne font pas les mises à jour (ou n'ont pas internet) : ils ne sont pas comptés. Mais il me semble que Smolt à le même problème (il faut que l'utilisateur accepte de transmettre les statistiques, et dispose d'internet), voir pire (un utilisateur à intérêt à faire les màj sécu, alors qu'envoyer des stats...).
Bref ça permet de faire une évaluation *conservative* du nombre d'utilisateurs : certains ne seront pas comptés. Mais, à mon avis, une évaluation assez proche de la réalité.
> les gens qui mettent à jour leur distro, et qui du coup sont comptés comme user de la version X et X+1
Non. Ce qu'on compte c'est « combien de personnes ont téléchargé le paquet toto_42-ubuntu2_i386.deb - récemment mis à jour pour raison de sécurité - dans le dépôt feisty-security, et dans le dépôt gutsy-security, etc. ».
Bref, on re-fait les comptes à partir de 0 pour chaque paquet proposé à la mise à jour, on n'additionne évidement pas les calculs successifs. Ainsi, celui qui upgrade est compté comme « utilisateur de feisty » lors d'une première mise à jour, et s'il upgrade, comme « utilisateur de gutsy » (mais plus utilisateur de feisty) aux màj suivantes. Et on peut ainsi, au passage, suivre l'évolution des utilisateurs des diverses versions.
> les gens qui ont un proxy chez leur fai
Un proxy configuré pour cacher des objets aussi gros qu'une mise à jour d'OOo ? tu veut dire qu'il y a des fai qui cherchent à mirrorer l'internet complet ? ou tu es de mauvaise foi ?
> les gens qui doivent utiliser un miroir.
Pour les mises à jour sécurité, par défaut, ubuntu ne place pas de mirroir dans le sources.list. C'est suffisant (en fait je ne crois pas qu'il y ai des mirroirs officiels du dépôt des mises à jours sécu).
> tu comptes quoi ? Les ips différentes (et le nat, et les ips dynamiques ) ?
Non, tu compte le nombre de téléchargements d'un paquet donné (peut importe les IP, uniques ou pas). Les outils apt ne re-téléchargent pas un paquet qu'ils ont déjà récupéré (sauf rare exception, si vous voulez chipoter). Si tu a trois postes sous Ubuntu à la maison (derrière du NAT ou pas), et que tu les maintient à jours, ils téléchargeront vraisemblablement tout les trois la dernière maj sécurité du noyau, une fois chacun.
> Le nombre de gens qui téléchargent les indexes
Non ça n'a pas d'intérêt de mesurer les téléchargements d'indexes, puisque, très souvent, on télécharge plusieurs fois le même indexe sur un même poste.
[^] # Re: Mark Shuttleworth
Posté par herodiade . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 0.
Le fait est qu'ils ne les publient pas (pour une raison qui m'échappe) : c'est un choix, et je vois mal en quoi smolt aiderai à changer ce choix. Ou, et c'est où je veut en venir, ils peuvent publier des statistiques bidons : ils le font (peut-être) déjà alors qu'ils ont les informations retournées de http://security.ubuntu.com (les 8 M users puis « plus de 6 M users »). Mais s'ils administrent le serveur de stats utilisé par le smolt sous Ubuntu, qu'est-ce qui les empêche de faire de même ? Mais au fait, qu'est-ce qui empêche Red Hat / Fedora d'arranger leurs stats smolt ?
Sinon à titre d'évaluation personnelle, si Fedora dispose d'une base de 1.7 million d'utilisateurs, je m'attends à ce qu'Ubuntu ai une base d'utilisateurs 3 à 5 fois plus grande (donc bien dans les 6 à 8 millions d'utilisateurs), minimum.
[^] # Mesurer les téléchargement des mises à jour sur security.ubuntu.com
Posté par herodiade . En réponse au journal De l'importance d'avoir des statisques fiables. Évalué à 2.
Les propositions de mises à jour sont activées par défaut (et probablement appliquées par la plupart des utilisateurs), et leur dépôt est placé sur le même (cluster de) serveur(s) central géré par Canonical, http://security.ubuntu.com/ubuntu . Évidement ça ne compte pas ceux qui n'appliquent pas les mises à jour (ou qui n'ont pas internet), mais j'estime ça à une proportion négligeable.
Je doute fort qu'ils (Canonical) ne fassent pas ce calcul. Je ne crois pas que Shuttleworth soit très honnête quand il dit qu'ils ne font pas de statistiques.
[^] # Re: Pays developpes en phase avec pays en voie de developpement
Posté par herodiade . En réponse à la dépêche OLPC Give 1 Get 1 : Donnez-en 1, obtenez-en 1. Évalué à 7.
« Pas plus adapté que n'importe que site Web lambda » : peut-être (ça se discute), mais encore faut-il avoir accès aux « sites web lambda ». Ce qui impose, pour commencer, d'avoir un ordinateur. Et une connexion à internet. D'oû un OLPC. Même sans connexion internet, les contenus éducatifs, numérisés et libres (=> qu'on peut copier sur le disque et redistribuer) sont très nombreux.
Wikipédia n'est peut-être pas ce qui se fait de plus adapté pour l'apprentissage (mais c'est tout de même bien utile, au moins en ce qui concerne la version anglophone), mais même si l'on se restreint aux projets de Wikimédia (le projet parent de Wikipédia), il y a des frères de Wikipédia pour le coups très adaptés. Je saisis l'occasion pour les présenter ici à ceux qui ne connaissent pas :
- Wikibooks (manuels scolaires libres) : http://fr.wikibooks.org/wiki/Accueil
- Wikiversité (une sorte d'université/communauté pédagogique en ligne) : http://fr.wikiversity.org/wiki/Accueil
- Wikisource (bibliothèque de libres dans le domaine public) : http://wikisource.org/wiki/Main_Page
- Wiktionnaire (dictionnaire multilingue) : http://fr.wiktionary.org/wiki/Wiktionnaire:Page_d%27accueil
À quoi il faudrait ajouter les projets de numérisation de contenu du domaine public, tels que gutenberg, les « classiques des sciences sociales » (http://www.uqac.uquebec.ca/zone30/Classiques_des_sciences_so(...) ), etc.
Pour une liste extensive, voir http://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Ressources_libre(...)
Sur gutenberg, Hamlet, compréssé pèse 75 KB. Si on considère qu'un bouquin compressé pèse en moyenne le double d'Hamlet, soit 150 KB, et qu'on peut dédier 512 Mo pour stocker des ebooks, ça permet de mettre dans l'ordinateur environ 512*1024/150, soit 3 500 livres.
Si l'argent était dépensé pour acheter directement des livres et manuels scolaires au lieu d'un ordinateur, et pour, mettons, 0.5$ par livre logistique comprise, on pourrait donner 140/0.50 soit 280 livres par enfant (ne me parlez pas de bibliothèques : la logistique est encore plus lourde, et avoir un manuel scolaire et un dico juste pour soi c'est très différent d'un manuel scolaire partagé à plusieurs !).
Ceci sans même compter sur la présence d'une connectivité internet Là, le nombre de contenus pédagogiques, de livres, etc., disponibles explose (et ne cessera d'augmenter, jour après jour, à l'opposé d'un achat de livres physique, one shot).
Bref, ce qui suffit à maintenir mon enthousiasme au sujet de l'OLPC, c'est qu'il permettrai à l'enfant d'avoir toujours sous la main une belle bibliothèque, de nombreux manuels scolaires, un dictionnaire, etc, pour un prix finalement compétitif. Et son mode réflectif de lecture à l'écran en fait un bon « multi-livre électronique ». En somme, même si tout le reste (logiciels pédagogiques, utilitaires, musique, travail et jeu en réseau, ...) échoue, cet aspect « bibliothèque » est suffisant pour justifier l'OLPC en tant qu'outil pédagogique.
Et ce, grâce aux médias et à la culture_libre (et au domaine public). Venez wikimédier, chers amis ! ;-)
Pendant des siècles les écoles ont très bien fonctionné sans accès Internet ni "ordinateur pour faire des choses compliquées" (sic !).
Tu a raison. Mais je ne crois pas (je n'y connais rien) que les écoles aient fonctionné sans livres, non ? Alors, si on garde l'équation "OLPC == plein de livres", on peut penser qu'ils nous replace, au moins, dans un schéma classique.
Et puis le monde à bien changé : apprendre à utiliser un ordinateur est en passe de devenir un apprentissage fondamental, de nos jours.
[^] # Re: Pas la peine de tricher sur les mots
Posté par herodiade . En réponse à la dépêche OLPC Give 1 Get 1 : Donnez-en 1, obtenez-en 1. Évalué à 10.
Mais ce qu'on peut d'or et déjà dire, c'est que c'est une sacré réussite sur le plan de l'ingénierie.
- Un ordinateur qui ne consomme que 2 W en plein fonctionnement (pour comparaison, les meilleurs ultraportables du moment tournent autour de 10 W, idle, et si on les optimise à mort)
- Plein d'amélioration des logiciels upstream pour arriver à ces fins (sur l'économie d'énergie en particulier)
- Un driver pour le chipset wifi Marvell Libertas
- Un modèle de sécurité démentiel et inédit, qui répond à plusieurs contraintes qu'on ne savait pas gérer avant (par exemple pouvoir authentifier, solidement et pour pas cher, des gens qui ne savent pas encore lire et écrire, ou encore simultanément protéger l'utilisateur naïf contre les conneries sécu de sa part (notamment s'il est sous influence d'un adulte malveillant, ie. sur irc), et simultanément de lui permettre de totalement tweaker/tout re-développer sur son ordi (liberté logicielle oblige) ...)
- Une technique antivol originale et innovante permettant automatiquement un ordinateur volé s'il ne se présente pas authentifié sur le réseau au bout d'un laps de temps, mais ne remettant pas en cause la liberté logiciel de l'ordi (le fait de pouvoir modifier tout le logiciel)
- Un écran démentiel, qui ne consomme que très très peu d'énergie, dispose d'un mode de fonctionnement « pc éteint » qui consomme encore moins d'énergie, peut se lire en pleine exposition lumineuse (soleil), peut se rabattre en mode tablette, et est finement conçu pour la lecture à l'écran (rien que ça, et son poids, fait de l'OLPC le lecteur ebook qui tue, vous n'avez jamais révé d'avoir quelque chose comme ça pour bouquiner au lit ?).
- Des techniques de fabrication censées assurer une robustesse de fou, au chocs, à la chaleur, à l'eau/la pluie, ... sans rendre l'ordi trop lourd
- Un système sophistiqué de mesh networking permettant de distribuer de la connectivité de pair à pair sans nuir à la sécurité ni aux batteries
- Une étude pointue des différents moyens pour fournir de l'énergie humaine pour alimenter un ordinateur
- Des nouveaux logiciels (je suis mitigé sur Sugar, mais de nouveaux softs libres, c'est toujours bon à prendre)
- ...
Fut-il dirigé par une entreprise, une telle réussite, une telle somme d'innovations aurait causé la ruine des investisseurs en achats de brevets !
Quant à l'aspect bazaar du projet, il me semble un excellent signe de la vie qui l'anime. Pour un outil qui se veut élaboré sur un mode communautaire (et destiné à mettre en oeuvre des théories constructivistes/vigotskiennes), c'est le mieux qu'ils puissent faire. Vu son ampleur et la taille de l'enjeu, le projet aurait bien sur pu être noyauté par des décideurs qui n'écoutent pas / ne font aucune confiance aux développeurs, écraser la communauté du libre à l'autel de la bureaucratie (salut Java, coucou OOo), utiliser les développeur du libre comme de la main d'oeuvre gratuite à qui donner des ordres, sans leur laisser l'initiative. Et bien je les trouve très fort et admirables de n'avoir pas procédé de la sorte.
Enfin, et contrairement à ce qui est dit plus haut ici, l'article de la Wikipédia anglophone [http://en.wikipedia.org/wiki/One_Laptop_per_Child] nous indique une longue liste de pays participants, y compris les USA (l'état du Massachusetts en particulier), que le Nigeria a déja commandé 1 000 000 OLPC, 1 200 000 pour la Lybie, ...
M'enfin, vous êtes militants du pessimisme ou quoi ?
[^] # Re: Gains très faibles
Posté par herodiade . En réponse au journal Intel contre EDF.. Évalué à 10.
Bref, pour vraiment juger de leur efficacité, il faudrait comparer la consommation d'énergie entre un kernel 2.6.20 (et xorg 7.2.0) et un kernel 2.6.23-rc7 (et xorg 7.3), sur x86.
Sinon, à combien de Watt est-tu, en situation "optimisée" ? Et quelle version du noyau utilise-tu ? Sur quelle architecture ?
La plupart des conseils (au moins, ceux qui visent à réduire les réveils de la CPU) ne sont réellement pertinents qu'avec un noyau tickless (donc >= 2.6.21 et x86, le ticklesss n'étant pas encore supporté par le kernel vanilla sur x86_64 ou ppc). Avec un noyau antérieur ou non x86, c'est beaucoup moins pertinent (pour le moment).
D'autre part lesswatt.org est censé, sou peu, recevoir toutes les astuces indiquées sur http://www.linuxpowertop.org/ , mais le transfert n'est pas encore fini à cette heure.
Et pour finir, il est bien utile de compléter l'application de ces astuces par une recherche des applications gourmandes, avec powertop (parce que les gens d'Intel n'utilisent pas forcément les mêmes logiciels que toi, ou la même version de ces logiciels, ils n'ont peut-être pas noté les bugs de certaines applications que tu utilise).
> hal-disable-polling --device /dev/sr0
Éventuellement faire de même avec les lecteurs smartcard et consorts.
> echo 1 > /sys/module/snd_ac97_codec/parameters/power_save
Note que ceci n'est effectif qu'à condition que les entrées son (micro, line in) soient coupées. Il faudrait peut-être ajouter un coups de "alsactl" ou autre ici. Dans mes scripts j'ai mis :
amixer set Line mute nocap
amixer set Mic mute nocap
> echo 1 > /dev/dsp
Pourquoi faire ?
> rovclock -c 100 -m 125
Alternativement, il y a une autre méthode pour économiser l'énergie avec les radeons (incompatible avec celle-ci) - mais je ne sais pas si elle est plus efficace ou pas (il faut comparer, en ce qui me concerne mon portable est tout Intel ;) : placer 'Option "DynamicClocks" "on"' dans son xorg.conf, et "aticonfig --list-powerstates" et "aticonfig --set-powerstate=1 --effective=now".
Aussi, le DRI et les sucreries 3D (compiz...) causent de très nombreux réveils. Un bon 'Option "NoDRI"' dans xorg suffit à calmer le jeux. Pour finir avec les cartes graphiques : Arjan indique aussi économiser 1 Watt en fermant la sortie TV de sa carte vidéo (Intel) avec un "xrandr --output TV -off", que le driver laisse malencontreusement ouvert. Je ne sait pas ce qu'il en est pour les radeons, mais ça vaut la peine d'enquêter...
Quelques pistes pouvant aider à compléter ton script (ou pas) :
# désactiver le Wake-On-Lan
ethtool -s eth0 wol d
# activer le laptop mode
echo 5 > /proc/sys/vm/laptop_mode
# si son système est stable, pas la peine de causer de nombreux
# réveils CPU avec la surveillance des "Non Maskable Interrupt".
echo 0 > /proc/sys/kernel/nmi_watchdog
# rendre l'ordonanceur CPU plus économe (nb le nom
# de ce fichier peut varier selon les phases lunaires,
# par ex. sched_smt_power_savings).
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
# tuer les divers daemons de gestion de la vitesse CPU
# (cpufreqd, cpudyn & co) et choisir un algo efficace et adapté
# aux kernels tickless :
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# ceci n'est utile que si le kernel est antérieur au 2.6.22
cd /sys/devices/system/cpu/cpu0/cpufreq
cat ondemand/sampling_rate_max > ondemand/sampling_rate
# ça, uniquement si on a appliqué les patchs de gestion d'énergie
# SATA AHCI de Kristen
echo min_power > /sys/class/scsi_host/host0/link_power_management_policy
echo min_power > /sys/class/scsi_host/host1/link_power_management_policy
# réduire la fréquence d'écriture des dirty pages sur le disque
echo 1500 > /proc/sys/vm/dirty_writeback_centisecs
# ça devrait déjà être actif, mais au cas où (ce serait balot de ne
# pas l'avoir activé, ou de ne pas se rendre compte que ça ne
# marche pas !).
xset +dpms
# fermer la sortie tv (avec les drivers xrandrisés, hein)
xrandr --output TV -off
# je sait pas vous, mais je n'ai pas franchement l'utilité de faire
# tourner le bluetooth en permanence, hors ça consomme pas mal
# de jus (autant l'activer manuellement lorsque besoin). Virons-le :
hciconfig hci0 down ; rmmod hci_usb
# À la différence de l'USB2 (qui peut couper l'alimentation du bus
# s'il n'y a pas d'activité), , l'USB1 n'a pas de fonctionnalité
# d'économie d'énergie. Le virer si on n'en n'a pas réellement besoin
# (les périphériques modernes tendent à être usb-2 de tt façons).
# Perso je fait carrément
# "echo "blacklist uhci_hcd" >> /etc/modprobe.d/blacklist"
# et je charge l'usb-1 à la main lorsque (c'est rare) j'en ai besoin.
rmmod uhci_hcd
# Le wifi est très gourmand. Si on a une interface wifi et qu'on
# l'utilise, activer le mode économe :
iwpriv eth1 set_power 5
# et si on ne l'utilise pas, la couper complètement :
# for i in /sys/bus/pci/drivers/*/*/rf_kill; do echo 1> $i ; done
# Si le laptop mode ne l'a pas déjà fait, activer l'économie d'énergie
# pour chaque disque dur :
hdparm -B 1 -S 12 /dev/sda
# la mise à jour du champ "atime" des inodes est passablement
# inutile (cf. les débats récents à ce sujet sur LKML), et cause des
# rotations disques régulières pour updater les inodes (le cache
# disque, utilisé en lecture, permet pourtant souvent de tenir un
# moment sans avoir besoin d'accéder physiquement aux disques),
# bref, faire qq chose comme ça pour toutes les partitions (voir,
# placer ça une fois pour toutes dans son /etc/fstab) :
mount -o remount,noatime /
# penser à désactiver tout les services inutiles. Par exemple :
# utilisez vous réellement l'imprimante, lorsque votre portable
# est sur batterie ?
/etc/init.d/bluetooth stop
/etc/init.d/cupsys stop
/etc/init.d/hplip stop
etc.
Et il y a les conseils pas trop scriptables, indiqués sur lesswatts ou linuxpowertop, comme :
- au lieu de paramétrer un écran de veille, choisir une shutdown complet de l'écran (d'où le dpms plus haut), avec par ex un "xset dpms force standby"
- virer les cochonneries d'indexeurs de fichiers (au moins tant qu'on tourne sur batterie) : beagle & co., et les autres trucs très gourmands (network-manager, compiz, xmms, mixer_applet2, ...)
- régler le rétro-éclairage au minimum lorsqu'on est sur batterie. Après la CPU lorsqu'elle est en pleine activité (et avant le Wifi), l'écran est ce qui consomme le plus d'énergie sur un portable moderne. Il faut chercher le meilleur compromis entre lisibilité et autonomie.
- vérifier dans son BIOS qu'il n'y a pas une option qui masque ou désactive les c-states C3 ou C4 et/ou l'HPET (c'est courant, à cause de limitations de Windows...).
Et vous pouvez aussi aider (et gagner encore de l'énergie) en testant ces patchs (qui devraient aller dans le 2.6.24 si j'ai bien compris, en tout cas le patch -hrt est bien stables chez moi) :
- Activation des hrtimers sur x86_64, activation d'HPET de force sur les chipsets connus pour supporter ce timer (même si le BIOS prétant qu'HPET n'est pas supporté pour ne pas brusquer WinXP) (par Thomas Gleixner) :
http://www.tglx.de/projects/hrtimers/
- SATA AHCI Linux power management (par Kristen Accardi, d'Intel) :
http://www.kernel.org/pub/linux/kernel/people/kristen/patche(...)
Et puis, c'est profitable à tout le monde, repérer les applications qui ne dorment pas lorsqu'elles le devraient (ou qui causent des accès disques, au bus USB, etc.), et reporter des bugs, avec des choses simples comme :
# l'incontournable outil de diagnostic
powertop
# mais strace suffit souvent à repérer les applis déconnantes
strace -p $(pidof tonapp) # pour tt les applis qui tournent
# ceci affiche (dans le dmesg, oui, c'est moche) toutes les applis
# qui causent des accès aux disques :
sysctl vm.block_dump=1
# ceci liste les applis qui ont utilisé bcp de temps CPU
# depuis leur lancement
ps aux | awk '{print$10,$11}' | sort -n
[^] # Re: llvm
Posté par herodiade . En réponse au journal Fin de gcc dans les *BSD ?. Évalué à 5.
D'un autre coté, si j'ai bien compris, le fait qu'il soit très simple et propre est précisément la raison de l'intérêt qu'il suscite. D'une façon générale, il est courant de voir des développeurs BSD réaffirmer leur attachement à la simplicité et la petite taille du code. Nonobstant cette simplicité, il semble que pcc sache déjà compiler (presque) tout le userland de NetBSD/i386 (et produise des binaires à peine 6 à 8% plus gros que ceux produits par gcc, ce qui n'est pas si mal à ce stade infantile de non-optimisations).
Et cet aspect est bel et bien un but du compilateur, tel qu'indiqué sur le site de PCC section « Goal » : « the intention is to write a C99 compiler while still keeping it small, simple, fast and understandable ». Preuve que la sophistication n'est pas toujours (ou pas pour tous) le critère d'ingénierie déterminant, s'agissant d'évaluer l'intérêt d'un logiciel.
> (En plus si j'ai bien compris ce que vienne de faire NetBSD et OpenBSD, ils viennent de forker le projet en l'important chacun dans leur cvs, donc ca risque d'avancer encore moins)
Tu a mal compris, donc.
NetBSD l'a simplement inclus dans pkgsrc (approximativement, pour rapprocher ça de quelque chose que connaissent les linuxien, ils en ont fait un package pour NetBSD).
Et OpenBSD l'a importé dans son cvs comme ils font avec tout les logiciels qu'ils veulent inclure dans le système de base (où re-travailler à partir de là). C'est leur façon de faire, je pense qu'ils trouvent cette méthode plus pratique, mais ce ne sont pas des forks : même les projets qui acceptent toutes les modifs d'OpenBSD upstream (par ex. Sendmail ou Sudo) sont inclus de la sorte dans leur cvs. Il faut garder en tête, lorsqu'on vient du monde Linux, que les *BSD ont une approche plus centrée sur le code source / le cvs (par opposition aux distributions Linux courantes, souvent plus orientées packages / bugzilla).
Bref, ça ne les empêche pas de re-synchroniser régulièrement leur copie des sources, et d'envoyer leurs modifications upstream.
En l'occurence, vous pouvez aisément voir qu'ils travaillent collaborativement, en lisant ce qui se passe sur la mailing-list de pcc. ML dont les archives viennent d'êtres incluses dans MARC, pour info : http://marc.info/?l=pcc-list&r=1&b=200709&w=2
Archive et collaboration qui me rappelle que, si on peut fortement s'inquiéter des problèmes sociaux causés par un compilo qui compilerai trop vite ( http://xkcd.com/303/ ), il ne faut pas bouder le plaisir de trouver un nouveau terrain où de nombreux devs NetBSD et OpenBSD peuvent se foutre sur la gueule collaborer publiquement. Ce qui nous offrira sans doute de superbes coups de hache dans les gencives débats pour les soirées d'un hiver qui vient à grands pas ! :)