Um, the technical work was already done. It could have shipped with Snow Leopard. Again, the reason it didn't has nothing to do with the technical feasibility of it.
Errrrrr, no. The technical work has not been done and was only just beginning. ZFS in OS X has always been an unstable beta project, and getting to a point where you can just about read and write from and to a filesystem means little. It's like saying that Ext2/3 is integrated into Windows because there is a driver that allows you to handle it. The filesystem has not been integrated into core services like Time Machine or within other services in OS X, and when you do that there are a ton of corner cases like performance to handle.
Booting a system with ZFS support and saying "OMG, it didn't fail it must be stable for everyday use!" is plain stupid.
Why? Because you say so?
Hmmmmm. So you've completely discredited yourself there then? The only way to deal with and recover from data corruption is to have a good copy somewhere else that can be manually or automatically brought in. That's what ZFS does, and Sun themselves say that you will risk data loss without redundancy. If you think ZFS magically handles everything to the point where redundancy isn't required then I'm afraid you've been drinking a lot of anti-freeze.
While I may be an idiot, you have to convince me that ZFS is not practical for a desktop. Again, just because you say so is not reason enough.
That's bizarre logic. Apple rejecting it is reason enough because they make desktops for a living. The memory and redundancy requirements (as I've mentioned clearly) are simply not practical at all on a thin Apple laptop. You aren't going to see Apple laptops with at least two disks to accomodate a filesystem who's major selling point is redundancy and data integrity. That's clear. Yes I'm afraid you are an idiot.
What exactly is this severe price? Can you spell it out? Exactly?
Memory requirements, redundancy requirements, checksumming overheads, RAID logic and code in a system that doesn't use RAID............ They all have to be factored in and tested in a lot of scenarios. I'm amused that you've been modded +5 informative with absolutely nothing informative to add yourself other than "I don't believe you".
How do you know? It's not a significant problem till the data you need is unavailable when you need it. At home my own modest media library sits on just 500 Gig...
So you're a fanboy with no knowledge whatsoever about storage other than the MP3s you've got sitting on some system somewhere - and someone somewhere thinks that you're informative? Give me a fucking break.
Yes you can checksum everything routinely and maintain a database of checksums to validate file change.
Checksumming will tell you that something went wrong, but without redundant copies of the data that can be brought in and the hardware to make that work then you've lost your data. If you don't know that then.........I don't want you around storage. Ever. Like I said - on systems with shitty device drivers then maybe you need this.
Do you enjoy explaining to an executive why the data they want is unavailable despite spending millions on enterprise class storage and backup solutions?
That's because it doesn't happen in those systems. Amazon store possibly more data in S3 than has been put on any ZFS system anywhere. ZFS might make the chores of storing that data a bit easier but it is no silver bullet in some magical pixie world where redundancy isn't required.
ZFS is the next generation file system that all others will have to live up to.
I'm sure it will, but I'm afraid that doesn't mean that made it practical for Apple to integrate into OS X or that it fitted the use cases they needed for many desktop scenarios. The FreeBSD people still haven't been able to run and integrate it reliably.
I use it on servers daily at work, and I was looking forward to having it on my Macs at home. Bit rot is a very real problem. ZFS handles it automagically.
The ZFS advocates trot those lines out every time and they're total nonsense. Ultimately, the only way to deal with silent data corruption or 'bit rot' is to have multiple levels of redundancy several times over for your data - which ZFS has and deals with. No desktop Mac can ever have that. Anyone who thinks that is anywhere near being practical to deal with on a desktop system is an idiot, and no, I'm afraid booting OpenSolaris with ZFS on your desktop system at home and not having it crash and burn does not even approach the kind of issues and corner cases that Apple's engineers will have to deal with, especially in a desktop system like OS X.
By no stretch of the imagination does ZFS handle this 'magically'. There is a severe price to be paid. If you don't have redudancy then you will simply risk losing your ZFS pool if there is corruption.
What handles failure at the data level? Nothing. Hope you make backups of your arrays.
I'm afraid that hardware, bad sector and disk issues are far, far more prevalent problems than data corruption at an OS level. Many apparent corruption issues at the OS level are usually down to hardware issues somewhere down the line. It might be a problem for operating systems with fairly shitty and poorly maintained disk and controller device drivers with a poor history on x86 and widely used hardware (hello Solaris!) but I'm afraid it's just not a primary concern for everyone else or for those developing desktop operating systems.
That doesn't make any sense. It only makes sense to engineer a new filesystem if the other options are inadequate or unusable.
It makes perfect sense. HPFS is simply far too long in the tooth now.
For them to seek to do that, they must have rejected the effort to integrate ZFS for some technical reason.
Yer................
The complexity of integrating ZFS pales into comparison to the massive cost of engineering and implementing a new filesystem from the ground up.
What's even more difficult is to integrate an existing filesystem into your OS that wasn't designed with your OS and your use cases in mind. It becomes virtually impossible to then change anything.
Spend ten minutes with the filesystem engineers at WWDC, and you wouldn't come away thinking there was any shortage of will to make ZFS fly on the Mac.
The proof of the pudding, as they say. By any stretch of the imagination ZFS within Mac OS is a project that has stagnated and gone completely stillborne from 10.5 and onwards. It's not something you could ever consider using semi-reliably, nor did you get the impression that it would ever reach that stage.
I'm sure there was no shortage of soundbites and excitement that someone was interested in Sun's pretty new baby, and Sun themselves gave overtures to that effect. That does not mean that it was ever going to work though.
The long and short of it was, Apple and Sun couldn't come to terms on the licensing. Sun wanted a lot of money...
That doesn't make any sense. I fail to see why Apple should agree licensing terms for a CDDL licensed open source project or how Sun could demand money for the privilege. Sun were positively overflowing with love towards Apple (as they usually are) when they heard that anyone would actually be interested in their uber new filesystem.
I doubt that it's a legal issue as the primary reason that this has happened, especially considering that the project seems to have stagnated steadily in successive versions of OS X. There just doesn't seem to have been the will within the OS X development group to make this work and to support and fully integrate ZFS into the inner workings of the OS. Given the pretty extensive functionality and plumbing of ZFS its probably been too much of a big ask to integrate a filesystem like that into a desktop. They might well have come to the conclusion that ZFS was simply complete overkill on a desktop and that it just wasn't possible.
However, they still desperately need a next generation filesystem and according to the linked article they're hiring filesystem engineers. I don't see any evidence that this was anything other than a technical avenue that they've explored that has fallen by the wayside as so many have before.
Interested parties (whose businesses rely and will expand with cheap or free bandwidth) are angling to use it as a means to get around current mobile operators, and it can't come a moment too soon in many ways as far as I'm concerned. However, I can only see this being a recipe for disaster given the state of many wireless devices and all their broken firmware updates today if it's accurate:
Devices must both consult an FCC-mandated database to determine which channels are available for use at a given location, and must also monitor the spectrum locally once every minute to confirm that no legacy wireless microphones, video assist devices or other emitters are present.
-msoft-float that should be. Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open/dev/dsp or something and simply pipe several outputs to it. It fits into the kernel philosophy of providing time-shared access to limited hardware and eliminates userspace complexity.
Large organizations that use SharePoint probably already have a large virtual machine farm, and would have used separate VMs in any case.
You're still talking about additional server licensing and administration.
People are definitely developing for SharePoint. Most development is oriented for enterprise use, however.
Which means that nobody is developing for it. Whenever you have a product that is only sold to enterprises rather than to the wider world it is very, very difficult for external developers to learn it and for software vendors to provide all the useful add-ons that really provide killer support for it and actually make it useful. It's just not used by everyone else enough. You're never going to get a meaningful startup using Sharepoint. Most CMS development ends up being terribly bespoke.
SharePoint has mindshare within large organizations.
Alas, there is nothing to support that. The wider world can't get access to Sharepoint so they're not coming into large organisations having already known about and learned Sharepoint. That's why companies like BEA found life pretty difficult, because there was a lot of people at college and university using PHP or something that just don't learn their stuff. The only way to make it work is to have a massive salesforce and make it expensive. They are at a massive competitive disadvantage.
Several years on, it's difficult to see how Sharepoint's position has changed.
Yay. Let's pick out and reference a random, meaningless scenario where there might not be a math co-processor. Bull. Somehow I doubt you're going to get smooth audio on there with Pulse's insane low latency CPU requirements.
I tried it and don't like it.
Good for you.
How can I connect my wireless headset to USB _and_ to my cell phone?
Yay. Let's pick out a random, obscure use case for Pulse and pretend that no other problems exist!
The majority would like our basic laptop/soundcard/speakers set up to work properly and reliably first on existing hardware with software mixing done as a matter of course that will actually make the kernel OSS -> ALSA interfaces work finally, and the pre-requisite for doing anything else is that this set up doesn't get more broken than it already is.
Software mixing is trivial to do in the kernel, and I know it was certainly looked at in the move to 2.6 for OSS -> ALSA compatibility. Your post touches none of the reasons why the kernel general avoids FPU, so it's generally meaningles twaddle that shouldn't be responded to. Rest assured that it is a matter of principal and not a technical matter. Linus Torvalds has even said in the past that FPU can be done if there are instances where it is useful, which is why -fno-fpu still isn't used as far as I'm aware.
Well, ALSA can be fixed. Pulseaudio works closely with the alsa devs to make them aware of their problems.
Not the same thing.
Why people just can't accept that Pulseaudio can work and does work for most people?
Because it doesn't. Saying that enough times won't make it true. Most of the supposed ALSA issues will probably never be fixed because they have come about as a result of PulseAudio pretending to be ALSA and trying to pretend to be ALSA compatible interfaces.
I mean, distros wouldn't have been able to push it if didn't worked for most of people.
Poor argument. Distros have long proved that they will package up anything with little thought to how the system functions as a whole.
Can't you guys get over it and admit that it's not because we are not "lucky" but because the whole thing does work?
If it was working then no one would be complaining. People quite clearly are complaining.
But...that's not at all what is happening. What is happening is exactly what you said. Where PA exposes kernel bugs, those bugs are being fixed.
No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA. That's where most of the bugs are coming up, and it's something that can never be practically fixed. Reimplementing yet another sound server to look like ALSA for backwards compatibility was always going to be a stupid thing to do.
He then *specifically* said that does _not_ mean they should not be fixed, or that he's not interested in fixing them. Yet you choose to draw that conclusion anyway...
I draw that conclusion because that's the net end result - the blaming of anything else apart from PulseAudio.
No, Windows and OS X do not have similar architectures so I wish people wouldn't repeat that bullshit. This by no definition is a sane architecture that has a hope of being reliable:
Sharepoint is a honking great pile of meaningless crap that just creates costs for everyone at every turn. The last I looked at it you *have* to run it as a default site, so that means you need yet another server and it's part of the panopoly of ridiculous deployment shite coming from the MSDN lunatics at the company that you can use to blow your foot off with. There is also a ton of confusion as to how it should actually be used, and considering that it is sold to enterprises pretty much exclusively then people scratching their heads over how to use it and what it is actually does is not good. What's worse is that people don't want to learn what it is for either. If someone feels they need a CMS or something then they will go out and get one.
Because it only seems to be sold to 'enterprises' that means that the wider world isn't using it at all and many software developers won't be writing for it either. As a result it has no mindshare whatsoever. I was always suspicious that there was any kind of real momentum behind it.
What specifically about PA's buffering scheme doesn't make sense? It provides for low latency (especially when the PA daemon itself runs with realtime priority); it saves power;
The problem with PA's low latency set up is that it consumes and inordinate amount of CPU. Lennart has admitted that. The problem with sound servers doing too much is that they will inevitably add latency. Paradox.
(Most) Audio drivers on Windows actually got fixed to make their change work, and don't be fooled - there's still a lot that's handled in the kernel. It's now standardised. What happened was that soundcards have got a lot simpler (and cheaper) to the point where drivers were replicating code to do the same simple things. Microsoft removed this and implemented sound processing that was previously in hardware or in several drivers between the kernel and userspace. They did that to reduce complexity and because they could do nothing with existing drivers. Unfortunately, that now means that many popular soundcards from several years ago simply don't and will not work with Vista or 7. Since Linux has soundcard driver source code available they don't need to take this approach to 'fix the mess'.
However and whatever, Microsoft found a way to not fuck sound up again by doing that and it doesn't mean that it's the correct approach for Linux.
Well, if the software calls on a driver, and the driver has a bug and crashes, then it's the fault of the driver. Therefore, fix the driver. Simple! Why is this so controversial?
Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.
No, I have not been "lucky". I had problems with Pulseaudio in the past. I had to unistall pulseaudio. But the problems are fixed now.
No. The problems are generally with the sorts of things that PulseAudio wants to do which shows up problems in ALSA. Either the low-level component in ALSA needs to be fixed universally, we start using OSS as a better solution with better hardware support or we stop trying to bludgeon yet another sound server with an apparently compatible ALSA interface into the middle of an existing problem that we haven't necessarily seen, but has made worse.
You have been lucky with your hardware and your set up.
Indeed. Long term maybe we can merge the libalsa functionality in pulseaudio and get rid of it. It would be far more clean. But that doesn't makes pulseaudio unnecesary.
libsydney is still vapourware as far as I'm aware, and the ALSA interfaces are still going to be the most well used interface because no one is going to rewrite for yet another sound interface whose furture is uncertain. It would have been a better idea to use ALSA or OSS, solve the problems there and then build off them.
Wrong, arts and esound were born largely to fix OSS....
Wrong. They were needed more than ever for ALSA and we then got people complaining that ALSA was worse to program for than OSS so we needed yet another wrapper so we could cover our ears. I'm afraid you're not proving anything because whereas OSS 3 (not OSS 4) was not ideal at all, ALSA, arts or esound did not make the problems any easier or solve existing problems - quite the opposite in fact. The brain damage continued.
I should...why? Pulseaudio works great here - no problems at all, no high CPU usage, nothing.
I'm pleased for you. You've been lucky. That doesn't mean that others don't have problems though and no, I'm afraid they're not a minority when you look at the forums of many distributions and the bug reports. I suspect many people just give up to be honest.
It's clear to anyone that has looked into this that most people are very happy with Pulseaudio.
If they were then we wouldn't get articles like this and Lennart wouldn't be as defensive as he is.
Linux would have far more problems going back to OSS4 (hey, why I can't set per-app volume, why audio over bluetooth doesn't works as I want?).
They can and do, and at least it wouldn't break existing sound use cases for many users and existing applications and break the one sound card with speakers plugged in standard set up in many cases. We already have OSS -> ALSA and ALSA -> OSS interfaces that have been around for some time. PulseAudio reimplementing ALSA to look like ALSA is just plain silly. There's no point in solving some problems if you break a ton of others that have been solved previously.
All the important distros ship it, and the users that have problems are clearly a _minority_, which is only getting smaller and smaller with each new version of Pulseaudio, Alsa and the kernel. And the geeks that fear changes and love to bitch about are running out of excuses.
Dream on. Sound servers of the type that we have found in the Linux desktop world over the years have been strewn with cow pats from the devil's own satanic herd and should have largely been consigned to the trash years ago. We've had arts and esound largely to cover up for ALSA, no one has been able to agree on any one sound server, there are always a ton of issues and it always takes years to solve those issues. Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in.
It will, if both your kernel and Pulseaudio are properly configured for low-latency desktop usage (realtime privileges, 1000hz timer, etc).
This is bullshit. No one should ever need to configure a sound system to get it to work on a basic set up and I'm sure that blaming distros or blaming kernels looks like the easy way out. No one needed to configure OSS, no one needed to configure ALSA and no one has needed to configure arts to get sound out of their speakers reliably on first start up. I've seen the mail where Lennart is blaming various Linux kernels for several hundred millisecond latencies and that is simply insane. Either he's lying or you've got a piece of software that is ridiculously sensitive and ultimately broken.
This includes making the ALSA drivers better at reporting which jacks are plugged in and things like that.
Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. We've had an unhappy history with sound servers in the Linux world and no one seems to have learned the lesson.
It's a lot cheaper to have a small handful of people on your tech staff and use specialized consultants on a project basis then it is to have a bloated IT department.
Sometimes, yer, but most companies your size have a bloated IT department AND a lot of consultants who eat money getting up to speed.
But hey you can criticize me all you want, the only opinion that counts to me is that of the people who sign my check and they're pretty pleased considering I got a 20% raise this year =)
I'm pleased for you, but in the context of this discussion you're in a minority. It's a case of dumb luck rather than judgement.
Slashdot Mirror
Errrrrr, no. The technical work has not been done and was only just beginning. ZFS in OS X has always been an unstable beta project, and getting to a point where you can just about read and write from and to a filesystem means little. It's like saying that Ext2/3 is integrated into Windows because there is a driver that allows you to handle it. The filesystem has not been integrated into core services like Time Machine or within other services in OS X, and when you do that there are a ton of corner cases like performance to handle.
Booting a system with ZFS support and saying "OMG, it didn't fail it must be stable for everyday use!" is plain stupid.
Hmmmmm. So you've completely discredited yourself there then? The only way to deal with and recover from data corruption is to have a good copy somewhere else that can be manually or automatically brought in. That's what ZFS does, and Sun themselves say that you will risk data loss without redundancy. If you think ZFS magically handles everything to the point where redundancy isn't required then I'm afraid you've been drinking a lot of anti-freeze.
That's bizarre logic. Apple rejecting it is reason enough because they make desktops for a living. The memory and redundancy requirements (as I've mentioned clearly) are simply not practical at all on a thin Apple laptop. You aren't going to see Apple laptops with at least two disks to accomodate a filesystem who's major selling point is redundancy and data integrity. That's clear. Yes I'm afraid you are an idiot.
Memory requirements, redundancy requirements, checksumming overheads, RAID logic and code in a system that doesn't use RAID............ They all have to be factored in and tested in a lot of scenarios. I'm amused that you've been modded +5 informative with absolutely nothing informative to add yourself other than "I don't believe you".
So you're a fanboy with no knowledge whatsoever about storage other than the MP3s you've got sitting on some system somewhere - and someone somewhere thinks that you're informative? Give me a fucking break.
Checksumming will tell you that something went wrong, but without redundant copies of the data that can be brought in and the hardware to make that work then you've lost your data. If you don't know that then.........I don't want you around storage. Ever. Like I said - on systems with shitty device drivers then maybe you need this.
That's because it doesn't happen in those systems. Amazon store possibly more data in S3 than has been put on any ZFS system anywhere. ZFS might make the chores of storing that data a bit easier but it is no silver bullet in some magical pixie world where redundancy isn't required.
I canot believe I replied to this shit.
???????!!!!! Far too late here now. That should of course be HFS(+).
I'm sure it will, but I'm afraid that doesn't mean that made it practical for Apple to integrate into OS X or that it fitted the use cases they needed for many desktop scenarios. The FreeBSD people still haven't been able to run and integrate it reliably.
The ZFS advocates trot those lines out every time and they're total nonsense. Ultimately, the only way to deal with silent data corruption or 'bit rot' is to have multiple levels of redundancy several times over for your data - which ZFS has and deals with. No desktop Mac can ever have that. Anyone who thinks that is anywhere near being practical to deal with on a desktop system is an idiot, and no, I'm afraid booting OpenSolaris with ZFS on your desktop system at home and not having it crash and burn does not even approach the kind of issues and corner cases that Apple's engineers will have to deal with, especially in a desktop system like OS X.
By no stretch of the imagination does ZFS handle this 'magically'. There is a severe price to be paid. If you don't have redudancy then you will simply risk losing your ZFS pool if there is corruption.
I'm afraid that hardware, bad sector and disk issues are far, far more prevalent problems than data corruption at an OS level. Many apparent corruption issues at the OS level are usually down to hardware issues somewhere down the line. It might be a problem for operating systems with fairly shitty and poorly maintained disk and controller device drivers with a poor history on x86 and widely used hardware (hello Solaris!) but I'm afraid it's just not a primary concern for everyone else or for those developing desktop operating systems.
It makes perfect sense. HPFS is simply far too long in the tooth now.
Yer................
What's even more difficult is to integrate an existing filesystem into your OS that wasn't designed with your OS and your use cases in mind. It becomes virtually impossible to then change anything.
The proof of the pudding, as they say. By any stretch of the imagination ZFS within Mac OS is a project that has stagnated and gone completely stillborne from 10.5 and onwards. It's not something you could ever consider using semi-reliably, nor did you get the impression that it would ever reach that stage.
I'm sure there was no shortage of soundbites and excitement that someone was interested in Sun's pretty new baby, and Sun themselves gave overtures to that effect. That does not mean that it was ever going to work though.
That doesn't make any sense. I fail to see why Apple should agree licensing terms for a CDDL licensed open source project or how Sun could demand money for the privilege. Sun were positively overflowing with love towards Apple (as they usually are) when they heard that anyone would actually be interested in their uber new filesystem.
I doubt that it's a legal issue as the primary reason that this has happened, especially considering that the project seems to have stagnated steadily in successive versions of OS X. There just doesn't seem to have been the will within the OS X development group to make this work and to support and fully integrate ZFS into the inner workings of the OS. Given the pretty extensive functionality and plumbing of ZFS its probably been too much of a big ask to integrate a filesystem like that into a desktop. They might well have come to the conclusion that ZFS was simply complete overkill on a desktop and that it just wasn't possible.
However, they still desperately need a next generation filesystem and according to the linked article they're hiring filesystem engineers. I don't see any evidence that this was anything other than a technical avenue that they've explored that has fallen by the wayside as so many have before.
-msoft-float that should be. Seriously, software mixing is a trivial algorithm and there's no reason why you shouldn't be able to open /dev/dsp or something and simply pipe several outputs to it. It fits into the kernel philosophy of providing time-shared access to limited hardware and eliminates userspace complexity.
You're still talking about additional server licensing and administration.
Which means that nobody is developing for it. Whenever you have a product that is only sold to enterprises rather than to the wider world it is very, very difficult for external developers to learn it and for software vendors to provide all the useful add-ons that really provide killer support for it and actually make it useful. It's just not used by everyone else enough. You're never going to get a meaningful startup using Sharepoint. Most CMS development ends up being terribly bespoke.
Alas, there is nothing to support that. The wider world can't get access to Sharepoint so they're not coming into large organisations having already known about and learned Sharepoint. That's why companies like BEA found life pretty difficult, because there was a lot of people at college and university using PHP or something that just don't learn their stuff. The only way to make it work is to have a massive salesforce and make it expensive. They are at a massive competitive disadvantage.
Several years on, it's difficult to see how Sharepoint's position has changed.
Yay. Let's pick out and reference a random, meaningless scenario where there might not be a math co-processor. Bull. Somehow I doubt you're going to get smooth audio on there with Pulse's insane low latency CPU requirements.
Good for you.
Yay. Let's pick out a random, obscure use case for Pulse and pretend that no other problems exist!
The majority would like our basic laptop/soundcard/speakers set up to work properly and reliably first on existing hardware with software mixing done as a matter of course that will actually make the kernel OSS -> ALSA interfaces work finally, and the pre-requisite for doing anything else is that this set up doesn't get more broken than it already is.
Software mixing is trivial to do in the kernel, and I know it was certainly looked at in the move to 2.6 for OSS -> ALSA compatibility. Your post touches none of the reasons why the kernel general avoids FPU, so it's generally meaningles twaddle that shouldn't be responded to. Rest assured that it is a matter of principal and not a technical matter. Linus Torvalds has even said in the past that FPU can be done if there are instances where it is useful, which is why -fno-fpu still isn't used as far as I'm aware.
The notion this cannot be done is total bullshit.
Not the same thing.
Because it doesn't. Saying that enough times won't make it true. Most of the supposed ALSA issues will probably never be fixed because they have come about as a result of PulseAudio pretending to be ALSA and trying to pretend to be ALSA compatible interfaces.
Poor argument. Distros have long proved that they will package up anything with little thought to how the system functions as a whole.
If it was working then no one would be complaining. People quite clearly are complaining.
No, they're not being fixed because it's extremely difficult to fix something in ALSA as a result of a piece of software (PA) that is pretending to be ALSA. That's where most of the bugs are coming up, and it's something that can never be practically fixed. Reimplementing yet another sound server to look like ALSA for backwards compatibility was always going to be a stupid thing to do.
I draw that conclusion because that's the net end result - the blaming of anything else apart from PulseAudio.
No, Windows and OS X do not have similar architectures so I wish people wouldn't repeat that bullshit. This by no definition is a sane architecture that has a hope of being reliable:
http://en.wikipedia.org/wiki/File:Pulseaudio-diagram.svg
Sharepoint is a honking great pile of meaningless crap that just creates costs for everyone at every turn. The last I looked at it you *have* to run it as a default site, so that means you need yet another server and it's part of the panopoly of ridiculous deployment shite coming from the MSDN lunatics at the company that you can use to blow your foot off with. There is also a ton of confusion as to how it should actually be used, and considering that it is sold to enterprises pretty much exclusively then people scratching their heads over how to use it and what it is actually does is not good. What's worse is that people don't want to learn what it is for either. If someone feels they need a CMS or something then they will go out and get one.
Because it only seems to be sold to 'enterprises' that means that the wider world isn't using it at all and many software developers won't be writing for it either. As a result it has no mindshare whatsoever. I was always suspicious that there was any kind of real momentum behind it.
The problem with PA's low latency set up is that it consumes and inordinate amount of CPU. Lennart has admitted that. The problem with sound servers doing too much is that they will inevitably add latency. Paradox.
(Most) Audio drivers on Windows actually got fixed to make their change work, and don't be fooled - there's still a lot that's handled in the kernel. It's now standardised. What happened was that soundcards have got a lot simpler (and cheaper) to the point where drivers were replicating code to do the same simple things. Microsoft removed this and implemented sound processing that was previously in hardware or in several drivers between the kernel and userspace. They did that to reduce complexity and because they could do nothing with existing drivers. Unfortunately, that now means that many popular soundcards from several years ago simply don't and will not work with Vista or 7. Since Linux has soundcard driver source code available they don't need to take this approach to 'fix the mess'.
However and whatever, Microsoft found a way to not fuck sound up again by doing that and it doesn't mean that it's the correct approach for Linux.
By making it even worse with an overly complex architecture that has no hope of being improved?
Because if the issue is really there then we need to be looking at solving it at that level and not bunging yet another in a long line of sound servers into the mix and making the problem even worse and then denying any responsibility.
No. The problems are generally with the sorts of things that PulseAudio wants to do which shows up problems in ALSA. Either the low-level component in ALSA needs to be fixed universally, we start using OSS as a better solution with better hardware support or we stop trying to bludgeon yet another sound server with an apparently compatible ALSA interface into the middle of an existing problem that we haven't necessarily seen, but has made worse.
You have been lucky with your hardware and your set up.
libsydney is still vapourware as far as I'm aware, and the ALSA interfaces are still going to be the most well used interface because no one is going to rewrite for yet another sound interface whose furture is uncertain. It would have been a better idea to use ALSA or OSS, solve the problems there and then build off them.
Wrong. They were needed more than ever for ALSA and we then got people complaining that ALSA was worse to program for than OSS so we needed yet another wrapper so we could cover our ears. I'm afraid you're not proving anything because whereas OSS 3 (not OSS 4) was not ideal at all, ALSA, arts or esound did not make the problems any easier or solve existing problems - quite the opposite in fact. The brain damage continued.
I'm pleased for you. You've been lucky. That doesn't mean that others don't have problems though and no, I'm afraid they're not a minority when you look at the forums of many distributions and the bug reports. I suspect many people just give up to be honest.
If they were then we wouldn't get articles like this and Lennart wouldn't be as defensive as he is.
They can and do, and at least it wouldn't break existing sound use cases for many users and existing applications and break the one sound card with speakers plugged in standard set up in many cases. We already have OSS -> ALSA and ALSA -> OSS interfaces that have been around for some time. PulseAudio reimplementing ALSA to look like ALSA is just plain silly. There's no point in solving some problems if you break a ton of others that have been solved previously.
Dream on. Sound servers of the type that we have found in the Linux desktop world over the years have been strewn with cow pats from the devil's own satanic herd and should have largely been consigned to the trash years ago. We've had arts and esound largely to cover up for ALSA, no one has been able to agree on any one sound server, there are always a ton of issues and it always takes years to solve those issues. Talking about each new version of the kernel and PulseAudio to fix issues now after all these years when sound and even ALSA for many people have started to work is laughable. History, and the Linux desktop world's inability to learn from the past, is against PulseAudio but Lennart seems determined to bludgeon it in.
This is bullshit. No one should ever need to configure a sound system to get it to work on a basic set up and I'm sure that blaming distros or blaming kernels looks like the easy way out. No one needed to configure OSS, no one needed to configure ALSA and no one has needed to configure arts to get sound out of their speakers reliably on first start up. I've seen the mail where Lennart is blaming various Linux kernels for several hundred millisecond latencies and that is simply insane. Either he's lying or you've got a piece of software that is ridiculously sensitive and ultimately broken.
Then fix ALSA or use OSS before you start retrofitting bullshit sound servers that breaks a lot of things. We've had an unhappy history with sound servers in the Linux world and no one seems to have learned the lesson.
That really is a damn unfortunate name for a company, or a subsidiary. I had to read the article carefully to confirm that wasn't a joke.
Sometimes, yer, but most companies your size have a bloated IT department AND a lot of consultants who eat money getting up to speed.
I'm pleased for you, but in the context of this discussion you're in a minority. It's a case of dumb luck rather than judgement.