La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?
Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?
Sauf que si tu regardes un peu autour de toi, tu va voir que le monde n'est pas composé uniquement de machines de bureau surdimensionnés.
D'une part, quand tu produit des appareils à des millions d'exemplaire, ton histoire de la barrette de ram devient "pourquoi ne pas avoir acheté des millions de barrettes de ram" ce qui reviens d'un coup à "pourquoi ne pas avoir dépenser beaucoup plus de pognon en achat, en logistique et en test". D'ailleurs, il suffit de voir qui teste networkd sur la list, et tu va voir des emails @intel.com, @axis.com .
Ou simplement que malgré le fait qu'on trouve des Giga de ram, on trouve pas encore des giga sur les contrôleurs embarqués et sur toutes les pièces d'un appareil.
Et d'autre part, la tendance est à faire des conteneurs pour augmenter la densité du nombre de service par machine. Donc quand tu tapes dans les 2/3, ça va, ça fait pas grand choses. Quand tu tapes dans les centaines, tout d'un coup, ça commence à faire un multiplicateur qui rends la chose un chouia moins futile que tu sembles le croire, aussi bien en temps de démarrage qu'en occupation mémoire.
Donc oui, je pense que Moonz a raison de pointer l'overhead de systemd lui même par rapport à /bin/init du bon vieux temps, et que même si ça semble futile, ça reste un point à regarder. Mais comme j'ai dit plus loin, j'ai changé juste un paramètre à la fois pour comparer.
Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.
Rajoute "et parce que toute les machines ne sont pas équipés en IMPI ou carte d'admin couteuses, ce qui permet d'adresser le marché des hobbyistes ayant leur serveur sous forme d'un shuttle dans le salon".
Et comme je peux pas me fatiguer à répondre à la même question sur le réseau, avoir un rescue sur le systéme qui a le réseau ça permet par exemple de télécharger le fichier de la glibc qu'on a écrasé par erreur depuis le rescue.
Bien sur, on arrive à se débrouiller autrement quand on a pas le réseau, mais je peux imaginer que ça peut faciliter la vie.
Et ça prends aussi moins de place dans l'initrd, au moins sur Fedora.
systemd-networkd fait 343k après passage de strip, bash + /etc/init.d/network + divers scripts dans /etc/sysconfig/network-scripts/ , ça fait 960k + ~100k de scripts.
Et si on me dit "mais networkd- tire la libpcre, ça fait 410k de plus", je dirais que les scripts d'init tire gawk, qui fait 570k.
Nan mais commence pas à ruiner tout l'argumentaire avec des vrais features et des use cases qui sont pas tirés par les cheveux, tu te rends compte que Linuxfr vit grace aux contributions, et que systemd a augmenté les contributions sur les commentaires :)
Les arguments à l'époque était sur les appels de fonctions dbus. La, on parle de fonctions en C et la différence entre avant et maintenant, c'est ce sur quoi tu lies ton binaire.
Networkmanager fait beaucoup plus de choses, genre le wifi, le bluetooth, le ppp. Il gère les proxys dns ( via dnsmasq) et le partage de connexion.
La, je pense que l'idée est surtout de remplacer /etc/init.d/network ( sur fedora ), et l'idée n'est pas non plus de Lennart, mais de Tom Gundersen, packageur Arch.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.
Upstart propose une option de configuration (stanza en jargon Upstart) qui permet pour un job de charger un profile et de démarrer directement le job avec ce profile :
Par exemple, je donne le chemin direct vers le profile, upstart le charge, l'utilise et lance le processus. C'est une ligne à rajouter.
Commencer à devoir utiliser aa-exec, ça deviens vite chiant. Déja, si ton job upstart contient plusieurs lignes de commande, tu es obligé de faire un wrapper ( et donc il n'est plus "self contained" ), et tu dois charger à la main, en n'ayant pas le diagnostique de pourquoi ça ne marche pas, etc, etc.
Pareil avec systemd, qui propose dans la version git "SeLinuxcontext" pour démarrer le process dans un domaine particulier. En faisant ça dans systemd directement, tu as la capacité d'interroger systemd par dbus pour avoir l'info, tu as un retour plus haut niveau via journalctl ( ie, un vrai code d'erreur ), tu as une gestion intégré via les templates, etc, etc.
Pour le moment, tu peux pas dire "ce job est dans ce profile apparmor", mais un patch a été envoyé ( et il attends une version 3.0 avec divers modifs ).
Je suspecte, juste comme ça, parce que j'ai l'esprit mal tourné,
que c'est un genre de renvoi d'ascenseur qu'il ait été embauché.
tu veux dire que c'est pas juste parce qu'il s'agit d'une personne qui a démontré sa capacité à comprendre le libre et à bosser dans la communauté dans un domaine qui manque cruellement de gens (à savoir les juristes spécialisés dans le domaine de la propriété intellectuelle et le libre) ?
Je ne suis pas bien certain que tous chez Red Hat "comprennent"
les mêmes choses que "comprend" Mr Fontana. Il lui reste du
travail.
Donc tu veux dire qu'un avocat qui passe plusieurs années à apprendre son métier et à l'exercer n'arrive pas à transmettre tout ce savoir en 5 minutes à un nombre arbitraire de gens, comme le montre un bug report isolé ?
Et pitié, ne ressortez pas le schéma ignoble pondu par Adobe il
y a quelques années — la flemme de le retrouver, mais je suis
sûr que vous voyez de quel schéma je parle : ce schéma dans
laquelle on nous présente OpenAL, SDL, Allegro, GStreamer et une
dizaine d’autres bibliothèques comme faisant partie de la pile
audio Linux et censé illustrer sa complexité démente. Oui, un
programmeur sous Linux a le choix entre de nombreuses
bibliothèques s’il ne veut pas utiliser libasound ou libpulse
directement.
Il te faut pas grand chose pour avoir de l'espoir. Klang a été annoncé en juillet 2012, et le site web dit encore "on va avoir un design document dés que possible".
Cet argument marche pour toute demande de CLA, y compris
Digia, FSF (pour le projet GNU, vraiment ces gars ils sont
horribles avec leur CLA à mettre des bosses)… Mais bizarrement
on parle surtout que de Canonical. Peut-être parce que ce
n'est pas la raison?
L'argument en question marche aussi pour la FSF. J'ai envoyé un patch pour grub2 et j'ai du attendre quelques semaines le temps de faire les papiers pour qu'il soit intégrer. Moi, ça me dérange pas, mais je connait des gens que ça dérange.
Et si tu parlais avec des gens du libres en dehors de linuxfr (genre sur irc, au fosdem, voir dans mon cas, au boulot) et surtout sans un filtre ou tu retiens que ce qui te permet de troller, tu verrais que les procédures de la FSF sont pas universellement acceptés. La différence est que dans le cas de la FSF, personne ne va te dire "je n'aime pas parce que je me fait flouer". Les gens sont pas d'accord, mais ils comprennent la position de la FSF pour le bien du logiciel libre.
Dans le cas de Canonical, les gens ont vachement moins confiance dans la boite. Par exemple, les annonces de "on va aider ça" ou ça se résume à "on va proposer ça dans Ubuntu", les revirements sur gnome-shell/unity, sur wayland/mir, sur bar/bzr.
Un codeur mercurial francais m'a dit qu'à un moment, il y a eu des propositions de fusionner mercurial et bzr, et que les discussions se sont arrêtés quand Mark a dit "bien sur, le résultat sera entièrement sous le copyright de canonical". Et c'est ce genre d'incidents repetés tout au long de l'histoire de la boite (le coup avec opensuse, le coup avec banshee et rhythmbox) qui font que non, même si digia a le même genre de CLA, les gens parlent pas de ce CLA.
Dans le cas de Canonical, personne ne te dit "on veut pouvoir faire du proprio parce qu'on a besoin un jour d'être à l'équilibre". Et personne chez eux ne veux rappeler le fait que pour le moment, la boite survit depuis 10 ans en tournant à perte. Et il faut dire que quand on se positionne comme champion du libre, ça fait un peu tache de dire ça.
Donc c'est même pas de le faire, c'est surtout l'hypocrisie complète, le fait qu'aux oreilles de beaucoup, tout ça sonne comme un mensonge. Et si tu rajoutes tout les faux pas (comme celui avec Mint et la trademark, avec le mec de la FSF et la trademark), tu aboutis à une situation ou la moindre chose que Shuttleworth fait ou dit part en vrille en plus de son coté polarisant habituel (parler de "losing graciously" implique d'avoir une compétition explicite, ce qui est totalement idiot)
Mais tout ces détails, je ne pense pas que tu les retiennes, vu que tu va continuer à troller sur "pourquoi les gens parlent que du CLA de Canonical et pas de Digia" à la prochaine news sur le sujet, j'ai déjà le sentiment d'avoir parler dans le vide.
Alors faut bien voir que d'abord, ça va pas arriver dans la stable avant 8 mois ( vu que faut d'abord sortir la 14.04, ensuite la suivante ). Ensuite, c'est en partant du principe que dans 8 mois, c'est fini, et au vue des cadences d'Ubuntu et du fait qu'il faut quand même d'une part coder ce qui manque ( genre le support de AppArmor au même niveau que dans upstart qui peut faire ça job par job ), et migrer tout les jobs customs, etc.
Faut voir par exemple que Unity utilise upstart comme gestionnaire de session utilisateur aussi.
Et je pense que Ubuntu va attendre que Debian fasse le taf, ce qui implique d'attendre la release de la stable ou au moins le gel. Et d'ici la, il va y avoir plein de changements dans le kernel et dans systemd, comme kdbus et les cgroups. KDus qui semble aussi ne pas aller dans le sens des demandes de Canonical pour la gestion fine des ACLs via apparmor, donc ça fait du taf en plus aussi.
Globalement, non. Et vu que parmi les juristes de RH, tu as Richard Fontana qui a co-écrit la GPL v3, je pense que l'équipe comprends le libre et ce que ça fait.
Il y a aussi des gens qui comprennent ce qui fait qu'une communauté marche, et qu'un CLA de quelque nature que ça soit, ça reste un obstacle de plus à la contribution ( comme le fait de devoir ouvrir un compte spécifique ou ce genre de choses, comme expliqué par Dave Neary sur http://blogs.gnome.org/bolsh/2012/09/14/attention-speed-bump-ahead/ ( qui justement bosse dans la dite équipe OSAS de Red hat, qui justement vise à conseiller les projets upstream en matière de communauté ).
D'ailleurs, il est amusant de voir que Jono Bacon, community manager chez Canonical, le dise aussi dans son bouquin, mais visiblement, qu'il n'a pas réussi à convaincre sa hiérarchie.
Le NIH s'applique peut être à SysVinit et pas à systemd :p
Mais je ne pense pas que ça soit la raison principale en effet de garder Upstart. Ce qu'on voit, c'est que si Debian passe à systemd (et donc fait le taf d'intégration), alors Ubuntu va suivre. Sans ça, ça aurait du être le taf d'Ubuntu, et je pense que Canonical n'avait juste pas les moyens humains de faire ça alors qu'ils ont des projets à finir.
Ça reviens à une bête question de ressource. Et le fait d'avoir des bugs non corrigés depuis longtemps dans Upstart, d'avoir finalement peu de code poussés dedans ne sont que d'autres symptômes d'une même cause.
En attendant que la QA de Debian (et de RHEL 7) fasse le taf, Ubuntu a tout à gagner.
Alors en fait, j'ai cherché ( car oui, je ne discute pas sans recherche minimum ), et j'ai trouvé divers choses.
Alors il y a virt-sandbox-service, qui est un wrapper entre libvirt et systemd. La dépendance est à la fois assez faiable ( car ça fait des unités systemd, rien de complexe à refaire sous upstart ) mais elle existe.
En fait, je savais même pas que c'était fortement lié à systemd avant de regarder en détail.
Tu as aussi des trucs comme fleet ( https://github.com/coreos/fleet ) du projet coreos, qui permet d'avoir un systemd sur le réseau ( ie, activation à la volée, ce genre de choses ).
Je pense qu'il y a surtout une question de marketing. IE, quand tout le monde a migré vers upstart, personne n'a rien dit parce qu'on a pas mis ça en avant, et parce que personne n'a eu le style de Lennart pour dire "les trucs sont de la merde, le mien est bien".
Quand Apple change un truc, ils vont le vendre bien, donc les gens acceptent. Lennart, lui, il compte juste sur la qualité du produit, et visiblement, ça ne suffit pas à réduire les peurs des gens. Il faut ensuite rajouter les pseudos experts qui postent pour dire "si systemd crash, l'os crash" pour avoir un panic.
Aucun n'a vérifié ce qui se passe, personne n'a lu le code pour voir qu'en pratique, systemd ne fait pas paniquer le kernel.
Donc oui, si systemd crash, il ne réponds plus, mais la machine tourne encore, les processes aussi, vu que systemd tourne en boucle en faisant "pause" pour éviter le kernel panic. Donc au final, ça reviens à être bien moins catastrophique. Et pour être franc, je me demande si il n'est pas possible de relancer automatiquement systemd pour plus de HA. ( le code n'est pas la, mais je ne sais pas si on peut le rajouter facilement et de façon robuste ).
Ou alors juste sur les rapports de IDC, ou Unix représente 16% du marché, et est prévu pour chuter à 9% ( http://www.networkworld.com/news/2013/081913-unix-272728.html ). L'article explique aussi que les déploiements de db sur linux ou windows dépassent ceux sur unix. Si c'est pas de la prod, je ne suis pas vraiment sur de savoir ce que c'est.
Digital et Compaq ont disparu et leur unix de même, SCO/Caldera aussi. Je sais même pas ce que Xenix est devenu, et Irix existe plus que dans Jurassic park ( dans le film, pas dans le sens ou c'est un dinosaure ).
HP-UX, AIX et Solaris sont encore la en effet, et je dirais bien que seul Solaris arrive à faire des trucs, poussé par Oracle, mais IBM dégraisse, HP aussi, et Sun s'est cassé la gueule pour se faire racheter par Oracle.
Ma maigre expérience de 18 ans d'Unix (Solaris, HPUX, AIX, NCR,
XENIX), me permets d'avoir un avis personnel et de juger que oui
Linux s'éloigne d'Unix,
ça fait bien longtemps que ça s'éloigne d'Unix. C'est même la raison de son succés, pas de procés au cul par AT&T.
Mais il faut bien voir une chose. Les Unix ont pour la plupart disparus. Et si il suffisait de suivre leur philosophie pour survivre et avoir du succès, debian kfreebsd serait pas à que dalle en terme d'usage, et l'Unix-like avec le plus de succès serait pas originaire de Cupertino.
Tu peux dire ce que tu veux sur les principes d'Unix, mais visiblement, ils ont pas l'air de passionner les foules ni d'être une raison de choisir cette famille d'OS. ( et faut pas me dire "oui, mais le marketin de blabla", si le marketing de tout les OS plus récents est meilleur, c'est bien la lose d'être la avant et de se faire battre )
Mais je suis sur que Freebsd sera ravi d'avoir ton aide avec tes 18 ans d'xp, car il me semble évident que tu va faire quelque chose, pas juste attendre, n'est ce pas ?
[^] # Re: Et si on lisait un peu plus loin ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 4.
C'est chose faite :
http://cgit.freedesktop.org/systemd/systemd/commit/?id=03e37dd767e52908f30783d9b4c09fb6a4e865c7
Et une release est prévu sous peu.
[^] # Re: Le nid à trolls
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 3.
La portabilité, c'est trés surfait. par exemple, awesome est minimaliste, mais est ce qu'il est portable ? Par exemple, je peux faire tourner ça sur ios, android ou windows ?
Ou est ce que la portabilité est une notion faiblement défini par "portable sur ce qui me parait important et fuck off les chiffres et les stats qui montrent que ça reste 1% du parc" ?
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 8.
Sauf que si tu regardes un peu autour de toi, tu va voir que le monde n'est pas composé uniquement de machines de bureau surdimensionnés.
D'une part, quand tu produit des appareils à des millions d'exemplaire, ton histoire de la barrette de ram devient "pourquoi ne pas avoir acheté des millions de barrettes de ram" ce qui reviens d'un coup à "pourquoi ne pas avoir dépenser beaucoup plus de pognon en achat, en logistique et en test". D'ailleurs, il suffit de voir qui teste networkd sur la list, et tu va voir des emails @intel.com, @axis.com .
Ou simplement que malgré le fait qu'on trouve des Giga de ram, on trouve pas encore des giga sur les contrôleurs embarqués et sur toutes les pièces d'un appareil.
Et d'autre part, la tendance est à faire des conteneurs pour augmenter la densité du nombre de service par machine. Donc quand tu tapes dans les 2/3, ça va, ça fait pas grand choses. Quand tu tapes dans les centaines, tout d'un coup, ça commence à faire un multiplicateur qui rends la chose un chouia moins futile que tu sembles le croire, aussi bien en temps de démarrage qu'en occupation mémoire.
Donc oui, je pense que Moonz a raison de pointer l'overhead de systemd lui même par rapport à /bin/init du bon vieux temps, et que même si ça semble futile, ça reste un point à regarder. Mais comme j'ai dit plus loin, j'ai changé juste un paramètre à la fois pour comparer.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 4.
Non, car je ne parle de l'amélioration par rapport à ce que j'ai maintenant sur ma Fedora 20, histoire de comparer à feature grosso modo égales.
Sinon, je pourrait aussi dire "bah je flash coreboot et je boote direct sur un kernel qui lance un shell en 2 secondes" comme sur la demo ici ( https://www.youtube.com/watch?v=IKBtQYNrsBU ) et conclure "tout est bloated, il suffit juste que tout le monde tourne sur exactement mon pc et mon setup".
Il y a bien sur sans doute toujours moyen de faire plus spécialisé et qui prends le moins possible de place ( genre coder en dur les ip partout, voir pousser directement ça sur la stack du kernel ), mais l'exercise me parait futile.
Ensuite, je reconnait que le script network fait beaucoup plus que networkd. Par exemple, il gére l'isdn [~1.4M pour le rpm), le ppp (380k pour le soft), le dhcpv6, le bonding via teamd ( 250k ) ou ipx. Donc c'est pas vraiment à feature égal.
Mais sachant que je doute que l'isdn, le ppp ou ipx dans l'initrd soit vraiment présent dans la majorité des cas, je vois pas l’intérêt de prendre ça en compte. Et malgré le fait que ça soit fait de manière ad-hoc, comprendre "à l'arrache", en ne copiant pas ce qui ne doit pas être copié sans avoir vraiment de vision haut niveau de ce qui est requis, le script network marche sans la majorité des dépendances. Alors que bash et awk sont requis.
J'ai non plus pas compté les 400k de iputils, car je part du principe que même si c'est pas requis pour que networkd fonctionne, dans le cas d'une machine de rescue, on peut en avoir besoin. mais si le but est juste de comparer la taille sans prendre en compte le rescue (ce qui me semble tricher un peu, car je pense qu'on a besoin des outils), on peut retirer ça et mettre networkd, et voila.
Et en compilant systemd sans selinux, on retire les 400k de la libpcre, et les 140k de la libselinux, et j'imagine qu'avec kdbus, on peut sans doute retirer les 430k de dbus-daemon.
Je suis pas sur pour la libdbus car systemd a sa propre lib pour le support de dbus et de kdbus, et je suis pas assez courageux pour faire un make install sur ma bécane de prod, ni assez motivé pour faire une vm pour vérifier l'hypothèse.
Donc oui, dans le cas d'un initrd avec systemd/udev/etc, mettre networkd à la place du script network permet d'avoir un solution plus économe à mon sens. Mais tu peux sans doute faire mieux en sacrifiant des features qui te paraisse superflu (sans discuter du fait qu'elles le soit ou pas pour d'autres, et je reconnais bien volontiers que pas grand monde n'a besoin des vlans dans l'initrd par exemple)
C'est comme démarrer directement erlang depuis xen directement. C'est custom made, c'est rapide, ça permet d'avoir des choses qu'on arrive pas à avoir autrement mais voila, la majorité des gens vont pas utiliser ça.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Rajoute "et parce que toute les machines ne sont pas équipés en IMPI ou carte d'admin couteuses, ce qui permet d'adresser le marché des hobbyistes ayant leur serveur sous forme d'un shuttle dans le salon".
Et comme je peux pas me fatiguer à répondre à la même question sur le réseau, avoir un rescue sur le systéme qui a le réseau ça permet par exemple de télécharger le fichier de la glibc qu'on a écrasé par erreur depuis le rescue.
Bien sur, on arrive à se débrouiller autrement quand on a pas le réseau, mais je peux imaginer que ça peut faciliter la vie.
Et ça prends aussi moins de place dans l'initrd, au moins sur Fedora.
systemd-networkd fait 343k après passage de strip, bash + /etc/init.d/network + divers scripts dans /etc/sysconfig/network-scripts/ , ça fait 960k + ~100k de scripts.
Et si on me dit "mais networkd- tire la libpcre, ça fait 410k de plus", je dirais que les scripts d'init tire gawk, qui fait 570k.
Et que le fait de tirer pcre est listé comme bug dans la TODO list de systemd :
https://github.com/systemd/systemd/blob/master/TODO#L152
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 8.
Nan mais commence pas à ruiner tout l'argumentaire avec des vrais features et des use cases qui sont pas tirés par les cheveux, tu te rends compte que Linuxfr vit grace aux contributions, et que systemd a augmenté les contributions sur les commentaires :)
[^] # Re: Le nid à trolls
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 7.
Les arguments à l'époque était sur les appels de fonctions dbus. La, on parle de fonctions en C et la différence entre avant et maintenant, c'est ce sur quoi tu lies ton binaire.
[^] # Re: systemd-networkd ?
Posté par Misc (site web personnel) . En réponse au journal systemd ca a l'air super.... Évalué à 10.
Networkmanager fait beaucoup plus de choses, genre le wifi, le bluetooth, le ppp. Il gère les proxys dns ( via dnsmasq) et le partage de connexion.
La, je pense que l'idée est surtout de remplacer /etc/init.d/network ( sur fedora ), et l'idée n'est pas non plus de Lennart, mais de Tom Gundersen, packageur Arch.
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 8.
En même temps, faut pas se voiler la face. AppArmor a failli disparaitre sans Canonical qui voulait avoir une alternative à SELinux, car Novell avait finalement décidé de lacher l'affaire. At AppArmor est en retard niveau intégration partout ailleurs, car Canonical n'a pas vraiment les ressources.
Pr exemple, dbus a d'abord supporté SELinux, puis AppArmor. Postgresql supporte la séparation par SELinux, pas par AppArmor. Des distros comme Gentoo, Debian ou Fedora ont supportés SELinux bien en premier, puis vaguement Apparmor. Les seuls à avoir AppArmor de base sont celles ou le sponsor a décidé d'en haut de pousser la techno, ie Ubuntu et Opensuse. IE, la communauté poussant AppArmor est pas très grande.
Et je peux détailler en long, en large et en travers pourquoi à mon sens AppArmor est plus primitif et moins extensible que SELinux.
Par exemple, AppArmor utilise des chemins pour les permissions et les accès la ou SELinux rajoute une couche d'indirection, ce qui le rends impropre a un usage comme "ce document est noté top secret, personne doit le lire". Apparmor ne supporte pas trop le concept de MLS ( mais sur la TODO list http://wiki.apparmor.net/index.php/AppArmorMLS ). Et c'est pas un exemple purement théorique non utilisé en pratique, car tout openshift dépend de ça pour l'isolation des gens.
Autre example, changer le repertoire racine d'un serveur web. Sous SELinux, tu changes le label du répertoire via semanage fcontext, et voila. Sous AppArmor avec le système de profile, tu doit modifier tout les profiles pour copier les permissions. Mais donc du coup, pour palier à ce cas, ils ont rajouté le concept d'alias. Donc tu va dire que /var/www/ est un alias vers /home/www et donc que les accès de l'un correspondent aux accès de l'autre. Donc la ou une solution élégante est en place, on rajoute un truc de plus.
Je pourrais dire comment les politiques de sécurité SELinux sont configurable via des booleans, etc, etc. Et comment la config de apparmor, c'est juste des variables prédéfinis. En théorie, on peut faire la même chose avec AppArmor, sauf qu'en pratique, c'est quasiment du tout ou rien.
Je pourrait rajouter comment le fait de rajouter un nouveau type d'objet ( genre les sockets réseau ) implique de rajouter une option au parser, des nouveaux types d'objet dans la lib et de tout recompiler, la ou SELinux fait ça de façon indépendante du code dans le kernel et le reste, tout dans sa policy ( et avec du code pour l'arbitrage dans le programme qui va se servir de la policy, bien sur ). Comprendre comment faire ça, c'est globalement un workshop de 2h pour quelqu'un qui sait écrire une policy.
Alors ouais, SELinux semble s'avancer pour devenir quasiment un choix "normaliser" ( mais ça reste plus que relatif, car le défaut pour la majorité des distros, ça va surtout être "rien" ). Mais c'est surtout que ç'est plus extensible, ce qui permet de faire plus de choses, ce qui fait qu'il y a un marché pour ça, et donc des investissements.
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 5.
Upstart propose une option de configuration (stanza en jargon Upstart) qui permet pour un job de charger un profile et de démarrer directement le job avec ce profile :
https://code.launchpad.net/~mdeslaur/upstart/apparmor-support/%2Bmerge/164169
Par exemple, je donne le chemin direct vers le profile, upstart le charge, l'utilise et lance le processus. C'est une ligne à rajouter.
Commencer à devoir utiliser aa-exec, ça deviens vite chiant. Déja, si ton job upstart contient plusieurs lignes de commande, tu es obligé de faire un wrapper ( et donc il n'est plus "self contained" ), et tu dois charger à la main, en n'ayant pas le diagnostique de pourquoi ça ne marche pas, etc, etc.
Pareil avec systemd, qui propose dans la version git "SeLinuxcontext" pour démarrer le process dans un domaine particulier. En faisant ça dans systemd directement, tu as la capacité d'interroger systemd par dbus pour avoir l'info, tu as un retour plus haut niveau via journalctl ( ie, un vrai code d'erreur ), tu as une gestion intégré via les templates, etc, etc.
Pour le moment, tu peux pas dire "ce job est dans ce profile apparmor", mais un patch a été envoyé ( et il attends une version 3.0 avec divers modifs ).
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 7.
tu veux dire que c'est pas juste parce qu'il s'agit d'une personne qui a démontré sa capacité à comprendre le libre et à bosser dans la communauté dans un domaine qui manque cruellement de gens (à savoir les juristes spécialisés dans le domaine de la propriété intellectuelle et le libre) ?
Donc tu veux dire qu'un avocat qui passe plusieurs années à apprendre son métier et à l'exercer n'arrive pas à transmettre tout ce savoir en 5 minutes à un nombre arbitraire de gens, comme le montre un bug report isolé ?
Wow, tant de révélations…
[^] # Re: fin de l'histoire ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 3.
Pour compléter ce que tu dis
http://blogs.adobe.com/penguinswf/2007/05/welcome_to_the_jungle.html
Mais le schéma a disparu du site lui même.
[^] # Re: fin de l'histoire ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 0.
Il te faut pas grand chose pour avoir de l'espoir. Klang a été annoncé en juillet 2012, et le site web dit encore "on va avoir un design document dés que possible".
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
L'argument en question marche aussi pour la FSF. J'ai envoyé un patch pour grub2 et j'ai du attendre quelques semaines le temps de faire les papiers pour qu'il soit intégrer. Moi, ça me dérange pas, mais je connait des gens que ça dérange.
Et si tu parlais avec des gens du libres en dehors de linuxfr (genre sur irc, au fosdem, voir dans mon cas, au boulot) et surtout sans un filtre ou tu retiens que ce qui te permet de troller, tu verrais que les procédures de la FSF sont pas universellement acceptés. La différence est que dans le cas de la FSF, personne ne va te dire "je n'aime pas parce que je me fait flouer". Les gens sont pas d'accord, mais ils comprennent la position de la FSF pour le bien du logiciel libre.
Dans le cas de Canonical, les gens ont vachement moins confiance dans la boite. Par exemple, les annonces de "on va aider ça" ou ça se résume à "on va proposer ça dans Ubuntu", les revirements sur gnome-shell/unity, sur wayland/mir, sur bar/bzr.
Un codeur mercurial francais m'a dit qu'à un moment, il y a eu des propositions de fusionner mercurial et bzr, et que les discussions se sont arrêtés quand Mark a dit "bien sur, le résultat sera entièrement sous le copyright de canonical". Et c'est ce genre d'incidents repetés tout au long de l'histoire de la boite (le coup avec opensuse, le coup avec banshee et rhythmbox) qui font que non, même si digia a le même genre de CLA, les gens parlent pas de ce CLA.
Dans le cas de Canonical, personne ne te dit "on veut pouvoir faire du proprio parce qu'on a besoin un jour d'être à l'équilibre". Et personne chez eux ne veux rappeler le fait que pour le moment, la boite survit depuis 10 ans en tournant à perte. Et il faut dire que quand on se positionne comme champion du libre, ça fait un peu tache de dire ça.
Donc c'est même pas de le faire, c'est surtout l'hypocrisie complète, le fait qu'aux oreilles de beaucoup, tout ça sonne comme un mensonge. Et si tu rajoutes tout les faux pas (comme celui avec Mint et la trademark, avec le mec de la FSF et la trademark), tu aboutis à une situation ou la moindre chose que Shuttleworth fait ou dit part en vrille en plus de son coté polarisant habituel (parler de "losing graciously" implique d'avoir une compétition explicite, ce qui est totalement idiot)
Mais tout ces détails, je ne pense pas que tu les retiennes, vu que tu va continuer à troller sur "pourquoi les gens parlent que du CLA de Canonical et pas de Digia" à la prochaine news sur le sujet, j'ai déjà le sentiment d'avoir parler dans le vide.
[^] # Re: C'est la vie...
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
et c'est pour ça qu'on utilise tous le même démon ssh, parce que la diversité est un atout majeur.
[^] # Re: Politique
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 7.
Alors faut bien voir que d'abord, ça va pas arriver dans la stable avant 8 mois ( vu que faut d'abord sortir la 14.04, ensuite la suivante ). Ensuite, c'est en partant du principe que dans 8 mois, c'est fini, et au vue des cadences d'Ubuntu et du fait qu'il faut quand même d'une part coder ce qui manque ( genre le support de AppArmor au même niveau que dans upstart qui peut faire ça job par job ), et migrer tout les jobs customs, etc.
Faut voir par exemple que Unity utilise upstart comme gestionnaire de session utilisateur aussi.
Et je pense que Ubuntu va attendre que Debian fasse le taf, ce qui implique d'attendre la release de la stable ou au moins le gel. Et d'ici la, il va y avoir plein de changements dans le kernel et dans systemd, comme kdbus et les cgroups. KDus qui semble aussi ne pas aller dans le sens des demandes de Canonical pour la gestion fine des ACLs via apparmor, donc ça fait du taf en plus aussi.
[^] # Re: C'est la vie...
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 4.
Upstart étant lui même inspiré de Launchd. Et launchd vient sans doute des idées de SMF.
Quand à aller de l'avant, PLD et Gentoo avait déjà repris l'idée de simplification des scripts d'init il y a longtemps.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 7.
Globalement, non. Et vu que parmi les juristes de RH, tu as Richard Fontana qui a co-écrit la GPL v3, je pense que l'équipe comprends le libre et ce que ça fait.
Il y a aussi des gens qui comprennent ce qui fait qu'une communauté marche, et qu'un CLA de quelque nature que ça soit, ça reste un obstacle de plus à la contribution ( comme le fait de devoir ouvrir un compte spécifique ou ce genre de choses, comme expliqué par Dave Neary sur http://blogs.gnome.org/bolsh/2012/09/14/attention-speed-bump-ahead/ ( qui justement bosse dans la dite équipe OSAS de Red hat, qui justement vise à conseiller les projets upstream en matière de communauté ).
D'ailleurs, il est amusant de voir que Jono Bacon, community manager chez Canonical, le dise aussi dans son bouquin, mais visiblement, qu'il n'a pas réussi à convaincre sa hiérarchie.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 5.
A ce moment, suffit juste de refuser les patchs, ça se fait très bien.
[^] # Re: NIH ?
Posté par Misc (site web personnel) . En réponse au journal Ubuntu passera lui aussi sur systemd. Évalué à 10.
Le NIH s'applique peut être à SysVinit et pas à systemd :p
Mais je ne pense pas que ça soit la raison principale en effet de garder Upstart. Ce qu'on voit, c'est que si Debian passe à systemd (et donc fait le taf d'intégration), alors Ubuntu va suivre. Sans ça, ça aurait du être le taf d'Ubuntu, et je pense que Canonical n'avait juste pas les moyens humains de faire ça alors qu'ils ont des projets à finir.
Ça reviens à une bête question de ressource. Et le fait d'avoir des bugs non corrigés depuis longtemps dans Upstart, d'avoir finalement peu de code poussés dedans ne sont que d'autres symptômes d'une même cause.
En attendant que la QA de Debian (et de RHEL 7) fasse le taf, Ubuntu a tout à gagner.
[^] # Re: En fait la discussion continue
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 5.
Alors en fait, j'ai cherché ( car oui, je ne discute pas sans recherche minimum ), et j'ai trouvé divers choses.
Alors il y a virt-sandbox-service, qui est un wrapper entre libvirt et systemd. La dépendance est à la fois assez faiable ( car ça fait des unités systemd, rien de complexe à refaire sous upstart ) mais elle existe.
Ensuite, j'ai trouvé cockpit :
http://liquidat.wordpress.com/2014/02/11/first-look-at-cockpit-a-web-based-server-management-interface/
En fait, je savais même pas que c'était fortement lié à systemd avant de regarder en détail.
Tu as aussi des trucs comme fleet ( https://github.com/coreos/fleet ) du projet coreos, qui permet d'avoir un systemd sur le réseau ( ie, activation à la volée, ce genre de choses ).
Ou netctl :
https://github.com/joukewitteveen/netctl
Et je pense qu'à terme, tu va avoir kde/gnome qui vont utiliser logind, qui s'appuie sur la gestion de cgroups de systemd.
Donc oui, la question est pas que théorique.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Je pense qu'il y a surtout une question de marketing. IE, quand tout le monde a migré vers upstart, personne n'a rien dit parce qu'on a pas mis ça en avant, et parce que personne n'a eu le style de Lennart pour dire "les trucs sont de la merde, le mien est bien".
Quand Apple change un truc, ils vont le vendre bien, donc les gens acceptent. Lennart, lui, il compte juste sur la qualité du produit, et visiblement, ça ne suffit pas à réduire les peurs des gens. Il faut ensuite rajouter les pseudos experts qui postent pour dire "si systemd crash, l'os crash" pour avoir un panic.
Aucun n'a vérifié ce qui se passe, personne n'a lu le code pour voir qu'en pratique, systemd ne fait pas paniquer le kernel.
Voir http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n115 ( le code est la depuis 2010 ).
Donc oui, si systemd crash, il ne réponds plus, mais la machine tourne encore, les processes aussi, vu que systemd tourne en boucle en faisant "pause" pour éviter le kernel panic. Donc au final, ça reviens à être bien moins catastrophique. Et pour être franc, je me demande si il n'est pas possible de relancer automatiquement systemd pour plus de HA. ( le code n'est pas la, mais je ne sais pas si on peut le rajouter facilement et de façon robuste ).
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Curieusement, je pense que les divers études de cas qu'on trouve ici (
http://searchdatacenter.techtarget.com/Unix-to-Linux-migration-advice-and-case-studies )
( ou sur les sites de RH, de Suse et ailleurs ).
Ou alors juste sur les rapports de IDC, ou Unix représente 16% du marché, et est prévu pour chuter à 9% ( http://www.networkworld.com/news/2013/081913-unix-272728.html ). L'article explique aussi que les déploiements de db sur linux ou windows dépassent ceux sur unix. Si c'est pas de la prod, je ne suis pas vraiment sur de savoir ce que c'est.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 4.
Digital et Compaq ont disparu et leur unix de même, SCO/Caldera aussi. Je sais même pas ce que Xenix est devenu, et Irix existe plus que dans Jurassic park ( dans le film, pas dans le sens ou c'est un dinosaure ).
HP-UX, AIX et Solaris sont encore la en effet, et je dirais bien que seul Solaris arrive à faire des trucs, poussé par Oracle, mais IBM dégraisse, HP aussi, et Sun s'est cassé la gueule pour se faire racheter par Oracle.
[^] # Re: je suis le seul ou quoi ?
Posté par Misc (site web personnel) . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 9.
ça fait bien longtemps que ça s'éloigne d'Unix. C'est même la raison de son succés, pas de procés au cul par AT&T.
Mais il faut bien voir une chose. Les Unix ont pour la plupart disparus. Et si il suffisait de suivre leur philosophie pour survivre et avoir du succès, debian kfreebsd serait pas à que dalle en terme d'usage, et l'Unix-like avec le plus de succès serait pas originaire de Cupertino.
Tu peux dire ce que tu veux sur les principes d'Unix, mais visiblement, ils ont pas l'air de passionner les foules ni d'être une raison de choisir cette famille d'OS. ( et faut pas me dire "oui, mais le marketin de blabla", si le marketing de tout les OS plus récents est meilleur, c'est bien la lose d'être la avant et de se faire battre )
Mais je suis sur que Freebsd sera ravi d'avoir ton aide avec tes 18 ans d'xp, car il me semble évident que tu va faire quelque chose, pas juste attendre, n'est ce pas ?