Archlinux utilisera prochainement systemd par défaut, en remplacement du vénérable système d'initialisation SysVinit. Cette migration n'est pas encore effective, les bénévoles qui maintiennent la distribution la préparent actuellement.
Conscients qu'un nombre significatif d'utilisateurs regrettent cette décision, les développeurs d'Archlinux lancent un appel à volontaire pour maintenir SysVinit (il sera également nécessaire de compiler des versions spécifiques de certains logiciels*).
Si la maintenance de SysVinit est rigoureuse et suivie dans le temps, les utilisateurs d'Archlinux auront le choix entre systemd (la solution par défaut) et SysVinit.
Ainsi, le maintien de SysVinit dans Archlinux semble possible … il « suffit » que quelqu'un fasse le travail nécessaire ! 😊
* Les développeurs d'Archlinux estiment que, prochainement, certains logiciels nécessiteront systemd. Les utiliser en l'absence de systemd pourrait néanmoins être possible, en recompilant les logiciels avec des options spécifiques.
# Utilité
Posté par Marotte ⛧ . Évalué à 2.
Cela me semble être une peine perdue si la plupart des autres distributions GNU/Linux passent à systemd. Selon moi c'est un peu du même ordre que vouloir maintenir Gnome 2. Si certains refusent systemd pour des raisons techniques il leur reste Debian (mais pour combien de temps encore…) et sinon les BSD. J'ai pas testé PC-BSD (basé sur freebsd) depuis un moment mais j'imagine que ça n'a pas forcément beaucoup à envier à une distribution GNU/Linux sur le coté user friendly pour le desktop de l'utilisateur lambda.
[^] # Re: Utilité
Posté par neil . Évalué à -1. Dernière modification le 06 octobre 2012 à 00:23.
Euh, c’est quoi le problème si les autres distributions passent à systemd ? Tu veux dire que c’est un peu du même ordre que de maintenir pacman alors que les autres distributions utilisent rpm/apt ?
Quel rapport entre systemd et passer à Debian ? Je crois que tu n’as pas bien compris l’intérêt de Arch… De même pour les BSD. À t’entendre on a l’impression qu’utiliser un noyau Linux sans utiliser systemd est une hérésie qui doit être supprimée.
Merci pour ton avis sur le côté user-friendly pour l’utilisateur lambda de PC-BSD, mais là encore ça ne concerne pas les gens intéressés par cet appel à contribution.
[^] # Re: Utilité
Posté par Marotte ⛧ . Évalué à 5. Dernière modification le 06 octobre 2012 à 01:09.
Non j'ai parlé de Gnome 2. Un système de gestion de package c'est un peu l'âme d'une distribution, ce n'est pas pareil. Comme le dit Sylvain Blandel ça représente un surcroît de travail, non négligeable selon moi. De plus, si je ne dis pas de bêtise, systemd permet de profiter de certaines features de Linux.
Debian reste sur SysVinit car elle supporte le noyau kfreebsd.
Peut-être. J'ai testé Archlinux mais je l'utilise vraiment très rarement. Pour moi l'intérêt c'est la rolling release, il y a peu de distributions de ce type.
Oui. Pardonne moi de donner mon avis sur cet appel…
[^] # Re: Utilité
Posté par Sylvain Blandel . Évalué à 9.
À l'heure actuelle, les distributions qui utilisent systemd par défaut sont :
Archlinux utilisera bientôt systemd par défaut, de même que la future version 7 de Red Hat Enterprise Linux (d'après cette dépêche).
À l'heure actuelle, Debian, Ubuntu, Gentoo et Slackware n'utilisent pas systemd par défaut. L'utilisation de systemd par Debian semble improbable pour l'instant.
Il me semble que systemd devient une solution générique pour l'initialisation du système et la gestion des services. Une distribution peut parfaitement se passer de cette solution générique, elle devra pour cela fournir un surcroît de travail (maintenir seule des trucs qui ne seront pas maintenu upstream).
# SysV rc
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 4.
Attention, systemd n'est pas un remplaçant pour SysV init seul. SysV init, c'est le premier processus, qui lance ce qu'on lui demande dans
/etc/inittab, soit très peu de chose. Il lance notamment SysV rc, qui lui va lancer tous ce qui se trouve dans/etc/rc?.d/.systemd est un remplaçant pour SysV init et SysV rc.
[^] # Re: SysV rc
Posté par Anonyme . Évalué à 6.
Pas sous Arch.
Sous Arch il lance
/etc/rc.sysinitqui lui va lancer les scripts contenu dans/etc/rc.d/en fonction de la variable d’environnement$DAEMONdu/etc/rc.conf. Une fois celà fait,/etc/rc.sysinitva lancer/etc/rc.local.[^] # Re: SysV rc
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
Ça ressemble à file-rc. Comme je ne le disais pas, SysV init peut lancer un autre outil de démarrage que SysV rc.
[^] # Re: SysV rc
Posté par Kwiknclean . Évalué à -1.
Le système de boot /etc/rc.d/ est un héritage du monde BSD like et UNIX (si je ne m'abuse), que l'on retrouve sur slackware et arch.
[^] # Re: SysV rc
Posté par Anonyme . Évalué à 2.
Pourquoi est-ce que tu me dis ça ?
[^] # Re: SysV rc
Posté par Sylvain Blandel . Évalué à 2.
Y a-t-il un terme pour désigner l'association
SysV init+SysV rc?Le terme
SysVaurait convenu, mais il désigne déja un système d'exploitation. 😞# systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Arthur Accroc . Évalué à 2.
Dernièrement j’ai lancé l’arrêt d’une Fedora 17 et j’ai éteint l’écran.
Quand je l’ai rallumé une vingtaine d’heures plus tard, la machine était toujours bloquée sur l’arrêt.
Accessoirement, comme la Fedora s’est encore « améliorée » avec la 17, les messages d’arrêt des services (qu’on voit aussi bien sur une Fedora 15 que sur une Arch avec systemd) ne s’affichent plus (et j’ai vérifié toutes les consoles).
J’avais déjà constaté avec Arch le problème de certains services qui partaient en sucette pendant plusieurs minutes quand systemd essayait de les arrêter, comme syslog-ng (remplaçable) ou à un moment Network Manager (difficilement remplaçable ; à l’essai wicd fonctionne moins bien). Ça m’avait conduit à repasser à l’init normale.
Pourtant, je n’avais jamais constaté un tel problème avec la Fedora 15 (et je l’ai mise sur plus de 100 postes pendant un an), qui utilise systemd aussi, mais uniquement en mode compatible (avec les anciens scripts de /etc/rc.d/init.d).
Il faut croire que ce n’est pas une question d’ordre d’arrêt qui serait inapproprié, mais plutôt que la manière super-fine de systemd de gérer les services pose des problèmes pour l’arrêt et pire, qu’il n’y a pas de timeout de prévu au cas ou un service ne se terminerait pas !
Autant systemd, sur le papier, c’est intéressant.
Autant, dans la pratique, c’est une calamité.
Si seulement Lennart n’était pas si occupé à intégrer tout le reste du système dedans, il pourrait peut-être fiabiliser l’existant…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Sylvain Blandel . Évalué à 3.
Oh putain, que c'est vrai ! 😄
D'après le wiki d'Archlinux, systemd gère (entre autres) le montage des systèmes de fichiers distants, et l'ACPI. Et il propose un équivalent à readahead.
Avant de s'occuper de tout ça, il me semble que systemd devrait déjà faire parfaitement son boulot : démarrer et arrêter le système, lancer et arrêter les services.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 3.
Et comment s'occuper des services sans monter les filesystems ? Tu as un truc ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Sylvain Blandel . Évalué à 0.
C'est juste.
Reste que systemd se propose de gérer l'ACPI, les logs ainsi que le readahead. À mon humble avis, systemd serait plus robuste s'il se contentait de son « cœur de métier » : démarrer et arrêter le système, lancer et arrêter les services.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 3.
Pas faux, mais tout ça ce sont des unités de systemd au même titre que les autres services :
Il ne les gère donc pas différemment des autres, ce n'est pas le même démon qui s'occupe de ça et des arrêts du système.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par duf . Évalué à 10.
Un certain Linus T. aimerait aussi quelques explications et recherche un certain Lennart ou un certain Kay pour un problème avec udev qui soit disant en fait ce serait pas de sa faute mais de celle du noyau….
Avis de recherche sur la LKML
Et sinon petit florilège :
Ca balance en ce moment :)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 10. Dernière modification le 06 octobre 2012 à 16:05.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
L'histoire se tient à propos du chargement des firmwares dans le noyau. Udev avec les nouvelles versions est très lent à les charger et ça fout la merde…
Depuis le mois d’août, il y a eu des patchs mais Kay n'en tient pas compte, limite il s'en fout…
Le pire, il accuse le noyau d'avoir des bugs … et ça gonfle clairement Linus.
Résultat des comptes, pour le chargement des firmwares et probablement des modules, le noyau risque de complètement outrepasser udev. La raison? Des mainteneurs qui en font qu'à leurs têtes et inefficaces.
Si vous n'aimez ce que devient udev en ce moment, prenez un sachet de pop-corn et lisez la LKML. Perso, j'ai fini mon sachet sans m'en rendre compte!
Quelques perles spéciales Linus:
Le meilleur reste celui de nix qui résume bien ce que devient udev.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par duf . Évalué à 5.
Je pertinente même si ton début de message laisse penser que je balance sur systemd, je dis bien qu'il s'agit d'udev :-p
J'aime bien aussi cette remarque d'Alan Cox :
Mais c'est clair que ça gonfle Linus (pas que lui d'ailleurs) et je pense que c'est pour ça qu'il fait cet appel :
Vu qu'avec Kay c'est du n'importe quoi, il espère qu'un interlocuteur de systemd (notamment Lennart) intervienne sur ce sujet, vu qu'udev devient lié à systemd.
En tout cas vu de loin c'est bien marrant (même si au final ça donne un peu raison à tous les détracteurs des évolutions actuelles :-/ ).
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 3. Dernière modification le 06 octobre 2012 à 16:34.
Salut,
Personnellement je ne suis pas Archiste. J'ai personnellement rien contre systemd à la condition que l'on ne me l'impose pas. Je suis sous OpenRC (Gentoo) et ça me convient… Le truc que je n'aime pas particulièrement ces derniers temps est udev, car le nouveau truc à la mode c'est de considérer que /usr doit être sur la même partoche que / sinon ça boote pas! ( ou bien avec une initramfs)
Maintenant que udev est mergé avec systemd… on peut considérer que c'est un même projet.
Pour l'instant on n'a pas vu Lennart mais je doute qu'il passe…
Il y en a des très croustillants:
Yes, doing it in the kernel is "more robust". But don't play games,
and stop the lying. It's more robust because we have maintainers that
care, and because we know that regressions are not something we can
play fast and loose with. If something breaks, and we don't know what
the right fix for that breakage is, we revert the thing that broke..
Le meilleur reste Nix
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par duf . Évalué à 2.
Étant moi-même sous Gentoo depuis 10 ans, je partage ton avis et je suis bien content de rester pour l'instant avec OpenRC.
D'ailleurs le problème soulevé ici n'est pas tant la qualité de l'un ou l'autre des logiciels, c'est qu'ils soient liés (au sens relation symbiotique).
Et comme le dit Nix, autant avant udev pouvait obliger les autres à s'adapter autant là ça commence à aller un peu trop loin….
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à -1.
En même temps, je n'ai jamais compris à quoi pouvait servir de mettre /usr sur une autre partition. C'est le meilleur moyen d'être emm*rdé si le système est en vrac et qu'on n'a que la racine.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par ahuillet (site web personnel) . Évalué à 4.
Et donc, sous prétexte que tu n'en vois pas l'intérêt, il faut l'interdire ?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 1.
Non, j'attends juste qu'on m'explique en quoi ça peut être utile :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 7. Dernière modification le 08 octobre 2012 à 17:45.
J'ai des /usr sur du lvm2, raid et pour certains montages en nfs…avec la racine en dehors de ces technos… mais tout cela importe peu…
Personnellement, ceux que je ne comprends pas, ce sont "les détracteurs" d'un /usr séparé de la racine, qui prennent l'argument historique pour assoir leur affirmations.
L'objectif suivant Fedora c'est de déplacer /bin /sbin /lib en les plaçant dans /usr sous prétexte qu''historiquement l'ensemble /lib, /bin /sbin étaient là pour bootstrapper le système par manque d'espace.
En effet, sur le pdp11, Unix fonctionnait sur une paire de disque RK05 de 1.5Mo chacun.
Un seul était insuffisant pour contenir tout le système. Le 2ème disque contenait "/usr" mais /usr à cette époque contenait les données utilisateurs et les binaires utilisateurs:
"It is common for the totality of user files to be too voluminous
for a given device. It is then impossible for the directories of
all users to be members of the same directory, say /usr. Instead
they must be split into groups, say /usr1 and /usr2;" D.Ritchie p.1953-1954 Bell System Technical Journal (juillet-Août) 1978 UNIX Time-Sharing System: A Retrospective.
Il y a également des indices dans le papier de Bourne UNIX Time-Sharing System: The UNIX Shell même époque où le PATH de l'utilisateur s'écrit comme PATH=:/usr/fred/bin:/bin:/usr/bin
/usr à commencer à perdre son sens ( d'ailleurs personne ne comprends à l'heure actuelle la signification de usr: Unix ressources, User ressources…) à partir du moment où /home est apparu (données utilisateurs) et qu'on a commencer à mettre des applis systèmes dedans:
/usr n'a plus de sens, pourquoi le garder? En plus si c'est pour dire http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken:
"The duty of the minimal boot system that consisted of /bin, /sbin and /lib on traditional Unix, has been taken over by the initramfs of modern Linux."
Ha bah! alors, mettons tout le sytème de boot et la racine dans une initramfs alors, puisque c'était le but initial de /lib /sbin /bin … pour au final ne garder que /boot avec le noyau et l'initramfs et /others pour tout le reste sur un disque!
et enfin arrêtons d'appeler systemd/udev un system d'init dans ce cas ( l'init c'est initramfs qui va se charger du montage) mais plutôt un controlleur de démons: "An initramfs that supports mounting /usr on top of / before it starts 'init'"
La plupart des systèmes comme OpenBSD, NetBSD, Freebsd (hier(7)) definissent ce qu'on attend dans /usr "Contains the majority of user utilities and applications." Ca marche, c'est pratique, c'est rodé et le système boot sans initramfs! Je peux mettre n'importe quel filesystem dans /usr. En quoi c'est plus chiant à faire sur linux?
D'ailleurs, comment est l'arborescence dans Plan 9?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 0.
J'ai toujours pas compris ce que ça peut apporter. Un exemple réel avec les avantages, ça ne serait pas de trop.
Je n'ai jamais pris l'argument historique (je ne le savais même pas). Je prends l'argument de l'utilité : à quoi ça peut servir ? Peut-être qu'il y a un usage qui se justifie parfaitement, mais je n'en vois aucun.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 4.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à -1.
Je répete : pour quoi faire ? Là, tu me donnes un moyen, pas une raison.
À ce compte-là, on peut tout faire : je peux mettre /usr/share/doc dans un volume à part, mais ça ne sert à rien.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 1.
souplesse,administration simplifiée
Pouquoi /usr et pas une sous-arborescence (si j'anticipe)?
* pourquoi pas? on laisse le choix, c'est flexible: si tu as envie tu peux, si tu veux rester simple tu peux aussi.
* 1 ligne sur le fstab
* migration plus simple aussi
* partage entre machine virtuelle simplifée
* mise à jour plus simple
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 1.
souplesse : je veux bien (encore que j'ai toujours pas vu l'intérêt)
administration simplifiée : ben non puisque ça fait un volume en plus.
Ben oui, pourquoi ? Je ne vois pas l'intérêt non plus pour une sous arborescence.
Je ne dis pas « il ne faut pas le faire », je dis « à quoi ça sert ? ». C'est pas pareil.
Euh c'est censé être une raison ?
En quoi ? Dans tous les cas, tu mets ta racine à jour avec, donc quel intérêt ? Tu as un exemple plus terre à terre ? Parce que là je ne vois pas trop :-/
OK pour la VM, ça peut être intéressant. Mais pas besoin de la monter à part sur l'hôte pour ça. Un bind ou un export NFS suffit.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par TortuXm . Évalué à 1.
Le fait d'avoir une partition /usr m'a bien servi quelques fois, quand elle ne pouvait plus être montée (coupure de courant…). J'avais du coup droit à un environnement minimal pour la réparer au lieu d'un bref "cannot find root partition".
Il faut dire qu'à l'époque je n'utilisais pas d'initrd, maintenant c'est peut-être moins utile s'il y a tout ce qu'il faut dedans.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par ahuillet (site web personnel) . Évalué à 5.
Monter /usr (ainsi que /lib et quelques autres) en NFS en lecture seule, pour avoir une seule install d'un OS pour toutes les machines d'un réseau donné.
C'est un cas parfaitement réel.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wismerhill . Évalué à -1.
Mais dans ce cas pas question d'utiliser une distribution à base de paquets, car la DB des paquets installés est dans /var et ça va être impossible de faire correctement les mises à jour.
Il faut obligatoirement avoir installé les systèmes à la main (LFS, peut-être gentoo) et maintenir le /usr commun à la main également pour être sur qu'il est auto-contenu et ne dépend pas de choses qu'il faudrait remettre sur chacune des machines qui le partagent.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par ahuillet (site web personnel) . Évalué à 5.
Bien sûr que si c'est possible. Tu montes /usr en lecture seule de toute façon.. la machine sur laquelle tu fais les mises à jour est celle sur laquelle il y a le /var correct. Les machines clients ne font aucune mise à jour.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wismerhill . Évalué à 1.
Et que fais-tu pour tous les paquets qui placent des choses dans /etc ou /var?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 0.
Pas besoin de monter /usr à part pour ça. Tu peux exporter un répertoire en NFS sans qu'il soit sur son propre volume.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # /usr sur NFS
Posté par Arthur Accroc . Évalué à 5.
Ce n’est pas pour la machine maître que ça pose problème, c’est pour les autres.
Après, on peut envisager qu’elles aient un /usr minimal pour démarrer et qu’ensuite elles montent la version NFS par dessus, mais ce sera moins pratique si tu as à mettre à jour un des programmes qui sont le le /usr local.
Je n’utilise pas personnellement (entre autres, parce que les distributions Linux ne m’ont jamais semblé très adaptées à cette optique), mais ça me semble un choix légitime.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Kaane . Évalué à 10.
Ca balance effectivement mais pas vraiment sur systemd en soi mais sur udev et son mainteneur Kay Sievers qui ne fait apparemment pas son boulot.
En fait si j'ai bien suivi les modifs récentes de udev ont été faites pour être "compatible" avec systemd. Lennart veut du tout asynchrone, et donc il s'est dit que d'avoir un chargement de firmware asynchrone plus une méthode de callback de la part du kernel ca permettrait d'aller plus vite au boot.
Sauf que bien sur du coup charge au kernel de
a) comprendre que l'on a chargé un nouveau firmware
b) surveiller les étapes de chargement
c) valider la finalisation du chargement et l'initialisation du device à un moment ou le module driver n'est pas encore chargé
d) prévenir udev pour lui dire "ca y est c'est bon pour le device xxx:yyyy" ou pour les devices xxxx:yyyy et zzzz:aaaa et bbbb:cccc etc. parcequ'un seul device physique peut engendrer plusieurs devices logiques (le tout toujours sans qu'aucun module/driver n'est été chargé)
Tout ça implique donc que le kernel possède une interface pour tout les devices possibles et imaginables qui nécessitent un firmware chargé au boot et bien entendu une autre interface pour dialoguer (en asynchrone bien sur) avec udev (j'imagine que Lennart voudra que l'interface soit DBus pour ne pas avoir à dupliquer du code - après tout DBus dans le kernel, ou est le problème ?).
Linus T. s'ennerve du coup, mais c'est justifié, seul un esprit malade ou une société qui cherche à monopoliser une techno ouverte prendrait des décisions aussi irréfléchies.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 3.
C'est Tanenbaum qui va être content… :)
Moi j'ai un truc que je ne comprends pas… il n'est pas possible de faire quelque chose de modulaire avec udev? Si on respecte "un modèle en couche" propre, a priori c'est udev qui fournit un service à init, systemd, etc… pourquoi absolument privilégier une dépendance forte?
D'ailleurs, Kaane, comme tu touches souvent du FreeBSD… il y a devd pour le remplissage à chaud de nouveau noeuds de périphériques. Tu as regardé le code? C'est une interface stable, non?
De ce que j'ai regardé, c'est simple, propre (mais c'est mon avis), ça fait son travail et ça semble stable sur le temps… c'est quoi le problème avec udev? Ce serait vraiment Sievers/Lennart?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par flagos . Évalué à 6.
C'est pas ce qui caractérise les projets menés par Lennart ca ?
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Arthur Accroc . Évalué à 10.
Il ne faut pas généraliser.
PulseAudio, même sur le papier, c’est une usine à gaz rajoutée par dessus Alsa, alors que la principale justification de PulseAudio est qu’Alsa ne donnerait pas satisfaction. Cherchez l’erreur…
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Anonyme . Évalué à 9. Dernière modification le 06 octobre 2012 à 18:16.
En effet.
Jusqu'à récemment, j'avais cherché à éviter pulseaudio comme la peste sur ma machine. Les raisons étant que :
Bref, Alsa me convenait tout à fait, donc je me fichais de ce pulseaudio pourri que j'avais désinstallé.
Sauf que voilà, dans sa version 4.0, Skype ne fonctionne correctement qu'avec Pulseaudio (avec Alsa, faire un appel ou aller dans les options fait planter Skype). La première chose que j'ai fait a été de revenir à l'ancienne version de Skype, mais pour une raison que j'ignore, le fait d'avoir installé Skype 4.0 m'a également flingué les versions précédentes (mêmes plantages).
En désespoir de cause, avant de réinstaller ma machine, j'ai donc redonné sa chance à Pulseaudio. Après tout, tant qu'à devoir tout réinstaller, autant en profiter pour tester des trucs bien merdiques avant.
Au premier abord, l'intégration de Pulseaudio avait été améliorée. J'avais enfin du son dès le démarrage et plus aucun plantage du système audio sous KDE. Skype fonctionnait de nouveau, ainsi que grosso-modo l'ensemble de mes applications. J'ai donc repoussé la réinstallation, et ça fait maintenant quelques semaines que j'utilise mon système avec Pulseaudio. Voilà mon bilan de simple utilisateur.
Bref, je compte réinstaller ces prochains jours, lorsque j'aurais fait le tour de tous les tests pouvant compromettre mon système que j'avais depuis longtemps envie de faire. Et il va sans dire que les paquets Pulseaudio seront dans la blacklist.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Mr. Magne . Évalué à 1. Dernière modification le 09 octobre 2012 à 14:56.
des souvenirs qu'il me reste du peu de temps pendant lequel j'ai supporté pulse audio, j'avais trouvé le moyen en ouvrant les préférences avancées de pulse de dépasser les 100%… bah oui, Lennart s'est dit que mettre le son à fond ça pourrait déranger les voisins alors il change le max de nos systèmes… le max de pulse ne correspond donc plus au max de ton matériel.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par xcomcmdr . Évalué à 1. Dernière modification le 09 octobre 2012 à 19:29.
Pour ma part, j'aime pas mal PulseAudio (principalement pour le volume sonore propre à chaque application : Sous Alsa, modifier le volume de Audacious modifie le volume PCM ou Master, donc ça affecte tout le monde : pas cool !)
Mais j'ai dû (encore) le virer pour deux raisons :
- Ça ne fonctionne pas avec Timidity (qui utilise ALSA), qu'il soit lancé en daemon ou non. Mon MIDI devient muet. Et ça, ça m'emmerde grave quand je veux l'entendre dans DOSBox ou ScummVM. Et pourtant, cette fois-ci, la dernière fois, ça avait fonctionné pendant un temps. Vraiment bizarre.
- Aléatoirement, si xfce4-volumed a été démarré avant PulseAudio lors de l'ouverture de la session, je n'ai pas de son (la carte son est remplacée par une "sortie factice" !). Je suis obligé de tuer xfce4-volumed, et de redémarrer dans l'ordre PulseAudio, et ensuite xfce4-volumed.
Le plus bizarre, est que je n'ai aucun de ces problèmes sous *buntu (je suis sous Archlinux) !
edit : Ah tiens, dans les préférences du module de sortie ALSA de Audacious, j'ai mis le 'mélangeur' sur autre chose : 'Speaker', et ça n'affecte plus que Audacious. Pas propre, mais c'est résolu. J'ai rien dit!
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par gnumdk (site web personnel) . Évalué à -1.
Et ben moi bizarrement, depuis que j'ai migré sous systemd, je n'ai aucun problème à signaler, tout fonctionne comme prévu.
Par contre, si ton pc ne s'arrête pas ou de façon aléatoire, c'est de la faute du noyau, enfin peut être plus de la faute de certains matériels.
En gros, il faut rajouter reboot=bios dans les paramètres du noyau et cela fonctionne tout le temps. J'ai vu ce bug d'arrêt aléatoire sur énormément de matos Dell et un peu de HP.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par wolowizard . Évalué à 4.
reboot=bios ne marche que pour des archi. bien spécifiques et notamment x86. [1]
D'ailleurs, ce shutdown est un gros hack pour les machines Dell comme tu le dis [2]
Il n'y a pas ce hack dans le code x86_64… apparemment, il faut repasser en mode 32 bit pour l'activer.[3]
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par YBoy360 (site web personnel) . Évalué à 1.
moi de même, strictement aucun problème avec des Mageia 2. Avant SystemD, il se pouvait que mon ordi ne s'éteigne pas également …
Je tiens à signaler quand même, qu'un des effet de bord sympa de SystemD, c'est la vitesse de boot : j'arrive à 8 secondes avec un core/1 giga sous VirtualBox avec une Mageia 3 (sans compter l'initrd de 2 secondes).
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Arthur Accroc . Évalué à 2.
Ça m’a fait ça aussi au début, enfin après que je passe de syslog-ng à rsyslog. Puis c’est Network Manager qui a eu une période à vide. Puis ça a été le nettoyage de /tmp (placé sur une partition dédiée) qui ne s’est plus fait (eh oui, systemd prend aussi ça en charge). Tout de suite, ça a l’air de bien marcher (sur Arch), mais bon…
Ça fait longtemps que tu as migré ?
Si c’était l’appel à l’extinction ou au redémarrage matériel qui ratait, je ne pourrais pas changer de console et ça ne se débloquerait pas au bout de 5 ou 15 mn, ce qui arrive assez souvent (le blocage persistent, c’est quand même l’exception ; une fois sur deux, ça s’arrête même en temps normal, génial, non ?).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par mirandir . Évalué à 1.
Systemd marche vraiment bien ici aussi.
Et mieux encore, j'ai un vieux portable sur lequel ça fait des années que la mise en veille ne marchait plus, que ce soit avec pm-utils, uswsusp et leurs amis, rien à faire, le portable ne réussissait jamais à se réveiller, malgré mes efforts les plus sincères. J'en étais arrivé à la conclusion que c'était un problème matériel.
Eh bien, depuis le passage à systemd (qui, entre autres choses, gère l'ACPI), ça remarche. Sans rien faire. Vexant !
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Miguel Moquillon (site web personnel) . Évalué à 4.
Systemd marche bien aussi sous Arch sur mon vieux portable (un Toshiba Satellite A40 Pro). Par contre, si je gagne en temps à l'arrêt de la machine, je ne gagne rien au démarrage comparé à l'init classique (dans lequel j'avais déjà parallélisé le lancement des daemons dans rc.conf).
A côté de ça, si le démarrage et l'arrêt des services via des fichiers de propriétés à-la-ini est sympa, ça devient vite abscons dès qu'il s'agit de jouer avec des .target et des dépendances dans les .service (par exemple dépend de truc mais peut démarrer en même temps mais doit attendre que truc ait fini pour finir lui aussi (ouf), etc.) -> bref une complexité qui me laisse perplexe comparé aux besoins (ici le démarrage des services).
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par xcomcmdr . Évalué à -1.
Pour ma part, systemd fonctionne très bien. C'est :
- facile à configurer ( sudo systemctl enable/disable , et voilà! On peut faire un start/ restart/ stop ensuite si on est pressé),
- facile de surveiller (d'autant que systemctl accepte de nombreux filtres en arguments) :
> $ systemctl
> UNIT LOAD ACTIVE SUB JOB DESCRIPTION
> proc-sys…misc.automount loaded active waiting Arbitrary Executable File Formats File System Automount Point
[…]
> cronie.service loaded active running Periodic Command Scheduler
> cups.service loaded active running CUPS Printing Service
> dbus.service loaded active running D-Bus System Message Bus
> getty@tty1.service loaded active running Getty on tty1
> lightdm.service loaded active running LightDM Display Manager
> network.service loaded active running Legacy unit for network
> NetworkManager.service loaded active running Network Manager
> rc-local.service loaded active exited /etc/rc.local Compatibility
> syslog-ng.service loaded active running System Logger Daemon
> systemd-journald.service loaded active running Journal Service
> systemd-logind.service loaded active running Login Service
> systemd-…s-load.service loaded active exited Load Kernel Modules
> systemd-…unt-fs.service loaded active exited Remount Root and Kernel File Systems
> systemd-sysctl.service loaded active exited Apply Kernel Variables
> systemd-…-setup.service loaded active exited Recreate Volatile Files and Directories
> systemd-…rigger.service loaded active exited udev Coldplug all Devices
> systemd-udevd.service loaded active running udev Kernel Device Manager
> systemd-…ssions.service loaded active exited Permit User Sessions
> systemd-…-setup.service loaded active exited Setup Virtual Console
> udisks2.service loaded active running Storage Daemon
> upower.service loaded active running Daemon for power management
> wpa_supplicant.service loaded active running WPA supplicant
> cups.socket loaded active running CUPS Printing Service Sockets
> dbus.socket loaded active running D-Bus System Message Bus Socket
> syslog.socket loaded active running Syslog Socket
> systemd-initctl.socket loaded active listening /dev/initctl Compatibility Named Pipe
> systemd-journald.socket loaded active running Journal Socket
> systemd-shutdownd.socket loaded active listening Delayed Shutdown Socket
> systemd-…control.socket loaded active listening udev Control Socket
> systemd-…-kernel.socket loaded active running udev Kernel Socket
> arch-daemons.target loaded active active Arch Daemons
> basic.target loaded active active Basic System
> bluetooth.target loaded active active Bluetooth
> cryptsetup.target loaded active active Encrypted Volumes
> getty.target loaded active active Login Prompts
> graphical.target loaded active active Graphical Interface
> local-fs-pre.target loaded active active Local File Systems (Pre)
> local-fs.target loaded active active Local File Systems
> multi-user.target loaded active active Multi-User
> network.target loaded active active Network
> remote-fs.target loaded active active Remote File Systems
> sockets.target loaded active active Sockets
> sound.target loaded active active Sound Card
> swap.target loaded active active Swap
> sysinit.target loaded active active System Initialization
> syslog.target loaded active active Syslog
> systemd-…es-clean.timer loaded active waiting Daily Cleanup of Temporary Directories
>
> LOAD = Reflects whether the unit definition was properly loaded.
> ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
> SUB = The low-level unit activation state, values depend on unit type.
> JOB = Pending job for the unit.
>
> 76 loaded units listed. Pass --all to see loaded but inactive units, too.
> To show all installed unit files use 'systemctl list-unit-files'.
(sans oublier la commande journalctl),
- bien plus rapide que SysV (même sur un SSD),
- fiable (au contraire de udev),
- largement documenté ( man systemctl, man systemd, man journalctl).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Anonyme . Évalué à 3.
Je pense que, soit tu t’es trompé de nom, soit tu ne sais pas ce qu’est udev.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par xcomcmdr . Évalué à -1.
Si si je sais très bien ce que c'est, et c'est bien lui qui bloque le démarrage une fois sur deux.
Y'a qu'à voir le bordel sur la LKML à son sujet.
Quand à tes exemples, je ne comprends pas pourquoi tu met systemd et sysv en opposition. On dit que systemd est compliqué, je réponds avec mon expérience jusqu'ici, c'est tout. Il n'y a pas d'attaque envers SysV dans mes propos. Je suis d'ailleurs passé à systemd uniquement parce que c'était "obligé" par les auteurs de Archlinux (on peut choisir d'autres systèmes d'init si on est vraiment allergique à systemd, mais ça m'a semblé plus compliqué sous Archlinux, et moins supporté, que de passer à systemd. Ce qui m'a pris 5 minutes).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Anonyme . Évalué à -1.
Non, visiblement tu ne sais pas ce qu'est udev puisque tu penses qu'il a été remplacé par SystemD.
Je pondérai simplement tes exemples.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par xcomcmdr . Évalué à -1.
Non, je ne le pense pas et je ne l'ai jamais dit, ni pensé, ni cru. Tu te fais des idées.
Ce que j'ai dit, c'est que Systemd ou SysV sont fiables. Udev ne l'est (toujours) pas. Que ce soit avec SysV ou SystemD, c'est bien udev qui m'emmerde un boot sur deux depuis bien avant le remplacement de sysV par systemd.
Ils n'en avaient nul besoin. Sauf si tu trouves que dès qu'on parle de systemd, faut que tu défendes ton cher SysV.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Anonyme . Évalué à 2.
Donc, quand tu dis que SystemD est fiable « au contraire de udev », tu ne compare pas SystemD et udev ? Ok… Pourquoi pas après tout…
Je comprends pas ce qui te dérange dans le fait que je pondère tes exemples. Tu dis que SystemD c'est trop cool parce qu'on peut faire X ou Y, je réponds qu'avec SysV on peut le faire aussi, je vois vraiment pas où est le problème.
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par xcomcmdr . Évalué à -2.
Comparer la fiabilité de deux logiciels ne les met pas dans le même rôle.
C'est comme si je disais que Firefox est plus stable que Audacious. Ça ne veut pas dire que je prends Audacious pour un navigateur Web. :')
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par zebra3 . Évalué à 1. Dernière modification le 08 octobre 2012 à 10:39.
En même temps, Fedora sert un peu à ça. Elle est la première à intégrer certaines technos justement pour les debugger. Il faut s'attendre à ce que certains trucs ne marchent pas, et dans ce cas faut faire un rapport de bug.
Bref, Fedora, c'est pas fait pour la prod : c'est un bac à sable, pour Red Hat principalement mais pas seulement car ça sert à tous. Si tu veux du fiable, prend RHEL ou Debian, voire Ubuntu LTS (pour du plus récent).
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Fedora
Posté par Arthur Accroc . Évalué à 2.
Quand tes utilisateurs veulent des logiciels récents, RHEL et Debian ne sont pas envisageables.
À l’époque où j’ai commencé à mettre des Fedora, les noyaux des distributions embarquaient souvent pas mal de pilotes pas encore intégrés dans le noyau officiel.
Et on tombait quelquefois sur une machine avec laquelle le noyau plantait net. C’est ennuyeux quand on a un parc hétérogène et qu’on espère installer le même système partout…
Ce genre de surprises était bien plus rare avec la Fedora qu’avec la Mandriva ou l’Ubuntu de l’époque (le fait que RedHat employait des développeurs du noyau n’y était probablement pas étranger) et globalement, la Fedora tenait bien la route pour une utilisation en réseau, malgré ce que son côté bleeding edge pouvait faire craindre.
Mais les choses ont évolué. Le noyau intègre les pilotes plus vite, Ubuntu a progressé, d’autres distributions sont apparues, tandis que Fedora se dégrade à plusieurs points de vue depuis quelques versions. Donc la 17 sera peut-être la dernière Fedora que j’installerai à mes utilisateurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: systemd ! Tant de complexité pour un moins bon fonctionnement…
Posté par Marotte ⛧ . Évalué à 0. Dernière modification le 10 octobre 2012 à 01:53.
Pars sur du CentOS plutôt. C'est du « libre » sensé être aussi stable que RH. Fedora c'est du beeding edge à priori. Ubuntu c'est à part.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.