5 ms·

Why not go all the way and move the rendering engine out of the privileged base of the system? Why is all this HTML and Javascript garbage in "kernel land" anyw

Why not go all the way and move the rendering engine out of the privileged base of the system? Why is all this HTML and Javascript garbage in "kernel land" anyway? Why not make your browser kernel concerned solely with providing asm.js or PNaCL plus WebGL and some other primitive services? Then everything else can be preloaded libraries. And what on Earth does Node.js have to do with any of this? Why not just create some Javascript bindings to WebKit and V8, then.. write the browser in Javascript? The browser needs less of this kind of ridiculous bloat, not more.

spolu 13y ago
Agreed with direct Webkit bindings in JS... only if you want to handle networking and file storage in Javascript, you'll end up rewriting node.js which is exactly that bindings for libuv... So node.js is not chosen because it's cool or anything, it's just because it's exactly what's needed. Not sure I see what you mean by HTML and Javascript garbage in "kernel land"?
- roarroar 13y ago
  HTML and Javascript are a horrible basis for a computing platform, which is why in the end they have resorted to providing a tiny, statically typed subset of Javascript plus some graphics primitives. And now the primitives exist, comically, side-by-side in the privileged base of the system with a bunch of application-level stuff (HTML etc) which could be built out of the primitives themselves. Your diagram doesn't indicate that you're just using libuv bindings for portability - it includes a local server.
lutusp 13y ago
> Why not go all the way and move the rendering engine out of the privileged base of the system? Why is all this HTML and Javascript garbage in "kernel land" anyway? There's a little-known emotional factor in software development at work here, apparently not clearly understood, indeed it might as well be a secret. And that is that kernel development is high-status, and user-space development is low-status. Many software developers want desperately to add to their resumes the fact that they contributed code to the Linux kernel. This is why so much user-space code has made its way into the kernel. Someone powerful should go through all the kernel-space code and order the deportation to user-space of all the stuff that doesn't belong, that has slipped across the border over the years like phony political refugees. This probably won't happen, but it's uncontroversial that much of the kernel code has no right to be there, and much of it is written so badly that it's dangerous for it to be in kernel space.
- spolu 13y ago
  The ExoKernel[1] principle is even more agressive (and awesome!) [1] http://en.wikipedia.org/wiki/Exokernel http://en.wikipedia.org/wiki/Exokernel
comex 13y ago
You can't make a JavaScript engine run anywhere near fast enough in PNaCl, so you need at least all of V8 in your "kernel". You could run WebKit on top of PNaCl with some magic V8 bindings, but I don't think this has been done before, and considering how big WebKit and NaCl are, it would probably be a lot of work. Useful work to do, but a lot of work... (And of course, Chromium already supports a process sandbox, so while this could theoretically be a really cool win for architecture, having less platform specific code to maintain, it wouldn't necessarily be much of a security win - the analogy of the kernel only applies so far.)
- roarroar 13y ago
  I'm aware of all this. I'm not saying it would be easy - and the belief that high speed Javascript is necessary is one reason we've been held back for so long. Nobody should be writing a browser in Javascript (when I mentioned this possibility I was simply humoring the poster's ideas). An "Exobrowser" (or perhaps "Microbrowser") is what we should have by now, but the linked project is not it. NaCl and asm.js are only necessary because operating systems have failed to successfully implement process separation (more crap, monolithic design at work), so now it's being reinvented in user land with the resulting performance overheads. Javascript doesn't need to be fast! The whole idea of high performance programming done in Javascript is stupid, especially if it means saying "no" to a better architecture designed around security and speed for better systems languages. Even Mozilla's penny has dropped on low-level code execution - hence asm.js. If operating systems had been done right in the first place then you could have the following arrangement: - Each browser tab is a separate OS process w/o any access to system calls except for calling browser services - Browser provides services (e.g. graphics primitives, input) - Processes from the same domain can talk to each other - Browser comes preloaded with some preferred, but optional portability layers for the processes - Everything else is libraries, with one domain being able to provide services to another. So mozilla.org could provide its rendering engine either as a library or as a background process (to reduce memory overheads). And so on. This way there's no more waiting 10 years for Mozilla to implement whatever it thinks you need, with their 640k ought to be enough attitude. Their rendering engine has to compete with others. The most popular engines are most likely to already be in cache when someone visits your site, so there is room for lots of vigorous competition. This is all so painfully BASIC, but it will likely be decades before people get it right, if they ever get it right. Chrome is going in the right direction, the poster's linked project is not.

spolu 13y ago

Agreed with direct Webkit bindings in JS... only if you want to handle networking and file storage in Javascript, you'll end up rewriting node.js which is exactly that bindings for libuv... So node.js is not chosen because it's cool or anything, it's just because it's exactly what's needed. Not sure I see what you mean by HTML and Javascript garbage in "kernel land"?

roarroar 13y ago
HTML and Javascript are a horrible basis for a computing platform, which is why in the end they have resorted to providing a tiny, statically typed subset of Javascript plus some graphics primitives. And now the primitives exist, comically, side-by-side in the privileged base of the system with a bunch of application-level stuff (HTML etc) which could be built out of the primitives themselves. Your diagram doesn't indicate that you're just using libuv bindings for portability - it includes a local server.

lutusp 13y ago

> Why not go all the way and move the rendering engine out of the privileged base of the system? Why is all this HTML and Javascript garbage in "kernel land" anyway? There's a little-known emotional factor in software development at work here, apparently not clearly understood, indeed it might as well be a secret. And that is that kernel development is high-status, and user-space development is low-status. Many software developers want desperately to add to their resumes the fact that they contributed code to the Linux kernel. This is why so much user-space code has made its way into the kernel. Someone powerful should go through all the kernel-space code and order the deportation to user-space of all the stuff that doesn't belong, that has slipped across the border over the years like phony political refugees. This probably won't happen, but it's uncontroversial that much of the kernel code has no right to be there, and much of it is written so badly that it's dangerous for it to be in kernel space.

spolu 13y ago
The ExoKernel[1] principle is even more agressive (and awesome!) [1] http://en.wikipedia.org/wiki/Exokernel http://en.wikipedia.org/wiki/Exokernel

comex 13y ago

You can't make a JavaScript engine run anywhere near fast enough in PNaCl, so you need at least all of V8 in your "kernel". You could run WebKit on top of PNaCl with some magic V8 bindings, but I don't think this has been done before, and considering how big WebKit and NaCl are, it would probably be a lot of work. Useful work to do, but a lot of work... (And of course, Chromium already supports a process sandbox, so while this could theoretically be a really cool win for architecture, having less platform specific code to maintain, it wouldn't necessarily be much of a security win - the analogy of the kernel only applies so far.)

roarroar 13y ago
I'm aware of all this. I'm not saying it would be easy - and the belief that high speed Javascript is necessary is one reason we've been held back for so long. Nobody should be writing a browser in Javascript (when I mentioned this possibility I was simply humoring the poster's ideas). An "Exobrowser" (or perhaps "Microbrowser") is what we should have by now, but the linked project is not it. NaCl and asm.js are only necessary because operating systems have failed to successfully implement process separation (more crap, monolithic design at work), so now it's being reinvented in user land with the resulting performance overheads. Javascript doesn't need to be fast! The whole idea of high performance programming done in Javascript is stupid, especially if it means saying "no" to a better architecture designed around security and speed for better systems languages. Even Mozilla's penny has dropped on low-level code execution - hence asm.js. If operating systems had been done right in the first place then you could have the following arrangement: - Each browser tab is a separate OS process w/o any access to system calls except for calling browser services - Browser provides services (e.g. graphics primitives, input) - Processes from the same domain can talk to each other - Browser comes preloaded with some preferred, but optional portability layers for the processes - Everything else is libraries, with one domain being able to provide services to another. So mozilla.org could provide its rendering engine either as a library or as a background process (to reduce memory overheads). And so on. This way there's no more waiting 10 years for Mozilla to implement whatever it thinks you need, with their 640k ought to be enough attitude. Their rendering engine has to compete with others. The most popular engines are most likely to already be in cache when someone visits your site, so there is room for lots of vigorous competition. This is all so painfully BASIC, but it will likely be decades before people get it right, if they ever get it right. Chrome is going in the right direction, the poster's linked project is not.