101–110 of 112 posts
Earlier quoted context omitted.
Easily proven by happy consumers on Apple, Microsoft, Sony and Nintendo devices. Or the millions of daily passengers in transport mechanisms powered by high integrity operating systems.
I'm kidding of course. But in the specific context of this thread which was Nodejs backend development, I'd still maintain that not using Linux to develop is suboptimal.
Earlier quoted context omitted.
I'm kidding of course. But in the specific context of this thread which was Nodejs backend development, I'd still maintain that not using Linux to develop is suboptimal.
Depends if one is stuck in the glory days of UNIX, or has already learnt to embrace native cloud development.
Earlier quoted context omitted.
As if docker doesn't run a VM on Linux when you invoke that one liner.
It doesn't
Forgive me if I don't believe that running a full OS on a host OS to run a single node command doesn't amount to running a VM.
Earlier quoted context omitted.
It doesn't
Official docker image for node is built from Alpine or Debian [1] Forgive me if I don't believe that running a full OS on a host OS to run a single node command doesn't amount to running a VM. [1] https://github.com/nodejs/docker-node/tree/main/20
You can think of Docker containers as a way to package an application dependencies, ending at the (Linux) kernel API/ABI.
Earlier quoted context omitted.
I think you can analogize these server JS runtimes (Node, Deno) to browser runtimes (V8, JavaScriptCore, SpiderMonkey) and to the APIs that ship with those. When one browser JS engine invents and exposes a novel feature + API surface for it that the other engines don't, what happens? If there's any demand at all for doing what the feature does, then devs will tend to write polyfills to make the feature "work" (for so…
Just want to point out one issue in your comment -- webkit, blink would be more suitable as examples for "browser runtimes". V8 and JavaScriptCore are JavaScript engines. In other words, the page here is more about platform APIs (or maybe "standard library") rather than JavaScript language features. V8 vs JavaScriptCore vs SpiderMonkey doesn't matter to most developers because they are mostly up-to-date with ECMAScri…
Unlike with browser-embedded JS engines, where "what native APIs are accessible from JS" is a relevant question†, in backend JS runtimes the answer to that question is always "all of them, because they're all just C FFI libraries, and these runtimes use the same C ABI, allowing interoperation with any such library." So for backend runtimes, it's only things to do with the JS engine itself — like language features — where the differences really matter.
† And actually, browser JS engines could have gone this way as well, if NPAPI/PPAPI had caught on. The "Java" in "JavaScript" was supposed to refer to using Java applets as ActiveX-like COM servers which would expose APIs to be scripted against! In other words: a common-standard for native FFI, just with sandboxing.
Earlier quoted context omitted.
Depends if one is stuck in the glory days of UNIX, or has already learnt to embrace native cloud development.
In a way, the glory days of Unix, with users using shared infrastructure is closer to cloud than using Linux locally, which gives you freedom, independence and privacy.
Zero POSIX.
Earlier quoted context omitted.
In a way, the glory days of Unix, with users using shared infrastructure is closer to cloud than using Linux locally, which gives you freedom, independence and privacy.
Not when the cloud is running servless and language runtime containers on top of type 1 hypervisors. Zero POSIX.
And almost all systems on AWS are running on Linux/KVM. Even quite a few that report as Xen are actually running on KVM; Amazon added a bunch of code to KVM to lie on guest hypervisor cpuid leaves as well as emulate Xens hypercall interface.
Earlier quoted context omitted.
Not when the cloud is running servless and language runtime containers on top of type 1 hypervisors. Zero POSIX.
All of the major serverless runtimes are running on top of Linux by default. And almost all systems on AWS are running on Linux/KVM. Even quite a few that report as Xen are actually running on KVM; Amazon added a bunch of code to KVM to lie on guest hypervisor cpuid leaves as well as emulate Xens hypercall interface.
Which happens to be a special Windows build, Azure Host OS.
https://techcommunity.microsoft.com/t5/windows-os-platform-b...
Additionally, bare bones Linux kernel infrastructure for Xen and KVM support isn't UNIX.
"Transcending POSIX: The End of an Era?"
https://www.usenix.org/publications/loginonline/transcending...
Earlier quoted context omitted.
All of the major serverless runtimes are running on top of Linux by default. And almost all systems on AWS are running on Linux/KVM. Even quite a few that report as Xen are actually running on KVM; Amazon added a bunch of code to KVM to lie on guest hypervisor cpuid leaves as well as emulate Xens hypercall interface.
No they aren't, if the cloud in question is Azure, as Hyper V doesn't need a kernel to make it work. The controlling OS is a guest as well, with additional privilege. Which happens to be a special Windows build, Azure Host OS. https://techcommunity.microsoft.com/t5/windows-os-platform-b... Additionally, bare bones Linux kernel infrastructure for Xen and KVM support isn't UNIX. "Transcending POSIX: The End of an Era?"…
> Additionally, bare bones Linux kernel infrastructure for Xen and KVM support isn't UNIX.
> "Transcending POSIX: The End of an Era?"
Xen and KVM aren't equivalent here.
KVM is ultimately an interface involving file descriptors, mmap(2), read(2), write(2), etc. IMO while not being UNIX™ it still very much embodies the UNIX spirit.