9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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


  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).