A good introduction to the Plan 9 UI I found, for any who are interested: http://vimeo.com/7748726
Plan 9: The way the future was
81–86 of 86 posts
Re: Plan 9: The way the future was
#82Earlier 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…
> that's a terribly limited API.
Plan 9's users consider that a feature. Standing boast: "GNU's compiler manual is bigger than our whole system!"
> I don't know enough about plan9 to suggest how, for example, notifications for device property changes could be added.
You'd add a virtual file named "ctl". Processes could open it and call read, which would block until something changed, then return with the notification.
Those processes will need threads that work. Plan 9's do.
Re: Plan 9: The way the future was
#83Earlier quoted context omitted.
That API seems so clunky. What if I have two different programs, with different sample rates, which I want to play back at the same time?
Each program sees its own copy of /dev/dsp. Behind the scenes, that copy is backed by some magic on the OS's part that handles state tracking, mixing, etc. The program only ever sees a dumb bit bucket with some flags on how to handle it--that's why we have OSs, after all: to avoid having to write hardware driver code for all our programs (see the bad old days of DOS game programming). The program still needs to manag…
Thanks to you and others who pointed out that plan9 exposes private copies to each program. I did not know that, and it would solve the issue I wondered about.
But that doesn't solve the underlying issue. If my program uses two libraries, both of which play sounds, then how does each library get its own configuration filesystem? Is there a way to create a new view, so that the two libraries can be disconnected from what the main program needs?
Re: Plan 9: The way the future was
#84Earlier quoted context omitted.
>Am I the only one who doesn't get excited about the idea of absolutely everything being a file? Don't think of it as everything being a file. Think of it as accessing everything including file data through an RPC system.
It's been a while since I looked at 9P. Is it really that much like an RPC system?
It lets you name resources and open communications channels to them, yes. It even preserves message boundaries, as I recall.
Re: Plan 9: The way the future was
#85Earlier quoted context omitted.
I actually tried to point out that configurability _is_ very possible with such an API. Your complexity argument does not hold. If I can control something with a C API, why not with a file API? Take atomicity as an example. C has no inherent concept of atomicity. Yet you can acheive atomicity by using C. So why not with a REST or file-based interface? You also mention speed. Interesting since complexity and performan…
> Take atomicity as an example. C has no inherent concept of atomicity. Yet you can acheive atomicity by using C. So why not with a REST or file-based interface? You achieve atomicity because inside kernel handler of relevant imaginary ioctl(2) which dumps all hardware configuration there is synchronization primitive which provides necessary guarantees, so this imaginary ioctl(HW_GET_STATE) writes coherent state to u…
[deleted]
Re: Plan 9: The way the future was
#86The 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 als…
C-c M-x undoify ?
In vim it's just: u
Much simpler and quicker than stretching your arm to the mouse, futzing around with the cursor to find god knows what menu option, clicking on it, and moving your hand back to the keyboard.
Having 30-40 files open in an editor is not impressive either. You can easily have hundreds of files open in vim, and navigate between them without a problem.
The mouse chords might make the mouse more functional, but it's certainly a far cry from having over 100 keys and thousands of key combinations at your fingertips.
Not that using the mouse excludes the possibility of using the keyboard, but as a vim user I almost never have need to use the mouse -- except when I've switched to vim from another application that requires mouse use and want to paste something. After that, my hand goes right back to the keyboard, because using the keyboard is just far more efficient.
Acme's forcing mouse use on the user is one reason I am really not very interested in using it. However, I am interested in seeing if there is anything it can do that doesn't absolutely require mouse use that could be integrated in to vim.