Not really involved with Linux for the past 15 years so don’t know the ins and outs of the systemd saga butyour debunking is not as convincing as you make it sound.
I do run a system at home that when all goes well I don’t need to login to or do troubleshootingfor months. (Ie. Movies and shows download fine, homeassistant works). I stumbled upon systemd a while ago when I had to google how to fucking find and look at some logs on my Ubuntu system. Wtf have been a sysadmin professionally for years until a decade ago. Never seen something changing like that, but I digress as for your points.
Being able to query logs like a database sounds appealing dont take me wrong. But If I am interested I will install splunk, graylog or whatever kids use these days, I don’t need a core component to make a major structural change (logging on Unix is expected to be in plain text, most tools on a Unix systems do some sort of manipulation of log files, and i expect to use cat, grep and tail to work on my logs). The fact that I can opt out is a minor consolation. Also if I want my logs not to be tampered with, I’ll look into how to do that with dedicated tools and technology. On most systems that’s not a concern, why would you even consider that something appealing?
As for sysvinit scripts pain, I hear you buy a) I am pretty sure most script I have written/modified were tens of lines of code, not hundreds, hardly an impossible task to deal with. And b) that’s not something your average user needs to do every day (or decade). Most likely a sysvinit script would be implemented once in the lifetime of a particular project by the developer themselves, or by a package maintainer.
If the solution to such a big problem is to have millions of lines of compiled code (that’s news to me, I’ll trust you on that number) it makes me wonder even more.
Are you sure all the counterarguments are really just bizarre nostalgia and easily debunked? I haven’t even read much about it and even when people like you try to sell how good systemd is, it looks to me like the solution we didn’t ask for a problem we didn’t have.
You can still log to text if you want by configuration (e.g. forward stuff to syslog) and you can use any tools you like to read those files you want. So if you like text logs you can get them. You can even invoke journalctl to output logs on an ad hoc / scheduled basis in a variety of text formats and delimited fields.
Binary allows structured logging (i.e. each log message is comprised of fields in a record), indexing and searching options that makes searches & queries faster. Just like in a database. e.g. if you want to search by date range, or a particular user then it’s easy and fast.
Binary also allows the log to be signed & immutable to prevent tampering, allow auditing, intrusion detection etc… e.g. if someone broke into a system they could not delete records without it being obvious.
So people object to systemd writing binary logs and yet they can get text, or throw it into splunk or do whatever they like. The purpose of the binary is make security, auditing and forensics better than it is for text.
As for scripts, the point I’m making is systemd didn’t supplant sysvinit, it supplanted upstart. Upstart recognized that writing massive scripts to start/stop/restart a process was stupid and chose an event driven model for running stuff in a more declarative way. Basically upstart used a job system that was triggered by an event, e.g. the runlevel changes, so execute a job that might be to kick off a process. Systemd chose a dependency based model for starting stuff. It seems like dists preferred the latter and moved over to it. Solaris has smf which serves a similar purpose as systemd.
So systemd is declarative - you describe a unit in a .service file - the process to start, the user id to run it with, what other units it depends on etc. and allow the system to figure out how to launch it and take care of other issues. It means stuff happens in the right order and in parallel if it can be. It’s fairly simple to write a unit file as opposed to a script. But if you needed to invoke a script you could do that too - write a unit file that invokes the script. You could even take a pre-existing init script and write a .service file that kicks it off.
As somebody who started my *nix journey on Unix System V, the OS that sysvinit came from, I think the grandparents comment is spot on.
Also, upstart could have been good, but it’s actually pretty great to see the majority of the ecosystem adopt a single new solution. We wouldn’t want the init landscape to be like the X vs Wayland and WM landscape.
Not really involved with Linux for the past 15 years so don’t know the ins and outs of the systemd saga butyour debunking is not as convincing as you make it sound. I do run a system at home that when all goes well I don’t need to login to or do troubleshootingfor months. (Ie. Movies and shows download fine, homeassistant works). I stumbled upon systemd a while ago when I had to google how to fucking find and look at some logs on my Ubuntu system. Wtf have been a sysadmin professionally for years until a decade ago. Never seen something changing like that, but I digress as for your points.
Being able to query logs like a database sounds appealing dont take me wrong. But If I am interested I will install splunk, graylog or whatever kids use these days, I don’t need a core component to make a major structural change (logging on Unix is expected to be in plain text, most tools on a Unix systems do some sort of manipulation of log files, and i expect to use cat, grep and tail to work on my logs). The fact that I can opt out is a minor consolation. Also if I want my logs not to be tampered with, I’ll look into how to do that with dedicated tools and technology. On most systems that’s not a concern, why would you even consider that something appealing?
As for sysvinit scripts pain, I hear you buy a) I am pretty sure most script I have written/modified were tens of lines of code, not hundreds, hardly an impossible task to deal with. And b) that’s not something your average user needs to do every day (or decade). Most likely a sysvinit script would be implemented once in the lifetime of a particular project by the developer themselves, or by a package maintainer. If the solution to such a big problem is to have millions of lines of compiled code (that’s news to me, I’ll trust you on that number) it makes me wonder even more.
Are you sure all the counterarguments are really just bizarre nostalgia and easily debunked? I haven’t even read much about it and even when people like you try to sell how good systemd is, it looks to me like the solution we didn’t ask for a problem we didn’t have.
Concerning logs:
So people object to systemd writing binary logs and yet they can get text, or throw it into splunk or do whatever they like. The purpose of the binary is make security, auditing and forensics better than it is for text.
As for scripts, the point I’m making is systemd didn’t supplant sysvinit, it supplanted upstart. Upstart recognized that writing massive scripts to start/stop/restart a process was stupid and chose an event driven model for running stuff in a more declarative way. Basically upstart used a job system that was triggered by an event, e.g. the runlevel changes, so execute a job that might be to kick off a process. Systemd chose a dependency based model for starting stuff. It seems like dists preferred the latter and moved over to it. Solaris has smf which serves a similar purpose as systemd.
So systemd is declarative - you describe a unit in a .service file - the process to start, the user id to run it with, what other units it depends on etc. and allow the system to figure out how to launch it and take care of other issues. It means stuff happens in the right order and in parallel if it can be. It’s fairly simple to write a unit file as opposed to a script. But if you needed to invoke a script you could do that too - write a unit file that invokes the script. You could even take a pre-existing init script and write a .service file that kicks it off.
As somebody who started my *nix journey on Unix System V, the OS that sysvinit came from, I think the grandparents comment is spot on.
Also, upstart could have been good, but it’s actually pretty great to see the majority of the ecosystem adopt a single new solution. We wouldn’t want the init landscape to be like the X vs Wayland and WM landscape.