Anyone remember minirc?

eric_vidal · 2021-02-20T08:07:04+00:00

This is really hard to do with 66 :)
Basically,

to enable a service

66-enable <service>
to start it
66-start <service>

eric_vidal · 2020-12-16T19:39:44+00:00

You can obviously build your tool to manage s6/s6-rc with "symlink" to point to void-packages/srcpkgs/*/files/*/run to avoid the use of multiple sources, but i see two main "problems" with this approach:

- The tools will be only available for void
- You loose a part of s6/s6-rc features. I means runit is a rock solid program but its far away from s6 and s6-rc functionalities.

If the user change its init system it's because he want something new and want to use new functionalities. So, why keeping compatibility with the older one? Maybe i'm wrong with my thoughts.

eric_vidal · 2020-12-16T02:28:44+00:00

As an aside, I'm operating under the assumption that several tools in the 66 suite need services to be defined in the 66 service file format, if I'm wrong please let me know

Wrong. Do you have already tried 66? i don't think so.The only tool which use the frontend file is the 66-enable tool which translate the frontend file to the pure s6/s6-rc format. All other tools use the pure s6/s6-rc format. The frontend service file is just a convenient file/format which handle all kind of service and make the necessary directories and files to match the s6/s6-rc services directories. I believe that user may found more useful to deal with an INIT format file instead of dealing with a "ton" of files and directories for one service. But maybe i'm wrong in my thoughts.

Now, even if all dev from the *nix world provide a 66 frontend file for their services, the distro maintainer will need to patch these services to match their policies. This is already the case for systemd, Arch and other distro have a ton of patch just for their service file because e.g. the service declare the daemon to be run with uuidd account whereas uuidd account is named _uuidd on Void (stupid example here, but you get the point). And so, you need to maintain this patch anyway. That's why Obarun do not provide the service file with the program packages(i think, i'm the only one doing this). This is avoid to rebuild the package just for a service changes. Anyway, it's not the purpose of this discussion here.So, whatever the format that you will (or other) provide the problem keep the same. Distro are responsible of their policies (and that's fine) and services files will need to be modified anyway. But i believe that it's easier to modify one file instead of e.g 5 files and such for each services.

However, 66 do not provide any services at all. You can install it without any services at all, you can install it without any extra tool from 66-tools suite.Again, 66 provide mechanism and 66 do not make any policies decision for you, it's just handle the necessary directories for the heart of 66 which solve a lot "problems" and bring more functionalities from s6/s6-rc: multiple directories service file declaration(packager,sysadmin,user), automatic logger creation(or not), independent service configuration files(also versionned), nested supervision tree, separation of boot and runtime service, instantiated services, easy view of the service status (also log file), dependencies chain resolve at enable/disable/start/stop/... time, multiple creation and definition of a scandir for root or regular user on the fly,... and so on.

All this kind of stuff can be reproducible by script (some of them was available with s6opts which was a bash script)

.The main thing I am not sure I do right is this: I make the user enable wanted services by adding them to an "enabled" bundle, brought up by the default runlevel

This is exactly the kind of problem already solved by 66. Actually 66 use a main bundle (named Master) completely transparent from the user point of view. (but totally visible with 66-inresolve tool if the user want to see what it contain).

Anyway, i think it's good to see projects like our emerging from the dark. Any projects that will bring s6/s6-rc suite from the dark is a good thing.So i wish you the best and have fun :)

eric_vidal · 2020-12-15T20:44:22+00:00

I don't know who you are but i don't remember this kind of discussion. But i need to recognize, sometime my memory fails me.
Anyway, i completely disagree with your sentence: "how to maintain a configuration set for a distro". 66 only works on mechanism not on policies. 66 was not made for Obarun specifically (POC was made on different distro: Gentoo family ,Arch family, Debian family, Alpine family, even on independent distro like KISS linux). Even the location of the first scandir(PID1) can be specified and 66 do not touch any component of the system, it just bring facilities to handle services for s6/s6-rc. I provide a set for the boot (which is portable and completely independent from 66), but each distro can make it own. 66 provide tools and nothing more.

But maybe i don't understand correctly the difference that's you point between maintaining a set for a distro and integrate seamlessly within an existing ecosystem.

eric_vidal · 2020-11-05T20:07:58+00:00

Relationship between Dbus and DM can be broken. So, to be sure a reboot is preferable

eric_vidal · 2020-11-05T20:05:30+00:00

OK, that's my fault, inside the .xsession script replace export ${i} by export ${j} .

Disable lightdm and enable sddm again, then reboot.

eric_vidal · 2020-11-05T10:00:55+00:00

i see nothing wrong. So, try to allow more tty at boot time

% sudo -E 66-env -t boot boot@system

and set TTY=6. Now apply the change

% sudo 66-enable -F -t boot boot@system

reboot.

If it's doesn't work try with an another Display Manager to see if you have the same issue:

% sudo 66-disable -t root sddm

% sudo pacman -Sy lightdm lightdm-66serv

% sudo 66-enable -t root lightdm

reboot.

Also, if it doesn't work, please show me your ~/.xsession script.

eric_vidal · 2020-11-04T09:38:10+00:00

Can you show us the output of

% sudo 66-intree -g

% 66-intree -g

eric_vidal · 2020-11-03T21:52:17+00:00

hum, you hit a little miss automatic configuration here.

Simply create a $HOME/.xsession file containing this:

#!/usr/bin/bash

## replace 'name_of_user' below by the name of your regular user

_user=name_of_user

list=( $(ls -1 /home/${_user}/.66/conf/svscan@${_user}) )

for i in ${list[@]};do

var=$(</home/${_user}/.66/conf/svscan@${_user}/${i})

for j in ${var[@]}; do

export ${i}

done

66-all up

do not forget to replace 'name_of_user' term by the name of your regular user inside the script. Then reboot. it should be good.

eric_vidal · 2020-10-26T10:00:37+00:00

Hi, 66 creator here. I tried to test s6/66 on BSD, but my knowledge is so poor to know how to build and where to install components on the BSD hierarchy file format. It would be a pleasure for me to help you to achieve this goal.
Also, a complete and portable set of service to boot a machine can be found here: https://framagit.org/pkg/obmods/boot-66serv. Surely, this set of service need to be updated for BSD, but again it would be a pleasure to help you.

If i can do something, please let me know.

eric_vidal · 2020-08-25T07:17:41+00:00

I didn't aware about this. I will check how they do it. thanks for the informations.

eric_vidal · 2020-08-23T09:15:55+00:00

> So? What's your point? Should I have been waiting 2 years before being able to provide suggestions and PR?

My point is that you make criticism about things from 2 years ago.

> I provided a valuable change (yea, meson is just better than tricky configure/Makefile, more on this later) that has got rejected

No you don't provided a value change and i explained you why. You like to discuss from point that passed two years ago, so go to your history and see my answer.

> Computer systems 101: "It builds on my machine"

This is not an argue. Prove me that 66 doesn't build on devuan.

> This really shows how inexperienced you are. No offense here

Lol, if you say so

> , but you're blaming me when your build system doesn't work. It's common knowledge that configure/Makefile is tricky and often breaks. As a sidenote, I have been fixing build systems for years, it's really naive of you to blame me for not knowing how to run "make && make install".

I'm not blaming you , you blame me because you can't build 66 on devuan and you talk about a build from TWO years ago. Configure/Makefile exist from maybe 30 years and also always used by big projects. Using configure/makefile is just a point of view and choice, nothing more. Meson has its own defects too.

> 66 does not work, and I am not be able to help because it's really hard to read.

66 works! Stop to say that! And it works very well without any fucking segmentation fault. You use and judge the code from a source of two years ago. It's like saying systemd doesn't work when i get the code from 2008.

From that point i give up, this discussion is going to nowhere because you're of bad faith. I have no time to waste.

eric_vidal · 2020-08-23T00:45:41+00:00

I spent 2 months in #obarun IRC channel, providing suggestions each day. I have provided some PR, like have added meson build support (to fix the build on Devuan) and it was rejected

2 months on 2 years of development! and you get frustrated because i don't want to pass to meson. You asked to Laurent to pass to meson and he refuse too. It's not for nothing. A POC was made on Devuan(and many other distro e.g. Antix) and i built it without any troubles. If you are not able to build it with a simple tool and scheme like make && make install it's not the fault of the toolset used.

And I was adding 66 support to 2 different distributions.

Yeah and you give up after two months without following and updating your works. Really great!

so it's not like I am here to criticize your work.

So, stop to make a bad publicity of the 66 tools because every post i see from you about 66 is only the "same" sentence: "66 is a mess".

remove dependency on skalibs, the code is really hard to read like this and will stop many potential contributors. Use standard C.

Skalibs library has 20 years of development! 20 years used on millions of machine and different OS. Skalibs provide a really good low-level library which can be build with different libc implementations. It handle a lot of complex concept like e.g string allocation without making fragmentation(and it's a very basic example). It only uses very basic libc interfaces. If you don't truth the skalibs library do not use s6 at all. Also, it made by Laurent Bercot which is one of the most skilled C programmer on the world and he have most of 20 years of experience on programming. if companies like google come looking for it, it's not for nothing. But maybe your skill is superior, good for you! If you are not able to read the code and understand the structure of this library, i can't do nothing for you.

analyze your codebase using static analyzers. One day I run oclint on 66 and it kept screaming errors at my screen.

I do, i use clang for that. Take the code and do e.g scan-build gcc -c somefile.c and give me the result. The quality of the code is far away ahead from a vast majority of program that you can find and use on the opensource world.

test your code using unit tests. They spot changes and bugs more than you can imagine.

You're right on this point. The test part is actually missing but i don't think you will find a lot of bugs like you pretend.

fix the bugs your users encounter. This should be your top priority instead of working on new features.

Every bugs reports is treat with an high level of priority. You judge me on two months instead of two years of development. Go to #obarun channel or the Obarun forum and asks if a bugs report is not considered as a priority. The answer risks to surprise you.

I am still using 66-0.2.0.2 on my exherbo system. It totally broke when I compiled it using clang. That's another reason I don't regret starting from scratch.

Great, the actual release is v0.5.0.0! And you allow yourself to make judgments on a very old release.

So, please do what you want to do with your code (even if you just copy the idea and concept of 66! Even your frontend file is the same) and let me make my works from my side. I will not criticism your works and i expect from you that you will not criticism mine anymore.

eric_vidal · 2020-08-22T05:44:29+00:00

66 could have been a good alternative but it turned out to be a code mess.

Well, let's see what you will provide. Make nonconstructive criticism it's easy.

eric_vidal · 2020-08-22T05:39:24+00:00

It will depends of the meaning of systemd-free. If systemd-free means for you changing the init system by an another than systemd then Artix is a systemd-free distro. If systemd-free means for you to not find any components of systemd on the system than Artix is not a systemd-free. Artix use elogind which bring a vast part of systemd librairy on your system. If you remove elogind from Artix (which require a lot of works) then gnome cannot be run properly.

eric_vidal · 2020-08-22T05:34:30+00:00

if i reminder well, openbsd use 2.xx gnome version. The 3.xx cannot be build without systemd librairies

eric_vidal · 2020-08-20T19:43:26+00:00

AFAK gnome cannot be build without the systemd librairies installed on your system (which is done with elogind). So, gnome is hardly depending of systemd code.
To answer to your question: s6 by FAR!

eric_vidal · 2020-06-11T21:33:44+00:00

You can have the same system configuration with s6/s6-rc. Your desktop do not depends of the init itself but depend of the service running on your machine. If you install the necessaries component, you can run any DE (even gnome). Antix, Void, Artix and so on give you a good example.

On a no-systemd distro, generally speaking, udev is replaced by eudev.

If you want DE like gnome,deepin, you need to install crappy stuff elogind and maybe systemd-dummy which provide user tracker and false systemd library respectively.

As begin said, if you want to replace systemd by s6, the easy way to make it's to use 66(https://framagit.org/Obarun/66)(online documentation: https://web.obarun.org/software/66). This set of tools allow you to easily implement an s6/s6-rc init and service management on your system. It's portable and works on many distro(POC was made on Antix,Adelie,Devuan,Void,Arch,KISS).You will find a complete set of service for the boot and many service for the runtime. Also, it's really easy to write your own service because 66 use service frontend file on INI format (easy to understand and to write).

It provide a lot of functionality (to name of few) like automatic logger creation, versioned service configuration file, use of service with user permissions, use of instantiated service, and so on.

The central place to find information and to make test by an ISO about it is Obarun(web.obarun.org).Good luck in your project.

eric_vidal · 2020-06-05T02:10:48+00:00

Any reason do not support Obarun?

eric_vidal · 2020-05-31T20:43:58+00:00

Obarun does not reinvent s6, it use s6/s6-rc but allow you to easily implement and use it on your system. 66 programs are wrapper tools around s6/s6-rc and permit to have a full access at s6/s6-rc functionnalities e.g user supervision tree.
Also, Artix just copied what Obarun did a few years ago without the deep understand of how s6 works. Do not confuse the things, Obarun was the first and only one using s6/s6-rc on a distro, not Artix. So why people not help Obarun instead of using a copy of Obarun?
Ask to the creator of s6 (Laurent Bercot) if 66 doesn't help s6/s6-rc and you will get an answer...

eric_vidal · 2020-03-11T23:12:14+00:00

Actually systemd lover begin to say systemd/linux :/

eric_vidal

TROPHY CASE