Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Language and the System

By extrasolar in News
Thu Jun 08, 2000 at 06:08:39 AM EST
Tags: Software (all tags)
Software

Recently, the Plan 9 OS was released as free software. It was interesting reading about it. The OS seemed to be a lot like Unix, only tailored to distributed computing.

One thing that interested me was how much it was influenced by the C programming language. The system treats every resource as a file, much like the Unix OS. In fact, Unix and C were in bed together from the very beginning. If you are interested in the history---get a good book on Unix or C. But I am going to assume you already understand this.

But how tightly does the Language and the System need to be intertwined?


This leads me to consider the relationship between the Language and the System. A remarkable attribute about the Plan 9 system is that even the GUI has an elegant API in C. Best of all, the entire system makes sense to me, just by reading about it. This may be the very reason why so many herald Unix as a better system.

I have to wonder. What would an OS based upon another programming language be like? A reference was made to an OS based upon functional programming in "Why Functional Programming Matters" but no explaination. If you applied C++ to an OS, would you get something like the BeOS? And, perhaps more to the point of this article, is there a direct correlation between intregration between a System and its Language, with its robustness and power?

It seems to me that to improve the state of the art of operating systems, an ingenuitive fellow needs to design a System based on a modern programming paradigm---like functional programming or OOP. Or perhaps we should choose to adopt the Plan 9 OS which seems to integrate very cleanly with C? Either way, it seems that an OS based on several programming paradigms doesn't work as well (like GNU). But I am interested in differing opinions as well.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o Plan 9 OS
o GUI
o "Why Functional Programming Matters"
o Also by extrasolar


Display: Sort:
The Language and the System | 41 comments (41 topical, editorial, 0 hidden)
Have they not been talking about ja... (3.00 / 1) (#1)
by gandalf_grey on Thu Jun 08, 2000 at 12:53:52 AM EST

gandalf_grey voted 1 on this story.

Have they not been talking about java based OS's for quite a while now? Or did it go the way of the dinosaur? Perhaps it's just the fact that OS popularization takes so long, and it's fairly hard to penetrate the market.

Re: Have they not been talking about ja... (none / 0) (#11)
by jonr on Thu Jun 08, 2000 at 07:27:17 AM EST

My bet that Palm Computing (The ARM based ones) will run some sort of Java-OS... Of course I could be completly wrong, and it will have more "tradidional" OS with only Java VM... J.

[ Parent ]
Re: Have they not been talking about ja... (4.00 / 1) (#26)
by daninja on Thu Jun 08, 2000 at 03:35:31 PM EST

My bet that Palm Computing (The ARM based ones) will run some sort of Java-OS... Of course I could be completly wrong, and it will have more "tradidional" OS with only Java VM.
Java doesn't fit well on the Palm because the Palm is an instant-on device (as opposed to a computer that you boot-up). Apps that conform to Palmness need to be really quick-starting, and Java apps (by definition) are not (even if the JVM is always on, a Java app must be loaded via the class-loader/bytecode-verifier, imposing unacceptable overhead on a Palm).

[ Parent ]
Re: Have they not been talking about ja... (4.00 / 1) (#31)
by Zagadka on Thu Jun 08, 2000 at 08:52:43 PM EST

Actually, there's at least one JVM available for the Palm. While there are performance issues with Java, I think the size of the JVM would be the big problem, not the startup time... unless you're talking about loading classes from a remote location. The fact that the Palm is "instant-on" is a non-issue. The classes wouldn't be re-loaded every time you turn the device on. They would remain "loaded" even in the "off" state.

[ Parent ]
Re: Have they not been talking about ja... (3.00 / 1) (#27)
by Anonymous Hero on Thu Jun 08, 2000 at 04:21:32 PM EST

Actually, I'm leasing ($50 a year for three years, first year waived because I was one of the first 10,000 - then I own the machine) an internet appliance from Virgin (the <a href=www.virginconnectme.com>virginconnect program) which has a linux microkernel (just to run the VM) and a Java OS with a Java browser. It's one of those i-brow thingeys from <a href=www.merinta.com>Merinta. Passive display screen and you can't open up more than one browser window (although it will open one for you if the page requests it: target=_new, javascript, etc), but it's kind of fun. Can't wait to open it up & see what's inside!

[ Parent ]
Functional systems have been explor... (2.67 / 3) (#8)
by maynard on Thu Jun 08, 2000 at 01:23:43 AM EST

maynard voted 1 on this story.

Functional systems have been explored in both SmallTalk and previous dedicated LISP machines from Symbolics and Lisp Machines Inc., (LMI).

It seems like the push away from free UNIX to new kinds of free Operating Systems development is underway... I would hope someone might revive the FreeVMS project. There's also a free new SmallTalk implementation called Squeak which is supposed to have additional features along with a completely free license, but I haven't done enough with SmallTalk to comment intelligently.

I'd really like to see the sources to those old Symbolics operating systems open up, or have someone knowledgable of that period try and re-implement those systems on modern hardware. I had a chance to fool around with one way back when and it was really amazing. No, not just emacs on a 68K... these machines did serious work fifteen years ago!



Read The Proxies, a short crime thriller.

Re: Functional systems have been explor... (none / 0) (#19)
by Alhazred on Thu Jun 08, 2000 at 11:02:45 AM EST

Smalltalk was horribly inefficient though. I mean horribly. On a machine purpose-built to run it you could get modest performance, but the reason it never took off was pure and simply performance, and the lack of any way to really distribute software written with it. I mean you can't just "compile" a smalltalk program! Its the same problem FORTH always had, it was an awesome idea, well executed, but you just couldn't make it practical for what people really wanted to do.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Re: Functional systems have been explor... (none / 0) (#32)
by Anonymous Hero on Thu Jun 08, 2000 at 09:09:24 PM EST


I know you're gonna need heroic compilers to make smalltalk go as fast as C or C++, but I was actually surprised at how fast squeak went when I downloaded it the other day. What makes it more impressive is that it's apparently one of the slower ST implementations available, and EVERYTHING in the squeak environment is written in smalltalk (except of course the bytecode interpreter. Not blazing fast, but very useable. (p133 w/64 megs, btw)

[ Parent ]
Re: Functional systems have been explor... (none / 0) (#38)
by Alhazred on Mon Jun 12, 2000 at 02:30:34 PM EST

Cool.

FORTH historically was and is BLAZING fast, a good implementation is faster than equivalent C in almost every case, and even GNU FORTH which is built more for portability is no slouch, turning in performance far beyond Java or Smalltalk, and nearly the equal of most C code.

The problem with FORTH is that it was never really operating system aware as originally conceived FORTH programs ran on bare metal, and even with later releases there is still no really good way to compile an app down to a size anything close to a C program. Useless things like dictionary headers and the entire FORTH Kernel and all the compiler words end up stuck in your app, even assuming you have a FORTH which can "freeze" code (traditional FORTH was more like Perl, it just compiled it every time you wanted to run it).

ST has the same problems. The concept of a "program" in ST or FORTH is a weak one, and thus code tends to be dependent on the development environment to run. That just isn't acceptable in today's production software environments. This is why C rules today, once an app is compiled its lean and mean and easy to distribute.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Funny, this is the same reason I li... (3.00 / 1) (#6)
by deimos on Thu Jun 08, 2000 at 01:43:18 AM EST

deimos voted 1 on this story.

Funny, this is the same reason I like BeOS. Functional. Clean. Fast. Simplicity in an elegant form.
irc.kuro5hin.org: Good Monkeys, Great Typewriters.

Well... ... (3.00 / 3) (#7)
by PresJPolk on Thu Jun 08, 2000 at 01:48:03 AM EST

PresJPolk voted 1 on this story.

Well...

Unix used C.

Windows 95 uses C++

Next used Objective C

Emacs uses Elisp

Linux uses everything

I wonder what can be learned from this...



Re: Well...... (4.00 / 1) (#18)
by odradek on Thu Jun 08, 2000 at 10:58:02 AM EST

Win95 doesn't really use C++. The Win32 API is an ugly C monstrosity. The fact that C++ stuff (MFC,COM,ATL,et al) is being layered on top now doesn't change the fact that the roots of Win95 are in procedural languages. It has been described as "object oriented" for various reasons, including the fact that you get polymorphisms in some APIs (i.e. you can call CloseHandle to close a file handle, a memory handle, or J. Random Other Handle.) In general, though... Win95 API is a disgusting bloated beast.

[ Parent ]
Re: Well...... (4.50 / 2) (#24)
by Anonymous Hero on Thu Jun 08, 2000 at 02:12:29 PM EST

Actually, its even worse than that! As anyone who has had to deal with windows C Compilers at a fairly low level will find out, Windows has its roots in PASCAL!!! Windows C compilers jump through hoops to use silly Pascal function call constructs and packed structures! That's right kids! The toy language - PASCAL, has produced a toy OS - Windows!

[ Parent ]
Re: Well...... (4.00 / 1) (#36)
by Anonymous Hero on Sat Jun 10, 2000 at 01:33:59 PM EST

The Pascal stuff you refer to must be the calling convention used in 16-bit Windows. It was used because it is more compact than the C convention, saving several KB systemwide in Windows 1.0. This was important, as everything had to fit in 640 K. Some people argue that Pascal was used because it was the system programming language of the Mac, which Windows copied. BTW, I disagree that Pascal is a toy language.

[ Parent ]
Actually, the GUI is mostly control... (3.00 / 1) (#4)
by Decklin Foster on Thu Jun 08, 2000 at 02:01:14 AM EST

Decklin Foster voted 1 on this story.

Actually, the GUI is mostly controlled by writing to files IIRC... somewhat like a sane version of the X protocol. The papers on their site are very good reading.

BTW, if you based an OS on OOP, you... (3.00 / 1) (#3)
by jetpack on Thu Jun 08, 2000 at 02:14:07 AM EST

jetpack voted 1 on this story.

BTW, if you based an OS on OOP, you'd get Taligent's attempt at Pink, and therefore, no OS at all :)
--
/* The beatings will continue until morale improves */

I think this is a bit of a red herr... (5.00 / 1) (#2)
by sergent on Thu Jun 08, 2000 at 03:40:50 AM EST

sergent voted 1 on this story.

I think this is a bit of a red herring. The Plan 9 interfaces are simpler than C level interfaces; that's kind of the whole thing is that the interface is not about different function calls so much as it is about protocols and namespaces.

Also don't forget Alef... more Plan 9-like than C is. So I don't think the original premise of this question is necessarily well-founded... but the rest of the question is still interesting. I think Plan 9 is probably more of a counter-example is all.

Most interesting. IMHO, it seems th... (3.00 / 1) (#5)
by Gentry on Thu Jun 08, 2000 at 04:05:42 AM EST

Gentry voted 1 on this story.

Most interesting. IMHO, it seems that the choice of language dramatically affects the OS as a whole. An OO based OS would be programmed most easily using an OO API and visa versa. You could go out of your way in C++ to avoid producing an OO API but that is rather self defeating and time consuming. The available tool kits and out of the box APIs (ala Perl, Java + Python) would also have a major impact - people don't usually want to rewrite what has already been done. BeOS's networking kit is rather similar to the BSD one and is written in C and is not OO. The rest of the OS is.

Interesting point. ... (3.00 / 1) (#9)
by martin on Thu Jun 08, 2000 at 06:07:08 AM EST

martin voted 1 on this story.

Interesting point. How about Transmeta's little product - the silicon and the O/S getting a middle layer of software. BTW most real-time stuff is done in C, but Mclaren Formaul1 now do all the car stuff for the engineers to view in Java. Its not the language you do stuff in its what the overall disign paradigm (ugh hate that word) is. After all you can do anything in machine code, but certain things are easier in C, Java, SQL etc.

the OOOS (3.00 / 2) (#10)
by marks on Thu Jun 08, 2000 at 06:37:19 AM EST

This is exactly what I've been thinking about the past year; an OOOS (Object Oriented Operating System). To me, it's an obvious next step in the development of operating systems, and I've always wondered why no-one has made such a thing yet. I also agree on the OS-language binding; I am, however not very pleased by current programming languages; they all have their flaws. That's why I'm trying to design a new programming language while designing the operating system. This language will be very small, and depend a lot on it's library, which will be part of the operating system. So, no longer will the library of the language make operating-system calls, the library IS the operating system.

Smalltalk (4.00 / 1) (#14)
by Anonymous Hero on Thu Jun 08, 2000 at 10:38:02 AM EST

You should check out Smalltalk then. It is exactly as you describe it: *) Extremely compact and sensible (_pure_) OO language. *) Power relies on an extremely rich library. *) The runtime environment _is_ the OS. Except for a very small hardware-dependent piece and some runtime code, the whole environment (including compiler, GUI etc.) are written in Smalltalk. Almost every Smalltalk environment is image-based, which means that the current state of the VM is kept in a block of memory (more or less), which can be synced to the disk at any time. This gives you immediate startup and complete persistence. If you want to check out a classic Smalltalk implementation, try one of the following: *) Squeak (www.squeak.org). This is a very rich Smalltalk-80 based system. The GUI takes a while to get used to, but all the Smalltalk essentials (for development etc.)are there, as well as complete web tools and multimedia subsystem. *) Dolphin Smalltalk (www.object-arts.com). An older version can be downloaded for free. Excellent windows-based version. Check out their Education Center package. *) Cincom's VisualWorks (www.cincom.com). A very comprehensive Smalltalk development environment, probably the leader in commercial ST. You can download their complete dev product for free now. PS. If you're using a Palm, try out PocketSmalltalk.

[ Parent ]
Re: Smalltalk (3.00 / 1) (#21)
by marks on Thu Jun 08, 2000 at 11:18:05 AM EST

Wow, that sure is a lot for me to check out ;) I've heard of Smalltalk before, and I've seen a few examples of it. It certainly seemed like a nice language (being such a pure OO language). I haven't really tried programming in smalltalk before, so the next few comments might not be very accurate.
First of all, the smalltalk implementation I've seen once (I can't remember which one it is) was interpreted. This is a major drawback for me.
Secondly, I'd like to be able to program the whole of the OS in the same programming language (except maybe for a few lines of assembly bootstrap code). This is not possible with the current Smalltalk environments.
Thirdly, I don't know of any free (as in speech) Smalltalk environments. I don't want to use any non-free software.
Fourthly, because of above limitations, using Smalltalk as a language for writing the OS, would mean writing a Smalltalk compiler. Well, if I'm going to write a compiler, I might as well write one which accepts a syntax that I like (which is not like Smalltalk).
Well, I don't know if above statements are completely true, but I'm going to check out the links you've provided. Any feedback is more than welcome.

[ Parent ]
Re: Smalltalk (4.00 / 1) (#28)
by FlinkDelDinky on Thu Jun 08, 2000 at 04:45:47 PM EST

Squeak is free. Free in cost and liberty

[ Parent ]
Re: Smalltalk (none / 0) (#30)
by sakti on Thu Jun 08, 2000 at 07:07:03 PM EST

You might also want to check out Pliant. It's a very interesting programming language with a corresponding project, Pliant Default Extended Environment (PDEE).

One unique aspect of the system is that it will be able to be run on a bare linux kernel (with absolutely nothing else, besides e2fsck, not even libc). Basically an alternative to the GNU system. In a few months you'll be able to run a machine with an HTTP server, an FTP server, and SMTP server, a POP3 server (plus clients for these and a DNS client). A nice little server based only on the Linux kernel and Pliant/PDEE.

The language is not limited to this environment. It works quite well in conjuction with a normal system (currently ported to x86-Linux, FreeBSD and Win32). Pliant is sort of similar to Scheme or Forth, with a simple efficient core which is built upon. Its base is a language equivalent to C in power (and efficiency, once optimizations are added), with objects and a meta-programming system. The meta-programming system built into the language is very powerful and is really what makes the system stand out.

Its still a fairly young project in terms of development, though it has a very mature design. Its hard to do it justice here, I suggest checking out the site given above.



[ Parent ]
Re: Smalltalk (none / 0) (#39)
by Alhazred on Mon Jun 12, 2000 at 02:51:12 PM EST

I found the Pliant Syntax ungainly at best, and a lot of the claims of the authors seemed rather hard to swallow too. Plus a lot of the reasons they gave for developing a new language were things that they COULDN'T DO in Pliant as it is actually implemented. New language designs are not where the action is at. We need something else. I guess I'll have to make a post on the way I see things. I'm sure some ideas from Pliant are good ones though.
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Re: the OOOS (4.00 / 1) (#17)
by Alhazred on Thu Jun 08, 2000 at 10:57:52 AM EST

Yeah, smalltalk, or any object-oriented FORTH

The problem is performance. With the proper hardware support that might change, and such systems HAVE been designed with hardware support too (modern CPU's really don't do justice to OOP based software). There is just no compelling market reason for it. Who wants an OS that you can't just drop all your favorite apps onto and recompile?
That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Re: the OOOS (2.00 / 1) (#22)
by marks on Thu Jun 08, 2000 at 11:25:53 AM EST

>Who wants an OS that you can't just drop all your
>favorite apps onto and recompile?
I do! If everyone would just make programs that fit in nicely with all current software, not much would change.

[ Parent ]
BeOS is written in C (4.00 / 2) (#12)
by Snomed on Thu Jun 08, 2000 at 09:28:15 AM EST

If you applied C++ to an OS, would you get something like the BeOS?

According to the BeOS Bible, BeOS is written almost entirely in C.
------------------

Re: BeOS is written in C (4.00 / 1) (#13)
by DJBongHit on Thu Jun 08, 2000 at 10:27:51 AM EST

According to the BeOS Bible, BeOS is written almost entirely in C.

You sure about that? The entire API is C++ based, it would make sense to me to have written a good majority of the core OS in C++ as well.

~DJBongHit

--
GNU GPL: Free as in herpes.

[ Parent ]
Re: BeOS is written in C (5.00 / 1) (#15)
by Anonymous Hero on Thu Jun 08, 2000 at 10:45:44 AM EST

You sure about that? The entire API is C++ based, it would make sense to me to have written a good majority of the core OS in C++ as well.

The core kernel is written entirely in C. This was discussed previously either on benews.com or in Be's regular newsletters. The higher level code is written in C++, but all of the low-level stuff is written in C because it gives them greater control over speed and memory usage.

[ Parent ]

Go read Hans Reiser's stuff... (4.50 / 2) (#16)
by Alhazred on Thu Jun 08, 2000 at 10:55:09 AM EST

The same guy that wrote the Linux reiserfs. I lost the link but he wrote a VERY good paper on the need for and logic behind unified name spaces. Its funny but I remember back in the early 80's working with the old OS9 68k operating system (Unix like RTOS) and came up with the same basic concept. EVERYTHING was a file, including the entire network, every network service, every chunk of memory, etc. I believe the /proc file system is inspired at least partly by Plan 9.

Its a very powerful thing, because as Reiser explains, the power of a software system is governed by the ability to INTERCONNECT its various components. If 2 components don't share a namespace then they cannot interface with each other because one can't FIND the other, they have no way to logically specify the interconnection (thats what namespaces really do, at least partly).

Plan 9 allows all sorts of wild things, like the ability to substitute a program in place of a file (not just like pipeing, I mean totally transparently, so you think your opening a file, but when you do a program runs and sends you the output instead, and that program can be on some other machine somewhere and you don't know it). A lot of network services simply become meaningless at that point. If I can write to your /dev/lpt0 over the network then why do we need lpd? Now maybe /dev/printer is still really an interface somewhere to a print spooler, but the point is that you can under Plan 9 NAME AN INTERFACE as a file, its not really a "filesystem" anymore, its an interface system.

As for the language that a system is written in, who cares? As a matter of fact since C was developed and became popular very few OS's have been written in anything else, and its unlikely that will change in the near future. C offers unparalleled compiler performance and portability.

What's always disappointed me about Linux has always been how RETRO it really is. Its basically 25 years ago's technology warmed over. I like Linux from a practical standpoint, but I think in 3 or 4 years it will either have to be completely rebuilt to look something like Plan 9 or it will just die off. We're going to NEED these advanced OSes to do what people are contemplating doing with computers these days. Remember, in about 12 years at present growth rates a computer system will equal the human brain in raw compute performance.


That is not dead which may eternal lie And with strange aeons death itself may die.
Re: Go read Hans Reiser's stuff... (4.00 / 2) (#20)
by bmetzler on Thu Jun 08, 2000 at 11:03:05 AM EST

What's always disappointed me about Linux has always been how RETRO it really is. Its basically 25 years ago's technology warmed over. I like Linux from a practical standpoint, but I think in 3 or 4 years it will either have to be completely rebuilt to look something like Plan 9 or it will just die off.

What's always disappointed me about cars has always been how RETRO they really are. It's basically 80 year old technology warmed over. I mean, I like cars from a practical standpoint, but I think in 3 or 4 years they will either have to be completely rebuilt to look like something else, or they will just die off.

-Brent
www.bmetzler.org - it's not just a personal weblog, it's so much more.
[ Parent ]
Re: Go read Hans Reiser's stuff... (2.33 / 3) (#33)
by floorpie on Thu Jun 08, 2000 at 09:22:47 PM EST

While I agree with you disagreeing that linux will die off in a few years if it doesn't change, I think his point was that it's the same old paradigm.

Sure, cars haven't been replaced by something new... but we've also developed helicopters and space shuttles.

Yes, a car is pretty much all you need nowadays, but if you only build cars, you're going to eventually run out of places to drive to...

-floorpie

[ Parent ]
Re: Go read Hans Reiser's stuff... (4.00 / 1) (#34)
by Oxryly on Fri Jun 09, 2000 at 02:26:22 AM EST

Treating everything as a file and enforcing rigorous namespaces is a noble goal. However, like with microkernel and message based OSes, the elegant approach usually falls down in the "real world" due to performance problems.

Breaking OS components up into pipes, files, shared memory, network connections, and the ilk isn't the norm because OS implementors dislike elegance, to be sure.

Generality (power) like that found in Plan 9 comes at a high cost. You lose the ability to optimize to the task at hand... at every level from the drivers to the applications.

I suppose my point is that Plan 9 looks great only from a limited perspective... that of the OS implementor locking himself in the ivory tower preaching elegance above all.

Oxryly

[ Parent ]
Re: Go read Hans Reiser's stuff... (none / 0) (#40)
by Alhazred on Mon Jun 12, 2000 at 03:00:30 PM EST

I have 2 answers to that. 1st of all we will have HUGE numbers of CPU cycles to work with, and the cost of developing, deploying, and maintaining the software will become essentially 100% of the cost. Code efficiency will be trivial really.

The fact is that if properly implemented systems like Plan 9 need not be any less efficient than existing systems. Again, go read Reiser's papers. Right now people are endlessly reinventing the same old functionality in slightly different iterations because they lack the generality of universal naming and a complete implementation of naming.


That is not dead which may eternal lie And with strange aeons death itself may die.
[ Parent ]
Re: Go read Hans Reiser's stuff... (5.00 / 1) (#41)
by Oxryly on Tue Jun 20, 2000 at 02:35:55 AM EST

1st of all we will have HUGE numbers of CPU cycles to work with, and the cost of developing, deploying, and maintaining the software will become essentially 100% of the cost. Code efficiency will be trivial really.

This seems to be an old fallacy. Huge increases in CPU speed always seem to indicate that soon efficiency will be less of a consideration. The fact is, we always find plenty to do (besides write more and more general and inefficient OSes) with the cycles. Performance is and always will be crucial.

I suppose a good way to think of it is that the computer's primary purpose will be the application, not the OS, so OSes that steal away precious cycles and memory always interrupt the main purpose of the computer and will always be avoided. More cycles means more cycles available to applications... ideally.

Oxryly

[ Parent ]

"systems research is dead" -- yeah right (4.00 / 2) (#23)
by Anonymous Hero on Thu Jun 08, 2000 at 12:47:20 PM EST

For an example of a new OS design which is based on a functional programming language (a dialect of lisp), check out Vapour at http://ftp.rook.com.au. The design is very unconventional by UNIX standards -- no files, no kernel, no binary compatibility even on the same platform. But it has many benefits including the best security model I've ever seen.

Please note that this is a work in progress...the device drivers and compiler are still being written and many aspects of the system are as-yet unplanned; please don't pester this guy with annoying messages, since I'm probably not supposed to be telling you about this anyway.

Are files a good fundamental abstraction? (3.00 / 1) (#25)
by dgph on Thu Jun 08, 2000 at 02:54:23 PM EST

When I think of files, I think of storage or communication. It seems to me that many objects in an OS are not file-like. Many file/objects would have to interacted with by ioctl commands to do anything useful with them. So why make everything file-like in the first place? Why not just have objects as the fundamental unit of a system?

Re: Are files a good fundamental abstraction? (4.00 / 1) (#29)
by Logan on Thu Jun 08, 2000 at 06:20:13 PM EST

Aren't files objects and ioctl calls message passing? It's crude, but it's the same idea.

logan

[ Parent ]

Q'n'D license analyis (none / 0) (#35)
by kmself on Fri Jun 09, 2000 at 12:47:53 PM EST

I'm not a lawyer, but I play one on the 'Net. Following is an analysis I posted to some people who are into that sort of thing.

Lucent has released Plan 9. They've written their own license in the process: http://plan9.bell-labs.com/plan9dist/license.html.

Quick synopsis:

  • License allows for commercial and noncommercial use, though it doesn't define the terms, they're not meaningfully distinguished, making mooting the distinction.
  • Primary grant addresses both copyright and patent, language similar to MozPL and IBM PSL. Trademarks are addressed seperately.
  • This isn't a strict copyleft -- alternative licensing of object code and modifications appears to be allowed.
  • There is an obligation to provide modifications to the original developer, on request. This is a forced disclosure clause similar to the SCSL language.
  • There is an obligation (3.4) of source distribution to third parties who receive the work in non source-code form. Whether or not this is sufficiently strong to be a copyleft, or could be weakened over several generations of derivation as with the Artistic License, is somewhat unclear. It appears that different rights to modifications may be allowed to apply to the original work than from third party modifications, though sources must be distributed. I don't believe this is a copyleft.
  • Termination language is interesting, and contains a "quit if claimed" clause -- the license terminates if any IP actions are initated:
    6.0 Termination
    The licenses and rights granted under this Agreement shall terminate automatically if (i) You fail to comply with all of the terms and conditions herein; or (ii) You initiate or participate in any intellectual property action against Original Contributor and/or another Contributor.
    (ii) reads as a mutual non-agression pact to my eyes. This is a step up from the IBM PSL language, though less broad than the patent trap I'd proposed at the second OpenSales licensing workshop.
  • Disclaimers of warranty and liability -- MEGO boilerplate, though some of the language differs from what's commonly used. The real lawyers should look it over.

I'm developing a theory of licensing I apply to both corporate and non-corporate entities. I loosely (and toungue-in-cheek) call "fear and greed". Classic business sense, no pejorative (and if you'll look up the terms in a search engine, most of the top hits involve busines and/or finance).

Free software licenses reflect an organizations fear and greed motivators. Fear being the things an orgainization is afraid of -- either losing control of or being hit with. Greed being the things an organization is hoping to secure -- benefits, direct or otherwise.


"Fear and greed" analysis of the Lucent License:

Fear motivators: The standard warranty and liability terms. As with most companies, trademark and patent are addressed, as with Netscape, Sun, and IBM. Contribution of modifications appears to be a concern, reflected by the requirement of contributing modifications at request. Unique to this license are limitations as applied to specific Lucida fonts included in the Plan 9 OS, though whether these represent valuable property of Lucent, third-party works which cannot be licensed, or both, I'm not sure.

Greed motivators: For a corporate license, this is fairly friendly to both developers and other companies -- termination patent language could offer fairly broad protections. The only readily apparent rights / obligation asymmetry is in the section 4.0 requirement to provide modified sources and documentation to the original developer on request. This may not be a minor consideration to some potential licensees. I don't see this as a standards-promotion license in the same manner as a BSD or MIT/X license -- proprietized development of the work doesn't appear to be permitted under 3.4.

That's a quick and sleep deprived read. Corrections welcomed.

--
Karsten M. Self
SCO -- backgrounder on Caldera/SCO vs IBM
Support the EFF!!
There is no K5 cabal.

OS and language shouldn't be coupled. (none / 0) (#37)
by Nelson on Sat Jun 10, 2000 at 01:34:52 PM EST

There shouldn't be any coupling in terms of what 2nd party developers need to use to achieve maximum benefits. That's generally how it is too.

In the future I could see that potentially changing, but it will take a pretty dramatic advancement in programming languages and compilers and some radical work in OS and API design. Right now, there are basically two programming paradigms, funtional and non-functional. OOP is pretty much just syntatical sugar, there isn't any expressive power you get over anything else. Everything the compilers are doing for imparitive and OOPLs are identical, I see no reason to believe that you'd get something different if you wrote a kernel in C++ instead of C.

Now if I could simply subclass a driver and change a couple methods to produce a new driver then there would be the start of an argument to more tightly couple langage and OS. Of course if you're going to allow that then why not use an ORB and stay language neutral?

I also think there is something to be said for having OS source. I've been hacking the linux kernel for a job now and the access to the source is letting us do things that are unparalleled with other projects the company has done. We can fine tune, optimize, figure things out, change things. We're in a specialized embedded field but I see the same advantages on the desktop and server, it will just take longer to figure them out and package them up for easier access by the masses. I'm not exactly sure how to word the idea but you can realistically only hook in to so many places in a kernel like NT, it's up to MS to figure it all out and provide enough hooks. With something like linux you can hook in where ever you need to, period. It really changes the rules to what you think of as a good API or why you would design some things a certain way. The windows' and Plan 9's (before recently) and OS/2s and what have you all design their APIs to maximize programmer freedom while keeping secrets secret, there is some fundamental obfuscation that occurs simply because you can't see the other side of the fence. I don't think the gravity of this has fully been realized by the programming masses yet, it puts the whole game on it's ear.

The Language and the System | 41 comments (41 topical, 0 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!