Systemd v218
Systemd v218 - Logiciels - Linux et OS Alternatifs
Marsh Posté le 09-05-2014 à 22:51:46
Cite moi OU debian utilise ce fucking system d'init par défaut ?
C'est encore dans Jessie, tu peu porter pour wheezy et sid certes mais hum ... Dans combien de temps ?
Même remarque pour Canonical puisqu'ils ont upstart. (ça sera pas avant d'avoir les .deb de leurs upstream, et vue qu'ils sont basés sur wheezy, par défaut c'est pas encore ça)
FreeBSD et les *BSD risquent de backporter massivement vers openrc + fork udev, qui d'ailleurs n'est pas un fork mais un wrap pour le moment d'une ancienne version (174 de mémoire, via gobject actuellement), qui ne s'appelle même pas mkdev (c'est eudev, pour embedded)
Et franchement un topic unique sur systemd on peu s'en passer, franchement, surtout quand c'est limite du lobbyisme pro systemd x_x (qui est une merde sans nom)
Marsh Posté le 09-05-2014 à 23:34:56
justement c'est pas du lobbyisme 
j'ai posté des avis contre francs et d'autres plus nuancés
et debian comme ubuntu ont annoncé qu'ils utiliseraient systemd par défaut, en ce qui concerne debian, seulement pour x86 et amd64
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 09-05-2014 à 23:58:59
| Magicpanda a écrit : justement c'est pas du lobbyisme |
Le comité debian a dit go pour systemd, c'est pas encore décidé.
Canonical a dit : suivre le choix de l'upstream, donc :
-Debian pour bouger, c'est très très très très très très long (y'a peut être que slackware qui est plus long dans ses mouvements et prises de décisions)
-Si debian bouge pas, ubuntu bouge pas.
Renseigne toi sur comment sont prises les décisions pour debian, parce que même si le comité directement ordonne un changement, avant que ça soit pris en compte, y'a de l'eau qui coule sous les ponts
Linus est anti systemd, et imho, la FSF va pas laisser longtemps freedesktop supporter systemd (c'en est même étonnant que Stallman ai pas encore réagit, et ça risque de faire très mal et d'être encore plus fleurit que Linus)
Marsh Posté le 10-05-2014 à 00:22:12
Ubuntu avait prévu de reprendre launchd dans un premier temps avant de créer upstart, donc ils ont souvent voulu faire cavalier seul. Si ils rejoignent l'upstream, c'est bien qu'ils considèrent que c'est trop lourd de garder un system d'init pour eux.
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 00:30:53
Pour ceux que ca intéresse : le post de Shuttleworth
http://www.markshuttleworth.com/archives/1316
Le vote du TC de debian sur le choix de l'init
https://lists.debian.org/debian-ctt [...] html#00281
Le wiki du débat sur les systèmes d'init chez debian
https://wiki.debian.org/Debate/initsystem
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 01:15:57
| Magicpanda a écrit : Pour ceux que ca intéresse : le post de Shuttleworth |
Oublie pas de préciser les éventuels conflits d'intérêt debian/red hat, et là ça coince un peu dans le TC.
Soucis de debian, c'est qu'ils ont pas que du linux en kernel qui tourne derrière (y'a du bsd et du GNU/Hurd).
Autre gros soucis, c'est qu'a la base, freedesktop est un projet support pour GNU, et GNU doit tourner indépendamment du kernel, Gnome étant sous dépendance systemd, systemd ne tournant pas sous GNU, puisque uniquement linux actuellement, et c'est pas franchement amené a changer dans le futur (puisque systemd développé par des dev red hat principalement et red hat étant linux only, et a but commercial).
Bref uniformément, les barbus sont contre systemd. Le boss est contre aussi (choix éthique et politique, dans le sens qualité de code et liberté/ouverture/accessibilité du code), et même si tu met les échanges les plus softs, ils sont très loin d'être aussi soft.
Il faut que tu mette les vrai divergences, pas seulement les édulcorées, car sinon tu fait de la censure = lobbyisme pro systemd.
Je ne suis absolument pas d'accord sur le passage xorg (qui d'ailleurs va évoluer vers wayland), puisque xorg EST la couche graphique GNU (et wayland devra être le futur de cette couche graphique), donc la FSF et freedesktop DEVRONT rester GNU, et donc RESTER compatible avec les autres kernels et donc systemd DEVRA NE JAMAIS être obligatoire, hormis s'ils dev pour hurd (kernel d'origine du projet GNU).
xorg ne réclame absolument pas udev en passant : tu peu faire du bon gros et vieux static conf des campagnes qui marche du tonnerre (exemple sur gentoo http://dev.gentoo.org/~neddyseagoo [...] ntoo_3.xml ) avec du bon gros static dev.
Petit aparté puisque visiblement tu as du mal a comprendre le problème principal de systemd :
Actuellement systemd a un PID de 1 dans les distro qui l'ont adoptées par défaut, le soucis, c'est que d'une version a l'autre tu as des options qui apparaissent et qui disparaissent, voir pire qui peuvent rendre ton système non bootable, l'exemple le plus flagrant c'est l'option en kernel cmdline "debug" qui flood tellement sous systemd qu'il plante la machine, moralité, tu doit désactiver l'option (et donc ne plus avoir de debug kernel) pour ne plus que systemd flood. L'autre exemple est qu'il est plus facile (pour celui qui connait la structure C) de dev une unit systemd mais tu n'as aucuns moyen de savoir si ton unit tournera a la prochaine update (combien d'utilisateurs arch postent régulièrement sur le forum parce qu'ils doivent changer des unit systemd qui fonctionnent plus ? quotidiennement ? Au minimum 1 voir 2 et la discussion du topic unique reflète bien se qu'est systemd = pas stable) j'ai des scripts sysinit qui fonctionnent depuis 10 ans et continuerons de fonctionner encore dans 10 ans, si sysinit ou openrc sont toujours fonctionnels. Alors certes, le script bash/sh ou n'importe quel shell au dessus de sysinit, c'est pas forcément idéal, python pour openrc, non plus, mais ça tiens dans le temps et je suis tranquille. Supporter du nouveau matos ? Je demande pas a mon système d'init de gérer mon matos, c'est a mon kernel et les modules de le faire, y'a rien a voir de ce côté.
Le problème sous jacent, c'est que Red Hat VEUX avoir son système binaire fermé et le vendre.
Marsh Posté le 10-05-2014 à 01:56:20
Je suis bien convaincu que c'est l'objectif de red hat, mais je pense pas que la FSF va bloquer systemd, non pas qu'ils ne veuillent pas, mais ils ne pourront pas parce que ce morceau de code va se répandre très vite, et il sera fortement utilisé dans les écosystèmes gnu/linux
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 02:31:48
| Magicpanda a écrit : Je suis bien convaincu que c'est l'objectif de red hat, mais je pense pas que la FSF va bloquer systemd, non pas qu'ils ne veuillent pas, mais ils ne pourront pas parce que ce morceau de code va se répandre très vite, et il sera fortement utilisé dans les écosystèmes gnu/linux |
GNU non, c'est pas possible, pour que ça soit GNU, faut que ça soit interopérable avec les autres kernels. systemd n'est pas GNU.
http://en.wikipedia.org/wiki/List_of_GNU_packages
Et pour que Linux soit toujours considéré GNU, il faut qu'il puisse tourner uniquement avec les 17 packages de base + kernel (hurd, bsd ou linux)
sachant que sysinit est inclus dans le kernel (ou du moins, doit être inclus en tant que partie du kernel pour fallback au minimum)
Red Hat dans la FSF, au prochain GNU summit, ça va faire des chocapics.
Les passages en gras sont les plus importants :
| Citation : What it means to be a GNU package |
Systemd n'est nul part sur le site GNU, ni dans le ftp, ni sur un autre site considéré GNU, il ne marche pas bien avec tout les autres packages GNU (la seule exception a date étant ututo), la documentation n'est pas accessible (y'en a t'il réellement une ?), le langage d'extension on peu mettre se qu'on veux donc ne s'applique pas, systemd est taggé "open source" pas "free software" et la licence d'utilisation est de type lgpl v2.1 (qui est en staggering chez GNU), les maintener sont pas franchement contactable facilement ...
Là le soucis c'est que gnome risque fortement d'être déprécié (entre autres) et si gnome est déprécié, ben systemd, udev et autres vont se retrouver sans appuis de la FSF et donc on y verra clairement mieux niveau politique générale, en attendant, systemd est et restera immature.
Sachant que ça implique quand même la modification du contrat social debian (pas une mince affaire) de sortir du modèle GNU/free/non-free software, http://en.wikipedia.org/wiki/List_ [...] Foundation
Tu verra que les distros réellement GNU/Linux, ben y'en a pas des masses (en bleus uniquement, en jaune, ce sont les distro qui pourraient se prévaloir de, et en orange, elles le sont carrément pas), aucunes distros en bleu n'a systemd par défaut. 
Archlinux n'est pas GNU.
Marsh Posté le 10-05-2014 à 13:37:39
Linux pourra toujours tourner sans systemd , là n'est pas la question.
La question c'est de savoir si de nombreuses applications de bureau ne vont pas avoir très rapidement systemd comme dépendance obligatoire.
Est-ce que c'est vraiment réaliste que gnome soit déprécié pour cette raison .. ?
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 13:40:34
Oui c'est réaliste, c'est réaliste que Stallman foute sont poing dans la figure des devs de systemd aussi.
Marsh Posté le 10-05-2014 à 18:07:00
Pour enrichir un peu avec des éléments du débat et d'explications :
La vidéo dans laquelle le créateur de systemd explique les objectifs de faire de systemd "the core os"
https://www.youtube.com/watch?v=_2aa34Uzr3c
Une présentation de Rodger Donaldson à la dernière conf australienne (janvier 2014) sur l'évolution de son rapport à systemd. (Donaldson est responsable de l'archi informatique de Bank of New Zealand)
https://www.youtube.com/watch?v=-97qqUHwzGM
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 19:10:55
Se qu'il faut voir c'est qu'au delà de ces personnes dites "vocales" sur le devant de la scène il y a tout le reste derrière.
En part de marché, systemd est minoritaire parmi les admins, c'est un fait. Sauf qu'on veux vous faire croire le contraire. Kay S., Lennart P. et autres ne sont que des supers commerciaux envoyés par Red Hat pour convaincre du contraire, et vue que la majorité des admins s'en foutent de répondre a ces personnes là, ben, le grand publique pense que systemd est super, est unique, le seul a faire se qu'il fait, le fait bien, et depuis longtemps.
Merde quoi systemd c'est un init qui existe depuis 2012, pour mon PID=1 j'attend un retour autre que 2 ans en sorties publiques (les sorties alpha/beta datent de 2010)
Marsh Posté le 10-05-2014 à 19:16:21
Y a pas un résumé de la conf de Lennart ?
Parce que bon 1h et quelques... et les slides sont useless...
Je suis intéressé de connaître les "objectifs" 
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 10-05-2014 à 19:19:15
j'ai pas trouvé de résumé sur son site 
j'ai trouvé ca mais la page date de 2011
http://0pointer.de/blog/projects/why.html
| Citation : systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system's userspace. It includes C rewrites of all basic early boot init scripts that are shipped with the various distributions. Especially for the embedded case adopting systemd provides you in one step with almost everything you need, and you can pick the modules you want. The other two init systems are singular individual components, which to be useful need a great number of additional components with differing interfaces. The emphasis of systemd to provide a platform instead of just a component allows for closer integration, and cleaner APIs. Sooner or later this will trickle up to the applications. Already, there are accepted XDG specifications (e.g. XDG basedir spec, more specifically XDG_RUNTIME_DIR) that are not supported on the other init systems. |
Message édité par Magicpanda le 10-05-2014 à 19:25:35
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 19:28:23
https://www.youtube.com/watch?v=rWux-PA6JCU
Vidéo de Kay, plus courte (un poil) sur débian et le lobbyisme qu'il y a eu sur les TC, les belles promesses non tenues.
Marsh Posté le 10-05-2014 à 19:30:51
| Magicpanda a écrit : j'ai pas trouvé de résumé sur son site
|
Ca me semble bien maigre...
Quels sont les problématiques qu'ils cherchent à adresser ?
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 10-05-2014 à 20:29:19
ce que je retiens c'est qu'ils veulent provoquer une standardisation en intégrant des composants kernels et applicatifs avec systemd
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée
Marsh Posté le 10-05-2014 à 22:29:12
drapal, mon retour après 1 mois en prod pour du serveur : du bon
De bonnes idées, pour l'instant ça m'a apporté que des bonnes choses et pas d'emmerdes.
/my 2 cents.
---------------
Spécialiste du bear metal
Marsh Posté le 11-05-2014 à 00:04:04
| Magicpanda a écrit : ce que je retiens c'est qu'ils veulent provoquer une standardisation en intégrant des composants kernels et applicatifs avec systemd |
![[:sniperlk]](https://forum-images.hardware.fr/images/perso/sniperlk.gif "[:sniperlk]")
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 13-05-2014 à 23:40:49
| Plam a écrit : drapal, mon retour après 1 mois en prod pour du serveur : du bon |
pas mieux, du point de vue d'un utilisateur desktop ou d'un mainteneur de paquet pour une distro, c'est autrement plus facile à utiliser que l'init system V
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Marsh Posté le 14-05-2014 à 05:35:17
| Mjules a écrit : |
Pourquoi c'est plus facile ?
Marsh Posté le 15-05-2014 à 09:53:35
/etc/init.d/machin start
Ouai dur
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 15-05-2014 à 22:18:45
| MysterieuseX a écrit : Pourquoi c'est plus facile ? |
côté utilisateur, je trouve les outils de suivi plus pratiques pour voir un truc spécifique à un service
par exemple (on peut sûrement le faire sans journald) :
[jules@tue-amour ~]$ journalctl --since=2014-05-12 --until=2014-05-13 -u dnsmasq.service |
ou encore :
[jules@tue-amour ~]$ systemctl status dnsmasq.service May 15 21:40:12 tue-amour dnsmasq[1505]: compile time options: IPv6 GNU-getopt DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack |
ou pour regarder ce qui prend du temps au boot (systemctl blame et plot sont très pratiques pour ça)
En dehors de ça, la transition a été invisible quand j'ai mis à jour ma distribution. Juste un peu plus rapide.
D'un point de vue mainteneur, écrire ou maintenir les fichiers units systemd est bien moins compliqué que les scripts d'init qu'on avait avant.
Exemple (toujours pour dnsmasq) :
https://svnweb.mageia.org/packages/ [...] iew=markup
le fichier init system V
l'équivalent en unité systemd (écrit par moi-même 
)
https://svnweb.mageia.org/packages/ [...] iew=markup
La config était possible à 3 endroits, j'en ai profité pour réduire à 2 endroits et je vais probablement supprimer le deuxième un jour ou l'autre.
un autre exemple d'unité que j'ai écrit pour remplacer un script :
http://mjules.littleboboy.net/carn [...] %A9marrage
Le script initial était pas compliqué mais l'unité est 4 fois moins longues, fait la même chose et est plus facile à lire. Et je gagne un suivi sans avoir besoin de me creuser la tête :
[jules@tue-amour system]$ systemctl status setkeycodes.service |
Message édité par Mjules le 15-05-2014 à 22:19:08
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Marsh Posté le 15-05-2014 à 22:59:13
Pour le "suivi" en quoi c'est différent d'un grep "service" /var/log/syslog ?
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 16-05-2014 à 00:07:35
| grao a écrit : Pour le "suivi" en quoi c'est différent d'un grep "service" /var/log/syslog ? |
ça dépend pas du service, c'est systemd/journald qui gère les métadonnées (nom du service, pid, date etc.) donc tu les as systématiquement. Comme je l'ai dit on peut sûrement faire pareil en chaînant des grep/cut ou autres (encore que je ne sais pas comment faire pour l'intervalle de date et la mention reboot) mais je trouve journalctl plus facile et plus consistant, sachant qu'il est aussi possible de chaîner grep ou autres sur la sortie de journalctl.
Message édité par Mjules le 16-05-2014 à 00:08:09
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Marsh Posté le 16-05-2014 à 00:08:08
| grao a écrit : Pour le "suivi" en quoi c'est différent d'un grep "service" /var/log/syslog ? |
En rien. Ca bouffe même du temps CPU et des IO ... Juste pour du logging. Alors qu'un debug ou /var/log sont déjà bien remplis. La seule option "sympa" c'est le suivi processus et cgroups et le modèle "pipé" d'office et pas avec une option (pratique pour l'user, il a pas a connaitre l'option qui va bien)
Pour les scripts ... Hum. Voyons voir, systemd usine a gaz qui prend la main sur la machine, forcément sachant que les scripts init sont forcément "3 états" les concepteurs ont rendu inutile les lignes if/then pour start/restart, puisque d'office systemd sait se qu'il doit faire avec un initscript. En fait, ils ont remplacés ces lignes par sysctl start "nom du script". Ah ouai, c'est sur t'as rien simplifié dans ton init script (3/4 des éléments dans le script de base sont des commentaires). Pire encore, t'as retiré des options "fines".
Explications :
Code :
|
Ca c'est ton script + configuration du service.
Code :
|
Ca c'est uniquement ton script, donc déjà tu biaise : il faut rajouter la configuration (ben oui tu définie ou les options définies dans le script init de base ?)
Elle est définie par la variable systeme "$OPTIONS" sauf que cette variable système est utilisée par tellement de trucs que v'la les bugs possibles xD
Marsh Posté le 16-05-2014 à 00:10:19
| Mjules a écrit : |
Et logger tout et n'importe quoi, voir même des choses inutiles, que ça soit accessible a tout le monde qui ai accès a la machine, en clair, voir même pire, si tu active les mauvaises options, tu peut même te retrouver a logger les infos kernel pouvant contenir entre autre les pass utilisateur, des hash et des clés, ça te parait pas être un POF niveau sécurité ?
Marsh Posté le 16-05-2014 à 00:17:33
| MysterieuseX a écrit : |
tu trolles ou tu es sérieuse ? la situation actuelle est exactement la même avec ou sans journald/systemd. Si tu configures pas bien, tu auras des problèmes systemd ou non.
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Marsh Posté le 16-05-2014 à 00:19:03
| MysterieuseX a écrit :
|
Je sais même pas pourquoi je me fatigue à donner un point de vue. De toute façon tu es bornée et incapable de discuter.
---------------
Celui qui pose une question est idiot 5 minutes. Celui qui n'en pose pas le reste toute sa vie. | Membre du grand complot pharmaceutico-médico-scientifico-judéo-maçonnique.
Marsh Posté le 16-05-2014 à 00:45:59
| Mjules a écrit : |
Heu j'ai déjà toutes ces infos sans systemd.
La mention reboot j'en ai pas besoin, tu vois tout de suite dans les logs quand la machine a rebooté.
L'intervalle de date je vois pas trop l'intéret: je veux avoir les évènements à partir d'une date ou autour d'une date:
grep "lejour l'heure" /var/log/syslog.
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 16-05-2014 à 14:14:04
C'te mauvaise fois quand même
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 16-05-2014 à 14:58:59
| e_esprit a écrit : C'te mauvaise fois quand même |
Mauvaise foi de quoi ?
Je bosse au support, grepper des logs ça fait partie de mes basics.
Désolé si je vois pas ce qu'apporte systemd sur le sujet ![[:spamafote]](https://forum-images.hardware.fr/images/perso/spamafote.gif "[:spamafote]")
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 16-05-2014 à 15:23:07
Mjules te donne un exemple avec un since/until, tu lui réponds qu'un grep "le jour l'heure" donne la même chose.
C'est faux, c'est beaucoup moins précis, et beaucoup plus complexe si tu dois prendre en compte une plage de jour, même si c'est faisable.
Pour ce qui est de gérer les heures, je demande à voir l'expression régulière qui te permet de le faire, elle ne sera certainement pas aussi simple que la syntaxe qu'il indique.
Tu peux tout aussi bien répondre "oui mais quand on doit travailler sur les logs, on met en place un système de gestion des logs centralisés avec un système d'interrogation/analyse/exploitation de ces logs".
Ca ne répondrait pas plus à sa remarque.
Tu as parfaitement le droit de ne pas être pro-systemd (je ne le suis pas spécialement non plus, je ne m'y suis pas encore intéressé), mais répondre à quelqu'un que son truc est équivalent à une autre solution existante qui n'apporte pas vraiment la même ergonomie/précision, c'est de la mauvaise foi, que tu l'admettes ou pas
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 16-05-2014 à 15:27:34
Bon aller, c'est 'dredi, je lâche un troll (ou pas, mais bon, vue que la plupart ne feront pas d'analyse de codes ...)
| Citation : I’ll put it together for you once again. For those who missed it in my other articles, Red Hat is a billion-dollar corporation with deep ties to the US military (their largest customer), and thus inevitably the NSA (a military security organization), etc. Adding to the conflict of interest, they have as direct corporate partners Google, Apple, and other too-large-to-imagine corporations with their hands in slime. Red Hat developers dictatorially control the core engineering of Linux, including components such as udev, udisks, xorg, dbus, systemd, etc., used by every major Linux distribution, as well as other common desktop components such as GNOME and GTK. (As Ts’o put it, “we have commit privs and you don’t”.) These are simple facts, though curiously never discussed. In many developers’ views, these Red Hat developers have consistently introduced closed, overly complex, security-breaking technologies to Linux for years, and have a long and tired history of sabotaging kernel development, creating unending bugs and problems for kernel developers, which they often categorically refuse to address. Linus knows them well – or does he? |
systemd a des backdoor NSA-esque dans son code et certaines demandes de l'équipe de dev pour avoir accès aux devices de manière exclusive risquent de créer des brèches et des précédents avec des parties de code fermées et obfusqués et systemd est très (trop ?) bavard sur les réseaux.
La vrai position de Linus sur le sujet est celle-ci et elle est loin d'être bisounours-esque comme décrite au dessus :
http://news.softpedia.com/news/Lin [...] 5714.shtml
http://www.muktware.com/2013/02/li [...] ntest/4035
Kevin Toppins pointe des éléments plus que parlant en dévafeur de systemd :
https://lists.debian.org/debian-dev [...] 00404.html
Sans parler du fait que systemd est en train de dev une pile DHCP complète parce qu'ils ne peuvent pas avoir la main sur un des projets existant => aller hop encore une brèche majeure et tout le monde dira "amen" ?
Si vous pensez que l'extension du support de squeeze est fortuite, vous vous trompez également. Cette extension a été faite pour laisser la porte ouverte au comitee de revenir sur l'adoption de systemd dans jessie, puisque les deux versions auront leurs fin de cycle en même temps. C'est une extension qui a été anoncée le 16 avril, juste après le vote du 14 avril, bizarre hein ? Ben non.
https://www.debian.org/security/2014/dsa-2907
L'avis de "vrais" barbus qui compilent :
http://forums.gentoo.org/viewtopic-t-937778.html
Marsh Posté le 16-05-2014 à 15:28:08
"Since until" m'apporte pas grand chose en fait:
Quand je veux savoir ce qu'il s'est passé entre jour1 heure1 et jour2 heure2 je grep sur jour1 heure1 et je lis les logs jusqu'à jour2 heure2.
Si j'ai des infos sur ce qu'il faut chercher je fais "|grep "info"".
J'ai pas besoin d'expressions régulières pour la date:
May 16 14:54:53 hostname kernel: [189561.045138] tg3 0000:0c:00.0 eth0: Link is up at 100 Mbps, full duplex
May 16 14:54:53 hostname kernel: [189561.045157] tg3 0000:0c:00.0 eth0: Flow control is on for TX and on for RX
May 16 14:54:53 hostname NetworkManager[5871]: <info> (eth0): carrier now ON (device state 100)
Pour avoir les logs du 16 vers 14h:
cat /var/log/syslog |grep "May 16 14:"
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 16-05-2014 à 15:30:58
Ca ne t'apporte rien à toi, mais peut-être qu'à d'autres si ?
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 16-05-2014 à 15:31:59
| e_esprit a écrit : Ca ne t'apporte rien à toi, mais peut-être qu'à d'autres si ? |
Peut etre. Surement même.
Est ce que ça necessite toute l'usine à gaz autour ? Je ne pense pas.
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 16-05-2014 à 15:34:40
Moi je trouve ça très bien pour du desktop, ça permet de se rapprocher de Windows 98 et de son explorer.exe
Manque le navigateur de fichiers quand même ![[:transparency]](https://forum-images.hardware.fr/images/perso/transparency.gif "[:transparency]")
---------------
Ce n'est point ma façon de penser qui a fait mon malheur, c'est celle des autres.
Marsh Posté le 16-05-2014 à 15:36:55
| e_esprit a écrit : Moi je trouve ça très bien pour du desktop, ça permet de se rapprocher de Windows 98 et de son explorer.exe |
Si on veut des améliorations pour du desktop: parfait améliorez les surcouches graphiques, les navigateurs de fichier, tout ce que vous voulez.
Il n'y a pas à réclamer de modifs dans le kernel pour ça ni à aller modifier le système en profondeur pour ce genre de problématique.
---------------
Recherche affiche de GITS Arise 3 et 4, faire offre.
Marsh Posté le 09-05-2014 à 20:50:04
MAJ : v218
http://cgit.freedesktop.org/system [...] rce=anzwix
Man pages : http://www.freedesktop.org/software/systemd/man/
Tips and tricks : http://www.freedesktop.org/wiki/So [...] AndTricks/
Mailing list : http://lists.freedesktop.org/archives/systemd-devel/
Git : http://cgit.freedesktop.org/systemd/
---------------------------------
Récemment, debian puis canonical ont décidé de switcher sur l'utilisation de systemd.
Rappelons que Xorg requiert udev depuis sa version 1.8 (car HAL est mutuellement exclusif avec udev) et que udev est maintenant fusionné dans systemd.
http://www.x.org/wiki/XorgHAL/
A court terme, toutes les distributions qui utilisent Xorg sont donc amenée à adopter systemd, ou à forker udev et à maintenir une correspondance avec Xorg.(Plus de détails ici, Xorg peut fonctionner en pratique sans udev mais on perd le hotpluggin, il faut utiliser evdev ou configurer à la main avec les drivers souris et clavier dans le xorg.conf)
http://linuxfr.org/users/sygne/jou [...] ace-a-udev
Ce dernier chemin a été choisi par gentoo qui a créé mkdev et eudev pour forker udev et continuer à implémenter un autre system d'init : openrc.
Le wiki d'udev
http://en.wikipedia.org/wiki/Udev
la page gentoo du projet eudev
http://www.gentoo.org/proj/en/eudev/
github eudev
https://github.com/gentoo/eudev
Documentation de cross linux from scratch (documentation pour l'installation systemd disponible aussi depuis que LFS propose les deux systèmes d'init)
http://lfs.traduc.org/view/clfs-2. [...] eudev.html
Systemd est un logiciel complexe, qui utilise des fonctions spécifiques du noyau linux et perd des fonctionnalités quand il est utilisé avec certains kernels notamment le kernel ck utilisant BFS (Brain Fuck Scheduler).
https://wiki.archlinux.org/index.ph [...] se_systemd
BFS patched kernels CAN in fact use systemd
It is a common mistake to think that BFS does not support cgroups. It does support cgroups, just not all the cgroup features. Systemd works with BFS patched kernels, though systemd user sessions are broken for now, as some of those missing features are required to start systemd --user.
La page de wiki archlinux
https://wiki.archlinux.org/index.php/systemd
La page systemd sur freedesktop.org
http://www.freedesktop.org/wiki/Software/systemd/
Systemd sur wikipedia
http://en.wikipedia.org/wiki/Systemd
La page de systemd chez gentoo
http://wiki.gentoo.org/wiki/Systemd
Principales distributions utilisant systemd par défaut
Archlinux
Debian
Fedora
Mageia
OpenSUSE
Red Hat (futur)
Ubuntu (futur)
L'essentiel des distributions linux sont donc concernées par ce nouvel init, dont les ramifications sont importantes.
La façon dont des composants importants du desktop amènent à utiliser systemd rend également difficile l'existence de long terme d'alternatives.
Certains projets plutôt orienté vers l'embarqué utilisent de plus petits systèmes d'init avec busybox (sinit par exemple)
http://git.suckless.org/sinit/
Un bon article de Linux Magazine sur les concepts de systemd
https://connect.ed-diamond.com/GNU- [...] s-System-V
Les réponses des développeurs de systemd aux principales critiques
http://0pointer.de/blog/projects/t [...] myths.html
Controverses :
Certaines personnes n'aiment pas systemd, lui reproche sa complexité, son utilisation des binaires à place des fichiers textes, le fait qu'il absorbe udev, et qu'il soit pour le moment uniquement utilisable sous linux et difficile à porter sur d'autres OS. (Pendant ce temps là, FreeBSD a repris le travail de portage de lauchd déja en service sous mac os X)
https://wiki.freebsd.org/launchd
https://github.com/rtyler/openlaunchd
Les opposants :
http://boycottsystemd.org/
Des critiques récentes plus modérées :
Patrick Volkerding :
Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well.
Eric S Raymond :
I haven't studied systemd in the detail that would be required for me to give a firm answer to this - it's been on my to-do list for a while, but I'm buried in other projects.
I want to study it carefully because I'm a bit troubled by what I hear about the feature set and the goals. From that, I fear it may be one of those projects that is teetering right at the edge of manageable complexity - OK as long as an architect with a strong sense of design discipline is running things, but very prone to mission creep and bloat and likely to turn into a nasty hairball over the longer term.
http://interviews.slashdot.org/sto [...] ?sdsrc=rel
Dietrich Schmitz, développeur de funtoo, a récemment publié un court texte pour revenir sur ses dénonciations plus anciennes et déclarer que systemd constituait un progrès
http://www.linuxadvocates.com/2014 [...] taken.html
Linus Thorvald a eu des échanges houleux avec Kay Sievers au sujet du développement de systemd
http://www.muktware.com/2014/04/li [...] vers/25151
Theodore T'so, mainteneur notamment de ext4 a eu quelques critiques mitigées sur systemd mais l'utilise sous debian
https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU
Allan McRae, développeur Archlinux explique la raison pour laquelle la distribution a switchée sur systemd assez rapidement après fedora
http://allanmcrae.com/2012/09/repl [...] rch-linux/
Un post intéressant sur les aspects non techniques de la transition sur la mailing list de debian par John Mist
https://lists.debian.org/debian-ctt [...] 00461.html
J'ajoute les remarques précises de MystérieuseX sur les évolutions chez gentoo
OpenRC date de 2006 en beta, 2007 en stable. Il est donc plus vieux que systemd. OpenRC se base sur l'init de la distribution (qu'elle soit *BSD, *nix, linux où autre). En gros quand on parle d'OpenRC dans le monde Linux, on parle du couple OpenRC/SysVinit : SysVinit reste PID1 en mode zombifié. Il utilise le mode baselayout pour la gestion des scripts (qui défini une arborescence spécifique et une organisation de /etc /var et /usr modulaire, tu peu mixer sans soucis). Sachant que baselayout 1 est un system gentooisé sans openrc et baselayout 2 un system gentooisé avec OpenRC.
seconde chose a expliciter aussi :
udev a été forké 2 fois par les dev gentoo, une première fois parce qu'ils n'avaient pas la voix sur des modifications néfaste aux environs de 2008/2009, finalement leurs commit sur leurs fork sont passés dans une version ultérieure de udev, se qui a avorté le fork. Le fork actuel est en réponse a l'intégration dans systemd et le fait que ça casse/oblige des dépendances profondes.
Message édité par Magicpanda le 10-12-2014 à 15:09:48
---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée