On Wed, Apr 14, 2010 at 08:56:17AM +0800, Ben Kloosterman wrote: > 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 .
What about those people with piles of old fortran libraries? I guess they will stick to running unix like they always have. :) I still run into 16 bit windows code at times. I really thought that would have gone away by now. > 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. So how do you upgrade the system then? And how do you tell the difference between an updater wanting to change a file in the system versus the virus wanting to do it? I think this is a problem of users simply don't know how computers work and no amount of confirmations are going to help. > 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. Certainly could be an interesting way to try to do that. > 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. Well if you can actually compile time check most things, and language runtime check the rest, then OK, I could see that working. It does to some extent limit what programmers can do and how close they can get to the hardware. Sometimes for performance you want to get close to the hardware, but in general most people don't need that. > 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. But would it work on an architecture that actually supported that in hardware? > 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) . Well uclinux with C programs are a lot smaller. Sure embedded systems are getting bigger, but some are still quite small. > 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 . Yeah it is a different coding method than most other languages. It just seems so elegant and clean though. -- Len Sorensen _______________________________________________ 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
