> >On Tue, Apr 13, 2010 at 10:28:45AM +0800, Ben Kloosterman wrote: >> By using languages that don't allow pointers . > >I imagine that will go over well with programmers in general. I would >be all for that, but it seems most people don't want to rewrite all >their code.
A lot of apps are written in Java , and .NET (including C#, VB , oCaml , Python , Ruby) which will be supported , if apps were not rewritten we would all be using S360/390 and DOS/Windows . It is important to note that advances in Software dev ( such as no static data) lead to similar benefits in the OS space by removing or reducing ambient authority. This is further enhanced by using capabilities which also requires apps to be rewritten , the benefit is far greater security and reliability for the OS to the point that a user approves an app which turns out to be a virus but has little ability to spread , penetrate or harm the system. > >Of course sticking with our current crap isn't a good plan long term >(or maybe even short term). > >Pointers under programmer control certainly are a huge source of evil. > Yep , note however both Singularity and the other managed OS are starting with a green field with no app support , I saw ucLinux and thought it would be perfect with Mono (if it works) . Quite a few drivers and apps that can be included with the OS and slowly ported to .NET CIL , though users can do this. >> Please read the paper "Rethinking the Software stack" 2005 Galen Hunt >et al. >> Which measured at 11% for a web server load with compile time checks >or 6% >> MMU cost for compile and runtime checks. > >I don't know if I would agree it is the MMU's fault. The TLB looks >to very much be at fault (at least in the case of x86 as currently >implemented). The MMU could still be used for protection without the >TLB >issue I imagine, although then you loose all the memory fragmentation >solving that the MMU can give you. Of course if you can in fact hide >that problem using the software (in the language runtime) and make >memory >fragments transparent, then that might not be such a big deal. I would >be impressed to see that really work. Agree it's TLB but any form of page based VM requires a TLB (except say segmentation like the 286) . Download Singularity it works . It's a full OS which is fast , very reliable and secure but MS may never release it since it would impinge on windows. If they do release it I can make their drivers work on my OS and have an open source platform. A great example is Java and .NET app servers these already can have no memory protection ( yes you can set up domains) and have little issues ( the main issues are process related eg in a cont . loop not memory prot) we are extending this down to the OS. The key idea is to remove the protection ( and move it mostly to the CIL to binary compiler) thus allowing very fast task switches (its not a context switch any more since the address space is global) . This allows more asynchronous IPC / Kernel calls at no cost which improves reliability and multi core performance and asynchronous apps like web servers. In other words a message based Micro Kernel but with a positive performance benefit instead of a negative. >I sometimes wonder why we still use shared memory space computer >architectures. Systems used to exist with seperate code and data >memory spaces. Seems like a pretty darn good idea. Of course intel >would never let us give up on the terrible x86 architecture (although >I guess with the Itanium they tried to). I guess we have to blame users >for demanding backwards compatibility with existing software. This OS will enforce separate code and data spaces but it will do so in software using the compiler. This will make arch ports much easier. > >> Again read the paper , for C++ apps its difficult ( though MS are >trying it >> with Windows device driver verication ) for Java , .NET or other >> environments it's much easier and most of the checks can be done on >the byte >> or CIL code. > >Well I hate C++. I tolerate C because it is currently useful. >Java should be exterminated. .NET is too tied to a single OS to be >interesting at this time (and much much much too big. No runtime >library >should be a 50MB download). Its not that bad as this lib would be shared by all apps in the OS ( at the moment you have Java Libs , C++ libs etc) , these are additions for rendered GUI , Web server (ASP.NET)and WCF ( Like Axis) which are the largest components. I spent quite a number of years on hand held development and Compact Framework ( where the lib is just the core and about 2 Meg) I was very happy with it compared to the old Embedded C++ which I used with most of the issues being more related to the platform ( Pocket PC 2002 , 2003 and WM5) . >I like ML (I wish I knew it better, specifically CAML or OCAML). I >would >probably like F# if it was available for an OS I cared to run. > That's very interesting , I have been thinking of writing some of the OS in F# (OCaml) , there is massive synergy between OCaml and SOOOS ( my OS) due to the asynchronous nature , it defaults to non mutable and parallelism. Since F# is a .NET language you just use VS to compile it and deploy the assemblies to the new OS . I think it's a good fit for large parallel services / code which will run on multi cores ( web servers , print servers etc) but a worse fit for low level / embedded code. I have spend a few weeks on oCaml but it has a huge learning curve so prob wont use it myself but I will support people who want to write services/apps in it . Regards, Ben _______________________________________________ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
