Comment by dredmorbius | Hacker News Reader

Comment by dredmorbius | Hacker News Reader

Linus Torvald's commnt provides some additional context (on the link above):

I think what you (and others) seem to miss is that the systemd people made the "debug" option that we introduced not just do something - but do something useless that actively broke other peoples use of that option.

It doesn't matter who "owns" it, the fact is, they broke it.

Ok, fine. Bugs happen, and that's not what makes people upset.

What makes me (and others) upset is that when the bug is reported, with explanations and a suggestion for how to fix it, Kay just closed the bug-report, claiming it wasn't a bug.

Seriously? You want to debug kernel stuff, using the kernel command line command "debug" that makes the kernel more verbose, and now the systemd people say "sorry, we stole your thing and made it useless, and it's not a bug because you didn't call shot-gun".

Now, if this was an isolated incident, I personally would let it go. There are bad engineers out there, it's not worth worrying about. Ignore them and move on.

But this is not an isolated incident. This is how Kay has treated other bugs in the past. Literally months of stalling, closing bug-reports, and blaming other people and projects for problems that he caused, telling others how they should change their projects because he broke something, and obviously it can't be his fault.

And that is a problem.

I'll openly admit I'm not a systemd fan. I've seen too much brokenness from the developers involved, in this and other projects. I've seen far too much arrogance. I see too much complexity. I'm quite disappointed in both the Debian vote and Ubuntu's decision to go along with it (I was really hoping that Shuttleworth would hold out as loyal opposition). Yes, systemd does provide some useful features, but at an extremely high cost in complexity and unproven changes to a system at the core of every last Linux system. Emphasis on "Linux", as it's also not cross-compatible with other OSes on which many Linux programs will run, and on which some distros (such as Debian) provide builds.

I'm still mixed on systemd. My favored distro, Arch, switched to systemd well over a year ago, and is currently the only supported init system. It works fine for me, but I don't do a lot of complex sysadmin tasks. To be honest, I haven't even learned the unit file syntax yet.

I do find Lennart's software to have godawful UIs and APIs. I dare you to write a simple audio output program using the PulseAudio API. Let me know when you've got the threading, mainloop, and callback APIs figured out so you can write your sine wave...

The command to interact with systemd is not 'systemd', but instead 'systemctl' (which is not 'sysctl'!). Systemd has units and targets which can be enabled and started and disabled and stopped (what's the difference again? off to the man pages...). systemd is trying to replace /var/log and cron as well, but damned if I can remember the right four switches to journalctl to make it do something useful.

On the other hand, systemd feels cleaner at a conceptual level to me. Apparently more competent sysadmins find the new journalctl idea to be super useful--it provides a consistent window into log files, so you don't have to remember varying paths and log file formats and such. Service unit files allow for complex dependency resolution for service startup, far more powerful than the old symlinks-in-etc or rc.conf files allowed.

It feels like the right solution to me. I just wish it was more intuitive to use.

I've found systemd to be fast and stable on Arch. There's a learning curve associated with a new way of doing old things. That doesn't bother me that much because this is how progress happens.

What I find far more disconcerting is that systemd seems to eschew core Unix philosophy (http://www.faqs.org/docs/artu/ch01s06.html):

This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface.

Systemd does none of these. Well, maybe it works with other programs... it really feels like it's own world.

That philosophy, which has many merits, was nonetheless a virtue forced by necessity. UNIX(TM) is Multics with, as the name implies, various important features ... omitted in squeezing down a big system, for a multiple 32 bit CPU mainframe architecture, to minicomputers. The first PDP-11 they used, which was not the first PDP model used, was the original, later named the PDP-11/20, which had 56KiB maximum of memory (above was reserved for memory mapped devices, an innovation of the architecture).

The 2nd, where they really got going, was the PDP-11/45, which allowed any one program 64 KiB of code and the same of data, but due to its paging architecture the data was divided into 8 KiB of stack and 56 KiB for normal user data.

So now that we use computers with as much or more L1 and L2 cache, we can, if warranted, ignore that philosophy. Don't know if that's the case here, the gravamen is that systemd's development team is grossly irresponsible. Which could be reflected in its architecture, but even if it was more in the traditional UNIX(TM) philosophy, their being that way would be as bad.

I just hope the next version of Debian is not a disaster, would not like moving off of it, not that I'm entirely satisfied with it.

So wait, some geniuses came along and banged out the OS of the future, in the smallest purest form they could, and now decades later, just because our computers have improved, you think it logical to ditch the philosophy that got us here???

More like "some geniuses came along and banged out an OS that would suit their needs on the limited hardware they had on hand"

The philosophy applies no matter how much hardware you have.

Not going to directly reply to the reading comprehension impaired, but my point is that part of the philosophy was required.

To print technical papers to a phototypesetter, one of the first use cases for which the UNIX project got serious funding, required a pipeline so that, as I remember, tables, equations and basic formatting were all separate programs piping their output to the next, with troff at the end (as I recall, I only used nroff in one step to a Xerox daisy wheel printer for one paper before I moved to Scribe and then TeX to a laser printer). No one single program doing all that could fit into the 11/45's split I&D address space as described above.

Now we can and have made individual programs bigger, but the philosophies of doing a limited number of things well and communicating by plain text are still very solid for many applications (but, not, say, many of the use cases of Photoshop/GIMP etc. Or a browser. Or (in)famously, the linux kernel itself).

How much they should apply to system initialization and daemon management etc. I just don't know, haven't examined the issue. Not entirely, I would hazard a guess, certainly nothing I can think of that looks like the chain ending in troff. That the creators of systemd are reported to have ignored this philosophy does not automatically make it bad.

Their reported consistent bad behavior (from people I know and trust, at least in the case of Ted Ts'o) would seem to make it automatically problematical. That Linus felt compelled to revoke this person's kernel commit privileges (https://news.ycombinator.com/item?id=7522791) is also telling.

Or let's put it this way: a program like systemd must, by definition, "play well with others", that's its job after all. That main developers can't do that in the real world is a very bad sign.

There were lots of other people banging out lots of other OSes. I've worked with many of them (S/360 and successors, VMS, S/400, CPM, among them).

What Unix had going for it wasn't getting started, but getting adopted. For a number of reasons, but among them two key advantages:

• It could be adapted to other architectures. That is, it was portable.

• It could be extended. Most particularly at UC Berkeley and MIT.

The simple-at-the-core bits certainly helped.

But before that a lot of universities paid $800 (call it $3,000 in today's dollars) for a tape and site-wide license, and ran it on relatively cheap PDP-11s. And I've heard one or more of the team, perhaps before that, would travel with an RK05 disk cartridge seeding copies.

Tapes shipped "from Ken, with love" are part of the legend.

Another significant factor was the 1950s consent decree under which AT&T operated, which prevented it from going into the computing business, as well as the lack of an explicit recognition of copyright for software. Effectively, AT&T couldn't sell Unix, even if it wanted to, so it had to give it away (or charge no more than the media fee for it).

This all changed after 1984 and the break-up of Ma Bell, giving rise to the UNIX Wars, Free BSD (1-800-ITS-UNIX!!), Minix, and a longing for the days when small furry creatures from Alpha Centauri were real small furry creatures from Alpha Centauri.

NB: Richie and Thompson did their development on the PDP-7, not the PDP-11, though the latter was an exceptionally popular system to run Unix on later (and was my first exposure to it).

http://www.unix.org/what_is_unix/history_timeline.html

"The first PDP-11 they used, which was not the first PDP model used"

The path, as I remember, was a side project sort of thing with that PDP-7, then they started getting real money for the project, first for a PDP-11(/20), then a PDP-11/45.

Ah, I should point out that I think it wasn't until the PDP-11/45 that they could put a lot of memory on the whole system, with the kernel and each process potentially having the 64/56/8KiB code/data/stack address space. The total memory you could put on a PDP-11/20 was 57KiB, and while I don't know how much was on that PDP-7, Wikipedia says the total was 64Ki 18 bit words.

Right. The history link I posted shows much of the early HW history.

I posted my note just because your language wasn't quite clear. Though properly parsed, it makes sense ;-)

There are excellent reasons to ignore the UNIX philosophy. "Do one thing and do it well" is fantastic and resonates a lot with us, programmers. The truth however is that this is not how an OS works.

systemd does a lot of things because the systemd project is tackling a lot of issues on Linux. And as any of us will know and have experienced, when refactoring something it tends to be very cascading. So systemd has all these inter-dependencies with tools and concepts that the same developers worked on. systemd-logind, systemd-journal, systemd-networkd, kdbus, etc etc.

Here's a fact: my systemd-powered machines have never worked so well and completely out of the box! These guys are doing amazing work, they are making Linux into a very, very serious competitor with today's desktop and mobile (incl laptop) machines.

They are doing the dependencies too tightly, yes. They don't care enough about the possibility of other people reimplementing parts of what they do. But their actual achievements are incredible. I have a huge respect for what they do.

That said... I have very little respect for them. The ability to separate a person from what they do seems to be a rare quality this way, despite what everyone claims (what with the Brendan Eich issue and such). The fucking attitude in these projects is disgusting. And these people don't actually understand that they are universally hated for behaving like children over such stupid issues. They live in a different world.

And this is all just what you see externally. Internally, it's free-for-all retardfest...

Fucking human nature, man. I've never been so uneasy as in the last few weeks... I can swear things used to be better but maybe I can just see things more clearly now.

I don't disagree with what you say, but it feels like a lot more important issue than you describe it. The whole systemd thing was intended to rewrite some pretty complex stuff that works already, but as it turned out over time does many things wrong. And do it right™ this time. Keywords: "rewrite", "already works", "right". And I personally believe it's a good idea, because what is done wrong at low level produces more and more work, complexity and errors on higher levels. Very hard to achieve, but essentially good.

Now, the complex system with good API and architecture, but not-so-perfect internals is hard, but possible to fix and improve over time. System with bad API is essentially impossible to fix, ever. People that write optimal code without bugs, but terrible APIs and don't care about what others feel about that simply cannot "do it right™". Yeah, it may work well out of the box, but the progress goes on and after 5-10 years community will struggle to implement something new and important on top of that systemd and feel that only way to stop the pain is to replace it with some systemπ and do it right™, and people will remember 2014 year and say: "Well, we had that story with systemd already. It turned out to be no good! We'll make do without doing stuff right™."

Thinking about it I feel sad regardless it may work smooth out of the box at the moment.

I found systemd has a really good API tbh. What are your issues with it?

I've read the front page of systemd a couple times, but have not dug into the documentation much.

Can someone give a tl;dr of what it provides over the (brilliantly designed in my opinion) daemontools, or successors like s6 [1] and runit [2]?

I hear features like "socket activation", but can this not be implemented in a helper program?

I've been using s6 to manage some ruby apps, and I've got a primary s6-svscan to start a few things, one of which is a secondary s6-svscan that manages a bunch of resque workers. This makes it easy to start/stop all the resque workers in one go. And I can also allow non-root users to manage them via plain old Unix file permissions (s6 can be controlled by writing commands to a fifo).

[1] http://skarnet.org/software/s6/ [2] http://smarden.org/runit/

I've a feeling this started as a failure to communicate (and understand). The fact that systemd spews a stupid amount of stuff into dmesg when debug mode is enabled is a bug and the root cause of the problem. But the bug report mentioned that only tangentially and suggested a solution which didn't address the root cause of the bug, which would be fixing the debug spew. The argument then focused on the whole 'kernel owns the command line' issue and completely failed to mention that the debug spew bug had already been fixed (in systemd, and there is some work to add rate-limiting to dmesg).

Reply on news.ycombinator.com