Je trouve que cela serait une bonne idée de séparer dans les distributions Linux, surtout dans l'optique d'une utilisation "desktop", la base du système de la base des logiciels utilisateur, pour en faire des développement séparés. En effet la base système (démarrage, shell, cups, python, perl, php, mysql etc) peut se permettre de rester figée plus longtemps que la base des logiciels courants de l'utilisateur (inkscape, firefox, blender etc.), ces derniers en revanche ont besoin d'être mis à jour souvent pour profiter des dernières améliorations ("release early, release often")
À ma connaissance aucune distribution ne le fait vraiment.
Dans le contexte d'une entreprise, mais parfois aussi d'un particulier, une fois que l'on a installé un système, on n'a pas forcément envie de le changer tous les ans, ni même tous les 2-3 ans. Exemple du système de base Windows ou Mac os X : il n'y a pas de nouvelles versions majeures tous les 4 matins, par contre les utilisateurs peuvent mettre à jour leurs logiciels relativement facilement, ils n'ont à regarder que la gamme compatible du logiciel : version Tiger et/ou Panther, version XP et/ou Vista.
Les mises à jour de sécurité sont faites au fil de l'eau, tandis que les logiciels fournis par le "vendeur", comme itunes, quicktime, sont également mis à jour au fur et à mesure.
Sous linux, hormis les paquets spécifiques à une distribution, souvent incompatibles (mais on peut tenter avec alien...) un paquet pour la version "instable" (donc récente) ne fonctionnera pas avec la version "stable". Et trop souvent, la version stable utilisée ne contiendra pas une mise à jour satisfaisante du logiciel. Je ne connais pas toutes les distributions, mais si on peut comprendre que la distribution ne mette pas à jour son système de base stable pour ne pas casser des applications existantes, en revanche on pourrait souhaiter (je me répète) avoir des versions récentes des applications de bureau, qui pourtant dépendent moins les unes des autres. Mettre à jour OpenOffice ne va pas casser Gimp... On pourrait éventuellement envisager l'utilisation de chroot pour encore plus compartimenter et sécuriser les logiciels fraîchement installés.
Un exemple concret : en mai 2006, j'installe sur un poste de travail, à mon boulot, une opensuse 10.1. Après diverses configuration, elle fonctionne pas trop mal, et par rapport aux besoins de l'utilisateur, il n'est plus nécessaire de toucher au système de base (l'imprimante est configurée une fois pour toute, l'accès nfs ou samba à des serveurs distants aussi, on l'utilise même comme serveur de sauvegarde avec rsync etc). Par contre c'est firefox 1.5 qui est livré, et sur certains sites, cette version trop vieille ne fonctionne pas de façon satisfaisante. On peut éventuellement télécharger (à l'époque) la version 2 sur le site de mozilla, mais qu'en est-il pour ceux qui ont des pc 64 bits, mozilla ne fournissant un binaire que pour 32 bits ? (si on l'utilise sur un poste 64 bits, il peut manquer des icônes, et il y a peut-être d'autres problèmes sous-jacents).
Idem pour les mises à jour OpenOffice, les nouvelles versions étant quand même plus fonctionnelles. Donc soit on s'embête pour les mises à jour (recompilation...), soit on garde des versions obsolètes. Ou soit on migre tout le système vers la version de la distribution, ce qui n'est pas très rationnel vu que toute la base fonctionne bien pour l'usage qu'on en a. C'est pourtant ce que j'ai fait dans cet exemple de l'opensuse, une mise à jour courant août, ce qui m'a fait beaucoup plus perdre de temps que si c'était une simple mise à jour de 2-3 logiciels spécifiques : au démarrage, j'ai eu droit à quelques gels d'écran, les configurations utilisateurs n'étaient plus les mêmes, les imprimantes avaient disparues (ennuyeux pour ce qui était sensé être une mise à jour...).
Je ne remets pas non plus en cause l'intérêt des paquets dans les distributions, c'est un service que j'apprécie et utilise beaucoup, mais à trop focaliser sur la globalité de la distribution à mon moment donné, cela a tendance à trop la figer dans un ensemble rapidement dépassé.
Un autre exemple : Le minimum, pour Firefox 3, sous Mac OSX c'est Tiger, sorti en avril 2005 (soit un an avant l'opensuse dont on parle). Pour Windows, c'est XP, sorti en 2001. Sur mon EeePC, acheté au début de l'année, le système xandros ne permet pas, facilement j'entends, d'installer Firefox 3, la version "Linux" du site de Mozilla, est incompatible (problèmes de dépendances). Cela pourrait peut-être changer ( http://www.blogeee.net/2008/08/26/les-prochains-eeepc-sous-l(...) ) mais en attendant, cela ne donne pas une superbe image de Linux auprès du grand public.
Aussi, dans nombre de cas, je suis obligé de compiler moi-même mes paquets avec une debian stable pour pouvoir les utiliser sur l'EeePC. D'ailleurs très souvent ces paquets compilent sans problème sur la debian stable, preuve que le système de base n'a pas forcément besoin de la toute dernière libc pour faire fonctionne des logiciels récents. Le concept de backports mériterait aussi d'être plus étendu (par exemple il n'y a pas de backport officiel de iceweasel 3 pour debian stable).
Je ne dis pas que Mac OSX ou Windows sont parfaits dans leurs conceptions, loin de là, mais, ces différents points mériteraient sans doute d'être améliorés sous linux.
Journal [Troll du vendredi] Mettre au même niveau la base des distributions stables en regard des logiciels utilisateurs est-il vraiment une bonne chose ?
29
août
2008
# www.backports.org
Posté par bigben99 . Évalué à 10.
You are running Debian stable, because you prefer the stable Debian tree. It runs great, there is just one problem: the software is a little bit outdated compared to other distributions. That is where backports come in.
Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution. I recommend you to pick out single backports which fits your needs, and not to use all backports available here.
[^] # Re: www.backports.org
Posté par B16F4RV4RD1N . Évalué à 10.
Pas d'inkscape, ni de iceweasel, ni de icedove (dernière version 1.5 dans stable, or la version courante de thunderbird c'est la 2.0.0.16 ), ni de gimp dans backports, or ces paquets me semble plutôt essentiels pour une utilisation de "bureau".
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: www.backports.org
Posté par wismerhill . Évalué à 3.
Par exemple, la source backport de la 2008.1 contient un firefox 3.0.1
après il y a encore les sources non officielles comme PLF (la plus importante), SoS ou MDE.
[^] # Re: www.backports.org
Posté par BAud (site web personnel) . Évalué à 3.
Néanmoins, le logiciel n'a généralement pas eu le temps d'avoir été testé sur Cooker et des problèmes peuvent subsister. (issu de [http://wiki.mandriva.com/fr/Backport]).
En clair, il y a de grandes chances que cela casse tout et le diagnostic en sera d'autant plus difficile que tout le monde n'utilise pas backports, soit beaucoup moins de rapports d'anomalie (et moins de temps que sur cooker pour les corriger).
L'inconvénient de backports est (encore actuellement) que _toutes_ les dépendances qui sont dans backports sont mises à jour sur un urpmi --auto-select :/
En gros, backports ne serait actif _que_ pour installer une nouvelle version de inkscape, par exemple, cela me conviendrait. Là il faut l'activer pour un paquet spécifique à installer puis se rappeller de penser à le désactiver pour éviter de tirer tout ce qu'il y a dans backports.
Perso, je préfère refaire mes rpmbuild -ba pour les paquets qui m'intéressent ou alors directement être en cooker, avec les soucis afférents assumés.
Le projet Taster est là pour améliorer les choses via la communauté : ce qui arrive en testing ou les bugs demandant un peu plus d'analyse (ou de retours, le statut "NEEDINFO") peuvent être vus à plusieurs
http://www.mandrivafr.org/trac/taster/ la présentation
http://forum.mandriva.com/viewforum.php?f=172 forum taster
[^] # Re: www.backports.org
Posté par wismerhill . Évalué à 2.
Le switch --media de urpmi est fait pour ça.
Tu ajoute les sources backports mais tu les désactive, quand tu as besoin de quelque chose dedans tu les met à jours explicitement avec urpmi.update et tu installe en précisant à urpmi qu'il peut aller chercher dans ces sources.
Ou récipoquement quand tu fais un --auto-select, tu ajoute un --exclude-media en précisant les médias de backports.
[^] # Re: www.backports.org
Posté par BAud (site web personnel) . Évalué à 4.
Clairement, par le jeu des dépendances c'est quasi l'intégralité (bon ok je grossis le trait) des paquets qui se trouvent backportés... sans compter ceux qui réclament à cor et à cri les toutes dernières versions de KDE (c'était plutôt des trucs comme compiz ou beryl à l'époque qui était aussi réclamé, mais demandait une installation manuelle sous peine de casser sa distrib'...) donc bon, quitte à avoir un système cassé autant être en cooker et l'assumer...
D'autant, que la plupart du temps, la justification de certains pour avoir la toute dernière version, c'est souvent "pour avoir la dernière version", pas une fonctionnalité ou une correction de bug citée (ce qui serait déjà plus justifié).
En tout cas, le système de backports est déjà un peu plus maîtrisé que SoS ou MDE... et j'aurai tendance à être confiant pour la suite si le projet Taster permet de mobiliser suffisamment de monde prêt à faire des retours (en français en plus, cela étant souvent un point de blocage avec l'anglais :/).
[^] # Re: www.backports.org
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
# Entièrement d'accord
Posté par Bruno Coudoin (site web personnel) . Évalué à 5.
Pour prendre un exemple que je connais bien, je sors les version Windows et GNU/Linux de GCompris en même temps mais pour beaucoup d'utilisateur GNU/Linux ils devront attendre des mois ou des années avant de pouvoir l'utiliser.
[^] # Re: Entièrement d'accord
Posté par jerome (site web personnel) . Évalué à 9.
Donc ils ne voudront plus utiliser GCompris.
C'est vrai que c'est assez gênant pour ton logiciel.
[^] # Re: Entièrement d'accord
Posté par ʭ ☯ . Évalué à 4.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Entièrement d'accord
Posté par gentildemon . Évalué à 1.
Dans le cas de Wormux, j'ai essayé à plusieurs reprises de faire un binaire statique pour contrer ce problème, je m'y suis cassé les dents. (Libcurl est notamment une plaie à ce niveau)
[^] # Re: Entièrement d'accord
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Le problème ensuite c'est de pouvoir installer / désintaller simplement et proprement des logiciels en dehors du système de packaging de la distro.
[^] # Re: Entièrement d'accord
Posté par Hobgoblins Master (Mastodon) . Évalué à 5.
C'est justement là où il y a un problème, toute personne qui gère un peu plus de 2 postes ne veut pas avoir à gérer de logiciels en dehors du système de paquets de sa distribution, c'est la porte ouverte à toutes les fenêtres®...
[^] # Re: Entièrement d'accord
Posté par vladislav askiparek . Évalué à 3.
Mes filles adorent!!
[^] # Re: Entièrement d'accord
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
Au nom de toute l'équipe, Merci.
[^] # Re: Entièrement d'accord
Posté par vladislav askiparek . Évalué à 2.
Quand tu écris "un utilisateur", j'espère que tu ne penses pas que je suis le seul!! J'en aurais la nausée....
[^] # Re: Entièrement d'accord
Posté par NeoX . Évalué à 3.
Je l'avais installé dans le Master que je deployais dans les ecoles ( 400Pcs)
Je l'ai installé sur le PC de ma copine (pour sa fille je precise)
Et franchement j'aime bien le logiciel.
[^] # Re: Entièrement d'accord
Posté par Bruno Coudoin (site web personnel) . Évalué à 4.
Comme tous les projets libres je ne sais pas compter le nombre d'utilisateur mais ça doit être au moins très beaucoup ;)
[^] # Re: Entièrement d'accord
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
# Reflexion à voix haute
Posté par dripple . Évalué à 4.
1. de créer un logiciel qui permettrait de fournir les informations nécessaires à l'installation d'un paquetage sur une distribution (répertoires par défaut des libs, configuration, blah blah blah...)
2. de packager des applications pour être géréres et installées par ce nouveau logiciel.
En quelques sorte, un gestionnaire d'application indépendant de la distribution, et un dépot de logiciels utilisables par ce gestionnaire d'application.
En même temps je ne sais pas ce que ça vaut comme idée. C'est certes moins sesky que de créer une nouvelle distribution, mais je pense que ça irait dans le bon sens...
[^] # Re: Reflexion à voix haute
Posté par Spyhawk . Évalué à 9.
C'est pour l'heure assez peu utilisé en dehors d'openSUSE, et c'est bien dommage à mon avis.
http://en.opensuse.org/Build_Service
[^] # Re: Reflexion à voix haute
Posté par dripple . Évalué à 2.
[^] # Re: Reflexion à voix haute
Posté par Spyhawk . Évalué à 2.
En ce qui concernent la création de paquets, les statistiques actuelles du dépôt central openSUSE donnent :
There are now 3716 projects, 48754 packages, 7204 repositories and 8606 confirmed users.
toutes achitectures (i586, x86_64, ia64) et toutes distributions confondues (mais surtout openSUSE).
Egalement, rien n'empêche n'importe qui (distribution, ou developpeur d'un projet quelconque) d'installer une copie locale sur sa ferme de compil/son ordinateur personnel, puique les sources du Build Service sont disponibles librement (mais on perd l'avantage de l'utilisation directe de la ferme de compilation du projet openSUSE).
Le but premier du Build Service, outre de creer des paquets pour plusieurs distrib facilement, est de dynamiser les interactions entre les projets (en recompilant automatiquement les paquets lors que c'est nécessaire), tout en ayant un lien direct avec les sources upstream.
Egalement, le BS peut s'utiliser de façon décentralisée, en "pointant" vers un Build Service central (celui d'openSUSE par défaut), les différents projets restant liés entre eux.
Les statistiques exactes sont donc difficiles à obtenir, et savoir "qui" l'utilise (et dans quel but?) est chose impossible. Mais aucune distribution majeure ne l'utilise à ma connaissance, chacune ayant son propre système local.
[^] # Re: Reflexion à voix haute
Posté par krobed . Évalué à 5.
http://www.autopackage.org/
Decouvert suite à la mise à jour du protocole reseau MSN qui empechait les utilisateurs de logiciels tiers de se connecter ( classique ). Les depots des distribs ne pouvaient pas toutes suivre le rythme sur ce coup là et le projet aMSN fournissait un paquet mis à jour avec installeur. Bonheur.
[^] # Re: Reflexion à voix haute
Posté par dripple . Évalué à -4.
[^] # Re: Reflexion à voix haute
Posté par Misc (site web personnel) . Évalué à 4.
http://kitenet.net/~joey/blog/entry/autopackage_designed_by_(...)
Donc il vaut mieux repartir sur une base saine, si autopackage n'a pas décollé, il y a une raison, et comme tout le monde ( ou presque, à lire les commentaires ici ) semble vouloir ce genre de système, c'est sans doute un problème de réalisation, non ?
# C'est du boulot
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
Cependant, le problème de cette idée de fournir ces logiciels en backport, c'est que ça demande du temps. Et les mainteneurs de paquets ont déjà assez de boulot comme ça pour mettre à jour les paquets des versions en développement des distribs.
Et je ne parle pas des backports sur les version n-2, n-3 des distribs, la charge de travail augmentant alors très rapidement (il faut avoir une machine avec ces vieilles distribs, probablement patcher le nouveau logiciel pour qu'il puisse encore fonctionner sur la vieille distrib etc...)
Bref, à mon avis, si les distribs ne font pas vraiment, c'est plus par manque de ressources qu'autre chose.
[^] # Re: C'est du boulot
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: C'est du boulot
Posté par Bruno Coudoin (site web personnel) . Évalué à 2.
[^] # Re: C'est du boulot
Posté par Misc (site web personnel) . Évalué à 2.
Et quand on voit que les distros commerciales ont des équipes de 30 à 50 personnes, et que debian a 1000 developpeurs, plus de 500 chez gentoo et fedora, je suis pas sur qu'une distro commerciale possède plus de moyen qu'une distro communautaire.
[^] # Re: C'est du boulot
Posté par Gniarf . Évalué à 8.
[^] # Re: C'est du boulot
Posté par Ozz . Évalué à 2.
il suffit de faire exactement l'inverse de Debian (Debian est une super distro, ce n'est pas le propos) pour faire une distribution core figé, haut niveau roulant (complètement roulant, pas figé et backport en complément, trop de boulot) maintenable, et on tombe un peu sur Archlinux:
- le moins de patchs possible, laisser le boulot d'upstream à upstream.
- packaging facile et on ne cherche pas à tout packager (le premier permettant le second)
- minimum de bureaucratie, règles souples (soft freeze, on préfère packager une release bugfix only plutôt que faire des backports de patchs => moins de taf, plus de corrections de bugs, et plus de risques aussi, certes, mais si upstream release n'importe comment, voir avec upstream :p)
- on ne supporte qu'une ou deux archi
J'aime bien Archlinux comme elle est pour mon desktop, mais j'aimerais beaucoup une arch semi figé pour mes petits serveurs perso (avec les logiciels serveurs en soft freeze) et les quelques desktops perso dont je m'occupe.
Peut-être que je me fais beaucoup d'illusions sur la complexité et la charge de travail.
[^] # Re: C'est du boulot
Posté par BAud (site web personnel) . Évalué à 2.
le fait de s'appuyer sur upstream est le meilleur àmha aussi, mais cela suppose que l'upstream a connaissance du packaging dans chacune des distributions :
- cela ne signifie pas que les développeurs ont toutes les distributions à leur disposition (c'est rarement le cas et encore moins dans toutes leurs déclinaisons de versions)
- cela signifie qu'il y au moins un utilisateur avancé tant du logiciel que de la distribution en mesure de maintenir ce qui est nécessaire pour le packaging
- éventuellement, doublonner les outils permettant de packager dans chaque gestionnaire de version (et là ça représente du boulot, un doublon qui peut être désynchronisé...) : c'est ce que j'avais sur un projet : un répertoire package avec debian / mandriva / fedora / arch...
- c'est là où il manque un outil distribué en libre qui a vocation, si j'ai bien compris, à aggréger les informations de VCS distincts et permettant ce travail sur "un seul source distribué" dans leur VCS respectifs, donnant visibilité à chacun de l'ensemble dans son dépôt préféré avec lequel il est habitué à travailler. C'est notamment pour cela que c'est rageant que launchpad ne soit pas encore distribué en libre (toujours repoussé aux calendes grecques, sans date ferme...)
# Rolling release
Posté par alberthier (site web personnel) . Évalué à 6.
En gros les nouvelles versions sont intégrées au fur et à mesure dans la distrib stable. Il n'y a donc jamais vraiment de "release" de la distrib, juste un snapshot tous les X mois qui permet de l'installer.
C'est pas mal, mais je crois pas qu'il y ait de distrib "grand public" qui fasse ça (genre Ubuntu ou openSUSE)
[^] # Re: Rolling release
Posté par Mildred (site web personnel) . Évalué à 3.
Ce que j'aime bien aussi, c'est qu'il est facile de créer ses propres paquets. Et donc d'installer un logiciel non encore packagé, sans ignorer le gestionnaire de paquets.
Dans l'optique de migration vers une distribution plus attractive (telle que fedora) je travaille plus ou moins sur un logiciel qui permettra à partir d'un fichier de description (équivalent des ebuild, RPM .spec, PKGBUILDs) qui pourrait permettre de générer un paquet pour chaque distribution.
Ce fichier décrira où sont les sources (URL), comment les télécharger, décompresser, patcher, compiler et installer puis permettra de faire un paquet binaire natif de la distribution utilisée. Mon but serait de créer un sie web où on puisse s'échanger ces fichiers, et où chacun pourra l'améliorer pour mieux prendre en compte sa distribution.
[^] # Re: Rolling release
Posté par B16F4RV4RD1N . Évalué à 2.
J'aime aussi la possibilité de faire ses "formules" avec Archlinux pour créer des paquets, c'est relativement simple et rapide, et surtout permet d'en faire profiter facilement tout le monde. Pour le moment je vais rester sur archlinux qui semble bien me convenir, puisque leur but c'est de faire une distribution moderne, utilisant des logiciels récents, et utilisable.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Rolling release
Posté par Hobgoblins Master (Mastodon) . Évalué à 4.
Je vis très bien sous Sid depuis plisieurs années avec plusieurs machines différentes, avec apticron, apt-listbugs et en prenant le temps de lire, ça marche très bien !
Pour ceux qui veulent du pas vieux sans prise de tête, c'est testing...
[^] # Re: Rolling release
Posté par Gniarf . Évalué à 3.
alors pour le coté "sans prise de tête", tu repasseras
[^] # Re: Rolling release
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
Bon, c'est peut-être parce que j'ai les 3 "saveurs" debian + stable/security + multimedia dans mon sources.list
[^] # Re: Rolling release
Posté par Gniarf . Évalué à 2.
...ça ne fait pas partie de Debian.
[^] # Re: Rolling release
Posté par Hobgoblins Master (Mastodon) . Évalué à 2.
J'ai essayé unofficial, et d'autres petits (freeplayer), ils n'ont pas fait long feu...
Backports ne faisait pas partie de Debian à l'origine non plus, l'espoir fait vivre :)
[^] # Re: Rolling release
Posté par Gniarf . Évalué à 2.
on perd juste la cohérence des dépendances que Debian gérait à peu prêt correctement. maintenant, chacun son trip, hein... et, oui, je sais que des fois y'aura pas le choix.
[^] # Re: Rolling release
Posté par Thomas Douillard . Évalué à 4.
Debian-multimedia c'est un truc qui tourne sans trop de soucis depuis quelques temps, genre ça a changé de nom et d'adresse il doit y avoir un ou deux ans, sinon j'y touche tellement rarement qu'il se fait oublier ...
Il m'est arrivé d'ajouter des dépots, mais c'est un peu le seul qui soit utile et pérenne pour ça ...
[^] # Re: Rolling release
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Ce dernier a été largement critiqué pour sa gestion des paquets Debian du projet Gnome (dont il avait le second monopole avec un japonais) avant la constistution d'une équipe dédiée à Gnome comme il y en a pour KDE et d'autres gros projets.
Christian a d'ailleurs abandonné tous ses paquets relatifs à Gnome au profit de cette équipe car il n'apprécie manifestement de travailler en équipe. Alors, le jour où il sera malade (tout ressemblance avec l'auteur d'une des plus vieilles distributions Linux serait fortuit) ou autre, tu peux dire adieu à ton cher dépôt tiers.
Christian est loin d'être une référence en la matière : les auteurs de MPlayer n'ont guère apprécié son paquet Debian, ce qui a fait traîné son intégration officielle en longueur.
En outre, si tu as des problèmes avec un de ses paquets, tu ne pourras plus compter sur la communauté Debian pour les corriger.
[^] # Re: Rolling release
Posté par Thomas Douillard . Évalué à 2.
# Debian
Posté par plic . Évalué à 6.
On va me dire qu'au bout d'un moment il y a beaucoup de paquets qui seront mis à jour, justement à cause des dépendances. Mais s'ils sont mis à jour, c'est qu'ils sont nécessaires, donc que de toute façon on ne peut pas s'en passer, à moins d'avoir plusieurs versions de GTK et de QT, etc.
On ne peut pas tout avoir...
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Debian
Posté par mekare . Évalué à 2.
Je ne connais pas "Apt-pinning" mais dans Debian il est possible sur une stable d'installer des paquets (et ces dépendances uniquement) provenant de testing ou sid. Pour cela il faut correctement renseigner son fichier de conf en définissant les priorités des dépôts et en choisissant quelle version on souhaite installer (avec synaptic par exemple).
[^] # Re: Debian
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
[^] # Re: Debian
Posté par mekare . Évalué à 2.
# ça existe déja
Posté par Misc (site web personnel) . Évalué à 10.
Sinon, les systèmes de ports ( macports (http://www.macports.org/), portage, parmi tant d'autres ) sont aussi une solution à ton problème.
Et la dernière solution, c'est simplement de te lancer dans un projet, et de mettre ça au point, car après tout, c'est du libre, personne ne t'empêche de te lancer, et vu le nombre de personne qui demande ça sur linuxfr, tu va facilement trouvé des gens aptes à t'aider, aussi bien en matière de travail, que d'hébergement.
Alors ensuite, si tu fait ça, tu va devoir faire face à tout les trolls qui vont te faire remarquer que kde, c'est à la fois dans la base et pas dans la base, que Firefox est une plateforme, et que les plugins en dépendent, tout comme openoffice, donc que ça devrait pas forcement bouger, que certains devs veulent avoir la nouvelle version de php/python, que le kernel, pourtant sans conteste de base, offre des tas de features dans les versions plus récentes et qu'il faut donc le mettre à jour, et donc le sortir de la base, et ce genre de choses, mais je ne doute pas que tu va trouver facilement la solution à ce genre de problème
[^] # Re: ça existe déja
Posté par B16F4RV4RD1N . Évalué à 2.
Pour un environnement de bureau, rien n'interdit à priori de le compiler pour que cela fonctionne avec une libc d'il y a 3-4 ans, sauf bien sûr s'il y a eu trop de modifications entre temps. Pour le noyau linux, une fois le système installé, si on ne branche pas trop de périphériques exotiques dessus, il n'y a pas forcément besoin de le changer.
Je pense quand même que vous conviendrez qu'il y a un peu des soucis au niveau de l'utilisation de binaires sous linux. Un logiciel de jeu qui sort en 2006 n'est pas certain de continuer à fonctionner en 2008.
Autre problème, c'est que l'on a souvent des références à des libmachins.so.4 alors que l'on en est à la libmachins.so.6, dans 90 % des cas en faisant un lien symbolique vers la dernière version, cela fonctionne très bien, cela serait bien que cela puisse tester automatiquement qu'une version plus récente existe plutôt que de bloquer.
En ce qui concerne PCBSD, je pense que je vais le tester prochainement, je viens de voir qu'une beta de la version 7 venait de sortir.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: ça existe déja
Posté par Hobgoblins Master (Mastodon) . Évalué à 3.
C'est une des plus grosses valeur ajoutée des distibs Linux par rapport aux OS du mal : l'intégration et la cohérence des dépendances logicielles. Si c'est pour se taper de la veille sur 120 sites web, télécharger toutes les semaines les trois mis à jour, les tester, désinstaller l'ancienne version et installer la nouvelle, va voir chez Slack...
Un logiciel de jeu qui sort en 2006 n'est pas certain de continuer à fonctionner en 2008
Solaris se targue d'avoir une ABI Stable depuis 1992 (de mémoire), tu devrais essayer, le jeux de 1994 doivent encore fonctionner :) Mais là, on est plutôt dans le problème inverse à celui évoqué à la base, à savoir faire tourner KDE 4.1 et openoffice 3.0B2 sur un noyau 2.2 :)
[^] # Re: ça existe déja
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 8.
Pas du tout, efface ! Si le SONAME a changé, ça veut dire que l'api a été cassée. Forcer l'utilisation d'une lib avec une SONAME différente, c'est jouer au loto en espérant que ce qui a été cassé n'est pas utilisé dans le programme…
# Gentoo ? Arch ?
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Il y a une évolution continue qui fait que les nouvelles versions arrivent au fil de l'eau. C'est d'ailleurs pour moi LE point fort de Gentoo.
Il me semble que Arch reprend ce principe mais avec des paquets compilés.
[^] # Re: Gentoo ? Arch ?
Posté par Aefron . Évalué à 5.
X.org (tout, sauf la base, en ce qui me concerne) voit encore sa version 7.3 tilde-archée... tout comme Firefox 3...
... et m'est avis que c'est tout sauf un mal, vu les problèmes qu'ont pu engendrer les dé-tilde-archage hâtifs dans cette, n'en reste pas moins, fantastique distro. A la limite, le point fort dans ce cas, c'est d'être fait pour proposer plusieurs versions des applis de manière concurrente (même si on n'en installe qu'une seule à la fois)...
... un peu comme les backports Debian, ou le apt-pinning (dont il faut parfois accepter les conséquences néfastes) en somme.
Maintenant, ça me paraît davantage être quelque chose qui intéresse les utilisateurs "avancés" plutôt que le grand public... ma mère utilise une Debian stable, et honnêtement, firefox 1.5, 2.0 ou 3.0, elle s'en fout complètement ; elle n'a même pas conscience qu'il peut y avoir des différences.
Avoir la dernière version pour pouvoir dire "t'as vu, j'ai la dernière version", je ne vois pas bien où ça mène... ni à quoi ça sert ; oui, firefox 3.0 et Gimp 2.4 sont un peu mieux que les versions précédentes... de là à dire qu'il y a un monde qui les sépare, je n'irais franchement pas jusque là : firefox 3 est toujours lent et très mal intégré sous X.org (seule et unique appli qui ne prend pas en compte mon dpi peu commun, fonctionnement bizarre du presse papier avec le bouton du milieu, intégration exécrable aux thèmes gtk, ...), et il manque toujours les dossiers de calques et les fonctions d'impression pro à Gimp 2.4... dont acte.
A la limite, ce que je préfèrerais, c'est que tout (et quand je dis "tout", je pense vraiment à "TOUT") ce qui concerne le support du matériel soit mis à jour plus souvent, de manière globale... comme lcdproc dans Debian, qui n'a pas été mis à jour depuis la sortie d'Etch, fut-ce en backport, et qui ne l'est toujours pas dans Lenny (même si la page QA laisse un poil d'espoir en laissant penser que l'exception de non-freeze de ce paquet va permettre de le voir upgradé dans la prochaine Stable)...
Voire à ne pas confondre non plus "stable", "fiable", "fonctionnel" et "récent"... les régressions, c'est monnaie courrante ; prenons X.org pour exemple... X.org 7.3 (en attendant que le 7.4 sorte enfin... si jamais...) est peut-être plus récent et plus fiable que les précédents quant à la gestion du multi-écran, mais il est indubitablement moins fonctionnel sur ce point ; avec le 7.1, on pouvait faire du multi-GPU, même si c'était au prix du manque d'accélération 3D... Avec cette version qui est encore celle de l'actuelle Debian stable (ie stabilisée, ie figée à une version qui n'est pas forcément la dernière en date : ni plus, ni moins), je n'ai aucun problème à avoir 3 écrans avec une accélération 2D libre...
Alors, laquelle est la mieux ? Et bien ça dépend, justement...
Ce qui est bien, au fond, c'est d'avoir le choix. Debian stable ne satisfait plus l'auteur du journal ? Pourquoi ne pas utiliser une Lenny, par exemple, en ce cas ? A défaut d'être "stable" (ie, ses paquets ne sont pas figés, ni plus, ni moins), elle se révèle globalement très fiable depuis la sortie même de Etch (le seul gros problème dont je me souvienne, hors problèmes de sécu, plus longs à corriger que dans les autres Debian, c'est un paquet de grub qui a été merdeux pendant quelques heures)...
Même si je ne serais pas du tout contre un poil de granularité en plus, avec des backports plus fournis, la diversité des distros fait que, de la granularité, justement, il y en a déjà pas mal.
[^] # Re: Gentoo ? Arch ?
Posté par B16F4RV4RD1N . Évalué à 4.
Et c'est là que l'on aurait aimé pouvoir installer facilement la dernière version, mais elle n'était pas dans les dépôts (et honnêtement, avec cette version 10.1 d'opensuse, pendant que le gestionnaire de paquet s'initialisait, on avait le temps de télécharger et d'installer 3 fois un .exe sous windows... heureusement cela s'est amélioré avec la version 11)
J'ai pu la télécharger depuis le site de mozilla (et encore parce que j'avais du x86 et pas du 64 bits qui n'est pas fourni, et je pense que la version 3 n'aurait pas fonctionné.
Pour les régressions de X, je pense que X fait partie des paquets de base à ne pas modifier une fois une machine installée. Car je parlais bien de stabiliser si possible une version de base dans le but de garder un système opérationnel sur le long terme, pas dans le cas de réinstallation ou de nouvelles installations.
Pour parler plus concrètement, j'ai installé dans la PME où je travaille plusieurs ordinateurs sous windows il y a 5 ans. Besoins : openoffice, firefox, émulateur de terminal (putty ou équivalent). Depuis 5 ans je n'ai pas touché à ces machines ni à leur système, à part faire évoluer openoffice et firefox.
Sur des postes similaire avec linux cette fois, j'ai comparativement passé plus de temps pour pouvoir mettre à jour ces logiciels, et j'ai d'ailleurs dû faire le plus souvent des mises à jour complètes du système pour cela.
Lorsqu'il s'agit d'un ordinateur perso, que l'on fait évolution selon ses besoins et ses capacités, c'est un peu plus facile à gérer que de placer un utilisateur devant un linux et lui proposer de mettre à jour son firefox ou openoffice via pkgsrc ou en le compilant à la main...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Gentoo ? Arch ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
pour firefox 1.5 ou 3.0, je pensais aussi pareil, pour un utilisateur non averti c'est plus ou moins la même chose, mais le problème c'est quand ils viennent te dire que certains sites ne s'affichent pas bien, qu'ils ne comprennent pas pourquoi, ben moi j'ai vite compris que cela venait de la version du navigateur.Et Firefox 2.0, il ne compte pas ?
Je veux bien que Firefox 1.5 soit « obsolète » mais de là à prétendre que Firefox 3.0 soit complètement indispensable, c'est comme prétendre qu'il faudrait utiliser IE7 et non IE6.
Pourtant de nombreux utilisateurs (environ 30%) utilisent encore IE6... Preuve que la course aux versions ne concernent pas tout le monde non plus. Et parmi ceux qui ont fait la mise à jour, c'était parce qu'elle était présentée comme une mise à jour *de sécurité* !...
La plupart des distributions fournissent à la fois Firefox 2.0 et Firefox 3.0 et, pour citer deux exemples, le site des impôts et de ma banque ne supportent que le premier. Et bien que le second fonctionne, ce n'est pas toujours sans mal : pour les impôts, il a même fallu bidouiller.
Ce sont sans doute des cas particuliers mais il s'agit de sites à l'audience non négligeable.
D'ailleurs, quand certains sites ne fonctionnent pas, c'est qu'ils sont d'abord conçus pour IE et non pour Firefox : changer de version ne résoudra pas le problème de fond.
[^] # Re: Gentoo ? Arch ?
Posté par wismerhill . Évalué à 1.
Ah mais il ne faut plus, ça fait des années qu'il faut jeter cette saleté, par pitié arrêtez d'utiliser cette merde d'internet explorer 6 (et puis le 7 n'est pas encore formidable non plus).
Ça nous simplifierait tellement la vie au boulot si on pouvait se permettre de laisser tomber la compatibilité avec ie6.
[^] # Re: Gentoo ? Arch ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Gentoo ? Arch ?
Posté par wismerhill . Évalué à 3.
Et je ne me gêne pas devant les clients de faire remarquer que ce truc pose des problèmes.
[^] # Re: Gentoo ? Arch ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Depuis hier soir, je suis un utilisateur comblé et heureux d’ArchLinux 64 bits. Même s’il m’a fallu près de 4 heures entre le début de l’installation et le lancement d’un firefox 3.0 pré-béta3 compilé maison. [...]http://frederic.bezies.free.fr/blog/?p=652
[^] # Re: Gentoo ? Arch ?
Posté par B16F4RV4RD1N . Évalué à 1.
oui mais c'était en décembre 2007. Maintenant firefox 3 existe dans les dépôts bien entendu :
http://archlinux.org/packages/extra/x86_64/firefox/
Au niveau des mises à jour, je n'ai jamais eu de problème avec, pourtant utilisant encore Debian en double boot, je ne lançais alors archlinux qu'épisodiquement, donc les différentes mises à jour étaient assez conséquentes, mais cela n'a jamais rien cassé.
Pour l'installation, entre mon premier boot sous arch et le lancement de firefox cela a dû mettre moins de 3 minutes, mais il faut dire que j'avais triché, ayant installé archlinux depuis un chroot sous Debian :)
Après, c'est sûr que cela reste assez brut de fonderie, mais justement l'intérêt c'est de pouvoir maîtriser la plupart des processus que l'on met sur le système. Après avoir lu le guide détaillé on sait un peu plus ce qui se passe.
Pour ce que tu disais de firefox 2, c'était possible de l'installer sur l'opensuse 10.1, mais c'était parce que l'architecture était en 32 bits, mozilla ne fournissant pas de paquet 64 bits. Et cela ne change rien au fond du problème : si on veut garder un système sans réinstaller la base, sous linux au bout de quelques mois il n'est pas aisé de faire évoluer la base logicielle. Windows XP sur un ordinateur acheté en 2003 : pas de problème pour installer firefox 3. Asus EeePC acheté en 2008 : ce n'est pas possible sans tout réinstaller.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Gentoo ? Arch ?
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
Pour ce que tu disais de firefox 2, c'était possible de l'installer sur l'opensuse 10.1, mais c'était parce que l'architecture était en 32 bits, mozilla ne fournissant pas de paquet 64 bits. Et cela ne change rien au fond du problème : si on veut garder un système sans réinstaller la base, sous linux au bout de quelques mois il n'est pas aisé de faire évoluer la base logicielle. Windows XP sur un ordinateur acheté en 2003 : pas de problème pour installer firefox 3. Asus EeePC acheté en 2008 : ce n'est pas possible sans tout réinstallerY compris sous Windows 64 bits ?
Ensuite, mettre à jour une distribution moderne ne signifie pas ré-installer. Ou alors, il faut carrément changer de distribution.
On ne peut pas comparer les modes de distribution entre Microsoft© Windows® et Linux car il y a une différence fondamentale : le système n'est pas libre. Les logiciels libres disponibles sous Microsoft© Windows® doivent donc se débrouiller SEUL. Rien n'est prévu pour les acceuillir ni pour gérer les dépendances. Les seules applications gérées par Microsoft sont celles qu'il édite lui-même. On peut mettre à jour Microsoft© Internet Explorer® via Microsoft© Windows Update®. On ne peut pas le faire (du moins pas pour l'instant mais il me semblait que Microsoft© planchait sur une méthode pour distribuer ses applications en ligne) pour Microsoft© Office® parce qu'il s'agit d'une suite logicielle payante. Et il en va de même pour tous les autres logiciels payants qu'ils éditent.
Quant aux logiciels d'éditeurs tiers, ils doivent se démerder tout seul, si bien que leurs applications sont généralement accompagnées de leur valises de DLL pour pouvoir fonctionner. D'où une gestion des mises à jour de sécurité complètement bordélique : un bibliothèque commune à deux ou trois applications nécessitera autant de mises à jour que d'applications, à condition que les éditeurs en fournissent...
Si certains développeurs ne veulent pas produire autant de paquets binaires que de distributions majeures (on ne leur demande pas non plus d'en faire pour les 200 et quelques distributions existantes) dont il n'existe finalement que deux ou trois grandes familles (les RPM, les debian et les sources), qu'ils ne viennent pas se plaindre si ces dernières n'incluent pas leurs dernières versions.
Après tout, les éditeurs de jeux ne jonglent pas seulement avec Microsoft© Windows® mais également avec MacOS© X et les diverses consoles de jeux du marché et ils ne se plaignent pas franchement du nombre de plate-formes... On va sans doute me dire que, certes, ils ont les moyens humains et financiers pour ce faire. Que dire alors des quelques responsables, qui se comptent sur les doigts de la main, de RPMforge qui maintiennent des milliers de logiciels sous forme de paquets RPM pour Fedore, RHEL, CentOS, dont plusieurs versions concurrentes et pour au moins deux architectures différentes ? Qu'ils ont les moyens humains et financiers de le faire ? Non : comme Debian, ils ont des outils pour se faciliter la tâche et cela prouve encore une fois que la prétendue disparité entre les distributions est, somme toute, assez limitée.
Exemple avec Nagios :
http://dag.wieers.com/rpm/packages/nagios/
Donc, s'il se trouve assez de développeurs et d'utilisateurs pour proposer une nouvelle voie à suivre pour les distributions Linux, tant mieux, mais qu'attendent-ils pour se mettre à l'ouvrage ? Gentoo a été un bel exemple de nouvelle voie, Gobolinux aussi : pourquoi pas une autre ?
# Pas de problème pour Ubuntu.
Posté par Loic Dreux . Évalué à 1.
Et pour les autres softs qui ne sont pas pris en charge à la sortie, il existe des dépôts spécifique (Banshee, Avant Window Navigator, Miro, ...)
Bref, moi je ne trouve rien à redire système de paquets Linux, c'est vraiment la chose qui me fait adorer Linux.
[^] # Re: Pas de problème pour Ubuntu.
Posté par MiniMoi . Évalué à 6.
Ce n'est pas du troll, même si je n'ai pas installe la 8.04, mais les précédentes avaient souvent des petits problèmes, qui sont vite réglés une fois la distrib sortie officiellement.
Donc je dirais par exemple que c'est le bon moment pour passer a 8.04, et que décembre sera sans doute le bon pour passer à 8.10.
[^] # Re: Pas de problème pour Ubuntu.
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
Toutefois, je pense également que la multiplication des dépôts est néfaste et qu'il convient plutôt d'attendre que la prochaine version d'Ubuntu soit publiée avant de se jeter sur les dernières versions de quelques logiciels.
Un autre point que personne n'a abordé, c'est le problème du piratage : il devient très facile, en proposant un paquet de la dernière version du logiciel à la mode (choississez celui que vous voulez) d'introduire des chevaux de Troie dans un maximum de systèmes. Exemple :
http://www.marsaud.org/index.php/post/2008/07/03/Compiz-Fusi(...)
PS: et pas de Ubuntu-bashing facile merci car c'est possible avec n'importe quelle distribution si les utilisateurs sont prêts à installer n'importe quoi pour avoir la toute dernière version de leur logiciel favori.
# Click'n Run
Posté par Mais qui suis-je ? :) . Évalué à 3.
http://www.blogeee.net/2008/08/26/les-prochains-eeepc-sous-l(...)
Est ce que quelqu'un à essayé ?
J'avoue être assez perplexe, d'autant que le système de gestion de paquet constitue une avancée sur le bordel des setup.exe de windows/dos
[^] # Re: Click'n Run
Posté par B16F4RV4RD1N . Évalué à 3.
Mais maintenant avec le recul je vais être très curieux de tester le dernier PCBSD. Normalement le système de gestion de paquets sous-jacent est conservé, mais une surcouche permet d'installer les logiciels que l'on veut. Cela ne sera sans doute pas mon mode d'installation préféré, mais j'aimerais voir ce que cela donne, et le retour des utilisateurs.
Le système de paquets intégré à la distrib est très bien et très pratique, mais souffre de 3 choses, surtout vis à vis des débutants :
- obsolescence des programmes (parfois), impossibilité de l'installer comme un simple utilisateur (comparer avec klikk ou autopackage qui permet de laisser l'empaquetage au dev. du logiciel et l'installation par un utilisateur non root)
- les listes de logiciels dans "synaptic" c'est bien, mais avoir blender coincé entre "barcode" qui gère les normes usuelles d'étiquetage de produits : UPC-A, UPC-E, EAN-13, EAN-8, ISBN et brdesktop-artwork-gnome qui "contains themes and artwork for the GNOME flavour of BrDesktop.", cela ne m'aide pas beaucoup pour savoir si blender est vraiment le logiciel qu'il me faut dans le domaine du graphisme : pas de copie d'écran, pas de commentaire un peu enthousiaste, pas de retour utilisateur etc. Je caricature un peu, mais cela reste un peu un outil d'utilisateur avancé. C'est très bien, mais un lien depuis un site internet vers un dépot click n run ou klikk, cela peut être plus attractif et communautaire (tout en me rendant compte que cela peut poser des problèmes de sécurité et pointer vers http://vilain-pirate.com/rootkit.cnr ). Mais dans le cadre du site d'asus pour le EeePC, cela peut avoir du sens, par ex: http://eeedownload.asus.com/products/overview/gimp avec des notations utilisateur, copie d'écran etc.
- on pourra rétorquer que l'on peut installer les paquets en téléchargeant l'archive depuis le site debian ou ubuntu, et en l'installant avec gdebi par exemple, mais les paquets sont souvent morcelés en monsuperjeu.deb , monsuperjeu-data.deb, monsuperjeu-audio-low.deb, monsuperjeu-audio-high.deb, monsuperjeu-editor.deb etc. Un paquet avec tout dedans pourrait suffire.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
# Préoccupation SuSE ?
Posté par Quzqo . Évalué à 2.
Dans une optique Debian et/ou Ubuntu (avec des cycles de vie de version différents), le principe stable/testing/unstable voire experimental permet de conserver un système de base très peu modifié tout en profitant de versions logicielles récentes. Dans les rares autres cas, le nombre de backports demeure appréciable et suffisant. Au pire, une compilation règle les derniers soucis.
Il est excessivement rare de devoir aller jusqu'à mettre à jour la libc ou autre composant de "bas niveau" entrainant incompatibilités et installations multiples, hors sortie de versions majeures (pas fréquent du côté de Debian ^^) ou mises à jour de sécurité... ou bidouillages incessants aussi (genre desktop) :)
Quant bien même une installation du système de base deviendrait nécessaire (mise à jour majeure ou besoin de version logicielle), la configuration reste peu touchée et reste cantonnée à de la migration de formats ou à un complément de configuration le plus souvent (si la nouvelle version ne le fait pas pour vous). Cette étape est de plus soit guidée par le système de packaging (dpkg, apt et frontend dans le cas Debian) soit suffisament documentée pour rester simple.
Et on ne fait pas cela tous les 4 matins non plus.
A l'inverse, le "Système Manager" type SuSE (YaST) reste une boite noire qui opère pas mal de modifications hors contrôle de l'utilisateur (scripts de mises à jour de la configuration lancés lors de la valiation des changements).
Cela nécessite beaucoup moins d'intervention dans la majorité des cas simples. Mais à contrario, seuls les cas simples sont gérés au travers de YaST ce qui signifie mettre réellement les mains dans le cambouis lorsqu'on souhaite particulariser son installation (et pas toujours simple de retrouver ses petits) et réinitialisation de sa configuration personnalisée en cas de reinstallations majeures.
Bref, les distributions type SuSE offre une facilité de façade (sans être péjoratif) mais ne sont sans doute pas adaptées à une utilisation un tant soit peu avancée à partir du moment où on ne souhaite pas suivre leur rythme de release (vrai pour Ubuntu aussi dans une moindre mesure).
Bon après, on ne peut pas non plus prétendre systématiquement faire le grand écart entre système de base et versions logicielles de niveau utilisateur car chaque application souhaite bénéficier des dernières fonctionnalités offertes par ce même système de base.
Et d'autres OS ne font pas mieux (voire XP et directX 10 par exemple) du reste.
# Ubuntu et les dépôts PPA
Posté par nicko . Évalué à 1.
http://planet.ubuntu-fr.org/tag/ppa
https://help.launchpad.net/PPA
[^] # Re: Ubuntu et les dépôts PPA
Posté par Nerdiland de Fesseps . Évalué à 2.
[^] # Re: Ubuntu et les dépôts PPA
Posté par Mildred (site web personnel) . Évalué à 2.
J'utilise énormément AUR sous ArchLinux (bon il faut dire qu'une grande partie des paquets que j'utilise, c'est moi qui les fait ... mais pas seulement) et je n'ai jamais vraiment remarqué de problèmes.
Je pense que ce genre de projets devraient être encouragés.
Après, il y a des problèmes de sécurités éventuels à permettre à n'importe qui de publier un paquet pouvant contenir un virus ou autre ... ce n'est pas impossible. Mais pas plus qu'un autopackage téléchargé sur un site web ou eds .deb qu'on télécharge de la même manière.
Je dirais que c'est sans doute plus sécurisé (du moins avec AUR) car on a avec chaque paquet les commentaires des utilisateurs, et certains paquets sont créés par des Trusted User (on peut raisonnablement leur faire un peu confiance). Si un problème est trouvé, il sera vite éliminé.
Pour ma part, j'aimerais bien voir une telle initiative naître qui fonctionnerait avec plusieurs distributions. Comme ça on pourrait bénéficier des paquets d'autres distributions. Il y a bien sûr des différences, qu'il conviendra de gérer, mais la plupart du code reste le même.
[^] # Re: Ubuntu et les dépôts PPA
Posté par nicko . Évalué à 1.
Cela dit certains mainteneurs qui se donnent plus de mal que d'autres, vont se faire un nom avec le temps et vont peut-être voir leur paquets acceptés dans les backports, venant ainsi en renfort des mainteneurs actuels.
# ciol, sors de ce corps !
Posté par Raphaël SurcouF (site web personnel) . Évalué à 4.
https://linuxfr.org//~ptitlouis/25313.html
https://linuxfr.org//forums/10/22694.html
Si son argumentation est sujet à troll, l'approche peut être pertinente dans la mesure où un certain nombre de personnes, de la communauté française du moins, semblent désirer un tel concept. Sauf qu'on attends toujours le « proof of concept ».
Je pense qu'aucune distribution généraliste ne pourra postuler pour une telle approche et qu'il faudra en construire plusieurs, spécialisées dans un domaine :
- Les postes de travail peuvent avoir besoin de nouvelles versions d'OpenOffice.org ou de Firefox ;
- Les serveurs LAMP de nouvelles versions de PHP, Perl, Apache, etc.
Par ailleurs, j'estime que les saveurs d'Ubuntu comblent ces besoins (une Desktop, une Server) et que les cycles de 6 mois permettent précisément de bénéficier régulièrement des mises à jour des logiciels les plus plébiscités (Firefox, Thunderbird, PHP, etc.). En effet, il s'agit souvent de gros projets qui ne publient qu'une à deux grosses versions stables (celles qui apportent précisément de nouvelles fonctionnalités) dans l'année... Ce n'est pas pour rien si Ubuntu s'est calée sur le calendrier du projet Gnome.
En fait, j'ai surtout l'impression que ces reproches portent sur le mode de fonctionnement Debian stable. Pourquoi demander à celle-ci de tout changer quand il existe déjà une alternative viable ?
[1]: il a également pas mal sollicité fcold sur Usenet mais je n'ai pas retrouvé d'archives pertinentes à ce sujet.
# La faute à la "GPL-Bis"?
Posté par yvan . Évalué à -1.
Et a lire certaines proses de gourous de la LKML (Genre Greg KH), on peut penser que c'est pas demain la veille que l'API linux soit figée sur, par exemple, une version majeure de kernel (qui dure environ 4 ans... et on ne réinvente pas le HW des machines en 4 ans pour que des interfaces bien spécifiées a la base doivent nécéssairement évoluer).
En effet, ces API à géométrie variable semblent aussi destiné a motiver les pourvoyeurs de drivers proprio à mettre tout ça en GPL et dans le kernel. Et tout le reste en patit, ainsi que les utilisateurs ce qui n'est jamais très propice à la diffusion. J'appelle ça la "GPL-Bis".
A titre perso, j'aime assez le concept des LTS ubuntu: Elles durent 3 ans. Une nouvelle version au bout de 2 ans et un an pour changer.
Ca ne règle pas réellement le pb de décorreler l'applicatif du système, mais disons que c'est un ratio emmerdes de réinstallation/nécéssité de nouveauté qui peut être convenable pour s'accomoder du monde linux tel qu'il est et je doute que ça bouge vite. Surtout que, au benefice du système de paquetage, la maintenance du système est ensuite beaucoup plus simple que sous windows, ce qui donne une organisation différente (plus de migrations complètes, moins de petite maintenance constante à la mimine) mais qui ne prends globalement pas plus de temps pour qui veut passer plus de temps a utiliser son PC qu'a la bricoler.
Mais c'est dans ce seul cadre que Linux risque hélas d'être vivable pour le grand public!
Il est vrai qu'en comparaison, un XP supporté complètement entre 2001 et 2010, avec MAJ de sécurité jusqu'en 2014... ça devrait donner à réfléchir à un juste milieu pour linux: L'applicatif compatible sur une version kernel majeure.
[^] # Re: La faute à la "GPL-Bis"?
Posté par Moonz . Évalué à 4.
Lesquelles ?
Gnome/KDE ? stables sur les versions majeures
glibc ? standardisé (POSIX/SUS), au niveau stabilité on peut pas rêver mieux
les appels systèmes ? ils ont pas bougé depuis au moins Linux 2.0
Haaa, tu veux parler de "l'API" interne au noyau ? Franchement, un soft qui tape direct dans l'API du kernel, j'en veux pas :)
[^] # Re: La faute à la "GPL-Bis"?
Posté par yvan . Évalué à -2.
Et tu veux un OS sans drivers aussi? Pourtant, le propos paraissait clair.
Heureusement que côté applicatif ça se tient... mais sans ce qui est en dessous, on n'en fait pas grand chose.
Et des mecs comme GKH qui rebelottent la gestion d'exception, de l'usb/pci etc... alors que ça existe depuis des années et qu'aucun chgt hardware profond ne le justifie... et qui clament qu'ils n'en ont rien à pêter que ça emmerde nvidia et autres... devraient aller demander à M$ leur avis sur les effets des ruptures de compatibilité. Et eux ça a été une fois en 25 ans... Linux c'est pluriannuel.
Pas dit que l'aspect gratos suffise a ce que les utilisateurs pardonnent des années...
Pourtant, avec la gabégie Vista, y'avait de quoi perçer... Bin non, malgré l'effet netbook ou M$ s'est réveillé, Linux stagne à moins de 2% d'usagers du net.
Pas dit qu'après le reveil de Redmond, linux ne soit à moins de 1%. C'est con, hein, l'effet GKH and co!?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.