This is an interesting read

Yep. Been supporting it for a while now.

Plus, over in the LFS section, we've been hard at work gearing up for a full Runit release complete with build hint, install scripts, scripts for booting, etc.

Not to toot any horns, including even our own, but our work could make systemd obsolete (maybe even useless) if and when we finish it. All we need are people to help with drafting Run, Log, and Finish scripts for all known daemon services out there. So far it's just me, Stoat, and Keith writing stuff, when we can, so progress has been a bit slow going.

And yes, we even recognized the need for a modernized init system for Linux, and while Runit might not be a perfect replacement, it's a better step, in a better, if not the right direction as Runit isn't just geared for Linux, it's geared for UNIX on the whole, is Bash scripted, works with pre-existing sysvinit scripting, and doesn't require any heavy duty rebuilding of other components which makes it a clean drop in.

5 members found this post helpful.

I can script, and I am willing to contribute to anything that will make systemd obsolete.

Does that mean that you have started to implement a daemon that offers the DBUS interface of systemd-logind? I do not know much about Runit, does it offer cgroup handling?
Not to diminish your work, but if that is not present systemd will not become obsolete or useless.
Keep in mind that not only systemd the init system exists, but also systemd the project, which offers far more than "only" an init system.

Tobi, were you reading the "Because Shiny Things are Fun" all over again? (your new signature)

Not to make you look bad Tobi, as if your statement didn't totally make you look like a systemd supporter/fanboy (and I'm beginning to wonder about your motives), but Runit isn't systemd, nor does it add bloat and nonsense to a system that already work through already available standardized applications, interfaces, and already standardized and existing software.

It's an init system only, and that's all it does, and that's all that it needs to be.

If you want logind, there's consolekit which is the standalone standard. Of course there is the option of using hal like FreeBSD does which is all consolekit provides a stripped down for. There is a script available I published somewhere here to build hal on modern Linux systems. Find it, use it, choice is yours.

Need D-Bus? There's a few run scripts already available in Keith's dropbox, but Runit doesn't require D-Bus, so either use the book and build it yourself and use the runscripts, or don't. The choice is yours.

CGroups is handled by, oh guess what... libcgroups... as it should be!

If you don't like it Tobi, go to systemd, or stay with sysvinit/bsdinit. Let others have their freedom of choice of a clean init system that's only an init system, and nothing else that abides by that little statement below of Doug's.

9 members found this post helpful.

Is this the right runit ?
http://smarden.org/runit/

A search gives a lot of hits for different programs called the same thing.

Yep, that's the correct chocolate cookie alright.

Our goal of using Runit isn't to replace sysvinit or even bsdinit for that matter. It's to offer a choice. A choice that's clean in implementation, UNIX friendly, uses classical bash shell scripting techniques, only is an init system, and utilizes existing tools and even scripts if necessary to establish a working system.

As mentioned in our hint, Runit might not be the best choice, as by nature it's just another choice, but in our opinion, and maybe ours alone, it's a step in a better direction that isn't towards one that isn't, nor is it side stepping the issue at hand... the need for a modernized init system for all of UNIX, not just Linux alone.

And I never said it would obsolete systemd, I only said it could so take that however you will for example... by meaning it can utilize existing or even classical tools in a more efficient and possibly effective way.

Besides the only arguement everyone has had against sysvinit has been it's startup speed... well that's been addressed by this, so unless there's been any complaints about libcgroups, the existing d-bus implementation, or even consolekit... to which I've found none in my searches, then let's not worry about what is or isn't included in Runit, that by dumb luck, if any, doesn't belong there.

2 members found this post helpful.

Not really. Seems to be your standard, run-of-the-mill resistance to change, combined with some conspiracy, and a call to action.

sysvinit is great...but is it so great that it should be in place forever?

SystemD is OK. It gets some things right, it gets some things wrong (like binary-based log files). I'm pretty sure the kinks will get worked out, and in 15 years, us old-timers can put up a fuss about how SystemD is the best, and SystemX is eeeeeeevil!

You can be sure that I am not, I even switched my systems (where ever possible) from Debian to a more sane solution when they decided to go the systemd route, I am happiliy running OpenRC.
It is pretty simple, I see the reality. If your init system does not come up with the functionality of systemd, which is nowadays widely used, it can neither render systemd obsolete nor make it useless. If your init system does not provide an alternative for systemd-logind then no major distribution will use it.

Offering choice is a good thing, don't get me wrong, but one has to see the reality. Consolekit is deprecated and as it seems no one will take it up, it will just rot away, viable alternatives for systemd-logind are mandatory for KDE and Gnome, at the latest when Wayland comes to the major distributions, and so on.
Of course Runit will work with the leaner DEs and all the WMs, but telling the people that it can make systemd obsolete or useless when it is obvious that it can't unless those problems are adressed (and for that matter, the same is true for OpenRC) is simply wrong.

2 members found this post helpful.

No, in regards to that I don't care about that thread, but I think that the statement in my sig is true for all technical threads.

Says you...just another opinion, and we all know about those.

Another opinion only. Many others see it as truth with facts thrown in to show it *isn't* the garbage you call it.

Well, I guess that's... Just another opinion, amiright?

-signed,

Not a SystemD fanboi

1 members found this post helpful.

DEs and Wayland aren't even finalized yet, and so far their actual used libraries within the system are still only speculatory at best. The X.org developers, rest assured, are not going to just toss out a Wayland implementation that only caters to the lowest common denominator. They're going to offer a system that aims at everyone and everything.

As far as KDE. KDE can bloat itself to hell and back for all I care. I don't even use it. It's a nice DE but it's functionality is no more or less useful than any other DE or WM out there. If it sells it's soul to systemd, and becomes another GNOME, I could care less. There's Trinity, Mate, Xfce, etc. And GNOME's a lost cause as far as I'm concerned and I use it's software, but not it itself.

Being obsoleted doesn't mean something newer has to come along. As far as ConsoleKit, it's deprecated only by it's developers, same as HAL, but neither are truly deprecated, as neither have both been effectively replaced in complete functionality by another stand-alone project. Udev still can't handle HAL's DRM, and ConsoleKit only functions as a stand-alone alternative to logind which does the exact same thing, and HAL can still serve as the functional alternative for consolekit and logind both (and does on FreeBSD). You could easily say logind should have been more accurately named systemd-consolekit. Being obsoleted can be done not by newer, flashier, or actively developed projects. If the older stuff that's stable, still works, and works well can still function, and can actually work better with a broader spectrum of systems, that's still, in a way, making the newer stuff, kind of pointless in venture, henceforth, obsoleting it in point-of-view.

1 members found this post helpful.