Watch out: That mindset is what got me into Rust in the first place!
I was so fed up with everybody drowning on about Rust that I thought I need to read up on it a bit so that I can argue against the hype. I am a seasoned C++ dev after all, I use a language that I picked because it allowed for robust and fast code. What could Rust add on top of that?
Well, I have a job working almost exclusively with rust now and do not plan to ever go back.
With textlogs you have a hard time noticing a couple of added/removed/changed characters or even entire log entries. Thats exactly why some industries may not use text logs in the first place as permanent records that are at least temper-evident are mandated.
If binary logs go kaputt they tell you exactly which entries were effected and still display every bit of data they contain. Typically you do not grep in binary logs: Grep can not make sense of all the extra data in the logs (way more than in a typical syslog), so grep is just a poor tool for the job. You typically can use grep as binary logs so contain lots of text. This is ignoring compression, encryption and other extras of course.
Fuck binary logs too.
Text logs are binary, too... they just uses a pretty common binary encoding.
Where do you actually use text logs? I did not use text logs outside of hobby machines ever during my career. Logs were either aggregated in databases or at least stored in temper-resistant formats (usually due to legal requirements).
Do you actually use text logs in a professional setting? Just curious.
I am not trying to convince you: Use whatever you want.I am trying to explain it, so that people can have a more informed discussion. The web is full of either systemd is the best since sliced bread and systems is horrible. It is neither: It is just a technical system that made technical choices that make certain things easier or even possible and others harder or even impossible.
The sytemd time thingy is actually more minimal than openntpd: It only supports sNTP and not the full NTP protocol and is a client only... Openntpd is a full NTP implementation with both client and server. It also is a great technical choice, so keep using it, especially when you need an NTP daemon.
You behemoth is my plumbing layer:-)
I like the ton of small and simple tools that systems brings along: systemd-nspawn is a really lightweight way to run containers that works basically everywhere, no need to install docker or podman. Disk resizing, sysusers, tmpfiles, boot, Key Management, homed, etc. enables me to build reliable, immutable images for my systems. There is no tooling whatsoever for this outside the systems umbrella.
If you do not try to build a 1980-style UNIX system, then you basically are stuck with systemd. Nobody else is even thinking about how to move forward. If you try to raise the challenges you see outside systemd, you get laughed at and are told that your usecase is obviously stupid. The limitations admins ran into 1980 are gospel now and you may not question any of that.
First off, there are lots of problems with systemd (mostly down in the details) and controversial defaults at times, bugs, bloat, and hickups and whatnot. Like basically in all projects all the time. So of course there is valid critique on systemd, lots of it.
But I have a problem taking any argument seriously that is based on "I am smarter than everybody else". I do not like detail Y or developer Z, so the project X sucks and everybody that disagrees is either a paid shill, forced into it or just stupid. There is no point in even talking with people like that.
Yeap, it is always the same set of poorly researched links that get pasted in threads like this.
Unix philosophy, evil corporate interests, insecure, bloated, entangled mess... it is these individuals thatbhave seen the light, notnthe silent majority that does all the work in distributions and when developing software that kind of opted withbtheir feet.
Check out the devuan mailing lists then:-)
Portability matters.
In general: Yes. In the specific case of an init system for a specific OS: Not so much.
This is nicely demonstrated by none of the non-Linux OSes embracing any of the options you listed. They all want something that plays to the strength of their specific systems over some generic Unix thing.
If using Linux specific features was the only approach to security, I wonder how OpenBSD exists.
It is the best approach we have on anything running a Linux kernel.
systemd cannot compete with their simplicity, maintainability, smaller attack surface, and the list goes on and on and on.
It is also easy to have really simple code that does nothing interesting whatsoever. And for something that does not do much at all, the fork-dance that e.g. s6 does is pretty complex.
Maintainability also does not seem to be a big issue for systemd at this point in time either.
The smaller attack surface is relative as well: systemd-the-init is a bit bigger than the ones you list. But the difference is not as big as you make it sound and an init system does not do many interesting things that can get attacked by either.
On the other hand systemd can seriously lock down any service it starts (and does so out of the box for anything from the systemd project and many upstream projects that ship locked down systemd unit files). The init systems you listed do can not do that directly and either need helpers (which increases their attack surface again) or just do not bother. Considering that a init system starts way more lines of code that do more security critical things than an init system: I think this lockdown does lead to a smaller attack surface of the system overall.
systemd de-facto causing other projects to put in (sometimes radically) more work than they should have to, is not okay;
Somebody has to invest work to make things convenient and easy to use. You either run with what everybody else uses and share the effort or you do not and do the work all by yourself.
This is in no way systemd specific.
There is no significant section. It is just a few people telling each other the same old conspiracy stories over and over again.
None of these even want to include support for features found in the Linux kernel, so that they work can work on all Unix systems out there. Thatbis a design decision eachnofnthese made.
So none offers similar features to lock down services out of the box, as those rely on Linux specific kernel features. Of course you can hack that into the init scripts somehow. Sysv-init has shown how well that worked cross-distribution.
Systemd moved the goal posts for what a Linux init system needs to do. I doubt any generic Unix init system can compete.
Systemd-the-init does depend on some core services and thise need to be used together: Init, logging and IPC. Anything running systemd-init will have journald for logging and IIRC DBus for communication. That's because you need to control a system managing services, so you need to communicate with it and you need to document whatbthe managed services do, so you need logging. And you do want tested and stable code here (reusing something that was widely used in Linux before systemd started) and you do not want that code in the init process either. So systemd-the-init has very simple code tomlog and journald then has thencode needed to stream logs out to disk or to interact with other logging systems.
Everything else is optional and in separate binaries written in a layered architecuture: Each layer uses services provided by the lower layer and offers services to layers higher up in the stack. So lots of services depend on systemd-the-init to start other processes instead of reimplementing that over and over again (thus gaining unified config files for everything that gets started and all the bells and whistles systemd-the-init has already or will pick up later).
Or if you prefer a more negative spin: "Systemd is on huge entangled mess of interdependent binaries" :-)
The basics are all the same:. memory, cpus and caches in between ;-)
But rust does approach many things very differently from C or C++. Learning those new approaches takes time and practice.