Des .app comme MacOS X?

SleepingTux · Le 26/10/2006, à 14:59

Bonjour à tous,
Depuis pas mal de temps, je trouve que GNU/Linux a un énorme problème: l'utilisation d'applications non packagées pour la distribution. En général, le premier type qui s'y connaît un peu s'y retrouve, mais le débutant, non.
En général, il y a deux possibilités de distribution d'applications:
- Le code source: L'avantage est que la portabilité est maximale, cependant il faut les outils de développement et être un minimum patient (cependant, le problème n'existe pas quand l'application est codé dans un langage interprété où tout est déjà installé). Un débutant n'a aucune chance de s'en sortir sans beaucoup d'aide et d'apprentissage. ("tu fais ./configure && make && sudo make install", certes, mais quand configure foire et qu'il faut aller chercher les paquets de développements de la librairie x et z, c'est mort)
- Des binaires précompilés: Pas de portabilité, au mieux c'est compilé en static et ça passe sur toutes les distributions linux de l'architecture de base, au pire, ça se limite à une distribution. Ensuite, l'utilisateur se retrouvera, après décompression, avec un dossier, avec un fichier sans extension avec une icône un peu bizarre, ça peut aller mais c'est pas terrible... Surtout s'il y a plusieurs exécutables (exemple avec Nexuiz: nexuiz-linux-686-glx, nexuiz-linux-686-sdl, nexuiz-linux-glx.sh... Comment trouver le bon?). L'avantage, c'est de ne pas avoir besoin de tous les outils de développement pour faire fonctionner une application, et c'est à peu près tout.

Il existe aujourd'hui deux systèmes pour gérer facilement ces binaires précompilés de manière indépendante à la distribution:
- Autopackage: Gère automatiquement les dépendances, mais demande une installation en administrateur obligatoirement.
- Klik: Après l'installation du gestionnaire, tout est géré automatiquement, pas besoin d'être administrateur, application totallement isolée du reste. Cependant, utilise une bidouille de fstab pour monter des images disques en loop, ce qui limite à 10 le nombre d'applications lancées simultanéments (à moins que je me trompe), ça fait pas très beau dans fstab et surtout on a vu plus propre.
- Zero Install: J'ai découvert ceci en me renseignant sur autopackage, le principe semble pas mal, demande une confirmation avant de lancer, vérifie les clefs GPG, fonctionne en utilisateur simple, gère les dépendances, bref un nombre incalculable d'avantages. Cependant, il reste assez dur de gérer l'application comme un simple fichier.

La solution, Apple l'a trouvé, c'est d'utiliser des dossiers avec une extension .app pour contenir l'application. C'est simple et efficace.
Il serait possible de faire de même sous GNU/Linux, cependant, un dossier n'est pas très maniable hors du système local: impossible de télécharger depuis un serveur HTTP, association de .app avec le lançeur dans les gestionnaires de fichiers assez difficile à mettre en œuvre, envoyer un .app par mail devient assez dûr... Klik a trouvé la solution: utiliser une image disque, mais c'est pas très propre dans fstab et plutôt limité. Peut-être que fuse permettrait d'avoir une alternative correcte, cela permettrait d'avoir des .app en images disques, mais dans ce cas, de deux choses l'une:
- Ou on reste en lecture seule (sinon il faut anticiper sur la consommation en espace disque de l'application), ce qui est faisable vu que les paramètres ne sont pas enregistrés dans le .app.
- Ou on utilise archivemount, qui peut monter une archive (on préférera le tar non compressé par soucis de performances, sachant que les grosses applications sont déjà compressées au niveau des données (par exemple Nexuiz, seul le binaire n'est pas compressé, le reste est dans une grosse archive zip), et ainsi laisse la liberté de changer la taille. Cependant, ce n'est pas encore au point, pas terrible conceptuellement et dispose encore de performances relativement faibles.

Ensuite, dans le .app, tout serait libre, il faudrait seulement un fichier Program.xml qui contiendrait:
- Le nom de l'application, évidemment
- Une description dans plusieurs langues (le lanceur se base sur la locale du système et choisit la meilleure)
- Le site web de l'application
- Le chemin de l'icône dans le .app (ou alors on nomme l'icône icon.png dans le .app ce qui retire un peu de liberté dans la conception de l'arborescence)
- Les chemins des binaires dans le .app, avec architecture (x86, ppc...) et distribution (ubuntu, mandriva, static>)
- Les URLs d'autre binaires pour d'autres architectures, qu'il ne vaut mieux pas intégrer dans le .app faute de place (histoire d'éviter d'avoir deux cents binaires par fichiers), téléchargés dans le .app si nécessaire, qui sera par conséquent adapté à la machine (ce qui empêche la lecture seule). Mais mieux vaut garder aussi les autres binaires si l'utilisateur souhaite envoyer le programme à un ami par mail par exemple
- Les dépendances (en tant que fichier, ou alors en tant qu'une sorte de "standard de paquets", et alors le lanceur devra ou se connecter à un serveur pour connaître l'équivalent du paquetage pour sa distribution, ou chercher dans des listes en local mises à jour sur demande, décentralisé mais moins propre). Dans ce cas, on perd la possibilité de lancer en utilisateur simple. (ou alors on lance le binaire statique si présent)

Au niveau de l'intégration, ça serait presque parfait car l'application est un fichier. On peut le glisser-déposer un peu partout en conservant quelque chose d'utilisable, afficher l'icône de l'application par un créateur d'aperçu gnome (très aisé à faire avec un script shell et imagemagick: trois arguments à gérer: la taille, le fichier d'entrée et le fichier de sortie, une image png de la taille demandée). Le système serait très simple à comprendre et à gérer, tout est dans la machine, l'utilisateur se sent propriétaire de l'application et a le pouvoir dessus, tandis qu'avec un paquet, des fichiers s'éparpillent dans tous les sens, c'est bien géré mais ça peut faire peur aux débutants qui s'en rendent compte.

Il serait aussi possible de rajouter une option pour lancer l'application en tant qu'utilisateur invité voir si ce n'est pas dangereux: ce serait un utilisateur non autorisé à se connecter, sudo s'en chargeant, et commun à tous (ce n'est qu'un test).

Tout ceci serait géré par un lançeur, qui monterait automatiquement le .app, demanderait confirmation à l'utilisateur avant de lancer l'application, affichant sa description en français, demandant s'il souhaite ne plus avoir cette fenêtre pour les prochaines fois, vérifiant que tout va bien avant le lancement en choisissant automatiquement le bon binaire. Le gros problème, c'est que ça risque de vite devenir lourd pour un lanceur, et attendre trentes secondes pour lancer une application, c'est pas terrible...

En gros, ça serait une sorte de klik un peu plus avancé. Qu'en pensez vous?

Dernière modification par SleepingTux (Le 26/10/2006, à 14:59)

Le Psykopat · Le 26/10/2006, à 16:41

Je pense effectivement que le systeme d'application devrai etre revu.

Pour moi une application devrai contenir ( dans son paquet ) tout ce qui est nécéssaire pour l'utiliser.
J'ai un mac et c'est vrai que leur systeme est quasi parfait. Windows y arrive plus ou moins, Mac y arrive aisément, alors pourquoi Linux ne sy met pas?
Je sais que lorsque l'on sait quelque choses on le trouve simple ( pour les compilations des sources ou makefiles ) Moi perso quand je tombe la dessus je lache l'affaire , des fois ça marche des fois ça foire.

C'est bien de filer les sources mais si c'était vraiment le meillleur systemes tous le monde l'aurait fait. A force d'etre soit disant libre on est libre de faire des conneries aussi. Fixer des standar pour Linux n'est pas quelque chose anti-libre , un standart n'est pas quelque chose de restreint c'est juste une manière de faire en sorte que tous le monde s'entendent.

L'asci est un standart, l'exadecimal aussi , et ça na pas fait de mal.

Si je my connaissai un peu en appli Linux je my serai mis mais.....c'est pas le cas pour l'instant

aleph · Le 26/10/2006, à 16:59

> SleepingTux

Une partie du problème :

http://forum.ubuntu-fr.org/viewtopic.php?pid=532824#p532824

et

http://forum.ubuntu-fr.org/viewtopic.php?id=68827

compte supprimé · Le 26/10/2006, à 17:01

Le Psykopat a écrit :

Pour moi une application devrai contenir ( dans son paquet ) tout ce qui est nécéssaire pour l'utiliser

Dans ce cas, oublie Debian et passe à PC-BSD. Le principe même d'un système à la apt c'est de se débarasser de ces énormes fichiers d'applications contenant je ne sais combien de libraries redondantes.

Enjoy Aspirin · Le 26/10/2006, à 17:25

Si j'ai bien compris le répertoire .app contient toutes les librairies nécessaire au fonctionnement du programme.
Sous linux la philosophie est de mettre au maximum les librairies en commun. De ce fait l'installation d'un programme n'est pas localisée dans un seul répertoire mais est éclatée dans l'arborescence du système.

Il est bien sûr possible de rassembler toutes les dépendances d'un programme dans un répertoire unique comme sur windows et dans une moindre mesure comme sur macosx. Par contre le système va devenir très volumineux...

SleepingTux · Le 26/10/2006, à 17:45

Je ne pensais pas à ça du tout, les .app contiendraient en fait des binaires liés à des distributions et l'URL de binaires non inclus pour réduire la taille de l'archive. En fait, ce principe de multiples binaires ne s'applique que pour les jeux où cette partie ne représente que 1% du poids total de l'application, et où l'on peut facilement rajouter de façon neutre 4-5 fois le même binaire sous une forme différente.
Et si l'on veut quelque chose d'universel au pris d'une certaine lourdeur, on peut inclure, sous forme d'URL si l'on veut, un binaire statique qui contient tout le nécessaire (comme le font la plupart des logiciels propriétaires).

jpaul · Le 26/10/2006, à 18:53

Un truc du genre: je lance le .app et un message: "Le logiciel requiert l'installation des librairies suivantes: Cliquez sur Installer pour les installer."

SleepingTux · Le 26/10/2006, à 19:41

C'est ce que fait klik, et plutôt bien. En fait ce que je pensais c'était plus une extension de klik qu'autre chose, les deux principes étant quasiment les mêmes.
Cependant, pour garantir le fonctionnement peut importe la distribution, faudrait une base d'équivalance de paquetages unique, par exemple "libsdl1.2" pour ubuntu correspond à "libSDL-1.2" pour mandriva et ainsi de suite pour les librairies les plus courantes. Mais ça devient désastreux, et même avec toutes les librairies, il peut y avoir des problèmes de compatibilité, et seule la compilation en static peut éviter tout ça, mais alors ça devient tellement lourd que ça devient vite chiant.

Ce système n'est pas là pour tuer les systèmes de paquetages, mais juste pour offrir un moyen unifié de distribuer des applications en binaire pour toutes les distributions, les paquets sources n'étant pas à la portée du premier débutant venu.

amadeus · Le 26/10/2006, à 20:01

Il serait pas plus simple de prendre un système qui facilitent la compilation, comme les *BSD ou Gentoo? Le fichier de config contient les dépendance, et hop l'application est compilé sans avoir à faire quoique ce soit.

Hebus95 · Le 26/10/2006, à 20:04

amadeus a écrit :

Le fichier de config contient les dépendance

Je ne connais ni BSD ni Gentoo, que veux-tu dire par là ?

SleepingTux · Le 26/10/2006, à 20:45

Avec Gentoo, tu as un petit fichier texte, un ebuild, qui dit où télécharger le paquet source, comment le compiler, et de quels paquets il dépend. Un coup de emerge, et tout est installé, de manière adaptée à ton système et à tes besoins.
C'est la méthode idéale; mais cependant, je doute que si quelqu'un souhaite installer openoffice sur son sparc il souhaite passer deux jours à recompiler...

amadeus · Le 26/10/2006, à 21:15

C'est vrai que ma phrase ne voulait pas dire grand chose. Du point de vue de l'utilisateur final, les dépendances sont gérées comme avec apt, sauf qu'au lieu d'installer les paquets, ils sont compilés puis installés.
En plus, avec les nouveaux processeurs, la compilation ne prend plus tellement de temps (on compile le kernel en moins de 5 minutes). Et les vieux pc ont tout intérêt à compiler pour avoir des performances honorables.

SleepingTux · Le 26/10/2006, à 22:05

En effet, le jour où tous les PC seront assez puissant, Gentoo, ou du moins, les ebuilds, auront enfin leurs vrais capacités ouvertes au grand jour.
L'universabilité dans toute sa puissance, si ce n'est pas déjà fait: l'installation en utilisateur dans un répertoire déjà prêt et la stabilité. La perfection.

Par contre, les logiciels proprios, même s'il est possible de les mettre en static pour différentes plate-formes, vont en chier s'ils essayent de faire des binaires partagés devant la grande diversité de systèmes existants créée grâce à gentoo.

GutsdBlack · Le 26/10/2006, à 22:09

Heu je trouve dommage de trouver des sujets comme ça... Je crois que beaucoup devrais essayer de comprendre un peu le pourquoi du comment... Parce que là c'est une des bases de Linux que l'on remet en question... GNU/Linux n'est ni MacOS X, ni Windows donc merci de respecter un peu ce qu'il est...

GutsdBlack · Le 26/10/2006, à 22:10

SleepingTux a écrit :

En effet, le jour où tous les PC seront assez puissant, Gentoo, ou du moins, les ebuilds, auront enfin leurs vrais capacités ouvertes au grand jour.

Ha oui et +10 la dessus... le jour où un emerge X.org prendras le temps d'un encodage mp3s, ça seras super génial d'avoir le meilleur des mondes

Crashforburn · Le 26/10/2006, à 22:17

Il ne faut pas oublier que le paquetage gentoo est inspiré de BSD...Et que sur BSD, on peut installer directement les binaires si on le souhaite

Enjoy Aspirin · Le 26/10/2006, à 22:36

GutsdBlack a écrit :

le jour où un emerge X.org prendras le temps d'un encodage mp3s, ça seras super génial d'avoir le meilleur des mondes

emerge brave-new-world-sources

Le Psykopat · Le 26/10/2006, à 23:00

GutsdBlack a écrit :

Heu je trouve dommage de trouver des sujets comme ça... Je crois que beaucoup devrais essayer de comprendre un peu le pourquoi du comment... Parce que là c'est une des bases de Linux que l'on remet en question... GNU/Linux n'est ni MacOS X, ni Windows donc merci de respecter un peu ce qu'il est...

Si un meilleur systeme est trouvé faut pas etre contre l'évolution. Du moment que ça contraint pas la phylosophie de linux je vois pas en quoi sa gene.

On respecte ce qui est les mecs donc on stop tout on arrete la, plus de mise a jours c'est tres bien comme c'est et on n'en bougera pas

kaworu · Le 26/10/2006, à 23:28

C'est la méthode idéale; mais cependant, je doute que si quelqu'un souhaite installer openoffice sur son sparc il souhaite passer deux jours à recompiler...

heu, disont que si t'utilise l'archi SPARC sous Gentoo, compiler OOo c'est un détail. T'as des binaires pour x86 et PPC.

En effet, le jour où tous les PC seront assez puissant, Gentoo, ou du moins, les ebuilds, auront enfin leurs vrais capacités ouvertes au grand jour.

a mon avis, de toute façon les programmes deviennent plus lourd au fur et à mesure que la puissance des PC évolue. La réputation de a souplesse des ebuilds/portage n'est plus à faire

SleepingTux · Le 26/10/2006, à 23:33

Je cherchais juste un exemple d'architecture un peu atypique. On a beau répéter "Regarde, ça tourne partout !", c'est pas avec 90% des paquets pour x86 qu'on ira bien loin; portage est la solution car tout en restant simple, par la recompilation on aura toujours un programme parfaitement adapté au système.

J'avais pris cet exemple pour montrer que dès qu'on sort du x86/ppc, il va falloir devenir très patient pour une installation, et de plus en binaire on perd toute la souplesse offerte par gentoo.

GutsdBlack · Le 26/10/2006, à 23:40

Le Psykopat a écrit :

Si un meilleur systeme est trouvé faut pas etre contre l'évolution. Du moment que ça contraint pas la phylosophie de linux je vois pas en quoi sa gene.

Bah justement c'est à l'opposé de la philosophie de Linux ....

Le Psykopat a écrit :

On respecte ce qui est les mecs donc on stop tout on arrete la, plus de mise a jours c'est tres bien comme c'est et on n'en bougera pas

Bouger ne veux pas dire rejoindre ce que tout le monde fait... c'est pas parce qu'un Os comme Windows qui représente 80% du marché le fait qu'il faut faire pareil... Ok pour l'innovation mais pas pour suivre bêtement...

Le fait que beaucoup d'entre vous est envie d'avoir des paquets statiques (contre quoi bcp de linuxien se battent) montrent que vous ne comprenez rien à cette philosophie...

Le Psykopat · Le 27/10/2006, à 00:01

L'évolution c'est pas la phylosophie de linux? Merde je doit me dépecher de désinstaller synaptic.

Bouger ne veux pas dire rejoindre ce que tout le monde fait... c'est pas parce qu'un Os comme Windows qui représente 80% du marché le fait qu'il faut faire pareil... Ok pour l'innovation mais pas pour suivre bêtement...

Voiiiiiiiiiiiiiiiiiiiila on y est, ça y est des qu'on veut changer c'est qu'on veut etre comme Windows???
Arrétez vos complexe avec cet OS, toujours entraint de le citer pour se défendre. Foutez lui la paix si il es si mauvais que ça.

Qui parle de suivre? Je parle d'ouvrir la marche.
A l'époque yavait que des codes sources, aujourd'hui ya des paquets .deb .rpm et autre. Ne nous fait pas dire qu'on veut totalement changer, on veut juste améliorer.

GutsdBlack · Le 27/10/2006, à 00:24

Le Psykopat a écrit :

L'évolution c'est pas la phylosophie de linux? Merde je doit me dépecher de désinstaller synaptic.

Tu ne comprend décidément rien... où alors t'es borné...

Le Psykopat a écrit :

Foutez lui la paix si il es si mauvais que ça.

Ha bon ? merde.... on m'aurait menti alors ?

Le Psykopat a écrit :

A l'époque yavait que des codes sources, aujourd'hui ya des paquets .deb .rpm et autre.

C'est un blague j'espère ? parce que sinon tu devrais un peu vérifier ce que tu penses savoir...

Le Psykopat · Le 27/10/2006, à 00:57

Quand je dit QUE des sources je veut dire par la que yen avait beaucoup, et que maintenant on a plus le choix entre paquets et sources. ( c'est meme pour ça que j'avai abandonné à l'époque )

Evidement, mes mots m'on dépassé il ny avai pas UNIQUEMENT QUE ça.

lastsseldon · Le 27/10/2006, à 06:12

.. GNUstep ?

(sinon, lisez un papier sur le fhs linux.)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/10/2006, à 14:59

Des .app comme MacOS X?

#2 Le 26/10/2006, à 16:41

Re : Des .app comme MacOS X?

#3 Le 26/10/2006, à 16:59

Re : Des .app comme MacOS X?

#4 Le 26/10/2006, à 17:01

Re : Des .app comme MacOS X?

#5 Le 26/10/2006, à 17:25

Re : Des .app comme MacOS X?

#6 Le 26/10/2006, à 17:45

Re : Des .app comme MacOS X?

#7 Le 26/10/2006, à 18:53

Re : Des .app comme MacOS X?

#8 Le 26/10/2006, à 19:41

Re : Des .app comme MacOS X?

#9 Le 26/10/2006, à 20:01

Re : Des .app comme MacOS X?

#10 Le 26/10/2006, à 20:04

Re : Des .app comme MacOS X?

#11 Le 26/10/2006, à 20:45

Re : Des .app comme MacOS X?

#12 Le 26/10/2006, à 21:15

Re : Des .app comme MacOS X?

#13 Le 26/10/2006, à 22:05

Re : Des .app comme MacOS X?

#14 Le 26/10/2006, à 22:09

Re : Des .app comme MacOS X?

#15 Le 26/10/2006, à 22:10

Re : Des .app comme MacOS X?

#16 Le 26/10/2006, à 22:17

Re : Des .app comme MacOS X?

#17 Le 26/10/2006, à 22:36

Re : Des .app comme MacOS X?

#18 Le 26/10/2006, à 23:00

Re : Des .app comme MacOS X?

#19 Le 26/10/2006, à 23:28

Re : Des .app comme MacOS X?

#20 Le 26/10/2006, à 23:33

Re : Des .app comme MacOS X?

#21 Le 26/10/2006, à 23:40

Re : Des .app comme MacOS X?

#22 Le 27/10/2006, à 00:01

Re : Des .app comme MacOS X?

#23 Le 27/10/2006, à 00:24

Re : Des .app comme MacOS X?

#24 Le 27/10/2006, à 00:57

Re : Des .app comme MacOS X?

#25 Le 27/10/2006, à 06:12

Re : Des .app comme MacOS X?

Pied de page des forums