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 remember reading where Starflight was susposidly written partly in Forth.
l8r
"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. "
Is this an attempt to create the most unreadable source code possible?
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
Just a thought.
Realistically if you think it's not necessary don't use it.
For example you might think, `Hmmmm.... why would anyone want more than Swank and Penthouse, I mean come on Big Mamas on Roids is too much`, however the big mamas mag may be just what you were looking for (theoretically only).
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
Ok...
The idea seems very interesting, although I would say that for the project to have any appeal outside of academic or research circles, it would need to based around something MUCH more popular than ADA, FORTH or LISP. Sure...ADA is good...well at least better than a $1,500 US NAVY hammer. Many he is paving the way to something like an OS built directly over C#? (Not C#.Net by the way) That might be a real leap forward.
please excuse my apathy
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.
not all that much written up anyway
he says that you translate c to crush if you want to
he says it has no kernel just a lib
(depends how you name things, a kernel is just a lib in the sense that after all you make calls to it )
but what he seems to be doing is a Virtual machine with bounds checking and such but it does not say what type of virtual machine
stack or register ?
overall I would have to see the code before I judge
to be quite honest I dont want to learn crush what I want is open source core java libs and virtual machine (but thats just my pet hate at the moment) this would mean a good set of proven techniques to be able to use in any project I like without haveing to go crawling to sun about it (java Micro edition would be great)
regards
John Jones
This approach has numerous predecessors,
not the least of which is Oberon, Lillith, Mesa, the Perq, and on back to the Burroughs B5500. Admittedly
the Burroughs machine had hardware segmentation support, but it had no notion of "privileged state" - the Algol compiler wouldn't produce code that could do "bad things". about a decade ago the hot topic in OS Research papers was all about how to use huge address spaces and the one-address-space model was resurrected again, with and without various hardware support for compartmentalization.
If you believe a compiler will never generate erroneous code, you'll sleep just fine with this model. On the other hand, if you've debugged a system compromise caused by a compiler bug, you might feel otherwise.
pleasant dreams
"Forth, LISP, and Ada"
Where do I sign up?
Invoicing, Time Tracking, Reporting
LISP has neither strong typing nor namespaces. Forth doesn't have much of anything, bar stacks. Do we really need an Ada clone?
Explaination of the punchline:
Unix and the C programming language were mutually developed for each other by Bell Labs.
"Learning is not compulsory... neither is survival."
--Dr.W.Edwards Deming
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});
Car and cdr originate from the IBM 704 family of computers' address handling.
In the great CONS chain of life, you can either be the CAR or be in the CDR.
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.
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});
I find it ironic that at a time when natural human languages are disappearing fast the number of programming languages and variants just continues to increase.
I dispair of constantly being obliged to re-learn how to do the same old things using the latest syntax.
Is the human race ever going to wake up to the fact that we could communicate far more effectively if there were only one computer programming language?
From "About":
"As the core components of BRiX mature the bounds checks will be removed giving it back the speed it had lost."
Mature means "no bugs" here. When are you sure your software has no bugs? Practice says you never can.
So you trade a small speed decrease for a security nightmare.
Give me an OS with bounds checking. If I want a faster OS, I'll buy a new, faster CPU.
Me
From the faq:
Wow, that's very humble of them. I'm very interested to see how this turns out, it has some interesting concepts, but I think this answer is a bit far fetched on almost all counts.
heavily influenced by Forth,
Crush is dead on arrival.
LISP,
OK, Crush is dead before leaving.
and Ada
I'm surprised it hasn't imploded, creating a black hole to suck enthusiasts in.
[I dearly loved both forth and LISP (and Modula-2). They changed the way I program. Doesn't really make them successful languages, though.]
I assume that it's more of a proof-of-principle kind of thing, meant to push the envelope of OS design but without any realistic hopes of being popular. But it's gone farther than a simple proof-of-principle would require. So, I'm curious what the strategy and goals of BRiX are.
My other complaint is that Brand's new "for dummies" text is not helpful, just arrogant.
... 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.
All the discussion here seems to be focused on the underlying workings of the OS, memory spaces, and the Crush language.
But to me the coolest thing was the Object Store: "...All file information (metadata) is stored in a database file and accessed with a search engine..."
Whoah! How awesome is that?! Is this something that is implemented in any other OS's/File Browsers?
There is so much talk all the time of how the "desktop metaphor is outdated and we need something new, but...what?"
Well in my eyes, here is the ideal replacement for the files/folders/hierarchy/etc.
I work with a LOT of computer-illiterate people, and it is very hard for them to find files on the computer (especially with a few network drives also available to them). They usually don't remember where they saved the file to in the first place! But with a system like this, where files are not arranged in a hierarchy, but rather you query for them much like a database, they can just pull up files that have attributes relevant to what they remember about it.
I think this would be fantastic, and I wish I could figure out how to get this Brix-OS running so I could see the implememntation of this feature(!)
I don't think so, .
the gui isn't tied to explorer
Nost of explorers functionality comes from a library shell32.dll this could be considered in part an os component.
In a simila fassion a lot of IE is in wininet.dll is this part of the OS?
thank God the internet isn't a human right.