Live data from Hacker News

Systemd redux: The end of Linux

blog.lusis.org

161–170 of 464 posts

Re: Systemd redux: The end of Linux

#161
post #114

Earlier quoted context omitted.

I completely agree with you that Lennart scratched an itch, which is the way all good software gets started, and others picked up on it. Where I think the systemd-naysayers have a valid point is around the tight coupling that has been introduced, and is still being introduced, between systemd and various other components of a fully functional Linux system. To take your "just submit a patch" example - say N years from…

Well, the very distro-specific bunch of scripts in /etc/init.d (or is it /etc/rc.d/init.d/? or /etc/rc.d? or a symlink to ...?) were some kind of tight coupling, too. Plus: This tight coupling did not exactly replace existing communication features. It created new ones. These are made use of. Yes, systemd is bringing lots of new functionality. Under the hood - that is why sysadmins love or loathe it and users mostly…

Honestly, I can understand why people are uneasy about this. "Yes, tight coupling is being introduced in many core Linux projects, but don't worry -it's only these shiny NEW features you don't have anywhere else!"

Sounds eerily like "Embrace Extend Extinguish" redux.

Don't get me wrong, I am aware systemd is a technically superior solution. But politically, it is a trainwreck.

Re: Systemd redux: The end of Linux

#162
post #6
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…

People who aren't extremely familiar with how the Linux init system works and whose job doesn't include keeping the servers stable don't see why the neckbeards are up in arms about systemd, but there's good reason. Many peoples' jobs depends on making sure the servers are working, and knowing how the servers work is a big part of their job (and sanity). In its current incarnation, systemd changes the fundamentals of…

Servers is precisely where I want systemd!

There are some things I've wanted reliable and consistent mechanisms for so long: starting/restarting/inspecting services, isolation/resource limiting, socket activation, log collection.

Re: Systemd redux: The end of Linux

#163
post #9

Earlier quoted context omitted.

It's not the end of Linux. It's the final death of the idea that Linux should just idly continue to act like a clone of some vague Unix of old because it was better when men were men and their computers had obscure RISC processors with billions of registers. Linux hasn't really been that way for an incredibly long time, but a large proportion of the userbase still cling to this notion, some for ideological reasons, a…

Systemd is most problematic because of its own-everything monolithic nature, and the changing of kernel interfaces to match. The vast majority of Linux systems are not desktops, and probably not servers either. The kernel and the core utilities around it (like init) should be designed with multiple implementations and all machine types in mind. This means phones, set top boxes, TVs, routers, automation hardware, supe…

systemd makes a lot of sense for embedded systems:

* Embedded systems use watchdogs. systemd implements a watchdog supervisor chain, where systemd supervises applications, and the hardware watchdog supervises systemd.

* kdbus: efficient IPC

* networkd: simple network setup, very fast DHCP client

* fast boot times

* handles many complexities, so that embedded developers can focus on their application

Re: Systemd redux: The end of Linux

#164
post #159

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…

Are you really extrapolating from ONE data point? In some sense systemd is more stable in that it's fixing some longstanding bugs with sysvinit, but of course it will have some bugs of it own. If you don't want to deal with that, you could skip a release.

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.

There is a distinct lack of engineering prowess and quality control. It originates at the core GNU + kernel + freedesktop teams and waterfalls down through the distribution houses.

That's the problem and it's endemic within Linux.

Re: Systemd redux: The end of Linux

#165

Earlier quoted context omitted.

And if journald goes belly up, no logs for syslog...

And if syslog goes belly up no logs. What's your point?

You used have one component that needed to fail to start losing logs. Now you have two.

Re: Systemd redux: The end of Linux

#166

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.

Re: Systemd redux: The end of Linux

#167
post #55

>single parent hierarchy for namespaces Predictably, all the blame is laid at systemd's feet. The current churn is happening, because all of Linux's core developers (kernel and user space) are wanting that change...to push the envelope. For example, the current change in CGroup's namespaces are because kernel is mandating that the current cgroup access mechanism be deprecated. They want a single writer to Cgroups. Sy…

No. Rebuilding the entire userspace set of services to be a systemd cluster is not nice. It's essentially redoing the traditional Linux approach, which has worked relatively well for years. There are a number of things that could be split out and made more modular - c.f., uselessd for a more in-depth analysis. To be clear, I'm not claiming that SysV init is The Best Way. Shell scripts are not the Happiest Place. But…

[deleted]

Re: Systemd redux: The end of Linux

#168
I have mixed feelings about systemd: like many others, I've spent a lot of time with traditional Unix systems (25 years) and like the simplicity and stability commonly associated with them and familiar tools/conventions. On the other hand, OS X showed what a modern system built on Unix should feel and look like, while Linux never got anywhere near (not only on the GUI layer). If it takes unreasonable people to make progress (like in the famous G.B. Shaw quote), then let's sit back and see what happens. Perhaps Linux will shed more cruft and become simpler to develop for rather than harder.

Of course, I'm in the favourable position of not having to maintain/administer a bunch of Linux boxes for a living. I can fully understand the frustration of people who built and shipped custom solutions on top of SysV init.

The end of Linux? No, it's the end of Linux as a traditional Unix with lots of arbitrary optional features on top perhaps. We'll get used to it, or switch to something better.

Re: Systemd redux: The end of Linux

#169

Earlier quoted context omitted.

That's probably a wrong choice, too, for most Linux users (though there are some reasons a reasonable, and technically competent, person might choose an Illumos system, if you're doing it because a random crank on the Internet tells you to, you probably don't know enough to understand those reasons and the quite large tradeoffs you'd be making). Regardless, it's one example of many where the author exhibits a very po…

You realize that you're just talking in ad hominem circles? You acknowledge that there are reasons that a "reasonable and technically competent person might choose an illumos system"; is it as least possible that someone advocating that choice might not be merely "a random crank on the Internet"? And given that this is potentially a reasonable choice, how does advocating it represent "a very poor grasp of [...] every…

Yes, I find the whole article so full of wrong that I didn't think it needed more than simply calling it "wrong". Though seeing how many upvotes it now has, I guess I was wrong.

But, if you insist, let's break it down a bit:

"...FreeBSD...also ships with ZFS as part of the kernel and has a jails which is a much more baked technology and implementation than LXC."

Which is an assertion that would require significant citation and specification about the ways in which the author believes jails to be superior in order to be a useful claim. I believe it is an assertion based on ignorance of either Jails or LXC, or the ways those technologies have been used historically and are being used today. For most of the uses I see talked about on HN, LXC is the "more baked" implementation. While Jails has existed for a long time, it was not intended for the purposes we're using LXC for today in Docker and similar deployments. The tools exist, the resource management exists, for LXC and they don't, or are quite rudimentary for jails. To suggest someone choose jails where they are currently using Docker and LXC is to suggest they live with a large variety of limitations and pain points, and in a lot of cases to simply not do what they are currently doing, or to do it in wildly different ways. All to avoid the minor pain that is represented by SystemD for most users.

In short: Jails are not (currently) a reasonable alternative to LXC in that context, and it exhibits some kind of ignorance to suggest them.

Continuing on, despite your suggestion that he is talking about SmartOS or OmniOS, he quite clearly is not. He specifically mentions Solaris while mentioning the others as other options:

"Speaking of zones and Solaris, if that’s an option for you it’s probably the best of breed stack right now. Rich mature OS-level virtualization. SmartOS brings along KVM support for when you HAVE to run Linux but backed by Solaris tech under the hood. There’s also OmniOS as a variant as well."

That paragraph clearly is recommending Solaris, specifically. If you'd like to argue that Solaris is a reasonable alternative for most Linux users, it's a conversation I'm going to opt out of. I'm pretty sure we'd be speaking completely different languages.

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

So, CoreOS is the Linux option he recommends? The same CoreOS that uses SystemD? Indeed, was among the first distros to embrace SystemD with gusto. CoreOS, that is remarkably different than all other Linux distros. All because "Linux is becoming something different than it was"? So, in response to Linux becoming something different, he recommends people switch to something that is utterly different, like an entirely different operating system (FreeBSD, Solaris(!), etc.) or a Linux distribution that rethinks everything, not just the init system (CoreOS).

All to avoid something being different. It absolutely boggles my mind, and I have hard time responding with anything other than derision; for that, I apologize.

You're right that I haven't been particularly persuasive, and have been quite abrasive. This article just really rubbed me the wrong way.

Re: Systemd redux: The end of Linux

#170

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…

It hardly does anything for FreeBSD in the enterprise world. Companies cannot afford to support Windows Server, Linux AND another flavor of UNIX (FreeBSD). They are already dumping Solaris/AIX/HP-UX as much as they can so environments are a bit more homogeneous (and easier to support). There is no point in onboarding FreeBSD for what they perceive as minor technical differences (that, truth be told, are overshadowed…

I disagree.

There are very few heterogenic systems in the enterprise. That is an objective, but the main thing is that we deliver what we're paid to deliver by choosing an appropriate platform. We have Solaris, zSeries, Linux and Windows. We just got rid of AIX.

As for minor differences, FreeBSD has a lot of much bigger wins than people realise at first glimpse. The differences are far from minor. For example:

ZFS, dtrace, rctl, a scary good IP stack, virtio support, documentation that doesn't suck, a POSIX base, LLVM/clang, a MAC framework that doesn't suck, OpenBSM, CARP and a pile more. Oh plus an automated deployment story that is pretty tidy.

Sure we can replicate some of these on CentOS 7 for example with similar tech but the above are a million times more cohesive.

Post reply on HN