Runit vs systemd placeholder

[superwow]

Linux userland has recently been outraged by systemd, including the VSIDOland. I myself voted for systemd v. upstart back when we had our discussion in January & February. It now seems to me that systemd is just another version of corporate decisions interfering with the libertarian linux-userland. Why bother to discuss those two offerings?

Why not discuss alternatives?

Gentoo uses OpenRC.
http://www.gentoo.org/proj/en/base/openrc/
And Manjaro has a pretty good page on OpenRC.
https://wiki.manjaro.org/index.php?title=OpenRC,_an_alternative_to_systemd

Slackware I believe does it differently. Same name as the systemd program but I think it is a totally different software.
http://www.slackware.com/config/init.php

Or maybe use something less. I mean useless. No, for real:
http://uselessd.darknedgy.net/

Everybody is hooting and hollerin about systemd, including me. All these damn problems with my favorite programs because of corporate decisions? Whatevs.

Anyway, solutions are out there.

Slack & Gentoo have pretty savvy user bases, so the knowledge is there to pull from, though I don't know anyone who uses either. Don't know a thing about useless though. What would be the difficulty in using one of these solutions?

[PackRat]

Slackware (Salix, Zenwalk) use a BSD-style init system; similar to systemv.

[zbreaker]

And as an also Slackware user I can say it performs admirably....in Slackware.

[statmonkey]

Lest you think I am crazy and paranoid (ok, I am) watching some of the structures of the programs change I had theorized that the developers of systemd were going to bring the file structure of Linux into compliance by in essence making that part of systemd's responsibilities.   I mentioned in the LightDM fiasco that part of that was due to systemd but didn't verbalize it very well.  I think this post http://0pointer.net/blog/projects/stateless.html by Lennart explains better what I was talking about. 

For those who don't want to go through the effort I'll summarize it and why it impacts you. (MY take and could be only of interest to me, I realize - caveat emptor)

The basic concept begins with the idea that devices are for the most part just that, devices.  That system file structure at it's core should be the same whether its a phone, tablet, desktop, watch and that Linux is an appliance OS. The file system should also be simple and transferable. Given that is accepted then there are certain goals including but not limited to:

Having a set file tree that centralizes the downstream and upstream essential files into one folder, creating a simpler more centralized file system.
Creating the ability to have a fresh install/environment on reboot or even live on the fly
Giving distro's and users the ability to recreate and duplicate their setups over an unlimited framework as userless with a known core set of standard admin/system users replicated with the system. 
By configuring a standardized setup like this it makes it easier for developers/upstream and down to work across all systems of a given OS without having to work around crazy variances and making installs/upgrades/customizations easier to implement.


So, how does this potentially affect you?  For now I would suspect that you will begin to notice that some developers for apps that are closely tied to RH/Fedora will be moving things around and this will affect customizations where you are not following the maintainer's structure in the strict sense.  Over the long term if it is successful it will mean a much more regimented file tree overall. This will affect permissions, how things are called on startup, the state or environment that is expected, how you script and where you place your "user" files and how you call stuff you want.

There is really no reason for me to parrot all that Lennart has said and he lays it out relatively clearly, if you have further interest I would suggest reading the link.  Personally, I hope this is something that gets followed through on, this has long been a pet peeve of mine.  So, I would put this in the plus column for systemd.  I really recommend reading it, it's pretty high level and there is a lot I have glossed over.  I just thought it was worth pointing out.

[VastOne]

^ Excellent post and points... thanks for that link. I have read it and have a much clearer understanding of systemd and why it in fact troubles so many people

This is from 3: Reproducible Systems

Furthermore this mechanism is useful to implement very simple OS installers, that simply unserialize a /usr snapshot into a file system, install a boot loader, and reboot.

This has always been my dream/goal for VSIDO... a simple starting point.  As a matter of fact, if I could simply script a method of that allowed using gparted to select and manage a disk and then a choice of x32 or x64, and that choice selects and dloads a fsarchived file (or on the CD as it would still be less than 600MiB) and finally installs grub ...  I would build VSIDO that way.  It would lose the LiveCD portion but it would be a simple three step and go process... It could be done with yad or zenity very simply

Think of VSIDO installed that way.. you would be on the go in less than 3 minutes with a complete reinstall using fsarchiver ... then a tweak to the fstab file to direct it to your /home drive and you are completely back to where you were in a disaster recovery process that is second to none...

My dreams... who needs a god awful installer anyway?

[statmonkey]

Hmm, Lennart's Ramblings the stuff that dreams are made of ..... 

Understand that Lennart see's this a little different.  He is speaking of three varieties one of which is stateless which speaks for itself, another is essentially a developmental state that is barren and yet another which (if IRC) he considers clean which is the OS developer's original state at the touch of a key or as a reboot option.  That is cool and it could be built upon if done correctly.  This all interests me very much.

My issue with being of much help is my lack of any understanding of what really is going on in the install process.  I do use scripts to do some of this (though not really any zenity/yad just a initiating script) but I have scripts around that do the following (not used in this order):

     a. Backs up home and root to a designated drive for re-install
     b. The thumb script that burns an iso and then reboots to install
     c. An app script that grabs the apps installed and then offers them as a checklist.  The user selects them and it feeds to create an apt install script. (this one is a wip but at present I use it, just pretty rough)
     d. A script that restores the proper user files for apps that I know I will be using on my new system, primarily config files, etc.
     e. A script that restores my dropbox stuff.
     f.  A script that restores my beloved cron stuff and confirms the permissions
     g. A script that sets up my equally beloved personal log files
     h. A script that does some hand installs (I run a script that builds my git locally and installs things like my personal dmenu program etc.

I happen to be looking at this stuff and checking it as part of my new install and have a feeling I am missing something.  Also pretty sure there are some I am not thinking of right now so I reserve the right to add to the list.  A lot of this type of thing could be written to be an add on to an install script regardless of where you got the install from.  I typically do it this way, I just haven't been really on the re-install train since VSIDO has spoiled me so horribly and there was no need.  Perhaps none of this interests you and perhaps others have better ways.  I'm just sayin' there it is if it might be a place to start or move closer.

[ozitraveller]

I read the whole thing, and like the direction systemd is heading, so far. A more flexible and consistent Debian.

I wish Lennert/someone had published some of this before "The Great Systemd Debate".

[jeffreyC]

With everything that will be run directly by systemd the only thing remaining on the to-do list is to change the name from Linux or GNU/Linux to systemdOS

[statmonkey]

I read the whole thing, and like the direction systemd is heading, so far. A more flexible and consistent Debian.

I wish Lennert/someone had published some of this before "The Great Systemd Debate".

I think it was published but got lost among all the fud, fud rebuttals and fud for fudsake. I think this because obviously I knew about it but can't remember where I got it?  Lennart somewhere I would think.

I agree that it's something long overdue and I disagree that it will end in "distro-less" Linux.  I think it will lead actually to more flexible Linux and probably a simpler customization process. If systemd is a base that is managing more then there really would be two key building blocks (the kernel and systemd) what lays on top of it will be less important but all will access the info in the same way.  That said, getting info out, repackaging and presenting it, piping it, etc. will be much more consistent and leave more time for creatively using it instead of the current situation where we all use a lot of time creatively getting at what we want to access.  The elephant in the room here of course is "having free access to the info we want in the way we want it".  Maybe not a good example but an example is the current journal/log situation which I am not sure anyone really likes.  Another example is the permissions information that I really can't figure out what the current path/methodology of favor is.  I do like the overall direction though.

[ozitraveller]

Debian leader says users can continue with SysVinit
http://www.itwire.com/business-it-news/open-source/65684-debian-leader-says-users-can-continue-with-sysvinit

[VastOne]

^ Finally a sane post...  thanks for that Ozi

Between Lennarts Blog that has explained so much and the leader of debian setting the record straight we might see some of the angst and vitriol diminish...

Nahhh

Never happen

[jedi]

Fellow VSIDO'ans, this "ain't" going away any time soon.  Personally, I have no iron in this fire.

However, I know some of our users are package maintainers, developers, and sysadmins!  Debian is our base distro of choice here, more specifically SID.  The voices are getting louder and more adamant that systemd does not "do one thing and do it well", (yes, there is that Un*x philosophy popping it's head up again, and not just the 'neck beards' raising the alarm) and this choir is definitely not going to quit singing!

I ran across this troubling site tonight while doing some more research on all that systemd is trying to encompass. Shall We Fork Debian?

I'm not trying to stir anyone up, incite any argument, or incur any vitriolic diatribes here.  But, this is not going to go away.  At this point, my worries lie in the realm of "why are so many of the systemd dev's from Gnome, and the others, former Redhat employees with some still being major stockholders there"?  I find that a bit disturbing.  systemd swallowed whole, udev, almost 2 years ago now, and it seems to me that Gnome is next as it is dependent on systemd now.  We all know or have heard of Gnome's vision of a GnomeOS.

This is just getting more and more interesting.  Please don't take this as FUD, I spent a lot of time reading on this today, and I love my Linux.  This (systemd) is turning into something that perhaps we should be questioning a bit more ardently than we previously thought we should have.  systemd has a lot of good things going for it, including the ease of which it works, not to mention the speed increase in boot times.  I post mine here as a case in point.  This while still using 'Legacy BIOS' rather than UEFI.

jedi@jedsdesk:~$ systemd-analyze
Startup finished in 1.699s (kernel) + 1.316s (userspace) = 3.015s

The speed however, is not enough for me to justify turning my back on the men and women who over the last half century have provided time, and time again, a rock solid OS that, if the masses new of, would be a world dominator.  Bill would still be in his garage.  Wozniak would well, still be Wozniak...

[jeffreyC]

Looks like it is not as set in stone as thought, round two of voting?:

https://www.debian.org/vote/2014/vote_003

[VastOne]

@jedi, so what is it that you are recommending?   

Regarding the General Resolution.. this says it all

Proposer: Ian Jackson

He was the biggest bitch about systemd winning and upstart losing during and after the Debian TC decision and to ask for a General Resolution is anyone's right to do so.  It will be interesting to watch this but impossible to retract from systemd in time for the imminent freeze of Jessie (23:59 UTC on the 5th of November 2014) ... FWIW, I already thought a user had a choice

A purge of systemd will automatically install sysvinit and sysvinit-core... Isn't that what is being asked for in that General Resolution?  It is always about choice isn't it?

[PackRat]

@jedi - good luck to them with an attempted fork of debian; I suspect they would lose a large chunk of the repos as systemd gets integrated into the dependecies.

What I can see happening is an exodus of developers from debian to non systemd distros and projects. Mate and Trinity (KDE 3.5 fork) come to mind as well as slackware and *BSD derivatives.