Live data from Hacker News

Systemd 250 Released

lwn.net

31–40 of 204 posts

Re: Systemd 250 Released

#31

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.

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.

Re: Systemd 250 Released

#32

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.

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

Re: Systemd 250 Released

#33
post #6

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.

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

Re: Systemd 250 Released

#34

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 a…

> 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.

Re: Systemd 250 Released

#35
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...

Re: Systemd 250 Released

#36

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.

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.

Re: Systemd 250 Released

#37
post #24

Earlier quoted context omitted.

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?

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 inhe…

consistency ftw: https://news.ycombinator.com/item?id=29670751

gimme open-rc or gimme death

actually, sysv was fine too

open-rc solves the parallel-startup desire for people who want a faster boot and doesn't hide logs in binary formats which can only be interrogated with specialised tools - my primary reason for leaving Debian-based systems that I'd used for 16 years was having systemd forced on me and trying to deal with how to read good old system logging, not to mention 5-minute shutdown times, slower boot on the same machine than with Ubuntu's upstart or with open-rc.

Re: Systemd 250 Released

#38
post #6

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.

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 comput…

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

Re: Systemd 250 Released

#39

> 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 ch…

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

Re: Systemd 250 Released

#40
post #3

> 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?

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