🚲 Tanguy Ortolo a écrit 12451 commentaires

apt-get install needrestart

Alors on pourrait être tenté de considérer les devs Excel comme des abrutis infoutus de chercher "calendrier grégorien" sur Wikipédia. On n'aurait pas forcément tort, mais je me permets de suggérer une autre hypothèse. La première version d'Excel date de 1985. À l'époque, la rapidité d'un algo était encore plus cruciale que son exactitude dans ce qui était considéré comme un cas limite. Calculer le reste de la division par 4 de deux chiffres, c'était ultrarapide. La contrepartie, c'était une erreur de 1 jour pour une année il y a 85 ans.

En 1985, je ne sais pas ce qu'on avait comme ordinateur, mais on parle de calculer le reste de la division par 4, le reste de la division par 100 et le reste de la division par 400. Le nombre de chiffres du numérateur a, je pense, peu d'importance puisque je doute que les ordinateurs en question calculent en décimal.

Je veux bien entendre que trois divisions euclidiennes, c'est trois fois plus long qu'une seule, mais on parle d'opérations à peu près instantanées, même sur les calculatrices de poche de l'époque non ? Sur une pascaline, je ne dis pas, mais sur un PC de 1985 quand même…

D'après mon expérience de tous les jours, c'est effectivement un problème de Firefox, et de lui seul. C'est dans doute lié à un fonctionnement particulier de ce navigateur puisqu'il utilise plusieurs processus qui semblent interagir assez fortement entre eux.

Par opposition à des logiciels qui n'utilisent qu'un seul processus, ou plusieurs mais avec des interactions entre eux limitées et surtout, cadrées, par exemple le serveur de courrier Postfix.

Mais dans l'ensemble, Flatpak est très orienté applications graphiques. Ceux qui adorent tout faire en ligne de commande resteront sans doute sur des distributions traditionnelles.

Ça confirme une impression personnelle, et donc un corollaire : le tout atomique + Flatpak ou équivalent n'a aucune chance de remplacer complètement nos distributions.

On peut mettre à jour sans risque une application en cours d'utilisation. Tant que l'application n'a pas été relancée, l'utilisateur reste sur l'ancienne version, évitant ainsi de possibles comportements erratiques et autres instabilités

Ça tu peux l'enlever de la liste, ça n'est pas spécifique aux Flatpak. C'est une généralité sous *nix.

…. mais je doute que Google le permette sur Androïd.

Disons que Google ne font rien pour ça évidemment. Il existe des outils pour le faire, c'est assez compliqué à mettre en œuvre et ça nécessite un téléphone rooté pour commencer.

Je questionne, parce que mine de rien, s'il y a des catégories de logiciels qui ne passeraient pas avec un tel format de distribution et d'utilisation, c'est bloquant en fait.

Je peux bien avoir un système de base atomique et plein de logiciels ordinaires sous forme de Flatpak, s'il n'y a pas moyen d'utiliser ainsi un truc comme Samba, ça implique qu'on peut se diriger, au mieux, vers un système triple : système de base atomique, paquets ordinaires et Flatpak. Mais en aucun cas système atomique et Flatpak seuls du coup.

Ah, très bien. Je doute que ça s'améliore sur Android, mais du moment que, sur les systèmes GNU/Linux atomiques dont on parle ici, il sera possible d'installer le Flatpak – ou quoi que ce soit d'équivalent – de Restic puis de lancer directement des trucs comme ce qui suit dans une terminal, ça me va.

mount /var/local/backup   # Grâce à une entrée idoine dans /etc/fstab
restic -r /var/local/backup/restic backup /home/tanguy

Perso, mon expérience avec Flatpak, qui se résume à l'utilisation de quelques logiciels qu'Ubuntu a décidé de ne plus distribuer en paquets Debian, c'est en gros : ça marche bien, mais pour ouvrir un truc avec Firefox il faut que je pense à le copier ou à le lier dans le répertoire « Téléchargements » parce qu'il n'a accès qu'à ça.

Bref, rien que du moins bien, mais pas trop quand même.

Dans les logiciels un peu spéciaux, je peux aussi ajouter quelques autres exemples intéressants, pour questionner les limites du modèle : JACK, bridge-utils ou encore les pilotes graphiques propriétaires Nvidia.

Quelques questions sur cette idée de système atomique et d'applications en bac à sable.

Comment est définie la frontière entre système et logiciels ordinaires ?

Le noyau, l'init et probablement la libc sont certainement considérés comme faisant partie du système, mais qu'en est-il des autres logiciels ? Par exemple :

• X.Org : système ?
• Gnome Shell ?
• Nautilus ?
• CUPS ?
• Epiphany, Firefox ?
• LibreOffice ?
• Totem, VLC ?
• Evolution, Thunderbird ?

Comment s'intègrent des logiciels « un peu spéciaux » ?

Je pense par exemple à des logiciels serveurs, des outils en ligne de commande et des outils d'administration, tels que GParted, Parted, RSync, Samba, Postfix, Apache httpd, lshw, btrfs-progs, LVM, cryptsetup, v4l2loopback…

Ça s'intègre bien en Flatpak ou équivalent, ce genre de truc ? Et installé ainsi, c'est aussi utilisable ?

iOS et Android le font depuis toujours. Et s'ils sont loin d'être parfaits, je pense néanmoins que ce sont des systèmes nettement plus fiables que les distros Linux grand-public (et c'est aussi pour ça que je ne dirais pas que c'est une "mode cyclique" : je ne vois pas pourquoi ces OS reviendraient un jour à l'ancien paradigme)

Ça pour moi c'est précisément l'exemple à ne pas suivre. Je ne sais pas à quel point c'est lié à cette conception avec un système magique intégré et des applications en bac à sable, mais Android est une horreur à administrer. Même en ayant activé un accès root.

Vous avez déjà essayé de faire des sauvegardes ? Des sauvegardes complètes je veux dire, un truc qu'on peut restaurer en cinq minutes sur un nouvel appareil en cas de panne de votre téléphone.

Il y a des logiciels géniaux pour faire des sauvegardes incrémentales et dédupliquées, personnellement j'utilise Restic. Eh bien, pour utiliser ça sur Android, et écrire dans un périphérique de stockage USB, vous pouvez toujours courir.

Premier problème, installer Restic (ou Borg, ou ce que vous voulez). C'est un outil en ligne de commande, et pas de bol, la ligne de commande, sous Android, n'est accessible que par USB, avec un outil qui s'appelle adb, pour Android debug bridge. Et pas moyen d'installer des logiciels utilisables dedans.

Il y a une solution tout de même, qui consiste à installer Termux, qui est une distribution GNU/Linux pour Android. Et là, Restic est dispo. J'ai quand même l'impression de complètement contourner le système normal de gestion de paquets – pardon d'applications –d'Android.

Enfin, utiliser cet outil pour faire une sauvegarde sur un périphérique de stockage USB. Pas moyen. Termux n'a pas accès aux supports de stockage externe, ne me demandez pas pourquoi. Il faut faire ça par réseau.

Un système (windows, mac, linux) et des applications (firefox, openoffice, vi, etc..), c'est au contraire d'une simplicité désarmante. Dire que tout est pareil et doit être traité pareil, ça n'amène que de la confusion.

Un noyau et des trucs en espace utilisateur, ça je comprends. C'est d'ailleurs à peu près la seule distinction réellement fondée. Bon, ok, on peut aussi distinguer l'init et le considérer comme copain du noyau. Et éventuellement la libc, et encore, ça se discute.

Mais le reste, que ce soit la libgtk3 ou le compositeur utilisé par ton gestionnaire de bureau, ça n'a rien de si particulier qui en ferait un truc à considérer comme faisant partie du « système ». Ou alors, je demande à voir quel serait le critère, pour que ça ne dérive pas selon la sensibilité du lecteur.

Parceque bon, pitié quoi, mais t'installes un truc avec apt-get et ça te conseille d'installer libtruc et donner les droits root et/ou au passage te demande d'activer les statistiques d'utilisations des logiciels avec un message qui te dit que t'as eu beau faire apt-get update && apt-get upgrade le paquet linux-image sera pas mis à jour parceque lol

Jamais eu ce genre de problème.

Que tu te dis tiens j'installe une calculette et que ça te tire l'intégralité de gnome avec, oué, il y a un problème et les gens préfèrent snap.

Ah ben si telle calculatrice dépend de plein de choses de Gnome, bonne nouvelle, en Snap ça va être pareil en fait. Juste au lieu d'installer une calculatrice de 5 Mio et 1 Gio de dépendances, ça va installer un Snap unique qui inclut 1 Gio de dépendances.

Le problème ne vient pas des paquets mais bien du logiciel amont.

Le changement de pilote graphique, genre pour le mettre à jour ?

Parce que sinon, passer du pilote libre, enfin, pardon, du pilote propriétaire Microsoft au pilote Nvidia ou je ne sais quoi, c'est le genre d'opération qu'on doit faire genre une fois.

Mais changer de pilote graphique à la volée, chapeau, c'est bien classe en effet.

Ouais alors si c'est pour se retrouver avec des machins en Java, je ne sais pas si je on doit vraiment considérer ça comme un objectif à défendre.

Il n’y a pas de différence notable entre redémarrer et devoir se relogguer parce que mon login shell et/ou mon DE doivent être relancés.

Le DE, c'est du vent, c'est juste un tas de logiciels, donc autant préciser de quoi on parle.

Si c'est ton gestionnaire de fenêtres X11 qui a été mis à jour, pas besoin de te reloguer, ça peut se relancer. Si c'est X.Org qui a été mis à jour, là oui, il va falloir se reloguer. Si c'est ton compositeur Wayland, il va falloir se reloguer aussi.

Disons que ce sont les deux seuls cas qui sont presque aussi contraignants qu'une mise à jour du noyau.

Après, si c'est le gestionnaire de fichiers ou un autre outil qui fait partie de ce que tu appelles ton environnement de bureau qui a été mis à jour, aucune raison de se reloguer.

Le fait de devoir redémarré pour avoir une mise à jour n’a jamais était un problème,

C'est très subjectif, ça. Personnellement, j'ai toujours trouvé bien préférable de disposer d'un système où tous les logiciels, y compris la libc et sauf le noyau, peuvent être mis à jour sans interrompre l'utilisation normale, et où ces mises à jour peuvent prendre effet en redémarrant simplement les logiciels concernés.

Après, sur un système qui ne nécessite pas de redémarrage, tu es toujours libre de redémarrer si ça t'amuse. Je ne vois pas l'intérêt, mais vu que ça ne te dérange pas…

Ben oui, beaucoup mieux.

La comparaisons à Windows n'était pas censé évoquer une piètre qualité en général, mais simplement une caractéristique précise assez connue et largement reconnue comme assez mal fichue.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Ce qui n'a rien d'atomique

En effet, mais ça peut le devenir en s'aidant de fonctionnalités du système de blocs, genre LVM, ou du système de fichiers, genre Btrfs.

C'est sûr que Windows est réputé pour être vachement plus fiable.

Ça y est voilà la mauvaise foi

Bon alors pour rappel, la nécessité de redémarrer pour les mises à jour de Windows vient d'une erreur de conception historique : l'absence de compteur de liens et d'ouvertures sur les fichiers, qui sont par conséquent censés avoir un unique nom qui ne peut pas être supprimé tant qu'un fichier est ouvert.

Sous *nix, un fichier peut avoir un nombre quelconque de noms au sein du système de fichiers qui l'héberge. Un fichier a souvent un seul nom, mais il peut en avoir plusieurs, on parle alors de liens physiques. Il peut aussi avoir zéro nom, lorsque son dernier nom a été supprimé ; pour autant il peut continuer d'exister tant qu'il y a encore un processus qui a un descripteur dessus, qui l'a ouvert quoi.

Cela implique d'avoir, pour chaque fichier, un compteur de liens et d'ouvertures, puisqu'un fichier ne peut être supprimé du système de fichiers que s'il n'a plus aucun nom et n'est plus ouvert par aucun processus.

Le rapport avec les mises à jour, c'est qu'avec des compteurs de liens et d'ouvertures, on peut installer une mise à jour d'un fichier pouet.so avec un nouveau nom, disons pouet.so.new, puis supprimer le nom pouet.so même s'il est ouvert par un logiciel, et enfin renommer pouet.so.new en pouet.so sans affecter les processus en cours.

Ça, c'est infaisable sous Windows, ce qui pose un gros problème pour remplacer des trucs ouverts en utilisation normale du système. Du coup, on diffère les mises à jour au moment où on est sûr qu'il n'y a pas grand chose d'ouvert, au tout début du démarrage je crois.

Par exemple, j'ai l'impression qu'Amazon et consorts gèrent eux-mêmes la nécessité de 2FA. Quand ils ont un doute (nouvelle carte, même carte sur plusieurs comptes, pas de commandes récentes, changement d'adresse, etc), ils t'envoient une demande de 2FA, mais autrement ça passe sans passer par l'interface de la banque pour valider le payement. J'imagine qu'ils prennent sur eux du coup si la transaction s'avère frauduleuse.

Absolument.

Après, c'est subjectif, mais je trouve que les sites d'ID des banques sont toujours très très laids, c'est tout petit, tout moche, on a l'impression d'être sur une procédure de debug réservée aux sites qui n'ont pas justement implémenté un formulaire correct de saisie d'indentifiants bancaires. Donc ça donne vraiment l'impression inverse, que la norme est de gérer la saisie des identifiants, en lien avec un compte client qui se rappelle des vieux paniers, des commandes, des adresses de livraison, etc.

Le côté joli ou pas, c'est sans importance, on parle de sécurité là, pas de décoration intérieure. Mais ça participe effectivement à bien faire entrer dans la tête des gens que pour effectuer un paiement, il est important de ne vérifier que dalle parce qu'on ne peut rien vérifier.

Je ne vois pas le rapport.

Le protocole qu'ils sont censés utiliser est public, soit. Et ? Ça ne garantit pas qu'ils l'utilisent, encore moins qu'ils n'envoient pas des informations essentielles par un canal détourné.

D'autre part, la mise à jour fonctionne par état. En gros c'est comme "git" pour le code d'un projet, la mise à jour est juste un rebase à partir d'une branche spécifique. Le rebase se fait lorsque le système tourne normalement. Le redémarrage ne sert qu'à changer le commit de référence pour exécuter le système. En gros au redémarrage c'est quasiment instantanée, contrairement à Windows où ça prend du temps. Car la partie longue aura été faite quand l'ordinateur est utilisé normalement.

Oui, ça je m'en doutais. Ça vient avec le fait que c'est conçu de façon réfléchie, pas comme Windows qui a évolué sans réflexion initiale pour ce genre de problème.

Avec ce fonctionnement, comme cela a été expliqué, l'avantage c'est que de revenir en arrière est fiable et tout aussi rapide si c'est nécessaire. Cela peut même se faire automatiquement si la machine est incapable de booter entièrement avec le nouvel état du système.

Et ça nécessite vraiment une distinction artificielle entre logiciels de base et logiciels supplémentaires ?

Enfin, oui l'approche de Windows reste théoriquement une bonne approche malgré tout. Des bogues qui arrivent et qui sont difficiles à corriger ou à identifier car on met à jour lorsque que le système tourne, cela arrive même sous Linux. Et si ton système crashe en pleine mise à jour pour X ou Y raisons, les problèmes peuvent vite s'accumuler. Appliquer les mises à jour quand le système est dans un environnement minimaliste réduit ces problèmes, en terme de fiabilité c'est mieux quoiqu'on en pense.

C'est sûr que Windows est réputé pour être vachement plus fiable.

La mise à jour d'un logiciels, c'est du remplacement de fichiers, et ça se fait très bien en fonctionnement. Pas en réécrivant directement les fichiers, évidemment, mais en les installant avec un nouveau nom puis en retirant les anciens et en renommant les nouveaux.

Ah, parce que ça va avec le concept de système vs applications. Typiquement le genre de truc que je n'ai jamais réussi à comprendre et qui à mon sens ne fait qu'ajouter de la complexité.

S'il y a bien un truc que je trouve super sous Debian et autres, c'est bien le fait que tout, y compris le noyau et la libc, vient de paquets qui se gèrent de la même façon.

Désolé, je ne comprends toujours pas. Es-tu en train de suggérer que les développeurs de Signal ont accès au code source actuel de WhatsApp et pourraient ainsi se rendre compte si Meta y ajoutent de quoi fuiter les clefs par exemple ?

Pour rappel, il n'y a aucune preuve que WhatsApp utilise actuellement ce fameux protocole historiquement utilise pour le chiffrement de bout en bout. Et même en supposant que c'est bien le cas, ce qui repose déjà sur une confiance aveugle, ça ne suffirait pas. Le chiffrement de bout en bout, ça ne sert à rien si c'est chiffré entre un interlocuteur et un MitM, ou si les conversations sont ensuite envoyées à la NSA (chiffrées de bout en bout entre le terminal et la NSA, évidemment).

Je ne sais pas d'où sort cette confiance, mais tout ce que je vois, c'est un éditeur de logiciel qui dit : vous ne pouvez pas vérifier notre code mais vous pouvez juste nous confiance, les communications sont chiffrées de bout en bout. Eh bien, en matière de sécurité, la confiance aveugle ça vaut de la merde, et c'est historiquement prouvé.