by Dietrich Schmitz
I recently wrote a story Systemd: The New Pulse Audio as regards the work undertaken by Red Hat and one employee +Lennart Poettering to improve Linux with a middleware daemon called systemd.
Much press has been given to the story surrounding systemd putting the work into question. Still, the work progresses and continues to move forward and many Linux Distros have chosen to adopt it as others opt to take a 'wait and see' approach.
So, far, the oldest Linux Distro Slackware has avoided the issue and the most recent version, Slackware 14.0 released last fall by its Founder +Patrick Volkerding, is doing just fine without it.
I came across an interview done by LinuxQuestions.org with Patrick and share here a passage in his interview which deals directly with the issue of systemd. Patrick writes:
I speculate (Patrick's development is kept private so nobody get's access to his decision making until he says so), that Patrick's plan's for the next revision may well include software design changes that successfully keep systemd out of his implementation.
If that is the case, it would be virtuous if other Community Developers fell in lock-step and provided him assistance in such a worthy effort.
Personally, I can understand the contention surrounding systemd's invasiveness and how it violates the UNIX concept of "doing one thing and doing it well".
Specifically, having the initialization process loosely coupled to a series of run level cascading shell scripts has served Linux well for many years and maybe the concern that work being done on systemd is too ambitious insofar as bringing too many processes under control of one daemon service, systemd is warranted. Add that the logging of activities taken by systemd are no longer human readable, but journalized in a binary format and you have a recipe for programmer revolt.
It was most recently the genesis of a decision by Fuduntu to close its doors as the volume of programming required to merge needed systemd changes was simply too large an undertaking for its meager staff to handle.
Will Slackware be the next Distro to fall in line and become systemd-compliant? Stay tuned for developments.
-- Dietrich
Much press has been given to the story surrounding systemd putting the work into question. Still, the work progresses and continues to move forward and many Linux Distros have chosen to adopt it as others opt to take a 'wait and see' approach.
So, far, the oldest Linux Distro Slackware has avoided the issue and the most recent version, Slackware 14.0 released last fall by its Founder +Patrick Volkerding, is doing just fine without it.
I came across an interview done by LinuxQuestions.org with Patrick and share here a passage in his interview which deals directly with the issue of systemd. Patrick writes:
"...Concerning systemd, I do like the idea of a faster boot time (obviously), but I also like controlling the startup of the system with shell scripts that are readable, and I'm guessing that's what most Slackware users prefer too. I don't spend all day rebooting my machine, and having looked at systemd config files it seems to me a very foreign way of controlling a system to me, and attempting to control services, sockets, devices, mounts, etc., all within one daemon flies in the face of the UNIX concept of doing one thing and doing it well. To the typical end user, if this results in a faster boot then mission accomplished. With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle...."Given the foregoing and given that historically Gnome was removed from Slackware, it would seem that Patrick is being careful not to tip his hand one way or another as to whether he will 'yield to pressure' and become systemd-compliant.
I speculate (Patrick's development is kept private so nobody get's access to his decision making until he says so), that Patrick's plan's for the next revision may well include software design changes that successfully keep systemd out of his implementation.
If that is the case, it would be virtuous if other Community Developers fell in lock-step and provided him assistance in such a worthy effort.
Personally, I can understand the contention surrounding systemd's invasiveness and how it violates the UNIX concept of "doing one thing and doing it well".
Specifically, having the initialization process loosely coupled to a series of run level cascading shell scripts has served Linux well for many years and maybe the concern that work being done on systemd is too ambitious insofar as bringing too many processes under control of one daemon service, systemd is warranted. Add that the logging of activities taken by systemd are no longer human readable, but journalized in a binary format and you have a recipe for programmer revolt.
It was most recently the genesis of a decision by Fuduntu to close its doors as the volume of programming required to merge needed systemd changes was simply too large an undertaking for its meager staff to handle.
Will Slackware be the next Distro to fall in line and become systemd-compliant? Stay tuned for developments.
-- Dietrich
