What init system do you use on MX, the default (sysVinit) or systemd?

[Davo]

I actually do quite love the fact that MX 18 uses sysvinit.
sysvinit might indeed be about 25 years old by now, but heck - the by then attained level of intimacy (by you or me) over so many years of hands-on stuff (almost like a marriage in some ways, haha) just breeds some very cosy familiarity.
I can for example usually find my own way blindfolded (so to speak) around all the various config file based and often shell-scripts, the entire boot-up and boot-down sequences are all fully known and clear too. So much bash stuff etc. All this is just-about on speed-dial.

I really do think that this sheer robustness qua booting and that by (deploying an ultra tried-and-trusted approach to the intricacies of) booting up almost any hardware out there could very well partly explain MX's recent explosive surge in popularity. I have yet to
have MX fail to boot for me completely - excepting one very troublesome Toshiba laptop (but almost nothing booted on it anyway - just an ultra cheap and flaky one). Sometimes a small extra tweak or two needed ...but we have all been there and done that.
Of course other aspects of MX's recent popularity surge are very manifold - a very clean design with nice graphics and clear help, a very and even ultra-helpful community, a plethora of very useful tools, a rock-solid base in stretch,
readily available request-based on-demand backports and kernel rolls, very up-to-date browsers, pretty recent kernels included, rolls and respins and masters all available. You name it, basically. Just attention to detail and giving users what they actually want.

I do use Gentoo and Arch quite a bit (about 10% of time-spent) - and the former in particular just goes it's own way here, as per usual. No worries though. Most of my other distros like Tumbleweed, Fedora and some others (about 60%) etc are all exclusively 100% systemd though.

As to systemd, I would suggest a very tiny exercise here. Just after initial boot-up, launch konsole (or xterm) and then execute $ echo $$

This result will tell you just how many processes actually got spawned from good-old PID 1 to achieve your desktop (ps, I always use KDE not the default Xfce). My result was 6535 here. On a mac I do get 159 here - and mac uses launchd, which is kinda same-same-but-still-quite-different to systemd.
On Tumbleweed I get 312. You can also (cough, cough and haha) just grep (or fgrep or rgrep) your own sysvinit start-up files under the /etc* tree to identify how many instances of (say) bash-based stuff like grep, awk, sed, find, cut etc are listed and executed on boot.
I get (not using MX here btw) well in excess of 900+ instances here. Who cares? Well ...each of these syscalls btw (from within bash or else tsch etc) during boot ....launches a new process id and fully accesses all it's libraries and can stall on wait-to-complete and has a whole wait cycle spawned.
Even if the single awk call in bash only does something tiny or minuscule, like disable ipv6 or whatever. Can still impact your boot though. Bash so easy to write and to hack, but quite expensive qua wait time during full boot-up stuff.

systemd is so very clean, mean and ultra-fast here. The only caveat is a properly implemented iteration of systemd. Everything if done very cleanly just explodes your boot time upwards. All processes just-about launched simultaneously and in full parallel mode.
No more waiting for fsck or mount or whatever or fstab accesses, all needed stuff just gets written to a ram-based autofs temporary file and then queued to actual write once the /home directory etc come online.
No more dependancy-based boot stuff aka everything just waiting for syslog to launch and to thus have /var/log up and running (SYSVINIT style). Just written to a ram buffer instead and then flushed in when online. If you do bootchart sysvinit, just so many wait cycles visible.

systemd also does not launch all and sundry services like cups or avahi. Your printer might be gathering dust most of the time, so why launch it always then. Instead it will launch only if-and-when needed. Dynamically. No waiting for any sockets to come online under /var/run, just written to ram buffers
and then queued for actual writes. No process then stalled waiting for only one tiny aspect, if the other 99% is already delivered. No waiting for confirmation stuff, just launch all processes at once and then queue the small missing elements within ram.

Launchd under mac also controls the full desktop environment too, not just the boot bit. systemd can also integrate very well with (say) kdeinit here too aka to minimize unnecessary duplication and to massively increase fluidity in launching. Also security is quite well-covered here as well.
sysvinit does have a huge issue with controlling external factors and sysvinit is so very poor at managing child processes or forking cq double/triple forking etc. Then a pkill command issued only gives a limited process kill, with many zombie or orphaned pid's left. systemd uses cgroups here as a catch-all.
Actually Apple got the idea of launchd from the older UNIX-based and server side inetd which handled tcp/ip stuff ...except thet inetd in it's default-mode of operation spawned a new tcp/ip connection for every connection (duh and why do that!!), which just proved to be incredibly slow.
However very well hidden within inetd (and completely undocumented therein) was the alternate option of defining a single master process and then spawning child tcp/ip from there within ...which was instead just ultra-fast. Don't know why this was never the default mode?
Anyways inetd as deployed natively just sucked big time ... but in it's secondary mode did not do so at all. Some bright spark at Apple then decided to leverage this mostly undiscovered secondary mode for it's own launchd master principle idea. Walking on the shoulders of giants etc.

I do also love a properly delivered systemd. My own business model deploys tumbleweed aka full rolling release with latest and greatest stuff - all just a moment away. Gotta be quite careful here on the snapshot updating stuff, but nowadays mainline kernel is just-about rock-solid and never had any unsolvable issues at all.
Would never ever install Tumbleweed (or else bleeding-edge Fedora) though for any family and friends. For them the priority is mostly stuff that just works ootb, not stuff that requires lots of judicial care and attention. MX has always been a very serious go-to distro in this regard. You can just about guarantee that it will work
and will continue to work and just be rock-solid and will require the smallest amount of external coaching or fiddling. A lot to be said for something that just works as is. I would not like MX to go systemd myself at all. The amount of work needed would be immense ...and to then achieve exactly what? MX just fine as is.
Huge re-learning curve attached for both devs and the entire userbase too and a small(er) distro needs to find niche areas to attract more users and not ever ways to potentially alienate them IMO. MX just fine as is, I'd like to think. Innovate in so many other areas and leave the intricacies of systemd to the bigger players

I have no problems at all with systemd (bar being dumped to a maintenance shell and it's then quite complicated syntax therein or else searching for answers when stuff sometimes goes wrong) or else being semi-forced to learn almost entirely new ways of doing stuff, which this way does require. Although one plus-point is that the then gained knowledge is pretty much distro-independent and will slot in in just about every distro out-there. Which normally did not apply when distro hopping, so systemd is quite uniform accross various *nixes. Usually for me) systemd is just fantastic to use and quite modern,
and delivers about 100x serious advantages over old-school sysvinit ....but Linux is all-about choice and sysvinit is not dead. Nor are those that use it. I'm quite quietly pleased that MX in fact actually prioritizes so many other areas of the basic computing experience - like look and feel, great user experience, solidity, great forum help, customizing packages and backporting stuff ...which are all major factors for most casual, very many intermediate and even quite a few expert users. Always nice to have something that you just know will boot and will just work for you. I would hate to have any of that make way for a big effort to got systemd instead.

MX just fine as is IMO. Better than fine actually!! Would not have it any other way.

Hope this does not derail anything. Not meant to do so. No reason to incite any flame wars. Could have just clicked a button. Indeed (as i suspected and fully agree with - MX and sysvinit is a very good match indeed).
MX maybe a bit old-school with sysvinit, but also bleeding edge with web-browsers, kernels and so many other ways. Whatever you do is up to you, is the Linux way I'd like to think.

[richb]

Hope this does not derail anything. Not meant to do so. No reason to incite any flame wars. Could have just clicked a button.

Which is what anticapitalista and I asked everyone to do and post these discussions in the thread that was started for them.

[figueroa]

Please don't post your favourite init; just simply answer the question about which do you use on MX, thanks.

Sorry, I was just replying to skidoo's incomplete list of init alternatives. I didn't mean to imply that the one that I listed was my favorite. I'm very much in favor of the choices that MX has made. Debian is a good choice of base for MX. I don't believe that Debian's decision to embrace systemd was wise. MX's approach that works around Debian's systemd dependencies is wonderful. I hope that it is sustainable.

[franksmcb]

systemd simply for snap support

[ludolph]

Yesterday was nordvpn (very sophisticated native app developed by nordVPN) for Linux significantly upgraded from version 2.2 to version 3.0. The one of main change is cancellation of sysVinit support. So from now is supported only systemd. Of course is still possible to connect to nordVPN servers via openvpn or downgrade and lock to nordvpn app version 2.2 (the only solution for MX Linux users), but the latest nordvpn v3.0 app is far more better ...

I am afraid that this situation will be more and more frequent in the near future, because systemd is practically standard for all main Linux distributions. On the other hand I still agree that systemd is a bit problematic (basic assumption of MX developers), but ... Any opinion?

[esbeeb]

there are a few snaps that I really like, such as obs-studio (as in the latest/very recent version, 23), electron-mail, and wire.

After a little research into seeing if I could go sysVinit-only with little hassle (and keeping the apps I mentioned earlier), here's what I found:

Some of these snaps are available as flatpaks, namely obs (called "com.obsproject.Studio" in flatpak), and wire (called "com.wire.WireDesktop" in flatpak). But flatpak doesn't, at this time, have (the latest) ffmpeg and electron-mail (whatsoever).

One thing about requiring a Gnome Desktop dependency, say for obs-studio, in a snap, is that the snap package for gnome (called "gnome-3-26-1604") is only 147MB. But the Gnome desktop package from flatpak (called "org.gnome.Platform", or "gnome.platform") is 1.0GB! I'm on a tight cellular data plan, so I would prefer to save that extra size to download. And flatpak additionally aggressively wants to check for newer packages every time the system boots, and this interferes with the work I want to do (the cellular data connection doesn't handle multiple connections well; the bandwith I get is far, far slower when two or more network connections are made simultaneously, so I have to manually kill flatpak with every boot, after catching it making a network connection when I don't want it to, using "nethogs"). Somehow snap behaves itself much better in this regard, it's more friendly to cellular data users. I never find myself having to catch snap with nethogs and kill it.

Having said all this, in the future, I'll look in flatpak first to find new software, before snap, as MX Linux favors it.

PS: I'm also a Docker user. Docker also wants systemd. I did the silly thing of installing Virtualbox, then a Debian VM in Virtualbox, then docker-ce in the Debian VM, just to install and use a docker container.

PPS: I don't have any qualms about MX Linux having sysVinit as the default (after a fresh install of MX Linux), but I wish there was a tool amongst the MX Tools, for toggling to systemd (and it will keep booting that way, by default, until further notice). Then I could use that same tool in the future, if necessary, to toggle back to booting with sysVinit again, by default, should the systemd-pocalyse truly arrive one day.

[BitJam]

PPS: I don't have any qualms about MX Linux having sysVinit as the default (after a fresh install of MX Linux), but I wish there was a tool amongst the MX Tools, for toggling to systemd (and it will keep booting that way, by default, until further notice). Then I could use that same tool in the future, if necessary, to toggle back to booting with sysVinit again, by default, should the systemd-pocalyse truly arrive one day.

I believe this is possible now and such a tool exists. Unfortunately it may not be possible in the future.

[KBD]

but I wish there was a tool amongst the MX Tools, for toggling to systemd (and it will keep booting that way, by default, until further notice). .[/b]

When you start to boot choose advanced, boot up into systemd. Under boot options after you are running in MX set it to continue to boot systemd. I did that for awhile to keep my brightness control set correctly on each boot.

[esbeeb]

I wish there was a tool amongst the MX Tools, for toggling to systemd (and it will keep booting that way, by default, until further notice). Then I could use that same tool in the future, if necessary, to toggle back to booting with sysVinit again, by default, should the systemd-pocalyse truly arrive one day.

I believe this is possible now and such a tool exists. Unfortunately it may not be possible in the future.

Sweet, thanks @BitJam and @KBD, I found it. But it took some fiddling before I could get the tool to work as I expected.

Here's what I had to do:
1) MX Tools -> Boot Options -> Check the two checkboxes: "Enable saving last boot choice", and "Use flat menus (no submenus)" -> Apply -> Close.
2) Reboot
3) MX Tools -> Boot Options -> "Boot to" dropdown -> MX 18.1 Continuum, with Linux 4.19.0-1-amd64 (systemd) -> Apply -> Close.

If I didn't break it into two visits to the "Boot Options" tool like this, it would still boot to sysVinit (if I merely did step 3 above).

[KBD]

Glad you got it figured out :)