[prev] [thread] [next] [lurker] [Date index for 2005/04/22]
On Fri, 2005-04-22 at 13:47 -0500, Peter da Silva wrote: > 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. Huh; I guess I never specifically compared BeOS to real-time OSes, and I haven't used any that qualify as such, although I've been meaning to try QNX for a while. I was mostly interested in BeOS's advancements on the desktop. > 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. I may be showing my youth and naivete here, but I guess I don't think there's a good high-level, compilable language out there that's got very common usage. Objective-C seems like it might have qualified, I guess, but I don't see much else. I'm in the middle of starting a software company, and I spent a while trying to come up with a good language. I absolutely refuse to use something as low-level as C, because it's so inefficient for the programmer, but I couldn't find anything else that seemed like it might not result in my app not being used because of language difficulties. (I ended up sticking with Ruby, even though I really want something that can be compiled.) I guess what I'm trying to say is: There don't seem to be many good choices. Languages seem to mostly suck, too. In addition to being embarassed that anything resembling Unix is the best OS out there, I'm embarassed that anything resembling C is one of the most popular languages out there. "All of the power of assembly language, combined with the flexibility of assembly language." I'd love to hear what you consider to be a good, high-level language, especially something that is compilable. I'm not saying there aren't any -- LISP, Scheme, and Haskell come to mind, and I've heard people mumble that Objective-C could be good (but again, C?) -- but none of the ones I know of seem to have enough users that one could safely write an OS in them. > 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. Frankly, I loved this about BeOS -- I'd much rather the computer do extra work than the user or the developer do it. It's _always_ cheaper to have the computer do it. OTOH, I could basically never keep my processors working very hard, so I never (as a user) experienced the inefficiency you're talking about. I wish people would do that more -- I hate being depended on to do something, because the developer was lazy, or because the solution is difficult in the language being used, or whatever. My programming philosophy is that if the computer can do it, it should. I don't know if that's what you mean, but... > 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. That soooooo doesn't impress me. :) I don't deride Unix for being inefficient or bulky... I deride it for being ancient, and long past its prime. It was great when it was new, but it's embarassing that it's still in use with so much kept over. > 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. Is there any way around this problem while still using an OO language? It seems like you'd always have difficulty integrating two languages. > 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. While I would have to bow to your greater knowledge in this area, I will say that one of the things I _loved_ about BeOS is that windows never, ever suffered from the refresh problem, because there was always a thread devoted to refresh. I have that problem on all other OSes, and it drives me nuts. It's especially bad on Linux sometimes, but it still hits on OS X. > 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. Huh. I used the os as a user, not really as a developer, and it seems like most of these complaints affect the developer more. I'm assuming some of the warts I saw resulted from these choices, but over all it was still basically the best computing experience I've ever had. > > > 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. Do these OSes even have the same goals? BeOS wasn't really meant to be a RTOS, just a good desktop OS. It did have very low latency, but I don't think that was exactly one of the primary goals, it was just part of the whole package. What other RTOSes specifically do you mean? Amiga and QNX? I really don't know. > 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. Of course, file names are not in the inode, but I see what you mean; the name is in the filesystem somewhere. > 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. I am imagining it, and it is a pleasant vision. I despise magic numbers. I think we're going to just have to agree that the other person is wrong here; normally I would (again) bow to your greater experience, but I just don't think I can bring myself to do so here. Having metadata access and storage be exactly the same for every file, every filetype, everything, on the whole system is just so damn powerful. > 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. Why does metadata have to be something you can throw away without losing information? That's a new one on me... I consider ID3 tags to be mp3 metadata, but I managed to lose all the track numbers on my mp3s last year, and that loss is still annoying the crap out of me. Frankly, I think metadata is pretty damn important, which is one of the reasons why I want more visibility and better control of it. And I want a standard OS interface for managing it. > > So now all of my files are directories? > > A lot of them are, yes. Garage Band documents, applications, plugins, rich > text documents. Yuck yuck yuck. Quadruple-yuck; I'd hate to explain that one to my mom. "Okay, so open the file up, and get the file from inside it." "...<thump>" > > 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. No, it's not an app. I can CD into the directory, find the actual executable, and run that manually. If it were actually an app, I couldn't do that. It's a directory (with metadata in the fucking name!) that the Finder and only the Finder treats specially. That's a really, incredibly stupid design. > 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. See, that's just fearmongering. "If it's not part of the standard, it's bad." No, I can't agree. If POSIX came anywhere near being sufficient for handling the metadata that people need to actually deal with, we wouldn't have the total lack of coherence that we have. I just don't see how it's harder; harder for whom? The user? They shouldn't really notice. The developer? It's all API to them, right? The power user? As long as there are good APIs (and CLI tools) available, it should be the same for everyone. And yes, with BFS it was really in the inode; each inode was 1024 bytes (because that's the minimum size on the filesystem), but the OS only needed to store about 300 bytes of data. That meant that every file had 700 or so bytes of free space in the inode. If your metadata was less than that (which is quite a few name/value pairs), then it's in the inode, and is part of the 1024 bytes you have to retrieve to do anything at all with the file. If your metadata was more than that, an extra data block (or more, as necessary) was allocated, but that was entirely transparent, and did not involve hidden directories or whatever, just links to more data blocks. So, yes, it's definitely faster, since it requires 0 extra disk or process accesses, and it doesn't increase the size of the inode at all. And again, I just can't countenace lack of interoperability being a good reason not to do something; I take pride in not being interoperable with crappy systems. MacOS 9 wasn't interoperable but it was still the best OS out there (for many purposes, any way) for a long-ass time. The fact that filetyping and metadata are basically unhandled by every OS out there is indicative that the problem is not solved; therefore, trying to stay compatible with people's crappy, half-assed puny attempts to kind of dance around those problems is just silly. > 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. Ugh, that's too bad. > 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. I've been trying to figure out how this would work for a while now. Yuck. Hopefully it won't be all bad, but I'm guessing you can expect some hate from me on that topic before too long... > > 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. I don't think I understood that. It's a process that trawls your system looking for metadata, using plugins to understand file contents, right? And then it stores the metadata in a db of some kind...? And the Finder has some mechanisms for accessing that db...? I don't understand the "take with you" part of that statement. -- 'Fire them. Fire every single person who ever worked on [Microsoft] Word. If they're no longer in Redmond, find out where they work and make their boss fire them. TP their houses. Take away their stock options and hack into their 401(k) accounts, changing all their long-range holdings into Overseas Tech Investments.' --Wired online --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://config.sage.orgThere's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52