Live data from Hacker News

Plan 9: The way the future was

catb.org

61–70 of 86 posts

Re: Plan 9: The way the future was

#61
post #28

I always find it pretty sad that while everybody speaks about the integrated environments of Smalltalk and Plan 9, Niklaus Wirth's Oberon is almost left forgotten…

One of the Plan 9 papers actually refers to Oberon as an example of a similarly integrated system. I believe it's the one titled 'The Use of Name Spaces in Plan 9,' but I'm not certain.

Unfortunately, the server is down right now so I'm unable to check but, if you're curious, the various papers can be found here: http://plan9.bell-labs.com/sys/doc/

Re: Plan 9: The way the future was

#62
post #14

Earlier quoted context omitted.

http://plan9.bell-labs.com/magic/man2html/3/audio

I'm not sure that really contradicts his point, that's a terribly limited API. Stereo only, no way to specify channel layout, 16bit only, no way to change the device buffer sizes, no way to tell if the device is in use, no way to tell the device latency, seemingly no way to examine what sample rates or bit depths the device supports, seemingly no way to subscribe to any kind of notification when the device has actual…

The thing to keep in mind is that this was written for a SoundBlaster back in the early 90s. I remember being really impressed that Commander Keen 4 could use the SoundBlaster 16 in my 486 to make decent music at all.

As for notifications of device property changes, you would probably get them by reading from the various control and status files. Although I use Plan 9 at home and at work, I have never really done anything with audio, I'm afraid.

Re: Plan 9: The way the future was

#63

The impression I got was that the guys behind Unix were annoyed when their operating-systems research was stalled in the name of "API compatibility", so they started Plan 9 and actively resisted commercialisation for as long as possible (for example, they gave it the least marketable name they could think of). There's so many interesting ideas in Plan 9, I'm occasionally tempted to install it and try it out... but th…

Regarding acme, everyone comes in and goes "Yuck, you mean I can't type 'C-c M-x undoify'?" However, once you get used to it, it's actually rather nice. I have something like 30-40 files open in acme right now, and I find it far, far easier to manage open buffers than in Emacs. Arranging and re-arranging buffers (to use the emacs term, since it's familiar) is very convenient and helps me keep things organized.

It also has "mouse shortcuts" (chords) that tend to reward using the mouse more--meaning you don't need to switch from mouse to keyboard as often, because you can do cut, copy, paste, search, command execution, etc. all with a click of the mouse (and no hunting through menus, either).

It's hard to explain... you really have to use Acme, or even better, watch someone use it. http://www.youtube.com/watch?v=dopu3ZtdCsg seems to be a decent intro, although I haven't had time to watch the whole thing yet.

Re: Plan 9: The way the future was

#64
post #42
post #2

Ugly now beats beautiful later. An elegant solution requires a deep understanding of a problem, and that understanding takes a lot of data (awareness of cases), and then a lot of time and effort to create a simple theory of it and to create a simple solution embodying that theory.

The trick is to build ugly systems that are able to grow into beautiful ones.

That is quite a trick. The problem is that pretty soon, everyone depends on the behavior of the ugly warts in your original system, so now you're stuck with them lest you break the holy Compatibility.

Re: Plan 9: The way the future was

#65
post #59
post #10

Earlier quoted context omitted.

> And I've come to terms with the fact that Plan 9 will > never, ever become the standard OS --- it is simply > not designed for any battlegrounds except those it > has already lost in Why is 9p cool? Are there any gaps - for example - lack of good support from scripting languages? Have there been any serious attempts at creating a plan 9 rackspace or cloud service? Maybe you could get a hobbyist community grown arou…

9P is cool, but 9P is not Plan 9. 9P is the Plan 9 filesystem protocol. Plan 9 lacks emacs, bash, C++, and a full-featured web browser; this alone is enough to make a lot of people post once on the mailing list bitching about it, then never come back. It does have vim now, although its use is not encouraged because we have other editors. If you come at Plan 9 as though it's "just like Unix", you're going to have a ba…

Are there reasons why it would be hard to port Unix software to it? Could something like Cygwin be developed to help make it easier to run Unix-ish software on it?

Re: Plan 9: The way the future was

#66

The real shame is that inferno never became android. It was around early enough. Had the right feature set. I guess it was not in Google's backyard (America) and had lost it's backbone a little to early. I guess when Google was shopping for mobile OS they were also looking for a talent grab. With Inferno by 2005 most had already left.

By 2005 most of the team that created Plan 9 and Inferno at Bell Labs were already working at Google.

But they were working on other stuff, like Go.

Re: Plan 9: The way the future was

#67
post #61
post #28

I always find it pretty sad that while everybody speaks about the integrated environments of Smalltalk and Plan 9, Niklaus Wirth's Oberon is almost left forgotten…

One of the Plan 9 papers actually refers to Oberon as an example of a similarly integrated system. I believe it's the one titled 'The Use of Name Spaces in Plan 9,' but I'm not certain. Unfortunately, the server is down right now so I'm unable to check but, if you're curious, the various papers can be found here: http://plan9.bell-labs.com/sys/doc/

Probably the acme paper. Oberon definitely had the mouse chording, not sure if there's previous art in that regard.

Re: Plan 9: The way the future was

#68
post #65
post #59

Earlier quoted context omitted.

9P is cool, but 9P is not Plan 9. 9P is the Plan 9 filesystem protocol. Plan 9 lacks emacs, bash, C++, and a full-featured web browser; this alone is enough to make a lot of people post once on the mailing list bitching about it, then never come back. It does have vim now, although its use is not encouraged because we have other editors. If you come at Plan 9 as though it's "just like Unix", you're going to have a ba…

Are there reasons why it would be hard to port Unix software to it? Could something like Cygwin be developed to help make it easier to run Unix-ish software on it?

It comes with a library called APE (see [1]), which provides most POSIX-y things implemented in terms of Plan 9 native API:s. (For example, BSD socket operations are just functions wrapping the normal file reads and writes that you would do in native Plan 9 code.)

Some things do not work, though (permissions models are a bit different, and chroot is entirely unimplemented, for instance).

1: http://doc.cat-v.org/plan_9/4th_edition/papers/ape

Re: Plan 9: The way the future was

#69
post #59
post #10

Earlier quoted context omitted.

> And I've come to terms with the fact that Plan 9 will > never, ever become the standard OS --- it is simply > not designed for any battlegrounds except those it > has already lost in Why is 9p cool? Are there any gaps - for example - lack of good support from scripting languages? Have there been any serious attempts at creating a plan 9 rackspace or cloud service? Maybe you could get a hobbyist community grown arou…

9P is cool, but 9P is not Plan 9. 9P is the Plan 9 filesystem protocol. Plan 9 lacks emacs, bash, C++, and a full-featured web browser; this alone is enough to make a lot of people post once on the mailing list bitching about it, then never come back. It does have vim now, although its use is not encouraged because we have other editors. If you come at Plan 9 as though it's "just like Unix", you're going to have a ba…

> Plan 9 lacks emacs

That's a feature: http://plan9.bell-labs.com/magic/man2html/1/emacs

Re: Plan 9: The way the future was

#70
post #65

Earlier quoted context omitted.

Are there reasons why it would be hard to port Unix software to it? Could something like Cygwin be developed to help make it easier to run Unix-ish software on it?

It comes with a library called APE (see [1]), which provides most POSIX-y things implemented in terms of Plan 9 native API:s. (For example, BSD socket operations are just functions wrapping the normal file reads and writes that you would do in native Plan 9 code.) Some things do not work, though (permissions models are a bit different, and chroot is entirely unimplemented, for instance). 1: http://doc.cat-v.org/plan_…

That shouldn't prevent things like scripting languages or web browsers to be ported.
Post reply on HN