1. 4

    I value external inputs such as technical discussions and user experience returns immensely

    I, for one, really hope this iteration of s6 will not depend on the authors personal collection of useful functions / djb-style NIH libc reimplementation (“skalibs”).

    Otherwise I have nothing but appreciation for the great amount of work put into s6. s6 is art. Together with apkv3 I will finally have enough reasons to switch all my machines from Void to Alpine.

    1. 2

      hope this iteration of s6 will not depend on the authors personal collection of useful functions / djb-style NIH libc reimplementation (“skalibs”)

      Why not? Many parts of libc are fraught.

      1. 1

        Because I don’t want every application authors’ take on which parts are fraught to end up on my system in the form of a shared library (distributions still haven’t figured out that static linking is the way to go).

      2. 2

        s6 is art

        Maybe I’m not good at appreciating art, but every time I look at s6 I’m like “why is this so much more complex than runit??”

      1. 4

        TempleOS only only runs one app at a time, the logic being that a human can only concentrate at only one thing at a time. There is no need to have multitasking, but sometimes an app would benefit additional processing power, so TempleOS can do multi-core processing by having a master-slave model: The main CPU can control the other CPU’s and hand out tasks to them.

        And while we think about crazy OS ideas: Why not run multiple independent kernels - one on every CPU? So while a rouge process could corrupt and take down one kernel the rest of the system would continue working.

        1. 6

          TempleOS can do multi-core processing by having a master-slave model: The main CPU can control the other CPU’s and hand out tasks to them.

          Classic Mac OS did this.

          And while we think about crazy OS ideas: Why not run multiple independent kernels - one on every CPU? So while a rouge process could corrupt and take down one kernel the rest of the system would continue working.

          This kinda exists already; galaxies in VMS achieve virtualization this way, I believe. Running multple OS instances could be useful for the Erlang OS mentioned though, especially since the concepts could make it transparent.

          1. 2

            Classic Mac OS did this.

            I forgot that the MDD dual G4 models could still boot Mac OS 9. I’m reasonably certain those shipped after OS X came out of beta, though, and could only boot OS 9 because it was (only slightly) too early to stop that.

            Were there other multi CPU macs that booted classic Mac OS?

            1. 7

              They made a bunch of SMP addons and even systems in the 90s. It was pretty much entirely to speed up gaussian blurs in Photoshop.

          2. 2

            You are describing unikernels.

            From my perspective it’s less about the human and more about the fact that most companies don’t run one computer or even one database - they run thousands. We are long past the “one operating system / computer” phase. Even the smallest companies are load balancing their webservers amongst multiple vms. We need new operating systems to facilitate this.

            1. 3

              I think on a personal level, nobody has only one device anymore (desktop/laptop/phone/tablet/smartwatch/e-reader/smart-TV/home-automation-stuff/home-server-possibly) and we need a good unified system for handling this, instead of pretending they’re all islands that just happen to communicate sometimes, with integration an afterthought.

            2. 2

              Why not run multiple independent kernels - one on every CPU?

              This has been explored in research. Check out http://www.barrelfish.org/

              1. 1

                And while we think about crazy OS ideas: Why not run multiple independent kernels - one on every CPU? So while a rouge process could corrupt and take down one kernel the rest of the system would continue working.

                Check out rump kernels in NetBSD probably not same idea but it can be achieved

                1. 1

                  And while we think about crazy OS ideas: Why not run multiple independent kernels - one on every CPU? So while a rouge process could corrupt and take down one kernel the rest of the system would continue working.

                  HydrOS did this (and it was a BEAM OS).