Heh:-) I'd probably mod you funny if I hadn't already commented on this article.
To be fair, a benefit of Linux for some folks is "unix compatibility" yet when I started using Linux I wasn't exactly going "Yay, I really missed awk!".
I think there are some people who genuinely miss old BeOS apps, though. It's probably one of those niche platforms for which an awesome app gets written, never ported to other platforms, then lost.
From a quick skim of the beginning of that article it is not quite the same thing.
The BeOS filesystem is still hierarchical but IIRC it had superior metadata handling to most other systems and *applications used that* (in constrast to, say, extended attributes which seem to be neglected a bit by most apps). Moreover, the extended attributes seem to have been indexable and searchable.
That's still Free Software by the FSF's and most other people's definitions. What it is *not* is copy left. So yes, you can make non-free derivatives. But the rest of the world will still have the previous, open source releases available. You even have the freedom to create a GNU-focused Haiku release if you really wanted to - it might be worth it, just for the looks of horror at the idea of a GNU/BeOS (I'd use it!).
Don't worry, it's perfectly safe. With a modern OS the applications do not have a direct understanding of the CPU share they're receiving, or how much memory they really have. The OS basically provides them with a (rather abstract) virtual machine that has system calls instead of real hardware. CPU and memory can be taken away from a process at pretty much any time without it being any the wiser. This all requires hardware support but that support (unlike the support required for *full* virtual machines) has been in CPUs for decades now. We *did* get stuck with bad OSes that didn't make use of this for a while - but fortunately memory protection and pre-emptive multitasking are pretty much universal features now.
The tradeoff is that yoinking resources from applications over frequently will reduce the system's total throughput as you spend more time shuffling stuff about and less getting stuff done. The trick is to balance getting stuff done vs switching things about fast enough that everything gets to run and the user stays happy.
* It's a BeOS clone, some people miss BeOS as it was revolutionary at the time. * It has a somewhat different user interface to what you'll get in Ubuntu. Don't know if it's better (for you) but it is different. * The whole stack is developed and released together, so it's potentially integrated in a way that's harder to do with Linux (though obviously Linux has more people doing the interoperation and integration work). * It aims for binary compatibility with BeOS - run your old apps. * It's fast. I'd be surprised if it gave you the throughput of a Linux system but for desktop use BeOS was always very responsive. I don't know if Haiku is as good as BeOS in this respect but it boots *super* quick and even under full emulation it runs at a surprising speed. * AFAIK it's also quite lightweight compared to modern Linux running a contemporary DE. BeOS originally ran on really weedy hardware. Don't know if Haiku is *that* light but I do know that it has a fairly small resource footprint. * New, non-Linux kernel and OS - is this an advantage? Not necessarily but it sure is cool. It's a microkernel, too. * BeOS used the filesystem in very cool ways; it's powerful metadata support let you basically treat it like a database, reducing the amount of stuff you needed to do in specialised apps. * It still has some POSIX support so your favourite shell utilities probably ought to work.
Taken all together, once the wireless support is done and the OS stabilised a bit more, Haiku should be an extremely good fit for a netbook, amongst other things.
You're misinterpreting what I originally meant in a fairly extreme way. Did you look at the context I was commenting in?
To be fair, perhaps I could have phrased it better. When I said "products" I should probably have said "retail products" to disambiguate from stuff (like open source code) that they produce but don't market to consumers.
I used "surprising" in the sense that "It's unusual to see a company that has both extreme secrecy and enlightened openness". "Surprising" in general, then, as opposed to surprising for a fully informed observer. I wasn't surprised personally, since I've been following Apple's open source activity for years, including quite obscure stuff (for instance, I understand they sponsored some Linux work back in the day). However, the person I replied to *was* personally surprised - I was trying to explain that whilst I understood his surprise, it was not indicative of anything fishy.
If you reread my post, you'll see that I commented that Apple do open source quite a lot of infrastructure stuff and that I believe that maintaining those seemingly contradictory stances is an indication of strong management. I was replying to somebody who was suspicious of the motives of Apple in this - and pointing out that although it might look odd it's actually quite normal behaviour for them.
I was aiming to be evenhanded and was, after all, defending them against accusations of copyright infringement. If a defense of the company qualifies as anti-Apple, then I'd hate to meet an Apple hater!
It sort of feels like Microsoft's relations with OSS are "less negative" now, so I guess that's an improvement. It is, of course, possible that they've merely moved from denial to trying "embrace and extend". But due to the way OSS works I doubt that tactic will even work - in the end - if they try it.
I agree, Open Source games are awesome. Some may point to the fact that modern games cost enormous amounts of money and man hours to create. But:
a) small indie games are still popular, not everything has to be a blockbuste b) open source games have development advantages:
- can share advanced engines between multiple projects, with no licensing fees
- content development can be crowdsourced - wikipedia et al demonstrate that this can lead to high quality content creation, when done right
I like to read Freegamer (http://freegamer.blogspot.com/) to keep up with developments. The associated forums are also quite nice.
The Xbox makes me feel a bit conflicted about DRM. The reason being that (more or less as the original article is pointing out) some of the uses of DRM on Xbox live arcade seem a bit less evil than you'd expect! For instance, they offer me the convenience of renting movies from a moderately sized catalog, for non-ridiculous prices, without going to the video shop. That's quite nice and it's something that would seem a bit silly to offer without DRM (unless you just streamed it, in which case quality might suffer). Generally I'd say that if you need DRM to enforce your policy then your business model probably isn't right - and to a certain extent I think that applies to online movie rentals; if you're giving someone the data you can't really make them give them back, unlike a physical disk. But in this case the Xbox isn't trying to con me, it's upfront about the cost and the fact it's just a time-limited rental. I just don't feel offended by it, the way DRM on a purchase would bother me.
However, XBox Live does really worry me in other ways. For instance, they recently added the ability to buy full released games via download. This might be marginally more convenient than going to the game shop every few weeks to pick up a new title. However, you lose the ability to resell the games or lend them to people *and* you're not only asked to pay more than a second-hand copy of the games would be - the games I've looked at are charging more than I payed for a *new* copy. Admittedly I bought those games during a sale but I got a real physical disk that I can even lend to friends and resell. The prices they're charging are possibly fair in the sense of "I feel I got enough enjoyment in return for what I paid" but they're out of proportion to what I can get elsewhere. They're entitled to try this and see if it works but when I think about a future when the console vendors control all prices, sales and resales my knees get all wobbly and I have to go play Halo to relax.
The other things that bug me about Xbox live's DRM / pricing include the fact that MS points are sold in inconvenient multiples, making it easy to have some left over. And also the rumours I've seen recently that they pressure DLC providers to charge money, so as not to create the expectation of free stuff. That's a rip off.
At the end of the day, the Xbox has plenty of DRM and, like the author, I find some aspects of it not entirely intolerable. It still annoys me and I hope that some of their more greedy efforts to extend Xbox Live fail commercially. But it's less obnoxious doing it on an Xbox where I (personally, others may get a nasty surprise) knew what I was buying into, as opposed to pushing DRM on my PC which cost me more money and came with the expectation I could run what I wanted.
I think really we're debating over semantics at this point - my original post was trying to point out that whilst Apple is known for its secrecy and control it is pretty open on infrastructure stuff, where it makes sense for them.
All I meant by "surprising" was that it's unusual to see a company that's known for tight integration and control but which also has another greatly contrasting. I'm not personally surprised by Apple's behaviour since it's consistent with what I've seen from them in the past. But I can see why it would be surprising to someone who had only seen the more visible retail face of Apple.
Good point, that's actually a biggy and I shouldn't have missed that.
At one point one of the KDE devs pointed out that, contrary to most folk's expectations, interaction between KHTML wasn't happening because Apple were - at the time - complying with the letter of the license but not really providing patches in a useful form. The KDE guy was basically saying "No, really, we're still on our own with KHTML" to uninformed commenters, rather than necessarily saying Apple was being bad.
After that, Apple addressed these concerns and massively improved (AFAIK) their community interaction over WebKit. Pretty impressive in my view. Openness and responding effectively to criticism is not the kind of thing Apple is usually known for - but unlike some companies they do often seem to understand that OSS works better as a two way street, rather than just going "OMG free developers!".
Companies are indeed defined by what they do - the majority of what Apple does in the marketplace is provide tightly integrated "Just Works" experiences by maintaining a strong control over what they do. They also maintain intense secrecy on all their products. Do you dispute anything specific that I said?
At the end of the day *nothing* is really unexpected on some level since there are unseen laws and logic governing basically everything that happens. But if you see a trend in behaviour from somewhere (e.g. tight control and secrecy in most of Apple's most visible things) and then that trend is apparently violated, that qualifies as "surprising" in my opinion.
Well, I can see the logic of your concerns but Apple do actually seem to be fairly good at open sourcing infrastructure-related things. Sure they maintain a tight control on the user-facing stuff that makes Apple products distinctive - on the iPhone they even maintain a tight control on applications. But bear in mind they're working on an open source kernel, employ developers to work on the LLVM compiler (open source), open sourced an init-ish daemon (launchd) they developed, etc etc. On stuff that's "for geeks" they seem fairly enlightened wrt open source.
It's quite surprising from a company like Apple but the fact that they manage to make surprising decisions like that looks like a strong technical management team at work, to me.
Hmmmm, fair point. I always thought of Firewire as an interface that got used mostly by video professionals but I guess it makes sense if it was in video cameras in general.
OTOH, I'd guess that these days dedicated video cameras are orders of magnitude less common for amateur videoing than point and shoot digital cameras, so I guess it's still plausible not to have come across one. I see portable video cameras occasionally in the hands of others but I've never had one myself, nor recently known anyone who owns one.
The post I was referring to was the "What about networking over USB?". The confused post about whether the Firewire networking was new was at least understandable - having two stacks is a bit of an odd situation! (one that hopefully can now be resolved)
Hmmm. It sounds like the current OSS proxy daemon does send stuff on to PulseAudio, which does mean extra overheads. But PulseAudio could support the emulation directly via a plugin or something, in principle, so hopefully if the latency is a problem then it'll be fixed. Hopefully...
As a point of interest, Xen runs paravirtualised VMs at ring 1 on 32-bit x86. I think other VMMs may run guests (paravirtualised or not) in this way too. They can get away with doing this since virtualisation tends to be quite hardware-specific anyhow.
And then Linus might pass Andy Tannenbaum's programming classes;-) I like this stuff, they're combining some of the user / programmer benefits of a microkernel without a wholesale changeover. Everybody wins.
FWIW, I don't actually think Linux audio is as bad as my comment may have implied. But, like many of us, I've experience "teething troubles" of several different sound technologies, most recently PulseAudio. It seemed like too good an opportunity to miss.;-)
Argh, how was your comment modded troll? What is up with the mods today? It's a fair point - Firewire's niche is in professional kit like MiniDV cameras. Most people aren't using professional video kit, so these days it's quite likely you just won't see Firewire devices unless it's in your area of work. It's not like the original days of the iPod, where Firewire was required.
It's not going to replace things like Jack (and OSS4 if that's available to you) but I don't think it's trying to.
It's trying to replace those weird LD_PRELOAD wrappers you have to use to make OSS-only apps speak to ALSA / PulseAudio. CUSE should be used to remove the need for LD_PRELOAD wrappers, making it more robust and simpler to use legacy OSS apps that can't use ALSA or PulseAudio directly. Regardless of what you think about replacing OSS, the current situation is pretty much pessimal: tricking applications into talking to the sound daemon, except sometimes it doesn't work.
If you're in the situation - right or wrong - of having a sound daemon, there should at least be a well-supported way of routing the sound from all apps into it. FUSE is slow partly because of more context switches and data copying. The context switches and (potentially) data copying are already required when a userspace daemon provides OSS emulation, so I can't see that CUSE will make this situation worse.
AFAICS, using CUSE to provide OSS emulation is pretty much unambiguously better for those already using a userspace sound server. For those who aren't, it doesn't affect them any more than the previous wrapper-based techniques did.
Yes, that's true, I should have mentioned that. But you still can't plug a normal host controller into another, regardless of the software stack you're running. You need special hardware that most PCs won't have that implements the device end of the channel. I think that it's something of a shame that PCs don't include this hardware but I imagine it wouldn't be that useful, given they all include ethernet ports these days.
Agreed it's not ideal. Well, it should be more like Just Working as compared to the current situation, anyhow.
In the current situation, most people have a weirdass sound daemon of some flavour and a load of OSS legacy apps that won't talk to it, necessitating an ugly hack to trick them into talking to the daemon. Using CUSE shouldn't add latency if done right (you still have to context switch to the sound daemon, copy some data, do some stuff, then call down into ALSA) and ought to improve the user experience for those apps. Other apps already talk to the sound server directly.
Eliminating the sound server might be nice, though it probably depends who you ask - some are convinced that having it in userspace ought to work fine. My main objection to sound daemons hasn't been that they add latency it's that oftentimes they seem to just not work *at all* in some crucial way:-( When they're working properly the latency doesn't bother me so much, it's just that still feels like a rare situation (on some distros, anyhow).
Actually, it probably depends on your point of view. "Daemon" usually refers to a userspace process but OTOH, try the following:
ps -A | grep k.*d
Aside from (potentially) some kde processes you'll probably see a load of kernel threads for various things, e.g. kjournald. I believe the d there stands for "daemon" and is being used merely in the sense of "a process or thread that runs in the background and Does Stuff"
Slashdot Mirror
Heh :-) I'd probably mod you funny if I hadn't already commented on this article.
To be fair, a benefit of Linux for some folks is "unix compatibility" yet when I started using Linux I wasn't exactly going "Yay, I really missed awk!".
I think there are some people who genuinely miss old BeOS apps, though. It's probably one of those niche platforms for which an awesome app gets written, never ported to other platforms, then lost.
From a quick skim of the beginning of that article it is not quite the same thing.
The BeOS filesystem is still hierarchical but IIRC it had superior metadata handling to most other systems and *applications used that* (in constrast to, say, extended attributes which seem to be neglected a bit by most apps). Moreover, the extended attributes seem to have been indexable and searchable.
Take a look at this for instance:
http://www.birdhouse.org/beos/byte/24-scripting_the_bfs/
This sort of stuff enabled BeOS to push stuff into the OS / filesystem that would normally be handled in an application-specific way.
Don't know how much of this Haiku supports - if they do support it already, that would be awesome!
That's still Free Software by the FSF's and most other people's definitions. What it is *not* is copy left. So yes, you can make non-free derivatives. But the rest of the world will still have the previous, open source releases available. You even have the freedom to create a GNU-focused Haiku release if you really wanted to - it might be worth it, just for the looks of horror at the idea of a GNU/BeOS (I'd use it!).
Don't worry, it's perfectly safe. With a modern OS the applications do not have a direct understanding of the CPU share they're receiving, or how much memory they really have. The OS basically provides them with a (rather abstract) virtual machine that has system calls instead of real hardware. CPU and memory can be taken away from a process at pretty much any time without it being any the wiser. This all requires hardware support but that support (unlike the support required for *full* virtual machines) has been in CPUs for decades now. We *did* get stuck with bad OSes that didn't make use of this for a while - but fortunately memory protection and pre-emptive multitasking are pretty much universal features now.
The tradeoff is that yoinking resources from applications over frequently will reduce the system's total throughput as you spend more time shuffling stuff about and less getting stuff done. The trick is to balance getting stuff done vs switching things about fast enough that everything gets to run and the user stays happy.
A few thoughts off the top of my head:
* It's a BeOS clone, some people miss BeOS as it was revolutionary at the time.
* It has a somewhat different user interface to what you'll get in Ubuntu. Don't know if it's better (for you) but it is different.
* The whole stack is developed and released together, so it's potentially integrated in a way that's harder to do with Linux (though obviously Linux has more people doing the interoperation and integration work).
* It aims for binary compatibility with BeOS - run your old apps.
* It's fast. I'd be surprised if it gave you the throughput of a Linux system but for desktop use BeOS was always very responsive. I don't know if Haiku is as good as BeOS in this respect but it boots *super* quick and even under full emulation it runs at a surprising speed.
* AFAIK it's also quite lightweight compared to modern Linux running a contemporary DE. BeOS originally ran on really weedy hardware. Don't know if Haiku is *that* light but I do know that it has a fairly small resource footprint.
* New, non-Linux kernel and OS - is this an advantage? Not necessarily but it sure is cool. It's a microkernel, too.
* BeOS used the filesystem in very cool ways; it's powerful metadata support let you basically treat it like a database, reducing the amount of stuff you needed to do in specialised apps.
* It still has some POSIX support so your favourite shell utilities probably ought to work.
Taken all together, once the wireless support is done and the OS stabilised a bit more, Haiku should be an extremely good fit for a netbook, amongst other things.
You're misinterpreting what I originally meant in a fairly extreme way. Did you look at the context I was commenting in?
To be fair, perhaps I could have phrased it better. When I said "products" I should probably have said "retail products" to disambiguate from stuff (like open source code) that they produce but don't market to consumers.
I used "surprising" in the sense that "It's unusual to see a company that has both extreme secrecy and enlightened openness". "Surprising" in general, then, as opposed to surprising for a fully informed observer. I wasn't surprised personally, since I've been following Apple's open source activity for years, including quite obscure stuff (for instance, I understand they sponsored some Linux work back in the day). However, the person I replied to *was* personally surprised - I was trying to explain that whilst I understood his surprise, it was not indicative of anything fishy.
If you reread my post, you'll see that I commented that Apple do open source quite a lot of infrastructure stuff and that I believe that maintaining those seemingly contradictory stances is an indication of strong management. I was replying to somebody who was suspicious of the motives of Apple in this - and pointing out that although it might look odd it's actually quite normal behaviour for them.
I was aiming to be evenhanded and was, after all, defending them against accusations of copyright infringement. If a defense of the company qualifies as anti-Apple, then I'd hate to meet an Apple hater!
It sort of feels like Microsoft's relations with OSS are "less negative" now, so I guess that's an improvement. It is, of course, possible that they've merely moved from denial to trying "embrace and extend". But due to the way OSS works I doubt that tactic will even work - in the end - if they try it.
I agree, Open Source games are awesome. Some may point to the fact that modern games cost enormous amounts of money and man hours to create. But:
a) small indie games are still popular, not everything has to be a blockbuste
b) open source games have development advantages:
- can share advanced engines between multiple projects, with no licensing fees
- content development can be crowdsourced - wikipedia et al demonstrate that this can lead to high quality content creation, when done right
I like to read Freegamer (http://freegamer.blogspot.com/) to keep up with developments. The associated forums are also quite nice.
The Xbox makes me feel a bit conflicted about DRM. The reason being that (more or less as the original article is pointing out) some of the uses of DRM on Xbox live arcade seem a bit less evil than you'd expect! For instance, they offer me the convenience of renting movies from a moderately sized catalog, for non-ridiculous prices, without going to the video shop. That's quite nice and it's something that would seem a bit silly to offer without DRM (unless you just streamed it, in which case quality might suffer). Generally I'd say that if you need DRM to enforce your policy then your business model probably isn't right - and to a certain extent I think that applies to online movie rentals; if you're giving someone the data you can't really make them give them back, unlike a physical disk. But in this case the Xbox isn't trying to con me, it's upfront about the cost and the fact it's just a time-limited rental. I just don't feel offended by it, the way DRM on a purchase would bother me.
However, XBox Live does really worry me in other ways. For instance, they recently added the ability to buy full released games via download. This might be marginally more convenient than going to the game shop every few weeks to pick up a new title. However, you lose the ability to resell the games or lend them to people *and* you're not only asked to pay more than a second-hand copy of the games would be - the games I've looked at are charging more than I payed for a *new* copy. Admittedly I bought those games during a sale but I got a real physical disk that I can even lend to friends and resell. The prices they're charging are possibly fair in the sense of "I feel I got enough enjoyment in return for what I paid" but they're out of proportion to what I can get elsewhere. They're entitled to try this and see if it works but when I think about a future when the console vendors control all prices, sales and resales my knees get all wobbly and I have to go play Halo to relax.
The other things that bug me about Xbox live's DRM / pricing include the fact that MS points are sold in inconvenient multiples, making it easy to have some left over. And also the rumours I've seen recently that they pressure DLC providers to charge money, so as not to create the expectation of free stuff. That's a rip off.
At the end of the day, the Xbox has plenty of DRM and, like the author, I find some aspects of it not entirely intolerable. It still annoys me and I hope that some of their more greedy efforts to extend Xbox Live fail commercially. But it's less obnoxious doing it on an Xbox where I (personally, others may get a nasty surprise) knew what I was buying into, as opposed to pushing DRM on my PC which cost me more money and came with the expectation I could run what I wanted.
I think really we're debating over semantics at this point - my original post was trying to point out that whilst Apple is known for its secrecy and control it is pretty open on infrastructure stuff, where it makes sense for them.
All I meant by "surprising" was that it's unusual to see a company that's known for tight integration and control but which also has another greatly contrasting. I'm not personally surprised by Apple's behaviour since it's consistent with what I've seen from them in the past. But I can see why it would be surprising to someone who had only seen the more visible retail face of Apple.
Good point, that's actually a biggy and I shouldn't have missed that.
At one point one of the KDE devs pointed out that, contrary to most folk's expectations, interaction between KHTML wasn't happening because Apple were - at the time - complying with the letter of the license but not really providing patches in a useful form. The KDE guy was basically saying "No, really, we're still on our own with KHTML" to uninformed commenters, rather than necessarily saying Apple was being bad.
After that, Apple addressed these concerns and massively improved (AFAIK) their community interaction over WebKit. Pretty impressive in my view. Openness and responding effectively to criticism is not the kind of thing Apple is usually known for - but unlike some companies they do often seem to understand that OSS works better as a two way street, rather than just going "OMG free developers!".
Companies are indeed defined by what they do - the majority of what Apple does in the marketplace is provide tightly integrated "Just Works" experiences by maintaining a strong control over what they do. They also maintain intense secrecy on all their products. Do you dispute anything specific that I said?
At the end of the day *nothing* is really unexpected on some level since there are unseen laws and logic governing basically everything that happens. But if you see a trend in behaviour from somewhere (e.g. tight control and secrecy in most of Apple's most visible things) and then that trend is apparently violated, that qualifies as "surprising" in my opinion.
Well, I can see the logic of your concerns but Apple do actually seem to be fairly good at open sourcing infrastructure-related things. Sure they maintain a tight control on the user-facing stuff that makes Apple products distinctive - on the iPhone they even maintain a tight control on applications. But bear in mind they're working on an open source kernel, employ developers to work on the LLVM compiler (open source), open sourced an init-ish daemon (launchd) they developed, etc etc. On stuff that's "for geeks" they seem fairly enlightened wrt open source.
It's quite surprising from a company like Apple but the fact that they manage to make surprising decisions like that looks like a strong technical management team at work, to me.
Just so you know, it's very unlikely the parent is safe viewing for your particular workplace ;-)
Hmmmm, fair point. I always thought of Firewire as an interface that got used mostly by video professionals but I guess it makes sense if it was in video cameras in general.
OTOH, I'd guess that these days dedicated video cameras are orders of magnitude less common for amateur videoing than point and shoot digital cameras, so I guess it's still plausible not to have come across one. I see portable video cameras occasionally in the hands of others but I've never had one myself, nor recently known anyone who owns one.
The post I was referring to was the "What about networking over USB?". The confused post about whether the Firewire networking was new was at least understandable - having two stacks is a bit of an odd situation! (one that hopefully can now be resolved)
Hmmm. It sounds like the current OSS proxy daemon does send stuff on to PulseAudio, which does mean extra overheads. But PulseAudio could support the emulation directly via a plugin or something, in principle, so hopefully if the latency is a problem then it'll be fixed. Hopefully ...
As a point of interest, Xen runs paravirtualised VMs at ring 1 on 32-bit x86. I think other VMMs may run guests (paravirtualised or not) in this way too. They can get away with doing this since virtualisation tends to be quite hardware-specific anyhow.
And then Linus might pass Andy Tannenbaum's programming classes ;-) I like this stuff, they're combining some of the user / programmer benefits of a microkernel without a wholesale changeover. Everybody wins.
FWIW, I don't actually think Linux audio is as bad as my comment may have implied. But, like many of us, I've experience "teething troubles" of several different sound technologies, most recently PulseAudio. It seemed like too good an opportunity to miss. ;-)
Argh, how was your comment modded troll? What is up with the mods today? It's a fair point - Firewire's niche is in professional kit like MiniDV cameras. Most people aren't using professional video kit, so these days it's quite likely you just won't see Firewire devices unless it's in your area of work. It's not like the original days of the iPod, where Firewire was required.
It's not going to replace things like Jack (and OSS4 if that's available to you) but I don't think it's trying to.
It's trying to replace those weird LD_PRELOAD wrappers you have to use to make OSS-only apps speak to ALSA / PulseAudio. CUSE should be used to remove the need for LD_PRELOAD wrappers, making it more robust and simpler to use legacy OSS apps that can't use ALSA or PulseAudio directly. Regardless of what you think about replacing OSS, the current situation is pretty much pessimal: tricking applications into talking to the sound daemon, except sometimes it doesn't work.
If you're in the situation - right or wrong - of having a sound daemon, there should at least be a well-supported way of routing the sound from all apps into it. FUSE is slow partly because of more context switches and data copying. The context switches and (potentially) data copying are already required when a userspace daemon provides OSS emulation, so I can't see that CUSE will make this situation worse.
AFAICS, using CUSE to provide OSS emulation is pretty much unambiguously better for those already using a userspace sound server. For those who aren't, it doesn't affect them any more than the previous wrapper-based techniques did.
Yes, that's true, I should have mentioned that. But you still can't plug a normal host controller into another, regardless of the software stack you're running. You need special hardware that most PCs won't have that implements the device end of the channel. I think that it's something of a shame that PCs don't include this hardware but I imagine it wouldn't be that useful, given they all include ethernet ports these days.
Agreed it's not ideal. Well, it should be more like Just Working as compared to the current situation, anyhow.
In the current situation, most people have a weirdass sound daemon of some flavour and a load of OSS legacy apps that won't talk to it, necessitating an ugly hack to trick them into talking to the daemon. Using CUSE shouldn't add latency if done right (you still have to context switch to the sound daemon, copy some data, do some stuff, then call down into ALSA) and ought to improve the user experience for those apps. Other apps already talk to the sound server directly.
Eliminating the sound server might be nice, though it probably depends who you ask - some are convinced that having it in userspace ought to work fine. My main objection to sound daemons hasn't been that they add latency it's that oftentimes they seem to just not work *at all* in some crucial way :-( When they're working properly the latency doesn't bother me so much, it's just that still feels like a rare situation (on some distros, anyhow).
Actually, it probably depends on your point of view. "Daemon" usually refers to a userspace process but OTOH, try the following:
ps -A | grep k.*d
Aside from (potentially) some kde processes you'll probably see a load of kernel threads for various things, e.g. kjournald. I believe the d there stands for "daemon" and is being used merely in the sense of "a process or thread that runs in the background and Does Stuff"