Et c'est pas parce que ça marche que c'est pas chiant. Vérifier de manière non automatisable la chose, ça coute du temps. Tu peux voir "mon binaire a besoin de /usr/lib/libtoto.so.3" facilement. Tu peux pas voir "mon binaire lance tel logiciel depuis son code source, ou depuis les régles udevs ou depuis un script bash un soft dans /usr".
Debian a toujours fait en sorte que ça soit possible, mais ça reste un travail manuel, avec tout les risques que ça comporte ( genre loupé un cas obscur ). Au final, conceptuellement, au lieu d'avoir les choses faites dans l'initrd et dans le système, c'est fait juste à un endroit, ça me parait plus sain.
sinon, y a aussi les bons vieux RPC de Sun, pour nfs. Il y a eu corba ( bonobo ).
mais la vraie solution, c'est de mettre directement le passage de message dans le kernel, et de ressortir un micro noyau, soit à la qnx, soit le hurd.
Et je pige pas, si tout le monde veut un truc modulaire et KISS, y a le hurd. L'archi est propre, il y a du taf pour tous :
- portage de logiciel sur le hurd ( genre, ne pas utiliser MAX_PATH )
- écriture de documentation ( genre, un guide pour linuxien, comment afficher son ip, etc )
- des tests, des présentations, etc
ou du plus complexes, genre écriture de pilote, etc.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
En l’occurrence, dans le cas que tu donnes, c'est prévu, tu peux désactiver le fait de trouver le pid via GuessMainPid=no, et juste utiliser un fichier de pid comme avant. Nombre de modif de systemd : 0, tout le taf est poussé sur le mec qui fait l'unit, en l’occurrence pour un soft proprio ou l'upstream ( ou le packageur ).
C'est dans les premières lignes de la page de man, avec les options "forking", "oneshot", ou "remainAfterExit".
Donc si, on peut lui dire de faire ça, car ça reste assez flexible.
Ensuite, si le souci, c'est l'orchestration de services sur le réseau ( ie, ce que tu parles quand tu dis "cluster", c'est pas le but de systemd ou de sysv init, plus le but d'outils comme juju, mcollective, noah, et des dizaines d'autres qui fleurissent depuis l’avènement du cloud.
Enfin, tu parles de certif Oracle, mais sachant que OEL est juste une bête recompilation de RHEL avec une paire de patches et de modifs ( genre, btrfs par défaut ), tu penses vraiment que Oracle va dire "on certifie pas notre db sur notre distro" si jamais sa distro d'origine passe à systemd par défaut ?
( et visiblement, c'est fort probable au vue de patch comme https://www.redhat.com/archives/libvir-list/2012-June/msg00374.html ).
Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents ( car comme la dépêche sur opensuse le laisse supposer, suse semble aussi bien parti pour basculer ), une doc et des outils d'admins différents etc.
En fait, la méthode à base de echo, elle est furieusement semblable à ce que tu doit sans doute faire en écrivant dans un fichier la liste des PIDs. ( et sincèrement, ne dit pas "j'ai pas le temps d'apprendre". Si on a le temps de poster sur linuxfr, on a le temps de lire la doc )
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère. En te démerdant bien, systemctl isolate doit même pouvoir faire des trucs plus chiadés qui devrait te permettre de faire encore plus complexe. Ou attends, même mieux, tu changes la config, et tu recharge le service. Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Mais sans doute qu'il y a une raison non exprimé qui fait que faire la même chose, ça va pas marcher ?
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ). Ou tu le fait via modprobe.conf, pour lancer le script avant de charger le module pour ip ( tout comme certaines distros font pour alsa, pour charger le volume, ou pour les firmwares ). Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch ( à commencer par toi, en fait ), et pourtant, tu es pas bloqué le moins du monde. En fait, tu peux aussi juste rajoute rune unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire, ça va pas casser à l'upgrade d'un rpm. Marvelous, non ?
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp ), la réponse est "la même chose que si tu as lancé apache via xinetd", vu que ( http://0pointer.de/blog/projects/inetd.html ) c'est le même système. En d'autres termes, tout comme lancer apache via xinetd va pas marcher si tu lance apache à coté une 2eme fois ( vu que le port tcp va être ouvert par xinetd ou systemd ), ça va pas marcher des masses de faire ça via systemd.
Mais comme la config par défaut pour apache, c'est justement de faire lancer apachectl ( ou plutot httpd -k ), le souci ne se poseras pas par défaut. Et en fait, si tu configures ça pour marcher en mode socket et que tu utilises le script qui est prévu pour marcher avec l'autre mode ( ie standalone ), c'est plus toi qui fait exprès un truc qui ne va pas marcher par design du mode xinetd d'apache ( ie le souci n'est pas lié à systemd, vu qu'il se pose aussi . Comme se dire "bah j'utilise nginx, pourquoi apachectl marche pas". Réponse, parce que tu as 2 modes différents pas prévus pour être mélangés dans apache, et c'est à apache de gérer le cas comme il faut.
En pratique, le mode inetd n'est plus dans apache 2 ( plus de directive ServerType cf http://httpd.apache.org/docs/2.0/en/upgrading.html ), et donc, ton exemple reste un exemple purement théorique. Mais tu peux continuer à dire que systemd fait mal les choses car les programmes peuvent proposer 2 modes incompatibles de lancement.
Sinon, je voit pas de boilerplate ajouté dans systemd dans tes exemples, je vois juste du boilerplate que tu as ajouté dans ton système, ce qui pour moi est différent ( ie, tu es responsable des kludges que tu fait, le reste du monde s'arrange pour faire des trucs propres ).
Y a des outils proprios pour ça, genre splunk. D'ailleurs, comme c'est un problème que personne n'a, la boite est pas du tout en train de faire des bénefs et d'avoir plus d'employés que Canonical ( pour donner un point de comparaison ). Comme c'est aussi un souci qui n'existe pas, la boite est profitable sans doute grâce au trafic de drogue.
La réponse est "pour l'instant, on est encore en train de bosser sur le format de stockage, donc on va pas le documenter tant qu'on est pas sur qu'il est viable car on veut pas que des gens commencent à l'utiliser tant que c'est pas fini".
Ça ne me parait pas déconnant de d'abord avoir du feedback avant de décider "c'est bon, ça bouge plus". On le fait sans arrêt avec les APIs, donc ça me parait une approche des plus viables, si ça s’éternise pas.
Sinon, tant pis, ça va se terminer comme le format sur disque de sqlite, mysql ou postgresql, à savoir, personne ne va avoir rien à faire de le documenter. ( ou le format sur disque de svn, de la base rpm, d'openldap si les gens veulent des exemples autre que des SGDB ou assimilés ).
Je pense que la cross compilation dépend des composants, mais sachant que systemd est dans openembedded, il y a des gens qui ont du faire de la cross compilation pour ça. Je traine sur #openmoko-cdevel, et dans mon souvenir, y a des gens qui ont fait le port de systemd pour SHR ( cf http://wiki.freesmartphone.org/index.php/FSOSHRCON_2011 ).
Ma foi, parce que peut être, y a des gens qui veulent avoir une interface graphique capable de gerer le wifi, etc ?
Mais si tu aimes pas nm, tu as connman, tu as wicd, et pareil, ils tournent pas sur les bsd.
Donc à la fin, c'est "est ce que les gens sur un système bsd (autre que celui d'apple) veulent tous gérer le wifi à la mano en cli" ?
Perso, nm marche sur mon portable et me taper wpa_supplicant à la main, ça va 5 minutes ( surtout vu que j'ai besoin d'une authentification à 2 facteurs pour le wifi au travail ), tout comme devoir faire les 3/4 commandes pour un wifi classique, ça me ferait chier ( à commencer par me connecter en root ).
En fait, c'est la même diffrence qu'entre java et python. java, faut rajouter toujours le même boilerplate pour les trucs simple, genre un hello world.
Ou la différence du xml et un DSL parfaitement prévu pour. Si tu commences à faire du copier coller, y a 2 choses :
- tu va jamais avoir besoin de toucher à ça, donc tu gaspilles juste de l'espace et tu rajoutes du bruit, autant faire un système qui retire tout ( ce que gentoo ou plf ont fait, par exemple )
- tu va devoir toucher au code un jour, et la, bah tu as juste des centaines de copies, et tu as fait de la merde
Dans mon souvenir, oui, et c'est Frederic Crozat qui a bossé dessus ( entre autre ). Il y a une page sur l'état sur le wiki : http://en.opensuse.org/SDB:Systemd
Ça fait 20 ans que les BSD et les systèmes Linux existent, et c'est quand la dernière fois qu'il y a eu des gens autour de la table pour discuter de standard communs entre les 2 ?
Quand tu vois que les gens sont pas capable de se mettre d'accord sur les conventions d'appel, sur la présence ou pas de fonction de manipulation de chaines ( strnlen ), sur la version de gcc, ou sur justement les initscripts, et les apis, je vois pas ce que Lennart va changer à ça.
D'ailleurs, la dernière fois qu'il a fait un soft portable ( genre avahi ), y a eu un gsoc pour coder un truc compatible sous une license BSD : http://wiki.freebsd.org/MulticastDNS
Donc oui, ce que les BSDistes veulent, c'est pas du code GPL, c'est des interfaces.
Grande nouvelle, y en a :
En même temps, la discussion, même basé sur des arguments faux, reste pertinente dans le sens ou ça a un rapport avec le sujet. Et le commentaire, même faux, n'est pas inutile car il permet de présenter des contre vérités ce qui permet de les dissiper.
( sinon, pour avoir +10, faut aussi faire des blagues, ça marche bien )
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde. Ensuite, tu peux utiliser selinux, chroot, lxc pour isoler les processes, mais tu va pas demander quand même à isoler un process mais vouloir que tout le monde puisse y toucher.
je te conseille aussi de lire la doc de systemd sur les montages ( genre, le montage en non auto ), et aussi d'avoir ton vocabulaire au point, tu crées pas une carte réseau, tu crées au mieux une interface réseau ( la carte réseau étant pour moi un objet physique ). Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique", j'ai le sentiment que tu confonds un peu tout.
Quand à avoir un script d'init par machine, que dire à part que c'est soit déjà le cas ( si tu veux un truc propre ), soit pas une chose que systemd va changer, car tu peux encore déposer ton script compatible LSB dans /etc/init.d comme avant. La preuve, c'est que tout n'a pas été migré sur une fedora 17.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Et donc, ton histoire de rajouter du boilerplate sachant que systemd est sorti depuis au moins 1 an, tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ? ( car affirmer, c'est une chose, mais avec des preuves, ça serait sans doute plus crédible, et ça serait pas de trop )
J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?
Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.
En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.
"pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.
Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.
En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).
Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.
Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?
D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )
Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )
Tu serais pas un peu aigri et totalement subjectif ?
Selon toi, le plus gros problème de systemd, c'est que les gens jugent pas le soft mais l'idée qu'ils se font d'un des auteurs sur la base d'extrait de discussions qu'ils ont pas suivi, mais dont il garde une sous partie qui leur semble choquante, c'est ça ?
Perso, je dirais pas que c'est un problème de systemd, plus un problème de gens.
Encore une fois, les technos linux only et bsd only abondent depuis des années. Samba utilise sendfile sur linux et pas sur bsd, personne trouve rien à redire. Nufw ne tourne que sur netfilter donc Linux, personne ne trouve rien à redire ( et dieu sait que mon patron, créateur du soft, a trollé pf plus d'une fois ).
NetworkManager tourne pas sur freebsd, wicd non plus, et je doute que connman soit dispo. Et pourtant, personne n'a jamais dit "faut pas coder ces outils". Ni personne n'a dit "je vais aller faire des patches".
Bluez tourne pas ( que je sache ) sur Openbsd, c'est pareil, ou sont les gens pour crier au complot de Nokia et Intel ?
Le montage des vpns marchent très bien ( en tout cas avec openvpn ), donc je vois pas ou serait le souci. Tu as 1 unité par vpn, ça démare quand le réseau se lance, ça se relance si ça tombe ( systéme de watchdog ), et conceptuellement, je sais pas trop ce qu'un autre vpn changerais ( genre, un daemon ipsec, ça reste un daemon ). Au pire, l'intégration est la même qu'avec les autres logiciels.
Quand aux fs chiffrés, si le souci est "systemd ne peux pas monter automatiquement un truc qui demande une intervention manuel" ( cf exemple donné plus tard ), je vois pas ce qu'un logiciel peut faire contre ça. Si un truc a besoin d'une intervention à la main, oui, tu va pas pouvoir faire grand chose pour automatiser ça. Et marqué le fs en "noauto" devrait suffire à régler le souci. Une fois que tu montes ça à la main ( avec ton mot de passe tapé ), systemd va réagir, si je comprends bien la doc de systemd.mount :
Mount points created at runtime independent on unit files or /etc/fstab
will be monitored by systemd and appear like any other mount unit in
systemd.
Donc soit je comprends de travers les soucis ( car la description est des plus lapidaires ), soit on n'a pas répondu comme il faut à tes questions.
Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais, et qui a décidé par exemple opensuse ou mageia à le faire. ( parce que globalement, c'est ce que tu décrit, et j'ai pas vu passer ce genre de mail, les gens ont choisit volontairement de basculer que je sache ).
Par exemple, pour Opensuse, est ce que quelqu'un s'est plaint de pression de la part d'une autre boite ? Est ce que tu as , genre, des preuves, des mails publiques ?
Tu fais aussi abstraction des discussions qu'il y a eu sur Fedora, sur Mageia, sur openwrt en toute transparence sur le passage ( ce qui ma foi, ne me parait pas faire preuve de beaucoup de rigueur dans l'hégémonie, mais bon, c'est bien connu que soit on est d'accord avec une décision technique, soit les devs et les packageurs sont des cryptofachistes doublés d'incapables de voir la vérité et de coder ).
Tu fais abstraction du fait que les devs de arch ont discuté de ça. Tu fais abstraction du fait que quand Fedora est passé à upstart, personne n'a ralé ( alors que upstart n'est pas compatible bsd, dépend de dbus, change les outils en ligne de commandes, n'utilise pas du tout de shell et fait juste moins de choses que systemd ). Et que upstart avait prévu de remplacer cron, at ( http://upstart.ubuntu.com/faq.html#replace-cron ), ce qui n'a fait bondir personne.
Au passage, personne n'a suivi, alors que pourtant, RHEL 6 utilise upstart.
Donc tu peux sans doute expliquer pourquoi un truc utilisé par Ubuntu, RHEL/Centos, et Fedora pendant un temps est vu comme moins hégémonique qu'un truc utilisé au début juste par Fedora ?
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 3.
Et c'est pas parce que ça marche que c'est pas chiant. Vérifier de manière non automatisable la chose, ça coute du temps. Tu peux voir "mon binaire a besoin de /usr/lib/libtoto.so.3" facilement. Tu peux pas voir "mon binaire lance tel logiciel depuis son code source, ou depuis les régles udevs ou depuis un script bash un soft dans /usr".
Debian a toujours fait en sorte que ça soit possible, mais ça reste un travail manuel, avec tout les risques que ça comporte ( genre loupé un cas obscur ). Au final, conceptuellement, au lieu d'avoir les choses faites dans l'initrd et dans le système, c'est fait juste à un endroit, ça me parait plus sain.
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
Ce que dracut peut faire. C'est expliqué ici :
http://unix.stackexchange.com/questions/18057/dracut-and-separate-usr
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
Tu veux dire ça :
http://wiki.gobolinux.org/index.php?title=The_GoboLinux_Filesystem_Hierarchy
Ou ça :
http://osxdaily.com/2007/03/30/mac-os-x-directory-structure-explained/
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
10 + 3 ans sur RHEL, 8+2 ans sur SLES
Détails de ce qui est couvert sur les urls suivantes :
https://access.redhat.com/support/policy/updates/errata/
http://support.novell.com/lifecycle/#policy
Et pour être complet, la policy Canonical :
http://www.canonical.com/enterprise-services/support/server/support-life-cycles
3 ans sur le desktop, 5 sur les serveurs.
[^] # Re: La lutte contre Lennart m'énerve un peu
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Y a binder \o/
http://developer.android.com/reference/android/os/Binder.html
sinon, y a aussi les bons vieux RPC de Sun, pour nfs. Il y a eu corba ( bonobo ).
mais la vraie solution, c'est de mettre directement le passage de message dans le kernel, et de ressortir un micro noyau, soit à la qnx, soit le hurd.
Et je pige pas, si tout le monde veut un truc modulaire et KISS, y a le hurd. L'archi est propre, il y a du taf pour tous :
- portage de logiciel sur le hurd ( genre, ne pas utiliser MAX_PATH )
- écriture de documentation ( genre, un guide pour linuxien, comment afficher son ip, etc )
- des tests, des présentations, etc
ou du plus complexes, genre écriture de pilote, etc.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 5.
Sincèrement, j'apprécierais d'avoir une discussion ou je suis pas obligé de sans arrêt sortir la documentation pour dire "voila comment faire tel chose" pour dire que la personne avec qui je discute qu'elle semble être dans le faux.
En l’occurrence, dans le cas que tu donnes, c'est prévu, tu peux désactiver le fait de trouver le pid via GuessMainPid=no, et juste utiliser un fichier de pid comme avant. Nombre de modif de systemd : 0, tout le taf est poussé sur le mec qui fait l'unit, en l’occurrence pour un soft proprio ou l'upstream ( ou le packageur ).
C'est dans les premières lignes de la page de man, avec les options "forking", "oneshot", ou "remainAfterExit".
http://0pointer.de/public/systemd-man/systemd.service.html
Donc si, on peut lui dire de faire ça, car ça reste assez flexible.
Ensuite, si le souci, c'est l'orchestration de services sur le réseau ( ie, ce que tu parles quand tu dis "cluster", c'est pas le but de systemd ou de sysv init, plus le but d'outils comme juju, mcollective, noah, et des dizaines d'autres qui fleurissent depuis l’avènement du cloud.
Enfin, tu parles de certif Oracle, mais sachant que OEL est juste une bête recompilation de RHEL avec une paire de patches et de modifs ( genre, btrfs par défaut ), tu penses vraiment que Oracle va dire "on certifie pas notre db sur notre distro" si jamais sa distro d'origine passe à systemd par défaut ?
( et visiblement, c'est fort probable au vue de patch comme https://www.redhat.com/archives/libvir-list/2012-June/msg00374.html ).
Ou tu penses que Oracle va juste décider de maintenir un system de boot différent à base d'initscripts pur, quitte à proposer moins de fonctionnalités que ses concurrents ( car comme la dépêche sur opensuse le laisse supposer, suse semble aussi bien parti pour basculer ), une doc et des outils d'admins différents etc.
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 5.
Pour bouger des pid dans le cgroup, c'est écrit dans la doc qui se trouve facilement via "cgroup pid move" sur un moteur de recherche. Exemple de résultat :
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-Moving_a_Process_to_a_Control_Group.html
En fait, la méthode à base de echo, elle est furieusement semblable à ce que tu doit sans doute faire en écrivant dans un fichier la liste des PIDs. ( et sincèrement, ne dit pas "j'ai pas le temps d'apprendre". Si on a le temps de poster sur linuxfr, on a le temps de lire la doc )
Pour tes trucs trop compliqués ou spécifiques, je pense qu'il a été dit facile 20 fois "tu peux garder ton script sysv". Voir même, tu peux lancer un script shell via systemd. Exemple de truc qui serait sans doute digne de la complexité dans laquelle tu aimes baigner :
http://kezhong.wordpress.com/2011/11/19/creating-my-own-systemd-service-files-on-fedora-16x86_64/
pareil, moteur de recherche, temps, linuxfr, etc
Pour ton histoire de maintenance, la solution est pourtant simple, tu peux faire un second service avec juste la config qui diffère. En te démerdant bien, systemctl isolate doit même pouvoir faire des trucs plus chiadés qui devrait te permettre de faire encore plus complexe. Ou attends, même mieux, tu changes la config, et tu recharge le service. Ou mieux, tu fait comme avec sysvinit, tu stoppes le service et tu lances à la main, puis tu fais l'inverse.
Mais sans doute qu'il y a une raison non exprimé qui fait que faire la même chose, ça va pas marcher ?
Si tu veux lancer un tunnel gre non ip, ben tu fait un unité qui le fait, et tu t'arrange pour que ça soit fait avant network ( en rajoutant, genre "before" dans l'unité ). Ou tu le fait via modprobe.conf, pour lancer le script avant de charger le module pour ip ( tout comme certaines distros font pour alsa, pour charger le volume, ou pour les firmwares ). Actuellement, tu as sans doute du écrire ton propre script, et visiblement, ton cas d'usage est assez rare pour que personne ne propose de patch ( à commencer par toi, en fait ), et pourtant, tu es pas bloqué le moins du monde. En fait, tu peux aussi juste rajoute rune unité network qui remplace celle de systemd, et grâce à l'usage judicieux de répertoire, ça va pas casser à l'upgrade d'un rpm. Marvelous, non ?
Enfin pour l'exemple d'apache avec préservation des sockets ( je suppose que tu veux dire dans ce cas précis port tcp ), la réponse est "la même chose que si tu as lancé apache via xinetd", vu que ( http://0pointer.de/blog/projects/inetd.html ) c'est le même système. En d'autres termes, tout comme lancer apache via xinetd va pas marcher si tu lance apache à coté une 2eme fois ( vu que le port tcp va être ouvert par xinetd ou systemd ), ça va pas marcher des masses de faire ça via systemd.
Mais comme la config par défaut pour apache, c'est justement de faire lancer apachectl ( ou plutot httpd -k ), le souci ne se poseras pas par défaut. Et en fait, si tu configures ça pour marcher en mode socket et que tu utilises le script qui est prévu pour marcher avec l'autre mode ( ie standalone ), c'est plus toi qui fait exprès un truc qui ne va pas marcher par design du mode xinetd d'apache ( ie le souci n'est pas lié à systemd, vu qu'il se pose aussi . Comme se dire "bah j'utilise nginx, pourquoi apachectl marche pas". Réponse, parce que tu as 2 modes différents pas prévus pour être mélangés dans apache, et c'est à apache de gérer le cas comme il faut.
En pratique, le mode inetd n'est plus dans apache 2 ( plus de directive ServerType cf http://httpd.apache.org/docs/2.0/en/upgrading.html ), et donc, ton exemple reste un exemple purement théorique. Mais tu peux continuer à dire que systemd fait mal les choses car les programmes peuvent proposer 2 modes incompatibles de lancement.
Sinon, je voit pas de boilerplate ajouté dans systemd dans tes exemples, je vois juste du boilerplate que tu as ajouté dans ton système, ce qui pour moi est différent ( ie, tu es responsable des kludges que tu fait, le reste du monde s'arrange pour faire des trucs propres ).
[^] # Re: Autre approche
Posté par Misc (site web personnel) . En réponse au journal Le journal. Évalué à 6.
Non mais par contre, tu as qu'un seul format de sérialisation.
Enfin un seul par lettre de l'alphabet.
Enfin pour ceux qui ont un nom bien sur.
[^] # Re: O (log (n))
Posté par Misc (site web personnel) . En réponse au journal Le journal. Évalué à 7.
Y a des outils proprios pour ça, genre splunk. D'ailleurs, comme c'est un problème que personne n'a, la boite est pas du tout en train de faire des bénefs et d'avoir plus d'employés que Canonical ( pour donner un point de comparaison ). Comme c'est aussi un souci qui n'existe pas, la boite est profitable sans doute grâce au trafic de drogue.
[^] # Re: Grep
Posté par Misc (site web personnel) . En réponse au journal Le journal. Évalué à 7.
La réponse est "pour l'instant, on est encore en train de bosser sur le format de stockage, donc on va pas le documenter tant qu'on est pas sur qu'il est viable car on veut pas que des gens commencent à l'utiliser tant que c'est pas fini".
Ça ne me parait pas déconnant de d'abord avoir du feedback avant de décider "c'est bon, ça bouge plus". On le fait sans arrêt avec les APIs, donc ça me parait une approche des plus viables, si ça s’éternise pas.
Sinon, tant pis, ça va se terminer comme le format sur disque de sqlite, mysql ou postgresql, à savoir, personne ne va avoir rien à faire de le documenter. ( ou le format sur disque de svn, de la base rpm, d'openldap si les gens veulent des exemples autre que des SGDB ou assimilés ).
Ceci dit, il y a une documentation sur le format d'export :
http://www.freedesktop.org/wiki/Software/systemd/export
[^] # Re: Cross compilation
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 3.
Je pense que la cross compilation dépend des composants, mais sachant que systemd est dans openembedded, il y a des gens qui ont du faire de la cross compilation pour ça. Je traine sur #openmoko-cdevel, et dans mon souvenir, y a des gens qui ont fait le port de systemd pour SHR ( cf http://wiki.freesmartphone.org/index.php/FSOSHRCON_2011 ).
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 2.
Ma foi, parce que peut être, y a des gens qui veulent avoir une interface graphique capable de gerer le wifi, etc ?
Mais si tu aimes pas nm, tu as connman, tu as wicd, et pareil, ils tournent pas sur les bsd.
Donc à la fin, c'est "est ce que les gens sur un système bsd (autre que celui d'apple) veulent tous gérer le wifi à la mano en cli" ?
Perso, nm marche sur mon portable et me taper wpa_supplicant à la main, ça va 5 minutes ( surtout vu que j'ai besoin d'une authentification à 2 facteurs pour le wifi au travail ), tout comme devoir faire les 3/4 commandes pour un wifi classique, ça me ferait chier ( à commencer par me connecter en root ).
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 5.
En fait, c'est la même diffrence qu'entre java et python. java, faut rajouter toujours le même boilerplate pour les trucs simple, genre un hello world.
Ou la différence du xml et un DSL parfaitement prévu pour. Si tu commences à faire du copier coller, y a 2 choses :
- tu va jamais avoir besoin de toucher à ça, donc tu gaspilles juste de l'espace et tu rajoutes du bruit, autant faire un système qui retire tout ( ce que gentoo ou plf ont fait, par exemple )
- tu va devoir toucher au code un jour, et la, bah tu as juste des centaines de copies, et tu as fait de la merde
Donc dans les 2 cas, ça pose problème.
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 4.
Genre ça : http://www.h-online.com/open/news/item/Debian-testing-a-systemd-to-sysvinit-converter-1670713.html
[^] # Re: Tout le monde n'est pas d'accord
Posté par Misc (site web personnel) . En réponse à la dépêche openSUSE 12.2 officiellement disponible. Évalué à 4.
ça date un peu, en 6 mois, les choses ont peut être pu changer, et tout a déjà été discuté 100 fois.
[^] # Re: Systemd
Posté par Misc (site web personnel) . En réponse à la dépêche openSUSE 12.2 officiellement disponible. Évalué à 3.
Dans mon souvenir, oui, et c'est Frederic Crozat qui a bossé dessus ( entre autre ). Il y a une page sur l'état sur le wiki :
http://en.opensuse.org/SDB:Systemd
En fait, c'est la depuis la 12.1 :
http://news.opensuse.org/2011/12/22/systemd-%E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
Ça fait 20 ans que les BSD et les systèmes Linux existent, et c'est quand la dernière fois qu'il y a eu des gens autour de la table pour discuter de standard communs entre les 2 ?
Quand tu vois que les gens sont pas capable de se mettre d'accord sur les conventions d'appel, sur la présence ou pas de fonction de manipulation de chaines ( strnlen ), sur la version de gcc, ou sur justement les initscripts, et les apis, je vois pas ce que Lennart va changer à ça.
D'ailleurs, la dernière fois qu'il a fait un soft portable ( genre avahi ), y a eu un gsoc pour coder un truc compatible sous une license BSD :
http://wiki.freebsd.org/MulticastDNS
Donc oui, ce que les BSDistes veulent, c'est pas du code GPL, c'est des interfaces.
Grande nouvelle, y en a :
http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 3.
En même temps, la discussion, même basé sur des arguments faux, reste pertinente dans le sens ou ça a un rapport avec le sujet. Et le commentaire, même faux, n'est pas inutile car il permet de présenter des contre vérités ce qui permet de les dissiper.
( sinon, pour avoir +10, faut aussi faire des blagues, ça marche bien )
[^] # Re: Questions
Posté par Misc (site web personnel) . En réponse au journal Linux from scratch face à udev. Évalué à 6.
Tu sembles avoir une vision faussé de ce que font les cgroups.
Je te conseille de lire ça http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
puis de voir la doc de lxc, puis de voir que lxc utilise les cgroups, mais que les cgroups ne sont pas lxc.
IE, tu peux interagir avec les processes sans souci, le cgroup dans systemd n'est la que pour dire "tel process a lancé ces 15 processes". Ensuite, oui, si tu lances les processes en dehors de systemd, bah, il va rien pouvoir faire. Tout comme si tu lances un soft a la main, l'initscript va sans doute faire de la merde. Ensuite, tu peux utiliser selinux, chroot, lxc pour isoler les processes, mais tu va pas demander quand même à isoler un process mais vouloir que tout le monde puisse y toucher.
je te conseille aussi de lire la doc de systemd sur les montages ( genre, le montage en non auto ), et aussi d'avoir ton vocabulaire au point, tu crées pas une carte réseau, tu crées au mieux une interface réseau ( la carte réseau étant pour moi un objet physique ). Quand à lancer la couche tcp/ip, tu veux sans doute dire "demander un ip" ? ( parce que la couche tcp/ip, elle est déja la, sinon ton vpn tourne sans doute pas ).
Donc si ton souci c'est "j'ai une config trop compliqué pour la config par défaut de network-manager, alors systemd est merdique", j'ai le sentiment que tu confonds un peu tout.
Quand à avoir un script d'init par machine, que dire à part que c'est soit déjà le cas ( si tu veux un truc propre ), soit pas une chose que systemd va changer, car tu peux encore déposer ton script compatible LSB dans /etc/init.d comme avant. La preuve, c'est que tout n'a pas été migré sur une fedora 17.
Enfin, si tu lit la page de man systemd.service, tu verras qu'il y a :
ExecReload=
Commands to execute to trigger a configuration reload in the
service.
Donc tu peux juste lancer le kill -SIGHUP qui va bien, ou lancer apachectl, ou ce que tu veux, pas besoin de rajouter un support dbus totalement fantasmé de ta part.
Et donc, ton histoire de rajouter du boilerplate sachant que systemd est sorti depuis au moins 1 an, tu va sans doute pouvoir trouver du boilerplate et des exceptions pour montrer ce que tu avances ? ( car affirmer, c'est une chose, mais avec des preuves, ça serait sans doute plus crédible, et ça serait pas de trop )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 5.
J'aime assez le coté péremptoire de ton commentaire qui fait croire que tu t'y connais sur systemd, suivi par "je n'investirais pas de temps à apprendre systemd". Faut savoir, tu connais systemd sur le bout des doigts pour expliquer comment dbus est obligatoire pour le debug ( ie, tu as eu à débugguer ? ), ou tu n'y connais rien et tu es juste un raleur aigri ?
Je penche pour le second, personnellement, mais je te laisse le bénéfice du doute.
En fait, je penche pour le second parce que tu sembles tourner les choses pour un bon FUD.
"pour avoir les fonctions qu'on a pas pour le moment, faut faire du boulot". En effet c'est logique, si tu veux des trucs qu'un script shell fournit pas, faut le refaire autrement. Mais sinon, les scripts marchent encore. Service marche encore.
Et contrairement à ce que tu crois, y a pas mal de distro qui font plus d’exécution séquentielle. RHEL, ubuntu ont upstart. Mandriva/Mageia a un système qui lance tout en même temps depuis 2006 ( pinit ). Et la plupart font de la gestion automatique de l'ordre via un système de tags LSB.
En fait, tu oublie aussi que les paquets des distros sont migrés, donc le travail de refonte est déjà fait ( comme les migrations à python 3 ou gcc 4, en fait ).
Pour la pérennité, prends au moins des trucs qui ont disparus ( genre oss, genre ipchains ), car selinux est la depuis facile 10 ans, et il n'a pas changé des masses, il a surtout eu des features en plus. Dbus existe depuis au moins 5 ans, et pareil, les changements sont pas révolutionnaires. Certes, hal a disparu.
Et sinon, comme tu avoues bien que faire des scripts d'init, c'est chiant, tu te rends bien compte que tu valides le point de vue des packageurs qui pousse à migrer à systemd ?
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 4.
En fait, le support est passé à 10 ans, comme indiqué sur Linuxfr :
https://linuxfr.org/news/le-support-de-redhat-enterprise-linux-passe-a-10-ans
D'autre part, RHEL 6 tourne avec upstart, et visiblement, ça n'a pas l'air de déranger grand monde ( vu que personne n'en parle et j'ai pas entendu de grand cri ), et le support de sysV par systemd est au même niveau que celui d'upstart ( ie, ça se lance directement les scripts de /etc/init.d )
Enfin, sachant que oracle avait déjà décidé de prendre son temps pour la certif de RHEL 6 ( http://blog.vishalgupta.com/2011/09/19/oracle-11gr2-on-rhel6/ ), donc j'ai l'impression qu'une version d'oracle non supporté sur RHEL est un événement déjà arrivé.
Moi, quand je relit ton histoire, je vois juste un client qui collabore avec son fournisseur sur un produit pas encore sorti, et ça me semble relativement positif comme façon de faire. Et à te lire, tu en reviendrais presque à le regretter, voir à imaginer des luttes de pouvoir qui n'existent pas. On pourrais même croire que tu sous entends que RH ne va pas pousser les bugfixes upstream, ou qu'il y a pas moyen de supporter proprement les scripts shell avec autre chose que sysV ( voir même que tes scripts magiques feraient des trucs si magiques que ça marcherais pas )
Tu serais pas un peu aigri et totalement subjectif ?
[^] # Re: les autres Unices...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 7.
Selon toi, le plus gros problème de systemd, c'est que les gens jugent pas le soft mais l'idée qu'ils se font d'un des auteurs sur la base d'extrait de discussions qu'ils ont pas suivi, mais dont il garde une sous partie qui leur semble choquante, c'est ça ?
Perso, je dirais pas que c'est un problème de systemd, plus un problème de gens.
Encore une fois, les technos linux only et bsd only abondent depuis des années. Samba utilise sendfile sur linux et pas sur bsd, personne trouve rien à redire. Nufw ne tourne que sur netfilter donc Linux, personne ne trouve rien à redire ( et dieu sait que mon patron, créateur du soft, a trollé pf plus d'une fois ).
NetworkManager tourne pas sur freebsd, wicd non plus, et je doute que connman soit dispo. Et pourtant, personne n'a jamais dit "faut pas coder ces outils". Ni personne n'a dit "je vais aller faire des patches".
Bluez tourne pas ( que je sache ) sur Openbsd, c'est pareil, ou sont les gens pour crier au complot de Nokia et Intel ?
[^] # Re: linuxfr: doc officielle de systemd
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 4.
Le montage des vpns marchent très bien ( en tout cas avec openvpn ), donc je vois pas ou serait le souci. Tu as 1 unité par vpn, ça démare quand le réseau se lance, ça se relance si ça tombe ( systéme de watchdog ), et conceptuellement, je sais pas trop ce qu'un autre vpn changerais ( genre, un daemon ipsec, ça reste un daemon ). Au pire, l'intégration est la même qu'avec les autres logiciels.
Quand aux fs chiffrés, si le souci est "systemd ne peux pas monter automatiquement un truc qui demande une intervention manuel" ( cf exemple donné plus tard ), je vois pas ce qu'un logiciel peut faire contre ça. Si un truc a besoin d'une intervention à la main, oui, tu va pas pouvoir faire grand chose pour automatiser ça. Et marqué le fs en "noauto" devrait suffire à régler le souci. Une fois que tu montes ça à la main ( avec ton mot de passe tapé ), systemd va réagir, si je comprends bien la doc de systemd.mount :
Donc soit je comprends de travers les soucis ( car la description est des plus lapidaires ), soit on n'a pas répondu comme il faut à tes questions.
[^] # Re: RH
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 10.
Ma foi, j'aimerais bien voir un mail ou il est marqué "vous passerez à systemd ou on butte le chien", si possible en anglais, et qui a décidé par exemple opensuse ou mageia à le faire. ( parce que globalement, c'est ce que tu décrit, et j'ai pas vu passer ce genre de mail, les gens ont choisit volontairement de basculer que je sache ).
Par exemple, pour Opensuse, est ce que quelqu'un s'est plaint de pression de la part d'une autre boite ? Est ce que tu as , genre, des preuves, des mails publiques ?
Tu fais aussi abstraction des discussions qu'il y a eu sur Fedora, sur Mageia, sur openwrt en toute transparence sur le passage ( ce qui ma foi, ne me parait pas faire preuve de beaucoup de rigueur dans l'hégémonie, mais bon, c'est bien connu que soit on est d'accord avec une décision technique, soit les devs et les packageurs sont des cryptofachistes doublés d'incapables de voir la vérité et de coder ).
Tu fais abstraction du fait que les devs de arch ont discuté de ça. Tu fais abstraction du fait que quand Fedora est passé à upstart, personne n'a ralé ( alors que upstart n'est pas compatible bsd, dépend de dbus, change les outils en ligne de commandes, n'utilise pas du tout de shell et fait juste moins de choses que systemd ). Et que upstart avait prévu de remplacer cron, at ( http://upstart.ubuntu.com/faq.html#replace-cron ), ce qui n'a fait bondir personne.
Au passage, personne n'a suivi, alors que pourtant, RHEL 6 utilise upstart.
Donc tu peux sans doute expliquer pourquoi un truc utilisé par Ubuntu, RHEL/Centos, et Fedora pendant un temps est vu comme moins hégémonique qu'un truc utilisé au début juste par Fedora ?
[^] # Re: Trop d'honneurs...
Posté par Misc (site web personnel) . En réponse au journal yet another journal about systemd. Évalué à 5.
Pour systemd :
http://patrakov.blogspot.fr/2011/01/writing-systemd-service-files.html
Pour un initscript mandriva
http://wiki.mandriva.com/en/Development/Howto/Initscripts
Pour gentoo :
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=4#doc_chap4
Je suis sur que tu peux trouver pareil pour le reste.