> >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.
If you can write a Fortran to CIL compiler it will work which is not that hard. However changing the desktop market from Windows and OSx is not my goal as it is too difficult and needs big marketing. My goal is a Niche where people want high security , reliability and low latency. Mobile phones , military uses ,Application servers etc I expect a lot of viruses will target phones in future and people will always be tricked into allowing something. > >> 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. Yes confirmations are regarded as bad and capability systems don't have them except for the install. Basically with capability security every application has a list of capabilities which the installer will confirm, obviously some things will be red flags ( ie high risk) , one big change is that .NET assemblies are signed by a certificate so you have some idea who the code comes from. Eg a Device Driver will be red flag and caution but most apps will just copy an assembly to a new dir ( green) , A app throws up a red flag it can report why and the risk. I think red flags will be infrequent enough. Like ACL system whether to allow non technical users the right to change device drivers , services and shared lib is a matter of policy. Note the difference though with an ACL OS the moment an app is installed it has access to everything the user (or root) has access to. Lastly the OS trusted parts are untouchable except for a trusted updater which will download the files from a central repository configured at install. You may ask how does it open data files etc , by the user clicking in a trusted file manager the user obviously is approving the action so no need to pop up a dialog etc ( the same on a console if the user specifies the file a file descriptor is passed into the app) . There is a lot of information on this and the Research OS are Eros, Capros and Coyotos. <snip> >> >> 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? Yes but you can't have ring 0 having write access and ring 3 not it has to be global once you set a page as Read only the only access is by changing the page to RW. Both MOSA and Sharp OS run with an MMU but still a single address space ( with all ring 0 code) which is ok for them as they are a more simple monolithic design hence they can mark pages as code or read only . SOOOS is a microkernel design and I believe to gain traction/acceptance I will need good performance ( with the history of Micro Kernels eg Mach3 and Minix) . With no pages I can't do it in HW though I can use segments. Note on Intel even with no MMU you can have a readonly flat code segment which grows up and a rw data & stack segment which grows from the top down( or visa versa) , you only need the SW check to make sure they don't overlap( on x64 on i386 the HW has a seg limit) > >> 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 attractive though I will need to add a 2 Meg shared.NET lib. Its better to start 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. It's the non mutable and parallelism that attracts me esp when new PC are able to run 12 threads in a single 6 core CPU. 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
