* Re: [9fans] Some Plan9 questions
2003-02-11 22:36 ` [9fans] Some Plan9 questions Matt Keeler
@ 2003-02-11 22:50 ` Scott Schwartz
2003-02-11 22:55 ` Ronald G. Minnich
` (2 subsequent siblings)
3 siblings, 0 replies; 10+ messages in thread
From: Scott Schwartz @ 2003-02-11 22:50 UTC (permalink / raw)
To: 9fans
| 1) My main question is how much compatibility is there between Plan9 and
| other UNIX-based operating systems, like BSD, Linux, etc.? That includes
| running applications that were developed for Linux, BSD, and UNIX systems in
| general.
Plan 9, unlike GNU, really is not Unix. Compatability with old mistakes
is not a feature of this system.
| 2) If Plan9 does not run applications that other UNIX operating systems can
| run, how hard is it to port the code over?
Some vanilla ANSI/POSIX programs can be ported with the help of a
compatability library, and some degree of fuss.
Mostly, though, Plan 9 users feel like the point is to not reinvent the
old stuff.
| 3) How hard is it for someone who is coming from a more common UNIX OS to
| get used to Plan9?
Not hard. Plan 9 has its quirks, but it was designed by just a few very
smart people, so you get a clear sense of their vision. Read the man
pages on the web site to see what I mean.
| 4) How popular is Plan9? This is just a question I ask out of plain
| curiosity.
There are about 400 people on the mailing list.
(Not counting list exploders and usenet readers.)
^ permalink raw reply [flat|nested] 10+ messages in thread* Re: [9fans] Some Plan9 questions
2003-02-11 22:36 ` [9fans] Some Plan9 questions Matt Keeler
2003-02-11 22:50 ` Scott Schwartz
@ 2003-02-11 22:55 ` Ronald G. Minnich
2003-02-12 18:32 ` north_
2003-02-11 23:25 ` Russ Cox
2003-02-12 0:13 ` Russ Cox
3 siblings, 1 reply; 10+ messages in thread
From: Ronald G. Minnich @ 2003-02-11 22:55 UTC (permalink / raw)
To: 9fans
On Tue, 11 Feb 2003, Matt Keeler wrote:
> 3) How hard is it for someone who is coming from a more common UNIX OS to
> get used to Plan9?
Speaking for me, there are at least 3 learning curves. Initially it's not
too bad (8c for cc, etc). Then you start trying to learn how to really use
the system, and learn how to use Acme etc., and unlearning all the dumb
things you learned to get used to Unix; e.g. getting used to using bind to
make it easy to build kernels without modifying the base kernel tree
(truthfully, how many of you out there started out using
disk/kfscmd allow
when you wanted to modify the kernel source? I happen to know one such
person who is now a prolific Plan 9 contributor ...)
The 3rd learning curve for me has been the steepest, trying to wrap my
brain around everything. Watching all the clever things people do.
Trying to set up a cpu cluster ...
Once you see all this stuff and go back to Unix, you keep saying "damn!
this is stupid! I wouldn't have this problem on Plan 9!". It's depressing
at times.
Oh yeah, program the graphics. You'll never want to touch X11 again.
Learn it well, it's worth it. The OS world by and large is not that
interesting right now, save for things like Plan 9.
ron
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [9fans] Some Plan9 questions
2003-02-11 22:36 ` [9fans] Some Plan9 questions Matt Keeler
` (2 preceding siblings ...)
2003-02-11 23:25 ` Russ Cox
@ 2003-02-12 0:13 ` Russ Cox
3 siblings, 0 replies; 10+ messages in thread
From: Russ Cox @ 2003-02-12 0:13 UTC (permalink / raw)
To: 9fans
> 1) My main question is how much compatibility is there between Plan9 and
> other UNIX-based operating systems, like BSD, Linux, etc.? That includes
> running applications that were developed for Linux, BSD, and UNIX systems in
> general.
> 2) If Plan9 does not run applications that other UNIX operating systems can
> run, how hard is it to port the code over?
> 3) How hard is it for someone who is coming from a more common UNIX OS to
> get used to Plan9?
This isn't an answer to any one of these questions but at the
same time it addresses all of them.
As Scott said, you have to come at Plan 9 with an open mind.
System interfaces that are felt unnecessary or clunky are
not implemented, and this makes Plan 9 nice but also makes
it not Unix. ANSI C code typically is easy to compile. Once
you get into heavily POSIX code, things get harder. The graphics
and networking models are completely different (much simpler),
so graphics code almost never ports, and network code only
sometimes ports (if it uses select, you've got your work cut
out for you, though APE can make that easier).
I don't know what your level of interest in IRC is, but it's a good
recent example. On most systems if you wanted an IRC client
you'd just port some other IRC client and end up with an IRC
client. But Plan 9 isn't really a good base for running external
programs. There's no X11, there's only rudimentary cursor
addressing, so you'd have to port a command-line program.
(If you want to run a Unix program, that's what Unix is for.)
The Plan 9 way to attack the problem would be to step
back and wonder whether there was a simpler and/or more
general interface that might be good.
I occasionally use IRC and AIM and ICQ, and would like to be
able to do so in Plan 9 rather than switching to Windows XP.
I wrote an ICQ implementation six years ago, but it ran in a
window by itself and I'd always forget about it, and it still
didn't really fit well with the rest of the system. A few
months ago I started thinking about this again, and have slowly
(a few hours here and there, very occasionally) been building
a generic chat file system interface:
/*
* Chat file system. Conventionally mounted on /net to provide /net/chat,
* for some value of chat.
*
* clone open and read to obtain new connection
* n connection directory
* ctl control messages (like connect user)
* data retrieved data
* err last error
* local local name
* remote remote name or channel
* status connection state
* who list of people in chat room
* ... other protocol-specific files
*
* The connect message typically takes the following possible addresses:
*
* #channel a channel
* chat room a chat room
* user a user
* *snoop* all traffic
* *mop* traffic with nowhere else to go
*
* It would be more true to form if there weren't a *mop* but instead
* you announced chat!you and then listened for connections.
* The *mop* is good enough.
*
* The data file returns messages one at a time. The messages are attr=value
* lists that can be parsed with the attribute parsing routines in auth.h [sic].
* Typical attributes include:
*
* src who is sending the message
* dst destination for message (you, a chat room)
* cmd command being sent
* args other arguments
*/
I have an IRC implementation of this pretty much done,
and I plan to do an AIM TOC implementation too. Once you've
got this as a building block, it's easy to build whatever
interfaces you want on top of it. I have a fairly nice Acme gui
pretty much done. (Because of Acme and win, it's hardly
any code.) You could build a really simple gui using rio
windows (using the same code, actually) with one window
per conversation. In a pinch, con -l 'irc!#plan9' would work
reasonably, and it's great for debugging. Another nice
thing is that suppose you want to write some sort of 'bot.
It could be something complicated, or something as trivial
as logging a particular chat session (or all your chat sessions).
Since all the programs can use the fs interface, none of them
have to worry much about the details of connection setup
or anything like that. And one connection can be shared
between many programs without any extra effort.
While there will probably be slight differences in syntax
and the frills commands that can be executed on each
network, the core interface is the same meaning that I'll
have multiprotocol guis for free.
I think the end result is that it will fit well with the
rest of the system and be more pleasant to use than
most standalone clients.
> 6) Is there going to be another release? If so, any idea when?
In a sense, the fourth edition release is the release to end
all releases. System updates are now distributed via a
Plan 9 file server on the internet, sources.cs.bell-labs.com.
We put changes out much closer to as they occur than ever
before. Some of us run generic installations as our day-to-day
system, which provides incentive to keep sources and the
internal Bell Labs system in sync.
There are no really big changes planned at the moment.
9P2000 was the big addition for the fourth release and
we're still coming to terms with a lot of that. If big
changes happen down the road then maybe that would be
another number.
But releases in the small happen very frequently.
Russ
^ permalink raw reply [flat|nested] 10+ messages in thread