Re: [DNG] Systemd depends on random numbers in order to work properly
On Mon, 08 Jul 2019 17:35:19 +0200, Martin wrote in message <1898883.rvtoQVDO1o@merkaba>: > Hi! > > Just another reason I am happy to use sysvinit on my systems. > > unblock: systemd/241-4 > https://bugs.debian.org/929215 > > Booting system should not depend on random numbers to be available in > a large enough quantity. > > Granted there is a processor bug involved… but why rely on the random > number generator of CPUs anyway? > > Thanks, ..I got curious, 'n chk'ed https://bugs.debian.org/927008 and duckducked "systemd-journal-remote", and learned they have 3? different log file formats?: 8oD https://www.freedesktop.org/wiki/Software/systemd/journal-files/ https://www.freedesktop.org/wiki/Software/systemd/export/ https://www.freedesktop.org/wiki/Software/systemd/json/ https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html __CURSOR=, __REALTIME_TIMESTAMP=, __MONOTONIC_TIMESTAMP= ..anyone heard of anyone working on ways to read these 3 formatted systemd logs files, e.g. with non-systemd log servers? .."if" somebody cracks the systemd market "infrastructure" and they have no plan B etc, they are going to bleed Bigly trying to come up with a way to e.g. read their own logs. Etc. ..we've heard etc ;o) about /etc/machine-id, but __CURSOR=, __REALTIME_TIMESTAMP=, __MONOTONIC_TIMESTAMP= etc are ALSO logged, if I can believe their https://www.freedesktop.org/wiki/Software/systemd/export/ ..first time I heard of anything like "_MONOTONIC_", was on Stalinist style "re-education camp" victims. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Server updated to Devuan Beowulf
On 2019-07-08 16:23, Martin Steigerwald wrote: goli...@devuan.org - 08.07.19, 23:11: On 2019-07-08 16:00, Martin Steigerwald wrote: > After release of Debian 10 aka Buster I just upgraded my new 64-Bit > Devuan server from Ascii to Beowulf. The server provides mail, web > and some other services. > > What can I say? > > It just worked. > > Only thing was that for Quassel IRC I had to use "aa-disable > quassel- > core" to disable AppArmor. Otherwise it would not be allowed to > access TLS certificate and config file¹. I believe it may make > sense to forward > this issue to the Debian bug tracker, as I do not think Devuan plays > a huge role here. Of course it could be something about using the > init script instead of systemd service to start up Quassel IRC > Core. > > [1] quassel-core: no permission to open certificate file, cannot > write quasselcore configuration > https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 It looks like Devuan is not at all involved so the conversation should probably be with Debian: https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=quassel-core&; release=any https://git.devuan.org/devuan-packages?utf8=%E2%9C%93&filter=quassel-c ore Thanks. I bet I report with Debian as well then. I just used reportbug on the server VM and that reported to bugs.devuan.org. Only thing may be that init script does something different than Systemd service and that would trigger the issue. But since quassel-core in Debian provides the init script I can still file a bug with Debian. Thanks, Congrats on the smooth upgrade BTW. That's good news all around! And thanks for the followup with Debian. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Server updated to Devuan Beowulf
goli...@devuan.org - 08.07.19, 23:11: > On 2019-07-08 16:00, Martin Steigerwald wrote: > > After release of Debian 10 aka Buster I just upgraded my new 64-Bit > > Devuan server from Ascii to Beowulf. The server provides mail, web > > and some other services. > > > > What can I say? > > > > It just worked. > > > > Only thing was that for Quassel IRC I had to use "aa-disable > > quassel- > > core" to disable AppArmor. Otherwise it would not be allowed to > > access TLS certificate and config file¹. I believe it may make > > sense to forward > > this issue to the Debian bug tracker, as I do not think Devuan plays > > a huge role here. Of course it could be something about using the > > init script instead of systemd service to start up Quassel IRC > > Core. > > > > [1] quassel-core: no permission to open certificate file, cannot > > write quasselcore configuration > > https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 > It looks like Devuan is not at all involved so the conversation should > probably be with Debian: > > https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=quassel-core&; > release=any > > https://git.devuan.org/devuan-packages?utf8=%E2%9C%93&filter=quassel-c > ore Thanks. I bet I report with Debian as well then. I just used reportbug on the server VM and that reported to bugs.devuan.org. Only thing may be that init script does something different than Systemd service and that would trigger the issue. But since quassel-core in Debian provides the init script I can still file a bug with Debian. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Server updated to Devuan Beowulf
On 2019-07-08 16:00, Martin Steigerwald wrote: Hi. After release of Debian 10 aka Buster I just upgraded my new 64-Bit Devuan server from Ascii to Beowulf. The server provides mail, web and some other services. What can I say? It just worked. Only thing was that for Quassel IRC I had to use "aa-disable quassel- core" to disable AppArmor. Otherwise it would not be allowed to access TLS certificate and config file¹. I believe it may make sense to forward this issue to the Debian bug tracker, as I do not think Devuan plays a huge role here. Of course it could be something about using the init script instead of systemd service to start up Quassel IRC Core. [1] quassel-core: no permission to open certificate file, cannot write quasselcore configuration https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 Thanks, It looks like Devuan is not at all involved so the conversation should probably be with Debian: https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=quassel-core&release=any https://git.devuan.org/devuan-packages?utf8=%E2%9C%93&filter=quassel-core golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Server updated to Devuan Beowulf
Hi. After release of Debian 10 aka Buster I just upgraded my new 64-Bit Devuan server from Ascii to Beowulf. The server provides mail, web and some other services. What can I say? It just worked. Only thing was that for Quassel IRC I had to use "aa-disable quassel- core" to disable AppArmor. Otherwise it would not be allowed to access TLS certificate and config file¹. I believe it may make sense to forward this issue to the Debian bug tracker, as I do not think Devuan plays a huge role here. Of course it could be something about using the init script instead of systemd service to start up Quassel IRC Core. [1] quassel-core: no permission to open certificate file, cannot write quasselcore configuration https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
On Mon, 08 Jul 2019 11:03:36 +0200 Martin Steigerwald wrote: > viverna - 06.07.19, 15:58: > > il devuanizzato Steve Litt il > > 06-07-19 > 07:24:37 ha scritto: > > >> Instead it's possible > > >> inject in all daemon's install a piece of posix shell? > > >> Workaround script on event "DPkg::Post-Invoke" as I said in the > > >> previous email? > > > > > >You know much more than I do about packaging. Given something like > > >event "DPkg::Post-Invoke", all it would need to do is call a > > >shellscript, with the argument of the daemon name, and the > > >shellscript could make the necessary symlinks or whatever. All the > > >heavy lifting would still be done in the runit-runscripts > > >package. > > > > Put my code here. > > > > Work for epoch init system but it is adaptable to any other such as > > runit, s6 and so on... > > Thanks a lot for your code contribution > > I was not even aware of epoch init system. > > https://universe2.us/epoch.html > > https://universe2.us/epochconfig.html I'm not sure Epoch is still being maintained, but when I used it it was an outstanding init system. I wrote about it here: http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#pure_epoch_init_system and here http://www.troubleshooters.com/linux/init/manjaro_experiments.htm#getting_epoch_running First, it's pure, 100% serial instantiation[1]. No "parallel" instantiation, so things like process prerequisites are handled simply by the ordering of the "objects" (like systemd unit files) within the config file. You might think serial instantiation would be slow, but that wasn't my experience. Epoch booted faster than runit or sysvinit. I was able to set up systemd to boot faster, but it took some doing,and do systemd wrong and it makes sysvinit look supersonic. Epoch is easy for anyone to understand, and is configurable by a user with a minimum of muss and fuss. [1] Epoch has a FORK ObjectOption that appears to be able to run a given service concurrently with the rest of the init process. Might be handy for stuff expected to take a long time. I've used runit for 4 years and am used to it and love it, but for certain simple setups, Epoch is wonderful. SteveT Steve Litt July 2019 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ascii netinstall problems
On 2019-07-08 17:24, aitor_czr wrote: Hi m_maass, On 8/7/19 17:41, m_maass wrote: Dear Friends, i want to install ascii with packages.devuan.org/devuan/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz As far as i know, the "packages.devuan.org" repository is deprecated. Did you try with "deb.devuan.org"? That is: http://deb.devuan.org/devuan/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz Cheers, Aitor. ___ According to these pages auto.mirror.org was the default repo for jessie. Early on before the jessie release some folks were using packages (I can't remember for what reason). https://devuan.org/os/ https://devuan.org/os/etc/apt/sources.list golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Systemd sd_notify(): was Runit service depend another script not daemon
On Mon, 08 Jul 2019 10:54:58 +0200 Martin Steigerwald wrote: > Steve Litt - 07.07.19, 01:26: > > I can't think of anything I or anyone could do, regarding runit > > runscripts, that would adversely affect sysvinit. As far as systemd, > > runit and s6 are never going to use the systemd mechanism by which > > service A tells systemd that it's loaded, but if someone switched > > back to systemd, that mechanism will still be there. > > Why? Currently my package supports both systems with sysvinit as well > as systemd. There are different debhelper commands for that. I'd > imagine that would work with runit as well. Your contention and mine don't contradict: They say the same thing: There's nothing inherent in runit or s6 that would sabotage one's moving to sysvinit or systemd for init purposes. The "systemd mechanism by which service A tells systemd that it's loaded" I mentioned is sd_notify(), described at: https://www.freedesktop.org/software/systemd/man/sd_notify.html# The only thing I was saying is that s6 and runit and sysvinit don't use sd_notify(), so their methods for detecting the functionality of a needed prerequisite process or state are different from sd_notify(), and if one used those methods anywhere but run scripts, they'd need to be changed out for systemd (or not: They'd actually work for systemd too). There's nothing inherent in s6 or runit that would "seal out" other inits. In fact, I'm a big proponent of having all the inits installed at the same time, so if you need to switch inits, short term you edit grub, long term you rename the PID1 executable. I've had cases where I borked an init system, and I was darn glad I had a second, working init system to boot to. SteveT Steve Litt July 2019 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ascii netinstall problems
Hi m_maass, On 8/7/19 17:41, m_maass wrote: Dear Friends, i want to install ascii with packages.devuan.org/devuan/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz As far as i know, the "packages.devuan.org" repository is deprecated. Did you try with "deb.devuan.org"? That is: http://deb.devuan.org/devuan/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz Cheers, Aitor. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
il devuanizzato Hendrik Boom il 08-07-19 18:59:00 ha scritto: Epoch is an init system very interesting. Syntax config file it's declarative like systemd. Don't exist dependency between objects but only prority (it may be strange in the beginning). I like scriptable init system (for example runit) however it's simple (more simple than runit) make your init environment and collection of objects with epoch init system. It's easy intersperse daemon and not daemon. The epoch documentation links are correct. The documentation is detailed. I discover epoch reading Steve Litt's "Manjaro Experiment" documentation. From what I know, epoch is packaged by gentoo folks. It should not be difficult considering small size and simplicity, make package for Devuan. I have a small subset of objects (entity to be managed in epoch) and i will be very happy to share with you. Is epoch capable of running as a service starter or manager if another init system starts the system? -- hendrik I think it's not possible. Epoch should be at the same time init system and service management. -- viverna ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..so Debian is Busting postgresql, evolution-ews inboxes and history itself?, was: Runit service depend another script not daemon
On Mon, 08 Jul 2019 11:00:27 +0200, Martin wrote in message <9089233.Yakf2O1BWr@merkaba>: > Arnt Karlsen - 07.07.19, 16:29: > > ..another motive in town?: > > 5.3.7. evolution-ews has been dropped, AND EMAIL INBOXES USING > > EXCHANGE, OFFICE365 OR OUTLOOK SERVER WILL BE REMOVED: > > https://www.debian.org/releases/buster/amd64/release-notes/ch-informat > > ion.en.html#evolution-and-exchange > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926712#19 > > The alternative would be to include an evolution-ews plugin that does > not check for any TLS errors nor verifies certificates. > > I certainly can understand the decision to remove the package from > testing. > > Its also mentioned in the release notes: > > https://www.debian.org/releases/buster/amd64/release-notes/ch-information.de.html#evolution-and-exchange > > Maybe it would have been good to delay the release… ..agreed, I suspect the Raspbian Buster release to support the Raspberry Pi 4, became a factor. > but on the other > hand: I would not recommend to anyone using Office 365. Unfortunately > at work I am not given a choice. > > Also it could probably be added back later at least as backport. ..meanwhile, it appears we have a profitable data recovery etc support business opportunity handy on people burned by Debian's move on their Microsoft Office 365 etc clientele. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Ascii netinstall problems
Dear Friends, i want to install ascii with packages.devuan.org/devuan/dists/jessie/main/installer-amd64/current/images/netboot/netboot.tar.gz The installation stop with this Error: anna-install: Queueing udeb ascii-support for later installation main-menu[2681]:DEBUG: resolver(libc6-udeb):package doesn exist (ignored) main-menu[2681]:INFO: Menu item 'download-installer' selected net-retriever:gpgv: md_enable: algorithm 10 not available net-retriever:gpgv: Signature made Sat Jul 6 23:50:26 UTC using RSA key ID 61FC752C net-retriever:gpgv: Can't check signature; checksum digest algorithm net-retriever:Error: Bad signature on /tmp/net-retriever-4250-Release. Can someone please help? Also the SSL Certificate for packages.devuan.org uses an invalid security certificate. The certificate expired on January 22, 2019, 10:05 PM. The current time is July 8, 2019, 10:48 AM. Error code: SEC_ERROR_EXPIRED_CERTIFICATE packages.roundr.devuan.org uses an invalid security certificate. The certificate is only valid for pkgmaster.devuan.org Error code: SSL_ERROR_BAD_CERT_DOMAIN Thank You, Mike ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
On Mon, Jul 08, 2019 at 06:33:02PM +0200, viverna wrote: > il devuanizzato Martin Steigerwald il 08-07-19 11:03:36 > ha scritto: > > viverna - 06.07.19, 15:58: > > > Put my code here. > > > > > > Work for epoch init system but it is adaptable to any other such as > > > runit, s6 and so on... > > > > Thanks a lot for your code contribution > > > > I was not even aware of epoch init system. > > > > https://universe2.us/epoch.html > > > > https://universe2.us/epochconfig.html > > > > Hmmm… > > > > -- > > Martin > Epoch is an init system very interesting. Syntax config file it's > declarative like systemd. Don't exist dependency between objects but only > prority (it may be strange in the beginning). > I like scriptable init system (for example runit) however it's simple (more > simple than runit) make your init environment and collection of objects with > epoch init system. It's easy intersperse daemon and not daemon. > The epoch documentation links are correct. The documentation is detailed. I > discover epoch reading Steve Litt's "Manjaro Experiment" documentation. > From what I know, epoch is packaged by gentoo folks. It should not be > difficult considering small size and simplicity, make package for Devuan. I > have a small subset of objects (entity to be managed in epoch) and i will be > very happy to share with you. Is epoch capable of running as a service starter or manager if another init system starts the system? -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
il devuanizzato Martin Steigerwald il 08-07-19 11:03:36 ha scritto: viverna - 06.07.19, 15:58: Put my code here. Work for epoch init system but it is adaptable to any other such as runit, s6 and so on... Thanks a lot for your code contribution I was not even aware of epoch init system. https://universe2.us/epoch.html https://universe2.us/epochconfig.html Hmmm… -- Martin Epoch is an init system very interesting. Syntax config file it's declarative like systemd. Don't exist dependency between objects but only prority (it may be strange in the beginning). I like scriptable init system (for example runit) however it's simple (more simple than runit) make your init environment and collection of objects with epoch init system. It's easy intersperse daemon and not daemon. The epoch documentation links are correct. The documentation is detailed. I discover epoch reading Steve Litt's "Manjaro Experiment" documentation. From what I know, epoch is packaged by gentoo folks. It should not be difficult considering small size and simplicity, make package for Devuan. I have a small subset of objects (entity to be managed in epoch) and i will be very happy to share with you. -- viverna ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
Hendrik Boom - 08.07.19, 16:56: > On Mon, Jul 08, 2019 at 10:54:58AM +0200, Martin Steigerwald wrote: > > Steve Litt - 07.07.19, 01:26: > > > On Sat, 06 Jul 2019 08:49:52 +0200 > > > > > > Martin Steigerwald wrote: > > > > So I believe it is good to let go of any drama and fear and just > > > > get > > > > on with actually doing something to improve runit / s6 support. > > > > > > Well, if I were to help integrate runit and s6 into Devuan either > > > directly or through Debian, would it really matter if my incentive > > > included drama and fear? > > > > For me it does. > > > > The fear may tell me that it is keeping me safe. My own direct > > experience through letting go tells something different however: > > Fear > > keeps me stuck. With fear I give my power away to what I imagine > > would be stronger than me. Like in your case, I dramatize a bit: > > "big large evil commercial corporations". > > > > What if I just let go of the fear instead? Or welcome it and then > > move on which is basically the same. It is just a feeling. It is > > not the truth. > > This sounds like Franl Herbert's Bene Gesserit litany against fear: > > Fear is the mind-killer . I do not know this one. Was it too much of a lecture for you? Well then please just disregard it. It is not my job to educate others without them asking for it. It appears I am still learning this. We are all in this human experience together. In the past I have also not been exempt from feeling fear and I may feel fear again. I am determined to welcome it and let it go whenever it arises. So Steve and everyone else, feel free to do or not do anything with what I wrote. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Systemd depends on random numbers in order to work properly
Hi! Just another reason I am happy to use sysvinit on my systems. unblock: systemd/241-4 https://bugs.debian.org/929215 Booting system should not depend on random numbers to be available in a large enough quantity. Granted there is a processor bug involved… but why rely on the random number generator of CPUs anyway? Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
On Mon, Jul 08, 2019 at 10:54:58AM +0200, Martin Steigerwald wrote: > Steve Litt - 07.07.19, 01:26: > > On Sat, 06 Jul 2019 08:49:52 +0200 > > > > Martin Steigerwald wrote: > > > > So I believe it is good to let go of any drama and fear and just get > > > on with actually doing something to improve runit / s6 support. > > > > Well, if I were to help integrate runit and s6 into Devuan either > > directly or through Debian, would it really matter if my incentive > > included drama and fear? > > For me it does. > > The fear may tell me that it is keeping me safe. My own direct > experience through letting go tells something different however: Fear > keeps me stuck. With fear I give my power away to what I imagine would > be stronger than me. Like in your case, I dramatize a bit: "big large > evil commercial corporations". > > What if I just let go of the fear instead? Or welcome it and then move > on which is basically the same. It is just a feeling. It is not the > truth. This sounds like Franl Herbert's Bene Gesserit litany against fear: Fear is the mind-killer . -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
viverna - 06.07.19, 15:58: > il devuanizzato Steve Litt il 06-07-19 07:24:37 ha scritto: > >> Instead it's possible > >> inject in all daemon's install a piece of posix shell? > >> Workaround script on event "DPkg::Post-Invoke" as I said in the > >> previous email? > > > >You know much more than I do about packaging. Given something like > >event "DPkg::Post-Invoke", all it would need to do is call a > >shellscript, with the argument of the daemon name, and the > >shellscript could make the necessary symlinks or whatever. All the > >heavy lifting would still be done in the runit-runscripts package. > > Put my code here. > > Work for epoch init system but it is adaptable to any other such as > runit, s6 and so on... Thanks a lot for your code contribution I was not even aware of epoch init system. https://universe2.us/epoch.html https://universe2.us/epochconfig.html Hmmm… -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..so Debian is Busting postgresql, evolution-ews inboxes and history itself?, was: Runit service depend another script not daemon
Arnt Karlsen - 07.07.19, 16:29: > ..another motive in town?: > 5.3.7. evolution-ews has been dropped, AND EMAIL INBOXES USING > EXCHANGE, OFFICE365 OR OUTLOOK SERVER WILL BE REMOVED: > https://www.debian.org/releases/buster/amd64/release-notes/ch-informat > ion.en.html#evolution-and-exchange > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926712#19 The alternative would be to include an evolution-ews plugin that does not check for any TLS errors nor verifies certificates. I certainly can understand the decision to remove the package from testing. Its also mentioned in the release notes: https://www.debian.org/releases/buster/amd64/release-notes/ch-information.de.html#evolution-and-exchange Maybe it would have been good to delay the release… but on the other hand: I would not recommend to anyone using Office 365. Unfortunately at work I am not given a choice. Also it could probably be added back later at least as backport. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
Steve Litt - 07.07.19, 01:26: > On Sat, 06 Jul 2019 08:49:52 +0200 > > Martin Steigerwald wrote: > > Steve Litt - 06.07.19, 07:24: […] > > There is the debian-init-diversity group where Debian and Devuan > > people work together. Back then I helped to bring that forward and > > there is still a lot of activity. > > Thank you for that. Regardless of the final outcome, you did something > important in undoing the savage mistakes of late 2014. A lot of > people talk: You did something, and the something you did might > benefit all of us. Thanks. […] > [snip sysvinit, insserv and startpar bug fixes] > > My feeling that sysvinit is not in safe hands in the Debian project > isn't based on the quality of sysvinit or its components. As a matter > of fact, I never noticed any bugs or weird stuff with sysvinit during > the 13 years I used sysvinit as my daily driver init (with occasional > forays into upstart and daemontools). My feeling is based on: > > 1) Corporate profit motive for keeping systemd the only init in town. > > 2) The (insert your own noun epithet) of "FreeDesktop.Org". > > 3) Systemd's technological ability to sabotage all attempts at >alt-initting a computer. > > 4) The huge moving-target workload necessary because of #3. > > 5) See the response to your next statement... For me this is just a feeling. Not facts. While I certainly can relate to the fear, I also know that up to now Debian is still a 100% community project. Does it mean that it absolutely cannot by manipulated by commercial actors? No. But I'd rather not anticipate something happening by putting a lot of energy, for example in the form of fear, into it. If I do not like it to happen, then I am sure I am better off not to give energy to it. And if it still happens I can act then. None of what you stated above is here right now. Fact is, that Debian can be run just fine – again! – without Systemd in most of the circumstances. > > While Debian project for now will keep the libsystemd0 dependency on > > a lot of packages > > Which makes libsystemd0 the ideal kill switch for init diversity. One > might ask who would be so mean as to kill init diversity within > Debian? For a list of such people, see the original decision: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 Nope, I won't. Reason is as simple as stated above: I'd give energy into something I do not choose as a possible future. Thus I'd rather use my time to help to bring forward the future I like to see to the best of my ability. […] > > So: If you like to provide runit support for fio Debian package, > > please go ahead. As long as the runit support is implemented in a > > way > > that the existing start support for sysvinit – which I implemented > > back then – and systemd still works as well, and you tested the > > runit > > support, I gladly accept a merge request. I'd even make some effort > > to put it into the package itself, in case you provide something to > > me, in case you are not familiar with forking a git repo and > > providing a merge request. > > I can't think of anything I or anyone could do, regarding runit > runscripts, that would adversely affect sysvinit. As far as systemd, > runit and s6 are never going to use the systemd mechanism by which > service A tells systemd that it's loaded, but if someone switched back > to systemd, that mechanism will still be there. Why? Currently my package supports both systems with sysvinit as well as systemd. There are different debhelper commands for that. I'd imagine that would work with runit as well. > > So I believe it is good to let go of any drama and fear and just get > > on with actually doing something to improve runit / s6 support. > > Well, if I were to help integrate runit and s6 into Devuan either > directly or through Debian, would it really matter if my incentive > included drama and fear? For me it does. The fear may tell me that it is keeping me safe. My own direct experience through letting go tells something different however: Fear keeps me stuck. With fear I give my power away to what I imagine would be stronger than me. Like in your case, I dramatize a bit: "big large evil commercial corporations". What if I just let go of the fear instead? Or welcome it and then move on which is basically the same. It is just a feeling. It is not the truth. However now I let go of wanting to control your experience. You may invent as much drama and fear as you'd like. I just won't take part in that. I bet I may just have replied cause all the near conspiracy-theory drama and fear stuff here and else sometimes just gets on my nerves. But can I let this go as well? Can I let go of wanting to give my power away as to whether apparent other(s) play the game of drama and fear or not? Yes. Thank you, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing sysv-init under Debian Buster
If there can be a convergence on this topic, I think it might be useful addition to the Devuan FAQ, relevant as it concerns init freedom. Q: I'm not ready to move to Devuan yet. Can I setup Debian to use sysvinit instead of systemd? A: For Buster (Debian's current stable distribution) the following steps are suggested. apt install -y sysvinit-core elogind apt --purge autoremove [Answers for Jessie, other releases] -- Joel Roth "Welcome to the World Heat Bank, where we store your waste energy and return it with interest." ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
