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".
The README is literally full of them.
Looking at the author's .emacs, I'm quite sure the README is legitimate ;-)
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
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.
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.
PS: and I hate sh (as many others probably do), everything-LISP would probably be more fun.
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
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.
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.
> explicitly uses Xorg instead of Wayland
Just as I thought. No actual simplicity, just some neckbeards complaining about software evolving in the last 20 years.
Care to rephrase that without the insulting terminology?
Those concerns are more important for graphical desktop environments, not so much for terminal multiplexers . 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).
 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.
The default compilation option is PulseAudio, but some distros (eg. Debian) also enable ALSA support. On OpenBSD Firefox uses sndio.
You can still prefer X11 for its features, like network transparency, but it is more complex than Wayland.
What on earth are you talking about? Individuals can and do contribute to Linux every day!
The barrier to contributing to Linux is lower than ever, this is such utter nonsense.
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.
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?
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.
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 like to keep things simple, even though many real-life scenarios don't always bend themselves to simplicity.
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
That's assuming you read all that firmware code already...
And then the sleeping giants wake, Lisp and Emacs.
62-year old Lisp, based on Lambda calculus from 80-90 years ago, pretty much pioneered much of computer science.
And 44-year old emacs and 35-year old elisp, they pioneered subsuming.
I mean, there's a church of emacs.
by the way, emacs has already been used as init:
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.
Maybe a better term might be "Init System"...
E.g. nginx can be used as an apache replacement.
If it read exiting config file typically you would call it a "drop in replacement".
* yes there was a time when the fsf’s only computer was a fax 750 (“soon to be running gnu”)
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.
$ ps aux | awk 'NR == 1 || /bash/'
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
kaz 2105 0.0 0.0 30196 5676 pts/0 Ss 14:22 0:02 bash
* ease of use: I don't want to deal with background/foreground processes, storing PID in files and hacks like the old start-stop-daemon.sh.
* reliable services: if it stops, restart it automatically. But stop hammering if it fails repeatedly.
* sandboxing: this service must have no access to the network nor to /home, etc.
This "lightweight replacement" does not have this small subset of features, so it's more an alternative init than a replacement of systemd.
Also.. Lets be cautious about getting Emacs reapable..
Do we really want to witness hoard of abominations (nice things too ofc) that would surface! :D
Just kidding, I know EMACS is lightweight for todays standards, at least compared to electron apps :)
In some cases you might reuse rc.d scripts across multiple OSs... But rc.d itself was not "a thing" everywhere.