Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We could have avoided so much hardware and OS complexity if we'd instead (mostly) discarded the idea of shipping and running compiled code directly on the hardware.

TL;DR: we are doing things in hardware that ought to be done in software, and we're giving software too close to metal access.

User mode should be something like the JVM, but more language-neutral, something based around WASM for example. The runtime for this should ideally be written in a memory safe language and very extensively tested. User mode code should not have access to raw pointers, raw CPU, etc.

If we'd done this we also could have elevated things like the common API beyond the lowest common denominator of C. We used to have a ton of research and some fielded systems like this: Smalltalk, LISP machines, the JVM, the CLR, etc. The JVM and the CLR are still quite alive and well but the HN world seems to hate them for some reason. Smalltalk and efforts like the LISP machines died out.



MS had a research project that built an OS from CLR.

One of the great things about it (in my opinion) was the lack of context switching. It broke a fundamental assumption about how an OS should work. It could also do global optimizations.


Oh yeah, forgot about that: you can do profile guided optimization on the entire running image of code in the machine.

I wonder how much of a boost you'd get for that? I'm sure it would depend on the work load.


So your solution is to nerf the computer in terms of both performance and functionality? There is a lot of software that cannot be properly written without being very close to the metal e.g. database kernels.


There would almost certainly be an escape hatch, but it would require user approval to run native code. It would probably be in the form of libraries that could be 'blessed' to run native. The vast majority of software does not need this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: