Messages in this thread | | | From | Fred Reimer <> | Subject | Re: nice troll (was: All this resource-fork AKA multiple streamnonsense) | Date | Thu, 8 Jul 1999 16:59:41 -0400 |
| |
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. That's why everyone had been complaining about Linux being too hard to use until the GNOME and KDE systems matured.
Part of the beauty and usefullness of Linux and Unix in general is that it doesn't "hide" stuff from users with a clue. 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.
Or were you and others thinking of rewriting all of the Unix utilities so that they can handle resource forks. Like a grep that specifies the resource fork to look through to find files that contain a certain regular expression.
I don't think what you and others are talking about is the Unix "way" of doing things. If you want to create another OS then I believe you're free to fork the tree and add what you want. If you want to create an application that handles resources in a user-land library that's fine. However, I don't think what I believe you are advocating fits in with the paradigm of Unix.
I could be wrong, but that's my current beliefs. I hope I understood your beliefs in the correct manner (that you support adding resource fork stuff in the kernel instead of having apps handle this in user space). If not, I appologize.
> >What part of that can't you understand? > > Unless you intend to macify the user interface and force users > to wade through trackless swamps and climb the Himalayas[1] to > do anything other than sitting at the console, a "we'll hide it > in the GUI and the app" approach will fall off the edge of the > universe pretty quickly.
A couple of questions on what you mean here. (First, I think it should be MACify or Mac-ify or something - I actually looked up macify at www.m-w.com and found out it's not a word before realizing what you meant)
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.
2) If you mean having to use the GUI in order to get the "simpler" view of the data then I don't see a problem with that. It's kinda like filesystems themselves now. It's arguably more convienant to look at an explorer like interface where you can click on folders and move around pretty conveniently. However, for more experienced users, it is still "easy" to do more complex things with files using the current directory symantics. It would be HORRIBLE if someone chose to take that away and make files only accessible from the GUI.
I'm saying that there is probably a good, easy to use, way of representing "compound documents" in a GUI for the lay person, but leave the internals exposed on the command line for more advanced users.
Fred
- 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/
| |