barmic 🦦 a écrit 6160 commentaires

En fait il faut comprendre simple :

• simple et facilement mémorisable : que l'utilisateur n'ai pas à chercher
• stable dans le temps : si ça change toutes les semaines ça ne marchera pas

Ou alors tu considère que 5 ce n'est pas un point d'entrée unique et la prédominance des GAFAM ne pose donc pas de problème particulier ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

La de-duplication pourrait faire quelque chose ici. Je ne sais pas comment elle s'en sort quand le contenu d'un bloc est sensiblement le même, mais un peu décalé.

Effectivement c'est la déduplication qui peut aider (si elle est activée). Après je crois que fedora a un système qui permet de mettre à jour par application de diff. Ça doit simplifier les choses.

Donc je suis d'accord avec l'argument du snapshot instantané et qui ne prend que la place nécessaire, mais je pense que cette place nécessaire peut être très importante.

Il n'y a pas de miracle. Cet espace très important c'est la différence entre les 2 états de ton système. On peut envisager des compressions, des déduplication plus ou moins fine, c'est un curseur à positionner.

Supprimer un snapshot va au moins lancer une cascade d'opération pour mettre à jour les meta données de ton file système. Toutes les données devenues orphelines après cette suppression vont devoir etre "collectée" et cela peut representer un gros travail.

Non, il ne touche pas aux fichiers. Il modifie ces propres métadonnées pour supprimer la référence du snapshot. L'espace occupé ne sera réutilisé au fur et à mesure que tu en a besoin. C'est sans commune mesure avec un parcourt arborescent du système de fichiers.

Je ne sais pas pourquoi là tu parle de cascade d'opérations et en dessous tu parle d'un seul.

La grosse difference entre les deux? La suppression d'un snapshot se fera en un appel système et le reste c'est le file système qui fait. La suppression des 200 Gio risque de générer de nombreux appels pour chaque fichiers à supprimer.

C'est exactement mon point.

Cependant, je vois un peu cela comme une analyse amortie. Dans le modèle snapshot + update, tu va supprimer et créer de nouveaux fichiers puis plus tard tu vas supprimer le snapshot. Dans le modèle "nix", tu vas seulement créer de nouveaux fichiers (donc pas d'appel système pour les suppressions) et plus tard, lors de la "purge", tu vas supprimer tes fichiers inutiles. Les deux sembles équivalents, mais pas au même instant.

Tu remplace la suppression par des créations de liens ce qui a le même coût.

En fait, nix fait la même chose que les snapshot sauf qu'avec la connaissance interne du système de fichier c'est bien plus rapide à manipuler, mais ça demande nécéssite un redémarrage pour faire le changement. Après nix a d'autres intérêts.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai pas parlé su service, j'ai parlé d'offre. Fournit moi déjà le logiciel, et je le ferai tourner (en le monétisant :) ). La, l'offre logicielle libre n'existe déjà pas.

Tu connaît parfaitement ces problématiques qui existent déjà (SSPL etc). Donc ton commentaire est juste un troll.

Tu parles d'une chose dont je n'ai pas parlé pour te cacher que le logiciel correspondant n'existe pas en libre.

On a eu 2 dépêches sur bitwarden cette année. Tu te moque de moi je présume.

Voila un paragraphe et je m'arrêterais là. Tu troll pour ensuite t'en servir pour juger. C'est classique, mais médiocre. Passe un bon week-end.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme si il y avait une phobie de rencontrer des gens pas comme eux, des gens pas geeks.

Écrire du code et maintenir un service c'est 2 choses totalement différentes. En plus des compétences différentes écrire du code est immatériel, tu peux le partager à l'infini sans surcoût alors que fournir un service a un coût par utilisateur.

C'est dommage, mais en attendant les gens même développant du libre mais n'ayant pas envie de s'emmerder utilisent du non libre pour ça, faute d'offre réelle (pour tous) libre.

Toi qui est pointilleux sur la notion de liberté parler de « service libre » c'est dommage.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je veux dire que tu peux utiliser la solution de synchro que tu considère la plus adaptée à ton usage¹. Après ça ne t'arrange peut être pas. Tu as des solutions qui sont sous forme de service et qui te permettent d'ignorer la notion de synchronisation, mais ça vient avec un coût je trouve : tu as une dépendance à un service. Charge à toi de garder une copie au cas où le service ne te convient plus, disparaît ou rencontre une panne.

C'est un choix, je ne crois pas qu'il y ai de solutions parfaites.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu peux juste utiliser Google drive, One drive, iCloud ou tout autre solution déjà prise en compte sur ton téléphone.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Alors qu'avec un outil de snapshot système, chaque mise à jour augmente la taille de ton snapshot de plusieurs gigas octets, avec très peu de partage.

Je présume que tu parle de snapshot pre-zfs/hammerfs/btrfs. Avec la technique du CoW, c'est instantané et ça ne coûte que la place réellement nécessaire. Donc non tu ne peux pas avoir une rétention infinie, mais si tu te donne la liberté de consommer 230Gio alors tu as de quoi faire pour un paquet de temps. De plus la gestion est plus légère, il est parfaitement inutile de garder plus d'un certains nombre de snapshots (à choisir) et supprimer un snapshot ne coûte rien. Ça ne ralenti pas ton build suivant, ça prend le même temps quelque soit la taille de ton fs ou des données contrairement à une suppression de 200Gio sur disque. Définir une rétention est simple tu n'a qu'à supprimer la plus vielle snapshot, tu n'a pas à aller voir chaque fichiers pour ne supprimer que les plus vieux.

(Je sais pas pourquoi tu parle de backup quand il est question de snapshot)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour le simple, je ne sais pas trop. Installer timeshift va sans doute te demander un peu de travail, tout du moins de configuration pour obtenir le snapshot qui correspond à tes besoins (afin de ne pas snapshoter de trucs inutiles qui prennent beaucoup de place, comme tes containers / images docker).

C'est cocasse un défendeur de nix qui explique qu'autre chose que nix prend de la place disque :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Là logique est une science dont l'objet d'étude est, comme son nom l'indique, le langage. Mais elle ne l'étudie pas à la manière de la linguistique, c'est-à-dire qu'elle ne s'intéresse pas à telle ou telle langues données pour les analyser comparativement dans leurs structures. Si je peut m'exprimer ainsi, ce qu'elle cherche à travers la diversité des langues c'est les invariants par variations. Elle cherche les lois nécessaires de toute pensée, dont le langage n'est que le moyen d'expression.

De ce qu'il me semble la logique s'intéresse uniquement aux langues formelles et à l'aspect objectif. Ce n'est qu'une petite partie du langage.

Le fait d'être prescriptif c'est une branche de la logique, mais je pense que ça capture bien ce que je trouve profondément gênant avec tes messages. Ça et l'appel continuel aux philosophes, ça ne donne pas vraiment l'impression d'une discussion, mais un étalage de ta science.

Voila c'était plus pour te donner un ressenti que pour en discuter. Bonne soirée

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si je suis que j'adore mon vélo, il va falloir que tu le compare au tiens pour venir me dire que le tiens est meilleur ?

Il décrit une solution, je ne vois pas ce qui présume que c'est la seule ou la meilleure ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Bon j'imagine que c'est possible de faire un alias bash ou zsh qui lance ton instantané avant de mettre à jour mais bon on rentre dans la bidouille.

Pas mal de gestionnaire de paquets ont des hooks, donc c'est pas de la bidouille. Ça fonctionne juste comme il faut.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est vrai la jvm n'était pas très pratique pour les langages dynamiques jusqu'à l'arrivée dynvoke dynamic pour java8. Il y avait des langages dynamiques avant, mais ils subissaient un peu.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quand tu utilise régulièrement une commande avec une autre, ça peut valoir le coup de regarder si la première ne peux pas faire le travail de la seconde. Un peu comme le sort -u ça remplace pas le uniq dans tous les cas mais si c'est juste pour faire sort | uniq ça veut le coup. Comme le grep -c à la place du grep | wc…

Par exemple si tu récupère des fichiers par ssh pour les désarchiver tu peux faire :

tar --rsh-command=/usr/bin/ssh -xf login@machine:/chemin
# qui peux se simplifer en
export TAR_OPTIONS="--rsh-command=/usr/bin/ssh"
tar xf login@machine:/chemin

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

pi@raspberrypi:~ $ free

L'option -h rend le poil soyeux, fais revenir l'être aimé, résorbe la couche d'ozone et guéri du covid toute ta famille ;)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça fait combien de temps qu'elle existe cette extension ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui mais non. NUR demande effectivement une étape de configuration mais après tu fais bien des installations hors nixpkgs (ou du moins sur un nixpkgs augmenté), par exemple :

$ nix-shell -p nur.repos.mic92.hello-nur

Non c'est juste un paquet qui est sur nur et qui sert à vérifier qu'il est bien installé (et ce n'est pas un paquet comme on l'entends ailleurs car il ne fais qu'un hello world en nix sans ajouter de fichiers).

Et pour en revenir au "cas nominal" de Nix, je pense que justement c'est plus de gérer nos propres environnements de développement que d'installer un logiciel de nixpkgs. D'ailleurs, la page de doc du site aborde très souvent les "developer environments" (https://nixos.org/learn.html).

Tout à fait et je pense qu'il est très pratique pour ça quand on a des dépendances qui sont intriquées avec le système (en js c'est osef par exemple).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Nix est peu connu donc on ne risque pas de voir, par exemple, vscode fournir un script Nix.

Ce n'est pas non plus mis en avant.

Mais dans la communauté Nix, il est assez courant de proposer des scripts/paquets en dehors de nixpkgs : home-manager, cachix, nixGL, nur…

Alors NUR pas vraiment et c'est assez logique, c'est juste une conf de nix et pas une installation de logiciel, mais oui c'est assez logique qu'ils s'en servent.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu as peut être évité de lire la parenthèse? Ça ne me paraît pas être le cas nominal. La page d'accueil présente immédiatement le nombre de paquet du dépôt, la page de features n'en parle pas et mentionne différentes commandes s'appuyant sur le dépôt,…

C'est tout à fait possible de le faire, mais je n'ai pas encore vu quelqu'un fournir de script nix hors du dépôt et d'exemples.

J'ai l'impression que c'est utilisé par les utilisateurs eux-même (tu dérive un paquet ou tu en crée un et tu l'utilise ou le lance sur l'ensemble de tes machines). Je n'ai pas vu d'upstream le faire, mais je peux me tromper.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Nix ne répond pas tout à fait à la même problématique.

Il y a plusieurs problématiques différentes:

• comment en tant que développeur je peux rendre disponible mon logiciel au plus grands nombres
• comment en tant qu'utilisateur je peux avoir des versions plus à jour (potentiellement sans trop impacter le reste de mon système)
• comment en tant que développeur je peux avoir les dernières versions des bibliothèques que j'utilise
• comment installer un logiciel pour un utilisateur uniquement
• …

Et les différentes solutions se basent sur une façon d'imaginer les choses.

nix, guix et pkgsrc permet surtout d'installer des logiciels sans impact sur le reste du système. Cela apporte des choses en plus et nixos pousse ça à tous l'ensemble du système. Mais on est sur un modèle à dépôt. Tu fais inclure ton logiciel dans le dépôt et il est dispo (tu peux fournir un script nix pour faire l'installation, mais c'est pas l'usage nominal).

snap et flatpack se concentre sur le sandboxing. L'idée c'est qu'un logiciel n'accède pas à tout tes fichiers par exemple. C'est très pratique pour des logiciels propriétaires. Moi par exemple j'ai besoin de teams pour travailler, mais je préfère qu'il soit dans une sandbox. Les 2 fonctionnent sur la base de dépôt, mais flatpack, mais en avant le fait que chacun peut créer un dépôt et donne la possibilité d'installer un fichier unique. En ça il vient aussi sur les cas d'usage des PPA par exemple.

appimage c'est vraiment un fichier que tu prend, tu lance, ça marche. Pas d'autres question, c'est très très pratique, même s'il n'a pas certaines bonnes propriétés qu'on les autres (il n'y a rien pour savoir/simplifier la mise à jour, l'utilisateur doit gérer ces fichiers les mettre dans son $PATH, etc).

Après il y en a eu un paquet des solutions 0install, klik, runz,… sachant que AUR, les PPA et probablement d'autres solutions spécifiques à des distributions se rapproches de ses solutions.

Il est vraiment difficile de ne pas y voir une xkcd #927, avant c'était la galère, il fallait packager pour deb, rpm, tarbal,… maintenant il y a appimage, flatpack, snap, nix,… et tu peux continuer à packager pour les classiques

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme le dis ton lien, uniquement pour les OS 32 bits uniquement et linux commence à préparer le 32bits à utiliser une représentation du temps sur 64bits.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

En réalité je suis développeur et je m'appuie sur les dernières dépendances disponibles (non-bétas) pour tout ce que je fais.

Avoir la dernière version de NodeJS sans avoir à utiliser nvm est un plaisir, j'évite de multiplier les gestionnaires de paquets (c'est une contrainte client que d'être sur la dernière version de NodeJS).
Avoir accès aux dernières nouveautés dans diverses libs pour préparer l'avenir et faire mes tests est essentiel.
Avoir un IDE à jour permet de profiter des dernières améliorations et comble parfois de réels manques.

Je suis aussi développeur et jamais quelque soit la stack, je ne mélangerais mes dépendances avec celles du système. C'est beaucoup trop risqué. En particulier quand on veut être très à jour. Il est facilement nécessaire d'avoir de multiples versions voir des builds autres pour pouvoir suivre certains développement. Utiliser le système pour ça c'est non seulement une contrainte (tu peux avoir de la gestion des droits juste embêtant pour un usage de développeur, tu es dépendant de ton système pour livrer, avoir différentes versions peut être un peu embêtante,…).

En tant que joueur et béta-testeur volontaire (là oui j'utilise les pilotes bétas) pour la marque verte (bien que je file chez la concurrence d'ici quelques semaines), je ne suis pas peu fier aussi de contribuer à l'amélioration des pilotes sous notre système d'exploitation préféré. Je remonte régulièrement les problèmes en upstream et j'ai évité quelques galères futures aux utilisateurs, notamment lorsqu'ils ont implémenté le support de la synchronisation PRIME.

C'est les questions de support toutes les distributions mettent à jour ce qui implique le support matériel. Ça n'implique pas des millions de paquets non plus.

J'ajouterai qu'être à jour m'a régulièrement évité des problèmes de compatibilité. A une époque (qui commence à être lointaine maintenant) sous Debian il m'était impossible de jouer à la majorité de mes jeux à cause de la libSDL qui était trop vieille. C'est juste chiant de devoir récupérer la lib et la compiler à la mano, pour peu qu'elle tire elle aussi des dépendances un peu plus récentes, tu finis avec un spaghetti de dépendances que tu ne peux même pas gérer avec ton gestionnaire de paquets…

Un jeu qui a était codé la semaine dernière avec la version de la SDL sorti la semaine d'avant ? Hum…

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce n'est pas un faux dilemme dans le sens où la question du packaging a des problématiques et des critères de décisions qui n'a pas une solution optimale sur tous les critères. Tu dois faire des choix, privilégier certains critères au détriment d'autres. C'est de ingénierie classique.

Ce n'est pas ce que disais.

Mais tout ça est possible avec Flatpak justement.

Tout à fait et je crois que l'une des applications que j'ai est parti dans cette direction.

Plus tu découpes les runtime, plus la maintenance est complexe, or les gens qui maintiennent ces runtime n'ont pas un temps infini.

Encore une fois ? Il y a un large éventail de choix entre faire des runtimes d'1Gio et en faire des millions de 200Kio. AMHA le curseur n'est pas optimal, même pour la maintenance. Je pense que séparer à minima les toolkit et des environnements de bureau ne serait pas déconnant je suis pas convaincu que la plupart des app que j'ai installé utilisent des spécificité de l'un ou l'autre.

Puis tu perds en réutilisation s'il y a 20 000 runtimes différents qui permettent d'utiliser Qt 5.15 et que chaque application en utilise un différent.

Encore une fois je pense que c'est un leurre. À part les hypothèses de concevoir des distributions entièrement basé dessus (ce qui n'est pas une bonne idée à mon avis) je doute que les gens installent 20 000 applications différentes avec. Se coupler avec une distribution et au détriment de tous les autres utilisateurs c'est un peu ce qui est reproché à snap.

Ensuite si chaque Flatpak embarque toutes ses dépendances à la AppImage, tu perds les bénéfices liés au runtime en terme de maintenance (dont de sécurité) et en mutualisation de ressources.

Et en regroupant de trop aussi. Parce que tous les composants ne sont pas gérés par les même équipes, ni avec les même temps de cycles,…

Et ce n'est pas un mal en soit.

Je n'ai fais que donner mon avis.

Ou si je veux avoir la dernière version de GNOME mais garder d'autres composants un peu plus ancien, je fais comment ?

Tu installe la dernière version de gnome et les quelques autres composants via flatpak. C'est bien plus logique et à l'usage ce sera bien plus simple.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis sûr que tu as des runtimes qui seront désinstallés après ça.

Merci j'ai perdu 1 version de gnome (il ne m'en reste que 3) et une version de KDE. Pratique d'indiquer ce qui est toujours utilisé ou non quand on demande la liste ou qu'on met à jour ⸮

Après c'est aussi le prix à payer pour que chaque application fonctionne quelle que soit ta distribution. ;)

Non, il y a d'autres choix possibles ton faux dilemme ne marche pas avec moi.

Tu peux avoir des parties plus petites et composables pour réduire ce qui est complètement inutile (mon wireshark n'a pas besoin de tout le KDE platform).
Tu peux faire du spécifique à la appimage.

Ce sont des choix (est-ce qu'il vaut mieux avoir 4 fois le même Qt ou un runtime de 1Gio). Ils sont fait en imaginant l'utilisation à voir comment ce sera utilisé. Je ne dis pas que flatpack est mauvais juste que la réutilisation c'est une chimère (particulièrement parce que ça sert entre autre à pouvoir varier les environnement comme là où j'ai un KDE et plusieurs versions de gnome). Entre autre parce que si tu utilise flatpak pour installer 25 applications qui demandent la même version de gnome, c'est peut être que tu avais juste besoin d'une distribution avec cette version de gnome.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

C'est pas un secret

Discord - Messaging, Voice, and Video Client                                           com.discordapp.Discord              0.0.12              stable x86_64 flathub               system
Microsoft Teams - Microsoft Teams for Linux is your chat-centered workspace in Office… com.microsoft.Teams                 1.3.00.25560        stable x86_64 flathub               system
Slack - Chat with your team                                                            com.slack.Slack                     4.11.1              stable x86_64 flathub               system
Spotify - Online music streaming service                                               com.spotify.Client                  1.1.42.622          stable x86_64 flathub               system
GNOME Twitch - Twitch desktop client                                                   com.vinszent.GnomeTwitch            0.4.2               stable x86_64 flathub               system
XMind 8 - Amazing brainstorming and mind mapping tool.                                 net.xmind.XMind8                    R3.7.9.201912052356 stable x86_64 flathub               system
razerCommander - Razer device manager for Linux                                        org.gabmus.razercommander           1.2.1.2             master x86_64 razercommander-origin system
Inkscape - Éditeur d'images vectorielles SVG Inkscape                                  org.inkscape.Inkscape               1.0.1               stable x86_64 flathub               system
Wireshark - Wireshark is the world's foremost protocol analyzer                        org.wireshark.Wireshark             3.2.7               stable x86_64 flathub               system

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

j'apprécie les mises à jours rapides à la fois pour des raisons d'accessibilité (avec un meilleur support des outils/réglages dont j'ai besoin pour pouvoir lire l'écran) […]

C'est ce que j'appelle des logiciels que tu utilise intensivement. Au final ça ne représente pas grand chose, quelques logiciels utilisateurs et du support matériel (noyau, drivers, microcode,…).

[…] et aussi par curiosité personnelle (je suis vraiment passé à Linux il y a quelques mois à peine, j'ai encore tant de trucs à apprendre… autant le faire avec des versions récentes des logiciels).

Avec le temps on voit surtout que même une RHEL, une debian ou une slackware, on en utilise pas les fonctionnalités à jour. Toi qui vient d'arriver tu connais plus ss ou lntp ? ipconfig ou ip ? tar tu l'utilise avec les options j/z/J pour indiquer les formats de compression ou avec a pour le laisser découvrir (à la compression, ça n'est pas nécessaire à la décompression) ? Je vois encore beaucoup de monde lancer des sous commande shell avec les backticks alors ça fait 15 ans qu'il vaut mieux utiliser $().

Entendons-nous bien il faut mettre à jour et certaines fonctionnalités infusent bien plus vite dans la communauté, il est bien plus confortable pour les développeurs de pouvoir s'appuyer sur les fonctionnalités de bibliothèques récentes. C'est le coté course, le « moi je suis tellement à jour que tous les matins je rebuild depuis le HEAD », que je trouve pas vraiment pertinent. Après chacun fais bien ce qu'il veut :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll