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 :)
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?
"Hardly used" will not fetch you a better price for your brain.
"malicious programmer"?
WTF does security has to do with namespaces?
This is just braindead. I refuse to discuss this any more. Sorry. Call me a troll, but this sucks.
lies, lies, lies
> 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
WTF does this has to do with namespaces?????????
A library provides a call to create a hard link. Ok. I understand that. It's part of the library according to posix. This is what the library was supposed to do.
WTF? If they didn't want to provide create_hard_link() public, they might as well did not. WTF?
This is getting tedious. I'm really tired. I come here to read "news for nerds" and I end up thinking who to correct the horrible misinformation that people pull outof their arse. SHUT UP! WTF? This site is getting paranoid or is it just me?
God help us Rob.
LISP has neither strong typing nor namespaces. Forth doesn't have much of anything, bar stacks. Do we really need an Ada clone?
I have no personal experience with Lisp machines, but Lisp machines didn't have much in the way of protection or "sandbox" type security.
The beauty of the Lisp machine was that even the assembly language in the kernel was expressed in Lisp. There was no real separation between the lower-level services of the operating system and the upper-level programming facilities, and all of it was exposed transparently (and with introspection) to the programmer's tools. Another important feature was the integration of the VM with the garbage collection.
(As an aside, it was possible to program in Fortran, etc., on Lisp machines. But much nicer in Lisp).
The reason this is a mixed bag is that a programmer could basically redefine any part of the system he wanted. You could cause serious confusion by redefining the wrong thing. (A simple example, which might be inaccurate: setting the value of nil to be something other than nil (i.e. a value other than false) would cause all sorts of bizzareness, because almost every element of the system depends on the value of nil to test false.)
Lisp machines were virtually ideal (some would claim still unsurpassed) as developer workstations. Not so ideal for deployment as enterprise servers.
Yes they could, and they do. But for most definitions of "Operating System" it's incorrect.
;-)
Usually OS is used to refer to the kernel and central libraries. The OS takes care of the low level stuff and adds hooks so you can run programs.
IE is not part of the OS for Win32 any more than eg Windows Media Payer. "Explorer" however is, this is easily witnessed when your file browser crashes and takes the GUI with it.
BTW the system in the article does in fact tightly integrate things. It seems like most of the kernel is in fact in the libraries. Also the language handle a lot of kernel/OS stuff at compile time. (Like memory management.)
Other examples of OS which tightly integrate applications and OS are "exo-kernels". These basically tack a small kernel onto an application and let them run as one. (But it's not as useful for multitasking.)
The HURD is also an example of an OS which makes the distinction between OS and user application less obvious.
Basically, claiming that IE is tightly integrated into Win32 only makes sense if you define OS as "The stuff you get when you buy the box". This is not the definition most by people "In the know".