[HN Gopher] Without Systemd
___________________________________________________________________
Without Systemd
Author : pmoriarty
Score : 54 points
Date : 2022-05-27 19:37 UTC (3 hours ago)
(HTM) web link (without-systemd.org)
(TXT) w3m dump (without-systemd.org)
| midislack wrote:
| Here's my experience with removing systemd from Debian - DO NOT
| ATTEMPT. There's a reason the Devuan people have made significant
| changes to the system and packages.
|
| If you don't want systemd it's important to choose a distribution
| that doesn't increasingly expect it. Don't try to rip it out,
| that just causes pain to the host (you). You need to treat it by
| avoiding it.
| bbarnett wrote:
| I've been running systemd free debian for years. It may be that
| you hit an edge case, and I bet that was with a display manager
| most likely?
|
| I run sawfish, and trinity, no problems with either...
| midislack wrote:
| There has been a difficulty with hibernate to disk with it
| missing among other issues.
| zajio1am wrote:
| I use Debian without systemd on both my desktop and some
| routers/servers and have no issues.
| capableweb wrote:
| Realistically, is there any better alternatives for a modern
| personal computer? I'm currently running systemd as I don't know
| better, and haven't hit any issues, but always keep an open mind
| for all the pieces in my setup, if there is some better
| alternative that would give me something better.
|
| But looking at the list of alternatives for the `init`
| (https://without-systemd.org/wiki/index_php/Init/), it seems like
| everything stopped updating after 2018, and if that's the case,
| I'll just go with systemd as it is still receiving updates.
|
| Edit: looking at the footer of the wiki, it says "This page was
| last modified on 17 March 2018" so I guess the jokes on me, the
| wiki is not being updated very frequently and that's why the
| release dates are not up to date.
| gjs278 wrote:
| akira2501 wrote:
| As long as it keeps working, I'm happy with 'runit'. I'm not
| sure what needs to be updated. It runs my boot scripts, it
| starts my service manager. It's been reliable for over 15
| years, across hundreds of installs, in a wide variety of
| contexts. Importantly, it has never created problems for me
| when trying to rescue a system.
| eesmith wrote:
| Yes, https://without-
| systemd.org/wiki/index_php/Special_RecentCha... shows the last
| edit on the site was 19 April 2018.
| pmoriarty wrote:
| runit works for me... on a modern system.
|
| Unlike systemd:
|
| - it's nice and simple
|
| - it's well documented
|
| - it's easy to troubleshoot
|
| - it doesn't have it's tentacles in everything
|
| That said, I don't run any desktop environments like Gnome or
| KDE, but just run i3 as my window manager.
|
| OpenRC also worked well for me when I was on Gentoo.
| LinuxBender wrote:
| Many of the distros they link to are very much kept up to date.
| I can vouch for Voidlinux and Alpine Linux. Another one I like
| that they left off the list of Qubes OS [1] although that needs
| a fair amount of memory to take full advantage of.
|
| [1] - https://www.qubes-os.org/
| flatiron wrote:
| If it ain't broke... If you are going to use Linux at work it
| will be system d. I use Linux both at home and work so I use
| systemd. I've had exactly 0 issues with systemd and if systemd
| has a solution for something (like ntp time or efi booting) I
| just use that.
|
| I understand it's not everyone's cup of tea and have nothing
| against peoples personal decisions. It's just the ship has
| sailed regarding systemd regarding that most people use it and
| it's the industry standard.
| throw0101a wrote:
| > _If it ain't broke..._
|
| And then there's systemd-resolved...
| vetinari wrote:
| As if resolving wasn't traditionally broken in Linux and
| now people are relying on broken behavior.
| SahAssar wrote:
| I run resolved and it works for me. That is not to say that
| is fine for everyone so: resolved and networkd can be
| replaced if they do not work for you, right? Not sure how
| it is in ubuntu now (as an example), but when ubuntu
| started using systemd they did not use either resolved or
| networkd.
|
| They point against systemd would be resolved both being
| broken and being unable to replace it with another
| resolver.
| strictfp wrote:
| "works"
|
| They closed this super-critical bug despite not fixing
| it, claiming they're making the right decision in their
| implementation when they in fact misread the spec
|
| https://github.com/systemd/systemd/issues/2514
|
| Yeah, that's right, with resolved you cannot connect to
| other machines on your local network by specifying their
| simple names, because it blackholes those requests, and
| there's nothing you can do about it.
| drdaeman wrote:
| > with resolved you cannot connect to other machines on
| your local network by specifying their simple names
|
| Huh? You most certainly can. I mean, somehow "ssh koyomi"
| works here on my network, no matter if machine I run this
| on uses system-resolved or unbound or something else. My
| DHCP server supplies options 119 and 135 and that's all
| that's necessary to make it work.
|
| What you can't is to have a CNAME with a bare hostname
| i.e. make "foo.example.org" magically resolve to
| "foo.local" when you're on that particular LAN with
| "search local" (and $deity knows what if you're not). To
| be honest, I'm not even sure what's the point of this
| setup, unless you do split-horizon (but then why not
| respond with "foo.local." proper?)
| strictfp wrote:
| Do you have a proper domain name for your local network
| (+ search domain)? I'm talking about the case where you
| don't, or have a '.local' domain;
| https://askubuntu.com/a/918161
| tasuki wrote:
| This issue also hit me! It was easy enough to set up
| `dnsmasq` and use that instead of `systemd-resolved`.
|
| And yes, I'm a little upset about it being broken by
| default and having to hunt down the issue, which did take
| quite a bit of time.
| SahAssar wrote:
| I skimmed the bug report, and wrote up a reply, but then
| realized that all of this is meaningless to the actual
| question: If your beef is with resolved, and resolved can
| be replaced with your resolver of choice, what is your
| point against systemd as an init?
| nullcipher wrote:
| what's wrong with systemd-resolved?
| 4bpp wrote:
| Good for you that you never experienced it breaking, because
| when systemd breaks, half the time the experience very much
| feels like breakage in a proprietary software stack (like
| Windows or, god forbid, Apple). Most recently, I've had
| systemd entirely prevent the mounting of an encrypted
| external HDD because the previous service it created for the
| mount (the previous time the disk was connected) refused to
| allow itself to be deactivated (even though there were no
| open handles left to either the disk or the mapper), and
| conversely knock a rental server offline (after an automated
| package upgrade from Debian security) as it decided that it
| didn't need to and wouldn't want to start network.target
| anymore.
|
| In neither case was there any diagnostic information
| available (in the journal or daemon status) that would
| provide pointers to _why_ it behaved as it did, and unlike
| with an external daemon manager it doesn 't seem easily
| possible to forcibly debug what exactly it tries to do when
| performing an action (without debugging the entirety of
| systemd, which probably would require a second machine in
| physical proximity or at least running the problematic system
| in a VM?). In the end, I still have no solution to the former
| problem (which occurs occasionally) other than doing a hard
| reboot; for the latter, I gave up and made a service (using
| the hoster's virtual console service) under a different
| target that performed the necessary ifupdown calls to make
| the server reachable again upon reboot. Neither of these are
| things that I remember having to do on Linux before this
| "enterprise-quality" technology was rammed down my throat; it
| really feels much closer in UX terms to patching out bugs in
| system DLLs with a hex editor back in the days.
| sillystuff wrote:
| I have personally experienced a ton of breakage from systemd.
|
| The claim was that systemd was compatible with sysV init
| scripts. This is not true, and the breakage might not even be
| noticed until you are dealing with data corruption. If you
| have a startup script that does an su to a different user,
| systemd will start the application, but it will just kill the
| application processes that were spawned after the su, rather
| than doing a proper shutdown. E.g., if you use the startup
| script (only sysV) Oracle provided, systemd will kill your
| DB's processes in an apparently random order rather than
| allowing a proper shutdown. The issue is in the way systemd
| uses cgroups to keep track of which running processes are
| associated with a particular startup script. Every version of
| systemd is affected.
|
| Systemd initially claimed compatibility with fstab. But, it
| broke things. Systemd does not process the entries in fstab
| sequentially. This breaks fuse filesystem mounts that depend
| upon a backing store mount. Systemd later added additional
| mount options to try to hack around the breakage, but, in my
| experience with glusterfs, they are necessary, but not
| sufficient, and I had to add overrides for other systemd
| service units to get things to start reliably.
|
| I also had a fun time cleaning up the mess after systemd made
| remote systems using full disk encryption, unbootable. The
| responses by Poettering in the bug report from the Debian
| systemd maintainer were what really convinced me this systemd
| thing was going to be a huge mess. TLDR Poettering basically
| said, he never used a feature like Debian's keyscripts, and
| wasn't willing to make the existing system work. Years later
| Debian has a hack that allows keyscripts to unlock disks in
| the initrd before systemd gets involved in the boot.
|
| Another fun issue early on, on an embedded system that was
| using ext4 without a journal. The system experienced a hard
| power down. When it came back up, it prompted for a root
| password for the emergency (single user) shell. But, it
| wouldn't auth. It started echoing back parts of what were
| typed mixed in with garbage characters in its prompts
| (including the plain-text root password). Messing around in
| this state, I realized that it was executing (as root)
| whatever I typed as the password. So, for password, I typed
| fsck -f ... and was able to get the system bootable again.
| System was reverted to sysV, and everything worked properly
| again. Maybe this was a systemd-logind issue?
|
| I use systemd since it "won", but it has not been a good
| experience (the above is a small subset of issues I've
| personally seen, but pretty representative of impact).
| nousermane wrote:
| "For a modern personal computer", systemd is pretty much spot-
| on what you'd want.
|
| On the other hand, if you're running a bunch of fast-scaling
| containers/VMs, and just want init to (re)spawn one (or a
| handful) of processes, then step aside as quickly as possible,
| sitting there quietly, reaping zombies - TFA has this page:
|
| https://without-systemd.org/wiki/index_php/Init/#standalone_...
|
| And there are other alternatives as well, such as:
|
| https://github.com/Yelp/dumb-init
|
| https://github.com/krallin/tini
| megous wrote:
| There are alternatives to [very many] individual core
| competencies of systemd. Obviously a direct alternative to a
| kitchen sink such as systemd would be just another kitchen
| sink, so there's no such thing like that, that I'm aware of.
| unkn0wn_root wrote:
| I would appreciate if anybody would explain why there's so much
| hate against systemd. I don't get it but maybe I'm just cusual
| Linux user.
| qbasic_forever wrote:
| Systemd "moved the cheese" and some people will never stop
| getting upset about it.
| croes wrote:
| https://without-systemd.org/wiki/index_php/Arguments_against...
| kristjank wrote:
| I hate to be smug here, but there are plenty of simple reasons
| outlined on the very same wiki: https://without-
| systemd.org/wiki/index_php/Arguments_against...
|
| My personal relationship is a necessary-evil one. Without it,
| I'd have more problems with concurrency and service/session
| management, but I'd lose a lot of "systemd messed up
| resolv/nsswitch/hosts" scenarios.
|
| Also, for most basic set-ups, even server ones, a classic BSD
| or SysV init works, as do simpler and more lightweight options,
| as proven by Alpine, FreeBSD and derivatives (FreeNAS, PFsense)
| and OpenBSD based solutions. And when stuff goes wrong, those
| are infinitely easier to decipher.
|
| That doesn't mean, however, that systemd is hard to write
| config for, often when you need a service or script ran at
| bootup or login it's easier to make it work right than with a
| SysV-style init script. The problem is the growing config- and
| codebase, coupled with the binary logging system, which makes
| it even harder (AND NO, I REFUSE TO LEARN ANOTHER HIGHLY
| SPECIFIC TOOL TO READ THE BINARY FILES).
|
| Ysall
| megous wrote:
| The logging system is one of those things that are just done
| right by systemd. I usually force everything to log to syslog
| and let journald handle it.
|
| Just being able to see all potential new issues all over the
| system with a single command after system update + reboot is
| extremely time saving. Viewing only logs from the last boot,
| filtering, interleaving of all log messages from everything
| on the system, so you can easily see the timeline of things
| in one place, sane log rotation that doesn't make it harder
| to query logs, etc.
|
| If I had to not use systemd, this is the first thing I'd
| rewrite or find some alternative that takes the same
| approach. :)
| corrral wrote:
| - Some Linux users aren't fans of super-projects.
|
| - Some Linux users really like modularity and composability
| ("do one thing") to the point of considering it a core tenet of
| unix-alikes overall.
|
| - Systemd is perceived as being a super-project that is not
| _practically_ modular and composable (though it may
| hypothetically be so)
|
| - Some see systemd and related activity in Gnome and elsewhere
| as Red Hat bullying their way into excessive control over the
| direction of Linux.
|
| - Mistrust of Poettering and the general attitude and
| competence of developers on the project--some of this hostility
| dates back to pulse audio, another Poettering/Red-Hat project
| that was seen by many as technically deficient, led by people
| with excessive hubris without the know-how or taste to back it
| up, and excessively/unjustifiably promoted by Red Hat and
| Poettering through political maneuvering.
|
| - Concern that due to all of the above it represents: a power-
| grab by a single actor over Linux; a risk to Linux security and
| stability; and a risk to the future maintainability of, and
| practical transparency to the user of, Linux due to the scope,
| complexity, and architecture of the project, coupled with its
| heavy dependence on a single benefactor.
| sroussey wrote:
| > - Some Linux users aren't fans of super-projects. > - Some
| Linux users really like like modularity and composability
| ("do one thing") to the point of considering it a core tenet
| of unix-alikes overall.
|
| That's why Linux itself is a micro kernel. Oh wait... ;)
| corrral wrote:
| I'm not claiming these preferences are consistently
| applied, necessarily :-)
| vetinari wrote:
| > - Some see systemd and related activity in Gnome and
| elsewhere as Red Hat bullying their way into excessive
| control over the direction of Linux.
|
| The funny thing is that Redhat management didn't see the
| point until _other_ distributions (read: Arch) adopted
| systemd. Until then, it was skunkworks.
| yjftsjthsd-h wrote:
| I guess I'd offer 2 big points.
|
| First, systemd came in and replaced a _lot_ of the base OS,
| happily changing things to be... either "modern and designed
| with hindsight" or "breaking compatibility because they could",
| depending on your viewpoint. As an end user it was mostly
| invisible, but anyone mucking around under the hood got half
| the engine replaced on them, and it was not appreciated. (A
| major example would be the journal; for 40 years logs went into
| nice flat text files that could be watched with tail(1) or
| searched with grep(1), and then systemd came along and moved
| logs into a binary format that forced you to go through
| journalctl to access anything.)
|
| Second, systemd can be viewed as "playing dirty" in the way
| that it was pushed through the ecosystem. It was viewed as Red
| Hat pushing their preferred solution by leveraging what should
| have been unrelated packages - udev went from an init-agnostic
| database of hardware and rules engine to being part of systemd
| and everyone else had to factor it back out, GNOME made systemd
| a dependency, that kind of thing. Further, the developers tend
| to take a... "our way is right and anyone who disagrees is out
| of touch" view, while being remarkably blind to other systems;
| my favorite was https://github.com/tmux/tmux/issues/428 ,
| wherein they wanted tmux (a portable program hailing from the
| BSD side of the ecosystem) to abandon existing daemonization
| code and go with a systemd-specific approach. They even came
| out and said that they were happy to try and make things harder
| for people who didn't accept their way - why try convincing
| someone to adopt your approach when you can just modify the
| ecosystem to progressively make it harder for them to do things
| their way (https://lists.freedesktop.org/archives/systemd-
| devel/2010-Se...)?
| peterhil wrote:
| These are my main reasons to avoid systemd as much as
| possible. And a bug in systemd-udev on 32-bit Linux systems
| that periodically halted the performance of the system into
| unusable state for long times that is probably never going to
| get fixed.
|
| Update: The bug was related with integrated Bluetooth card on
| some Dell laptops and is fixed on Ubuntu 22.04: https://bugs.
| launchpad.net/ubuntu/+source/systemd/+bug/17598...
| bsder wrote:
| There isn't "so much" hate.
|
| _Any_ change to Linux will set off some very small, very vocal
| number of very entitled complainers.
|
| The short is that all operating systems face various problems
| of synchronization and they have all roughly converged to a
| very similar design to manage it. And I really mean _all_
| --Windows, OS X/macOS, Linux, Solaris, AIX, ...
|
| The long is that there was a window where this problem needed
| to be solved and there were a bunch of half-baked solutions.
| Pottering sat down, wrote code, came up with a 3/4 baked
| solution, and RedHat adopted it. After that, RedHat continued
| funding and improving it and other distributions realized that
| systemd made things better and slowly adopted it as well.
|
| And throughout it all, a bunch of people continued to bitch
| like hell. But at no time did _anyone else_ put in enough work
| --technical, social _AND_ political--to solve the problem.
|
| Yeah, the social and political work seemed to be "It works.
| We're adopting it. Pound sand and get lost." However, even in
| the face of that, _still_ lots of people just pissed and moaned
| but failed to come up with a decent alternative.
| dylan-m wrote:
| > However, even in the face of that, still lots of people
| just pissed and moaned but failed to come up with a decent
| alternative.
|
| Which is, alas, typical. Sources of truth in free software
| are, of course, not very coordinated, but one does learn,
| eventually, how to work with that.
|
| So I find it very unfortunate that noise from these sorts of
| unhelpful reactionaries keeps getting amplified on Hacker
| News, while actual good and constructive stuff (hey, have you
| seen those lovely progress posts on GNOME Builder's GTK4
| update? Did you know there's a KDE version of Fedora
| Silverblue? How about that interestingly modern OS image for
| Steam OS? Did you know people are actually making cool new
| things with this platform instead of clinging to the past?)
| barely appears at all.
| throw7 wrote:
| Lennart came down from heaven (or, depending on your
| perspective, up from hell) and looked at the state of linux
| distributions.
|
| He said, "This sucks. Boot times are slow. Distros have a mish-
| mash of init systems and shell scripts, all subtlety different.
| Linux features like cgroups, which are the bee's knees, are
| left as an exercise to the sysadmin. Why aren't user processes
| manageable? etc."
|
| Thus systemd decided it was going to standardize a new layer
| between the linux kernel and userspace using a declarative
| model for configuration for... like everything. This was a huge
| change in the linux world. A huge change was going to be
| controversial. Systemd is still controversial.
|
| Systemd won though.
| throwaway0x7E6 wrote:
| >He said, "This sucks. Boot times are slow
|
| https://www.google.com/search?q=a+start+job+is+running+for
| nousermane wrote:
| If only they paid equal attention to shutdown as well. It
| is relatively easy to inadvertently break a systemd install
| in such a way that reboot/shutdown would go through a
| number of grotesque "tasks" with _very_ generous time-outs:
|
| - Unmounting filesystem /mnt/nfs (X seconds out of 1:30)
|
| - Waiting for D-Bus to terminate (Y seconds out of 4:00)
|
| ...and so forth. It's so bad, there is a special "C+A+D, 7
| times in two seconds" key combination to deal with those.
| Which, I've seen fail as well.
| creeble wrote:
| +10 on this. The first thing I noticed years ago from
| running a systemd-based distro, is that shutdown (thus
| reboot) got stuck in "...waiting for xxx to terminate"
| for multiple minutes. This had never happened before, and
| there were never consequences from it not happening. So
| it was (and remains, in many hard-to-debug cases)
| strictly a drawback for systemd-based systems.
| orf wrote:
| Sorry, what does that link have to do with anything?
| vetinari wrote:
| > declarative model for configuration for... like everything.
|
| Here I find that many people look for the wrong thing. Their
| idea is 'do $stuff at boot'.
|
| However, systemd does 'do $stuff at $event', where 'boot' is
| one of the events in the set. They are not wrong though, _we
| are used to cron_ is not a valid reason why it should not get
| unified.
| deathanatos wrote:
| ... but you can still just run your favorite crond, and
| keep doing exactly what you were before? I've still never
| run a cron job under systemd, and I've never hit trouble
| doing that. I.e., Systemd doesn't _force_ you to use it for
| cron.
|
| Although, now that I'm looking at ArchWiki's "list of
| reasons you might want to do this" ... it checks off
| basically every problem with traditional cron. I might need
| to start using this.
| throwaway0x7E6 wrote:
| the systemd suite had replaced tools that didn't need to be
| replaced, often does a worse job than they did and introduces
| measurable overhead, all for the sake of "standardization" no
| one had asked for
|
| besides that, it is a significant part of ongoing corporate
| embrace/extend/extinguish of OSS
|
| besides that, Poettering is a little shit -
| https://nitter.net/pid_eins/status/1376838491863191556
| creeble wrote:
| There are many arguments, but the one that I identify with best
| is that systemd is unnecessarily complex, and it's components
| are tied closely together, breaking the "single function"
| paradigm of original Unix.
|
| But really, it's more about un-learning the "old way" and re-
| learning an entirely new way. Is the new way better? It depends
| on what you need. In my case, I have never had an occasion
| where it was either simpler or "better" to change a
| configuration with systemd, so it required learning the "new
| way" with no benefit. I think many people are in this camp.
|
| But the the main reason I dislike systemd is that it has
| resulted in broken boots on servers, sometimes randomly, and
| sometimes for un-debuggable reasons (something you get when you
| mess with init). "Failed to start X", and system hangs kinds of
| things.
|
| But I have other reasons. For example, in olden times,
| /etc/resolv.conf is where your resolver addresses went. But if
| you're running systemd, then you're probably running systemd-
| resolved, which means /etc/resolv.conf points to localhost --
| because systemd-resolved is a resolver itself. So where do you
| actually configure the IP addresses of an external resolver,
| which must be set somewhere? Go ahead and look it up, I'll
| wait.
|
| /etc/systemd/resolved.conf? Maybe, depends on other systemd
| configuration files. Want to know what it's set to now? Sure
| just type "resolvedctl status", so obvious! Unless your distro
| doesn't have that binary, it's fairly new. In systems without
| systemd, updating /etc/resolv.conf was dynamic; the network
| stack recognized the change instantly and you were done. I
| don't actually know what you have to do after changing
| /etc/systemd/resolved.conf; I end up just rebooting. So time-
| saving.
|
| Is systemd-resolved better? Well, it caches DNS for all
| processes (even the ones that already cache them), so that's
| something. Do I care? I haven't yet, but this nebulous benefit
| (for me) results in me having to re-learn how DNS works on my
| machines regardless.
|
| I have a few servers running Devuan, and it's great.
| christophilus wrote:
| I really like systemd, but from what I understand, the folks
| who don't like it have a number of gripes. The one that most
| resonates with me is that systemd is monolithic as opposed to
| the old Unix philosophy of small, simple tools that compose.
| nvrspyx wrote:
| I'm not super familiar with systemd or any of the lower level
| stuff like init systems in general, but I was under the
| impression that it's just an umbrella for many individual
| modules/binaries, like journald, etc, and not actually
| monolithic.
|
| I get the argument against hard dependencies, which the
| individual modules seem to be dependent on each other, but is
| that really that abnormal with Linux programs? I more
| understand the criticism against higher level programs, like
| GNOME, having hard dependency on systemd specifically.
|
| With all that said, I'm not doubting there's valid criticism
| as I'm sure that I'm missing for fundamental points of the
| "monolithic" argument as it relates to systemd. The above is
| just my sort-of layman impression.
| yjftsjthsd-h wrote:
| > but I was under the impression that it's just an umbrella
| for many individual modules/binaries, like journald, etc,
| and not actually monolithic.
|
| If you can't use journald without systemd, and you can't
| use systemd without journald, or they really modular in any
| meaningful sense? I can take a Void Linux system and drop
| in rsyslog and chronyd and maybe dnsmasq (for DNS caching);
| I _can 't_ take a Void system and add journald and
| timesyncd and resolved.
| frutiger wrote:
| > systemd is monolithic as opposed to the old Unix philosophy
| of small, simple tools that compose
|
| Isn't the typical Unix kernel that most users interact with a
| giant monolithic program with some runtime modules but mostly
| compile time configurability? I think this goes all the way
| back to the original Unix kernels.
| rektide wrote:
| Most users don't interact with the kernel. They interact
| with a posix (or posix-like) environment. And that is
| definitely a kalidescope of independent utilities. Most of
| which are at least somewhat portable across *nix/bsds.
|
| To the haters credit, previously the init system itself was
| also authored with posix-compatible tools. And could be
| hacked upon easily, readily, without compiling. By compare,
| you'd kind of need to attach gdb or what not to systemd's
| pid1 to see what's happening, and it'd be much more
| complex, and you'd need to be compiling your own systemd to
| make changes. I'm a huge systemd proponent, but to be
| honest, it's shocking to me that there's not a bunch of
| guides to running gdb, to watching systemd do it's thing:
| we largely are all consumers, accepting systemd's
| activities/behaviors on faith.
| [deleted]
| yjftsjthsd-h wrote:
| The kernel being largely monolithic is an annoyance that
| people _do_ keep trying to fix where possible, but it 's
| easier to sweep that under the rug than to deal with
| monoliths in userspace.
| frutiger wrote:
| Yes, this just highlights the cognitive dissonance that
| systemd haters have.
| yjftsjthsd-h wrote:
| systemd is in userspace; what are you trying to say?
| dspillett wrote:
| Yes, and as kernels grew this is where the arguments
| for/against micro-kernels began. Modular monoliths seem
| most common ATM, but micro-kernel architectures haven't
| entirely lost the game yet.
| [deleted]
| xcambar wrote:
| sarcastically: because it works.
|
| Less sarcastically: because it does too much, in ways that
| sometimes are impractical (networkd comes to mind). Expect
| better answers by more knowledgeable people.
|
| Personally, I like it. But I'm a simple person with simple
| needs.
| larrymyers wrote:
| I hate networkd with a passion. The levels of abstraction it
| introduces into dns resolution has wasted so much of my time.
|
| I just want to be able to have resolv.conf work. Thank
| goodness it still does on debian.
| thawaya3113 wrote:
| This is what it boils down to. Systemd has been solving
| problems that all distros have been facing.
|
| Unlike most Linux development, they haven't focused on what
| their devs want to do (which for much of Linux is repackaging
| Ubuntu with uglier skins, and Ubuntu itself is a repackaging
| of Debian/Gnome), but rather, are solving problems that
| distros are actually facing.
|
| The consequence of that is that nearly every distro goes with
| the systemd solution, and it's this popularity that leads to
| people complaining that it's being forced upon them.
| evol262 wrote:
| My experience is that it broadly falls into two categories.
|
| The first is comprised of people who never actually had to
| wrangle sysvinit/upstart (openrc is relatively sane), and have
| never seen the ridiculous amount of engineering time which went
| into hacky stuff like supervisord and bizarro, bespoke hacks to
| try to do things which systemd makes trivial: socket
| activation, optional service dependencies, file-based service
| activation/restart, "failing fast", timing various parts of the
| boot chain, etc. This class of people, broadly, probably never
| actually understood how `init` worked anyway (or how booting
| worked once dracut came into the picture), but they now feel
| like it's an opaque, unobservable system. They would have felt
| like that anyway if they had tried to work with pre-systemd
| tooling.
|
| The second mostly thinks that systemd is against the "UNIX
| philosophy". This class of people, broadly, has never touched a
| "real" UNIX other than MacOS (and they probably never had to
| deal with netinfo) or BSDs (which are great). There was
| absolutely no sanity or consistency between, say, AIX, Solaris,
| IRIX, and Tru64, and all of them had various classes of "god"
| tools.
|
| Lennart is not always right, but he does have a vision of Linux
| for the 99%. That is, one of the "against systemd" links is
| this: https://edgeofsanity.net/rant/2017/12/20/systemd-
| resolved-is...
|
| This is indicative of the problem. Ninety-nine percent of users
| don't WANT to configure 40 different baroque things with their
| own configuration files (rsyslog/syslog-ng, dhcpcd,
| resolv.conf, ntp.conf, /etc/hosts|/etc/hostname, etc). They
| want Linux to work. They want systemd-networkd to get them an
| address in 1/10th of the time, and they have absolutely no need
| to start a daemon which can set every DHCP option ever when
| ACKing. They to fuss with nameserver rotation to deal with
| flaky stuff for split-horizon DNS -- they want systemd-resolved
| to handle "this server can't be reached right now, so I'll put
| it in timeout, keep returning cached results, and send new
| queries to a nameserver which is responding."
|
| If you still WANT to do the other stuff, nobody is stopping
| you. Yes, you probably need dbus and udev and udisks, and all
| of those things are light years better than the tools we used
| to have before, but systemd itself can be trimmed down to
| almost nothing if you want to. The alternative, building up a
| stack which can sort of approximate systemd, would take a very
| competent admin at LEAST a week to build deployment tooling
| for, and that's assuming they already knew all the stuff they
| needed to plug in.
| Barrin92 wrote:
| because it's a comprehensive suite of software that largely
| gets the job done while ignoring various 'unix philosophies',
| which some people in the linux world really do not like. To me
| it resembles programming language debates a lot where highly
| popular, pragmatic languages get attacked by people with strong
| philosophical ideas about how software ought to be built.
| josephcsible wrote:
| Because for basically every new thing it replaces, it causes
| problems that the thing it replaced didn't have, and Lennart
| Poettering often pushes back against fixing these problems.
| midislack wrote:
| [deleted]
| theamk wrote:
| I think it is like old car vs modern cars.
|
| Old cars are finicky and you need to keep maintaining it. But
| people know how every part of the system works, and they can
| repair it with a duct tape and a piece of bent wire.
|
| Modern cars are full of electronics and don't break as much..
| until the do. And then you need all new tools to repair them,
| and those tools are much harder to use, especially if you are
| used to old cars.
|
| (I myself spent plenty of time on pre-systemd systems. I can
| tell you wonderful stories about apache children cleanup, and
| debugging failed startup at scale. I use systemd all the time
| now, and don't miss rc.d a bit)
| strictfp wrote:
| It brings Linux closer to Windows in philosophy. Systemd is
| building a coherent large codebase (albeit modular) that solves
| all the problems, as opposed to Linux userspaces old philosophy
| of having a collection of "expert" tools, where each tool or
| project did one thing, one thing only, and did it really well.
| Then the system was a collection of such expert tools.
|
| The collection of expert tools naturally aren't as well-
| integrated with each other, so on a system level the solution
| might look a bit spotty. But every function is thought through
| and works really well. Plus, each tool is useful on its own,
| which makes the system very configurable, introspectable, and
| hackable.
|
| The "one big codebase that solves all problems" approach might
| appear more stable all-in-all, but it's a fundamentally
| different approach where you no longer have a bunch of expert
| tools, but rather a large collection of mediocre software
| components who's only real purpose is to be integrated with
| each other.
| kanbara wrote:
| i dunno-- i grew up playing around with every distro of linux
| and unix i could get my hands on, and my first was
| Slackware/LILO. a lot of the so-called "expert" tools _work_
| in some fashion, but could definitely use a UI/UX
| improvement.
|
| all of the binutils and basic stuff is pretty antiquated and
| has an old-school and specific perspective and lot of the
| modern work we do as developers and operators has use-cases
| which fall behind due to such a rigid way of thinking.
|
| i think systemd is great, and maybe it's overkill for certain
| applications, but there are also smaller containers and
| distros one can use for this. i'm all for modernising linux
| and the tooling around it, it's sorely needed.
| strictfp wrote:
| I'm not opposed to the idea of a more intelligent init
| system, but systemd is doing waaaay to much. One example;
| it messed up hostname resolution on my lan by blackholing
| DNS traffic for single-name queries. And you cannot turn
| their dns component off.
|
| Upstart would have been a better alternative.
| johnny22 wrote:
| > And you cannot turn their dns component off.
|
| Of course you can turn it off. Fedora didn't even use
| resolved until 2 or 3 releases ago and they were one of
| the first major (non rolling) distro to adopt systemd.
| strictfp wrote:
| Maybe nowadays, but when it came to Ubuntu back in the
| day it was enabled by default and couldn't be turned off
| because it was being used early in the boot cycle when
| other resolvers hadn't booted yet. Talk about bad design
| decisions...
| oblio wrote:
| That "do one thing well" ship sailed decades ago, when ls
| added sorting. I don't recall the date, but I believe ls has
| had sorting for more years than it hadn't, possibly a lot
| more.
|
| ls is not Unixy, find is not Unixy, wget/curl are not Unixy,
| the list is infinite.
| strictfp wrote:
| I thought it was "cat -v" (https://cat-v.org/) ;P
|
| Anyways, those breakages aren't nearly as big of a
| deviation from the modular design as something like
| systemd. I'm sorry, but that comparison just cannot be
| made.
| na85 wrote:
| Frankly because of the extreme arrogance originally displayed
| by Poettering and his cronies, in the vein of Apple-style
| "you're holding it wrong" when people would raise valid
| criticisms of some early systemd warts.
|
| Nowadays systemd is pretty good and not deserving of the hate
| it gets, but early on the opposite was true.
| mjw1007 wrote:
| Broadly, systemd was trying to do two things at once:
|
| - be "opinionated" software
|
| - supersede all other software in its category
|
| Very few other free software projects have tried that
| combination.
|
| I think it might have been be possible to do without angering
| large numbers of people if the developers had been
| significantly above average in both technical judgement and the
| social aspects of developing free software.
|
| But the systemd developers weren't either of those things.
| strictfp wrote:
| Classic Red Hat. Arrogant and agressive. Reinventing the
| wheel. Usually also one or a handful of developers per
| project.
| strictfp wrote:
| For those of you who downvote this because you think I'm
| being disingenuous, I speak from personal experience of
| working closely with Red Hat in a number of projects where
| their code were an integral part of the solution.
|
| Red Hat really do reinvent the wheel, for the purpose of
| making money selling popular kinds of software. And they're
| shamelessly declaring themselves superior to the product
| they're mimicking. And the projects are ran like side
| projects of the lead developers.
| sodality2 wrote:
| Lots of people complain about its complexity and how many lines
| of code it is, making it very difficult to audit; it "goes
| against the UNIX philosophy" because it tries to do too much.
|
| No dog in this race, so if someone wants to correct me, feel
| free to.
| yarrel wrote:
| It's a Dunning-Krugerish non-solution, sold as an init system
| trojan that is replacing more and more of the OS with less and
| less understanding of how it would need to work in order to do
| so effectively. It's a monolith that is almost pure attack
| surface, which requires the rest of the OS to change to work
| with it, thereby making it part of that monolith and extending
| the attack surface.
|
| Every admin issue I've had over the last decade save two has
| been due to SystemD. I'm not opposed to change, but I'm also
| not going to embrace change for its own sake, particularly
| incompetently designed and implemented change.
|
| Then we get to the project's social problems. But people get
| very defensive about that, so I'll just point out that if
| change is such an unalloyed good we certainly can't argue
| against changing away from using SystemD, can we?
| dylan-m wrote:
| > Every admin issue I've had over the last decade save two
| has been due to SystemD.
|
| Do you administer systems with SysVinit as well? If not,
| please consider that _of course_ the system which manages
| startup and background services is going to be responsible
| for admin issues. It is exactly the area you are responsible
| for administering! If yes, I 'm curious how those are going
| in comparison. Are they less trouble?
| bee_rider wrote:
| I was averse to systemd initially, and held on to my legacy init
| for as long as I could until my distro totally switched over and
| just stopped supporting the legacy stuff.
|
| At that point, I realized I don't actually want to manage an init
| system. Which further lead me to the realization that I wasn't
| actually working with the thing very often, and brought into
| question my qualifications for having strong opinions on the
| topic.
|
| I see lots of arguments against systemd that, to my untrained
| eyeball, seem pretty compelling, and lots of groups who are doing
| the actual, non-hypothetical work who seem to've ignored the
| arguments and switched over.
| GauntletWizard wrote:
| I'm an SRE, I've done Linux from scratch, and I've built my own
| alternatives to system management, including "Service Managers"
| and "Container runtimes" (a fuzzy distinction if ever there was
| one)
|
| Systemd badly needs alternatives. Upstart was a good one, and I
| wish it hadn't been abandoned. It had a lot of things wrong
| _around_ it, but Upstart was not all-consuming and it did the one
| job it was supposed to do - Keep a set of processes alive - well.
|
| Systemd is opinionated in every way, and that's fine. But it
| needs something out there to challenge those opinions. It needs
| something that will force it to evolve the way users want and not
| just how it's developers want. Most importantly, it needs the
| egos involved to be shut down.
| midislack wrote:
| The alternatives all exist and work fine. Init still works
| great too. And if you need auto "healing" daemons and such you
| can even use daemontools. There are a slew of actively
| developed well supported alternatives you can use today. And
| it's not so much the opinionated nature of the systemd pushers
| that's obnoxious, it's the fact that the software is enormous,
| buggy, and insecure.
| [deleted]
| jchw wrote:
| A lot of the arguments about systemd are annoying because they're
| either based on things that are simply inaccurate (like many of
| the jabs about stuffing things into PID 1, done by people who
| don't realize systemd-init is just one component,) are based on a
| super luddite mindset (I really don't think shitty Bourne shell
| sysvinit scripts are better than systemd units, TYVM,) or
| hyperfocus on relatively small points of contention (Usually
| Poettering's attitude, which does suck sometimes. Sometimes more
| specific things like the UID fail-open bug. Sometimes valid but
| contentious design choices like binary log storage.)
|
| Granted. There is plenty of valid criticism against systemd, and
| when it was first pushed on all of us I was among the angsty
| annoyed people. However, I also don't care that much about init
| systems, so if it was gonna work it was gonna be fine for me.
| Systemd today works quite well. It's a more complete replacement
| for many of the components it replaces. It has a handful of
| annoying behaviors, but it also does _a lot_ of things quite
| well. I really like socket-activated units. User systemd works OK
| for me too. systemd-networkd is pretty good for systems that
| don't need NetworkManager. I initially had some issues with
| logind, but today it does roughly what I want it to. (Desktop
| Linux is the only OS that gives me the actual behavior I want
| with sleep on lid close: it does it only when the last external
| display is disconnected. I have written software to try to get
| similar behavior in Windows.)
|
| My remaining complaints:
|
| - I dislike the way systemd is pushing the world towards dbus
| even more. Not every UNIX like ships dbus by default and not
| everyone wants it. It is flawed in some ways and it is terrible
| that it is being imposed as a boundary for all kinds of system
| services in a way that will take ages to break free from.
|
| - I dislike that instead of building more generalized interfaces
| or working into existing frameworks, systemd's interface is
| quickly becoming a major part of the desktop Linux ABI. Major
| projects increasingly depend on it, working poorly or not at all
| without it.
|
| - Generally just RedHat not caring about the former concerns as a
| whole makes me not like their control over the ecosystem. I'm
| glad somebody takes the mantle of trying to push desktop Linux
| forward, but I really have a strong dislike towards RedHat in
| general, and things that are perceived as highly influenced by
| RedHat. GNOME's CSD initiative is the worst thing that has ever
| happened to desktop Linux and libdecor is an ongoing failure of a
| solution years later. No offense to the folks who painstakingly
| work to make it happen, but I'm not sorry, it's crap. My opinion
| hasn't changed even slightly since day one. (Though almost all
| Wayland compositors outside of GNOME's support server side
| decorations, so you could always give GNOME users decorations
| that let them know how you feel ;)
| linsomniac wrote:
| From list of reasons: "immaturity and instability"
|
| I dunno, I've been running systemd on Ubuntu across over 100
| machines for ~5 years and I can't agree with either of those
| points.
| dang wrote:
| Related:
|
| _Without Systemd_ -
| https://news.ycombinator.com/item?id=14875452 - July 2017 (49
| comments)
|
| _Without Systemd_ - https://news.ycombinator.com/item?id=9515125
| - May 2015 (88 comments)
| sylware wrote:
| I run my own custom linux based distro.
|
| I run a minimal init process and my desktop rig is inited by a
| brutal and beyond idiotic sh script.
|
| What's long is the EFI bios init, and displayport programing,
| namely everything is done in a matter of very few seconds.
|
| Anything more complex would be grotesque.
___________________________________________________________________
(page generated 2022-05-27 23:02 UTC)