Slashdot Mirror

They don't use systemd, do they? At least not yet.

Use it?!?

Man, they INVENTED it!!! LONG before there was systemd, Apple had... launchd !!!

Way back in OS X 10.4-land. And they've been using THEIR "systemd" (launchd) ever since then, without incident.

Lance Potty-ring just fucked it ALL up for you guys, DESPITE the fact that Apple Open Sourced launchd and gave it to the WORLD!

https://en.wikipedia.org/wiki/...

BTW, launchd precededs systemd by 5 years:

https://blog.darknedgy.net/tec...

I disagree that systemd centralization of services is a good idea. That is exactly what got it into this bug, and there will be more.

But, regarding this:

At this point, the only real solution I can see is making a fork of systemd, banning the current systemd creators from participating in it, and trimming it to size.

Systemd has only two advantages:

1. Startup Sequence Dependency Management. A way to tell daemon X that daemon Y and Z have to start first.

2. An easier syntax. I myself don't mind shell script startup inits, but it seems that other do, perhaps the younger generation.

To that end, there is a solution that addresses the above two advantages, while abandoning all the other bad things about systemd, such as scope creep, swallowing all other services, ...etc.

It is called uselessd. It seems dormant at the moment though, but that is the right approach.

If systemd is replaced by uselessd, AND a given distro (e.g. Debian) allows for multiple init replacements, without a deep dependency chain (e.g. most Desktop Environments today), then I don't mind those who want systemd to remain as an option. The rest of us can just replace it with uselessd, or OpenRC, or anything else and everything works, and continue the UNIX philosophy of many components each specializing in one thing: do one thing and do it right.

Major or minor is irrelevant. What's relevant here is the design or rather the lack thereof. I could argue the specifics but I don't think you have looked at the code. If you actually want to know more about the design of systemd, here's a basic explanation of how it's core works.

I take it that you have not looked at the actual code, afaik there is no nasty web of dependencies. Where there are dependencies they are on a documented DBUS service and not on a specific pid 1 and afaik there are no inter-project dependency either.

Yeah, so a fork that tries to split the "applications" in systemd must be quite easy to produce. Or is it?

From Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise:

Despite its overarching abstractions, it is semantically non-uniform and its complicated transaction and job scheduling heuristics ordered around a dependently networked object system create pathological failure cases with little debugging context that would otherwise not necessarily occur on systems with less layers of indirection. The use of bus APIs complicate communication with the service manager and lead to duplication of the object model for little gain.

Further, the unit file options often carry implicit state or are not sufficiently expressive. There is an imbalance with regards to features of an eager service manager and that of a lazy loading service manager, having rusty edge cases of both with non-generic, manager-specific facilities. The approach to logging and the circularly dependent architecture seem to imply that lots of prior art has been ignored or understudied.

In my own words: it is an undebugable piece of shit spaghetti project. I'm pretty sure Cthulhu is in some way involved.

Perhaps because of your ignorance?

Structural and semantic deficiencies in the systemd architecture for real-world service management, a technical treatise

I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.

My point is that only the people with as much experience (not even skill, just experience) are able to even understand the issues.

Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too :)

I actually appreciate these because they are from people that really understand what they're talking about, it's refreshing.

One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.

I agree with this, my problem with a lot of opponents to systemd is not the fact that they have a different opinion, it's just two things :
- most of the time they don't understand what they're talking about and are just following a trend;
- those that are knowledgeable don't make enough serious work done to make a valuable competition to systemd;

The worse thing is that I understand the genuine flaws the knowledgeable people are talking about. They are trade-offs I think the systemd devs are well aware of.
I find them acceptable, the others find them not acceptable. We're in the exact same situation of Linux vs Minix or GNU Hurd, XFree86 vs the rest, DBUS vs other IPC tools...
Some people got the work done, it's not perfect, but it allows to make a useful implementation that can be improved later.
Other people have legitimate complaints, but are not doing any serious work, or let go when they realize that their high standards implementation would require 10 times more work to make sth useful. It's the real life world we live in.
Most of the anti systemd people don't realize that the problems systemd tries to solve, knowledgeable people have tried to solve them inadequately since 2 decades if not more. And some problems kept getting in, like the dynamic nature of the Linux kernel, which in itself caused a lot of shitstorms with devfs and the like before udev settled. These were the most painful migrations due to Linux kernel changes I ever had to do on my own made systems, and distributions maintainers must have been at huge pain since then.
Separation of mechanism and policy is a good thing, but the problem is that a distribution HAS a policy to withstand, which made the mess of hugely incompatible init, which in itself is not a problems for distributions, but one from upstream projects.
Systemd tackled lots of problems like these, it made some kernel Linux features prominent and simple to use (features that were rarely used before, and still not used in other init systems), improving the kernel by showing buggy, insecure or inadequate features (of course, as nobody used them, nobody noticed), some of them being huge problems for years (like mtab handling). For all that and more things (like improved security by default) that have nothing to do with systemd features, I thank the systemd devs.
That busybox removed support for the journal is not really a problem though, as if systemd is used with a busybox system (that's what I do in my LiveCD), the busybox syslog is not even used, there was no point in doing that.

Hmmmmm.......I don't think I'll be able to convince Lennart to come to a "Everything Bad about Systemd" hackfest lol.

Seriously though, I don't think systemd is the answer to an init system, but systemd has started to get a lot of competent people thinking about what a good init system should look like. See this for example. I don't think we're at the implementation stage yet, we're still at the brainstorming/exploration stage. It's a difficult problem, and a lot of people have come up with mediocre solutions. Eventually we'll come up with something good: that's the nature of open source.

If you're going to replace a system that's worked for decades, you ought to do a really, really good job of it.

I do that since 15+ years. I'm sure most seasoned sysadmins do the same as soon as they encounter one init script bug that breaks their OS.

I think you are underestimating your relative skill level. I know some system admins who are capable of that, but the vast majority seem not to be. I would guess you are in the top 10% if not the top 2% in terms of skill level. I see your point that writing init scrips is hard, and systemd will reduce problems from less-competent init writers.

Just like PulseAudio forced sanitizing lots of ALSA drivers, I guess systemd will at least force sanitizing init environments and weed out all these nonsense. At least I can hope.

Yeah, recently is that the systemd argument has started drawing some very skilled people in to discuss what a good init system would look like. Here's one example. And of course, you've commented in some of the discussions in my journal, and I would like to think they are the work of a very skilled person too :)

One thing I've noticed is that people who favor systemd almost all favor the features of systemd. Those who oppose systemd almost all oppose because of architectural reasons, or implementation details. So theoretically both sides could come together if an architecturally sound init system were created with features people need.

[...] Anyhow, if you've not seen this then this makes an EXCELLENT read:

http://blog.darknedgy.net/tech...

In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.

Seriously, thank you, your post is one of the best I've read on Slashdot, especially because you cite the ONLY really good (blog) post describing systemd problems I've ever read.
As the author note, not a single systemd opponent can articulate any specific problem in systemd, just general things that they attribute to systemd but can't understand.
This blog post is genuinely good, and from someone that actually understand what he's talking about (he's at least read some of the code in systemd).
The flaws of systemd are clearly explained, and even I being a pro systemd person, can agree completely with everything written there.
This is an essential read for any systemd proponent or opponent actually.
What it shows, is that you can do better than systemd, because systemd devs took the practical way, not the high standard one.
Basically, it's like systemd were Linux, and the alternative must be like Minix (or GNU Hurd), that's how I'd summarize what is written in the blog post.
Most of the flaws described in the post are shortcuts chosen by the devs (and the systemd devs are aware of them), just like Linus did with Linux, so as to provide an implementation in a reasonable amount of time.
Now, if you look at the state of Linux and the state of Minix or the Hurd, I personnally agree with the choice made by the systemd devs.
The competition just now has to start implementing and proposing their high standard alternative to systemd and stop the complaining that doesn't help anyone.
Some have started (s6 with OpenRC might lead to sth), but nothing usable is available yet. Instead, there's lots of red herring and bad mouthing systemd by the competition, making them losing their time in useless discussions. Things like "systemd didn't invent socket activation, it's not even really socket activation" (hint: we don't care, the functionality is provided and advertised, when it wasn't before, or the projects like inetd and xinetd went abandoned), "systemd didn't invent cgroups, you can use them with scripts" (hint: we don't care, nobody used them with sysvinit, and systemd uses them by default), "you can jail your processes without systemd" (hint: this is laughable, as it was so complicated to do, and even more to do right in shell scripts, that it was never done, or always done wrong, and wrong feeling of security is worse than no security), ...

I administer a whole host of Linux boxes and some of them are servers. Of course, that's just a half-rack leased for my own use and my own, personal, systems. Honestly? I learned a few new commands. Meh... It hasn't hurt anything at my end. I don't stray too far from the roost though, so it's pretty much out of sight and out of mind for me.

Of equal importance is to note that this reply is from someone who spends the vast majority of their time in userland (though, almost certainly, with a terminal open and usually doing something via remote). Also important is to qualify the below by reducing the importance to consider that I'm not to be confused with a professional. Having said that...

Truth told, I've not noticed it helping anything that affects my use patterns. It hasn't hindered anything, either. I've had nary a problem. I kind of want to fit in and say how I hate it, how it's not the Unix Way, and that it's too bloated, too complex, and the ruination of all the distros I know and love. Actually? Meh... I'm not really impacted, in the least. I guess it makes the dev's live's easier (for the distro packagers, at least) and I tend to donate to a few of them so, by extension, I guess you could say that I'm getting a bit more (theoretically) bang for my buck?

Mostly, I just watch and see what's going to happen next. Someone did a huge, academic-style, write up on it. It took me a minute to dig it out of my browser history on a networked box (long story - I'm still not home) but I was able to find it for you. I think, I'm not sure, it may have been on Slashdot? Anyhow, if you've not seen this then this makes an EXCELLENT read:

http://blog.darknedgy.net/tech...

In the end, I've concluded, I just doesn't seem to matter to me - yet. It doesn't really impact me. I'm sure that it does others but, for me, it just works. I want to hate it. I want to be in the cool crowd and rage against the evils of the domineering Red Hat and crew... I want to be enraged enough to key cars, throw bricks through windows, or at least post vile, spittle speckled, angry posts on the internet but it just hasn't bit me yet. Maybe when it does? I'll start my brick collection, just in case.

http://blog.darknedgy.net/technology/2015/08/26/0
Correct link

uselessd is dead. The last release was uselessd-8 on November 16, 2014. An effort to revamp the IPC system away from D-Bus into using a byte stream-based fifodir protocol was staged for uselessd-9, but a growing lack of interest and realization that trying to mangle the systemd architecture into something more minimal was becoming increasingly fruitless and unwieldy lead to the project being orphaned. It was transferred to Tarnyko in January 2015, but no activity of any sort has been seen since then. For all practical purposes, it's over.

I know parent was marked Funny, but uselessd is a very real thing: http://uselessd.darknedgy.net/

nobody has ever given an example of how to do this that doesn't involve keeping the systemd version at least installed on your system

The closest thing is probably uselessd (their site is apparently down temporarily). Not sure if that should be considered "keeping systemd" or not...

There's a list of specific issues (mostly not the vague hand-wavy complaints you're talking about) with systemd here.

Personally, I think uselessd should be getting a lot more attention in all this. (Their site is down atm, just a temporary provider issue I think).

Thanks systemd.

BINGO. In spite of Joey being on the 'winning' side of the systemd debate, his resignation seems to be a direct reaction to the schism that systemd has driven into the linux community. As someone far brighter than me said:

the systemd debate is rarely a technical argument for either side, instead it is an ideological and cultural war waged by two opposing demographics that inhabit the same general sphere of Linux and FOSS. This isn’t about technical merits, it’s about politics.

Read the whole piece. It's one of the best round-ups of the state of the debate.

(And by 'debate', I mean 'debacle' of course.)

You outlined your scepticism, thought processes, and the "general concern" standpoint that is so often lost in political vs. technical (or "politechnical") battles involving the "monolithic systemd" approach and I share your sentiments completely. Maybe that's because, like you, I'm an "oldish UNIX guy" (1990 and counting), and a lot of us have been around long enough to see the negative effects of "change for the sake of change" (which, in my opinion, systemd suffers greatly from); a lot of software today suffers from that driving force, so I shouldn't exclusively pick on systemd.

The author of uselessd said "many of the more technically competent people with views critical of systemd have been rather quiet in public, for some reason". The reason is that most of us in those positions do not have the time, energy, or interest to partake in long-winded uphill battles when our jobs, responsibilities, and lives tend to already be inundated with energy-depleting tasks; the last thing we need is to voluntarily enter into a near-religious debacle when we could just switch distros or flavours (e.g. Linux vs. BSD) and continue to do what we've done for a long time (and continue to do it well). Thus, our scepticism is justified -- we are not "against" change, we just don't make hasty decisions.

Is there scope for a less intrusive fork of SystemD?

OpenRC + Init seems to be the commonly referenced replacement. UselessD seems to be a more reactionary replacement, which is also often mentioned. I still can't see what's wrong with init scripts :)

Can one expect a re-write of all these daemons by a small team with no history of working on these applications to be anywhere near free of bugs?

Not likely.

One of the defects constantly levelled against systemd is its propensity to corrupt its own system logs, and how the official response to this defect is to ignore it. The uselessd page has a link to the bug report in question, which was reported in May 2013 and, over a year later closed and marked NOTABUG. However, it seems Mr. Poettering is getting annoyed by people using his own bug reports against him, and added a comment to the bug report today purporting to clarify his position.

Unfortunately, his "clarifications" serve only to reinforce my suspicion that systemd is a thing to be avoided. To wit:

Since this bugyilla [sic] report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

Well, yeah, corrupt logs would be regarded by many as a major bug...

...Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.

Okay, so freeze the corrupted data set so things don't get worse, and start a new data set. A reasonable defensive practice. You still haven't addressed how the corruption happened, or how to fix it.

Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.

Okay, so journalctl tries to be robust, assumes the journal data might be crap, and works around it. So we can assume journalctl is probably pretty solid and won't make things worse.

Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!

....Uhhhhh-huh. So, yeah, newer tools will do a better job of working around the corruption, and we'll be able to recover more data, assuming we kept known-corrupt logs around. But what I still don't understand is WHY THE LOGS ARE CORRUPT. And why aren't there log diagnostic and analysis tools? If you already know your logs can turn to crap, surely there are structure analysis tools around that let you pick through the debris and recover data that your automated heuristics can't.

And why do I get the feeling that implied in the above is, "You don't need to know the log structure or how to repair it. We'll write the tools for that. We'll release better tools when we get around to it?"

File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.

....AAAAnd you lost me. Seriously, this is your defense: "Filesystems are more important than system logs, so they have to try harder?" I find this insinuation... surpr

Few people want systemd at all. Why it is being forced on us?

If you don't want to use all of Lennart Poettering's code, you can choose to use less.

Which is why I don't see a systemd fork as a viable alternative. The whole idea is broken, as it breaks with the Unix toolbox approach, where tools work independently, and not as a clusterfuck of apps that engage in social networking under the dictatorship of an object-oriented leviathan. ... Give me an init that only does init and does it well with a KISS philosophy.

Try reading the project site, because AFAICT it meets your requirements. They've removed pretty much everything except for init, including journald and udev.

Then you will be delighted to learn that, according to uselessd website, they dropped udev and systemd-udev and any dependency to it. They also dropped logind, journald (i.e. no idiotic binary logs), all of the fuckingd retardedd crapd.

Besides, they give clues (if not full explanation) about which existing third party programs you can use to achieve everything that systemd tried to replace.

In other words, they keep only what you asked for: the init part.

We’re opinionated and socially maladjusted dwellers who lead monotonous lives and are trying to bring some variety in our existences by seeing if we can win a Darwin Award, or at least rustle your jimmies.

I'm in.