Live data from Hacker News

Linux greybeards release beta of systemd-free Debian fork

theregister.co.uk

51–60 of 189 posts

Re: Linux greybeards release beta of systemd-free Debian fork

#51
post #48
post #34

Earlier quoted context omitted.

Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into indepen…

The thing is that the kernel, while large, has one defined purpose -- to provide abstractions of hardware resources and arbitrate those resources between programs -- and thus conceptual simplicity, even if the source tree is huge. The POSIX syscall API is simple and the rest is just implementation. In contrast, systemd is conceptually complex -- its scope continues to expand to manage every little nook and cranny and…

Really? How is it complex conceptually? The main concepts you really need to understand is that of units, and for that I found a very well written piece by Digital Ocean on the topic:

https://www.digitalocean.com/community/tutorials/understandi...

Aside from that, there are a number of services and utilities, but I'm not sure how they are conceptually harder to understand that any other similar program or utility on Linux...

Re: Linux greybeards release beta of systemd-free Debian fork

#52
post #34

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.

Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into indepen…

Modules worked. Fuse worked. DRI worked.

In kernel space, the global lock is gone, there is a central API that everybody else uses with code that mostly don't touch each other.

Linux is very modular. It is just not a microkernel, and that is probably more due to historical performance bottlenecks than to architectural concerns.

Re: Linux greybeards release beta of systemd-free Debian fork

#53
post #36

Earlier quoted context omitted.

It's ironic that one of the design goals (or was that just the marketing blurb) of systemd was "modularity".

Systemds molecularity is 'we'll write a systemd module to handle that.'

What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!

Re: Linux greybeards release beta of systemd-free Debian fork

#54
post #34

Earlier quoted context omitted.

Wasn't it? Multics was the modular system, Unix was the one where they said "That's silly, let's stick everything in a single kernel and not bother with all the flexibility because we don't need it." People seem to ignore the kernel for some reason, but it is literally one giant program to rule them all, and it works very well. There have been many efforts to modularize it and move most of the complexity into indepen…

Modules worked. Fuse worked. DRI worked. In kernel space, the global lock is gone, there is a central API that everybody else uses with code that mostly don't touch each other. Linux is very modular. It is just not a microkernel, and that is probably more due to historical performance bottlenecks than to architectural concerns.

It occurs to me that there is quite a bit of confusion around the terms "monolithic", "microkernel" and "modularity". The misconception is that a monolithic kernel isn't modular, which is very far from the truth.

Re: Linux greybeards release beta of systemd-free Debian fork

#55
post #30

No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so. I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more o…

I'm a tad confused... you cite that famous Unix philosophy quote "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together"... but I don't see how that doesn't apply to systemd?

Could you clarify?

Re: Linux greybeards release beta of systemd-free Debian fork

#56
post #2

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

> functionality That is, actually doing the work of init i.e. spawning daemons and services.

Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts.

It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.

Re: Linux greybeards release beta of systemd-free Debian fork

#57

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…

> sysvinit-script

OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy.

> I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts.

There are more options than sticking with Debian's ancient scripts.

The larger problem is that init is only a tiny part of systemd. Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel. Even if you like the init features of systemd, you should be looking at all the changes; do you really want to depend on all of systemd's features in the future? Do you enjoy depending on a moving target that changes at the whim of the systemd cabal and their reputation for WONTFIXing anything that they don't understand or haven't considered as a use case?

Re: Linux greybeards release beta of systemd-free Debian fork

#58

Earlier quoted context omitted.

> getting pushed around by end-user focus is way too unacceptable behavior why?

Perhaps because end users only focus on one thing, be it faster boot, or better service management, but are rarely well versed enough to understand the long term implications of using a monolith like systemd.

I might be one of those users. Could you explain what these long-term implications are?

Re: Linux greybeards release beta of systemd-free Debian fork

#59

Earlier quoted context omitted.

BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.

What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.

Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting to take effect in IT. Unix-like operating systems are supposed to be non-complex. My example above, of OpenBSD, is true. Maintaining OpenBSD systems is trivial compared to similar Linux systems, and I maintain both. Sadly, I admin a series of CentOS PBX servers that are an absolute pain. A friend runs his on FreeBSD and has less than half the pain points I do. And we're running the same PBX software.

I believe in lowest common denominator everytime. Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device drivers under Linux are now almost all binary blobs. You will not see this in OpenBSD, for example. The BSD folk reverse engineer the drivers and write their own free drivers -- and they are usually far and away better afterwards.

Take the wireless chipset drivers for Ralink. The BSD guys took a 30,000 line driver and rewrote the entire thing in less than 1/3 of the code. That's just the whole attitude between Linux and BSD. Linux is a series of cobbled-together hacks on top of an ever-growing, ever-complex kernel (that really needs legacy crap removed). BSD, on the other hand, is engineered as a single OS with a small collection of pruned base programs. Big difference. If you've ever used BSD, you will know the joy of /etc/rc.conf vs the nightmare of Linux config files that live in myriad locations depending on the distro.

Re: Linux greybeards release beta of systemd-free Debian fork

#60

Earlier quoted context omitted.

What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.

Aside from the binary logs, which are really not a great idea, systemd adds orders of magnitude more complexity to a system that really didn't need it. The init system could have been addressed without something like systemd. I'm old enough to remember and use Unix. Like a lot of IT guys my age, we all tend to think that adding complexity is wrong. This notion of one ring to rule them all mentality is really starting…

I'm afraid you still haven't answered my question. Aside from binary logs, what binary blobs are you referring to in systemd?
Post reply on HN