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. "
I didn't read the article, but I definitely am setting a few kilobucks aside of Crush/BRiX goes public. It appears that BRiX's namespaces delve deeper than traditionally as in C++ or Java, where a malicious programmer can get around the namespace compartmentation via direct addressing. A particular nasty example of this was recently reported on BugTraq, where filesystem access logs could be circumvented by creating a hard link to an arbitrary file, accessing the file through the hard link, and deleting the hard link. File access would not be logged, and past logs would be compromised. Although this is only tangential to namespace security in programming, I find it quite reassuring Mr. Huntsman is taking the initiative to push forward computer science and information technology security. Hopefully, the ideas presented by Crush will be widely adopted by commonplace languages such as Perl and Logo in years to come.
Use the SourceForge page instead http://brix-os.sourceforge.net/
Nobox: Only simple products.
They always claim IE and other applications are tightly integrated into the OS. Heck, you could argue any OS which ships as anything more than a kernal is a "combination of operating system and applications all-in-one".
That said, someone please tell me if I'm wrong, and how.
I'm the stranger...posting to
How long until we get Crush.NET? ::runs::
[o]_O
im not sure about those metaphors. i wouldnt like my language to crush my brix!
four-oh-four
Because what kind of loser would want to write software that can run on any operating system? And what idiot end user would want an OS that could run software written in any language?
Platform independence is overrated anyway. Proprietary is the way to go!!!
Oh shit! I forgot to click "Post Anonymously"...
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
It seems to me that any applications written in assembly of using this hypothetical compiler would look like any other BRiX application to the user, but would have access to the address space of the whole system! Surely not a good thing.
...or am I missing something?
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?
"Hardly used" will not fetch you a better price for your brain.
LISP has neither strong typing nor namespaces. Forth doesn't have much of anything, bar stacks. Do we really need an Ada clone?
There you see the basic concepts of Brix and Crush. Symbolics had that in 1984. One of the Symbolics people wrote a post-mortem,"The Lisp Machine: Noble Experiment or Fabulous Failure?", which explains what's wrong with this concept better than I could.
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});
AS/400 (with OS/400) runs all code in a virtual machine, and it relies on a number of compile-time checks (in combination with some run-time checks) to ensure reliable operation, like BRiX. There's no hardware support for memory protection needed, all in all it seems that the BRiX model is heavily inspired by AS/400.
The even cooler thing is, that since all 3rd party programs for AS/400 are distributed in byte-code (the only kind of code you can run on this system), to be run by the OS/400 virtual machine, the AS/400 product line has changed processors over time without needing any re-writes or even re-compilations of 3rd party products.
It seems that BRiX applications are machine-code - this kills off some of the coolness found in AS/400, unfortunately. It should get them some of the performance AS/400 cannot have, though.
Back in the good ol' days, AS/400 hardware did not have the support needed to perform memory access control in hardware - today they run on Power3 CPUs which has the support, but none of this matters for 3rd party products. All they do is run in the virtual machine, that's all they need to know.
However, porting apps from other OS'es is of course going to be a complete PITA. Not just porting to a completely different environment, but changing language at the same time. I guess that was what you meant when you said portability, and I completely agree there.
Anyway, just wanted to point out that there is at least one successful platform out there, built in a way similar to that of BRiX.
gcj has substantially more functionality than JME.
You should check out gcc 3.2. It has the advantage
of being able to do ahead-of-time compilation.
While the optimizations have not matured to the
degree of the IBM JDK JIT, for example, they are
progressing in fits and starts.
-I like my women like I like my tea: green-
The -fomit-frame-pointer merely converts frame-pointer-relative addressing into stack-pointer-relative addressing, thus saving a register. What I'm talking about is the kind of optimisation which stores live data above the stack pointer.
Consider, for example, the following code:
At -O8 -march=pentiumpro I get:
Adding -fomit-frame-pointer I get:
It successfully eliminated %ebp, but did not eliminate the sub %esp/add %esp pair even though there are no calls in the intervening code. The reason for this is that if a signal is delivered to the current thread, it will happen by making a C call frame at the current %esp, so if there's live data above the top of the stack, it will be clobbered.
This may not seem too bad a price to pay, but many nonprocedural languages (mostly functional and logic languages) do not use a conventional "call stack" in the same way that C does, and so could use the built-in stack (or the built-in stack pointer) for other purposes. No such luck under Unix, because signal delivery is by C callback, so you need a valid C stack.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
... behind every buzzword is a concept, sometimes a lump of bogus hype but much more often a key piece of understanding.
And when a whole flock of buzzwords describe different useful techniques that are similar in style but different in form, the underlying concept, if you can discover it and apply it generally, is likely to be EXTREMELY important.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Strong typing means that it is not possible to write code which is not type safe. E.g. C does not have strong typing, since it is possible to say things like printf("%s", 5); and compile and run the code with undefined results.
While K&R C didn't have strong typing, ANSI C does. (ANSI cloned it from C++.) It isn't strong enough to meet the strict definiton you gave because it's static (i.e. no run-time checking) and the language allows the author to violate type-safety - mainly by explicitly declaring he wishes to do so (with "void" and typecasts).
In my opinion, strong typing is never bad per se, except that it may result in slightly slower execution because for most languages strong typing means that some level of run-time check need to be done.
Actually compilers can do a good enough job of type-checking statically to catch the bulk of the problems.
The advantage of strong and/or static typing is that it lets the compiler assist you in finding errors. Some people claim that the reduced flexibility impeeds them. But I've found that I can generally express my desires without interference from the language (at least in C and C++), while the people running into trouble were generally not giving adequate attention to their interface definitions. The compiler was just warning them about their confusion or their failure to specify what they wanted to do.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
(* Well, then use Common Lisp: strong, dynamic typing, optional, but powerful, static typing. *)
Kudos to languages that allow one to take either approach. VB was heading in this direction also (although in a kludgey kind of way), but MS seems to now be "de-scripting" it after doing the opposite to compete with Perl for a while.
Allowing both approaches means that you don't have to succumb to one person's programming philosophy. Until approach X is shown to be objectively better than Y, please don't shove X down my throat.
There are enough dictators in the world who think they know more than others (or know more about others) and deserve the right to shove their truth down other's throats.
Table-ized A.I.
That's because the task bar is explorer (they run in the same process).
If it was part of the OS you wouldn't be able to get the file-browser or task bar up again, and everything else would probably crash.
I normally take OS to be things that run at ring 0 + ring1
Applications (like explorer) run in ring 3.
(at least that's what i remember from my dos days!)
Quick guide to protected mode
thank God the internet isn't a human right.