Forum › Forums › antiX-development › Development › Is antiX going to get s6 init manager?
- This topic has 70 replies, 12 voices, and was last updated Oct 31-8:51 pm by mobinmob.
-
AuthorPosts
-
March 4, 2021 at 6:12 pm #55359Forum Admin
anticapitalista
::@fungalnet – you could try a sid-runit 32 bit iso and see how far you get installing s6.
https://mxlinux.ipacct.com/MX-Linux/ANTIX/Final/antiX-19/runit-sid/
Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
March 5, 2021 at 11:37 pm #55414Member
fungalnet
::1st from the base runit i386 installing git is not enough, ca-certificates is needed and maybe ca-cacert (I installed both in one shot and github.com/skarnet worked, otherwise it doesn’t.
I rolled it into testing/21 first and the problem was the same /run is not mounted correctly, scandir takes too long to create and fails.
But if runit is still installed and you use the init= switch on bootloader you can boot runit still.
I will roll it into sid tomorrow to see if there is a difference, but I don’t think there will be.
anti-X - Adélie - obarun - systemd Free Space
May 26, 2021 at 10:50 am #60155Membersamtix
::I’d like to register my excitement for s6 on antiX!
It’s probably already been thought through, but is there a benefit to keeping the sysvinit image, even now? When is runit not sufficient?
May 26, 2021 at 11:28 am #60160Member
fungalnet
::it is too bad that between antiX and Eric there wasn’t enough time available to iron out the little 32bit library problem, on 64bit it is close to production ready. The boot@-66serv module although working, it would need some refinement to meet and match antix-debian policies and configuration.
When I used runit in parallel with s6/66 on arch/obarun there you can feel the difference of how superior it is. There are so many things you can never do with runit, but even at its bare bone with least essential running, you can tell the difference. Maybe because one is based on slow bash scripts and the other runs on execline, specifically made to run s6.
The only conflicts as packaged between the two systems are the link /sbin/init and /usr/bin/{reboot,poweroff,shutdown,halt} if you can move those to their corresponding separate directories the two coexist as well. Adding to the bootloader linux line init=/usr/bin/run/runit-init gives you a runit boot, or /usr/bin/s6/init depending which you want as default and which as alternative.
A recent 66 tool is:
https://web.obarun.org/software/66-tools/v0.0.7.1/66-ns.html66-ns can take anything executable and place it in a containerized environment/bubble with specific configuration run as a specific user, … and all this with little code, compared to huge amounts of software that achieve the same in other systems. This means that you can convert your “whatever” linux into something like cubes … and all parts of systemd are nowhere to be found.
s6/66 is like a door to a new world, few dare to take the first step … and even fewer will look back.
anti-X - Adélie - obarun - systemd Free Space
May 26, 2021 at 1:13 pm #60162Memberolsztyn
::66-ns can take anything executable and place it in a containerized environment/bubble with specific configuration run as a specific user, … and all this with little code, compared to huge amounts of software that achieve the same in other systems. This means that you can convert your “whatever” linux into something like cubes … and all parts of systemd are nowhere to be found.
s6/66 is like a door to a new world, few dare to take the first step … and even fewer will look back.
Any chance antiX owner can still pursue this for antiX? Looking forward to this fundamental step forward…
In the interim I will try Obarun for first-hand experience. I am all for excellence in architecture…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersMay 27, 2021 at 8:42 am #60262Membersamtix
::The design sounds like it is superior to every other init system out there.
That’s a bummer about the 32-bit.. I’m pretty sure that would be valuable to a lot of people to get that working as well, because 32-bit antiX is what I use.May 27, 2021 at 1:01 pm #60287Memberolsztyn
::The design sounds like it is superior to every other init system out there.
That’s a bummer about the 32-bit.. I’m pretty sure that would be valuable to a lot of people to get that working as well, because 32-bit antiX is what I use.In the interim, before 32bit version is figured out, I suggest antiX owner could come out with 64bit S6, while leaving 32bit leaving on the current init systems. I think such opportunity that would be the most significant factor that sets antiX apart from other distros should not be wasted.
I also have one of my systems on 32 bit, Thinkpad T60 operating audio system my wife running for her open.fm music station in the kitchen round the clock. Very stable as it is, holding up on memory footprint. This could wait for S6 when issues are resolved.
In the meantime, if antiX can show to Linux world the most successful 64bit implementation of S6, putting to shame systemd, this would be something…Live antiX Boot Options (Previously posted by Xecure):
https://antixlinuxfan.miraheze.org/wiki/Table_of_antiX_Boot_ParametersOctober 31, 2021 at 9:38 am #69829Member4L1V3
::Hey, anticapitalista, any chance you could provide an remastered-ISO of that antiX with 66 please?
October 31, 2021 at 11:06 am #69832Member
fungalnet
::Since there is interest, there should be a couple of things noted for the initially posted script.
Somewhere a link or two on skarnet’s s6 pieces there is a change, so the script fails. It is best that each piece is individually cut from the script and built separately but in the same order. 66 git location may soon change as well from framagit.org to git.obarun.org.The latest version of boot@-66 module requires two more separate packages, opentmpfs and modules which used to be part of 66 but since opentmpfs was abandoned for use of systemd’s tmpfs (3-4 times more code) this and the modules script were separated as independent sw. It is best to remove a pre-existing boot tree and rename/create a new one if you are just upgrading, otherwise traces/definitions of the old tree may look for modules.sh and opentmpfs.sh in the wrong place (usr/lib/66/script/* instead of usr/bin/*)
The 32bit issue of a mislocated library still seems a mystery, but I haven’t tried recently to see if it has cured itself. s6/66 on 32bit void, glibc and musl, has no issues what so ever, so it is not an architecture related problem, it must be a debian policy issue of a 32 bit library being misplaced. I am pretty sure the same holds true for alpine as well.
anti-X - Adélie - obarun - systemd Free Space
October 31, 2021 at 8:51 pm #69864Member
mobinmob
::The best solution is to create packages – the script is nice, I have modified it for a POC (66 on pclos) and it worked 😉
I have no idea if antix uses the tmpfiles.d spec. If not, then tmpfiles support is not needed. The sysvinit scripts for module loading can probably be used in place of the modules.sh. I hope I can run some tests in the following days… -
AuthorPosts
- You must be logged in to reply to this topic.