Unfortunately, Eclipse still tends to choke on C++ code a lot in my experience. I'm not writing particularly devilish C++ code, but I still find that it just gives up in situations when it clearly shouldn't. Code folding is starting to misbehave all of a sudden when editing files, sometimes Eclipse has no clue what possible completions are, although it did a fine job discovering two lines above the current one etc. I really wished this thing was more robust. It would help me alot.
The crazy thing is that process isolation as provided by operating systems is relying heavily on hardware support. Most processors only have a kernel mode and a user mode and the mode switching is a part of what isolates processes. The 80386 was cleverly designed to have 4 modes, called rings, 0 to 3, where each inner ring would have more privileges than the outer rings. This was at a time where most of the OS makers ended up looking at this design and scratching their heads in wonder, having no idea how to use that feature. OS/2 was one of the few exceptions. Well, most other OS makers were thinking about compatiblity with other CPUs and put the kernel at ring 0 and the user space at ring 3, leaving no ring above and below. This is why hardware support for virtualisation has to add another layer below ring 0. And this is also why NaCl needs such an elaborate sandbox: it can't use the support already within the CPU because it can't run in ring 2 and let the downloaded code run in ring 3, which would be the ideal solution.
No, you got that backwards. Cairo as a drawing library provides features that X never was designed for and it offers them in a device- and platform-independent way, if required. So given the fact that all windowing toolkits that are worth mentioning support more than just X, depending on Cairo for rendering is the perfectly sane thing to do. Otherwise you risk a broken UI because it ends up looking differently on different platforms (e.g. truncated labels, graphics not showing correctly etc.).
Which is a test that any sane person would run on test tracks first and strictly using company-owned cars until it works under any circumstances. So if this was the first test of that feature on a real road some major bug must have slipped through. I don't believe that.
What a shiny little world you must live in! In the real world OpenGL drivers are *massive* and extremely complex beasts. And they contain more shenanigans than you could probably imagine. And for bugs, there are hordes of them - you just have to be unlucky enough to encounter them. It is all a mix of obscure stuff in the OpenGL specification that is rarely, even never, used, weird combinations of features that should work, but maybe won't because nobody uses them and nobody cares to test them properly for this very reason and known bugs that won't get fixed because they are not important enough.
Unfortunately, you can't just build a new replacement driver from the ground up even with the specs within reasonable time. Both OpenGL and the underlying hardware are much too complex for that. Just look at the sorry state of the open source Radeon drivers. The guys have the full specs for the hardware, but the drivers are unfortunately unusable for real OpenGL use. They are still incomplete and unbelievably buggy. I'm certain that the developers working on the driver are competent enough. They just aren't done yet. "But it runs compiz" means nothing in that context, because the OpenGL rendering within compiz is a joke.
If you have to ship real, working software in such an environment, each configuration that does not behave totally different from the others you need to support is a godsend.
For starters you would get the same set of driver bugs and features as on the other platforms, because nVidia really only has one driver with different interface layers for different systems. This would reduce the pain of working around driver bugs in cross-platform products a lot.
Getting streaming right is a challenge, but it is quite possible.
Anyway, if they want to make money from this they will eventually have to tell us how it works. We might discuss this between ourselves endlessly until then. I have mailed them some questions which might shed some light on what they are actually doing. But I do not expect them to reply with useful answers.
Yes, the terminology is totally strange. I guess this is an overly ambitious attempt to hype this technology by swapping the more accurate terms out with words that sounds cooler but end up saying nothing. It does not help those of us who think that the tech might be real.
By the way: point cloud rendering can store texturing information in the form of per-point colors. No textures or polygons involved (see Pfister et al, Surfels: Surface Elements as Rendering Primitives). Unfortunately I do not fully understand your comment about the roughness. Keep in mind that the demo video has pretty awful texturing and lighting that is able to hide artifacts from aliasing, interpolation and surface roughness.
I am not convinced that what we are looking at are sparse voxel octrees. Why?
If you look at the original paper there, they really needed to use a Quadro card with 4 to store the data for their scenes and this was their main limiting factor. These guys claim that they have a much much bigger scenes. If the reported 200 billion "atoms" were voxels in the sparse voxel octrees, and given that a voxel required more than 5 bytes of information on average (taken from the paper), the scene would require about 1TB of storage.
Also, sparse voxel octrees was implemented on a GPU in order to reach the performances that was reported. Volume raycasting and GPUs are a very good match. These guys claim that their renderer is running on a CPU with about 20fps. I do not believe that sparse voxel octrees can reach that performance in a CPU implementation, but to be fair, I have not heard of anyone trying. Point clouds, on the other hand, could reach that level of performance. I'm pretty certain about that.
These storage problems have been solved cleverly about 10 years ago - see QSplat. I don't recall the details and I'm too lazy to reread the paper right now, but they did a very clever job at removing redundant information from the data while organizing it hierarchically. The added bonus is that the same weird data structure helps making the rendering really really fast.
The downside is that it requires a lot of precomputation and some rendering problems with point clouds have not been solved to my knowledge, including antialiasing and texture interpolation.
The technology is rather related to point cloud rendering which is about 10 years old now. This is the most clever implementation of point cloud rendering that I am aware of and it is pretty cool: http://graphics.stanford.edu/software/qsplat/ It renders amazingly fast.
It has its shares of problems including requiring a lot of precomputation and as far as I know noone was able to do proper anitaliasing on point clouds. Texture interpolation in the traditional sense has also not been solved to my knowledge because with these point clouds all you can do is give individual points colors, so you will always have hard edges between points. Those two combined result in a lot of visual noise that destroys the illusion in the demo videos that I have seen so far.
Most of the content I see is quasi-static. The actual page content does not change often enough to warrant a complete page regeneration on each request. Complete page generation for each request is really only justified if there are either too many pages to write them all to a static cache at the same time or if the pages are very dynamic (like very active forum threads or other dynamic data that needs to be delivered "fresh").
Oh? Then you can certainly tell me how you can manage different access rights for different users/user groups on different parts of a repository (hint: they may and will change over time). We need to be specifically able to deny any access or write access to any path/file within the repository. SVN does a really nice job there. Certainly you can point me to another version control system where there can be a central server hosting some 400 repositories and watching over the access rights. Such a system would be instantly considered as a possible alternative here.
I can't tell you about 50GB of data, but I've had a repository with 10GB worth of text files and it worked like a charm. Sure, checkouts would take forever, but with the huge number of files this was expected. The repository never broke.
And to be honest, 50GB of source and data for a game sounds quite modest to me if this includes all the data in the respective source format (Photoshop, Maya/3dsmax,...).
Exactly this! It is not about the education of the people writing the code. It's about the purpose for which it is written. I've done it all.
As a scientist most software that I write is geared to solving the problem at hand, nothing more. Sometimes this can be 10.000 lines of C++ code, at other times a short python script or 10. Each time, the code serves as a sort of automation for something that needs to be done anyway (I could attempt to compute the simulation result myself, by hand on pen and paper, you know... if I don't die of old age first;) ). Often, not a single thought goes into how to make this stuff reusable, robust or more generic. It works on the one machine it is ever going to run on and very likely nowhere else, because it does not matter. What matters is the program output, not the program itself.
As a software developer I have to think differently. Software gets compiled, packaged and deployed elsewhere. It must run out of the box, never crash, give useful error message and recover cleanly if something bad happened. And amidst all this effort, there's a tiny bit of code hidden somewhere doing the actual work. All that matters is that the program behaves correctly, no matter what the concrete output is. I might not even be expected to understand what the output actually means - it's not my primary concern.
You are right - limits in the levels are missing, but the proposal explicitly states that it is intended as a groundwork for introducing those by defining a baseline algorithm for measurement.
In the long run, this might only limit clipping due to overly aggressive mixing. The true loudness war caused by compression of dynamic range in the mixing process might not go away as a result. And I don't know how that could even be regulated.
Yes, you can legally link binary blobs to the Linux kernel. See the nVidia driver for example: a binary blob with an interface layer that is shipped as source and compiled for each target kernel. Not much complaining about that one, in fact.
He was talking about Portal, not Portal 2. The first game was really that short. I strolled through it at a rather slow pace in about 4 hours in the first go. On replays I'm doing it in about 2 to 3 hours now because I remember most of the solutions. Portal 2 is different. It took me about 10 hours to complete. Just for comparison.
Now you mention just another incompatible audio daemon. Great! See what's wrong with that? In order to make that audio mess work, it has to be scaled back into a single, monolithic, much more capable system.
Furthermore, any remixing that the application is not aware of is able to degrade the output quality. Consider the following scenarios:
1. The user starts playback of a DVD with 5.1 sound while his headphones are plugged in. Some time after he started playback, he pulls the plug and the sound output should transition to the 5.1 speaker set also connected to the computer. However, the player started playback in stereo because the default output was stereo only. Result: unless the player is notified and re-initializes sound output, the output must remain stereo.
2. The user now terminates the DVD player and starts playing a first person shooter. The game detects 5.1 channel output and initializes its audio engine for that. Now, the user wants to switch back to his headphones. In this scenario, a downmix from 5.1 to stereo may not be what the user expects because the game engine might have a special mode for headphones where it applies HRTFs to the sound sources in order to give the user spacial cues about the sounds (some commerical audio engines offer that).
Currently, there is no way to not have quality degradation in either scenario with the current Linux sound system mess.
Yet another sound server will never be the answer to this because if there's one, there will be others and users will expect developers to support all of them. That is infeasible. There must be one and exactly one kernel-level interface or else the situation will never get better.
This "standard approach" of yours is horribly broken. It adds latency, degrades audio quality by withholding information about the current audio setup from the source application and on Linux never was done in a way that worked (e.g. FMOD not working with pulseaudio last time I checked).
From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes. Otherwise, that particular demon will be handled like in the old init system. So, in order to bring any benefit at all, the whole system (which worked) must be adopted to systemd in some way. Given that some of these demons are really there to be run on servers where systemd has no place, this thing does not seem like a very good idea.
But unlike PulseAudio, i haven't had a chance to see systemd fail spectacularly.
I hate audio demons. These crutches never worked properly and never will. Someone needs to actually make a lot of absolutely breaking changes to ALSA. Why?
When I plug in my USB headphones in Windows, all programs using default audio output automatically move from my 5.1 speakers (onboard sound) to the headphones the moment I plug them in. When I pull the plug, the reverse happens automatically. It just works! MacOS supposedly behaves the exact same way.
On Linux, this is broken in ways you cannot even imagine. When I plug in the USB headphones after booting, they are treated as the second sound card (hw:1) when everything uses the first one (hw:0) by default. So in order to have anything use the headphones I have to reconfigure the applications one by one and probably restart them (xine needs a restart). Same when I change back. When I leave the USB headphones in when booting, it is totally random which sound device will be hw:0 and which will hw:1. Great. To make matters worse, when I leave the webcam plugged in, the internal microphone also gets registered as a different sound device. Plus, when it is plugged in when booting it gets a number one below the headset. So sometimes the webcam microphone ends up as hw:0 during boot and every program attempting to use hw:0 as output device will throw up confusing error messages about how everything stopped working (if they even detect that). A normal user would have given up on this mess already!
The really proper fix would be the following: break the ALSA interface in a big way: don't number sound devices, but name them after the hardware they contain (not the bus location, esp. in the case of USB devices), and make the current default device queryable somehow. Programs must then query ALSA for the default device and be aware that this may change at any moment. ALSA must be extended by a mechanism to report such changes to programs, which absolutely have to respond to this in order to not crash and burn (it'll be a PITA for the programmers, but it's absolutely necessary to enforce all of this). Also, ALSA must be able to report the speaker configuration connected to a certain device.
Why? Programs that are capable of generating two or more channels of output sound need to be aware of how many channels are going to be audible. It's not enought to know that the sound device has a 5.1 analog output. It is equally important to know whether all outputs are actually connected to speakers (e.g. a headphone connected to the onboard 5.1 analog output) or the program will play sound on channels that are inaudible and will not be heard by the user. Really great programs even should distinguish between stereo speakers and headphones or different setups for the same set of speakers (I guess most OSS Linux app devs won't even know why that is). Automatic downmixing inside ALSA when the output channel count decreases on a device change should not happen because the program almost always has additional information and thus can do a better job.
I know that programmers will cringe when they read this because it makes using ALSA much more difficult, but that's what is missing to get consumer desktop audio up to par on Linux.
No. Both iOS and Android threw a lot of the traditional desktop user space away in order to make the OS fit in the device. Android's libc isn't a full POSIX implementation, for example (they're not using glibc). So both OS kernels come from the desktop, but the finished result is no longer comparable. This is where MS will fail.
Slashdot Mirror
That's a space station! Painted all black!
Unfortunately, Eclipse still tends to choke on C++ code a lot in my experience. I'm not writing particularly devilish C++ code, but I still find that it just gives up in situations when it clearly shouldn't. Code folding is starting to misbehave all of a sudden when editing files, sometimes Eclipse has no clue what possible completions are, although it did a fine job discovering two lines above the current one etc. I really wished this thing was more robust. It would help me alot.
The crazy thing is that process isolation as provided by operating systems is relying heavily on hardware support. Most processors only have a kernel mode and a user mode and the mode switching is a part of what isolates processes. The 80386 was cleverly designed to have 4 modes, called rings, 0 to 3, where each inner ring would have more privileges than the outer rings. This was at a time where most of the OS makers ended up looking at this design and scratching their heads in wonder, having no idea how to use that feature. OS/2 was one of the few exceptions. Well, most other OS makers were thinking about compatiblity with other CPUs and put the kernel at ring 0 and the user space at ring 3, leaving no ring above and below. This is why hardware support for virtualisation has to add another layer below ring 0. And this is also why NaCl needs such an elaborate sandbox: it can't use the support already within the CPU because it can't run in ring 2 and let the downloaded code run in ring 3, which would be the ideal solution.
No, you got that backwards. Cairo as a drawing library provides features that X never was designed for and it offers them in a device- and platform-independent way, if required. So given the fact that all windowing toolkits that are worth mentioning support more than just X, depending on Cairo for rendering is the perfectly sane thing to do. Otherwise you risk a broken UI because it ends up looking differently on different platforms (e.g. truncated labels, graphics not showing correctly etc.).
Which is a test that any sane person would run on test tracks first and strictly using company-owned cars until it works under any circumstances. So if this was the first test of that feature on a real road some major bug must have slipped through. I don't believe that.
What a shiny little world you must live in! In the real world OpenGL drivers are *massive* and extremely complex beasts. And they contain more shenanigans than you could probably imagine. And for bugs, there are hordes of them - you just have to be unlucky enough to encounter them. It is all a mix of obscure stuff in the OpenGL specification that is rarely, even never, used, weird combinations of features that should work, but maybe won't because nobody uses them and nobody cares to test them properly for this very reason and known bugs that won't get fixed because they are not important enough.
Unfortunately, you can't just build a new replacement driver from the ground up even with the specs within reasonable time. Both OpenGL and the underlying hardware are much too complex for that. Just look at the sorry state of the open source Radeon drivers. The guys have the full specs for the hardware, but the drivers are unfortunately unusable for real OpenGL use. They are still incomplete and unbelievably buggy. I'm certain that the developers working on the driver are competent enough. They just aren't done yet. "But it runs compiz" means nothing in that context, because the OpenGL rendering within compiz is a joke.
If you have to ship real, working software in such an environment, each configuration that does not behave totally different from the others you need to support is a godsend.
For starters you would get the same set of driver bugs and features as on the other platforms, because nVidia really only has one driver with different interface layers for different systems. This would reduce the pain of working around driver bugs in cross-platform products a lot.
Getting streaming right is a challenge, but it is quite possible.
Anyway, if they want to make money from this they will eventually have to tell us how it works. We might discuss this between ourselves endlessly until then. I have mailed them some questions which might shed some light on what they are actually doing. But I do not expect them to reply with useful answers.
Sorry to reply to myself. I meant a Quadro card with 4GB RAM. This got lost somehow.
Yes, the terminology is totally strange. I guess this is an overly ambitious attempt to hype this technology by swapping the more accurate terms out with words that sounds cooler but end up saying nothing. It does not help those of us who think that the tech might be real.
By the way: point cloud rendering can store texturing information in the form of per-point colors. No textures or polygons involved (see Pfister et al, Surfels: Surface Elements as Rendering Primitives). Unfortunately I do not fully understand your comment about the roughness. Keep in mind that the demo video has pretty awful texturing and lighting that is able to hide artifacts from aliasing, interpolation and surface roughness.
I am not convinced that what we are looking at are sparse voxel octrees. Why?
If you look at the original paper there, they really needed to use a Quadro card with 4 to store the data for their scenes and this was their main limiting factor. These guys claim that they have a much much bigger scenes. If the reported 200 billion "atoms" were voxels in the sparse voxel octrees, and given that a voxel required more than 5 bytes of information on average (taken from the paper), the scene would require about 1TB of storage.
Also, sparse voxel octrees was implemented on a GPU in order to reach the performances that was reported. Volume raycasting and GPUs are a very good match. These guys claim that their renderer is running on a CPU with about 20fps. I do not believe that sparse voxel octrees can reach that performance in a CPU implementation, but to be fair, I have not heard of anyone trying. Point clouds, on the other hand, could reach that level of performance. I'm pretty certain about that.
These storage problems have been solved cleverly about 10 years ago - see QSplat. I don't recall the details and I'm too lazy to reread the paper right now, but they did a very clever job at removing redundant information from the data while organizing it hierarchically. The added bonus is that the same weird data structure helps making the rendering really really fast.
The downside is that it requires a lot of precomputation and some rendering problems with point clouds have not been solved to my knowledge, including antialiasing and texture interpolation.
The technology is rather related to point cloud rendering which is about 10 years old now. This is the most clever implementation of point cloud rendering that I am aware of and it is pretty cool: http://graphics.stanford.edu/software/qsplat/ It renders amazingly fast.
It has its shares of problems including requiring a lot of precomputation and as far as I know noone was able to do proper anitaliasing on point clouds. Texture interpolation in the traditional sense has also not been solved to my knowledge because with these point clouds all you can do is give individual points colors, so you will always have hard edges between points. Those two combined result in a lot of visual noise that destroys the illusion in the demo videos that I have seen so far.
Link to PDF version of paper: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.33.3465&rep=rep1&type=pdf
Most of the content I see is quasi-static. The actual page content does not change often enough to warrant a complete page regeneration on each request. Complete page generation for each request is really only justified if there are either too many pages to write them all to a static cache at the same time or if the pages are very dynamic (like very active forum threads or other dynamic data that needs to be delivered "fresh").
Oh? Then you can certainly tell me how you can manage different access rights for different users/user groups on different parts of a repository (hint: they may and will change over time). We need to be specifically able to deny any access or write access to any path/file within the repository. SVN does a really nice job there. Certainly you can point me to another version control system where there can be a central server hosting some 400 repositories and watching over the access rights. Such a system would be instantly considered as a possible alternative here.
I can't tell you about 50GB of data, but I've had a repository with 10GB worth of text files and it worked like a charm. Sure, checkouts would take forever, but with the huge number of files this was expected. The repository never broke.
And to be honest, 50GB of source and data for a game sounds quite modest to me if this includes all the data in the respective source format (Photoshop, Maya/3dsmax, ...).
Exactly this! It is not about the education of the people writing the code. It's about the purpose for which it is written. I've done it all.
As a scientist most software that I write is geared to solving the problem at hand, nothing more. Sometimes this can be 10.000 lines of C++ code, at other times a short python script or 10. Each time, the code serves as a sort of automation for something that needs to be done anyway (I could attempt to compute the simulation result myself, by hand on pen and paper, you know... if I don't die of old age first ;) ). Often, not a single thought goes into how to make this stuff reusable, robust or more generic. It works on the one machine it is ever going to run on and very likely nowhere else, because it does not matter. What matters is the program output, not the program itself.
As a software developer I have to think differently. Software gets compiled, packaged and deployed elsewhere. It must run out of the box, never crash, give useful error message and recover cleanly if something bad happened. And amidst all this effort, there's a tiny bit of code hidden somewhere doing the actual work. All that matters is that the program behaves correctly, no matter what the concrete output is. I might not even be expected to understand what the output actually means - it's not my primary concern.
See the difference?
You are right - limits in the levels are missing, but the proposal explicitly states that it is intended as a groundwork for introducing those by defining a baseline algorithm for measurement.
In the long run, this might only limit clipping due to overly aggressive mixing. The true loudness war caused by compression of dynamic range in the mixing process might not go away as a result. And I don't know how that could even be regulated.
Yes, you can legally link binary blobs to the Linux kernel. See the nVidia driver for example: a binary blob with an interface layer that is shipped as source and compiled for each target kernel. Not much complaining about that one, in fact.
He was talking about Portal, not Portal 2. The first game was really that short. I strolled through it at a rather slow pace in about 4 hours in the first go. On replays I'm doing it in about 2 to 3 hours now because I remember most of the solutions. Portal 2 is different. It took me about 10 hours to complete. Just for comparison.
Now you mention just another incompatible audio daemon. Great! See what's wrong with that? In order to make that audio mess work, it has to be scaled back into a single, monolithic, much more capable system.
Furthermore, any remixing that the application is not aware of is able to degrade the output quality. Consider the following scenarios:
1. The user starts playback of a DVD with 5.1 sound while his headphones are plugged in. Some time after he started playback, he pulls the plug and the sound output should transition to the 5.1 speaker set also connected to the computer. However, the player started playback in stereo because the default output was stereo only. Result: unless the player is notified and re-initializes sound output, the output must remain stereo.
2. The user now terminates the DVD player and starts playing a first person shooter. The game detects 5.1 channel output and initializes its audio engine for that. Now, the user wants to switch back to his headphones. In this scenario, a downmix from 5.1 to stereo may not be what the user expects because the game engine might have a special mode for headphones where it applies HRTFs to the sound sources in order to give the user spacial cues about the sounds (some commerical audio engines offer that).
Currently, there is no way to not have quality degradation in either scenario with the current Linux sound system mess.
Yet another sound server will never be the answer to this because if there's one, there will be others and users will expect developers to support all of them. That is infeasible. There must be one and exactly one kernel-level interface or else the situation will never get better.
This "standard approach" of yours is horribly broken. It adds latency, degrades audio quality by withholding information about the current audio setup from the source application and on Linux never was done in a way that worked (e.g. FMOD not working with pulseaudio last time I checked).
From what I've read about systemd the most irksome part is that every daemon that wants to really work well with systemd must undergo quite some code changes. Otherwise, that particular demon will be handled like in the old init system. So, in order to bring any benefit at all, the whole system (which worked) must be adopted to systemd in some way. Given that some of these demons are really there to be run on servers where systemd has no place, this thing does not seem like a very good idea.
But unlike PulseAudio, i haven't had a chance to see systemd fail spectacularly.
I hate audio demons. These crutches never worked properly and never will. Someone needs to actually make a lot of absolutely breaking changes to ALSA. Why?
When I plug in my USB headphones in Windows, all programs using default audio output automatically move from my 5.1 speakers (onboard sound) to the headphones the moment I plug them in. When I pull the plug, the reverse happens automatically. It just works! MacOS supposedly behaves the exact same way.
On Linux, this is broken in ways you cannot even imagine. When I plug in the USB headphones after booting, they are treated as the second sound card (hw:1) when everything uses the first one (hw:0) by default. So in order to have anything use the headphones I have to reconfigure the applications one by one and probably restart them (xine needs a restart). Same when I change back. When I leave the USB headphones in when booting, it is totally random which sound device will be hw:0 and which will hw:1. Great. To make matters worse, when I leave the webcam plugged in, the internal microphone also gets registered as a different sound device. Plus, when it is plugged in when booting it gets a number one below the headset. So sometimes the webcam microphone ends up as hw:0 during boot and every program attempting to use hw:0 as output device will throw up confusing error messages about how everything stopped working (if they even detect that). A normal user would have given up on this mess already!
The really proper fix would be the following: break the ALSA interface in a big way: don't number sound devices, but name them after the hardware they contain (not the bus location, esp. in the case of USB devices), and make the current default device queryable somehow. Programs must then query ALSA for the default device and be aware that this may change at any moment. ALSA must be extended by a mechanism to report such changes to programs, which absolutely have to respond to this in order to not crash and burn (it'll be a PITA for the programmers, but it's absolutely necessary to enforce all of this). Also, ALSA must be able to report the speaker configuration connected to a certain device.
Why? Programs that are capable of generating two or more channels of output sound need to be aware of how many channels are going to be audible. It's not enought to know that the sound device has a 5.1 analog output. It is equally important to know whether all outputs are actually connected to speakers (e.g. a headphone connected to the onboard 5.1 analog output) or the program will play sound on channels that are inaudible and will not be heard by the user. Really great programs even should distinguish between stereo speakers and headphones or different setups for the same set of speakers (I guess most OSS Linux app devs won't even know why that is). Automatic downmixing inside ALSA when the output channel count decreases on a device change should not happen because the program almost always has additional information and thus can do a better job.
I know that programmers will cringe when they read this because it makes using ALSA much more difficult, but that's what is missing to get consumer desktop audio up to par on Linux.
No. Both iOS and Android threw a lot of the traditional desktop user space away in order to make the OS fit in the device. Android's libc isn't a full POSIX implementation, for example (they're not using glibc). So both OS kernels come from the desktop, but the finished result is no longer comparable. This is where MS will fail.