I remember Club Mario too. In fact, the first time I saw the Mario cartoon it was on this. Imagine my surprise when I saw the Super Show live action segments a few years later.
BTW do you remember what the hell they were talking about on Club Mario?
"I think that been able to play most widespread audio and video formats (with Xine or Mplayer) should be a key point for a moder linux distro."
Then join the fight against software patents. Distros like Fedora are only protecting themselves, you know. Multimedia is a patent hell, basically everything under the sun is under a patent, and you need to pay for licenses.
BTW, it may not be your cup of tea, but Gentoo has none of these problems. You just emerge xine or mplayer or whatever and it comes with full support for pretty much everything.
Then a company called 4Front came along. They wanted to create a common sound API standard for all those UNIX systems that lacked sound support, like Linux, BSD, etc. Hence OSS (Open Sound System) was born. A simple API to cover a simple need: get sound. Cool.
But then they decided to charge people for their drivers. Now who hell would pay for a fucking sound driver? Hence the OSS/Free project was born. Its mission: create free OSS-compatible drivers.
But most OSS/Free drivers sucked. Buggy, lacked basic features, etc. And they still suck as of now. But since sound manufacturers often don't reveal specs, you can't really blame the OSS/Free guys for this.
Also, OSS was nice and all, but lacked advanced audio features needed for pro work, and >2 speaker support requires having multiple sound device nodes, which is an ugly hack. Also, some people didn't like its ioctl() interface, saying a library would be superior. Hence the ALSA project was born. Its mission: create a modern sound API for Linux (yes, only Linux), along with free drivers that don't suck.
But ALSA has many problems. First, its library-based API broke binary and source compatibility many times. Second, it has a powerful infrastructure, capable of doing pro work stuff such as routing sound from a card to another, or use plugins, however ALSA can only be configured to do those things through confusing plaintext config files that are barely documented, and hard to understand. Thirdly, it's a bitch to have working. ALSA is very modularized, which is normally a good thing, however it tends to make it break up more than the plain one module way of OSS.
Oh, and let's not forget that since OSS is an established standard, ALSA needs backwards OSS compatibility. Hence the ALSA people made OSS emulation standard in ALSA. Which brings up the same chicken and egg problem we have seen with OS/2 and its Win 3.1 support: since ALSA has OSS API support, why should we care about the native ALSA API? So, even today, many apps have not taken the plunge to ALSA because OSS "just works". Well, most of the times at least. OSS emulation is not perfect (gasp!).
Oh, another thing: since the ALSA libs are LGPL and have broken backwards compat quite often, closed-source projects tend to forget about bothering to support ALSA, prefering the simple ioctl() API of OSS.
And of course most ALSA drivers are very buggy, for the same reason as the free OSS ones. Which brought up some interesting situations: sometimes when an application supports both the OSS and ALSA APIs, some ALSA drivers actually work better with the OSS API!! Another blow to the native ALSA API.
But one of the biggest problems of ALSA is that its devs refuse to believe that having more than one app playing sound at the same is a major problem, which continues to piss off lots of people to this day. Indeed, very few sound cards can actually play more than one stream directly in hardware, so the mixing must be done in software, preferably at the driver level so that the operation is transparent and (this is very important) latency-less. Windows has done this for a long time now. The ALSA people came up with "dmix", a userspace plugin that does the transparent mixing we needed so much. However, being a userspace plugin, it needs to be configured, so again the ugly ALSA config files are to be used. After being configured, dmix works quite nice, HOWEVER for some reason some apps just crap out when using dmix. Apparently dmix is not transparent enough. It's clear now that software mixing must be done at a lower level, however no work is done on that front. Arguments against it say "this shouldn't be in kernelspace, bla bla". which is funny, because the commercial OSS drivers do support hardware mixing inside their kernel drivers. And it always work fine.
For a long time people have tried to solve the more-than-one-app problem through things called sound servers. The idea is simple enough: have one program open the sound
Actually, believe it or not, xterm was one of the first apps (if not the first one that's not a test) to have fontconfig support. We don't notice it though, because it still uses a bitmap font by default, and has a crappy font selector.
"If they all agree that it's "crap" then why don't they use Rythmbox or Beep or whatever?"
You're underestimating the force of inertia. Many XMMS users are former Winamp users. For them the idea of using a different interface, even though there are superior ones out there, is frightening. Not that I don't understand them, I too used XMMS for too long.
"I don't even use the GUI. All I care about is the video. Using the keyboard arrow keys to fast forward is much, much easier and more convenient than using the mouse."
So do I. Did you even read what I said? Besides that wasn't my point. My point was that since many people use xmms and/or gmplayer, crappy fonts are still part of the Linux desktop, sadly.
Of course the real people at fault are the developers of those apps, who are still stuck in 1999. Yeah I know, migrating GTK+ 1.x code to 2.x is a bitch, but christ, GTK+ 1.x is long dead, can we bury it already??!
You're forgotting all those people who still use that godawful crap that is XMMS. Oh, and MPlayer's awful GUI (I'm a big MPlayer user but its GUI is just terrible, terminal MPlayer all the way for me). Both still use GTK+ 1.x, which never got modern font support.
Wait, they CHARGE people for such a TRIVIAL app?? Are all OSX developers like this? I have nothing against paying for quality software, but whoever sells something that simple should be shot on sight.
ACK! The SB Live 24-bit is a complete piece of shit. It uses a whole new chipset that doesn't work at all like the one in the rest of the Live and Audigy series (ie. EMU10k1). Yes, that sucks. Creative should be beaten up with a large hammer for such a confusing name. I made the same mistake recently. Hopefully the place that sold it to me exchanged it for an Audigy.
Funny how it worked flawlessly under mplayer on my Linux box, yet I hear people here saying it required them to upgrade QT to v7. Makes you wonder if: 1) Apple does a shitty job at correctly supporting their own damn formats OR 2) ffmpeg (the almighty decoding lib under mplayer's hood) comes from TEH FUTURE
Slashdot Mirror
I remember Club Mario too. In fact, the first time I saw the Mario cartoon it was on this. Imagine my surprise when I saw the Super Show live action segments a few years later.
BTW do you remember what the hell they were talking about on Club Mario?
I agree, Pinky and the Brain was brilliant, however I think there was like about a hundred episodes, so I can't really imagine a DVD box set.
"I am just completely awestruck. That is so incredibly geeky. Kudos to you! :)"
But the fact that he hosted the image on members.aol.com kind of counteracts the geekiness.
Have we stumbled back to 1993 while I was not looking?
So basically the answer is yes?
Do they still cripple the KDE libs? I'd like to try Fedora, but its GNOME-centric nature annoys me.
"I think that been able to play most widespread audio and video formats (with Xine or Mplayer) should be a key point for a moder linux distro."
Then join the fight against software patents. Distros like Fedora are only protecting themselves, you know. Multimedia is a patent hell, basically everything under the sun is under a patent, and you need to pay for licenses.
BTW, it may not be your cup of tea, but Gentoo has none of these problems. You just emerge xine or mplayer or whatever and it comes with full support for pretty much everything.
We can say "fuck" on /. you know. Self-censoring yourself only makes you look silly.
At first there was silence.
Then a company called 4Front came along. They wanted to create a common sound API standard for all those UNIX systems that lacked sound support, like Linux, BSD, etc. Hence OSS (Open Sound System) was born. A simple API to cover a simple need: get sound. Cool.
But then they decided to charge people for their drivers. Now who hell would pay for a fucking sound driver? Hence the OSS/Free project was born. Its mission: create free OSS-compatible drivers.
But most OSS/Free drivers sucked. Buggy, lacked basic features, etc. And they still suck as of now. But since sound manufacturers often don't reveal specs, you can't really blame the OSS/Free guys for this.
Also, OSS was nice and all, but lacked advanced audio features needed for pro work, and >2 speaker support requires having multiple sound device nodes, which is an ugly hack. Also, some people didn't like its ioctl() interface, saying a library would be superior. Hence the ALSA project was born. Its mission: create a modern sound API for Linux (yes, only Linux), along with free drivers that don't suck.
But ALSA has many problems. First, its library-based API broke binary and source compatibility many times. Second, it has a powerful infrastructure, capable of doing pro work stuff such as routing sound from a card to another, or use plugins, however ALSA can only be configured to do those things through confusing plaintext config files that are barely documented, and hard to understand. Thirdly, it's a bitch to have working. ALSA is very modularized, which is normally a good thing, however it tends to make it break up more than the plain one module way of OSS.
Oh, and let's not forget that since OSS is an established standard, ALSA needs backwards OSS compatibility. Hence the ALSA people made OSS emulation standard in ALSA. Which brings up the same chicken and egg problem we have seen with OS/2 and its Win 3.1 support: since ALSA has OSS API support, why should we care about the native ALSA API? So, even today, many apps have not taken the plunge to ALSA because OSS "just works". Well, most of the times at least. OSS emulation is not perfect (gasp!).
Oh, another thing: since the ALSA libs are LGPL and have broken backwards compat quite often, closed-source projects tend to forget about bothering to support ALSA, prefering the simple ioctl() API of OSS.
And of course most ALSA drivers are very buggy, for the same reason as the free OSS ones. Which brought up some interesting situations: sometimes when an application supports both the OSS and ALSA APIs, some ALSA drivers actually work better with the OSS API!! Another blow to the native ALSA API.
But one of the biggest problems of ALSA is that its devs refuse to believe that having more than one app playing sound at the same is a major problem, which continues to piss off lots of people to this day. Indeed, very few sound cards can actually play more than one stream directly in hardware, so the mixing must be done in software, preferably at the driver level so that the operation is transparent and (this is very important) latency-less. Windows has done this for a long time now. The ALSA people came up with "dmix", a userspace plugin that does the transparent mixing we needed so much. However, being a userspace plugin, it needs to be configured, so again the ugly ALSA config files are to be used. After being configured, dmix works quite nice, HOWEVER for some reason some apps just crap out when using dmix. Apparently dmix is not transparent enough. It's clear now that software mixing must be done at a lower level, however no work is done on that front. Arguments against it say "this shouldn't be in kernelspace, bla bla". which is funny, because the commercial OSS drivers do support hardware mixing inside their kernel drivers. And it always work fine.
For a long time people have tried to solve the more-than-one-app problem through things called sound servers. The idea is simple enough: have one program open the sound
Sound on Linux as a whole is messed up anyway, so if you're doing professional audio work, you may as well forget about Linux.
"And in Gnome I've not seen any dialogs that are 800x600 or larger, but then again, I ussually run at 1024x768 or 1600x1200, so I may not notice."
You've just proved his point: too often developers are not affected by a particular problem, so they simply pretend it doesn't exist.
Actually, believe it or not, xterm was one of the first apps (if not the first one that's not a test) to have fontconfig support. We don't notice it though, because it still uses a bitmap font by default, and has a crappy font selector.
"If they all agree that it's "crap" then why don't they use Rythmbox or Beep or whatever?"
You're underestimating the force of inertia. Many XMMS users are former Winamp users. For them the idea of using a different interface, even though there are superior ones out there, is frightening. Not that I don't understand them, I too used XMMS for too long.
"I don't even use the GUI. All I care about is the video. Using the keyboard arrow keys to fast forward is much, much easier and more convenient than using the mouse."
So do I. Did you even read what I said? Besides that wasn't my point. My point was that since many people use xmms and/or gmplayer, crappy fonts are still part of the Linux desktop, sadly.
Of course the real people at fault are the developers of those apps, who are still stuck in 1999. Yeah I know, migrating GTK+ 1.x code to 2.x is a bitch, but christ, GTK+ 1.x is long dead, can we bury it already??!
You're forgotting all those people who still use that godawful crap that is XMMS. Oh, and MPlayer's awful GUI (I'm a big MPlayer user but its GUI is just terrible, terminal MPlayer all the way for me). Both still use GTK+ 1.x, which never got modern font support.
"Perhaps someday I will switch to L4/Hurd for the exact opposite reasons."
I hope you're an immortal. If Hurd ever becomes a usable system, it won't be in anyone here's lifetime.
A skull and crossbones for something that's meant to save your screen?? That's one of the worst logos I have ever seen.
Wait, they CHARGE people for such a TRIVIAL app?? Are all OSX developers like this? I have nothing against paying for quality software, but whoever sells something that simple should be shot on sight.
ACK! The SB Live 24-bit is a complete piece of shit. It uses a whole new chipset that doesn't work at all like the one in the rest of the Live and Audigy series (ie. EMU10k1). Yes, that sucks. Creative should be beaten up with a large hammer for such a confusing name. I made the same mistake recently. Hopefully the place that sold it to me exchanged it for an Audigy.
"Java apps... not sure about. I generally hate standalone Java apps, especially after my experiences with the execrable OpenOffice."
OpenOffice is not Java.
"No one has written decent Quicktime codecs for DivX/XviD/3viX yet. This is Apple's fault?"
Yes it is. Nowadays MPEG-4 video (ie. "DivX/XviD/3viX") is one of the most important codecs out there. Yet Apple pretends it doesn't exist.
Indeed. That's actually how the Darwin CD is right now.
The nfo says "Hardware requirements: 133MHZ/128MB RAM/1GB HD". Riiiiight...
Does anyone know if the "Mac OS X Tiger X86 READNFO-XISO" torrent is the real thing?
Funny how it worked flawlessly under mplayer on my Linux box, yet I hear people here saying it required them to upgrade QT to v7. Makes you wonder if:
1) Apple does a shitty job at correctly supporting their own damn formats
OR
2) ffmpeg (the almighty decoding lib under mplayer's hood) comes from TEH FUTURE
That doesn't do anything to fix the lack of precision.