31–40 of 86 posts
Plan 9 was and is too good to be ignored. Indeed many of its features are now a must in Linux systems (for example good support for private namespaces) and the p9fs, designed to be virtualizable and distributed, is getting serious traction in the virtualization world (see 9p virtio). And Plan 9 also has the best mascot around!
First, one should note that this is a chapter (or section) of "The Art of Unix Programming", by esr; it is a fantastic book (I'm going through it now, on chapter 9 of 20, and the wisdom has been near-palpable). As for the specifics of the article. Plan 9 did indeed do many things right; in fact, many things are done in a very Unixy way. For example, the networking stack is build precisely where it ought to be: as a d…
- FUSE for file systems that are generated programmatically or exportable over a network. [http://code.google.com/p/macfuse/]
- The approach to concurrency and network programming in the Go language. [http://golang.org/]
Both of which show that problems that we used to leave to the OS can be elegantly solved in userland, which is a good thing.
Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this c…
You could configure it by doing something like echo "22050" > /dev/dsp/config/sample_rate_hz echo "lanczos" > /dev/dsp/config/resample_algorithm You could then search for configs by using find, back them up by using tar, be able to easily replicate settings between computers using rsync etc. The idea is not to have one unconfigurable binary reciever, but rather to expose the interface as a hierarchy of rw files inste…
It _is_ configurable, why do you think it is not?
This idea that somehow one can fit any interaction with hardware into a filesystem ends when hardware becomes complex enough to simply NOT fit (like modern GPU).
How do you guarantee atomicity when saving configuration with tar(1)?
Linux recently deprecated textual conntracking data interface in favour of shipping binary data over netlink socket. Reason -- read() speed in real life high load scenarios.
What could Plan9 do here?
Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this c…
You could configure it by doing something like echo "22050" > /dev/dsp/config/sample_rate_hz echo "lanczos" > /dev/dsp/config/resample_algorithm You could then search for configs by using find, back them up by using tar, be able to easily replicate settings between computers using rsync etc. The idea is not to have one unconfigurable binary reciever, but rather to expose the interface as a hierarchy of rw files inste…
Am I the only one who doesn't get excited about the idea of absolutely everything being a file? People seem to like the idea of being able to say things like "cat file.wav > /dev/dsp". But a sound card is a complex thing that can be configured in umpteen different ways; what if the file has a different sample rate than the card is currently running at? Even if you gerry-rigged a kernel driver that could handle this c…
Don't think of it as everything being a file. Think of it as accessing everything including file data through an RPC system.
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.
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…
The problem wasn't that the Plan 9 guys opposed commercialization, quite the contrary, the problem was that AT&T never let the system become open source. For some time it wasn't even available outside universities. That killed it. Yes, acme doesn't have keyboard shortcuts, I use it every day.
The whole thing except the fonts was put under a very liberal open-source licence 10 or 12 or so years ago. (By then it was owned by Bellcore or Lucent, not AT&T.) Before then there were severe restrictions; is your opinion that by time the severe restrictions were lifted, it was too late because Linux had already become entrenched?
Earlier quoted context omitted.
The problem wasn't that the Plan 9 guys opposed commercialization, quite the contrary, the problem was that AT&T never let the system become open source. For some time it wasn't even available outside universities. That killed it. Yes, acme doesn't have keyboard shortcuts, I use it every day.
>the problem was that AT&T never let the system become open source. The whole thing except the fonts was put under a very liberal open-source licence 10 or 12 or so years ago. (By then it was owned by Bellcore or Lucent, not AT&T.) Before then there were severe restrictions; is your opinion that by time the severe restrictions were lifted, it was too late because Linux had already become entrenched?
Earlier quoted context omitted.
You could configure it by doing something like echo "22050" > /dev/dsp/config/sample_rate_hz echo "lanczos" > /dev/dsp/config/resample_algorithm You could then search for configs by using find, back them up by using tar, be able to easily replicate settings between computers using rsync etc. The idea is not to have one unconfigurable binary reciever, but rather to expose the interface as a hierarchy of rw files inste…
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?