3 ms·
Discussing a change in assumptions that alters the core requirements of the most-used user-facing application on the operating system is hardly 'bikeshedding.'
by stonogo 10y ago
Discussing a change in assumptions that alters the core requirements of the most-used user-facing application on the operating system is hardly 'bikeshedding.'
Requiring additional third-party software will never result in 'more consistent' behavior. It merely reduces the userbase to those whose systems look like the developers, and causes your project to be beholden to the whims of the upsream devs.
This is not some architectural decision with a measurable quality impact; it is another abdication on Mozilla's part. We will see more and more of this as their current decline continues. I happen to have no problems with libpulse, but it's pretty clear Mozilla is trying to throw as much as possible over whatever fence they can find. See also Project Mortar.
- scrollaway 10y agoMy own complaints I mentioned are about Project Mortar. Like I said, Mozilla does plenty wrong. > It merely reduces the userbase to those whose systems look like the developers Pulseaudio is included by default in almost every Linux distribution. Certainly in every major Linux distribution. This is Mozilla not catering to the 1%. I'm sorry but I cannot see a world in which that decision is incorrect. I found that of all the people complaining about, for example, systemd, very few actually stepped up to actually maintain the batshit-insane ecosystem of init scripts of their distributions. Those that did, quickly gave up and admitted they were wrong - we had a few of those in Arch Linux when we moved to systemd. For Pulseaudio, it's the same thing. Who's stepping up to improve the state of Linux audio? In fact, who, of those complaining about pulse, even have a clue about the state of Linux audio and how much of a pain it is to develop for it?
- stonogo 10y ago> Pulseaudio is included by default in almost every Linux distribution. Certainly in every major Linux distribution. This is Mozilla not catering to the 1%. I agree. It's a natural reaction for a company struggling to find its purpose. I hope for all our sakes it helps Mozilla survive. > Who's stepping up Well, that's the crux of the problem. Very few people are qualified. Those that are qualified almost universally do not have the backing of Red Hat. It is the opinion of many that both pulseaudio and systemd achieved market dominance because of politicoeconomic reasons, rather than a technological decision-making process. It is very, very hard to prove otherwise... which is why we get these ridiculous religious wars on the topic. Personally, I don't care. The bugs I've run into in both pulse and systemd are always products of naivete rather than some ficticious malicious plot. Growing pains, like all other projects undergo. The problem we are starting to have is that we are losing portability in the process. The more software requiring libpulse and libsystemd, the more difficult it is for novel approaches to survive. A posix capability layer is one thing. How does a new player enter the game, when libpulse and libsytemd have no specification? It feels a little like embrace/extend/extinguish. I have no reason to move away from linux. I have no problem using systemd and pulseaudio on all my systems. But I do understand why some might miss the days when the barier was lower. Dismissing and/or demonizing the people who think that way isn't particularly productive, and neither is telling them their opinions are irrelevant. I hope we move past "if you don't like it reimplement it yourself" one day. The ability to do so was what gave us systemd and pulseaudio, but the requirement that it be done before you can be taken seriously doesn't really add much value.
- onli 10y ago> The ability to do so was what gave us systemd and pulseaudio, but the requirement that it be done before you can be taken seriously doesn't really add much value. It's also an insane request because it just can't be done. If I would want to provide an alternative to systemd for the mainstream distros, my first poinft of work would be to implement systemd. Because the environment around me assumes systemd, apart from some safe enclaves. If I were to provide an incompatible alternative I'd have to win the political war to have it be used or even just considered. Given how upstream looks today that is impossible, even if my solution were excellent. And in that space, nothing can compete against organized paid developers. And still: People did step up. There still is OpenRC, for example, which is what I'm using. There are the forks that work and provide alternatives. But Linux is more splintered than ever because of that. The situation with PA and ALSA is better, because ALSA always still worked (I know, because of being an underlying layer, but also without PA, which is nice).
- belorn 10y agoMoving the alsa compatibility code from inline to a third-party library doesn't sound like it alter "the core requirements" by much. Its a 255078 byte package in debian, while firefox itself is ~50MB.