Misc a écrit 6333 commentaires

Je sais pas. Les cgroups sont orthogonaux à l'usage de ptrace. Ptrace sert juste à déterminer quel process doit être le process principal, du moins pour upstart. Mais tu peux t'en passer avec divers options, sauf erreur de ma part. Donc tu pourrais très bien imaginer que upstart se retrouve avec une option "kill cgroups", pour tuer tout les process, et avoir le support de "expect systemd", pour avoir la notification comme systemd, ou "expect pidfile", pour faire comme systemd également.

IE, la modularité est déjà la dans le code pour supporter divers choses à divers niveau, et sans remettre en cause le format.

Ensuite, le format est pourri ( difficilement parsable ), mais ça, c'est une autre histoire. Et je parle du code maintenant, pas de celui d'il y a 5 ans, et peut être que ça change tout aussi.

Les soucis de design n'étaient pas évident. Ni i impossible à corriger. Par exemple, le suivi de processus par cgroups auraient pu être mis dans upstart, le suivi avec ptrace aurait pu être refait ou abandonné. Mais Scott ne voulait pas.

Les parties manquantes dans le code (support ipv6, socket activation correct) aurait aussi pu se rajouter, avec un protocole d'activation mieux foutu.

Par contre, ce qui aurait été dur à corriger, c'est les soucis au niveau du design (genre le fait que les dépendances sont dans l'ordre inverse de ce que tu crois et que la logique interne avec les 'ou' a des résultats surprenants). Et ça, je pense qu'il fallait faire un gros usage avant de le voir.

Mir, je sais pas, mais upstart m'a intéressé. C'était une amélioration et un changement dans la gestion des processus, ça apportait des idées intéressantes ( le fait d'avoir une manière plus simple de lancer les services, le coté dynamique, le fait d'avoir une API haut niveau ).

Ensuite, l’exécution était défaillante, le CLA a bloqué des boites qui n'ont pas contribué, et Canonical n'a pas vraiment mis les moyens. Mais ça n'a pas empêché Fedora de le prendre en 2008, pour Fedora 9.

RHEL 6 aussi a adopté Upstart (bien qu'avec une intégration très light), mais je pense que c'est au cours des phases finales de RHEL 6 (cad en 2010, au vue du calendrier) que systemd a vu le jour. Le timing n'est à mon avis pas un hasard. Si je peux hasarder une rétrospective:

RHEL 6 sort en novembre 2010.
Systemd sort en avril 2010.

On peut donc supposer que l'idée de faire systemd est né fin 2009, le temps de faire un truc grosso modo potable pour la version 1, et de contacter des gens à gauche et à droite (Lennart a indiqué qu'il avait pris contact avec des mainteneurs d'autre distributions pour récolter les différentes pratiques et je pense que ça prends du temps).

On peut donc supposer que les équipes de RH ont regardé upstart plus en détail durant l'année 2009, et que ça a aboutit au fait que Lennart propose systemd. Il est aussi fort probable que ça soit la raison d'une intégration "light" au contraire d'Ubuntu.

Upstart est sorti en 2006, donc il a fallu 2/3 ans avant que des gens se penchent pour l'intégration ailleurs ( cad globalement après que la techno se soit montré assez viable pour la LTS en avril 2008, à vue de nez ).

Je sais qu'il y a eu des discussions pour prendre ça sur OpenSuse en voyant Fedora, et pareil pour Mandriva. Sauf que Mandriva a implosé en 2010, et que Suse n'a pas suivi, sans doute à cause de la sortie de systemd, et son intégration avec Fedora.

Mais voila, Upstart, sur son principe, a intéressé des gens. Le nokia n9, sorti en 2011, a upstart. On peut supposer que le choix d'upstart s'est fait 3 à 4 ans avant, ce qui montre bien le moment ou upstart a intéressé les gens. D'ailleurs, pareil pour Chromeos, toujours sur upstart, et qui a commencé en 2009 aussi.

Un simple truc comme ça:

$ echo 3 > /dev/full; echo $?
echo: write error: aucun espace disponible sur le périphérique
1

Tu peux tenter aussi

$ $ exec 1>/dev/full ; echo coin

Mais dans un cas plus proasaique, je suis pas sur que echo renvoie pas 1 si le tty disparait ( genre, tu tues sshd )

Linus fait confiance aux divers lieutenants. Par exemple, pour le réseau, David Miller, qui est lui aussi membre de la conspiration au chapeau. J'ai pas réussi à trouver de listes des dit trusted lieutenants ( ce qui est ma foi un peu un manque de transparence ), mais je pense que Ingo Molnar est potentiellement dessus pour la partie RT , pareil, chapeau rouge ). Ou Al Viro.

Donc je pense que si ce qu'on dit est vrai ( à savoir que Linus ne regarde même pas les PR et merge direct ), Linus veille pas tant que ça. Mais bon, ça va, tant que la machine vger.kernel.org n'est pas sous la protection d'un firewall sous le controle de RH, on peut supposer que les gens sont libres.

déjà répondu:ils n'ont pas forcemment les moyens humains de le
faire

Alors, si Canonical a eu les moyens de faire son propre init ( et de continuer à faire son serveur d'affichage, son outil d'orchestration de serveur, son interface graphique et sa pile pour téléphone ), je pense qu'ils ont aussi les moyens de faire mieux, si ils le voulaient. Et Canonical est largement la plus petite des boites restantes à faire des distributions à destination du monde professionnel.

Donc, c'est quoi les moyens requis en terme d'ingénieur ?
2, 3 personnes à temps plein ? Plus, moins ?

C'est simplificateur. Tu as aussi l'équipe qui va sur Phoronix pour répandre la propagande dans les commentaires, l'équipe qui étudie comment casser la compatibilité sacré avec Unix et le passé, l'équipe qui prends en otage les gens des projets communautaires pour faire ce que RH veux.

Je te trouves pas super respectueux envers tout ces groupes qui travaillent à rendre le libre sur le point d'exploser, sans doute un vaste plan de l'armée américaine (
http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/ & http://igurublog.wordpress.com/2014/04/08/julian-assange-debian-is-owned-by-the-nsa/ )

Alors, j'ai demandé à un pote avec un compte chez FDO :

$ getent group systemd
systemd:x:882:david,walters,kay,harald,tfheen,lennart,mbiebl,holtmann,martin,colin,bor,michich,zbyszek,dreisner,straussd,tomegun,phomes,auke,dvdhrm,zonque,bphilips,msekleta,lnykryn,pflykt

Grosso modo, on a de chez RH:
- kay
- lennart
- msekleta
- lnykryn
- haralt
- tomegun
- walters
- michich

De chez intel, on a :
- pflykt
- auke
- holtmann

En indépendant, on a:
bphilips (brandon Philips) bosse chez CoreOS.
straussd (David Stauss), chez Pantheon system
dvdhrm (David Herman), est étudiant d'aprés sa page web
colin, (Colin Guthrie), chez une boite qu'il a fondé ( et pour le projet mageia )
dreisner (Dave Reisner), packager Arch, qui bosse chez Google d'aprés son compte github

tfheen (Tolef Fog Heen), Debian et qui bosse chez Fastly
mbiebl (Michael Biebl), Debian, étudiant
zbyszek, (Zbigniew Jędrzejewski-Szmek), bosse dans un labo de neuro science aux US
martin, (Martin Pitt), Canonical

Et ceux que je sais pas:
zonque ( Daniel Mack )
phomes ( Thomas Andersen )
bor ( Andrey Borzenkov ) ( potentiellement chez Suse, mais j'arrive pas à vérifier )

Et le reste, ou je suppose uniquement:
david, sans doute david stauss ( mais pourquoi 2 comptes )

On a donc 24 commiteurs, dont 8 gens chez Red Hat, 3 chez Intel.
Ça fait 33% de commiteurs chez RH, et donc 66% venant d'autres boites diverses et variées. On noteras qu'il y a des devs de divers distros (Arch, Debian, Ubuntu, Mageia, potentiellement Suse). Y a même des concurents (genre coreos, qui est relativement en concurence avec projectatomic de RH).

Et ça compte que les commiteurs, pas les gens qui filent des patchs sur la ml.

Tu veux dire "l'API" ?

http://www.freedesktop.org/software/systemd/libudev/

ça se trouve sur un moteur de recherche

Trop de dev d'un endroit est un risque, si jamais RH va mal ou si il y a rachat. Maintenant, tu peux pas forcer non plus les gens à travailler sur les projets sauf si tu est leur employeur et les alternatives ont des effets de bord plus genant qu'un risque futur.

Exemple, ne pas bosser autant sur un projet, ça va ralentir le libre. Ne pas embaucher les codeurs principaux d'un projet, ç'est prendre le risque que le mec se barre dans un trou noir potentiel à la Google/Facebook/Apple et ne bosse plus sur le projet,ce qui implique de former quelqu'un ou d'attendre qu'un remplaçant émerge.

Des gens vont dire que l’émergence d'un concurrent est rendu difficile (exemple, Canonical) de part la position de la boite.
Mais ne pas chercher à augmenter son chiffre d'affaire, c'est prendre le risque qu'une boite moins orienté libre et plus grosse prenne le marché et qu'on revienne en arrière (exemple, une domination d'un secteur par vmware ou oracle). Et c'est pas en laissant une plus petite boite prendre la place d'une plus grosse que tu arrives à te battre contre une boite très grosse.

Il faut aussi voir que plus une technologie est générique (genre glibc, gcc), plus ça pourrait poser de souci. Mais plus elle est générique, plus on devrait avoir des contributions variés car la communauté est plus grande donc moins le risque est grand.

Ensuite, ça reste que du très théorique. Après le rachat de Sun par Oracle, les gens de ZFS et Solaris ont réussi à faire vivre le projet. Aprés Mandriva, Mageia est arrivé.

Oui. Je pense que j'ai la sale habitude de retailler les citations pour que ça rentre dans la boite de dialogue pour éviter de casser l'alignement, et en effet, ça doit donner une coupure à 80 caractères.

bon nombre de technologies flaguées "experimental" dans le noyau

comme ?

DBus utilise les sockets. Du moment que vous avez les droits
root, une version custom de DBus avec tracages des paquets
et la logique de désérialisation - ca n'est pas plus dur à
suivre qu'un socket non DBus.

tu bullshites un peu ( comme d'hab ). Y a dbus-monitor, fourni de base, pas besoin de version custom.

Mais sur systemd avoir un /usr séparé fonctionne très bien (sauf
en double montage - mais que personne n'arrive à faire marcher.
Je vous jure, si, si)

Oui, ça marche, si tu fait monter le /usr par l'initrd. D'ailleurs, c'est la raison de l'unification de /bin et /usr/bin, refaire un /usr commun pour plusieurs containeurs.

En ce qui concerne l'ajout d'un serveur DHCP dans l'init,
c'était obligatoires. Parceque des raisons

Visiblement, tu as oublié de te relire ici, tu as oublié un 's' en trop dans ta précipitation et tu as oublié le lien vers le post qui donnent une raison. Heureusement, il y a des gens qui suivent pour te corriger:

https://plus.google.com/+TomGundersen/posts/ht4nn9jHbAR

Encore faux, systemd peut parfaitement renvoyer le contenu de
journald sur syslog si vous tenez tant que ça à doubler les
I/Os.

Si je peux me permettre (c'est une formule de politesse), tu fait encore preuve d'imprécision (on t'en veux pas, on peut pas passer sa soirée sur un commentaire et savoir de quoi on parle), la page de man (c'est la documentation sous Unix, si tu connais pas) semble indiquer que si tu ne fait pas un repertoire /var:log/journal, alors rien n'est écrit sur le disque par journald. Donc je ne suis pas sur que les I/Os soient doublé, sauf si tu configures mal ton systéme aprés ne pas avoir lu la page de man.
Reference :
http://www.freedesktop.org/software/systemd/man/systemd-journald.service.html

"By default, the journal stores log data in /run/log/journal/.". Comme /run est un tmpfs, ça fait pas d'I/O sur le disque (sauf si tu configures /run pour ne pas être un tmpfs, cad sauf si tu fait exprés de rendre les choses moins performantes).

Tu peux aussi filer à syslog et envoyer ça vers splunk/logstash ou autre. Enfin, ça, c'est pour les admins avec du pognon et ou des infras plus conséquentes.

Honnêtement on ne peut pas porter systemd ailleurs.

Visiblement, en 4 ans, personne n'a tenté, et encore moins réussi. Donc soit c'est pas faisable et Lennart a raison, soit ça intéresse personne, et Lennart a raison de pas perdre de temps dessus. Dans les 2 cas, il a raison.

Nous on a un système centralisé ou pour lancer une copie d'un
service qui tourne déjà avec d'autres paramètres il faut
copier un template

Non, tu fait le fichier et un include.

, le linker symboliquement, l'enregistrer, et finalement
l'initialiser (éventuellement avec des scripts pre et post
traitement) via des commandes DBus et/ou systemctl.

Faire un lien, comme sur gentoo et openrc ? C'est vrai, je me souviens des cris des gens quand on a dit "oui, faut faire un lien d'un script d'init pour en lancer plusieurs exemplaires, puis il faut connaitre le nom du nouveau script, puis taper 1 commande par script à lancer, comme c'était long. les gens ont râlés de partout à dire que Gentoo ne marcherais jamais avec un système si fastidieux. Je me souviens des gens envoyant des menaces à Daniel Robbins, etc.

Mais bon, je doit reconnaitre que ta mauvaise foi est distrayante, et ça change des fois ou tu as affirmé (je cite) que RHEL sortirais mi-2013 (supposition de ton chapeau), en envisageant sérieusement de ne pas mettre systemd. Comme tu as la mémoire courte (vu le nombre conséquent d'oubli à chaque fois), je te remets le lien:

https://linuxfr.org/nodes/96086/comments/1401229

Au final c'est pas bien connu, mais il me semble que les distributions serveurs (comme Suse Entreprise ou Red Hat) envisagent très sérieusement de ne PAS passer à systemd. En tout cas pas tout de suite.

En fait, ils envisagent tellement de revenir en arrière qu'il reste que 3 scripts d'init dans la version finale de RHEL 7.

Je pense que l'affaire du dernier bug d'openssl montre bien pourquoi les gens preferent manger du verre pilé que de traiter avec Theo.

Sinon, le client des BSD est dérivé de celui de l'ISC :
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sbin/dhclient/dhclient.c?rev=1.311;content-type=text%2Fplain

Et il est pas portable tel quel sur Linux. Exemple, prenons le premier fichier, le code pour faire un socket bpf ( http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/dhclient/bpf.c?rev=1.32;content-type=text%2Fplain ). Openbsd demande à ouvrir un device dans /dev, Linux fait ça via une option sur le socket ( https://www.kernel.org/doc/Documentation/networking/filter.txt ).

La syntaxe des filtres BPF semble aussi ne pas être la même, donc il faut aussi faire des adaptations.

Les ioctl sont pas pareil ( je pense pas que BIOCVERSION existe sous Linux, aprés une rapide recherche ). Et je suis sur que l'ajout de route non plus. Et après lecture du code, je suis pas sur qu'il gére pas le dhcpv6 ( avec délégation de prefix, etc, etc ).

Et c'est pas une lib.

Donc si le but, c'est juste de forker le code pour faire chier Theo, je suis pas sur que ça vaille le coup, vraiment.

Et pour Freebsd, bah pareil, le client dhcp est dérivé de openbsd, et en plus, utilise capsicum (non dispo sur linux) :

http://svnweb.freebsd.org/base/head/sbin/dhclient/bpf.c?revision=263234&view=markup

Décider de ne pas suivre, ça a un coût que ne peuvent supporter
la majorité des distributions.

Tu veux dire "ne rien faire rends dépendant de ceux qui font les choses, car sinon, on arrive pas à suivre ?"

Les communautaires parce que créer et maintenir une solution
alternative, c'est hors de leurs moyens

khof BSDs khof

Avant que GNOME ne s'y mette, systemd vivait dans son coin et
personne ne songeait à switcher, ou en tout cas pas si vite
étant donné la quantité de problème qui restait à régler avec
systemd.

Fedora a switché. Suse, Mageia, Arch. Debian et Gentoo l'ont mis en option depuis longtemps. Je boote mon serveur Debian stable avec. Et il est dans Debian depuis 2010. Pour un truc ou personne ne songé à switcher, je trouve que les gens ont vite fait le travail.

Développer du logiciel libre, ce n'est pas comme développer du
logiciel tout court, il y a des règles tacites, des
communautés à prendre en compte.

Sinon quoi ?
Ah oui, sinon, les gens vont râler sur linuxfr et slashdot. En vérité, les règles, c'est pas "faut respecter les communautés". C'est plus "on propose, et si les gens sont content, ils suivent, sinon, ils se barrent". Et visiblement, la majorité se barre pas. Ou plutôt, la majorité qui compte, cad les contributeurs. L'équipe de systemd a consulté les gens des autres distributions dés le début, c'est pour ça que le système utilise /etc/hostname et d'autres debianismes.

Si tu ne respectes pas les règles de la communauté, tu as personne qui vient contribuer sur ton logiciel, et on se retrouve avec la même communauté qu'un logiciel proprio ( ie, personne ne t'aide ). Le fait que des externes au projet contribuent semble montrer que les règles sont respectés.

RedHat reste une entreprise avec ses intérêts particuliers et > il se peut qu'un jour les intérêts de RedHat soient en
contradiction avec les intérêts du monde libre.

En pratique, ça serait quoi ?
Le code est libre, si tu changes la licence, l'ancienne s'applique encore sur les anciens tarballs distribués. RH fait parti de l'OIN, donc je ne pense pas que les brevets soient un souci. Il reste divers trademarks, qui devraient bloquer qu'une paire de projets de la boite.

Le plus gros souci, ça serait d’arrêter de aire du libre. Mais pour ça, la solution, c'est que le reste du monde en fasse plus, et pour ça, faut arrêter de zoner sur linuxfr et commencer à contribuer.

Y a eudev : https://github.com/gentoo/eudev/commits/master

Alors bien sur, ça reprends beaucoup de udev, preuve que c'est pas si simple. Et grosso modo, y a quelques distros qui doivent proposer ça, mais y a pas la vivacité de systemd.

Les deux. Pour la gouvernance de GNOME, apparemment, c'est un
problème pour certaines personnes assez impliquées dans GNOME.

Sauf erreur de ma part, c'est visiblement pas un problème pour la communauté gnome, vu qu'Emily Gonyer n'a pas été élu:

https://vote.gnome.org/results.php?election_id=22

Je doit reconnaitre que je pige pas trop la méthode de comptage, mais je doute qu'on puisse contester que ça n'a pas bousculé vraiment le scrutin.

Mais comme c'est libre, on pardonne et on fait semblant de rien.

Oui. parce que c'est libre, c'est pas de l'enfermement. C'est juste des gens qui font pas ce que tu veux mais qui t’empêche pas de faire ce que tu veux. Que la majorité ne te suive pas est une autre paire de manche.

Je peux donner des contre exemples. Les nouveaux produits comme the foreman, openshift sont en ruby en rails, ou en go ( geard ), alors que RH promeut java via jboss ( et a du monde sur le jdk, etc ), du monde sur gcc, et fait son propre language par dessus la jvm.

De même, openshift utilise depuis quasiment le début ActiveMQ plutôt que Qpid, qui est pourtant "de la maison". Des esprits chagrins et observateurs vont dire qu'avec le rachat de fusesource, RH a mis le pied dans ActiveMQ, mais la chronologie ne colle pas, car Openshift est antérieur à ce rachat.

Ou le fait d'avoir choisi de mettre en avant docker plutôt que virt-sandbox ou une solution basé sur les lxc et libvirt, pour ne parler que des choses récentes.

Tu parles de Tom Gundersen, le développeur que Red hat a embauché pour bosser sur networkd, sans doute pour le récompenser d'avoir mis systemd au sein de Arch Linux. Il est fort probable que le but obscure de la manœuvre soit d'infecter la distro qui monte et qui menace la main mise de la société sur le marché des serveurs.

Moi je dit, il faut se méfier de tout le monde, je suis même sur qu'ils sont parmis nous ici à surveiller et à répandre la propagande pour cacher le plan de domination du libre !

(je précise que c'est du sarcasme, pour le cas ou des gens souffriraient du même travers que le docteur Sheldon Cooper.)

La version anglaise dit 32, la version française ( qui doit avoir du retard sur ma machine ) dit 16.

Et en fait, c'est dépendant de l'os :
http://community.aegirproject.org/developing/architecture/unix-group-limitations

Donc si on veut faire vraiment portable sur les anciens OS, c'est 8.

$ getent group | perl -n -e '@a = split /\:/,$_,0 ; if (length($a[0]) > 8) { print $a[0] . "\n" } ' 
avahi-autoipd
pulse-access
nm-openconnect
nfsnobody
wireshark
stap-server
gamephant
monkeysphere
systemd-journal
systemd-journal-gateway
teeworlds
tinyproxy
gnome-initial-setup

Et en effet, si on veut être compatible avec les systèmes à 16:

$ getent group | perl -n -e '@a = split /\:/,$_,0 ; if (length($a[0]) >= 16) { print $a[0] . "\n" } '
systemd-journal-gateway
gnome-initial-setup

Donc au lieu d'opmitimiser une bibliothèque existante, on en
écrit une autre. Si c'est pas du NIH c'est quoi ?

La réponse est sur le g+ du dev:

https://plus.google.com/+TomGundersen/posts/U6Es8bpmMbP

ie, "l'existant ne nous va pas, mais on a regardé et on va bosser sur une nouvelle lib proposé par quelqu'un d'autre". Donc reprendre le code de connman, c'est pas vraiment du NIH.

Voir aussi https://plus.google.com/+TomGundersen/posts/eztZWbwmxM8

Et les commentaires, surtout la fin, ou il dit avoir regardé les 3 libs et en avoir repris une.

Il explique aussi pourquoi systemd a sa propre lib pour la communication avec le kernel :

https://plus.google.com/+TomGundersen/posts/JhaBNn8Ytwu

( TLPL: les libs sont synchrones et bloquantes, le dev veut de l'asynchrone non bloquant, ça implique de tout refaire dans tout les cas )

Qui ont leur propres standards d'options et ne réutilisent pas
l'existant

L'existant pour quoi ?

Les options de systemd-detect-virt réutilise pas l'existant de ou ?
Ou journalctl devrait reprendre quel options existantes ?

Pour les trucs ou ça a du sens, c'est exactement ce qui est fait. Exemple, /etc/fstab, /etc/hostname, /etc/cryptsetup. Quand il y a rien, ou quand il y a des implémentations divergentes, il faut faire un choix.

et ça sera forcément moins UNIX que l'était System V
(franchement, du XML c'est pas très UNIX…).

On parle de systemd, pas de SMF…

Après, c'est peut-être ça l'avenir du Libre : ça devient plus
professionnel, et les petits bénévoles ne pourront plus suivre
le développement des composants au cœur du système.

Tu sembles tout d'un coup te réveiller d'un sommeil de 10 à 15 ans. Tu connais beaucoup de gens qui bosse sur gcc sur leur temps libre ? Sur la glibc, le kernel ou Xorg ?
Tu t'es dit que des trucs comme xen ou kvm sont arrivés sans avoir des gens à temps plein dessus ?

Pour la liste des gens qui peuvent commiter, suffit de trouver une personne avec un accès à fdo et de dire "qui est dans le groupe qui peux commiter".

Pour savoir qui bosse chez RH, suffit de trouver un mec qui bosse chez RH et de demander.

En effet, demander à Lennart remplit les 2 conditions.

C'est bien ce que j'avais compris. Mais, je ne sauterais pas
aussi vite que toi sur la conclusion. Les units sont distribués
par des logiciels tiers, que tu peux ne pas vouloir faire
tourner en root (souvent tu lances un daemon sous un autre
utilisateur par exemple)

Dans ce cas, systemd le permet, via User=. Encore mieux, via l'activation par socket, tu peux même espérer avoir les softs ne jamais voir l'uid root, dans certains cas spécifiques.

En fait, non seulement systemd permet ça, mais en plus, permet de rajouter facilement la configuration via les drop-in config ( ie, faire un fichier /etc/system/foo.service.d/foo.conf avec juste User=foo et paf, il va faire ce que tu veux, à savoir combiné ton service et celui du distributeur tierce en gérant l'upgrade proprement )

Tu peux toujours te NIH tout seul.

Le NIH, c'est "Not Invented Here". Quand tu refait ton propre code, c'est pas vraiment du NIH, par définition. Est ce que pour toi, NIH veut dire "refaire du code alors que du code existant rempli une partie des besoins", auquel cas, on peut qualifier tout un tas de trucs de NIH…
( ou du moins, je pense que systemd-consoled n'est pas un NIH de ksmcon pour ma définition de NIH, mais c'est juste mon point de vue ). J'imagine qu'on ne mets juste pas la même chose sous le terme NIH.

Quel est le soucis avec ISC ?

Personnellement, je leur reprocherais une certaine obscurité et/ou de l'amateurisme. Exemple, le bug tracker de bind qui est une liste de discussion, les VCS des projets sont parfois non publiques et/ou mal documentés ( celui de dhcp me semble assez récent par exemple, bind < 10 n'etait pas existant). L'abandon soudain de bind 10 est un exemple de process interne non discuté en publique, etc, etc.

Donc je pense que la collaboration peut être difficile avec l'ISC, d'ou sans doute le fait que personne ne tente de faire une lib pour le dhcp en partant de dhcpd (encore une fois, l'équipe de connman bosse sur ça)

Je pense que la déserialisation est implementée ici :
http://cgit.freedesktop.org/systemd/systemd/tree/src/core/unit.c
et pour autant que je sache c'est executé dans le contexte du
pid 1.

C'est plus subtile. C'est dans le pid 1 pour les fichiers de root, et dans le pid du gestionnaire de session pour les fichiers accessibles par l'utilisateur ( ie, sous l'uid de l'utilisateur ). Donc je pense que si tu peux écrire le fichier, alors c'est déjà trop tard, pas besoin d'exploiter une erreur dans le parser. Non pas que ça veuille dire "on s'en fout de la sécurité", mais que le fait de faire l'analyse du fichier dans un process à part avec un canal de communication avec le pid 1 est une complication qui n'a pas jugé valoir la chandelle pour le moment. Une des choses que j'ai trouvé complexe dans le code d'upstart est justement ça, l'overhead lié à la communication interprocessus, avec les problématiques de synchronisation, etc, etc. Peut être que ça arriveras plus tard, mais je pense que c'est plus important pour un browser que systemd.

J'ai cherché justement après avoir posté ça, apparament ça n'a
pas été mergé, mais il y avait un début de code. J'espère
juste simplement qu'ils vont ajouter cette fonctionnalité
(parce que c'est une bonne idée) mais qu'ils vont se baser sur
l'existant, notament kmscon.

C'est le lien que tu cherches, je pense :
http://lists.freedesktop.org/archives/systemd-devel/2013-November/014808.html

Visiblement, c'est le dev de ksmcon qui a proposé systemd-consoled, mais j'imagine qu'il fait du NIH sans le vouloir :)

Je pense que DHCP est un bon exemple, mais si ça te suffit
pas, il y aussi timesyncd

DHCP est pas le meilleur exemple de NIH. Timesyncd est déjà mieux. Ensuite, le client que tout le monde utilise ou presque, c'est celui de l'ISC. Pareil pour ntpd. Je dit pas qu'il y a un lien mais bon, peut être qu'il y a une piste.

Mais après avoir vu le code, il semble que timesync fasse juste du sntp client ( tu va pas loin avec 1200 lignes de code ), et pas la totale comme ntpd qui peut faire serveur, qui a un algo bien spécifique pour gérer les cas particuliers et le drift, etc.
( et tout comme dhcp, y a pas de lib existant qui vont permettre l'usage du code de ntpd, donc tu doit refaire tout ).

Certes, pour les contacts ( je pense que tu parles de ça ), mais ça ne parait pas être le paradigme premier d'usage.

En tout cas, pas sur mon vieux android ou mon nokia.