antiX Runit – iceWM – X64 and 386 editions – beta?

This is the first edition (I think) of antiX with an alternative to sysvinit.  This is runit, the same init/service supervisor Void and Artix use.  As far as I know this is the first application in a debian based system.

Check for a close mirror to test run a live image.  The X is configured with ICEWM and antiX’s huge assortment of tools and helpers.  For information on how runit works I recommend and (void and artix linux wiki pages), although antiX’s implementation of runit seems a little different.

Very good work and very refreshing to see something like this on a debian based system.

12 thoughts on “antiX Runit – iceWM – X64 and 386 editions – beta?

  1. What a strange choice and in my opinion a bad choice. I had the opportunity in the past to use runit, I no longer find any advantage since I use s6 and 66.Obviously runit seems to be dying with no release since five years and the mailing list is no longer available.


  2. I think to move away from sysvinit (or trying to keep debian wheezy alive after 4 generations of debian) is a good step forward. If runit is history sysvinit falls into the sphere of archaelogy.
    Runit is simple, and simple things don’t break easily, but simple things can’t do more than they were designed to do. As far as I know, and you probably know much more, the man that made it said enough, no bugs, no reason to make it more complicated, it is what it is and this is the end. Forks are free to go beyond it, and it is hard to deviate from the work of void. When artix decided to use runit they just copied what void had done, pretty much. Now antix instead of doing the same blended runit with sysvinit (a familiar to them workhorse) and produced an alternative. It is hard to tell if this is somehow an improvement or just an alternative to display the freedom the antix platform provides in contrast to debian.

    So s6 and 66 work on antix, adding the OpenRC working on devuan, that proves the important difference between those projects and debian. Both devuan and antix have to rebuild many packages, probably the same that obarun rebuilds and maybe more, to make them work without systemd. But people don’t see the qualitative difference, of the one working only when systemd (and its snitches) is present, and the other projects working with sysv, openrc, runit, s6 without further alteration.

    If there could also be a convention of shutdown,reboot,poweroff,suspend(!!), and their location so each of this systems can substitute the same, then logout-menus wouldn’t have to be manually edited to work with each one in specific.

    Now on the list you mention: s6-supervise list seems to be serving as a runit list, although it seems as the void people are too busy to participate, they are just doing their thing. There is Steve Litt who is a void user that represents that group, in a way, there is mobinmob that knows s6 and 66 and void, but all this is done through informal personal communication and relations. The products are out, they are what they are, like organic bio-non-gmo vegetables, but the overwhelming majority of non-MS computer users still prefer square shinny tomatoes because based on a popular myth those square tomatoes and the chicken with no wings and legs, is what everyone eats and don’t appear sick.

    I think organic/bio agriculture works exactly like “alternative” init systems. Coca-Cola and Heineken are pretty secure coexisting with those alternative colas and micro-beer breweries. No threats.
    Have you thought about Russia and linux? You’d think with this tremendous scientific theoretical work on its munition depositories (academies ex-soviet) and with all those brains in physics and math, and all the culture of a century long “critical” view of capitalism, despite of practical politics and interests, that when it came to computing systemd would have been dumped as a western piece of trash. The leading distros there seem to have adopted it. Think! The mental health services and direction in Russia and the US were surprisingly very parallel as well. Think again! Aaaahh…. social control, it is an objective. NSA’s interests and KGB’s interests are not that different after all, are they? Neither is state and private capitalism. The umbrella economic/political systems may appear to change from time to time, the hard-core remains the same. UK, Turkey, China, Russia, US, India, maybe France and Germany, … they have an inner core and an outer cover. Progress can only take place in Chile, Uruguay, Bolivia, Mexico, Greece, Ireland, maybe Poland and Cz/Slo, etc.. where the core and cell are made of the same crap, they are satellites of other cores.

    Square tomatoes, square burgers, square buns, wrapped with square papers, can fit on the racks easier and preserve the shape. That’s what it is all about.


  3. At the moment this release of antiX with runit is a test case. We know there are issues, especially when running live, but we also wanted to showcase that live iso plus runit can be done on a Debian base. The same applies if we can get s6/66 working on a live iso (at the moment it is not working). OpenRC also works on installed antiX (with or without openrc-init).

    Liked by 1 person

  4. I know you are a very busy man anti and thanks for all your good work, if you can spare a few minutes to explain to us why is it so hard for a debian-based live system to boot?
    I remember refracta did it with OpenRC but it has been a while and I don’t know whether it was straight OpenRC or OpenRC on top of sysvinit.

    Now that I have a handle on my antiX-sid +s6 +66 -sysv -runit I will try to make a live image using your software to clone an installation.


  5. It’s not so much the booting of antiX live plus another init, but the shutdown that could cause issue.
    antiX live boot (the early initrd part) actually uses busybox at the beginning and then boot is passed on to whatever is the default init. At the moment our scripts assume that this default init will be sysvinit. So, for example, on a snapshot made live iso with runit, I noticed that boot seems to hang at the switch to desktop stage. In fact, using ctrl alt 7 will put you in desktop mode. antiX uses run level 5 for its ‘desktop’ mode, unlike Debian, which uses run level 2.
    I don’t have any experience of s6/66 so hope you can help us out with it.

    re OpenRC – Refracta uses it only as a service manager, the init is actually sysvinit.
    Someone over at the MX forum has been using antiX-19 with openrc-init also as the default init with success.


  6. People… I don’t bag on s6. (I’m working as one of the devs doing maintenance and improvements on runit and adding embedded functionality on top of it effectively (Look for meta-runit on GitHub…)) YOU all shouldn’t bag on runit either. That’s the systemd crowd’s play. We all have valid complaints for it, but that’s a differing discussion.

    More than enough room there and if you’re going there, guys, you need to question your take as well as whether it’s a viable thing or not. No place for this sort of thing. It’s either technically superior in whatever ways (Hint: If it’s, “too simple” for things, maybe a revisit of your ideas and notions- for it was this thinking that SPAWNED systemd and it’s jamming down everyone’s throat… I have yet to see where “too simple” was actually a problem…things should only be as complex as they NEED to be…)


  7. …or not. If it doesn’t/can’t do the things it does gracefully, yes, it needs to be re-worked. But with what? An init system should be VERY simple. The more “features” and all you add in equates to possible exploits and attack faces. (See systemd and it’s Pwnie Award…)

    You’re going to have to convince all sorts of people that you’ve got a solid answer…and people bagging on runit because “s6 is all” is just leading me to believe it’s become yet another systemd.”

    Do you HONESTLY want that?


  8. As for “blended” anything… sysvinit scripts are clumsy and rather counterproductive to runit. Seriously. “Familiar” shouldn’t enter into the discussion. What makes sense does. In this, the sysvinit scripts have all sorts of responsibilities and convoluted natures that cope with all the sorts of things runit does for them. In most cases, you need only exec the daemon into the foreground and it’s all done. No other scripting. WHY would you drag a bunch of OLD baggage that was a part and parcel of the main complaints about sysvinit along with you? Doesn’t make sense. Seriously.

    With runit, you can do things like tiered runtime starts, either with simple checks or sequenced where you run one block, then the next by “up”-ing the next services group block and so on and so forth. You can also turn things off as well. All with, “just runit”. You don’t need more complicated in that save maybe some more sophisticated by a small amount checking for services up and easier one-shot “services”. I’m evaluating that since we need it at Motorola Solutions, Inc., but if you don’t need to add it to the core and just add command-line/gui tools to do that, then that is what you should do. It’s what I did there. There’s quite likely to be other methodologies, etc. They may only need one or two more simplistic answers added in as options if that. I didn’t need to modify anything to add services groups to meta-runit. Now a fortune 500 is using it in their embedded software for their next generation products. Secure. Simple. The same can be scaled to servers, to be honest. It’s all in how you’re looking at the problem. I asked what do I need to do to produce this desired result and what is in the framework there to do it with. End result, services groups as implemented in meta-runit.

    An init and supervision system doesn’t need a new language that needs to be parsed. This adds complexity in many cases, and doesn’t offer you any better answers than you left behind with sysvinit, to be honest.

    An init and supervision system doesn’t need DNS, etc. Mounting drives, handling network lookups, etc. should be the responsibility of something else there. If it’s providing this, “feature,” it’s going down, if only slightly, the systemd path itself.

    This is why systemd became a problem and is why it keeps having horrific exploits happen regularly for it. If you’re doing anything, “fancy,” in this space, you might want to ask yourself if you’re looking at it right- because adding new syntaxes, etc. isn’t that. Adding anything else to it all past maybe logging in the core piece is not likely robust. It goes the ways of systemd. One sharp set of tools for ONE specific task set, gang.

    If s6 and 66 does this for you, great. Well, so long as it’s not trying to be a different and better systemd. If you’ve got that? Well, why did you leave systemd or why are you even USING a Unix-like to begin with?


  9. And, before you remark on whether I tried it out or not, folks…heh… I did…there’s a solid reason why I quickly jettisoned the original attempt at adding runit to our Yocto based builds from another, third party’s repository on GitHub. The end result of what I ran with is a metadata layer that bolts on/into your build sets and provides the same classes of functionality that you get when you specify systemd as a Distro feature in the metadata. It just does runit. The way Gerrit originally intended for it…had anyone went and read his example run files or looked at how Void basically did things.


  10. antiX used a mixed solution of sysv/runit because that was the only way to get a debian based live image to work. Knowing and trusting the abilities of the developer I take his word and will not even waste time trying to disprove him. Just because you can make an arch or void live image work with straight runit doesn’t mean the same setup would work on debian. Debian’s focus on live images is that they work everywhere and adjust to hw before booting, as far as I know.


  11. I am not sure I fully understand your terminology “bugging on runit” but let’s say zfs becomes more prevalent on linux and various other things change as well, as linux “develops”. Who is going to undertake the task of taking runit to this new developing technology? Void appears as the only carrier that ensures that runit as it has been complies with everything that may be new. Is there anyone else to look up to for runit apart from Void?


  12. Criticism, constructive criticism, with rational arguments, should always be welcomed and there should always be room for it. To be quiet about which system we prefer and why as “there is room for all of them” is a wal-mart/superstore mentality. This is why you have sites listing the “top ten” linux distributions, and all ten are part of the same. The top 100 are also mostly the same thing. If out of an open and rational discussion people can determine they should drop whatever they do because busybox does most of what we want, faster, easier, more reliably, then we need to say this, that busybox is better. There still will be people that for their specific use and needs sysvinit will be better. We shouldn’t be preventing such discussion from taking place openly and publicly.

    The other paradigm is where ONE system has the power (through financial power) to direct 90% of publication to portray it as THE SINGLE solution. Just try it. There are very popular linux publication that for all the years they have been on the subject they have not ever mentioned OpenRC, runit, s6, many of them not even sysvinit. It is not there. When they refer to linux and when they refer in practical solutions to common problems, they will ONLY mention systemd.

    But this rag here is not your neighborhood’s Wal-Mart/Carefour/Lidl to have 10 choices on the top shelves of brands owned by a single entity, and if there is room in the very bottom there will be all the “competitors”. Mr.Linus himself has a blog, for years he has a top-ten distros for development listed. All systemd. All his salary is paid by systemd “promoters” as well.

    We can also speak of Marielle Franco here, where WalMart employees are prevented for mentioning her name! Till our free host allows us the space to do so we will keep talking.


If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.