From: Mike Haertel <mike@ducky.net>
To: 9fans@cse.psu.edu
Subject: Plan 9 annoyances (was: Re: [9fans] mv vs cp)
Date: Mon, 8 Oct 2001 01:38:00 -0700 [thread overview]
Message-ID: <200110080838.f988c0Y95817@ducky.net> (raw)
In-Reply-To: <20011008082741.X28720@cackle.proxima.alt.za>
>> Often. This is one of the things that most irritates me about Plan 9.
>
>Talk about extreme responses :-)
What's this, can't the Plan 9 Thought Police take a little criticism? :-)
More seriously, an extreme response would be something like giving
up Plan 9. If anything, I am using it more often these days.
That said, there are numerous irritations. Some are architectural
and unlikely to be fixed, others are easy to fix. Here's a sample:
* The existence of non-network-transparent kernel devices like /srv
which don't work when accessed by exportfs on behalf of a remote machine.
* The need for /$objtype/bin/ape/psh, which is a #!/bin/rc script.
(Exercise for the reader: explain why this exists even though the
same script can also be found in /rc/bin/ape/psh.)
* Lack of long file names. (Someday to be fixed in 9P2000.)
* Other arbitrary limits in programs. Everyone is familiar with line
length limits in various utilities. Lots more obscure ones, like
max 512 files in ramfs. Avoiding arbitrary limits is something the
GNU folk got really right, because one person's "this is a reasonable limit"
is another's "how could those morons set such a low limit?" It's easy
to get right and you should Just Do It.
* rio windows are not searchable, but on the other hand acme "win" windows
won't let you run graphics programs.
* Lack of find and xargs. I don't need creeping featurism like "chmod -R",
but there should be *some* mechanism for mapping commands over the
file hierarchy.
* Anemic functionality in diff, and lack of patch. For example, GNU
diff will at least tell you whether binary files differ; Plan 9 diff
just gives up.
* Bad release engineering. For example, in /sys/src:
"mk all" builds the commands in /sys/src/cmd, but doesn't
build the commands in subdirectories of /sys/src/cmd.
(you need to also go to /sys/src/cmd and do "mk all.directories")
why?
"mk clean" doesn't remove every generated file. try (say)
"find . -mtime -1 -type f -print" after rebuilding the world.
(oops, forgot--Plan 9 doesn't have "find".)
"mk all" installs some things even though there is a
separate "mk install" target for installing. the lib*
makefiles are particularly annoying in this regard.
* Poor support for symbolic debugging. This one has always baffled
me because Bell Labs had an amazingly pleasant debugger called "pi"
under v10.
* Poor memory management. On my 1GB desktop system, a ridiculous amount
of kernel memory gets allocated to pixmaps, but kfs still uses only 2mb
for file buffers. (Yes, I know I'm supposed to use the dedicated file
server... someday soon.)
* Lack of a web browser. Sigh, even those of us who should know better
get caught. ("Hey man, you've got to try this stuff... don't worry,
you can't get addicted if you just try it once!")
* /lib vs. /sys/lib
next prev parent reply other threads:[~2001-10-08 8:38 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-08 5:05 [9fans] mv vs cp jmk
2001-10-08 5:45 ` Mike Haertel
2001-10-08 6:27 ` Lucio De Re
2001-10-08 8:38 ` Mike Haertel [this message]
2001-10-08 9:08 ` Plan 9 annoyances (was: Re: [9fans] mv vs cp) Lucio De Re
2001-10-08 6:25 ` [9fans] mv vs cp Lucio De Re
2001-10-08 9:50 ` Douglas A. Gwyn
2001-10-08 9:51 ` Thomas Bushnell, BSG
2001-10-08 15:37 ` Richard
2001-10-08 16:02 ` William Josephson
2001-10-08 16:51 Plan 9 annoyances (was: Re: [9fans] mv vs cp) anothy
2001-10-09 9:04 ` Thomas Bushnell, BSG
2001-10-09 9:04 ` Ralph Corderoy
2001-10-10 8:56 ` Douglas A. Gwyn
2001-10-08 20:17 Russ Cox
2001-10-14 19:54 ` Mike Haertel
2001-10-15 6:46 ` Boyd Roberts
2001-10-15 8:30 ` Mike Haertel
2001-10-08 21:21 rog
2001-10-08 21:24 Russ Cox
2001-10-09 10:12 forsyth
2001-10-09 16:18 ` Thomas Bushnell, BSG
2001-10-09 10:55 rog
2001-10-09 11:50 ` George Michaelson
2001-10-09 13:18 bwc
2001-10-10 8:57 ` Douglas A. Gwyn
2001-10-09 14:56 anothy
2001-10-09 15:23 anothy
2001-10-09 16:55 anothy
2001-10-09 17:08 forsyth
2001-10-10 8:56 ` Thomas Bushnell, BSG
2001-10-10 9:55 ` Mike Haertel
2001-10-10 10:09 ` Lucio De Re
2001-10-11 9:10 ` Thomas Bushnell, BSG
2001-10-10 10:45 forsyth
2001-10-10 10:50 forsyth
2001-10-10 13:06 ` Sam Hopkins
2001-10-11 11:20 forsyth
2001-10-12 9:23 ` pac
2001-10-11 12:21 bwc
2001-10-11 15:17 forsyth
2001-10-11 19:29 ` Micah Stetson
2001-10-15 14:45 presotto
2001-10-15 18:36 David Gordon Hogan
2001-10-16 19:46 forsyth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200110080838.f988c0Y95817@ducky.net \
--to=mike@ducky.net \
--cc=9fans@cse.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).