undefined | Better HN

0 pointsj16sdiz4y ago0 comments

Not OP.

I my experience, systemd config is simple because it handles all the complexity. Inside it’s guts, it is much more complicated than a sysv system — naturally so because it can do so much more. Those folks loves using the latest and greatest kernel function for all its glory.

All works well - until it don’t. When something is broken, suddenly you have to understand all the interdependent components to debug.

Back in the days, these were not so uncommon, because bugs or simply unimplemented features………

0 comments

knorker4y ago

Agree with that. It breaks catastrophically.

But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that.

Like: oh, I want to restart this daemon, because I want it to re-run its init code (possibly with new settings), but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.

yawaramin4y ago

> but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.

FTA:

> It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.

knorker4y ago

You can, but it doesn't. If I know I want to start it I can just connect with the client.

Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore".

Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.

1 more reply

throw-84626824y ago

Starting a daemon on first connect is essential for fast boot times of a system with multiple dependent network services. This is mostly a desktop use case though. Not sure if it can be disabled for servers.

knorker4y ago

But I would also like to see data showing how often desktop users reboot (on purpose, that is, not because systemd or something says "you should reboot now" because it's shitty software that doesn't just work cross updates).

Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it?

My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot.

And even for the people that do, at what cost, here? You have a bunch of services and services completely broken, but "they started just fine" (except they didn't start), and only break once you actually need them.

So to me this really looks like it applies neither to servers nor desktop. I'm really not seeing any use case except fetishizing boot times.

And for me this always SPENDS human wait time, not save it. I try to use a service, and nope, it needs to "boot up" first. Could you not have done that already, WTF? (and maybe it fails to boot, which I only find out about now that I'm already in the zone to use it)

Are we really optimizing for kernel developers, here? Can't they just disable the services they don't need, to speed it up?

And we have eleventy billion cores now. Really? You can't start a 645kB gpsd? It takes what, 3ms?

1 more reply

j / k navigate · click thread line to collapse

0 comments

knorker4y ago

Agree with that. It breaks catastrophically.

But it's also overengineered. Like starting a daemon on first connect is "neat trick", but should never have gone beyond that.

yawaramin4y ago

> but you CAN'T, because some idiot decided that it'll only actually start when someone connects to its unix socket, so running "restart" is a no-op.

FTA:

> It can then boot your service on the first request, or you can do systemctl start lunchd yourself if you think that would take a while.

knorker4y ago

You can, but it doesn't. If I know I want to start it I can just connect with the client.

Sounds like you're arguing something like "yes, it's broken. But you can just reimplement everything and it won't be broken anymore".

Yes, I can also turn off "kill user processes on logout", but that doesn't make that not-broken.

1 more reply

throw-84626824y ago

knorker4y ago

Like, who even boots their computer anymore? Isn't the typical user on a laptop, and just suspends it?

My workplace even had to install corp software that forces a reboot every N days (with warnings ahead of time) because people just Do. Not. Reboot.

So to me this really looks like it applies neither to servers nor desktop. I'm really not seeing any use case except fetishizing boot times.

Are we really optimizing for kernel developers, here? Can't they just disable the services they don't need, to speed it up?

And we have eleventy billion cores now. Really? You can't start a 645kB gpsd? It takes what, 3ms?

1 more reply

j / k navigate · click thread line to collapse