4 ms·

> and cloud infrastructure nowadays focus on other stacks, instead of being yet another UNIX clone could you elaborate? I was under the impression, that most c

by hnben 3y ago

> and cloud infrastructure nowadays focus on other stacks, instead of being yet another UNIX clone could you elaborate? I was under the impression, that most clouds heavily rely on unix, both for host and guest systems (and containers)

pjmlp 3y ago
First, Azure runs on Windows, using Azure Host OS at the lowest layer. https://techcommunity.microsoft.com/t5/windows-os-platform-blog/azure-host-os-cloud-host/ba-p/3709528 https://techcommunity.microsoft.com/t5/windows-os-platform-b... Secondly, unless you are doing classical VM deployments, the only thing we care about are type 1 hypervisors. If the language runtimes are running directly on top of a type-1 hypervisor, some kind of container, or bare metal, it is mostly irrelevant for most languages, with exception of C and C++ with their direct dependency on POSIX related APIs. Taken to the extreme, on serveless workloads, you can even upload the code, and it get magically transformed into a deployment, mostly using managed languages that are OS agnostic. At the end of the day, if those type-1 hypervisors are self-contained, or need a guest OS as management node, is completly transparent to the managed runtime workloads.
- flohofwoe 3y ago
  > with exception of C and C++ with their direct dependency on POSIX related APIs ...why would POSIX be special if the POSIX layer is statically linked with the application and would just be a translation layer to anything that lies below? Same way MUSL works on Linux as alternative C library which bypasses glibc and instead directly uses syscalls to talk to Linux. (also technically the POSIX standard doesn't have anything do to with the C and C++ standards)
  - lmz 3y ago
    The POSIX standard definitely has something to do with C standards: > Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2017. Some functions and headers included within this volume of POSIX.1-2017 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2017 and the ISO C standard is unintentional.
    - flohofwoe 3y ago
      Well ok, the two standards are overlapping where it makes sense, I stand corrected there. But nothing prevents me from writing C or C++ programs on Windows which don't have a single POSIX (or even libc call) in them, but exclusively use Windows system DLL calls - and those are still entirely valid C or C++ programs (although I'm aware that the situation is muddy for some libc calls which some compilers treat like builtins, e.g. memset and memcpy).

by hnben 3y ago

pjmlp 3y ago

First, Azure runs on Windows, using Azure Host OS at the lowest layer. https://techcommunity.microsoft.com/t5/windows-os-platform-blog/azure-host-os-cloud-host/ba-p/3709528 https://techcommunity.microsoft.com/t5/windows-os-platform-b... Secondly, unless you are doing classical VM deployments, the only thing we care about are type 1 hypervisors. If the language runtimes are running directly on top of a type-1 hypervisor, some kind of container, or bare metal, it is mostly irrelevant for most languages, with exception of C and C++ with their direct dependency on POSIX related APIs. Taken to the extreme, on serveless workloads, you can even upload the code, and it get magically transformed into a deployment, mostly using managed languages that are OS agnostic. At the end of the day, if those type-1 hypervisors are self-contained, or need a guest OS as management node, is completly transparent to the managed runtime workloads.

flohofwoe 3y ago
> with exception of C and C++ with their direct dependency on POSIX related APIs ...why would POSIX be special if the POSIX layer is statically linked with the application and would just be a translation layer to anything that lies below? Same way MUSL works on Linux as alternative C library which bypasses glibc and instead directly uses syscalls to talk to Linux. (also technically the POSIX standard doesn't have anything do to with the C and C++ standards)
- lmz 3y ago
  The POSIX standard definitely has something to do with C standards: > Parts of the ISO/IEC 9899:1999 standard (hereinafter referred to as the ISO C standard) are referenced to describe requirements also mandated by this volume of POSIX.1-2017. Some functions and headers included within this volume of POSIX.1-2017 have a version in the ISO C standard; in this case CX markings are added as appropriate to show where the ISO C standard has been extended (see Codes). Any conflict between this volume of POSIX.1-2017 and the ISO C standard is unintentional.
  - flohofwoe 3y ago
    Well ok, the two standards are overlapping where it makes sense, I stand corrected there. But nothing prevents me from writing C or C++ programs on Windows which don't have a single POSIX (or even libc call) in them, but exclusively use Windows system DLL calls - and those are still entirely valid C or C++ programs (although I'm aware that the situation is muddy for some libc calls which some compilers treat like builtins, e.g. memset and memcpy).