Messages in this thread | | | From | (david parsons) | Subject | Re: nice troll (was: All this resource-fork AKA multiple streamnonsense) | Date | 9 Jul 1999 01:15:24 -0700 |
| |
In article <linux.kernel.99070817390802.11473@yogibear.penguinpowered.com>, Fred Reimer <Fred.Reimer@bellsouth.net> wrote: >On Thu, 08 Jul 1999, david parsons wrote: >> In article <linux.kernel.Pine.LNX.4.10.9907060957530.2179-100000@mothra.ilogic.com.au>, >> Damien Miller <dmiller@ilogic.com.au> wrote: >> >On Mon, 5 Jul 1999, Albert D. Cahalan wrote: >> > >> >> Fortunately I don't mind trolls. I don't think I have _ever_ seen >> >> a compound document represented as a directory. I know that TeX >> >> users do it sometimes, but they aren't normal users anyway. >> >> Ask a random MBA, art student, or secretary what "TeX" is. >> >> Normal users don't write Makefiles for their documents. >> > >> >Your random MBA, art student or secretary will be using an >> >application or GUI which hides the fact that the albod is >> >a directory. >> >> "When I'm trying to copy my wonderful document, cp says something >> about a directory and doesn't copy it." >> >> "When I ftp my wonderful document, ftp says it's not a plain >> file and doesn't copy it." >> >> "Chapter core in my wonderful document vanished over the weekend." > >He was talking about a GUI. You're talking about command line tools. >People who use command line tools are expected to know more and >understand computer concepts a little more than GUI users.
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/
| |