Journal : Mark Shuttleworth : il remet ça
Posté par IsNotGood () le 12 mai 2008
J'aimais bien lire Mark Shuttleworth. Plus maintenant.
Son dernier blog (à cette date :-)) :
http://www.markshuttleworth.com/archives/146
Titre : The Art of Release
Voyons les conneries qu'il y a dedans.
To the best of my knowledge there has never been an "enterprise platform" release delivered exactly on schedule, to the day, in any proprietary or Linux OS.
Bullshit.
Et en passant, heureusement qu'aujourd'hui les distributions entreprise ne se lient pas à un planning, mais à des fonctionnalités à fournir au client.
Not only did it prove that we could execute an LTS release in the standard 6-month timeframe
"Entreprise Ready" veut dire qu'il y a des tonnes d'applications tiers disponibles à la sortie de la distribution. Ça veut aussi dire que la hot line a été formée. Ça veut aussi dire qu'il y a de la documentation de qualité. Pas de la doc qu'on va récupérer ici ou là dans un wiki ou dans un README.txt. Ça veut aussi dire qu'il y a des programmes de formation en place, etc.
Ubuntu 8.04 n'a pas du tout démontré ça. Elle a démontré qu'elle fait comme les autres distributions "communautaires" (Mandriva, Fedora, OpenSuse, etc). Presque rien de plus.
As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.
Et ?
Red Hat ou Novell n'a aucune difficulté pour faire (que) ça !
N'importe qui peut le faire.
Fedora, Mandriva, etc le fait très bien !
Le problème n'est pas de fixer une date et de si tenir, mais de fixer la date où une technologie en développement sera founie prêt à l'emploi pour les entreprises.
Se donner comme objectif seulement une date est ri-di-cu-le.
Par exemple RHEL 6 aura très probablement ext4.
Es-ce Mark Shuttleworth pourrait utiliser sa boule de cristal et nous dire quand ext4 sera prêt pour les entreprises ?
J'en doute, même les développeurs n'ont qu'une vague idée.
En passant, Ubuntu est sorti Firefox en version beta.
Je doute que c'était l'objectif d'Ubuntu 8.04...
Les fonctionnalités ont été adaptés à la date. Où est alors la "prédictibilité" dont il se flatte ? Seulement dans une date. On sait maintenant que l'objectif de la sortie d'une LTS est une date...
This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it.
C'est extraordinaire pour le département pub...
This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.
Je ne comprend rien...
Ou je comprend mais je ne vois pas où il veut en venir ou ne préfère pas voir où il veut en venir...
There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that.
Ben qu'Ubuntu le fasse.
Et pour RHEL c'est très facile.
Le cycle de développement d'une LTS est de 6 mois. Le cycle de développement de RHEL est de 6/9 mois (7 mois pour RHEL 5 entre la première beta et la finale). Donc Ubuntu connait suffisament tôt le noyau que va utiliser la prochaine RHEL, la version Gnome, la toolchain, etc.
Red Hat fournit parfois la date de release finale. Mais même dans ce cas il n'y a pas de garantit.
Il est très probable que la prochaine RHEL 6 soit basée sur F10 (certains pensent que ça va être F9, mais j'en doute). Dès que les premiers plannings de F10 seront dispos, on aura probablement confirmation que RHEL 6 sera basée sur F10. Ceci laisse beaucoup de temps à Ubuntu de s'ajuster (probablement autour de 10 mois). Au "pire", il y a 6 mois entre la première beta RHEL (qui est public) et la finale.
Voyons le ridicule dans la situation.
Ubuntu LTS : 04-2008
RHEL 6 : 04-2009 (peut-être)
Es-ce que Ubuntu va retarder son planning d'un an pour être synchro avec RHEL 6 ?
Ubuntu LTS : 04-2010
Es-ce que Ubuntu va avancer son planning d'un an pour être synchro avec RHEL 6 ?
Es-ce que Ubuntu 10-04 va utiliser la même toolchain que RHEL 6 sortie il y a depuis un an à la sortie d'Ubuntu 10-04 ?
Croyez vous 1 milli-seconde que Red Hat va sortir une RHEL 7 le 04-2010 juste pour faire plaisir à Ubuntu ?
Red Hat ne veut pas s'imposer de date.
Sortir une distribution entreprise juste pour être dans les plannings et faire plaisir au département pub est ridicule.
Red Hat sort une distribution lorsque c'est un plus pour ses clients et que ces plus justifient une nouvelle distribution (migration demandant l'installeur, incompatibilité binaire/source pour les services, etc).
Les (possibles) plus pour le client de RHEL 6 est ext4, FreeIPA, KVM (au-lieu de Xen), etc.
Il y a des nouvelles technologies libre, elles demande parfois une nouvelle distribution.
Mais sortir une nouvelle distribution entreprise à date fixe pour ne pratiquement rien apporter aux clients (seulement s'arracher les cheveux en migration, mise à jour, etc) est ridicule. NB: je parle d'un contexte entreprise et pas hobbyiste.
Un petit exemple, RHEL 5.2 est en beta :
https://www.redhat.com/archives/rhelv5-announce/2008-March/m(...)
Ben oui, passer à Firefox 3 ou OOo 2.3 ne justifie pas une nouvelle distribution (lire le reste de l'annonce, il n'y a pas que ça dans RHEL 5.2 (qui n'est qu'une mise à jour et ne demande qu'un "yum update" qui ne vont pas casser les applis en place, etc)).
Pour avoir OOo 2.3, le client ne veut pas passer à RHEL 6. Il le veut sur ses RHEL 5. Techniquement le passage à OOo 2.3 ne justifie pas une nouvelle distribution.
Ubuntu ne comprend pas ce que veux les entreprises avec le libre.
Les entreprises ne veulent plus de mise à jours juste pour faire plaisir au département pub d'Ubuntu et car ça fait entrer du pognon à Ubuntu. Elles veulent du service ! Elles en ont rien à foutre de changer de distribution si c'est pour 3 fois rien. En tout cas, c'est ainsi pour les serveurs.
Red Hat l'a très bien compris et Red Hat ne vend pas une distribution, mais un service (qui donne accès à toutes les versions d'RHEL). Le client a une souscription pour RHEL, ben il installe une RHEL 4, puis met à jours, s'il le juge utile, vers RHEL 5, puis vers RHEL 6. C'est inclus dans le prix de la souscription (c'est un poil plus compliqué car parfois il n'y a pas correspondance exacte, mais c'est l'esprit). Ce service inclus évidemment le backport des patchs de sécurité pour une version de distribution, les corrections de bug, mais aussi la mise à jours de certaines applis bureautiques comme on l'a vu, ainsi que j'ajout de driver, etc.
Red Hat propose aussi de nouvelle fonctionnalité pour une même version de distribution si ça ne justifie pas une nouvelle distribution.
Avec ce blog, Mark Shuttleworth démontre qu'il n'a pas compris grand chose.
Ou alors en basant sa Ubuntu sur RHEL ou Novell, il veut pouvoir dire : "Ubuntu = RHEL".
Il veut récupérer le boulot de RHEL à moindre coût et le fournir en même temps que RHEL. Il est clair que Red Hat ne va pas lui macher le boulot. Ben oui, Red Hat comme Canonical est une entreprise commerciale qui fait attention à son pognon.
Son dernier blog (à cette date :-)) :
http://www.markshuttleworth.com/archives/146
Titre : The Art of Release
Voyons les conneries qu'il y a dedans.
To the best of my knowledge there has never been an "enterprise platform" release delivered exactly on schedule, to the day, in any proprietary or Linux OS.
Bullshit.
Et en passant, heureusement qu'aujourd'hui les distributions entreprise ne se lient pas à un planning, mais à des fonctionnalités à fournir au client.
Not only did it prove that we could execute an LTS release in the standard 6-month timeframe
"Entreprise Ready" veut dire qu'il y a des tonnes d'applications tiers disponibles à la sortie de la distribution. Ça veut aussi dire que la hot line a été formée. Ça veut aussi dire qu'il y a de la documentation de qualité. Pas de la doc qu'on va récupérer ici ou là dans un wiki ou dans un README.txt. Ça veut aussi dire qu'il y a des programmes de formation en place, etc.
Ubuntu 8.04 n'a pas du tout démontré ça. Elle a démontré qu'elle fait comme les autres distributions "communautaires" (Mandriva, Fedora, OpenSuse, etc). Presque rien de plus.
As a result, we can commit that the next LTS release of Ubuntu will be 10.04 LTS, in April 2010.
Et ?
Red Hat ou Novell n'a aucune difficulté pour faire (que) ça !
N'importe qui peut le faire.
Fedora, Mandriva, etc le fait très bien !
Le problème n'est pas de fixer une date et de si tenir, mais de fixer la date où une technologie en développement sera founie prêt à l'emploi pour les entreprises.
Se donner comme objectif seulement une date est ri-di-cu-le.
Par exemple RHEL 6 aura très probablement ext4.
Es-ce Mark Shuttleworth pourrait utiliser sa boule de cristal et nous dire quand ext4 sera prêt pour les entreprises ?
J'en doute, même les développeurs n'ont qu'une vague idée.
En passant, Ubuntu est sorti Firefox en version beta.
Je doute que c'était l'objectif d'Ubuntu 8.04...
Les fonctionnalités ont été adaptés à la date. Où est alors la "prédictibilité" dont il se flatte ? Seulement dans une date. On sait maintenant que l'objectif de la sortie d'une LTS est une date...
This represents one of the most extraordinary, and to me somewhat unexpected, benefits of free software to those who deploy it.
C'est extraordinaire pour le département pub...
This is in my mind a very compelling reason for distributions to focus on distribution - that’s the one thing they do which the upstreams don’t, so they need to invest heavily in that in order to serve as the most efficient conduit of upstream’s work.
Je ne comprend rien...
Ou je comprend mais je ne vois pas où il veut en venir ou ne préfère pas voir où il veut en venir...
There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat (RHEL), Novell (SLES) and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that.
Ben qu'Ubuntu le fasse.
Et pour RHEL c'est très facile.
Le cycle de développement d'une LTS est de 6 mois. Le cycle de développement de RHEL est de 6/9 mois (7 mois pour RHEL 5 entre la première beta et la finale). Donc Ubuntu connait suffisament tôt le noyau que va utiliser la prochaine RHEL, la version Gnome, la toolchain, etc.
Red Hat fournit parfois la date de release finale. Mais même dans ce cas il n'y a pas de garantit.
Il est très probable que la prochaine RHEL 6 soit basée sur F10 (certains pensent que ça va être F9, mais j'en doute). Dès que les premiers plannings de F10 seront dispos, on aura probablement confirmation que RHEL 6 sera basée sur F10. Ceci laisse beaucoup de temps à Ubuntu de s'ajuster (probablement autour de 10 mois). Au "pire", il y a 6 mois entre la première beta RHEL (qui est public) et la finale.
Voyons le ridicule dans la situation.
Ubuntu LTS : 04-2008
RHEL 6 : 04-2009 (peut-être)
Es-ce que Ubuntu va retarder son planning d'un an pour être synchro avec RHEL 6 ?
Ubuntu LTS : 04-2010
Es-ce que Ubuntu va avancer son planning d'un an pour être synchro avec RHEL 6 ?
Es-ce que Ubuntu 10-04 va utiliser la même toolchain que RHEL 6 sortie il y a depuis un an à la sortie d'Ubuntu 10-04 ?
Croyez vous 1 milli-seconde que Red Hat va sortir une RHEL 7 le 04-2010 juste pour faire plaisir à Ubuntu ?
Red Hat ne veut pas s'imposer de date.
Sortir une distribution entreprise juste pour être dans les plannings et faire plaisir au département pub est ridicule.
Red Hat sort une distribution lorsque c'est un plus pour ses clients et que ces plus justifient une nouvelle distribution (migration demandant l'installeur, incompatibilité binaire/source pour les services, etc).
Les (possibles) plus pour le client de RHEL 6 est ext4, FreeIPA, KVM (au-lieu de Xen), etc.
Il y a des nouvelles technologies libre, elles demande parfois une nouvelle distribution.
Mais sortir une nouvelle distribution entreprise à date fixe pour ne pratiquement rien apporter aux clients (seulement s'arracher les cheveux en migration, mise à jour, etc) est ridicule. NB: je parle d'un contexte entreprise et pas hobbyiste.
Un petit exemple, RHEL 5.2 est en beta :
https://www.redhat.com/archives/rhelv5-announce/2008-March/m(...)
* Laptop and Desktop Enhancement
+ Suspend and Hibernate improvements
+ Re-base of the top Desktop applications
- Evolution 2.12.3
- Firefox 3
- OpenOffice 2.3.0
- Thunderbird 2.0
+ Updated graphics driversBen oui, passer à Firefox 3 ou OOo 2.3 ne justifie pas une nouvelle distribution (lire le reste de l'annonce, il n'y a pas que ça dans RHEL 5.2 (qui n'est qu'une mise à jour et ne demande qu'un "yum update" qui ne vont pas casser les applis en place, etc)).
Pour avoir OOo 2.3, le client ne veut pas passer à RHEL 6. Il le veut sur ses RHEL 5. Techniquement le passage à OOo 2.3 ne justifie pas une nouvelle distribution.
Ubuntu ne comprend pas ce que veux les entreprises avec le libre.
Les entreprises ne veulent plus de mise à jours juste pour faire plaisir au département pub d'Ubuntu et car ça fait entrer du pognon à Ubuntu. Elles veulent du service ! Elles en ont rien à foutre de changer de distribution si c'est pour 3 fois rien. En tout cas, c'est ainsi pour les serveurs.
Red Hat l'a très bien compris et Red Hat ne vend pas une distribution, mais un service (qui donne accès à toutes les versions d'RHEL). Le client a une souscription pour RHEL, ben il installe une RHEL 4, puis met à jours, s'il le juge utile, vers RHEL 5, puis vers RHEL 6. C'est inclus dans le prix de la souscription (c'est un poil plus compliqué car parfois il n'y a pas correspondance exacte, mais c'est l'esprit). Ce service inclus évidemment le backport des patchs de sécurité pour une version de distribution, les corrections de bug, mais aussi la mise à jours de certaines applis bureautiques comme on l'a vu, ainsi que j'ajout de driver, etc.
Red Hat propose aussi de nouvelle fonctionnalité pour une même version de distribution si ça ne justifie pas une nouvelle distribution.
Avec ce blog, Mark Shuttleworth démontre qu'il n'a pas compris grand chose.
Ou alors en basant sa Ubuntu sur RHEL ou Novell, il veut pouvoir dire : "Ubuntu = RHEL".
Il veut récupérer le boulot de RHEL à moindre coût et le fournir en même temps que RHEL. Il est clair que Red Hat ne va pas lui macher le boulot. Ben oui, Red Hat comme Canonical est une entreprise commerciale qui fait attention à son pognon.
> Lire le journal (81 commentaires, moyenne: 3,6).
Vous avez demandé le commentaire #930177.
Run by 
Cette page a été générée par Templeet en 0.0523s (dont 0.0055 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Autre point de vue...
Il est admis dans les nouvelles méthodes de gestion de projet agiles (scrum et Xp par exemple) que les release doivent plutot être faite à date fixe (avec un perimètre de foonctionnalités changeant).
Pour cela, vouloir synchoniser toutes les distributions et les projets upstream me semble plutot bon (même si je crois que c'est plutot utopique).
Cependant, là où le problème est pris à l'envers, c'est que pour moi, c'est au vu des fonctionnalités ajoutées qu'il faudrait alors choisir si c'est une LTS au moment de la realese et non pas dire celle-ci sera une LTS alors qu'il n'y a pas de bouleversement majeur...
[^]Re: Autre point de vue...
je ne pense pas qu'on puisse comparer un "simple projet web/informatique d'entreprise" aussi complexe qu'il soit avec le developpement d'une distribution gnu/linux.
Le but des méthodes dites agiles est de délivrer de la valeur en continue, pour faire du scrum/xp, il faut une équipe de 5 à 10 gus dans une seule pièce avec des post-its à faire des stand-up meeting tous les matins, ce qui veut dire que la méthode pert de son efficacité en mode distribué ou les developpeurs sont dans des fuseaux horaire differents.
Je conçois l'utilisation de scrum/xp pour des projets précis, limité dans le temps. Les sprints scrum sont en général de 2 à 4 semaines.
Pour moi le developpement d'une distribution est un meta-projet composé de divers autres projets (artefact) avec chacun leur méthodes de developpement xp, en cascade, anarchique. Vouloir "unifier" les méthodes qu'ont choisi ces projets est la meilleure fàçon de mettre le bordel ...
[^]Re: Autre point de vue...
Je voulais juste dire que pour une bonne gestion de projet, il vaut mieux avoir une release à date fixe en taillant dans les fonctionnalités prévues plutot que d'attendre que toutes les fonctionnalités prévues soient développées.
Et ce dotant plus (comme dans une distribution) que le projet dépend de beaucoup d'entitiés.
[^]Re: Autre point de vue...
>Il est admis dans les nouvelles méthodes de gestion de projet agiles
-les nouvelles, méthodes agiles de gestion de projet
ou
-les nouvelles méthodes de gestion de projet sont les méthodes agiles?
Sinon, le client (interne ou externe) normal il s'en cogne de savoir que son site web/annuaire/base de données est sortie en version 0.1 puis 0.2 à date fixe.
Ça arrange éventuellement le chef de projet d'annoncer que tous se passe selon les délais prévus.
Par contre à date fixe, de simple notion d'ordonnancement de tache (genre la construction d'un maison, d'abord les fondations etc...) montre que c'est ahurissant (certaines fonctionnalités sont atomiques, on ne peut pas découper les fonctionnalités indéfiniment, certaines sont requises pour d'autres, etc...)
Donc, cet "admis" par qui?
P.S. nouveau pour les méthodes agiles c'est comme NTIC plutôt que TIC (combien de points au business loto?)