Slashdot Mirror


Gloolabs Readies A Java-Based WiFi Audio Device

An anonymous reader writes "A new Java powered home entertainment audio device design promises to simplify sharing computer music files among computers and stereos in connected homes. Gloolabs's Gloo is Java middleware that puts an iPod-like interface on music files it "discovers" around the network. Gloo, which will be licensed to multiple device makers, is available now on one device that runs embedded Linux, and Gloolabs is currently bootstrapping a Gloo developer community. Gloolabs is currently taking orders for the $250 MacSense HomePod, the first Gloo-based device, which will ship in January 2004. A limited quantity of the $350 Developer Edition is available now."

8 of 149 comments (clear)

  1. I ordered mine in JANUARY by Anonymous Coward · · Score: 2, Informative

    Of 2003. They said it would ship in March.

    Still waiting.

  2. is there anything that cool about this device? by Uthiroid · · Score: 2, Informative

    seems the latest slimp3 device does this stuff. somebody please clarify why this is better/different than the current market offerings?

  3. Re:Open-ish source.... by Phil+John · · Score: 4, Informative

    Try doing your homework:

    The Java SDK source is indeed available and no, you don't have to pay for it! How else do you think the FreeBSD port of Java works? You can get it from http://wwws.sun.com/software/communitysource/j2se/ java2/download.html

    As for the speed of Java, why do people still push around this piece of FUD? With dynamic optimisations Java is starting to rival the Speed of compiled code, sometimes even beating it. No, I don't have any benchmarks to hand, since benchmarks are the Root of all Evil(tm)

    True, you cannot share the source code to the Java Platform. Welcome to the Real World(tm), not everything is free, some companies *gasp* actually want to keep some things proprietary, be thankful we have the source to play with/port to other systems at all.

    I see you have been modded as a troll since I started writing this, I'm still going to post it, just so others who think along the same lines as you can get the facts.

    --
    I am NaN
  4. Re:Neat idea, but by Crazy+Man+on+Fire · · Score: 3, Informative
    I can't imagine a single /. user (hopefully) who doesn't have 128-bit WEP

    WEP (128-bit or othewise) really isn't very secure. If you're that freaked out about it, you should be using something else...
    Of course, 128-bit WEP is better than nothing, but it really isn't any better than any other strength WEP.

    From this Ars Technica article:
    Using today's computing horsepower, this feature (128-bit WEP) increases the time it takes to brute force crack a WEP key from a few days to approximately 20 weeks. While it seems like a good idea, there are several key areas where this security initiative falls short of the definitive security solution. On top of the management problems using static WEP keys there are two serious issues that plague 128 bit WEP. First of all, the attacks on WEP have nothing whatsoever to do with the key length itself. Whether you are using a 64 bit or 128 bit WEP you still have the exact same 24 bit IV which is the source of the weaknesses. This increases security absolutely zero for today's wireless implementations because no one bothers to brute force a WEP key when it is so easy to use one of the other attacks.
  5. Re:Open-ish source.... by dasmegabyte · · Score: 3, Informative

    Java generally BEATS code written in a non garbage collected language when there is enough memory on the machine and many objects are quickly created and dropped. For example, i wrote a mail merge program in Java. For the average size merge we ran (2000-3000 addresses), it was usually 40-50% faster than C++, because the "garbage" of unused, unreferenced variables could be left behind when an address record would go out of scope. This would fill up memory, but since we had enough memory to fit the garbage of 2000 records while we did the important i/o work, it wasn't an issue.

    And newer (since 2001) versions of the Java VM further improved this code, as garbage collection is handled on a separate thread. So while in C++ you're spending 200 cycles doing nothing, waiting for the disc to be accessed, then deleting the record, I can spend those 200 cycles cleaning the heap.

    C# under .NET is approaching this level of speed as well. In another 10 years, people are going to talk about the old days when code was written for just one type of operating system, and one type of hardware, and when it was written without automatic garbage collection or memory management, or array bounds checking (the thing that PREVENTS buffer overflows?) And they're going to laugh at all the people clinging to C like the cavemen they are.

    --
    Hey freaks: now you're ju
  6. Re:ACC files are NOT standard! by dasmegabyte · · Score: 3, Informative

    AAC may be new (which is what you're talking about) but it is certainly standardized.

    "Standard" in that phrase refers to files that meet the Mpeg-2/4 standard for AAC audio in an LC profile, which Apple Music Store Downloads don't (they encrypt the data, which decrypts to standard AAC during playback if a license file is available). They are quite "standardized," which means a standard has been published describing how to write a decoder for each of the 9 profiles, and most PC uses of AAC use the Low Complexity profile. They are most certainly as much a "standard" as MP3. As for programs and devices not playing them...that'll clear up quickly. At present, there are a dozen media player options for Mac, Windows and Linux, and since Apple's built AAC support into iTunes and the iPod, more portables will be jumping on board soon enough.

    AAC files (why do people have trouble with those letters? It's double As, then a C, stands for Advanced Audio Coding, doesn't look like the start of te word ACCessory) are the new MP3 in just about every way except one: they don't have MP3's expensive licensing costs.

    --
    Hey freaks: now you're ju
  7. Re:Open-ish source.... by HisMother · · Score: 3, Informative

    >Yippie, *some* expertly written Java *can* come close to being as fast as *poorly* coded programs, written in compiled languages. Big whoop. Bzzt, sorry. Looking at one computationally-intensive domain I'm familiar with (rule engines,) those vendors (like ILOG) that offer both a Java and a C rule engine tend to have performance within a factor of two for the two implementations. Many Java rule engines absolutely kick the asses of rule engines written in C. Why do people like yourself feel threatened by the reality of Java's good performance?

    --
    Cantankerous old coot since 1957.
  8. Re:Other Internet Radio/MP3 clients? by kennylives · · Score: 3, Informative

    Actually, the Slimp3 does do shoutcast/icecast streams. Works very well...

    --

    Where the value of X-Mailer: is the true measure of a man...