So put a big red scary "PRESS THIS BUTTON AND YOU'LL GET HACKED IN TEN MINUTES UNLESS YOUR COMPUTER DOES NOT CRASH BEFORE THAT" that turns telemetry off and let me press it.
What later days? Software mixing worked fine in ALSA in 2004-2005, and OSS emulation had been working reliably way before that. The first PulseAudio release was in 2004, and it wasn't adopted by Fedora until way, way later.
This has worked reliably in ALSA before it has worked reliably in PulseAudio (and, in fact, way before PulseAudio received any meaningful adoption, when Fedora enrolled everyone in PA's beta testing).
That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
In the meantime, a bunch of us developers are desperately trying to figure out what the fsck broke this time, drinking our sorrows about this new life where we can't debug anything that happens at boot, and frantically setting up BSDs on our laptops at home, so that we can at least get a break from this mess when we're at home.
I (thankfully only) used to do Linux BSPs in a former life. In the last year or so of doing that, I think we spent about 15-20% of a project's time debugging systemd problems and working around it being too smart for its own good. 20% for the bloody init system sounds fine until you realize the rest of the time included stuff like writing or expanding device drivers.
Of course you are free to do whatever you want, it's the entitlement that pisses me off. Somehow, employees charging "too much" is not ok and totally not the companies' fault, whereas offering too little is great management. Then they wonder why there are six million jobs that they can't fill.
So... the business doesn't even generate enough revenue to afford hiring the kind of people who can keep it running well, or at least not as well as its owners would want it to be running?
Honestly -- I have no idea, I only had to do it a few times, on Yocto and buildroot images, and in pretty restricted cases. It was pretty easy (basically udev has this file which matches a set of device selection rules with a set of actions, effectively saying "if I encounter a device of this type, I'm going to do these particular things"), but I googled my way through it.
I expect there are some distro-specific hoops to jump through, but I have no idea which ones -- I really don't like automounting, I keep it disabled even on KDE.
I don't know what they use, but there's always eudev, Gentoo's fork which works just fine, and offers pretty much everything that udev offers (except for the systemd dependency).
Yes. This is all handled via udev, udisks & co., XFCE, Gnome and KDE have nothing to do with it (other than having it work more or less out of the box).
But it's not "just" limited tools and a need to train developers. A language having a small community results in a lack of library and collaboration; you end up dealing with tool vendors who barely manage to keep themselves afloat, let alone invest in development, with long unmaintained libraries, with months, sometimes years passing between when a new architecture or OS is available and when the compiler and the libraries you use get updated.
It's not too different from how things are in Common Lisp land, a language (and a land...) that I'm pretty familiar with. It's a great, probably the best language. There are a few success stories, but truth is, in 2017, most large-scale, non-hobby projects are failures.
Do you think (as in bet-your-company's-profits-on-it believe) that Ada will still be a first-class language in GCC ten years from now (the standard product lifecycle for RHEL), and that you'll be able to staff the project and build a community throughout that period?
I love Ada, and I've written Ada code, but there are so few people who know it that building a community around an init system built in Ada is very difficult. The barrier of entry for contributions is "learn this language developed by the DoD thirty years ago that you won't use unless you work on embedded systems, in the US, for a living." I agree that it's a better technological choice than C, for any systems-level program, but Red Hat, like virtually any company out there, cares about money more than tech.
FreePascal, Oberon, ActiveOberon, are all great (I'm hesitant to say I know Oberon since I haven't written Oberon code in like 15 years), but besides having the same problem as Ada above, the communities maintaining the compilers are small and understandingly fragile. systemd is still going to be here 15 years from now. Oberon -- who knows?
Modula really belongs in a museum :-).
Besides, they'd all need things like D-Bus bindings etc., a working, stable compiler is just the first step.
I ended up trying apulse myself last evening and it seems to work fine, so crisis averted for now. I don't particularly enjoy having stuff much with LD_PRELOAD and friends but I suppose it's less effort.
Thing is... I know what you're saying, and I don't doubt it's probably just some trivial issue that I can solve with a two-hour trip to Google and my PA config files. However, not running PA works fine, and has been working fine for like 12 years on every computer I've owned. It's literally no effort at all. I could spend some time getting sound to work again, or do absolutely nothing at all and have it working fine, just as it's worked for the last six years on the machine in question.
The days of endlessly troubleshooting ALSA settings and OSS wrappers aren't really gone if we're troubleshooting PA settings and ALSA wrappers instead.