Oh, you're brain-dead shut the hell up...
Macintosh resource forks are somethat you you either "get" or don't "get".
Coming from a Macintosh background and working with Macintosh OS internals,
I can't imagine that OSes live without and additional stream per file.
The BeOS does some pretty outstanding stuff with file attributes and
like. OpenStep hack this stuff in using directories, but it still was
pretty effective since I was designed correctly.
> So I question the whole practical utility of file streams in the first
> place. The only place where they don't screw the user is if the
> alternate streams are used to store non-critical information where it
> doesn't matter if the information gets lost when you ftp the file or
> copy the file using a non-multi-fork aware application. For example,
Half brain-dead Macintosh folks have been dealing with this crap without
problems since 1984.
Are you telling me that you, being a Unix/Linux, person can't handle
FTPing a multistream file with all those user-unfriendly tar options ?
That's complete bullshit and being a down right technical pussy..
> the icon of the file, so the display manager can more easily figure out
> what icon to associate with the file --- and of course, some people
> would argue with the notion that the icon isn't critical information,
> and that it should be preserved, in which case putting it in a alternate
> stream may not be such a hot idea.
That's probably because you don't do any serious GUI programming
and find crap like Xt and Xlib acceptable. Gnome is good though, same for Qt.
> manager would have to deal with anyway). The advantage of using a few
> dot files in each directory is that it will result in a lot fewer system
> calls and files needs that need read and touched than if the graphical
> file manager has to open the icon resource fork in each file just to
> determine which icon to display for that one file. So I don't even buy
> the argument multifork files are required to make graphical file
> managers faster; a few dot files in each directory would actually be
Watch how "find" chokes on Linux/Unix/Win32 systems and then do the
same search on crappy MacOS machine that's got a 32 bit DOS extender for
a VM subsystem and blow the all the Linux/Unix/Win32 away from having all
those dorky "dot" ("." <---) pathetically slow down the search.
You can just search the data fork for content.
> more efficient, and would work across non-multi-fork aware remote
> filesystems like NFS. I don't think a graphical file manager that only
> worked on specialized filesystems would be all that well received!
Well, I guess you like double clicking on a MP3 file with a ".au" suffix
and watch the spawned program choke on a bunch of discrete cosine data,
right ?
File suffix MIME determination is just about the most brain-dead/annoying
thing. Replace them with per file attributes for MIME determination, etc...
> So before we design filesystems that support multi-forks, let's please
> think about how they will be used, and how they will interact with
> current systems that don't really support multiple forks, and in fact
> are quite hostile to the whole concept. What's the point of being able
> to treat a filesystem object as both directory and a file if none of the
> system utilities, file formats (like tar) and internet protocols don't
> really support it? Does it really buy us enough to be worth the effort?
> And if we don't know exactly how it will be used, how will we know what
> sort of performace/feature tradeoffs we need to make before it will be
> useful?
I take it you never made the transition away from the DOS prompt over to
a Macintosh, right ?
> - Ted
This is freaking irritating post.
Die conservative Unix attitude, DIE DIE DIE !!!!!!
bill
-
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/