gnumdk a écrit 7497 commentaires

systemd ne dialogue vraiment qu'avec dbus

Dbus est lancé par systemd après syslog sous Arch alors j'aimerai bien savoir comment tu m'expliques ton argument pourri…

Non systemd peu utiliser dbus pour le lancement des services mais il ne dialogue pas en interne avec dbus.

Donc effectivement, si dbus ne se lance pas, la condition tel interface dbus existe ne pourra pas être vérifiée et sera ignorée. Mais c'est un plus par rapport à sysvinit donc paye ta critique…

systemd n'est pas compatible avec autre chose que Linux

Comme udev

De la même façon tous les points de montage locaux sont systématiquement montés avant de lancer
le moindre démon.

On continue dans le n'importe quoi, si tes démons n'ont pas le Wants=local-fs.target, tes fs locaux ne seront pas montés sauf si:
" In addition, systemd adds dependencies of type Wants to this target unit for those mounts listed in /etc/fstab that have the auto and comment=systemd.mount mount options set."

ils n'auront probablement jamais de support DBus.

Et en gros, si je comprend bien ton argumentation, les programmes qui ne supportent pas DBus ne fonctionne pas avec systemd, et la marmotte…

et qu'en plus les dialogues avec systemd ne peuvent qu'avoir un impact négatif sur les perfs

Le dialogue avec systemd se fait via socket, pas via dbus qui n'est utilisé que pour valider des conditions!

Un peu comme si, tu insérais la lecture du jpeg dans le noyau parce que c’est trop cool

Moi, à ta place, j'aurai dit LibreOffice dans le noyau, plus c'est gros, plus ca passe…

Sinon, tu crois vraiment qu'on peut pas insérer une clé USB à chaud sans udev ?

À commencer par systemd qui met les logs ailleurs que dans /var si j’ai bien compris.

Non, t'as rien compris, il les mets dans un tmpfs tant que tu n'a pas créer /var/log/systemd…

Ce qui est logique, sur un desktop, j'ai pas besoin de logrotate et compagnie, les logs de la session en cours me sont largement suffisant.

Il est reproché à Dbus d'être un démon inutile sur LFS.

Comme je le dis plus haut, j'aimerai bien savoir en quoi udev est un démon utile pour LFS, ca me trou vraiment le cul! Genre, Linux From Scratch, ca veut pas dire se taper les mknod à la main quand on rajoute un niveau périph?

Pff, les distribs pour barbu, c'est plus ce que c'était…

En même temps, si le but de LFS c'est d'avoir un Linux aux petits oignons sans outils neuneu proof, je vois pas pourquoi ils veulent udev qui a quand même été la première brique vers tout ce qui a suivi… (pour avoir un linux qui fait tout à ta place).

Bluetooth et Avahi, ça a de la gueule sur un serveur en prod !

Mon dieu!!! Y'a deux dépendances vers une pauvre librairie, c'est la fin du monde, t'as raison, recompile tout! A ta place, je passerai sous Gentoo histoire d'optimiser un peu tout cela, ca se trouve, tu pourrais virer directement le support cups de samba, puis virer le support usb de cups, …

Et en plus, dans le cas de Arch, les paquets étant peu découpé, le service est installé mais je ne pense pas qu'il se lance tout seul.

Pfff, ca devient insupportable les mecs qui parlent de systemd sans savoir de quoi ils parlent…

Ca doit prendre 2 minutes de faire une "unit" systemd qui lance des scripts shell comme le faisait sysvinit…

Mais bon, c'est tellement plus simple d'utiliser la bonne vielle technique du Fear, uncertainty and doubt.

Ou alors systemd répond à un besoin que sysvinit n'est pas capable de comblé…

Parce que bon, tu oublies quand même ArchLinux dans l'histoire, et tu le fais exprès en plus pour appuyer ton propos.

autant de goto

Comme dans le noyau Linux

de dizaine de return par fonction

Comme dans le noyau Linux

de pointeurs non-initialisés à NULL

Mwai, ca ce discute, mais bon, quand tu fais:

Manager *m;

assert(_m);
assert(running_as >= 0);
assert(running_as < _MANAGER_RUNNING_AS_MAX);

if (!(m = new0(Manager, 1)))
                return -ENOMEM;

Ca n'a absolument aucun intérêt de l'initialisé à 0 quand tu fais l'init 3 lignes plus bas…

Mais bon, après, tout ce que tu dis, c'est ce qu'on m'a appris à l'école mais c'est un peu la guerre de clocher entre les devs system et les devs objets.

Je n’ai pas trouvé de documentation qui me soit accessible.

https://wiki.archlinux.org/index.php/Systemd#Writing_custom_.service_files

Je précise que c'est une techno linux only qui n'est pas obligatoire pour démarrer comme dbus… Pourtant systemd dépend aussi de udev et cela n'a pas l'air de gener ;)

Non, j'utilise puppet

Quand un truc s'arrête brutalement, je veux savoir pourquoi avant de le redémarrer

Tu travailles dans une MJC, c'est ça ?

De plus, si vraiment t'as un service non critique, ben tu dis à systemd de pas le redémarrer automatiquement.

Euh, comprendre le fonctionnement de systemd, c'est à la porté de toute le monde, t'inquiètes que les prochains Linuxiens qui n'ont connu que cela le comprendront, après si tu ne veux pas faire d'effort…

Bref, c'est plus abordable de comprendre la conf de systemd que de comprendre la syntaxe de bash pour un profane…

10 heures à apprendre un nouveau systeme qui me ferait gagner 30 secondes à chaque reboot,
si je ne reboot mon serveur que quelques fois par an

Si tu pouvais passer 10 minutes à comprendre ce que fait systemd plutot que de montrer que tu n'en sais rien… Si systemd avait été créer pour gagné 30 seconde au boot, alors upstart suffisait…

les serveurs n'ont pas besoin de systemd

C'est vrai que le reprise d'un service sans coupure en cas de segfault d'un service, c'est pas du tout intéressant…

les portables et les ordinateurs de bureaux entrent et sortent de veille (ils démarrent
une fois chaque mois)

T'en connais beaucoup des gens toi qui n'éteignent pas leur pc et même leur portable ?

Quand on compare ça à un inittab ou on peut remplacer /etc/init.d/rc par ce que je veux

Tu rajoutes init=/bin/ton_init.sh dans les paramètres de ton noyau et cela fera ce que tu veux… Si t'as pas envie de dbus, je vois pas pourquoi t'aurais envie de udev donc y'a pas de problème… Ton Linux fonctionnera comme tu le veux.

J'ai monté toutes les salles infos de mon école d'ingé en double boot Windows/Ubuntu avec auth Active Directory…

Et bizarrement, j'ai bien galérer la dessus mais c'est très simple en fait:

$ cat /usr/share/glib-2.0/schemas/19_ensat.gschema.override

[com.canonical.indicator.session]
suppress-restart-menuitem=true

[org.gnome.nautilus.desktop]
computer-icon-visible=false
home-icon-visible=false
network-icon-visible=false
trash-icon-visible=false

# glib-compile-schemas /usr/share/glib-2.0/schemas/

et c'est torché

2 secondes sur mon laptop entre syslinux et kdm avec systemd, voilà mon sentiment…

Après, il faut savoir ce que l'on test, en gros, si on installe systemd en mode compatibilité sysvinit, y'a peux de chance que ça aille plus vite… Mais c'est surement trop dur de lire une doc…

2) it is modular: all of what is now rc.sysinit is split out into many independent services, each of which is well documented and easy to understand. I.e., if you don't like how systemd e.g. does it's fstab handling, then you can write your own little helper (in bash if you wish) to replace the official one. Doing this in the old initscripts is much harder because 1) it is not so clear which parts of rc.sysinit are dependent on eachother 2) any changes you do you'll have to merge on every update.

J'aime bien cette partie qui fout à la poubelle les arguments de anti systemd qui pense qu'ils pourront plus contrôler leur système après alors que c'est tout l'inverse…

C'est un peu facile de cracher sur systemd quand on utilise ArchLinux…

Ca fait des mois que l'init standard Archlinux me fait des FAILS sur toutes mes machines aléatoirement (un shutdown sur trois) donc dois je en déduire que l'init Archlinux n'est pas stable ?

Par contre, sur mon laptop sous ArchLinux avec systemd, je n'ai aucun problème…

Dans ce sens-là, des composants tels que xf86-video-nv ou systemd n'ont pas l'éthique
libre, pour moi.

Dans ce sens-là, tu dois penser la même chose de udev avant systemd non? Ce truc codé pour Linux et qui bloque la liberté des BSDistes…

Donc la perspective de devoir tous les réécrire et les maintenir pendant les deux ou trois
ans que va mettre systemd à crever ne m'enchante pas.

L'espoir fait vivre hein, bon courage :p

Désolé, je n'ai pas la place d'avoir deux installations de KDE (une en utilisation
courante et la version dév) chez moi. Je vais donc arrêter de traduire. Merci de m'avoir
ouvert les yeux.

Genre t'as un disque dur de 8Go ? C'est quand même un problème, alors je sais que les devs essayent de vous donner du contexte mais pas vous faire savoir si la phrase traduite va complètement défigurer une boite de dialogue…

Comment veux-tu motiver une équipe si elle se fait critiquer de la sorte ?

J'ose quand même espérer que les gens qui traduisent KDE ne le font pas pour moi, donc c'est mon avis, tranché certes mais c'est un problème que je n'ai jamais rencontré chez GNOME…

Et je tiens quand même à rappeler que c'est moi qui me suis fait agresser alors que je précisais juste que Amarok n'avait peu être traduit en Francais… Ah aucun moment je ne faisais une critique sur la trad de KDE à ce moment là… Après, si on m'y invite…