IsNotGood a écrit 5009 commentaires

> non, ce n'est pas vraiment ce qui a été dit dans l'article :

D'accord.

> Mais l'article précise que plusieurs sources ont affirmées que des employés de HP travaillaient sur un système Linux :

Et cette partie est hypra floue.
On peut avoir :
- reprise d'Ubuntu ou Fedora ou Mandriva ou ... avec quelques add-on et finement paramétré (par exemple un "spin" Fedora que presque le premier venu peut réaliser).
- réalisation d'une distribution spécifique avec tout ce que ça implique (infrastructure, développement, support).

L'écart est énorme entre les deux. On peut aussi imaginer un concurrent à eeepc.
Que va-t-il réellement sortir de ses "fuites" ?
Bien malin celui qui le saura.
Mais :
- Dell ne fait que proposer une Ubuntu
- Lenovo ne propose plus de Linux sur ces portables
- Les distributions desktop ne font pas de pognon
- L'année 2008 est comme les dix précédentes, l'année du desktop Linux...

Et si finalement ces "fuites" n'étaient qu'un moyen pour faire pression sur MS...

Pour HP prendre un pas de recul par rapport à MS peut aussi seulement être fournir des machines sans OS.

Je n'y crois pas.
Que HP adapte une distribution (et la "certifie") et, par exemple, l'installe en parallèle avec Windows ou sans Windows, peut-être. De la a créer une distribution pour 1 ou 2 % de leur vente...

Très juste.

> Le truc, c'est qu'en général on a pas envie de se faire chier à inventer encore un nouveau format

Chaque fichier .ini a son propre format qui n'est pas décrit (sauf dans la doc)...

Je ne dis pas que l'XML doit être foutu partout. Mais aujourd'hui on ne peut plus demander à l'utilisateur de prendre un éditeur de texte pour change une configuration. Aujourd'hui la grande grande grande majorité des fichiers de configuration sont modifiés via un programme (qui n'est évidemment pas un éditeur de texte). XML est excellent dans ce domaine.

Libvirt a-t-il besoin de fichier de configuration en XML ?
Je ne donne pas la réponse. Mais c'est très cool avec virt-manager de créer et modifier une machine virtuelle est quelques cliques au-lieu de se bouffer la doc et utiliser un éditeur de texte (avec tous les risques d'erreur que ça implique). En majorité XML (ou autre) c'est mieux pour l'utilisateur, c'est aussi beaucoup mieux pour les développeurs.

Voyons ces projets :
http://cft.et.redhat.com/
http://augeas.net/
https://fedorahosted.org/func

Si tout était en XML, leurs vies seraient grandement simplifiées (avec contrôle et tout ; par exemple ils détecteraient automatique qu'une modification n'est pas encore supportée avec telle version d'apache).

> Les fichiers .INI, c'est un standard

Et comment tu décris le contenu d'un fichier .INI ?
Il y a des dtd pour fichiers .INI ?
Il y a l'équivalent de XPath pour les fichiers .INI ?

> Le XML est un standard récent

Mouaif...

> Les fichiers YAML, c'est un standard, il y a des outils pour les manipuler. .

Tu veux bien des fichiers YAML, mais pas des fichiers XML...
Va savoir pourquoi...

> Et puis c'est ce que veulent les entreprises alors suivont comme un mouton...

Soit rebelle.



> Bref, tu ne me donnes aucun argument qui tienne la route.

Et quel est ton argument ?
Ton argument c'est "XML poua, car c'est à la mode ; je veux un truc qui n'est pas à la mode".
Ben ça ne va pas loins.

> Les boites comme Red-Hat ont peut être tout intérêt à vendre du support la dessus.

C'est du libre. Fock libvirt. C'est beaucoup plus fort que de critiqué ce qui est fait pour et par le communauté.
N'utilises pas libvirt, n'utilises pas Gnome, n'utilises pas Firefox, etc. T'es libre.

> Petit exercice pour finir : vous mes traduisez en XML un fichier de configuration conséquent des serveurs apache2

Ben un fichier de conf d'apache a des ressemblances avec XML. Si c'était en XML, copier programmatiquement la configuration d'un site vers un autre site serait trivial. Mais actuellement il faut faire une usine à gaz pour y arriver.

Mouaif...
XML c'est un standard, il y a des outils pour les manipuler.

Le but n'est pas de tout faire avec vi. Mais d'avoir des outils de haut niveau.

De tout manière, c'est un débât dépassé. Il y aura de plus en plus de fichier de configuration en XML. Pour les choses compliquées ça présente trop d'intérêt pour s'en passer (sans compter qu'on n'a pas à ce faire chier a écrire un parser etc).

> Bref, je ne sais pas si c'est Red-Hat qui pousse à cela mais libvirt

Pour libvirt, le choix de XML a été fait dès le début (donc par Red Hat).

Marrant de voir que dans ce journal jamais virt-manager n'est cité...

virt-manager a été initialement developpé par Red Hat. Ubuntu l'utilise (et Novell/SuSE aussi ?).
C'est ultra simple d'utilisation. Ça peut-être cliquodrome, ou en "shell". Virt-manager utilise libvirt (qui gère Xen, KVM/qemu, etc).
C'est aussi intégré à Policy-kit, donc pas besoin d'être super-utilisateur.
Bref, que du bonheur (même s'il reste quelques bugs).

Virt-manger :
http://www.virt-manager.org/
Libvirt :
http://www.libvirt.org/

C'est que du libre, pas de modules proprios, etc.

En passant, ovirt :
http://www.ovirt.org/

> c'est l'impression que j'avais en ayant suivi de loin l'evolution de Fedora/redhat.

On peut avoir cette impression car l'offre commerciale actuelle de virtualisation de Red Hat utile principalement Xen.
Donc Red Hat a aussi beaucoup travaillé sur Xen. Mais depuis plusieurs mois les efforts se concentrent sur KVM (qui est déjà annoncé rendre obsolète Xen pour RHEL 6).

http://www.redhat.com/about/news/prarchive/2008/qumranet.htm(...)
Quelques commentaires de Red Hat :
http://www.redhat.com/promo/qumranet/

> Redhat n'a pas ete un precurseur dans le support de KVM a ma connaissance.

Tu te plantes complètement.
Fedora (qui est "massivement" sponsorisé par Red Hat) a misé sur KVM. F7 était la première distribution avec KVM "out of the box". Durant la phase beta de F8, Red Hat a annoncé se retirer de Xen au profit de KVM. Red Hat a développé la couche permettant de faire tourner des machines Xen sur KVM. Xen n'est pas supporté pour F9. On sait depuis plusieurs mois qu'il n'y aura pas Xen dans F10.

> Mais aujourd'hui que la strategie de XenSource semble plus que floues depuis que Citrix les a racheté, Redhat a fait de gros efforts sur KVM (ils ont plus trop le choix en meme temps... )

Rien à voir. KVM est plus prometteur que Xen selon Red Hat. Cet avis est très largement partagé chez les développeurs de Linux. Par exemple KVM est upstream et Xen non (sauf quelques bouts).

Un test de KVM de F7 (version Beta) :
http://www.phoronix.com/scan.php?page=article&item=656&a(...)
Article du 3 mars 2007...

Le rachat de Qumranet par Red Hat n'a rien de surprenant.

qui vote pour ?

> À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.

Ne dit pas de connerie.
Si Fedora/Red Hat n'avait pas dit qu'ils avaient un problème, on en aurait rien su.
Actuellement on est dans le flou et la communication de Fedora/Red Hat ne le nie nullement et elle demande un peu de patience pour avoir toutes les informations.

> À ce niveau-là, les autres distributions (notamment Debian) sont un peu plus transparentes sur leurs problèmes de sécurité.

Et que c'est-il passé pour le dernier problème de Debian avec Openssh ?
Debian a donné l'info dès que Debian à connu le problème ou Debian n'a diffusé l'information que lorsque Debian avait le correctif ? Ben que lorsque que Debian avait le correctif (Dieu merci).

Red Hat/Fedora doit problème faire exactement ce que fait Debian : confirmer le problème, trouver une solution, voire appliquer un embargo si d'autres distributions ont aussi ce problème.
Quand Red Hat (qui trouve beaucoup de failles de sécurité) applique un embargo afin que Debian et d'autres ait le temps de mettre à jour, Debian trouve ça très bien.

> un peu plus transparentes sur leurs problèmes de sécurité.

Red Hat est transparent. Mais parfois, l'information, pour d'excellentes raisons, n'est pas diffusée de suite.

Les données "brutes" sur la sécurté de Red Hat :
https://www.redhat.com/security/data/metrics/
A titre d'exemple, un rapport sur la sécurité de RHEL 4 (en cherchant on en trouvera d'autres) :
http://www.redhatmagazine.com/2008/02/26/risk-report-three-y(...)

Ce n'est absolument pas moins transparent que Debian (et ses patchs qui ne sont pas séparés...).

Je ne vois toujours pas le rapport.
Il y a des obligations pour communiquer, non l'inverse.

C'est assez comique, car RHN n'a fournit aucun mauvais paquets. Par contre des serveurs (de Red Hat) ont été compromis et surtout la signature de RHEL a été utilisée. Red Hat ne sait pas si ces mauvais paquets sont sortis de ses serveurs (via un canal différent de RHN).

Bref, ceux qui n'utilisent que RHN n'ont pas de soucis à se faire...

Je plussois massivement le commentaire de Krunch ci-dessus.

J'ai oublié les détails.
En gros DMCA couvre aussi les moyens de protection de donnée et on ne peut pas annoncer une faille sans quelques précautions. Si tu annonces une faille de sécurité et que tu mets en péril significatif des entreprises (ou leurs "oeuvres"), je crois que tu peux tomber sur DMCA.

Peux-tu être plus précis ?
Être en bourse n'implique pas d'appliquer la censure à tout. C'est même souvent l'inverse.

Il n'y a que les paquets Rawhide (de la branche de développement quasiment uniquement utilisé par les développeurs/testeurs) qui sont signés automatiquement.

Le commentaire de la clé et clair :
$ gpg /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-rawhide
pub 1024D/1CDDBCA9 2003-10-27 Fedora Project automated build signing key (2003) <rawhide@redhat.com>

> Dans les deux cas, une faille d'un autre élément (dans les patchs locaux du paquet openssl de Debian pour la première, dans l'infrastructure de gestion des paquets de Red Hat pour la seconde) a eu des conséquence sur les paquets openssh de ces distributions.

Pour Red Hat/Fedora, pour l'instant on en sait rien. Paul Frields a promis de donner des explications, mais pour l'instant elles ne sont pas la. Il faut attendre.

> Sauf que tout cela se passe en privé sur des mailling list privés, et il est interdit à ceux qui sont sur ces listes de rendre publique les failles qui y sont discutées avant la date prévue

"Interdit" est trop fort. C'est très très mal vu. Les personnes raisonnablent ne feront pas ça. Ceux qui s'y risquent seront probablement bânis de la mailing.
Par contre Fedora est sous la responsabilité de Red Hat et Red Hat est une boite américaine. Donc Red Hat a des obligations légales (respecter DMCA entre autre).

Tout ceci n'est évidemment pas positif. Fedora/Red Hat a pris le problème avec le gros sérieux que demande ce type de situation. Certes certains utilisateurs ont montré de la frustration, mais que je crois que la majorité (souvent silencieuse) comprend que les actions doivent être vigoureuses et la communication gérée avec doigté. Red Hat doit respecter DMCA et si c'est un problème upstream aussi respecté un embargo pour les autres.

> A noter que cette absence de distribution ne vaut que pour le canal officiel Red Hat et pas pour des dépôts tiers.

Des paquets ont été signé sur les systèmes Red Hat, mais Red Hat n'est pas sûr que ces paquets ne sont pas sorti de leurs systèmes.

Rien indique que c'est un problème avec openssh...

> N'ayant aucune RedHat/Fedora dans mon parc, me voilà rassuré.

Mouaif. Vu le faible niveau d'information donné par Fedora/Red Hat, ont peut aussi penser que c'est un problème upstream (période d'embargo). Et dans ce cas tu es aussi en "danger".

> Par contre je pense à une chose : la sécurité de ces dépôts reste, elle, bel et bien centralisée.

La signature est (forcément) centralisée.

> Ne serait-il pas une bonne idée de confier une verification tierce de signatures à un tiers indépendant des distribution,

Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.

> genre X s'occupe de vérifier que chaque changement de signature d'un package de la distribution.

Il n'y a pas eu de changement de signature, il y a eu abus de l'infrastructure pour signer les paquets avec la signature de Fedora / Red Hat.

> le format OXML "Open XML" qui est normalisé ISO.

Non. Regarde la norme pour t'en convaincre.

Vu les montants, si t'enlève la "contribution" de MS, Novell est quasi mort...
Et après on va expliquer que Novell se porte bien...

> Tu sais, moi je m'en fous des journaux/dépêches sur Red Hat/Fedora, c'est pas pour autant que je poste un commentaire en dessous pour dire que je m'en fous (car je t'explique, le monde ne tourne pas autour de toi et les autres s'en foutent que tu t'en foutes ...)

Certes. Mais je dis seulement que *moi* je m'en fous. Je ne dis pas qu'il n'aurait pas dû faire de journal, ou que son journal c'est de la merde, etc.

Par contre, ce qui a plus particuliairement motivé mon commentaire, c'est le "Entièrement libre".