1. 31
  1.  

  2. 5

    There was an attempt for the Erlang thing, and Genode might be interesting for the second one I guess

    1. 3

      HydrOS (pdf slides) was an attempt to build a full-fledged Erlang OS, but seems to have also been abandoned.

      1. 2

        Also while I like a lot of things there from my limited understanding it could be too slow. Erlang isn’t slow per se, but if we’re talking stuff where even mode switches are too slow (say, network drivers) - I’m not sure where this OS would be useful.

        1. 2

          The advantage of architectures such as these is that you get process isolation ‘for free’ from the language semantics and type system, so you don’t need to use hardware isolation. Meaning that context switches are free.

          (I don’t know if hydros actually does this, but if it doesn’t it should.)

          1. 1

            you would keep mode switches fast and metal. Erlang would be used for things that are more sensitive and would benefit from reliability, like tracking shared resources (fds, sockets, etc).

          2. 1

            I heard it from someone in the community that the common failure mode of all of these things is that they eventually try to rewrite the erlang VM.

        2. 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).

                  2. 3

                    You might be thinking in the direction of so called “Single Image” Operating systems. Initially DragonFly BSD declared that to be one its goals. But, it seems, that that ambition is long gone.

                    There are many fascinating topics and approach there, interesting read would be also, this paper on MagnetOS

                    “… A Thread in MagnetOS is an execution context that can perform a sequence of synchronous event raises. It differs from threads in standard Java in that it is distributed over multiple nodes and can migrate from one node to another while Java threads are confined to a single node. Each Thread in MagnetOS has a unique identifier, which is crucial for the remote synchronization mechanism in MagnetOS .. “

                    Having addressable memory, threads, file systems that are hidden behind a cluster of machines that scale horizontally (and, perhaps, automagically, with auto-restart) built into OS and the programming environment – one day could eliminate a lot of the so called ‘cloud-enabling’ tools and architecture patterns.
                    With exception of ‘BSD jails’. :-) That’s a good concept that would work well on single image OS too!

                    When used Erlang years ago, it did feel like, it had that vision with ETS, mnesia, addressable processes, etc But perhaps, at the time lacked some functionality, tooling, ecosystem, theoretical framework and the polish around which operations and surrounding guarantees are available.

                    Also I doubt that automatically our solution could withstand network partitioning or node crashes.

                    May be I misunderstood your line of thinking, if yes, apologies for the diversion.

                    1. 2

                      Might be worth interesting to look at unikernels? One example being MirageOS - I think I remember a talk saying it was so quick that they could freshly boot to their app on every request. Although I’m guessing you wouldn’t want to do this for an OTP-style app, which emphasizes long running processes. Seems like there is a dead project called LING that wanted to do this for .beam files, and there’s a project called rumprun that claims to support Erlang, but activity on it seems low.

                      1. 2

                        We were able to get erlang, along with elixir working with Nanos https://github.com/nanovms/erlang && https://github.com/nanovms/ops-examples/tree/master/elixir and Nanos doesn’t just have daily activity - it has full time engineers working on it. (I’m with the project.)

                      2. 1

                        Looks like you’re down? I get “connection reset.”

                        1. 1

                          Works for me at the moment