Announcement

Collapse
No announcement yet.

Debian May Need To Re-Evaluate Its Interest In "Init System Diversity"

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Originally posted by cb88 View Post

    I do this on Gentoo... but yeah, I may give MX Linux a try... I have downloaded antiX in the past... many moons ago.
    MX is nice, but I actually prefer antiX with Xfce installed from the repository.

    Comment


    • #92
      So, replacing init was tough and complicated.
      I wonder, how tough and complicated it will be, when systemd eventually needs to be replaced?
      I hope not i-m-p-o-s-s-i-b-l-e, because that's an alternate spelling for r-o-a-d-b-l-o-c-k.

      Comment


      • #93
        Idiots at work: read the word "diversity" and start supporting the idea because "diversity" means something good.

        Comment


        • #94
          Originally posted by bison View Post

          MX is nice, but I actually prefer antiX with Xfce installed from the repository.
          Yeah, antiX is quite likely the best performing, easiest to use distro I've ever tried. I'm just sorry that it took me so many years to find it. If it is maintained and updated in its current form, which there's no reason to believe it won't be, I think I've found a distro home for years to come.

          Comment


          • #95
            Originally posted by starshipeleven View Post
            Systemd API is public and documented. If other init systems want to implement it they can.
            You see.. that is exactly the problem..
            A project looking only to its belly.. that is not a standard

            A standard is something that is agreed by several projects.. that is a open API.

            Comment


            • #96
              Originally posted by discordian View Post
              shell scripts are fragile, and few of them are tested with multiple shells and non-standard tools (busybox userspace, hush/ash shell).
              I don't understand your comment..
              If you for example, have a bash script, why does you want it to run with hush/ash shells?

              Does you run java programs in a Python vm, or otherwise?
              because a lot of scripts are created to work so so, in different shells doesn't mean they need to be compatible with all shells..

              you just need to use the correct one for the job..
              The same applies to other language/vms, etc..

              Comment


              • #97
                Originally posted by sandy8925 View Post
                True, the ability to have multiple applications play audio streams simultaneously, the ability to easily move streams to different devices is awesome! I could do that in 2009, on KDE 4 with a simple GUI, almost 9 years before Windows finally introduced equivalent capabilities.
                Uh, playing audio streams concurrently is something that worked pretty much forever (that is, '96 on Windows 95, and '03 with alsa dmix).

                Comment


                • #98
                  Originally posted by jrch2k8 View Post

                  Well, i worked through the years with many OSes all the way from Caldera/SCO to Solaris and recently to Archlinux(since 2012 i think) and i have enough experience with filesystems to trust ZFS with my life. I did try BTRFS several times through the years and honestly is not even on the same league as ZFS is for me because it lacks many features i consider tier 1 (like proper RAID 6/0+ for example) and compared to ZFS is quite easy to make it unusable and also it doesn't work properly with virtualization(huge no no for my workflow).

                  I did use FreeBSD from 4.3 up to 10(i still use FreeBSD derived tools like opnsense firewall tho) quite commonly on my workflow(as i did use hardened openBSD a lot) but since systemd 100+ i replaced them all with ArchLinux throughout the years and honestly once you do understand how systemd works is better than anything you can find and easier than anything you can find even windows and apple systems(an boy i did use launchd a loooot same as Solaris SMF).

                  The level of reproducibility, automation and resource management/security systemd provides is unique specially if you are a developer with enough skill to work with DBUS.

                  Now i do agree with you in the sense most Linux distros just barely use the power of systemd and many for lazyness or lack of taking 5 minutes to read the documentation just add some very idiotic defaults and call it a day that have given argument to the regular haters and i do admit that systemd may seem overkill for someone who wanna just push power on and open firefox and have a minimal understading how code/security works making it seems like systemd use gigabytes of RAM and bloat your hard drives, etc ,etc etc. when in reality is not even close to how it works but yeah FreeBSD is a good OS as Linux is, just use what you can understand better for your workflow and thats it
                  I do know systemd. I'm a sysadmin. If find it's syntax to be revolting and a difficult way to do things. I tend to avoid it as much as possible when there are other ways to accomplish the same thing. (supervisord job control etc) Helps me keep my sanity.

                  Comment


                  • #99
                    Originally posted by k1e0x View Post
                    I do know systemd. I'm a sysadmin. If find it's syntax to be revolting and a difficult way to do things. I tend to avoid it as much as possible when there are other ways to accomplish the same thing. (supervisord job control etc) Helps me keep my sanity.
                    supervisord is one of the tools I hate finding that people have used.
                    https://serverfault.com/questions/45...h-shell-script

                    You common end up having to deal with leaking child processes problem. Supervisord cgroup support is basically non existent. Yes the "How to propagate SIGTERM to a child process in a Bash script" instructions are unreliable on Linux this is the kind of hack you find people using supervisord users doing all the time.

                    If you don't want to use systemd fine. Use something else based around cgroups like docker so that service restart is reliable please.

                    Items like supervisord need to be put in the broken bin and left there or use a freebsd kernel. sysvinit, Runit, daemontools and supervisord operation pattern is not compatible with the way Linux kernel tracks child processes. The platform that are compatible to use Runit, daemontools and supervisord you don't have systemd. BSD based kernel child process tracking is required Runit, daemontools and supervisord to work right so freebsd, netbsd.... Yes Launchd is the same if you ported it to Linux without adding cgroup support it would be mega busted as well.

                    There is truly only a handful of service management things that work on Linux that don't leak child processes. Its fairly quick to sort once you work out there is no option bar to use cgroups due to the fact Linux kernel allows child processes to change every other associating value themselves with a parent.

                    Only way you can do a dependable SIGTERM walk on Linux is to have assigned cgroup value there is no other way hello kernel design limitation.

                    Comment


                    • Originally posted by oiaohm View Post

                      supervisord is one of the tools I hate finding that people have used.
                      https://serverfault.com/questions/45...h-shell-script

                      You common end up having to deal with leaking child processes problem. Supervisord cgroup support is basically non existent. Yes the "How to propagate SIGTERM to a child process in a Bash script" instructions are unreliable on Linux this is the kind of hack you find people using supervisord users doing all the time.

                      If you don't want to use systemd fine. Use something else based around cgroups like docker so that service restart is reliable please.

                      Items like supervisord need to be put in the broken bin and left there or use a freebsd kernel. sysvinit, Runit, daemontools and supervisord operation pattern is not compatible with the way Linux kernel tracks child processes. The platform that are compatible to use Runit, daemontools and supervisord you don't have systemd. BSD based kernel child process tracking is required Runit, daemontools and supervisord to work right so freebsd, netbsd.... Yes Launchd is the same if you ported it to Linux without adding cgroup support it would be mega busted as well.

                      There is truly only a handful of service management things that work on Linux that don't leak child processes. Its fairly quick to sort once you work out there is no option bar to use cgroups due to the fact Linux kernel allows child processes to change every other associating value themselves with a parent.

                      Only way you can do a dependable SIGTERM walk on Linux is to have assigned cgroup value there is no other way hello kernel design limitation.
                      I've heard that before, I've always found it reliable. (and yes you need to use it correctly, on the actual daemon process not a script.)
                      It's a bandaid anyhow.. if your services are dying unexpectedly there is something wrong with the system. (in my book maybe not yours)

                      I believe OpenRC implements this too but they also have their own called supervise-daemon. I'll watch it with my eyes before I trust systemd tho. lol

                      If you haven't figured it out yet.. I like simplicity. I want to run top on the box and see everything the system is doing in one page and know everything in there.
                      Last edited by k1e0x; 09-19-2019, 06:03 PM.

                      Comment

                      Working...
                      X