I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state.
I hold no animus towards the systemd project's goals or aspirations, but I have yet to hear a compelling reason for systemd to be shipping in it's current state.
I am, in a way, reminded reminded of PulseAudio. I kept PA of my desktop and laptop for years, having heard about PA being a complex nightmare to configure and make work that caused audio to break. Eventually, there was an application I needed to use that had a hard dependency on PA, so I bit the bullet and installed it. And everything magically Just Worked. My only complaint at the moment is that the pactl command seems more fiddly and verbose than it might need to be.
A closer look at the complaints about PA showed that many of them were older. This gives me the impression that PA was in fact a steaming pile that broke audio at one point, but eventually matured into something functional and useful.
And I think this is where systemd is at present: perhaps a good idea, but its implementation is not yet production ready, and should not be the default on production systems. And the project's continued scope creep is working against it in that regard.
systemd wasn't reliable or fit for purpose for servers when it got shoehorned in to everything.
When it comes to production servers you need stable and reliable. Not new and shiny. You're ideally rarely having anything happen on the server other than "run this software"
There is the classical "box in the corner sending and receiving data over the network".
And then there is the new "bunch of software in a container in the cloud somewhere".
And with the latter definition, stable and reliable seems to be of lesser importance in the eyes of the faithful. This because they can just fire off a new instance of the container if the existing one falls over (Uptime by machinegun as i like to think of it).
http://www.commitstrip.com/en/2015/07/08/true-story-fixing-a...
On either case, respawning time and scalability are limited by data coherence needs.
Frankly i think it would have gone nowhere if Canonical didn't decide they needed to copy Windows' "one volume slider pr program" thingy that was introduced in Windows 7 or there about.
Note btw that these days Poettering is no longer involved with PA development.
BTW, the main goal of systemd seems to be to create a single baseline for desktop Linux in code rather than spec.
It is a "continuation" of the -kit mentality that spawned within Freedesktop (or frankly within Fedora, at it seems said distro is basically the Petrie dish for anything under the Freedesktop umbrella).
With only a single master volume control I'm often fiddling with it to keep things at a reasonable level. With per program volume, I'm fiddling with levels less often and spending more time just listening.
When I plug in any new audio device, whatever I'm playing/recording automatically sinks to the most recent device. Seamlessly. So if I'm on mail.google.com and a GVoice call comes in, I can take the call, and during the call, plug in my USB headset.
It just works.
Mac can't do that. Windows can't do that. Linux/PulseAudio can. And that kicks ass.
I do it almost daily when I come home and plug in my Bose Companion 5 into my Macbook (USB Speakers)
It could also have been a borked install as well. But I'm sitting in front of a Win10 install on a Surface 4 Pro, and it can't auto-sink audio.
In fact, I quite often start music playing on the laptop (chrome/Google Play Music) and then power up my bluetooth headset -- it initially uses eSCO when it routes the audio over (mono) and then switches to A2DP a few seconds later
Maybe the issue is something to do with the SW (chrome/firefox?) you use for GVoice? Or maybe there are some edge cases that I'm not triggering (in particular, a USB headset is effectively a new soundcard and not just an audio sink; I can completely believe windows is flaky with them especially with third party drivers)
You are talking about a headset welded to a soundcard, that you then insert into a data bus each time you want to use it.
It completely fucked up the audio on my desktop at the time. Lots of cracking and hissing, some really weird delays as well.
With 16.04, PA has decided to not recognize the analog ports (headphone, microphone) on my motherboard. They are still there, and I can use ALSA programs to control the volume and play audio. But they just disappear after a couple seconds. It is annoying enough I might just move back to Ubuntu 14.04.