LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux From Scratch (https://www.linuxquestions.org/questions/linux-from-scratch-13/)
-   -   [Annoucement] B/LFS-s6 project (https://www.linuxquestions.org/questions/linux-from-scratch-13/%5Bannoucement%5D-b-lfs-s6-project-4175510228/)

ReaperX7 07-05-2014 06:08 PM

[Annoucement] B/LFS-s6 project
 
As you may well have been aware of the past week or so, myself and the Runit team have been in discussion over our next project aimed at offering yet another init system to GNU/Linux. This package known as s6, is an init and service management system created by the developer of skarnet.org and it's many minimalistic toolkits for UNIX, Laurent Bercot.

First off let's clear the air here...

1. Why another init system for GNU/Linux?

To offer choice and retain the aspect of choice not just by end users, but system and network administrators, project developers, and distribution maintainers.

2. How is s6 going to help?

S6 works very differently than sysvinit, yet returns some aspects of bsdinit while implementing a modernized and functional UNIX-like way of controlling the system and allowing programs and daemons to interact using named pipes and script driven control features. It functions very similar to other projects like Perp, daemontools, and Runit. S6 starts controls Linux from a basic form init script as it's stage-1 process, then passes the process of PID1 to a handler control, and then sits quietly while it's management and control s6-svscan does practically all the work for stage-2. In all regards, it's not only implementing classical UNIX design into Linux, it's actually introducing minimalism back into init structuring the way UNIX was designed to be.

3. Why LFS?

Good question to ask. LFS provides the ideal setting of a clean room Linux distribution. Because the init of the system can be built around the system, LFS can be used effectively to formulate a strategy of deployment across the Linux spectrum. Plus because LFS lacks a package management system, and instead uses classical make to manage packages, it's easier to develop packages for other systems.

4. S6 doesn't use FHS directories for tools. Isn't that wrong?

Is the FHS really that important that it has to be a law? Not always. The FHS is more of a guideline, not a law. While we will work to make s6 more FHS compliant, s6 will for the start, be non-FHS so we can do our work accordingly.

5. Is s6, as Runit, as you claim, a better step towards a true init successor for Linux?

Yes, it's yet again a better step towards what could be the true successor of sysvinit for GNU/Linux, but only time will tell if the work can catch on and spread out from our implementation. As you well may know, I am a staunch opponent of another init and service management system that aims to break ties with UNIX, destroy the UNIX ecosystem, and hard lock a lot of projects into problems that should not be done. System designers who have chosen this init system, in my opinion, are lazy, did not do their research, don't care about Linux or UNIX as a whole, and wanted something quick, cheap, and easy. Ask any person who's dived truly into init development, and you'll understand that init is not something that needs to be bulky, poorly designed, and just plain overbearing by design that it requires external dependencies to work at all.

6. When can we expect a working model release?

A system for testing s6 is currently being designed and built from the ground, up. It is based on the 6-23-2014 SVN release of LFS and will use Skarnet's execline, skalibs, and s6 software in a basic design structure.

7. Runit has it's own init program runit-init, but s6 doesn't. How does it boot?

S6 utilizes the classical "init as a script" method to boot the system for s6's stage-1. In fact the script for stage-1 is the actual init program. This actually is the best design for init because it allows the init to execute quickly and be equally humanly readable as a program. You don't have to have a dedicated execution program for init. That's a myth. Init can be a simple script that executes, loads the basic daemons, and then hands off control to the service manager. True to form bsdinit uses init as a script as well.

8. What are skalibs and execline?

Skalibs are a set of libraries Laurent wrote to assist s6 in functionality along with his other programs he's written. Execline is a scripting language that is similar to shell scripting language as well. Both work with s6 to extend it's functionality and give it flexibility.

9. What license will this project be under?

We will be choosing MIT license due to the fact we want others to not just see our work, but fork it not just for their own purposes, but for their distributions as well. We don't expect contributions back due to the fact each distribution is different on some fundamental level. We want you the end user, the network and system admin, the project manager, and the distribution maintainer to have freedom for yourselves, and just simply acknowledge where you got your design from and based it off of. If you want to contribute back, that's your freedom, and freedom of choice.

We hope to have this project available here for you all very soon. Please support us in this effort, and feel free to contribute as needed.

j_v 07-06-2014 05:47 PM

I'm definitely interested. What I have started is located here (as well fragments for the runit-alt-hint):
https://github.com/jvvv/my_lfs_build...aster/examples

ReaperX7 07-06-2014 09:12 PM

Thanks j_v. Our implementation is going to be published soon in the standard s6-project work topic, as we did with Runit. Keith and Stoat have been busy with other projects as far as I can tell, so once the initial work I do is up, they'll be joining in to assist in clean up and other things.

I can say this effort is going to be different than Runit.

We have only a sampler script to work with for the system run stages and only documentation to work with, so besides being a clean room effort, this will be a pure and true ground-up effort. I was actually thinking of asking Patrick Volkerding about his work with Slackware's bsdinit implementation for pointers and other information.

skarnet 07-07-2014 02:43 AM

Great job, James!
I'm always available if you need more details about the workings of s6.

To add a little precision to a few of your points:

4. s6 does not enforce a policy, it only provides mechanism. It doesn't need to break the FHS per se.
(I'm currently thinking about converting my build system to a more standard configure-make-make install one, to remove the small amount of policy contained in s6: slashpackage - the system layout I use - is a good thing and I can only encourage people to adopt it, but a piece of software is not the place for advocacy, so the build system will be as flexible as can be in the future.)
The problem with the FHS is that it is incomplete. For best results, s6 needs a few directories with varying properties, and some of those directories need to be:
- read-write in every case (so, not the root filesystem)
- available before disk and network mounts (so, a tmpfs)
- available only to root, with no sticky bit (so, not /tmp).
The FHS does not provide a standard place with those properties, so an extension has to be used.

Note that every system needs such a place, not only s6-based systems. Distributions either provide it (often by enforcing an initramfs, sometimes by creating non-FHS mount points such as /lib/init/rw) or prevent the root filesystem from being read-only (which is bad design). If the FHS was updated to include that basic need, it could be scrupulously followed.

8. skalibs is a C library gathering all the utility functions used by s6 and other skarnet.org software; it's simply packaged separately for maintainability and code reuse.
execline is a tiny scripting language that is more suited than the shell to very simple scripts (and especially scripts relying on chain loading, which s6 makes heavy use of). It's a dependency of s6 because of the s6-log program, which may fork a user-provided command line, and interpreting such a command line with execline is more efficient and less resource-consuming than interpreting it with a shell.

basica 07-07-2014 05:40 AM

This is a very interesting project, I definitely look forward to seeing it unfold.

stoat 07-07-2014 07:36 AM

Quote:

Originally Posted by skarnet

I'm currently thinking about converting my build system to a more standard configure-make-make install one...

This would be a good thing (for me, anyway). It's the one issue that has pushed this project to the bottom of my do-list. That slashpackage stuff may be a simple thing; I don't know. But I just can't muster the mental energy to learn that right now.

Keith Hedger 07-07-2014 08:19 AM

Would it not be a good idea to close this thread and use the thread here:
http://www.linuxquestions.org/questi...on-4175510325/


All times are GMT -5. The time now is 11:07 PM.