barmic a écrit 927 commentaires

Je ne suis plus très près l'actu Debian, mais c'était aussi un problème de sécurité. Les mises à jour de sécurité vont moins vite dans testing qu'ailleurs.

Alors google a besoin de flash. Le player est bien fait, mais la doc n'est pas folle (il est question de "dnf" qui est gestionnaire de paquet dont je n'ai jamais entendu parler par exemple).

Quand on écrit, on choisit soigneusement des idées, des mots.

T'expliquera ça à Jul :p

(c'est gratuit juste pour la vanne ^^)

Le stockage sur disque implique déjà l'usage de CRC à très bas niveau (hardware et juste au dessus). Étant donné que les fonction de hachage comme MD5, SHA1, etc. sont de taille fixe et sont faites pour être faciles à calculer, c'est quelque chose que l'on pourrait envisager d'intégrer dans les inodes et que l'on récupérerait ensuite avec stat().

Tu peux mettre ça dans les xattr.

Mais les fs qui font ça vont plus loin. Ils prennent pas en compte le fichier mais les chucks de fichiers et ils font du COW pour que si tu modifie le chuck, il l'écrit dans un nouvel espace et pointe vers ce nouvel espace. Tu n'a donc pas le soucis que tu as en utilisant des hards links.

Donc, on prend du TCP qui est full-duplex et à une connexion établie, pour construire un protocole déconnecté et half-duplex, sur lequel on construit un protocol full-duplex connecté?

Non on switch le protocole. websocket n'est pas au dessus de HTTP, il en fait parti.

La seule chose qui fait que le polling soit exposé aux développeurs utilisant TCP, àmha, c'est qu'il n'existe pas de lib standardisée.

Pas compris.

Il n'y a pour moi pas besoin d'aller pondre une surcouche à HTTP qui contourne les limitations du protocole pour lui faire faire ce pour quoi il n'est pas conçu (Hyper Text Transfert Protocol, c'est clair pour moi, c'est pas conçu pour établir un flux continu.

Il ne s'agit pas d'une surcouche, mais d'une extension comme il est prévu de l'étendre. De plus c'est l'organisme qui a standardisé HTTP qui a crée websocket, tu sais mieux qu'eux ce pourquoi HTTP est fait ou pas ? Note que HTTP2, de base, permet des communications dans les 2 sens avec le push server.

quelqu’un qui ne connaîtrait ni le shell ni le Python (mais connaissant au moins un autre langage), il va mettre beaucoup moins de temps à appréhender le script Python que ton script ta boucle en shell…

Quand tu décide d'outiller autour d'une commande, il y a un probabilité non nul que tu ai déjà utilisé cette commande dans ton shell, que tu ai fais la manip' de défragmentation « à la main » et donc tu as déjà presque tous pour faire le script shell. Il faut ajouter find et cut.

La raison pour éviter le shell autant que possible, c’est bien le temps de déminage et le fait qu’on peut difficilement être sûr qu’on l’a bien terminé.

Aucun langage ne te garantira ne pas avoir de bug…

Bien vu ! Encore un piège du shell…

Ça n'est pas un piège du shell. C'est un piège des options… Si tu lance le programme via un exec de ton langage, tu aura le problème. Tu l'a juste plus souvent en shell parce que tu utilise plus de commande. Je viens de vérifier d'ailleurs avec le script python, tu aura le problème au lancement de filefrag.

Je présume que c'est vraiment très basique, par exemple il n'y a pas besoin de l'opération trim sur les périphériques USB. POur moi le contrôle d'usure consiste surtout à vérifier qu'une puce est encore valable ou pas. Je doute qu'il y ai un algo de répartition à proprement parlé.

Ce mécanisme il fonctionne toujours de la même manière, il est « considéré transparent ». Quand on indique les vitesses d’IO c’est en prenant en compte ce mécanisme, qui est activé par défaut (et pas toujours désactivable peut-être ?).

Le wear levelling est totalement transparent au SE et il est justement là pour rendre moins séquentiel les accès, mais je n'ai jamais entendu parler de clef USB avec un firmware pour faire ça…

Je suis d'accord que le shell a des pièges, mais pour ce genre de choses je préfère un script que je suis capable de relire très facilement (moins de lignes, seulement des opérations simples) qu'un script plus long dans un langage réputé plus sûr mais que je ne relirais pas par TL;DR.

Mais ça n'est que mon avis de personne qui ne partage pas grand chose, hein !

Au passage, ta regexp est incorrecte, c'est extent quand il y en a 1 et extents quand il y en a plusieurs :)

J'ai pas de fichiers fragmentés pour essayer.

Le but était de partager avec tout le monde, donc j'ai pris python pour aider à la relecture.

Je trouve justement que ça rend la relecture bien plus compliquée. C'est la version que j'aurais fais moi et c'est la raison qui fait que je ne partage pas ça. C'est juste un trucs que je fais dans ma shell. Pour te montrer une version shell simple et partageable.

#!/bin/bash

FRAGMENT_LIMIT=5

defragment() {
    cp -- "$1" "$1.tmp" && mv -- "$1.tmp" "$1"
}

nb_fragment() {
    filefrag -- "$1" | cut -d' ' -f2
}

for music in ( $(find "$1" -type f) ) do
    fragment=$(nb_fragment "$music")
    if [[ ${FRAGMENT_LIMIT} -lt $fragment ]] then
        defragment "$music"
    fi
done

Ça décrit bien ce que l'on veut faire :

• comment on défragmente un fichier
• comment on sait combien de fragments composent un fichier
• on cherche tous les fichiers et s'ils ont plus de FRAGMENT_LIMIT fragments on les défragmente

On peut ajouter quelques infos mais la base est très lisible sans avoir à gérer de fonction récursive, de sous process (bien sûr c'est juste que c'est transparent), ni même d'expression régulière. Il y a une subtilité dans ma version, l'utilisation du -- pour ne pas avoir de problème dans les cas où tu as un fichier qui commence par "-".

Oula ! Non il n'est pas du tout question de censurer ou autre !

Un gars qui fait quelque chose a bien plus de valeur que celui qui commente sans rien faire !

Voila pour le plus important : écrivez du code comme vous le voulais !!!

Je ne trouve pas si surprenant que ça de réaliser une opération dans un langage qu'on maitrise (sans qu'il soit nécessairement le plus adapté) plutôt que de se former et de produire un code bancal dans un langage qu'on ne maitrise pas. Au niveau individuel, c'est assez rationnel.

En fait quand tu as vu le fonctionnement de ton outil (filefrag ici) tu as déjà fait 80% du boulot. En fait tu le fait une fois en ligne de commande (pour voir comment ça fonctionne), tu copie le tout dans un fichier, tu met une variable et tu as déjà un script sympa. Ensuite golfer c'est pour les accros qui veulent faire une pause au travail. J'ai l'impression que le fait d'utiliser python ne vient pas du "c'est ce que je sais faire", mais d'un "si je veux faire propre c'est pas le shell qu'il faut utiliser". Je trouve ça dommage parce que ça ajoute de la complexité.

Je crois avoir déjà lu que même si l'impact est faible il y en a un. Grosso modo (du vague souvenir que j'en ai) pouvoir demander des blocs les plus gros possibles rend plus simple la lecture et plus performante. Mais c'est très loin de ce que demande un déplacement d'une tête de lecture. Tu retrouve même comportement pour la mémoire vive et l'utilisation des huge pages.

Je suis toujours surpris de voir ce genre de choses faites en python quand le shell est plus simple :

for fragmented ( $(find . -type f -exec filefrag \{\} \+ | awk -F: '!/ [1-5] extent found$/{print $1}') ) do 
    cp "$fragmented" "${fragmented}.tmp" && mv "${fragmented}.tmp" "$fragmented"
    filefrag "$fragmented" | awk -F: '!/ [1-5] extent found$/{print $1}'
done

Ça économise pas le mv, mais pour le coût que ça a je pense que c'est acceptable.

Hypothèse: il impossible de rémunérer certains produits à leur juste valeur, la somme des heures de travail derrière Firefox et toutes ses dépendances doit être monstrueuse.

Conclusion : Il ne faut pas essayer de rémunérer ses produits du tout.

---

Ça me gêne la société du gratuit dans le quel on vit. Soit on considère véritablement un modèle sociétal où, à base de troc ou autre et ok tout est gratuit (attention spoil on ne vit pas dans ce mode de société). Soit on n'est pas dans ce mode de vie et il faut rétribuer les gens qui produisent des choses.

Ça me gêne énormément de voir des gens expliquer : « ce que tu as créé, tu dois me le donner gratuitement parce que tu comprends c'est un principe ». Autant pour le logiciel que pour la création artistique par exemple (sujet sur le quel ça a beaucoup était dit).

Au principe de partage que ces gens défendent, j'opposerais un principe permettant à ceux qui produisent d'avoir une rétribution. Même RMS est d'accord avec ça. Je l'ai vu en conférence expliquer qu'il manque un moyen vraiment simple pour rétribuer les gens (il décrivait quelque chose qui ressemble à flattr, patreon ou tipeee).

Les gestionnaires de fenêtres qui maintiennent des sessions sont totalement bloated

À ce niveau, mon problème principal, c'est que je ne sais pas définir précisément ce qu'est une session. Sérieusement. Je suis au courant des problèmes d'i3, ou du moins de certains. Par exemple, il est très difficile et très aléatoire de répartir comme on le veut un groupe d'applications dans un workspace.
Je me plante peut-être, mais, pour moi, ce point particulier est lié au fait qu'i3 ne permette pas d'«opérations atomiques». Évidemment, c'est facile à dire, mais pas à faire.
Ce qui ne m'empêchera pas de penser (et, espérons-le, un jour d'agir?) que le gestionnaire de session et le gestionnaire de fenêtres sont aussi des choses distinctes.

Awesome est plus sympa pour faire ce genre de chose. C'est un wm "automatique". Tu peux configurer des choses de manière totalement automatique. Mais c'est largement plus complexe à utiliser que ce que propose Firefox.

Pour être franc, je pense que je manque de recul sur la réflexion qu'il doit y avoir encore gestionnaire de session, gestionnaire de fenêtre, décorateur de fenêtre (pour le coup, i3 (que j'utilise au quotidien) est un bloatware: il fait wm, décorateur, et gère en partie les sessions puisqu'il colle toujours une status bar avec des info obligatoires… entres autres, mais c'est le plus proche de mon équilibre perso)…

Je ne sais pas découper peut réduire la cohérence et rendre les choses plus compliquée à faire.

Hum hum… Tu as des cas un peu répandu où tu va nous donner un lien d'un rapport de bug plus ou moins obscure ?

C'est vrai, je n'ai aucun bug report ni report à citer
Mais, que se passe-t-il si un thread plante? Sur ce point de la discussion, j'ai tout à gagner: soit je me plante, et j'apprend comment une application récupère d'un crash de thread (big win), soit je gagne un échange sur dlfp (peu probable) qui fera réfléchir avant d'utiliser du multi-thread (encore pire).

Ça dépend de ce que tu fais et de la technologie que tu utilise. Java et .Net ont des pool de threads qui sont gérés chacun son tour. Pour Firefox je présume qu'il ne fait que de l'interprétation (du DOM HTML, du JS, des images,…). Il n'est pas si compliqué de gérer les erreurs d'un méta-langage dans un langage (modulo certaine erreurs de sécurité) et on peut utiliser des tests de fuzzing pour vérifier avec des données aléatoires.

D'un autre côté, il est simple de protéger une IPC contre un crash des interlocuteurs, et au niveau code, c'est quasi trivial de savoir qui bug, alors que du multi-thread… c'est pénible à lire, pénible à debug, pénible à maintenir.

C'est pour cela que Rust existe (pour de bon, c'est vraiment pour ça qu'ils l'ont créé). Ce qui fait choisir entre des threads et des processus, ça va souvent être le rapport entre la puisance de calcul nécessaire et les besoins de communication.

Le multi-processus consomme beaucoup plus de ressource.

C'est un fait. Relativement à un thread, il faut sauvegarder beaucoup plus d'informations. D'un autre côté, c'est de toute façon fait par le kernel, vu que de toute façon les processus résident quelque part?
Cela dit, sur nos systèmes de bureautique, cette consommation de ressources supplémentaires est-elle significative? On parle de quelques kibi octets, la on l'on dispose de plusieurs de gibi octets. À moins que tu ne parles de performances CPU? Dans ce cas, le problème vient-il des erreurs de cache? De cycles gâchés?

Si le noyau ne fait du COW sur les pages mémoire, il reste une quantité de données que tu va devoir recopier entre tes fils d'execution. Tu prend le DOM, tu construit un arbre que tu va pouvoir manipuler pour fournir l'API DOM, mais ausi pour pouvoir faire une navigation CSS et tout ce qui est interne.

Si tu utilise des processus, il va falloir serialiser toute cette structure (qui n'est pas petite) pour la deserialisée de l'autre coté.

Il faut se rendre compte que l'objectif de quantum n'est pas d'avoir un thread par onglet, mais d'en avoir plusieurs ce qui augmente encore les besoins de communication.

Je t'avoue, moi, je ne sais pas, à quel point un multi-thread est plus lent, sur un système moderne, qu'un mécanisme d'IPC, comparé au temps d'exécution total.
Cela dis, si tu as de la doc, je la dévorerai (enfin, un peu comme pour le vin, seulement si elle est bonne :p).

C'est un bench à faire ça dépend de la granularité que tu souhaite.

ils ont pris une bibliothèque qui fait déjà bien le job

Laquelle? Est-ce vraiment son job, ou son job est-il plutôt de permettre de tisser des relations entres les données, «bêtement»? Est-il possible d'interagir simplement de l'extérieur sur cette BDDR?

~/.mozilla/firefox/<ton profile>/places.sqlite tu peux y accéder avec la commande sqlite (faut la version 3).

Soyons honnêtes: si tu veux faire adopter le panda roux, tu ne mettras quand même pas ça en exergue, si?

Tu ne me verra jamais « faire adopter ». Les gens font bien ce qu'ils veulent de leur machine.

Et perso, j'aurai tendance à considérer ce genre d'outils comme des plug-ins, vu qu'ils ne concernent réellement qu'un très faible nombre d'utilisateurs, alors que d'autres sont utilisés en masse et sont des plug-ins, justement.

Ça l'était.

Tu entends quoi par « pas fait pour » ? C'est des usages décrit par des différents standards tous très largement reconnus. Les serveurs sont développé avec ces usages en tête et les client aussi. Donc qu'est-ce qui n'est pas fait pour quoi ? Le fait que ça n'a pas était imaginé à la base ne l'empêche pas d'évoluer. Tu as vu la sécurité sur SMTP ou sur FTP, je trouve que HTTP et le web s'en sort pas si mal.

Dis-moi, c'est quoi, les websockets?

Un standard IETF pour le protocole, W3C pour l'API qui permet d'établir une communication bidirection avec HTTP. Au lieu d'avoir juste de requête/réponse, on maintiens la connexion (ce qui est déjà le cas au niveau TCP) et on permet le fullduplexe. Mais il n'est pas seul, tu as les server side event qui sont arrivés avec HTML5 (donc W3C) et l'IETF avec HTTP2 a créé le concept de server push.

Tout ces trucs là cherchent à remplacer des techniques comme le (long) polling. Quand il y a une pratique aussi répandu et autant de gens qui cherchent à y répondre c'est qu'il y a un besoin réel AMHA.

Par chance, tu n'émets aucun jugement sur ce point.

Tu fais bien de parler de jugement vu la suite de ton commentaire…

Pour les onglets, en fait, c'était une erreur. Ça permets d'utiliser le multi-thread et de contourner les gestionnaires de fenêtres pourris? Certes.

… parce que c'est tout de même bien tranché tu ne trouve pas ? Ça fait beaucoup de gens qui se trompent, ils doivent pas trop savoir ce qu'ils veulent je présume, c'est ça ?

Personnellement, ça fait 10-15 ans que j'utilise des gestionnaires de fenêtres très pointus (wmii, awesom, xmonad, i3 et un petit passage par celui de suckless) et je ne tiens pas à laisser ça à mon gestionnaire de fenêtres. Les gestionnaires de fenêtres qui maintiennent des sessions sont totalement bloated et il est très difficile de gérer leurs sessions. Hors c'est ce qui est intéressant avec ce mécanisme d'onglets, les sessions. Je ne connais aucun wm qui sache gérer des minisession en leur sein (pour ne pas tout garder mais que quelques clients… C'est simple une fonctionnalité existante est mieux qu'une fonctionnalité théorique. Tu peux tenter de m'expliquer comment m'en passer, mais ça ne rendra pas cette fonctionnalité plus existante.

Ben, ça devrais pas être le problème du brouteur, selon moi.

Effectivement c'est selon toi donc pas la peine de commencer en étant aussi tranché :)

Mais en fait, le multi-thread pour les onglets, c'est pas cool, ça propage les emmerdes. Les wm pourris?

Hum hum… Tu as des cas un peu répandu où tu va nous donner un lien d'un rapport de bug plus ou moins obscure ? Le multi-processus consomme beaucoup plus de ressource.

C'est quoi, un favori? Un lien stocké sur le disque dur? Comment te dire…. je doute que le fait que le brouteur le gère via un SGBDR (parce que, oui, la plupart le font via des SGBDR à vue de ldd) soit super portable|performant|efficace.

:) Pour le cas de Firefox. Il gère ça de la même façon que l'historique et oui il veut des propriétés ACID. Ils auraient pu réinventer quelque chose c'est vrai, à la place ils ont pris une bibliothèque qui fait déjà bien le job, qui est libre et qui est largement utilisé. Tu trouve ça vraiment bête comme idée ? Quant à la performance, il me fait des propositions sans que je ne ressente le moindre ralentissement, à aucun moment.

des outils de développement

Ce qui est totalement inutile pour 95% de leurs utilisateurs. Minimum.

Mettre à disposition des gens de quoi devenir acteur du web et comprendre/maitriser ce qu'ils ont devant eux ne me paraît pas choquant.

Ah, oui! Les plug-ins. Tu veux dire, le mécanisme dont l'API n'arrête manifestement pas de casser chez mozilla, dont on parle?
Oh, merde, je vais trop loin la.

Euh… Alors soit tu parle des plugins (Flash par exemple) et oui ils ont changé une fois d'API pour être interopérable avec celui qui est le plus utilisé (Chrome). Soit tu parle des extensions et oui ils ont changé une fois d'API pour être plus interopérable avec celui qui est le plus utilisé (Chrome).

Que ce soir l'un ou l'autre ils ont pété une fois la compatibilité en 15 ans, c'est ce que tu appel « ne pas arrêter de casser » ?

Oui, ça, c'est balèze. Surtout que le web, plus le temps passe, plus ça fait n'importe quoi au travers de formats et de protocoles pas conçus pour (chiffrement, communications asynchrones, notamment).

Tu entends quoi par « pas fait pour » ? C'est des usages décrit par des différents standards tous très largement reconnus. Les serveurs sont développé avec ces usages en tête et les client aussi. Donc qu'est-ce qui n'est pas fait pour quoi ? Le fait que ça n'a pas était imaginé à la base ne l'empêche pas d'évoluer. Tu as vu la sécurité sur SMTP ou sur FTP, je trouve que HTTP et le web s'en sort pas si mal.

Oui, ça, c'est balèze. Surtout que le web, plus le temps passe, plus ça fait n'importe quoi au travers de formats et de protocoles pas conçus pour (chiffrement, communications asynchrones, notamment).[…]

Pourquoi ne pas utiliser uzbl ou surf ? Ils font juste ce que tu semble attendre d'un navigateur.

Et pour l'interface, la grosse critique et que Mozilla pompe Google, pas l'inverse.

Puisque tu en parle, la prochaine version de Chrome est assez marrante :

source

Je trouve que ça ressemble sacrément à une précédente version de Firefox.

Il a fallu que Google donne un coup de pied au cul de Mozilla sur la perf pour que Mozilla investisse dans un navigateur rapide (en 2018).

Il faut un concurrent pour créer une émulation ? T'es sûr ?

Sérieux, évitez ce genre de blague si vous voulez aider Mozilla, la ça rend les amateur de Firefox comme des plaisantins.

Personnellement je me fou des concours du quel des 2 a la plus grosse d'ailleurs il semble qu'exécuter des scripts de plus de 10Mio aussi vite que possible ne soit plus trop à la mode. Maintenant que tout le monde devrait faire du WebAssembly (à la place des NaCl et autres asm.js) ça n'est plus un argument de vente donc on en parle plus. Comme quoi ça devait être vraiment quelque chose de critique…

Pourquoi ne pas utiliser l'image docker ?

C'est que c'est particulièrement intéressant comme commentaire…

Je serai ravi de porter plainte contre ma banque ou mon assureur. Moi, j'imagine que ma banque et mon assurance respectent la loi sur les données personnels, la déontologie, et les règles en cours dans le milieu. Ils y ont intérêt, d'ailleurs, je les paye pour ça.

Respecter la loi pourquoi pas mais ça n'indique pas qu'il faut faire confiance, ça dit que si on les chope ils encourent des sanctions. Il faut donc surveiller ce genre de pratique. L’expérience montre que le respect des règles ou lois n'est pas toujours une priorité (cf les montages financiers qu'ils créent à la limite de la légalité, le fait de ne pas vérifier l'éligibilité à un prêt, l'histoire avec Kerviel,…)

La déontologie euh… Un Homme peut avoir de la déontologie pour une entreprise c'est beaucoup plus compliqué (mais tu peux mettre les valeurs que tu veux sur ta banque hein).

La règle dans le milieu c'est bien plus drôle. Le milieu c'est les banques en France ? Dans le monde ? Parce que dans le monde les lois ne sont pas toutes aussi protectrices pour toi.

Ce qui me gêne, c'est que ton message ressemble beaucoup à « les banquiers sont méchants, donc il font surement des trucs de méchant. Mais ce n'est que mon avis donc je n'ai pas de preuve à donner. ». Se contenter de poser une question pour induire, malgré l'absence totale de preuve, une idée chez le lecteur est une forme déplorable de manipulation.

Non c'est une façon de dire qu'il faut faire attention car ils ont un intérêt particulier à violer la loi.

Je ne vois pas en quoi ça aide que mon banquier sache que j'achète des sextoys ou du thé aurait un impact sur le taux qu'il me propose. Justement, c'est un problème qu'ils demandent les comptes détaillées pour un emprunt, alors que seules des catégories (revenus, emprunts, dépenses courantes) sur 3 mois (et pas par mois) devraient être fournies par exemple.
Mais les gens s'en foutent, râlent un peu sur Facebook (et encore), donc ça va.

Ils profiles, ils te classent en fonction de tous sur quel niveau de confiance on peut t'attribuer et en plus de l'algo de data mining on ajoute une couche humaine pour dire que si on parle de loi pour expulser tous ceux qui possèdent un sextoy on va peut être pas te faire un prêt à trop long terme. Je dis pas que c'est bien ni légal, je dis que ça m'étonnerait pas qu'ils veuillent le faire.

Facebook qui découvre la maternité de ces utilisatrices ou wallmart qui déduit que les couches et les bières s'achètent ensemble sont de bons exemples qu'avec des informations très abstraites mais en très grand nombre on peut déduire des choses folles.

J’imagine tout de même que le navigateur (enfin Pocket…) va remonter la liste des publicités qui ont été choisies par l’algorithme à partir des données locales. Ne serait-ce que pour proposer aux annonceurs des indicateurs sur la diffusion de leur réclame.

Si c'est le cas (et c'est ce que je viens de lire ici : https://help.getpocket.com/article/1142-firefox-new-tab-recommendations) alors oui il y a fuite de données et ils sont au même niveau que presque n'importe quelle autre régie publicitaire. On peut déduire une quantité folle d'informations via ces données là. Et ça utilise le canal de report des métriques techniques, s'ils ne font pas réaccepter cette nouvelle information aux utilisateurs ça crée un très mauvais précédent pour moi.

Pour le coup du banquier, je ne suis pas d'accord. Lorsqu'il faut te prêter de l'argent savoir de manière profonde la façon dont tu vis leur est utile, de même quand tu es assureur (et les banquiers sont des assureurs maintenant).

Avec les systemes d'init classique, c'était tout simple :

Hé hé !

tu places tes scripts dans /etc/rcx.d et tu t'arranges pour qu'ils traitent les paramètres start, stop, reload, etc …

Bien sûr… Tu as regardé comment le skeleton de Debian par exemple ? Tu espère que le script prennent correctement en compte les paramètres, mais en faite euh… Ben pas forcément… Tu as vu combien de scripts qui ne sont trop dépendant de l'environnement ? (lancé par le mauvais utilisateur, variable d'environnement en trop,…)

Je pense bien connaître le scripting shell et il est vraiment rare que je ne vois un script sans me dire "là on peut le faire péter". Pour faire un bon script shell il faut être très défensif. Donc le shell c'est bien, mais c'est bien de limiter fortement le contexte dans le quel on l'utilise.

Bref je connais suffisamment le shell pour vouloir simplifier au maximum ce qu'on en fait et toujours me méfier des scripts shell.

Et si tu veux savoir comment ça marche, tu lis le code.

C'est insupportable à lire, les distributions font différemment (ma distribution utilise un binaire compilé qui s'appelle "start-stop-daemon".

Et sur ur xBSD c'est encore plus simple.

Non c'est encore différent pas simple. Simple quand tout se passe bien. Valider que tout est fiable est encore une complexité en plus.

Avec systemd, si tu as un problème de démarrage, t'es obligé d'attendre que ta distrib (ou l'upstream) corrige avant de pouvoir démarrer. Avec les scripts init classiques, tu peux corriger de suite et démarrer ton serveur en attendant que les correctifs te soient fournis.

Tu es entrain de nous présenter le scénario de la bombe à retardement version système d'init. Les faits montrent que ça ne semble pas si invivable (Note : quand tu fais quelque chose qui pète ton init quelque soit ton système d'init tu pourra le corriger => je n'ai pas de doute que tu sache faire l'action inverse de ce que tu as fais).

Ça n'a pas de rapport avec ton script que tu « colle dans /etc/init.d ».

(c'est pratique de virer des mots pour détourner le sens d'une phrase :p).

J'ai pris la totalité de ton paragraphe.

Les comportements de « je veux pas savoir comment ça fonctionne soit ça marche, soit je bave sur le logiciel » est relativement nouveau sous linux. Je présume que ça vient de sa popularité, les utilisateurs de niveau plus faibles qui préfèrent se comporter en consommateurs plus qu'en utilisateurs avertis :p (à troll, troll et demi)