Re: State of skarnet.org projects
On Sun, 02 Feb 2020 15:58:12 + "Laurent Bercot" wrote: > >Do you mean they don't like editing files and creating symlinks? Do > >they want a GUI interface to the service directory tree and the symlink > >tree? > > No, it's about service startup with s6-rc. They don't want to dive into > the unpalatable blobs that are the set of systemd unit files or the set > of openrc init scripts (and I can undertand their reluctance); and > they don't want to make the effort of understanding the s6-rc syntax and > creating s6-rc source directories (and that's something I'm sure you can > relate with ;)). They want a service startup configuration format that's > close to what they are used to, typically text files that are easy for > a human to read. Already done. A set of service portable and hackable easily is already operationnal. One file to deal with all services format for s6 and s6-rc which can be written with every language that they prefer. > Ideally, they'd want systemd unit files. Which is not gonna happen, > because the format of these files maps the systemd architecture too > closely and there are lots of things that would be expressed differently > under a s6-linux-init/s6/s6-rc system; but a text-based configuration > engine is totally doable, it's just a long project. Done. INI format what's not invented by systemd. This format is easy to understand, easy to write/read. > They also want high-level commands like "service" or "openrc" to control > the machine state without having to undertand the nitty-gritty of > "s6-rc change", or the difference between "s6-rc -d change foo" and > "s6-svc -d /run/service/foo". Which makes sense: can *you* tell me what > this difference is? :) Done, a set of command wrapper with consistent options between command with deal with pure s6 services and s6-rc compiled database are already operationnal > All of this will be solved by s6-frontend, but that's not something I > can work on in the evenings. > > > >What is UX? > > User experience. > -- > Laurent > They can make test easily to see if s6 suit their needs even if your s6-frontend is used in the future. And maybe after a few POC they can realize the advantage of s6 and finance you correctly to allow you of make rapid progress on the s6 development and s6-frontend -- eric vidal
Re: State of skarnet.org projects
Do you mean they don't like editing files and creating symlinks? Do they want a GUI interface to the service directory tree and the symlink tree? No, it's about service startup with s6-rc. They don't want to dive into the unpalatable blobs that are the set of systemd unit files or the set of openrc init scripts (and I can undertand their reluctance); and they don't want to make the effort of understanding the s6-rc syntax and creating s6-rc source directories (and that's something I'm sure you can relate with ;)). They want a service startup configuration format that's close to what they are used to, typically text files that are easy for a human to read. Ideally, they'd want systemd unit files. Which is not gonna happen, because the format of these files maps the systemd architecture too closely and there are lots of things that would be expressed differently under a s6-linux-init/s6/s6-rc system; but a text-based configuration engine is totally doable, it's just a long project. They also want high-level commands like "service" or "openrc" to control the machine state without having to undertand the nitty-gritty of "s6-rc change", or the difference between "s6-rc -d change foo" and "s6-svc -d /run/service/foo". Which makes sense: can *you* tell me what this difference is? :) All of this will be solved by s6-frontend, but that's not something I can work on in the evenings. What is UX? User experience. -- Laurent
Re: Project funding: was State of skarnet.org projects
Finding long term sponsors is a kind of sales I'm not experienced in, but I can probably get people to contribute on a one-time or intermittent basis. Do you have a contributions page that takes Paypal? I don't, for the reasons explained here: https://twitter.com/laurentbercot/status/1209247040657674240 Also, I want to make a living, not pocket change; I want a job, not charity. As good and well-intentioned as one-time or intermittent donations are, as much as I would appreciate them, if they don't add up to something I can live from, then they don't help solve the original problem of my needing to work on paid contracts. -- Laurent
Re: State of skarnet.org projects
On Sun, 02 Feb 2020 14:22:31 + "Laurent Bercot" wrote: > The big pain point for further s6 integration in distros, as _every > single one_ of those I contacted told me, is the user interface, Do you mean they don't like editing files and creating symlinks? Do they want a GUI interface to the service directory tree and the symlink tree? > and > that > UX return What is UX? Thanks, SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Project funding: was State of skarnet.org projects
On Sun, 02 Feb 2020 14:22:31 + "Laurent Bercot" wrote: > On a related note, it should now be obvious that the main obstacle > to further s6 growth is the lack of time I can spend on it, and that > comes directly from the need to self-fund. As a consequence (and I'm > addressing > the whole community here), if you like s6 - or other projects of mine > - and want to see it become more widely adopted, the best thing you > can do is find me sponsors! Finding long term sponsors is a kind of sales I'm not experienced in, but I can probably get people to contribute on a one-time or intermittent basis. Do you have a contributions page that takes Paypal? SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: State of skarnet.org projects
I'd like to know what is your view and feeling of this expanding base, what does it mean to you, and whether you see an influence of the project by the growing popularity. If I can interpret this announcement correctly you seem already to be reacting to the Debian s6 incorporation fiasco more than the projects who have treated s6 with greater respect. I don't quite understand what you mean. I love that the s6 base is expanding, I really appreciate that we have a community around it, and I've always been committed to supporting it. I keep repeating that I'm always willing to help people who are trying to integrate s6 in their projects; it just so happens that, for many excellent reasons, I don't get many requests. But when people reach out to me, I try to make good on the promise: for instance, making s6-linux-init sysvinit-compatible was a request from Adélie Linux; it took about two weeks of vacation time and a few week-ends; 100% worth, because that's what made it possible to have s6 as init in Adélie, which I'm very happy with and grateful to the whole Adélie community for. The big pain point for further s6 integration in distros, as _every single one_ of those I contacted told me, is the user interface, and that UX return is basically driving my career. It is a big project that will need a lot of focused, uninterrupted time, so I'm currently trying to max out my earnings over 3 years so I'm able to take a whole year off to work on that project. The Debian thing is a minor annoyance; it took two week-ends and a couple evenings to address it. You see me address minor annoyances more than The Big Request because it's all I have time and energy for while working on an outside contract. Maintenance things, tweaks around the edges, light QoL adjustments, and community support on IRC; no big developments. So, in that context, I don't understand your point; could you clarify? On a related note, it should now be obvious that the main obstacle to further s6 growth is the lack of time I can spend on it, and that comes directly from the need to self-fund. As a consequence (and I'm addressing the whole community here), if you like s6 - or other projects of mine - and want to see it become more widely adopted, the best thing you can do is find me sponsors! Long-term sponsoring would allow me to work on these projects full-time, and *then* they would take off. -- Laurent
Re: State of skarnet.org projects
On Sun, 2 Feb 2020 12:34:05 +0200 fungal-net wrote: > Void is also > very close, I for one use it with s6 and 66 for a while now and in > many ways being more carefree than obarun having fast balls thrown by > arch daily. Have you, or are you going to, write documentation on how to install and maintain s6 (and presumably s6-rc) on Void? Are you using Void's s6* packages, or do you compile the stuff yourself? If you install Void's s6* packages, does that remove runit? I'd like to have both, to a/b them against each other and to more quickly learn s6*. It seems trivial to me to deploy s6 stage 2 and migrate all my runit stage2 to s6 stage 2. However, migrating stage 1 sounds to me like an Einsteinian task. Runit's stage 1 repeatedly loops through .d directories in what I find to be an unobvious way. It seems to me that Void is getting more popular every day, and Void could serve as a Rosetta Stone between runit and s6. I'd appreciate any documentation you have or will write in the future concerning your use of s6* on Void. Thanks, SteveT Steve Litt February 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive
Re: State of skarnet.org projects
Is it 10 years now that s6 has been around, more or less. For 10 year old software of its nature it appears as the best kept secret. There are 3 distributions openly available to various levels of users' expertise, that are now utilizing s6 init and supervision, Obarun for 4 years, Adelie for about 1, and Artix for a few days. Void is also very close, I for one use it with s6 and 66 for a while now and in many ways being more carefree than obarun having fast balls thrown by arch daily. This should open up the base of people using s6 in a variety of architectures and purposes, and will inevitably stress test the ability and reliability of s6, while it may create a significant stress to skarnet's ability to communicate with all this testing feedback. I'd like to know what is your view and feeling of this expanding base, what does it mean to you, and whether you see an influence of the project by the growing popularity. If I can interpret this announcement correctly you seem already to be reacting to the Debian s6 incorporation fiasco more than the projects who have treated s6 with greater respect. In solidarity Gus
State of skarnet.org projects
Hello, A small update on my current projects. - Most important skarnet.org packages are due a new release. If only to fix a bug that prevents them from properly installing shared libraries in some cases. - The release hasn't been cut yet because things are still evolving and I don't want to tag a release right before I need to add some functionality. (Which, by Murphy's law, always happens anyway.) - Everything is available, and builds, on the projects' git head. If you build from git, please be aware that you always need the latest version of all the software in the dependency chain. - Some things are *only* available from git because the project they're a part of is much bigger and far from complete, but pieces of the functionality are already in. And for some specifics: - The next execline release has been ready for some time and just needs some external testing. (Hint, hint.) The new thing is a posix-umask program. When it's released, execline will be fully POSIX-compliant (when built with the --enable-pedantic-posix option). As an aside, posix-umask was a lot of fun to write. Unlike posix-cd. - The next s6 version, among other things, has an option to disable its dependency on execline, which hopefully will alleviate a lot of the FUD surrounding it. Of course, disabling the execline dep will make some minor functionality unavailable. And since s6-log is vital, there is a new '?' s6-log directive to launch a processor under /bin/sh. - The next s6-linux-init has options that make it usable in containers. The plan is to use it to work on a new version of s6-overlay that would be lighter, faster, and less clunky. - Following a discussion that happened here last December, there is a new s6-frontend git repository, which currently only holds a series of binaries designed to provide daemontools- and runit-like interfaces to s6 programs. The emulation is not perfect, in particular lots of runit interfaces cannot be exactly mapped to s6 interfaces because the architecture is too different, but the main ones are there. So if you are used to controlling your services with sv, you can switch to s6 and keep using sv while porting your scripts (and getting used) to the native s6 interfaces. Nothing's decided yet, but I may embark on a programming project for one year or so for a professional contract within the next month, which won't leave me many programming brain cells for skarnet.org. So, if you have feature requests, or bug-reports, things I forgot to integrate, or anything to send me, now would be the time: I'd like to cram as much minor stuff as possible into the next releases before a potentially dormant period. -- Laurent
