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/