> Mais avant de lâcher RHEL 5.2, celle-ci sera blindé de tests
C'est du desktop seulement :-)
Red Hat ne va pas faire des tests de non régression ou des benchs comme il le fait pour les systèmes fichiers ou le noyau.
> Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier
Le débat est totalement faussé. Ubuntu LTS est une distribution comme Mandriva / Fedora / OpenSuSE / etc ou comme RHEL SLES ?
Si c'est une distribution comme Fedora ou Mandriva, c'est grosso-modo une bonne distribution (peut-être pas le meilleur cru).
Mais ça n'a rien à voir avec une RHEL.
> Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.
C'est supporté 3 ans, LTS est le nom pour ça. Donc c'est digne de LTS.
Fedora a aussi eu ces "LTS" (Fedora Legacy qui n'existent plus aujourd'hui).
Mais LTS != RHEL ou SLES.
En tout cas pour la 04-08.
M'enfin, quel sont les rapports de force ?
Au pif :
RH : 10
Novell : 6
Ubuntu : 1
Ben n'empêche qu'Ubuntu veut fixer la date de release de RHEL, SLES ou Debian. Autour d'avril 2010 (plus ou moins 1 mois).
Que peut y gagner Red Hat ou Novell ?
Quasiment rien et en plus ils perdent en liberté.
RHEL est pour une boite commerciale où la date de release (comprendre les fonctionnalités ici) est critique pour le business. La date de release n'est pas importante dans son respect, mais dans la possibilité de la changée ! Pour ajouter telle ou telle fonctionnalité, pour passer de gcc 4.3 à gcc 5, etc.
Bref, fixer aujourd'hui pour Red Hat ou Novell la date de release où même les versions majeurs des principaux composant de leur "de dans 2 temps" distribution entreprise est quasi suicidaire.
L'excellent Russel Coker a fait un billet sur ça. Il n'est pas vraiment d'accord moi on va dire : http://etbe.coker.com.au/2008/05/13/release-dates-for-debian(...)
Il propose que Debian se synchronise avec RHEL.
Mais, il y a une énorme différence avec Ubuntu. Il reconnait le rapport de force, il n'impose pas de calendrier à RHEL.
It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle.
Il insiste plus sur les composants que sur la date de sortie. Debian sortira quand elle jugera qu'elle est prête.
M'enfin, je pense que ça passera plus par une collaboration avec Fedora que directement avec RHEL.
Biensûr que Red Hat / Fedora ne va pas refuser ce type de collaboration et que les choses seront fait pour que ça soit du gagnant-gagnant.
Mais ce que propose Ubuntu, et notamment pour des distributions entreprise (avec enjeux commercial), ce n'est pas du gagnant-gagnant.
C'est du gagnant pour Ubuntu et c'est tout.
Ubuntu a choisi de sortie des releases à date fixe. Ubuntu a ses raisons pour ça.
Les autres n'ont pas choisi ce modèle. Ils ont aussi leur raison. Mais Ubuntu veut imposer son modèles aux autres. Qui y gagne ? Que Ubuntu.
On peut chipoter sur le verbe "imposer". M'enfin, il a dit que la date de release c'est avril 2010 (plus ou moins un mois). J'image que pour Red Hat et Novell, voir ça est de la science fiction.
La pratique d'avoir une branche Debian est très très discutable.
Chez Fedora ce sont les patchs individuels qui sont stockés. Il est alors facile de savoir qui fait quoi et pourquoi. Il est plus facile d'envoyer des patchs en upstream, de faire auditer ses patchs, etc.
Cette pratique de Debian a aussi agacé Mozilla...
J'espère que tous les paquets Debian ne sont pas géré comme ça. Parce qu'en gros Debian fait un fork.
> Aucune publicité n'est apparu, et même RH ne fait pas de stand à son effigie. (seule la communauté daigne en parler)
Oui et non.
Red Hat *vend* pour des entreprises. Red Hat *vend* RHEL, JBoss, des services, etc.
Lorsqu'il y a une rencontre Red Hat (summit), c'est pour les clients Red Hat.
Ce n'est pas du dédain, c'est une clarificaiton de la communication.
Ce n'est pas une volonté de "cacher" Fedora. Sur la page d'accueil de http://www.redhat.com/ , il y a en titre la sortie de F9. Il y a aussi un lien vers http://fedoraproject.org/ sur toutes les pages de http://www.redhat.com/ .
On trouve de nombreux articles sur Fedora dans Red Hat Magazine : http://www.redhatmagazine.com/
Fedora : 53
RHEL : 35
Le prochain Red Hat Summit aura lieu en même temps avec FUDcon (et au même lieu :-)).
Certe, il n'y a pas de publicité. On peut imaginer la raison.
Red Hat préfère investir en développement qu'en pub. De plus, Red Hat ne vend pas Fedora. Donc investir en publicité sur Fedora ne lui fait rien gagner. Perso, je préfère que l'argent soit mis dans le développement (code, infrastructure pour la communauté, etc).
Notons que Fedora veut son indépendance par rapport à la "stratégie commerciale ou communication" de Red Hat.
Red Hat ne peut l'offrir totalement, mais y répond grandement (ce qui a des conséquences en bien et en mal).
Si Red Hat ne se met pas en avant pour Fedora, c'est aussi car Fedora ce n'est pas que Red Hat. Red Hat ne peut pas s'"approprier" Fedora. C'est "seulement" le plus gros contributeur (mais un peu plus pour être honnète). http://www.redhat.com/archives/fedora-announce-list/2008-May(...) Giving credit where credit is due, and working hand-in-hand with others
Tu ne peux donc pas être "agressif" et t'afficher en concurrent (comme le fait RHEL par exemple).
Notons que le leader du projet Fedora n'est pas un employé Red Hat et que Red Hat n'a plus la majorité dans le directoire Fedora (4 sièges pour Red Hat sur 9).
Notons aussi que Fedora n'a quasiment aucune pub pour Red Hat :-)
On me rétorquera que c'est inutile...
F9 est en mode compatible SysVinit. Donc il n'y a pas de gain ici ou très peu (du moins pour F9). Entre appeler /etc/rc.d/rc5.d/S27named depuis le vieux init ou depuis upstart, ça ne change pas grand chose.
Pour la petite histoire, le nom Sulphur a donné du fil à retordre à l'équite artistique. En effet, le sulphur (soufre) fait passer à des mauvaises odeurs. Il a donc été viré de l'image de fond du bureau même si d'un point de vu uniquement visuel c'était sympa.
> * Gestion du système de fichier Ext4 (expérimental).
Attention, grub ne sait pas lire du ext4. Donc si on veut tester ext4 il faut une partition /boot (en ext3 par exemple). Je précise car on le sait qu'à la fin de l'installation :-)
> RPM Fusion
Malheureusement RPM Fusion n'est pas encore prêt. Mais il n'est pas abandonné. Pour ceux qui vont vers livna aujourd'hui, il est prévu une migration en douceur.
> FUNC (Fedora Unified Controller)
> Module Python afin de faciliter la gestion d'un parc informatique via XML-RPC/SSL.
Ce n'est pas un module python, mais on peut faire des modules python pour func (il y en a déjà quelqu'uns). https://fedorahosted.org/func
> tu apprécierais qu'un "metteur en boite" décide pour toi d'un calendrier sur deux ans
Je n'image même pas comment Red Hat ou Novell voit l'"invitation" d'Ubuntu a sortir leur prochaine distribution entreprise en avril 2010...
Ces derniers sont toujours hyper discrets sur les dates des prochaines releases entreprises. Pas forcément car c'est un secret, mais car ils ne savent pas !
Ils ont seulement un vague idée.
> Fedora 9 (base de RHEL 6)
Même entre Fedoraiste, on se battaille pour savoir si RHEL 6 va être basée sur F9 ou sur F10 :-)
A la sortie de F8, Red Hat ne le savait pas.
Jusqu'à maintenant on ne sait toujours pas.
Certains (dont je fais parti) pensent que ça va être F10 car les développeurs Red Hat sont très occupés actuellement et que ext4/kvm ne sont pas prêts encore.
D'autres comme GeneralZod passent que c'est F9.
Je ne serait pas étonné que du côté de Red Hat il ne savent pas encore de façon sûr...
> Et dire que dans le journal juste en dessous tu dis que c'est complètement débile de fixer une date pour une release...
Justement. Je dis ici qu'il faut attendre l'annonce officiel !
Tant qu'il n'y a pas d'annonce, elle n'est pas sortie. Même si le planning dit que F9 va sortir aujourd'hui, il faut attendre l'annonce.
En passant, la date de release de F9 a été repoussée 2 fois (en tout ça fait 21 jours je crois). Donc Fedora n'a pas respecté son calendrier. C'est un petit dérapage dont a beaucoup de release de Fedora (il y a toujours des imprévus).
Dans le cas d'Ubuntu, ça serait un changement de nom de distribution :-)
Je n'ai pas reproché à Debian de faire des patchs, mais de ne pas les remonter upstream.
Sinon rigolons un peu : http://www.br0kenhalo.com/?p=49
int getRandomNumber() {
return 4 ;
}
> Mais c'est quand même bizarre de pas signer des paquets aussi cruciaux.
C'est clair.
C'est simple, chez moi je n'installe jamais un paquet non-signé. Ou alors après une vérification, ou pour une bécane de test, etc.
Si c'est pour ma bécane ou une bécane en production, alors ça doit être signé.
> En upstream on lui aurait : "- malheureux, ne fais pas ça !"
En fait : http://www.links.org/?p=327
we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was.
On va peut-être éviter les expéditions punitives ?
Il a certainement très bien retenu la leçon maintenant.
Par contre, faudrait qu'Ubuntu qui fait des distributions "entreprise" audite mieux ce qui est fait pour les paquets critiques. Ça fait depuis 1 an que ça traine chez Ubuntu.
Espérons qu'aucune bécane ne va être crackée, sinon Ubuntu va se prendre une volée de bois vert.
Pour Fedora, avoir anaconda (l'installeur) qui fait les mises à jours entre versions distributions est quasi indispensable (ou très très recommendé).
Le problème de passer par anaconda jusqu'à maintenant, est qu'il demandait de graver un CD, etc. Ou de download un gros DVD dont on ne va utiliser que la moitier.
Ce n'est pas d'un très bon rendement.
Fedora a développé preupgrade. L'idée n'est pas de "virer" anaconda, mais de préparer la futur mise à jours par anaconda. De plus, il n'est plus nécessaire de graver de CD.
Preupgrade examine votre installation, détermine les paquets de la version suivante de la distribution qu'il vous faut, les downloade.
Après il ajoute une entrée à votre grub (pour booter le nouveau noyau et lancer anaconda).
Une fois que preupgrade a fait son boulot, il suffit de rebooter.
[^] # Re: Pour info
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 1.
Si ils peuvent le faire.
Mais j'ai la faiblesse de croire que c'est moins probable :-)
[^] # Re: firefow 3.0 beta 5
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 4.
C'est du desktop seulement :-)
Red Hat ne va pas faire des tests de non régression ou des benchs comme il le fait pour les systèmes fichiers ou le noyau.
> Ce n'est pas tant le choix de FF3 qui est à remettre en question dans Ubuntu que la rigidité du calendrier
Le débat est totalement faussé. Ubuntu LTS est une distribution comme Mandriva / Fedora / OpenSuSE / etc ou comme RHEL SLES ?
Si c'est une distribution comme Fedora ou Mandriva, c'est grosso-modo une bonne distribution (peut-être pas le meilleur cru).
Mais ça n'a rien à voir avec une RHEL.
> Il faudra probablement attendre Ubuntu 8.04.1 pour avoir une version digne du nom LTS.
C'est supporté 3 ans, LTS est le nom pour ça. Donc c'est digne de LTS.
Fedora a aussi eu ces "LTS" (Fedora Legacy qui n'existent plus aujourd'hui).
Mais LTS != RHEL ou SLES.
En tout cas pour la 04-08.
[^] # Re: firefow 3.0 beta 5
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 1.
Bravo arch, mais pas bravo Ubuntu :-)
[^] # Re: Pour info
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 2.
> * Jeter le bébé avec l'eau du bain
Non. Une connerie a été faite. Faut arrêter de chercher des excuses.
Mais ça arrive ! C'est comme ça, ça arrive. Personne n'est à l'abris.
[^] # Re: moui
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
Je propose Mark S.
> Je trouve ça pénible
Moi aussi.
[^] # Re: L'upstream
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
On peut voir les choses comme ça.
M'enfin, quel sont les rapports de force ?
Au pif :
RH : 10
Novell : 6
Ubuntu : 1
Ben n'empêche qu'Ubuntu veut fixer la date de release de RHEL, SLES ou Debian. Autour d'avril 2010 (plus ou moins 1 mois).
Que peut y gagner Red Hat ou Novell ?
Quasiment rien et en plus ils perdent en liberté.
RHEL est pour une boite commerciale où la date de release (comprendre les fonctionnalités ici) est critique pour le business. La date de release n'est pas importante dans son respect, mais dans la possibilité de la changée ! Pour ajouter telle ou telle fonctionnalité, pour passer de gcc 4.3 à gcc 5, etc.
Bref, fixer aujourd'hui pour Red Hat ou Novell la date de release où même les versions majeurs des principaux composant de leur "de dans 2 temps" distribution entreprise est quasi suicidaire.
L'excellent Russel Coker a fait un billet sur ça. Il n'est pas vraiment d'accord moi on va dire :
http://etbe.coker.com.au/2008/05/13/release-dates-for-debian(...)
Il propose que Debian se synchronise avec RHEL.
Mais, il y a une énorme différence avec Ubuntu. Il reconnait le rapport de force, il n'impose pas de calendrier à RHEL.
It seems to me that the best way of achieving the goal that Mark advocates (in the short term at least) is for Debian to follow Red Hat’s release cycle.
Il insiste plus sur les composants que sur la date de sortie. Debian sortira quand elle jugera qu'elle est prête.
M'enfin, je pense que ça passera plus par une collaboration avec Fedora que directement avec RHEL.
Biensûr que Red Hat / Fedora ne va pas refuser ce type de collaboration et que les choses seront fait pour que ça soit du gagnant-gagnant.
Mais ce que propose Ubuntu, et notamment pour des distributions entreprise (avec enjeux commercial), ce n'est pas du gagnant-gagnant.
C'est du gagnant pour Ubuntu et c'est tout.
Ubuntu a choisi de sortie des releases à date fixe. Ubuntu a ses raisons pour ça.
Les autres n'ont pas choisi ce modèle. Ils ont aussi leur raison. Mais Ubuntu veut imposer son modèles aux autres. Qui y gagne ? Que Ubuntu.
On peut chipoter sur le verbe "imposer". M'enfin, il a dit que la date de release c'est avril 2010 (plus ou moins un mois). J'image que pour Red Hat et Novell, voir ça est de la science fiction.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 4.
Chez Fedora ce sont les patchs individuels qui sont stockés. Il est alors facile de savoir qui fait quoi et pourquoi. Il est plus facile d'envoyer des patchs en upstream, de faire auditer ses patchs, etc.
Cette pratique de Debian a aussi agacé Mozilla...
J'espère que tous les paquets Debian ne sont pas géré comme ça. Parce qu'en gros Debian fait un fork.
[^] # Re: Re:
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
Non ou pas seulement. Il y a les programmes func, func-inventory, func-create-module, etc.
Ces derniers utilisent des modules.
Peut-être qu'un jour il y aura libfunc avec func comme utilisateur. Mais ce n'est pas le cas aujourd'hui.
[^] # Re: firefow 3.0 beta 5
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 8.
Oui et non.
Red Hat *vend* pour des entreprises. Red Hat *vend* RHEL, JBoss, des services, etc.
Lorsqu'il y a une rencontre Red Hat (summit), c'est pour les clients Red Hat.
Ce n'est pas du dédain, c'est une clarificaiton de la communication.
Ce n'est pas une volonté de "cacher" Fedora. Sur la page d'accueil de http://www.redhat.com/ , il y a en titre la sortie de F9. Il y a aussi un lien vers http://fedoraproject.org/ sur toutes les pages de http://www.redhat.com/ .
On trouve de nombreux articles sur Fedora dans Red Hat Magazine :
http://www.redhatmagazine.com/
Fedora : 53
RHEL : 35
Le prochain Red Hat Summit aura lieu en même temps avec FUDcon (et au même lieu :-)).
Certe, il n'y a pas de publicité. On peut imaginer la raison.
Red Hat préfère investir en développement qu'en pub. De plus, Red Hat ne vend pas Fedora. Donc investir en publicité sur Fedora ne lui fait rien gagner. Perso, je préfère que l'argent soit mis dans le développement (code, infrastructure pour la communauté, etc).
Notons que Fedora veut son indépendance par rapport à la "stratégie commerciale ou communication" de Red Hat.
Red Hat ne peut l'offrir totalement, mais y répond grandement (ce qui a des conséquences en bien et en mal).
Si Red Hat ne se met pas en avant pour Fedora, c'est aussi car Fedora ce n'est pas que Red Hat. Red Hat ne peut pas s'"approprier" Fedora. C'est "seulement" le plus gros contributeur (mais un peu plus pour être honnète).
http://www.redhat.com/archives/fedora-announce-list/2008-May(...)
Giving credit where credit is due, and working hand-in-hand with others
Tu ne peux donc pas être "agressif" et t'afficher en concurrent (comme le fait RHEL par exemple).
Notons que le leader du projet Fedora n'est pas un employé Red Hat et que Red Hat n'a plus la majorité dans le directoire Fedora (4 sièges pour Red Hat sur 9).
Notons aussi que Fedora n'a quasiment aucune pub pour Red Hat :-)
On me rétorquera que c'est inutile...
[^] # Re: Goulots d'étranglement de X
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
Ce n'est pas vraiment un "goulot d'étranglement", c'est pour raccourcis le temps de démarrage de Xorg :
http://fedoraproject.org/wiki/Features/OneSecondX
> Sinon, upstart est bluffant.
F9 est en mode compatible SysVinit. Donc il n'y a pas de gain ici ou très peu (du moins pour F9). Entre appeler /etc/rc.d/rc5.d/S27named depuis le vieux init ou depuis upstart, ça ne change pas grand chose.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 1.
Tu vois la nuance ?
L'installation d'un paquet rpm peux exécuter n'importe quelque script ou programme sous root.
[^] # Re: Re:
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
[^] # Re: Re:
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 2.
C'est plus qu'expérimental
# Re:
Posté par IsNotGood . En réponse à la dépêche Fedora 9 : une version sulfureuse. Évalué à 9.
Malheureusement, PreUpgrade (pour mise à jour vers F9) n'a pas encore atteind les dépôts accessibles via un "yum install preupgrade".
Pas de panique, vous trouverez les preupgrade qui vont bien ici :
http://skvidal.wordpress.com/2008/05/13/looking-for-a-preupg(...)
Preupgrade sur fedoraproject.org (avec des copies d'écran) :
http://fedoraproject.org/wiki/Features/PreUpgrade
Interview sur PreUpgrade :
http://www.redhatmagazine.com/2008/04/15/interview-fedora-de(...)
> * Gestion du système de fichier Ext4 (expérimental).
Attention, grub ne sait pas lire du ext4. Donc si on veut tester ext4 il faut une partition /boot (en ext3 par exemple). Je précise car on le sait qu'à la fin de l'installation :-)
> RPM Fusion
Malheureusement RPM Fusion n'est pas encore prêt. Mais il n'est pas abandonné. Pour ceux qui vont vers livna aujourd'hui, il est prévu une migration en douceur.
> FUNC (Fedora Unified Controller)
> Module Python afin de faciliter la gestion d'un parc informatique via XML-RPC/SSL.
Ce n'est pas un module python, mais on peut faire des modules python pour func (il y en a déjà quelqu'uns).
https://fedorahosted.org/func
Dans le même esprit (pour admin), notons aussi Augeas :
http://www.augeas.net/
Très intéressant.
> OpenJDK
> Fruit de la collaboration entre RedHat et Sun, OpenJDK 1.6 (Java 6)
Maintenant c'est OpenJDK. Contrairement à IcedTea, il n'est pas très lié à Red Hat.
M'enfin, il y reste encore beaucoup de patchs de IcedTea :-)
> Intégration de GCC 4.3 avec le support expérimental de C++ 0x
C'est plus expérimental je crois. C'est initial. Le chemin est encore (très) long.
> Cette version est la première de Paul Frields
Le mot (et ses réflexions) du "boss" sur F9 :
http://www.redhat.com/archives/fedora-announce-list/2008-May(...)
L'annonce de F9 par fedoraproject (fun comme d'habitude) :
http://www.redhat.com/archives/fedora-announce-list/2008-May(...)
L'annonce par Red Hat (moins fun) :
http://www.redhat.com/about/news/prarchive/2008/fedora9.html
[^] # Re: L'upstream
Posté par IsNotGood . En réponse au journal Mark Shuttleworth : il remet ça. Évalué à 2.
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
> A l'exception de quelques paquets, Ubuntu est un très mauvais élève concernant les remontées en upstream.
On peut aussi noter qu'Ubuntu a une mailing pour les développeurs Ubuntu (Canonical principalement), et une mailing pour les autres développeurs...
> ils recommandent aux développeurs de venir suivre directement les patchs chez eux !
C'est prévu :-)
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Point of contact for upstream developers to reach Ubuntu developers
> tu apprécierais qu'un "metteur en boite" décide pour toi d'un calendrier sur deux ans
Je n'image même pas comment Red Hat ou Novell voit l'"invitation" d'Ubuntu a sortir leur prochaine distribution entreprise en avril 2010...
Ces derniers sont toujours hyper discrets sur les dates des prochaines releases entreprises. Pas forcément car c'est un secret, mais car ils ne savent pas !
Ils ont seulement un vague idée.
> Fedora 9 (base de RHEL 6)
Même entre Fedoraiste, on se battaille pour savoir si RHEL 6 va être basée sur F9 ou sur F10 :-)
A la sortie de F8, Red Hat ne le savait pas.
Jusqu'à maintenant on ne sait toujours pas.
Certains (dont je fais parti) pensent que ça va être F10 car les développeurs Red Hat sont très occupés actuellement et que ext4/kvm ne sont pas prêts encore.
D'autres comme GeneralZod passent que c'est F9.
Je ne serait pas étonné que du côté de Red Hat il ne savent pas encore de façon sûr...
Les paris sont ouverts !
[^] # Re: repos tiers
Posté par IsNotGood . En réponse au journal Fedora 9. Évalué à 2.
C'est ça.
Par contre il n'y a pas flash, acroread, etc.
C'est seulement du contenu légal en Europe (à vérifier).
> Qu'en est il du projet rpmfusion ?
Il a du retard.
Plus d'infos ici :
http://www.redhat.com/archives/fedora-announce-list/2008-May(...)
[^] # Re: Une dépêche...
Posté par IsNotGood . En réponse au journal Fedora 9. Évalué à 2.
Justement. Je dis ici qu'il faut attendre l'annonce officiel !
Tant qu'il n'y a pas d'annonce, elle n'est pas sortie. Même si le planning dit que F9 va sortir aujourd'hui, il faut attendre l'annonce.
En passant, la date de release de F9 a été repoussée 2 fois (en tout ça fait 21 jours je crois). Donc Fedora n'a pas respecté son calendrier. C'est un petit dérapage dont a beaucoup de release de Fedora (il y a toujours des imprévus).
Dans le cas d'Ubuntu, ça serait un changement de nom de distribution :-)
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 2.
Mais ce n'est pas grave !
C'est le rire, ce n'est pas controlable.
Ils auraient bien rigolé, puis lui aurait dit de ne pas faire cette connerie.
Mais clairement ils préfèrent être informé (et si en plus c'est l'occasion de se marrer :-)).
Avec cette faille diffusé à des millions d'exemplaires, c'est beaucoup moins drole.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 4.
Je n'ai pas reproché à Debian de faire des patchs, mais de ne pas les remonter upstream.
Sinon rigolons un peu :
http://www.br0kenhalo.com/?p=49
int getRandomNumber() {
return 4 ;
}
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 2.
Ben oui. Mais Debian ne l'a pas fait que pour la version debug.
Le patch qui corrige :
http://svn.debian.org/wsvn/pkg-openssl/openssl/trunk/crypto/(...)
Où tu vois le "#ifdef ..." ?
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 4.
C'est clair.
C'est simple, chez moi je n'installe jamais un paquet non-signé. Ou alors après une vérification, ou pour une bécane de test, etc.
Si c'est pour ma bécane ou une bécane en production, alors ça doit être signé.
Bref => n'installes pas.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 5.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 2.
En fait :
http://www.links.org/?p=327
we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was.
[^] # Re: Debian et dérivées
Posté par IsNotGood . En réponse au journal Vulnérabilité Debian. Évalué à 6.
Il a certainement très bien retenu la leçon maintenant.
Par contre, faudrait qu'Ubuntu qui fait des distributions "entreprise" audite mieux ce qui est fait pour les paquets critiques. Ça fait depuis 1 an que ça traine chez Ubuntu.
Espérons qu'aucune bécane ne va être crackée, sinon Ubuntu va se prendre une volée de bois vert.
# Preupgrade
Posté par IsNotGood . En réponse au journal Fedora 9. Évalué à 2.
Le problème de passer par anaconda jusqu'à maintenant, est qu'il demandait de graver un CD, etc. Ou de download un gros DVD dont on ne va utiliser que la moitier.
Ce n'est pas d'un très bon rendement.
Fedora a développé preupgrade. L'idée n'est pas de "virer" anaconda, mais de préparer la futur mise à jours par anaconda. De plus, il n'est plus nécessaire de graver de CD.
Preupgrade examine votre installation, détermine les paquets de la version suivante de la distribution qu'il vous faut, les downloade.
Après il ajoute une entrée à votre grub (pour booter le nouveau noyau et lancer anaconda).
Une fois que preupgrade a fait son boulot, il suffit de rebooter.
C'est une idée sympatique.
NB : je n'ai pas testé.
Malheureusement, les parquets preupgrade qui permettent la mise à jour vers F9 ne sont pas encore disponible "en standard".
Il faut les récupérer ici :
http://skvidal.wordpress.com/2008/05/13/looking-for-a-preupg(...)
PS : Preupgrade est jeune, donc faites un backup. Ooops, il doit déjà exister.