gnumdk a écrit 7486 commentaires

"Est il pertinent que ce soit le système d'init qui gère tout ça plutôt qu'un outil spécialisé
dans chaque tache ?"

Non, la question est: « est il possible de faire tout cela ailleurs que dans le système d'init » …

Je me permets d'ajouter une petite remarque. Systemd est un développement "from scratch" qui
n'a pas cherché à préserver la rétro-compatibilité avec l'existant.

Eux, systemd est tout à fait capable de lancer les scripts de sysv… C'est juste que si tu l'utilise comme ça, autant ne pas l'utiliser.

Pas de troll sur gnome ?

En même temps, j'aurai plus envie de troller sur la gueule du code que sur le message d'erreur (ca arrive).

Mais coder un bureau avec un truc aussi horrible que GTK/GObject, il faut le faire quand même.

Voilà, c'est fait ;)

Du coup je viens de perdre 20 minutes à regarder mes vieux screenshots de Gnome 1.4 et je suis retombé la dessus, message de e16 qui est mon préféré:

(NdM: image reprise de archive.org)

Lennart a dit qu'il ne ferait jamais le port sous BSD et que si ca intéresse les devs BSD, ils peuvent le faire.

Et un port de systemd si ce n'est pas utilisé par défaut pas les BSDs, ca sert à rien et je vois pas pourquoi on vient nous dire que c'est une honte que systemd soit orienté Linux ;)

Oui, j'ai pris le cas extreme de RedHat même si celui de Suse doit être pas mal dans le genre.

ps: merde, je t'ai [-] alors que je voulais te [+], souris de merde!

est il possible de modifier son comportement (par du script par ex)

Tu peux lancer n'importe quel script shell dans un unit systemd donc oui.

à l'inverse peut-on utilisé journald sans systemd ?

Non, c'est systemd qui permet à journald de mieux loguer que syslog: du début du boot et pour tout ce qui est lancé par systemd, pas juste les trucs qui ont prévu d'envoyer des logs dans syslog.

Des préjugés? Non, c'est la réalité, les devs BSD ne veulent pas de (L)GPL dans leur OS (pour les bases), je l'ai dit en trollant mais c'est la réalité.

Donc un port de systemd sous BSD, sans changement de licence, j'y crois pas.

l'une des critiques envers systemd est qu'il essaye de tout faire au lieu de laisser chaque
tache à un outil dédié.

Wai, enfin ca veut pas dire un seul exécutable, logind et journald sont des exécutables distincts. Et si un jour systemd doit remplacer crond & ses petit frères, ce sera pareil.

Parce que bon, on peut dire, mais cron c'est quand meme bien merdique à l'utilisation, pour faire tourner un truc le premier samedi du moi, t'es obligé de faire des trucs du genre:

7 0 * * 0 root if [ -x /usr/share/mdadm/checkarray ] && [ $(date +\%d) -le 7 ]; then /usr/share/mdadm/checkarray --cron --all --idle --quiet; fi

Puis se limité à une date pour lancer un script, avec systemd, il serait bien de pouvoir réagir à des évènements.

sont passé à GNU/Linux récemment

Ca fait 13 ans que j'utilise GNU/Linux et c'est pour ça que je fait mon vieux…

Parce que bon, j'espère que tu charges encore tes clés usb à la main parce que sinon, ca craint, ca ressemble trop à ton ancien OS (si tu l'as utilisé un jour).

Les répertoires /bin et /sbin sont là pour avoir les softs nécessaire au démarrage et /usr
(note: ressemble à user), pour tout ce qui n’est utile que lors d’une session utilisateur.
Pourquoi casser ça ?

Parce que ca sert plus à rien? On est plus dans les années 70, si c'était fait comme cela, c’était par contrainte, pas parce que c'est plus cool.

Le libre ne passera jamais plus loin tant que les gens ne feront pas des applis portables.

Ben va demander à Linus de ne plus rajouter de fonctionnalité dans son OS tant que les BSDs n'ont pas la même fonctionnalité et va demander à la même chose aux BSDistes vis à vis de Linux, tu vas te faire recevoir…

Systemd n'est pas portable, pas parce que Lennart ne sait pas coder, mais parce que Linux propose des fonctionnalités non POSIX qui sont utilisés par ce dernier.

Et sinon, toi tu codes quoi de beau qu'on puisse admirer la qualité et le non bloat de ton travail, si il y'en a ce dont je me permet de douter…

Tout le monde me dit ça mais pourquoi les distributions continuent à packager lilo, BURG, par
exemple ? Pourtant ils exigent de la maintenance aussi.

Parce qu'il y'a un mainteneur ?

La le truc, c'est que quand Arch sera passé à systemd, le mainteneur de sshd par exemple, si il a pas envie, il va virer le /etc/rc.d/sshd et donc il faudra trouver quelqu'un pour maintenir le script sysv.

Moi, les deux énormités, ce sont stopspam et dcp qui n'ont toujours pas compris que systemd n'existe pas pour booter plus vite, c'est juste une conséquence de son architecture…

Debian/FreeBSD c'est vraiment utilisé dans la vrai vie ?

Wai par les linuxiens à qui FreeBSD fait peur…

Combien de logiciels dans nos distros viennent de
ces BSD? Combien d'idées venant de ces projets
reprises dans GNU/Linux?
Quelle ingratitude, finalement!

Tu déconnes j'espère ? Les BSDistes passent leur temps à recoder les softs sous licence GPL/LGPL parce que la liberté, la vraie, la contagieuse, pas le libéralisme à trois francs leur fait peur…

Alors, je vois pas pourquoi on se ferait chier…

ps: un troll s'est caché, ou pas, dans ce message…

systemd peut arrivé et dire, jetez tout.

Non, syslog c'est un standard utilisé partout dans l'industrie… (switch, …).

Ton sysvinit, vu qu'il discute avec rien, on s'en fout un peu.

Et si sysvinit était vraiment un standard, alors j'aurai pas besoin de faire des trucs comme ça:

#tina.pp

# Script d'init compatible avec Debian Squeeze
class tina
{
        file
        {
                "/etc/init.d/tina.tina":
                        owner => root,
                        group => root,
                        mode => 700,
                        source => "puppet://servietsky.*****.fr/files/servers/tina/tina.tina"
        }

}

https://plus.google.com/104232583922197692623/posts/L1vzCnKCHMD

J'ai pas compris qu'il chiffrait les logs sur le disque, surtout que dans ton exemple, tu chiffre la modif de l'attaquant mais je vois pas ce que ca va avancer.

Dans l'idée, c'est de garantir l'intégrité du journal.

L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal
fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être
corrompu et inutilisable.

C'est aussi le cas du journal de journald, le format a été pensé pour ça

À ce propos, journald permet-il de faire l'équivalent d'un `tail -f' ?

journalctl -f

Ce qu'il décrit n'est pas le comportement par défaut de systemd mais c'est faisable… J'ai pas encore bien fouillé la question :)

On parle d'un systeme d'init là, pas d'un gros soft.

Et ?

[gnumdk@tina ~]$ wc -l /etc/rc.sysinit 
980 /etc/rc.sysinit

C'est vrai que c'était tellement mieux ces scripts shell à rallonge…

Mais si tu as un début de réponse je veux bien que tu m'expliques.

Ben, si les distribs passent à systemd, c'est pour ne plus avoir à se prendre la tête avec cela dans l'avenir… Après, je pense pas que sysvinit va disparaître de ArchLinux par exemple, il sera dans Community au mieux, dans Aur au pire…

Il y'aura juste un paquet sysvinit-rcs avec tous les scripts de la distrib à l'arrache comme c'était le cas pour systemd avant que Arch commence la migration.

Bon bien sur, c'est dans le cas ou y'a vraiment des gens que ca motive de le maintenir.

Pour la prochaine version du journal, il sera possible d’empêcher l'altération des logs, en gros, un attaquant pourra supprimer tous les logs (et donc être grillé) mais pas les modifier.

"Un programme fait une chose unique et le fait bien"

Wai, enfin ca fait des années que cet argument est faux, tu veux une listes de programmes Unix qui ne respecte pas ce principe ?

Dans les gros softs, il faudrait plutot chercher les logiciels qui le respecte encore, genre postfix…

Un programme fait une chose unique et le fait bien, c'était surtout pour les utilitaires de la ligne de commande que ca avait un sens: "Ne cherche pas à tout faire dans un seul programme quand tu peux faire discuter ces derniers via des |"

Je suis pas sur que ce soit très pertinent pour un system d'init.

syslog, c'est un standard et journald ne peut pas arrivé et dire je ne sais pas causer avec syslog… Même le gestionnaire d’évènement de Microsoft sait le faire!

Sauf qu'il me semble que les logiciels formatent leur logs actuellement comme ils le veulent donc ca doit être un beau bordel à convertir si il faut gérer plein d’exceptions.