L'une des grandes forces de Linux et BSD, ce sont les paquets. Mais voilà, il n'y a pas un format de paquet standard, ce système ne va pas sans défauts, et le foisonnement des distributions peut dérouter.
Cette dépêche n'aborde pas tant la distribution pour l'utilisateur final que pour le contributeur ; cependant le mouvement que l'on peut constater à travers différents efforts devra bien aboutir à un changement radical pour l'utilisateur de Linux.
Sommaire
Chez Gnome
Après tout ils sont à l'initiative de Jhbuild, alors je commence par eux, nah ! À l'heure actuelle, le moyen recommandé pour contribuer à Gnome est de passer par Jhbuild : ce système ingénieux permet d'installer les versions instables des modules GNOME dans une arborescence à part, et d’exécuter les binaires générés dans cet environnement (avec les bonnes variables). Ainsi on garde un système en version stable, et l'on peut tester et modifier un ou plusieurs modules GNOME dans leur coin, sans désinstaller leur version stable.
Très pratique, mais Jhbuild ne va pas sans défauts : il peut s'avérer très fastidieux de mettre en place son environnement, puisque l'on rencontre systématiquement des petits soucis au moment de la compilation.
Os-tree
GNOME-OS, petit pseudo qui fut la source de bien des confusions, est le projet d'offrir aux développeurs, designers, traducteurs, testeurs et autres contributeurs un système efficace et simple. Concrètement, il est d'ores et déjà possible d'installer une image virtuelle incluant les développements les plus récents et de la lancer très facilement. La notion ayant été diffusée au Guadec 2012, elle était déjà abordée dans cette dépêche. L'auteur, Colin Walters, l'a présenté ici.
Techniquement, on parle de OSTree, un outil créant des images virtuelles que l'on peut éxécuter (soit dans une machine virtuelle, ce qui est au moins pour l'instant recommandé, soit carrément en rebootant dessus, ce que je n'ai pas testé). Il ne s'agit pas de remplacer les distributions. C'est un système extrêmement pratique pour développer et tester : les distributions s'en trouveront améliorées. Opposer OSTree à jhbuild n'est pas tout à fait exact : on peut très bien utiliser OSTree pour avoir sous la main un environnment à jour et faire mumuse avec jhbuild par dessus, ce qui effectivement reste un procédé rapide.
Bien sur chez GNOME le concept est directement lié à celui, fonctionnel, d'écosystème cohérent : une image testable en live, sert justement aux designers à suivre de près le développement des applications, pour travailler à fournir un produit cohérent, soigné, etc. Et l'idée va de paire avec le projet de fournir un SDK aux développeurs GNOME (maintenant que le langage JavaScript a été choisi, reste à mon sens à documenter, puisque actuellement il y a de grosses lacunes, et à implémenter l'IDE qui va bien).
Logithèque
Plus récemment, une logithèque a vu son implémentation démarrer. Il s'agit d'abord d'intégrer dans GNOME ce qu'Ubuntu a fait de son côté il y a déjà bien longtemps, à l'image des App Store, à savoir proposer à l'utilisateur une liste d'applications disponibles, avec des notes, captures d'écrans, etc.
Mais il s'agit aussi d'une volonté de proposer à l'utilisateur des applications qui ne soient pas forcément sous la forme de paquets.
Si comme je le rappelais GNOME OS ne se veut pas un concurrent des distributions, à mon sens il y a au moins re-définition massive de la répartition des rôles entre l'environnement de bureau et son distributeur : de nombreuses tâches qui incombaient jusqu'ici aux distro sont intégrées, dans une volonté de proposer une expérience identique quelque soit la distribution. (Mais ce sujet upstream/distro demanderait d'aborder bien d'autres points, comme l'exemple évident de la concurrence récente entre l'outil de configuration post-installation GNOME et celui de Fedora, aux tâches pouvant se recouper)
Ailleurs
L'idée d'éviter les paquets ne date pas d'aujourd'hui. Vous vous souvenez encore des installeurs de Loki !
Avant de lister de manière fort incomplète des alternatives vieilles ou plus récentes, le plus précieux me parait de renvoyer à un avis de Ingo Molnar, employé de Red Hat travaillant sur le noyau, postée sur G+ : pour résumer, la notion de paquets est dépassée car les distributions veulent contrôler beaucoup trop, sont donc trop lentes à intégrer de nouveaux venus ou simplement les mises à jours. Son avis est détaillé sur une première partie et une deuxième.
- NixOS Un idée du bundle et une distribution se basant sur cette idée.
- 0install , utilisé par exemple du côté du bureau ROX
- Glick2 . Une idée fait son chemin de l'utiliser en complément de OSTree.
- Ubuntu : sa propre alternative aux paquets a été traitée ici, mais Martin Pitt s'intéresse de son côté à OSTree : des images OSTree sont construites pour Ubuntu depuis peu.
- BTRFS : ce système de fichier permet de créer des "snapshot", aussi facilement qu'on clone une vm, ce qui permet de revenir en arrière. Le gros point fort de BTRFS étant de ne copier que les fichiers qui sont modifiés, ce qui serait donc en théorie utilisable par des gestionnaires de paquets pour proposer différentes versions. Mais même en préservant /home, quid si /var a été modifié et que l'on revient en arrière? voir ces commentaires ici-même.
Une note sur Fedora et les bundles
Fedora possède une règle pour ses paquets : il ne faut pas qu'ils intègrent de "bundles", des librairies ou bouts de codes disponibles ailleurs mais intégrés en dur dans le code (des exceptions étant autorisées). La logique étant que si des problèmes se posent dans le code, le fait qu'il soit copié à droite à gauche empêche de le corriger facilement : il ne suffit plus de modifier un paquet, mais il faut identifier tous les paquets ayant copié le même code problématique. Si l'argument fait parfaitement sens, les trois exemples ci-dessous en sont des contreparties.
Par exemple Chromium utilise de nombreux morceaux, mais modifiés pour son usage, et pas "upstream" : ce fut la raison de refuser l'introduction d'un RPM dans Fedora
Le problème peut également se poser avec l'utilisation de submodule git, puisque alors un logiciel va reprendre dans ses fichiers d'autres lui étant extérieurs, ou encore avec php-composer (toujours pas empaqueté chez Fedora, ce qui fait que OwnCloud 5 n'y figure toujours pas).
Conclusion
Eh non, pas encore de conclusion! à vous codeurs de l'écrire… en espérant que j'ai oublié encore plein d'autres alternatives. Ou à moins que la conclusion ne soit, tout simplement, les applications en html5…
# Mouais
Posté par haleth . Évalué à -8.
Mouais
dpkg est déjà awesome, et aucun des projets lister ne lui arrive à la cheville.
Beaucoup de bruits pour rien..
# Ca commence mal...
Posté par Zenitram (site web personnel) . Évalué à 10.
A partir de la, on retombe dans la même chose qu'avant : une séparation arbitraire suivant ton gestionnaire de bureau.
Ca change de la séparation arbitraire en fonction de ta distro, mais même façon d'agir --> même résultat…
On ne change pas une équipe qui gagne (pas).
[^] # Re: Ca commence mal...
Posté par Lizzie Crowdagger (site web personnel) . Évalué à 4.
Il me semble que tout ça part de l'idée de faciliter le développer des applications GNOME (au sens "utilisant l'eco-système", pas forcément approuvées par GNOME). D'oû le truc de préconiser JavaScript, et aussi de permettre de distribuer/installer plus facilement des applis développées pour GNOME. Ça peut être contestable, mais je trouve que ça a quand même un certain sens.
Je me dis que ça rejoint, même si c'est à un niveau différent, les langages qui proposent des outils pour installer des bibliothèques ou des applis, comme RubyGems, etc.
[^] # Re: Ca commence mal...
Posté par saltimbanque (site web personnel) . Évalué à 4.
OSTree est donc un projet susceptible d'intéresser du monde en dehors de GNOME - fut-ce de par ses défauts, ces derniers pouvant contenir des enseignements. Désolé d'avoir un esprit ouvert?
[^] # Re: Ca commence mal...
Posté par Adrien . Évalué à 10.
Désolé de te contredire, ça marche pas mal… Je sais que tu aimes à montrer que Linux c'est que de la merde face à la concurrence, mais pour le coup, à mon avis tu fais fausse route.
Par exemple le projet Debian. Le but est de fournir un système, en respectant certains critères, philosophique, de qualités, etc. Un gros travail est donc réalisé au niveau de la distribution pour améliorer les logiciels empaquetés : vérification des licences, outils comme lintian pour améliorer la qualité, portage sur d'autres plate-forme (hurd, freeBSD, ARM, etc.), traductions, tri des bugs, etc. Tout ce travail ne serait très probablement pas réalisé par les dev.
Ce fonctionnement n'est pas idéal, mais il est plébicité par pas mal de gens, certes plutot sur les serveurs que les postes utilisateurs. Tu me répondra que c'est un enfer pour les dev et les utilisateurs quand l'outils n'est pas packagé. Tout à fait, mais le travail du packageur n'est pas inutile : il apporte réellement quelque chose, qui emmerde souvent le dev mais profite à l'utilisateur : l'intégration.
Un argument qui revient sans cesse est qu'il faut packager le truc pour plein de distribution et c'est rébarbatif. À mon avis c'est un mauvais argument : Il est possible d'utiliser le même paquet pour Debian et Ubuntu. Mais en pratique les deux distributions ont des buts différents, l'approche sera donc différentes pour pas mal de paquet, et pas que sur un point de vue technique. Si on veut fournir un truc identique pour toutes les distrib, c'est possible, certains le font depuis très très longtemps : un tar.gz statique par exemple.
Là on veut squeezer le travail des distro, c'est pas forcément une bonne idée, puisqu'il y a de forte chance que le logiciel ne s'inscrivent plus dans le but de pas mal de distribution. Soit l'utilisateur se reconnait dans ce but et ça va lui poser problème, soit non et il ferait mieux de changer de distribution…
[^] # Re: Ca commence mal...
Posté par saltimbanque (site web personnel) . Évalué à 3.
les tarballs fournissent justement la source utilisée par les paquets, afin de se baser sur une version définie.
L'idée est de fournir autre chose, en parralèle du travail de distribution "classique" qui reste la référence. La faute au titre de la dépêche (oups, mauvaise idée).
# Et prochainement...
Posté par Maclag . Évalué à 10.
Programmer sans langage
Après une brève intro sur le foisonnement inutile de langages, je vous expliquerai que vous devriez utiliser du C, du JS, ou du OCaml. Quand il n'en restera qu'un, on ne parlera plus de langage.
Intégrer sans intégration
On n'a plus besoin de distro qui harmonisent des trucs inutiles, puisqu'on a un gestionnaire de paquets amont et toute façon on aura tout porté en OCaml qui pourrait très bien proposer son app store.
Commenter sans fond ni argument
Ben quoi? Je viens pas de vous en donner un cas d'école??
-----------> [ ]
# Par rapport à Guix c'est comment?
Posté par kadalka . Évalué à -6.
Par rapport à Guix c'est comment?
Il est meilleur ? Plus complet ? Plus abouti ? Plus stable ? etc.?
Merci de nous en parler un peu…
[^] # Re: Par rapport à Guix c'est comment?
Posté par saltimbanque (site web personnel) . Évalué à 3.
Je découvre le commentaire un peu tard pour y répondre aujourd'hui, mais Colin Walters présente ici une (trop) brève comparaison.
# Trop lentes ?
Posté par Jiehong (site web personnel) . Évalué à 9.
Étant sous Archlinux, cet avis est simplement fallacieux pour moi. D'ailleurs, le système des paquets fait que les mises-à-jours sont plus régulières, et mieux suivies.
Par contre, l'idée de paquet universel — standard et adopté par la majorité des distributions — a vraiment du sens ( et non fait du sens, hein). Cela faciliterait grandement la tâche des contributeurs, mais aussi des distributions. Ça implique de regrouper les plus grands acteurs des distributions libres autour d'une table, et de se mettre d'accord sur le fond, mais aussi la forme pour gérer tous les cas. C'est ça l'avenir pour moi.
[^] # Re: Trop lentes ?
Posté par claudex . Évalué à 8.
Un paquet universel est loin d'être possible. Pour certains paquets, c'est le cas. Mais dès qu'une bibliothèque n'a pas la même ABI sur deux distributions ou que les chemins pour certaines ressources , ce n'est pas pour rien que quand des RPM sont distribués, il y a des version pour Red Hat, Fedora, Suse et Mageia. Même chose avec les deb pour Debian et Ubuntu.
« 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: Trop lentes ?
Posté par Jiehong (site web personnel) . Évalué à 8.
Il faudrait donc unifier les chemins, et la logique sous-jacente. Je crois, en fait, que cette démarche aboutirait à la création d'une seule distribution, puisque peu de choses pourraient distinguer deux distributions basées sur une « architecture » de paquet unifiée.
L'éclectisme des distributions actuelles est aussi une force que je voudrais pas voir disparaître…
[^] # Re: Trop lentes ?
Posté par peikk0 . Évalué à 5.
[^] # Re: Trop lentes ?
Posté par Kekun (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 26 mai 2013 à 18:14.
Il propose justement l'inverse : au lieu de se dire "les autres font de la merde, faisons notre solution TroPlusseMeilleure3000" il propose un truc comme "cherchons à faire discuter tout ceux qui ont proposé des solutions différentes sur une solution certe nouvelle mais unifiée depuis le départ".
Ça a peu de chances d'aboutir, certes, mais ça coûte rien d'essayer, même si seulement un tiers des distros se mettent d'accord sur un truc commun entre elles ça serait déjà un grand pas en avant.
[^] # Re: Trop lentes ?
Posté par peikk0 . Évalué à 4.
Le résultat serait le même. ;)
[^] # Re: Troplentes ?
Posté par Juke (site web personnel) . Évalué à 8.
Pas forcement, le systeme de package peut lire dans la conf "je stocke mes binaires ici" bon par contre il faut unifier le systeme de conf, c'est un peu la poule et l'œuf.
[^] # Re: Troplentes ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
C'est déjà fait: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Troplentes ?
Posté par Kekun (site web personnel, Mastodon) . Évalué à 6.
Quoiquoiquoi ? Un truc fait par Lennart Poetering ?!? Jamais personne n'en voudra ! :p
[^] # Re: Troplentes ?
Posté par kadalka . Évalué à -10.
Amen… :P
[^] # Re: Trop lentes ?
Posté par saltimbanque (site web personnel) . Évalué à 4.
effectivement ce n'est pas pour rien que cette distrib sort du lot. Justement elle fait partie du mouvement allant du contrôle vers l'upstream. non?
[^] # Re: Trop lentes ?
Posté par xcomcmdr . Évalué à 2.
Exactement, et on évite les patchs au maximum. Tant que ça compile et que ça fait pas de crash quand on le lance, y'a pas besoin de patcher.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Trop lentes ?
Posté par Anthony Jaguenaud . Évalué à 6. Dernière modification le 26 mai 2013 à 22:36.
Oh, oh… ;-p
Pour moi, c’est contre productif. Un système universel revient à avoir une seule distribution. Ce qui n’est pas souhaitable pour GNU/Linux. Je pense que de multiple distributions ont leurs places pour des utilisateurs différents. Certaines applications peuvent avoir du mal à coucher ensemble à cause de dépendance contraire (version de lib différentes)(2 lib qui implémente le même service Dbus)… il peut y avoir plein de raison. Sans multiple distributions, moins de fork (àmha).
Linux est un melting pot ou tout se mélange, du bon, du moins bon… mais c’est aussi ça force, évoluer rapidement. Sans cet aspect, tiendra-t-il longtemps, je ne le crois pas.
Pour avoir quelque chose de plus stable de se côté, il vaut mieux aller chez BSD.
[^] # Re: Trop lentes ?
Posté par kadalka . Évalué à -10.
Au contraire il faut une base stable pour tous, quitte à n'avoir qu'une seule distribution.
Sinon nous serons à la merci d'une distribution et d'une seule pour cause d'incompatibilité au lieu de pouvoir prendre d'autres distributions.
Android était quasiment seul avec iOS donc le combat a été plus facile pour Android.
Le noyau ne suffit pas pour qu'une distribution se démarque.
Un dicton le dit bien : l'union fait la force
Ce n'est pas un crime: il est libre aussi.
[^] # Re: Trop lentes ?
Posté par barmic . Évalué à 5.
Je comprends pas.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Trop lentes ?
Posté par kadalka . Évalué à -10.
Vous avez raison de demander des précisions
J'ai écrit un peu vite… sans donner d'explications…
1/ une personne est contre l'unicité d'un logiciel de packaging.
Bon. OK.
2/ J'explique qu'il vaut mieux prendre ce risque.
3/ Le problème si chacun fait pour soi son logiciel de packaging c'est que la distribution qui aura la meilleure force imposera SA loi comme il lui plaira.
C'est une des plaintes contre Red Hat (systemd, etc.) ou contre ubuntu (pour certaines choses).
4/ Bref, il vaut mieux un même système de packaging quitte à diluer tout le monde.
Mais on ne veut pas qu'une seule distribution phagocyte tout le monde sans possibilité de réagir.
Dans certains domaines Red Hat commet cette erreur et dans d'autres c'est Ubuntu.
De toutes les façons les sociétés de services proposent souvent divers distributions dans leur offre de service (debian, centos, etc.) donc je ne vois vraiment pas où est le problème…
J'espère que c'est un peu plus clair.
[^] # Re: Trop lentes ?
Posté par Anthony Jaguenaud . Évalué à 4.
Tu es incohérent. (voir le gras).
Quelle sera la différence entre les distribution, si on a un seul type de paquet, un seul dépôt centralisé ?
Windows, MAC OS ne sont pas des crimes, ils répondent à un besoin. Ce n’est pas le mien, mais je peux le comprendre.
Je prends mon cas :
J’utilise gentoo car c’est la seule distribution qui me permet de personnalisé aussi bien mon ordi.
Pour ma femme, j’utilise une debian stable, car elle n’a pas besoin que les applications change tous les jours de look, de fonctionnalité, de bug…
Pour mon fils, j’utilise debian stable, car je ne veux pas y passer du temps et qu’une distribution « source » sur son ultra portable n’est pas envisageable.
Pour ma maman, j’utilise debian stable pour les même raison que pour ma femme.
La personne à qui je répondais utilise Arch parce qu’il veut des programmes toujours à jour, parce qu’il est fan de systemD, ou pour une autre raison.
Les distributions sont là pour répondre aux besoins de chacun. C’est la diversité qui fait la force de l’open source et le libre. Si un programme se démarque, il gagne la visibilité et peut devenir un « standard » voit systemD ;-)
Sinon, pour les modérateurs, c’est quoi ce : « Do not feed the troll! » ? Ça dépend de la note du commentaire précédent ?
[^] # Re: Trop lentes ?
Posté par kadalka . Évalué à -10.
j'avais mal expliqué…
J'ai répondu ici :
http://linuxfr.org/news/distribuer-sans-distributions#comment-1454142
Ca devient une obsession chez vous… :P
Oui bon, debian c'est toujours mieux dans la majorité des cas.
On ne va pas trop s'étaler dessus… (misc n'est pas loin)
Je ne nie pas le fait que plusieurs distro est utile mais je constate que pour faire avancer plus vite linux, il faut créer un format de package universel compatible pour tous quitte à risquer de n'avoir qu'une seule distribution ce qui je reconnais ne va ni plaire à ubuntu et encore moins à Red Hat…
Pourtant je suis convaincu que c'est le seul chemin. L'union fait la force.
Je suis même d'avis que si linux pouvait se rapprocher de BSD ce serait vraiment idéal.
(Oui je sais qu'on va encore me taper dessus pour çà…)
[^] # Re: Trop lentes ?
Posté par Misc (site web personnel) . Évalué à 3.
Oui :
https://github.com/nono/linuxfr.org/blob/master/app/views/comments/new.html.haml
Quand un commentaire est à -10 (comme c'est le cas de kadalka par défaut de part sa capacité à faire preuve d'une obsession malsaine sur debian et fedora, et à pontifier sur des sujets qui ont l'air de le dépasser) va toujours avoir ce message. C'est pour ça que je réponds plus directement aussi.
[^] # Re: Trop lentes ?
Posté par kadalka . Évalué à -10.
Je comprends mieux maintenant pourquoi linux a du mal à décoller.
Effectivement, avec un tel état d'esprit çà va être dur… :'(
C'est plutôt toi qui n'est pas à la hauteur (fedora qui crashe) et je parle pas souvent de debian ni de fedora.
C'est juste que tes copains ne supportent pas les antiFedora.
J'ai vu ailleurs que debian est bien devant or tu n'es pas d'accord n'est-ce pas ?
# make --prefix
Posté par Sytoka Modon (site web personnel) . Évalué à 10.
Comment qu'on fait sur les machines de calcul ?
On installe sous /opt/mon_prog/version/… puis on ajoute les chemins qui vont bien dans des variables d'environnement : PATH, PYTHONPATH… Cela peut être fait de manière module et assez proprement avec "modules" (si celui-ci n'était pas basé sur Tcl que je n'aime pas).
Bref, la très grande majorité des programmes peuvent se contenter de la structure historique d'UNIX avec les variables d'environnement. Il faut que les codes explicites mieux sur leur site comment installer ailleurs (en général via --prefix) et les variables d'environnement importante.
Il faut arrêter de trop programmer en variable global avec des services qui ressemble trop à une base de registre. Sous une apparente simplicité, cela complexifie énormément les installations parallèles et l'utilisation parallèle de X version.
[^] # Re: make --prefix
Posté par Tarnyko (site web personnel) . Évalué à 5.
Pour rebondir sur ton commentaire Sytoka, une solution qui fonctionne et automatise les étapes que tu écris -plus l'insertion des dépendances.
[^] # Re: make --prefix
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Ca a l'air intéressant mais j'ai quand même des doutes que cela marche en pratique sur des cas complexe comme OpenFoam par exemple… (doit avoir 40 variables d'environnement pour que celui-ci marche). Ce truc me rappelle ThinApp de Vmware après une lecture très rapide…
[^] # Re: make --prefix
Posté par Loïc Ibanez . Évalué à 1.
Merci ! Merci ! Merci ! Je ne connaissais que APPimagekit format pour faire ça, mais CDE m'a l'air bien mieux.
Surtout qu'il cite tiny core linux ! Ce qui signifie qu'il est sur la même "piste" que moi :-D
Avec xpra/xdummy ça commence à faire un ensemble léger et très intéressant pour exécuter et visualiser à distance une mono-application.
[^] # Re: make --prefix
Posté par Misc (site web personnel) . Évalué à 3.
C'est le principe des software collections :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/1/html-single/Software_Collections_Guide/index.html
http://developerblog.redhat.com/tag/scl/
C'est par exemple utilisé par les équipes d'Openshift pour faire du ruby 1.9 et faire tourner toute l'infra sur des RHEL 6.
Fedora a décidé de ne pas suivre ce chemin contrairement à RHEL :
https://fedoraproject.org/wiki/SoftwareCollections
même si des tentatives ont été faites de faire adopter ça upstream :
http://lwn.net/Articles/529912/
[^] # Re: make --prefix
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Il faut dire que ca écrit sous /opt… J'ai horreur des paquets propriétaire (debian) car il écrivent sous /opt. Dernier exemple en date, mendeley. Lui c'est même un virus car il rajoute sa clef et son dépot APT direct. Une installation à la main marche tout aussi bien !
# LVM
Posté par barmic . Évalué à 4.
lvm fait ça depuis longtemps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# je suis perplexe
Posté par hervé Couvelard . Évalué à 10.
En fait il faut voir le système de paquet comme un dépôt interne à une distribution qui à fait des choix, loin en amont, pour fournir un produit final, complet et cohérent par rapport aux choix qui ont été faits.
EN plus de 10 ans, des systèmes qui passent au dessus des paquets, j'en ai vu des tas : cela part de l'idée que le dev il sait pas faire et il y a tellement de distribution qu'il peut pas gérer, faisons un truc unique qui marche partout. ca existe déjà : c'est le compilé statique, firefox le fait.
Dire que la distribution fait une sorte de tri suivant des critères techniques et/ou philosophies c'est montrer qu'elle fait son travail. Celui qui est sous debian, ne veut pas la même chose que celui sous ubuntu : vouloir porter la même chose aux deux, est probablement techniquement intéressant mais pratiquement peu utile, la preuve aucun truc n'a réellement marché, tout simplement parce que ce n'est pas intégré. Pourquoi construire une architecture d'os dans un os ? autant distribuer des VM, autant installer l'autre sur une autre partition. Parce que le principal soucis des dev, ce n'est pas tellement le paquet, c'est le choix des libs, tout le reste descend de cela. Et le développeur moyen il a tendance à intégrer plein de nouvelles libs dernières versions, que l'on ne retrouve pas sur les machines installées.
Une idée serait de fournir une ferme de compilation ou l'on place son programme source et son makefile et la ferme compile la bête pour toutes les architectures et distributions qui sont renseignées, chaque distrib fabriquerait les règles qui lui conviennent et la bête sortirait un paquet parfait.
Mais on en revient encore aux problèmes des libs.
Enfin, le fait que chaque distribution contrôle, permet de savoir qu'on ne va pas se retrouver avec une merde. Voila le mail que j'ai reçu aujourd'hui :
"Je suis un peu z'énervée…
J'ai regardé une chronique sur un jeu vidéo pc gratuit, le jeu a
l'air sympa, je me suis dit que j'allais le télécharger (sur windows forcément).
J'ai trouvé un seul site où le télécharger, j'ai fait tout ce qu'ils m'ont dit de faire et… ça n'a pas marché. J'ai essayé deux fois, rien à faire, le jeu n'était pas sur mon pc.
Par contre ! Je me suis retrouvé avec une bonne demi-douzaine de programmes qui se sont installés à cette occasion ! Putain !!! J'ai passé genre une demi-heure à tout désinstaller, ça m'a un peu gavé."
C'est ce que vous voulez voir arriver sur vos linusque ?
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 26 mai 2013 à 23:31.
Pourquoi fait-il ça? En général parce que les versions fournis par les distribs ont un train de retard.
Ce problème a été résolu par Maven, RubyGems, pip, npm & co (seul C/C++ n'est pas à la page). Il faudrait que ces solutions soient pris en compte par les distributions pour la création de paquets.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Adrien . Évalué à 8.
course à la nouveauté vs dépendances stables… on est bien sur deux conceptions de l'informatique :-)
[^] # Re: je suis perplexe
Posté par Kekun (site web personnel, Mastodon) . Évalué à 7.
C'est l'éternel problème du développeur :
- avoir un environnement stable avec des libs qui seront "obsolètes" quand l'appli sera prête à être livrée ou,
- se taper un environnement instable pour avoir les libs que les utilisateurs auront dans leurs environnements stables au moment de la sortie de l'appli.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 9.
Il y a stable et obsolète.
Un exemple: la plupart des libs pour les jeux (SFML, allegro, clanlib) dans debian stable ont une version majeure de retard.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 3.
Même si la version n'était pas obsolète à un temps T, elle va l'être à un temps T+N tot ou tard. Et si le N est de 1 à 2 ans, alors pas grand chose va réussir à corriger ça du coté des distributions, sauf à violer le principe de non modification, qui est la pour des tas de bonnes raisons.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
D'accord, mais que doit faire le développeur?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 2.
C'est tout le noeud du souci et c'est le souci que les distributions tentent de régler aussi bien que les développeurs.
Je note que l'option "embraquer toute les dépendances" implique aussi de ne pas bénéficier des correctifs de bugs, et ce genre de choses.
Et que c'est aussi la solution de microsoft en proposant directx comme un addon au système.
Et la seule solution saine, c'est d'avoir des ABIs relativement stable. Ce que personne ne semble vouloir faire pour une raison X ou Y.
Essayons d'aller de l'avant, toi, tu voudrais avoir quoi en terme de support ( en terme de durée, quitte à donner la durée sous forme de date de sortie de distro, genre "j'aimerais que mon soft marche sur N-1 de debian sans modif et en N aussi") ?
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Peut être faudrait-il que debian choisisse un petit nombre de lib dont les développeurs seraient motivés pour créer une sorte de "core API set" sur laquelle on sait que l'on pourra compter pour être stable, mais pas obsolète?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 10.
Ok, je le fait. Je choisit SDL. Tu es satisfait du choix ?
( c'est une question réthorique, je sais que tu veux autre chose)
Et attends, mieux. je prends clanlib, et je dit "bon, maintenant, faut que ça soit maintenu". Les devs upstreams veulent pas et casse la compatibilité, qui le fait ?
Ton idée, c'est vieux comme linuxfr.
C'est aussi ce que la LSB a fait, et personne n'a suivi la LSB. Pire, les gens râlent car ça rajoute du bloat sur leur installation minimal ( moi le premier, j'ai installé une RHEL, j'ai viré le support lsb car ça m'a fait chier). C'est aussi ce que fait Gnome ( proposer une plateforme), ce que fait KDE (et qui garde la compatibilité pendant longtemps ), et pourtant, les gens continuent à faire en dehors des toolkits. C'est aussi ce que fait python, et les modules tierces pullulent.
Bien que ça semble être une solution séduisante, dans la pratique, c'est pas tant un souci technique qu'un souci de mentalité. Ça marche sous Windows car on laisse pas le choix. Si Microsoft te dit "non", tu obéis. Sous Linux, une distribution peut dire "on veux pas de ça pour tel raison objective", tu as tout de suite des dépôts tierces qui arrivent. C'est comme retirer des fonctions. Quand Apple le fait, c'est une ode au design propre et à Steve Jobs qui s’élèvent des utilisateurs rassemblés en train de chanter. Quand c'est GNOME, on part cherche les torches et les fourches contre ces fachistes sanguinaires qui égorgent nos programmes.
Donc oui, dire "on veut avoir qu'une version minime", c'est un tabou du logiciel libre.
C'était vrai il y a 5 ans :
http://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html
C'est toujours vrai aujourd'hui.
Et qu'on me dise pas "pourtant, tout le monde est d'accord sur le fait qu'il y a trop de trucs", car tout le monde est pas d'accord sur ce qui est en trop. Pour chaque truc dans une distribution, y a au moins une personne qui a écrit ça qui est pas d'accord, et au moins une pour packager. Et par exemple, tu va définir ton core api. Tu va prendre qt et gtk ? Ou qt ou gtk ? Ou pareil pour les languages, tu gardes perl, ou pas ? Et nodejs ?
Et si les gens ne suivent pas ton core set api, on fait quoi ? On rajoute ce qui manque ? Et si après 2 ans, les gens changent d'avis ( genre nodejs est à la mode ), on ajuste, ie on retire brutalement pour faire chier les gens qui veulent pas changer, on rajoute des ressources par magie jusqu'à ce que ça donne la même chose que la debian actuelle ?
Peut être que je suis juste un pisse vinaigre, mais j'aurais tendance à croire ça plus facilement si les efforts d'avant n'avaient pas échouer et si on avait amorcé un début de discussion avec un truc minimal, et un début de consensus. On est même pas la depuis des années.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ben non, si je devais commencer un jeu C++ aujourd'hui, je prendrais effectivement la SDL, même si c'est super pénible, mais je vois beaucoup de projets se lancer avec la SFML.
Par contre pour mon jeu actuel en Java, la situation est catastrophique:
Avec un label debian stable premium de la bombe de boulette de balle, qui si tu ne l'as pas montre que ton API est pourri et instable :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Loïc Ibanez . Évalué à -1.
Clap clap ! J'applaudis des deux mains, des deux pieds et de la tête ! Je n'ai jamais pu comprendre qu'un système "libre" puisse priver l'utilisateur de la plus élémentaire des libertés : installer ses programmes où il le souhaite !
Je veux que l'OS soit dans /OS_DANGER_PAS_TOUCHER, que les programmes soient dans /programmes et que les données soient dans /donnees. Parce que c'est MON ordinateur. Et sur MON ordinateur c'est MOI qui décide comment les éléments sont rangés. Et au passage les trois dossiers sont sur 3 supports de stockage différents et /OS_DANGER_PAS_TOUCHER est sur un support en lecture seule - parce que je me connais et que deux précautions valent mieux qu'une… :-)
Et les manuels je les veux dans /programmes/miguel/. Parce que ça me plaît et que je trouve ça drôle et original.
Est-ce que j'impose aux empaqueteurs du monde entier de ranger leurs fichiers comme moi ? Non. Ils font ce qu'ils veulent avec leurs ordinateurs et moi c'est pareil.
Même Microsoft n'impose pas d'installer ses programmes dans "c:\program files" - même si c'est plus subtil que ça (dlls, base de registre etc…)
C'est bien simple je hais TOUS les gestionnaires de paquetages. Ils me posent des questions que je ne comprends pas et ils refusent de ranger les choses dans MON ordinateur comme JE l'ai décidé. Ce sont TOUS des programmes totalitaires. Et inutile de m'expliquer qu'en tapant une ligne de 2345 options derrière apt-get/yum/synaptic/ on peut y arriver. De toutes façons je cherche le manuel dans /programmes/miguel et - avouez que vous vous attendez à la chute - il n'y est pas !
Pour continuer sur cette voie et en rebondissant sur le sujet de l'article - oui je sais j'aurais dû rédiger un commentaire à part - pourquoi ne pas parler de : Portablelinuxapps.org et de l'Appimagekit format ?
C'est également une voie similaire qui a été choisie par les développeurs de Tiny Core Linux avec avec les packages .scm.
Comme je regrette qu'ils n'adoptent pas l'appimagekit format…
[^] # Re: je suis perplexe
Posté par Adrien . Évalué à 2.
À mon avis c'est une question très personnelle. Pour moi, le développeur doit très clairement privilégier le premier cas. Avoir des logiciels qui dépendent sans arrêt du dernier cri à la mode n'est pas spécialement sain, que ce soit pour l'empaqueteur ou l'utilisateur. Je préfère très nettement que les bibliothèques ne soient utilisées que lorsqu'elles sont un minimum stabilisée, c'est beaucoup plus pérenne, et ça demande moins de travail derrière.
Mais encore une fois, c'est très personnel, et ça rejoint presque une conception plus large : est-il préférable que le monde évolue à toute vitesse, ou faut-il mieux privilégier ce qui dure dans le temps…
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Le problème c'est que sous Windows et Macosx, les versions les plus stables sont les dernières. Sous Linux c'est plutôt les plus anciennes.
Comment faire du multiplateforme avec ces deux rythmes?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Adrien . Évalué à 2.
À mon avis il y a un problème de vocabulaire entre nous :
– stable : qui ne change pas, qui dure dans le temps
– fiable : dont le comportement est prévisible, sans bugs.
Dire que la stabilité c'est la dernière version est à mon avis un contre-sens : toutes les versions sont stable… jusqu'à la suivante, ou au changement d'API/ABI pour les bibliothèques. À mon avis tu voulais dire que les dernières versions sont les moins buggées ?
plus haut, tu dis :
Concernant Debian, le choix est fait d'avoir une distribution stable sur deux ans, ça veut dire que pendant deux ans, les paquets garderons la même version (et les même bugs). On a donc ce que tu recherches, mis à par l'obsolescence. Mais là c'est un choix des développeurs de la bibliothèque : si entre-temps la bibliothèque est obsolète, c'est que les dev vont trop vite pour Debian… mais sans doute pas assez vite pour celui qui veut voir corrigé le bug XXX :-)
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Oui, en fait je me rends compte le problème est difficile à résoudre:
Ca veut dire qu'à la sortie du jeu, il dépendra d'une lib vieille de 3 à 5 ans.
Combien de libs propose de garder une compatibilité parfaite sur une si longue durée ? Malheureusement trop peu.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Adrien . Évalué à 2.
À mon avis, la situation peut être améliorée de deux façons :
– faire en sorte que les gens participent à la distribution. Avec plus de main d'œuvre, on peut espérer quelques accélérations bienvenues : nouvelles version dans testing plus rapidement, correction des bugs critiques plus rapide et donc, le cycle de freeze avant une stable sera réduit.
– faire en sorte que les bibliothèques s'envisagent sur du long terme. Ainsi on aura des trucs plus fiables, plus solide, sur lesquels on peut capitaliser.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Anéfé, il faut peut être commencer par mettre à jour la doc et les outils de packaging avant le reste :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 4.
Faire rentrer ça dans les best practices.
Par exemple, utilise abi-compliance checker dans les tests ( genre dans jenkins ) de façon systématique. Une distribution peut le faire ( rosa/mandriva le fait ), mais idéalement, faut que ça soit upstream, et que les upstreams soient sensibles.
Ou déjà, avoir des critères plus précis ou plus facile à transmettre de ce qui est une bonne API, pas juste un feeling, car sinon, personne ne va réussir à faire une bonne API sans se planter 20 fois. Même si au final, ça ne réduit le nombre d'erreur qu'à 10 fois, ça peut faire la différence.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
C'est très C++ centré. Il faut aussi penser aux autres langages!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Tu demandes 5 ans. Je fais par exemple marcher Nedit basé sur Motif (donc sur X) qui a je ne sais combien d'année… J'ai encore des programmes en Perl/Tk qui marche sans aucune modif depuis 10 ans.
Je sais qu'on est dans une période ou un certain nombre de personne veulent tout virer, tout modifier ! L'API public de Linux change très peu. Les nouvelles fonctions mettent du temps pour être vraiment utilisé et parfois cela a du bien (permet de virer un truc que l'on croyait bien mais en fait non).
Je ne dis pas qu'il faille rester sur le passé. Je pense simplement que les anciennes API ne sont pas toutes moisis et que les garder quelques années est un plus. J'ai pas envie de développer sur un truc qui change tous les deux ans.
Pour Debian, il faut toujours penser aussi à l'aspect multi-architecture. Combien de programme ont des bogues dès que l'on sors du x86 ?
[^] # Re: je suis perplexe
Posté par Gabbro . Évalué à 3.
Si encore ce n'étais que Debian stable (qui cherche ça). Dans Fedora, Allegro est en version 4.4 (la 5 est sorti en 2011) mais SFML devrai être en 2.0 pour la prochaine version.
Ayant récemment eu envie de créer un jeu sous linux, je me retrouve avec pygame et python2, car c'est le seul binding python qu'on retrouve partout.
Ce que j'espère, c'est que la sdl2 qui devrai sortir d'ici quelques temps sera prise rapidement par les distributions, histoire d'avoir un bibliothèque efficace et présente partout.
[^] # Re: je suis perplexe
Posté par claudex . Évalué à 3.
J'en profite pour faire ma pub, si tu as des idées d'amélioration de la news, n'hésite pas
« 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: je suis perplexe
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 0.
Je ne comprends pas pourquoi tous les développeurs sont fondus de ces systèmes dangereux. Les systèmes de packaging tels que Pip ou Pear ne signent pas les paquets, les paquets sont téléchargés on ne sais où, pas de contrôle du fonctionnement, etc. Sans compter qu'il n'y a pas de mise à jour au niveau système, et qu'il arrive que ces charmants robots polluent /usr.
Bref, en C/C++, on peut se construire des environnements spécialisés, avec des versions particulières, mais il faut effectivement un peu se sortir les doigts du fondement et comprendre ce qu'on fait.
[^] # Re: je suis perplexe
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Je ne connais pas Pip ou Pear, mais les dépendances Maven sont signés, ne polluent /usr et pas besoin de se sortir les doigts pour avoir le beurre et la crémière!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 5.
Y a des avantages :
- ça marche sans être root
- ça permet d'avoir ( pour les gems en tout cas) plus d'une version de ton paquet.
- ça marche sur windows et mac
Oui, c'est moins bien qu'un système de paquet pour le déploiement par un sysadmin, mais c'est pas non plus inutile.
[^] # Re: je suis perplexe
Posté par Antoine . Évalué à 2.
On peut combiner les deux, par exemple certains créent un virtualenv (*) qu'ils peuplent en utilisant pip / easy_install, puis font un paquet Debian du virtualenv (*) tout entier afin de le déployer aisément et de manière fiable.
(*) « virtualenv is a tool to create isolated Python environments. […] It creates an environment that has its own installation directories, that doesn’t share libraries with other virtualenv environments (and optionally doesn’t access the globally installed libraries either). »—http://www.virtualenv.org/en/latest/
[^] # Re: je suis perplexe
Posté par Misc (site web personnel) . Évalué à 2.
Un virtual env, ça change peu vis à vis de la problématique de l'industrialisation. Le sysadmin moyen veut avoir des choses uniformes ( car ça permet d'avoir moins de travail, car moins d'exception, etc ), et pour ça, ça implique d'avoir par exemple le même code partout ( cad le même apache dans la même version, etc ). Utiliser un paquet .deb d'un virtualenv, ça résout le souci qu'à moitié, ie, ça résout le souci de la gestion unifié du déploiement, mais il te reste les problématiques d'avoir lle mêm module partout pour des questions de patchs, de comportement, etc.
Les admins sont pas contre juste pour faire chier les développeurs, vu qu'un admin va chercher à faire le moins de boulot possible, et le boulot de faire chier les devs, c'est déjà fait par le firewall :p
[^] # Re: je suis perplexe
Posté par Antoine . Évalué à 3.
Parce qu'ils fonctionnent (tm) ?
Et surtout, parce qu'ils fournissent toutes les bibliothèques désirées par le développeur, dans les versions qu'on veut, ce qui selon les besoins est loin d'être le cas des dépôts Debian & co.
Il me semble que par défaut c'est /usr/local (pour pip et easy_install). On peut aussi installer sans droits root, dans le $HOME de l'utilisateur courant.
Par ailleurs ce ne sont pas des robots, ils sont invoqués à la main et ne "polluent" pas ton système sans que tu lui demandes.
[^] # Re: je suis perplexe
Posté par saltimbanque (site web personnel) . Évalué à 1.
Tiens ça m'étonne y'a pas de feedback dans RubyGem, on voit simplement le nombre de downloads? est-ce qu'il y un outils de rapport de bug quelque part ou chaque gem se débrouille? bon bref ma question est y'a t'il une modératon sous une forme ou l'autre ou est-ce l'anarchie que ça laisse supposer?
[^] # Re: je suis perplexe
Posté par barret benoit . Évalué à 1.
Ha, Linspire étant trop en avance sur son temps avec son CNR, qui la plupart du temps était un CNB…
Click'N Run
Androïd est une sorte de distribution linux !
On me chuchote à l'oreille que dans la volonté d'unifier, en fait ce seraient des personnes qui par mégalomanie, ont la flemme de faire une distribution qui veut s'imposer comme standard, mais veulent imposer une unification ?
Arg…
Effectivement il y a eu des tentatives, je pense que la "force" des logiciels libres est de pouvoir s'adapter facilement.
L'intégration dans les distributions se passe bien si les devs prennent le temps de bien faire leur taf : fournir les prérequis et les tester : "installez telles versions de telles librairies et compilez". Des projets fournissent même des scripts d'install qui s'adaptent à la distribution
C'est une bonne idée que de vouloir unifier l'installation,
C'est une bonne idée d'utiliser des gestionnaires de paquets, qui "ne" sont "qu\'" au nombre de 5 après tout.
Quand bien même une communauté s'entendrait pour "poser" un standard de paquet universel, qu'en sera-t-il une fois Tizen, Sailfish OS, OpenWebOs, Firefox OS sur le marché ?
[^] # Re: je suis perplexe
Posté par saltimbanque (site web personnel) . Évalué à 2.
Pensons aux extensions firefox. On va sur le site, on fouille, on prend les extensions les mieux notées, on sait qu'on ne va pas être gavé par des verrues tout partout (adblock n'installe pas une barre d'outil malware.fr…).
Les extensions sont disponibles vites, sans travail de packaging (mais si les distrib le veulent, elles peuvent). Pour peu que l'extension se mette à jour en auto, on a le beurre et l'argent du beurre. En tout le cas tant que l'on reste dans le domaine du libre rien n'est impossible.
# punaise de délai
Posté par barret benoit . Évalué à 2. Dernière modification le 27 mai 2013 à 11:01.
dans un élan de passion, j'ai pas pu éditer pour mieux structurer mon commentaire à temps, si un admin peut supprimer mon précédent svp si c'est possible ?…
_ merci à l'auteur de l'article qui m'a réveillé :)_
Le voici en version finale :
Chapitre Tentatives (de faire du commerlibre) passées
Ha, Linspire étant trop en avance sur son temps avec son CNR, qui la plupart du temps était un CNB…
Click'N Run
Androïd est une sorte de distribution linux ! et on y retrouve du crapware, du payant,
de plus il s'installe de mieux en mieux sur des PC…
Créer un besoin qui n'existe pas ?
On me chuchote à l'oreille que dans la volonté d'unifier, en fait ce seraient des personnes qui par mégalomanie, ont la flemme de faire une distribution qui veut s'imposer comme standard, mais veulent imposer une unification ?
Arg…
Unifier pour combler des manques en amont ?
L'intégration dans les distributions se passe bien si les devs prennent le temps de bien faire leur taf : fournir les prérequis et les tester : "installez telles versions de telles librairies et compilez". Des projets fournissent même des scripts d'install qui s'adaptent à la distribution
Une solution simple peu utilisée, car pas créé par le prêcheur unificateur tueur de diversité ?
Et checkinstall ? hein ? c'est fait pour quoi/qui à la base ? pour les informaticiens dans le coma ?
howto linuxjournal
La diversité = une force
Je pense que la "force" des logiciels libres est de pouvoir s'adapter facilement.
Des groupes de personnes prennent le temps de porter certaines applis sur différents O.S. et différentes distribution
- quand ils sont investis dans leur rôle de développeur distributeur
- pour promouvoir le projet qui apporte une réelle plus-value dans la myriade de logiciels proposés.
Solution diverses actuelles : pas si compliquées
C'est une bonne idée que de vouloir unifier l'installation,
C'est une bonne idée d'utiliser des gestionnaires de paquets, qui "ne" sont "qu\'" au nombre de 5 après tout.
Unifier les debs, rpms, pkg, ebuild, et après ?
Quand bien même une communauté s'entendrait pour "poser" un standard de paquet universel, qu'en sera-t-il une fois Tizen, Sailfish OS, OpenWebOs, Firefox OS sur le marché ?
L'enfer est pavé de bonnes intentions
S'il y a des vieux "cons" comme nous qui disent : "c'est inutile c'est pas nouveau",
c'est parce qu'on en a vu passé des inventeurs révolutionnaires visionnaires, qui balancent leurs théories, et en fait qui veulent juste "prendre le dessus et monter en haut de la pyramide", sous prétextes de "tuer les méchants, apporter le bonheur et le sourire",
sans vouloir rien abandonner de ce qu'ils ont, ni faire des coupes franches dans leurs besoins et ressources,
mais au contraire pour avoir "plus"…
[^] # Re: punaise de délai
Posté par Misc (site web personnel) . Évalué à 2.
Unifier le format binaire, c'est bien joli, mais ça ne suffit pas.
Au delà du binaire, il y a aussi le contenu, et soit tu prends une intégration forte via une centralisation ou via des règles à suivre de façon drastique, et tu t'arranges pour que tout le monde suive les régles ( sachant que plus tu as de régle, plus c'est chiant, plus les gens vont vouloir aller voir ailleurs, ce qui aboutit à la multiplication des dépôts ), soit tu décentralises ( ce que fait windows ), mais tu oublies l'idée d'avoir des règles et une intégration aussi poussé et rapide. L'exemple typique , c'est le menu démarrer des anciens Windows, avec 1 répertoire par marque.
[^] # Re: punaise de délai
Posté par saltimbanque (site web personnel) . Évalué à 1.
on ne parle pas forcément d'UN système unifié. Plusieurs outils peuvent contribuer à une amélioration.
Ce qui m'a plus dans OSTree c'est justement qu'il fait le choix de ne répondre qu'à une petite partie du problème, pour essayer d'y répondre correctement. Par exemple il serait absurde de vouloir monter un serveur avec, pour ça on utilise Debian RHEL etc…
[^] # Re: punaise de délai
Posté par barret benoit . Évalué à 0.
D'accord,
je me suis fait avoir par le titre et n'ai pas vu que tu focalisais sur OSTree.
Merci, ça m'a fait (re)découvrir 0install, checkinstall et ce "nouvel" outil.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.