je suis peut être  un peu naïf sur le sujet, mais je ne comprend pas cette dernière remarque : quelles libs sont en retards sur lesquelles?

La version dans les dépots, par rapport à upstream, ça veux dire que pour que firefox compile sur ubuntu avec les libs ubuntu, ils faudrait passer outre pleins de bugs réglés pour eux depuis, et se passer des fonctionnalités implémentés après… et 18mois c'est long, pour une lib de navigateur, pour un projet aussi actif que mozilla… donc pour eux, ce n'est pas viable… ils aimeraient que tout le monde utilise la version statique, compilé par leur soins…

Oui mais il y a des programmes (critiques) ou l'on ne veux que des mises à jours controllées (les correctifs de sécurité tout le temps, le changements de fonctionnalité uniquemement quand on a le temps de gérer si ça nous pose problème) et d'autre ou on veux le dernier truc à jour, par ce que même si on a des petits soucis, on sait qu'on s'en sortira, et qu'en tout cas l'avantage de la nouveauté surpasse très probablement les risques de problèmes (navigateur).

Les rolling release auront beau tester dans tous les sens qu'aucun bug n'est introduit, on ne peux pas s'assurer que fonctionnellement c'est la même chose, donc sur une machine de travail, une mise à jours tous les 6/18mois est idéal, entre temps, on bosse… on ne veux pas que ça change tous les 4 matins (ou que les glandus de ta distro décident qu'a partir d'aujourd'hui, c'est python3 le python par défaut, te pétant blender, libreoffice, et la moitié de tes utilitaires qui ne demandent que "python" et non pas une version précise).

Bref, pour certains programmes, la rolling c'est cool, pour d'autres on a de bonnes raisons de vouloir un fonctionnement à base de releases ponctuelles (maj de sécu uniquement).

Faire le mélange des deux représente un vrai challege, debian + pinning est une solution partielle, mais on se retrouve rapidement a monter des paquet de stable à testing sans vraiment le vouloir, par le jeu des dépendances…

Debian CUT résoudra peut être ça, peut être qu'aptosid le fait déjà, j'ai pas testé… mais oui, avoir plusieurs versions différentes des libs seraient une solution, mais c'est sacrément complèxe à mettre en oeuvre… (actuellement, quand c'est vraiment nécessaire, on fait plusieurs paquets différents).

@ yohann > wahou ... jolie démonstration à laquelle meme moi j'avais pas pensé ...
en bref c'est le principe complet des logiciels libres que notre amis remet en question avec sa théorie

Bon aller je me lance je suis d'humeur taquine aujourd'hui, mais le principe remis en question ici n'est absolument pas celui des LL, mais celui de la philosophie Unix :

Un OS fonctionnait sur le principe décrit par Galuel serait tout a fait en accord avec le principe des logiciel libre. (mais à mon avis il serait juste aussi compliqué à utilisé qu'à maintenir). d'ailleurs, à bien y réfléchir, une slackware avec des abonnements aux dépots cvs/svn/git/Mercurial des logiciels qu'on souhaite utiliser correspondrait à peu prêt à ça.
Tu choisi ce que tu installes, dans quelle version, tu mets à jours ce que tu souhaites, tu peux toujours avoir la dernière version de chaque produit si tu le souhaites.
En contre partie, tu as un système plutôt fragile et tu ne fais pratiquement que cela évidemment.

Peut-être qu'il y a de la place dans l'écosystème du libre pour une telle distribution.
Des motivés?

quelques distros qui je pense on une philosophie de gestion des paquets qui se rapproche de mon idéal:
- gentoo
- archlinux
- Debian CUT (Constantly Usable Testing)

Pour revenir a ce que tu disais sur mozilla, si j'ai bien compris le problème, (et je ne suis vraiment pas sur) c'est que les libs d'Ubuntu que mozilla pourrait utiliser sont trop vielles, dont il ajoute leurs propres version des libs avec le programme pour que ubuntu puisse bénéficier d'une version récente de leur navigateur, si c'est le cas ça ne m'étonne pas tant que ça, et pour moi c'est un problème qui vient plus du choix de debian stable / ubuntu d'avoir une distribution en versions plutôt qu'en rolling, (= plus de stabilité et moins de progrès) que du système modulaire de la gestion des maj.

progrès VS stabilité (et communion des efforts), je pense qu'on a pas encore trouvé de vraie solution… peut être qu'il n'y en a pas…

Je pense que le futur passera par les ordinateurs qui démarrent à froid en moins de 3 secondes pour arriver au bureau.

J'ai déja vu ça avec le systeme AmigaOS au JDLL il y a 2 ans...

sinon pour rester dans le sujet et rebondir sur une remarque de galuel:

La fonction d'un logiciel (prenons un éditeur de texte par exemple) est de faire ce qu'on lui demande (éditer du texte).
La fonction d'un systeme d'exploitation est de permettre d'utiliser différents logiciel dans les meilleur conditions.

un logiciel n'a par conséquent pas à ce mettre à jour tout seul, car se faisant, il outrepasse ça fonction et gère des trucs qui ne le regarde pas.
imaginons que quelqu'un installe 2 éditeurs de texte sur ça machine:
tout le 2 aurons des chose en comuns que le développeur du logiciel n'aura pas envie de réécrire (par exemple la gestion de différents jeux de caractères), le développeur va donc utiliser une bibliothèque, c'est à dire plus ou moins une liste de fonctions qu'il pourra utiliser dans sont programme.
L'éditeur de texte 1 va utiliser une certaine version d'une bibliothèque pour gérer les jeux de caractère
L'éditeur de texte 2 va utiliser la même.
L'intelligence voudrais donc que cette bibliothèque soit partagées par ces 2 programmes pour optimiser le fonctionnement de l'ordinateur (moins d'espace de stockage, éventuellement moins d'espace mémoire utiliser si on utilise les 2 programme en même temps).
Et maintenant attention:
l'éditeur de texte 2 qui fait le café se met à jour tout seul, et sa nouvelle version utilise une nouvelle version de la bibliothèque, incompatible avec la précédente, comme l'éditeur de texte 2 n'est pas le systeme d'exploitation, il ne sait pas forcément que la bibliothèque qu'il a installé est nécessaire a l'éditeur de texte 1, donc, en se mettant à jour tout seul, il casse l'éditeur de texte 1.
ou alors on dit qu'il installe une nouvelle copie => mais si l'éditeur de texte 1 fait pareil pour sa propre mise à jour, on garde des bibliothèques inutilisé.
donc ce qui est modulaire c'est le système actuel:
le logiciel fait sont boulot de  logiciel
le gestionnaire de mise à jour (qui n'est pas l'OS) fait sont travail de mise à jour, et il le fait bien car il est conscient de ce qui est ou pas à mettre à jour, et comment le faire.

atichu a écrit :

Sur ubuntu j'ai les dêpots et si je ne veux pas changé de version, j'ai les .deb.

Je ne vois pas en quoi cela ne pourrait pas être proposé au sein des programmes (vérification de mise à jour - accord pour mise à jour), tout en étant compatible avec la gestion des dépôt.

Voilà si tu configures tes accords pour mise à jour et que tu allumes l'ordinateur resté un mois à l'arrêt tu te retrouves avec 200 mises à jour et 200 accords manuels par exemple. Que fais-tu ?

C'est une bonne idée pour ceux qui s'ennuient.

Je pense que le futur passera par les ordinateurs qui démarrent à froid en moins de 3 secondes pour arriver au bureau.

En revanche lors de la proposition de mises à jour, on pourrait proposer à l'utilisateur deux choix : mises à jour automatique ou mise à jour à confirmer par logiciel mais cela semble régressif puisque qu'en règle générale les mises à jour ne plantent pas.

1) Via les paquets des dépôts via la logithèque (ou Synaptic pour ceux qui préfèrent).
2) Via un fichier.deb.
3) Via ce que l'on trouve. Ex: j'ai installé un jeu via un fichier.sh car non disponible autrement.

Pour les points 2 et 3, c'est dans le cas d'un logiciel qui n'est pas dans les dépôts.

Mon conseil: toujours aller voir dans la logithèque (ou Synaptic) en premier lieu.

C'est pour cette raison que j'ai précisé "à la maison". Car à la maison, l'administrateur c'est l'utilisateur final.

il faut comprendre que l'administrateur système est en fait un utilisateur final.

A la maison, tout-à-fait d'accord avec toi.

Oui et non.

On décompresse l'archive téléchargée puis on ouvre le fichier Readme qui donne la procédure a suivre.

Et c'est à ce niveau que c'est plus ou moins facile.

Suivant le logiciel, tu peux avoir une simple commande genre:

sudo sh install.sh

qui fait tout pour toi.

Ou une série de commande avec, entre autre, une compilation. Et là, effectivement, il y a moyen de s'amuser.

Après, l'administrateur système peut s'amuser avec si ça le chante, mais il faut comprendre que l'administrateur système est en fait un utilisateur final. Il va donc manipuler des paquets, pas des sources ... à moins d'être un cascadeur de l'extrême.