Discussion :

[RyzenOC]

Moi je trouve sa cool, on pourra enfin transporter nos soft sur clé USB, et pourquoi pas les installer ou l'en veut et pas la ou Linux veut.

Moi je suis pas fan l’arborescence imposé, j'aime bien séparer mes programmes dans plusieurs endroits, pareil pour mes fichiers.
Le mieu c'est de rien imposé, et de laissé le choix a l'utilisateur.

Et enfin avec ces snaps, on pourrais imaginer pour la première fois avoir des applications linux universelles, qui fonctionne sur n'importe quels distributions avec n'importe quels architectures, puisque les dépendances serons intégrer a l'apps, et pourrons d’après ce que j'ai compris être compilé sous n'importe quels architectures.

[Squisqui]

Moi je trouve sa cool, on pourra enfin transporter nos soft sur clé USB, et pourquoi pas les installer ou l'en veut et pas la ou Linux veut.

Tu as toujours pu exécuter des binaires à l'emplacement de ton choix. Tu as toujours pu lister les dépendances nécessaires pour les rassembler sur une clé usb. Tu n'as même pas besoin de devenir root. Tu ne l'as juste jamais fait.

Moi je suis pas fan l’arborescence imposé, j'aime bien séparer mes programmes dans plusieurs endroits, pareil pour mes fichiers.

Qu'est-ce que ça peut faire d'avoir telle ou telle arborescence de fichier. C'est le gestionnaire de paquet qui entretien un système cohérent pour toi. Mais tu peux toujours construire et entretenir un dépôt qui contiendront des paquets qui indiquerons à ton gestionnaire de paquets où les copier sur ton système.

Le mieu c'est de rien imposé, et de laissé le choix a l'utilisateur.

Windows est un bel exemple. Chaque éditeur (logiciel libre ou pas) se fait plaisir et on se retrouve avec une décharge.
Un installateur peut copier des fichiers dans C:\, C:\WINDOWS, C:\WINDOWS\System32, C:\Program Files, C:\Program Files (x86) lorsque le chemin est écrit en dur ou dans %ProgramFiles%, %ProgramFiles(x86), %Windir%, %HOMEDRIVE%, %HOMEPATH%, %SystemDrive%, %SystemRoot%, %LOCALAPPDATA% lorsque les variables d'environnement sont utilisées. Le pire est que parfois le chemin est imposé, la solution serait de désarchiver l'installateur et de tout faire à la main.
Et dans ce monde joyeux sans aucune règle, un installateur ne se gênera pas pour écraser une bibliothèque copié dans %SystemRoot% et péter l'exécution d'un autre logiciel. Je crois que c'est justement ce que tu veux éviter en voulant tout séparer.
Je ne parle même pas des fichiers de configuration où les 3/4 des éditeurs (logiciels libres ou pas) snobent %ProgramData% et %APPDATA% sans pouvoir rien y faire.

Et enfin avec ces snaps, on pourrais imaginer pour la première fois avoir des applications linux universelles, qui fonctionne sur n'importe quels distributions avec n'importe quels architectures, puisque les dépendances serons intégrer a l'apps, et pourrons d’après ce que j'ai compris être compilé sous n'importe quels architectures.

Ça risque d'être compliqué. Snappy ne fonctionne que sous Ubuntu pour le moment.
Si tu veux de l'universel, tu peux te tourner vers pkgsrc du projet NetBSD (le contorsionniste). Même Windows est supporté.

[Chuck_Norris]

Il a toujours été possible de compiler ses programmes en mode statique, donc en incluant les bibliothèques dans l'exécutable même. Cela le grossit fortement, mais cela donne une grande pérennité à l'exécutable produit, autant que sous Windows. Il existe donc des solutions pour faire des programmes portables et compatible avec de nombreuses distributions déjà depuis la nuit des temps. L'avantage aussi c'est que sous Linux un exécutable une fois chargé ne laisse pas de verrou sur le fichier exécutable contrairement à Windows. On peut donc en théorie lancer un programme depuis une clé USB et retirer cette dernière sans nuire au programme en cours.

[Ah_Kin]

C'est sympa, depuis cette mise à jour, j'ai plus le message "time and date not set" mais un truc comme dev/sda1 clean