Tout ce que je dit est que j'ai un système qui fonctionne très bien sans systemd, et que je ne vois par conséquent aucun avantage à changer de système d'init pour un autre qui a autant de bugs. Je ne parle pas que des forums, mais aussi des bugzillas. Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs. C'est un fait, alors qu'on arrête de nous vendre ce truc comme un programme stable et bien testé. Utilisez d'autres arguments que le fait que des distros qui vivent en vendant leurs services veulent nous vendre un truc avec lequel elles sont sur de vendre leurs services.
Sur les plantées du kernel, celles que j'ai expérimentées étaient liées à des bugs hardware ou du bios. Ainsi qu'à des kernels de distributions qui chargent le mauvais driver. C'est pourquoi j'utilise toujours mes propres kernels, ceci même avec les distributions binaires. Ceci permet aussi de les optimiser pour ce que je veux faire avec l'ordi. C'est un des avantages de linux, c'est que nous pouvons faire nos propres kernels. Dans cette optique, je suis aussi réticent à me mettre à systemd car il me forcerait à rajouter des cgroups dont je n'ai pas besoin à celui que j'utilise. Et je n'ai pas envie de me retrouver avec une usine à gaz déjà dans le kernel.
Quand aux performances qui se dégradent, la dernière fois que cela m'est arrivé, c'était du temps des mono-processeurs, avec du multi-coeur, je n'ai jamais rien remarqué de bien sérieux, alors que je fais pas mal de compilation et d'audio temps réel. C'est sur qu'il faut trimer les priorités du système, mais entre une pause du bureau d'une fraction de seconde, ou une pause de plusieurs dizaines de secondes comme j'ai pu en observer avec des kernels temps réel sur des mono-processeurs, il y a une sacrée différence. Le plus remarquable est que pendant ces pauses du bureau, le kernel et les logiciels jack continuaient à fonctionner, ce qui prouve la fiabilité du kernel. Ces pauses ont disparu dés que je suis passé à du multicoeur pour ne plus devenir que de minuscules glitchs visuels.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.
[^] # Re: De plus en plus complexe, le système d'init...
Posté par Domi . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à -2.
Tout ce que je dit est que j'ai un système qui fonctionne très bien sans systemd, et que je ne vois par conséquent aucun avantage à changer de système d'init pour un autre qui a autant de bugs. Je ne parle pas que des forums, mais aussi des bugzillas. Je ne sais pas si le record est battu, mais je sait que systemd est parmi les programmes qui ont vraiment beaucoup de bugs. C'est un fait, alors qu'on arrête de nous vendre ce truc comme un programme stable et bien testé. Utilisez d'autres arguments que le fait que des distros qui vivent en vendant leurs services veulent nous vendre un truc avec lequel elles sont sur de vendre leurs services.
Sur les plantées du kernel, celles que j'ai expérimentées étaient liées à des bugs hardware ou du bios. Ainsi qu'à des kernels de distributions qui chargent le mauvais driver. C'est pourquoi j'utilise toujours mes propres kernels, ceci même avec les distributions binaires. Ceci permet aussi de les optimiser pour ce que je veux faire avec l'ordi. C'est un des avantages de linux, c'est que nous pouvons faire nos propres kernels. Dans cette optique, je suis aussi réticent à me mettre à systemd car il me forcerait à rajouter des cgroups dont je n'ai pas besoin à celui que j'utilise. Et je n'ai pas envie de me retrouver avec une usine à gaz déjà dans le kernel.
Quand aux performances qui se dégradent, la dernière fois que cela m'est arrivé, c'était du temps des mono-processeurs, avec du multi-coeur, je n'ai jamais rien remarqué de bien sérieux, alors que je fais pas mal de compilation et d'audio temps réel. C'est sur qu'il faut trimer les priorités du système, mais entre une pause du bureau d'une fraction de seconde, ou une pause de plusieurs dizaines de secondes comme j'ai pu en observer avec des kernels temps réel sur des mono-processeurs, il y a une sacrée différence. Le plus remarquable est que pendant ces pauses du bureau, le kernel et les logiciels jack continuaient à fonctionner, ce qui prouve la fiabilité du kernel. Ces pauses ont disparu dés que je suis passé à du multicoeur pour ne plus devenir que de minuscules glitchs visuels.
Aux agents des services secrets qui lisez ce message, veuillez considérer que défendre votre nation contre ces ennemis interieurs et extérieurs implique de suivre l'exemple de Snowden.