Hacker News new | past | comments | ask | show | jobs | submit login

A minor disagreement, that software is perfectly reliable with decent hardware and perfect 3rd party software, it just does not degrade gracefully (to say the least) when things it interoperates with misbehave. If you're not doing networking or audio, it doesn't matter if buggy hardware makes PA go bonkers or weird service defs make avahi behave weirdly. A lack of error handling and error recovery.

Its a violation of the old unix principle of be liberal in what you accept.

The most likely outcome of that philosophy installed in everyone's init system is going to be a heck of a lot of systemd crashes, although it'll all technically have a root cause of some other software or perhaps dodgy hardware. None of those crashes would occur with an init system that handles errors better, so systemd is going to catch a lot of blame.




Actually, the flat volumes feature that's on by default in recent PulseAudio versions (and cannot be disabled without editing a config file as root) relies on entirely unspecified behaviour of the audio hardware, namely the timing relationship between volume changes and sample data. It has a hack that avoids deafening people unexpectedly on most hardware, but at the expense of very audible volume glitches every time it decides to fiddle with the global volume.

(Also, thanks to inconvenient analog issues like component tolerances, the most reliable way for hardware to deal with PulseAudio's flat volumes is to provide no volume controls except for a single digital one that simply undoes all of PulseAudio's weird fiddling. This volume control would provide no functionality that couldn't just be implemented in software, but PulseAudio handles devices without one really badly.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: