Messages in this thread | | | Subject | [Offtopic] (reiserfs) Re: I discussed reading directories as files with jra, Stallman, and | Date | Wed, 23 Jun 1999 12:10:19 -0400 | From | Justin Hahn <> |
| |
Bill Huey writes:
I'd like to discuss some of the issues you presented.
bh> Oh, you're brain-dead shut the hell up...
First, ad hominem attacks generally aren't very effective.
bh> Half brain-dead Macintosh folks have been dealing with this crap without bh> problems since 1984. bh> bh> Are you telling me that you, being a Unix/Linux, person can't handle bh> FTPing a multistream file with all those user-unfriendly tar options ? bh> bh> That's complete bullshit and being a down right technical pussy..
Well, it's not so much of a matter of the user not being able to handle it, but the current tools not supporting. UNIX has no tools to handle this sort of thing. You'd need to rewrite tar. And gzip. And bzip2. And cpio. And pax. And ar. And zip. And lha. And so forth. I think you get the idea. That's a lot of code. All for something which can arguable be solved with directories.
bh> That's probably because you don't do any serious GUI programming bh> and find crap like Xt and Xlib acceptable. Gnome is good though, same bh> for Qt.
Well, Xt and Xlib are mainly intended as low level toolkits. Write in Qt, or GTK+, or Gnome, or [insert a good toolkit here]. You essentially nix your argument with this.
bh> Watch how "find" chokes on Linux/Unix/Win32 systems and then do the bh> same search on crappy MacOS machine that's got a 32 bit DOS extender for bh> a VM subsystem and blow the all the Linux/Unix/Win32 away from having all bh> those dorky "dot" ("." <---) pathetically slow down the search. bh> bh> You can just search the data fork for content.
I don't understand this argument. So far as I can tell it's content-free.
bh> Well, I guess you like double clicking on a MP3 file with a ".au" suffix bh> and watch the spawned program choke on a bunch of discrete cosine data, bh> right ? bh> bh> File suffix MIME determination is just about the most brain-dead/annoying bh> thing. Replace them with per file attributes for MIME determination, etc...
Then don't do it. Do data signature matching, which is fairly reliable. (UNIX file command. I've gotten pretty low false-pos rates with it. And it can be improved upon). Sure a fork makes it easier, but it's not necessarily the One True Path.
bh> I take it you never made the transition away from the DOS prompt over to bh> a Macintosh, right ?
I don't see an advantage either way. Macintoshes of that era were extremely limiting to someone who really knew the DOS prompt. At the same time DOS was overly cryptic, poorly designed, and ugly. But it had a lot of versatility.
bh> Die conservative Unix attitude, DIE DIE DIE !!!!!!
If you don't like the "Let's look before we jump" attitude, then don't use UNIX. The reason UNIX works as well as it does is that people have paid a LOT of attention to detail and tried to make the best decisions. Simply saying "The Mac does it so it must be good" is wrong. If it were right, we'd be doing co-operative multi-tasking, in an non-protected VM space. I don't see the advantage there.
While I don't necessarily agree with Ted at all times, he knows his shit. Yes, he's a bit more conservative than some, but it helps to have people who insist on having a good reason for doing things. If at the end of it you disagree with him and implement it anyway, at least you were forced to analyze your proposal.
----------------------------------------------- Justin Hahn <jehahn@raven.bu.edu> Systems Administrator Boston University SPI Lab -----------------------------------------------
- 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/
| |