I think this is really cool, but calling it a "systemd replacement" feels like click bait to me.
Systemd manages a huge number of things, and this doesn't even reap zombies, which all good init programs do. It doesn't support run levels, it doesn't support "resapwn" (for getty processes) -- hell feature-wise this isn't even a legit replacement for SysV init.
Having said that, I think this is a neat idea, and it'd be cool to have an emacs server process as a true pid 1 init, and when you SSH or go to the virtual terminals you'd get an "emacsclient".
Saying that something is not a systemd replacement because it does not do x feature that systemd does misses the point that systemd does too much. /sbin/init can be simple, and written in any language, and when it is, its often better than systemd because of that.
If software supports start but not stop or restart or enable disable as both systemV and systemd do, its still a fully functional systemd replacement if your context does not need those features
> Saying that something is not a systemd replacement because it does not do x feature that systemd does misses the point that systemd does too much. /sbin/init can be simple, and written in any language, and when it is, its often better than systemd because of that.
If someone tells me something is a systemd replacement I don't take it as them telling me it is an init system. If it is an init system unrelated to systemd don't call it a systemd replacement.
Are you talking about systemd the project or systemd the init?
I have heard lots of complaints about journald or this and that other project under the umbrella, but you are the first person I hear complain about the init part.
Linux has become so versatile and powerful, but I miss the days of simple OS’s. I used to be a Unix OS architect and would study kernel code professionally while working on virtual memory systems, distributed file systems, and so forth. Linux has gotten so big now that I don’t think I’d have the energy to dive into the kernel code anymore.
The KISS Linux distro looks interesting because of it’s extreme focus on simplicity.
Looks curious, I'd love to try it, I always wanted a system which wouldn't run anything I don't need (e.g. I never need Avahi or Samba, I don't need a user manager and would love to startx, I agree to sacrifice boot speed for simplicity - waiting a minute is ok for a desktop PC to start if you get something as valuable as understanding your system in exchange). That's a pity it doesn't have binary packages - building everything I need from source is going to take too long. I also doubt everything is going to work without the D-Bus. AFAIK many apps also fail to work with musl, and busybox might not include all the features of the classic GNU tools I may occasionally need. So I wish there were a slightly less radically simple Linux distribution.
PS: and I hate sh (as many others probably do), everything-LISP would probably be more fun.
Have you tried Arch? It has binary packages; GNOME, Avahi, Samba and similar basic but non-essential packages must be explicitly installed; the package manager is ridiculously fast; and it’s usually easy to install proprietary blobs and other unsupported stuff using the huge user package repository, if you’re comfortable with the associated risks.
I used Arch during the days before it switched to systemd (and before Ubuntu introduced Unity) and enjoyed it until I have accidentally found out Ubuntu feels faster on my PC so I switched to Ubuntu.
Once Ubuntu switched to GNOME3 I have switched to Manjaro (with KDE5) and I really love it (it feels like the perfect spot between Arch freshness and reasonable stability - you still get the fresh stuff reasonably fast but they test it before that so it's much less likely for an update to ruin your system) but I don't know how to get rid of Avahi:
:: removing avahi breaks dependency 'avahi' required by geoclue
:: removing avahi breaks dependency 'avahi' required by gvfs
:: removing avahi breaks dependency 'avahi' required by kdnssd
:: removing avahi breaks dependency 'avahi' required by libcups
:: removing avahi breaks dependency 'avahi' required by mpd
:: removing avahi breaks dependency 'avahi' required by nss-mdns
:: removing avahi breaks dependency 'avahi' required by ostree
:: removing avahi breaks dependency 'avahi' required by pulseaudio-zeroconf
:: removing avahi breaks dependency 'avahi' required by sane
i.e. I certainly need CUPS (to have a virtual PDF printer) and it depends on it (and I don't even know what 2/3 of the rest of the packages listed do). It is also very much possible the situation is the same on Arch.
Also, I don't really mind systemd from the practical point of view but the actual idea we were speaking about is having a simple, intuitive init system, which systemd is not.
> A fully free, stable, secure, simple, lightweight and long-term support distribution
The first, second and the last attributes make a kind of distributions I am really (really!) glad they exist but, unfortunately, am hardly going to use because from the real life perspective this means your hardware is not going to work, you won't be able to read common file formats and you will be limited to ancient version of software.
It's nice, simple, boots fast. Uses runit as init. The package manager, XBPS, has a funny name which I always misspell, the tools are separate like legacy apt-get, apt-search etc and it's CLI is a bit like pacman's, as in not quite the user friendliest. Package number is comparable to alpine. It's probably a bit like a modern Slackware.
You can install vanilla kernel and firmware. It won't ever be in the official repos, but the needed configuration is relatively simple and easy to google.
Wayland is just a vastly simpler architecture compared to Xorg, enabling lower redraw latency and tighter control of the display hardware on modern hardware (as in: systems where the GPU rather than the CPU computes the actual colors of pixels).
Those concerns are more important for graphical desktop environments, not so much for terminal multiplexers [1]. Therefore most existing Wayland compositors are focused on conventional desktop users. People with a "I just need a bunch of terminal windows" mindset will look at these and complain about bloat, but it's not really bloat to be able to play games without screen tearing (an issue that I always had with Xorg and that's just gone with Wayland). And it's not bloat to be able to play audio in Firefox either (Firefox afair only supports PulseAudio).
[1] Referencing the old 90s joke that Xorg is just a graphical terminal multiplexer, since the average Unix user mostly just uses it to have multiple terminal emulator windows open at the same time.
Nothing is particularly simple about X11, especially in its modern incarnations. It's much simpler to have an API that maps cleanly to what the hardware is actually doing, which is what Wayland is.
You can still prefer X11 for its features, like network transparency, but it is more complex than Wayland.
Check out OpenBSD. It gives me that old Linux feeling before it became corporate infrastructure. The code is not bloated like Linux so you can actually contribute as an individual.
It is not. You are really dismissing his original point that the contribution is made difficult because of code bloat. I have a hard time believing this is easier than ever, as 20 years ago the code must have been simpler.
Are we talking about the kernel or the entire distro?
Let's look at one of the favorite whipping boys from uninformed folks claiming linux systems are now bloated: systemd.
In many ways the consolidation of various disparate userspace components that occurred with the advent of systemd has substantially simplified the task of contributing to anything it covers.
There's now a mono repo encompassing a huge swath of the core of userspace with far less code duplication than we used to have in the bad old days where every little component was a snowflake project managed by its own respective cabal with its own mailing lists (if you're lucky) and its own ideas of how configuration files should be parsed, services installed/enabled/run, and generally a huge snowflake pile of redundant functionality.
Anyone with basic C knowledge now can clone the well organized repo and in very little time be reading and modifying code in a DVCS, and with systems and processes like git and github in place you can have your first patch up in the form of a reviewable and upstream-mergable PR in under an hour, without anyone else's involvement!
If you don't think this is has all lowered the barrier substantially for individual contributors interested in understanding, modifying, and contributing changes to the code underpinning their systems, you simply have no idea what it used to be like.
>its own ideas of how configuration files should be parsed, services installed/enabled/run, and generally a huge snowflake pile of redundant functionality.
Wouldn't there have been a different possible way of tackling this issue tho? Some framework group setting a standard for config file parsing, etc and then compiling a list of component(s) that fit these definitions?
It used to be that things like sysvinit were a handful of sourcebfules that you could read and understand in a few hours. Now you must wade through 500.000 lines of code to find what you're looking for.
I've yet to find this makes things that much harder to find. Even on smaller projects people clearly don't read the entire thing to find what they're looking for. Searching for a given bit of functionality is far from an O(n) process.
Then our experiences with these codebases are entirely different. I have a hard time looking things up in the systemd source code. The code really is more complex.
sysvinit scripts were/are massive, plus usually source some other file. For systemd they're replaced with configuration files. Much easier.
I don't see why you'd need to check the source code though. It's often just init scripts, plus the various related ones (timers, path, socket, etc). Before that was also spread out over multiple things. Now they all share a similar way of doing things.
Slight annoyance is that some systemd manpages too often refer to another manpage. Example: if you e.g. skim the systemd.service manpage, you'll likely miss the options documented under systemd.exec. The manpage does refer to those, but I often forget that you need to read multiple manpages.
Comparing systyemd with init scripts is disingenious. I can only read systrmd unit files after learning their language, which includes all the meanings and interactions of the possible statements in them. In othrrvwords, I have to learn at least the entire default behavior of systemd up front. With init scripts I need to only know the script language. A skilled Linux user will be quite familiar with the later anyway.
> Comparing systyemd with init scripts is disingenious
You're not really explaining why I think. For systemd you have configuration files. It's very easy. At a last resort you can write a shell script for some special handling. With init scripts it's totally false that "you only need to know the script language". The way those init scripts are written differs across distributions. Meaning, small differences between e.g. Fedora, openSuse, Mageia, etc. Bigger differences for Debian.
I don't get why you call a configuration file a language.
> A skilled Linux user will be quite familiar with the later anyway.
That's what I mean, the system unit files are way easier. There's pretty much options for loads of things. Much easier than doing that stuff yourself in each and every shell script.
Loads of things which is an easy option in systemd I wouldn't know how to easily to in a shell script (e.g. ProtectHome).
I hadn't heard of Kiss, looks cool. I'd say that the go-to simple linux option has been Slackware for a very long time. And the simple linux modern option is something like Void Linux. Simplicity largely comes from not using systemd in the case of Void, though I'd be reluctant to say the same of its (very powerful) package manager.
In my experience as an end user, they are decidedly simpler, have much better documentation, and changes are broadcast through standardized release processes. I spend a lot less time “admin-ing” my FreeBSD servers than I did when they were Linux.
FreeBSD you mean. OpenBSD and NetBSD are still simple.
You can realistically read the entire source code of OpenBSD, compile it, and know exactly what's on your computer front to back. To do the same with Linux is a research project.
> You can realistically read the entire source code of OpenBSD, compile it, and know exactly what's on your computer front to back. To do the same with Linux is a research project.
openbsd/src is over 17,000 *.c files with over 3 million lines of code
I don't mean just FreeBSD, being quite a bit smaller than Linux is still a gigantic, 30 year old, codebase. You can not realistically read through the entire openbsd codebase unless you spend a decade at it
Turning and turning in the widening gyre
The falcon cannot hear the falconer;
Things fall apart; the centre cannot hold;
Mere anarchy is loosed upon the world,
> 'Computer science' is the study of information complexity and how it maps to solving computational problems, so no.
I'm not saying that Lisp pioneered Lambda Calculus, I'm saying that your definition "CS is the study of information complexity and how it maps to solving computational problems" isn't correct.
Edit: Okay, I might have misread OP and thought he'd said LC pretty much pioneered CS, not Lisp.
Unix never thought of OS as only the kernel as linux does now. All the Solaris, BSD OSs see the kernel and the core libs incuding service manager as part of the OS.
That's not as weird as it might sound (perhaps you knew this). He used /bin/sh until bfox wrote bash.
But on ITS, the PDP-10 OS we mostly used until the mid 80s, DDT (the debugger) was the shell. There were no core dumps for interactive programs; if your program halted abnormally you were already in the debugger so it was no big deal. The Lispm, of course, worked this way too although the debugger was more sophisticated than DDT.
I'm curious if it is actually more "lightweight" than Systemd in terms of memory consumption or CPU load, especially it depends on emacs PID2. Less lines of code does not always means lightweight.
The impression that Emacs and Emacs Lisp are heavyweight comes from the 1980s. (Since then Emacs Lisp has gained the ability to talk to GTK+ and to the GUI toolkits native to Mac and Windows, but has bloated up very little otherwise.) Compared to for example 2020's Firefox or Chrome, 2020's Emacs Lisp is very lightweight.
"emacs is a great operating system lacking only a decent text editor", goes the old joke. It's amusing that people are doing this. I wonder what text editor M. Schaefers will end up using. (-:
Let me interject for a moment, but what you guys are referring to as fun, is in fact, GNU/fun, or as I've recently taken to calling it, GNU plus fun. Fun is not a thing unto itself, but rather another free component of a fully functioning GNU system.
Because it’s way better than what we had before. SystemD doesn’t care to be portable so it can expose a ton of nice Linux specifics and it centralizes a ton of stuff that was all over the place previously. I understand people hate it just consuming functionality one by one as it grows but from an end user perspective it’s been helpful.
The "not portable" thing is actually such a weird point. Every other non-linux OS had its own pid 1, none of them identical to the sysvinit package formerly used by Linux distros. (though some of them quite similar) So I don't think you could really claim the thing systemd replaces needed to support the BSDs or anything. Because it did not.
In some cases you might reuse rc.d scripts across multiple OSs... But rc.d itself was not "a thing" everywhere.
It is not a weird point because systemd imposes the use of non-standard interfaces on daemons to be regarded as good citizens of the systemd OS. So porting daemons that do this to another Unix becomes significantly more than locating and fixing a few edge cases that are handled differently.
I suppose that's true. I was saying gp's point that portability was a burden was weird. As if anyone who touched sysvinit was cursing at themselves in fury because they needed to support BSD (which doesn't use it).
Systemd manages a huge number of things, and this doesn't even reap zombies, which all good init programs do. It doesn't support run levels, it doesn't support "resapwn" (for getty processes) -- hell feature-wise this isn't even a legit replacement for SysV init.
Having said that, I think this is a neat idea, and it'd be cool to have an emacs server process as a true pid 1 init, and when you SSH or go to the virtual terminals you'd get an "emacsclient".