Re: [9fans] blanks in file names

[Dave <dave@dave2.dave.tj>]

I just noticed that there were a few more messages in this thread that
got lost in my email (and I can't really blame elm this time, either) :-(

I know we'd all like to kill this thread, but I can't look at this post
without replying; it's just too misguided to ignore.

The reason I want a new open is _not_ that the current open isn't
efficient enough for my tastes.  The reason I want a new open is that the
current one was lifted straight out of the old UNIX design, and miserably
fails to accomodate the modular approach that UNIX no longer provides,
but Plan 9 has found some brilliant ways of recreating (which is why I
got my original Plan9 installation in the first place).  The fact that
the new open happens to be more efficient than the old one for many
applications is merely a neat side effect, one that I only brought up
when I was accused of making open _less_ efficient (and I didn't see you
pipe up then to complain that cost doesn't matter).  In UNIX, paths never
became real objects in the sense that Plan 9 has promoted them to, because
UNIX has very primitive filesystem serving.  In Plan 9, it becomes a lot
more interesting to have commands simply create temporary filesystems
and populate them with the results (e.g., ls creating a directory with
each file being one of the entries requested, and the contents of each
of those files being information about the entry).  UNIX tried to make
everything a file, but it got bogged down with plain-text IO.  Plan 9
aligned itself squarely with the file philosophy, and I see no reason
to stop short when filenames are concerned.

 - Dave

BTW - I don't know if it's worth noting that while strlen (sequential
memory accesses) is an order of magnitude faster than DES (repeated
computations + sequential memory accesses), simply getting the length
from a structure (direct memory access) is an order of magnitude faster
than strlen.


Geoff Collyer wrote:
> 
> My apologies for dragging this out, but I think this gets to the heart
> of the matter.
> 
> The cost of strlen doesn't matter, it really doesn't matter.  I can't
> recall seeing a real-life program where the cost of strlen was more
> than trivia.
> 
> A quick comparison on Plan 9 shows that strlen runs at 19 times the
> speed of DES, using the same 64-byte string as input each time, which
> is almost certainly longer than the average string.  DES is really
> slow, by design; it's not just a question of a few more memory
> accesses; it's just hard to do the bit-swizzling quickly in software
> (though it can be done relatively quickly in hardware).
> 
> One of the big achievements of Unix was to get people to stop worrying
> about the microseconds and look at the slightly larger picture of what
> could be done if your first concern were not microseconds, and that
> was a quarter-century ago!  With processor cycles being so cheap and
> available now, it's generally not worth worrying about expenses until
> they cause a real (measurable, reproducible) problem.  Proposals based
> on supposedly greater efficiency for a new open(2) interface are not
> worth considering, particularly when open's efficiency isn't currently
> a problem, and the new interface is ugly, incompatible with the
> existing clean and simple one, and purports to solve non-problems like
> allowing NUL and slash in file name components.
> 
> 
> One downside of APE is that it's made some people think of Plan 9 as
> Just Another Goddamned Unix Implementation.  If you're not interested
> in exploring what's new in Plan 9, and are offended that realloc isn't
> provably optimal or that GNU configure doesn't just run out the box,
> why are you using Plan 9?  FreeBSD, OpenBSD, NetBSD and Linux are all
> available at no monetary cost.
>