Re: MP3 players? Linux? I'm not sure, but I know there's hate

[prev] [thread] [next] [lurker] [Date index for 2005/04/22]

From: peter (Peter da Silva)
Subject: Re: MP3 players? Linux? I'm not sure, but I know there's hate
Date: 19:47 on 22 Apr 2005
> 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