For a replacement for cron...sure, that's nice too. The benefit of being able to manually activate a timer in order to test it is completely worth it.
For an NTP implementation? Eh. I'm not sure why that needs to be bundled in under the same umbrella as the service manager. It's also just an SNTP implementation, not full NTP, so it's notably feature-crippled relative to better options like chrony.
Network management? Meh. Again, that strikes me as something that should be loosely coupled to the service manager.
A UEFI implementation? gummiboot was assimilated and become systemd-boot. Was that necessary for technical reasons, or was it just moving a project under the systemd umbrella similar to how there's an umbrella of GNU projects?
Container management? Another place where systemd-nspawn doesn't strike me as notably better than the alternatives.
At a certain point "systemd" becomes a brand more than anything else, sort of like what IBM has been trying to do with Watson. Yes, it beat Ken Jennings at Jeopardy and that's great. That doesn't mean anything associated with the overall brand is automatically equally amazing.
Systemd-nspawn contains no new code; just calls existing systemd library code. It gives people a familiar image based interface for a small cost in terms of lines of code.
Bootloader i have a less strong argument for but at least it allows them to iterate in hopefully-standards-soon.
Also systemd-boot is not an UEFI implementation. I'm not sure where you read that. It's an extremely small UEFI executable that lists a list of boot entries. (Note that an UEFI executable is just a Windows .EXE file).
UEFI itself has more lines of code than the Linux kernel, replacing it would be insane (though very noble. See coreboot and Linuxboot projects).
One argument is that it allows them to iterate on standards like the following:
https://systemd.io/BOOT_LOADER_INTERFACE.html
Because it was originally advertized as an optional init replacement. The acrimonious debates were because a number of people did not believe that's all is going to be, given the history of its designers.
Of course, nowadays many people would flat-out deny that systemd was sold as an init replacement, and claim that what you see was the original intention all along.
For example many of the larger DEs use logind because it is good at what it does and consolekit at that time was not really active anymore. That meant that for example freebsd had to either make the DEs work with consolekit (and maintain it) or make a logind implementation work with their implementation.
This is one of the confusing things about the discussion. The systemd project very much follows the "unix way" in that there are lots of subprojects that do one thing well, but is developed in a cathedral style (just like the *BSDs are) and not easily reusable, which kinda loses the benefit.
More that ConsoleKit developers and logind/systemd overlapped. For GNOME, logind seemed better and used to be separate. A warning that it would not always stay decoupled was underestimated/ignored.
Once logind was tied to systemd all hell broke loose :-P
Having something like systemd is great; e.g. GNOME has various user services running. Nowadays systemd manages those user services. But as great as that is, it makes non-Linux more difficult. IMO systemd on Linux makes things very easy and it's better to standardize on it.
No need to use networkd for example, networkmanager works great along systemd.
Actually most my systems use only systemd and journalctl to my knowledge. I prefer my established tools for all other jobs.
Can you? The whole premise of systemd revolves around ability to use existing init files, written by upstream developers.
Upstream init files are going to use arbitrary parts of systemd functionality, which may include network and container management, timers and God knows what else.
So in effect you HAVE to use those parts of systemd — unless you are insisting on writing all your init files from scratch (at which point you may as well use any of systemd alternatives).
There are many premises for which systemd was designed, but this is not one of them, let alone "the whole premise".
1. Before systemd, upstream developers were never precluded from supplying their own init files, and many often did.
2. Even in systemd, downstream maintainers and users were never precluded from modifying, overriding, or even completely replacing upstream-supplied init files.
The difference is that with SysV upstream-provided init files were often bad because upstream developers had to use a bunch of hacks in shell scripts to (necessarily reinvent and) supply features that were essential but SysV couldn't provide. The distro maintainers and users were thus sometimes _forced_ to try and fix upstream-supplied init files, but even they could do only so much because ... shell scripts on SysV.
Systemd allows everyone (upstream and downstream) to write better, cleaner, more maintainable init files.
> which may include network and container management, timers and God knows what else.
1. Timers are a core requirement of service management, and they're correctly a part of the service manager that is systemd.
2. network management (systemd-networkd, systemd-resolved, and .link, .network units) and container management (/var/lib/machines, machinectl etc) are _not_ service management features and are _not_ implemented in pid-1 systemd. I have also not seen any upstream package that used them. In fact, these features _cannot_ be used from service unit files.
> ... unless you are insisting on writing all your init files ...
It's not an all-or-nothing affair. It never was, not with systemd not with SysV.
> ... at which point you may as well use any of systemd alternatives
Only if you mistakenly believe that the "whole premise" of systemd was to disallow downstream of touching any unit files at all, which is false.
Not to mention, systemd is much better than the alternatives in terms of allowing the sysadmin to override parts of the config for a service without needing to merge in updates from upstream later on. I can just add an override for e.g. PrivateTmp=yes and if there's some update to the original unit file later on, it'll apply that update but it won't mess with my override that I set up.
With SysV I'm stuck with updates being a pain that I'd need to manually merge every time there's some change if I didn't want it to just nuke my changes.
And unless you are working with e.g containerized services (which you create yourself), why would a service need anything from networkd? I have never encountered a unit file like that on my system, and I don't run anything apart from systemd and journalctl. No networkd (I prefer NetworkManager), no systemd containers, no systemd ntp. I wonder if I even have those installed, why should I?
And all my services run just fine.
It leaks into user land.
The alternative for systemd would've been to shutdown the system without waiting for a clean unmount, which can lose data, which is what used to happen with SysV. The alternative for you would be to unmount your filesystem yourself before shutdown, which is what people used to do with SysV. Some SysV distros even had scripts that tried to automatically clean up mounts before shutdown, which is exactly what systemd does now, and your 90-second hangs would've shown up there too.
> It leaks into user land.
Init has always been in user land.
I think systemd actually won when they absorbed udev.
It's a nice design rule for CLI utilities, it doesn't work for systems.
Similarly, curl supporting both HTTP and HTTPS is not a violation of "do one thing and do it well" - if you fail to support at least those two protocols, you've built a shitty tool.
It's best to consider "do one thing" in the context of "what does the user want the software to do". A web browser having lots of functionality baked in is not necessarily a violation of this principle if all of that functionality is used to solve one user problem (I want to view YouTube, or I want to use GMail). At that point, the factoring issue lies somewhere else - the definition of the web platform, etc.
Systemd attempts to solve very many user problems all at once, with varying levels of success, and other software packages have solved one or two of them at once instead. In that case there is a clear way to separate the ones that probably apply the "unix philosophy" and the ones that obviously do not.
The Linux kernel and related components themselves sort of violate this, but that's mostly a matter of necessity - super-modular microkernel designs have not worked out great in practice. However, it still is built around relatively narrowly-scoped drivers for individual devices or services, instead of massive Megadrivers that handle every component in your system. Your PC may have an Intel GPU integrated on the CPU die, but it's still using a separate video driver, and the video driver is probably separate from things like the compositor and the actual PnP layer beneath that detects what hardware you have.
If you look at the average USB device in Windows' device manager (this is probably true in Linux as well but I don't know how to dump the data), you can see a given device like a mouse or a phone is actually split up into a bunch of sub-capabilities exposed by the device, and those can each have their own driver. Same thought process there.
Realistically, one tends to take or leave an upstream package since picking and choosing pieces of it is far more work than a typical package maintainer takes on. Also, upstream design decision changes can make doing so problematic down the road.
Not necessarily. RHEL does not ship gummiboot, timesyncd or networkd for example; it uses grub, chrony, NetworkManager. On my raspberry pis running Debian I have systemd as pid 1, one runs ConnMan (it connects to wireless) and the other runs networkd (it connects to Ethernet).
Everybody does that. Are you using networkd? Every distro makes different choices and user can then further configure what they want to use.
You can already configure systemd as you like, there is no need to 'take it apart'.
On Debian, systemd similarily basically only takes care of service and timer management (and cron is still available on all systems). I guess it does NTP too, I don't really spend much time thinking about my NTP client.
Yes, systemd is a brand. But just like you don't have to eat every burger at McDonald's, you can choose what works for you.
I agree systemd tries to do a lot (maybe too much) and often isn't better than alternatives, but I don't think that's a big deal since you can still use the alternatives quite easily.
I was an Arch Linux user before, during, and after the systemd transition. I welcomed it initially, because pre-systemd Arch had a lot of "here's how to decide which logging daemon / cron daemon / etc to use" which I always thought was unnecessary. As I said, I think it's a great service manager.
But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"; SNTP doesn't handle falsetickers well; and under dynamic Docker workloads systemd-timesyncd would decide "network configuration changed, better synchronize the clock" every time a Docker container started or restarted.
If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager? Each of those has no reason to have any sort of coupling to my service manager.
My biggest quibble with stories like this one is that they keep focusing on the decision of systemd as service manager / init system rather than the umbrella of other jobs that the service manager has no good reason to try to take over.
You absolutely can have it both way. Systemd is great because it offers a set of tools which are consistent, provide a lot of the functionality you want on a workstation in a cohesive way. It doesn't prevent you from choosing not to use one of the components developed under the project umbrella and uses something different instead. Systemd is modular enough for you to do that.
> But I've also had to deal with production servers using systemd-timesyncd and pool.ntp.org that would occasionally have system clocks that were off by ~10 minutes. SNTP was deemed "good enough"
Why are you using timesyncd if you need more than SNTP ? Timesyncd is not shipped by default with the systemd init system. It is not even installed by default on RHEL. Nothing prevents you from using a different NTP client with the systemd init system.
> If I use systemd as a service manager, why does that also imply I'm making "default" choices for boot loader, (S)NTP service, network manager, and container manager?
It does not imply that at all. You absolutely do not have to use the boot loader, timesyncd, networkd and nspawn with systemd. They are not even installed by default on some distributions. They are not coupled to the service manager.
You can use rsyslog in addition to journald, but there's no way to get journald out of the picture - it's intertwined with the service manager.
I had an automation recipe that would start a bunch of cloud instances, configure them and start certain job via a systemd service unit, and collect logs from this job 24 hours later. Initially, we were pulling these logs via journald as logs for that service unit. But then we noticed that random lines (1-5 lines out of maybe 40 for a single job) would be missing in about half the instances.
We ended up pulling those logs from files in /var/log instead, made courtesy of rsyslog. Not a single missed line.
Again journald is unreliable and as a whole should be nuked from the orbit.
It's not that the logs are missing, it's that they're not getting included by your query.
The way journald associates log lines with process metadata is inherently racy.
This situation has improved some with the metadata caching changes, but IIRC there are still some holes where processes can log without journald associating accurate/up-to-date metadata with the logged info.
The lines would go missing mostly if the logs were collected two or three days later instead of immediately after the job finished (it was a job running for 24 hours), which leads me to think it had to do with journald expiring entries to save on disk space. A consistent log manager would expire them chronologically, but here the lines were missing from the middle or the end of the output, so not the oldest ones logged.
The most common one (and one I share) is how slow it can be. `systemctl status foo.service` takes a significant amount of time on any of my machines thanks to the journal, and that's just the reader side.
It used to be quite crashy with lots of CPU overhead, but that has improved over time, the metadata caching helped a bunch with the overhead.
There was also a pretty embarrassing CVE not long ago:
Many people when they encounter problems with journald want to continue using systemd for their service management, but revert to the old world of low-overhead metadata-free unstructured syslog O_APPEND text files for everything logged.
If systemd (the project) were truly a collection of modular components you could pick and choose, you wouldn't need journald and you'd be able to run syslog like it's the 90s.
It's not an impossibility, the systemd developers just seem to have zero interest in implementing stuff that enables escaping their overall architecture. I imagine all that's needed is some minimal IPC glue to forward all the stdout/stderr output from services to syslog when journald isn't in use. Systemd's role is to wire that stuff up to journald currently, and it's unnecessarily opinionated about journald being the only supported target in that role.
Journald and udevd are exactly the only piece of systemd that systemd's pid 1 requires, and udevd can be used independent of systemd's pid 1.
I just think of journald as a piece of the init system that is split to a separate process, and provides log data to other programs.
Secondly, I don't, I expect the recent logs portion of `systemctl status $unit` to be suppressed when journald isn't present.
Note that journal-caused slowness of that very command is a common complaint aimed at journald contributing to people wanting to remove it!
E.g. `service_directory/service/logs`
Seems like a trivial way to solve it...
Bingo, so what's the problem? Except for the timer/cron functionality, everything else you listed is separate software that just comes from the systemd brand.
Apart from networking. That’s an f*ing mess without systemd.
I have a wireguard tunnel setup by networkd with custom rules to only send traffic from a slice through it. It works fine. Take a look at the netdev documentation [1].
What are you trying to do exactly ?
[1] https://www.freedesktop.org/software/systemd/man/systemd.net...
You don't know how the network will be parsed or which statements that works with your version. Very difficult to debug when it doesn't behave as it should.
After a lot of fiddling with source routing on e.g. Debian Strech I was able to something working. But only half of the times I restarted networkd.
I would like some better tooling to assist with more difficult setups.
But, yes, turning on debug mode is harder than it should be, and it's usually not the right level. (I usually just go for strace first, but with netdev I guess it's using netlink to talk to the kernel, so that'll not help much :/ )
I use strace etc (and debug level in networkd), but then you realise that this should make it easier not tougher. I did learn about ifup -v though which gave me all I needed. But both tools silently ignores flags that is wrong.
I'm writing my own tool now that is more strict in that sense instead.
Sorry about the rant but it's at least three trips to get everything working flawless in systemd-networkd now..
Of course it's free and open source, so we can at least try to make it better besides complaining, but that part is harder than it should be (otherwise the whole problem would have been "solved" by now).
Systemd-networkd is fine layout wise, it's just the tooling that could be improved upon. Also here you see the problem with systemd-networkd being shipped together with systemd deb, if it were to be standalone it would be so easy to backport just that.
Coreos even made a complete systemctl dbus integration.
With anything dynamic though - laptops, VMs - the various solutions can be pretty hit and miss. NetworkManager was terrible for many years, but seems relatively ok these days.
Could it have been done any differently? Perhaps. Would it require more moving parts? Definitely.
So you're advocating making systemd even bigger and dependent on more stuff?
systemd now is something like all except kernel, DE and applications. It's not clear.
The only part of systemd other than core init that you have to run is the journal and even then you can configure the journal to just forward to rsyslog and not store any logs even just in tmpfs.
Stuff like systemd-nspawn wasn't even developed to be a container management solution. IIRC the main goal was just to leverage the existing namespacing features in core systemd to allow booting up a minimalistic container in order to make developing systemd easier.
That's one thing where it's way better.
If you want to count like this you might as well speak of vulnerabilities in GNU.
From the second link you posted:
> None of that completely ended the systemd squawking, but it was clear to most that the real problem lies in the UEFI implementation.
So I am not sure what you hoped to prove here.
It's much more than an init system; it obviates a number of other components. This may be a desired quality for some. "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
The fact that systemd did not have the highest reliability for years did not help its popularity. It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Funnily Unix and C are also examples of "worse is better".
(Mildly NSFW)
Modularity implies formalization and restrictions about how components communicate and depend.
One of the goals: the ability to replace the implementation of one component without having to modify/adapt the others (the top-level component (also called 'main' or 'composition root') used to instantiate all the others doesn't count).
If your components can be compiled separately (e.g without having to recompile the whole app), then you know you're modular (however, modularity doesn't necessarily involve dynamic linking).
Real world examples of modularity:
- device drivers of the Linux kernel
- SDL device backends
- decoders/demuxers in VLC
- Cubase VST effects
- Filters in DirectShow and Gstreamer
Real world non-examples:
- LLVM backends: in practice front-end implementations need to know about the various backends, so you can't simply add one.
- GCC frontends: almost modular, however, there's some bunch of places you still need to modify so they know about your new frontend.
- GCC plugins: although no line of code in GCC know about your plugin, your plugin can depend upon almost anything from the GCC implementation itself, in other words, the plugin API is too big (=the density of interconnections is too high).
- Descent 1&2 (the game) enemies: the list of enemies appears at several places in the codebase, so you can't simply add one (=the density of interconnections is too high).
I'm not sure why you picked such a specific example, but it looks like read_robot_info() will happily read in additional robots from descent2.ham if you increase MAX_ROBOT_TYPES and stick them in the same global. There might be specific behavior info sprinkled elsewhere in the game, but that is probably code you'd need to touch to implement the uniqueness of new enemies anyway.
This is an entirely unrelated question to modularity - the "problem" is that systemd supports certain features and if you want to run without systemd, some other component needs to support them. Such components could be designed pretty easily, sure, but people who are using those features are typically happy with systemd's implementation so there's little motivation to write them.
In the article, systemd's tmpfilesd mechanism is given as an example. It's straightforward to reimplement as a standalone component, but someone has to actually be interested in writing the implementation and writing tests that it behaves like systemd does and keeping it up to date.
What we have here is a dependency chain that pulls in all of systemd, therefor it isn't modular.
It isn't modular just because it's divided into modules.
You wouldn't say that a company lacks a microservice architecture simply because they don't have unused reimplementations of each microservice lying around, would you?
Come on, that's literally what it means. Just because your modules aren't compatible doesn't mean it isn't modular.
It's monolythic in the same what that the GNU project or FreeBSD is monolithic.
It's a large number of utilities, tools, and daemons that is designed to provide the low-level features application developers and users demand from a modern operating system.
> It's much more than an init system;
Systemd is a init system, but systemd is also a major project that has taken on the task of unifying low-level Linux OS features.
> "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
All these systems have their own init systems they designed with no regard towards Linux and replaced older systems and obsoleted them.
> It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
Lies and misrepresentations.
> OTOH the history shows that technically poor, and even terrible, things can get wide enough adoption and stick with us for a long time; X is a good example, SysV init is another.
Which is why people are working on replacing both X and SysV.
You want to know the real problem with anything-but-systemd crowd?
This:
> Of course, this approach is not viable if it turns out that too few people are interested in init system diversity sufficiently to do the reasonably substantial implementation work required to maintain a competing implementation of the systemd unit features we care about.
There is no 'If' there. Some people don't want systemd, but the only people doing the work are Systemd. So their choice is to stick with Linux from 2000's or use systemd. Because nobody wants to commit to making any alternative actually work.
Making noise online is annoying, but it ultimately is not something that goes into the decision making of people designing operating systems. People willing to do the work are the ones that get to make the choices.
If somebody comes along and makes a better init system then systemd then they can do it and if it is better it will get adopted.
You can pretend that this is all Redhat's fault, but they are the only real enterprise that made the transition from sysv in Rhel 5, to upstart in 6, and then to systemd in 7.
And, ironically with systemd, migrating to another different init system is massively simplified compared to the work it took to migrate from sysv init. So now moving to a new init system is easier then ever.
Why do I say this?
Because systemd has unified OS design for Linux in a way that never happened with sysv init. Sure people were using 'sysv' and all used shell scripts, but they were all fundamentally different from one another. Only the most complicated shell scripts imaginable (think Apache init) or the most trivial could be made to work on more then one Linux distribution. Meanwhile systemd uses a declarative configuration syntax that all you need to do is create a parser and you could effectively import any systemd application configuration into a system with equivalent or better capabilities in any operating system.
The same can't be said for any of the bash scripts developed by any of the distributions prior to this for their own sysv variant.
> It's monolythic [sic] in the same what that the GNU project or FreeBSD is monolithic.
The FreeBSD system initialization artifacts are not monolithic.
> > "Linux monoculture" is a real thing, and systemd makes it seriously more monocultural.
> FreeBSD is a monoculture. OS X is a monoculture. Solaris is a monoculture. OpenBSD is a monoculture.
This is straw man incarnate.
> > It was not entirely gently pushed on everyone by Red Hat, by making Gnome dependent on it.
> Lies and misrepresentations.
Not according to here[0].
If you want to be a "systemd warrior", fine, feel free to be so. But don't lump FreeBSD and other Unix systems into your crusade.
BTW, when you wrote:
> Because systemd has unified OS design for Linux ...
Know that an init system, any init system, does not design nor define an Operating System.
And while your disdain for shell scripts is readily apparent, what you proffer as the benefit of "... systemd uses a declarative configuration syntax that all you need to do is create a parser ..." ignores the fact that POSIX shell scripts provide this feature by definition. Including, but not limited to, being able to source other files which define requisite variables.
And nobody claimed that... . The claim was that FreeBSD is monolithic in the same way that the systemd project (logind, nspawn etc. ) is monolithic.
> Not according to here[0].
Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
> Know that an init system, any init system, does not design nor define an Operating System.
Are you purposely confusing systemd-init and systemd the project? Because your argument is the same as "GNU does not design or define an OS", which many people would call plain wrong.
> Okay, let's click on that. First sentence "It doesn't". What were you trying to argue again?
And the second sentence says:
What it requires is a service that
implements the same set of APIs as
systemd-logind.
So what are you trying to argue again?
> > Know that an init system, any init system, does not design nor define an Operating System.
> Are you purposely confusing systemd-init and systemd the project?
No, what I stated I thought was quite clear: an init system does not design nor define an Operating System.
This is orthogonal to the question you present.
IMHO, that's not the best way to say what I think you really meant.
There are alternatives for just about every single systemd function (e.g. there are other init system that are not sysvinit). It is true though, that the people implementing these alternatives are far more levelheaded regarding systemd than the haters - at least in my experience.
I dare say there's bit of an irony in that assertion. 4 different operating systems, each of one of which uses a different init system. Pardon me, but that looks like the exact opposite of a monoculture.
Also, the rc system in FreeBSD could probably be ported with not too much effort into other operating systems, as it uses pure sh (not even bash). Surely, that cannot be considered monoculture. I would dare say that porting systemd into FreeBSD (or any of the other OSes you mentioned) should be more difficult.
As for init system, I would argue nosh[1] is a better init system. It’s based on daemontools design (same as s6, runit, etc, where it’s just a process that monitors a service directory). nosh can even semi-automatically convert systemd unit files[2] to a run script (including socket activation and all).
For everything else that is not part of the system initialization process (initialize/running/shutdown) I don’t think they need to be tie into PID 1. elogind aims to do this job of taking the logind part out of systemd into its own service, which I found to be a good way of living in systemd world without using systemd (e.g. GNOME works) but it requires a lot of commitment of patching everything to link against elogind instead of systemd (Void Linux/Artix Linux are doing a good job at this).
What I understand from this topic(about the ilogind) is that you can't even create such an alternative because the packages are depending hard on systemd. So you will be forced in future to re-create systemd features and bugs similar how wine does it for Windows API.
My issues with systemd do not pertain to functionality and consistency: rather, they are issues of taste, style, competence, design and size.
The basic ideas behind systemd are, frankly, great. The free desktop really really needs something like it. 100% behind the idea and the functionality.
The consistency is pretty good too, I think. It would be taste if it were less consistently in bad taste and more consistently in good taste.
Which brings us to taste. First, systemd is security-important system software written in C. Why? There is no good reason to write software in C in 2019. Use a safer language like Go or Common Lisp (both of which are performant enough). I don't know if Java or other JVM languages would work. Perl probably would, although ensuring that a Perl project produces sane code is … difficult.
Also on the issue of taste: systemd incorporates Windows-style .INI files wholesale into Unix-like systems. The freedesktop.org folks were already doing this, but why encourage it? The world has at least two better text-based alternatives to .INI files: S-expressions and YAML. Even JSON would be better, even without comments.
Also on the issue of taste: systemd just doesn't feel like Unix. In order to get anything done one has to hand-edit lots of little files rather than run a few commands. It's a bit like if you had to run a text editor on a directory to add a file, rather than just creating the file. I'd love to see some commands like mktimer, mkservice or somesuch.
I am mostly over the binary logfile issue — after all, ultimately everything on a computer is stored in binary — but I do wish that the tools were a little saner. It's still a pain to figure out where error outputs and so forth are going.
The manner in which systemd takes over the world is completely inexcusable. I fully expect to see systemd-browser within the next decade, no doubt with just a few hooks to prevent using Firefox or Chromium, and of course with a few security issues just to spice things up.
I really wish that someone with good taste had managed to get the attention of and money from Red Hat in order to design a clean, intelligent, 21st-century init system.
The basic idea of an init system is pretty simple: start services in such a way that the system comes up reliably. There are two main approaches here, simple but inefficient or complex and more efficient. The FreeBSD/rsysv approach is the former, while the systemd/launchd approach is the latter. If I just want to make sure services start on boot in the right order, why not just have a script run it all? For 99% of use cases, it's good enough, so why complicate matters?
I do appreciate systemd and the faster boots I get from it, but I still find myself longing for similar init systems.
——
Basically every type of systemd configuration files are just INI files, which I seem to remember originating in MS-DOS...
I'm using runit on void for years now. It has no functionality besides being a service manager. Having more functionality is a non feature.
> because it can both save you massive time
It also can cost you massive time whenever it doesn't work. Then you have to dig yourself through an opaque mess caused by literally millions of lines of C code. I wouldn't trust it with any mission critical. The only usecase for systemd I can think of is grandmas laptop. Maybe that is the target audience for debian, who knows. It is certainly not me.
Earlier it was just one (config) file and one start/stop script.
For WiFi, you still need WPA supplicant or similar, but you'll have those two things playing together.
This misses the point about init diversity. Let me show you one that has _less_ fuctionality, and is thus more suited to LXC os containers.
Also, in the article:
> Others, including Triplett, said that not only do the developers of other init systems lack the desire to implement systemd features, but they argue that those features should not exist in the first place.
Something with all the functionality of systemd is just another systemd, which some people don't want in any shape or form.
The whole point is that systemd replaces a large number of solutions to various system components and there’s alot to be said for pulling all that together into a consistent solution.
The competition to systemd can’t match its power, but there are good solutions for more limited scope situations like embedded.
Systemd is incredibly powerful and is very much a welcome part of software that I build. My system architectures depend heavily on systemd.
knowing what systemd is capable of is really required knowledge for software developers because it can both save you massive time and also enable the creation of systems that otherwise would have required you to write more code.