6 ms·

The X11 protocol was standardized in 1987. Any X application which worked then would work now. There are extensions and new capabilities being added, but every

The X11 protocol was standardized in 1987. Any X application which worked then would work now. There are extensions and new capabilities being added, but every one is backwards-compatible. Ditto with audio APIs -- the last major change was the changeover from OSS to ALSA, in 2002, and to this day there's an OSS compatibility layer. I've used Linux since early 2001, and in all that time I've never encountered an incompatibility with libc. The filesystem semantics issue is due to idiot application developers trying to squeeze out a few msec of performance, at the risk of their user's data. The issue exists on every modern filesystem, no matter which OS is used. Anybody who relies on POSIX -- ie, uses fsync() -- doesn't have to worry about that problem.

blasdel 17y ago
The reason application developers haven't been using fsync() is because it's ridiculously slow on ext.
modeless 17y ago
Yes, X11 is backwards compatible and that's been really great for the Linux desktop. But the article bashes Windows for rapidly introducing new APIs even though the old ones remain compatible; I'm just pointing out that Linux does that too. As for the audio situation, the problem is sharing between multiple apps. ALSA sucks at it so "sound servers" were invented but they caused more problems than they solved. Now it seems like every distro has a different sound solution, and meanwhile OSS was never removed from the kernel so you can't even rely on ALSA always being there. The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO the problem really lies in POSIX which doesn't specify a way to achieve what app developers need in a way that can also be easily implemented in the kernel with good performance. I would argue that the behaviors app developers were using became a de facto part of POSIX and the way kernel devs broke them was irresponsible even if it didn't break the letter of the standard. Contrast with Microsoft which goes far, far out of its way to avoid breaking apps even when they flagrantly violate good practices (there are some great examples on The Old New Thing: http://blogs.msdn.com/oldnewthing/ http://blogs.msdn.com/oldnewthing/ ).
- jmillikin 17y ago
  Yes, X11 is backwards compatible and that's been really great for the Linux desktop. But the article bashes Windows for rapidly introducing new APIs even though the old ones remain compatible; I'm just pointing out that Linux does that too. Linux's graphics APIs have remained largely static: they are GTK+ and Qt. Nobody writes their own implementations of X11. Your audio paragraph is completely divorced from reality. Sound servers were originally created to implement software mixing, which is not supported by OSS. When ALSA was imported into the mainline kernel, software mixing became possible without servers and they largely died out. Now, ALSA is the dominant standard for Linux audio. Recently, the sound server PulseAudio was created, but apps use it through the standard ALSA API. To my knowledge, there is no distribution using a sound server other than Pulse. You can't rely on sound being enabled, true. But every mainline distribution ships with sound enabled, and that means they support ALSA. If a user disables their sound subsystem and then complains they can no longer hear music, that's their problem. The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO the problem really lies in POSIX which doesn't specify a way to achieve what app developers need in a way that can also be easily implemented in the kernel with good performance. Sure it does -- fsync(). To my knowledge, the only filesystem which has poor performance when using fsync() is ext3 in data=ordered mode (which is not the default).
  - modeless 17y ago
    When ALSA was imported into the mainline kernel, software mixing became possible without servers and they largely died out. My experience was completely different. A few years ago, ALSA software mixing was not enabled by default and didn't work well when enabled. When not enabled, apps couldn't share the audio device at all. KDE created aRts to allow sharing at the app level, but aRts sucked, plus it hogged the audio device so non-aRts apps wouldn't work at all. Later aRts added a timeout after which it would release the device but this obviously wasn't a good solution. Gnome had ESD which I didn't use but it conflicted with aRts. JACK came along but was only ever used by high-end audio programs. ALSA finally did get decent software mixing support, but now people are used to running sound servers. PulseAudio is the newest thing but last I heard a lot of people are still unsatisfied with it (e.g. http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solution-in-search-of.html http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solut... ). Furthermore, people who know what they're talking about are recommending a move away from PulseAudio and ALSA and back toward OSS! Personally, I think the case is quite convincing: http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html http://insanecoding.blogspot.com/2009/06/state-of-sound-in-l... To my knowledge, the only filesystem which has poor performance when using fsync() is ext3 in data=ordered mode (which is not the default). Not according to http://lwn.net/Articles/351422/ http://lwn.net/Articles/351422/
SwellJoe 17y ago
Ditto with audio APIs -- the last major change was the changeover from OSS to ALSA, in 2002, and to this day there's an OSS compatibility layer. ALSA, as an API for building modern audio applications, is useless. Yes, literally, useless. I have tried for over ten years to move my home studio recording to Linux-based tools...but, to this day, reliable, glitch-free, low-latency, multi-track 24 bit 96kHz audio from multiple applications and external sources is simply not possible under Linux (without dedicating a machine to the task, which I've never been willing to do, and which I don't have to do under Windows or Mac OS X). First up, audio requires an rt kernel. The rt kernels trail behind the mainline kernel by several revisions, and usually include a few major security or stability issues. The latency of a non-rt kernel is such that even with extremely large buffers, audio still stutters. You also need a sound server to permit multiple apps to share and route sound amongst other apps. The competing and barely compatible sound servers for Linux are targeted to different audiences, and generally don't do a very good job even for their specific niche. JACK is the professionals choice, but in my experience, it's never been stable enough to be usable for any real work. PulseAudio is laughably unreliable...it consistently fails when returning from sleep on my desktop, and makes weird popping noises after playing sounds on my laptop. It never worked at all on my mid-range audio devices (Delta 66 on the desktop and FireWire Focusrite Saffire LE on the lappy), as it seems to just freak out when there are multiple devices (to be fair, Vista also freaks out a bit when changing sound devices and using both for various tasks; I've been able to find a delicate balance that allows Flash and movies and such to play through the built-in audio and audio software to use the good devices). Anyway, I use, and have used, Linux as my primary operating system for all of my machines for over ten years for everything except audio. I try to make the switch at least once a year, and I've failed every single time because of failures of both the kernel and the audio APIs on Linux. I'm not a neophyte at this stuff, either. I've written and maintained patches for the Linux kernel over the years, I'm not nervous about any of the required steps to make things work, it's just that when all is said and done, the system is either not capable of working with high quality audio at all (non-rt kernel, normal desktop PulseAudio configuration), but usable as a desktop system for normal work...or it's configured exactly right for pro audio (rt kernel, jackd, etc.), and sort of works for a few minutes or hours at a time, but is otherwise useless as a desktop system because 3D video drivers are too flaky in this configuration, kernel has stability or security issues, and normal software (like Firefox+Flash) can't talk to the jackd server and can't get access to the audio device because jack is holding it. Music software that does happen to support Linux (Renoise, for an example of one of my favorite tools), there is confusion among the developers about what they should be doing to provide good support to Linux users...which of the several sound servers is the "right" one? It depends on who you ask. So, while I spend 90% of my day running Linux, when I want to record music, I have to reboot into Windows.

blasdel 17y ago

The reason application developers haven't been using fsync() is because it's ridiculously slow on ext.

modeless 17y ago

Yes, X11 is backwards compatible and that's been really great for the Linux desktop. But the article bashes Windows for rapidly introducing new APIs even though the old ones remain compatible; I'm just pointing out that Linux does that too. As for the audio situation, the problem is sharing between multiple apps. ALSA sucks at it so "sound servers" were invented but they caused more problems than they solved. Now it seems like every distro has a different sound solution, and meanwhile OSS was never removed from the kernel so you can't even rely on ALSA always being there. The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO the problem really lies in POSIX which doesn't specify a way to achieve what app developers need in a way that can also be easily implemented in the kernel with good performance. I would argue that the behaviors app developers were using became a de facto part of POSIX and the way kernel devs broke them was irresponsible even if it didn't break the letter of the standard. Contrast with Microsoft which goes far, far out of its way to avoid breaking apps even when they flagrantly violate good practices (there are some great examples on The Old New Thing: http://blogs.msdn.com/oldnewthing/ http://blogs.msdn.com/oldnewthing/ ).

jmillikin 17y ago
Yes, X11 is backwards compatible and that's been really great for the Linux desktop. But the article bashes Windows for rapidly introducing new APIs even though the old ones remain compatible; I'm just pointing out that Linux does that too. Linux's graphics APIs have remained largely static: they are GTK+ and Qt. Nobody writes their own implementations of X11. Your audio paragraph is completely divorced from reality. Sound servers were originally created to implement software mixing, which is not supported by OSS. When ALSA was imported into the mainline kernel, software mixing became possible without servers and they largely died out. Now, ALSA is the dominant standard for Linux audio. Recently, the sound server PulseAudio was created, but apps use it through the standard ALSA API. To my knowledge, there is no distribution using a sound server other than Pulse. You can't rely on sound being enabled, true. But every mainline distribution ships with sound enabled, and that means they support ALSA. If a user disables their sound subsystem and then complains they can no longer hear music, that's their problem. The filesystem problem can't be blamed wholly on apps or kernel devs; IMHO the problem really lies in POSIX which doesn't specify a way to achieve what app developers need in a way that can also be easily implemented in the kernel with good performance. Sure it does -- fsync(). To my knowledge, the only filesystem which has poor performance when using fsync() is ext3 in data=ordered mode (which is not the default).
- modeless 17y ago
  When ALSA was imported into the mainline kernel, software mixing became possible without servers and they largely died out. My experience was completely different. A few years ago, ALSA software mixing was not enabled by default and didn't work well when enabled. When not enabled, apps couldn't share the audio device at all. KDE created aRts to allow sharing at the app level, but aRts sucked, plus it hogged the audio device so non-aRts apps wouldn't work at all. Later aRts added a timeout after which it would release the device but this obviously wasn't a good solution. Gnome had ESD which I didn't use but it conflicted with aRts. JACK came along but was only ever used by high-end audio programs. ALSA finally did get decent software mixing support, but now people are used to running sound servers. PulseAudio is the newest thing but last I heard a lot of people are still unsatisfied with it (e.g. http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solution-in-search-of.html http://jeffreystedfast.blogspot.com/2008/06/pulseaudio-solut... ). Furthermore, people who know what they're talking about are recommending a move away from PulseAudio and ALSA and back toward OSS! Personally, I think the case is quite convincing: http://insanecoding.blogspot.com/2009/06/state-of-sound-in-linux-not-so-sorry.html http://insanecoding.blogspot.com/2009/06/state-of-sound-in-l... To my knowledge, the only filesystem which has poor performance when using fsync() is ext3 in data=ordered mode (which is not the default). Not according to http://lwn.net/Articles/351422/ http://lwn.net/Articles/351422/

SwellJoe 17y ago

Ditto with audio APIs -- the last major change was the changeover from OSS to ALSA, in 2002, and to this day there's an OSS compatibility layer. ALSA, as an API for building modern audio applications, is useless. Yes, literally, useless. I have tried for over ten years to move my home studio recording to Linux-based tools...but, to this day, reliable, glitch-free, low-latency, multi-track 24 bit 96kHz audio from multiple applications and external sources is simply not possible under Linux (without dedicating a machine to the task, which I've never been willing to do, and which I don't have to do under Windows or Mac OS X). First up, audio requires an rt kernel. The rt kernels trail behind the mainline kernel by several revisions, and usually include a few major security or stability issues. The latency of a non-rt kernel is such that even with extremely large buffers, audio still stutters. You also need a sound server to permit multiple apps to share and route sound amongst other apps. The competing and barely compatible sound servers for Linux are targeted to different audiences, and generally don't do a very good job even for their specific niche. JACK is the professionals choice, but in my experience, it's never been stable enough to be usable for any real work. PulseAudio is laughably unreliable...it consistently fails when returning from sleep on my desktop, and makes weird popping noises after playing sounds on my laptop. It never worked at all on my mid-range audio devices (Delta 66 on the desktop and FireWire Focusrite Saffire LE on the lappy), as it seems to just freak out when there are multiple devices (to be fair, Vista also freaks out a bit when changing sound devices and using both for various tasks; I've been able to find a delicate balance that allows Flash and movies and such to play through the built-in audio and audio software to use the good devices). Anyway, I use, and have used, Linux as my primary operating system for all of my machines for over ten years for everything except audio. I try to make the switch at least once a year, and I've failed every single time because of failures of both the kernel and the audio APIs on Linux. I'm not a neophyte at this stuff, either. I've written and maintained patches for the Linux kernel over the years, I'm not nervous about any of the required steps to make things work, it's just that when all is said and done, the system is either not capable of working with high quality audio at all (non-rt kernel, normal desktop PulseAudio configuration), but usable as a desktop system for normal work...or it's configured exactly right for pro audio (rt kernel, jackd, etc.), and sort of works for a few minutes or hours at a time, but is otherwise useless as a desktop system because 3D video drivers are too flaky in this configuration, kernel has stability or security issues, and normal software (like Firefox+Flash) can't talk to the jackd server and can't get access to the audio device because jack is holding it. Music software that does happen to support Linux (Renoise, for an example of one of my favorite tools), there is confusion among the developers about what they should be doing to provide good support to Linux users...which of the several sound servers is the "right" one? It depends on who you ask. So, while I spend 90% of my day running Linux, when I want to record music, I have to reboot into Windows.