InformationWeek is speculating on how Linux will change in the next four years. "By 2012 the OS will have matured into three basic usage models. Web-based apps rule, virtualization is a breeze, and command-line hacking for basic system configuration is a thing of the past."
To read all comments associated with this story, please click here.
Member since:2008-07-15
Please tell me that your comment about a competitive audio architecture being made up of ALSA, JACK, and PulseAudio integration was sarcasm or a joke? Because, to put it bluntly, the Linux audio architecture is a complete mess of competing APIs and half-baked drivers. Pulse is the closest thing we've got in recent years to something decent on top of ALSA, but the fact that we needed something like Pulse should give anyone a clue about how bad the situation has gotten. Here are the main Linux audio APIs I know about, and I'm not counting intermediate libraries like libaudiofile:
* ALSA
* OSS
* Jack
* PulseAudio
That's four different APIS, count them. So, what happens when we put a few of them together? Here's an example situation, one that I've encountered several times. I'm using vmWare Workstation as the example product, but feel free to substitute.
* ALSA loads the basic audio subsystems, including your audio driver, and its OSS emulation layer
* If the audio card in question doesn't have hardware multi-channel support in ALSA, Dmix is brought into play for software mixing (this is yet another audio layer, though not really an API)
* If your distro has decided to use it, PulseAudio is then loaded, though in most distros ALSA isn't configured to use it for all sound output
So what happens now? We've got three ways for a program to output to the sound card: ALSA's native API, OSS, or PulseAudio. If they all played nice we'd be fine. Unfortunately, they don't:
* Programs that use PulseAudio play the nicest, since all PulseAudio settings are honored, including the audio device you've selected. PulseAudio handles software mixing itself and does a much better job of it than Dmix. No problems so far.
* Now, a program that uses ALSA's native API comes in. It honors none of your PulseAudio settings and, therefore, does not honor your volume nor your chosen Audio Device. A bit annoying, not a show-stopper yet.
* Now, throw an OSS application into the mix. Here's where the fun begins. OSS is handled by ALSA's OSS emulation. Problem is, the OSS emulation does not utilize Dmix at all. This means that if you're running an OSS application and don't have a full multi-channel card, the OSS application will control the sound card completely until it terminates. But, wait, we've got another problem: PulseAudio already has the sound device via Dmix. This means that the OSS application cannot utilize the audio device at all. This *is* a show-stopper to the average user, who just wants some freaking sound in all their apps.
Now, there are workarounds, usually utilizing a wrapper script and the LD_PRELOAD environment variable to substitute an emulation library into the application. This doesn't work in all cases, however, Vmware is one such application that doesn't like either the ALSA or PulseAudio emulation libraries, and RealPlayer can be downright iffy with the Pulse emulation libs though the ALSA ones seem to work fine. I can work around these audio issues.
But that's not what's going to matter in the long run. The average desktop user doesn't even know what a shared library is, let alone how to write a wrapper script utilizing a linker preload. For them, what they see (or rather hear) is that applications aren't consistent, and some may not work at all. They don't know what ALSA and OSS are, or why OSS applications don't play nice. And they don't care.
Personally, I'd like to see the audio stack slimmed down considerably. Have ALSA be the bare audio drivers. They initialize the audio cards, and let the system know what their capabilities are, and handle the final generation and/or capture of sound. Have PulseAudio handle the rest of the audio work, including mixing sounds, recording, and playing them, meaning the Applications go through Pulse to do these tasks, and ALSA only handles the lower level, card-specific bits as Pulse requests them. Let the native ALSA API go for general application development, and have an OSS emulation layer for PulseAudio that integrates seemlessly with other Pulse applications (since OSS works across various UNIX-like OS's it's not going to go away soon). As PulseAudio is relatively portable, all things considered, perhaps in time it would be adopted by other UNIX platforms. Even if not, though, this would considerably reduce the issues encountered all too often with audio in Linux. It'll never happen, of course, since it would require significant change, and it would certainly not be a one-person project or done quickly.
Member since:
2006-01-16
My predictions for Linux in 2012.
The kernel will have grown so mature that multiple janitor groups have formed, for security, portability and so on and now make up about half of the code changes. The OpenSolaris, FreeBSD, OpenBSD, NetBSD and DragonflyBSD kernels wont be far behind.
Linux will gain market share, and so will the other free *NIXes. As new users come to Linux thanks to Ubuntu and SUSE old user will migrate to less well know distributions or free *NIXes (because they are still cool). All of them together might finally scratch the 4% mark (I'm rather optimistic on this).
Linux and the other free *NIXes will all have their own specific VM/hypervisor infrastructure in kernel. XEN will evolve to a bare metal VM/hypervisor.
Linux and the other free *NIXes will start talking about a shared userspace driver model.
We will finally have a competitive sound architecture (alsa, jack and pulsaudio integration).
The desktop environment market will look a bit different. We will have KDE5, a port and direct continuation of the KDE4 work, just ported to QT5. We will have GNOME3, it will have made true on the on the promise of allowing different GNOME distributions to be build on its core. Because of this XFCE and ROX will chose to continue as GNOME distributions rather then totally independent DEs. GNUStep and Etoile will finally have reached beta and have started to attract and build a sustainable community. Enlightenment will have either grown into a DE with distributions similarly to what GNOME is planing or will have died.
We will see dozens of new command line shells pop up using new approaches (we are already seeing some of this) that try to make the command line a modern experience.
People will still say Linux and the other Free *NIXes will never be an important desktop even though they have already started using Linux and other Free *NIXes on embedded devices all over the place. Linux, Free *NIXes and UNIXes will still hold a very strong position in the server market. Maybe people will finally get it that UNIX isn't going to die.