Alternative fork about sct-daemon HOT 9 OPEN

yeh, i see, interesting, i implemented handling for sig hup and sig usr1 in a "fake async" manner but at no moment did i consider error checking, or logging... and i wanted to create a release of this, oh well more work to do!

from sct-daemon.

oh well, i've added a couple things which i think make behaviour a little better, next i will start with error checking and making sure the values from the config aren't complete nonsense

from sct-daemon.

Appreciate you guys keeping sct support alive, but I should mention, there is another more active fork that OpenBSD could make use of...
https://github.com/faf0/sct
Incidently, If I had known this existed before I would have ditched redshift much sooner. I assume runit and openrc can use this, potentially?

Either way, thanks for fighting against bloatware foolishness. :)

from sct-daemon.

Dunno about openrc but i imagine it works okay since i've seen this daemon work correctly on runit, tho i don't have a way to test that personally since i use devuan with sysvinit (i like some old school stuff okay) and for these kinds of daemons i rolled out my own user services manager-thing https://github.com/eylles/shed (still a proof of concept but made a release to get feedback)

from sct-daemon.

Dunno about openrc but i imagine it works okay since i've seen this daemon work correctly on runit, tho i don't have a way to test that personally since i use devuan with sysvinit (i like some old school stuff okay) and for these kinds of daemons i rolled out my own user services manager-thing https://github.com/eylles/shed (still a proof of concept but made a release to get feedback)
Actually, making it work for runit shouldn't be that much harder, nor should openrc.

Btw, runit supposedly is a similar level of minimalism to runit but without being so minimal that it is as frustrating to code for on the same level.

Also, runit has two parts I have used:

runit-init which is the init part and the service manager part for runit.

There are others, but usually those are for more fine grained info.

if you cannot figure out how to get it working, in runit, without multiple tests, you could use qemu.

Although, things might have changed since I used the guide I have now, but it usually works.

This is how I usually use qemu:

qemu-img create -f qcow2 an.img 60G
qemu-system-x86_64 -m 3072 -cdrom an.iso -boot d an.img --enable-kvm
qemu-system-x86-64 --enable-kvm an.img -cpu kvm64,+nx -m 4096 -device AC97

If your device has 8GB of ram, this should be fine unless your computer overheats and is slower than dual core gen 2 sandybridge.

If I have 16GB of ram and its ivy bridge, then I can use half if it has a quad core or at most double the last one, etc...

Anywho, point being, it is possible to test it easily, if I knew a way to transfer it to you, an easily built install of devuan, with runit, I definitely would, but it would be good, if I could figure out how to do so, without having to send a 2GB+ size image to you.

If could send a very tiny image that would be the best of all, given that with qemu, it can very easily be extended to the new size.

This is also possible with openrc, but the one I use is well, outdated because the newer openrc builds supposedly are getting too heavy for the developers who build my OS.

If you know @zapper on devuan forums, you might know why.

from sct-daemon.

got a little confused with your comment, but looking at the void linux documentation it seems rather straightforward to get per user services on runit https://docs.voidlinux.org/config/services/user-services.html

from sct-daemon.

got a little confused with your comment, but looking at the void linux documentation it seems rather straightforward to get per user services on runit https://docs.voidlinux.org/config/services/user-services.html

I did ramble a bit, so I understand.

It's a weakness of mine.

Btw, openrc isn't much harder either for devuan.

from sct-daemon.

Do you want me to make a new issue for the following btw?

Wondered if after you added runit and openrc functionality, you could make a stable release when it seems like its a good time, etc... If it will take a while, like beyond a 2 years, then its not a huge issue for me, because of specific plans the distro I am using has.

This is a requirement to get your package into some distros, etc... anything that focuses on a debian or devuan like focus, especially the second, has this mentality, as I am sure you well know. ;)

Mostly though, I am in no hurry even if you have the time. Not that this is a requirement, its up to you anyhow.

Thanks for keeping a K.I.S.S friendly option to the rust version and for not using go.

👍

Both are bloated, especially the rust version.

from sct-daemon.

well, now this sctd does check that the config has somewhat acceptable values, i gotta cap the MIN and MAX temp but that will be for later, so will be the logging...

from sct-daemon.