kisslinux / repo

KISS Linux - Official Repositories
https://kisslinux.github.io
MIT License
401 stars 101 forks source link

Init #325

Closed dylanaraps closed 3 years ago

dylanaraps commented 3 years ago

The distribution won't package anything beyond s6 and sinit (what's in this PR) but baseinit will support many more (as well as device managers and service managers, etc) (send suggestions). Still a lot of work to do but this PR should give those wanting to try a functional system.

Look at the new README files and then look at https://github.com/kisslinux/init/blob/master/etc/rc.conf for more info. Basically, you use the alternatives system to swap things around and then set the corresponding values in /etc/rc.conf.

Edit: Documentation can be found here: https://github.com/kisslinux/init

dylanaraps commented 3 years ago

Rethinking things some. This model of juggling behaviors between components is bound to get complex/unmaintainable as support is expanded. It also creates a rigid structure around observed behavior and ends up limiting users. Instead, I want to support/provide one default configuration leaving the possibility open for users to swap to something else. This means going back to the drawing board (doing more work on this PR + baseinit) and making s6 the default in the future.

Rio6 commented 3 years ago

I agree that having one framework would make everything complex in the future, especially that different inits/service managers have different way to run all the mounting, mdev, etc, commands. Like s6-linut-init has /etc/s6-linux-init/current/scripts/*, runit has /etc/runit/{1,2,3}, s6-rc uses oneshot services. I think what KISS has right now works great for different inits and service managers already.

One idea I have is to have a package that provides all the common functionalities a init might need - like mounting special dirs, fstab, remounting root, setting up hostname, setting sysctl, loading modules, loading console keymaps... And for each init they just need to call those scripts from their preferred locations (set up by the maintainers or the users). This way we can reduce the amount of scripts needed for each unit while having more flexibility.

dylanaraps commented 3 years ago

Will open another PR shortly.