Misc a écrit 6288 commentaires

Tu sais, c'est pas grave, tu peux pas aller vérifier le code sur le ne…. oups, on me dit que si /o\

Ce n'est pas que je n'aime pas la nouvelle méthode - c'est que
je ne la connais pas. Et j'ai beau chercher et ouvrir des
tickets chez RH je n'ai pas encore eu de réponses
satisfaisantes.

Que je récapitule. Tu as déjà migré tes services de prod en RHEL 7 sorti il y a une semaine, tu as déjà ouvert des tickets entre temps, mais par toi même, tu as pas trouvé les présentations comme
https://events.linuxfoundation.org/sites/events/files/slides/linuxcon.pdf

La doc officiel comme ça :
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Resource_Management_and_Linux_Containers_Guide/sec-Modifying_Control_Groups.html

Ou les blogs comme
http://schnouki.net/posts/2013/12/19/resource-control-with-systemd/

Ou la doc de systemd comme :
http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/

Ensuite, peut être que j'ai mal compris la question, mais globalement, tu peux faire l'ajustement avec un bon vieux sudo et voila.

Sinon, c'est du dbus. Cad que la doc que je trouve sur developpez.com avec google me semble suffisante :

http://yoannsculo.developpez.com/tutoriels/linux/introduction-dbus/#LIV

En plus SELinux c'est quand même pas évident à gérer et très
facile à casser (ce qui en langage hypervisuer veut dire plus
personne ne peut rien faire tant qu'on a pas rebooter la
machine en single user et passé SELinux en audit only).

je sais pas exactement comment tu te débrouilles. Tu peux faire un setenforce 0 sur une machine de test, et tu charges ta policy, tu regardes si tu as des AVC avec auditd. Ou si tu tiens à faire ça en prod, tu peux faire des semanage permissive pour juste mettre ton domaine en permissif.

Les seuls fois ou tu va te bloquer avec selinux, c'est si tu bascules ton utilisateur dans un mode restreint sans prévoir un login root de secours et sans mettre selinux en permissive. Un peu comme basculer sur ldap sans te laisser un shell root ou ce genre de choses.

Enfin, les histoires de 7% à 15% , je pense que tu parles des audits, pas de selinux. Les 2 sont séparés ( ie, selinux peut tourner sans audit, auditd peut tourner sans selinux ), donc je suis pas sur du coup que tu testes vraiment ce que tu crois tester….

Sinon, y a softwarecollections.org pour les gens qui veulent du communautaire.

Je vois pas qui ferait ça ni dans quel intérêt. Des gens qui font des infras ultra complexes, ça existe à la pelle. On a tous croisé des usines à gaz et ce genre de choses, donc je vois pas pourquoi ça ne serait pas la vérité.

Les cgroups s'oriente vers une architecture avec un seul processus capable d'écrire dans la hierarchie. Donc c'est déjà mort, on le sait depuis quelques temps.

Ensuite, la façon de faire qui consiste à dire "nagios peut lancer et relancer tout", c'est aussi pas le but de nagios, qui fait du monitoring, pas du correctif en temps normal.

Le souci de Kaane, c'est qu'il monte ses propres architectures qui semble ultra complexes ( du moins, c'est l'impression que j'en retire des pavés et de ce que j'arrive à comprendre dans tout le mix qu'il fait ), qu'il fait des trucs relativement hors des clous ( la, nagios qui relance les services, avant, son histoire de réseau GRE à monter avant TCP/IP, etc ), et qu'ensuite, quand systemd fait la même chose (à savoir la gestion de processus) et que systemd est adopté, ça le bloque dans son architecture.

Mais systemd bloque pas quoi que ce soit, nagios peut parfaitement lancr tout ce qu'il veut soit via service ( et sudo ), soit via l'api DBUS de systemd qui est accessible à des non roots via une configuration standardisé ( vu que c'est le but de dbus ). Point bonus, tu peux contrôler ça via selinux ( ie, dire que nagios a les accès qui vont bien via dbus avec médiation par selinux https://fedoraproject.org/wiki/Features/SELinuxSystemdAccessControl ), ce qui renforce d'autant plus la sécurité et l'isolation qu'il semble vouloir.

Et en fait, l'API dbus est exactement fait pour ça, pour ne pas donner les droits roots mais pour avoir un accès fins aux données. Un project comme cockpit ( http://cockpit-project.org/ ) tire justement parti de ces APIs pour ne pas avoir besoin d'être root.

Je ne doute pas qu'il existe sans doute des vrais soucis, peut être que l'API ne donne pas les accès suffisamment finement pour ce qu'il veut, etc, mais la, les soucis semblent surtout être un mélange de dette technique et d'un manque de clarté dans l'explication du souci.

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 )