Thoughts about new features

eric

Let's talk about coming features and how to implement it. Any comments, ideas are welcomed

https://git.obarun.org/Obarun/66/-/snippets/4

eric

eric
Documentation for this features was committed
Let me know if you think that's unclear
https://git.obarun.org/Obarun/66/-/commit/f092771f489e6170d7a553e83e34e5fd9cbf3150

eric

You will get this one at next release:

commit
doc

eric

This will be available on next release
https://git.obarun.org/Obarun/66/-/blob/dev/doc/66-snapshot.md?ref_type=heads

pramodvu

I might sound systemd-ish but that's not the case. I genuinely like and support 66.

What about transient services? Say 66 spawn -T oneshot $SVNAM $cmd $cmd_Args

Also, cgroup support would be much useful.
A [CGroup] section with cpu.weight= like options.
slices like systemd to group services would be practically useful for desktops.
No need for any init-integrated coordinator-daemon like systemd says. Just prepare, say, 66-cgroup, a command which sets up cgroups with appropriate controllers, along with a small daemon or control file/dir, say /run/66/cgroups, to keep track of cgroups.

Also, aliases. And Provides=().
And a 66-dbus-launch feature that I can link org.freedesktop,NetworkManaager.dbus service to NetworkManager service, such that I can override the Execute= of dbus-broker service files via 66 frontends.

eric

pramodvu What about transient services? Say 66 spawn -T oneshot $SVNAM $cmd $cmd_Args

why not but clearly is not planned on near future. Some features are more important than that for now (e.g. events).

pramodvu A [CGroup] section with cpu.weight= like options.
slices like systemd to group services would be practically useful for desktops.

cgroups integration is planned.

pramodvu slices like systemd to group services would be practically useful for desktops.

absolutely not. This is one of the mistake of systemd that will not appear with 66. Cgroups is not and was never designed to track processes. This is an horrible hack make by systemd dev.

pramodvu Also, aliases. And Provides=().

no need to ask for this feature again, you know that is planned.

For now, before implementing new features i try to be "free of bugs" with 0.8.x.x version.

pramodvu

eric

eric Some features are more important

Obviously. No comments on that. But in your free time plz let me know what exactly events are.

eric before implementing new features i try to be "free of bugs"

Good initiative. THIS is one of systemd's major downfalls.

eric absolutely not. This is one of the mistake of systemd that will not appear with 66. Cgroups is not and was never designed to track processes. This is an horrible hack make by systemd dev.

I meant to put services into slices ad sub-cgroups, for resource management. [Eg. boot.slice/boot-services-like-acpid-and-cpupower-or-thermald system.slice/cups.slice/cupsd-and-all network.slice/networkmanager-and-samba-and-all] each slice has collective options for it's services.

No, I am not pro-systemd. Just an opinion:
Using CGroups to track processes isn't as hacky as you think. Yes, there are better methods. But this is fine as a stopgap, which you can implement using the existing libraries like libcgroup[-tools]. It works very well as a process tracker, and you don't have to put a lot of work into it [/sys/fs/cgroup is there for you will all knobs and toggles, as well as a list of processess].
Yes, BSDs have implemented CGrpFS just for process tracking.
Again, I am not pro-systemd-nonsense or against your opinion. Just saying that CGroups are infact fine for process tracking, and it's systemd doing things the wrong way.

pramodvu

Also, here is another feature that would be useful.
Using a PIDFile, say, ="/run/${SVC}.pid", to supervise a service which double-forks without any option to disable it.
It is already supported by systemd and shepherd/dmd.
I know that this is to be implemented in s6, but nevertheless I let you know.