Live data from Hacker News

What “technical” concerns do I have with systemd?

blog.lusis.org

91–100 of 102 posts

Re: What “technical” concerns do I have with systemd?

#91
post #76

Earlier quoted context omitted.

Mac OS's architecture is totally unlike systemd. Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can: 1) Run in isolation from their upstream dependents. 2) Be replaced individually.

Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol. The core components hardly run in isolation, nor are they interchangeable. You don't, for example, just replace launchd with some other init system. You don't just say "hey, screw Aqua I want to use something else." (You can run other WMs through X11, but only on top of Aqua) D…

> Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol.

What common protocol? Mac OS X doesn't have dbus. It recently acquired XPC, but XPC is NOT a system bus -- it's simply an IPC library. It's neither required, nor universally used, nor is it terminally glued to the remainder of the OS.

> You don't, for example, just replace launchd with some other init system.

You don't? Says who? All launchd does is serve as an inetd/cron-esque daemon. The system daemons themselves continue to vend standard sockets and mach ports, and launchd itself does not pervade their externally vended interface.

> You don't just say "hey, screw Aqua I want to use something else."

Actually, you can. The display stack is driven by IOKit; XDarwin can run directly atop said stack.

Likewise, none of the "Mac-like" features that you want -- for example, automatic network configuration -- rely on any sort of centralized entity that pervades all daemons. There's a seperate system -- SystemConfiguration -- that provides that functionality, abstracted through a set of well-defined APIs and modular and distinct from the remainder of the system.

> * It's a collection of daemons running that communicate over a common protocol.*

Hence it's really rather monolithic, because to play in the systemd universe, everything has to conform to systemd's tightly coupled design.

Re: What “technical” concerns do I have with systemd?

#92
post #76

Earlier quoted context omitted.

Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol. The core components hardly run in isolation, nor are they interchangeable. You don't, for example, just replace launchd with some other init system. You don't just say "hey, screw Aqua I want to use something else." (You can run other WMs through X11, but only on top of Aqua) D…

> Lol no. On many levels. MacOS does implement separate daemons, but they're all very tightly integrated, communicating over a common protocol. What common protocol? Mac OS X doesn't have dbus. It recently acquired XPC, but XPC is NOT a system bus -- it's simply an IPC library. It's neither required, nor universally used, nor is it terminally glued to the remainder of the OS. > You don't, for example, just replace la…

What you're describing is all quite similar to how systemd operates. Your definition of "monolithic" seems to be that the components communicate with each other. My definition is that the components are difficult to replace. Systemd makes it easier to replace components, because the requisite interfaces are clearly defined.

MacOS is quite tightly integrated, it's what Apple does. Darwin is a bit different, as it's much more BSD-ish; with that I agree. But MacOS is a lot of stuff on top of Darwin and replacing any part of that would require tons of very MacOS specific code to do. Apple most definitely does not intend for their users to be able to replace logind or Aqua or pretty much any core service.

Probably a better way to phrase it would be to consided how much effort it'd take to run Aqua on BSD. You'd have to port basically everything that is MacOS. To me, that is what a monolithic system means.

Re: What “technical” concerns do I have with systemd?

#93
post #85

Earlier quoted context omitted.

>Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd. Do you have a source for this or is it FUD?

Before throwing such accusations, at least search Google or HN itself. http://lists.freedesktop.org/archives/systemd-devel/2014-May...

They're saying that after the kernel release with those features comes out they will make a release that depends on those features, not that the kernel and systemd must always be updated together.

Re: What “technical” concerns do I have with systemd?

#94
post #86

Earlier quoted context omitted.

>the developers are busy adding new features and don't care at all about old bugs. What old bugs are you talking about? the only old bugs I can find are fixed or non-systemd bugs that weren't cleaned up >They say if you're not using one of the latest kernels, tough luck. Where recent means at least 3.7, or 3.8 if you want Smack support. >certain problems with systemd will take down the whole system, and make it unboo…

I've been also using systemd since Arch switched over, I've discovered bugs and vulnerabilities. But the thing is, if you're happy with systemd and works well for you, great! I've seen this very prevalent attitude in systemd users, the less they know, more fervently defend systemd, even if they think it sucks, they tell you it's the best thing ever because they're using it, and they always have to use the best. Arch…

>systemd has bugs, just like every other program, but by being so intermingled with the kernel, the consequences are much worse.

WHAT? I thought systemd was flawless by virtue of being the creation of god-emperor Poettering. /s

>asserts that there are critical bugs that make the system unbootable

>asserts that changes to systemd break everything

>refuses to provide source

Why should I look for data to support your assertions? If there is any data supporting your assertions you should know where to find it already.

Re: What “technical” concerns do I have with systemd?

#95

Earlier quoted context omitted.

The Linux kernel is considered monolithic because all those modules run in the same kernel space, where they can all walk over each other and bring down the system. Systemd is not like that: its components run in separate processes. By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.

systemd's modules are interdependent and all require systemd to be PID1 in order to function. You cannot, e.g. strip out logind only and use it as a ConsoleKit replacement. Contrast this with a toolkit based approach like s6, which can run as init, process supervisor or both, and can have its tools that operate on process state be used independently. Another criteria is whether you can swap out one component without…

The journal is a bit of a contrived example though, it is pretty much the only mandatory part of systemd outside of pid 1 and you can still replace it, you just need something to fill the place of it and no one wants to put forth the effort to create some journald compatible rsyslog daemon because it would be mostly pointless. Also, if you really hate it you can still configure it to not even store run time logs by throwing Storage=None into the config file.

Re: What “technical” concerns do I have with systemd?

#96

Earlier quoted context omitted.

Network configuration. You don't need systemd to solve that, though!

How does systemd help with this? The networkd component is still underdeveloped and unfinished, and meant for container setups, primarily.

networkd is still under development but if you're running a version of systemd that has it, it's already very nice so long as you don't need wifi. Right now I'd recommend it over NetworkManager for users who don't mind config files instead of using a GUI if they have access to it. It just works and it's automatically triggered by udev right when the hardware appears on the bus and sets everything up without the pile of shell scripts that is the status quo right now.

Re: What “technical” concerns do I have with systemd?

#97

Earlier quoted context omitted.

Tightly integrated operational systems are painful. The article really says it all: > Linux is becoming the thing that we adopted Linux to get away from. It's just true in many more aspects than the one where this sentence is placed.

Most people now didn't adopt Linux to get away from something, its just the default server OS. (And not desktop).

That explains a lot.

And it's very sad: Linux won, thus Linux becomes everything it stands against.

Let's restart the cycle for the next 30 years. Maybe FreeBSD this time? Or is it time for a plan9-like system?

Re: What “technical” concerns do I have with systemd?

#98
post #55
post #42

Earlier quoted context omitted.

I'm in the same boat - I wind up in a situation where I find myself missing the features, stability, coherance, and integration of systemd at least once a week in my day job, where we currently use Ubuntu with upstart. For me, it's a combination of things: 1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph. 2. Proper service supervision. I've had ups…

systemd is less stable than upstart (and sysvinit, obviusly), "it lacks maturity" says the author. You've had several problems with upstart, but count yourself lucky, certain problems with systemd will take down the whole system, and make it unbootable too! systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one…

If you know of some old neglected bugs like you keep saying then point some out. I would love to see an actual source on something other than the constant made up retorts of "PID 1 now has an HTTP server" or "Now kernel panics display a QR code".

Re: What “technical” concerns do I have with systemd?

#99

Earlier quoted context omitted.

oh ffs

QR codes for kernel panics is actually brilliant, because it encodes the data which would otherwise just be serialized to screen in a manner that makes it portable.

That actually might be nice but don't get your hopes up, systemd isn't actually part of the linux kernel as some conspiracy nuts would have you believe. The systemd project can't possibly just add random stuff to kernel panics, all of that code is in the kernel, not userspace.

I think a little while ago there actually was some work done on making kernel panics display a QR code but I doubt it'll ever be merged in if it's even done.

Re: What “technical” concerns do I have with systemd?

#100
post #87

Whatever happened to the old unix philosophies of KISS, and if it isn't broken, don't fix it. Granted, as many other have pointed out, SysVinit definitely has its pain points and could use improvements, but there are some other init systems people can use without having systemd shoved down our throats. It's been a while since I've played with *BSD, but it might be the time to start seriously looking at it again. Or s…

debian is switching to systemd. the only big holdout i've heard of besides slackware is gentoo.
Post reply on HN