La distribution GNU/Linux "Ubuntu" est probablement celle qui jouit de la plus importante notoriété parmi le grand public. Actuellement, une nouvelle version est publiée tous les six mois. Six mois ça peut paraître court, et bien visiblement c'est au contraire trop long pour certains, notamment Scott James Remnant, qui voudrait bien sortir une version tous les mois.
L'article sur generation-nt.com nous explique :
c'est dans l'ère du temps avec Google Chrome puis Firefox, les cycles de développement ont tendance à évoluer pour devenir plus rapides.
Ubuntu cédera-t-elle à ce qui n'est peut-être qu'une nouvelle mode de la course au numéro de version ? Au moins comme ça les numéros de version entre X.04 et X.10 serviront à quelque chose... Qui sait, peut-être verra-t-on Ubuntu en rolling-release dans 2 ou 3 ans ?
J'espère que Debian restera fidèle à sa politique de « ça sort quand c'est prêt » et ne suivra pas le mouvement. Bien que Debian s'interroge également sur la longueur du cycle de sortie des nouvelles versions...
Les anglophones pourront consulter le blog de Scott où il donne ses arguments en faveur de ce changement.
# Cycle de développement
Posté par Reihar . Évalué à 3.
Je dois dire que j'ai un avis assez mitigé sur cette idée.
Le modèle actuel est un bon compromis entre le ça sort quand c'est prêt et la rolling release, toutes deux visant un public spécifique. Le modèle de la version tous les six mois s'adapte, à mon avis plutôt bien Madame Michu qui n'aime pas faire ses mises à jour.
Après, je ne vois pas vraiment ce que ça peut apporter. Réduire le risque de casse ? Attention, je ne dis pas qu'Ubuntu casse systématiquement à chaque mise à jour majeure, juste que ça peut arriver.
[^] # Re: Cycle de développement
Posté par Framasky (site web personnel) . Évalué à 7.
Moi ça m'est arrivé à chaque fois sur l'ordi d'une amie. Marre => Debian, comme chez moi. Depuis ? Plus de problème.
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à 1.
Je trouve debian un peut trop stable (comprendre lente pour les mises à jour [à part la sécurité, bien entendu]) pour un desktop. En testing, ça peut être un peu plus intéressant pour la fréquence des mises à jour mais je pense qu'une bonne distribution de devrait pas avoir à être utilisée en testing pour être intéressante, et ce, même si le testing rend toujours les choses plus intéressantes.
C'est pour ça que je n'ai aucun problème à conseiller Debian en serveur mais que je me montre un peu plus réservée pour le desktop. Et le premier qui vient troller sur le desktop linux, je l'envoie au coin écouter du Justin Bieber !
[^] # Re: Cycle de développement
Posté par zebra3 . Évalué à 6.
En plus, la testing est à éviter en ce moment sur le desktop, vu que GNOME 3.0 y arrive module par module, et on se retrouve avec un hybride entre la 2.30 et la 3.0;
D'autant que certains de ces modules y arrivent incomplets, comme seahorse qui est en version 3.0, mais seahorse-utils (qui comprend l'intégration à Nautilus) n'est qu'en 2.30...
Bref, pour rester sur GNOME 2.30, restez sur Stable (mais ne comptez plus sur les dernières versions de certains logiciels comme Shotwell ou Pitivi).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Cycle de développement
Posté par Marotte ⛧ . Évalué à 5.
On fait ça dépend des fois je dirai... Quelques mois après sa sortie, la Debian stable est un très bon conseil pour un desktop à mon avis. Par contre il est vrai que 3 ans après sa sortie c'est surement moins le cas.
J'ajouterai que la plupart des utilisateurs n'ont absolument pas besoin des dernières versions des logiciels qu'ils utilisent. Ils préfèrent des logiciels un peu vieux mais qui marchent à des versions très récentes qui plantent. J'ai notamment le souvenir d'une version d'Ubuntu qui est sorti avec un Ardour inutilisable ! (Dialogue d'import de fichier inutilisable). Bug pourtant corrigé très rapidement par l'upstream mais les utilisateurs d'Ubuntu ont dû attendre six mois pour que ça fonctionne[1]... Je crois pas que l'on ait déjà vu une chose semblable chez Debian.
[1] J'imagine bien que les utilisateurs d'Ardour utilisent plutôt d'autres distributions orientées M.A.O, donc c'est pas si grave. Mais ça fait tâche quand même...
[^] # Re: Cycle de développement
Posté par claudex . Évalué à 3.
Ces derniers temps, une nouvelle version de debian sort, plus ou moins, tous les 2 ans, ça risque d'être difficile, sauf si on installe une oldstable mais là il faut le chercher. Mais je te rejoins sur le fait qu'une partie des utilisateurs s'en foutent que leur version ne permettent pas de faire clignoter un pixel sur deux quand on n'appuie sur ctrl-alt-shift-a-b-c-d-e-f (moi, je ne peux pas m'en passer mais du coup, je en suis pas en debian stable sur tous mes pc).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Debian et moi
Posté par Marotte ⛧ . Évalué à 0.
J'ai tourné un moment en testing mais j'ai vite arrêté. Tant qu'à taper dans un truc d'équilibriste je préfère carrément unstable. Ça pète parfois par endroit, il y des bugs à la con par-ci par-là. L'intérêt que j'y vois personnellement, quand j'ai à me casser les couilles pour éviter/réparer un bug, c'est que ça permet d'apprendre et de maintenir ses connaissances sur le fonctionnement interne du système, de la distribution.
D'un autre coté c'est pas mon poste professionnel, j'aurais choisi stable sans hésiter, et si jamais tout me pète à la gueule j'ai des solutions de repli.
Cependant depuis presque 10 ans, j'ai réinstallé une seule fois, non pas parce que rien ne fonctionnait plus, j'avais juste pas envie de trier le bordel que j'y ait foutu durant 5 ans :) Là ça fait pas loin de quatre ans que j'ai réinstallé, ça m'a toujours pas explosé entre les mains.
Après, l'impossibilité de renommer un onglet dans Calc pendant 6 mois ou ce genre de truc, c'est juste chiant mais c'est pas la mort. D'ailleurs je me dis que je devrais holdé LibreOffice pendant que ça marche bien. En plus ça m'éviterait pas mal de Mo à télécharger lors des updates.
Testing c'est clairement pour les gens doués et ayant une vrai envie de participer pour améliorer Debian en testant et en remontant les bugs. Et c'est pas toute l'année si j'ai bien compris le système de freeze. (ie : hors freeze on s'en fout un peu des remontés de bugs de testing) Il faut aussi des rapports de bugs pour stable pour finir de virer les quelques bugs qui restent...
[^] # Re: Cycle de développement
Posté par Efemero (site web personnel) . Évalué à 1.
J'ai essayé ctrl+alt+shift+a+b+c+d+e+f rien ne clignote...
[^] # Re: Cycle de développement
Posté par bubar🦥 (Mastodon) . Évalué à 1.
J'imagine que les utilisateurs de Ardour aimeraient bien pouvoir utiliser la même distribution que tout le monde. Donc c'est grave.
J'rebondis sur ton commentaire parcequ'il est un bon exemple de la problématique du desktop linux Et, //mode évidence : je suis d'accord avec ton commentaire et on s'en fout.
Pourquoi grave ? C'est vraiment un bon exemple du traitement des utilisateurs par les distributions (attention, le mot distribution sera remplacé, implicitement, au cours de ce commentaire). En fait, il est fort probable que la majorité des utilisateurs catégoriels aimerait aussi utiliser une distribution standard. Peut être même tous, hormis quelques kékés qui s'tapent la branlette de l'optimisation à tout prix. Or, actuellement ce n'est pas le cas. Les utilisateurs sont obligés d'utiliser des distributions "spécialisées". Et ça a un double impact : rarement satisfaits (à part les kékés) individuellement, et globalement un effritement des usages des grandes distributions, par un maintient d'un grand nombre de petites distributions spécialisées. (me faite pas dire ce que je ne dis pas : non la diversité n'est pas un problème.) Ce qui entraîne certainement aussi un effritement des compétences (par exemple, ce bug sur Ardour, il était présent dans Ubuntu mais pas dans Ubuntu Studio, est ce une situation normale ?)
Un utilisateur de logiciels spécialisés musique est contraint d'utiliser une distribution spécialisée. Il ne peut pas installer une distribution classique et y ajouter un dépôt répondant à sa catégorie d'usage. Il n'a que le choix Debianesque de la stabilité absolue pour tout au détriment des mises à jour. Un utilisateur de logiciels musicaux n'installera pas Debian, parcequ'il serait contraint ne pas avoir l'avant dernière version de X apportant la fonctionnalité Y, dont il se faisait une joie d'utiliser...
On peut décliner ça à l'infini : utilisateur de logiciels bureautiques (LibreOffice, Scribus), il sera contraint d'aller chercher le binaire, àlawindows, ou de compiler le bousin. Utilisateur de jeux libres, il va installer une distribution "spécialisée" ou utiliser des backports plus ou moins stables, et plus ou moins impactant sur son système. Un utilisateur de ... Bref à l'infini.
Dès lors que l'on admet qu'il n'y a pas que deux catégories d'utilisateurs : ceux voulant du stable, et ceux voulant les dernières versions de tout, on admet qu'il y a un problème et on le regarde en face. Les utilisateurs fonctionnent par catégories. Oui il y a ceux qui veulent du stable à tout prix, et se fichent de la version qu'ils utilisent. Oui il y a ceux qui préfèrent "de vieilles versions qui marchent". Oui il y a les kékés qui veulent tout, l'argent du beurre et le sourire de la crémière. Mais ils y a aussi un grand nombre d'utilisateurs qui aimeraient sans doute utiliser le même système que tout le monde, et utiliser dessus leur choix de logiciels en fonctions de leur domaine d'activité sans que cela impacte leur système.
Voilà le terme "distribution" a effectivement été remplacé implicitement. Mais je me garderai bien de lancer le troll du static dans /opt, avec des dépôts de la distribution, classés par catégories d'usage. Parceque ce n'est qu'une idée, et si elle n'a pas été retenue, il y a des raisons. Donc je me garderai bien de lancer "une idée de solution", juste poser le problème. Problème qui semble être assez central et majeur des "desktops linux", et qui impacte de manière nuisible un potentiel développement d'usages.
[^] # Re: Cycle de développement
Posté par bubar🦥 (Mastodon) . Évalué à 2.
et à force de pas trancher cette question, on va tous finir indagooglecloud
[^] # Re: Cycle de développement
Posté par ianux (site web personnel, Mastodon) . Évalué à 4.
Je ne comprends pas trop ta problématique. Tu voudrais qu'une distrib spécialisée puisse être généraliste ? Ou l'inverse ? Tu as compris tout seul que ce n'est pas possible, c'est bien pour ça qu'il y a les 2 genres de distrib. Encore que, dans Ubuntu Studio, par exemple, il y a Ubuntu, donc avec les dépôts généralistes, rien ne t'empêche d'installer Open Office ou n'importe quoi d'autre qui n'es pas installé de base, et donc d'en avoir un usage desktop standard.
Mais la musique est un bon exemple, toute distrib orientée audio fournira un noyau temps temps réel patché comme il faut, avec jack installé par défaut et toute les applis compilées pour, avec une conf système aux petits oignons, etc... Toutes sortes de choses inutiles pour un bureau standard, voire même contre-productives.
Bref, pour moi, les distrib spécialisées (qui pour le son, qui pour le routage, qui pour le forensic, qui pour tenir sur une disquette...) sont une des grandes forces du libre.
[^] # Re: Cycle de développement
Posté par bubar🦥 (Mastodon) . Évalué à 3.
C'est une des forces du libre, oui, il n'y a pas de contestation de cela dans mon commentaire. C'est une force plus pour y participer que pour l'utiliser, souvent.
Il y a besoin d'installer un système pour ça ? Non, le système de base sait le faire : être modifié pour être en adéquation avec l'usage, avec le domaine d'activité.
Plus à jour. Plus besoin d'avoir le patch _rt depuis, pfiou... La majorité des avancées de ce patch ont été intégrées à la branche principale. Celles restantes concernent plus les électroniciens que les musiciens, il me semble bien (...). Enfin, l'usage du noyau RT avec Jack est un exemple kékés. La majorité des besoins dont l'usage de jack découle n'ont pas de nécessité de noyau RT, ni de configuration système fine. Le RT et Jack en RT ne concerne que quelques usages dans la vaste catégorie musique. C'est effectivement un bon exemple, tu vois ?
Je ne voudrais rien. Je me contente très bien de ma distribution actuelle telle qu'elle est. Mais le personnel n'est en question ici.
Non.
Que l'utilisateur puisse installer une distribution standard, classique, genre Debian, et l'utiliser pour son domaine d'activité, avec les dernières versions stables des logiciels, tel que les projets eux mêmes les définissent comme stable. Que l'utilisateur de bureautique puisse avoir la dernière version de LibreOffice et de Scribus, sur son système stable, avec un empaquetage de qualité. C'est pas compliqué à comprendre ?
Et cela se décline en secteur d'activité, effectivement : bureautique, musique, sysadmin, électronique, etc etc.
Aujourd'hui l'utilisateur à trois choix :
Installer une Debian stable, et ne jamais avoir les dernières versions des logiciels de son secteur d'activité.
Installer une distribution spécialisée. Qui souvent n'apporte pas ce qu'apporte un système plus standard.
Installer un système instable, pour quelques logiciels récents de son domaine d'activité.
En plus des problèmes pour l'utilisateur (qu'on ne va pas re-lister encore une fois ici : switch vers de petites distros, ras le bol retour windows ou sur mac clique on installe, avoir un système instable, avoir des logiciels obsolètes, etc etc) il y a les inconvénients pour les distros (effritement des forces, multiplication des chemins de retour, etc etc).
Chaque distro cherchent à répondre à cette problématique à sa façon. Debian en proposant les backports, comme d'autres. Fedora en mettant à jour ce type de logiciels tiers sans attendre la nouvelle version du système (...) Donc visiblement le problème est parfaitement identifié. La solution pas encore trouvée. Quoique Fedora est devenue exemplaire sur ça.
Je ne sais pas si tu cherches à noyer le poisson, où a vraiment poser une question. Et je ne sais pas pourquoi j'ai remis cette question sur le tapis, tellement souvent il a été noyé que j'ai fini par abandonner.
[^] # Re: Cycle de développement
Posté par bubar🦥 (Mastodon) . Évalué à 0.
Désolé pour les deux commentaires précédents. Inutiles.
[^] # Re: Cycle de développement
Posté par Marotte ⛧ . Évalué à 7.
Alors là non, ça m'arrange pas ! Moi j'ai besoin d'un avis bien tranché, en mode tête de mule avec une bonne dose de mauvaise foi et des insultes gratuites. Sinon comment veux-tu troller ?
[^] # Re: Cycle de développement
Posté par fearan . Évalué à 1.
En postant un journal de ce genre un jeudi après midi, pour déclencher tous les commentaire disant que les trolls c'est le vendredi, et d'autre pour leur répondre que c'est presque vendredi ;)
Bon personnellement ils font les conneries qu'ils veulent, je ne suis pas sous ubuntu.
P'têtre que lorsque les gens en auront mare de voire leur distrib cassé tous les 2/3 mois ils iront voir ailleurs et iront utiliser de vrai distrib ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Cycle de développement
Posté par Altor . Évalué à 3.
Pour moi, le mieux c'est d'avoir une base solide qui sort tous les X mois avec la possibilité d'avoir les logiciels que l'on utilise tous les jours dans la version que l'on veut et dont on a besoin. Par exemple, firefox, libreoffice, inkscape …
Malheureusement ce modèle est dur à obtenir à cause de la gestion des dépendances car, dans ce cas-là on est obligé de passer par la case compilation. Le binaire universel ne peut fonctionner car si on veut les dernières versions, souvent c'est parce que l'on a une utilisation spécifique et du coup, on veut pouvoir le lier avec certaines librairies plus ou moins stables.
[^] # Re: Cycle de développement
Posté par StreakyCobra . Évalué à 3.
Je ne suis de loin pas spécialiste, mais les branches backports genre celle de debian ne repondent-elles pas à ce que tu dis?
[^] # Re: Cycle de développement
Posté par Altor . Évalué à 3.
Si en partie. Il est toujours difficile de choisir de lier différemment ses logiciels. Par contre, slackware et ses slackbuilds répondent parfaitement à ça :)
[^] # Re: Cycle de développement
Posté par ianux (site web personnel, Mastodon) . Évalué à 1.
Mieux, tu as Archlinux qui est en rolling release et qui propose ABS et AUR !
De la part d'un ancien utilisateur de Slack qui n'a pas connu (ou trop tard) les slackbuilds...
[^] # Re: Cycle de développement
Posté par Altor . Évalué à 3.
Non, car Archlinux ne propose pas de base stable. Ok, elle ne plante jamais, il n'y a pas de problème… Mais l'avantage de Slackware c'est que tu as une base stable et patché et tu es en rolling release que sur les logiciels dont tu as vraiment besoin. Tu as même la possibilité d'avoir plusieurs versions de la même lib.
Pour reprendre l'exemple de tankey, imagine que quelqu'un veuille faire de la M.A.O à un niveau professionnel (j’entends par là un bon niveau sans forcement une rémunération) avec la Slackware il peut bénéficier d'une distribution réputée fiable et la même que son collègue qui lui par contre est spécialisé en développement web.
Imagine l'avantage pour une boite. Elle, ce qu'elle veut c'est maintenir une seule distribution alors qu'elle a plusieurs domaines d'expertises. Elle veut pouvoir faire du développement électronique, de la bureautique, des calculs scientifiques, un serveur mail … Et chacune de ses branches veut travailler avec les logiciels à la pointe de la technologie. Tu lui dis quoi ? Alors pour les utilisateurs de base (qu'est-ce que c'est ? les secrétaires ?) il vaut mieux prendre Ubuntu, pour le serveur mail Debian, pour le calcul scientifique Scientific linux … Aucune de ces distributions ne se met à jour en même temps, du coup, tu auras des utilisateurs avec openoffice, d'autre libreoffice …
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à 0.
Dans ce cas, ma réponse va paraître audacieuse mais il y a Gentoo. Il y a une branche stable et on peut piocher dans l'instable au cas par cas.
Mais de la compilation systématique, ça peut poser quelques problèmes, c'est long et consommateur en ressources. Et puis, ça nécessite de tout configurer, ce qui pose problème à l'utilisateur de base, même si la doc est très bien faite.
[^] # Re: Cycle de développement
Posté par Altor . Évalué à 2.
Je ne connais pas bien gentoo, mais si on doit recompiler sur chaque PC, aucune boite ne voudra ça.
Sur slack le système de slackbuild permet de construire un paquet que tu peux installer partout.
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à 0.
Si les PC ont tous la même architecture, on peut redistribuer les paquets sur un réseau local.
Et on peut aussi faire de la compilation croisée donc il suffit d'une machine de compilation/distribution de paquets.
[^] # Re: Cycle de développement
Posté par Altor . Évalué à 2.
Juste pour préciser, par architecture tu entends bien x86, x86_64 … ?
Sinon, c'est pareil pour slack (la compilation croisée).
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à 0.
Oui, je parlais bien de l'architecture de processeur. On peut également être bien plus précis en compilant du code optimisé pour processeur de type i5/i7 (J'ai oublié le nom exact de l'architecture.).
[^] # Re: Cycle de développement
Posté par Jux (site web personnel) . Évalué à 2.
ArchLinux n'est pas et ne sera jamais grand public. La distribution est clairement orientée utilisateurs avertis et demande de la config à la main. Je suis un utilisateur d'ArchLinux comblé, mais ça restera une distribution minoritaire en terme de nombres d'utilisateurs. Les AUR (Arch User Repository) requierent de savoir ce qu'on fait et de faire gaffe aux dépendances pour ne pas foutre le bordel monstre. Berf, Arch ça rox, mais c'est réservé à ceux qui ont les connaissances et qui veulent prendre le temps. A mille lieux d'Ubuntu.
Par contre, effectivement, le concept de rolling release d'Arch est intéressant. Finalement, j'ai deux catégories de logiciels :
- ceux que je n'update jamais (Xorg, kernel) parce qu'ils fonctionnent bien et qui ont un risque important de me casser le système lors d'une mise à jour
- les logiciels end user que j'update régulièrement car j'ai envie d'avoir les dernières avancées
Je pense qu'Ubuntu peut réussir à arriver à un système dans le style. Il est illusoire de vouloir mettre à jour X.org et le kernel en rolling release. J'ai beaucoup de connaissances à qui j'ai installé Ubuntu qui ont peur de faire les mises à jour d'une version à l'autre car ils ont trop vécu la situation où X.org ne démarre plus. Par contre, ça doit être faisable pour les applications "utilisateur final".
[^] # Re: Cycle de développement
Posté par Marotte ⛧ . Évalué à 1.
La question c'est : "À quel niveau tu situes la limite base, pas base ?"
[^] # Re: Cycle de développement
Posté par totof2000 . Évalué à 3.
Ben disons que ça arrive de plus en plus ... :)
Le tout est de savoir combien de temps une version donnée sera maintenue. Pour ma part lors des mises à jour majeures, j'attends au moins 1 mois pour la faire (plus lorsqu'il y a eu des changements profonds, style changement d'environnement graphique). Si le système adopté me permet de sauter une ou deux versions sans problème de sécurité, ça ne me dérange as plus que ça. Par contre si ça force la mise à jour, ben là, non.
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à -2.
Une mise à jour n'a pas à être forcée. On peut la recommander vivement avec des icônes rouges qui clignotent en disant "DANGER METTEZ A JOUR SINON VOTRE ORDINATEUR VA EXPLOSER ET TUER DES CHATONS !", mais pas la forcer.
Pourquoi ne pas bloquer le port 25 pour réduire le SPAM ? ... Oubliez-ça.
[^] # Re: Cycle de développement
Posté par stopspam . Évalué à 1.
C'est tendancieux. Indirectement, tu fais croire que rolling release ne sort pas quand c'est prêt. Ça veut dire quoi "être prêt" ?
[^] # Re: Cycle de développement
Posté par Anonyme . Évalué à 2.
Pas tout à fait. Ça c’est du Rolling Release à la Arch (et non pas à la Rache).
En fait une Rolling Release c’est surtout une distribution sans version définie et qui évolue continuellement.
[^] # Re: Cycle de développement
Posté par Marotte ⛧ . Évalué à 1.
Debian aussi évolue continuellement.
J'aurais tendance à dire qu'un distribution à publication/livraison/libération continue essaye juste d'avoir le cycle le plus court possible. Un lâcher tous les deux ou trois jour quoi...
[^] # Re: Cycle de développement
Posté par Marotte ⛧ . Évalué à 1.
Forcément avec des nouvelles versions, des fois séparées de seulement quelques heures, on ne compte plus...
[^] # Re: Cycle de développement
Posté par Reihar . Évalué à -2.
Je vais reformuler. C'est un bon compromis entre ça sort quand on considère que c'est prêt et ça sort quand c'est prêt.
# Marrant ça ...
Posté par soulflyb (Mastodon) . Évalué à 7.
Juste au moment où Mandriva retourne à un cycle d'une release par an ...
[^] # Re: Marrant ça ...
Posté par Misc (site web personnel) . Évalué à 7.
Ceci dit, la 2011 est sorti avec 2 mois de retard sur le planning ( ce qui montre que quand on double le temps pour le travail, ça ne change rien car on a tendance à aussi doubler les taches à faire voir plus ).
Et il y a eu un certain nombre de personnes qui ont poussés des fonctionnalités en se disant "si je le fait pas maintenant, faut attendre 1 an", mais qui ont eu dieu merci les 2 mois de retard pour stabiliser. Il suffit de voir les réactions autour de la version du kernel ( http://forum.mandriva.com/en/viewtopic.php?f=35&t=135407 ) ou de xorg ( http://forum.mandriva.com/en/viewtopic.php?f=35&t=134793 ) pour voir que les gens veulent des logiciels récents pour des questions de support hardwae.
On voit bien le noeud du problème. Les gens veulent que la couche basse soit à jour ( xorg, kernel ) pour supporter le matos, et avoir les applicatifs à jour ( pas tous, juste ceux qui sont utilisés par tout le monde comme gnome, kde, firefox libroffice, etc ). Mais pas la distro. Sauf que si on retire xorg/udev/kernel/etc, et firefox/libreoffice/gimp/etc, et le wm, il reste quoi ? La glibc, la libpng, ruby, python ?
[^] # Re: Marrant ça ...
Posté par claudex . Évalué à 3.
Debian backporte une partie des drivers dans son noyau, ce qui fait qu'il supporte du matos plus récent qu'au moment de sa sortie, ça résout une partie du problème.
Avec les backports disponible mais pas en update automatique, ça permet aux gens de choisir s'il veulent la version plus récente ou s'ils s'en foute. C'est une solution mais ça demande beaucoup de boulot.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Marrant ça ...
Posté par Misc (site web personnel) . Évalué à 4.
Sauf que c'est pas si simple que ça. Quand tu refactorises le code des drivers ( ce qui arrive quand même assez souvent, je pense ), tu peux pas aussi facilement backporter le tout, ou du moins, pas sur la durée. Quand il y a une nouveauté ( genre des cartes avec 2 chipsets comme pour xorg ), faut mettre à jour plus que les drivers. Quand il y a des changements ailleurs, faut faire gaffe à l'impact ( exemple, udev, etc ).
Et les backports, c'est juste une façon déguisé de faire des mises à jours de version en faisant croire aux gens que ç'est mieux testé et que ça casse rien. En pratique, soit tu forkes l'upstream ( et on arréte pas aussi de dire "faut arreter de dupliquer les efforts entre distros" ), soit tu fait une montée de version.
Et dans un cas, tu as une version custom avec le cout de maintenance associé, dans l'autre, tu as juste réussi à faire une mise à jour sans le dire, ce qui ne change rien au probléme.
[^] # Re: Marrant ça ...
Posté par bubar🦥 (Mastodon) . Évalué à 1.
ça demande beaucoup de boulot.
ça frustre les utilisateurs parce que les backports n'ont pas la qualité de la distribution.
ça épuise les contributeurs parce qu'ils n'ont pas la satisfaction des utilisateurs.
bref, les backports, pour les avoir vu fonctionner pendant longtemps dans mandriva, je ne le recommenderais à personne, même pas à Debian (pour la touche d'humour)
Ubuntu apporte sa réponse à la question, si elle suit l'idée de Scott James Remnant. Toujours proposer des logiciels très à jour, très proche de ce que les projets nomment eux même leur production comme stable. Tout en réduisant les impacts éventuels sur le système. Est ce meilleur que du static dans /opt : une séparation tranchée entre système et logiciels tiers ? En tout cas, ça semble mieux pour le desktop linux chez le particulier.
moinssez moi, moinssez moi, moinssez moi, c'est le chant du commentaire
[^] # Re: Marrant ça ...
Posté par claudex . Évalué à 4.
Justement, ça marche plutôt bien dans Debian. Parce qu'il s'agit juste d'une recompilation des paquets de testing avec les libs de stable. Le travail supplémentaire n'est pas pas trop élevé. Debian est d'ailleurs la seul distrib que j'ai vu avec des backports corrects.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Bah pourquoi ?
Posté par j_kerviel . Évalué à 4.
Ben Debian a déjà une version testing en constante évolution (mis à part pendant les périodes de freeze. C'est pour ça qu'un projet CUT a été monté.)
Donc pourquoi Debian s'inspirerait d'Ubuntu qui va de facto moins vite qu'une testing ?
Dernièrement ?
Parce que moi j'en étais resté au freeze fixe tous les deux ans. Mais ça date.
Il y a eu du nouveau depuis ?
[^] # Re: Bah pourquoi ?
Posté par Marotte ⛧ . Évalué à 2.
Oui ils parlaient d'entrer en période freeze à dates régulières tout en continuant de sortir "quand c'est prêt". J'ai la flemme de chercher le lien, honte sur moi.
Par contre du coup je m'interroge : Si le freeze dure 1 an et demi, on fait le freeze suivant 6 mois après la release ?
# de la folie pure
Posté par GeneralZod . Évalué à 5.
Pour résumer:
* ce n'est pas une rolling release
* c'est un cycle de développement de 1 mois, on compresse encore plus les phases de développement.
* une cadence infernale: on n'a plus le temps ni même le recul pour développer/corriger les fonctionnalités.
* moins de testeurs: les développeurs bossent dans leur coin et leur travail n'est reversé dans le master que lorsque c'est prêt (l'assurance de n'avoir aucun retour des utilisateurs)
* échec garanti: Canonical a déjà du mal à tenir une cadence de 6 mois/18 mois pour les LTS, alors des cycles de 1 mois, c'est peine perdue.
En bref, je me demande qu'est-ce qu'on lui donne à fumer au père Scott chez Google ? Ce qui marche pour chromium (avec le résultat qu'on connait: bibliothèques forkés sauvagement inclus dans le tronc, réinvention du système de construction, gestion désastreuse et brutale de la communauté, bref un joli tas de merde bien emballé) ne marchera pas dans une distro (pas le même scope, pas le même niveau d'exigence qualité y compris chez Ubuntu -enfin j'espère qu'ils n'oseront pas descendre aussi bas dans la merditude et qu'ils continueront à essayer de se rapprocher du niveau de qualité de la distro maman aka Debian)
[^] # Re: de la folie pure
Posté par Ronan BARZIC . Évalué à 3.
J'ai l'impression que tu n'as bien bien compris sa solution pour l'introduction de nouvelles fonctionalités C'est fait dans un ppa à part, non soumis au cycle de 1 mois et accessible par les volontaires.
Ben justement, il ne veut pas que ce soit l'utilisateur lambda qui découvre les problèmes, parce que ca entraine une dégradation de l'image de qualité de la distri.
Pour ma part, c'est une idée qui bouscule (un peu) les habitudes, qui semble étayée par des arguments recevables (enfin plus recevable que de l'accuser de fumer comme dans la dépêche originale). Pourquoi pas essayer ? Je ne pense pas qu'Ubuntu risque grand chose si la chose est gérée intelligemment.
[^] # Re: de la folie pure
Posté par GeneralZod . Évalué à 3.
Dans un coin, donc jamais testé. Déjà que pour les versions de développement (alpha, béta etc ...) c'est la misère pour trouver des testeurs, si tu dois foutre chaque nouvelle fonctionnalité dans un truc à part, t'auras forcément moins de monde pour tester, c'est mécanique.
L'utilisateur lambda n'installe pas les versions de développement, si tu lui fais faire des mises à jours tout les mois:
soit t'es ultra conservateur: ubuntu perds tout intérêt par rapport à une debian unstable
soit tu ne l'es pas: l'utilisateur va s'en manger plein la gueule, c'est mécanique.
Ils ont déjà du mal à tenir le rythme de 6 mois, alors 1 mois ... 3 mois aurait été envisageable si on limite le nombre de paquets supportés mais 1 mois c'est un rythme bâtard et intenable par la communauté. Passer à un système de rolling release aurait été plus sensé (d'autant qu'avec les PPA, c'est faisable techniquement)
[^] # Re: de la folie pure
Posté par jbbourgoin (site web personnel) . Évalué à 3.
Si j'ai bien compris l'argument du monsieur, c'est précisément l'inverse qui, selon lui, doit se produire. Pour lui une période de 1 mois permet d'avancer par petites touches mieux gérées et étalées qu'un gros bloc sur 6 mois qui touche des trucs trop sensibles pour faire le boulot dans les temps et/ou proprement.
Mais bon, j'ai lu en diagonale, j'ai peut-être mal compris :p
[^] # Re: de la folie pure
Posté par GeneralZod . Évalué à 5.
Dans les faits, les testeurs sont peu nombreux, les testeurs qui font des retours le sont encore moins, des testeurs productifs ça se compte sur les doigts. Si tu développes les fonctionnalités dans un PPA à part, la plupart des mecs n'activeront pas parce que ça ne les intéressera pas, parce qu'ils n'y penseront pas etc ...donc mécaniquement moins de testeurs (alors qu'il en faudrait plus !)
Sans compter que certains composants ont un cycle de développement plus long qu'un mois donc le temps d'arriver à un truc stable, bah tu retrouveras avec un cycle de test d'environ 1 mois ou 2 mois au lieu de 4 à 6 mois (donc les développeurs upstream auront beaucoup moins de retours et potentiellement moins de temps pour corriger les bogues).
La proposition de SJR ne fonctionne que si on a un fonctionnement type cathédrale "je maitrise tout le code", ça marche pour chromium, ça ne marchera pas avec une distro GNU/Linux qui fonctionne selon un mode bazar.
[^] # Re: de la folie pure
Posté par Ronan BARZIC . Évalué à 2.
Je ne suis pas forcément d'accord. Actuellement, tester une Ubuntu RC, c'est mettre à jour l'ensemble de sa distribution avec le risque de ne rien pouvoir faire (genre écran noir pour mauvais support de sa carte graphique), ce que peu d'entre nous peut se permettre de faire si on utilise sa distrib tout le temps.
Par contre, si je peux sélectivement, "en avance de phase", tester certains composants (pour moi, ca serait emacs et des outils de devs), pas de pb - je peux prendre le risque sachant qui sera sans doute possible de revenir à la version officielle - Et si ca ne l'est pas, ca ne rend pas forcément la distrib inutilisable pour autant.
Pour des modifs plus majeures (installateur, bureau,etc..) , il y a aura forcément plus de personnes intéressées par le test vu les conséquences
[^] # Re: de la folie pure
Posté par Marotte ⛧ . Évalué à 1.
Tous les six mois :
* Mettre à jour ses sauvegardes.
* Se préparer, éventuellement, à réinstaller (CD, pop-cron)
* Passer de 15 min à 4 heures (selon le point 2) a reconfigurer son "interface au petits oignons"
C'est pas le bonheur :)
Tu peux aussi utiliser Ubuntu LTS, c'est seulement tous les trois ans. Mais c'est plus intense forcément !
[^] # Re: de la folie pure
Posté par zebra3 . Évalué à 3.
On peut déjà. Il suffit d'activer le dépôt de développement et de configurer ses préférences pour n'en installer que certains paquets.
Un peu comme Debian experimental quoi. En gros, tout est déjà conçu pour faire ce qu'Ubuntu prépare : man apt_preferences.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: de la folie pure
Posté par Prae . Évalué à 2.
Tu es un peu entrain de critiquer la méthode Agile: sortir des releases rapidement pour coller à ce que veut le client. Et non pas attendre 2 ans pour sortir le produit suivant le cahier des charges.
Perso, ca me va, je préfère avoir des releases régulièrement avec des ajouts périodes que d'avoir un gros truc de 300 Mo et après tu te démerdes pour trouver toutes les nouveautés.
[^] # Re: de la folie pure
Posté par GeneralZod . Évalué à 3.
Loin de là, primo, entre un projet logiciel et une distro l'échelle n'est pas la même (sans compter le déphasage inéluctable avec les projets upstream), secundo tu confonds itération et cycle complet (à l'origine le cycle de 6 mois introduit par GNOME repris par Fedora puis Ubuntu est par essence agile), tertio avoir des releases tout les mois, certes tu auras un diff plus petit mais parce que derrière, les développeurs passeront moins de temps à développer (lors d'une itération, certains délais sont incompressibles comme la QA), une itération d'un mois c'est trop court pour développer des fonctionnalités majeures/tester/valider et qu'en plus tu auras moins de testeurs alors qu'en pratique on en manque cruellement.
Projets agiles != projets bouclés en quelques semaines
[^] # Re: de la folie pure
Posté par bubar🦥 (Mastodon) . Évalué à 2.
Bien que tu ne le fasse pas dans ce commentaire directement, on ne peut s'empêcher en te lisant de lire aussi "fedora" entre les lignes.
Et tout le monde ne pas suivre le rythme Fedora, surtout depuis presque deux ans (c'est ça ?). Un utilisateur comme moi qui installe une Fedora a de grandes chances d'être très satisfait : une distribution à la fois stable et à jour. Avec des logiciels tiers à jour et stable eux aussi (dépôts audio, électronique, sysadmin, etc etc). Et sans avoir besoin d'artifices tels que des mises à jour plus incrémentales ou un /opt transformé en \programfiles avec la remise en cause du fonctionnement même des _packages managers au final. Bref du bonheur, clairement, objectivement. Mais tout le monde ne peut pas suivre ce rythme en gardant cette qualité, visiblement.
Les mises à jour plus incrémentales semblent être une solution sympa pour répondre à la même problématique, autrement et plus simplement : avoir un système stable et des logiciels tiers très à jour.
ps : des dépôts de binaires statiques destinés à /opt permettraient d'augmenter drastiquement le nombres de testeurs, pour les retours au projet upstream. Le système reste stable, les utilisateurs ne sont pas obligés d'avoir un système cassé la moitié de l'année pour tester des logiciels de leur domaine d'activité. Ils pourraient même avoir des versions différentes du même logiciel, sans impact. M'enfin bon, c'est juste une idée ça, force est de reconnaître qu'allier les deux est mieux et possible : fedora y arrive.
[^] # Re: de la folie pure
Posté par GeneralZod . Évalué à 5.
Oui, je me base sur mon expérience de développeur fedora (et de contributeur occasionnel à d'autres distros) pour réfléchir à la suggestion de SJR.
Le cycle de 6 mois n'est pas le graal non plus, il a fait ses preuves comme le système de rolling release ou le cycle de plus ou moins 2 ans de Debian. Par contre, le cycle de 1 mois est clairement bâtard entre une rolling release sans l'exigence de la qualité (dans ArchLinux ou Gentoo, ce n'est pas la foire, les nouveautés passent en stable quand c'est prêt, pas le stress de la deadline qui arrive ou d'attendre la prochaine), et un cycle de 6 mois qui permet d'avoir des cycles itératifs tout en gardant une ligne conductrice à moyen et long terme.
C'est même le problème, quelle vision à long terme avec une cadence infernale de 1 mois (oui, c'est intenable à l'échelle d'une distro). La seule façon de tenir, ce serait de réduire le nombre de paquets maintenus mais je vois mal ubuntu le faire, sans compter qu'à ce rythme, bon nombre de contributeurs décrocheront et tu retrouveras avec l'effet inverse, un système de base éventuellement plus robuste (mais moins innovant) et des paquets contrib complétement pétés parce que les mainteneurs n'auront plus le temps de suivre.
Le plus simple, c'est reprendre la recette BSD: un système de base réduit mais cohérent et un système de ports qui évoluent indépendamment. Tu as un système stable car maintenu par une équipe certes réduite mais qui maitrise l'ensemble du code, et des logiciels tiers à jour, car ils évoluent sans dépendre de la base ou des autres ports.
[^] # Re: de la folie pure
Posté par Arathor . Évalué à 2.
Ah on parle de firefox maintenant ?
;-)
[^] # Re: de la folie pure
Posté par rewind (Mastodon) . Évalué à 2.
C'est pourtant de cette manière que fonctionne le kernel et ça marche bien. Est-ce que les mêmes causes ne vont pas produire les mêmes effets ?
[^] # Re: de la folie pure
Posté par claudex . Évalué à 4.
Le développement du kernel n'a rien à voir avec celui d'une distribution. Premièrement, le kernel maitrise son code et ne dépend d'aucun autre composant (occasionnellement de GCC, mais c'est anecdotique) pour sortir une version, une distribution dépend de beaucoup d'autres projets et ne maîtrise pas forcément tout le code ce qui ralentit la correction de bogue¹. Deuxièmement, le kernel peut se permette d'intégrer des fonctionnalité en plusieurs étapes, ce n'est pas toujours possible pour une distribution parce que les logiciels ne lui sont pas livré comme ça, il suffit de demander à ceux qui sont en Debian testing si c'est possible d'intégrer Gnome3 par petits bouts.
¹: il faut que quelqu'un se plonge dans le code ou demander à l'upstream.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.