"Those who don't understand UNIX are condemned to reinvent it. Poorly." – Henry Spencer
Except that Plan 9 was designed by the people who built UNIX. Are you implying that the people who built UNIX don't understand it?
No, no! Quite the reverse.
Plan 9: The way the future was
51–60 of 86 posts
Re: Plan 9: The way the future was
#52This need updating. "The Room", a film that came after the article was written, is obviously worse than either "Manos" or "Plan 9", as anyone who saw even its first minutes will readily attest. edit: I'm sorry. I often forget my colleagues are humourless at this time in the morning.
I think "Birdemic" would be more appropriate, since the first half is about someone pitching a tech startup (and the second half is about being vomited on by animated GIFs of birds).
Re: Plan 9: The way the future was
#53Am 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…
> 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? That's what ioctl does: http://www.manpagez.com/man/2/ioctl/
Sure, you can use an ioctl for this. You could use some combination of ioctl()s to tunnel absolutely any API, just like you can wrap any text string in pointy brackets and call it XML.
The question is whether this is useful. In particular, once your interface requires ioctl(), you lose the benefit of easy interoperability with UNIX command-line tools.
Re: Plan 9: The way the future was
#54Earlier 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…
> The idea is not to have one unconfigurable binary reciever, 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 s…
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).
The idea that one can fit any interaction with hardware into the mere toggling of registers and stuffing of byte buffers...
I don't know what FS you're using, but any good modern filesystem (say, ZFS or something similar) should prove more than adequate for handling that many/that size nodes.
Everything else can probably be fixed in the kernel level--for example, duplicating the hardware directory prior to tar'ing it, and have the kernel/FS note what actions to do to guarantee atomicity. I mean, we do the same thing with sharing /dev/dsp anyways (I believe daemons can be set up to handles this), so what's the deal?
Re: Plan 9: The way the future was
#55Am 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…
The HUGE advantage of "everything is a file" is that if you make a tool that works on one "thing" and then want to use it on another "thing" it is quit possible that it will just work. For instance, on OSX, one of the things I sorely miss is the sysfs from Linux. Sure, OSX has the ioreg, but I cannot use the tools I am used to (find, grep, cat, echo, sed, awk, ...).
To put it in terms the web programmers can understand, it is like REST, you have a GET (read), and a POST (write), and I suppose a DELETE (unlink), and with that you can implement all you need. Everything fits into a very few syscalls (open, read, write, close).
Re: Plan 9: The way the future was
#56Earlier 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?
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 manage sound mixing in userland to fill that buffer. That's nothing new, however, and you can use PortAudio, FMOD, XACT, whatever to do that mixing for you, or roll your own.
This abstraction would greatly simplify that process.
Re: Plan 9: The way the future was
#57I 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…
For over a decade, dozens of actual people used Plan 9 as their main environment. (Many but not all of these people worked at Bell Labs.) I tend to believe that Smalltalk has also seen serious numbers of actual users. In contrast, who has ever used Oberon as their main software environment except perhaps students required to do so to pass some class?
If we're talking about popularity contests here, all the "contestants" aren't doing very well…
Re: Plan 9: The way the future was
#58Plan 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!
It helps that Eric Van Hensbergen, the guy behind 9p virtio, was a Plan 9 developer.
s/was/is/
He was one of the guys that ported Plan 9 to the Blue Gene supercomputer. He has many active projects in the Plan 9 community.
Re: Plan 9: The way the future was
#59First, 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…
> 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 bad time. Expecting to access it via ssh is one part of that--yes, we have an old ssh server, and yes we now have ssh v2 client support, but to access a Plan 9 system you want to use something like drawterm on Linux/Windows/Mac or cpu from another Plan 9 system.
I'm on sdf but have not played with my Plan 9 instance much. If you want to start off experimenting, I'd recommend just firing up VMware or Virtualbox instead. If you decide you want a physical Plan 9 system, well, I've found that it runs pretty well on every Thinkpad I've ever tried.
If you want more info, you can ask here or email me (check my profile).
Re: Plan 9: The way the future was
#60This need updating. "The Room", a film that came after the article was written, is obviously worse than either "Manos" or "Plan 9", as anyone who saw even its first minutes will readily attest. edit: I'm sorry. I often forget my colleagues are humourless at this time in the morning.
I think "Birdemic" would be more appropriate, since the first half is about someone pitching a tech startup (and the second half is about being vomited on by animated GIFs of birds).
I can't disagree with facts. According to IMDB, http://www.imdb.com/title/tt1316037/ is worse than http://www.imdb.com/title/tt0368226/