Slashdot Mirror

XMMS uses the old 1.x toolkit, and is due to be replaced with the superior JuK in KDE 3.2 in most distributions when it comes out.

Are you on crack? You're telling me that this JuK player is going to replace XMMS? Go ahead and use that fugly pos if you want but I sure as hell won't.

Well, I assume XINE can play MP3's (it has to support the format anyway for all of those video encodings that use MP3 for audio), and as you can see from the plugins page, XMMS can be made to play a wide variety of non-audio media formats. So that description is technically correct.

But they probably did mean the opposite, yes.

Ah yes, the GIF patent. That stopped any free software using GIFs.

The MP3 patent's licensing terms don't even prohibit legal Free Software implementations - you pay a one-off licensing fee, and you're fine. There seem seem to be plenty.

The reality is, those patents haven't killed MP3 or GIFs. If anything, it's Ogg Vorbis and PNGs which are an endangered species - not from litigation, but disuse. (The MP3 patent, by the way, is Fraunhofer's - a German group, not US.) Patents or no patents, MP3 and GIF are still the format for that application, and supported by plenty of free/open source programs.

So the future for free software is (and this would be fine with me, except that it doesn't promote either fair use or interoperability) a ghetto of free formats like Ogg.

Unlikely. As I said, we've had MP3 and GIF patents for years without this result - the former from a German company, not a US one - without the result you predict. Why would Europe adopting the US system have this result, when it hasn't happened in the US?

CDex uses LAME. LAME's site links here . The answer seems to be a big fat maybe. Also, try here, and click on News. Notice BladeEnc was discontinued for reasons including legal hassles. Also, note that RedHat wussed out and pulled MP3 support from RedHat Linux 8.

Or worse, have a gap between each track. Apple, oh Apple, WHY won't you address the issue of seamless (but still tracked) music?? if MP3/AAC can't handle it, then you should be supporting OGG or something that can.

Uhh, all the albums I play in XMMS are without gaps in between tracks (other than those on the CD) thanks to the XMMS Crossfade Plugin. There's nothing intrinsic to the MP3 format that causes the gaps. To do this on the iPod, Apple would have to transfer the next song into the 32- or 64-MB buffer and tell the hardware to immediately beging decoding the next file once the first one is done. They're already buffering the next song, but my guess is that the decoding hardware cannot handle song changes fast enough.

The issue has been brought up many times on the Apple discussion forums, but I've never really seen a good response on the issue.

And the iPod can't even play a trance cd ripped as one track without stopping halfway through. Why the hell can't it read in more data while playing what is currently in memory?? Grrr!!!

This seems to be an issue with Apple's caching algorithm. They apparently assume that people will be playing smaller tracks as opposed to larger ones that do not fit in the buffer. When you are halfway through an album, the iPod flips out because the buffer is empty and it didn't know to continue reading the file from disk. The pause results from the iPod needing to go back to disk. This may be less of an issue on the new iPods with the 64-MB buffer, especially if the album is less than 64 MB.

I don't know why they haven't fixed these problems; they seem relatively simple on the surface.

Why the hell would you use Winamp on Wine instead of straight up XMMS? XMMS is much much better than Winamp. A specific example: XMMS's random function actually works. With Winamp, even if you have hundreds of songs in the playlist, with randomize you get the same 10 or so over and over.

You might like Rhythmbox a bit better than GQmpeg or xmms but it depends how you weight your different needs. It doesn't look like ass and it has neat metadata but 1. no viz, 2. no ID3 editing, and 3, no moon on a stick.

This is assuming a gtk2 app is acceptable, you can get it running-without-crashing for enough time to build up useful playlists and use it enough to make the metadata actually have an effect.

If you can't, there was a fork/branch a while back that add's streaming management and is relatively stable.

For the id3 tags, I highly highly recommend EasyTAG.

that itunes skin looks like the standard "ultrafina" XMMS skin to me

look at it here:
http://xmms.org/files/Skins/images/ultrafina_sem.j pg

Ok, ignoring the dumb idea or converting one compressed lossy format for another, you need to go here and get the mpg123 plugin. Install that, and you can play mp3s as normal!

Problem with Konq, so many websites that dont render properly (many .com sites) Mozzy is more temperamental to 'em. granted the mplayer gui isnt default, the gui code is still based upon GTK+.

have you looked at the screenshots of kvirc? its more bloated than mIRC. Xchat is pretty thin, thats not just opinion its fact, Im guessing you're trying to stir me up ;)

just looking at some screenshots of Juk, the thing that disappoints...i just want to play mp3s/ogg, sure Juk might do more etc..but the interface, its HUGE. In comparison to xmms, its 274x115 in size. Looks like an overkill personally. main reason why most people prefer a sperate tag editor easytag and a seperate player xmms Specialised programs, for Specialised Jobs.

Key features of the Network Audio System include:

• Device-independent audio over the network
• Lots of audio file and data formats
• Can store sounds in server for rapid replay
• Extensive mixing, separating, and manipulation of audio data
• Simultaneous use of audio devices by multiple applications
• Use by a growing number of ISVs
• Small size
• Free! No obnoxious licensing terms

• Festival - The Festival Speech Synthesis System.
• mpg123 - a command line MP3 player
• GAIM - a free AOL IM client
• OpenOffice (StarOffice) - the (now opensourced) StarOffice Suite has built-in NAS support for the Solaris and Linux Platforms.
• The Qt Library - from Trolltech supports NAS natively. You will need to pass the '-system-nas-sound' to './configure' before building.
• libSDL - SDL, the Simple DirectMedia Layer library, now has native NAS support thanks to Erik Inge Bols\x{00F8}
• XAnim - the X Animation viewer
• XBoing - a blockout type X game
• XPilot - a multiplayer client/server space warfare game
• Xemacs - the best cross-plaform, cross-language IDE
• Alsaplayer - A NAS Output plugin written by Erik Inge Bols\x{00F8} is now supplied with the Alsaplayer distribution.
• X MultiMedia System (XMMS). A NAS Output plugin written by Willem Monsuwe is available at ftp://ftp.stack.nl/pub/users/willem/
• Wine. A NAS plugin written by Nicolas Escuder is now available with the WINE distrubution.

Really? Where's the bug report? I don't see anything on bugs.xmms.org.

Sorry for sounding like an a-hole, but an AC exclaiming a bug in a product, no follow up on the product's web site, and no other info sounds very suspect to me.

-Ducky

I'm sure there are exploitable buffer overflows in Vorbis too but as the format is so little used (relatively), hackers ain't looking for them. The day Vorbis is more popular than mp3 is the day the hackers change what they're targeting.

Much like people used to claim in days of old that certain message base formats (BBS / FTN message 'echoes') were faster than others, this is also a bit of rubbish. The format doesn't contain vulnerabilities; the players that implement the format have vulnerabilities. It is, in point of fact, perfectly feasable to assume that the same, if only slightly different vulnerability could possibly be exploited with the Ogg Vorbis format.

Unchecked buffers (read: lazy/braindead programming and poor code audits) are at fault here. MP3 is merely the current carrier.

But you're right; it is a feeble excuse to switch formats. It would be more apt to suggest that people switch to a different player, or use a different operating system, but I'm not going to do that.

http://www.xmms.org

feh
gtk-gnutella
lopster
dc_gui w/ dctc
mtr
gkrellm (Not sure how well this would work...do OS X systems have a compatible /proc?)
xmms

I wasn't going to reply to this, but then I saw this little nugget.

You may already be aware, but just in case you're not, there are a few *nix equivalents for these "applications you can't live without":

WinAmp: Try XMMS. It does everything WinAmp does, plus several things it can't, and even looks and works the same (it is 100% skin-compatible with WinAmp). Of all the *nix equivalents, XMMS is probably the closest match. Home Page

Photoshop: Of course, everyone will tell you that The GIMP is a worthy replacement for Adobe's product. In practice, it lacks only a few high-end features (such as CMYK color separation) that professional users require; but for everyday use it's very close indeed. Try the Win32 port first, though, to help determine if it's right for you. Home Page

Flash MX: ...You've got me here. I don't think there's a single Flash solution for *nix, beyond the outdated Flash 5 plugin for Netscape/Mozilla. Anyone with better knowledge?

Nero: Believe it or not, Nero disc images are simply ISOs with a different TLA tacked on, so switching to Linux or another *nix doesn't require giving up the ability to use them. For CD burning and mastering, I've found cdrecord to be an excellent program, almost as easy to use as Nero, and unlike Nero I've yet to make a coaster with this thing. Excellent piece of software. Home Page

Exact Audio Copy: ...I admit it, I don't know what this program is - I've never heard of it. Thus, I can't give an alternative for it, I fear...

I'll second this. Specifically, what I'm looking for is a KDE theme that matches this GTK theme and this XMMS skin. KDE Look, this site where most people tell me to go, didn't really have anything appropriate. Just a lot of Aqua clones.

3) WinAmp has a nifty double-size function that makes it quite usable on the TV. I don't know if XMMS or any of it's ilk have this, though.

There are a few similar projects out there as well that I've been tracking.

• Myth TV has a music mode AND does live tv functionality! (I will probably migrate to this instead of continuing my project).
• Dave/Dina project may fit the bill too.
• IR File Chooser for the perl hackers. :)

Yes, it's possible. You can even control xmms with it. Or even (shameless plug) AlsaPlayer (although the AlsaPlayer control doesn't work the way it should, yet. It's just a load of hackery at this point.). One issue, though, with all these, is setting up playlists. AFAIK the xmms plugin has some playlist control, but I've never tried it. The AlsaPlayer has basically nothing.

Jason Earl said...
RedHat can't distribute MP3 codecs without paying royalties, and so they don't distribute the libraries that XMMS uses to decode MP3s.

Err, umm.... well, xmms.org says:
To clarify, since the beginning of our mp3 licensing program in 1995, Thomson has never charged a per unit royalty for freely distributed software decoders. For commercially sold decoders - primarily hardware mp3 players - the per-unit royalty has always been in place since the beginning of the program.

So all this about RedHat not being able to distribute MP3 codecs without paying royalties actually appears to be, as we say, a bunch of FUD. Maybe they have different reasons, but it's not about royalties.

it might be an idea for the XMMS people to contact this guy/company and see if they could pass on the knowledge so *nix systems could benefit too

Try this.

Never heard of it, but the stream looks like a normal Shoutcast/Icecast stream and xmms likes it.

Now if they only started to play Arkanoid... :-)

Not sure this isn't overreacting a bit at least on the Linux front. Look at xmms's website for their nice statement on the front page. They claim it doesn't affect them and no changes will be made in their distribution of the player.

Taken from the XMMS website:

Statement from Thomson Multimedia, mp3 Licensing Aug 29, 2002


In a posting appearing Tuesday August 27, 2002 on the Web site 'slashdot.org,' an individual cited a change in the mp3 license fee structure of Thomson and Fraunhofer. The writer of the post apparently misread the mp3 licensing conditions, as Thomson's mp3 licensing policy has not experienced any change.

To clarify, since the beginning of our mp3 licensing program in 1995, Thomson has never charged a per unit royalty for freely distributed software decoders. For commercially sold decoders - primarily hardware mp3 players - the per-unit royalty has always been in place since the beginning of the program.

Therefore, there is no change in our licensing policy and we continue to believe that the royalty fees of .75 cents per mp3 player (on average selling over $200 dollars) has no measurable impact on the consumer experience.

Stefan Geyersberger Business Manager - Audio & Multimedia

Who this kills is the free (as in speech) players - Zinf, XMMS, etc. They can't afford $50k OR $0.75/copy. They can either hope Fraunhofer doesn't notice them, or try to relocate to a place with either no software patents or no Fraunhofer patent, or they can leave MP3. In fact, Linux users in general may be left out in the cold, because I'm not aware of any commercial MP3 decoders for Linux, at all.

Unfortunately, this probably won't be enough to move the world from MP3s. WinAmp will still be downloadable for free, which is all 98% of users care about.

I remember when I was at EMusic, I met with the Thompson guys, who were trying to figure out how to make money on this (circa 1999). I explained to them that nobody was going to pay for a decoder, and that their choice was either to give the decoder away or have people switch to something else. I also suggested the encoder should be free for non-commercial use, in order to cement their current dominance against (then soon-to-be-released) Windows Media.

One of them replied (imagine a German accent), "I see! Vee give avay evrysing for free, and you make more money selling music!"

So, you could say we had a meeting of the minds. :)

I posted this yesterday (and even got trolled!) My example isn't a good one--it works best with photos, but I don't have any handy that aren't copywritten by someone else and I don't have a digital camera handy.
Here's the post again:

Encoding image data in Ogg Vorbis audio streams:

Written by zinx:
http://halcyon.bluecherry.net/~rain/oggpic/ogg2yuv
http://halcyon.bluecherry.net/~rain/oggpic/yuv2ogg

The quality is better than you might expect, and they're fun to listen to! (Note: requires imagemagick, cat, ogg123, and oggenc.)

(sample data is available in the same directory, http://halcyon.bluecherry.net/~rain/oggpic/, if you're too lazy or lack the resources to do it yourself.)

Note that this is meant to be interesting rather than practical. It's a hack. But, like I said, the images are fun to listen to... (You can just use convert and play the sound as raw 8-bit samples if you want to listen to some images without the ogg step.) While this should be obvious, it apparently wasn't to someone yesterday.

Have fun!

Check the plug-in directory. I've had no problems playing vorbis files on my computer via xmms.

> IMHO, it's time to build a lossy format for storing graphics similar to Ogg Vorbis. Perhaps the video codec Ogg just released can be used to make reasonable single-framed movies? Anyone familiar with the format care to comment?

Encoding image data in Ogg Vorbis audio streams:

Written by zinx:
http://halcyon.bluecherry.net/~rain/oggpic/ogg2yuv
http://halcyon.bluecherry.net/~rain/oggpic/yuv2ogg

The quality is better than you might expect, and they're fun to listen to! (Note: requires imagemagick, cat, ogg123, and oggenc.)

(sample data is available in the same directory, http://halcyon.bluecherry.net/~rain/oggpic/, if you're too lazy or lack the resources to do it yourself.

Thanks to a conversation that went something like this:

"I need some new music."
"What kind?"
"I dunno, surprise me."

I've been getting into music like this. I'm liking it. While most of my favorites so far have been mentioned by others (Aphex Twin's Richard D. James, Boards of Canada's Music Has The Right To Children, etc.), I haven't seen my top favorite mentioned. Boulderdash's We Never Went to Koxut Island is an absolutely awesome album, IMO. The songs "Headless in a Topless Bar" and "Dregs of Tar" are just... Wow.

(Be sure to try the Iris plugin for xmms, with the Background color Random on beat option set, and the output plugin set to the OSS driver. Fullscreen, obviously. ;))

Confronting the KDE propaganda machine.

The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

• Myth #1 - KDE is more integrated than GNOME

  The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

• Myth #2 - KDE is easier to use

  Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME, and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian, which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small and lame Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth #3 - KDE is more popular

  In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth #4 - Konqueror is the best Linux browser

  Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

• Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

  This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications get a good deal more testing in their 0.x stages, and despite shorter development phases they mature and reach stable featureful release versions much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not just in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.

  
  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth #6 - KDE is faster and takes less memory than GNOME

  KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues - in fact, GNOME 2 is significantly faster with fewer resources than previous version, a feat quite beyond the KDE project), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

• Myth #7 - GNOME development is slower. KDE releases faster.

  Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.
  
  Perhaps the greatest example of KDE release games occured with the recent KDE 3.0 release. In a desperate race to beat GNOME 2.0 to, the KDE team did not put back their schedule in the middle of a late release freeze when they suddenly added lots of new features - and, as expected, this has proved to be disasterous. KDE 3.0 is the worst KDE release yet in terms of reliablity - and is essentially early beta software put out as a stable release. Compare this with GNOME, which has had a number of betas and quality assurance procedures leading up to the eventual release of GNOME 2.0. The difference in approach is obviously due to the ultimate destinations of the systems and the vastly more experienced developers behind GNOME. GNOME is heading for commerical use on Sun and HP desktops, and hence requires commericial release quality. While KDE is destined for the porn and MP3 boxes of noisy advocates who don't mind huge numbers of crashes while waiting for KDE 3.0.0.4 to fix issues overlooked in the mindless rush to release. Quality control is an afterthought to the KDE project - the version number and releasing first are everything.

• Myth #8 - The Qt toolkit is cross-platform and yet takes advantage of each individual platform

  The Qt toolkit (the software at the heart of KDE) is supposedly a cross-platform toolkit allowing the lucky developer the opportunity to write Windows/Linux/Mac software all at once. And yet, among the magical mythical claims made, the most nonsensical is that it makes applications which take advantage of the distinct features of the different platforms. This is of course, nonsense. Qt is a bloated, slow layer that is slapped over a native system's APIs in an attempt to make all the systems look alike. It no more takes advantage of Linux/Windows/Mac than Java does - in fact it offers many of the disadvantages of Java with few of the advantages. If you have ever wondered why the KDE desktop looks so much like Windows... you need look no further than Qt. Qt is a lowest common denominator toolkit, and that LCD is Windows - Trolltech's, the creator of Qt, real market.

• Myth #9 - TrollTech is a friend of Free software

  To Be Written. Ideas: Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt, and hence KDE. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare (3 licenses to deal with). Gradual migration of features belonging in KDE into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE an irrelevant launcher of Qt applications. Claims made that Qt is GPL, while true, hide the real truth. There cannot be a real fork of Qt for the KDE project: Core developers work for Trolltech; any fork would need to be full GPL and hence ban any closed-source apps from KDE altogether (all KDE apps must link with Qt); Any commerical licensees of Qt (non-GPL) would and could only follow TrollTech. KDE is stitched up good and proper.

• Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

  To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-out and of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

What would be really cool is an XMMS input plugin that can decode WMAs.

Confronting the KDE propaganda machine.

The KDE project is famous for its funded and organised trolling of weblogs and message board associated with Linux and Free software/open source. Outrageous newbie impressing claims are made for the software and huge quanities of FUD are spread to destroy competitors. If this sounds familiar, then you are correct, most of these tactics were lifted straight from Microsoft's arsenal of dirty tricks. The Windows look and feel is not the only thing the KDE project has copied! In this short article I will address some of the lies and FUD spread by the KDE trolling teams. It is my hope that this, in some small way, will redress the balance and re-introduce two things almost eradicated by the KDE project: Honesty and facts.

• Myth #1 - KDE is more integrated than GNOME

  The oft-heard cry of the noisiest KDE advocates. No explanation is given, the reader is expected to simply grok the wholesomeness of KDE and the lack of this mystical quality in GNOME. It is nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac. Whatever "integrated" actually means.

• Myth #2 - KDE is easier to use

  Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (all systems do), but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME, and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet by Ximian, which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various tricky cross-platform and potentially risky system configuration operations. KDE offers none of this, only a few small and lame Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth #3 - KDE is more popular

  In what sense? Arguably more people use KDE, but it is a close run thing. Most KDE zealots use the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when *both* GNOME and KDE are frequently installed on the same system. The systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is commercial use of a desktop, and here, GNOME is far ahead with both Hewlett Packard and Sun committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use. Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth #4 - Konqueror is the best Linux browser

  Oh for a penny every time this lie is told in any KDE story! Konqueror not a bad piece of software. It's authors deserve praise for the work done on it. However, the sheer amount of orgasmic gushing by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla or Opera. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus filemanager/browser (a target of much KDE FUD during its development).

• Myth #5 - KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit

  This is the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications get a good deal more testing in their 0.x stages, and despite shorter development phases they mature and reach stable featureful release versions much more quickly. Some examples of this are: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet, X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade and Anjuta. All of these packages ooze quality, and far outclass their KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not just in the area of user applications that GNOME is vastly more advanced. With the forthcoming 2.x release, a number of impressive behind the scenes technologies will finally mature: component technology (bonobo), media (Gstreamer), internationalisation (pango). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what is more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  It is also worth noting that GNOME also develops code for use outside the project (see the XML libraries as one example) - the KDE project rarely (if ever) engages in this kind of work. KDE developers ensure that all software must link with Qt, and hence tie it closely with the Qt toolkit preventing re-use and enhancing the value of TrollTech intellectual property.

  
  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth #6 - KDE is faster and takes less memory than GNOME

  KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects; and masses of unnecessary allocations and deallocations of memory are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) used to bandage up the design and coding flaws in the decrepit KDE architecture to see the truth.

• Myth #7 - GNOME development is slower. KDE releases faster.

  Fundamental misunderstanding. The KDE project releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.
  
  Perhaps the greatest example of KDE release games occured with the recent KDE 3.0 release. In a desperate race to beat GNOME 2.0 to, the KDE team did not put back their schedule in the middle of a late release freeze when they suddenly added lots of new features - and, as expected,

• Myth #10 - KDE is more than attractive, but GNOME/GTK is ugly

  To be Written. Ideas: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are better thought-out and of a far higher quality than the poorly drawn and cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

If you are looking for cheap, maintainable, stable software to replace your current Windows environment, then look into this :

Slackware Linux.
KDE.
OpenOffice (maybe StarOffice or Hancom Office or KOffice).
Mozilla (or maybe Netscape 6 or Opera).
The GIMP.
XMMS.
MPlayer.
GNUCash (or maybe Kapital).
Evolution.
NEdit.

Or if you need anything else, check out Freshmeat.

There's several XMMS plugins that do this type of plot. The descriptions don't say whether they have a linear / log switch, though.

• Myth: KDE is more integrated than GNOME
  
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared any version of the Apple Mac.

• Myth: KDE is easier to use
  
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. What about application (see GNOME apps later) installation and removal: GNOME has the excellent RedCarpet by Ximian , which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase... which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post on a zealot-ridden site can reduce the result to a running joke. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system - and indeed, can co-exist except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead. Both Hewlett- Packard and Sun Microsystems have committed to using GNOME as the desktop for their Unix systems. This ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME effort is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror is a fine piece of software - it's authors deserve plently of praise - it is, however, quite unreliable and lax in its support of basic web standards compared to either Mozilla or Opera . It is also extremely slow - slower than the latest incarnations of the GNOME Nautilus filemanager/browser.

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  
  Reality: See also: Qt/TrollTech. Easily the most common wail heard by KDE developers - and yet it is easily disproved by looking at the actual applications for GNOME/GTK and KDE/Qt . KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2. GNOME applications wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly: the superb Evolution (groupware/email), Gnumeric (spreadsheet), Pan (newsreader), The GIMP (image manipulation), Abiword (word processing), RedCarpet ,X-Chat (IRC client), XMMS (media player), Galeon (web browser), and for developers: Glade , Anjuta . All of these packages ooze quality, far outclass and are, at least, 18 months ahead of their KDE/Qt counterparts. It's not only in the area of user applications that GNOME is lightyears ahead, with the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo ), media (Gstreamer ), internationalisation (pango ). As a developement platform, GNOME 2.x is, frankly, years ahead of KDE. And what's more, it is not tied to a lowest common denominator cross-platform bloat-fest like Qt. Yet despite all this, we are still fed the lie that Qt and C++ makes development easier. Judge for yourself.

• Myth: KDE is faster and/or takes less memory than GNOME
  
  Reality: KDE is written in C++. While this is not necessarily a bad thing, it is when the programmers do not know enough to avoid certain pitfalls that can plague software projects. Stupid use of ++/-- with C++ objects; masses of unnecessary allocations and deallocations of memory, and the most cretinous of all, blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the KDE architecture and basic design.

• Myth: GNOME development is slower. KDE releases faster.
  
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the consequent problems with libraries. It bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version. Occasional releases of the entire GNOME system are done, and that's when the GNOME version number is bumped (currently it is 1.4). To see this in action, use RedCarpet and you will regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  
  Reality: Qt started out as non-Free. KDE developers knew this violated the GPL and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Labyrinthine licensing nightmare.

• Myth: Most good GNOME apps are actually GTK applications.
  
  Reality: Most KDE apps, such as those from The Kompany are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

• Myth: KDE is attractive/GNOME/GTK is ugly
  
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

• Myth: KDE is more integrated than GNOME
  Reality: The oft-heard cry of the noisiest KDE advocates. No explanation is given - the reader is expected to simply grok the wholesomeness of KDE, and the lack of this mystical quality in GNOME. It's nonsense of course. Neither desktop is particularly "integrated" compared to Windows XP, and certainly not compared to any version of the Apple Mac. Whatever "integrated" really means.

• Myth: KDE is easier to use
  Reality: Again, such nebulous arguments are never explained, and the reader is expected to simply understand the truth of the zealots statement. Both KDE and GNOME have user-interface irritations (indeed, all systems do) - but "ease of use" is not a simple thing to measure. KDE has never been subjected to detailed user testing, unlike GNOME [gnome.org], and the claims of user-friendliness are from crazed supporters and not average users. Furthermore, the KDE faithful rarely look beyond simple-minded copying of Windows, and forget that administering a desktop system is just as important as having widgets in the correct place on the toolbar. For example: What about application installation and removal? GNOME has the excellent RedCarpet [ximian.com] by Ximian [ximian.com], which makes the installation, removal and updating of applications trivial. KDE users are expected to fend for themselves with brutal command line driven systems. GNOME also has the excellent Ximian setup tools to handle various very tricky cross-platform and potentially risky system configuration operations - KDE offers none of this, only a few small half-assed Linux-only tools, which make no attempt at check-pointing to return to known working configurations.

• Myth: KDE is more popular
  Reality: In what sense? Arguably more people use KDE - but it is a close run thing. Most KDE zealots claim the results of online polls as proof of their superior userbase - which is, quite frankly, complete and utter nonsense. Online polls are the joke of the century; it doesn't even require a motivated script kiddie to render then worthless. A single post alerting the faithful on a zealot-ridden site can skew the result so much it makes American presidential elections look fair and well organised. Popularity is also difficult to measure when both GNOME and KDE are frequently installed on the same system. Indeed, the systems can co-exist and even run at the same time, except for certain applications such as panels. Many KDE users actually run GNOME applications for their superior features and stability, not realising that by doing so they are barely running KDE at all.

  One of the few solid measures of popularity is the adoption in commercial use - and here, GNOME is far ahead, with both Hewlett-Packard [hp.com] and Sun Microsystems [sun.com] committing to using GNOME as the desktop for their Unix systems. This also ties in with the previously mentioned ease of use - Sun's major contribution to the GNOME project is in the areas of user/developer documentation, testing, accessiblity and user-testing. Three of the less glamourous parts of desktop development. The arrival of the GNOME 2.x series will see these contributions reach fruitition and allow GNOME to make a quantum leap ahead of KDE in most of the basic computer/user issues.

• Myth: Konqueror is the best Linux browser
  Reality: Oh for a penny every time this lie is told in any KDE story! Konqueror [konqueror.org] is not a bad piece of software - its authors deserve praise for the work done in it. However, the sheer amount of orgasmic praise lavished by the KDE faithful is completely out of proportion to its actual quality. It is quite unreliable and even simple standards compliant pages can crash it quite comprehensively. It is also lax in its support of basic web standards compared to either Mozilla [mozilla.org] or Opera [opera.com]. It is also extremely slow - much slower than the latest incarnations of the GNOME Nautilus [eazel.com] filemanager/browser (a target of much KDE FUD during its development).
  .

• Myth: KDE applications are better/more advanced than GNOME ones due to the ease of developing in C++ using the Qt toolkit
  Reality: Easily the most common wail heard by KDE developers, and yet it is easily disproved by looking at the actual applications for GNOME/GTK [gtk.org] and KDE/Qt [trolltech.com]. KDE applications often have larger version numbers than GNOME ones... an old trick played by commerical software developers. Most KDE apps seem to jump for 1.x releases long before they are ready - KOffice [koffice.org] being the best example. None of the components in Koffice are worthy of a 1.0 release, let alone 1.1 or 1.2.

  GNOME applications [gnome.org] wait longer and get more testing in their 0.x stages and despite shorter development phases mature more quickly and reach stable featureful release states more quickly. Some examples of this are the superb Evolution [ximian.com] (groupware/email), Gnumeric [gnome.org] (spreadsheet), Pan [rebelbase.com] (newsreader), The GIMP [gimp.org] (image manipulation), Abiword [abisource.com] (word processing), RedCarpet [ximian.com], X-Chat [xchat.org] (IRC client), XMMS [xmms.org] (media player), Galeon [sourceforge.net] (web browser), and for developers: Glade [gnome.org] and Anjuta [sourceforge.net]. All of these packages ooze quality, and far outclass the KDE counterparts. It is no understatement to say that GNOME is at least 18 months ahead of KDE in applications, and pulling still further ahead.

  It's not only in the area of user applications that GNOME is lightyears ahead. With the forthcoming 2.x a number of impressive behind the scenes technology will finally mature: component technology (bonobo [gnome.org]), media (Gstreamer [gstreamer.net]), internationalisation (pango [pango.org]). As a developement platform, GNOME 2.x is, conservatively, 2-3 years ahead of KDE. And what's more, because it is not tied to a lowest common denominator cross-platform bloat-fest like the Qt toolkit, the lead (as with applications) can only increase further.

  Yet despite all this, we are still regularly fed the lie that Qt and C++ makes application and desktop development easier. Judge for yourself.

• Myth: KDE is faster and takes less memory than GNOME
  Reality: KDE is written in C++. While this is not necessarily a problem, it can be when Visual Basic reject programmers (which the KDE project is overrun with) do not know enough to avoid important pitfalls that plague C++ software projects. Stupid use of autoincrementing operators and iteration with C++ objects, and masses of unnecessary allocations and deallocations of memory, are two of the most common. KDE suffers badly from both problems.

  Perhaps the most cretinous of all problems is blaming the extremely slow startup times of KDE apps on GCC. The GNOME 1.x releases were hardly svelt (2.x fixes many of these issues), but GNOME is a fashion cat-walk superwaif when compared to KDE's 500lb fat-momma cheese-burger scoffing trailer trash. One need only look at the recent fuss over ugly KDE hacks (such as prelinking) to see the problem inherent in the poor KDE architecture and basic design flaws.

• Myth: GNOME development is slower. KDE releases faster.
  Reality: Fundamental misunderstanding. KDE releases as one big lump of code due to its use of C++ and the many problems this causes with libraries. The project bumps the version number of the entire KDE system for the smallest modifications. GNOME, on the other hand is componentized and each component releases on a (almost) separate schedule, bumping it's own version number but not the main GNOME version (1.4, for example). Occasional releases of the entire GNOME system happen, and that's when the GNOME version number is bumped (currently it is at 1.4). To see this in action, use RedCarpet and you will see regular updates to GNOME components. GNOME development is not slower, it is in fact faster and more advanced. Lamers and newbies, however, fail to understand the advantages of this method and just see KDE 1.1.1 followed a few weeks later by KDE 1.1.2. Wow! KDE roolz.

• Myth: TrollTech is a friend of Free software.
  Reality: TO BE WROTE -- IDEAS Qt started out as non-Free. KDE developers knew this violated the GPL, didn't care, stole others' GPL code by porting it to link (in violation of the license) with Qt and are therefore untrustworthy. KDE core developers work for TrollTech. Expensive per developer licensing for writing closed-source with Qt. Trolltech only moved towards the GPL because of the success of GNOME. Labyrinthine licensing nightmare. Gradual migration of features into Qt (and so into TrollTech's IP portfolio), allowing easy porting of apps to the revenue generating Windows world (see TheKompany for a perfect example), thereby making KDE irrelevant.

• Myth: Most good GNOME apps are actually GTK applications.
  Reality: TO BE WROTE -- IDEAS Most KDE apps, such as those from The Kompany [thekompany.com] are actually Qt apps because they want to port to the more lucrative Windows/Qt market.

  Myth: KDE is more than attractive - GNOME/GTK is ugly
  Reality: Mosfet liquid theme is an ugly and unstable hack. GNOME GTk icons are of a far higher quality than the cartoonish and confusing KDE ones. Qt is basically a Windows-look on a Unix platform.

This troll was reposted from the Troll Library without permission of the original author. If you object to this post, or if you wish to add your troll to the Troll Library, please reply to this message.

xmms

... WinAmp is bloated spyware, RealPlayer is the same ...

... the damn thing crashes!

... My perfectly usable computer has been handicapped by its software.

I'm glad to see this... MP3's have received so much attention, none of the other codecs haven't been in the news much. Sure, there's the random article comparing 4 or 5 codecs that no one's ever going to use, or the little articles saying that people hear an improvement in Ogg over MP3. But have you seen people using .ogg's? I do. Everything I've ripped is now in Ogg. Better quality, more flexibility, and a superior acoustic model.

I thought listening to the BBC over Ogg was cool. I remembered the first time I'd heard it over shortwave. Not to mention that it worked flawlessly. Then again, I'lve always got the latest plugin for my Winamp, and my XMMS. No annoying RealPlayer crap. No proprietary codecs. It works on my non-Windows boxes.

I sent a brief, yet eloquent note to the BBC webmaster when the original test completion was finished, and will probably send another encouraging this continued project. I would encourage the same from others.

Support your local hackers. (no, not crackers. hackers. Damn Hollywood crap.)

I'm not familiar with the state of MP3 tools which support ReplayGain, but I know that Gian-Carlo Pascutto just wrote a tool to add ReplayGain information to Ogg Vorbis files. There is an XMMS support in CVS which uses the information, and I just got done adding support for ReplayGain to ogg123 (it will be about a week before it goes into the xiph.org CVS pending the approval of some other changes). Winamp also supports ReplayGain using Peter's Vorbis plugin

Try grip. Configure it to rip to any format you want - all it needs is the path to the executable. It will do the freedb lookup and name the files in your favorite style too.

Since ogg vorbis is a free codec (as in beer; as in speech) this is really the best way to go. Note that US Linux users who rip to MP3 with free-as-in-beer software are probably in violation of one or more laws. Since XMMS plays OGG as well as MP3 you can mix and match MP3's from your favorite P2P community with OGG's of your own collection.

as you probably know there is a sparse few number of them available to download...

So what are you waiting for? Get oggenc and do your part!

-Renard

Even more important, users should download XMMS, which supports Vorbis on UNIX or FreeAMP which supports Ogg Vorbis on UNIX and Windows via a plugin.

Then (and this is the most important bit) go to BBC and use it to stream content.

First of all, I want to get one thing straight. Stealing music is illegal.

So is driving faster than 65 MPH. What's your point?

Such that this is, I think that Digital Rights Managment, properly implemented, could be a great thing.

First off, let me correct your terminology. The term "Digital Rights Management" is a smokescreen, intended to deceive the public. Its proper name is Copy Protection. The free market long ago made the decision that Copy Protection subtracts value from digital media, and is not wanted. The software industry, by and large, accepted this, and went on to make trillions of dollars. But now that older media publishing companies are wading into the digital age, they want to re-hash this mess all over again. It's the same basic idea, except this time they've given it the name, "Digital Rights Management."

I encourage you, do not go along with the semantic dodge, and call this stuff by its true name, Copy Protection. The computing consumer already understands what it is, and what it means for his/her investment in digital works.

Secondly, I can assure you that copy protection, by definition, cannot be implemented fairly. The taxonomy you relate is certainly interesting, meriting further study, perhaps as a basis for new legal frameworks. However, copy protection technology is fundamentally unfair. At its core, it presupposes that uses not authorized beforehand by the copyright holder are prima facie unlawful and prohibited.

As Professor Lessig correctly points out, this is pure bullshit.

But, I'm interested to hear, [ ... ] would DRM really be so bad according to you all? If you bought a car-stereo, a portable stereo, a home stereo, and computer running LinuxDRM (or WindowsDRM), and they were all registered to you, you could buy "Metallica - Master of Puppets (Live with the San Francisco Orchestra).DRM.mp3" and it would run on all your DRM-registered items.

Just so. But in this wonderful world you espouse, where is my right to create a DRM-registered player?

Right now, I can go out and write a visualizer for WinAmp, or XMMS, or Cthugha, or any other music player I care to name, take the digital audio data -- no matter its source -- and convert it into moving visual forms and images. In a world of copy protection, I would not be allowed access to the audio data to create those visualizations because, technically, there's nothing preventing me from, rather than visually transforming the data, just saving it out to disk instead.

So, to write my harmless little display hack, I have to go to the RIAA and fellate some executive to get his permission, in the form of an "authorized player" key, to do so. Not only will this likely cost me thousands of dollars (assuming they don't reject me out of hand as not being a "credible developer"), but they will insist on code audits, precise download and usage statistics, and probably a key renewal fee. Moreover, after doing all this, if I fail to offer the proper ongoing tribute, or someone offers them more money, my "authorized player" key can be revoked, and all copies of my visualizer will stop working. My speech -- in the form of my code -- can be remotely and unaccountably silenced at whim.

All for a fscking display hack.

Now, generalize this to all forms of data meriting "protection": Music, software, text, Web page graphics, user interface layout, font outlines, Quake 3 Arena models, etc. It is not difficult to imagine that "permission" and "authorization keys" will be required to write any piece of software, and that obtaining same will be monsterously expensive, affordable only to wealthy corporations.

Sorry, I'm not buying this. I don't buy for one femtosecond that this level of "protection" is necessary to effect commerce and make fortunes in the digital age. Hell, Bill Gates became the richest man in the world selling stuff that end-users could copy at whim.

These reasons, among others, are why I've arrived at the conclusion: Copy protection is fundamentally unethical, and antithetical to the nature of computing. Copy protection measures as you describe will serve to kill innovation, not spur it.

Schwab

Here, fucknut.

I swear some of you babies need to be fucking spoonfed all the time. It is a wonder you get out of bed in the morning. And you call yourself a nerd!

Of course, mine was a fairly small project with less visibility, but I was still getting over 1000 downloads (as per the web logs) of each new version, so there were a significant number of users. Actually, the number of downloads helped give me a nice warm fuzzy feeling; "look at all these people using something I helped write!".

In the end, I passed control to the central XMMS team as I moved jobs and didn't have a SPARC at my desk. However, that was always my end goal, to have it in such a state that it could be integrated.

Winamp 3 will be like what XMMS 2 might be like, if such a thing were made.

There IS an XMMS 2 on their cvs.

http://cvs.xmms.org/index.cgi/

I don't know much about ogg, as I use mp3 for most of my music encoding. I've played around with various bit rates and finaly settled on what I felt was the best for me in terms of quality vs size.

I now encode all of my music at a variable bit rate 64-256kbps with lame. Lame 3.70 does a really good job of this and produces files (at least for the types of music I listen to) that sound very good. For the most part, they encode smaller than a 192kbps, as the average bit rate used is less. As a check, peeking at John Coletrane's Giant Steps, the average bit rate is right around 150. The bulk of my music averages between 160 and 192kbps.

The cool thing about vbr is that if the file needs more than that, is can use up to 256kbps to help make the harder to encode spots sound better. So I guess the worst case size you could get would be a song completely encoded at 256kbps (but I can't say that has ever happened).

I have a hard time telling these vbr 64-256kbps files apart from the orignal cd. Sometimes I can tell, but it is rare and difficult. However, IANAA (I am not an audiophile), so doing your own tests should help.

All of your standard tools should support vbr files. Xmms does a fine job. I did need to upgrade mpg123 to pre0.59s, however.

Anyway, consider vbr before you go straight to 300kbps.

I say who cares. We have XMMS, FreeAmp, and a whole host of other players. If your gratitude is based on the fact that WinAmp has better playlist controls, then do us all a favor and write a patch for one of the existing open source players. I'll admit that I haven't actually checked out the link, but are they making the source available? I doubt it, and so I say again, who cares.

While linux is improving nicely, it still lacks heavily in any music reporduction,

Actually, there's quite a bit of music production software for Linux.

media interfaces

You mean like Shockwave and MP3s?

business applications.

Such as Excel and Word?

I'd rather pay 199.00 bucks for something that works out of the box and comes with lots of software then several hours downloading, burning iso's and then chasing down the latest versions of all apps waisting a whole entire weekend or business days (thus costing more then the 199.00 XP package).

So would I. Fortunately, if I want to run Linux, I can get a complete set of CD-ROMs from CheapBytes for less than fifteen bucks (including postage) and usually install or upgrade the whole system in about two hours, most of it hands-free. Most of these systems have a reputation for running smoothly "right out of the box."