[prev] [thread] [next] [lurker] [Date index for 2005/04/22]
> Interesting; you would be the first person I've communicated with who > actually expresses specific hate about BeOS (I'm obviously ignoring all > of the "but it's not free" trolls out there). Well, it's just that I've used a lot of realtime operating systems that address the problems that BeOS was supposed to be solving and did it a lot better, as well as one PC operating system that, allowing for the limitations of the hardware it was running on, was a far cleaner basic design. What I don't like about BeOS: 1. C++ is an appalling choice for an implementation language. Either a low level language (like C, BCPL, PL/M, or BLISS) or a true high level language (of which there are ample examples) would have been better. Hell, I'd rather an OS written in Javascript. Well, maybe not, but it's not an open-and-shut case. 2. Like the GNU people with HURD, they deliberately embraced inefficiency for the sake of convenience, depending on Moore's Law to pull them out of the hole. That mostly works, eventually, but it leaves a bad taste in my mouth. I mean, people deride UNIX for being inefficient and bulky... but it can run on a Palm IIIx, and run with a GUI on a machine with less horsepower and RAM then a Mac SE. Not SE/30, plain old 68000-based SE. There's some layering problems: 3. The implementation language is tightly bound into the API. Components communicate through APIs that are written in terms of C++ classes and objects. This means that any other language is going to be a second class citizen to a far greater extent than in an OS like UNIX. Cocoa does this too, though the late binding in Objective C mitigates it there. 4. Concurrency at the application level depends on threads. This means that applications HAVE to be multithreaded, they can't use the simple event loop or dispatch model even where it's adequate. It also means that threads have to be prepared to block. Threads are a lousy way to handle concurrency. In fact, threads don't handle concurrency at all, they hand the whole problem over to the application programmer. It's better to have the API based on explicit messages (preferably with bundling like X11 or queueing like AmigaOS) so the client application can deal with it however it likes. There's more, I really don't have time to go into details... but I've seen the user-visible results of all these decisions and they filled me with hate. > > I'll just say that I can understand them reinventing the wheel, but they > > should have actually looked at some of the *round* ones available before > > deciding that a triangle made a better wheel than a pentagon. > Examples? Just about any real-time operating system in existence. > > Oh, and putting necessary metadata in the file system, outside the file, > > where it is GUARANTEED to get lost as son as you have to deal with the > > fact that nobody else in the whole world does it the same way as you even > > if they're daft enough to think it's a good idea, is hateful in so many > > ways... > So I assume that you hate that Unix metadata is in the inode, too? I do in fact have mixed feelings about the layering of file metadata (the execute bit) on file access data (permissions). The file name is the one apparently inescapable piece of file metadata that lives in the inode. For the past 30 years I have had to be aware of the differences between what different operating systems and file systems allow for file names. UNIX has traditionally been a lot less restrictive about file names than most operating systems... not always the most liberal but liberal enough that at the very least moving files TO UNIX has not normally been a major problem, though Mac OS (another OS with very liberal conventions) has occasionally caused problems by allowing "/" as the local part of a file name. For non-UNIX systems, or moving files from UNIX to other systems, it's been a nightmare. This is one of the reasons I am reluctant to accept this design as anything but a trap. We have finally, after more than forty years of dealing with the problem of just file *names*, reached a point where there's only a few last little bits of pain to deal with - FAT32 file systems, case-sensitive versus case-insensitive file systems, the "/" versus "\" issue... Imagine if we were routinely putting more metadata in the file system rather than in things like magic numbers and structured files. > Metadata is exactly that: data about the data. It's a meeting point > between the OS, the app, and the data, and it doesn't make sense to make > the exclusive domain of any of them. Sticking it in the filesystem > works just dandily, as long as you provide good, simple tools for > converting. Caching it in the file system, or in a database, that's fine. So long as you can throw it away and not lose information. Conversion tools? Dear god, I have been flayed and burned and scarred for life by conversion tools JUST FOR FILE NAMES. We're almost past that now. The corpse has been staked, don't drag it out of the coffin again. > > > toning down their lickability, and they still haven't fucking figured > > > out filetyping. Filename extensions? Seriously? No, seriously? > > > Really? *faints* > > Directories, dude. All the advantages of file types and resource > > forks, and they don't go BOOM when you back them up. > So now all of my files are directories? A lot of them are, yes. Garage Band documents, applications, plugins, rich text documents. > I mean, I understand the value > of an abstraction, but I just don't think this whole "files are actually > just abstractions and don't really exist" thing is a good idea. "No, > that's not an app, it's a directory that functions as an abstraction for > an app." No, that's an app. It happens to be implemented as multiple files in a common directory, but that's an application. It's no more of an abstraction than a file. > Metadata in the inode is simple to understand, simple to maintain, > incredibly powerful, really fast (because it's in the inode), and pays a > legacy compatibility cost. So be it. Metadata that is not exposed to the common POSIX API that finally, after decades, virtually every OS implements is a snare. It's harder to maintain even on an isolated system than metadata in the file or metadata in associated files, it's no more powerful, it's no faster (because if it's really "in the inode" it makes the basic file object bigger and slower, and if it's not it's just a directory you can't really see), and it locks you in to a single platform because anyone using a different operating system... even if their OS has a similar mechanism... can see it. > So Spotlight is not copying BFS to some extent? No. It's a separate database about the file that is just a file in the file system, and it contains information that is extracted from file metadata by applications and plugins that know about those files. I am sure that some idiots will start using it for things that need to be preserved outside the local user's environment, but it's not designed with that in mind... it's just a common place to put stuff like a copy of "iTunes Music Library.xml"... it's not like the UNIX execute bit or the Mac finder info or resource fork. > What's better about Spotlight, other than the fact that they obviously > took the next step and started indexing the internals of the apps The better thing is that it's the map, not the territory. It's the library, not the books. It's a spotlight... it tells you WHERE to go but once you get there you have something you can pick up and take somewhere else without worrying whether it will still work when you get there.There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52