(suite du journal précédent)
Lors du Fosdem 2013, deux développeurs Debian, Tollef Fog Heen et Michael Biebl, ont présenté une conférence intitulée « systemd in Debian ».
Dans le diaporama de leur présentation (disponible sur ce lien), les deux développeurs Debian écrivaient que, dans la future Debian Jessie :
sysvinit will most likely remain the default for most installations
… ce qui avait donné lieu à différentes interprétations (voir le journal précédent).
La vidéo de la présentation (45 minutes) est maintenant disponible en ligne, ce qui devrait lever les ambiguïtés. Télécharger la vidéo « systemd in Debian » (format WebM, 499 Mio).
Remarque : la vidéo semble figée durant les deux premières minutes, c'est normal.
Les personnes douées en anglais sont invitées à écrire un résumé dans les commentaires. 😊
Les autres vidéos du Fosdem sont disponibles ici.
# 5 premières minutes sans son
Posté par Misc (site web personnel) . Évalué à 10.
Alors j'ai chopé la vidéo, et pendant 5 minutes, y a pas de son ( ce qui m'a fait chercher pendant 30 secondes le problème )
Sinon, à 23/24 minutes : "Jessy, the next release, we will probably use sysvinit on most system".
"In gnome 3, I think, we will start to depend on systemd, and that will create lots of interesting flamewar."
"By default, I think, we will likely see sysvinit as still the default, systemd is going to be supported. If we can move to a single init system for jessy, that would make me very happy, but I don't think that's gonna fly politically. because this is as much a political question as a technical question."
Donc en gros, systemd supporté officiellement, mais pas installé par défaut.
Suivi d'une discussion sur le passage de jessie à logind pour l'équipe gnome, avec un impact inconnu pour kfreebsd. Ils n'ont pas les ressources pour maintenir consolekit et pas d'utilisateur de kfreebsd et de gnome, ce qui leur prends du temps pour rien d’après un des 2 conférenciers.
Ensuite, Tolef ( je crois ), explique qu'ils veulent rendre systemd plus facile à packager ( outil systemd aware, synchronisation de l'état des systems d'init ), et il y a une question de l'assistance.
Le reste attendras.
# comme ca
Posté par maboiteaspam . Évalué à -2.
J'ai jeté un oeil à la vidéo, et je dois dire que j'ai été choqué de voir que le mec à pris plus d'une demi heure sur le même slide.
Celui où il doit expliquer, pourquoi / comment, il se permet de remplacer console kit, cron, atd et quelques autres (j'en oublie la moitié désolé).
L'audience était une bande de moule réfractaire au changement ?
# Putaing, ils ne sont pas clairs les deux garçons.
Posté par groumf . Évalué à 2.
Je respecte le travail des développeurs, mais la présentation donne envie de se mettre des poireaux dans les oreilles, à chaque fois qu'il vont parler de quelque chose d'intéressant ils s'interrompent ou alors c'est confus.
Tout ce que je dis en dessous est à prendre avec des pincettes.
Il y a une histoire de sauter des releases pour aligner les numéros de version avec udev. Du coup system-journald n'est pas encore fiable alors qu'il est bon dans la dernière version de systemd.
Sysvinit et systemd peuvent être installés tous les deux en même temps. Ils vont garder un paquet udev séparé de systemd pour sysvinit.
Sysvinit est utilisé par défaut et il faut ajouter une commande dans grub pour lancer systemd.
Si ont désinstalle sysvinit, systemd se lance alors par défaut.
On ne peut pas désinstaller le paquet initscripts car il a un flag "Essential". Il y a un mécanisme de blacklist pour ne pas exécuter les scripts de initscripts. (j'ai compris comment ce système de blacklist fonctionne)
Il reste des problèmes avec insserv et nfs/portmap.
Systemd-logind va remplacer ConsoleKit si on utilise Gnome.
[^] # Re: Putaing, ils ne sont pas clairs les deux garçons.
Posté par groumf . Évalué à 1. Dernière modification le 14 février 2013 à 15:06.
Systemd n'a pas de mécanisme de restart, il fait un stop puis un start.
Tout ce qui est dans la section restart des init.d/* est zappé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.