meme avec autopackage, quel interet de supporter le libre avec ses 50 systemes de paquets different qui va te couter 50 equipes de packaging en plus pour augmenter ton marche de 0.3%.
pour les parts de marché, on verra comment cela va évoluer, mais à mon avis cela représente plus que 0.3 % d'augmentation. Pour le bureau, c'est encore un peu différent, mais là aussi cela va évoluer rapidement (oui je sais cela fait 10 ans que l'on dit cela...)
Il n'y a pas tant de systèmes de paquets que cela, 3 principaux, et encore on peut facilement installer une version à partir d'un paquet différent (sous opensuse j'ai déjà pu installer des rpm issus de fedora ou des deb, sous debian j'ai pu installer des rpm mandriva etc ok c'est pas très propre mais cela fonctionne), comme quoi il n'y a pas tant de différence que cela entre les distributions. À mon avis en respectant un peu plus les LSB on devrait arriver à qque chose de bien. Quand à réaliser un paquet autopackage (ou zero install etc), je ne pense pas que cela fasse un trop gros trou dans le budget des oracle et compagnie. Avec bcp moins de moyen planeshift arrive à nous sortir de très bon autopackage qui fonctionnent sur toutes les distributions à ma connaissance.
.
de vouloir comparer l'installeur Mac avec son OSX unique et sa 10aine de modele d'ordinateurs supportes avec la diversite des distributions linux et des architectures,
Il y a quand même 2 architectures différentes, ppc et intel, et les développeurs arrivent bien à faire un paquet unique. OK, cela augmente la taille des paquets, mais cela fonctionne bien (si on fait abstraction tout de même de la frénésie d'Apple à "oublier" les anciennes version de son système dans la conception des nouvelles API). Le fait que les machines apple sont limitées en modèle est un faux pb, un logiciel qui tourne sur un "vrai" mac tournera sans doute pareil sur un pc normal bidouillé pour avoir mac os x.
Je pense que si on sort un paquet pour gcompris (je prends cet exemple car je sais que l'auteur est sensible à cette question des paquets), si cela sort pour PPC, i386 et x64, cela me semble bien suffisant, tant pis pour les "pauvres" admin de S/390 ou Sparc qui ne pourront pas faire jouer le petit dernier à gcompris sur le Mainframe de la société...
J'ai lu entièrement la seconde partie du texte de Murdock, mais il n'y a pas vraiment de proposition concrète ; "yakafokon fasse une API pour que les ISV puissent packager leurs applis.". L'idée est louable, mais cela reste encore bien vague...
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: Today it sucks, tomorrow it won't
Posté par B16F4RV4RD1N . En réponse au journal Problèmes d'installation des logiciels : paquets sources ?. Évalué à 1.
pour les parts de marché, on verra comment cela va évoluer, mais à mon avis cela représente plus que 0.3 % d'augmentation. Pour le bureau, c'est encore un peu différent, mais là aussi cela va évoluer rapidement (oui je sais cela fait 10 ans que l'on dit cela...)
Il n'y a pas tant de systèmes de paquets que cela, 3 principaux, et encore on peut facilement installer une version à partir d'un paquet différent (sous opensuse j'ai déjà pu installer des rpm issus de fedora ou des deb, sous debian j'ai pu installer des rpm mandriva etc ok c'est pas très propre mais cela fonctionne), comme quoi il n'y a pas tant de différence que cela entre les distributions. À mon avis en respectant un peu plus les LSB on devrait arriver à qque chose de bien. Quand à réaliser un paquet autopackage (ou zero install etc), je ne pense pas que cela fasse un trop gros trou dans le budget des oracle et compagnie. Avec bcp moins de moyen planeshift arrive à nous sortir de très bon autopackage qui fonctionnent sur toutes les distributions à ma connaissance.
.
Il y a quand même 2 architectures différentes, ppc et intel, et les développeurs arrivent bien à faire un paquet unique. OK, cela augmente la taille des paquets, mais cela fonctionne bien (si on fait abstraction tout de même de la frénésie d'Apple à "oublier" les anciennes version de son système dans la conception des nouvelles API). Le fait que les machines apple sont limitées en modèle est un faux pb, un logiciel qui tourne sur un "vrai" mac tournera sans doute pareil sur un pc normal bidouillé pour avoir mac os x.
Je pense que si on sort un paquet pour gcompris (je prends cet exemple car je sais que l'auteur est sensible à cette question des paquets), si cela sort pour PPC, i386 et x64, cela me semble bien suffisant, tant pis pour les "pauvres" admin de S/390 ou Sparc qui ne pourront pas faire jouer le petit dernier à gcompris sur le Mainframe de la société...
J'ai lu entièrement la seconde partie du texte de Murdock, mais il n'y a pas vraiment de proposition concrète ; "yakafokon fasse une API pour que les ISV puissent packager leurs applis.". L'idée est louable, mais cela reste encore bien vague...
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