hum... De nos jours, un poste client redémarre aussi souvent qu'un serveur.
De nos jours, il y a encore des logiciels qui n’existent que sous Windows.
Donc sur un poste en double boot...
hum... De nos jours, un poste client redémarre aussi souvent qu'un serveur.
Quand tu mets à jour le noyau ou la glibc, il faut bien le redémarrer. Si tu peux le faire proprement sans que ça bloque, c’est bien aussi.
Conneries
Toujours aussi poli.
personne ne force à utiliser systemd
Si tu veux toutes les fonctionnalités de certains logiciels (notamment des environnements graphiques), tu ne peux pas vraiment faire autrement.
Ubuntu? Tu parles des gens qui essayent d'imposer Mir la... Ce n'est pas un argument
Ils font des conneries, donc les gens qui utilisent leur distribution, même nombreux, ne comptent pas ?
Et le pire dans ce que tu dis, c'est qu'en quelques ligne tu dis une chose est son contraire : "quasiment plus possible d’éviter systemd" puis "la distribution la plus populaire n’a pas adopté systemd", désolé mais quand la disstribution la plus populaire n'adopte pas x, j'ai du mal à imagine que tu ne peux pas éviter x, suffit de prendre la plus populaire (la popularité d'un distro t'étant importante dans ton argumentation, ça devrait aller).
C’est-à-dire que tu peux éviter systemd soit en acceptant de te passer de fonctionnalités qui existaient avant (notamment celles liées auparavant à console kit, que systemd a remplacé aussi), soit en développant comme Ubuntu ce qu’il faut pour simuler son API, soit en utilisant Ubuntu, la distribution avec un système d’init plus merdique que systemd.
En gros, tu as le choix de ne pas utiliser systemd en ayant moins bien que ce qui existait avant. Pas terrible.
Il remplace (hormis le système d’init) l’automontage (mal), la gestion de la veille (sans fournir toutes les fonctionnalités non plus), les journaux système...
ben oui, c'est lié... Pareil, on n'est plus en 1990, les besoins ont évolués.
Je ne vois pas le rapport avec le point auquel tu réponds.
Mais tu veux dire qu’avant, on pouvait vouloir que son portable éteigne juste l’écran quand on le replie alors qu’il est sur secteur, et qu’il mette le portable en hibernation si on est sur batterie, mais qu’en 2013 ce n’est plus un besoin légitime ?
C’est facile de dire que les besoins ne sont plus les mêmes qu’en 1990.
Déjà, c’est de la mauvaise foi, puisque les besoins comme les fonctionnalités ont évolué entre 1990 et l’avènement de systemd, et d’autre part, les besoins existent toujours pour une bonne partie. Il y a plus de portables, mais les postes fixes en réseau sont encore nombreux en environnement professionnel.
Donc leur système actuel ne répond pas à leur besoin ("simple", ha ha ha) ok :)
Simple, ce n’est pas la même chose que facile.
C’est peut-être plus facile pour l’utilisateur d’une distribution Linux de configurer ses services avec systemd, mais si je veux comprendre entièrement le système d’init en lisant son code, j’aurai beaucoup plus vite fait avec un init BSD. Si je maintenais un système Unix non Linux, j’aurais aussi beaucoup moins de mal à avoir un init BSD que de me coltiner l’adaptation du noyau à systemd ou l’inverse.
Donc je persiste : l’init BSD est plus simple.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Re: C’est du propre
Posté par Arthur Accroc . En réponse à la dépêche Entretien avec François Tigeot, développeur DragonFly BSD. Évalué à 5.
De nos jours, il y a encore des logiciels qui n’existent que sous Windows.
Donc sur un poste en double boot...
Quand tu mets à jour le noyau ou la glibc, il faut bien le redémarrer. Si tu peux le faire proprement sans que ça bloque, c’est bien aussi.
Toujours aussi poli.
Si tu veux toutes les fonctionnalités de certains logiciels (notamment des environnements graphiques), tu ne peux pas vraiment faire autrement.
Ils font des conneries, donc les gens qui utilisent leur distribution, même nombreux, ne comptent pas ?
C’est-à-dire que tu peux éviter systemd soit en acceptant de te passer de fonctionnalités qui existaient avant (notamment celles liées auparavant à console kit, que systemd a remplacé aussi), soit en développant comme Ubuntu ce qu’il faut pour simuler son API, soit en utilisant Ubuntu, la distribution avec un système d’init plus merdique que systemd.
En gros, tu as le choix de ne pas utiliser systemd en ayant moins bien que ce qui existait avant. Pas terrible.
Je ne vois pas le rapport avec le point auquel tu réponds.
Mais tu veux dire qu’avant, on pouvait vouloir que son portable éteigne juste l’écran quand on le replie alors qu’il est sur secteur, et qu’il mette le portable en hibernation si on est sur batterie, mais qu’en 2013 ce n’est plus un besoin légitime ?
C’est facile de dire que les besoins ne sont plus les mêmes qu’en 1990.
Déjà, c’est de la mauvaise foi, puisque les besoins comme les fonctionnalités ont évolué entre 1990 et l’avènement de systemd, et d’autre part, les besoins existent toujours pour une bonne partie. Il y a plus de portables, mais les postes fixes en réseau sont encore nombreux en environnement professionnel.
Simple, ce n’est pas la même chose que facile.
C’est peut-être plus facile pour l’utilisateur d’une distribution Linux de configurer ses services avec systemd, mais si je veux comprendre entièrement le système d’init en lisant son code, j’aurai beaucoup plus vite fait avec un init BSD. Si je maintenais un système Unix non Linux, j’aurais aussi beaucoup moins de mal à avoir un init BSD que de me coltiner l’adaptation du noyau à systemd ou l’inverse.
Donc je persiste : l’init BSD est plus simple.
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone