Systemd 250 Released

by nnx • 5 years ago

89 197 5 years ago

sigmonsays• 5 years ago

minor issue, but anyone know how breaking changes are managed?

between ubuntu16 and ubuntu20 some unit file parameters have changed. I find it rather troubling that we can't maintain consistency.

p_l8• 5 years ago

The approach was always "fuck you" and it's bigger part of "lennart hate" than people like to admit...

rurban• 5 years ago

The static lease DHCP server logic in systemd-networkd may now serve IP addresses outside of the configured IP pool range for the server.

See, see, taking lessons from C++. So someone requested a bug, and they got it. How could that be useful?

electric_mayhem• 5 years ago

Systemd is a matryoshka doll of bugs.

How could that be useful?

JoshTriplett• 5 years ago

Suppose you have a network 192.168.0.0/24, with the router at 192.168.0.1, and you want the DHCP server to hand out dynamic addresses from 192.168.0.50 to 192.168.0.240 to clients, and hand out static IPs from 192.168.0.2 to 192.168.0.49 to specific identified devices via static leases. Those static IPs are outside the configured IP range for the DHCP server, intentionally.

iam-TJ• 5 years ago

DHCP protocol actively avoids specifying a policy - that is for the system administrator. It defines three 'mechanisms' for allocation [0]:

  * automatic == permanent address
  * dynamic == finite (time-limited) and possibly re-assignable to a different client
  * manual == assigned by system administrator (and simply conveyed by DHCP)

Static leases outside any 'pool' are "manual" allocations.

[0] https://datatracker.ietf.org/doc/html/rfc2131#section-1

kuhsaft• 5 years ago

I think there’s a misunderstanding. The [DHCPServer] section is tied to a [Network] unit. The [Network] unit has an address range. The [DHCPServer] section has options to reserve a range for dynamic leases. There is also [DHCPServerStaticLease] sections to assign static leases. However, previous versions of networkd did not allow the static lease to be outside of the [DHCPServer] dynamic range. Now, the static lease can be outside the dynamic range but within the network range. So, pretty much what any other standard DHCP server can do.

davydm3• 5 years ago

wait, hang on - the init process now incorporates a dhcp server? why? when there are existing solutions to that problem?

sgaduuw7• 5 years ago

no, it's not the init process, it's one of the tools in the systemd suite

ChuckMcM2• 5 years ago

At this point any system that is running this should not be called "UNIX derived" or "UNIX like" as systemd has subsumed all of the pre-existing architecture around system startup and management. Not arguing if that is a good or bad thing just saying we should stop putting systemd managed systems in the 'UNIX' column just like we don't put Windows NT systems in the UNIX column.

ddingus4• 5 years ago

Agreed, also no judgement here as well.

I propose: "UNIX-ish" or Sysd type Linux.

Shit, what am I thinking!

GNU LINUX was the older discussion and development.

SYSTEMD LINUX is likely most applicable nomenclature, given current development.

traverseda3• 5 years ago

Well UNIX is "a pun on multics", so how about EUNICS? The S can stand for systemd.

josephpoon• 5 years ago

I'd just like to interject for a moment. What you're referring to as Linux, is in fact, systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning systemd system made useful by the systemd init system, IPC layer, and other vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the systemd system every day, without realizing it. Through a peculiar turn of events, the version of systemd which is widely used today is often called "Linux", and many of its users are not aware that it is basically the systemd system, developed by Red Hat. There really is a Linux, and these people are using it, but it is just a part of the system they use.

Linux is the kernel: the program in the system that allocates the machine’s resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the systemd operating system: the whole system is basically systemd with Linux added, or systemd/Linux. All the so-called "Linux" distributions are really distributions of systemd/Linux.

(/s)

ChuckMcM2• 5 years ago

Okay, that made my wife come in to see what I was laughing about.

ChuckNorris89• 5 years ago

Would anyone care to explain to someone who isn't 1337 in the inner workings of Linux, why systemd makes modern Linux not very UNIXY anymore and why everyone seems to hate it to death?

theteapot2• 5 years ago

This: https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_a...

lbotos• 5 years ago

Linux via Unix: Do one thing, and do it well. https://en.wikipedia.org/wiki/Unix_philosophy

Systemd: Not that.

See https://news.ycombinator.com/item?id=29670980 for an example.

ddingus4• 5 years ago

Basically, systemd is a big binary that manages the system.

That used to be many discrete programs and shell scripts and files.

There is a lot of philosophy to consider from there.

ggm• 5 years ago

It used to be process 1 was init, and it forked/exec'd everything else typically from /etc/rc (this elides over a lot) -its the first binary the kernel runs. Everything else stems from the birth of user process number 1.

Fork/exec is the lightweight process inheriting of open i/o and memory state with copy-on-write which made Unix a joy to work with. It's a delightful mapping of kernel and userspace into complex inherited tree of processes sharing that origin state (or not. You can close it all down, change things.)

systemd is a complex mega binary which parses control files and subsumes several functions. It's big. It's not small like init. It's not fork/exec simple it forks control processes and monitors children and does a lot of work some daemons did themselves (getty, inetd) but others didn't do. And you get to monitor things. It's not unlike launchctl on OSX or other platforms. And after all /etc/rc is now 5 or more/etc/rcX.d/ complex substates of states to look for scripts, SAT solver complex dependency stuff between semi arcane shellscripts... blah.

PRO: everything is now much more consistent

CON: greybeards like me hate it (beardless btw but meh) because it's complex

traverseda3• 5 years ago

Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

It's a bit of a monolith. People will say it's not, because it's made out of a bunch of smaller components, but when those components are that closely interlinked it stops mattering if they live in different code bases.

It also has a pretty wide scope. PID 1 is responsible for things like dealing with zombie/orphan processes and it's generally a good idea to keep it as minimal as possible, and keep the attack surface as small as possible. Systemd handles things like socket activation, logging, scheduling, etc. It handles all this in more or less one process, which means that when/if that process crashes or has security concerns it's a much bigger deal. It even has it's own docker-equivalent!

Really you want to keep PID 1 as minimal and secure as possible.

Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

They've made it hard to work with generic linux tools. For example they have their own custom log format that isn't text based. This means that linux tools like find or grep won't work on systemd logs. Generally systemd has replacements for those tools, like you can still grep but you've got to learn the specific systemd ways of actually getting the output and all that (note that a lot of distros seem to ignore systemd's logging provisions and just log to files like normal, for a bunch of stuff).

It's pretty complicated to reason about, one "unit" can be a bunch of different files spread out all over the filesystem, and it can be hard to get a good view of all the aspects that effect a unit without resorting to systemd-specific tools to figure out the relationships between things. For example if you want to edit a unit file the suggested way to edit a unit file is with something like `sudo systemctl edit ssh` or possible `sudo systemctl edit ssh --full` depending on the situation. Spreading files all over the place like that sort of betrays their enterprise roots, it makes some sense when you're working with very large teams but just having all the until files in one location (/etc/init.d) would be a lot more readable and manageable. Also having one file per unit, instead of having to have separate file for units and their dependencies (things like sockets) would be nice.

Another problem is that they broke chroot, which makes dealing with embedded systems that use systemd a pain if you're not using a systemd based host to develop on. They sort of force you to use systemd's docker equivalent instead of the more common chroot if you're dealing with systemd-based embedded systems. That means you'd better be running a systemd based host system as well.

---

Also I think some of us feel like it's being forced on us. Redhat/IBM funds or has control over a lot of the unix ecosystem, so when we see things like Gnome not working on BSD any more because it has a hard dependency on systemd, well it starts to look like an intentional.

Things like the systemd decision to randomly kill off screen/tmux sessions on user logout leave a really bad taste in some people's mouth. Honestly a fair bit of the dislike is just repeated instances like that, and repeatedly ignoring feedback as to why that's actually a pretty big problem, and generally being unwilling to compromise with the broader community.

https://www.reddit.com/r/programming/comments/4ldewx/systemd...

Spivak2• 5 years ago

* dbus — This is part of a broader change in Linux userspace from text/byte streams to a message bus of structure data similar to COM. It’s incredibly powerful the things you can accomplish with it but it’s sysadmin/power user unfriendly if you expect the interface to system services to be “call a binary from bash.” systemd uses dbus for basically everything which makes it really really easy to program while simultaneously erasing every sysadmins muscle memory and ability to solve every program with more bash.

* lack of composability — This is what is really meant by the “do one thing” mantra. Plenty of UNIXY tools are bloated but they don’t feel like it because they can be called as filters. systemd is actually quite modular but the pieces aren’t designed to be standalone. Like how in Ansible is everything is a plug-in but it’s cumbersome to just run a single module.

* “better is worse” — one of the weirder faults of systemd is that it’s thoughtfully designed, handles edge cases gracefully, and does things the right way. Kinda odd to paint this as a fault but it’s the reason people like bash over powershell; Unix tools were mostly made by people solving their own problems and so are completely inconsistent, full of sharp edges, odd syntax and parsers, have plenty of unimplemented features but are fiercely useful. systemd is a tool not forged in battle and is designed by people trying to write good software over software that solves an immediate need. This isn’t to say that systemd isn’t useful — it’s genuinely transformative but software written out of frustration tends to be designed differently and it shows.

gorgoiler6• 5 years ago

UNIX, TCP/IP, C libraries, web browsers and HTML… all are interoperable technologies. If your site works in browser X, you can switch to browser Y and it still works. If your code compiles for x86 Linux, it’ll run on arm Linux too.

SystemD is not an interoperable technology. It insists on wrapping itself around what was already there, in the guise of making it better while also making it impossible to use something else.

Abstract example: imagine systemd-plated manages access to crockery in your kitchen, providing neat features like being able to quickly pick out plates by colour (the old system never did that!). However, if you take a plate for yourself instead of asking systemd for it then systemd will take the plate out of your hands, put it back in the stack, and say “error: plate not requested via systemd”. Now imagine everything in your kitchen has to go through systemd. Now imagine that systemd is one of the biggest and most rapidly changing machines in your kitchen that breaks a lot. You’d be pretty annoyed if you ever did anything weird enough to encounter these bugs. If you only ever want a blue plate, you’re fine.

Real example: Any day now we’ll be unable to use plain LXC on Linux because systemd (1) assumes you only manage containers via systemd and (2) clobbers any changes you make outside systemd, using the lxc-* tools.

Woodi• 5 years ago

Like someone already answered systemd started as init replacement "to make Linux boot faster" - that was PR pitch. But then it consumed many system services like logging, time, logging in, hardware detection, network, mounting, audio, GNOME, etc etc. That alone is enough to clearly state systemd is bullshit. Everything is now interdependend and it is realy hard to replace some parts of it like eg. udev - decade old story ?

Yes, some things was improved but it could be done in sane way - making things by design replecable, as it was always in UNIX way. But systemd is intentionally self absorbing, more - looks like it is intentionally layer above Linux. Now what we can do when one day Pottering or anyone from that IBM/Intel/MS cabal will merge Linux kernel uncompatible change ? And make Windows kernel "working flawless" - for some time of course. And with build in tracing. Or login right licensing ? :) That can be easily done today. And what plain users will tell ? "Works for me, what you talking about ??" Remember, some idiots already tried to sell plant seeds that you needed to re-buy every year. Business unchecked becoming evil.

Btw. about that "boot fast" :> Now it is dropped, of course. Also making system gooing down almoust instant is broken for years now.

My prediction is that in some time facepalm will be most common reaction when someone hears "systemD".

nightfly2• 5 years ago

why everyone seems to hate it to death

This isn't universal. For service management systemd is awesome, and has been way more enjoyable to use than any other system (Ubuntu's upstart, Solaris's SMF, FreeBDS, and old-school linux init). As a sysadmin my only issues with systemd have been occasional patches that required rebooting, but these have practically disappeared in the last few years.

3np7• 5 years ago

I don’t follow how a new startup/system management architecture makes it “not UNIX”. We do put OS X in the UNIX column, after all. POSIX and all that.

fsflover4• 5 years ago

https://en.wikipedia.org/wiki/Unix_philosophy

Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

AFAIK none of these describes systemd.

nightfly2• 5 years ago

Solaris's init/service/network management is/was just as complicated and it was definitely still UNIX.

p_l8• 5 years ago

Solaris 10 system is IMHO less complicated than systemd mess, and definitely easier to debug when things go wrong (and the documentation doesn't lie)

jart• 5 years ago

Well the name System D implies a manifest destiny to conquer System V (i.e. UNIX) because D=500 and V=5 in Roman numerals. Why else would they choose the name? Also you should call it GNU/Systemd.

rswail• 5 years ago

Or you could avoid silly conspiracy theories and think about a lot of different daemons that have "d" at the end, like httpd, crond, etc.

rzzzt• 5 years ago

"d" is also a frequently used suffix for daemon processes: inetd, pppd, httpd, etc(-d)

tssva• 5 years ago

Should macOS and Solaris also not be considered "UNIX derived" or "UNIX like" because of their use of launched and SMF?

starklevnertz2• 5 years ago

I just want to pre-empt the inevitable bitching about systemd to say I think it’s awesome and incredibly useful and consistent and powerful and I’d take it any day over the mess of stuff that filled systemd’s duties before.

Sure it isn’t perfect, but what software is?

And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative?

lmm7• 5 years ago

And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative?

Because it's tightly coupled to everything (particularly to the few profitable parts of linux - most open-source is maintained on a shoestring, so it's pretty cheap to take control over development of even vital low-level infrastructure). This is how systemd bypassed the bikeshedding problem of there being half a dozen replacement inits but no clear consensus, with the result that everything relied on a lowest common denominator. But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.

3np7• 5 years ago

But it's toxic for the long term, because it undermines the whole point of using linux if you can't swap out pieces or maintain your own forks of individual components.

You can, though? And many distros do by default.

Don’t like systemd-boot? You can replace it with grub.

Don’t like systemd-networkd? You can replace it with networkctl. Want to use it but prefer to handle Wireguard tunnels with wg-quick? Fine!

Don’t like systemd-resolved? You can replace it with dnsmasq.

Don’t like systemd-cryptsetup? systemd won’t care if some other system takes care of your LUKS partitions.

Etc, etc.

starklevnertz2• 5 years ago

But no systemd distro is saying “we want to dump systemd but we can’t because it’s too tightly Coupled” are they?

Or maybe the maintainers are I don’t know do you have links to show this is the case?

Systemd is used by all major linux flavors because it’s the best solution for the problems it solves.

The distro maintainers are too smart to be stuck with systemd against their will.

And it’s linux …. make a better solution, if it’s truly better it’ll be used.

kaba09• 5 years ago

Why was it chosen by debian multiple times with the most democratic process out there?

Mikhail_K3• 5 years ago

And let me ask a question, if systemd is crap, why does every major distro use it?

If Big Mac is a crappy food, why billions are served with it?

pverghese2• 5 years ago

Or maybe you should questions yourself as to why you are so angry about what others like

toast0• 5 years ago

And let me ask a question, if systemd is crap, why does every major distro use it? If it was truly crap then surely the distro builders would use the alternative?

If Windows is crap, why does every system builder ship the majority of their machines with it? Why bother with a different desktop than Windows? Just because it's popular doesn't mean it's good.

Building a distro is a lot of work already, and avoiding systemd takes a lot of effort these days. Plus, there seems to be a lot of people who like systemd, so if you want curmudgeons like me (well, probably not me, I'm going to FreeBSD instead; I understand there may be some sort of fancy rc replacement in the works there, but I presume it won't break the things I expect to work, and it won't subsume half of base) and people who like systemd, then you've got to do twice the work, and everybody will ask you why you're pushing against the tide.

IshKebab4• 5 years ago

Windows isn't crap though.

esarbe12• 5 years ago

If Windows is crap, why does every system builder ship the majority of their machines with it?

Because they get incentivized by Microsoft to do so. This is a well document part of their often illegal business practices.

Maursault• 5 years ago

And let me ask a question, if systemd is crap, why does every major distro use it?

Won't find systemd in Gentoo, Slackware or Alpine. Also it is a little interesting, just a little, that whatever imperative systemd has to exist is entirely absent in every SysV and BSD, and yet variants of SysV and BSD and thier hybrids still exist, somehow, no worse for the wear.

trabant003• 5 years ago

Work hard and solve a big, complex set of problems. Solve them well. Offer the solution as free open source. Work some more to offer extra functionality and fix the bugs. Become the internet's villain.

Come up with a commercial solution to a simple problem. Ex: file sharing or password management. Make it slow, insecure, privacy violating, lose people's data. Make millions, become a hero.

theteapot2• 5 years ago

systemd is a cuckoo bird that found the perfect nest, init. Not-a-hero.

bayindirh4• 5 years ago

Become the internet's villain.

This is not about the problems systemd solves, but how they solve them and how they act while solving them.

davydm3• 5 years ago

not to mention the new problems it introduces

42jd2• 5 years ago

As someone who has learned Linux/Unix just the past few months using a systemd based distro, I find it a breeze to use. Great documentation, FOSS, and really easy to pick up. I just don’t understand why there is so much dislike thrown around when that energy can be focused elsewhere on truly bad behavior/software. And from my understanding, there are distros out there that don’t use systemd for those who dislike it that much. It’s really perplexing to me as someone newer to the community.

voidfunc• 5 years ago

Disclaimer: I _still_ like systemd.

My only real big pet peeve with Systemd is the documentation is somewhat lacking..., like it's all there in the manual, but its laid out poorly and makes it hard to understand. The interaction between unit files and dependencies is also quite convoluted when you start digging into how things are ordered. There's a ton of unit file options that enable weird conditional behavior. The moment you need to start comprehending the difference between Wants vs. Requires and not hooking into running when multi-user.target is reached (the most common situation) you are in for a world of trial-by-error testing.

Systemd is great for starting simple background services on simple desktop and server environments. It becomes a real pain in the ass once you get beyond that.

mst• 5 years ago

I'm an old school unixhead who's nonetheless made his peace with systemd because, honestly, it makes lots of things work way better than most previously available solutions did.

Thing is, it also forcibly changed a bunch of things by introducing defaults that were not at all what people expected. They might have been better overall, but it still caused some nasty surprises.

Let me try and explain a bit more concretely -

An easy example (not a hypothetical one, btw): if you have a physical server with multiple hard drives and one of them doesn't start, old school unix would boot everything it -could- boot anyway. SystemD changed that behaviour to "if a filesystem doesn't come up, and you don't set an option to tell systemd it's ok if that doesn't happen, don't finish booting".

Now, imagine you're somebody who has a physical server somewhere that has a big cache disk that you use a cheap drive for because if it fails, well, you've lost some cache space. Now imagine your server used to run a pre-systemd setup, and when you upgraded it to a systemd using version of the same distro you left all your settings as-is because everything seemed to be working fine. Now ... imagine that drive dies during a reboot ... and so the server doesn't finish booting, and so you can't even ssh in to it to figure out what's going on, and the only way to figure it out is to get physically in front of the console.

If that server is four hours' drive away, you might not be very impressed.

I still, overall, think systemd is pretty nice. But while some of the people annoyed with it are annoyed with it on a purely aesthetic/principle sort of basis, there are definitely some decisions the authors made that caused -very- surprising results for people who had been running servers for years already, and some of the dislike being thrown around is very much understandable.

lmm7• 5 years ago

If forcibly "updating" my system so that it doesn't boot doesn't count as "truly bad behavior/software", I don't know what does. The difference between systemd and outright ransomware is only a matter of degree (frankly I'd prefer paying a bit of cash to having to learn a new set of config files and admin commands because someone decided they didn't like the old ones).

(I don't particularly blame him for the specific non-booting bug, but I do blame him for the arrogance. Everyone makes mistakes, but most people learn from them and develop a bit of humility. Pottering continues to break people's computers every couple of years)

captainmuon2• 5 years ago

Systemd by itself is alright, the problem for me is the larger movement from "Linux is about choice" to tightly integrated, opinionated tools. Examples:

- Gnome started to depend on systemd features. Now non-systemd systems become second class citizens.

- You used to be able to freely swap out window managers, taskbars, and so on, because everything was working with common standards. In the modern world, everything is integrated in your wayland compositor, and if you want to change the way window decorations look, you will also have to change everything else. Systemd is similar, it wants to take over so many responsibilities (task scheduling, DNS, session management), and if you want to swap out one part it is going to be difficult.

- Pulseaudio, NetworkManager, Polkit: Written in the same spirit, in part from the same people. Work great if everything works as expected, if they break it is a nightmare to figure out why. But code depends on them, so they become de facto standard on desktop linux.

aww_dang• 5 years ago

You make a valid observation. However I doubt that most Systemd haters are champions of commercial bloat. If I had to generalize, I'd assume that they dislike both.

xpressvideoz• 5 years ago

Yeah, it's about whom to target. Open source overlords are hard to satisfy, to be honest.

0x0nyandesu• 5 years ago

Personally I use Gentoo with OpenRC. It's basically the opposite of bloat.

bayindirh4• 5 years ago

Half of systemd's problems are coming from human aspects rather than technical.

I'm too tired to write them all over again, but here's a rundown, from me.

- https://news.ycombinator.com/item?id=25611149

- https://news.ycombinator.com/item?id=27651567

sjansen2• 5 years ago

There is so much truth to what you say. I used Linux exclusively from January 2000 until April 2012. A lot has changed in that time, but out of all the changes the three I'm most thankful for are:

(1) Xorg replacing XFree86 and making video "just work"

(2) Pulse Audio replacing OSS and making audio "just work"

(3) systemd replacing the dog's breakfast of scripting madness each distro built from scratch instead of collaborating

It amazes me that the same person was responsible for leading 2 of the 3 changes.

I for one welcome an increasingly unified operating system core, instead of the random competing and overlapping components we used to have. Sure they worked 97% of the time, but the other 3% when they didn't could be a royal PITA. Especially when two waring components wasted time pointing blame at each other instead of focusing on solving end user issues.

dschuetz5• 5 years ago

(3) systemd replacing the dog's breakfast of scripting madness each distro built from scratch instead of collaborating

Which goes completely against what Linux stands for - collaboration. The "scripting madness" as you call it was actually completely transparent - if the scripting was bad, you were free to fix it. But now you have to issue a bug report when systemd does something stupid and it's not even your fault to Lennart and his gang only to get it dismissed with "no a bug, won't fix".

Also, Pulse Audio only "just works" because the distribution maintainers do that for you. It's still a stinking pile of "don't no how, but it just works".

Keep telling yourself that Lennart does a great job. Stockholm syndrom much?

lmm7• 5 years ago

The thing is, you used to be able to fix something and have it stay fixed. You used to be able to find a config that worked - which, sure, might have required some manual experimentation and customization - but then you could back it up and keep it.

Maybe pulseaudio and systemd only breaks 2% of the time rather than 3% of the time. But when they do break, you can't understand what's happened and you can't fix them, and even if they worked yesterday they won't necessarily work today. If that was tradeoff I was happy with I'd use windows or OSX.

guywhocodes3• 5 years ago

I don't know about (2). Alsa "just worked" when pulse audio was released and PA did not "just work" for like 8 years after the first release.

Seems like software history revisionism to me.

esarbe12• 5 years ago

Yeah. Lennart Poettering is one of the unsung heros of modern Linux - and the most maligned one, in my opinion.

While I get that some people are uncomfortable with breaking with traditions, I absolutely do not get all the hostility directed towards this craftsman programmer.

dschuetz5• 5 years ago

Just you wait until Lennart and his gang changes LGPL to MIT.

3np7• 5 years ago

That’d result in a fork for the major distros.

gorgoiler6• 5 years ago

“Offering some extra functionality” is a novel way of describing how systemd has expanded since being anointed as everyone’s init-replacement.

Systemd broke my ability to login, once. That was fun.

raverbashing3• 5 years ago

More like replace a working system with a more unreliable one with stability problems (and prioritize more features instead of fixing it) and more resource usage, then push for its adoption, then complain when you get hate.

Now yes, it gives you more functionality, but it was a pain until it got there. Systemd was just Pulseaudio all over again (except now in init, so if it breaks your whole system can't boot).

Now, yes. initd is jurassic. Systemd got stable eventually and has gone beyond it. And this is more complicated than it seems. But still, it's the attitude that made things hard.

pverghese2• 5 years ago

There is no reason to be so dramatic. In the end you are free to use any init system you want.

foodbag• 5 years ago

Is Lennart/Red Hat meant to be the internet's villain? Perhaps that's the view of a small minority.

I for one am very grateful for Lennart/Red Hat's vast contributions. Leading modern Linux.

userbinator• 5 years ago

Be aware that "modern" has a very negative connotation for a lot of people now.

nyanpasu64• 5 years ago

systemd-homed now makes use of UID mapped mounts for the home areas. If the kernel and used file system support it, files are now internally owned by the "nobody" user (i.e. the user typically used for indicating "this ownership is not mapped"), and dynamically mapped to the UID used locally on the system via the UID mapping mount logic of recent kernels. This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary.

I wish it was possible to pull a hard drive from one Linux system, and plug it into another, and mount the ext4/etc. partitions in a "removable" mode which ignores permissions and mismatched UIDs, and grants full access to the files without needing to be root.

LeoPanthera• 5 years ago

You can set an ACL on the appropriate mount point to grant all users in an arbitrary group rwX permissions.

teleforce• 5 years ago

This week I have just learned that systemd has an alternative scheduler in addition to cron.

At this rate systemd will probably become another new OS on top of Linux similar to Android.

pmontra2• 5 years ago

Yesterday I learned that it has its own alternative to NTP: systemd-timesyncd. Quite a big dose of NIH.

cturner• 5 years ago

Solving integration problems well is often harder than implementing functionality.

5e92cb50239222b2• 5 years ago

You mean systemd timers?

https://wiki.archlinux.org/title/Systemd/Timers

They were always there, and they work much better than cron in my experience (you're not forced to use cron expressions because it supports things like human-readable time formats; they can randomize startup times, which is useful for backups; they can put additional constraints (like "start only if network is available"); and they can actually be controlled from a single place (systemctl list-timers) instead of cron files that can be spread across multiple configs and directories in /etc/cron*, and pretty much every single user profile).

It's a tiny slice of functionality and it makes a lot of sense to keep it in the service manager.

Try harder next time.

totony3• 5 years ago

Cron has all these features:

- single place control: crontab -e

- additional constraints: systemctl status && scirpt.sh

- randomize startup times: sleep ${RANDOM:0:MAX} && script.sh

The nice thing is that it integrates with the existing infrastructure (shell scripts). This means you don't have to add code to cron to add features.

I agree with the 10s of files in /etc/cron.daily, etc. But those are there for convenience (you can even remove them from /etc/crontab)

fsh4• 5 years ago

What I really like is that systemd can tell me when the next execution will happen. One typo in the awful crontab format and your job will never execute with no way of testing it.

oynqr2• 5 years ago

My favorite feature of systemd timers is that they get triggered when the time is set by NTP on boot. Combine that with a system without an rtc and a timer to reboot the system every week. It just works.

rakoo• 5 years ago

Another one that can't be done easily with cron: when your system boots and an execution was missed, systemd timers can be told to run it

dschuetz5• 5 years ago

If homed makes it into the major distributions I'm done with mainstream Linux.

Mikhail_K3• 5 years ago

I use Devuan, systemd-free fork of Debian, no complaints so far.

sgaduuw7• 5 years ago

genuine question: what's so bad about homed to jump ship? can't you just disable it and not look back?

dschuetz5• 5 years ago

What do you mean "jump ship"? There are plenty of Linux distributions that still let you choose.

Genuine question though: why didn't Lennart and his gang just fork some Linux distribution for their ideas? Why invade everywhere else instead? Anybody ask them that?

arianvanp• 5 years ago

Being able to seal credentials for services like TLS keys to your TPM is extremely dope. I welcome this feature a lot.

3np7• 5 years ago

  systemd-networkd will now automatically configure routes to addresses specified in AllowedIPs=. This feature can be controlled via RouteTable= and RouteMetric= settings in [WireGuard] or [WireGuardPeer] sections.

Wow, that’s a pretty significant breaking change that I’m surprised to see (and one I don’t really agree with; there was reasoning behind not doing that in the first place). This is going to bite most users already using the WG functionality if they don’t realize when upgrading.

I really hope apt will notify users about this when upgrading.

  sd-boot gained the ability to change screen resolution during boot-time, by hitting the "r" key. This will cycle through available resolutions and save the last selection.

Neat!

Overall I learned to stop worrying and love the systemd, especially systemd-networkd. The maintainers can be impressively responsive in acknowledging and fixing reported issues.

dschuetz5• 5 years ago

Reading this the following comes to mind: Wow systemd breaks important things and solves non-problems, awesome, I love systemd!

3np7• 5 years ago

Honestly, moving my VPN management from wg-quick+ip-route+iptables to systemd-networkd was a great experience and made things so much easier and predictable. Wish I had done it way sooner. Similarly, after having spent way too much time fiddling with IP and routing in other ways (OpenWRT comes to mind), systemd-networkd made it so much more predictable and straight-forward.

Similar story with other components.

Having to read the release notes before upgrading to a new major version is a price I’m willing to pay.

asymmetric• 5 years ago

there was reasoning behind not doing that in the first place

What would the reasons be?

gorgoiler6• 5 years ago

SystemD has something of a reputation for being a bunch of arrogant young engineers making fundamental changes to the long established status quo in order to solve clever problems that range from tiny-minority-edge-case to non-existent.

It’s an absolute classic anti-pattern any industry veteran would recognise. Your new-grad engineer, top of their class and incredibly smart, spends two weeks rewriting a core system in Idris without telling anyone.

So accordingly, I was delighted to see the following:

[files in] systemd-homed home areas are now internally owned by the "nobody" user and dynamically mapped to the UID used locally.
This makes migrating home areas between different systems cheaper because recursively chown()ing file system trees is no longer necessary.

All that to save a chown -R if I screw my drive into a new PC (or rebuild the current PC around it)?

If I move it to a non systemD system, you’ve just added the need to chown -R all my files because the new OS says they are all owned by nobody.

I don’t even believe for one moment that a recursive chown of 100k files takes any appreciable amount of time. Certainly not when it’s a one off. (5s for 66k files on my crappy VPS just now.)

In any case, the nobody user is a blunt but useful instrument for running daemons as a user that does not own any files. I don’t really want some janky daemon to run as a user which has write access to /home/gorgoiler.

[I have some guacamole prepared, to spread on my inedible but soon to be eaten hat, the moment someone links me to a diff showing the author of this change as Alan Cox.]

[Update: The hat and condiment survive, author is one L Poettering: https://github.com/systemd/systemd/commit/cf5115f6e531c65bbb...

fsh4• 5 years ago

systemd-homed is not intended for your single-user desktop. Don't use it.

traverseda3• 5 years ago

What is it intended for? Certainly not large scale user groups backed by an LDAP server, as those would have consistent uid/gid so setting everything to be owned by nobody wouldn't make sense technically...

What is the use case?

oynqr2• 5 years ago

I guess the use case is for when you want to migrate home to a different install. At the same time assuming you can't just adjust passwd to make uids work.

So I guess there is none.

mariusor• 5 years ago

SystemD has something of a reputation for being a bunch of arrogant young engineers making fundamental changes to the long established status quo in order to solve clever problems that range from tiny-minority-edge-case to non-existent.

With all due respect, but this is bullshit. The devs that started and are working on systemd are clearly veterans of linux system programming and understand quite well the ins and outs of initializing a linux machine. Unless by some chance you're a gray beard that was working on posix in the eighties, I would give the title of veteran to Lennart and the gang.

esarbe12• 5 years ago

SystemD has something of a reputation for being a bunch of arrogant young engineers making fundamental changes to the long established status quo in order to solve clever problems that range from tiny-minority-edge-case to non-existent.

Now, I wonder what could be the reason for that? Maybe because some people just trow out unsubstantiated accusations and hearsay as matter-of-fact? Maybe. Who knows.

If I move it to a non systemD system, you’ve just added the need to chown -R all my files because the new OS says they are all owned by nobody.

Looks like you completely misunderstood the use case. Congratulation.

gigel82• 5 years ago

I'm curious if it's still falling back to Google DNS / NTP if not otherwise configured. That was a very bad choice even though I understand it'll only kick in under unusual circumstances.

bitwize• 5 years ago

Congratulations to the systemd team.

I still won't use systemd, and to the extent of my ability I will fight the trend of the Linux ecosystem hard-depending on it. But it's a bit silly to be anything but grateful for open source and choice.

esarbe12• 5 years ago

I applaud your ability to simultaneously dislike systemd and acknowledge the achievements of it's developers without the need to vilify them.

sgaduuw7• 5 years ago

I recently switched from Ubuntu to FreeBSD, and systemd-networkd is what I miss the most. Network settings in /etc/rc.conf totally feel like a bandaid on a bandaid on a bandaid.

iio7• 5 years ago

What you need is dhcpcd. I use dhcpcd on Linux as well, rather than systemd-networkd. It's better and doesn't come with any hardcode Google or Cloudflare DNS servers as systemd-networkd does.

sgaduuw7• 5 years ago

I don't think dhcpcd will create and configure VLANs and WireGuard VPNs for me

scottlamb• 5 years ago

This release should have my small fix for a pet peeve: if any local filesystem failed to fsck, the system used to go into emergency mode even if the fsck entry was marked "nofail" or "noauto". It contradicted intuition and documentation. It came up rarely but was frustrating to have the system broken until you were physically there, even if you tried to avoid this exact behavior.

Now the system boots anyway, just as it would if the filesystem was entirely missing.

oliwarner• 5 years ago

I'm a Log4Shell survivor and I'm finding it hard to see them packing more and more features into this monolith.

It'll probably be fine, but I'll be Jack's complete lack of surprise when I'm taping servers back together after a DNS exploit gives some kids root access.

revanx_• 5 years ago

I wish Systemd-networkd had native PPPoE support.

https://github.com/systemd/systemd/issues/481

Still, systemd is just great and it has made my life a lot easier.

egberts1• 5 years ago

Still no default-deny option in systemd.

unixsheikh• 5 years ago

I cannot believe how big of a monstrosity systemd has become. It started out as an init system and was promoted as such and I started out liking it. Then the wording suddenly changed to "a suite of basic building blocks for a Linux system", then came the hardcoded DNS servers, then the shitload of bugs that has been ignored since about 2015. Now instead of fixing what's broken and making things more secure, more and more cruft keeps getting added.

We used to sit around in the Unix Room saying, 'What can we throw out? Why is there this option?' It's often because there is some deficiency in the basic design — you didn't really hit the right design point. Instead of adding an option, think about what was forcing you to add that option. (Doug McIlroy).

Sigh!

Systemd 250 Released

Related Stories