man man

Nicely viewable in VuuMan.

Really loving this simple utility, been meaning to make one for a long time and should have done so many months ago, now I keep it and VuuNotes open all day long while i'm wrestling with code and trying to learn and make new things. I fixed a typo in the man page for it earlier and uploaded that, I always find these tiny issues after i've made a package and updated/uploaded everything. The curse of being just one guy with one set of old eyeballs on the code I guess.

- "on demand" services are now a thing shed can support, there simply is the need for a program to run shedc start <service> when it starts and then run shedc stop <service> on exit, for programs that natively support configurable/programmable hooks that's not an issue, for others the need will arise to have wrappers that simply run the commands calling starting/stopping their required service

- "start-stop-daemon" has been integrated into shed as an optional backend for starting, stopping, hupping processes, the integration currently is experimental but should work, by default shed will not use start-stop-daemon but it's own methods, to enable usage of start-stop-daemon a file in the session config dir named use-start-stop-daemon.rc must be present and contain USE_SSD=true, as per regular shed functions the strings "true", "yes", "on", "t", "y" case insensitive as well as '1' are taken as true while everything else as false, empty string included, 'start-stop-daemon' should also be available to run by the user, the check is done with command -v

other than that i'm not sure what else to add before cutting the next release or if trying to keep chewing through the current pending points of the roadmap, been thinking about adding some form of service auto-restarting on crash but i'm not fully convinced as that is not a feature of sysvinit, the architecture of which i'm basing shed off, not that i'm opposed to the idea but i'm not sure if that should be a component of shed or rather a separate utility, even a separate daemon to be more re-usable across the whole range of init implementations.

p2papp: p2p chat, file sharing and remote command execution.

a ~300 LOC single file C app without runtime deps other than libc.

no compile time deps other than gcc. even C headers not needed.

IP filtered singleton one-to-one connection. no socket backlog.

p2pchat: This is a clone/fork of p2papp  with only one difference:

remote command execution logic completely stripped of. So more safe.

Here is the repo. please enjoy:  https://codeberg.org/postala/

Rebuilt version 0.4.0 is here https://sourceforge.net/projects/namix/ code is here https://github.com/rations/NAMix

"minimal GTK graphical login manager ... snip"

* user's login MUST not / never been breaks.

   pulling GTK isnt like minimal.

   GUI libs/frameworks depends/assumes too much little things;  its fagile, not safe at least.

   gtk needs already running/functional display server/compositor to present something.

   gui stuff may not even installed on given system. (Say container, server, or user (wants to) uninstall that gui libs  for some reason.)

   A newbie user may not repair broken login himself and/or dont know how to drop root console at boot.

   I see to much complaints about broken login caused by "login managers" on forums.

* So how about a self contained statically linked tui/gui app that cant depends anythink in system.

FYI: there are a handfull single file/header tui/gui stuffs on codeberg, github ...

I suspect we copied similar ideas around the web
for comparison

see man invoke-run(8) and /lib/runit/invoke-run script (instead of sourcing, it's an interpreter that exec into the run file)

in the runit Devuan/Debian package we ship /etc/sv/svlogd/run, same concept as yours (to be symlinked in each service's log dir)

and /lib/runit/finish-exec ;
usage examples for the above 3 are in services in the runit-services package.

Again I agree: in fact invoke-run and finish-exec supports printing start/stop messages, but you need to touch a flag file in /etc (/etc/runit/verbose)

Yes it's of interest I'll see if this can be included in runit-services; getting network right for distribution is not that easy because you
have to account for different setups (sometimes in conflict/not compatible with each other); in case, is it ok if I
credit you as 'freem' (do you want ot add an address - beware the spam-  or a full name?) ?

Now about udev/eudev: the main problem is that it has to be started early at boot (as a oneshot, when the supervision tree is not active yet).
So, in order to supervise it in a run script we need to stop it and restart it inside the runit service; I saw this done in Void, not sure if ther are races during startup.
Do you start udevd early during boot , then  stop it and restart it in the runscript? If yes, are there any issues such as races due to udev not being up when the supervision tree starts all services? Do you have any runit service that depends on udevd?

Also, there is the same problem at shutdown; usually udevd is stoped very late during shutdown (later than other services); I'm not sure this is actually necessary, because, in theory, I think, we don't need to react on devices event at shutdown. But I'm not sure if it creates problems to shutdown without udevd running; again do you observe any issues, such as an unclean shutdown?
Issues with filesystem at next boot?

Best, Lorenzo

It's now been forked and called vstbridge. It can be found here  https://sourceforge.net/projects/vstbridge/

https://github.com/WeirdGnome/AppImage-Installer

Btw, at present my .asoundrc says this:

pcm.!default {
        type sndio
}

I wonder if its possible to enable both cards at the same time.  It would be peculiar though.

Deb package to follow soon, this is very new and testing is just getting started.

The general consent seems to be: Don't do it!

And I will not.

Maybe I'll try a VM or a disposable installation sometime.

The suggested deadbeaf deb-package form sourceforge works so far on freia. Main reason to install it were two plugins: "musical-spectrum" for spectral lines by notes and "spectrogram", which draws a logarithmic sonogram (impressiv, if you like such things).

Intersting to hear that some distributions officially include deb-multimedia.
Also will keep in mind to eventually pick isolated packages by having the repo temporarily enabled.

Again, thanks for the detailed posts.

Just for giggles I tried it on Mate last night and yeah it installed fine and worked great up until I hit that Apply button...it was a hoot, it actually tried to apply the paper but only like a quarter of it laid over the previous wallpaper.