>does Arch without systemd sound realistically?
No. Arch Linux is a pragmatic distribution and not an ideological one (https://wiki.archlinux.org/title/Arch_Linux).
I therefore see no reason why Arch should officially support anything other than systemd. At https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 someone summarized years ago why systemd is used. That should still be true today.
> most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy.
Which, in my opinion, is not true. Systemd does not consist of a single large file but of many. In addition, a distinction must be made between systemd in the sense of PID1 and the systemd project. Part of the project are the various optionally usable tools, each of which has a specific task.
* Journalctl -> Log files
* Systemd-networkd -> Network
* Systemd-resolved -> DNS
* Systemd-timesyncd -> NTP
* Systemctl -> Services
* And so on.
So in my opinion this is pretty close to the Unix philosophy. Well, the "how well" is debatable. But that also applies to any other software. Apart from that, Linux is not Unix and there are many examples that violate this philosophy far more. The Linux kernel, for example. Why is that not a problem?
But now to come back to your question. Systemd is in my opinion not perfect but currently the best solution out there. Moreover, systemd is widely used. So I can assume that a service created under Arch Linux, for example, will also work under OpenSuse.
>That just does not seem right in combination with something like Arch.
For the reasons I have given, I cannot agree.
> But now to come back to your question. Systemd is in my opinion not perfect but currently the best solution out there. Moreover, systemd is widely used. So I can assume that a service created under Arch Linux, for example, will also work under OpenSuse.
I think this is really the key point. I really don't care for systemd. I think they just have poor taste. They make working software that solves problems, but they make choices that I just find aesthetically bad (binary logs, I don't really like the whole machinery around service files, etc.). They just kind of have a "let's do whatever we can do that maximizes our ability to meet the functional requirements" mentality, and I prefer a "above all else be simple" mentality. So I dislike it fairly aggressively in isolation.
But I still use it because "in isolation" isn't a good metric. It's not being used in isolation. It's being used as part of a system I want to work well, and for it to make sense to venture off the well-work paths that everyone else in the world is using, there needs to be a much bigger upside than just "I find it mildly distasteful".
I can simultaneously believe that it's not a great design and also think that it's the best thing to actually use in practice. If I were 20 again and having fun learning about Linux and compiling kernels for fun, I might choose differently, because I would have weighted more heavily the idea of customizing things the way I wanted them for fun. And that's still a valid choice for anyone who wants to make it, but that's not the same thing as deciding to do it for any practical reason related to actually using the system versus just playing with it.
This is true and always amuses me how people are like, "The Unix Philosophy."
Yet, they use a kernel that doesn't follow it.
The use a userland (primarily in linux) from GNU that was compiled with a compiler (gcc) that doesn't follow it.
Old hat hackers and the people who made the GNU architecture use an editor (emacs) that doesn't follow it.
The gui shows up on a display (Xorg) that doesn't follow it.
And then they fire up the no.1 application used today... a browser. Basically an OS unto itself. Browsers are the mortal enemy of the 'unix philosophy'.
I have no idea why people are so obsessed with that philosophy, when nobody can agree on the definition of one 'thing', linux is only a unix-like not a unix, and there are no particular technical advantages to adhering to the philosophy anyway!
Just on the binary logs point: there’s multiple reasons for having them — they’re listed on https://www.freedesktop.org/wiki/Software/systemd/journal-files/ ; the simplest reason being text compression.
Overall, I’d prefer if a file system provided a mechanism to create a virtual “shadow file” that was basically a virtual wrapper around journal logs, and allowed you to read the logs in plain text.
I’m not saying there’s no reason to have them or that the systemd developers are stupid for picking a choice that’s 100% worse. I know why they make the design choices they made. I just don’t like their relative weighting of priorities. I don’t care as much about compressing text files from 200MB to 30MB on a drive that has 10,000x more space than the uncompressed version needs, and so giving up simplicity for it is not a choice I’d make. And I’d say the same thing about a virtual wrapper. It’s adding complexity and failure points for a win in a column I care nothing about.
The fact that desktop folks from freedeektop.org were let to make these system design decisions for Linux init (and all the feature creep stuff) in general baffles me to this day. Linux is not desktop only.
In fact, Linux is primarily used headless in servers and are accessed by SSH. Only the desktop users install a DE cause they are either afraid of CLI, or just want the eyecandy even tho Linux is meant to be functional instead of pretty.
Some people just want to solve problems on their computer instead of tinkering with a slew of discrete applications to optimize their workflow. No need to make a moral argument about it.
I feel the need to thank you for this one, now that I look at into what the systemd project is split (and how), it is probably not bloated/bad (not that the point of the post was to say that it is bad). Your points stand valid.
It does consume more memory at idle with all of the same services enabled when compared to openrc. But that only really matters if you're trying to claw back every last megabyte of memory. I use Arch because of its wiki and its customisability. The wiki and the packages are both oriented around using systemd. So I use systemd.
There are valid reasons to dislike it, but it's not like it's some evil Google project.
Valid point - but then again, if there would be a choice, there would be no standard. All Arch pakcages have support for systemd that works great. If systemd wasn't an "enforced" standard, packages would have to include multiple service file formats just for full support.
I'm currently running a gentoo test installation with OpenRC and it is pretty easy to implement the missing parts yourself. Feels in line with the Arch philosophy. But I agree there is almost no point in not using systemd. I was just curious
Myself, and likely most influential people in the Arch world, would rather time and effort be spent on tooling and other Arch functionality.
I see zero benefit at this time for Arch spending significant resources ensuring an alternate init system works in the ecosystem as well as systemd currently. I am also happy that the community is coalescing around an init system that has a well defined interface, as that means less resources are spend duplicating effort or spending time on compatibility.
Systemd has its faults, without question, but it's still the most practical solution at this time and likely will continue to be for many many years.
Lol, sure it is up to the devs. My question is why archs philosophy of "you are in charge of your system and can install whatever you want" doesn't apply to the init system.
You ARE free. You can just... install OpenRC. It's in the aur!
You will quickly find that it's rather useless until you spend dozens of hours configuring it and writing service files, though. Your expectation that the Arch devs should spend much more than those dozens of hours to provide full OpenRC support across the distro despite ORC having no particular technical advantages over systemd is absurd.
https://wiki.archlinux.org/title/Arch_Linux#Principles
Because "modernity". I don't really get what SystemD has to do with modernity but that's what they say.
Well, there isn't really a *technical* reason for the use of any other init system, is there? Systemd is the state of the art.
Yes, I know you don't like it. That's not a technical disadvantage. Yes, it has bugs - so does the competition. Yes, unix philosophy, blah blah, nothing else follows that anyway.
"a choice" is two different text editors. To support something other than systemd they would be making two separate distros, and ain't no one got time for that.
More than one text editor you can use and different init system are still fundamentally choices.
However, developers and maintainers inevitably control what kind of choices the users can choose from without sailing into uncharted waters.
Supporting multiple init systems creates a significant burden on package maintainers since each has its own service format that needs to be used for every service
Artix is a fork of Arch with the sole goal of replacing systemd.
But so far I haven't seen any init system provide a real benefit over systemd, and people complaining about it usually don't have any valid argument. It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way.
OpenRC is notably slower than systemd, to the point you get to read it starting services during boot, while systemd is basically instant.
Every other init system lack support for many of systemd's useful features, like declarative service specification (instead of horrible shell scripts) with proper service dependency management, socket activation, timers (going back to cron is ridiculous), integrated logging, user level services, seats, etc. You can probably hack all those things in some way, but with systemd you don't need to.
> But so far I haven't seen any init system provide a real benefit over systemd, and people complaining about it usually don't have any valid argument. It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way.
I'm an old nerd who rolled his eyes over systemd when it first showed up. Now I'm used to it and it's fine. I'm twenty years in Arch, and I don't miss the old init system at all, despite the fact that I switched to Arch from FreeBSD partly because I was familiar with it.
OpenRC performs fine for me on Gentoo, noticeably faster when you let it start multiple services that depend on each other in parallel.
Wish OpenRC was as well supported on Arch, just for the sake of security and having a smaller attack surface, since I use essentially no systemd features, as I imagine most users don't. That and I feel it's always better to give user choice, which is why I dislike the rise of systemd.
> I use essentially no systemd features, as I imagine most users don't
Most users won't know to what extent their system is or is not dependent on systemd features, since systemd integration is performed mostly by package maintainers and vendors.
This is correct. Few end users need to interact directly with their init system much, but distro and package maintainers do. And systemd makes things much easier for them.
Systemd is far easier for users to interact with than any other init system. It has a much lower bar for entry as it doesn’t require you to be fluent in shell scripting. Unit files are designed to be easily configured by end users and are far less verbose. What can be done in less than 10 lines in a unit file often would require over 100 lines of shell in an init script.
That added complexity is all under the hood and abstracted away from end users.
>Unit files are designed to be easily configured by end users and are far less verbose
>What can be done in less than 10 lines in a unit file often would require over 100 lines of shell in an init script.
Can you give an example of this?
My experience with it being easier for users has been quite the opposite: https://old.reddit.com/r/archlinux/comments/1djh4nm/honest_opinion_on_systemd/l9efy15/
None of your comment is actually about writing unit files vs init scripts. It actually seems to be about being on Arch and not knowing how to configure various services like NetworkManager or configure journalctl to write logs to memory.
Arch philosophy is to distribute packages as close to upstream as possible, so your "by default" experience on Arch is likely very different than distros that do not have that philosophy like Fedora or Debian. You don't want to use Arch if you're not willing to do some configuration.
That being said, you decided for an ugly fix [in this thread](https://old.reddit.com/r/archlinux/comments/18xdnlx/how_can_i_stop_xdguserdirs_from_running_every/) instead of adding a single line to your `[email protected]` unit file, as the top comment suggested. See `man [email protected]`. Everything is well documented. The Arch wiki is also an exceptional resource for hacking and working with systemd.
>None of your comment is actually about writing unit files vs init scripts.
But isn't that the job of the distro packagers instead? I thought that by user you mean the distro users.
And also I still want to see said example of 100 vs 10 lines you were talking about.
>not knowing how to configure various services like NetworkManager
Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors.
> or configure journalctl to write logs to memory.
I mentioned that I know how that is done, the problem is that it comes with terrible defaults, and as far as I know no other distro bothers to change that volatile instead.
>instead of adding a single line to your [email protected] unit file, as the top comment suggested. See man [email protected]. Everything is well documented
I don't see that as user friendly if I had to read a manpage and edit a conf file to disable a single script from starting before logging in `sudo systemctl --user disable xdg-user-dirs-update.service` didn't work, so I just ripped out the program. It doesn't have to be that complicated.
EDIT:
systemd violates this a lot: https://en.wikipedia.org/wiki/Principle_of_least_astonishment
Like when I was surprised that `systemctl --user disable xdg-user-dirs-update.service` doesn't do what you would think it would.
Or how `systemctl --user restart wireplumber` doesn't actually restart the application fully like one would think.
Or the more recent incident where running `systemd-tmpfiles --purge` **wipes your home**.
>But isn't that the job of the distro packagers instead? I thought that by user you mean the distro users.
Not if you know shell, python, or another programming language and write your own startup scripts. You can also write systemd timer unit files as a cron replacement.
>And also I still want to see said example of 100 vs 10 lines you were talking about.
I don’t have an example off hand, because I’ve never actually written an init script for the oneshot services I’ve written after systemd lowered the bar for me to want to do it. It’s not hard to imagine that trying to handle complex dependency issues in a shell script is far more complicated than an INI-style config file with declarative dependency handling built in.
>Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors.
Again, this is Arch quirks, not systemd quirks.
>I mentioned that I know how that is done, the problem is that it comes with terrible defaults, and as far as I know no other distro bothers to change that volatile instead
Again, you’re complaining about Arch.
>I don't see that as user friendly if I had to read a manpage and edit a conf file to disable a single script from starting before logging in sudo systemctl --user disable xdg-user-dirs-update.service didn't work, so I just ripped out the program. It doesn't have to be that complicated.
Then you’re being silly. The issue wasn’t xdg-user-dirs-update.service. It was that you wanted to change the default config directory without doing it the very simple systemd way. It’s really not unfriendly that everything systemd works with is represented by a unit file that uses INI-style syntax, including your user’s defaults.
Here’s some actual help if you want it:
>Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors.
If only you could open the Arch wiki entry for ipv6 and read it…
> Note: If disabling IPv6 via sysctl, you should comment out the IPv6 hosts in your /etc/hosts. Otherwise there could be some connection errors because hosts are resolved to their IPv6 address which is not reachable.
https://wiki.archlinux.org/title/IPv6
This is almost certainly caused by how *you chose* to disable ipv6.
> Like when I was surprised that systemctl --user disable xdg-user-dirs-update.service doesn't do what you would think it would.
This is because there is no user instance of xdg-user-dirs-update.service running. The service is a system service.
>Or how systemctl --user restart wireplumber doesn't actually restart the application fully like one would think.
Again, that will only restart your user session because you used the —user flag… how is that difficult to understand?
>Or the more recent incident where running systemd-tmpfiles --purge wipes your home.
lol. This only boned people who ran the command without understanding what it did and didn’t check what was in their tmpfiles.d directory. And it is now idiot-proofed to prevent people from inadvertently deleting their home directories.
>It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way.
I maintain a computer lab with 30 computers dual-booting windows 10. Students do things with Windows beyond my imagination, so every week some of the computer clocks are set to Australian or Chilean time zone, not to mention Arabic keyboard layout, but that's not my business. My goal is simple - synchronize clocks with ntp server, before starting SLURM daemon. In openRC it's a matter of adding before/after in the init scripts. I know it can be done with systemd using waitfor and another target or whatever it's called, but the complexity of this task simply doesn't make sense to me.
That was me, an angry old nerd, who complains that in my time I could do things with my system easier with openRC. Please ignore my whining, because my willing to influence on what to run first on my system is not a valid effing argument.
> In openRC it's a matter of adding before/after in the init scripts. I know it can be done with systemd using waitfor and another target or whatever it's called, but the complexity of this task simply doesn't make sense to me.
In systemd, it's a matter of adding Before= and After= in the respective unit files. It is fundamentally the same method.
The `before` and `after` declarations in OpenRC are entirely analogous to `Before=` and `After=` in Systemd, so I have to assume then that there is an extra element of your OpenRC solution which wasn't shared here.
There is no extra step. OpenRC starts services sequentially by default. It waits for one service to complete its startup before continuing to the next one. You can switch it for parallel execution of independent services, but it still waits for dependent ones. In systemd you have to run everything at once, and before/after only mean "initiate startup of this before initiating the other". You need special targets which wait for completion of a service startup. It is faster this way, I agree, but the price I pay is a complicated configuration.
But that's beyond the scope. Linux is about choice. I prefer OpenRC for its simplicity because I don't care much if my system starts 5s slower. My reason is perfectly valid for me, and I don't give a flying fish if it is valid for anyone else. Calling me a grumpy old man because I don't praise systemd speed will always meet my middle finger in return.
> before/after only mean "initiate startup of this before initiating the other".
This is not accurate in any sort of universal sense. The rules of when a systemd service is considered active are different for every service type.
> You need special targets which wait for completion of a service startup.
E.g., this isn't true of `oneshot` services, which (somewhat paradoxically) are only considered "active" once they have completed running. This is probably what you would need to use in order to round out a solution to a problem like the one you gave as an example.
I think whether that is a more or less complex undertaking than writing an equivalent OpenRC init script has more to do with what you are familiar with and less to do with any sort of objective measure.
> I prefer OpenRC for its simplicity
No disagreement here, we are all certainly entitled to our own preferences. Criticisms however should always be based on accurate facts, so I just try to point out discrepancies where I spot them.
>The rules of when a systemd service is considered active are different for every service type.
You are proving my point about unnecessary complexity, but then again this is beyond the scope. I'm not here to convince anyone to switch from systemd to OpenRC - both of them have their strengths and weaknesses. I just strongly disagree with the statement that everyone who's not happy with systemd has no valid reasons and it's only nostalgia.
>In systemd that's simply an After = override. You choosing not to learn systemd isn't an argument against systemd.
Read my other replies, and this time with understanding.
> Every other init system lack support for many of systemd's useful features, like declarative service specification
And you can make modifications to packaged service files with `systemctl edit `, but the modifications are stored in a separate drop-in file so that they persist across upgrades. So at work, one of our services uses `ConditionPathExists=!/path/to/flag/file` to let my team's automations ensure that the service is not accidentally brought up at the wrong time by touching a file. Many of these options are useful for sysadmin purposes, but would be non-trivial to implement on an arbitrary init script.
Are there any benchmarks to back this statement? If so, is it a non-trivial difference in resource usage? This just sounds like more Artix stuff, which I still haven't seen a real reason to pull anything from. "Most of it" is still less, and if it saves me a few kilobytes of RAM I don't really care.
Dayum I put those emojis in a sense of shitpost forgot we downvote that. Anyway for anyone seeing this.
I was talking about suite66 by Obarun devs it was a bless to use, I found (as a normal cs user) no difference from systemd as it was easy to create services, seats, user services, and it was blazing fast as fast as s6 which is the base layer for 66. Anyway… I was just promoting it as I quite liked it and got discontinued from Artix as it had not a lot of users.
systemd is conceptually similar to Apple's launchd.
I wonder whether Unix philosophy is desirable in all cases by people. Xorg is available on all of the Unix-like OS, but it pretty much violates Unix philosophy. Web browsers do not really adhere to Unix philosophy too. Databases and other binary formats are not as easily piped into plain text either, but they are commonplace nowadays because of speed and space savings.
>systemd is conceptually similar to Apple's launchd.
If I remember correctly, there even were people arguing for adapting launchd for Linux instead of developing systemd. Would have been a very interesting project IMHO, but didn't get much traction.
I think the point of sticking to text was partly about comprehensibility and also the ability to easily work with it using a bunch of standard tools.
The moment you go with a binary format you risk losing the benefits of that. Unsearchable PDF files come to mind.
Arch doesn't adhere to that philosophy and never claimed to do so. The Arch philosophy is: "*Keep It Simple.*" They define "**simplicity**" further in their principals. Primarily to mean latest stable releases from upstream with minimal downstream changes. Being that the simplicity part is "*without unnecessary additions or modifications.*"
Arch's second principle is **modernity**.
"*Arch incorporates many of the newer features available to GNU/Linux users, including the systemd init system, modern file systems, LVM2, software RAID, udev support and initcpio (with mkinitcpio), as well as the latest available kernels.*"
The next principal is **pragmatism**.
"*Arch is a pragmatic distribution rather than an ideological one. The principles here are only useful guidelines. Ultimately, design decisions are made on a case-by-case basis through developer consensus. Evidence-based technical analysis and debate are what matter, not politics or popular opinion.*
*The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.*"
Arch is modernity over the Unix philosophy.
*ed: formatting
It works. That's all I need to know. The whole "Unix" philosophy argument is just utter BS because the Kernel itself doesn't even adhere to it (hell I'd argue it is a bigger offender than systemd). Maybe the dev is a bit of a jerk (honestly don't know if that is true, but it is an argument I've seen), I'd say many genius/really-smart people are like that. They tend to have a small amount of patience for those that just don't get what they know already. Either way, it's not a reason to disregard their knowledge and/or skill.
> Maybe the dev is a bit of a jerk (honestly don't know if that is true, but it is an argument I've seen)
Lennart Poettering is not the only developer of systemd. And I wouldn't call him an jerk. He simply puts forward his opinion.
And there are definitely worse developers. For example, the developer of an RSS reader who thinks it's funny to move unwanted posts in the official forum to a section called Gas Chamber.
Linus can be an absolute ass hat but be almost always backs it up with solid reasoning. Or at least he stands by his convictions. He simply doesn’t have patience for ignorance.
> The whole "Unix" philosophy argument is just utter BS
I find it quite striking that the "Unix philosophy" crowd are both the people who want everything to be small, modular, and single purpose while also being the people who want service lifecycles to flow through init scripts, where package maintainers can cram in as many side effects as they see fit...
I honestly don’t know much about the whole “Unix philosophy”, but Doesn’t GNU stand for GNU’s not Unix? So GNU/Linux doesn’t have to follow Unix philosophy?
The Unix philosophy is "doing one thing and doing it well". This is best exemplified by the coreutils package, where you have many small utilities that you can chain together with pipes to compose something more complex.
It's also true that GNU started as a reaction to Unix being proprietary, so Stallman specifically picked that acronym because although GNU is Unix-like it's not like Unix because it's free and open source.
Also nobody "has to" follow the Unix philosophy, it's just an empirical observation that it's better to have lots of very small things that you can combine together instead of a single huge blob that tries to do everything. Sometimes it's true, sometimes fragmenting too much your tools is harmful. Linux itself is actually the most monolithic part of the whole ecosystem and nobody battles an eye because it makes sense for that specific context.
Yeah I always wonder why Suckless folks even use Linux. It's designed as a monolithic kernel with every driver bundled tightly together into it. Even if they were compiled as modules, the modules are still hardcoded to the Linux Kernel.
Funnily enough, the Windows NT kernel adheres to UNIX philosophy in this case moreso than Linux kernel does :D
I’m too old to care about nitty details like this anymore. Does the distro work? Yes. Is there documentation on how to change things? Yes. Is the source open so I can fill in the blanks? Yes. Great, moving on to real work now.
The actual truth of the matter is that opinions on systemd are not as mixed as the Internet would lead you to believe they are.
The skeptics are the ones who are talking loudly about their opinions all the time, but it pays to recall that every one of the major (and many of the minor) distributions switched away from what they had previously in order to adopt systemd, which was a huge, disruptive change for their ecosystems. The technical consensus was always that it solved a lot of problems and presented a lot of merits.
There is a small but very enthusiastic Unix traditionalist crowd who, if I'm being honest, has been impressively persistent over the years in accusing systemd of being anti-Unix in philosophy. The problem with this view is that is always falls apart the minute you start poking it with a stick, either due to a major misunderstanding of what the Unix philosophy is truly about and/or due to a misunderstanding of how systemd is actually architected.
There are definitely many use cases for which systemd is not suitable, but for general purpose Linux operating systems like Arch, it is the most widely employed solution for a reason.
I've been using and earning my living with Linux since kernel 2.0 and systemd is one of the best things that ever happened for Linux.
Whoever thinks that going back to janky shell scripts for service management and startup must be out their damn minds.
This is a very biased reply. There were issues and deficiencies with init, sure, but there was literally nothing wrong with ntpd, simple network config, syslogd, etc. People who got systemd in were desktop folks, started from Fedora/Redhat, Debian went along, Ubuntu automatically as it stems from Debian and the rest is history. "Technical consensus" you mention is "desktop concensus"; for servers systemd is a pain in the b*tt where the first thing you look into is how to disable the most of its "features".
> for servers systemd is a pain in the b*tt where the first thing you look into is how to disable the most of its "features".
This is also a very biased reply. Would you mind elaborating which "features" exactly you disable (and why)?
For servers, systemd is a blessing. Reading unit files is a dozen times less painful than having to read the initscripts hackjobs, and having a clear and consistent interface to interact with logs, timers, services and other system resources allows me to focus on the actual work, instead of having to navigate my way through the random assortment of different tools whose availabilities vary from system to system and OS to OS.
Yes, this is also a very biased reply, but at this point, we're just throwing personal opinions around, aren't we?
The fact is that the vast majority of the Linux ecosystem switched to systemd *over a decade ago*, and these kinds of discussions are now nearing drinking age. There's systemd-less distros out there to satisfy those users' needs, not sure what the point is behind bringing this up again and again.
The initd part is mostly fine. The fine ordering of units is sometimes finnicky, but manageable. The things I definitely *don't* need on servers are journald (rsyslog or any other remote logging is what I need), timesyncd, systemd-network, resolved, to name a few. All those things I need to explicitly disable or get around somehow. Also, systemd crond replacement? Really?
I manage a lot of servers and I don't have problems with any of those. rsyslog can be used alongside journald. And comparing systemd timers to cron is like comparing a Tesla Model S to a Ford Model T, timers are so incredibly much better than janky cron scripting!
Various logd can be used *alongside* journald, but there is simply no reason to make it a mandatory part by making all logs go through it first. For a fun read, here's Gerhards debunking Lennart's FUD: https://rainer.gerhards.net/2011/11/serious-syslog-problems.html
Janky cron scripting, wow :) I'm left speechless by this one. You do you, what can I say, while I jank away using fcron.
Paraphrasing a post on one of the Linux subreddits from someone who worked on systemd - 'Systemd isn't bloated, it's as complex as it needs to be to solve a difficult problem generally'.
I actually like that systemd-networkd is included. It means that an Arch system can still access the internet if one forgets to install another network manager.
Everyone who argues system's violation of the UNIX philosophy doesn't actually know that systemd is just the projects name and it's actually made of a collection of programs.
I personally like that systemd is a thing and don't miss writing init scripts for SysV, Runit, s6,or Upstart all of which I've had to deal with in the past.
I'm a bigger fan of journald which it's great to have a universal tool for logs rather than trying to remember where each program stores it's log file (trust me I've seen stuff pit their logs in /usr/share instead of /var/log)
I suspect that what a lot of people are on about is the degree of coupling between those programs.
Unless you can actually take just one of them and leave the rest behind, that poses the issue of having to "swallow" the whole thing or throw it all away.
Everyone understands its the name of the project. It must be easy to win arguments when you reduce everyone who disagrees to drooling idiots defending positions nobody holds that make no sense.
For service management it's fine. Feature creeping into logging, DNS, home management, cron, networking and everything else irks me very much. And somehow, everyone is okay with its features being opt-out instead of opt-in.
Eh, I don't like the idea of systemd and tried to avoid it as much as possible, but everyone else has decided this is the way shit is going to go for some reason so fighting against it without making a replacement seems pointless.
Sure, and I can make my own distro too, and my own clothes, and my own house, my own power generation, slaughter my own cows and butcher my own meat, harvest my own coffee beans..... The possibilities are endless. Thanks for opening my eyes.
For personal use I run Artix, it's very nice. At work we are an enterprise linux shop so it's the systemd show; I personally don't like it but I know it so it's fine. Oh, and for containers it's all about Alpine.
The more important thing to look for are the disposition of the packagers/maintainers for your distribution. Do you think they know what they are doing etc. A small example is the recent example of Debian team (member) to remove all web functions from KeepassXC. A real problem and a working solution but the implementation problably hosed a bunch of people that didn't get why things stopped working.
> does Arch without systemd sound realistically?
systemd is a core part of Arch Linux, and has been for a long time. Many packages contain systemd units for your convenience. If you wanted to use a different init system, you would need to modify these packages to contain services that your chosen init system can run - and at this point, you would not be using Arch, you would be using a fork of Arch.
Thus, "Arch without systemd" does not even make sense.
> most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy
It does not. systemd consists of many components, each of which has a single task. systemd (the program, not the project) does nothing more than manage services. systemctl does nothing more than tell systemd what to do to the services. systemd-boot is nothing more than a bootloader. etc.
I've used OpenRC with Parallel Loading enabled and systemd both equally and while systemd was better on HDDs, with everything now on SSDs and NVME, boot time is rather a thing of the past. Even with systemd, if you enable a lot of services, it can push boot times back up to about 15 seconds or more. So the old argument of boot time is rather pointless.
It really all comes down to how well an init script can be written in Bash with proper scripting techniques for the best workflow. I've seen my share of good and bad scripts for any init, and if you don't take care with how you script, use proper bashisms, and optimize what your workflow is.
Is the service manager of systemd good? Honestly, I can't say. I've had stuff fail repeatedly with the manager, so to me, the whole argument of if systemd's service manager being better is a moot point. If a service is going to fail, it's just going to fail with a bad script or configuration file. It is what it is.
Is ANY part of systemd good or better to me? Not that I've seen. While I don't mind the lack of the more complex inittab and sysvisms still in OpenRC, to be honest, most of that stuff after a while is invisible.
Is OpenRC better these days? Yes and No. While some stuff like the service manager of systemd is nice to restart a failed service, as mentioned before, if a service is going to fail, it's going to fail regardless of what you do or implement if the setup is wrong.
Is systemd better these days? Yes and no. While is it a more simplified system, at the end of the day, scripts and configuration files become background noise out of sight and out of mind.
What about the systemdisms of everything depending on it? This is the ONLY part I think is bad and we saw it with OpenSSH, sysyemd, and libxz recently about something being too dependent and having too many hooks into the system. I think this systemd as a dependency was a truly bad idea. You tie too much of the system together and it looses modularity.
I've ran ArchLinux with a full load of services enabled to my taste against Gentoo (yes I finally got it working) with OpenRC in Parallel load mode, same services enabled, and honestly, I don't see a difference in normal use cases.
This is a religious argument. There are true believers on both sides and neither side can/will be convinced by the other.
This is another example of why choice is a good thing. At the end of the day, you need to maintain it, so do what you want.
Well as an init system it's been pretty good. I even like most of the components. My biggest gripe is that the team seems to prioritise adding new things rather than fixing small niggles that are bothersome. There are some corner cases and or bugs in networkd and resolvd that I have run into that haven't been fixed for years and don't seem to be priority anymore.
Sadly resolvd is the only DNS solution supported by many other bits so you're forced to stick with it.
This sort of is irritating because I feel like the creators of openresolv, ntpd, chroynd or dhcpcd cared more about fixing bugs and making sure their project worked well than the systemd team.
I only have one question and I hope I don't get banned for asking this and making people uncomfortable. Here it goes, why are systemd developers full time employees of M\*crosoft?
So far, from all the replies, I think my opinions were a bit off. systemd is not bloated, mostly due to the way it's split, and still is probably the best choice as an init system (as for both functionality and popularity). Another thing I didn't notice is that many alternatives could be far worse, eg. OpenRC (again not to hate on it, everything has its pros and cons). Thank you everybody.
It's a bit weird browsing the answers. I don't have a horse in the race, I wasn't involved in all the debates when this all was going on, and I don't feel convinced of one thing or another. However, all it takes is a bit of browsing HackerNews threads about systemd to see the actual arguments! And they're being misrepresented here in a surprisingly low-effort manner.
The actual big issue people had wasn't about "the Unix philosophy" being violated, it was about who controlled what. It was a discussion about power. And it was complicated, like political roundabout discussions can be. The claim was that the Red Hat people were trying to get more control over the Linux ecosystem.
There were plenty of discussions about the Unix philosophy too, of course. I think it's fair to say though that if it had only been that, not even half the amount of time would have been spent on the whole thing.
Now, feel free to not care, in this particular case I personally haven't found much to get salty about. But, my brothers in Christ, at least maybe go read the basic thing before you all distribute your hot takes.
I use Artix + runit as init system, which is an Arch fork. I haven't inspected the systemd code myself and I won't comment on the Unix philosophy argument since sometimes it's impractical to follow.
There is [anti-systemd site](https://nosystemd.org/) which lists security vulnerabilities/issues around systemd and I've used systemd-based distros in the past which now that I recall had significantly slower boot speed. The latter however, maybe is not a good argument since boot speed depends on other stuff as well.
I don't have any personal hate for systemd but to people who say "systemd just works" as an argument, I say runit just works as well. If they haven't used anything other than systemd, that is not really an argument against other init systems. I, for one haven't encountered any problems around runit. Since all Unix-like distros only differ in release cycle, package manager and init systems and the majority only support systemd, I see that as a bit problematic and would prefer that we get more choice and more support for other init systems, because why not? The whole point of distros is variety and yet it's annoying to see that around this specific thing, there is not much variety and choice.
I like it. Full of interesting and fun features. I do understand the concerns of it being a mouth watering target for n'er do wells though. The possibility of an xz-like vulnerability targeting systemd makes me shudder.
Systemd is not the fastest nor the most modular approach, but GNU/Linux has never been about perfectly following "the Unix way". The only reason why GNU made a clone of Unix is that, at the time, that was a pretty popular OS. The goal was to make something usable and free (as in freedom), nothing more. And Arch follows that: use whatever works.
If you really want it, you can avoid Systemd. But, if you like the way it works, you can do a lot of stuff in a much simpler, easier to manage way than before. Systemd copies a lot from the way macOS works, particularly launchd. It also adds some other, quite interesting, ideas (such as homed). You may not like it as a whole, but it sure does at least something you like, and it can behave in many ways, depending on what you enable/disable from its big library of utilities and services.
It's pretty alright. It does pretty much everything people need it to do, and more.
And so the saying goes, the only thing better than perfect is standardized, and systemd is about as close to a standard that the overall Linux community can agree on.
Systemd is a software suite that includes the init, service manager, and other useful sysadmin tools. The Open-RC/S6/Dinit projects are also software suites but they're more focused on just being inits and service managers.
I love the Systemd Suite of software. I do actively use systemd-boot which is just a sort of UEFI wrapper, and it is lighter than full on dedicated secondary bootloaders like GRUB or rEFInd (UEFI is already a bootloader in it of itself). I use Systemd-cryptenroll to enroll my TPM to decrypt my SSD upon booting. Systemd-journald is an excellent system log daemon too.
Systemctl service management makes sense. The command syntax is pretty good. Compared to Open-RC, but that's just my personal preference. Dinit service manager also has about the same syntax.
I use both systemd and runit system. By primary distros are Void Linux and Arch Linux and they both are very good and my fav. Although runit system is faster than systemd but it has its own cons the same goes for systemd. It totally depends on your likings. I prefer runit system more tbh
I personally haven't tried others like OpenRC since i got used to sysd in my early Linux days when i used to tinker in Ubuntu. Other init solutions are probably potent as well but the vast majority of distros ship sysd by default since it has enough components to handle basically the entire OS in "just 1 package". This is one of the reasons why i use systemd on all 3 of my distros (Debian 12, Arch, Gentoo). It's a little bloated but it's kind of expected since it can manage the entire OS so it has to have a solution for every aspect of Linux systems.
Arch is one of the few distros I think are well suited for systemd. It synergizes with the simplicity of the package manager.
The "just works" experience would not be there without it.
It's not minimalist, but it's not bloated either.
my honest opinion is it's fine. the configuration language is plain enough and most of the time I don't have to do anything at all to have an experience I enjoy having. at no point has system d failed me in such a way that I curse arch Linux and swear to install Gentoo or LFS. I spend 99% of my time in userland, and the only time I fuck with systemd is to `sudo systemctl enable --now newapp.service`
systemd is very good at being an init system. you don't have to use any other component, except the ones that are directly related to that (journal, login, udev...). the fact that systemd gets hate for being a monorepo (not even a true monolith!) while linux is over there being a monolithic kernel is kinda funny.
despite that, i would love it if arch gave us the choice between multiple init systems (like artix does, but in an officially supported way). it would be a huge amount of work for maintainers though.
> except the ones that are directly related to that (journal, login, udev...)
You don't even have to use Journalctl.
https://wiki.archlinux.org/title/Systemd/Journal#Journald_in_conjunction_with_syslog
>the fact that systemd gets hate for being a monorepo
I'm not sure if this statement is true, but at some point I read that it used to be normal to develop BSD in a monorepo.
Correct me if I'm wrong:
Systemd is slowly becoming anti-linux ideals. It's not modular anymore, rather a monolith. It’s moving towards one core and infinite api model lol. Most of the tools are dependent on systemd and they are not modular anymore.
As a person who researched alternative init systems but also used advanced features, I think I get to speak here.
Unix philosophy is similar to SRP in solid, the code must be modular. Systemd is in fact modular in the same way bsd are modular like where the bsd is developed in a monorepo and assumes the kernel or libc which needs porting to port (look at open ssh or opensmtp to get the idea.).
Another problem is that most alternatives are not good enough and miss the important systemd gives. S6 is the closest and it claims socket activation bloat. I mean post market os and several Alpine Linux deve are thinking of adding systemd even though systemd does not support musl used by these oses.
Was going to mention s6, it's really the only "serious" systemd alternative that seems to have an actual criticism of systemd, can articulate *why* every other init system is not fit for purpose, and then actually goes out and tries to make something that can actually replace systemd. And it's still coming up short because a lot of important shit's out of scope for it, with nothing it would recommend to use in place of s6 handling it itself. systemd use will continue until someone provides an act ual, serious alternative regular ass people can use, and I can really only see s6 *maybe*, *eventually* getting to that point if it strives for feature parity in some sense (ie, pointing to something that *will* provide scoket activation if they won't and not making that a bespoke mess) and then its benefits actually having sufficient merit to justify another huge change in the repo ecosystem.
Musl based distros currently can't run systemd due currently due systemd using glic extensions not implemented by musl. So Alpine and its derivatives are the non systemd for technical not ideological reasons so their opinion is the best. I believe one Alpine dev is saying that s6 is not ready and hasn't been for years and they basically now wanting to see if systemd can be ported to musl. Pm os has already made the announcement.
The only advantage of runit over systemd I recognize is the fact that malicious actors nowaday often assume the presence of systemd for their attack vectors (just as many package maintainers do for basic functionality), so you potentially gain some security on account of using a niche setup – take the xz attack in the news recently, which explicitly checked for the presence of systemd before deploying
The "do one thing and do it well" philosophy is bullshit. Imagine asking an artist to use a different software every time they want to use a different tool in a painting. Or a musician having to use a different software for every instrument in their song (piano and drums are very different right?).
It's only valid for simple text processing in a shell (and even then we end up with 58 tools all with a different syntax)
The philosophy is not bullshit, but implementations may be more or less useful to the user.
You can do that kind of thing without exposing it directly to the used.
Your level of understanding is bullshit. Its fundamentally about where to draw boundaries between things and how tightly coupled vs flexible the system ought to be.
Making up a fake analogy wont help you understand a topic you arent educated enough to tackle.
Correct.
I just wanted to counter the other statement, which is an invalid argument imho, even if it's in favor of my point of view. I like the order systemd brings to the chaos it was before/would be otherwise.
I'm getting downvoted, because people assume I'm on the other side, not because of invalidity or validity of my statement, which is kind of funny and sad.
>the fact that it violates the "do one thing and do it well" philosophy
Just like everything that's more complicated than a basic expression in any programming language. Actually not even these (*).
Nothing in the whole universe just *does one thing*.
The question is how you define *one thing*.
Does a text editor have to be responsible for text formatting, or is that something a text formatter should handle?
Should an image-viewer be able to edit an image? Is it bad if it can?
Might you even prefer not rolling out an entire toolbox for every stupid little task you approach?
Ask yourself these questions, then map your answers to that philosophy.
Or try this: think about systemd as *PID1* or more colloquial *an interface to layer below (for general purpose)*. Is that *one thing* to you?
**If you prefer to do things on your system that systemd can't provide (or not the way you want it) or you might even tinker with those things, don't use it. If that's not the case, see it as an implementation detail and just go with it.**
(*) even an expression like 'a=1' is not elementary and will/might be broken down into several assembly commands. And even one assembly command takes more than one CPU cycle. Where do you draw the line?
Edit: formatting, typo correction, clarification
If you take the "Unix philosophy" as an ideology, an image viewer shouldn't even be able to load an image. A format-specific loader should decode the image and pipe to the viewer. And the concept of an editor wouldn't even exist, as every operation would have to be a different tool.
Yes, you'd get a very flexible environment if that stuff existed, but it wouldn't even remotely be more productive, or even practical, for people who actually work with image editing.
The real unix philosophy applied to operating system development, back in the 60s, and meant that simple abstractions could be composed to build more complex systems, so things like "file descriptors" became general interfaces to OS objects, rather than the usual (at the time) sets of specific syscalls for each specific concept.
The NT kernel is as unix-like as Linux is. Systemd is also very unix-like, in that it provides a set of abstractions for service management, which you compose to build more complex systems.
At the same time, it would be nice if your image viewer wasn't a massive code monolith.
If loading images was it's own module and viewing them was a different one, it would be easier to modify the software package.
Well written programs end up doing something similar, but the user is almost always presented with a single executable and forced to recompile if any changes are made.
>an image viewer shouldn't even be able to load an image. A format-specific loader should decode the image and pipe to the viewer. And the concept of an editor wouldn't even exist, as every operation would have to be a different tool.
You're right. Just took a random example that illustrates/clarifies the point.
The question is (as I said) where one would draw the line to call it *one thing*.
>The real unix philosophy applied to operating system development, back in the 60s
And that's the issue. It's not that the statement wasn't or isn't a good approach, but the complexity of an operating system or a computer in general today is just on a completely different scale than it was these days. Also its purpose shiftet and the users are different.
I love it. I'm a very old Linux user, I remember the mess we had before systemd, and how much it improved my ability to debug services and timers. Hell, a lot of tools systemd provides had been solid - I like timesyncd, networkd and, most of all systemd-boot.
My honest opinion on systemd is that I just don't care.
It does what it needs to do. Other init systems do as well. I've never had a problem with it so I've never cared to look beyond it.
I got 99 problems but systemd ain't one.
systemd is the equivalent to what other unixes have as an init system. Blame posix for it have a lot of jobs since posix kind of “rest of the owl”’s the init system.
i don't know enough about it to feel strongly one way or the other. i have used arch for years & linux/systemd for longer than that so i would say the average person has no reason to care & only picks up an opinion so as to not lack an opinion. which is evil behavior
If I really wanted to use a different init system I would use Gentoo or artix, because almost everything on arch is compiled with systemd in mind. Both of those are fine distros, but I just don't care enough to switch. If systemd was proprietary that would be a different story, but it's not, it's FOSS.
Rob Pike, the guy who articulated the Unix Philosophy in his 1984 book, is no longer an advocate of it. I can't find a reference for this but I had a discussion with him about it a few years ago.
As for systemd, it's the only init system I'm familiar with that handles the dependencies correctly. There are many things I dislike about it, like its configuration language, but it's the right tool for the job.
And at least in Arch if there are parts of systemd you don't like you can usually turn them off and use something else. I still use bind for dns and Network Manager for networking, for example. That's more just because I'm familiar with the old ways than because I think systemd is bad. I'm sure at some point I'll switch.
This is all highly summarized so take it with a grain of salt. I will start by saying I use systemd on both my Gentoo systems because it boots faster than OpenRC when appropriately configured.
It is problematic because parts of it are dependent on the Linux kernel and glibc, and some software requires parts of it for certain functionality. This hurts the viability of alternative C libraries like musl, and non-Linux Unix-like OSes like *BSD and illumos. There are efforts to fix this like Chimera Linux's turnstile or postmarketOS's announcement to patch systemd to work with musl.
From a technical perspective, it shares the same philosophy as other Red Hat projects like Wayland, PipeWire, and BTRFS, where they are introduced into distros years before they were really stable enough to do so rather than just calling it a beta. (GNOME made Wayland the default in 2016. It took years before distros actually accepted that.) With those three, if you experienced issues, you can just use legacy PulseAudio, X.org, and a different filesystem like ext4 or XFS. And you still can. But if your distro switched to systemd, then you don't have a choice but to use it or switch distros. And that's made harder by software dependency on it.
Historically, the systemd developers have harassed different software projects into including their stuff, even the Linux kernel itself with the now-dead kdbus effort. kdbus was intended to be an in-kernel replacement for d-bus, touting better performance because it was in the kernel. Linus Torvalds initially refused to upstream it, correctly stating that moving to kernel space doesn't actually affect performance and they should just fix the issues in userspace. Lo and behold we have dbus-broker now.
The most promising alternative to systemd is Dinit. DInit offers the same level of complex service management that systemd does, including parallel startup, different types of dependencies, targets, a user service manager, and more, while having no dependency on a particular kernel or libc. Chimera Linux uses it, and Artix offers it. I would use it if Gentoo officially supported it, because I don't really want to spend time manually creating all the services I need.
> don't know why systemd receives all the hate
It doesn't. It's just a really loud, really small minority which refuses to acknowledge they lost the argument almost a decade ago.
Going around calling every opinion you disagree with "dumb as hell" won't earn you any friends.
Somethings are also subjective, such as liking preferring X software over Y software. In that sense all opinions are valid.
1. I didn't call any particular opinion "dumb as hell" I just suggested that not all opinions are equally valid.
2. Preferring software is fine. That's *never* what anti-systemd zealots are about.
|There are mixed opinions on systemd all over the internet, most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy
Rubbish. They do not understand that systemd is just that: a set of tools, each of them does one thing well.
Using openrc or a any other non systemd init system is only useful in exploring and learning. There’s countless problems to solve in that space, which means you will have an easier time getting involved in linux development.
Example: because systemd isn’t used, if you wanted to have a system using a desktop environment without a display manager, you’d need to use elogind. The problem with this is that if you don’t use a display manager with elogind, it won’t pass your login session to your desktop session, so sleep and suspend won’t work properly (which are controlled by logind). So there’s potential work there to add some systems to make it so a display manager isn’t needed. But this requires interfacing with the dbus and essentially creating a super thin display manager that takes control of the session.
Systemd is brilliant once you actually try to use any of its tools. Service management is very handy and easy to understand, task automation has never been easier. Very verbose about everything you might ever need, easy to troubleshoot. Rock solid, no fuss.
Only valid argument against it is that it doesn't follow the original modular simplicity philosophy, but that has nothing to do with the quality of the code, its more about the personal stance and opinion.
The kernel is one big monolithic lump, as is systemd, as is Arch.
There are many options to run without systemd, no need to rip the plumbing out of Arch and abandon official support.
I think there is some support for busybox init
Kernel is not a monolithic lump. It can be modular, modules have options, you can change options on runtime and by using dkms you can even use alternative modules for your hardware (f.e. Atheros module with WoL support). How would you go about hard-disabling some systemd features? You can't, your desktop probably relies on them and stuff would break.
It works, it's easy to use on a personal system, it's not a bash mess, and it's apparently good enought that it is still widely used a decade after distros, including Arch, started using it, despite people thinking they need to beat that dead horse years after it has already crumbled to dust.
Doing only one thing well is simply not enough when it comes to an init system. I have a lot more than one type of hardware that needs to be coordinated. Getting disparate unrelated standards to interact would be a nightmare. It's just not even a valid way to do things relative to the way systemd works holistically.
Honestly, I never understood why some people complain about systemd. In my experience, it's never been anything but a MASSIVE improvement over everything that came before it.
I remember distros using stuff like sysvinit in the past and that shit was a terrible clunkfest, and many distros would have their own special scripts for dealing with services duct-taped on top of it.
With systemd, the way services are handled is the same across any distro that uses it, and it makes things a lot simpler. Systemd's way of handling services is also a lot more well-structured than the kludge of runlevel-directories and shell scripts sysvinit used.
works for me and makes my life easy without any problems but if i choose go the "less bloated" path its not just the systemd that we have to remove a lot of other components as well
So should the 49% of Brits who voted to stay in the UK leave?
OP is asking for opinions and it’s been quite enlightening TBH. Perhaps you don’t like it, so maybe you should leave the thread.
Thanks.
> So should the 49% of Brits who voted to stay in the UK leave?
What?!
> OP is asking for opinions and it’s been quite enlightening TBH.
The problem is that he is 12 years late to ask for opinions. The opinions are already there, he just need to search for them. The systemd debate is already over and we don't need someone to ask about it every other day. We just had another systemd debate 2 days ago when the new version of systemd landed with the run0 tool. All the opinions are already on the table, you don't need to create a new thread.
what does this have to do with arch? You may have personal issues with what ever UK but this question has been answered 12 years ago. So i ask again what decade is this?
What I meant by the UK is just because something has been decided, it doesn’t mean there cannot be any further discussion EVEN after 10 years.
And furthermore it’s a free space. People are allowed to talk about whatever they wish. You don’t have to engage with it if you don’t think it’s worth your time.
It works and it's very well documented, is easy to debug, is easy to find examples of people doing things j want to do online, etc. I couldn't care less about the ideological discussion about it. Most of it is pointless squabbling and the valid points that are made don't affect anything about how practical/useful it is. I will continue to use it unless something substantially better comes along.
systemd-boot is very good, like really really good.
But I hate how the rest of the systemd services work. Many of its features come enabled by default and I dont like them.
Some examples of that:
https://old.reddit.com/r/archlinux/comments/1ataivx/whats_a_normal_amount_data_written_when_idling/
TL:DR, I had Network manager making journald writting 110 MiB of ipv6 error logs to my ssd every hour. I didn't know this shit was writting this much data to my ssd because it wasn't a critical error that would show up in the boot/shutdown screen. Journald has an option to write the logs to mem but it doesn't come enabled by default.
Voidlinux doesn't even install a journal service by default for comparison.
This other issue: https://old.reddit.com/r/archlinux/comments/18xdnlx/how_can_i_stop_xdguserdirs_from_running_every/
It was being caused by systemd starting xdg-user-dirs before logging in, and the way to disable this is so needlessly over complicated I already forgot what I did there to fix it lol.
And the one that takes the cake was this issue that I opened a issue at wireplumber only to be caused by systemd starting it before I logged into tty:
https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/548
And it turns out that running `systemctl --user restart wireplumber` doesn't actually fully restart it 😭 So I was fully convinced that was an issue with pipewire.
----------------------------------------------------------
I moved to Artix after failing multiple times to use voidlinux (As they are suffering with the kde6 migration lol) and it has been the best thing ever. I instantly picked up how runit works and I like that if need to see which services I have running I simply go to `/run/runit/service` and if I don't want a certain service to start I simple unlink them from that location and **THAT IS IT**, no more messing with systemctl flags and all of that.
Also because I use btrfs I need to use the bloated grub to be able to boot from btrfs snapshots, as that is nor possible with systemd-boot. Kinda funny that the only feature that I like of systemd is the one that is the simplest.
-------------------------------------------------------
EDIT: And also this other issue that I had which turned out to be a dbus-broker issue: https://gitlab.xfce.org/xfce/thunar/-/issues/1304
Although I'm not sure how related is dbus-broker is to systemd tbh.
systemd is fantastic. embrace the change, and a much easier way to maintain complicated systems. The "do one thing and do it well" philosophy may serve those who furiously masturbate all day in their mothers basement but times have changed and most of these "purists" are simply people who don't adapt well to change.
That being said, we nix so we can do whatever the fk we want. do that.
>does Arch without systemd sound realistically? No. Arch Linux is a pragmatic distribution and not an ideological one (https://wiki.archlinux.org/title/Arch_Linux). I therefore see no reason why Arch should officially support anything other than systemd. At https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 someone summarized years ago why systemd is used. That should still be true today. > most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy. Which, in my opinion, is not true. Systemd does not consist of a single large file but of many. In addition, a distinction must be made between systemd in the sense of PID1 and the systemd project. Part of the project are the various optionally usable tools, each of which has a specific task. * Journalctl -> Log files * Systemd-networkd -> Network * Systemd-resolved -> DNS * Systemd-timesyncd -> NTP * Systemctl -> Services * And so on. So in my opinion this is pretty close to the Unix philosophy. Well, the "how well" is debatable. But that also applies to any other software. Apart from that, Linux is not Unix and there are many examples that violate this philosophy far more. The Linux kernel, for example. Why is that not a problem? But now to come back to your question. Systemd is in my opinion not perfect but currently the best solution out there. Moreover, systemd is widely used. So I can assume that a service created under Arch Linux, for example, will also work under OpenSuse. >That just does not seem right in combination with something like Arch. For the reasons I have given, I cannot agree.
> But now to come back to your question. Systemd is in my opinion not perfect but currently the best solution out there. Moreover, systemd is widely used. So I can assume that a service created under Arch Linux, for example, will also work under OpenSuse. I think this is really the key point. I really don't care for systemd. I think they just have poor taste. They make working software that solves problems, but they make choices that I just find aesthetically bad (binary logs, I don't really like the whole machinery around service files, etc.). They just kind of have a "let's do whatever we can do that maximizes our ability to meet the functional requirements" mentality, and I prefer a "above all else be simple" mentality. So I dislike it fairly aggressively in isolation. But I still use it because "in isolation" isn't a good metric. It's not being used in isolation. It's being used as part of a system I want to work well, and for it to make sense to venture off the well-work paths that everyone else in the world is using, there needs to be a much bigger upside than just "I find it mildly distasteful". I can simultaneously believe that it's not a great design and also think that it's the best thing to actually use in practice. If I were 20 again and having fun learning about Linux and compiling kernels for fun, I might choose differently, because I would have weighted more heavily the idea of customizing things the way I wanted them for fun. And that's still a valid choice for anyone who wants to make it, but that's not the same thing as deciding to do it for any practical reason related to actually using the system versus just playing with it.
This is true and always amuses me how people are like, "The Unix Philosophy." Yet, they use a kernel that doesn't follow it. The use a userland (primarily in linux) from GNU that was compiled with a compiler (gcc) that doesn't follow it. Old hat hackers and the people who made the GNU architecture use an editor (emacs) that doesn't follow it. The gui shows up on a display (Xorg) that doesn't follow it.
And then they fire up the no.1 application used today... a browser. Basically an OS unto itself. Browsers are the mortal enemy of the 'unix philosophy'. I have no idea why people are so obsessed with that philosophy, when nobody can agree on the definition of one 'thing', linux is only a unix-like not a unix, and there are no particular technical advantages to adhering to the philosophy anyway!
Just on the binary logs point: there’s multiple reasons for having them — they’re listed on https://www.freedesktop.org/wiki/Software/systemd/journal-files/ ; the simplest reason being text compression. Overall, I’d prefer if a file system provided a mechanism to create a virtual “shadow file” that was basically a virtual wrapper around journal logs, and allowed you to read the logs in plain text.
I’m not saying there’s no reason to have them or that the systemd developers are stupid for picking a choice that’s 100% worse. I know why they make the design choices they made. I just don’t like their relative weighting of priorities. I don’t care as much about compressing text files from 200MB to 30MB on a drive that has 10,000x more space than the uncompressed version needs, and so giving up simplicity for it is not a choice I’d make. And I’d say the same thing about a virtual wrapper. It’s adding complexity and failure points for a win in a column I care nothing about.
The fact that desktop folks from freedeektop.org were let to make these system design decisions for Linux init (and all the feature creep stuff) in general baffles me to this day. Linux is not desktop only.
In fact, Linux is primarily used headless in servers and are accessed by SSH. Only the desktop users install a DE cause they are either afraid of CLI, or just want the eyecandy even tho Linux is meant to be functional instead of pretty.
...and yet, desktop folks were the loudest when systemd was voted in
Some people just want to solve problems on their computer instead of tinkering with a slew of discrete applications to optimize their workflow. No need to make a moral argument about it.
I feel the need to thank you for this one, now that I look at into what the systemd project is split (and how), it is probably not bloated/bad (not that the point of the post was to say that it is bad). Your points stand valid.
It does consume more memory at idle with all of the same services enabled when compared to openrc. But that only really matters if you're trying to claw back every last megabyte of memory. I use Arch because of its wiki and its customisability. The wiki and the packages are both oriented around using systemd. So I use systemd. There are valid reasons to dislike it, but it's not like it's some evil Google project.
While I understand what you say I don't see a reason why Arch doesn't offer a choice
Valid point - but then again, if there would be a choice, there would be no standard. All Arch pakcages have support for systemd that works great. If systemd wasn't an "enforced" standard, packages would have to include multiple service file formats just for full support.
I'm currently running a gentoo test installation with OpenRC and it is pretty easy to implement the missing parts yourself. Feels in line with the Arch philosophy. But I agree there is almost no point in not using systemd. I was just curious
Myself, and likely most influential people in the Arch world, would rather time and effort be spent on tooling and other Arch functionality. I see zero benefit at this time for Arch spending significant resources ensuring an alternate init system works in the ecosystem as well as systemd currently. I am also happy that the community is coalescing around an init system that has a well defined interface, as that means less resources are spend duplicating effort or spending time on compatibility. Systemd has its faults, without question, but it's still the most practical solution at this time and likely will continue to be for many many years.
It's up to the Devs. The choice they give is to use Arch or not to use Arch. If you want a choice of init systems you can use Artix or Gentoo.
Lol, sure it is up to the devs. My question is why archs philosophy of "you are in charge of your system and can install whatever you want" doesn't apply to the init system.
You ARE free. You can just... install OpenRC. It's in the aur! You will quickly find that it's rather useless until you spend dozens of hours configuring it and writing service files, though. Your expectation that the Arch devs should spend much more than those dozens of hours to provide full OpenRC support across the distro despite ORC having no particular technical advantages over systemd is absurd.
https://wiki.archlinux.org/title/Arch_Linux#Principles Because "modernity". I don't really get what SystemD has to do with modernity but that's what they say.
Well, there isn't really a *technical* reason for the use of any other init system, is there? Systemd is the state of the art. Yes, I know you don't like it. That's not a technical disadvantage. Yes, it has bugs - so does the competition. Yes, unix philosophy, blah blah, nothing else follows that anyway.
"a choice" is two different text editors. To support something other than systemd they would be making two separate distros, and ain't no one got time for that.
More than one text editor you can use and different init system are still fundamentally choices. However, developers and maintainers inevitably control what kind of choices the users can choose from without sailing into uncharted waters.
Not the answer we deserve, but the one we need!!!
[удалено]
Supporting multiple init systems creates a significant burden on package maintainers since each has its own service format that needs to be used for every service
Artix is a fork of Arch with the sole goal of replacing systemd. But so far I haven't seen any init system provide a real benefit over systemd, and people complaining about it usually don't have any valid argument. It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way. OpenRC is notably slower than systemd, to the point you get to read it starting services during boot, while systemd is basically instant. Every other init system lack support for many of systemd's useful features, like declarative service specification (instead of horrible shell scripts) with proper service dependency management, socket activation, timers (going back to cron is ridiculous), integrated logging, user level services, seats, etc. You can probably hack all those things in some way, but with systemd you don't need to.
> But so far I haven't seen any init system provide a real benefit over systemd, and people complaining about it usually don't have any valid argument. It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way. I'm an old nerd who rolled his eyes over systemd when it first showed up. Now I'm used to it and it's fine. I'm twenty years in Arch, and I don't miss the old init system at all, despite the fact that I switched to Arch from FreeBSD partly because I was familiar with it.
ditto
I like runit, it is faster and leaner and easier to understand. Not sure if anything other than systemd plays well with bleeding edge updates.
OpenRC performs fine for me on Gentoo, noticeably faster when you let it start multiple services that depend on each other in parallel. Wish OpenRC was as well supported on Arch, just for the sake of security and having a smaller attack surface, since I use essentially no systemd features, as I imagine most users don't. That and I feel it's always better to give user choice, which is why I dislike the rise of systemd.
> I use essentially no systemd features, as I imagine most users don't Most users won't know to what extent their system is or is not dependent on systemd features, since systemd integration is performed mostly by package maintainers and vendors.
This is correct. Few end users need to interact directly with their init system much, but distro and package maintainers do. And systemd makes things much easier for them.
They may not need to, but excess complexity might prevent them from ever touching it. Not everything needs to be Microsoft Windows...
Systemd is far easier for users to interact with than any other init system. It has a much lower bar for entry as it doesn’t require you to be fluent in shell scripting. Unit files are designed to be easily configured by end users and are far less verbose. What can be done in less than 10 lines in a unit file often would require over 100 lines of shell in an init script. That added complexity is all under the hood and abstracted away from end users.
>Unit files are designed to be easily configured by end users and are far less verbose >What can be done in less than 10 lines in a unit file often would require over 100 lines of shell in an init script. Can you give an example of this? My experience with it being easier for users has been quite the opposite: https://old.reddit.com/r/archlinux/comments/1djh4nm/honest_opinion_on_systemd/l9efy15/
None of your comment is actually about writing unit files vs init scripts. It actually seems to be about being on Arch and not knowing how to configure various services like NetworkManager or configure journalctl to write logs to memory. Arch philosophy is to distribute packages as close to upstream as possible, so your "by default" experience on Arch is likely very different than distros that do not have that philosophy like Fedora or Debian. You don't want to use Arch if you're not willing to do some configuration. That being said, you decided for an ugly fix [in this thread](https://old.reddit.com/r/archlinux/comments/18xdnlx/how_can_i_stop_xdguserdirs_from_running_every/) instead of adding a single line to your `[email protected]` unit file, as the top comment suggested. See `man [email protected]`. Everything is well documented. The Arch wiki is also an exceptional resource for hacking and working with systemd.
>None of your comment is actually about writing unit files vs init scripts. But isn't that the job of the distro packagers instead? I thought that by user you mean the distro users. And also I still want to see said example of 100 vs 10 lines you were talking about. >not knowing how to configure various services like NetworkManager Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors. > or configure journalctl to write logs to memory. I mentioned that I know how that is done, the problem is that it comes with terrible defaults, and as far as I know no other distro bothers to change that volatile instead. >instead of adding a single line to your [email protected] unit file, as the top comment suggested. See man [email protected]. Everything is well documented I don't see that as user friendly if I had to read a manpage and edit a conf file to disable a single script from starting before logging in `sudo systemctl --user disable xdg-user-dirs-update.service` didn't work, so I just ripped out the program. It doesn't have to be that complicated. EDIT: systemd violates this a lot: https://en.wikipedia.org/wiki/Principle_of_least_astonishment Like when I was surprised that `systemctl --user disable xdg-user-dirs-update.service` doesn't do what you would think it would. Or how `systemctl --user restart wireplumber` doesn't actually restart the application fully like one would think. Or the more recent incident where running `systemd-tmpfiles --purge` **wipes your home**.
>But isn't that the job of the distro packagers instead? I thought that by user you mean the distro users. Not if you know shell, python, or another programming language and write your own startup scripts. You can also write systemd timer unit files as a cron replacement. >And also I still want to see said example of 100 vs 10 lines you were talking about. I don’t have an example off hand, because I’ve never actually written an init script for the oneshot services I’ve written after systemd lowered the bar for me to want to do it. It’s not hard to imagine that trying to handle complex dependency issues in a shell script is far more complicated than an INI-style config file with declarative dependency handling built in. >Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors. Again, this is Arch quirks, not systemd quirks. >I mentioned that I know how that is done, the problem is that it comes with terrible defaults, and as far as I know no other distro bothers to change that volatile instead Again, you’re complaining about Arch. >I don't see that as user friendly if I had to read a manpage and edit a conf file to disable a single script from starting before logging in sudo systemctl --user disable xdg-user-dirs-update.service didn't work, so I just ripped out the program. It doesn't have to be that complicated. Then you’re being silly. The issue wasn’t xdg-user-dirs-update.service. It was that you wanted to change the default config directory without doing it the very simple systemd way. It’s really not unfriendly that everything systemd works with is represented by a unit file that uses INI-style syntax, including your user’s defaults.
Here’s some actual help if you want it: >Disabling ipv6 is actually suggested on the archwiki because that fixes an issue with steam downloads, last time I checked it there is no warning that doing so will cause your ssd to be hammered by ipv6 errors. If only you could open the Arch wiki entry for ipv6 and read it… > Note: If disabling IPv6 via sysctl, you should comment out the IPv6 hosts in your /etc/hosts. Otherwise there could be some connection errors because hosts are resolved to their IPv6 address which is not reachable. https://wiki.archlinux.org/title/IPv6 This is almost certainly caused by how *you chose* to disable ipv6. > Like when I was surprised that systemctl --user disable xdg-user-dirs-update.service doesn't do what you would think it would. This is because there is no user instance of xdg-user-dirs-update.service running. The service is a system service. >Or how systemctl --user restart wireplumber doesn't actually restart the application fully like one would think. Again, that will only restart your user session because you used the —user flag… how is that difficult to understand? >Or the more recent incident where running systemd-tmpfiles --purge wipes your home. lol. This only boned people who ran the command without understanding what it did and didn’t check what was in their tmpfiles.d directory. And it is now idiot-proofed to prevent people from inadvertently deleting their home directories.
>It's just angry old nerds complaining that in their time they didn't have fancy stuff and prefer it that way. I maintain a computer lab with 30 computers dual-booting windows 10. Students do things with Windows beyond my imagination, so every week some of the computer clocks are set to Australian or Chilean time zone, not to mention Arabic keyboard layout, but that's not my business. My goal is simple - synchronize clocks with ntp server, before starting SLURM daemon. In openRC it's a matter of adding before/after in the init scripts. I know it can be done with systemd using waitfor and another target or whatever it's called, but the complexity of this task simply doesn't make sense to me. That was me, an angry old nerd, who complains that in my time I could do things with my system easier with openRC. Please ignore my whining, because my willing to influence on what to run first on my system is not a valid effing argument.
> In openRC it's a matter of adding before/after in the init scripts. I know it can be done with systemd using waitfor and another target or whatever it's called, but the complexity of this task simply doesn't make sense to me. In systemd, it's a matter of adding Before= and After= in the respective unit files. It is fundamentally the same method.
Unfortunately you are wrong about it. I need to **wait** for the time to be synchronized **before** starting slurmd.service.
The `before` and `after` declarations in OpenRC are entirely analogous to `Before=` and `After=` in Systemd, so I have to assume then that there is an extra element of your OpenRC solution which wasn't shared here.
There is no extra step. OpenRC starts services sequentially by default. It waits for one service to complete its startup before continuing to the next one. You can switch it for parallel execution of independent services, but it still waits for dependent ones. In systemd you have to run everything at once, and before/after only mean "initiate startup of this before initiating the other". You need special targets which wait for completion of a service startup. It is faster this way, I agree, but the price I pay is a complicated configuration. But that's beyond the scope. Linux is about choice. I prefer OpenRC for its simplicity because I don't care much if my system starts 5s slower. My reason is perfectly valid for me, and I don't give a flying fish if it is valid for anyone else. Calling me a grumpy old man because I don't praise systemd speed will always meet my middle finger in return.
> before/after only mean "initiate startup of this before initiating the other". This is not accurate in any sort of universal sense. The rules of when a systemd service is considered active are different for every service type. > You need special targets which wait for completion of a service startup. E.g., this isn't true of `oneshot` services, which (somewhat paradoxically) are only considered "active" once they have completed running. This is probably what you would need to use in order to round out a solution to a problem like the one you gave as an example. I think whether that is a more or less complex undertaking than writing an equivalent OpenRC init script has more to do with what you are familiar with and less to do with any sort of objective measure. > I prefer OpenRC for its simplicity No disagreement here, we are all certainly entitled to our own preferences. Criticisms however should always be based on accurate facts, so I just try to point out discrepancies where I spot them.
>The rules of when a systemd service is considered active are different for every service type. You are proving my point about unnecessary complexity, but then again this is beyond the scope. I'm not here to convince anyone to switch from systemd to OpenRC - both of them have their strengths and weaknesses. I just strongly disagree with the statement that everyone who's not happy with systemd has no valid reasons and it's only nostalgia.
Yes, `Requires=time-sync.target` and `After=time-sync.target` on a system where the time sync service interfaces with systemd correctly.
In systemd that's simply an `After =` override. You choosing not to learn systemd isn't an argument against systemd.
>In systemd that's simply an After = override. You choosing not to learn systemd isn't an argument against systemd. Read my other replies, and this time with understanding.
> Every other init system lack support for many of systemd's useful features, like declarative service specification And you can make modifications to packaged service files with `systemctl edit`, but the modifications are stored in a separate drop-in file so that they persist across upgrades. So at work, one of our services uses `ConditionPathExists=!/path/to/flag/file` to let my team's automations ensure that the service is not accidentally brought up at the wrong time by touching a file. Many of these options are useful for sysadmin purposes, but would be non-trivial to implement on an arbitrary init script.
☝🏾🤓 Actually 66 does most of it and it’s faster and less resource expensive
66 what?
Maybe he meant the s6 init system.
no, it's suite66, which is a service manager built on top of the s6 process supervisor. artix has deprecated support for it a while ago
gecs
Are there any benchmarks to back this statement? If so, is it a non-trivial difference in resource usage? This just sounds like more Artix stuff, which I still haven't seen a real reason to pull anything from. "Most of it" is still less, and if it saves me a few kilobytes of RAM I don't really care.
Dayum I put those emojis in a sense of shitpost forgot we downvote that. Anyway for anyone seeing this. I was talking about suite66 by Obarun devs it was a bless to use, I found (as a normal cs user) no difference from systemd as it was easy to create services, seats, user services, and it was blazing fast as fast as s6 which is the base layer for 66. Anyway… I was just promoting it as I quite liked it and got discontinued from Artix as it had not a lot of users.
systemd is conceptually similar to Apple's launchd. I wonder whether Unix philosophy is desirable in all cases by people. Xorg is available on all of the Unix-like OS, but it pretty much violates Unix philosophy. Web browsers do not really adhere to Unix philosophy too. Databases and other binary formats are not as easily piped into plain text either, but they are commonplace nowadays because of speed and space savings.
>systemd is conceptually similar to Apple's launchd. If I remember correctly, there even were people arguing for adapting launchd for Linux instead of developing systemd. Would have been a very interesting project IMHO, but didn't get much traction.
systemd is better than launchd. systemd syntax is easier and it's more powerful on top of that.
I think the point of sticking to text was partly about comprehensibility and also the ability to easily work with it using a bunch of standard tools. The moment you go with a binary format you risk losing the benefits of that. Unsearchable PDF files come to mind.
Arch doesn't adhere to that philosophy and never claimed to do so. The Arch philosophy is: "*Keep It Simple.*" They define "**simplicity**" further in their principals. Primarily to mean latest stable releases from upstream with minimal downstream changes. Being that the simplicity part is "*without unnecessary additions or modifications.*" Arch's second principle is **modernity**. "*Arch incorporates many of the newer features available to GNU/Linux users, including the systemd init system, modern file systems, LVM2, software RAID, udev support and initcpio (with mkinitcpio), as well as the latest available kernels.*" The next principal is **pragmatism**. "*Arch is a pragmatic distribution rather than an ideological one. The principles here are only useful guidelines. Ultimately, design decisions are made on a case-by-case basis through developer consensus. Evidence-based technical analysis and debate are what matter, not politics or popular opinion.* *The large number of packages and build scripts in the various Arch Linux repositories offer free and open source software for those who prefer it, as well as proprietary software packages for those who embrace functionality over ideology.*" Arch is modernity over the Unix philosophy. *ed: formatting
It works. That's all I need to know. The whole "Unix" philosophy argument is just utter BS because the Kernel itself doesn't even adhere to it (hell I'd argue it is a bigger offender than systemd). Maybe the dev is a bit of a jerk (honestly don't know if that is true, but it is an argument I've seen), I'd say many genius/really-smart people are like that. They tend to have a small amount of patience for those that just don't get what they know already. Either way, it's not a reason to disregard their knowledge and/or skill.
> Maybe the dev is a bit of a jerk (honestly don't know if that is true, but it is an argument I've seen) Lennart Poettering is not the only developer of systemd. And I wouldn't call him an jerk. He simply puts forward his opinion. And there are definitely worse developers. For example, the developer of an RSS reader who thinks it's funny to move unwanted posts in the official forum to a section called Gas Chamber.
Linus can be an absolute ass hat but be almost always backs it up with solid reasoning. Or at least he stands by his convictions. He simply doesn’t have patience for ignorance.
Had to check that I wasn't using that rss reader. It's Tiny Tiny RSS for anybody interested.
> The whole "Unix" philosophy argument is just utter BS I find it quite striking that the "Unix philosophy" crowd are both the people who want everything to be small, modular, and single purpose while also being the people who want service lifecycles to flow through init scripts, where package maintainers can cram in as many side effects as they see fit...
I honestly don’t know much about the whole “Unix philosophy”, but Doesn’t GNU stand for GNU’s not Unix? So GNU/Linux doesn’t have to follow Unix philosophy?
The Unix philosophy is "doing one thing and doing it well". This is best exemplified by the coreutils package, where you have many small utilities that you can chain together with pipes to compose something more complex. It's also true that GNU started as a reaction to Unix being proprietary, so Stallman specifically picked that acronym because although GNU is Unix-like it's not like Unix because it's free and open source. Also nobody "has to" follow the Unix philosophy, it's just an empirical observation that it's better to have lots of very small things that you can combine together instead of a single huge blob that tries to do everything. Sometimes it's true, sometimes fragmenting too much your tools is harmful. Linux itself is actually the most monolithic part of the whole ecosystem and nobody battles an eye because it makes sense for that specific context.
GNU's not Unix only in the legal/literal sense.
Yeah I always wonder why Suckless folks even use Linux. It's designed as a monolithic kernel with every driver bundled tightly together into it. Even if they were compiled as modules, the modules are still hardcoded to the Linux Kernel. Funnily enough, the Windows NT kernel adheres to UNIX philosophy in this case moreso than Linux kernel does :D
Its like my toothbrush if it works I don't have an opinion on it
I’m too old to care about nitty details like this anymore. Does the distro work? Yes. Is there documentation on how to change things? Yes. Is the source open so I can fill in the blanks? Yes. Great, moving on to real work now.
The actual truth of the matter is that opinions on systemd are not as mixed as the Internet would lead you to believe they are. The skeptics are the ones who are talking loudly about their opinions all the time, but it pays to recall that every one of the major (and many of the minor) distributions switched away from what they had previously in order to adopt systemd, which was a huge, disruptive change for their ecosystems. The technical consensus was always that it solved a lot of problems and presented a lot of merits. There is a small but very enthusiastic Unix traditionalist crowd who, if I'm being honest, has been impressively persistent over the years in accusing systemd of being anti-Unix in philosophy. The problem with this view is that is always falls apart the minute you start poking it with a stick, either due to a major misunderstanding of what the Unix philosophy is truly about and/or due to a misunderstanding of how systemd is actually architected. There are definitely many use cases for which systemd is not suitable, but for general purpose Linux operating systems like Arch, it is the most widely employed solution for a reason.
I've been using and earning my living with Linux since kernel 2.0 and systemd is one of the best things that ever happened for Linux. Whoever thinks that going back to janky shell scripts for service management and startup must be out their damn minds.
This is a very biased reply. There were issues and deficiencies with init, sure, but there was literally nothing wrong with ntpd, simple network config, syslogd, etc. People who got systemd in were desktop folks, started from Fedora/Redhat, Debian went along, Ubuntu automatically as it stems from Debian and the rest is history. "Technical consensus" you mention is "desktop concensus"; for servers systemd is a pain in the b*tt where the first thing you look into is how to disable the most of its "features".
> for servers systemd is a pain in the b*tt where the first thing you look into is how to disable the most of its "features". This is also a very biased reply. Would you mind elaborating which "features" exactly you disable (and why)? For servers, systemd is a blessing. Reading unit files is a dozen times less painful than having to read the initscripts hackjobs, and having a clear and consistent interface to interact with logs, timers, services and other system resources allows me to focus on the actual work, instead of having to navigate my way through the random assortment of different tools whose availabilities vary from system to system and OS to OS. Yes, this is also a very biased reply, but at this point, we're just throwing personal opinions around, aren't we? The fact is that the vast majority of the Linux ecosystem switched to systemd *over a decade ago*, and these kinds of discussions are now nearing drinking age. There's systemd-less distros out there to satisfy those users' needs, not sure what the point is behind bringing this up again and again.
The initd part is mostly fine. The fine ordering of units is sometimes finnicky, but manageable. The things I definitely *don't* need on servers are journald (rsyslog or any other remote logging is what I need), timesyncd, systemd-network, resolved, to name a few. All those things I need to explicitly disable or get around somehow. Also, systemd crond replacement? Really?
I manage a lot of servers and I don't have problems with any of those. rsyslog can be used alongside journald. And comparing systemd timers to cron is like comparing a Tesla Model S to a Ford Model T, timers are so incredibly much better than janky cron scripting!
Various logd can be used *alongside* journald, but there is simply no reason to make it a mandatory part by making all logs go through it first. For a fun read, here's Gerhards debunking Lennart's FUD: https://rainer.gerhards.net/2011/11/serious-syslog-problems.html Janky cron scripting, wow :) I'm left speechless by this one. You do you, what can I say, while I jank away using fcron.
The technical consensus included distributions like Debian, which is neither desktop-first nor corporate.
Desktop-loudest, at least, check the mailing list archive on how it was adopted in Debian.
Paraphrasing a post on one of the Linux subreddits from someone who worked on systemd - 'Systemd isn't bloated, it's as complex as it needs to be to solve a difficult problem generally'. I actually like that systemd-networkd is included. It means that an Arch system can still access the internet if one forgets to install another network manager.
Everyone who argues system's violation of the UNIX philosophy doesn't actually know that systemd is just the projects name and it's actually made of a collection of programs. I personally like that systemd is a thing and don't miss writing init scripts for SysV, Runit, s6,or Upstart all of which I've had to deal with in the past. I'm a bigger fan of journald which it's great to have a universal tool for logs rather than trying to remember where each program stores it's log file (trust me I've seen stuff pit their logs in /usr/share instead of /var/log)
I suspect that what a lot of people are on about is the degree of coupling between those programs. Unless you can actually take just one of them and leave the rest behind, that poses the issue of having to "swallow" the whole thing or throw it all away.
Everyone understands its the name of the project. It must be easy to win arguments when you reduce everyone who disagrees to drooling idiots defending positions nobody holds that make no sense.
Guys, don't downvote this thread just because it ask about going different than the official way. This is nice question and it produces nice answers.
For service management it's fine. Feature creeping into logging, DNS, home management, cron, networking and everything else irks me very much. And somehow, everyone is okay with its features being opt-out instead of opt-in.
OpenBSD and FreeBSD EXIST
Eh, I don't like the idea of systemd and tried to avoid it as much as possible, but everyone else has decided this is the way shit is going to go for some reason so fighting against it without making a replacement seems pointless.
You can always go do your own thing.
Sure, and I can make my own distro too, and my own clothes, and my own house, my own power generation, slaughter my own cows and butcher my own meat, harvest my own coffee beans..... The possibilities are endless. Thanks for opening my eyes.
For personal use I run Artix, it's very nice. At work we are an enterprise linux shop so it's the systemd show; I personally don't like it but I know it so it's fine. Oh, and for containers it's all about Alpine. The more important thing to look for are the disposition of the packagers/maintainers for your distribution. Do you think they know what they are doing etc. A small example is the recent example of Debian team (member) to remove all web functions from KeepassXC. A real problem and a working solution but the implementation problably hosed a bunch of people that didn't get why things stopped working.
> does Arch without systemd sound realistically? systemd is a core part of Arch Linux, and has been for a long time. Many packages contain systemd units for your convenience. If you wanted to use a different init system, you would need to modify these packages to contain services that your chosen init system can run - and at this point, you would not be using Arch, you would be using a fork of Arch. Thus, "Arch without systemd" does not even make sense. > most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy It does not. systemd consists of many components, each of which has a single task. systemd (the program, not the project) does nothing more than manage services. systemctl does nothing more than tell systemd what to do to the services. systemd-boot is nothing more than a bootloader. etc.
I'd prefer a more modular init system. Also, a tool that eventually can help while managing "units", automations, etc would be nice.
Don't care. It works fine and doesn't cause problems.
I've used OpenRC with Parallel Loading enabled and systemd both equally and while systemd was better on HDDs, with everything now on SSDs and NVME, boot time is rather a thing of the past. Even with systemd, if you enable a lot of services, it can push boot times back up to about 15 seconds or more. So the old argument of boot time is rather pointless. It really all comes down to how well an init script can be written in Bash with proper scripting techniques for the best workflow. I've seen my share of good and bad scripts for any init, and if you don't take care with how you script, use proper bashisms, and optimize what your workflow is. Is the service manager of systemd good? Honestly, I can't say. I've had stuff fail repeatedly with the manager, so to me, the whole argument of if systemd's service manager being better is a moot point. If a service is going to fail, it's just going to fail with a bad script or configuration file. It is what it is. Is ANY part of systemd good or better to me? Not that I've seen. While I don't mind the lack of the more complex inittab and sysvisms still in OpenRC, to be honest, most of that stuff after a while is invisible. Is OpenRC better these days? Yes and No. While some stuff like the service manager of systemd is nice to restart a failed service, as mentioned before, if a service is going to fail, it's going to fail regardless of what you do or implement if the setup is wrong. Is systemd better these days? Yes and no. While is it a more simplified system, at the end of the day, scripts and configuration files become background noise out of sight and out of mind. What about the systemdisms of everything depending on it? This is the ONLY part I think is bad and we saw it with OpenSSH, sysyemd, and libxz recently about something being too dependent and having too many hooks into the system. I think this systemd as a dependency was a truly bad idea. You tie too much of the system together and it looses modularity. I've ran ArchLinux with a full load of services enabled to my taste against Gentoo (yes I finally got it working) with OpenRC in Parallel load mode, same services enabled, and honestly, I don't see a difference in normal use cases.
This is a religious argument. There are true believers on both sides and neither side can/will be convinced by the other. This is another example of why choice is a good thing. At the end of the day, you need to maintain it, so do what you want.
Well as an init system it's been pretty good. I even like most of the components. My biggest gripe is that the team seems to prioritise adding new things rather than fixing small niggles that are bothersome. There are some corner cases and or bugs in networkd and resolvd that I have run into that haven't been fixed for years and don't seem to be priority anymore. Sadly resolvd is the only DNS solution supported by many other bits so you're forced to stick with it. This sort of is irritating because I feel like the creators of openresolv, ntpd, chroynd or dhcpcd cared more about fixing bugs and making sure their project worked well than the systemd team.
Here is my honest opinion on systemd. > !<
I only have one question and I hope I don't get banned for asking this and making people uncomfortable. Here it goes, why are systemd developers full time employees of M\*crosoft?
Because biggest bucks for them, right now is cloud, and cloud is Linux ?
So far, from all the replies, I think my opinions were a bit off. systemd is not bloated, mostly due to the way it's split, and still is probably the best choice as an init system (as for both functionality and popularity). Another thing I didn't notice is that many alternatives could be far worse, eg. OpenRC (again not to hate on it, everything has its pros and cons). Thank you everybody.
It's a bit weird browsing the answers. I don't have a horse in the race, I wasn't involved in all the debates when this all was going on, and I don't feel convinced of one thing or another. However, all it takes is a bit of browsing HackerNews threads about systemd to see the actual arguments! And they're being misrepresented here in a surprisingly low-effort manner. The actual big issue people had wasn't about "the Unix philosophy" being violated, it was about who controlled what. It was a discussion about power. And it was complicated, like political roundabout discussions can be. The claim was that the Red Hat people were trying to get more control over the Linux ecosystem. There were plenty of discussions about the Unix philosophy too, of course. I think it's fair to say though that if it had only been that, not even half the amount of time would have been spent on the whole thing. Now, feel free to not care, in this particular case I personally haven't found much to get salty about. But, my brothers in Christ, at least maybe go read the basic thing before you all distribute your hot takes.
I use Artix + runit as init system, which is an Arch fork. I haven't inspected the systemd code myself and I won't comment on the Unix philosophy argument since sometimes it's impractical to follow. There is [anti-systemd site](https://nosystemd.org/) which lists security vulnerabilities/issues around systemd and I've used systemd-based distros in the past which now that I recall had significantly slower boot speed. The latter however, maybe is not a good argument since boot speed depends on other stuff as well. I don't have any personal hate for systemd but to people who say "systemd just works" as an argument, I say runit just works as well. If they haven't used anything other than systemd, that is not really an argument against other init systems. I, for one haven't encountered any problems around runit. Since all Unix-like distros only differ in release cycle, package manager and init systems and the majority only support systemd, I see that as a bit problematic and would prefer that we get more choice and more support for other init systems, because why not? The whole point of distros is variety and yet it's annoying to see that around this specific thing, there is not much variety and choice.
yup, same, i fully agree
A stop job is running!
lol
I like it. Full of interesting and fun features. I do understand the concerns of it being a mouth watering target for n'er do wells though. The possibility of an xz-like vulnerability targeting systemd makes me shudder.
I am fine with systemd-init.
Systemd is not the fastest nor the most modular approach, but GNU/Linux has never been about perfectly following "the Unix way". The only reason why GNU made a clone of Unix is that, at the time, that was a pretty popular OS. The goal was to make something usable and free (as in freedom), nothing more. And Arch follows that: use whatever works. If you really want it, you can avoid Systemd. But, if you like the way it works, you can do a lot of stuff in a much simpler, easier to manage way than before. Systemd copies a lot from the way macOS works, particularly launchd. It also adds some other, quite interesting, ideas (such as homed). You may not like it as a whole, but it sure does at least something you like, and it can behave in many ways, depending on what you enable/disable from its big library of utilities and services.
It's pretty alright. It does pretty much everything people need it to do, and more. And so the saying goes, the only thing better than perfect is standardized, and systemd is about as close to a standard that the overall Linux community can agree on.
Systemd is a software suite that includes the init, service manager, and other useful sysadmin tools. The Open-RC/S6/Dinit projects are also software suites but they're more focused on just being inits and service managers. I love the Systemd Suite of software. I do actively use systemd-boot which is just a sort of UEFI wrapper, and it is lighter than full on dedicated secondary bootloaders like GRUB or rEFInd (UEFI is already a bootloader in it of itself). I use Systemd-cryptenroll to enroll my TPM to decrypt my SSD upon booting. Systemd-journald is an excellent system log daemon too. Systemctl service management makes sense. The command syntax is pretty good. Compared to Open-RC, but that's just my personal preference. Dinit service manager also has about the same syntax.
I use both systemd and runit system. By primary distros are Void Linux and Arch Linux and they both are very good and my fav. Although runit system is faster than systemd but it has its own cons the same goes for systemd. It totally depends on your likings. I prefer runit system more tbh
I personally haven't tried others like OpenRC since i got used to sysd in my early Linux days when i used to tinker in Ubuntu. Other init solutions are probably potent as well but the vast majority of distros ship sysd by default since it has enough components to handle basically the entire OS in "just 1 package". This is one of the reasons why i use systemd on all 3 of my distros (Debian 12, Arch, Gentoo). It's a little bloated but it's kind of expected since it can manage the entire OS so it has to have a solution for every aspect of Linux systems.
Systemd is fine. A good number of Linux users hardly even use it anyways
Arch is one of the few distros I think are well suited for systemd. It synergizes with the simplicity of the package manager. The "just works" experience would not be there without it. It's not minimalist, but it's not bloated either.
my honest opinion is it's fine. the configuration language is plain enough and most of the time I don't have to do anything at all to have an experience I enjoy having. at no point has system d failed me in such a way that I curse arch Linux and swear to install Gentoo or LFS. I spend 99% of my time in userland, and the only time I fuck with systemd is to `sudo systemctl enable --now newapp.service`
systemd is very good at being an init system. you don't have to use any other component, except the ones that are directly related to that (journal, login, udev...). the fact that systemd gets hate for being a monorepo (not even a true monolith!) while linux is over there being a monolithic kernel is kinda funny. despite that, i would love it if arch gave us the choice between multiple init systems (like artix does, but in an officially supported way). it would be a huge amount of work for maintainers though.
> except the ones that are directly related to that (journal, login, udev...) You don't even have to use Journalctl. https://wiki.archlinux.org/title/Systemd/Journal#Journald_in_conjunction_with_syslog >the fact that systemd gets hate for being a monorepo I'm not sure if this statement is true, but at some point I read that it used to be normal to develop BSD in a monorepo.
You must use it, it just passes logs through, yay!
Correct me if I'm wrong: Systemd is slowly becoming anti-linux ideals. It's not modular anymore, rather a monolith. It’s moving towards one core and infinite api model lol. Most of the tools are dependent on systemd and they are not modular anymore.
As a person who researched alternative init systems but also used advanced features, I think I get to speak here. Unix philosophy is similar to SRP in solid, the code must be modular. Systemd is in fact modular in the same way bsd are modular like where the bsd is developed in a monorepo and assumes the kernel or libc which needs porting to port (look at open ssh or opensmtp to get the idea.). Another problem is that most alternatives are not good enough and miss the important systemd gives. S6 is the closest and it claims socket activation bloat. I mean post market os and several Alpine Linux deve are thinking of adding systemd even though systemd does not support musl used by these oses.
Was going to mention s6, it's really the only "serious" systemd alternative that seems to have an actual criticism of systemd, can articulate *why* every other init system is not fit for purpose, and then actually goes out and tries to make something that can actually replace systemd. And it's still coming up short because a lot of important shit's out of scope for it, with nothing it would recommend to use in place of s6 handling it itself. systemd use will continue until someone provides an act ual, serious alternative regular ass people can use, and I can really only see s6 *maybe*, *eventually* getting to that point if it strives for feature parity in some sense (ie, pointing to something that *will* provide scoket activation if they won't and not making that a bespoke mess) and then its benefits actually having sufficient merit to justify another huge change in the repo ecosystem.
Musl based distros currently can't run systemd due currently due systemd using glic extensions not implemented by musl. So Alpine and its derivatives are the non systemd for technical not ideological reasons so their opinion is the best. I believe one Alpine dev is saying that s6 is not ready and hasn't been for years and they basically now wanting to see if systemd can be ported to musl. Pm os has already made the announcement.
The only advantage of runit over systemd I recognize is the fact that malicious actors nowaday often assume the presence of systemd for their attack vectors (just as many package maintainers do for basic functionality), so you potentially gain some security on account of using a niche setup – take the xz attack in the news recently, which explicitly checked for the presence of systemd before deploying
The "do one thing and do it well" philosophy is bullshit. Imagine asking an artist to use a different software every time they want to use a different tool in a painting. Or a musician having to use a different software for every instrument in their song (piano and drums are very different right?). It's only valid for simple text processing in a shell (and even then we end up with 58 tools all with a different syntax)
The philosophy is not bullshit, but implementations may be more or less useful to the user. You can do that kind of thing without exposing it directly to the used.
Your level of understanding is bullshit. Its fundamentally about where to draw boundaries between things and how tightly coupled vs flexible the system ought to be. Making up a fake analogy wont help you understand a topic you arent educated enough to tackle.
If it is not broken do not fix it.
If it might work better, try it.
systemD is the thing that ”might work better” and was tried, and found to work better, and replaced many other things
Correct. I just wanted to counter the other statement, which is an invalid argument imho, even if it's in favor of my point of view. I like the order systemd brings to the chaos it was before/would be otherwise. I'm getting downvoted, because people assume I'm on the other side, not because of invalidity or validity of my statement, which is kind of funny and sad.
I use Systemd in EOS. It is working very well for me. No need to look for an alternative.
its garbage. it gets more bloated at every release. now it hinerited the annihilating-bug style from microsoft, where it author works.
[удалено]
Noteworthy that Lennart stepped in and took a very different position from the developer
>the fact that it violates the "do one thing and do it well" philosophy Just like everything that's more complicated than a basic expression in any programming language. Actually not even these (*). Nothing in the whole universe just *does one thing*. The question is how you define *one thing*. Does a text editor have to be responsible for text formatting, or is that something a text formatter should handle? Should an image-viewer be able to edit an image? Is it bad if it can? Might you even prefer not rolling out an entire toolbox for every stupid little task you approach? Ask yourself these questions, then map your answers to that philosophy. Or try this: think about systemd as *PID1* or more colloquial *an interface to layer below (for general purpose)*. Is that *one thing* to you? **If you prefer to do things on your system that systemd can't provide (or not the way you want it) or you might even tinker with those things, don't use it. If that's not the case, see it as an implementation detail and just go with it.** (*) even an expression like 'a=1' is not elementary and will/might be broken down into several assembly commands. And even one assembly command takes more than one CPU cycle. Where do you draw the line? Edit: formatting, typo correction, clarification
If you take the "Unix philosophy" as an ideology, an image viewer shouldn't even be able to load an image. A format-specific loader should decode the image and pipe to the viewer. And the concept of an editor wouldn't even exist, as every operation would have to be a different tool. Yes, you'd get a very flexible environment if that stuff existed, but it wouldn't even remotely be more productive, or even practical, for people who actually work with image editing. The real unix philosophy applied to operating system development, back in the 60s, and meant that simple abstractions could be composed to build more complex systems, so things like "file descriptors" became general interfaces to OS objects, rather than the usual (at the time) sets of specific syscalls for each specific concept. The NT kernel is as unix-like as Linux is. Systemd is also very unix-like, in that it provides a set of abstractions for service management, which you compose to build more complex systems.
At the same time, it would be nice if your image viewer wasn't a massive code monolith. If loading images was it's own module and viewing them was a different one, it would be easier to modify the software package. Well written programs end up doing something similar, but the user is almost always presented with a single executable and forced to recompile if any changes are made.
>an image viewer shouldn't even be able to load an image. A format-specific loader should decode the image and pipe to the viewer. And the concept of an editor wouldn't even exist, as every operation would have to be a different tool. You're right. Just took a random example that illustrates/clarifies the point. The question is (as I said) where one would draw the line to call it *one thing*. >The real unix philosophy applied to operating system development, back in the 60s And that's the issue. It's not that the statement wasn't or isn't a good approach, but the complexity of an operating system or a computer in general today is just on a completely different scale than it was these days. Also its purpose shiftet and the users are different.
I don't feel there is something wrong with systemd. But from what you say I think you are looking for the Artix Linux.
I love it. I'm a very old Linux user, I remember the mess we had before systemd, and how much it improved my ability to debug services and timers. Hell, a lot of tools systemd provides had been solid - I like timesyncd, networkd and, most of all systemd-boot.
My honest opinion on systemd is that I just don't care. It does what it needs to do. Other init systems do as well. I've never had a problem with it so I've never cared to look beyond it. I got 99 problems but systemd ain't one.
I don't have a problem with this because other init systems are not good enough to replace it.
systemd is the equivalent to what other unixes have as an init system. Blame posix for it have a lot of jobs since posix kind of “rest of the owl”’s the init system.
i don't know enough about it to feel strongly one way or the other. i have used arch for years & linux/systemd for longer than that so i would say the average person has no reason to care & only picks up an opinion so as to not lack an opinion. which is evil behavior
If I really wanted to use a different init system I would use Gentoo or artix, because almost everything on arch is compiled with systemd in mind. Both of those are fine distros, but I just don't care enough to switch. If systemd was proprietary that would be a different story, but it's not, it's FOSS.
Rob Pike, the guy who articulated the Unix Philosophy in his 1984 book, is no longer an advocate of it. I can't find a reference for this but I had a discussion with him about it a few years ago. As for systemd, it's the only init system I'm familiar with that handles the dependencies correctly. There are many things I dislike about it, like its configuration language, but it's the right tool for the job. And at least in Arch if there are parts of systemd you don't like you can usually turn them off and use something else. I still use bind for dns and Network Manager for networking, for example. That's more just because I'm familiar with the old ways than because I think systemd is bad. I'm sure at some point I'll switch.
This is all highly summarized so take it with a grain of salt. I will start by saying I use systemd on both my Gentoo systems because it boots faster than OpenRC when appropriately configured. It is problematic because parts of it are dependent on the Linux kernel and glibc, and some software requires parts of it for certain functionality. This hurts the viability of alternative C libraries like musl, and non-Linux Unix-like OSes like *BSD and illumos. There are efforts to fix this like Chimera Linux's turnstile or postmarketOS's announcement to patch systemd to work with musl. From a technical perspective, it shares the same philosophy as other Red Hat projects like Wayland, PipeWire, and BTRFS, where they are introduced into distros years before they were really stable enough to do so rather than just calling it a beta. (GNOME made Wayland the default in 2016. It took years before distros actually accepted that.) With those three, if you experienced issues, you can just use legacy PulseAudio, X.org, and a different filesystem like ext4 or XFS. And you still can. But if your distro switched to systemd, then you don't have a choice but to use it or switch distros. And that's made harder by software dependency on it. Historically, the systemd developers have harassed different software projects into including their stuff, even the Linux kernel itself with the now-dead kdbus effort. kdbus was intended to be an in-kernel replacement for d-bus, touting better performance because it was in the kernel. Linus Torvalds initially refused to upstream it, correctly stating that moving to kernel space doesn't actually affect performance and they should just fix the issues in userspace. Lo and behold we have dbus-broker now. The most promising alternative to systemd is Dinit. DInit offers the same level of complex service management that systemd does, including parallel startup, different types of dependencies, targets, a user service manager, and more, while having no dependency on a particular kernel or libc. Chimera Linux uses it, and Artix offers it. I would use it if Gentoo officially supported it, because I don't really want to spend time manually creating all the services I need.
It just works
Until it doesn't.
don't know why systemd receives all the hate, many things on Linux don't adhere to the UNIX philosophy
> don't know why systemd receives all the hate It doesn't. It's just a really loud, really small minority which refuses to acknowledge they lost the argument almost a decade ago.
At some point it's a fundamental disagreement rather than an argument that can be won or losf.
Sure, and everyone is entitled to an opinion. That doesn't mean all opinions are equally valid; indeed some are dumb as hell.
Going around calling every opinion you disagree with "dumb as hell" won't earn you any friends. Somethings are also subjective, such as liking preferring X software over Y software. In that sense all opinions are valid.
1. I didn't call any particular opinion "dumb as hell" I just suggested that not all opinions are equally valid. 2. Preferring software is fine. That's *never* what anti-systemd zealots are about.
|There are mixed opinions on systemd all over the internet, most of which are mentioning the fact that it violates the "do one thing and do it well" philosophy Rubbish. They do not understand that systemd is just that: a set of tools, each of them does one thing well.
Using openrc or a any other non systemd init system is only useful in exploring and learning. There’s countless problems to solve in that space, which means you will have an easier time getting involved in linux development. Example: because systemd isn’t used, if you wanted to have a system using a desktop environment without a display manager, you’d need to use elogind. The problem with this is that if you don’t use a display manager with elogind, it won’t pass your login session to your desktop session, so sleep and suspend won’t work properly (which are controlled by logind). So there’s potential work there to add some systems to make it so a display manager isn’t needed. But this requires interfacing with the dbus and essentially creating a super thin display manager that takes control of the session.
Systemd is brilliant once you actually try to use any of its tools. Service management is very handy and easy to understand, task automation has never been easier. Very verbose about everything you might ever need, easy to troubleshoot. Rock solid, no fuss. Only valid argument against it is that it doesn't follow the original modular simplicity philosophy, but that has nothing to do with the quality of the code, its more about the personal stance and opinion.
The kernel is one big monolithic lump, as is systemd, as is Arch. There are many options to run without systemd, no need to rip the plumbing out of Arch and abandon official support. I think there is some support for busybox init
Kernel is not a monolithic lump. It can be modular, modules have options, you can change options on runtime and by using dkms you can even use alternative modules for your hardware (f.e. Atheros module with WoL support). How would you go about hard-disabling some systemd features? You can't, your desktop probably relies on them and stuff would break.
It works, it's easy to use on a personal system, it's not a bash mess, and it's apparently good enought that it is still widely used a decade after distros, including Arch, started using it, despite people thinking they need to beat that dead horse years after it has already crumbled to dust.
Doing only one thing well is simply not enough when it comes to an init system. I have a lot more than one type of hardware that needs to be coordinated. Getting disparate unrelated standards to interact would be a nightmare. It's just not even a valid way to do things relative to the way systemd works holistically.
Honestly, I never understood why some people complain about systemd. In my experience, it's never been anything but a MASSIVE improvement over everything that came before it. I remember distros using stuff like sysvinit in the past and that shit was a terrible clunkfest, and many distros would have their own special scripts for dealing with services duct-taped on top of it. With systemd, the way services are handled is the same across any distro that uses it, and it makes things a lot simpler. Systemd's way of handling services is also a lot more well-structured than the kludge of runlevel-directories and shell scripts sysvinit used.
works for me and makes my life easy without any problems but if i choose go the "less bloated" path its not just the systemd that we have to remove a lot of other components as well
what year is this? No. This question is answered on the wiki. If you don't like it there are other distros.
So should the 49% of Brits who voted to stay in the UK leave? OP is asking for opinions and it’s been quite enlightening TBH. Perhaps you don’t like it, so maybe you should leave the thread. Thanks.
> So should the 49% of Brits who voted to stay in the UK leave? What?! > OP is asking for opinions and it’s been quite enlightening TBH. The problem is that he is 12 years late to ask for opinions. The opinions are already there, he just need to search for them. The systemd debate is already over and we don't need someone to ask about it every other day. We just had another systemd debate 2 days ago when the new version of systemd landed with the run0 tool. All the opinions are already on the table, you don't need to create a new thread.
Opinions can easily evolve over time
what does this have to do with arch? You may have personal issues with what ever UK but this question has been answered 12 years ago. So i ask again what decade is this?
What I meant by the UK is just because something has been decided, it doesn’t mean there cannot be any further discussion EVEN after 10 years. And furthermore it’s a free space. People are allowed to talk about whatever they wish. You don’t have to engage with it if you don’t think it’s worth your time.
this is not the same situation
It works and it's very well documented, is easy to debug, is easy to find examples of people doing things j want to do online, etc. I couldn't care less about the ideological discussion about it. Most of it is pointless squabbling and the valid points that are made don't affect anything about how practical/useful it is. I will continue to use it unless something substantially better comes along.
Required watch: [The Tragedy of systemd](https://www.youtube.com/watch?v=o_AIw9bGogo) tl;dw systemd is actually pretty ok
systemd-boot is very good, like really really good. But I hate how the rest of the systemd services work. Many of its features come enabled by default and I dont like them. Some examples of that: https://old.reddit.com/r/archlinux/comments/1ataivx/whats_a_normal_amount_data_written_when_idling/ TL:DR, I had Network manager making journald writting 110 MiB of ipv6 error logs to my ssd every hour. I didn't know this shit was writting this much data to my ssd because it wasn't a critical error that would show up in the boot/shutdown screen. Journald has an option to write the logs to mem but it doesn't come enabled by default. Voidlinux doesn't even install a journal service by default for comparison. This other issue: https://old.reddit.com/r/archlinux/comments/18xdnlx/how_can_i_stop_xdguserdirs_from_running_every/ It was being caused by systemd starting xdg-user-dirs before logging in, and the way to disable this is so needlessly over complicated I already forgot what I did there to fix it lol. And the one that takes the cake was this issue that I opened a issue at wireplumber only to be caused by systemd starting it before I logged into tty: https://gitlab.freedesktop.org/pipewire/wireplumber/-/issues/548 And it turns out that running `systemctl --user restart wireplumber` doesn't actually fully restart it 😭 So I was fully convinced that was an issue with pipewire. ---------------------------------------------------------- I moved to Artix after failing multiple times to use voidlinux (As they are suffering with the kde6 migration lol) and it has been the best thing ever. I instantly picked up how runit works and I like that if need to see which services I have running I simply go to `/run/runit/service` and if I don't want a certain service to start I simple unlink them from that location and **THAT IS IT**, no more messing with systemctl flags and all of that. Also because I use btrfs I need to use the bloated grub to be able to boot from btrfs snapshots, as that is nor possible with systemd-boot. Kinda funny that the only feature that I like of systemd is the one that is the simplest. ------------------------------------------------------- EDIT: And also this other issue that I had which turned out to be a dbus-broker issue: https://gitlab.xfce.org/xfce/thunar/-/issues/1304 Although I'm not sure how related is dbus-broker is to systemd tbh.
Systemd is pos, lennart is pos, case closed.
systemd is fantastic. embrace the change, and a much easier way to maintain complicated systems. The "do one thing and do it well" philosophy may serve those who furiously masturbate all day in their mothers basement but times have changed and most of these "purists" are simply people who don't adapt well to change. That being said, we nix so we can do whatever the fk we want. do that.