Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.
Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )
En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.
les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.
Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.
J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.
Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )
Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).
Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.
Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.
Donc on trouve grosso modo dans ceux qui proposent pas :
- Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
- slackware et autres pour des questions de minimalisme
- gentoo qui le propose en option ( à la méthode gentoo )
- mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
- openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo
Du coté des autres distros à but commerciales, tu as :
- Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )
En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.
Regardons maintenant les distros qui proposent :
- opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu
curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
- les distros n'ont pas décidé de faire leur truc
- les distros n'ont pas décidé de garder les anciens initscripts
Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.
Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.
conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
Bah, faut leur dire de mettre à jour leur site web :
"Ubuntu Server LTS is maintained with security updates and bug fixes for up to 60 months (five years) and Ubuntu Desktop LTS for up to 36 months (three years). However, stability doesn't need to mean stagnant systems."
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 )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 3.
Suffit de lui demander, il traine sur irc ( genre, freenode, nick mezcalero ), il a un compte google plus, un email ( voir plusieurs ). tu peux aussi le trouver à des confs IRL genre le FOSDEM.
Ceci dit, aussi loin que je me souvienne, il avait déjà le même caractère quand il était étudiant ( au vue de la page http://0pointer.de/lennart/projects/atitvout/ vu que j'avais ça sur mon portable de l'époque )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
En fait, c'est toujours pareil, tu dit "tel truc est déprécié", la plupart des gens font rien. Tu retires, ça crie de partout.
les scripts réseau de rh sont aussi ceux qui sont utilisés par les autres distros rpm-based, donc ça a migré également.
Les debians utilisent ifup, un executable, donc je suppose qu'il fait direct les appels aux ioctls ( comme NetworkManager, au passage ). j'ai trouvé encore des appels à la commande "route" ceci dit dans un script.
J'ai rien pigé au script de gentoo, donc je peux pas dire, mais je pense que ça a du être migré.
Au final, les distributions ont fait leur taf. Ce qui coince, c'est toujours pareil, c'est le reste du monde. Et qui doit faire le travail pour que d'autres puissent ne rien faire ? Les distributions… ( et souvent gratuitement, avec le sourire )
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Il va pas démarrer, en effet. D'ailleurs, il y a eu des soucis avec lxc au début, car lxc utilise aussi les cgroups, et il y a eu clash sur l'usage en simultané des 2 ( souci corrigé depuis ).
Ceci dit, j'ai pour le moment vu personne se plaindre de ça à part toi, et bien que la remarque soit valable et génante pour ton usage, je pense qu'il y a donc un choix à faire sur ce que tu supportes en tant que distribution, et pour la plupart, l'usage en VPS est minoritaire AMHA.
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 3.
Et arch aussi. Et tu noteras qu'il y a des distros commerciales comme Ubuntu qui n'ont pas suivi.
Donc on trouve grosso modo dans ceux qui proposent pas :
- Debian qui ne bascule pas car ils ont des raisons techniques ( kfreebsd, hurd )
- slackware et autres pour des questions de minimalisme
- gentoo qui le propose en option ( à la méthode gentoo )
- mint, parce que mint fait 0 devs sur la plateforme et fait juste de la repompe de ubuntu
- openembedded, pas de probléme avec hurd/kfreebsd, pas de souci de minimalisme => proposé en option comme gentoo
Du coté des autres distros à but commerciales, tu as :
- Ubuntu, qui le propose pas car ils ont leurs propres trucs, à savoir upstart ( upstart qui a été intégré dans RHEL et Fedora, mais personne ne va crier au complot dans ce cas la, car c'est juste quand un truc a du succès qu'il y a complot )
En gros, pour chaque distro qui propose pas, on trouve une raison de pas le faire.
Regardons maintenant les distros qui proposent :
- opensuse, mageia, fedora, mandriva, rosa => pas de souci techniques comme Debian ( ie linux only ), pas de souci de minimalisme comme lfs ( ie, udev, dbus sont déja la ), pas de système de boot maison aussi avancé comme Ubuntu
curieusement, aucune des raisons des autres ne s'appliquent. Donc la question est de savoir pourquoi est ce que :
- les distros n'ont pas décidé de faire leur truc
- les distros n'ont pas décidé de garder les anciens initscripts
Alors le 1, c'est simple, parce que ça coute des ressources. Et le 2, c'est simple, parce que personne n'a vraiment envie de s'occuper d'une grosse pile de trucs bash pour avoir en plus moins de fonctionnalités. Pour le moment, ça va, mais si dans 1 ou 2 ans, faut intégrer des nouveautés, ça devient vite galère.
Et peut être que l’intérêt est juste la, c'est de proposer un système qui correspond plus au besoin des mainteneurs ( genre, tu sais, les gens qui te file gratuitement leur boulot sous la forme d'une distribution ) et que c'est pour ça que les distros y passent ? Et parce que du coup, ça laisse du temps pour faire autre chose.
conclusion, on a une paire de distros qui n'ont pas de raisons de refuser un truc, pas envie de se taper le cout de maintenance du à une divergence, trouve des avantages à basculer et qui, du coup, bascule dessus.
C'est vraiment bien foutu ce complot
[^] # Re: la guerre de s unices
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 1.
Tu appelles quoi "besoin particulier" ?
À vue de nez je pense que tu veux dire 2 trucs :
1) les services avec des actions en plus ( genre, postgresql, dump de la db via le script d'init ).
C'est une chose qui fait pas stricto sensu parti du script d'init. En général, ça a été mis dedans parce le script d'init a besoin de la config du daemon, et sans doute pour des questions d'ergonomie et d'affordance ( ie, pour le modèle mentale de l'utilisateur, le script est la porte d'entrée sur la manipulation du daemon, un dump de la db est une manip de ce genre donc on rajoute la fonction )
Avec systemd, tu doit faire un script à part ( vu que tu peux pu intégrer ça dans le script principal ). Il y a un emplacement spécifique quand tu utilise ça avec service pour garder l'intégration ( genre service pgsql dump va appeler /XXX/pgsql/dump ). La différence entre "j'écris du code que je mets avec un case en plus dans un script" et "j'écris du code que je mets dans un fichier à un endroit spécifique" est pas flagrante. En fait, tu peux juste garder ton script d'init qui fait appel à ton 2eme script.
2) les services qui ne sont pas des daemons classiques. Exemple, tu as un truc à lancer au démarrage, mais c'est pas vraiment un daemon, c'est juste la configuration de l'affichage sur un ecran lcd 4" du nom de la machine ( le seul exemple que j'ai trouvé qui ne soit pas géré autrement ). En gros, tu doit lancer une paire de commande pour charger le matos, et lancer ce que tu veux écrire. Ben ça, oui, tu peux lancer un script shell, ou un programme en C. Ou tu peux lancer les commandes à la suite dans le fichier systemd, avec plusieurs lignes Execstart, en précisant "c'est normal si il reste aucun process à la fin" et "ne fait pas de tracking de PID". IE pour les actions spécifiques, rien n'empeche de faire encore du shell. Après tout, si le but est de lancer des softs, personne ne va vérifier si le soft est en C, en python, en perl, en bash ou autre. Donc pareil, si tu codes bien, tu as fichier que tu appelles depuis un script classiques ou systemd.
Maintenant, en pratique, j'ai du mal à voir ce qui requiert des dizaines de commandes spécifiques au boot, à part le réseau et perso, je pense que ça peut sans doute être mieux intégré et de plus haut niveau que sous la forme d'un script shell.
Mais du coup, est ce que tu penses à autre choses pour "besoins non spécifiques" ?
[^] # Re: open source ou toute autre solution déjà développée
Posté par Misc (site web personnel) . En réponse à la dépêche Modification du code des marchés publics italien imposant l’usage du logiciel libre. Évalué à 3.
Ce qui voudrait donc dire qu'un autre organisme peut payer pour l'utiliser :)
[^] # Re: Merci Lennart
Posté par Misc (site web personnel) . En réponse au journal udev forké. Évalué à 2.
Bah, faut leur dire de mettre à jour leur site web :
"Ubuntu Server LTS is maintained with security updates and bug fixes for up to 60 months (five years) and Ubuntu Desktop LTS for up to 36 months (three years). However, stability doesn't need to mean stagnant systems."
C'est aussi ce que je trouve ailleurs :
http://vlinux-freak.blogspot.fr/2011/10/ubuntu-support-life-cycle.html
Ceci dit, tu as raison dans le sens ou c'est contraire à ce que dit la press release
http://www.canonical.com/content/ubuntu-1204-feature-extended-support-period-desktop-users
ou sur :
http://www.ubuntu.com/business/desktop
Du coup, est ce qu'il y a une version spécifiquement supporté plus longtemps ou c'est juste le site web qui est pas du tout à jour ?
[^] # 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 )