4 ms·

I love it. God speed. The idea of a multi-user time-sharing virtual memory operating system is seriously outdated. Today, the server OS could be based on a o

I love it. God speed. The idea of a multi-user time-sharing virtual memory operating system is seriously outdated. Today, the server OS could be based on a one user, multi computer abstraction, with multiple gigs of memory, solid state storage, and reliable gigE+ network as assumed essentials. Entire sub-systems of the current linux kernel can be omitted. Most of the VFS layer, with so many optimizations for spinning rust. Right out. Paging, swapping, shared objects, address randomization and PIC. Right out. User access controls, file access controls, network access controls / firewalls. Right out. Of the 50,000 device drivers in the linux kernel, probably 50 deserve to be supported. For a workstation with graphics / GPU and console support, and every pluggable external device support, maybe some sort of legacy emulation layer would work. Basically run a linux VM for backwards compatibility with those 50,000 devices. Would be less work than implementing those drivers... Remember, Linus was once a 19 year old with a dream, and a small repo of prototype kernel demo code, 25 years ago.

nerdponx 8y ago
As part of the lightly educated masses, this sounds good to me. Can anyone more knowledgeable than me comment on the feasibility of something like this?
- kartan 8y ago
  JavaScript was running in the browser until Ryan Dahl decided to create Node.js. Nowadays it is a big platform, and it can run also WebAssembly. This is just another step in that direction where is the OS the one running that code. Does it have problems? Yes. Adding more complexity to the kernel will open new attack vectors for breaking its security. But that is true for any added layer, even in the hardware which complexity has brought Meltdown and Spectre. Running JavaScript in your kernel is a lot riskier than running it in your app. The good news is that WebAssembly is created with sandboxing in mind. I hope they have learned some lessons (https://en.wikipedia.org/wiki/Java_security https://en.wikipedia.org/wiki/Java_security).
- FooHentai 8y ago
  To the extent the OP took it, as a universal way that 'servers' could go, not very feasible. Partly because we already HAVE what's being described, in the form of hypervisors. We then layer within it all that other stuff that's chopped away to bring us back to a system that has a bunch of stuff we want, but most importantly that supports a wide range of applications we want to deploy. The big problem with stripping back to the absolute bare essentials is that you optimize towards a local maxim, and severely limit your flexibility. This is certainly the way you want to go if you have deep pockets coupled with a need for bare-bones speed that can't be sharded in an effective manner. But that's not the majority of workloads.
  - detuur 8y ago
    Honestly the overhead of a modern OS, especially one like Linux which has been finetuned for these sorts of workloads is negligible. More importantly, any gains you make by stripping out parts of the OS you don't need you immediately throw away by going for a virtualised, sandboxed ISA. If you want to squeeze more performance per watt than you can get from a modern server, the only way forward is to code your application in Verilog and to run it on an FPGA or ASIC.
    - vthriller 8y ago
      It's not only about performance per something though, see e.g. this paper about boot time optimizations: http://oirase.annexia.org/tmp/paper.pdf http://oirase.annexia.org/tmp/paper.pdf
xyzzyz 8y ago
You don't need to implement networking either, because connecting it to the network is out of the question -- with no process isolation, access privileges, ASLR etc., any security bug means immediate privilege escalation to ring 0.
- lachlan-sneff 8y ago
  The great thing about using a transparently compiled isa is that there is no way you can get arbitary code execution. The only things exposed to the outside will be SIPs and if you exploit one of those, the most you can do with it is make it crash.
  - xyzzyz 8y ago
    Yeah, you have a point -- after all, nobody published any code execution bug in V8 in, like, forever, and by forever I mean in last 6 months. FYI, there have been 6 CVEs last year for code execution in V8 only in the last year. Fortunately, Chrome has great sandboxing and mitigation mechanisms to limit the impact of these, the mechanisms the parent explicitly recommends doing away with.
    - lachlan-sneff 8y ago
      WebAssembly is inherently simpler to compile and there is no complex interaction between the runtime and the SIP once compiled, like there is in v8.
      - DuskStar 8y ago
        And rowhammer was never a thing either. The point being, when everything is ring 0, you bet on both the hardware and software being perfect. And if there's anything that years of vulnerabilities in cryptographic software has taught me, it's that perfection is REALLY DAMN HARD.
wahern 8y ago
Unikernels have been a thing for awhile but have yet to take-off: https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Unikernel
microcolonel 8y ago
> Most of the VFS layer, with so many optimizations for spinning rust. Right out. You already aren't running 'em! Also, that's the block device layer, not the VFS layer. The VFS is the bit between the syscall interface and the concrete FS (which then in turn works with the block layer, if you are using a block device). Don't go signing the death warrant for something you clearly don't understand.

nerdponx 8y ago

As part of the lightly educated masses, this sounds good to me. Can anyone more knowledgeable than me comment on the feasibility of something like this?

kartan 8y ago
JavaScript was running in the browser until Ryan Dahl decided to create Node.js. Nowadays it is a big platform, and it can run also WebAssembly. This is just another step in that direction where is the OS the one running that code. Does it have problems? Yes. Adding more complexity to the kernel will open new attack vectors for breaking its security. But that is true for any added layer, even in the hardware which complexity has brought Meltdown and Spectre. Running JavaScript in your kernel is a lot riskier than running it in your app. The good news is that WebAssembly is created with sandboxing in mind. I hope they have learned some lessons (https://en.wikipedia.org/wiki/Java_security https://en.wikipedia.org/wiki/Java_security).
FooHentai 8y ago
To the extent the OP took it, as a universal way that 'servers' could go, not very feasible. Partly because we already HAVE what's being described, in the form of hypervisors. We then layer within it all that other stuff that's chopped away to bring us back to a system that has a bunch of stuff we want, but most importantly that supports a wide range of applications we want to deploy. The big problem with stripping back to the absolute bare essentials is that you optimize towards a local maxim, and severely limit your flexibility. This is certainly the way you want to go if you have deep pockets coupled with a need for bare-bones speed that can't be sharded in an effective manner. But that's not the majority of workloads.
- detuur 8y ago
  Honestly the overhead of a modern OS, especially one like Linux which has been finetuned for these sorts of workloads is negligible. More importantly, any gains you make by stripping out parts of the OS you don't need you immediately throw away by going for a virtualised, sandboxed ISA. If you want to squeeze more performance per watt than you can get from a modern server, the only way forward is to code your application in Verilog and to run it on an FPGA or ASIC.
  - vthriller 8y ago
    It's not only about performance per something though, see e.g. this paper about boot time optimizations: http://oirase.annexia.org/tmp/paper.pdf http://oirase.annexia.org/tmp/paper.pdf

xyzzyz 8y ago

You don't need to implement networking either, because connecting it to the network is out of the question -- with no process isolation, access privileges, ASLR etc., any security bug means immediate privilege escalation to ring 0.

lachlan-sneff 8y ago
The great thing about using a transparently compiled isa is that there is no way you can get arbitary code execution. The only things exposed to the outside will be SIPs and if you exploit one of those, the most you can do with it is make it crash.
- xyzzyz 8y ago
  Yeah, you have a point -- after all, nobody published any code execution bug in V8 in, like, forever, and by forever I mean in last 6 months. FYI, there have been 6 CVEs last year for code execution in V8 only in the last year. Fortunately, Chrome has great sandboxing and mitigation mechanisms to limit the impact of these, the mechanisms the parent explicitly recommends doing away with.
  - lachlan-sneff 8y ago
    WebAssembly is inherently simpler to compile and there is no complex interaction between the runtime and the SIP once compiled, like there is in v8.
    - DuskStar 8y ago
      And rowhammer was never a thing either. The point being, when everything is ring 0, you bet on both the hardware and software being perfect. And if there's anything that years of vulnerabilities in cryptographic software has taught me, it's that perfection is REALLY DAMN HARD.

wahern 8y ago

Unikernels have been a thing for awhile but have yet to take-off: https://en.wikipedia.org/wiki/Rump_kernel https://en.wikipedia.org/wiki/Unikernel

microcolonel 8y ago

> Most of the VFS layer, with so many optimizations for spinning rust. Right out. You already aren't running 'em! Also, that's the block device layer, not the VFS layer. The VFS is the bit between the syscall interface and the concrete FS (which then in turn works with the block layer, if you are using a block device). Don't go signing the death warrant for something you clearly don't understand.