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 :)
"BRiX, like many other operating systems, provides features such as SMP, preemptive multithreading, virtual memory, a secure multiuser environment and an easy to use graphical interface. How it does this and the end result make it very much unlike any existing operating systems. BRiX is a computing environment and not an operating system. It is a combination of operating system and applications all-in-one. "
Use the SourceForge page instead http://brix-os.sourceforge.net/
Nobox: Only simple products.
The Operating System is called BRiX, and it uses a language called Crush, which is woven tightly into the core of the OS.
And thus is the same class of mistake as were made in lisp, mad, smalltalk, fortran, forth, and a number of others made once more.
Integrating the language and the OS kills portability, robustness, and security. Integrating the development enviornment with the software under development risks breaking the environment as you develop your target application and sucking the whole environment, bugs and all, into the target.
The languages I named had one or both of those problems. Sometimes it was useful, or "elegant". But always it was an albatross around the neck. I don't know if this new pair has the environment/target confusion. But the anonymous poster brags about combining the OS and language. So (if he's not just mischaracterizing an interpreter/P-code compiler) it certainly has that problem.
The key to successful programming is isolation. Single-mindedly chopping the problem into tiny pieces and walling them off from each other, then putting a few tiny holes in their individual prisons to let in and out ONLY the things they need to know and manipulate.
"Modularity". "Data Hiding". "Strong type-checking". "Interface Abstraction". The list of buzzwords is long. But the battle is constant. The number of interactions goes up with the FACTORIAL of the number of pieces interacting, while a programmer can only keep track of about six things at a time. The more connected the compiler, OS, and target program, the bigger the ball of hair a programmer has to unsnarl to get the program working. One of the things that was key to the success of the C language was the isolation of the runtime environment behind the subroutine interface.
Let us hope it's the characterization, and not the implementation, which has the problem.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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?
"Hardly used" will not fetch you a better price for your brain.
I'm not buying this. I've used -fomit-frame-pointer
with signals and setjmp/longjmp more times than I've
gotten laid since I was married, and never seen a
blip. In fact, I've seen compilers for C (slightly
modified versions of C, but the modifications were
not relevant to this discussion) which used heap
allocations exclusively, but fully supported signals
and setjmp/longjmp (even call/cc!), so you're going
to have to explain your view in greater depth to
gain credibility against such apparent counter-evidence.
-I like my women like I like my tea: green-