gnumdk a écrit 7492 commentaires

Où il parle de KDE?
Où il dit que le concept de composants enfichables est pourri ?

Par contre séparer le système des applications me semble toujours aussi pertinent.

Sur un Unix qui n'a pas de gestionnaire de paquet, ca peut être logique, mais sous GNU/Linux, faut m'expliquer…

Mwai, enfin le message correct, il parait que c'est plus: "Veuillez installer cups-pdf" …

Ben non, les mecs qui retirent sont jamais les mecs qui ont codé !

En fait, McCann, il regarde le code des softs GNOME, il comprend rien alors il enlève le code: j'ai enfin compris sa logique (qui se défend).

Ouh là, systemd sur mes serveurs ? Mais ce n'est pas prévu et vu que tout est sous Debian, ca va pas arriver demain.

Mais bon, je pense que quand RedHat le mettra par défaut, ce sera bon.

Une faille sur la version n, c’est pas grave, on la corrige sur la n + 3, et on continue.

Euh, dans quel monde ?

Canonical: 5 ans de support gratuit sur les mises à jour de sécurité
Redhat et Suse: J'en sais rien mais plus j'imagine vu que c'est payant

"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 :)