Re: What init system do you use on MX, the default (sysVinit) or systemd?
Posted: Wed Apr 17, 2019 3:07 pm
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.
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.
