Skip to main content ↑ ↓
Topic: Does Artix use original runit or a fork by madscientist42? (Read 1280 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.
 

Re: Does Artix use original runit or a fork by madscientist42?

Reply #1 –
There was something on the old Void forum that no longer exists where someone, I think cr6, found some repo where some people were developing a "next version" runit, but Duncaen didn't like it because it used cmake and that isn't very BSD. The madscientist42 runit uses cmake, so it may be related.
Looking about I found this on gitlab, vaguely relevant and interesting as it's not in the repos or AUR it seems, and by Aaditya :
https://gitlab.com/abchk1234/runit-init-openrc
Setup to use runit-init with OpenRC. runit-init is used for booting, which transfers control to OpenRC for bringing up the filesystem, loading modules, running udev, etc. Then control is passed back to runit for starting and maintaining the system services.

Re: Does Artix use original runit or a fork by madscientist42?

Reply #2 –
Quote from: ####### – on
There was something on the old Void forum that no longer exists where someone, I think cr6, found some repo where some people were developing a "next version" runit, but Duncaen didn't like it because it used cmake and that isn't very BSD. The madscientist42 runit uses cmake, so it may be related.
Looking about I found this on gitlab, vaguely relevant and interesting as it's not in the repos or AUR it seems, and by Aaditya :
https://gitlab.com/abchk1234/runit-init-openrc
Setup to use runit-init with OpenRC. runit-init is used for booting, which transfers control to OpenRC for bringing up the filesystem, loading modules, running udev, etc. Then control is passed back to runit for starting and maintaining the system services.

As the gent that is the lead for that project in question, I thought I ought to chime in since it got brought to my attention...

Heh.  Not very BSD...  The original build system wasn't very BSD from my recollection of the codebases (Which could be wrong...)  and wasn't really usable for Cross-compile for embedded targets, which this stuff rocks for.

Right now, a Fortune 500 company is using the project in question (Mine and David Sugar's...) as the core of their product.  If you stuck with the original...or a "BSD-like" solution...they'd be using, heh, systemd.  (Yes, I had a hand in them dodging that particular bullet).

One of the criteria I had was that it cleanly built as a cross-compile solution so I didn't have to resort to using the Busybox variant of things.  Not everything is native compile, folks...and can't be.  So, for now, you have three realistic choices for build systems there with that particular criteria added there.  You can use Autotools.  (Please don't tell me that it's "BSD-like"...  X-D )   You can use CMake.  Or you can use Meson.  Make/Gmake type systems need not apply as they are clumsy at best for that sort of thing- and oftentimes require all sorts of patching to make them work right.   At the time, I was much, much more comfortable with CMake and could assure it would cleanly cross-compile.  I couldn't do that with Autotools and I'd not even contemplated Meson at that time.  So, CMake was used.  It should be noted that while David does Linux stuff, he's more a *BSD guy and makes sure it works right with it all.  I'm the Linux guy and have been for decades now.  As a Linux solution for init...it's kind of...ODD...to not like it because it's not *BSD-like for it's build system, don't you think?

Anyhow...it's got a Fortune 500 company helping with the maintenance as well as a well-maintained partial (It very definitely lacks support for all of the recipes for services in Yocto, but what it does have, it supports it fully and correctly)  layer for it's full support for Yocto.  I'd love people to step up and join in.  The help'd be appreciated on that front.   If CMake's not to your liking, we can discuss things, but  anything you propose needs to cross-compile cleanly and sensibly in Yocto and OpenWRT for anything you propose there.  And I'm just as open to helping the other distros that are interested in looking at this.  I've been just busy with my own projects and work's to start up a conversation until now with Artix or Void for this.  So...

Re: Does Artix use original runit or a fork by madscientist42?

Reply #3 –
Well, welcome to Artix  :D  It could be considered encouraging that it was cmake Duncaen didn't like, rather than the project itself. And certainly back then Meson wasn't even discussed in any build tool comparisons I read. I haven't used Void for quite a while now, and there have been several changes it seems, beyond the forum guy leaving with the forum, after Juan RP left (the first time.)
I'm sure that no one will stand in your way here if you wrote a PKGBUILD for the AUR, if it was possible to use your Runit as a replacement for the regular Runit, and possibly someone might even then provide it as a binary package.
But you probably want to speak to someone who would be actually doing that, and although I used Runit in the past and liked it, I'm personally currently using OpenRC - in fact one of the main reasons is that it's still actively developing, so it's more interesting to see what new versions bring.  :D

Re: Does Artix use original runit or a fork by madscientist42?

Reply #4 –
Quote from: ####### – on
Well, welcome to Artix  :D 

Thanks.  And I am starting to use it a bit on some of my systems (One of the things I do after hours other than support Embedded Linux (If one looks hard enough, you'll find me at the beginnings there...)  is Linux Game porting.  I kind of run a mix of a lot of distros, including the ones that actually officially use runit...).  :D

Quote
It could be considered encouraging that it was cmake Duncaen didn't like, rather than the project itself. And certainly back then Meson wasn't even discussed in any build tool comparisons I read. I haven't used Void for quite a while now, and there have been several changes it seems, beyond the forum guy leaving with the forum, after Juan RP left (the first time.)

I've been sort of following some of that fun.  Partly because they're a primary prospective user base, partly because one of my co-workers is one of the "Void maintainers".

Meson's got some promise since I've been having to deal with EFL/Enlightenment within the context of Yocto as well.  It's not QUITE as capable as CMake is, but that's not a negative.  Depends on your needs.  It might be a discussion point if the other is a sticking point for people- it would let me build against Yocto and OpenWRT, which are concerns in my case there.  OpenWRT has their own init system, but you can replace it if you're using it as a souped up buildroot.  I don't want to cut my nose off to spite my face though.  If Meson is not suitable on *BSD...we work on *BSD officially.  I want to build in those two spaces.  I need to support at least Yocto as it's important to my after-work projects and it's very important to the day job.

Quote
I'm sure that no one will stand in your way here if you wrote a PKGBUILD for the AUR, if it was possible to use your Runit as a replacement for the regular Runit, and possibly someone might even then provide it as a binary package.
But you probably want to speak to someone who would be actually doing that, and although I used Runit in the past and liked it, I'm personally currently using OpenRC - in fact one of the main reasons is that it's still actively developing, so it's more interesting to see what new versions bring.  :D

That makes a lot of sense.  And I'm absolutely not dismissive of people using any one of the three Artix supports directly.  Each solves the problems differently and has use and purpose for everyone- I'm not even remotely one-size-fits-all.  Let the other camp there do that garbage.

As for the fork?  It explicitly maintains original compatibility.  We add additional functionality where needed, either as something bolted on top with a Yocto specification that builds out the content dynamically, or with new apps either within runit or other sharp tools elsewhere.  We brought socklogd back to life for the same reasons, for example.  I want this to work for Void, Artix, and anything else and STAY that way.  Changes need to make sense in the big picture...and keep it as simple as is possible.  If you need more, there's s6/OpenRC.