Live data from Hacker News

What “technical” concerns do I have with systemd?

blog.lusis.org

81–90 of 102 posts

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

#81
post #61

Earlier quoted context omitted.

What mystifies me in these systemd discussions is that systemd proponents always seem to think that "modular" is somehow the opposite of "monolithic," when it is entirely possible for a system to be both. "Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled. For example, the Linux kernel and X.org are both mod…

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 breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).

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

#82
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…

>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 unbootable too!

>you're continuously debugging systemd "modern innovations" instead of focusing on your product.

[citation needed]

I've been using systemd and systemd user sessions since Arch switched over and the only issues I've come across have been my own fault.

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

#83
post #59

Earlier quoted context omitted.

osx guy here. Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids. However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd. In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.

GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.

[deleted]

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

#84
post #79
post #59

Earlier quoted context omitted.

GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.

> Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd. I'm just feeding a troll or someone who is really ignorant, but here I go. No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland,…

And you don't have to update the kernel in sync with systemd

Quote from http://lists.freedesktop.org/archives/systemd-devel/2014-May...:

> > You update systemd but you don't update the kernel? How does that make > > any sense?

> > systemd and kernels are updated in lockstep (Lennart)

And it bears repeating again... systemd is not one single executable or process

https://news.ycombinator.com/item?id=8364318

Also, Vi, Python and Perl aren't "required" for GNU/Linux.

By that definition nothing is ever required. There's the same argument in my comment history, someone said, udev is not required for GNU/Linux. technically, chromium doesn't "require" blink. It's not required, you can use chromium and receive raw html, right? But in that case OSX doesn't "require" Python either, just delete the files, done :)

So again, I'm saying, I want a GNU/Linux system. (Yes, it's not required, I can install MS-DOS, HURD, HP-UX or Android.) That means POSIX, LSB... That's what 99%+ of programs targeting GNU/Linux expect.

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

#85
post #59

Earlier quoted context omitted.

GNU/Linux requires vi, perl, python... also as dependencies, but they're separate programs, the thing with systemd is that nothing can be separated, you use ALL components at the same time or change OS. Bear in mind that systemd is being integrated with the Linux kernel, so you have to update the kernel in sync with systemd.

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

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

#86
post #55

Earlier quoted context omitted.

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…

>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 is bleeding edge, if you've never seen a bug, you haven't been paying attention. So, again, you've never suffered a problem with systemd. Now do a web search, and in less time it takes to write "[citation needed]", you'll see that this is real. Sorry, but systemd has bugs, just like every other program, but by being so intermingled with the kernel, the consequences are much worse.

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

#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 switch to slack/debian and keep my old-fashioned init system.

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

#88
post #84
post #79

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. I'm just feeding a troll or someone who is really ignorant, but here I go. No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland,…

And you don't have to update the kernel in sync with systemd Quote from http://lists.freedesktop.org/archives/systemd-devel/2014-May... : > > You update systemd but you don't update the kernel? How does that make > > any sense? > > systemd and kernels are updated in lockstep (Lennart) And it bears repeating again... systemd is not one single executable or process https://news.ycombinator.com/item?id=8364318 Also, Vi,…

[deleted]

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

#89
post #30
post #20

Earlier quoted context omitted.

Was there even an argument presented in the section titled 'The invasion of “desktop linux”'? I couldn't find it. Where's the evidence that systemd is making design choices that are driven by desktop linux and detrimental to usage on servers?

There really wasn't. It starts off with: "I’m going to state up front (and people are free to disagree with me) that I believe you cannot provide a distribution of Linux that is both designed for the 'server' and the 'desktop' and provide a product that is worth using on either." I, uh, what? Someone let everybody know that, as I'm pretty sure all the popular server distros (I guess not CoreOS, but that's pretty new)…

> all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops

CoreOS is basically ChromiumOS minus the GUI. It'd be pretty easy to make a "desktop CoreOS" distribution by adding ChromiumOS components.

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

#90
post #84
post #79

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. I'm just feeding a troll or someone who is really ignorant, but here I go. No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland,…

And you don't have to update the kernel in sync with systemd Quote from http://lists.freedesktop.org/archives/systemd-devel/2014-May... : > > You update systemd but you don't update the kernel? How does that make > > any sense? > > systemd and kernels are updated in lockstep (Lennart) And it bears repeating again... systemd is not one single executable or process https://news.ycombinator.com/item?id=8364318 Also, Vi,…

Tell me, have you actually used systemd? Because you're completely misunderstanding the first two points as they're overtly not the case. Particularly the first point, as what it is saying is that they are willing to use newish features in the kernel, not that you are forced to always be running the latest bleeding edge kernel to have an up to date systemd.

The second point has some validity, but is a distortion. Of course you couldn't plug ConsoleKit in as a replacement for logind, because ConsoleKit was never designed for that. What you can do with logind is implement a simple compatibility layer with the standard systemd interfaces and then use it; this is what Ubuntu is doing. What is mandatory to use systemd's services is to implement its protocol for communicating between the services. This is why some of the services are "core" ones- because they're implementing the basic functionality common to the other modules. They can still be replaced, as long as the replacement obeys the same interfaces. This is however a problem for BSD, as the easiest way to use the systemd components is to implement the interface, but that does require features that are only present on Linux.

> By that definition nothing is ever required.

And yes, that was exactly my point. The term "GNU/Linux" is meaningless and doesn't require anything specific. What you might want out of a GNU/Linux system is probably totally different than what I do. You might want Emacs, but I'm a Vi guy. I don't want Emacs and you might not want Vi. How do we settle this? Committee vote? Mud wrestling?

Post reply on HN