| |||||||||||||
The Managed Runtime InitiativeThe Managed Runtime InitiativePosted Jun 18, 2010 10:05 UTC (Fri) by marcH (subscriber, #57642)In reply to: The Managed Runtime Initiative by martinfick Parent article: The Managed Runtime Initiative
> Without using pipes and forking, it is hard to create large robust modular programs in any language.
Agreed.
On the other hand, please tell us how to implement Eclipse or Emacs using a bunch of independent and loosely connected processes.
Even better: please tell us how to implement something as powerful and fast as Linux using a micro-kernel and a bunch of loosely connected daemons :-P
(Log in to post comments)
The Managed Runtime Initiative Posted Jun 18, 2010 15:48 UTC (Fri) by martinfick (subscriber, #4455) [Link]
Eclipse -> KDE (except KDE does so much more in so much less memory, and still, I would not call it efficient)
Emacs -> Vi + 1000 other small unix utilities
Linux, well, we have to reverse things here a bit, linux is somewhat large, but still modularization was defined early by the original unix devs. So the image looks more like this.
multics -> linux + 1000 other small unix utilities.
Remeber how often the "do it in userspace" slogan is shouted from linux kernel devs. Perhaps if the java devs used a bit more of this approach (i.e. do not use the same JVM for everything) they would not be suggesting to expand the kernel just so that JVMs can get bigger! Note how different from normal scalable program requests that is. This is not a request to" "be able to create 1 billion threads/processes and to switch efficiently and fairly among them", or "to communicate between them with low overhead"..., no it is a request to fundamentally support using larger and larger monolithic programs. One might ask why the JVM even needs an OS, why not just run it straight on the iron and optimize the hell out of it, for this single use case, isn't that what the java devs really want? ;)
|
|||||||||||||