Runit vs systemd placeholder

[statmonkey]

I understand the simple fact that this distro is founded on Debian Sid at its base. I also understand that part of the beauty of this wonderful distro is that it just works with very little effort and affords a fantastic balance of ease of use and freedom to have what you want.  The question is what the "cost" for this will be going forward.  If you look at it as a linear equation one side is now wildly out of balance.  You still have the ease of using Debian as a core but a great deal of freedom and in my opinion flexibility has gone away.  I am not sure that formula works for me anymore and not sure I can accept that price.  That is a personal choice of mine, I again can understand that most people would rather just go on down the road accepting the loss as a cost of doing business.  Sorry want to be pithy and interesting and humorous but really too much to do today.

Should of had a guinny myself.  I really need to spend more time on the actual call handling with runit v systemd.
I want to know

• What that cost actually is as far as freedom
• What impact would runit have from an upgrade/maintenance perspective
• Can I continue to install/add software/etc with minimal impact (say on the level of what I do to use flux or OB)

Just to be clear my problem is not with the basic functions of systemd at the init level but the journal changes, the overlap with other tools/the removal of specialized tools (there are going to be some quality stuff that Debian will be removing as time goes forward and the systemd people say "oh we are already doing that ... etc.) and the external processes and tasks it takes over. UNDER NO circumstances can I accept corrupt journals/log files.  That is as much of a no go to me as attempting to license the init functions is.  It's just an impossibility.

I've got 3 horses running this weekend and once that is done will have more time.  I apologize that my comments (re-reading them) do not seem well formed.  It's kind of I know what I mean but not how to put it.  I do agree with PackRat and his excellent comment regarding the boutique potential of using something other than systemd.  I can't assess that as either good or bad and I am not totally sure of the total impact on running a system that is "not quite" pure Debian.  As we have discussed ad infinitum this decision by the Deb leadership puts a fork in the road and where that fork takes me is really up to me.  I am not attempting to influence/persuade/demand that VSIDO or anyone else follow my path.  The information and discussion I am adding is meant as informative and conversational as again I don't want to waste anyone's time.  FWIW, I greatly appreciate ALL the comments and value the opinions of each of you, I feel lucky to have this forum to be able to essentially think out loud.  I am pretty sure Jedi will point out how wrong I am 

[VastOne]

No need to ever apologize statman, we all understand it.  I am in the least enviable position of sharing your views exactly but nearly impotent in things I can do. 

I am grateful for the understanding of everyone regarding my desire to follow the debian path..

Edit - having said that, if an alternative solution arises that makes sense,  VSIDO will jump on it in a heartbeat

Good luck with your horses this weekend!

[ozitraveller]

I agree with statmonkey, a feasibility study should be carried out, I just don't have the time nor resources to go down that path, unfortunately.

But having said that, I would love to see the results if they were available.

If systemd ever became a problem I would investigate other distros including bsd.

@packRat - I'm very pleased my stocks have gone up!

[zbreaker]

OK.fantastic pouring of perspectives here. While I subjectively sidle up with statmonkey, I realize that we are a Debian distro and as such follow the path chosen by said distro. I support staying the course for the immediate future, but will be always vigilant of alternatives "if" the "monster" of systemd proves to be what some of us envision. While I've always been a "Debian guy" , I''ve developed a Slackware habit
that would not make my bailing a problem....although I really love this distro too much to consider that as a  possibility.

[jedi]

I agree VastOne, we stick it out with systemd.

The choice, if you want to call it a 'choice', was Debian's, and, as SID is the reason and core of VSIDO, it seems like we'd be "cutting off the nose to spite the face" at this point to try the others. (init systems) The HUGE amount of time invested in getting VSIDO to be as perfect as it is has to be taken into account.  Over 2 years in the making and God only knows how many hours spent getting us here, I fully support the systemd route.  To not only be able to have this stable of a distro, but daily (sometimes even instantaneous) access to the distro's developer/maintainer is to my knowledge unheard of.  VastOne has gone above and beyond in his creation of this distro as well as creating this community.  I'm a member of several, however this is the one my browser opens up to.

That said, statmonkey has made a lot of very good points as to the 'cost' of systemd, not just to VSIDO, but to Linux in general.  It is a huge change in direction, certainly philosophy, of what Linux has always
been about in the past.  KISS, is definitely not a descriptor for systemd.  So again, statmonkey you are right, and the depths you've gone too to point all of this out to us (ME) is greatly appreciated.  You are one wise fella!  The impact of systemd on the programmer/package maintainer, in the end, may be catastrophic.

Could ozi really offend anyone?     Just give him a beer and he's all set!

I would imagine, that if past indicators are any prediction of the future, in regards to VSIDO, the testing and functionality of any current or future init system will be given serious attention.  I test VSIDO regularly on several different laptop systems, and have already gotten my head bloody playing with runit!  (insert brick wall here!)  Today has been spent playing around with OpenRC.  (another init system Gentoo is working on I believe)  Again, I'm no pro, no Linux guru, BUT, I can seriously wreck a well running machine!

This has been one of the best discussions on this subject I've seen or participated in anywhere on the web.  You have all been scholars and gentlemen!  (are there any gentlewomen among us?)

To statmonkey, a big thank-you, you made me do some homework that I should have already done.  Your input is invaluable to this community, and has been since you got here.  The same is true of ozitraveller, whose posts have often times gotten me out of situations I'd inadvertently gotten myself into!

You guys are the best! 

[ozitraveller]

 @jedi - thanks appreciate the mention, but I think it's really a group effort 

Beers for everyone!

[VastOne]

Free Beers for everyone!

[ozitraveller]

I thought you guys might be interested in  post on  lists.debian.org

Bug#761387: debian­installer: Please allow selection of alternate init
system at install time.
Steven Chamberlain <steven@pyro.eu.org> Sun, Sep 14, 2014 at 4:33 AM
Reply­To: Steven Chamberlain <steven@pyro.eu.org>, 761387@bugs.debian.org
To: Matt Miller <bucket58@yahoo.com>, 761387@bugs.debian.org
Hi.
On 13/09/14 14:42, Matt Miller wrote:
> Is it possible to add either a prompt for init system selection in the expert mode install (similar to the kernel
choice) or a tasksel option that installs an alternate init?
I think many people would like this, including myself. Other people
don't want to be bothered with this, which I can understand. (Yet other
people are violently opposed to it and I've seen them be rude and
derisive to anyone asking for this or doing actual work on it).
It is probably a matter of whether someone can do the necessary work,
and making it non­intrusive. I'll do whatever I can, after more urgent
matters for jessie are taken care of. See:
https://lists.debian.org/debian­devel/2014/08/msg00977.html
To begin with I think there ought to be a canonical (little "c")
metapackage for a particular alternative init system, keeping maximum
compatibility with anything expecting systemd, e.g.
* altinit­sysv could install sysvinit­core, systemd­shim, etc. and
perhaps have Conflicts: or Breaks: on some things known to not work.
There are still things to think about such as making sure a package
upgrade doesn't replace the init system later.
Something like this could be installed easily via preseed late_command,
or if we're really lucky, from an appropriate dialog in d­i. Spinning
off unofficial install media could be a last resort.
Regards,
­­
Steven Chamberlain
­­

[VastOne]

That is an interesting request and not a surprise at all.  What would be a surprise is if it were a Debian developer suggesting it.

I imagine Debian will point back to the committee's decision/commitment to systemd as the end all for requests like these. 

Implementing something like that would fracture Debian in a heartbeat IMO

Now who will be the first to question what v-ger is really asking about with the term 'implementing something like that...' systemd or a replacement alternative during the boot process (think chicken before the egg)

Thanks for posting it Oz Man

[ozitraveller]

He is a maintainer.

And there has been no further comment as far as I can tell.

EDIT: that bug has been marked as DONE. Suggestion is to use preseed.

[statmonkey]

Great addition OziT. I apologize for both the length and the Tom Robbins manner in which this is written. This had been on my mind all weekend.

I have seen the above discussed a couple of places but it only takes care of the initial part of the problem.  The fact of the matter is that using an init alternative is going to create breakage. 

There are going to be things, increasingly, going forward that are going to be built utilizing the systemd framework.  By framework I mean the obj's that systemd packages as a block.  In the alternative init's (excluding upstart for the most part but not completely) components are broken out and there are different handlers (this is the freedom of which I speak) that allow you to fork processes and make direct calls.  [I am really simplifying this a great deal for my own simple brain]

In systemd a lot of the low-level functions are bundled and this both limits what a developer can do as well as how he can do it but at the same time makes it easier to ignore these low-level calls.  It creates inefficiencies in handling but simplicity in functionality or simply put, there will be times where you can't really get there from here.  The bottom line will be an impact on maintenance, not so much today but tomorrow.  There are always going to be developers who don't accept this. 

The time I have been spending on this (not as much as needed) indicates to me that this impact will mostly be with the bells/whistles type gee-whiz stuff that we are not prone to using.  People who like things like VSIDO and Slack and other sparser distro's, people who are not running Gnome Desktop or KDE or all in one type solutions are not going to run into it.  Things that could require some effort would be things like Nautilus that integrate with those desktops and provide one click type solutions at a higher level, that are hiding the low-level work. 

I am speculating here, but I think what frustrated someone like IG (to a lesser extent myself) is that for his tools to work he needs access to those lower-level pathways and calls.  Without that access his ability to provide the stuff we know and love becomes drastically reduced (e.g. the ability to structure how the drives are called and get control of certain processes with Udevil or SpaceFM). Providing this under systemd will require either a fairly constant upkeep/impossiblity or limit the tools to non-systemd inits.  This led him to a "why bother" position and I can't say I blame him.

This over-arching problem is going to result in narrowing choices for the end-user.  There will be tools that we now know and love that provide in depth solutions and hacks that won't work anymore because access to those low-level processes won't be available.  They will be replaced with other tools that might or might not give the same info/access but will not be the same and example is the "improved" logging/journals that systemd offers.  Some will call this progress and perhaps they are correct.

The good news is that everything that works now with VSIDO would work with an alternative init.  Choosing an alternative init initially would be pretty painless but the fact is with rare exceptions (Pulse Audio anyone?) Debian rarely dumps a shiny new toy and goes back to a simpler more elegant solution.  Going forward these tools will probably continue at least for a good while to be maintained and probably some will continue in full development regardless of what Debian does.  The bad news is that there are going to be things that possibly will only work in the systemd environment out of the box.  Without looking into more detail I can't tell you how difficult the ports will be but I imagine that they won't be that heinous and possibly will be requiring only a script type solution.  It could require working together to try and get something to work at times and will require a committed community to support the distro.  Initially I think this is a ways out.  Few if any are immediately prepared to utilize much of systemd "infrastructure". 

I am not sure what a true feasibility study would look like.  I am guessing something like we are discussing here and maybe we can flesh it out as a group. 

Runit or its brothers would work well currently as would systemd. I don't think you could get away with splitting the installation path and just let it go at that.  Again, I am not really sure that anything won't work with a lower-level init system but it will require maintenance and some work. I do think that there remains a GREAT deal of resistance to systemd on a technical basis, that is a core group that is saying this is wrong because ... and that always leaves a door open in a community based project like Debian. 

Is it feasible that a distro could spin off and go with an alternate init?
   Yes, certainly.

Would it require a significant initial effort to do so?
   No

How would it limit the user experience?
   Initially it would probably provide very little difference between the current systemd environment.  Over the long-term this burden would increase assuming that systemd remains the init of choice.  If over time systemd grows into it's role as the init of choice it will develop more and more tools and apps that work symbiotically with it's feature set.  Undeniably though there will be progress on the other alternative init's and they too will offer increased features and work-arounds to the community.  I really believe that based on my research (again, limited as it is) that the difference in impact will probably be minimal.  I think there would be hiccups but that is kind of assumed with a cutting edge distro.  There also remains the basic fact that jumping from an alternative init to systemd is probably always going to be rudimentary but going the other way will be more difficult.

How difficult would it be to maintain?
   This is a harder call to make, at least initially.  I don't see a rush by the development community to embrace systemd. The red-hat bootlicker apps, those apps that depend on redhat for installed base will be all over it, certain large Debian installed base apps, the rest I think not so much.  I don't see a reason that a lot of the console type apps using lower level tools would change, etc.  People in this community (Debian/Linux) are always looking to get simpler and more efficient, I find it hard to believe that overall they will ever totally embrace systemd and it's architecture.  But this could be my head in the sand.  In answer to the above I think not very hard but in the end this is a guess.

What is the real argument against an alternative init?
   That is the question I am asking you.  What is it that Debian is bringing to the table here other than it being part of their standard bundle?

What other concerns/feasibility issues are there.

[ozitraveller]

WOW .............. Thanks statmonkey an awesome explanation!

You have cemented my my initial thought to go with the debian way!




Head spinning, in need of some amber fluid to lubricate the old brain. 

[VastOne]

statmonkey, once again you have belted one out of the park and I love the Tom Robbins reference... that in as much as anything shows your street creds and explains the depth of thy mind/thoughts

I am going to try to add a perspective that explains more than my shallow attempts at staying out of this argument for the sake of ... hmmm ... balance? laziness? complacency? all of the above?

I think you statmonkey and IG are similar and even Jed is of the same ilk.  Thinkers who look deeper at the muddled mess and see the complexity from several angles.  systemd of course impacts IG more as a true developer whose body of work is challenged at the slightest bit of change.  IG depends on the KISS philosophy so as to not go insane constantly reinventing both SpaceFM and Udevil at another developers whim

In the early days of VSIDO, I needed to have it reach out to many different people, forgetting how easy apt-get was in just installing something not there (OpenBox, Liquorix kernels, Xfce) or adding sources. We evolved nicely into a little niche that is simple... Debian Sid with a simple desktop and a very easy reinstall process with an ISO that is no longer than 2 weeks old for a new user (wow that is a bizarre Mission Statement) .. All I have ever wanted to do was show the stability of SID to the folks who have been brainwashed into believing SID was unstable and unusable. 

Along comes systemd and suddenly KISS looks like a strange hair/makeup band from the 70's that failed ... except that band finally made it to the Rock and Roll HOF that had it's own POLITICS to deal with.. That is right where I am at with systemd.  I never really liked KISS (the band) but just like The Beatles I appreciated and respected both for all that they have done in the music world.  (Did I just compare systemd to The Beatles?)

How would one judge PulseAudio now?  Is it overkill? perhaps... Is it bloat? Define bloat!  (I hate that fecking word) Does it just work? I use it and like it but I also use and like alsa/alsamixer.  PulseAudio has been hated from the beginning and just keeps going.  I do not think it even has the same developers as it did in the beginning which in itself says a good thing about the application. 

I am looking at systemd as the exact same KISS way.  Is it overkill? Is it bloat? Does it work? Will it be an easy transition between it's v-ger and a new developer / team?

In the end, the simple truth is I trust Debian.  If it is good for the mother ship, then I can live with it.  I believe in Debian's approach to adding anything as complex as a new init system (the Technical Committee approach) and NO ONE can say they did not vet systemd to the nth degree. 

Statmonky asked

Would it require a significant initial effort to do so?

and answered it with a No

That is correct in the simple process of removing and replacing systemd ... I (or you) can do that in a heartbeat.  It is the 'What Now' aspect that has me skeered to venture down that path.  Right now and with systemd VSIDO seems to fully function within the Mission Statement and my own selfish desires to show SID as stable.  Is SID KISS stamped ... I would say the brainwashed world would say Hell NO... I say (and have always said) Hell Yes!

Does this mean that there will be people who will not use VSIDO because of it being Debian or systemd?  I hope so! Linux is and will always be about choice.  I hope there is a better discussion in a few weeks, months or years about systemd and I think that will happen.  I think for better or worse there is too much angst / passion from folks who see a change to the ecosystem as a bad or harmful thing. 

I have rambled on and on as to what systemd means to VSIDO (from my perspective) ... take it as nothing more than an old man's rambling

[statmonkey]

Nothing rambling about that.  One riff begets another. Thank you for the compliments guys, not sure they are deserved but thank you. 

A couple of points to add.

1. Define Bloat - similar reaction to the word but I define bloat as this.  If I am doing a new install and have a problem with sound and pulse audio the first thing I do is set up alsa to test and get working.  Once I have alsa working I know that I can get Pulse to work.  I would never reverse that process, I would never install Pulse to see if I could get alsa to work.  The reason is that alsa is simple, clear and elegant.  It allows for easy diagnosis and it's very easy to get under the hood and see what is happening.  In my experience pulse is not, there are things that are obscured and harder to track down.  Therefore I would say that pulse audio is bloated. Sorry that is indeed pendantic.   Or perhaps it is bias but I could use other examples.  I think you get my drift though.

2. I mentioned elegance. I like elegance, to me it is essentially looking for the "middle path" not in a fence sitting way, but in a right choice way. (For Reference see "Buddha aka that big guy"). VSIDO is to me a most elegant distro.  The middle path here is clearly to go with systemd and leave the user the choice as you suggested. A choice that is not unlike the choice of pulse, Gnome, openbox, mutt, etc. In this case should I or others choose an alternative init it's just that, their choice and it is open to all that choose VSIDO.  This is not like Debian or not Debian.  I was attempting to suggest that the choice really is the end users and for all intents and purposes that choice will remain.  I was also attempting to suggest that Debian seems to agree and that in the interim there seems to be nothing stopping anyone from making that choice.

3. Fear of the Einstellung Effect. My fear that stems from the knowledge that once people have a good solution there is a tendency to find it hard to move on or look for an even better solution to a problem. Call it stasis, following the leader, etc. By all measurements systemd is at present an acceptable outcome for the init issue but it is far from ideal or even great depending on the perspective you have.  It has a long ways to go for some of us to even call it a good solution.  But since it has passed into Debian it will have momentum, etc. I can think of quite a few things that got this far and just never went any farther.  In this particular case I am more worried about good becoming the standard level of acceptance.  The reason being that the work/advancements I see being done on systemd are being done toward adding more tools into the system it controls and more things for it to control rather than fixing what it currently does.  That's scary to me.

In other words one of the great things about this entity you have created is that VSIDO is very much a beginning or jumping off point.  Too many distro's are seeking to be the end point and that is why we all hop away from them.  This is the middle path, there is no end only a path and only a starting point.

Oooh I hope that doesn't sound too ego based or philosophical.  Really just the best way I can put into words what I am trying to say.  For you or others it may be something else.  This is it for me.

Forgot to add: No, it seems that you compared KISS to the Beatles and both to systemd??? Next you will be comparing lumping John Coltrane in with Kenny G.  Someone stop him before this point please 

[VastOne]

Thank you statmonkey... 

In other words one of the great things about this entity you have created is that VSIDO is very much a beginning or jumping off point.  Too many distro's are seeking to be the end point and that is why we all hop away from them.  This is the middle path, there is no end only a path and only a starting point.

The new Mission Statement!  Thank you!

Forgot to add: No, it seems that you compared KISS to the Beatles and both to systemd??? Next you will be comparing lumping John Coltrane in with Kenny G.  Someone stop him before this point please

Yes.. it flowed weird but it made sense to me (I think...)

Shoot me if I ever bring Kenny G to the dance..

John Coltrane Blue Train Full Album

could be the VSIDO soundtrack!!