Comment Re:Kernel mode (Score 1) 221
Sadly for your worldview, accessing fields at fixed offsets from a pointer isn't parsing. To say that it is redefines absolutely everything that software does as parsing.
Sadly for your worldview, accessing fields at fixed offsets from a pointer isn't parsing. To say that it is redefines absolutely everything that software does as parsing.
In a sequential processing system, polling cannot begin until the last event has been fully processed. Which means that if you have a button that does something really complicated, NO other button can work until that process is complete.
None of the buttons do anything even slightly complicated. They just update some state data that will be used by the game loop. I explained this already, but you were too arrogant to pay attention.
In a threaded system, with CORRECT design, one event produces one interrupt produces one thread. That thread lasts the lifetime of that process, then dies. Thus, there isn't a thread per button, there's a thread per active event.
So more like a thread per button press, which lives until the action performed by the button press is done? As I said, all you need to do is update some state. That task can be completed in less time than it would take to create a thread to do the work. So I assume you must mean, for example, that if I press a button to throw a grenade, the game should spawn a thread to move the grenade through its trajectory, calculating collisions, exploding, and then the thread should terminate. That wouldn't be efficient, and it's not how games are programmed.
You seem to think that execution of game logic for events spans multiple frames. Games don't work that way. Such a thread could waste CPU time by updating its state more than once per rendered frame, or if it didn't get CPU time it might not run at all that frame, leading to glitches (not moving, not triggering a response to something, etc). To solve those problems, you'd have to make the routine's execution block after an update to wait for a frame to render. And at the same time, your render would have to block until all tasks have run so that everything runs exactly once.
And then congratulations, you've built a list of tasks and executed them once per frame. Which is what games actually do. But your method is convoluted and inefficient. Real games implement handler functions that do one frame worth of processing and then return. They execute each handler once per frame, and then render graphics.
You generally do not let threads run freely, updating the game state while you're trying to render. You can implement concurrency between rendering and execution, where you render one frame and process physics and logic for the next at the same time, but that's still calling each handler once per frame.
The only common exception is AI. Since it both sees and directs the game world at a high level, it doesn't require as much consistency. And it also does some things that might take a while, so you might actually need to run a task in its own thread over a period that spans several frames.
Event-driven designs almost invariably use this design because you get a flat latency (ie: you're not waiting for something else to finish, which will take a non-deterministic amount of time).
You can't just create additional processor resources by spawning a thread. Whether you have a thread per task, or you put them in a task queue, you're going to share time with the other tasks in some way. Either by letting everyone ahead of you go first, or by having every active task take turns round-robin until all are done. But the policy doesn't matter here, because you have to wait for all the tasks to complete before rendering the frame. So just use one of these.
My definition of real-time is indeed correct. The "short and bounded time" description of yours is the effect of guaranteeing N amount of runtime in M amount of wall-clock time (the time has to be bounded, as N cannot exceed M, and because latency has to be extremely tiny, M is classically small making N classically small.) Real-time means Extremely And Utterly Predictable, my definition says how that is achieved in real-time systems, your joke of a definition describes the consequences once it is achieved.
Excuse me? My definition is a "joke"? Yours was "there is a fixed relationship between CPU time and wall-clock time", and you didn't even define "CPU time". All I can infer from this is you're saying the CPU meets a certain guaranteed minimum performance. Sorry, but that misses the most important point about real-time: that you need to use good algorithms. You'll normally need to use O(1) algorithms for critical tasks, or otherwise limit your n. You can't just throw hardware at the problem. If you have an "Extremely And Utterly Predictable" CPU, but your scheduler is O(n^2), then you can't maintain real-time performance under load.
Clearly, you have not looked at any source code since no modern game will use polling. I suggest you try again.
If you've looked at source code, then cite some. I'll certainly cite code. For example, Open Arena. Look at engine/code/sdl/sdl_input.c, in the function IN_Frame(). This is called once per frame. (If you don't believe me, check the main loop in engine/code/sys/sys_main.c). IN_Frame() calls IN_ProcessEvents(), which gobbles up all pending input events using 'while(SDL_PollEvent(&e))'. After getting all the input events, the game loop calls Com_Frame(), which does game logic, then renders. Just like I said. I've now cited source. Your turn. Show me something that works the way you claim.
RASDIT is known to any - and I mean ANY - person who has even got as far as 1st year Comp Sci or Software Engineering.
Funny, because I have my degree and have never heard of it.
If you need to google it, you're not qualified to tell those of us who are professionals how we operate or how we define things.
I absolutely am qualified to tell you not to make up words and then act superior to anyone who's never heard of your made-up nonsense.
And you can't have googled very well, I found the definition from various university papers from the UK, US and Oz.
Prove it. Give links. I looked at all the search results for "RASDIT" (in quotes, so it won't return irrelevant results like "rasd it", and filtered for English). On page 8 Google tells me that the rest of the 406 results are mostly just duplicated content omitted for my convenience. So either you're calling this thing by the wrong name, or you made it up wholesale. I'm leaning toward the latter at this point.
You've never seen split-screen games with different framerates? You probably have, just not in the trivial sense. Try again. The level of changing detail (static detail is immaterial) on the screen has to be different enough for you to measure the difference, and judging by eye will be impossible so you should put the action onto disk and then run through it with an editor. Tell me then that the two players run at exactly the same rate. (No, an FPS counter isn't enough. it's trivial for games to reduce detail to increase FPS, so you actually have to go onto the screens and =measure= the level of change per user.)
I'm talking about the frame rate, and you start talking about the player walking speeds being different. They won't differ, but that's beside the point. Go ahead and rip this video and look at it in a video editor (such as avidemux). Starting at around frame 2212 (01:13.937), there's a lot of slowdown. The framerate drops below 30, so you can see multiple frames where the screen hasn't updated. Step through them and you'll notice that both players' screens always update in unison. If the players and their screens were handled by independent threads, you'd be able to see them updating at independent times when the framerate gets this low.
But games don't work like that. The split-screen multiplayer pretty much functions exactly like the single player, except that it accepts input from more controllers, and renders more views. The game still has one single game state, and it renders all views from that one consistent state, updating all screens together. If you want to prove otherwise, cite some source or post a video, like I have.
Sorry, but your post makes me more sure that you don't know what you're talking about than I was before.
Standard multiplayer games use event-driven I/O (because polling is bloody awful) and if you want simultaneous action then each event will be on one thread. You don't queue them up. Some multiplayer games opt to have one thread per player, rather than one thread per event, but that means that user input is non-deterministic. Pressing up and firing should perform exactly the same operation no matter which button made contact first. That's a parallel operation, not a sequential one.
Are you seriously telling me games have a thread for every button or axis on each controller? That seems to be what you mean by 'each event on one thread'. If so, wow... Do you understand how the controller input even gets to the system? The three major consoles have Bluetooth controllers. This is a serial connection. Only one input device talks at a time, and the Bluetooth chip sends the data to the system in serial. The threading strategy you discuss gains absolutely nothing, because you'd still have a thread somewhere reading the sequence of input events and selecting the appropriate thread to delegate handling to. You could instead just do that work in the original thread, and lose nothing (except some unnecessary overhead).
And usually, the only 'work' ever done by the input routine is updating controller state data used by the main loop. That's practically no work at all. If you had four players and they all hit every button and moved every stick and even made some motion for the accelerometers to pick up, all at the same time, it'd take mere microseconds of CPU time to process it all. Consoles max out at 60 FPS, and that means there are ~16 milliseconds between each screen update. There's absolutely no risk that a button press won't be processed in time to be handled in the next frame just because controller input handling wasn't multi-threaded.
There is generally one core engine doing the heavy lifting, but even there you parallelize the hell out of it. (You could timeslice, I suppose, but only an incredibly moronic imbecile would use 40-year-old serialized and painfully slow simulations of threading when true threading is available.)
You'd parallelize physics and/or AI just to utilize all the cores. But I'll bet most games synchronize their physics threads every frame. So no strange side-effects if one physics thread takes longer than the others. It'd just delay rendering as you wait for all physics to complete.
As for the other post, no you do NOT want the perception of realtime in gaming. Realtime in software engineering has a very specific meaning (there is a fixed relationship between CPU time and wall-clock time)
In the context of this discussion, it can just mean that the game feels like it's responding as you press buttons, instead of responding moments later, or it can mean that game time runs at the same speed regardless of framerate.
Your definition of realtime is wrong, BTW. Real-time just means that the hardware and OS are designed to perform certain operations in a short and bounded amount of time, so that response time can be guaranteed.
and that is exactly what you do NOT want in a single-player game. In a single-player game, the most important thing is that there is a fixed relationship between game time and wall-clock time. This is NOT, however, realtime. Realtime can vary the relationship between game time and wall-clock time since it fixes CPU time and less CPU intensive scenes would therefore run faster than more CPU intensive scenes.
Sorry, I don't think any of this makes any sense. For one, if we go by your definition above of real-time meaning that "there is a fixed relationship between CPU time and wall-clock time", then if the framerate changes, shouldn't the game keep time correctly because this "fixed relationship" correctly accounts for the amount of time each frame takes? Regardless, having a real-time OS isn't going to stop a game from accessing the system clock. I bet I can install a real-time Linux kernel without messing up my games.
With non-networked multiplayer games, the slight variations are going to be unimportant in comparison to each player having equal CPU resources. The intensity of processing needed for one player should not alter - by any degree whatsoever - the responsiveness of the controls of the other player. (And, yes, again you have to do that multithreaded. You can't sequentially read and process because that would add enough latency to kill the opponent right off the bat.)
Both players get the same framerate, so both players get the same responsiveness. I've never seen a split-screen game where the framerate for one screen can be different from the framerate on the other screen. As I explained, it's going to take mere microseconds to process all controller inputs. After that, the game is running off of saved controller state data. Player actions are usually processed with physics, and physics are usually processed once per frame. So both players get a responsiveness based on the framerate and the framerate is the same for both players.
My guess is that you've not looked at the source for a lot of multiplayer (or even single-player) games.
I've looked at some. Do you have a suggestion? I'd really like to see what it looks like to have a thread per event.
I would also guess that you've very little parallel processing experience, RASDIT, or low-level engineering. (Trust me, low-level engineering is a terrifying experience if you're not a master of parallelization.)
I have to admit, I don't even know what RASDIT is. Google doesn't seem to know either...
If you're playing two-player console games, you want absolute smoothness between the threads.
Uh... You clearly have misconceptions about how multiplayer games are programmed...
It may not be the stock OS, but it still has official support from the manufacturer, which is a similar situation. And even with that, the install and setup process isn't totally user-friendly. I'm looking at these instructions.
You have to do the partition setup twice. Once in MacOS to resize the existing filesystem and create a new partition, and again in the Windows installer to select the new partition as the install destination. Select the wrong partition, and you wipe out your data.
Then it comes up in low graphics mode. Connect to the Internet, let Windows Update run and reboot for the graphics driver. Then put in the Mac OS disc, run the install program and reboot. If sound isn't working, download drivers from realtek.com and reboot.
If Apple put the same effort into supporting Linux that they put into Windows, you wouldn't need the MacOS-side app at all. They'd upstream everything needed, so you can just boot the install disc. The partition setup done in the Ubuntu installer is essentially the same screen as the Boot Camp partition setup, except it directly leads into the install process without a reboot followed by a re-selection of the install partition. After the first boot of the installed OS, you'd have at most one more reboot to install a proprietary graphics driver in the case of nVidia/ATI graphics.
So you'd do partition setup once instead of twice, you'd reboot 0-1 times instead of 2-3 times (after OS install), and there'd be no "insert this disc and run setup.exe" or downloading from specific websites. Everything needed to run well (sound, power management, etc) would be integrated into the install disc (except proprietary graphics drivers, and Windows is no better on this matter).
So let me clarify my original statement: Any OS is likely to not run well on a system if there isn't official support for the OS from the system's manufacturer. Linux isn't immune to this rule, but it's far better at operating without official support than any other OS out there. To convey this as a failure on the part of Linux devs is absurd. If you want a system that runs an OS well, buy from a competent manufacturer that officially supports the OS.
This is the kind of thing that makes linux a poor choice on the desktop.
No, it's the sort of thing that makes changing out the stock OS a poor choice on the desktop.
Had you bothered to read the post I linked to it was clear that it wasn't intended for people to be using their 3G connection to be surfing the web.
Maybe you should read your own link:
"Experimental web browsing is free to use over 3G or Wi-Fi."
Yeah, that's some pretty serious "not intending for people to use 3G for web browsing". The author is misinterpreting a fairly standard anti-abuse clause. Obviously "service" includes the 3G web browsing that's being advertised by Amazon. If they advertise and supply a web browser that works over 3G, they're supplying 3G web browsing service. It's something pre-installed on the device. The web browser, complete with a link to Google and other sites, is ready to go when you first turn on the device. You have to deliberately go out of your way to not use 3G when you browse, by setting up Wi-Fi first.
What isn't part of the service would be something like ripping the 3G module out of the Kindle and hacking it into your laptop. That's the kind of action that violates the ToS.
I hear that release comes with a free Slurpee.
That's good.
I don't blame him for creating PulseAudio. I blame the distribution maintainers for having the poor judgment to make it the main sound system for so many distributions. It would be one thing to have a sane default like ALSA and then have PulseAudio available in the repositories for those who really want it.
For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using PulseAudio. If so, I remove it and replace it with ALSA. Suddenly issues related to audio playback go away and everything just magically works. Oh and they easily have a proper mixer without jumping through hoops, too, which is handy considering some of them are using 5.1 surround sound and/or bluetooth headphones.
The first headache I had with PulseAudio was when I tried to run something as a different (normal) user account and audio wouldn't work. There was no meaningful error message. There was only a "connection refused" error in the terminal. As it turns out, this is because PulseAudio has to be run by the user and it is recommended not to run it as a system-wide daemon. User A was running the user-daemon and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used ALSA since PulseAudio didn't do anything I needed it to do that ALSA couldn't do with none of the hassle.
What would you think of the following hypothetical complaint?
I don't blame him for creating X. I blame the distribution maintainers for having the poor judgment to make it the main interface for so many distributions. It would be one thing to have a sane default like text consoles and then have X available in the repositories for those who really want it.
For my friends who use Linux, the first thing I do whenever a new distro is installed is to check if it is using X. If so, I remove it and replace it with screen. Suddenly issues related to mice go away and everything just magically works. Oh and they easily have a proper task switch without jumping through hoops, too, which is handy considering some of them are using international keyboards and/or aalib.
The first headache I had with X was when I tried to run something as a different (normal) user account and graphics wouldn't work. There was no meaningful error message. There was only a "cannot open display" error in the terminal. As it turns out, this is because X has to be run by the user and it is recommended not to run it as a system-wide server. User A was running the X server and User B was denied access to it as a consequence. They both could not run their own, well they could but it wouldn't work, as that'd be far too easy. Rather than screw around trying to get that to work I just used screen since X didn't do anything I needed it to do that screen couldn't do with none of the hassle.
Surely you know enough about X to understand the errors and mis-diagnoses made in the third paragraph. Well, they are exactly analogous to your own error and misdiagnosis about PulseAudio. First, the error message is actually very meaningful. It's telling you it can't talk to the server. So right away you should know to check that the server is running, that the app is trying to talk to the right server, and that it has permission. But you instead mis-diagnose that you need another server running and waste time trying to set up a configuration that won't work.
You'd have that same attitude toward X that you have toward PulseAudio if X was as new and unfamiliar to you as PulseAudio is.
Hello again.
PulseAudio is a middleman standing between the applicating wanting to play sound, and ALSA.
So is dmix. I explained this to you before.
How exactly is that going to fix an inherent flaw in the underlying ALSA system? Hint: it will not and cannot.
You are conflating ALSA, the clean efficient kernel API for using sound hardware, with ALSA the user-space API that adds on a complex system of plugins that can be inserted in place of, or before, sending sound to the hardware. It's this complex plugin system (and the mixer built on top of it) that is inherently flawed and has fundamental limitations. There's no dynamic routing or hot-plugging for starters (and I mean while an application is running). Fixing these limitations requires a rewrite.
If there are such horrible problems with Dmix [...], that kind of development effort should be put towards fixing Dmix
Dmix is being fixed, via a rewrite called 'pulseaudio'. You may have heard of it.
...they want their proprietary format back. Another GD-ROM style abortion? Hopefully they don't think that the awkward size will prevent piracy. Sega made the same mistake, until pirates just reduced video quality on FMV and fit it the games on a standard 800mb CD-ROM (old, I know).
Uh, you do realize this is probably the exact same tech as Blu-ray but without paying for the trademark, right? And even if it's not just Blu-ray, don't you realize that ALL consoles use proprietary formatting in their discs anyway?
Seriously, I don't get why you're portraying this as such an extreme negative. If you tried two consoles, one with proprietary discs and the other without, you wouldn't be able to tell which is which from how much fun you're having... Because there is no difference.
I really hoped they would step up to the big boys in console gaming
How?
You'd think differently if English didn't allow you to use the words 'broke', 'stole', and 'attack' to describe their actions. Stop being controlled by language.
Yes, I'm sure it has nothing to do with Apple's huge TV advertising budget and presence of physical products in stores. Linux doesn't have high market share just because you're not in charge of naming the releases.
If you're going to lecture people about understanding what they're talking about, you'd better understand it, or you'll just make yourself look like a contentious idiot.
And on how many distros does sharing the sound card between different accounts (you know, that thing I was actually talking about) work by default?
Considering this is a default kernel setting and all distros are using a Linux kernel this figure would approach 100%.
No, it is not a "default kernel setting". It is not even a kernel setting.
Simply put, if your kernel has ALSA support it has dmix.
Uh, no. There is no in-kernel mixing in Linux. If you want in-kernel mixing, install FreeBSD. The Linux kernel's sound system is designed for a single process to open a sound device exclusively (unless there's hardware mixing). Dmix is a plugin for the user-space ALSA library that makes the first process to open the sound device create a shared memory segment that other processes will map into their address space. This shared space is then used to coordinate mixing. Don't believe me? I'll cite code. Notice it isn't kernel code. Also notice how it's located the "first instance". And the error message if it fails? "unable to create IPC shm instance". IPC = inter-process communication. shm = shared memory.
Don't like running a sound server? Then don't run dmix. It does the same thing as Pulseaudio, only without a single dedicated process for mixing. It gathers up sound output from every process through shared memory and has one process mix it all.
Dmix has no purpose other than to allow multiple sounds to be played simultaneously. Dmix does not care about whether they came from multiple accounts.
Yes it does. Or more accurately, the shared memory segment it uses does have access rights associated with it. If you don't believe me, then explain this. Maybe there are a few common distros that share the dmix key with everyone in the audio group. All I know is, Ubuntu didn't do it, and it's a bad idea for security and reliability to create backdoors around user isolation.
If you had decency you would be embarassed that you are entering into this discussion without knowing basic facts like that. You would also admit that you shouldn't be spouting information that's more than six years out-of-date, that this makes your opinions about ALSA invalid. That's if you cared about truth and weren't just trying to posture and hand-wave.
Your rant is a better description of you than me. Except that what you're saying about ALSA isn't merely outdated; it's just plain wrong and has never been right. My description of ALSA is accurate and current.
That's a terrible default behavior. If the other user's desktop and applications go away when you switch to your account, why should their sound stay? It's inconsistent. I don't want to hear a random ad suddenly at high volume because somebody else left a webpage open that cycles through ads and eventually plays one with sound. A person should be able to use sound without logging into other people's accounts and closing their programs first.
For a user to have access to play sound, you must first add them to the audio group. If a user only ever connects remotely through something like SSH, then obviously you wouldn't give them permissions to play sounds on your hardware.
Is this even an honest mistake at this point? Are you really that stupid? I was not talking about SSH. I did not even mention SSH. I'm talking about logging in as a second user on the physical machine, and using its keyboard, mouse, and monitor. What did you think I meant when I said 'when you switch to your account'? It only makes sense in the context of the "switch user" function available within or near the 'log out' option on most desktop environments. It leaves the current desktop session running, and starts a completely new login screen on a new X server. Now do you know what I'm talking about? That's what's broken with ALSA.
And it's not obscure functionality either. Most XP users who know only the basics of computer use know how to switch between multiple logins, and that functionality is commonly used. It had better work right and not break audio, or users will get a bad impression of Linux.
Instead, the sound could be played on their own. This is how remote desktops work. If you have to pick such a stupid scenario to discredit something, you are actually adding credibility to the thing you tried to discredit. The scenario you are crying about simply wouldn't happen, and if it does happen, you are seriously doing something wrong and that'd be your fault, not ALSA's.
Again you say something that would be more appropriate for me to say about you. The scenario I was actually talking about is extremely common. Your wine as a separate user scenario is the strange one. The fact that you would portray it as typical to discredit Pulseaudio just discredits you. Here's a hint: If you've opened Konsole, it's not for average users.
I'll give you a non-retarded example of multiple users. I have my main user account. Then I have a separate restricted user account for the sole purpose of running Wine since I do not trust Windows programs.
Sounds more like you do it to brag about how much of a 1337 power user you are. With wine, you are not running Internet Explorer and a bunch of Microsoft network services. Your collection of Windows games does not contain code to root your Linux box.
When I play Fallout: New Vegas in Wine under that second account, I can hear all the game sounds. At the same time, I can run Amarok under my main user account and select background music. The window for Fallout and the window for Amarok are side-by-side on my taskbar. It would serve no useful purpose whatsoever to allow one of these to monopolize the sound. It serves a very useful purpose allowing both to play sound.
This much makes sense. But that's because you're running them on the same session. I was very clearly talking about separate sessions.
I don't have to "log into other people's accounts and close their programs." When I am done playing Fallout, I close the game. Any sounds it was playing close with it. The fact that it runs under a separate user account has nothing whatsoever to do with this. This is the scenario I already described for you.
No, you did not already describe the scenario to me. You're not going to get away with lying directly to me about the contents of your own post that I can easily double-check. You said "His main user had Pulseaudio start up automatically upon login. The user account we created for Wine enjoyed no such privilege." That implies that you actually tried logging in as the other user and the daemon didn't start. Now you tell me you didn't log in as the other user at all and merely used su. Well there's your problem right there.
If there's no additional login session, there shouldn't be an additional daemon. Your attempt to spawn one is in error. I'm surprised doing that didn't completely fail, actually. You manually operated a power tool you didn't understand, then blamed the tool when you didn't get the result you wanted.
Ok, I'll break it down for you in easy-to-digest little baby steps since apparently this is difficult for you.
Assume a running KDE desktop belong to a user account. Let's call this user account "bob". Firefox, Amarok, Thunderbird, Konsole, and a few other programs are running on this KDE desktop. Any of them that use sound are playing it through Pulseaudio. Sound works, so far.
Now then, we want to play a game under Wine. We do this under a different user, let's call this username "alice". There are multiple ways to run something as this other user, but let's keep it simple. We click that Konsole window. We type "su alice -" and enter the password.
OK...
We are now in
No, you're still in
We launch Fallout. It has no sound.
It has no video, either. In fact it completely fails to start:
No protocol specified
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Because you haven't yet set up authorization for alice to connect to bob's X server.
Why? Because for some reason, alice needs to run its own instance of Pulseaudio.
No, because you haven't set up authorization for alice to connect to bob's Pulseaudio server.
Under ALSA this would just work.
Maybe on some distros. But not on others.
Under Pusleaudio, do we get an error message saying "could not play sound: this user isn't running an instance of the Pulseaudio daemon"? No. Instead, we get a bunch of "connection refused" errors
Well, that's an awful lot like saying like saying "No protocol specified, no driver could be loaded, etc" isn't it? Wine's suggestion to set $DISPLAY above wasn't the problem, so it's not doing any better at assisting you with the X connection than it is with the audio connection. So do you make the same complaint about X that you make about Pulse?
No, because you already know how to deal with X. You have a double standard where things are automatically acceptable if you personally are familiar with them. When something's new, you don't like it.
Guess how Pulseaudio eventually sends the sound to the sound hardware? Eventually, it goes through ALSA. Look it up yourself if you don't believe me.
I know this already. You aren't giving me new information here. However, Pulseaudio goes straight to the hardware without going through a redundant dmix layer first.
Maybe you didn't know that little fact, that Pulseaudio is NOT an alternative to ALSA. It is a pre-processor before the sound goes to ALSA anyway. That's why I call it redundant, because it is redundant.
So is dmix redundant? It's a pre-processor before sound is sent to the kernel, just like Pulseaudio.
How ironic. Now that you've said this, if you're not a completely hypocritical asshole, you'll apologize for being the one that's spouting off about a subject you don't understand. I'm informed. You are not.
The thing is, the poster above was just using pulseaudio as a single example of a common problem with multiple faucets of all Linux distros.
Think of it from your mother's perspective. How would she feel if she bought a new computer and the audio didn't work all the time? Or if she couldn't always watch DVDs on it? Or if she had to do something more complicated than click on system preferences to adjust a setting... What's a terminal again? And why don't this computer recognize my *insert peripheral here*???
Not everyone wants to tinker with their desktops. You know how you feel when your motherboard dies? That is how they feel when their computer won't do something simple and they can't figure out how to fix it.
That was my whole point, though. Software like Pulseaudio and Network Manager are needed to provide a user-friendly desktop experience. But long-time Linux-using luddites are often complaining that the old way is better. They might be right, at first. But they go as far as saying the new software will never work and shouldn't be used or developed.
The problem is, they have no vision. They lack the ability to imagine how the software could make things better in the future. Instead they point to bugs in the current version, or sometimes even in past versions, and use it to justify their opposition to the very idea of software that performs that function. Meanwhile, their justification crumbles with every bugfix but they won't change their position.
Sometimes I think these people are just bitter that they wasted too much time trying to get an early version to work well, and now they're trying to get revenge on the inanimate piece of software, even if it works fine today.
Happiness is twin floppies.
