Alex a écrit 1849 commentaires

Si il y avait un choix (aussi utilisable) en micro noyau, je pense qu'on serait nombreux à apprécier

Mais on va tomber dans un autre débat stérile

moins verbeux, mais c'est une interpretation perso

pour 90% des features, oui
donc je reformule, "est il nécessaire que le système d'init fasse des choses qui ne sont pas lié à l'init, et que d'autres outils font très bien (modularité) au prix d'une compléxité un peu plus élevé (n interfaces à maitriser)"

la question est "est il pertinent que ce soit le système d'init qui gère tout ça plutôt qu'un outil spécialisé dans chaque tache ?"

que le système d'init devienne un vrai bloat m'embête
avoir une seule interface pour effectuer toutes ses opérations me plait

Pas de troll sur gnome ?

le troll sur systemd aurait-il épuisé tous les trolleurs du coin ?
À moins que tout le monde attende minuit pour passer au stade supérieur de trollisation

Mais vois-tu, sans vouloir troller plus, c'est ce qui AMHA gène la plupart des users (en dehors de la non-portabilité, et des dépendances):

si systemd ne me convient pas pour une utilisation, je ne peux pas simplement changer un composant (mais au moins je peux scripter).

A l'inverse, autant il ne me gêne pas d'avoir systemd sur mes machines persos, mais sur les 2/3 machines que j'administre à distance, j'aimerai bien utilisé journald (et même le conseiller en test à des clients), néanmoins à l'heure actuelle il me parait prématuré d'installer systemd, et de déployé tout ce va autour

Bon il reste aussi apparement de vrai problèmes à résoudre, notament sur le montage des vpns et des volumes chiffrés

Mais c'est pour cela que j'aurai préféré que systemd ne veuille pas remplacer la plupart des services "classiques" unix.

Sur ton exemple sur cron, au contraire j'y vois la souplesse d'unix en 2 points:
- la capacité de mettre du shell (même si en effet c’est crade, ça offre de la souplesse)
- la capacité de changer le composant si nécessaire, pour ce genre de problèmes j'ai utilisé une alternative a cron et une a syslog
si systemd n'adresse pas correctement un problème, est il possible de modifier son comportement (par du script par ex), ou d'utiliser un autre composant en parallèle sans foutre le bordel partout ? (c'est une vrai question, pas un début de troll)
à l'inverse peut-on utilisé journald sans systemd ?

le format plist peut aussi bien être du json (pour le barbu), binaire (pour ceux qui trouve que le fichier texte ca fait trop barbu), ou du xml (pour les autres). C'est effectivement le format idéal

Tu as raison, lennart fait des outils bien trop compliqué (et des trolls de bien trop haut niveau) pour une simple femme (et les apparentés tels les féministes).
Lennart veut rendre linux a son propriétaire d'origine: le vrai barbu

Tiens, des arguments qui tiennent la route et qui ne parlent pas de résistance au changement ou je ne sais quelle autre connerie

et tu as raison, il y a bien sûr des plus values, et c'est pour ça que je disais que c'était un bon outil

Par contre j'avais déjà vu ces tableaux, j'espère qu'on sera d’accord pour dire qu'ils ne valent pas grand-chose, il est toujours facile de créer ce genre de comparatif qui tourne à l'avantage de qui on veut.
Bon après, il est vrai que je ne sais pas à quoi correspondent certaines features, et que justement l'une des critiques envers systemd est qu'il essaye de tout faire au lieu de laisser chaque tache à un outil dédié.

Si il y a autant de gens qui savent ce qui ne va pas dans systemd, pourquoi ne travaillent-ils pas ensemble pour faire quelque chose qui va?

systemd n'apporte pas de nouveautés, il agrège dans un seul outil des composants déjà existant.
Il y a déjà un système fonctionnel qui fait la même chose, pas besoin d'en recoder un autre

En fait AMHA, systemd est un bon outil, mais il s'écarte fortement de l'esprit unix (KISS, un outil par tache, modularité des composants, etc…) d'où une certaine résistance.
Rajoute à celà le caractère de lennart qui pousse fortement son produit en voulant y intégrer des éléments qui avant se voulait modulaire, le troll est loin d'être mort

du coup:

Il est si difficile de l'étendre en ajoutant des fonctionnalités

ben c'est l'inverse qui est demandé

Un fichier binaire corrompu, si ton outil n'a pas une certaine tolérance aux fautes, tu pourras difficilement l’exploiter.
Pour un fichier texte le problème est le même, néanmoins un oeil humain aura plus de facilité à récupérer de l'information.

Ceci dit, si journald a une sortie de type "classique", il me semble que ce troll n'a pas lieu d'être

je pensais plus à un système de chiffrement par flux

ceci dit je suis hs vu qu'il parlait plus de signature que de chiffrement

La question c'est est-ce que les logs sont exploitables en cas de gros crash de la machine ?
est-ce que petites modifications du binaire rendent de grosses parties du log inexploitable ?
est-ce que si le système redémarre dans un niveau d'init bas (partoche en ro, services non lancés, lib inaccessible, pas de machines de secours), on peut toujours utilisé journalctl ?

Et est ce que çela corrige les manques de(s) syslog(s) ? (signature, authentification des machines envoyant des logs, et surement d'autres)

Ceci dit avoir des logs aisément filtrable est une bonne idée, tant que je peux avoir en même temps une sortie texte "classique", et ce même si je regrette qu'il n'utilise pas un db texte.

Le coté temps réel ?

Ces problèmes ne sont-ils pas simplement un manque de fonctionnalités dû à la jeunesse de la chose?

Certainement, mais actuellement c'est vu comme des régressions, d'où la critique sur l'adoption trop rapide par les distros

Pour le "linux only", udev est linux only et ne pose pas de problème philosophique aux critiqueurs

Mouais, j'ai entendu pas mal de critique sur udev aussi (mais bon on sortait de devfs, de hotplug et de je ne sais plus quoi d'autre, donc les critiques devaient être émoussées)
de plus il est plus facile de se passé de udev que du système d'init.

Mais bon je trolle je trolle, le peu que je connais de systemd me plait bien (ptet que je suis devenu un trolleur de haut niveau finalement), même si je lui reproche certaines choses (la non portabilité, le coté bloat, j'ai même lu qu'à terme ça voulait remplacer cron ! ). De toute façon quoique quelqu'un fasse (y compris ne rien faire) il y aura toujours des mécontents

Si c'était la seconde partie:
risque pour la stabilité, moins de souplesse dans les déploiement

systemd est peut-être la pour répondre au problèmes de l'admin

Bien sur, ça ne veut pas dire que cela y réponde
mais ça y répond peut être très bien, je rebondissais juste qu'on n'ait pas placé l'admin dans la liste des gens ayant de bonne raison d'adopter systemd

perso je ne suis pas admin, ceux que je connais ne sont pas fan, surtout pour le coté bloat et le risque pour la stabilité de leur système.

en plus, ses fichiers de config seront les mêmes sur toutes les distros qu'il a à gérer

Mouais, ou la minorité d'admin qui n'ont que linux en unix

systemd est sponsorisé par RedHat, dont le but est de vendre. Et il n'y a pas mieux pour vendre du Linux que de se mettre l'admin dans la poche, qui argumentera sur le gain de temps de la distro.

Mouais, et c'est grâce à l'admin que linux c'est développé.
Néanmoins vendre et répondre au besoin ne vont pas nécessairement de paire, même si redhat est la mieu vendue je n'ai pas l'impression qu'elle fasse l’unanimité chez les admins (changement brutal de techno, support couteux, etc…)

J'ai plutôt l'impression que les gens qui refusent le changement se braquent

Si il y a une constante, c'est bien ça: beaucoup d'early adopters qui veulent tout changer tout de suite, et beaucoup de gens craintifs au changement.

Néanmoins ici je vois des arguments intéressants , philosophiques (bloat, adoption trop rapide par les distros) et techniques (problème avec l'utilisation de partition chiffrés, vpn, dépendances, linux only, services en doublon )

L'utilisateur ne voit absolument pas systemd (ou alors, on n'a pas la même notion d'utilisateurs…)

tu as raison, je pense même que ça apportera des plus à l'utilisateur lambda, ne serait ce que pour les futurs ihm qui controleront l'outil via dbus

L'admin, qu'est-ce qui te fait dire que ce n'est pas mieux pour lui aussi?

peut être, néanmoins je vois souvent les admins pestés contre les bloatware surtout pour tout ce qui est critique (et j'ai la prétention de croire que c'est le cas du système d'init, ainsi que de pas mal de features que systemd reprend a son compte)
on trouve dans systemd n'est plus qu'un système d'init, il prend en charge inetd, reprend a son compte une partie de ce que fait cron, fait du monitoring de process, etc… mais fait (actuellement) doublons avec d'autres process courrament utilisés

C'est fou comme on peut vouloir demander tout aux autres…

Pas plus que ce qu'on lui demande à lui même.
Faut arrêter ce genre de logique, le dev fait un taf, le mainteneur fait un taf, l'admin fait un taf, les 2 premiers sont sensé travaillés pour que le 3ème puisse faire son travail correctement (oui je sais, moi aussi j'ai fait des patchs qui ne servaient qu'à moi même)
l'admin on lui demande suffisament de choses pour qu'il ne se fasse pas chier à maintenir lui même des système que d'autres considèrent comme deprecated.
Mais en effet, si la solution ne lui convient pas, il passera sur autre chose

Grande nouvelle : à l'école, tu n'apprends quasiment rien. Tout ce que je fais aujourd'hui, je l'ai appris sur le tas. Les études ne m'ont servi qu'à apprendre une méthodologie et une façon de travailler.

C'est vrai à partir du lycée, mais il me semble que ce que tu apprends bettement avant sert de socle, socle particulièrement difficile à rattraper par la suite (il suffit de voir les galères de ceux qui tentent d'apprendre à lire à 30 ans)

Si c'etait une si mauvaise idee, pourquoi la majorite des gens qui font des distribs, developpe des plateformes ou developpe du soft sur Linux suivent le mouvement ?

Parce que ça leur offre plein d'avantage, il manque c'est l'avis de l'utilisateur, ou surtout de l'admin
ce que je dis est un troll gratuit, je ne suis pas admin (ou que de mes serveurs perso), et je connais peu/pas systemd, et je dirai même qu'à titre perso j'y vois certains avantage
Mais j'imagine assez facilement les craintes d'un admin: un composant critique et bas niveau éffectuant énormément de taches et interagissant avec des composants haut niveau, à la place d'un ensemble de composant n'effectuant chacun qu'une seule tache.

mdr

Mais c'est un effet assez classique, d'où l'importance d'une première version utilisable
Je me suis rendu compte de la même chose au sujet de java: je trollais modérément ("java est une version raté de smalltalk") en avançant mes arguments (gestion de io, cast vers obj, dépendance dans les jars, etc…).
On m'a fait constater que la plupart des problèmes avaient été corrigés depuis les dernières fois où j'avais été contraint d'utilisé java.

Son but étant de montrer le cout d'un fork
tu peux faire le test avec de 1 à 50 wc

ce qui est plus intéressant, c'est que chez moi ce n'est pas tant le temps passé dans le noyau qui coute, mais bien le temps en userland

time for i in {1..100}; do echo "plop" | wc   2&> /dev/null ; done

real    0m0.208s
user    0m0.340s
sys     0m0.164s

time for i in {1..100}; do echo "plop" | wc  |wc |wc|wc |wc|wc |wc|wc  2&> /dev/null ; done

real    0m0.478s
user    0m2.272s
sys     0m0.860s

On parle ici du propriétaire (donc celui qui a acheté l'oeuvre, non l'auteur)
il me semble donc que ça ne correspond pas à ce que tu indiques

Pas besoin de généraliser à tout les datacenter

Ceci dit, excellent blog, je ne connaissais pas, merci

Un peu le bordel

mes parents font leur backups chez moi (sur mon nas via un vpn entre nous… vivement la fibre ;) )
mes backups sont sur un volume hubic, et non chiffrés pour 99% des trucs, chiffré pour le reste

bup ne marche pas sur mon nas ni sur du webdav (comme rsnapshot), du coup j'ai des scripts un peu crade pour avoir un backup à la timevault

ça marchote, mais ce n'est pas une solution que je recommande