freem a écrit 5059 commentaires

Perso, je dirais qu'un dépôt git pour du code LaTeX, avec un hook qui compile à chaque à chaque push le code LaTeX en HTML devrait pouvoir répondre au plus gros des tes problèmes.

La seule chose qu'il te resterait ensuite à faire, c'est de trouver un CMS qui supporte d'avoir les posts en HTML. Je suppose que ce n'est pas trop complexe, mais ce n'est que supposition (jamais cherché).
Enfin, je dis HTML, mais LaTeX supporte peut-être d'autres formats utilisés sur la toile en sortie (un des nombreux formats de wiki, ou des trucs de forums, que sais-je?).

Pour le coup, avec git+LaTeX, en bricolant un hook, tu réponds déjà aux points 1 à 8, c'est à dire tous les points relatifs à la présentation des données. Les autres points, je ne doute pas que la plupart des moteurs de blogs en sont capables. En gros, l'idéal serait que tu cherches un CMS qui supporte une interface shell, histoire de compléter le hook parfaitement.

Cette réponse n'apporte pas grand chose, je sais, je voulais juste dire qu'à mon avis tu cherches trop de choses et que tu peux réduire ta recherche.

Il y a besoin d'être mainteneur pour avoir un avis sur systemd? Tout le monde peut avoir un avis, mainteneur ou non. Et donc, tout le monde peut être pro, anti, ou entre les deux.

Enfin, je suis d'accord que les discours autour de systemd virent souvent à l'extrême.
J'ai arrêté de suivre la ml de debian à cause de ça et de certains débordements (tant des utilisateurs que des modérateurs) que j'ai constatés (et non, je n'irai pas exhumer des preuves, ça fait longtemps que je n'en ai plus rien à foutre).
Par contre, je ne crois pas que seuls les anti mènent les «débats» dans la direction des décharges. Pour ma part, j'ai vu pas mal de débats constructifs être pourri par les deux camps extrêmes, ce qui est dommage, parce que j'ai aussi vu des avis constructifs tant des pro que des antis.

Exact, et c'est assez simple: il suffit d'aller dans la description du paquet, d'aller tout en bas et de prendre la version de son choix.

Sauf qu'en fait, il y à deux problèmes:

1. Une version bugguée peut avoir introduit un bug dans la configuration, qui ne sera pas nécessairement nettoyé (si le fichier à été généré particulièrement) par une downgrade.
2. Les seules versions affichées par aptitude sont les versions actuellement diffusées par les dépôts dans /etc/apt/sources.list(.d). Hors, quand tu fais une MàJ de stable vers stable (correctif de sécurité principalement) l'ancien paquet tombe dans l'oubli. Le seul moyen que je connaisse pour le récupérer, c'est le dossier que j'ai cité dans mon autre post. Et encore, problème: cette archive qu'aptitude construit, tu peux régler aptitude pour "supprimer automatiquement les paquets obsolètes" (ceux qui ne sont plus listés). Si tu fais ça, t'es bon pour aller faire de l'archéologie. Le fait de ne pas pouvoir indiquer combien de versions de backup conserver avec aptitude est l'un de ses inconvénients (mais c'est toujours mieux que les autres outils qui ne proposent même pas ce nettoyage automatique, sachant que quleques MàJ de gros paquets peuvent vite bouffer inutilement plusieurs Go).

99% Compatible virus.

Stats Zenitram, la majorité des gens qui critiquent systemd se défoulent pour le plaisir (ça a l'air de faire du bien) et continue d'utiliser leur distro (avec systemd donc).

Stats Freem, la majorité des gens qui critiquent systemd lui font une critique positive. Ça à l'air de faire du bien :D

T'inquiètes pas, Lennart nous sauvera bien à un moment donné…

Ce que ne comprennent pas les "anti-systemd", c'est qu'en face il n'y a pas de "pro-systemd"

.

des mainteneurs, qui eux […] on trouvé la chose utile

C'est contradictoire, non? Être "pro-whatever", c'est bien être en faveur de whatever? Si on trouve une chose assez utile pour en remplacer une autre, c'est bien que l'on est en faveur de la première, sans obligatoirement considérer que la seconde est absolument mauvaise?

Pour le reste… il n'y a pas que des extrémistes et des aveugles dans la discussion, ce n'est pas parce que l'on n'apprécie pas systemd qu'on le déteste, et j'ose espérer que ce n'est pas parce qu'on l'apprécie que l'on doit jouer les zélotes.

D'abord, il faut rappeler que runit ne suit pas la norme SysVinit. Donc il faut se coltiner l'écriture de scripts en shell pour piloter le démarrage des services, en remplacement de ceux écrits dans /etc/init.d/.

Hum… sysVinit, il ne fait que lancer des services, il ne les gère pas. Il le faut au travers de scripts shell. Alors tout ce qui gère les services, sors forcément de la «norme» sysVinit.
Runit, il lance des services, et il les gère. Au travers de scripts shell.

Le langage shell utilisé est le même pour les deux cas. Du coup, je ne vois pas trop comment runit ferait moins bien que sysVinit?
Je reconnais n'avoir pas essayé, mais, ça ne marche pas de lancer les scripts de /etc/init.d par runit?

Et le coup de la norme sysVinit pas respectée, ça ne prend pas.
Oui, systemd peut lancer des scripts sysVinit (comme runit, j'en suis persuadé), mais il ne respecte pas non plus celle-ci. Donc il faut se «coltiner» (ton terme) l'écriture de fichiers de config avec la syntaxe de systemd .
Maintenant, je trouve que le shell à une syntaxe de merde (et des mots-clé à la con, genre fi et esac, par contre pas de rof ni de elihw? Mots clé à la con, et même pas consistants! Je ne parlerai pas de test, à chaque fois que je m'en sers, je sors le man!), est bourré de chausses-trappes et à pleins d'autres inconvénients (me semble plusieurs de ces inconvénients on causé la naissance de perl, d'ailleurs).
Mais pas obligé de connaître le shell pour écrire des scripts runit, rien n'empêche d'utiliser python par exemple (j'en ai vu un exemple sur github, il y a quelques jours).
D'un autre côté, systemd «impose» un langage, plus simple qu'un langage de programmation. Par contre, il s'agit d'une technologie spécifique, qui ne servira que pour systemd.

Du coup, vraiment, l'argument de la norme en faveur de systemd et contre runit il est pas terrible :)
D'ailleurs, le coup d'utiliser un autre langage pour écrire les scripts d'init, pourquoi ne pas l'avoir utilisé pour sysVinit? Je viens de réaliser que je n'ai pas souvenir d'avoir lu quoique ce soit à ce sujet? Ça aurait sûrement pu simplifier énormément les usines à gaz.

Par contre, je me suis retrouvé avec le problème inverse : il fallait que les services soit lancés en premier plan, sans forker en tâche de fond.

Oui, c'est le problème, le service doit avoir un moyen de ne pas utiliser le double fork. Qui ressemble quand même pas mal à un workaround, pour moi (traditionnel, certes, mais workaround quand même).

Par exemple, je lançais autant que possible les processus avec des utilisateurs différents, pour des raisons de sécurité. Avec Runit, soit il faut activer un mécanisme global de déclaration dans les répertoires des utilisateurs, soit il faut jouer avec su dans les scripts shell des services.

Ou utiliser le programme chpst fourni par runit? Cet outil est vraiment très intéressant, il permets notamment de:

• changer l'utilisateur
• les groupes du processus
• les variables d'environnement (bien apprécié ça, récemment) en définissant un dossier dont chaque fichier/contenu est une variable/valeur
• créer un fichier de verrouillage. Peut-être que ça aurait pu résoudre ton problème de fichier PID manquant? (je viens de l'apprendre, cette option, j'ai ouvert le man par curiosité)

Par contre, je ne sais pas s'il y a un workaround contre les programmes qui exigent de forker. À part les forker eux, pour faire sauter le double fork et recompiler, bien sûr :D

Quant à la vitesse, oui runit est rapide, mais je doute qu'il le soit plus que systemd, notamment parce qu'il lance un nouveau shell pour chaque service.

C'est vrai, le lancement d'un shell est lent. Celui qui lance des bash à chaque fois dois prendre bien cher… d'un autre côté, celui qui lance juste busybox-static, ça doit être raisonnable, niveau coût.
Par contre, je ne sais pas du tout comment systemd marche, de ce côté la. C'est un binaire séparé de l'init qui lit la config?

(hélas peu documenté)

C'est vrai, la documentation tiens sur peu de place. D'un autre côté, je n'ai pas l'impression qu'il y ait besoin de plus. Après tout, runit délègue au système la plupart de ses actions. Alors que systemd c'est plutôt le contraire, il prend les prérogatives du système pour la plupart des actions du systèmes :)

il n'y a pas une grosse communauté autour de runit (admirez la litote ;-).

Oui, je pense que c'est une des raisons qui fait qu'il n'est pas utilisé plus que ça.

à mon avis il n'a pas la carrure pour être le gestionnaire de démarrage d'une grande distribution.

Probablement. Le point le plus noir étant probablement sa communauté trop réduite. Du coup, effectivement, peu de scripts sont fournis, et soyons honnêtes, ceux du site officiel semblent un peu obsolètes.
Je ne pense pas que runit vise à gérer le démarrage d'une grande distribution. Pour moi, il est plus adapté à des distributions qui cherchent à laisser le contrôle à l'utilisateur. Ne serait-ce que par la quasi absence de comportement par défaut.

Surtout que l'auto-complétion pour les chemins de zsh est bien sympa (pas besoin de mitrailler les tab, on take 1 lettre, 1 slash, 1 lettre… et à la fin, ). La seule chose que j'aimerai, c'est qu'il arrête de faire défiler les résultats quand il y a plusieurs choix, mais plutôt tape le maximum et s'arrête au moment ou il ne sait plus, comme le fait bash. Doit être possible, j'ai juste pas cherché comment faire (pareil pour vim d'ailleurs).

Quelle utilisation vais je faire de mon ordinateur ?

Très vrai.

Je pense donc pouvoir vous dire que Debian est vraiment stable si vous utilisez Stable

Vrai aussi, la réputation de Debian n'est pas usurpée. Je me suis amusé avec ma machine personnelle, à plusieurs mois d'intervalle, de passer de stable à testing, de testing à unstable/experimental, en passant par des sessions de jeu sur /etc/apt/preferences puis à revenir à stable. Le retour à stable est une manipulation longue (résoudre les conflits à la main dans aptitude, c'est long et fastidieux) mais simple.

J'ai aussi traîné mes octets sur la ml pendant un temps, et cette question revenais assez souvent (stable vs testing vs unstable).
En général, ce qui était conseillé pour les serveurs, c'était soit stable, soit unstable. Pas testing, parce que les correctifs de sécurité mettent (mettaient, je crois que ça a changé) trop de temps à descendre.

Pour le bureau…
Pas vraiment de consensus.

Mon avis est moi, c'est que pour ne pas être embêté, le mieux c'est stable + backports, avec éventuellement les dépôts source de testing/unstable enregistrés.
Comme ça, on peut avoir un système au cœur stable (Xorg, kernel, terminal), accompagné de logiciels «finaux» plus récents (browser, gestionnaire de fenêtres…).
Et si vraiment il faut à tout prix un truc dernier cri, alors on peu utiliser un paquet source plus récent et recompiler. Ça demande plus de travail, et ça ne se mets pas à jour tout seul, mais ça à le mérite d'éviter de casser le système.

Et si jamais un truc pète à cause d'une MàJ (sait-on jamais), par défaut, les anciens paquets sont conservés dans /var/cache/apt/archives.
Il suffit donc de purger le paquet incriminé (pas supprimer ni réinstaller: purger. Ça nettoie la config système au passage), puis d'aller installer à coup de dpkg la version voulue présente dans le répertoire sus-cité.

C'est plus rapide pour les aller-retour.

Je pense que ceux qui ne sont pas 100% pour systemd ont juste lâché l'affaire. Ils utilisent autre chose, et basta.
Perso, quand je vois un article qui va clairement faire l'apologie de systemd, en général, je me contente des 10-20 1ères lignes et je passe à autre chose. Je peux limite deviner le reste sans le lire.

Les débats autour de systemd que j'ai lu ont toujours été menés à charge contre sysVinit (et la plupart des arguments étaient fondés) mais pas en montrant en quoi systemd était le meilleur (de tous les init).

Maintenant, parmi les opposants à systemd, certains faisaient de la résistance au changement (genre ceux qui défendaient les scripts de sysVinit…), mais pas tous. D'autres disaient qu'il existe des alternatives, aussi bien voire mieux en terme de maintenance (daemontools/runit étaient régulièrement cités, et je n'ai souvenir d'aucun argument contre eux, étrange… au lieu de ça, la discussion re-déviait sur une attaque à sysVinit qui démontrait combien le bash ne conviens pas pour les scripts d'init, comme si sysVinit en faisait le meilleur usage…).
N'étant pas fan de systemd, et encore moins de sysVinit, j'ai un peu suivi certaines de ces alternatives et lu quelques articles (pas de grands livres rentrant dans les détails, des articles relativement courts, pas plus de 2 pages A4) s'y relatant (donc mon opinion est clairement partielle).

• sysVinit, j'avais eu l'occase d'essayer de faire un service… Tout est dit.
• openrc, je n'en ai pas vu l'intérêt. Je ne l'ai pas considéré assez supérieur à sysVinit pour justifier un remplacement.
• upstart, réputation à problèmes.
• uselessd est mort, de mémoire l'auteur affirme que le code de systemd est trop… heu… on va dire, complexe…
• systemd, et son flou «artistique» sur les limites du projet. Sans parler de son code C assez hermétique (de mémoire, parce que oui, j'ai été voir un peu, il y a perpette).
• runit. Simple. Efficace. Le code C est lisible et concis. La doc complète (sans les exemples de services) tiendrai, à vue de nez, sans difficulté sur 5 feuilles a4.

Sur deux VMs, j'ai fait des tests niveau vitesse. À services égaux, runit semble légèrement plus rapide, au démarrage comme à l'extinction.
C'est probablement égal, une fois pris en compte le manque de précision de mon outil de mesure (horloge système de l'hôte, combiné à un regard vissé sur les fenêtres des VMs) biais d'observation et le fait que la nature même d'une VM virtualbox rend les mesures aléatoires.

Personnellement, je ne comprends pas cet engouement qu'il y a pour systemd. A la limite, il se limiterait à la fonction d'init pourquoi pas. Ce serait une alternative de plus et puis voilà.

Je pense que l'engouement est lié à:

• quelques fortes personnalité qui ont fait du buzz autour, en promouvant son adoption rapide
• le fait que son inventeur ait été connu avant
• le fait qu'il fournisse, justement, tant de fonctionnalités. Ça plaît, ça donne l'impression que c'est bien, parce que les logiciels qui ne font qu'une chose, ça n'impressionne pas.
• du fait de l'engouement, il a bénéficié d'un vrai travail pour remplacer l'init sur plusieurs distributions.

Runit, puisque tu le cites, n'a, à priori, pas eu le même nombre de personnalités célèbres derrière. Et il ne cherche évidemment pas à faire autre chose que

1. initialiser le système
2. superviser les services

C'est tout de suite moins sexy. Du coup, j'imagine que peu de gens on fait l'effort de fournir des scripts d'initialisation pour une distribution, ce qui n'aide pas non plus.

tu connais la SPL ? https://raw.githubusercontent.com/matildah/SPL/master/LICENSE :)

Je connaissais pas moi, très fun :)

Sans oublier parfois l'incompatibilité manifeste entre deux paquets de distributions différentes, si un paquet a besoin de Qt 4 et l'autre de Qt 5, tu peux avoir des soucis si la distribution cible n'a pas plusieurs exemplaires de la bibliothèque.

Bien entendu, si la bonne version n'est pas disponible dans le bon système, ça passe pas.
C'est d'ailleurs une des faiblesses de Debian quand on veut des logiciels pas trop anciens (p.e., j'aimerai bien tester openmw, mais ils ont une dépendance sur une version de openscenemap qui n'est pas encore dans debian stable, backports inclus :'( ).

C'est juste que je supposais que si 2 distrib ont la même version mineure (c'est à dire avec API compatible, et puisque c'est interprété, pas de problème d'ABI) de python-qt4 (ou peu importe le nom) les paquets qui ne dépendraient que de ça n'auraient pas besoin d'être repackagé si le gestionnaire de paquet était compatible.
Manifestement, je me trompais, puisqu'ils semblerait que les mainteneurs changent les noms.

Probablement pour des raisons plus ou moins bonnes en fonction de la situation d'ailleurs: j'avais oublié qu'il puisse même y avoir des conflits de noms, par exemple dans Debian le paquet "apcalc" pour lequel "Le nom original de ce paquet est « calc » mais à dû être changé en « apcalc » pour debian car il y a déjà un autre paquet appelé « calc » dans Debian. Les binaires et les pages de manuel installés par ce paquet sont encore nommés « calc ».".
À noter qu'il n'y a plus de paquet "calc" depuis longtemps, et que celui qui à fait ce paquet à été sympa: il a mis dans la description le nom du binaire… combien de fois j'ai du décortiquer le paquet pour savoir ou les trucs étaient installés…

Je suis pas non plus vraiment d'accord pour dire que ça rende tout si compliqué. Si c'était le cas, je pense qu'il y aurait plus de matos avec une variante de netbsd/freebsd plutôt que Linux. Surtout dans la mesure ou on arrête pas de dire que le code de Linux est pas claire, que les BSD ont une meilleur pile réseau et que la GPL est trop compliqué.

Je pense qu'une raison majeure de l'utilisation de la GPL est simplement l'effet de masse. C'est l'une des licences libres les plus célèbres, après tout, et encensée plus bruyamment que les autres.
En tout cas, ce sont les raisons pour lesquelles j'avais plus "d'affinités" pour elle quand je découvrais le logiciel libre. À l'époque, j'aurai surement pas dit ça, bien sûr. Mais si on s'était avisé de me poser des questions sur la LGPL, GPL ou AGPL, j'aurai été bien embêté. Oui, je connaissais les grandes lignes, mais, par exemple, je n'ai jamais su quelle est la différence entre la v1 et la v2 de GPL. Pour la v3, je crois que c'est un truc lié au code qui tourne sur du matos loué?
Malgré que je les aie lues, et plus d'une fois, j'ai découvert aujourd'hui cette histoire de devoir fournir le code pendant 3 ans… Mon cerveau à du le zapper à chaque lecture.

Maintenant que je me soucie vraiment de comprendre les autorisations liées à un bout de code, je préfère des licences courtes (BSD 2/3 clauses, MIT, zlib…) qui restreignent moins que la GLP&co. Moins complexes. Lisibles.
Sinon les licences CC me semblent bien aussi, même si j'admets ne jamais les avoir lues.

Pour faire comme toi le lien avec du code, il y à plus de systèmes qui tournent avec:

• la version GNU de coreutils
• libstdc++
• glibc

Alors que, sincèrement, pour avoir lu le code de 2 commandes (yes et echo, de mémoire. Des commandes relativement simples, quoi.) des coreutils GNU, FreeBSD, NetBSD et OpenBSD, le code GNU est le moins lisible et de très loin. Le plus lisible était NetBSD, puis OpenBSD.
Ça me fait penser que je n'ai pas lu le code de busybox, et qu'à l'heure actuelle, c'est le sort -n de busybox que j'utilise, celui de GNU ne fonctionnant pas comme je veux (et ajouter l'option -b, qui ignore les blancs d'en-tête, ne change rien):

% ps -orss,vsz,comm -A | sort -n | grep -C 3 'ssh-agent' 
 1108   4252 runsvdir
 1424   4256 acpid
 2116   8172 pager
  336  10700 ssh-agent
 1108  10928 dropbear
 1808  15492 init
 1900  15952 xinit

% ps -orss,vsz,comm -A | busybox sort -n | grep -C 3 'ssh-agent'
    0      0 writeback
  RSS    VSZ COMMAND
    4    160 ngetty
  336  10700 ssh-agent
  672   5964 cat
  704   5964 cat
  720   4712 busybox

Pour ce qui est des lib C et C++, quand j'ai un doute sur un prototype ou une struct (parce que les manpages sont super mal branlées de ce point de vue, sans parler du fait qu'il n'y a rien pour la STL), je vais lire les header de la libc++ (de llvm) ou de muslc.
Les headers sont moins chargés, moins de branchements et inclusions, et accessoirement, la dernière fois que j'ai regardé, les espaces et les tabulations n'étaient pas mixés pour l'indentation. Contrairement au code GNU.

Dans la pratique, j'ai la flemme de recompiler ma Debian pour me débarrasser des outils GNU en faveur des alternatives plus propres. Et je parie que je ne suis pas le seul dans ce cas.
Donc, oui, vraiment, je doute que l'usage actuel des outils GNU (code comme licences) tiens énormément à un effet de masse et d'historique.
Absolument pas à des choix techniques éclairés.

Pour le code kernel (puisque tu as cité Linux), je n'en ai aucune idée, je n'ai pas encore osé mettre mon nez dedans. Les kernels restent des choses qui m'intimident, et de toute façon je n'aurai pas vraiment d'usage: je ne parviens pas à imaginer ce que je pourrai leur apporter :D

Par exemple, pour python, le paquet pour avoir pyyaml s'appelle python3-yaml chez Debian et python3-PyYAML

Effectivement, si les paquets changent de nom, c'est pas simple.

Mais sinon, tous ces langages compilés finissent très souvent par appelé du code compilé

Je pensais que les libs natives étaient encapsulées. Si ça avait été le cas, seule la lib python elle-même aurait eu une dépendance sur du natif, pas les applications (ou du moins, pas directement).

Ce qui n'empêche pas qu'il soit possible que ce soit le dernier arrivé. Je ne sais pas moi, personne ne donne de dates, et j'ai rien trouvé sur wikipedia.

Bien d'accord avec toi, mais je tenais à préciser que ce problème de disparité me semble surtout lié aux binaires exécutables.
Pour pas mal de paquets, ça ne devrait pas être le cas, puisque de nos jours, il y a énormément de logiciels écrits en langages interprétés (surtout python).

Ça serait très bien si ça se passe comme ça mais on peut en douter. Quand tu vois qu'il y a toujours les deux formats deb/rpm alors que c'est strictement la même chose.

Ironiquement, deb semble antérieur à rpm, et c'est rpm qui a été adopté par le «standard». Si c'est la même chose, pourquoi? Si FDO était là pour favoriser l'amélioration de l'existant, pourquoi?

On peut vouloir améliorer les choses plutôt que de ne rien faire

Il est plus facile d'améliorer quand il y a des concurrence à priori. Il suffit de voir les progrès que GCC fait depuis que clang est populaire.

Sinon, pour rester dans la sécurité, côté Snap ils parlent bien de sandboxing, mais je n'ai rien trouvé dans leur doc vis-à-vis des autorisations. Côté Flatpak, par défaut il n'y a aucun accès aux fichiers, réseau, périphériques, process en dehors de la sandbox, services (X, D-Bus, PulseAudio…). Et pour pouvoir y accéder, il faut le spécifier dans la conf du conteneur. Ensuite, de ce que j'ai compris, il y aura des demandes utilisateur au niveau de l'environnement de bureau. « L'application Tartampion souhaite pouvoir accéder à la webcam. Souhaitez-vous l'autoriser ? ».

À priori, ça me semble le seul intérêt (qui n'est pas négligeable) de la technologie comparé à la création de paquets contenant un binaire lié statiquement.
Je me trompe?

l'aridité sans nom des types de bases (chaines de characteres et collections en tete),

En même temps, y'a pas de collections en C. Et les chaînes de caractères en C, elles sont … ouai, bon, disons qu'elles sont légères. Lentes sur certaines opérations (strlen) mais légères en mémoire (1 octet gâché au lieu de sizeof (char*)).

c'est pas le premier langage qui me vient a l'esprit quand je pense simplicité.

C'est lequel?

Et j'aborde pas la gestion de la memoire, qui nous apporté tant de failles critique de sécurité ces 2-3 dernières années.

C'est vrai. Quand on touche la mémoire, on peut avoir des failles de sécurité.
Mais ce n'est pas une fatalité, particulièrement quand l'application est simple et le codeur propre.
Pour les failles de sécurité de ces dernières années, plusieurs auraient été détectées si:

1. le code n'avait pas été une usine à gaz (openssl)
2. la compilation avait été faite avec tous les warnings (code unreachable pour l'histoire du goto d'apple)

Par contre, pour les rares failles que je connais, c'est plus dur d'exploiter des failles en natif qu'en interprété.

Perso, ce qui me retiens sous Debian, c'est aptitude.
Je ne connais actuellement aucun logiciel pour gérer mes paquets avec un meilleur ratio simplicité/souplesse, malgré les nombreux défauts de celui-ci (lent, pas portable, mal adapté au multi-arch, principalement).

Personnellement, systemd, au début qu'on a commencé à en parler, j'ai bien aimé l'idée (création de service simple, véritable gestion des services et init parallèle). Clairement, moi non plus je n'irai pas pleurer sur la tombe de sysVinit quand il sera mort.

Maintenant, si je n'ai pas envie de l'utiliser, c'est parce que:

• je n'ai pas l'impression qu'il soit aussi facile qu'avant de délimiter le projet. Systemd (le projet) ne se content plus de faire l'init et de surveiller des daemon, il touche au login, aux journaux, etc. C'est une question de principe, je vous l'accorde, mais tant que j'ai le choix, je préfère les projets simples et bien délimités.
• il n'est pas portable et ne vise pas à l'être. C'est un choix que je respecte, mais je me souviens que d'utiliser des logiciels portables m'a énormément aidé quand je suis passé de Windows à Debian.

Principalement, ce sont des choix de projet dans lesquels je ne me retrouve pas. Il n'y a pas de problème, juste, c'est pas mon truc.

J'ai cherché des alternatives, et dans le genre simple, il y a runit qui colle beaucoup plus à ma philosophie.
Bon, il utilise toujours des scripts exécutables pour gérer les services, mais vue la simplicité de ceux-ci, je ne considère pas ça comme un étant un problème (moins de 10 lignes de shells contre plusieurs centaines… sans parler du fait qu'il suffise de faire sauter ou d'ajouter un lien symbolique pour supprimer/ajouter un service. Pas besoin de balancer une commande qui au final sort un warning et dont on ne sais du coup pas trop si ça à marché ou pas…).

J'aurai bien passé complètement ma Debian à runit, mais… je n'arrive pas à porter tous les scripts sysV de Debian. Typiquement, le peuplement de /dev. Pas trouvé de doc assez simple pour moi. Aussi, le réseau, il y a un truc qui dois m'échapper.
Donc, j'utilise encore le vieil init de sysVinit pour les trucs que je maîtrise pas, mais pour le reste, c'est runit.

Du coup, oui, je compte changer de distrib (je pense à voidlinux).
Systemd fait partie des raisons, mais c'est loin d'être la seule qui fait que je suis las de Debian.
Si ce n'était que systemd, je resterai sous Debian, en prenant juste soin de basculer après chaque installation l'init vers sysVinit. Ce n'est que 1 reboot de plus à l'installation après tout.
Mais je ne crois pas que le sujet soit "pourquoi ne plus utiliser Debian" donc je m'arrêterai la. Toujours est-il que si Devuan suit la ligne de Debian sauf pour l'init, alors Devuan ne me conviens pas non plus.

C'est l'intérêt du gestionnaire de code source de pouvoir montrer, si besoin est, que ces contributions ne sont plus fonctionnelles à un temps t du développement.

Mais, à moins que ce ne soit une réécriture complète du code, le code actuel est le résultat d'une évolution, potentiellement lente et très fragmentée, depuis leurs contributions. Il n'existe que parce que leurs contributions ont été possibles.

Le truc, c'est que tous les VCS ne sont pas égaux. Par exemple, cpold ne garde pas automatiquement la trace des contributeurs.
Par contre, je suis relativement d'accord avec toi pour ce qui est du fait qu'un code est une évolution.
Maintenant, en France, s'il n'est pas possible de coller un copyright sur quelque chose découlant de l'état de l'art, c'est qu'il y a une raison. Et, oui, ça veut dire que corriger une typo qui cause une segfault toute bête et est signalée par un warning de clang (pas gcc, parce que gcc est en retard sur mon système) ne donne pas vraiment de paternité.
Problème: ce type de problématique est international.

Ce n'est pas une idée, c'est une habitude. Toujours prévoir un moyen de retomber sur ses pattes pour éviter que l'utilisateur dise "putain mais c'est de la merde ça marche jamais" :)
Voit ça comme le fait d'avoir subi des réunions "développeur-utilisateurs" (parent-prof) :p

Je l'ai précisé dans un autre commentaire.

Concrètement, que se passerait-il si un jour un élève:

• dont les responsables légaux n'ont signé aucune décharge ou document officiel
• dépense le fric de ses responsables légaux (volontairement ou non, qui sait?) sans leur accord via son smartphone
• constate que son smartphone est vérolé
• accuse l'école d'être la source de la vérole

Je pense avoir cité un scénario pas si improbable? Surtout compte tenu du fait que ton dispositif s'adresse à des gens dont l'aisance avec la technologie est en moyenne supérieure à celle de leurs parents, et qui sont dans ce qui est communément nommé "l'âge bête".