I'm interested in consistant interfaces; in my experience, having
documents behave differently when you access them from different
shells is a good recipe for making me dislike the platform (like my
discovery that the MacOS's much-trumpeted-as-better-than-Unix
undelete didn't work from a shell.)
>Part of the beauty and usefullness of Linux and Unix in general is that
>it doesn't "hide" stuff from users with a clue.
There's a difference from not hiding information from the persistant
and going out of your way to have a neolithic interface because it's
easier than thinking.
>Yes, you can stick to
>your application that knows how to read resource forks and such, but if
>you do that then you prohibit users with a clue from using standard
>tools on the constituant parts of this compound document because it's
>all in a resource fork and there's no way to pull it out unless you
>write a custom program.
I don't think you've been paying attention to this argument. The
proposal, which has been beaten around the block by traditionalists
because it's not the way it's done in THEIR village, is to have a
magic directory (qv: podfuk, if I understand it correctly) that
is treated like an ordinary file for most operations, but you can
cd into it via some means and access the gory details using normal
tools.
>Or were you and others thinking of rewriting all of the Unix utilities
>so that they can handle resource forks.
No, you're not paying attention. Right now, the traditionalists
are objecting strenuously to magic directories because people can
modify their applications and some selected GUI to understand
resource forks for application X (this is the Apple style of
design: "We have the one true way of dealing with computers, and
you are DAMNED TO HELL if you dare treat the Holy Mac any other
way!" Well, if I wanted VMS with a GUI, I'd not be posting to the
linux kernel mailing list.) I DONT WANT TO REWRITE ANYTHING EXCEPT
THE APP; I want everything else to be able to treat the document
as an atomic file, except when they explicitly want to treat it as
a directory.
Is it doable? Maybe. A proof of concept already exists (podfuk),
and such a thing may be implementable in userspace. The stumbling
point would be the semantics for presenting the data as both a flat
file and a directory.
>I don't think what you and others are talking about is the Unix "way"
>of doing things.
If the ``Unix way'' has changed from using simple tools to do the
job to having every application carry around a complicated
infrastructure to access record-format files, well, yes, I'm not
talking about the ``Unix way''. I prefer to do things the way
Unix used to do things, where the kernel provided services in such
a way that you could build up simple tools to get most everything
done.
>1) Do you mean by "other than sitting at the console" to mean a failure
>to be able to do "things" remotely? I think that any GUI interface
>that would need anything like resource forks would be written on top of
>X ultimately, which should handle any remote issues.
If a user telnets in and manipulates the data, it should behave the
same way it does when you use the same tools from a windowing
interface.
____
david parsons \bi/ A simple enough request.
\/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/