Linux Mint Will Continue To Provide Both Systemd and Upstart

jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.

Comments

The pain isn't in the switch

[Anonymous Coward]

it's in trying to resolve problems later on, when you'll find that systemd helps you obscure the source of the trouble instead of resolve it.

Re:The pain isn't in the switch

[Antique Geekmeister]

It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.

Quoting from the b log at http://0pointer.net/blog/proje...

> A Stateless System goes one step further: a system like this never stores /etc or /var on persistent storage, but always comes up with pristine vendor state.

That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in /etc or persistent data in /var/lib. They're basically taking all the daemon specific parameters from /etc and putting them in /run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in /var/lib or configuration in /etc will have to be rewritten, including long-standing conventions such as /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf.

Re:The pain isn't in the switch

[gbjbaanb]

a system like this never stores /etc or /var on persistent storage

including /var/log?? Well, I suppose that's one way to hide the fact that systemd's logs get corrupted.

Re:The pain isn't in the switch

[squiggleslash]

IIRC these "binary" logs you speak of are simply text files with indexing information attached. They're not encrypted or compressed, you can, at worst, use the "strings" command to pull the information, and if you're doing raw sector dumps from a hard drive then you'll be able to read them there too.

Of course, if the log files are zero'd out, like the bug report you quote, then it doesn't matter whether they're "binary" or text, you're screwed. That has nothing to do with systemd.

Re:Year of the Linux

[jeremyp]

Linux is merely the kernel used by systemd. The correct name of the operating system is systemd/GNU/Linux.

Are the "GNU" and "Linux" parts still needed?

[Anonymous Coward]

I've been learning more about systemd lately, and I'm liking what I'm seeing. It's cohesive, yet it's completely modular. It's modern. Its binary log files make debugging easier. It's getting more and more critical functionality every day, and this makes my Linux system easier to use each time I update it.

The deeper I dig into systemd, and the more I use it, the more I question why we even need the GNU utilities and the Linux kernel.

I hope to see the most useful parts of the GNU toolchain and the most useful parts of the Linux kernel folded into systemd eventually. This way I don't have to install a Linux distro. I can just install systemd itself, and it will give me everything I need.

If my computer boots directly to systemd, and systemd provides the command line tools and the UI, then my boot time will be shaved down to almost nothing, and I'll get to use some really nice and modular command line tools. I won't have to try to remember awkward shell, sed, grep, and awk commands and their flags, because if systemd provided alternatives, I know they would be easier to use.

I've found that systemd is all about empowering me, as a user. It's about letting me get more done with less effort. GNU and Linux aren't always about that. They're about doing things for philosophical reasons, or for scratching an itch of their developers. Systemd is all about getting work done, which is why I've found it to be so useful. If it can do the things that the GNU toolchain and the Linux kernel are doing, but it can do them better, then I'd prefer just to use systemd directly.

Re:Are the "GNU" and "Linux" parts still needed?

[Anonymous Coward]

Take note modern shitposters. This is what a good troll looks like.

If everyone who wants to derail a discussion would put in as much effort as this the Internet would be saved.

Lennart Poettering is cancer on the face of Linux

[Anonymous Coward]

systemd is an abomination.

Linux's benefit for a long time now has been the ability to swap functionality out you don't like for other functionality that you do. I don't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues, written mostly by a developer who has a track record of making extraordinarily poor choices in software development and writing poor code.

What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system. What's even more stunning is that Lennart didn't stop them, realizing his code was not appropriate in production environments and doing the responsible thing, which is to say "We're far from ready". systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".

For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.

Lennart likes to whine about how much the community hates him and how much people take it out on him personally. Reality is that outside of a few people who take it much too far, the reason people don't like Lennart is because he makes poor decisions with poor forethought and his advocacy and arrogance for his own approach have a seriously negative effect on a great many people, enterprises, and efforts. He likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.

The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.

I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
I hope it comes sooner rather than later.