Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

Post reply on HN
Print view View original

191–200 of 464 posts

Re: Systemd redux: The end of Linux

#191

Post by tormeh »

threeseed wrote: post #135
SwellJoe wrote: post #88

Earlier quoted context omitted.

Software maintenance matters. A lot. Particularly for networked systems. Also, it hasn't been Open Source in several years. That makes Solaris utterly irrelevant in my world. This blog post is suggesting Linux users move to Solaris. It's just a bizarre recommendation, made as an off-the-cuff assertion with no reasons given. Also, Oracle. What hacker chooses to be beholden to Oracle?

> What hacker chooses to be beholden to Oracle ? How about almost every single Java, Scale, Clojure etc developer. We are all using Oracle's JVM and they have been unquestionably a fantastic steward of the Java platform. I know the company deserves a lot of criticism but remember it is a big company with many different departments.

I don't know about clojure, but Scala ships with openjdk. It's possible to use the oracle JVM, but that's not default. They rely on oracle for bytecode/behaviour spec and not much more. Personally I'd like to see more bytecode effort being directed towards supporting non-java languages on the JVM, so I'm not saying the status quo is ideal, but it's not that bad.

Re: Systemd redux: The end of Linux

#192

Post by toolz »

microtonal wrote: post #177
bcantrill wrote: post #83

Earlier quoted context omitted.

Wow, great comment -- and one that all who endeavor to innovate in systems should take to heart. As my former colleague Bart Smaalders was fond of saying, "the hardest software to upgrade is the software in our brains"; when inventing new abstraction, it must be done so sparingly and (as much as reasonable) by leveraging extant notions. This isn't merely to allow a technology to be readily understood (though that too…

I think it is a perceived lack of this kind of humility in systemd that has been so alienating for those who have a long history with Unix: it's not as if other approaches are being rejected so much as they are not being considered at all. I really have the feeling that people are using double standards here, especially when suggesting Solaris or Solaris-derived systems. Since systemd is implementing pretty much what…

I want to know how this even became an argument in the first place.

It's not that I don't like systemd, it's that [insert affiliated party] is way too cocky

It blows my mind to see people regress so far back into arguments that this because an issue of emotions in a technical debate.

Re: Systemd redux: The end of Linux

#193

Post by badgersandjam »

moron4hire wrote: post #190
badgersandjam wrote: post #164

Earlier quoted context omitted.

No it's not just one data point. This is the final straw to use the old phrase. After a few years of serious problems, our most recent being CIFS VFS problems causing panics and mounts locking up on CentOS 6.5, hard locks on RH certified hardware, power management hell and so much incredible churn with no progress and the sudden "fuck POSIX" approach, it paints a really bad picture of the current state of things. The…

I caution you to not apply the word "engineering" to software, especially in the apparent manner you've been applying it to this thread. You seem to have an idea that there are universal software development practices that are so well understood we can make regulation around them. But that isn't how software works. There are some practices that are known and some that are unknown. For working software "engineers", we…

That sounds like an excuse which I don't accept. I have a formal engineering background and whilst you're fundamentally right, engineering is based upon cumulative experience gained. We have a hell of a lot of experience as a society of writing software that works and is of merchantable quality.

What the general state of affairs shows is the following traits:

1) There is no thought and research going into the design of a piece of software. Ergo, we do not learn from past mistakes.

2) There are isolated individuals writing vast swathes of software which are trusted unconditionally. Ergo, we do not learn the benefit of multiple eyes on a problem, review and discussion.

3) We assume that software is correct from one person's viewpoint and opinion. Ergo, we do not test software properly nor cover those tests with objectives.

4) We work to deadlines, not quality objectives. Ergo, we trade quality for tolerance from others.

In this case someone came along and didn't think about the problem, didn't work with others, assumed they were unconditionally correct and chose tolerance over quality.

To use your analogy, they're now selling stainless steel lightning rods (poor conductivity), are the only vendor of them, are a vocal marketing front and houses are catching fire everywhere.

Or more specifically, in one example, the entire process was above and from the author to the distributor, no one even noticed that loginctl doesn't work properly.

Re: Systemd redux: The end of Linux

#194

Post by matthewmacleod »

badgersandjam wrote: post #189
matthewmacleod wrote: post #181

Earlier quoted context omitted.

That's not the case though – systemd has been enabled by default by Fedora for three and a half years or so, and has been steadily adopted since then by most other major distros. Not everybody is moving at once, so why would waiting a year make any difference?

This bugzilla query against RHEL 7.0 systemd says otherwise: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&bug_s... A lot of the bug descriptions are quite scarily bad when you consider them in context such as "various loginctl commands not working" etc.

So what you mean is "Systemd still has serious bugs," which is nothing to do with whether or not everybody is moving at once.

That's the point – if systemd has important bugs they should be fixed. Clearly, the groups responsible for the decision have concluded that the tradeoff is worth it, and have accepted that a large, fundamental change will have issues. That's fine – there are a bunch of other distress you can use that have not adopted systemd, which you can use in the meantime if you disagree.

Re: Systemd redux: The end of Linux

#195

Post by badgersandjam »

nailer wrote: post #186
badgersandjam wrote: post #95

Earlier quoted context omitted.

I had no opinion on systemd until yesterday. In fact I had a glace or two at the code and it's pretty clean and I liked the rough objectives laid out. I installed CentOS 7 on a machine last night that we're replacing CentOS 6 on and was poked in the face with timedatectl and dbus problems for an entire hour, some of which were intermittent. Debugging these issues is a horrific pain. I lost 4 hours on it. I've never l…

I installed CentOS 7, with no prior systemd experience, had no problems and found .service files way neater than sysvinit bash scripts and liked having meaningful names in the log/ journal rather than 'local3'.

I had no problems the second time as well.

Unfortunately when the first and second time differ even though identical (recorded) steps were performed, one has to ask the question: why and can I trust it?

Re: Systemd redux: The end of Linux

#196

Post by pdkl95 »

rythie wrote: post #166
AaronFriel wrote: post #80

Perhaps this is a controversial idea, but is this not just someone finally taking the tried and true Open Source "advice" to heart? That is, every time I've reported something is broken, wonky, doesn't work reliably, et cetera, I've been told, "Submit a patch.", "Write some code.", or worse, "Implement it yourself." Someone finally got fed up with the haphazard state of affairs in Linux-land. Fed up with the fragment…

You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.

Not only would submitting a patch be agreeing to their goals (Lennart gets to push the Overton window a bit further), suggesting that we should simply submit patches presupposes that the systemd cabal would ever accept them. Unless it is perfectly in agreement with their goals - including the complete software - they probably won't accept it. They don't even accept already written and tested patches for trivial things like #ifdef-ing a couple minor fixes so the project can build on a different libc.

Lennart Poettering[1]:

    Humm, I know this will disappoint you, but we are not particularly
    interested in merging patches supporting other libcs, if those are not
    compatible with glibc. We don't want the compatibility kludges in
    systemd, and if a libc which claims to be compatible with glibc actually
    is not, then this should really be fixed in the libc, not worked around
    in systemd.
If they aren't interested in trivial compatibility patches, they certainly aren't going to accept any patch that dares to disrupt their tight integration or questionable design choices.

As for forking the whole thing, remember that logind was briefly liberated so it could be build as a standalone package, Lennart went and did a big rewrite so the next version was much more integrated with systemd. When he controls the internal APIs and can change them whenever he wants, a clone will have to be a total replacement right from the start, or it ends up perpetually having to catch up to the changes that will be introduced just to cause breakage.

[1] http://lists.freedesktop.org/archives/systemd-devel/2011-Jul...

Re: Systemd redux: The end of Linux

#197

Post by vidarh »

matthewmacleod wrote: post #105

Really bored of this nonsense at this point. Take this for example: If you absolutely MUST run Linux, my recommendation is to minimize the interaction with the base distro as much as possible. CoreOS (when it’s finally baked and production ready) can bring you an LXC based ecosystem Systemd is absolutely key to how CoreOS works. It's the basis for the distributed init system it provides — a major selling point. Takin…

I agree with that specific advice (minimize the interaction with the base distro). I'm on a quest to isolate every major component of my user experience in containers (including things like browser etc.).

But not because I have anything against Systemd. I love Systemd so far.

It's hilarious that he's proposing CoreOS as an alternative, given that it's one of the most radical rethinks of a Linux distro out there.

Re: Systemd redux: The end of Linux

#198

Post by vidarh »

pdkl95 wrote: post #196
rythie wrote: post #166

Earlier quoted context omitted.

You can't realistically submit a patch to change the direction that Systemd's is going in. For example, they won't accept a patch which removes 95% of the code, so a more modular system can be built. Submitting a patch, implies you agree with the general direction but need a bug fixed or a feature added.

Not only would submitting a patch be agreeing to their goals (Lennart gets to push the Overton window a bit further), suggesting that we should simply submit patches presupposes that the systemd cabal would ever accept them. Unless it is perfectly in agreement with their goals - including the complete software - they probably won't accept it. They don't even accept already written and tested patches for trivial thing…

His response seems perfectly reasonable to me - even more so after reading that whole exchange.

Why should the Systemd team pay the overhead - in terms of complicating their code - to work around incompatibilities in another libc that will also affect portability of a lot of other Linux software?

Re: Systemd redux: The end of Linux

#199

Post by zvrba »

ratboy666 wrote: post #60
api wrote: post #2

One thing I've realized about the Linux community through all this systemd flame warring is how unbelievably conservative a large subsection of it is. There's this huge so-called "neckbeard" continent that views anything architecturally beyond the 1980s as a huge affront to Unix. IMHO I kind of shrug at this, since Unix was never really all that great to begin with. Unix won because the only commercially viable and w…

http://thorstenball.com/blog/2014/11/20/unicorn-unix-magic-t... is also a current story on HN. Just an example of how powerful that simple 70's Unix is. Allows features that appear "magical" to thorsten, anyway. Windows? Wasn't really even an option... until 20 years later. And, of course, Unix really isn't that good, either. But, before you ignore it, please come to feature parity, at least.

> Windows? Wasn't really even an option... until 20 years later.

Which 'Windows'? Before Windows 2000, there was Windows and Windows NT, the former being a more-or-less just a shell running on top of DOS.

Re: Systemd redux: The end of Linux

#200

Post by moron4hire »

badgersandjam wrote: post #193
moron4hire wrote: post #190

Earlier quoted context omitted.

I caution you to not apply the word "engineering" to software, especially in the apparent manner you've been applying it to this thread. You seem to have an idea that there are universal software development practices that are so well understood we can make regulation around them. But that isn't how software works. There are some practices that are known and some that are unknown. For working software "engineers", we…

That sounds like an excuse which I don't accept. I have a formal engineering background and whilst you're fundamentally right, engineering is based upon cumulative experience gained. We have a hell of a lot of experience as a society of writing software that works and is of merchantable quality. What the general state of affairs shows is the following traits: 1) There is no thought and research going into the design…

Wait, so let me get this straight. You're an engineer-engineer, not a system administrator or a software developer. And you think there is a fundamental problem of qualification in software development, yet you lack qualification in software development.

On your points:

#1 is patently false, to the point of being extremely insulting. You've lost all sympathy from me at this point. Go peddle your baseless opinions somewhere the audience doesn't know better.

#2 is also laughably false, as that is the entire freaking point of open source and often considered the greatest strength of Linux. You think because your highly qualified opinion wasn't consulted before you had to spend a whole four hours, OMG on a problem that means that no review or discussion was done?

#3 is false again, because software is tested. You use the word "properly", so I will sit here and wait for you to bestow upon us your great wisdom on what we could be doing better.

#4 is false on both presumptions that software is not built to quality standards instead of deadlines, or that other fields are not dictated by deadlines.

Post reply on HN