Oui, c'est assez juste.
Peut-être pas pour le besoin de dévouement: certaines de ces technologies ne demandent pas beaucoup d'efforts particuliers, le terrain a déjà été déffriché par les autres distros, et il y a aussi du suport commercial derrière Debian (Xandros, Ubuntu, Progeny, DCC, ...), mais je crois que tu a raison en pointant le besoin de collaboration et la difficulté de prendre des décisions collectives comme les causes principales de ce problème.
Car même lorsque la mise en oeuvre de certaines de ces protections est assez simple, elle doit souvent être appliquée à toute l'archive ou aux composants centraux. Elle demande donc une décision collective (pour les mainteneurs gcc/glibc/kernel de Debian, ça représente peut-être plus de travail que la mise en oeuvre technique).
Dommage, j'aurai préféré que, même sur ces questions, le modèle de fonctionnement démocratique soit le plus efficace :(
Pour les chantiers plus lourds (comme l'intégration de politiques RSBAC ou SELinux), il aurait été juste que ceux qui tirent un profit commercial de Debian mettent leur responsabilité en oeuvre. Par exemple que DCC se montre enfin utile, plutot que de faire mal aux mouches !
Si j'ai bien compris, ils l'ont conçu pour que Linux puisse répondre à leurs propres critères d'utilisation de logiciels pour des opérations sensibles, en fonction de contraintes légales qui leurs sont imposées.
Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
Mais de là à dire que SELinux est une régression en termes de sécurité ....
Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.
Maintenant que cette fonctionnalité de protection de la pile fait partie intégrante de GCC (ce qui était réclamée à corps et à cris depuis des années ) on peut penser que toutes les distributions vont faire profiter leurs utilisateurs de ce surcroît appréciable de sécurité.
Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.
Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?
Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").
C'était une blague bien sûr (je ne supposait pas vraiment que la Corée disposait d'un énorme parc sous *BSD).
Je ne sait pas si ces deux phénomènes sont liés, mais au moins on peut dire que la Corée semble vouloir manifester une certaine indépendance par rapport à microsoft, ces derniers temps:
Les adresse lien local (ce sont les adresses IPv6 qui sont construites automatiquement à partir des adresses MAC, si adresse MAC il y a) ne sont pas routable donc ça ne poserai aucun problème d'avoir des adresses MAC en doublons sur des liens différents.
D'autre part il est prévu un mécanisme de génération aléatoire d'adresse lien local (et du coup, de résolution automatique de conflits en cas de doublon sur le même lien, puis qu'on n'a pas la garantie d'unicité qu'offrirait l'utilisation systèmatique des addr MAC). Ceci est nécéssaire puisque certains médias n'ont pas d'adresse MAC (PPP par exemple). Donc même sur un même brin, le doublon ne poserai pas de problème à pour IPv6.
En revanche IPv6, comme IPv4, s'appuie sur les couches de niveau inférieur, et une adresse MAC en doublon risque fort de perturber les équipements à ce niveau (je pense en particulier aux switchs).
Cette quantité est prévue pour ça, en l'occurence (pour que chaque particulier puisse addresser son stylo bille, sa poele à frire, sa brosse à dent ...).
Distribuer les IPv6 au compte goutte aurait pour conséquence un "gaspillage" de ressources énorme et difficile à gérer: les ressources des routeurs (qui par ailleur doivent encaisser un traffic de plus en plus gargantuesque).
Grace à ce mode d'adressage et de distribution des adresses les routeurs n'ont besoin de consulter, et dans le pire des cas, que les 64 premiers bits de chaque trame (voir les 48, voir 32 premiers bits pour les core routeurs).
L'allocation (la redistribution) des 48 premiers bits est organisée de façon très rationnelle et hierarchisée ce qui là encore permet un routage plus rapide et efficace (on aurait pu allouer sur ce modèle avec IPv4, mais il est trop tard pour revenir en arrière, et de toutes façon celà aurait couté une grande part de l'adressage disponible) ; avec des adresses de 128 bits, c'est bien l'inverse (la redistribution au cas par cas / en vrac) qui serait très coùteux, qui serait "une gestion désastreuse" et un gaspillage.
Bref, on peut déja anticiper des problèmes qui se présenteront après un long et massif déploiment d'IPv6: il y en aura bien, il très très improbable que ce soit les mêmes qu'avec IPv4, et il est certain que tenter de résoudre ces problèmes imaginaires agraverai les problèmes réels !
Si j'ai bien suivi votre raisonment "IPv6 ce sera bien quand beaucoup de monde l'utilisera ; mais que les autres comment avant moi. Passez d'abord, je ne veut pas essuyer les platres". Bel esprit !
Le pire c'est que ce raisonement très individualiste et peu citoyen est - à mon avis - le frein majeur au déploiment d'IPv6.
Et que faites vous de notre héritage Unix, l'environement pionnier des résaux TCP/IP ?
Et de notre responsabilités "citoyenne" de geeks unixiens ? S'ils faut que certains commencent, franchement, je crois que ça sera nous (et si possible a l'échelle d'un grand FAI).
IPv6, c'est bien [...] pour les chinois ou les japonais : oui c'est ça l'Europe et les USA squattent la plus grande partie de l'espace IPv4 au détriement de l'Asie et l'Afrique. Alors faisons comme avec l'énergie et le pétrole: il n'y en a pas assez, ça pose problème à tous mais surtout à certains, mais ouf, ce n'est pas nous, alors ne changeont rien, et s'ils ne veulent pas que la planète se réchauffe ou que le désert avance, les Africains n'ont qu'à réduire leur consomation d'énergie.
Malheureusement on ne peut pas dire ça.
En fait le site est plutôt bien placé en matière de standards :
- xhtml 1.0 strict
- mise en page entièrement en css
- fonctionnement en mode strict (vs quirk mode) dans les navigateurs
Bref du point de vue du respects des standards c'est plutot le haut du panier pour ce genre de site.
L'incompatiblité firefox (et opera, et ...) est totalement articicielle en réalitét: au début de la page d'acceuil, juste apres l'ouverture du , il y a ceci:
Mais comme tu le fait remarquer, le fond du problème c'est que de toute façon leur contenu est vérouillé par des DRM dans wma non supportés (à ma connaissances) ailleurs que sous windows.
C 'est une très bonne nouvelle pour le monde des BSD, car jusque là il n'y avait qu'un seul live-cd, FreeSBIE
En fait, pas vraiment: http://sourceforge.net/projects/anonym-os/
C'est un live-cd dédié à la sécurité et l'anonymat (par exemple, il utilise tor pour "anonymiser" le traffic).
Mais quoiqu'il en soit, il reste des choses aussi simple que l'utilisation de scripts.
$ echo -e "echo pouet" > /tmp/tst.sh
$ chmod -x /tmp/tst.sh
$ /bin/sh /tmp/tst.sh
pouet
Bof... ça ne corrige pas la faille pour autant.
Et tant qu'il est possible d'injecter des requetes maison dans les logs du serveur web (même dans le error_log, donc raf de la "redirection vers https") awstats risque de se vautrer lorsqu'on lance l'analyse de ces logs (je ne sait pas si c'est la faille visée par ce vers, mais c'est une faille qui a affecté awstats).
Je t'accorde volontier que l'accès aux services du backoffice / d'administration du serveur (comme la consultation des stats par awstats ou webhint) devrait généralement être authentifiés et par conséquent, accessible seulement par SSL (parceque l'auth web sur plain http ... hum ...), mais c'est une autre question.
Je saisis l'occasion pour manifester mon mécontetement à l'égard de nombreuses applications web ultra populaires qui s'offrent le luxe de vulnérabilités critiques tout les deux ou trois mois. On se croirait revenus à l'époque de wu-ftpd !
C'est choquant de voir autant de failles triviales publiées pour de simples applis web en languages interprétés, lorsque, à l'opposé, les services / applications système écrites en langage casse-gueule sont devenues plutôt robustes (les failles sur ces applis sont de plus en plus rare ou du moins, de plus en plus sophistiquées / subtiles). Voilà qui pourri la sécurité (et la réputation de fiabilité) des serveurs unix, malgré tout les efforts des devs système !
Il faudrait vraiment que les developpeurs d'awstats, squirrelmail et autre phpmyadmin se ressaisissent, ou arrètent les frais.
Et en tout cas, je déconseille aux admins d'installer ces logiciels sur leurs serveurs.
Si Nokia a fait un carton avec son 770 (toutes proportions gardées: il s'agit d'un périphérique très spécialisé, mais je parle du succès parmi les geeks du LL, nous quoi ;), c'est certainement parce qu'ils ont vraiment su jouer le jeu avec la communauté du logiciel libre: plateforme de dev transparente, documentée et libre, grande réutilisation des composants du desktop Linux, environement de dev libre et tournant sous Linux, subvention pour les devs libres, rabais sur les ventes aux developpeurs, contributions intégrées upstream, nouveaux developpements libres subventionés, bugtracker public et ouvert ....
À l'opposé il y a la vague récente de smartphones japonais sous Linux, dont on parle peu (bien qu'elle représente une part très importante du marché des smartphones), et pour cause: tout est vérouillé et seule l'API Java est exposée aux developpeurs. Même problématique pour de nombreux autres périphériques sous Linux sur lesquels il est presque impossible de hacker (donc le fait qu'ils utilisent Linux ne nous avance pas trop): freebox/livebox, kiss player, ...
Et sur un plan intermédiaire il y a les périphériques pour lesquels les developpements communautaires sont ralentis par le manque de coopération du fabriquant (par ex. les AP Linksys, et même les Zaurus: la plupart des Zaurus ne sont toujours pas pleinement supportés par le noyau 2.6, faute de doc sur le matériel et d'un quelconque support de Sharp).
Donc le succès (ou au moins, l'intéret pour nous) de cette plateforme ne dépend pas seulement des logiciels qu'ils utilisent (Linux, GTK, ...) mais aussi de l'attitude et des choix de PalmSource envers les barbus du LL.
- Fourniront-ils un environement de developpement fonctionnant sous Linux ? Je pense par exemple à l'émulateur (sans lequel le cycle de dev est beaucoup plus lent) ? Pour l'environement de compilation j'ai confiance, s'ils ne fournissent pas le gcc & les headers qui vont bien, d'autre le feront.
- L'utilisation de leur enviornement de dev sera-t-elle suffisament documentée et transparente pour le hobbyste (celui qui ne paiera pas de licence pour avoir accès aux docs) ? La présence de leur framework propriétaire MAX n'aura elle pas pour conséquence d'opacifier le fonctionnement de l'appareil ? Et les specs des matériels ? (eg si on veut mettre à jour le noyau ...).
- Nous laisseront-ils des moyens aisés pour distribuer des applications (comme l'utilisation de packages & archives au format debian pour le N770) ou laisseront-ils le controle de ces choses aux opérateurs ? Je dev des applis python sur nokia series60 (symbian OS) et j'ai remarqué que la difficulté de distribuer (installer, updater, ...) ces applis est vraiment trop rédibitoire pour être utilisée par d'autres que les developpeurs. Idem pour l'intégration des contributions (améliorations ou corrections de bugs) sur le framework.
- Ils disent utiliser GTK. C'est très vague: GTK sur X11 ? framebuffer ? avec Cairo ? comment comptent-ils faciliter le portage d'applications économes en ressources et adapté aux smartphones ? (compatiblité Maemo ? environement GPE ?). J'ai l'impression que tout le PIM sera du coté du framework propriétaire de Palm, MAX ; le risque c'est que le reste des applications portées sur l'appareil soient les applis propriétaires pour telephones habituelles, en java + les applis compat palm/m68k, et qu'on ai seulement la possibilité d'avoir des applications GTK trop lourdes et inadaptées (du coup, peut nombreuses ou peu utilisées) faute d'un framework adéquat (eg. un gnumeric ou un totem non modifés sur les petites ressources d'un telephone seraint hais par les utilisateurs ! il ne s'agit pas seulement de l'économie en mémoire & cpu: penser aussi à l'adaptation aux petits écrans, aux méthodes de saisie ...).
- Avec un peu de chance, celà amenera de belles améliorations à Gstreamer: Si PalmSource veut être compétitif sur le plan voip et du multimédia, il leur faudra améliorer le support des technos liés à la VoIP ou au GSM, à la lecture de divers médias protégés par DRM, etc... ?
Ça serait une excellente nouvelle pour le desktop unix en général, car Gstreamer est maintenant une techno fd.o plutôt que purement gnome (par ex. les applis KDE tendent à abandonner aRts, les applis gnome ESD, pour un backend basé sur Gstreamer: les poids lourds tels que AmaroK et Totem l'utilisent).
En un mot, nous n'en somme plus à l'époque où on avait a se réjouir de la seule utilisation de Linux sur une nouvelle plateforme: nous pouvons être plus exigeants, et demander des comptes aux fabriquants sur l'ouverture de leurs appareils, de leur environement logiciel et de developpement !
Après réflexion, je me demande même si, finallement, l'annonce «Sun livre ses designs sous GPL » a plus de portée effective (!= médiatique) que « Sun montre les specs détaillées de ses nouvelles CPU ».
En effet:
- Si dans ce contexte la GPL n'est pas contraingnante sur le matériel produit (distribuer un processeur basé sur un design libre ce n'est pas ditribuer un binaire, le fameux « in either source or binary form » de la GPL), les autres constructeurs ne seront pas contraints de livrer les « sources » de leurs processeurs basés sur le design de Sun. De fait Sun aurait aussi bien pu licencer ses docs sous BSD, CDDL, MIT ou Choucroute Folle, ça n'aurait pas changé grand chose en pratique (sinon l'effet médiatique).
- Si Sun dispose de brevets pour protéger ses innovations matérielles, ils peuvent cependant empécher totalement la fabrication/vente de processeurs inspirés de leurs designs.
Donc en l'attente de précisions sur ces points (type: « Sun ouvre son portefolio de brevets » et « Ils utilisent une version modifiée de la GPL imposant la redistribution des schémas si distributions de procs » ) on sait seulement que les specs du processeur Niagara T1 sont dispos. Point barre. Le reste est exrapolation (ou j'ai fait une erreur dans mon raisonement).
Vu comme ça, ce n'est peut-être finalement pas un évenement extraordinaire :/
D'autre part -même à s'en tenir au kernel- le fait que le noyau (Linux, xBSD, yBSD ...) puisse tourner sur une architecture donnée ne signifie pas que cette archicteture soit pleinement supportée.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».
> Perdu. C'est du GPL. S'ils veulent pouvoir vendre des CPU avec des bouts en provenance de Sun dedans, il faudra qu'ils les passent sous GPL aussi. Et j'ai comme un doute, la ...
Le design est GPL.
Je crois qu'il set un peu abusif de parler de "Hardware Libre" en fait, parce que je doute que le fait que les schémas soient sous GPL change quoi que ce soit au droit de redistribution du hardware.
Bref, je ne suis pas sur que dans ce cas, Intel ou AMD soient contraints de reverser leurs propres designs.
Quelqu'un à les idées plus clair que nous sur cette question ?
Wow, c'est plutôt bon marché en plus: à peut près le prix d'un serveur x86 1U !
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
> J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
Oui, là le "release early, release often" serait dévastateur !
Mais je pensait "vivante, riche, active et innovante" au sens d'une communauté large et créative, plutot que sur le plan du nombre de projets/releases.
> Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Je ne suis pas certain d'y voir très clair sur ce point.
Est-ce que le fait que le design soit sous GPLv2 empêche les fondeurs (et même, les concepteurs/designers) d'implémenter des fonctionalités de type DRM ?
Je connais super mal le sujet des DRM, mais il me semble (me détromper si je dit une connerie) que:
1- un système de protection robuste ne devant pas reposer sur le secret de l'algorithme (security by obscurity), l'éventuelle protection DRM ne devrait pas être remise en cause par la publication des schémas (~= de l'algo), mais plutot de la clefs privée (par ex intégrée dans le firmware) qui l'utilise.
2- que le design du processeur soit GPL n'impose probablement pas que le contenu du firmware, dont la clef, le soit (ps: Sun a-t-il libéré le OpenBoot ?).
3- la GPLv2, même sur le plan logiciel, n'interdit pas l'implem de DRMs
Pour les GPUs, sans être aussi optimiste que toi, je crois me souvenir que le dev principal du projet Open Graphics peinait à trouver un support financier (d'ailleur ce projet avait été laché par son entreprise) parceque "le matériel libre, ce n'est pas une idée sérieuse". Maintenant que Sun fait des specs libres, son projet pourrait parraitre plus crédible aux yeux des décideux préssés !
> donc Sun ne craint plus que son code soit pris pour renforcer Linux.
Non il est très improbable que ça soit leur motivation, car la remarque de Linus était un pur choix politique (une "police" le noyau mainstream, de kernel.org). Mais il n'y a pas un d'obstacle légal.
Moyennant quoi, si OpenSolaris est relicencé en GPLv3, et que par exemple ZFS ou DTrace intéressent suffisament les developpeurs (+ sont suffisament portables etc.) on verra certainement des projets adaptants ceux-ci à Linux, au moins come modules externes (ce qui de toute façon est assez bien admis et communs dans le monde Linux: p-o-m iptables, (anciennement) fuse, ...: autant de projets respectables mais pas immédiatement acceptés dans le kernel vanilla de Linus).
Même un fork n'est pas exclus: il en existe déjà, comme uclinux par exemple.
D'autre part Linus a mis de l'eau dans son vin en précisant qu'il pourrait y avoir des contributions v3 au noyau (simplement, que le noyau lui-même, dans son ensemble, serait considéré v2).
> En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
La GPLv3 n'empecherai pas Solaris de "renforcer Linux".
Ce qui est certain c'est qu'il ne s'agit pour le moment que de annonce d'une reflexion, meme pas d'un engagement. La GPLv3 n'est pas encore releasée.
Sun a déjà annoncé maintes fois "réfléchir à la libération de java", et on n'a encore rien vu venir.
(en clair: il s'agit peut-être d'une autre trouvaille de Schwartz en matière de marketing ciblé, ne tombons dedans: attendont plus de concret !).
La question est intéressante: ce sera bien la GPLv2 (nécéssairement: la GPLv3 n'est pas encore "releasée"), mais peut-être envisageront-ils de passer en v3 lorsqu'elle sortira ?
Car enfin, il suffit qu'un contributeur au processeur (peut-etre meme Sun l'a déja fait ?) réussisse à faire accepter une modification couverte par un de ses brevets (hardwares, donc valable aussi en Europe) pour que le matériel soit vérouillé au point que plus personne ne puisse implémenter le design librement. C'est un danger très important pour ce genre de projets, et la GPLv3 devrait permettre de le désamorcer (si au final elle impose effectivement au contributeur de céder les droits d'exploitation de ses brevets, c'est dans le cahier des charges).
Sun semble être bien disposé envers la GPLv3, en tout cas suffisament pour (prétendre) envisager de re-licencer OpenSolaris sous double licence (CDDL + GPLv3). Mais il s'agit peut-être d'une promesse en l'air ... cf. le blog de Jonathan Schwartz: http://blogs.sun.com/roller/page/jonathan
> le machines existent : c'est SUN qui les vend pour l'instant
Hmm, je ne suis pas sûr qu'ils vendent déjà des serveurs sous Niagara.
Es-tu certains de cette info ?
> Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Attention, le fait que certains processeurs UltraSparc|Sparc soient supportés ne signifie pas qu'ils le soient tous (en fait certains ne sont pas du tout supportés, au moins par les *BSD, faute d'ouverture des docs de la part de Sun -- c'est d'ailleur pour ça, obtenir cette ouverture, que je gueule un peu).
D'autre part - et à contrario des allégations marketing de J. Schwartz - la mise à disposition des schémas du processeur n'aidera (quasiment) pas le portage sur les serveurs de la vraie vie: encore faut-il que Sun mette à disposition, si possible sans NDA, les spécifications complétes de leurs serveurs: cablage du proc et de la mémoire, cartes scsi/raid etc. Ce qu'ils ont parfois, mais pas toujours, accépté de faire. J'avais déjà parlé de ça dans la précédente dépêche sur le sujet.
En fait l'intéret pratique de cette nouvelle n'est pas tant la portabilité que l'extention du libre au monde du matériel. Effectivement, de nombreux projets existent mais aucun d'une telle ampleur. Quelles seront les conséquences ? aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ? D'autres gros constructeurs emboiteront-ils le pas à Sun ? Quelles conséquences sur les prix des futurs procs ? Sur la qualité ? Quels vont être les modus operandi de ces communautés (cvs/svn + mailing-lists + wiki ... ?) et quels rétro-conséquence sur la communauté du LL ? Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
Cette dépêche n'a pas oublié que Schwartz s'adresse généralement aux developpeurs (car ce sont eux qui décide au bout du compte, dit-il dans l'article lié à la dépêche), moyennant des efforts de communication ciblée (sur nous !) et au prix de petites contre-vérités (paradoxalement, au prix de ne peut-être pas mettre assez en avant ce qu'il y a de réellement révolutionnaire dans la démarche de son entreprise !).
Donc mention spéciale à patrick_g qui nous a fait une excellente dépêche, distinguant le bon grain (l'extraordinaire potentiel d'un tel matériel libre) de l'ivraie (le marketing de Sun concernant sa position sur les LL, la GPL, la portabilité etc.). Un vrai boulot de journaliste ;) comparé à la précédente dépêche sur ce sujet. J'adorerai que toutes les dépêches relatant les coups de campagnes ciblées vers la communauté des LL émanant des gros industriels (Sun, IBM et Apple en particulier) soient rédigées avec autant de prudence.
Il reste juste un détail mineur qui m'interroge (enfin, peut-être que j'ai mal compris l'annonce de Sun): la dépêche semble indiquer que Sun compte libérer les designs de tout ses processeurs UltraSPARC (en précisant que le T1 était juste "les première spécification disponible ". Mais pour le moment je n'ai trouvé que des indications contraires, par exemple dans la FAQ du projet OpenSPARC : "OpenSPARC project is making the hardware source code of the recently announced UltraSPARC T1 processor available under an Open Source license. ".
J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ? Ou est-ce une mauvaise transcription des journalistes ?
Une dernière question: on-t-ils annoncé qu'ils donnaient gracieusement une licence d'utilisation de leurs (éventuels, mais probables) brevets concernants ce matériel à tous, sans discrimination, et royalty free ? Parceque la "gplisation" du design d'un proc vérouillé par des brevets serait complétement inutile. Bref, qu'en est-il de la question des brevets _matériels_ sur l'US ?
Pour un complément d'informations en français et de bonne qualité sur IPv6 en général et la mobilité en particulier, le fameux O'Reilly « IPv6, Théorie et Pratique » de Gisèle Cizault (nom d'écrivain pour un collectif de spécialistes) est maintenant en cours de « wikification », gracieusement et publiquement accessible sur http://livre.point6.net/index.php/Accueil
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par herodiade . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 2.
Peut-être pas pour le besoin de dévouement: certaines de ces technologies ne demandent pas beaucoup d'efforts particuliers, le terrain a déjà été déffriché par les autres distros, et il y a aussi du suport commercial derrière Debian (Xandros, Ubuntu, Progeny, DCC, ...), mais je crois que tu a raison en pointant le besoin de collaboration et la difficulté de prendre des décisions collectives comme les causes principales de ce problème.
Car même lorsque la mise en oeuvre de certaines de ces protections est assez simple, elle doit souvent être appliquée à toute l'archive ou aux composants centraux. Elle demande donc une décision collective (pour les mainteneurs gcc/glibc/kernel de Debian, ça représente peut-être plus de travail que la mise en oeuvre technique).
Dommage, j'aurai préféré que, même sur ces questions, le modèle de fonctionnement démocratique soit le plus efficace :(
Pour les chantiers plus lourds (comme l'intégration de politiques RSBAC ou SELinux), il aurait été juste que ceux qui tirent un profit commercial de Debian mettent leur responsabilité en oeuvre. Par exemple que DCC se montre enfin utile, plutot que de faire mal aux mouches !
[^] # Re: Protection de la pile par défaut sur les prochaines releases des dis
Posté par herodiade . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 3.
Bref, ils sont problablement les utilisateurs qui ont le plus besoin de cette technologie ; il est donc improbable qu'ils aient pris le risque de laisser des trous connus - même cachés. De même qu'ils n'ont surement pas choisi Rijndael pour devenir AES en fonction d'une quelquonque fragilité de l'algorithme, vu qu'ils seront contraints de l'utiliser quotidiennement.
Celà étant dit il faut reconnaitre que les contraintes de la NSA sont assez tortueuse, et (en conséquence ?) SELinux un poil byzantin.
Je suis d'accord avec Sytoka Modon (commentaire ci-dessus) pour privilégier RSBAC lorsque l'administration étasunienne n'est pas votre cible: le code est moins volumineux (potentiellement moins de bugs), le système est beaucoup plus facile à mettre en oeuvre (potentiellement moins d'erreurs d'admin) et surtout, certains composants de SELinux sont affectés par de sombres histoires de brevets logiciels qui font froid dans le dos.
Mais de là à dire que SELinux est une régression en termes de sécurité ....
Quoiqu'il en soit, ces systèmes sont peut-être contraignants et difficiles à mettre en oeuvre dans une distro (mais certaines l'ont fait ...) mais ça n'est pas le cas des options de renforcement à la compilation, comme fstack-protector et fortify ainsi que de certains patches du noyau ! C'est maintenant une responsabilité des mainteneurs de distribution, de contraindre un minimum de protections en les activants pour les binaires qu'ils produisent.
Quand on apprend qu'une majorité (je n'ai plus les chiffres en têtes, peut-être 70%) des failles critiques indéxées par le CERT sont des buffers overflow, précisément, ce que protègent ces outils simples et non intrusifs (dont la mise en oeuvre n'est pas lourde mais doit être faite par ceux qui packagent), on peut trouver irresponsable, pour des mainteneurs de distribution, de les ignorer.
# Protection de la pile par défaut sur les prochaines releases des distros
Posté par herodiade . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
Ça serait formidable !
À ce jour, je n'ai pas eu d'autres echos que de la position de Fedora Core, dont un développeur expliquait sur une mailing-list que les packages sont désormais compilés avec cette option activée (la FC 5 sera donc releasée avec cette protection). Et évidement DragonflyBSD et OpenBSD qui utilisent son équivalent pour gcc3 depuis une paye.
Qu'en est-il des autres distributions ? quelles sont celles qui ont annoncé leur position par rapport à cette option (qu'ils aient décidé de la supporter ou non) ?
Qu'en pensent Debian, Ubuntu, OpenSuse et Mandriva ?
Je suis particulièrement inquiet pour Debian, qui a longtemps tenu le haut du pavé en matière de sécurité, du fait de la très haute exigeance qualité de son équipe de developpeurs. Mais qui semble ne plus tenir le rythme, par exemple par rapport à Fedora (qui intègre maintenant par défaut SELinux , Exec-Shield, fstack-protector , FORTIFY_SOURCE...).
Un grand nombre de ces protections (option /Gs de vc++, ACL ntfs, ...) sont même désormais intégrées dans les dernières releases de windows, cependant que (selon un sondage mené par debian-administration.org) les developpeurs Debian considèrent la sécurisation comme relativement secondaire (et je ne parle pas des couacs comme l'absence de maj sécu de juillet dernier, le temps de réponse aux problèmes de firefox en aout etc. !).
Quel dommage s'il fallait se priver de la qualité et stabilité légendaires de Debian (sur ce plan, Debian ne fléchit pas !) pour avoir un environement sécurisé par défaut, lors de la prochaine release (et non, recompiler toute l'archive avec -fstack-protector, créer les polices SELinux pour les daemons courants et le système de base etc. n'est pas une solution triviale. Et oui, ces protections sont devenues nécéssaire, parceque les pirates ont, eux aussi, progréssé. D'où le besoin du secure "by default").
[^] # Re: Régréssion
Posté par herodiade . En réponse à la dépêche La Corée du Sud veut créer "une ville Linux". Évalué à 3.
Je ne sait pas si ces deux phénomènes sont liés, mais au moins on peut dire que la Corée semble vouloir manifester une certaine indépendance par rapport à microsoft, ces derniers temps:
Aujourd'hui sur slashdot (http://yro.slashdot.org/yro/06/02/25/0833236.shtml ):
" Microsoft Faces Korean Deadline" (Microsoft subis un ultimatum de la Corée)
[^] # Re: Re:
Posté par herodiade . En réponse au journal Plus de 10.000 Freenautes prêts à payer 1 euro par mois pour l'IPv6. Évalué à 10.
# Régréssion
Posté par herodiade . En réponse à la dépêche La Corée du Sud veut créer "une ville Linux". Évalué à 1.
[^] # Re: Re:
Posté par herodiade . En réponse au journal Plus de 10.000 Freenautes prêts à payer 1 euro par mois pour l'IPv6. Évalué à 3.
D'autre part il est prévu un mécanisme de génération aléatoire d'adresse lien local (et du coup, de résolution automatique de conflits en cas de doublon sur le même lien, puis qu'on n'a pas la garantie d'unicité qu'offrirait l'utilisation systèmatique des addr MAC). Ceci est nécéssaire puisque certains médias n'ont pas d'adresse MAC (PPP par exemple). Donc même sur un même brin, le doublon ne poserai pas de problème à pour IPv6.
En revanche IPv6, comme IPv4, s'appuie sur les couches de niveau inférieur, et une adresse MAC en doublon risque fort de perturber les équipements à ce niveau (je pense en particulier aux switchs).
[^] # Re: Re:
Posté par herodiade . En réponse au journal Plus de 10.000 Freenautes prêts à payer 1 euro par mois pour l'IPv6. Évalué à 10.
Distribuer les IPv6 au compte goutte aurait pour conséquence un "gaspillage" de ressources énorme et difficile à gérer: les ressources des routeurs (qui par ailleur doivent encaisser un traffic de plus en plus gargantuesque).
Grace à ce mode d'adressage et de distribution des adresses les routeurs n'ont besoin de consulter, et dans le pire des cas, que les 64 premiers bits de chaque trame (voir les 48, voir 32 premiers bits pour les core routeurs).
L'allocation (la redistribution) des 48 premiers bits est organisée de façon très rationnelle et hierarchisée ce qui là encore permet un routage plus rapide et efficace (on aurait pu allouer sur ce modèle avec IPv4, mais il est trop tard pour revenir en arrière, et de toutes façon celà aurait couté une grande part de l'adressage disponible) ; avec des adresses de 128 bits, c'est bien l'inverse (la redistribution au cas par cas / en vrac) qui serait très coùteux, qui serait "une gestion désastreuse" et un gaspillage.
Bref, on peut déja anticiper des problèmes qui se présenteront après un long et massif déploiment d'IPv6: il y en aura bien, il très très improbable que ce soit les mêmes qu'avec IPv4, et il est certain que tenter de résoudre ces problèmes imaginaires agraverai les problèmes réels !
[^] # Re: Re:
Posté par herodiade . En réponse au journal Plus de 10.000 Freenautes prêts à payer 1 euro par mois pour l'IPv6. Évalué à 10.
Le pire c'est que ce raisonement très individualiste et peu citoyen est - à mon avis - le frein majeur au déploiment d'IPv6.
Et que faites vous de notre héritage Unix, l'environement pionnier des résaux TCP/IP ?
Et de notre responsabilités "citoyenne" de geeks unixiens ? S'ils faut que certains commencent, franchement, je crois que ça sera nous (et si possible a l'échelle d'un grand FAI).
IPv6, c'est bien [...] pour les chinois ou les japonais : oui c'est ça l'Europe et les USA squattent la plus grande partie de l'espace IPv4 au détriement de l'Asie et l'Afrique. Alors faisons comme avec l'énergie et le pétrole: il n'y en a pas assez, ça pose problème à tous mais surtout à certains, mais ouf, ce n'est pas nous, alors ne changeont rien, et s'ils ne veulent pas que la planète se réchauffe ou que le désert avance, les Africains n'ont qu'à réduire leur consomation d'énergie.
# standards du web
Posté par herodiade . En réponse au journal Arte et DRM : pareil que les autres. Évalué à 5.
En fait le site est plutôt bien placé en matière de standards :
- xhtml 1.0 strict
- mise en page entièrement en css
- fonctionnement en mode strict (vs quirk mode) dans les navigateurs
Bref du point de vue du respects des standards c'est plutot le haut du panier pour ce genre de site.
L'incompatiblité firefox (et opera, et ...) est totalement articicielle en réalitét: au début de la page d'acceuil, juste apres l'ouverture du , il y a ceci:
Mais comme tu le fait remarquer, le fond du problème c'est que de toute façon leur contenu est vérouillé par des DRM dans wma non supportés (à ma connaissances) ailleurs que sous windows.
[^] # Re: standards
Posté par herodiade . En réponse au journal artevod. Évalué à 1.
# standards
Posté par herodiade . En réponse au journal artevod. Évalué à 1.
Heureusement qu'on s'est bien batu pour le respect des standards au bénéfice de l'interopérabilité, non ?
C'est doublement décevant venant d'une chaine de cette qualité et surtout, publique !
Nos redevances dans les poches de cette webagency ...
# standards
Posté par herodiade . En réponse au journal artevod. Évalué à 7.
Heureusement qu'on s'est bien batu pour le respect des standards au bénéfice de l'interopérabilité, non ?
C'est doublement décevant venant d'une chaine de cette qualité et surtout, publique !
Nos redevances dans les poches de cette webagency ...
# Un autre récent live-cd avec OpenBSD: Anonym.OS
Posté par herodiade . En réponse à la dépêche Un live-cd pour OpenBSD : OliveBSD. Évalué à 10.
En fait, pas vraiment: http://sourceforge.net/projects/anonym-os/
C'est un live-cd dédié à la sécurité et l'anonymat (par exemple, il utilise tor pour "anonymiser" le traffic).
Mais ça reste une bonne nouvelle quand même ! ;)
[^] # Re: Strange !
Posté par herodiade . En réponse à la dépêche Un petit ver pour Linux. Évalué à 3.
Exemple:
$ cat <> tst.c
#include <stdio.h>
int main(void) { printf("pouet\n"); return(0); }
EOF
$ gcc tst.c -o /tmp/tst
$ chmod -x /tmp/tst
$ /lib/ld-linux.so.2 /tmp/tst
pouet
$ gcc -static tst.c -o /tmp/tst
$ /lib/ld-linux.so.2 /tmp/tst
Segmentation fault (core dumped)
Mais quoiqu'il en soit, il reste des choses aussi simple que l'utilisation de scripts.
$ echo -e "echo pouet" > /tmp/tst.sh
$ chmod -x /tmp/tst.sh
$ /bin/sh /tmp/tst.sh
pouet
[^] # Re: Petite solution
Posté par herodiade . En réponse à la dépêche Un petit ver pour Linux. Évalué à 5.
Et tant qu'il est possible d'injecter des requetes maison dans les logs du serveur web (même dans le error_log, donc raf de la "redirection vers https") awstats risque de se vautrer lorsqu'on lance l'analyse de ces logs (je ne sait pas si c'est la faille visée par ce vers, mais c'est une faille qui a affecté awstats).
Je t'accorde volontier que l'accès aux services du backoffice / d'administration du serveur (comme la consultation des stats par awstats ou webhint) devrait généralement être authentifiés et par conséquent, accessible seulement par SSL (parceque l'auth web sur plain http ... hum ...), mais c'est une autre question.
Je saisis l'occasion pour manifester mon mécontetement à l'égard de nombreuses applications web ultra populaires qui s'offrent le luxe de vulnérabilités critiques tout les deux ou trois mois. On se croirait revenus à l'époque de wu-ftpd !
C'est choquant de voir autant de failles triviales publiées pour de simples applis web en languages interprétés, lorsque, à l'opposé, les services / applications système écrites en langage casse-gueule sont devenues plutôt robustes (les failles sur ces applis sont de plus en plus rare ou du moins, de plus en plus sophistiquées / subtiles). Voilà qui pourri la sécurité (et la réputation de fiabilité) des serveurs unix, malgré tout les efforts des devs système !
Il faudrait vraiment que les developpeurs d'awstats, squirrelmail et autre phpmyadmin se ressaisissent, ou arrètent les frais.
Et en tout cas, je déconseille aux admins d'installer ces logiciels sur leurs serveurs.
</coup de gueule>
# La plateforme sera-t-elle vraiment geek friendly ?
Posté par herodiade . En réponse à la dépêche Les plans de Palm concernant Linux. Évalué à 10.
À l'opposé il y a la vague récente de smartphones japonais sous Linux, dont on parle peu (bien qu'elle représente une part très importante du marché des smartphones), et pour cause: tout est vérouillé et seule l'API Java est exposée aux developpeurs. Même problématique pour de nombreux autres périphériques sous Linux sur lesquels il est presque impossible de hacker (donc le fait qu'ils utilisent Linux ne nous avance pas trop): freebox/livebox, kiss player, ...
Et sur un plan intermédiaire il y a les périphériques pour lesquels les developpements communautaires sont ralentis par le manque de coopération du fabriquant (par ex. les AP Linksys, et même les Zaurus: la plupart des Zaurus ne sont toujours pas pleinement supportés par le noyau 2.6, faute de doc sur le matériel et d'un quelconque support de Sharp).
Sur ce sujet, voir ce récent article « Linux-based Motorola cell phones frustrate third-party developers » :
http://mobile.newsforge.com/article.pl?sid=06/02/01/1655248&(...)
Donc le succès (ou au moins, l'intéret pour nous) de cette plateforme ne dépend pas seulement des logiciels qu'ils utilisent (Linux, GTK, ...) mais aussi de l'attitude et des choix de PalmSource envers les barbus du LL.
- Fourniront-ils un environement de developpement fonctionnant sous Linux ? Je pense par exemple à l'émulateur (sans lequel le cycle de dev est beaucoup plus lent) ? Pour l'environement de compilation j'ai confiance, s'ils ne fournissent pas le gcc & les headers qui vont bien, d'autre le feront.
- L'utilisation de leur enviornement de dev sera-t-elle suffisament documentée et transparente pour le hobbyste (celui qui ne paiera pas de licence pour avoir accès aux docs) ? La présence de leur framework propriétaire MAX n'aura elle pas pour conséquence d'opacifier le fonctionnement de l'appareil ? Et les specs des matériels ? (eg si on veut mettre à jour le noyau ...).
- Nous laisseront-ils des moyens aisés pour distribuer des applications (comme l'utilisation de packages & archives au format debian pour le N770) ou laisseront-ils le controle de ces choses aux opérateurs ? Je dev des applis python sur nokia series60 (symbian OS) et j'ai remarqué que la difficulté de distribuer (installer, updater, ...) ces applis est vraiment trop rédibitoire pour être utilisée par d'autres que les developpeurs. Idem pour l'intégration des contributions (améliorations ou corrections de bugs) sur le framework.
- Ils disent utiliser GTK. C'est très vague: GTK sur X11 ? framebuffer ? avec Cairo ? comment comptent-ils faciliter le portage d'applications économes en ressources et adapté aux smartphones ? (compatiblité Maemo ? environement GPE ?). J'ai l'impression que tout le PIM sera du coté du framework propriétaire de Palm, MAX ; le risque c'est que le reste des applications portées sur l'appareil soient les applis propriétaires pour telephones habituelles, en java + les applis compat palm/m68k, et qu'on ai seulement la possibilité d'avoir des applications GTK trop lourdes et inadaptées (du coup, peut nombreuses ou peu utilisées) faute d'un framework adéquat (eg. un gnumeric ou un totem non modifés sur les petites ressources d'un telephone seraint hais par les utilisateurs ! il ne s'agit pas seulement de l'économie en mémoire & cpu: penser aussi à l'adaptation aux petits écrans, aux méthodes de saisie ...).
- Avec un peu de chance, celà amenera de belles améliorations à Gstreamer: Si PalmSource veut être compétitif sur le plan voip et du multimédia, il leur faudra améliorer le support des technos liés à la VoIP ou au GSM, à la lecture de divers médias protégés par DRM, etc... ?
Ça serait une excellente nouvelle pour le desktop unix en général, car Gstreamer est maintenant une techno fd.o plutôt que purement gnome (par ex. les applis KDE tendent à abandonner aRts, les applis gnome ESD, pour un backend basé sur Gstreamer: les poids lourds tels que AmaroK et Totem l'utilisent).
En un mot, nous n'en somme plus à l'époque où on avait a se réjouir de la seule utilisation de Linux sur une nouvelle plateforme: nous pouvons être plus exigeants, et demander des comptes aux fabriquants sur l'ouverture de leurs appareils, de leur environement logiciel et de developpement !
[^] # Re: C'est bien mais
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 7.
En effet:
- Si dans ce contexte la GPL n'est pas contraingnante sur le matériel produit (distribuer un processeur basé sur un design libre ce n'est pas ditribuer un binaire, le fameux « in either source or binary form » de la GPL), les autres constructeurs ne seront pas contraints de livrer les « sources » de leurs processeurs basés sur le design de Sun. De fait Sun aurait aussi bien pu licencer ses docs sous BSD, CDDL, MIT ou Choucroute Folle, ça n'aurait pas changé grand chose en pratique (sinon l'effet médiatique).
- Si Sun dispose de brevets pour protéger ses innovations matérielles, ils peuvent cependant empécher totalement la fabrication/vente de processeurs inspirés de leurs designs.
Donc en l'attente de précisions sur ces points (type: « Sun ouvre son portefolio de brevets » et « Ils utilisent une version modifiée de la GPL imposant la redistribution des schémas si distributions de procs » ) on sait seulement que les specs du processeur Niagara T1 sont dispos. Point barre. Le reste est exrapolation (ou j'ai fait une erreur dans mon raisonement).
Vu comme ça, ce n'est peut-être finalement pas un évenement extraordinaire :/
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 5.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».
[^] # Re: C'est bien mais
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 5.
Le design est GPL.
Je crois qu'il set un peu abusif de parler de "Hardware Libre" en fait, parce que je doute que le fait que les schémas soient sous GPL change quoi que ce soit au droit de redistribution du hardware.
Bref, je ne suis pas sur que dans ce cas, Intel ou AMD soient contraints de reverser leurs propres designs.
Quelqu'un à les idées plus clair que nous sur cette question ?
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
> http://www.sun.com/servers/coolthreads/t2000/
Wow, c'est plutôt bon marché en plus: à peut près le prix d'un serveur x86 1U !
>> aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ?
> J'y crois pas trop car le hard reste un domaine matériel et donc il faut obligatoirement passer par le cycle très long de la conception/fabrication...rien a voir avec une chtite compilation de 15 mn !
Oui, là le "release early, release often" serait dévastateur !
Mais je pensait "vivante, riche, active et innovante" au sens d'une communauté large et créative, plutot que sur le plan du nombre de projets/releases.
> Pas tant qu'il pourront l'éviter et d'autant moins qu'ils voudront implanter des fonctions Trusted computing/DRM...etc.
Je ne suis pas certain d'y voir très clair sur ce point.
Est-ce que le fait que le design soit sous GPLv2 empêche les fondeurs (et même, les concepteurs/designers) d'implémenter des fonctionalités de type DRM ?
Je connais super mal le sujet des DRM, mais il me semble (me détromper si je dit une connerie) que:
1- un système de protection robuste ne devant pas reposer sur le secret de l'algorithme (security by obscurity), l'éventuelle protection DRM ne devrait pas être remise en cause par la publication des schémas (~= de l'algo), mais plutot de la clefs privée (par ex intégrée dans le firmware) qui l'utilise.
2- que le design du processeur soit GPL n'impose probablement pas que le contenu du firmware, dont la clef, le soit (ps: Sun a-t-il libéré le OpenBoot ?).
3- la GPLv2, même sur le plan logiciel, n'interdit pas l'implem de DRMs
Et puis Sun n'a pas l'air si farouchement anti DRM que ça ... : http://blogs.sun.com/roller/page/jonathan/20050826
Pour les GPUs, sans être aussi optimiste que toi, je crois me souvenir que le dev principal du projet Open Graphics peinait à trouver un support financier (d'ailleur ce projet avait été laché par son entreprise) parceque "le matériel libre, ce n'est pas une idée sérieuse". Maintenant que Sun fait des specs libres, son projet pourrait parraitre plus crédible aux yeux des décideux préssés !
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 4.
Non il est très improbable que ça soit leur motivation, car la remarque de Linus était un pur choix politique (une "police" le noyau mainstream, de kernel.org). Mais il n'y a pas un d'obstacle légal.
Moyennant quoi, si OpenSolaris est relicencé en GPLv3, et que par exemple ZFS ou DTrace intéressent suffisament les developpeurs (+ sont suffisament portables etc.) on verra certainement des projets adaptants ceux-ci à Linux, au moins come modules externes (ce qui de toute façon est assez bien admis et communs dans le monde Linux: p-o-m iptables, (anciennement) fuse, ...: autant de projets respectables mais pas immédiatement acceptés dans le kernel vanilla de Linus).
Même un fork n'est pas exclus: il en existe déjà, comme uclinux par exemple.
D'autre part Linus a mis de l'eau dans son vin en précisant qu'il pourrait y avoir des contributions v3 au noyau (simplement, que le noyau lui-même, dans son ensemble, serait considéré v2).
> En effet, si la licence choisie est CDDL+GPLv3, alors ce n'est pas compatible avec Linux qui est GPLv2.
Apparement Stallman tient à faire en sorte que la v3 finale soit compatible avec la v2.
http://gplv3.fsf.org/rationale#SECTION00380000000000000000
> Bref, moi plus comprendre la! :?
La GPLv3 n'empecherai pas Solaris de "renforcer Linux".
Ce qui est certain c'est qu'il ne s'agit pour le moment que de annonce d'une reflexion, meme pas d'un engagement. La GPLv3 n'est pas encore releasée.
Sun a déjà annoncé maintes fois "réfléchir à la libération de java", et on n'a encore rien vu venir.
(en clair: il s'agit peut-être d'une autre trouvaille de Schwartz en matière de marketing ciblé, ne tombons dedans: attendont plus de concret !).
[^] # Re: Les UltraSparc sous quelle GPL?
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 2.
Car enfin, il suffit qu'un contributeur au processeur (peut-etre meme Sun l'a déja fait ?) réussisse à faire accepter une modification couverte par un de ses brevets (hardwares, donc valable aussi en Europe) pour que le matériel soit vérouillé au point que plus personne ne puisse implémenter le design librement. C'est un danger très important pour ce genre de projets, et la GPLv3 devrait permettre de le désamorcer (si au final elle impose effectivement au contributeur de céder les droits d'exploitation de ses brevets, c'est dans le cahier des charges).
Sun semble être bien disposé envers la GPLv3, en tout cas suffisament pour (prétendre) envisager de re-licencer OpenSolaris sous double licence (CDDL + GPLv3). Mais il s'agit peut-être d'une promesse en l'air ... cf. le blog de Jonathan Schwartz: http://blogs.sun.com/roller/page/jonathan
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 10.
Hmm, je ne suis pas sûr qu'ils vendent déjà des serveurs sous Niagara.
Es-tu certains de cette info ?
> Quand aux distribs elles existent aussi ! (Debian Sarge est compatible Sparc...gentoo aussi je crois). Pareil pour NetBSD et OpenBSD.
Attention, le fait que certains processeurs UltraSparc|Sparc soient supportés ne signifie pas qu'ils le soient tous (en fait certains ne sont pas du tout supportés, au moins par les *BSD, faute d'ouverture des docs de la part de Sun -- c'est d'ailleur pour ça, obtenir cette ouverture, que je gueule un peu).
D'autre part - et à contrario des allégations marketing de J. Schwartz - la mise à disposition des schémas du processeur n'aidera (quasiment) pas le portage sur les serveurs de la vraie vie: encore faut-il que Sun mette à disposition, si possible sans NDA, les spécifications complétes de leurs serveurs: cablage du proc et de la mémoire, cartes scsi/raid etc. Ce qu'ils ont parfois, mais pas toujours, accépté de faire. J'avais déjà parlé de ça dans la précédente dépêche sur le sujet.
En fait l'intéret pratique de cette nouvelle n'est pas tant la portabilité que l'extention du libre au monde du matériel. Effectivement, de nombreux projets existent mais aucun d'une telle ampleur. Quelles seront les conséquences ? aura-t-on un jour une communauté du HL (hardware libre ;) vivante, riche, active et innovante comme la communauté du LL actuelle ? D'autres gros constructeurs emboiteront-ils le pas à Sun ? Quelles conséquences sur les prix des futurs procs ? Sur la qualité ? Quels vont être les modus operandi de ces communautés (cvs/svn + mailing-lists + wiki ... ?) et quels rétro-conséquence sur la communauté du LL ? Verra-t-on cette démarche reprise par des constructeurs sur d'autre types de matériels ? Les projets type Open Graphics y trouveront-ils le crédit / gage de sérieux nécéssaire à la levée de subvention ? ...
Cette dépêche n'a pas oublié que Schwartz s'adresse généralement aux developpeurs (car ce sont eux qui décide au bout du compte, dit-il dans l'article lié à la dépêche), moyennant des efforts de communication ciblée (sur nous !) et au prix de petites contre-vérités (paradoxalement, au prix de ne peut-être pas mettre assez en avant ce qu'il y a de réellement révolutionnaire dans la démarche de son entreprise !).
Donc mention spéciale à patrick_g qui nous a fait une excellente dépêche, distinguant le bon grain (l'extraordinaire potentiel d'un tel matériel libre) de l'ivraie (le marketing de Sun concernant sa position sur les LL, la GPL, la portabilité etc.). Un vrai boulot de journaliste ;) comparé à la précédente dépêche sur ce sujet. J'adorerai que toutes les dépêches relatant les coups de campagnes ciblées vers la communauté des LL émanant des gros industriels (Sun, IBM et Apple en particulier) soient rédigées avec autant de prudence.
Il reste juste un détail mineur qui m'interroge (enfin, peut-être que j'ai mal compris l'annonce de Sun): la dépêche semble indiquer que Sun compte libérer les designs de tout ses processeurs UltraSPARC (en précisant que le T1 était juste "les première spécification disponible ". Mais pour le moment je n'ai trouvé que des indications contraires, par exemple dans la FAQ du projet OpenSPARC : "OpenSPARC project is making the hardware source code of the recently announced UltraSPARC T1 processor available under an Open Source license. ".
J'ai l'impression que les communiquants de Sun entretiennent la confusion en parlant à l'occasion d'UltraSPARC (la famille de processeurs) de façon générique là où ils devraient préciser "UtraSPARC T1". Ou je me trompe et l'ensemble des designs UltraSPARC seront effectivement libérés ? Ou est-ce une mauvaise transcription des journalistes ?
Une dernière question: on-t-ils annoncé qu'ils donnaient gracieusement une licence d'utilisation de leurs (éventuels, mais probables) brevets concernants ce matériel à tous, sans discrimination, et royalty free ? Parceque la "gplisation" du design d'un proc vérouillé par des brevets serait complétement inutile. Bref, qu'en est-il de la question des brevets _matériels_ sur l'US ?
# Fin de KAME
Posté par herodiade . En réponse à la dépêche Sortie de MIPL Mobile IPv6 2.0. Évalué à 5.
Les ressources du projet seront réallouées notament pour travailler sur la mobilité.
cf. http://www.kame.net/newsletter/20051107/ et http://www.wide.ad.jp/news/press/20051107-KAME-e.html
Pour un complément d'informations en français et de bonne qualité sur IPv6 en général et la mobilité en particulier, le fameux O'Reilly « IPv6, Théorie et Pratique » de Gisèle Cizault (nom d'écrivain pour un collectif de spécialistes) est maintenant en cours de « wikification », gracieusement et publiquement accessible sur http://livre.point6.net/index.php/Accueil