There are big difference...
Posted Nov 17, 2011 22:50 UTC (Thu) by khim
In reply to: Don't make me laugh
Parent article: Interview with Andrew Tanenbaum (LinuxFr.org)
Well, your hardware also requires quite literally PhD-level complexity to handle segmented RAM.
Not really. 80386 included 275,000 transistors and already included all the components needed to handle segmented RAM. Security model was only minimally changed since then.
Sure, CPUs do have PhD-level components: branch predictor, various eviction algorithms, etc. But all these components are designed to fail! Sure, failure rate here can have huge implication on speed (and thus on power spent and price), but they don't affect security.
Singularity, on the other hand, gets rid of context switches completely and works in flat RAM without segments. This gives some advantages: thread switching is EXTREMELY fast and threads themselves are cheap.
Yes, this is great achievement but then you are forced to trust that huge pile of code which does non-trivial optimizations. Which is comparable in size to the Linux kernel. This will give us advantage in security... exactly how?
And bytecode verifier's reliability becomes crucial for the security of the whole system. But it's one piece of code and it can be audited thoroughly by a throng of PhD-wielding developers.
Bytecode verifier is not important. It's tiny piece of software and yes, it can be verified. What is important is JIT. Either you use simple JIT (or no JIT at all) - and lose all these nice benefits from fast switching because your system just runs slow - or you use complex, spaghetti-like, unverifiable pile of crap which makes your "security" wishfull thinking.
Virtual machines can give you security. Virtual machines can give your speed. But not at the same time!
And if you don't care about speed then microkernels looks like more logical approach.
And by 'uses' I'm not talking about 'runs a JVM'. They have implemented hardware-accelerated garbage collector and a special CPU architecture suited to run Java code.
We've seen this long, long time ago. They don't run Java because they wanted to make fast system. They run Java because it's "buzzword of the decade". Their task was now "make the system which is as fast as possible" but "make system to run Java programs as fast as possible" - and they managed to do that. This is great achievement but it has nothing to do with suitability of Java for anything and everything to do with current fashion.
to post comments)