Systemd lead developer Lennart Poettering has posted on Mastodon about their upcoming v256 release of Systemd, which is expected to include a sudo replacem...
Why do you consider it as poisoning? I’ve heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they’re a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that’s wasting disk space on a binary format no one wants or needs), and it didn’t stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don’t get the issue with binary logs.
Yes, and many distros have that out of the box… But they don’t have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that’s since long fixed now and I’ve not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don’t need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don’t get the issue here
I was arguing how it is a very useful tool with many great additions, rather than rely on the: “no old better!” reply based on ignorance. But it looks like your replies have turned full removed, so no point in continuing here to try and educate you.
Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.
Isn’t the guy behind systemd a (former?) Microsoft employee? I feel as though that might offer a clue as to why the trajectory towards bloat.
It is. He is poisoning Linux, slowly, from the inside. Like the XZ attack, just smarter and much slower.
Why do you consider it as poisoning? I’ve heard the argument about not doing things the traditional Linux way (binary logs for example). But if the alternative provides so many benefits, why is it an issue? Systemd is a piece of cake for all parties compared to sysvinit and alternatives, so why is it bad when it solves so many issued, and makes it super easy to use by just adding e.g. a new option to a Unit?
Another example: timers are more complex than cronjobs, but timers offer additional needed features like dependencies, persistence, easy and understandable syntax, and more. So although more complex, once you get the hang of them, they’re a very welcomed feature imo
By itself, solely doing init, it would have been fine, however, binary logging (even if you eventually end up with a text log, that’s wasting disk space on a binary format no one wants or needs), and it didn’t stop there. He keeps replacing Linux subsystem after subsystem, and many of those replacements are not progress, just duplication of effort and creates more ways for configuration drift.
You can still forward to text syslog or to a central logging server like Loki if working with multiple hosts. I still don’t get the issue with binary logs.
Yes, and many distros have that out of the box… But they don’t have it sent to keep the binary journal as close to empty as possible. So you end up with twice the space in use for logs. As for the issue with binary logs, text logs can be read by far more tools and utilities, rather than just journalctl and pipes.
You can set the space limit for journals logs really low then, to avoid double space usage. As for the last argument, that also was an issue for me years ago because not all tools were compatible with the journald format, but that’s since long fixed now and I’ve not experienced any issue for a long time. Journal logs provide a standard format for all applications, so third party tools don’t need to be compatible with every log format of your applications. And it also comes with great additional features like -b or --since etc. So I still don’t get the issue here
The issue is logs are suppose to be text. Seriously, wtf. You some Poettering fan boy or something?
I was arguing how it is a very useful tool with many great additions, rather than rely on the: “no old better!” reply based on ignorance. But it looks like your replies have turned full removed, so no point in continuing here to try and educate you.
Here is the rationale for the Journal. In short it is really not that simple and it has a lot of advantages over simple text files and it saves disk space.
Having the logs twice is saving space, got it. Do you hear yourself?