Slashdot Mirror
MP3 Player - The Be Way
shyster writes "Be has created a prototype mp3 player that puts all other hack jobs to shame. Using an Intel 810E chipset with a Celeron-400MHz processor, and relying on BeOS's wonderful file system (where attributes are stored with the files) for database search capabilities, this thing really makes BeOS look good, as well as emphasizes it's audio/video capabilities. They don't plan on making this thing themselves, but rather customizing and branding the OS for OEM partners to place in their own hardware solutions. This kind of approach should allow for some differences between devices, such as having a CD-RW, DVD drive, touchscreen LCD display, etc. The other great thing about this is that it's networked.
Check out the full story here."
well technically the "index" (i assume you're talking about the Sherlock index) on a MacOS volume is stored in a separate file. the other difference from BFS is that the index isn't automatically updated everytime a file is changed. instead, it's more of a hack, where Sherlock's "scheduler" runs at midnight (default) and updates the day's changes in the index file. BFS does all of this behind the scenes and in real-time, along with many other niceties (such as storing attributes along with the files as mentioned in the article).
so really what they're saying is correct, though misleading. they make it sound as though you can't do the same thing with MacOS. you can of course, it's just not as elegant a solution.
i was a big Be fan a back a few years ago but i gave up on them (especially after their "Apple screwed us" FUD when they dropped Mac support). i'll stick with my Mac, with some real applications and enough niceties for my taste. besides, i always liked NeXT-Step, and i'll get to use once again, but on my G3s! :)
- j
Not so far. In fact, Be's deadness is so complete that its doubtful that a free, GPL'd BeOS could even attract mindshare at this point.
Be is simply the next Amiga. People will be playing with Be ten years from now. At least none of the Amiga advocates try to convince you that its going to take over any market - they're a happy clan of hobbyists. I suggest Be advocates adopt this mentality if they want to salvage any dignity.
Multimedia is only going to be more and more integral to everyday information appliances (not just stereo components and PVRs). What answer does Linux have to this with its mishmash of incompatible multimedia technologies?
To me, this article indicates exactly why operating systems like BeOS will continue to make inroads into the embedded market, while Linux is in serious danger of losing out. Be is designed and marketed as a "multimedia OS", and uses like this allow it to really shine. How long before the built-in features of BeOS are more than anyone doing it from scratch in Linux will want to compete against? Isn't it already that way?
My feeling is that the multimedia capabilities in BeOS will eventually obviate the need for Linux's primary strength in the embedded market--the availability of source code. If an OEM-ready platform already has support for all the stuff you'd want to hack into Linux, is small and cheap enough, why NOT use it? Isn't the whole reason TiVo used Linux so they could add in all the multimedia stuff they needed that Linux didn't provide? (And don't tell me they did it for philosophical reasons. OEMs want results, not dogma.)
If Linux wants to compete in this space, it needs focus, which seems to be the one thing it doesn't (yet) offer.
The only certainty is entropy.
Be Inc. changed it's focus in January.
They are focusing now on Internet Appliances, thus BeIA, rather than BeOS. BeIA is supposed to be fully customizable for the OEM, including UI and all sorts of other things. It's made to run on as little as 32MB of RAM and has support for Flash, Real, and Opera 4 as it's main browser.
The device spoken of here is yet another iteration of BeIA. This just goes to show the remarkable uses of Be's latest work. Hopefully the networking support will be seamless- not like it is on R5 Pro. Check out http://www.qubit.net for another BeIA enabled device, this one with 802.11b connectivity.I'm sorry, but its curtains for Be. Its mindshare is nonexistant, it has no direction, and it will soon be out of cash. Be essentially went out of business the day Apple chose NeXT instead of Be.
Imagine a centralised MP3 server networked (both 802.3 and 802.11 - thats ethernet and wireless for the young ones) to other appliances around your house. Choose a MP3 track and listen to it from your Hi-Fi / TV / Refrigerator / PC / backyard hammock on a internet appliance etc. Listen to a streaming MP3 server, and immediately download more songs from the same group. Little Johny listens to kiddie MP3's from the bedroom, Mrs Jones listens to a hip song in the kitchen while Mr Johnes listens to a blues song in the garage - all songs are streamed from one box. Stick a new CD in, convert the audio to MP3 (with online lookups) and all networked devices in the house have access to the new songs. With MP3 storage space reaching double gig digit storage sizes (>10G) it becomes more and more cumbersom to issue searches, as well as a problem of duplicating data. I think that this custom built MP3 box on steroids provides so much more than anything I can muster myself. This appliance will be idiot proof to operate, and you'll be able to buy it at your local electronics shop. Nice.
Revolution = Evolution
The difference here is: the BFS doesn't index its files centrally to some index. Each file has a variable amount of attribute data that can be extended as the user/developer wishes. That attribute information is stored directly in the file system info tree, although if it gets really big its stuck into a hidden file [or extra node/block actually].
This is super-slick because the file system info tree is structured mostly in places where the head of the drive can get to fast, and usually right next to tons of similar information about all the files in a directory or group of directories. This way you can read a couple blocks of file attribute information without ever having to actually skip to the files themselves and search that, thus acheiving a great savings in head movement. Its similar in basic concept to the BSD Fast File System and the Linux Ext2fs, in that they do the same for filenames, sizes, and other attributes. But the BFS has extensible attributes.
So extensible attributes mean: I downloaded a file from somewhere, besides just a filename=foo.tgz, I could put a from_URL=ftp://ftp.foo.org/pub/foo/src/tgz/ attribute there. All mail messages have their subject, from, to, reply to, and all that stuff stored as attributes, and all mp3s have their ID3 tags (and possibly more) stored as attributes. So you can just grab stuff that matches the attributes you want. This happens really quickly because the head only has to skip to the general inode information, better yet, any smart OS will cache all that in memory, so a large portion of your search is done without drive head movement.
Large attributes exist too. For example some drawing programs store a scaled down preview in an attribute... fair enough, that is in an extended attribute node/block, but that node/block doesn't have to be searched or then cached unless it's known to contain the key that is being searched for.
So sure, any OS could go ahead and index mp3 id information, cache it, maintain coherancy between it and the fs, and search through it, but for Mac OS, that would take a seperate indexing phase, an extension that pays attention to fs changes and updates the index, and a special extension to a special searcher (the BFS search is just an fs feature with a gui interface) that looks through the special index. And that is just as feature rich, but it lacks the performance considerations that were taken into account when building such things directly into the fs.
I do like the Mac, unfortunately Be sucks for not keeping developers more PPC aware, even if Apple forced them out of developing for G3 [not that that has stopped NetBSD or linux even]. It's a real shame because the BeBox was one of the coolest ideas in a long time, especially because of the OS, but not solely... the PPC is a cool chip (literally too).
-Daniel
P.S. The guy who developed BFS presented it as a talk at WPI (cause he graduated from there), and the guy who developed Ext2 came to talk to the linux group a few weeks earlier over how it worked and what may be done differently for Ext3. Both were very informative
Journaling, Schmournaling. Be's filesystem keeps information about files in a metadata database. You can add arbitrary information types to this metadata, and you can search the filesystem for files.
For instance, you can add Artist, title, album, live/recorded, and bitrate to the information on the file. Then you could search for all live recordings by Tori Amos or Limp Bizkit, at a datarate above 128 kbps, sorted by title.
All without writing but one line of code (the search query)
-
Just because it works, doesn't mean it isn't broken.
Hello,
/. Aura is nothing more than networked mp3. Lot of people have done it. And also as mentioned above this has nothing to do with the journaling filesystem (which just happens to be the default fs on Be). When articles like this are posted people are incited to point out the holes in the article and thus create FUD towards Be. I understand Be is not a free OS. But we here in France have a strong Be following and are faithful Be users. I would really like right information on Be posted here, instead of FUD and things that anyone could point fingers at. Sorry for my bad english.
As a Be user, I find it frustrating when I see things twisted around and posted as news on sites like
Hi,
I tried Aura a few weeks ago on BeIA developer forum. But I must say that it's nothing as mentioned here. I mean the mp3 player bit is just a normal mp3 player. It's got networking (sort of like the way most people host mp3's on nfs mounted partitions). The default filesystem (Be Journaled fs) just takes care of all directory work. This could be easily implemented in almost anything else. Also it has nothing to do with Be's mp3 player.
I saw one such implementation with a LDAP and NFS. A script goes and constructs LDAP entities for all songs. It's tiresome if you dont have the stuff in the mp3's to begin with. But the LDAP imeplementation is magnitutdes faster. I dont know why the author of the article missed this altogether. And maybe some reaserch before posting the article on slashdot might have stopped all the trolls here today!
Enjoy
Beed!