Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par Misc (site web personnel) . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 7.
Dans ce cas, tu doit faire que du C ou du perl. Parce que le python, le ruby et le php d'il y a 10 ans, y a des chances que ça marche plus.
je suis d'accord qu'il faut de la stabilité, mais je pense que c'est à la distribution d'assurer ça. Le reste, c'est juste une conséquence de la R&D distribué qu'est le mouvement du logiciel libre. Il y a les outils ou personne n'innove,
Systemd a une page qui liste les interfaces et la promesse de pas les changer, ce qui est largement mieux que la majorité des projets que je connais, même si certains s'en sortent aussi bien voir mieux.
Mais maintenant, je pense qu'on peut pas soutenir les devs kernels qui soutiennent que les interfaces internes du kernel peuvent bouger, alors qu'il y a de la demande pour la stabilité (pour les drivers), que d'autres arrivent à le faire (solaris, windows ), et en même temps réclamer que rien ne change sur les autres projets.
Ça me semblerait juste hypocrite, et je doute qu'une séparation arbitraire il y a un bout de temps entre kernel space et user space soit une raison suffisante pour dire "c'est normal d'être emmerdé pour les drivers, bout de code compilé qui tourne sur ton pc, mais pour les softs en user space, autre truc compilé qui tourne sur ton pc, c'est différent".
Et je pense que le but n'est pas de remplacer init, mais de remplacer les initscripts ( au sens paquet du même nom ). Et en effet, par la suite, d'offrir une API pour gerer la machine tant qu'à faire.
Les initscripts, les trucs qui montent le LVM, lance le réseau, lance les softs, etc. Tout des trucs qui étaient déjà fait à gauche et à droite de façon différente par chaque distro.
Tu donnes l'exemple de la journalisation, mais il faut bien voir que le journal est une conséquence du design et de la position de systemd. Tu voudrais mettre ça en dehors de systemd, mais comment est ce qu'un programme en dehors de systemd accède à stdin et stdout ? Donc une fois que tu te dit "ça serait une idée de choper ça", tu te retrouves à avoir un cache. Et tu te dit "je peux rajouter plus de données". Et ensuite, "je peux sans doute faire des recherches dans ce cache", et le mettre sur le disque et voila, journald dans sa forme actuelle, cad un programme qui va en effet faire le même travail que les fichiers syslog, mais dans une base de données indexé lisible.