freem a écrit 5019 commentaires

J'ai lu les manpages, et essayé divers changements, sans effets actifs, parfois même avec des conflits entre la manpage et le binaire (debian, donc p'tet lié à des patch debian).

Je me souviens pas, mais j'ai essayé de réduire déjà:

• le nombre de threads, 15-20 thread/process pour notre usage, c'est un pur gâchis, et chacun consomme son quota;
• la mémoire par thread;
• le nombre de requêtes acceptables en parallèle;

Et autres dont je n'ai plus souvenir: c'était y'a 4-5 mois, et je suis pas dba. Déjà que je dois apprendre à gérer un parc, faire une chiée de scripts, coder en C++ et former mes collègues, le tout sans moi-même être formé… pfiou. Le plus simple sera largement de remplacer ça par un outil plus adapté. Ce qui m'empêche pas de regretter la qualité faible de la doc. Pour le fun, j'essaierai un jour de me faire une vm avec d'autres BDD, et voir si j'arrive à mieux maîtriser l'occupation des ressources système.
P'tet que je changerais d'avis et que je considérerai mysql comme le fleuron, après ça.

Tu comprends mal. Un des logiciels maisons faits a eu une fuite de mémoire. Réactiver l'overcommit, et ajouter les conditions à la fuite mémoire à fait freeze les systèmes. Déplacement obligatoire pour rebooter, à plusieurs centaines de kilomètres.

Quand l'overcommit était désactivé, ben, sql marchait pas, mais le prog avec fuite mémoire se serait fait tuer dès le 1er dépassement de capacité, ce qui aurait évité le freeze.

N'étant pas un dev kernel, ni mysql/mariadb, je n'ai sûrement pas toutes les clés en main, mais pour moi, allouer plus de mémoire qu'il n'y en a vraiment de dispo sur le système, c'est une mauvaise chose que ça réussisse. Et swapper sur des mémoires fragiles, c'est pas franchement pertinent non plus. Le choix de mysql était de base mal fait, mais voila, il a été fait avant que j'arrive, je n'ai pas eu mon mot a dire, alors j'ai fait avec de mon mieux.

Ah, j'oubliais, ces systèmes embarqués (aujourd'hui, un peu plus de 200) à plusieurs 10aines voires 100aines de km, sur lesquels on a la main via de la 2/3G (et ce, de façon aléatoire compte tenu de la captation de certains coins), ils utilisent runit pour gérer le moindre service, donc si l'un d'eux meurt, il est relancé à propre, ce qui réduit considérablement le problème. J'aurais pu utiliser systemd aussi, certes, ça serait revenu au même. J'aurai aussi pu utiliser les cgroups, il faudrait, même, mais voila, il faut le projet avance et je sais pas utiliser les cgroups.

SInon, ça a quoi de magique pour toi, l'overcommit? A quel moment tu trouves ça logique d'allouer des ressources inexistantes à un processus?

j'utilise la capacité d'Emacs à ouvrir des fichiers sur une machine distante à travers une session SSH (C-x C-f /ssh:user@host:/path/to/file). vi sait le faire aussi il me semble.

Jamais testé. De mon côté, je préfère utiliser sshfs, ça me permets d'utiliser la totalité de mon environnement principal sur la machine distante, notamment zfs.

Après concernant vi lui même, bien que je le connaisse peu, il me semble qu'il est aussi versatile qu'Emacs et qu'il peut permettre de faire à peu près tout.

vi est un simple éditeur de texte. A ma connaissance, il ne se programme pas, ne peux servir de frontal à gdb ou autres logiciels. vim en revanche, le peux probablement. En revanche, tout logiciel qui sait interagir avec des fichiers et un tty peut l'intégrer aisément (probablement la même pour emacs, mais j'ai l'impression que le paradigme d'emacs est plutôt l'inverse).

si on compare l'installation de base des deux, je pense qu'il ne doit pas y avoir beaucoup d'écart en terme de perf ou de conso de ressources.

Vi est, entres autres, fournis par busybox. Le build de debian hors installateur l'inclue. Je doute que emacs soit, même de loin, un candidat pour intégration busybox.

Enfin, a propos du fait que tu serais démuni sans ta conf d'Emacs : en même temps, c'est ça qui fait la force d'un outil adapté à ton usage et à tes besoins.

+1

Dans ton cas, je partirais sur un parc de systèmes diskless, sauf pour le prof.

L'avantage, c'est que tu peux close les sessions à l'extinction des machines (hors débranchement, forcément), pas de risque de laisser des traces, des systèmes tout frais à chaque fois… par contre, faut que les élèves sauvent leurs travaux. Aussi, ça implique que les machines aient une alim fiable, sinon, ben, perte de travail aussi.
On peut aussi coller du diskless en sauvegardant le $HOME sur un serveur de fichiers, ça évite ces problèmes, mais c'est moins facile a mettre en place.

Un parc diskless, ça implique par contre d'avoir un LAN isolé ou d'avoir la main sur le DHCP maître, pour qu'il autorise BOOTP, et d'avoir un serveur TFTP/NFS pour héberger le système bootable. Autre avantage, c'est que si les élèves collent des virus sur leurs machines, via usb ou autres, ben, ça sera juste en ram, donc ça affectera qu'eux.

Je peux t'aider a déployer ça si t'as plus d'infos sur la config réseau de ta salle.

non, je parle bien de millisecondes, mais on parle du traitement de 800x600 pixels, pas juste de 32 entiers… chaque pixel étant codé sur 32 bits, et dans un format défini par le noyal, qui n'est pas identique au format RGBA de spng entres autres.

Me reste beaucoup a apprendre, et j'admets avoir aimé bosser sur ça: du graphisme low-level, c'est fun, surtout quand il faut coder une lib a destination de dev débutants, que libinput dépends du temps pour choper toutes les inputs et que, pour éviter les emmerdes, j'ai choisi d'interdire l'usage de multi-thread (multi-process avec comm par socket, c'est plus simple a debug, et de toute façon les threads seraient permanents…). Du coup, j'ai passé un peu de temps a optimiser.

À noter que j'ai réduit le temps moyen a 5ms, rotation incluse, avec des changements d'archi logicielle qui rendent l'usage de memcpy possible, donc, pour en revenir au comm précédent, probablement facilitent l'usage d'instructions dédiées par le compilo, sans pour autant attaquer moi-même l'ASM. J'en serai presque fier, s'il ne restait pas tant a améliorer…

C'est ce que je pense, oui, j'ai d'ailleurs déroulé la boucle manuellement après un peu de lecture sur SIMD. Je pourrais ptet encore booster en exploitant les flottants dans l'incrément, histoire de parraléliser calculs sur float et calculs sur entiers, mais bon, le plus gros des dégâts viens maintenant des cache miss a mon avis, vu que je fait une translation d'axes x/y sur 800*600 cases.

Sinon merci pour le respect dont tu fais preuve dans cette discussion, même si tu n'es pas d'accord avec moi (ce qui n'est pas le cas de tout le monde).

C'est normal, je pense. Même si je me log plus trop souvent sur linuxfr (la raison: j'ai l'impression que le contenu deviens plus orienté politique/bienpensance que technique, et j'aime juste la technique, la perf, causer ce cycles CPU, de Kio de ram, bref…)

Je précise : quand je dis "je suis dans le même cas" c pas par rapport au tilling, mais par rapport au fait que je n'aime pas supporter des soft hypers lents. Je préfère un environnement un peu moins joli mais plus léger. (je me suis rendu compte de la confusion de mes propos après coup).

j'avais compris.

Un jour lointain, je publierais un journal pour faire la pub d'une distro release-based orientée clavier & hackers. J'y travaille (sur la distro), mais les powerusers, c'est exigeant, donc attends pas et bidouille de ton côté. Pour la perf, un des pré-requis, c'est que le core tournera sur la plus vieille machine que j'ai a dispo: un 586 avec moins de 200Mio de ram. J'y fais déjà tourner debian, donc c'est facile, mais Debian c'est pas axé hacker pour moi, déjà que le côté poweruser a pris une sacrée claque…

s’attaquer à la pénurie de compétences avancées sur les bases de données

Pardon, mais, p'tet que le problème vient du fait que la doc est contre-intuitive? Chose qui sera jamais corrigée par des rencontres au sommet…

Désolé si je suis amer, mais je me tape (connotation négative volontaire) des systèmes "embarqués" (beaglebone black, 512Mio de ram, ça va, les ressources sont larges) sous debian, dont les softs utilisent mysql… pardon, mariadb.
Vu que "peu" de ram, systèmes sur mmc, distants (plusieurs 100aines de km, on peut pas y aller en un jour), et proprio (mea culpa) j'ai essayé de désactiver l'overcommit.

Soit. Sous linux, pas de souci, ça se fait en 1 ligne de conf. Par contre, ben, mariadb démarrait plus: pour une DB utilisée par 3 processus, il lui faut 10 threads/process, chacun bouffant sa dose de MébiOctets de RAM… bien trop pour l'usage.
Lecture de manpage. Modif de fichiers de conf. Essai… rien ne change. Réduire le nombre de threads ou la taille des caches ne fait RIEN, contrairement a ce que promets la manpage…

Alors, je sais, c'est pas fait pour l'embarqué, mais je dois faire avec, jusqu'a ce qu'on migre vers ce bon vieux sqlite, mais quand même, pourquoi qu'elle semble mentir, la doc? Pourquoi que c'est si dur de trouver des infos? Pourquoi qu'embarquer ce machin dans du proprio (désolé, vraiment, j'aimerai pouvoir release le code en libre, ma boîte y gagnerais même en qualité de code, parce que la, quand je lis le code, je pleure) embarqué, c'est pas possible?

Avant de s'attaquer aux problèmes avancés, attaquer la base serait p'tet pas mal.
Merci de votre lecture, vous pouvez moinsser maintenant :)

J'ai lu en diagonale le journal avant sa promotion. Je ne m'y suis pas attardé parce que 1) j'étais au taf 2) je n'y connais pas grand chose et 3) je l'ai bookmarké, pour quand j'aurai le temps.

Les FPGAs, j'ai découvert leur existence sur linuxfr, dans mon esprit, c'est mêlé avec des termes du genre verilog, VHDL, eux-mêmes étant liés (toujours dans mon esprit) à "plus bas niveau que l'assembleur".

Bref, me suis bookmarké ton journal parce que je pense qu'il me permettra d'augmenter ma compréhension de l'informatique de manière générale, et je pense que c'est un but qui est quand même vachement proche de ce que je suppose être un des objectifs du libre. Après tout, une des libertés est bien celle d'étudier, avec selon moi une connotation d'apprendre, de partager la connaissance.

Du coup, je pense que ton journal est plus qu'éligible au "rang" de dépêche, même si tu parles d'un hello world.
Accessoirement, c'est juste super cool de faire un hello world de ce style!

PS: bon courage pour la suite et meilleurs voeux de réussite.

Pas s'il fait du DHCP simple….

De nos jours, les noms des interfaces réseau sont "prévisible", générées à partir d'inforamtions techniques. Du coup, le fichier /etc/network/interfaces doit être patché. Les fichiers /etc/hosts (pour associer le hostname à 127.0.1.1 qui est utilisé par sudo) et /etc/hostname (le nom de la machine) également.
Encore que, pour le fichier interfaces, si un gestionnaire réseau graphique est utilisé, c'est inutile, puisqu'ils remplacent le fichier interfaces me semble.

Enfin, je dirais que si:

• les machines ne disposent que d'une seule interface réseau filaire;
• les machines disposent d'au moins un disque SATA;
• avoir un hostname généré n'est pas gênant;

alors y'a moyen de scripter ça vite fait mal fait (code pas testé donc a vérifier et corriger sur machine non nécessaire avant usage):

test -e /var/firstboost.sh && . /var/firstboost.sh

NEW_IFACE=$(ip -o link | grep -v '\<lo\>' | cut -f2 -d:)
OLD_IFACE=$(grep inet /etc/network/interfaces|tail -n1 | cut -f2 -d' ')
sed -i "s/\\<$OLD_IFACE\\>/$NEW_IFACE/g" /etc/network/interfaces
NEW_HOST=$(printf "%s-%s\n" $(hostname) $(udevadm info --query=all --name=sda | awk -F'=' '/ID_SERIAL=/{n=split(tolower($2),array,"_"); print array[n]}'))
OLD_HOST=$(hostname)
echo $NEW_HOST > /etc/hostname
hostname $NEW_HOST
sed -i "s/\\<$OLD_HOST\\>/NEW_HOST/g" /etc/hosts
rm /var/firstboot.sh

En gros, ce script altère les fichiers hosts, hostname et interface pour remplacer le nom de l'interface réseau Éthernet filaire (dans mon cas enpXsY, YMMV) et les noms de la machine par le nom de la dernière interface interface réseau trouvée sur la nouvelle machine (si n'y en a pas, ça pète!) et un nom composé de celui du modèle ainsi que du numéro de série du disque dur sda (idem, s'il n'y en a pas, ça pète, cas qui se présenteras notamment sur des beaglebone black qui n'ont pas de carte mémoire, leurs "disques" internes étant notés "mmcblkX").

Encore une fois, lire, comprendre et tester sur machine pas critique: certaines données sur lesquelles je me suis basé peuvent varier en fonction des logiciels systèmes utilisés ou du hardware!

Pardone la poche que je suis, mais, tel que je lis, il dit juste:

On a une nouvelle techno qui ne garanti rien mais permets à l'utilisateur de faire de la merde et d'installer des virus vu que le bin n'est jamais vérifié.

MAIS LE PUTAIN DE BON POINT QUI ÉCRASE TOUT MAUVAIS SYMPTOME, C'EST QUE LE TRUC EST A JOUR… j'ai mis assez de caps lock la? J'ai un doute….

Pardon, j'ai répondu qu'a une partie.

Le reste sera pas mieux, mais, tu m'as répondu, c'est de mon devoir de faire de meme.

Les distributions en général doivent donc corriger ces écarts de compatibilités évidentes et corriger les problèmes que cela implique aussi.

C'est une des limites du modèle traditionnelle d'une distribution, qui est très gourmande aussi en travail humain pas forcément passionnant.

C'est aussi ce qui fait leur robustesse.
Il est vrai que le travail manuel est énorme, mais c'est justement a mes yeux une des raisons majeures de confiance. Que l'on est en droit d'accorder a du privé, mais je préfère croire des passionnés. En vrai, ces gens m'ont permis d'apprendre a me méfier d'eux, au point de lire le code C de presque tout.

Pour faire ça, il faut sélectionner des logiciels simples a lire, et connaître son OS. Je sais sélectionnner, mais je maitrise encore mal mon OS, c'est pour ça que j'aime mon job: je peux galoper après des cerveaux si précis, avec un recul en plus, que, jamais je pourrais les rejoindre: soit je reste derrière, soit je les dépasserai. Si j'arrive a grimper leurs épaules.

Je suis d'accord, même bien bourré…. en soit, une distro devrais pas être l'autorité absolue. Chaque user devrais pouvoir installer un soft.

Enfin, s'il est permis par le ldap. Et quelle distro intègrre ça? Aucune. Windows le fait depuis au moins 10 ans, sorry. Je veux faire une distro pour ça, mais, c'est un bordel de fou, il me faudra au moins 2 voire 3 mois pour piger comment ça marche, les bases!

A la base, j'avais estimé a 2 semaines, mes chevillles sont encore un peu enflées, on dirait

Et relis Platon :)

ben, pour le coup, source? Histoire qu'on puisse apprendre, quoi :) ou au moins faire semblant :p

Bah, vraiment, j'apprécierais toujours tes interventions, même sans être toujours en accord (plus souvent sur la forme que le fond), elles me font toujours cogiter.

Et qu'on aime ou pas, mais traiter de con des gens qui appliquent des règles pas unanimement conspuées, et utilisées par d'autres, n'est pas objectif.

Du coup, une règle unanimement conspuée est toujours vraie, comme celle qui disait que la terre est ronde? Pardon, tu ne parlais pas de véracité, mais de connerie… ceci étant dit… hum.

Perso, un règle qu'on doit apprendre par coeur et accepter, c'est une preuve de connerie. Le contraire de la connerie, c'est de comprendre les règles, leur pourquoi et leur comment.
Donc, pour moi, nous sommes tous cons, et toutes connes, et pour les non binaires, je sais pas comment le dire.
Je crois qu'il est important de se souvenir que l'on est incapables de tout comprendre, y compris les "génies". Le trip open source pour moi, c'est vraiment "tiens, telle idée je la trouve pas optimale pour telle situation, pourquoi ne pas tenter cette autre?" et laisser les autres bâtir sur cette autre idée si elle est vraiment meilleure. Sinon, ben, elle pourrit, et c'est pas plus mal

En même temps, le net est vu comme un endroit ou l'on peut s'exprimer librement.
Les gens qui connaissent ses limites (je n'en fais pas partie) sont des élites, des pointures, cette science est pas accessible au geek moyen, alors, le lambda…

si tu le regrettes, aides nous.

Tu noteras que tu as un score particulièrement élevé sur ce post, et je pense qu'il est justifié. Par chance, je n'utilise plus le système de vote que pour des contenus excteptionnellement bons ou nuls, du coup je n'ai pas besoin d'annuler des votes.

Pour en venir au fait, je voudrais savoir comment tu reformulerais le journal. Parce que bon, nombre d'entre nous sommes décents voire plus en terme d'info, mais en terme de politiquement correct, j'en doute, et avoir quelques exemples en opposition a d'autres nous permettrait de nous améliorer, pour ceux qui le souhaitent.

Le risque de tomber dans la manipulation étant, bien sûr, présent. Mais, bah, je sais pas, en fait, juste, je voudrais voir comment tu aurais écris ça. Vraiment.

Je serais preneur d'un retour, perso. Voila un sujet qui mériterais un journal, voire serait une dépêche bien plus intéressante que la moyenne (je trouve les journaux souvent plus intéressants que les dépêches, en vrai, pardon pour la critique négative sans arguments)

le traité empirique est nettement plus compliqué que ce que moi je fais pour construire un deb…

Je commence a croire que c'est le manque de doc sur le format binaire qui est le problème de debian.

Je cite, et vous m'excuserez des fautes, je suis hors d'état de conduire, et je ne devrais pas poster sur l'autoroute de l'information… mais je compte sur votre magnanimité, donc:

Il nous faut créer quatre fichiers :

debian/compat
debian/changelog
debian/control
debian/rules

c'est pas une citation exacte, j'ai viré la poncutaition et divers mots de jonction.
Bref, seul control est vital. Je connaissais même pas l'existance de compat, en vrai. On se fait une dépêche en mode coop sur comment faire un deb proprio/freestyle propre, un jour? Je pense que ça permettrait d'aider a perdre cette réput injustifiée du format deb…

Le changelog, c'est d'un pénible a maintenir… on sent que debian est née avant les DVCS, mais, pour être honnête, je ne connais aucun outil capable de gérer C ou C++ qui sache compiler en prenanant en compte facilement le versionning a base de hash. Dur sujet, faut dire. Mais même les tags sont absents… et un admin noob comme moi a pu pondre un script (de merde, je tenterais unjour de faire mieux, et de le publier d'abord sur le temps libre, puis de l'utiliser au taf, en ayant soin dans ce cas d'utiliser GPL) qui peut récup les tag+commit hash d'un dépôt pour générer un numéro de version.
Le changelog, en soit, c'est plus dur, y'a une notion de politique: est-ce destiné a l'utilisateur, ou a l'admin, ou au contributeur? Pas facile.

Le dernier fichier à rédiger est debian/rules

Je croyais que ça devait pas générer un deb source? Ce truc est useless dans le cas d'un deb binaire.
Le ficher rules, c'est en gros un makefile de ce que j'ai compris (confirmé par la 1ère ligne, en fait).

purée, c'est ça, la ceinture blanche? J'ai pas un tiers des connaissances requises, et pourtant, promis, je peux te générer un .deb a partir d'un binaire proprio en moins de de 15 minutes…

Je crois que la complexité, ça s'acquiert quand on cherche a faire du propre, du bien intégré et universel.
Ce qu'on repproche a debian, justement, c'est de vouloir faire trop universel, et le pire c'est que ça marche pas: Debian reste, malgré les efforts (qu'il faut saluer) une distro GNU/linux. Les ports BSD ou non-GNU officiels semblent a l'état de bêta-test, et je suis gentil.

Merci d'arrêter de balancer des rocquettes dans les pattes de cette distro. A la base, c'est censé être une distro geek friendly, pas user-friendly, et il reste des traces, très claires: je peux installer un paquet avec juste du shell unix, et je peux installer un système en mode archlinux, la stabilité en plus.

J'ai parfois l'impression que les "nouveaux geeks" se contentent de lire 1 seul tutoriel, et se proclament maîtres de la techno en question, en ignorant tout de l'histoire et du fonctionnement interne…. le pire, c'est que ces gens semblent se croire aptes a critiquer des choses que peu d'entre nous seraient capables de recreer, même avec l'exemple sous le nez! Ou alors, je suis totalement idiot…. ça me choquerais pas, d'ailleurs, en soit.

Je pense que tu mets le doigt exactement ou est le problème: la maintenance.

Les distros stable type debian, doivent patcher les softs pour qu'ils soient compatibles entre eux et donc mériter la réputation de stabilité. La volonté de fourguer le dernier soft tout frais, ben, c'est pas compatible.

D'un côté, on veux un système a jour, a la pointe, et d'un autre on veut un système stable. C'est pas possible. Il faut des compromis, et je pense que le fait de pouvoir installer un soft pour un user est pas mal. C'est ce que proposent ces formats, mais du coup, je pense qu'en effet ils repartent en arrière en ignorant totalement la notion de système. Bon, j'ai un peu peu bu, je peux pas argumenter correctement, je peux vous laisser construire sur cette notion de format compromis (dans le sens "entre deux extrêmes" pas dans le sens "troué").
Perso, je pense qu'il serait plus efficace de recoder les outils type dpkg pour qu'ils soient utilisables sans etre root. Ca implique de retravailler l'archi systeme, de manièere autrement plus utile que merger /usr et / pour les bin & /sbin (qui en auraient pu être fusionnés avant en plus, m'enfin).

En tout cas, a la vôtre. et pardon pour les fautes de français. Le reste des fautes, je dirais ça a tête repôsés

Lampiris, pour ne pas le nommer — je te/vous laisse deviner dans quel pays j'habite

Je dirais que tu habites dans le "contre-attaque". Comment ça, j'ai faux?

tu as perdu la main…

Faut reconnaître que c'est dommage de la perdre avec un système de paquet nommé fapfap flatpack.

Je suis déjà dehors :)

En fait c'est tellement compliqué de faire un package pour Debian (ya tjs pas de PPA :-) qui soit dans la distro, et je ne parle pas des 6 mois pour être Debian Developer.

Je comprends que la majorité de fasse plus de paquets, mais des images Docker.

Pas moi, si ton objectif est juste d'installer ton blob sur une bécane.

Si tu veux être un paquet Debian officiel, il faut suivre une tétrachiée de règles, un format fixe qui garantit tout plein de truc, et… mais en fait, on s'en fout.

Le but d'un dev, c'est de distribuer son application. Pour la distribuer sur Debian, le plus simple, c'est de filer un paquet Debian binaire, proprio-style, pas un paquet source qui permets… euh… de se prendre la tête?

Et un paquet binaire de Debian, ça se construit hyper facilement, promis. Allez, j'explique, s'pas bien long après tout:

Il faut lancer la commande dpkg-deb -b $TARGET, $TARGET étant une arbo constituée, de mémoire, ainsi:

• DEBIAN/control: fichier qui permets d'avoir le nom du paquet, sa version, ses descriptions courtes/longues, la homepage, etc… dans un format que même un enfant de 10 pourrait comprendre. C'est le seul fichier obligatoire;
• DEBIAN/md5sums contiens les somme de contrôle md5 (on peut aussi utiliser SHA512 je pense). C'est basiquement la sortie de md5sums avec quelques arguments…
• DEBIAN/post-inst (en gros) script lancé après chaque dépaquetage
• DEBIAN/pre-inst (en gros) script lancé avant chaque dépaquetage
• DEBIAN/post-rm (en gros) script lancé après chaque suppréssion
• DEBIAN/pre-rm (en gros) script lancé avant chaque suppréssion
• une arbo qui indique la ou iront les fichiers. En fait, la partie du système concernée par le paquet

Vraiment, pourquoi viser l'officiel? C'est le job des mainteneurs, les paquets source Debian ont des patchs justement pour ça: l'intégrer aux changements systèmes de Debian.
Rien n'empêcherait de faire un paquet avec un binaire lié statiquement qui s'installe dans /usr/local ou /opt…

AppImage ne fournit aucune sécurité, et n'est a ma connaissance pas géré par dépôts, juste l'utilisateur télécharge le fichier d'origine, le chmod, et l'exécute.
Les autres semblent essayer de fournir des sécurités.

J'ai lu plusieurs fois sur linuxfr que les autres ont aussi l'avantage du téléchargement incrémental, contrairement a appimage, mais les auteurs de ces commentaires n'ont jamais du essayer d'utiliser l'appimage de redeclipse2, sinon ils sauraient que c'est faux.

Pour le reste, je n'en sais pas pas plus, je n'ai jamais testé fapfap/snap (désolé, pas pu résister), et jamais analysé un binaire AppImage, donc…

Est-ce une réaction de réactionnaire de chercher a tendre vers un système que l'on est capable de dépanner, de maintenir, de modifier soi-même?

Parce qu'une des raisons qui font que je n'ai pas encore étudié systemd en détails, justement, c'est que je le trouve complexe, alors que j'ai l'impression (est-elle justifiée? C'est pas sûr) de pouvoir faire la même chose avec des outils plus simples, dont je suis même capable de comprendre le source (j'ai encore lu le source de sv aujourd'hui, me suis d'ailleurs demandé si c'était du C K&R…) chose utile quand un comportement n'est pas ou est mal documenté (un logiciel trop documenté s'expose au problème qu'il faut lire trop de trucs pour le juste mettre en place, l'équilibre n'est pas simple).

J'ai parlé de systemd ici, mais la même chose peut s'appliquer a bien des technologies, et il est possible que ces nouveaux systèmes de paquets y aient leur place.

J'ai aussi parlé de tendre vers, parce que je suis conscient que ce n'est pas possible de comprendre la totalité de son système (le kernel linux m'est obscur, et même si je comprenait 100% des binaires de mon système, il resterait les firmwares, le code verilog/whatever qui programme un CPU s'il est en fait un FPGA, puis l'électronique… bref).