Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 31/12/2019, à 01:38

moths-art

gestionnaire de paquet NIX

Bonjour,

J'ai découvert il y a peu le gestionnaire de paquet NIX.
Je le trouve un plein de points très supérieur à Flatpak, Snap ou autre AppImage.

J'aimerais en faire la promotion et commencer à rédirer un article wiki sur le sujet. Qu'en pensez-vous ?

Les gros + à mon sens que les 3 autres n'ont pas :

* approche fonctionnel : l'installation et maj ne peut pas casser d'autre paquet. Néanmoins, il n'utilise pas de sandbox et du coup, les logiciels installés sont plus réactifs, prennent moins de place.
Si le besoin s'en fait ressentir, il est possible de revenir à une version précédente : il y a un vrai système de rollback.
* grosse logithèque à jour (https://nixos.org/nixos/packages.html?channel=nixos-19.09 : rien à voir avec https://www.appimagehub.com/ https://snapcraft.io/store ou https://flathub.org/home)
Mon expérience est peut-être biaisé mais je trouve peu de chose sur flatpak et snap a beaucoup de paquet cassés.
* permet d'installer des paquets binaires (comme une Ubuntu) comme leur pendant source (comme une gentoo)
* orienté dev :
pour ceux qui ont déjà essayé de créer des paquets sous snap ou flatpak (pas essayé AppImage), on galère vraiment dès qu'on sort du cadre des exemples.
Là,

Dernière modification par moths-art (Le 31/12/2019, à 02:17)

Hors ligne

#2 Le 31/12/2019, à 02:00

moths-art

Re : gestionnaire de paquet NIX

J'ai créé une petit article sommaire : https://doc.ubuntu-fr.org/nix

Hors ligne

#3 Le 31/12/2019, à 11:25

GammaDraconis

Re : gestionnaire de paquet NIX

J'en ai entendu parlé et effectivement ça semble intéressant cependant il y a plusieurs problèmes concernant NIX dont 2 génants surtout pour une distribution grand public comme Ubuntu.

Mais avant ça, je tiens quand même à rappeler qu'actuellement sous Linux et surtout sous Ubuntu, il y a déjà une multitude de méthodes différentes pour installer un logiciel, on a que l'embarras du choix.

Petit rappel :

- Il y a déjà les dépots officiels qui contiennent un nombre important de paquet
- Il y a la multitude de PPA (très nombreux) qui permettent d'avoir des logiciels supplémentaires ou en version plus récente
- Il y a de nombreux sites d'éditeur qui fournissent le paquet deb (exemple Spotify ou Google Chrome), parfois le paquet deb ajoutera aussi leur dépot pour qu'il soit à jour automatiquement
- Il y a des les dépots externes que propose directement les éditeurs (par exemple Virtualbox pour avoir la dernière version systématiquement)
- Il y a les paquets universels avec la technologie de Canonical : les snaps
- Il y a les paquets universels concurrent avec Flatpak
- Il y a les applications portables avec le format AppImage (qui n'est pas exactement pareil que les snaps et flatpak)
- Il y a les applications fourni par un script bash à lancer
- On peux aussi installer les paquets/logiciels Python en passant par la commande "pip" (ex: pip3 install spyder)
- Certains paquets peuvent s'installer aussi avec le gestionnaire de paquet "npm" (npm install...) même si c'est des cas particuliers...
- En dernier recours on peux aussi compiler le logiciel à partir des sources pour ensuite l'installer

La méthode de paquet NIX n'est donc qu'une énième méthode supplémentaire.

Je l'ai testé et l'avantage par rapport à Snap c'est qu'il semble y avoir + de choix et pas de problème de lenteur au 1er démarrage contrairement à Snap.

Par contre j'ai relevé 2 gros défauts :
- Quand on installe un logiciel, il n'y a pas de raccourci crée dans le menu pour ce logiciel (même après un redémarrage), j'ai testé plusieurs logiciels différent et à chaque fois j'ai dû le lancer depuis le terminal, c'est problèmatique pour une distrib grand public si un novice doit lui même créer son raccourci.
- Le 2ème problème et ça c'est précisé dans la doc, ça gère mal les applications qui fonctionnent avec OpenGL, il faut faire des commandes particulières pour que ça marche, là non plus ça ne peux pas convenir à des novices.

Comme autre défaut, le répertoire /nix grossi très vite quand on ajoute des applis (beaucoup plus lourd que des applis installés via "apt install"), cependant, c'est la même chose avec les snaps et les flatpaks.
Ensuite dans les autres défauts moins génant : leur gestionnaire de paquet est actuellement trop lié à leur distribution "NixOS", il faudrai qu'il la généralise + comme Flatpak. Le fait d'ailleurs d'être obligé de taper une commande avec curl pour l'installer la 1ère fois prouve que ça ne vise pas le grand public, il faudrai que nix soit installable directement avec un simple "apt install nix" par exemple. Il faudrai même aller jusqu'à intégrer à Gnome Software (logithèque de gnome) la bibliothèque de NIX si on y ajoute un plugin (par exemple gnome-software-plugin-nix).

Bref c'est un outil intéressant pour les utilisateurs avancés mais il manque encore des choses pour que ça puisse être utilisé par des novices sur une distrib grand public comme Ubuntu.

Dernière modification par GammaDraconis (Le 31/12/2019, à 11:30)


Discussion sur mon script de post-install pour Ubuntu 20.04LTS : https://forum.ubuntu-fr.org/viewtopic.php?id=2026344
Lien direct script : https://github.com/simbd/Ubuntu_20.04LTS_PostInstall
Démo vidéo (peertube) : https://video.ploud.fr/videos/watch/fb7 … 0d252ed2db

Hors ligne

#4 Le 31/12/2019, à 15:41

moths-art

Re : gestionnaire de paquet NIX

GammaDraconis :

Merci tout d'abord pour ta contribution.
Ton rappel est effectivement important et je suis le premier à trouver qu'il existe beaucoup/trop de méthodes différentes pour installer un logiciel sous Linux.

Alors, dans ta liste, je pense qu'il faut supprimer tout ce qui est orienté dev.
Les trucs qui s'installe avec du bash ou via pip, npm etc c'est orienté dev. Tu peux ralonger la liste car y'a souvent un ou plusieurs gestionnaire de paquet par langage :
Cargo pour Rust, composer pour PHP, CPAN pour Perl, Gem pour Ruby etc.
En plus, avec des softs comme Docker, on peut aussi installer via des conteneurs.

Après, dans cette jungle de méthodes, il y a forcément des trucs qui vont disparaître et d'autres qui vont s'imposer : Le darwinisme a l'état pure.

Je dirais que ce qui va pousser un format par rapport à un autre c'est aussi le côté création et maintenance.
Si c'est très difficile de créer et maintenir un paquet dans un format, il risque d'y en avoir peu et que la sauce ne prenne pas.
Perso, je commence a avoir un peu de bouteille dans la création de paquet debian et d'entretien d'un PPA.
Ce qui en ressort c'est que c'est pas forcément simple (pour que ça marche sur plusieurs versions d'Ubuntu) surtout quand il y a beaucoup de dépendances.
Refaire le taf/test à chaque nouvelle version est héritant et peu valorisant.

Flatpak, Snap, AppImage et Nix ont cet avantage de ne pas tenir compte des libs de la distrib : du coup, une app sera compatible pour toutes les versions et ça c'est un gain incroyable de temps et de qualité. (l'utilisateur final se contre-fou qu'il a une mauvaise version qui est incompatible : si ça marce pas pour lui c'est de la m****)
L'inconvénient, c'est comme tu le dis, ça grossi vite.
Les 3 premiers s'appui sur une sandbox qui fait que chaque logiciel est isolé et à ses dépendances.
NIX fait un peu mieux en partageant des dépendances quand elles existent. Du coup, ça prend moins de place quand on installe plusieurs softs.
Dans tous les cas, ça sera toujours en doublon avec de l'apt donc à ne pas utiliser à tord et à travers.
Après, sans tirer à boulets rouges, ça relève encore d'avantage les soucis liés à des mauvais choix techniques ou des optims non présente dans le dev.
On revient au fondement de l'info qui dit que chaque octet à un coût. (et qu'on a tenté d'oublier ces derniers années)

J'ai tenté l'aventure de créer des paquet Snap et Flatpak mais dès que ça devenait un peu trop spécifique... gros tâtonnement.
bref, une cata. J'en suis dégoûté et je ne vais sans doute plus tenter l'opération dans les mois qui viennent.
Nix est bien mieux outillé (même si il force à apprendre un nième langage) et rien que pour ça, il a une longueur d'avance.

Alors, après enquête : depuis que Ubuntu est basé sur Debian Buster, soit la "Eoan Ermine", il est possible de rajouter nix via un simple "apt-get install nix".

Côté utilisation, j'ai installé Gimp via Flatpak et via Nix.
Gimp côté Nix est plus rapide à se lancer, prend moins de Ram et parait plus réactif (ça c'est peut-être subjectif).
Même constat pour Gcompris.
Pour l'instant, j'ai pas rencontré de soucis d'install alors qu'avec Snap et Flatpak, j'ai souvent des couacs.

J'ai proposé au dev de Synaptic de rajouter Nix : https://github.com/mvo5/synaptic/issues/46
J'ai proposé la même aux dev de Bauh  : https://github.com/vinifmor/bauh/issues/45)
Pour Bauh, je vais peut-être même retrousser les manches et tenter de créer l'évol.

Pour les 2 points que tu évoques :

1. Les raccourcis : c'est un vrai soucis et je vais enquêter la dessus.
2. J'ai perso installé des softs qui tire parti de OpenGL sans rencontré de difficulté mais je m'étais également posé la question en lisant la doc.
J'ai pas vraiment d'avis sur la question pour le coup.

Dernière modification par moths-art (Le 31/12/2019, à 15:41)

Hors ligne

#5 Le 31/12/2019, à 16:17

GammaDraconis

Re : gestionnaire de paquet NIX

moths-art a écrit :

depuis que Ubuntu est basé sur Debian Buster, soit la "Eoan Ermine", il est possible de rajouter nix via un simple "apt-get install nix"

Je viens de vérifier, Nix n'est pas présent dans les dépots d'Ubuntu que ça soit ceux d'Eoan (19.10) ou ceux de la future LTS Focal (20.04) même si pour la 20.04 ça peux encore se faire jusqu'à Mars vu que les paquets ne sont pas gelés pour l'instant. (ou sinon il faut installer manuellement le paquet deb)

Sinon Ubuntu n'est pas basé sur une version précise de Debian, il n'y a pas de version d'Ubuntu qui correspond à Jessie ou Stretch ou Buster. C'est synchronisé sur la version en développement de Debian à un moment donné (Debian Testing/Sid puis ensuite Canonical gèle les versions majeurs des paquets) et donc ça ne va pas forcément correspondre aux versions des paquets une fois qu'une version de Debian passe en stable.

Buster étant sortie en 2019 quelques mois avec Eoan, beaucoup de paquet venant de Buster doivent probablement fonctionner sans problème sur Eoan mais c'est simplement parceque c'est à peu près la même génération pour la sortie de ces 2 versions mais il y a beaucoup de différence quand même. Ubuntu 19.10 par exemple est fourni avec Gnome 3.34 alors que Debian Buster est fourni avec seulement la version 3.30 soit 2 versions majeurs de retard par rapport à Ubuntu.

Même la version précédente d'Ubuntu (la 19.04, Disco Dingo) à pas mal de logiciel plus récent que Debian Buster pourtant sortie après. Les versions d'Ubuntu ne sont pas synchro sur les versions stable de Debian. Ubuntu à des paquets nettement plus récent à date de sortie équivalente, ça vient surtout que sous Debian, ils ont une période de "freeze" beaucoup plus longue alors qu'Ubuntu peux encore intégrer des nouvelles versions 1 mois à peine avant la sortie.

Par exemple, la prochaine version de Gnome (3.36) sortira en Mars 2020 soit seulement 1 mois avant la sortie de la 20.04 et bien il y aura bien cette version 3.36 dans Ubuntu 20.04 alors que ça serai impossible avec une Debian Stable qui sortirai en Avril 2020, il faudrai que Gnome soit publié pratiquement 6/7 mois avant la sortie. Ubuntu est donc beaucoup plus dynamique que Debian sur les versions des logiciels, c'est normale, Debian Stable est + dans une logique "conservateur" et de "stabilité". D'ailleurs il y a beaucoup de Debianiste qui préfère utiliser la version Sid à cause de la stabilité et certains choix sur la version stable.

Rien que le choix de la version de Firefox l'illustre : sous Debian par défaut c'est Firefox-ESR dans les dépots, version conçu pour les environnements en production par ex une entreprise ou une administration mais pour une utilisation perso, on préfère la version standard. Sous Ubuntu c'est bien la version standard par défaut. Ubuntu vise + le grand public.


moths-art a écrit :

Les raccourcis : c'est un vrai soucis et je vais enquêter la dessus

C'est un énorme défaut car Nix ne pourra pas avoir un succès global si l'utilisateur est obligé de créer lui même ces raccourcis.

Mais tu es développeur pour le projet Nix ?


Discussion sur mon script de post-install pour Ubuntu 20.04LTS : https://forum.ubuntu-fr.org/viewtopic.php?id=2026344
Lien direct script : https://github.com/simbd/Ubuntu_20.04LTS_PostInstall
Démo vidéo (peertube) : https://video.ploud.fr/videos/watch/fb7 … 0d252ed2db

Hors ligne

#6 Le 31/12/2019, à 16:27

moths-art

Re : gestionnaire de paquet NIX

GammaDraconis a écrit :

Sinon Ubuntu n'est pas basé sur une version précise de Debian

Oui, elle se base effectivement sur Sid et fait sa soupe. Mais y'a quand même une volonté d'être iso avec la dernière version stable de Debian... va falloir que je trouve des sources pour avancer ce que je dis.

GammaDraconis a écrit :

Mais tu es développeur pour le projet Nix ?

A non, pas du tout. Mais bon, j'aime bien fouillé dans les sources d'un projet, proposer des améliorations etc.

Hors ligne

#7 Le 31/12/2019, à 17:14

Roschan

Re : gestionnaire de paquet NIX

J'ai pas lu tout le débat je réagis juste sur ça :

- Il y a déjà les dépots officiels qui contiennent un nombre important de paquet
- Il y a la multitude de PPA (très nombreux) qui permettent d'avoir des logiciels supplémentaires ou en version plus récente
- Il y a de nombreux sites d'éditeur qui fournissent le paquet deb (exemple Spotify ou Google Chrome), parfois le paquet deb ajoutera aussi leur dépot pour qu'il soit à jour automatiquement
- Il y a des les dépots externes que propose directement les éditeurs (par exemple Virtualbox pour avoir la dernière version systématiquement)
- Il y a les paquets universels avec la technologie de Canonical : les snaps
- Il y a les paquets universels concurrent avec Flatpak
- Il y a les applications portables avec le format AppImage (qui n'est pas exactement pareil que les snaps et flatpak)
- Il y a les applications fourni par un script bash à lancer
- On peux aussi installer les paquets/logiciels Python en passant par la commande "pip" (ex: pip3 install spyder)
- Certains paquets peuvent s'installer aussi avec le gestionnaire de paquet "npm" (npm install...) même si c'est des cas particuliers...
- En dernier recours on peux aussi compiler le logiciel à partir des sources pour ensuite l'installer

La méthode de paquet NIX n'est donc qu'une énième méthode supplémentaire.

Tu gonfles artificiellement ta liste. Les points 2, 3 et 4 sont la même chose. Les points 9 et 10 aussi. Ni appimage, ni les scripts bash dégueulasses à télécharger sur navigateur pour les lancer comme root, ni la compilation à partir des sources ne sont des utilitaires de gestion de paquets. Pas de mises à jour, pas de sécurité, pas de garantie de stabilité ni de compatibilité. Rien.

Au final on a :
  - les paquets natifs de la distribution, avec les coûts que ça implique pour les mainteneurs des distros.
  - les paquets natifs sur dépôts externes, avec les risques de sécurité et de stabilité qu'on connaît
  - les utilitaires de gestion des dépendances pour le développement (cargo, npm, pip, gem, ...)
  - flatpak
  - snap
  - et nix, donc

Nix est donc une nième méthode pour fournir des logiciels de manière solide et universelle avec un système de rollback et possibilité d'installer plusieurs versions en parallèle. "nième", avec n = 3, ce qui est plus que nécessaire, mais pas énorme. Je ne sais pas si c'est fonctionnel, mais il y a éventuellement Guix aussi, ce qui ferait 4.

-----

Ceci dit comment t'en vouloir de gonfler artificiellement ta liste, quand on voit que Nix ne propose pas de nombreuses applications dispo sur flathub ni snapcraft, mais alleluiah ils ont 30 000 paquets de librairies de développement pour des langages obscurs.

approche fonctionnel

Je ne sais pas ce que ça veut dire en français, mais ce qui me paraît fonctionnel personnellement c'est plutôt quand en un clic t'as ton appli d'installée et prête à l'emploi, et Nix en est encore loin

Dernière modification par Roschan (Le 31/12/2019, à 17:15)

Hors ligne

#8 Le 31/12/2019, à 18:06

moths-art

Re : gestionnaire de paquet NIX

Fonctionnel, plutôt dans le sens du paradigme de programation : https://fr.wikipedia.org/wiki/Programma … ctionnelle
Donc sans effet de bord.

Pour Guix, je ne connais pas l'état d'avancement mais c'est du Nix à la sauce FSF.

Dernière modification par moths-art (Le 31/12/2019, à 18:11)

Hors ligne

#9 Le 31/12/2019, à 18:46

Roschan

Re : gestionnaire de paquet NIX

Écrire sur le disque est en soi un effet de bord, de même qu'un affichage à l'écran. La programmation fonctionnelle est un paradigme de programmation, pas un gestionnaire de paquets. En l'absence de sandboxing, la seule absence d'effets de bords notable c'est une isolation au niveau de l'arborescence dans l'espace de stockage

Hors ligne

#10 Le 01/01/2020, à 12:33

GammaDraconis

Re : gestionnaire de paquet NIX

Je regrette aussi que beaucoup d'applis qui ne sont pas dispo dans les dépots d'Ubuntu, ni snap ni flatpak ne sont pas non plus présent dans Nix. On retrouve en faite le même problème : la plupart des applis dans Nix sont des applis "facile" à installer en temps normale et donc ont peu d'intêret d'utiliser encore une autre méthode d'installation d'alternative.

Par exemple, le logiciel de bureautique "OpenOffice" (je ne parle pas de LibreOffice mais bien d'OpenOffice), c'est un logiciel libre et même si il a moins d'intérêt que LO, certains veulent l'utiliser. Actuellement pour l'installer on est obligé de récupérer sur le site officiel une archive qui contient pleins de paquet deb à installer, ce n'est objectivement pas pratique (et en + il ne sera pas maj même si les maj de versions sous oo sont peu fréquentes...).
Il n'y a pas de PPA ni de snap ni de flatpak pour l'installer. Ça aurai pu avoir un intérêt qu'il soit géré par NIX mais il n'est pas dans les dépots.

Pour que NIX soit vraiment intéressant et avantageux, il faudrai qu'ils se concentrent sur les logiciels qui sont pénibles à installer et qu'on ne retrouve pas dans la logithèque d'Ubuntu;

Dernière modification par GammaDraconis (Le 01/01/2020, à 12:33)


Discussion sur mon script de post-install pour Ubuntu 20.04LTS : https://forum.ubuntu-fr.org/viewtopic.php?id=2026344
Lien direct script : https://github.com/simbd/Ubuntu_20.04LTS_PostInstall
Démo vidéo (peertube) : https://video.ploud.fr/videos/watch/fb7 … 0d252ed2db

Hors ligne

#11 Le 02/01/2020, à 00:44

Roschan

Re : gestionnaire de paquet NIX

C'est d'ailleurs l'approche de snap, qui se concentre énormément sur les applis tierces, notamment celles propriétaires

Hors ligne

#12 Le 02/01/2020, à 20:45

moths-art

Re : gestionnaire de paquet NIX

Désolé de répondre aussi tard, nouvel an oblige.

Je recentre un peu le débat. (si débat il y a)
J'ai découvert et testé Nix il y a peu de temps et trouve qu'il manque de visibilité par rapport à d'autres solutions.(qui présente chacun leurs avantages/inconvénients)
C'est un gestionnaire de paquet à part entière (comme apt, rpm, pacman etc.) qui peut fonctionner sur plusieurs distrib linux. (à la diff de celle pré-cité)
Ça n'a donc pas la vocation de remplacer les gestionnaires de paquet natif (apt pour Ubuntu en l’occurrence) mais de l'étendre.
Ma connaissance est de l'ordre de la découverte et donc j'affine ma compréhension par l'expérimentation.

A la diff de apt qui est plutôt orienté versionning, Nix est dans une optique Rolling release donc on peut avoir des softs plus à jour qui fonctionne partout.
En soit, c'est donc un concurrent direct à AppImage, Flatpak ou Snap.

Néanmoins, sous le capôt, il n'utilise pas de sandbox. (à tord ou à raison, c'est difficile de trancher)
Je ne sais même pas si ils utilisent des briques tel que les cgroups qui permettent du sandboxing au niveau noyau...

Le process de création de paquet se base sur un langage avec le paradigme "fonctionnelle".
C'est une "promesse", ça ne veut pas dire que c'est prouvé 100% sans effet de bord.
De plus, n'étant pas core-dev mais simple utilisateur (qui cherche à élargir ses connaissances sur le sujet), j'émets des hypothèses plutôt que des affirmations.
Ce que je trouve déjà louable c'est de "tendre" vers cette approche. Après, la réalité est toujours plus nuancé que la réalité.

Néanmoins, de ma faible expérience de dev de paquets deb, le process de build s'appuie (en partie) sur des scripts sh et donc sur un paradigme plutôt "impératif".
Sur une distrib plutôt "cohérente" et incrémentiel, ça fonctionne plutôt bien mais ça présente des faiblesses sur des migrations, (jamais vraiment bien fonctionné sur Ubuntu et c'est en partie lié à Apt) sur des sources tiers (ppa, paquet debian séparé etc.).
On se retrouve avec des paquets "cassés", des dépendances non résolus etc.

Rpm, pacman, Snap et Flatpak (les gestionnaires de paquets que j'ai approché, le reste j'en sais rien) ont tous des approches "impératives" et du coup peuvent présenter les mêmes écueils que apt.

Avec une approche fonctionnelle, Nix apporte un approche "transactionnel" ou un paquet ne peut pas se retrouver dans un état "indécis".
Le paquet est installé ou non, y'a pas d'intermédiaire.
Les dépendances ne sont pas liés à une version précise de la distrib mais plutôt à un hash.
Ça a l'avantage (au moins sur le papier) de fonctionner partout, de permettre des rollbacks, d'avoir une install d'un ensemble de softs unitaires.
Imagine, tu as une centaine de paquets qui fonctionne exactement tel que tu veux sur une Archlinux et que tu veux les basculer sur des postes sur Ubuntu sans avoir de blagues (version plus récente ou plus ancienne, config diff etc.)
Avec des paquets Nix, tu es capable de faire ça et je ne connais pas beaucoup d'autres solutions qui proposent de faire aussi simplement.

L'inconvénient c'est que ça peut être plus gourmand (ou surtout plus difficilement contrôlable) en occupation disque.

Maintenant, Nix est un support et ce n'est pas "magique".
Si le soft installé est bancal c'est pas la faut du système de packages : ça ne peut pas résorber des écueils lié à des technos pourris.
Pareil pour les libs : si des dépendances sont pas ou mal renseignés : ça peut fonctionner dans certains cas et pas dans d'autre.
D'un point de vue extérieur, on pourra reprocher au système de package alors que c'est plus lié au mainteneur du paquet voir au dev.

@GammaDraconis :

Je suis bien sur en accord avec toi.
J'ai jamais dit que Nix était la solution à tout. C'est un outil supplémentaire et qui est "à mon sens" stable.
Nix est pour l'instant connu et intéresse beaucoup les devops (et peut être un alternative à docker). Il est donc compréhensible que beaucoup de paquets concernent ce domaine.
Comme pour n'importe quel projet, si personne ne fait l'effort de proposer un paquet, ben il n'existe pas...
Je ne pense pas que ça soit lié à "facile" ou non mais je me trompe peut-être.
C'est aussi un peu le serpent qui se mort la queue : si on veut qu'il y ait plus de paquets supportés, il faut que ça soit connu.

@Roschan : écrire sur le disque etc c'est un effet de bord.
Dans l'absolu, tu as raison. Après, c'est le cas de tous les langages/softs, paradigme fonctionnelle ou non.
En revanche, des langages tel que haskell vont isoler ces parties 'impropres" et encapsuler avec des appels fonctionnelles pures.
C'est beaucoup mieux dans le sens ou les effets de bord ne sont possibles QUE dans ce cadre.

Que Snap se concentre sur le propriétaire, c'est tant mieux et compréhensible.
Si Canonical veut agréger des nouveaux utilisateurs, il doit permettre de retrouver des softs grand public présent sur Windows pour que la transition soit plus douce.

Dernière modification par moths-art (Le 02/01/2020, à 20:45)

Hors ligne

#13 Le 03/01/2020, à 23:07

moths-art

Re : gestionnaire de paquet NIX

Après quelques recherches :

Il est possible d'avoir les raccourcis de Nix via cette commande :

echo 'export XDG_DATA_DIRS=$HOME/.nix-profile/share:$HOME/.share:$XDG_DATA_DIRS' >> /etc/profile.d/nix.sh

Le paquet est bien dans les tuyau de Debian (https://salsa.debian.org/debian/nix/tree/master/debian) mais je sais pas trop pour Ubuntu.

A priori, Nix utile firejail pour isoler les softs. C'est donc bien du sandboxing. (Voir source : https://nokomprendo.gitlab.io/posts/tut … ADME.html)
La, je suis en train d'explorer NUR : c'est un dépôt non officiel qui permet de rajouter pas mal de softs.

Hors ligne

#14 Le 26/01/2020, à 11:28

moths-art

Re : gestionnaire de paquet NIX

Un petit retour d'expérience rapide.
J'ai réussi après quelques efforts à empaqueter un paquet en python pour Nix que je viens de proposer sur le store "nixpkgs" : https://github.com/NixOS/nixpkgs/pull/78492
J'ai également remarqué que Guake n'était pas bien traduit et après enquête, j'ai trouvé la raison puis fourni un patch : https://github.com/NixOS/nixpkgs/pull/78488

L'expérience, même si elle a été semé d’embûches devient passionnante et formatrice.

Je n'en reste pas moins lucide : force est de constater que dans tout système il y a des qualités et des défauts.
Avant d'avoir des conclusions hâtives, je continue l'expérience en notant assidûment ce qui me plait et me déplaît.
Une fois que j'aurais suffisamment de recul, je ferais un bilan.

Hors ligne