Slashdot Mirror
Crush/BRiX: An Experimental Language/OS Pair
An anonymous reader writes: "Brand Huntsman (the creator of the Bochs Front-End, among other obscure things) has been developing an integrated language/operating system for the past few years now. The Operating System is called BRiX, and it uses a language called Crush, which is woven tightly into the core of the OS. On his project web page he has posted the source code to his preliminary compiler, which runs in Linux and outputs optimized assembly from Crush source code. The Crush language itself is heavily influenced by Forth, LISP, and Ada, and provides strong typing and extensive namespace security." Update: 08/19 00:03 GMT by T : Note, the project page URL has been updated, hope it now works for everyone :)
I'm probably going to get moderated down for this, but I couldn't help but notice the similarities between Crush/BRiX and Microsoft's .NET framework.
Crush doesn't use protected memory to protect applications from each other, but instead relies on the language, Crush, to ensure programmatically that it is impossible for programs to interfere with each other. This is almost exactly the same as a .NET application domain (ASPX or IE would be a single application domain); there isn't any enforced seperation of processes or security features running in an application domain - the CLR instead formally proves that the applications running don't violate the security boundaries it's supposed to conform to.
I'm wondering if this is an idea whose time has come, particularly in the field of low-cost embedded development. Instead of including costly hardware and OS support to provide these features, you use software development tools to create software which renders them unnecessary. Or am I just smoking crack?
I don't understand why that posting got rated Troll, except from the slightly offensive language it is a very insightful comment.
By placing the security model in the language rather than the OS design you will get some disadvantages. You will either have to limit yourself to applications written in this single language or loose the security. Of course some kinds of frontends can get other languages compiled into something running on the system. But this is likely to give you some penalty in performance and perhaps other areas as well.
The language is probably usable on other OSes as well, if anybody care to write the necessary compiler and libraries. But you might not get the full benefits from the language.
However the main idea isn't new. Some people seriously believe JavaOS has a future. Generally you get a uniform security model all the way from OS core through library layers all the way up to the applications. You get runtime typechecking, boundary checking, and garbage collection. You prevent half of the possible security problems. And people believe that good JIT compilers can be faster than compiled C code in some areas where runtime code analysis can be used to do optimizations not possible at compile time.
Do you care about the security of your wireless mouse?
May I ask you how FORTRAN is a) integrated with it's OS (whatever that really means in the case of FORTRAN), or b) integrating the development environment with the software under development?
I hate to break this to you, but C is just as tightly woven into Unix, as anyone who has tried to implement a compiler for a higher-level language will tell you.
For example: Suppose your language wants to manage a stack differently than C does. Suppose, for example, you want to perform some optimisation where the stack pointer does not point to the true end of the stack (say, in a leaf call). Under Unix, too bad. You need to maintain a true C stack pointer otherwise signals won't be delivered properly.
Unix is just as much a C virtual machine as the Symbolics devices were Lisp virtual machines.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});