This is just a placeholder folder for comments/ideas/links regarding runit. I am looking forward to having a go at it this week as time permits (bit of another pject need to finish up). Also this does not preclude that runit is a solution or an answer I would hope that if there are other suggestions people will start similar threads.
Currently I am starting with this thread as recommended by a friend http://smarden.org/runit/ (http://smarden.org/runit/)
Thank you for this statmonkey...
I know it sounded as if I had no time for this, but in fact I do and will make additional time. My initial look into runit was that it was overwhelming but I now see it is not incomplete like my initial thought was... It will just require some setup and work and I can get to it.. I am looking forward to working with you and anyone else who gets involved on this
I have been looking at this and runit doesn't look that bad. The question/concern/issue really is from an integration standpoint. Since the beginning you have had very little for the end user to care about when installing or adding about anything they wanted. if you move along a divergent path (regardless of what that path is at this level) you are going to add "complications" to this. It really is the elephant in the room with the whole systemd decision. I had planned on adding some examples to make myself clear but time and some pressing issues have gotten in the way and I don't want to drop this or let it seem as if it has been dropped. I can give a reasonable example of what I mean and someone can check me if I am wrong ... I had a pretty similar issue already so I think I get it tho
Lets say someone developed a program that takes dmenu and then autostarts it's daemon at boot. Besides autostarting it's going to check to see what mounts you have include that in the menu. Since the author was an ubuntu guy, this is written to be triggered by the upstart boot process, upstart calls. Now I hate Ubuntu and want to run it in Deb for me. The developer either will have to rewrite the calls and rebuild it to work with systemd or I will or I can't use it. I don't think this is a constant issue but there are some things that will have to be reworked. It's not trivial, I personally would not mind it much but ...
Not so serious in the above example with upstart and systemd since they are the crowd favorites and we have already had canonical running roughshod over a great many people so most things have Debian installs versus ppa's but in the case of runit this might/will cause issues and will mean either a fair amount of work for our fearless leader on a regular basis or a complicated set of issues for the users. Again, I may be making this more complicated than it is and it might be rare or extremely rare (feel happy to correct me) but I do think it's something that people should be aware of.
Wouldn't that scenario be the same for any init system? sysVinit is so lacking that even standard shutdown and restarts are an issue
Is systemd, which is currently working on all levels OOTB, in the same situation and unpredictable?
I do not want to have to think about any of it at all... That has always been the grand scheme, a plug and play SID system installable and re-installable in 5 minutes. If I have to worry about the init system even handling simple tasks, it would seem that whatever does the job should win the job... Just my opinion
"..a plug and play SID system installable and re-installable in 5 minutes"
Looks like you want to stick with the Debian default then; the repos will be coded to work with it. Stray too far from that, and you'll be running the risk of becoming a boutique distro.
I hope nobody minds if I stick my 2c in here??
There has been a shift to systemd for many of the major distros, and I think they will not likely shift again in the near future.
For me, as a small distro owner/sole maintainer, I don't want to and haven't the time to stray too far from mainstream debian and increase my workload. And loose 100% compatibility with debian.
This is one of my hobbies and if it becomes "WORK", then I'll move on to something else.
I've closed the door on this. Until I see Debian support interchangeable init systems, then it goes in the too hard basket.
Hence my comment on the other thread, sorry if I offended anyone. :(
:-[
Ozi
I am not aware of anyone being offended Ozi and I completely agree with your thought and decision...
Well said PackRat
statmonkey... I get and understand all the reasons why systemd is insane... but I do not see a clear alternative right now
For better or worse, agreed.
Quote from: PackRat on September 10, 2014, 09:36:19 PM
"..a plug and play SID system installable and re-installable in 5 minutes"
Looks like you want to stick with the Debian default then; the repos will be coded to work with it. Stray too far from that, and you'll be running the risk of becoming a boutique distro.
Quote from: ozitraveller on September 11, 2014, 12:37:10 AM
I hope nobody minds if I stick my 2c in here??
There has been a shift to systemd for many of the major distros, and I think they will not likely shift again in the near future.
For me, as a small distro owner/sole maintainer, I don't want to and haven't the time to stray too far from mainstream debian and increase my workload. And loose 100% compatibility with debian.
This is one of my hobbies and if it becomes "WORK", then I'll move on to something else.
I've closed the door on this. Until I see Debian support interchangeable init systems, then it goes in the too hard basket.
Hence my comment on the other thread, sorry if I offended anyone. :(
:-[
Ozi
[edit] Ozi can't imagine what you said that might have been offensive. I think we even agreed with you at the time that it had been talked to death. But, again. If it has to be accepted we should really understand what we are accepting. That was the point.[/edit]
I can't disagree. That was really what I was trying to say with examples in my post above. For my own personal systems I may well run runit or sysV but for a distro it would be a significant amount of work in maintenance, etc. That said, I also have some future projects that systemd is going to pose a significant hurdle to.
The finality of this decision (by Debian, the finality of the box it puts all of us in, the limiting of choices I mean) was part of what I was trying to communicate in my response to Jedi in the other thread. The Debian decision really closes a great many doors, it's extremely impacting.
Sorry for wasting anyone's time on this.
I am not going to say I can accept this path and will probably at least play with BSD in the near term.
@statmonkey it also bothers me that for all the variety in linux this is an area where that is not the case. I think it is a flaw and systemd isn't a "swiss army knife" of init systems.
I am thoroughly confused...
My brain hurts, I'm done with init systems unless someone comes up with one in my colour! ;D
Beer anyone? 8)
Popping the top on a classic ale now...
Fuck init systems for the time being
Now there's a man with a fine idea! 8)
A pint of guinness for me please! ;D
Quote from: ozitraveller on September 11, 2014, 04:14:32 AM
A pint of guinness for me please! ;D
your stock just went way up.
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 :D
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!
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! ;)
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.
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! 8)
@jedi - thanks appreciate the mention, but I think it's really a group effort :-[
Beers for everyone! ;)
Free Beers for everyone! ;)
I thought you guys might be interested in post on lists.debian.org
Quote
Bug#761387: debianinstaller: Please allow selection of alternate init
system at install time.
Steven Chamberlain <steven@pyro.eu.org> Sun, Sep 14, 2014 at 4:33 AM
ReplyTo: 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 nonintrusive. I'll do whatever I can, after more urgent
matters for jessie are taken care of. See:
https://lists.debian.org/debiandevel/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.
* altinitsysv could install sysvinitcore, systemdshim, 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 di. Spinning
off unofficial install media could be a last resort.
Regards,
Steven Chamberlain
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
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.
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.
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. ;)
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
QuoteWould 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
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 ::)
Thank you statmonkey... ;D
QuoteIn 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!
Quote
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 (http://www.youtube.com/watch?v=Lr1r9_9VxQA#)
could be the VSIDO soundtrack!! 8)
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/ (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 (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 (http://www.slackware.com/config/init.php)
Or maybe use something less. I mean useless. No, for real:
http://uselessd.darknedgy.net/ (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?
Slackware (Salix, Zenwalk) use a BSD-style init system; similar to systemv.
And as an also Slackware user I can say it performs admirably....in Slackware.
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 (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.
^ 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
Quote
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?
Hmm, Lennart's Ramblings the stuff that dreams are made of ..... ;D
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.
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".
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
Quote from: ozitraveller on October 12, 2014, 05:46:06 AM
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.
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 (http://www.itwire.com/business-it-news/open-source/65684-debian-leader-says-users-can-continue-with-sysvinit)
^ 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
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? (http://debianfork.org/)
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...
Looks like it is not as set in stone as thought, round two of voting?:
https://www.debian.org/vote/2014/vote_003 (https://www.debian.org/vote/2014/vote_003)
@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?
@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.
Rather than quote @PackRat and @VastOne I'll save space and say I agree with both their posts and add the following.
Beware of Bold Font like comic sans I wonder what all the shouting is about on that site. The fact remains that those who do, shut up and just do it. There is choice now and if someone builds a better init or even distro or forks Debian and it is well done the people will come and will use it. Until/if that happens systemd is here, it works and the choice has been made. Personally, I may not like it but I have other things to worry about (I'll post about that later). I will admit that I think udev, udisks, polkit, pam is all one big cluster at the moment but I have enough faith in the community to believe that all this will get sorted. Once there is something concrete to dispute on then that can be done but right now I am really tired of speculation (even my own) on this.
I have personally been following Lennart and his group and think there are some good ideas there, some of it is speculative, some of it far-fetched but at the core the direction seems to be helpful. I have also researched BSD, Gentoo, Slack, etc. and know that if I really see a Gnomie conspiracy I have real alternatives. For now, I personally want to stay focused on VSIDO and what we have, hopefully in my small insignificant way to help this stay the best distro it can be. It's too easy for me to get distracted by things that just don't matter.
More power to them and if they build something that actually works and works well I will be interested.
:D Actually, I have no recommendations, other than everyone should be using VSIDO! I just need to quit reading the mailing lists, and the FUD sites about systemd. The choice has been made, and I'm happy, and satisfied that people smarter than me made that choice!
In my own defense, when I posted it was almost 3 in the morning! ??? How in the world I missed the fact that
Quote from: VastOneRegarding the General Resolution.. this says it all
Proposer: Ian Jackson
he was in any way involved, well I'm just ashamed! His is the loudest mouth in the room no matter what the subject. I find him very offensive! For all I know, he could be the one behind this FUD campaign that doesn't seem to go away.
That I posted about it again, well someone just kick me already! :-[
Not so serious Jedi. I think it is good to keep up on it and am interested in hearing what is going on. I just don't want to debate it anymore. The personalities involved here are not really the point, it's what works, moving forward and really knowing what we have. It is still possible that something else will rise above the rest, I just doubt we will see much from the people who keep spouting off. I don't think they will come up with anything because they keep spending all their time spouting off, instead of ... you know.... working on a solution. What's PackRat's quote "I'm am tired of talk that comes to nothing." very apropos to this topic.
A comment on Distrowatch draws a parallel between Windows svchost and systemd, noting also that both present a large "attack surface".
Making all Linux distros the same "under the hood" would also increase vulnerability in some ways I would think.
Just in case y'all hadn't heard, Debian has been forked over the systemd issue. Just to give credit, I got the info from @jaromil.
QuoteJaromil retweeted
Slashdot @slashdot · 4h 4 hours ago
Debian Forked Over Systemd http://bit.ly/1FCmRWc (http://bit.ly/1FCmRWc)
0 replies 42 retweets 12 favorites
And a nice background on the dyne site: https://lists.dyne.org/lurker/message/20141127.212941.f55acc3a.en.html
Follow the bitlink to https://devuan.org/
So, now, what will VSIDO do?
I highly suspect VSIDO will continue on in the tradition of Debian, and that we wont see much "forking" in the long run. 20+ years of Debian; what's to fork?
Quote from: jedi on November 30, 2014, 03:25:55 PM
I highly suspect VSIDO will continue on in the tradition of Debian, and that we wont see much "forking" in the long run. 20+ years of Debian; what's to fork?
That right there. In addition to them not being able to keep up with the package maintenance, what is there really to fork? If they are that committed to sytstemv, create a new distro from the ground up with systemv and either maintain something along the lines of the AUR, or use pkgsrc for a sources based distro. Adopt the parts of the Debian social contract regarding FOSS, QA/QC etc ... that are pertinent and have at it.
What I'm really waiting to see, is a migration by devs from distros that adopt systemd to *BSD or other projects. I think a major brain drain is a distinct possibility.