5 ms·

Apache Mesos is an OS??

nix23 4y ago
https://mesos.apache.org/ https://mesos.apache.org/ >Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines
- still_grokking 4y ago
  It's still not an OS in the classical sense. It's a regular user-mode executable. The idea is that it provides a kind of "virtual OS" to the applications build against it. But Mesos needs a regular OS as runtime on the nodes of the cluster.
  - skissane 4y ago
    > It's a regular user-mode executable. I don't think that necessarily excludes something from being an OS. Historically, a number of Unix ports ran as applications on top of a non-Unix. AT&T's early 1980s port of Unix to IBM S/370 mainframes, ran Unix as an application on top of IBM's TSS/370 operating system. [0] The Interdata 7/32 port done at Wollongong University in Australia, initially ran under Interdata's OS/32 operating system, although once the port had advanced sufficiently to run on bare metal, OS/32 was ripped out from under it. [1] The first versions of Cray's UNIX port, UNICOS, supported running as a guest under their earlier COS operating system (which was a batch processing operating system, modelled after that of CDC mainframes.) I still don't think Mesos counts though. Applications running under Mesos access resources by calling the Linux APIs; Mesos configures the Linux environment the application runs under, but at runtime it steps out of the way. If, hypothetically, Mesos had exposed its own API to applications running under it – separate from the Linux API, even if ultimately implemented using it – and forced them to use that rather than call the host OS APIs directly – then I would count it as an OS. But, that would be a rather different thing from what Mesos actually is. (And all those points apply to Kubernetes too.) With talk about WebAssembly as a container format – if you had something like Mesos/Auroroa/K8S/etc which ran WebAssembly containers only, so that applications running under it could only access WASI and other WebAssembly-based APIs – that would be closer to a true OS, even if it happened to run on top of the Linux kernel. You could swap out the Linux kernel for another – BSD, Windows, Illumos, XNU, GNU Hurd, L4, Fuschia, z/OS, whatever – and the apps shouldn't be able to tell the difference. [0] https://ieeexplore.ieee.org/document/6771917 https://ieeexplore.ieee.org/document/6771917 [1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
    - still_grokking 4y ago
      I think this is too broad of a definition. This would make more or less all VM runtimes "OSes". In a sense, they are "operating systems", yes, but it's more about how the APIs bind and constrain the applications that build on top of them. For that reason I call K8s "Windows for the cloud". But that's another story. I would say that, by a "strict definition", OS describes the software that runs on the metal, and operates all the different kinds of (application) runtimes and (OS) services under itself. A type 1 hypervisor would be by this definition an OS for example. But say a bare metal implementation of Doom would be not, I think, as it would not provide any implementation of a ("universal") app runtime. [Please don't say Doom is Turing complete. I hope not!] And Mesos? Mesos is really something else. It's a distributed "task manager". But even without a scheduler. Everything else should be provided by "frameworks". One could say Mesos is a kind of micro kernel for the data center (and the frameworks are the OS servers). But that is very figuratively speaking. Mesos is also less a "Windows for the cloud" compared to K8s because it supports different frameworks as runtimes. You can bring our own framework (or plugins for some existing). K8s on the other hand tries to be (more or less) "the one true" all encompassing API. Vendor lock-in works than as with Windows (or Linux, or macOS / iOS)^^.
      - skissane 4y ago
        > This would make more or less all VM runtimes "OSes". I argued that Mesos is not an OS because it exposes so much of the underlying host OS API - well, the same is true of most language runtime VMs. Java’s famous slogan was “write once run anywhere”, but in practice it exposes a huge amount of the host operating system, such that Java apps often end up with multiple code paths (even entirely separate classes) for different host platforms. The same is true for node.ha, Python, Perl, Ruby, Tcl, most Lisp implementations, etc But, imagine a language runtime which didn’t do that - that hid the host OS so well, apps written for it couldn’t know or care what the host OS was (or whether it was actually bare metal). Such a runtime would have greater claim to be an actual OS. Imagine a language runtime which included its own filesystem implemented in userspace - which was a single file on the host filesystem. Maybe it even has its own user space network stack, using TUN/TAP. It treats the host OS basically as a microkernel, only consuming a small subset of services provided by it (such as memory management). Hence you could swap the host OS for an actual microkernel running on bare metal and no app would notice. > I would say that, by a "strict definition", OS describes the software that runs on the metal Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS. Given all of this, I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”

https://mesos.apache.org/ https://mesos.apache.org/ >Apache Mesos abstracts CPU, memory, storage, and other compute resources away from machines

still_grokking 4y ago
It's still not an OS in the classical sense. It's a regular user-mode executable. The idea is that it provides a kind of "virtual OS" to the applications build against it. But Mesos needs a regular OS as runtime on the nodes of the cluster.
- skissane 4y ago
  > It's a regular user-mode executable. I don't think that necessarily excludes something from being an OS. Historically, a number of Unix ports ran as applications on top of a non-Unix. AT&T's early 1980s port of Unix to IBM S/370 mainframes, ran Unix as an application on top of IBM's TSS/370 operating system. [0] The Interdata 7/32 port done at Wollongong University in Australia, initially ran under Interdata's OS/32 operating system, although once the port had advanced sufficiently to run on bare metal, OS/32 was ripped out from under it. [1] The first versions of Cray's UNIX port, UNICOS, supported running as a guest under their earlier COS operating system (which was a batch processing operating system, modelled after that of CDC mainframes.) I still don't think Mesos counts though. Applications running under Mesos access resources by calling the Linux APIs; Mesos configures the Linux environment the application runs under, but at runtime it steps out of the way. If, hypothetically, Mesos had exposed its own API to applications running under it – separate from the Linux API, even if ultimately implemented using it – and forced them to use that rather than call the host OS APIs directly – then I would count it as an OS. But, that would be a rather different thing from what Mesos actually is. (And all those points apply to Kubernetes too.) With talk about WebAssembly as a container format – if you had something like Mesos/Auroroa/K8S/etc which ran WebAssembly containers only, so that applications running under it could only access WASI and other WebAssembly-based APIs – that would be closer to a true OS, even if it happened to run on top of the Linux kernel. You could swap out the Linux kernel for another – BSD, Windows, Illumos, XNU, GNU Hurd, L4, Fuschia, z/OS, whatever – and the apps shouldn't be able to tell the difference. [0] https://ieeexplore.ieee.org/document/6771917 https://ieeexplore.ieee.org/document/6771917 [1] http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/...
  - still_grokking 4y ago
    I think this is too broad of a definition. This would make more or less all VM runtimes "OSes". In a sense, they are "operating systems", yes, but it's more about how the APIs bind and constrain the applications that build on top of them. For that reason I call K8s "Windows for the cloud". But that's another story. I would say that, by a "strict definition", OS describes the software that runs on the metal, and operates all the different kinds of (application) runtimes and (OS) services under itself. A type 1 hypervisor would be by this definition an OS for example. But say a bare metal implementation of Doom would be not, I think, as it would not provide any implementation of a ("universal") app runtime. [Please don't say Doom is Turing complete. I hope not!] And Mesos? Mesos is really something else. It's a distributed "task manager". But even without a scheduler. Everything else should be provided by "frameworks". One could say Mesos is a kind of micro kernel for the data center (and the frameworks are the OS servers). But that is very figuratively speaking. Mesos is also less a "Windows for the cloud" compared to K8s because it supports different frameworks as runtimes. You can bring our own framework (or plugins for some existing). K8s on the other hand tries to be (more or less) "the one true" all encompassing API. Vendor lock-in works than as with Windows (or Linux, or macOS / iOS)^^.
    - skissane 4y ago
      > This would make more or less all VM runtimes "OSes". I argued that Mesos is not an OS because it exposes so much of the underlying host OS API - well, the same is true of most language runtime VMs. Java’s famous slogan was “write once run anywhere”, but in practice it exposes a huge amount of the host operating system, such that Java apps often end up with multiple code paths (even entirely separate classes) for different host platforms. The same is true for node.ha, Python, Perl, Ruby, Tcl, most Lisp implementations, etc But, imagine a language runtime which didn’t do that - that hid the host OS so well, apps written for it couldn’t know or care what the host OS was (or whether it was actually bare metal). Such a runtime would have greater claim to be an actual OS. Imagine a language runtime which included its own filesystem implemented in userspace - which was a single file on the host filesystem. Maybe it even has its own user space network stack, using TUN/TAP. It treats the host OS basically as a microkernel, only consuming a small subset of services provided by it (such as memory management). Hence you could swap the host OS for an actual microkernel running on bare metal and no app would notice. > I would say that, by a "strict definition", OS describes the software that runs on the metal Nowadays, many OS don’t actually run on the “metal” directly, rather under a hypervisor. On some architectures, a hypervisor is architecturally mandatory, there is no ability to run without one. Whether some facility is implemented in the real hardware or the hypervisor may be an implementation detail which can change over time, oblivious to the OS. Given all of this, I don’t think “runs on bare metal” is necessary to be an OS, especially given it is not always clear any more what actually counts as “bare metal”