Reprise du message précédent :
Uselessd est annoncé, un fork de systemd 208 avec pour principe de ne garder que les composants principaux, d'avoir à terme la portabilité en pid2 sur freebsd  
 
http://uselessd.darknedgy.net/
 
Et ca cogne dur :  
 

 
Oui, on dirait un discourt politique, pas content le gars. Sinon on peut aussi lui apprendre que le refactoring de n'importe quel soft qui a un certain temps d'existence, ça donnera "mécaniquement" un truc "mieux". Par contre il est vrai que l'adhérence grandissante systemd / gnome n'est pas vraiment terrible, ça finira encore en fork ce truc.

Probable, en tous cas c'est intéressant de voir des projets se développer en fork ou en module de remplacement compatibilité.
Paradoxalement c'est aussi ce qui pourrait limiter les débats politiques et favoriser l'adoption plus vaste de systemd en n'en faisant pas un composant incontournable

La suite des éléments de portage d'une interface pour les logiciels dépendants de systemd sous openBSD
 

Waouh, du Théo "mesuré", impressionnant

 
Je m'auto quote, un refactoring va arriver (autre que celui de uselessd)

un papier intéressant relayé sur slashdot
 
http://www.infoworld.com/article/2 [...] -wars.html

 
En quoi c'est intéressant ? Rien que le début du second paragraphe montre encore et encore et encore que le mec parle d'un truc qui ne connait pas... J'ai fait l'effort de lire cette pile de conneries, ça montre bien une chose, qu'il soit pro-Windows et pro-Linux, un mec borné restera borné, et surtout aime parler de ce qu'il en connait pas.

En effet. Genre ya personne qui utilise systemd sur des serveurs

Tu as lu ?
 
Il ne fait que raconter des trucs qui vont être vécus (ou pas) par les autres, son expérience personnelle = 0. Merci mais quand on sort directement que encore une fois on a pas de log en texte, on est juste un incompétent complet sur le sujet.

Oui j'ai lu. Il assène des « vérités » sans en avoir usage. Dire que c'est être un nœud-nœud de pas savoir utiliser Bash et que c'est pour ça qu'on veut remplacer par SystemD

C'est mon associé qui est développeur à temps plein (et qui a un sacré niveau), qui préfère 100000 de fois SystemD à des scripts Bash en terme de maintenabilité et de simplicité. Je peux pas (et veux pas) le contredire.

Ok, donc ça me va

4 messages, 4 trolls, pas mal.

Mais est-ce que c'est au développeur de choisir/imposer le système de lancement utilisé sur un serveur ?  

* systemctl enable devops *

 
Non, ce n'est pas imposé, mais on travaille en équipe, et on en a discuté. Quand je prend 4 secondes à lire un fichier d'init SystemD VS 10 minutes pour certains trucs en Bash, c'est quand même pas pareil.
 
On est deux à administrer, même si c'est moi qui fait 80% du taff (c'était bien l'intitulé officiel de mon poste d'avant). Je disais que c'était justement intéressant d'avoir l'avis d'un dev, surtout comme celui de mon associé qui n'aime pas le code crade (et franchement, me dit pas que Bash c'est pas crade...)

Le multi piping et la granularité des logs systemd est réalisée en mode kernel, elle est crade de facto. Un log ou system d'init n'a pas a tourner en mode kernel 100% du temps pour raison de sécurité. (pour être propre, le canal de communication doit être ouvert quand on en a besoin et fermé dès qu'on en a plus besoin, pas rester en mémoire)

Qu'est-ce que tu veux que je te dise, on a pas les même besoins ni les même impératifs

Le confort que m'apporte Systemd est vraiment important, et pour l'instant, je n'ai pas été confronté à un seul point limitant pour mon usage.

Et puis merde quoi, on est dans le monde UNIX, ya le choix, et si ça convient pas, il y a suffisamment de monde pour faire une alternative ! Je reste sur mon point de vue : Systemd est un progrès, et en plus ça a fait bouger les choses

Yep, mais se qui est vrai d'un côté (qu'on ai le choix d'utiliser systemd pour raisons X ou Y) doit l'être aussi dans l'autre (qu'on puisse ne pas utiliser systemd pour raisons X ou Y). Que ça soit un progrès reste assez discutable (d'autres alternatives qui sont historiquement plus anciennes et mieux foutus sur beaucoup de points existaient avant systemd, pourquoi réinventer la roue, ou bien pourquoi systemd et pas upstart, openrc, ou autre alternative ?)
On voudrait nous faire croire que systemd est une révolution, alors qu'il n'est qu'un parmi d'autres.

Je me fais pas de soucis que tu puisses faire comme tu le sens, il y a rarement UNE solution hégémonique dans le libre (cf KDE/GS, Vim/EMACS, etc.) Je suis pas inquiet pour ça
 
Concernant Systemd, son adoption vient à mon avis (entre autre) du fait que ça soit simple à l'utilisation, ce qui est un gros gros plus.

Mieux foutu ce qui a été fait avant ? Ça serait intéressant d'argumenter, je sais bien que le syndrome NIH est pas mal présent chez les dev, mais il y a un réel confort à utiliser systemd, dans l'embarqué part exemple, j'ai pu virer dhcpcd et chrony pour des "extensions" systemd super bien intégrées.

 
Quand tu commencera a taper dans du busybox où de la conf WRT et voir comment on administre autre chose qu'une arch, tu pourra venir discuter d'argumentation.

Tu n'as aucune idée de ce que j'ai/je fais pour le boulot et en dehors. Merci.

Tout aussi affligeant que de lire quelqu'un nous rabâcher les oreilles avec son prosélytisme sur systemd. La question n'est pas que j'aime ou pas systemd, la question est que toi, tu vienne nous dire que systemd est seul, unique, et qu'il fait tout bien, qu'il n'y a rien a redire dessus et qu'il n'existe aucune alternative, alors que c'est juste faux. Et y'a pas besoin d'argumenter la dessus, puisqu'en termes d'init, il existe d'autres choses a commencer par se que systemd cherche a remplacer, niveau gestion des daemons, y'a openrc, launchd, upstart, j'en passe, au niveau services/process y'a autre chose aussi (runit, minit, S6 ( http://www.skarnet.org/software/s6/#related )...)
Tu confond également utilisation baremetal et manager (dhcpcd vs dhcp baremetal vs systemd dhcpd) entre autres.

Merci de chercher à me faire dire ce que je n'ai pas dit (je ne parles pas du quote original un peu sec) sur systemd, et les autres systèmes d'init dans me topic dédié au premier cité. On va en rester la, déjà que tes posts sont très limites.

Ben, ce post illustre bien se qu'on reproche aux devs de systemd en même temps.  
L'init sur n'importe quel OS est le parent pauvre de la communication, personne avant eux n'a communiqué sur l'init uniquement et a juste titre, y'a rien a en dire qui puisse réellement intéresser l'utilisateur final.
C'est purement philosophique et politique. Alors ils essayent de justifier le battage autour des "features" sauf que dans leurs approches il y a clairement du pour et du contre.  
Un topic dédié aux autres systèmes d'init ? A quoi bon ? Autant comparer sur le seul topic existant, ça ira plus vite. Et donc oui ensuite on compare les features de systemd avec l'existant sur son propre topic se qui me semble normal. Pas la peine de s'en offusquer ensuite de dire que systemd implémente les choses de manière peu élégante ou manquant d'optimisation/a l'utilisation obscure.

Honnêtement, en cas de problème au lancement d'un service, je préfère 100 fois lire un script bash que de devoir aller fouiller dans des centaines de milliers de ligne de code en C pour comprendre d'où vient mon problème
 
En plus bash permet de faire le goret dans le code pour débugguer, et ça c'est bien
 

 
 
wat ?  

Bah si ton script systemd est réduit à son strict minimum, c'est que c'est lui qui gère tout le côté "gore" de la chose, donc en cas de bug/incompatibilité/effet de bord, faut bien aller voir ce qui se passe derrière

Euh il ne fait que lancer un programme, donc si ça merde je lance la commande à la main et je regarde ce que ça fait. Je vois pas pourquoi j'irai voir dans les entrailles de Systemd

edit : c'est dans la même veine que Cron quoi.

 
pour moi c'est ca le point essentiel : l'imbrication mécanique et non négociable de systemd comme dépendance de pleins de briques logicielles

Je ne pense pas qu'il ne fasse que ça

http://lists.freedesktop.org/archi [...] 24662.html
 
Version 217 annoncée

Tu regardes aussi le code de bash quand ton script fait n'importe quoi donc ?

Bash est quand même vachement plus éprouvé que systemd
 
/haha_shellshock-proof

Et Dash aussi ?

pour une comparaison plus éclairée, je vous conseille les pages de linux from scratch qui propose les deux inits en builds officielles
 
Systemd
http://www.linuxfromscratch.org/lf [...] ction.html
 
Initscripts
http://www.linuxfromscratch.org/lf [...] ction.html
http://www.linuxfromscratch.org/lf [...] part4.html

Ah non, celui-là est moisi, une fois j'ai accepté qu'il devienne le shell par défaut, je suis vite revenu en arrière

 
Rien que ça, ça va réduire drastiquement l'utilisation de systemd dans les serveurs (où comment redhat se tire une balle dans le pied pour l'utilisation dans les datacenter)
 

Epic aussi celle là, exit donc certaines cartes SCSI, je t'explique pas aussi si tu veux faire un chargement dynamique des firmware avec les cartes radeon et le driver libre (qui peut nécessiter le chargement du firmware pour je sais pas moi ... Le décodage hard des fichiers multimedia ?)
 

Super ça, si t'as pas les logs, tu peut planter ton système avec un timeout aussi long.
 

J'ai pas franchement envie que udev touche a certains de mes tags.

Bof, ça ne concerne que la phase de boot, et franchement gagner 5ms (ou même 10 secondes) sur le boot de mes serveurs, rien à battre perso

Sauf que si t'as des cartes qui ont une utilisation soutenue de readadead et que c'est autant la misère qu'avant pour charger un firmware, le gain d'avoir systemd revient a 0, tu bloat ton système pour quedale, super la feature qui devait apporter un plus pour au final retourner a l'ancienne, configuration des firm dans le kernel/initrd et gestion readahead par device et pas system-wide.