Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it.
Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.
Well, for ALSA and pulseaudio, the latter more or less just surfaced the tons of bugs in the underlying, at the time very shitty audio drivers. Remember, only pulseaudio is a sound server, so ALSA wasn't even exercising many of the more "advanced" features, and drivers were only supporting the most basic stuff.
That's at odds with the fact that pulseaudio is incapable of exposing the audio reference clocks from sound hardware, which is a fundamental aspect of digital audio engineering. Its design doesn't even acknowledge the existence of an audio clock.
That's fine for basic audio but completely excludes any higher demand application, including high quality A/V sync. Best you can do is work around and best effort guess.
Considering pipewire was a drop-in replacement for pulseaudio with (almost*) full compatibility and none of the stability issues (you can even use the pulseaudio commands to control it), the problem was definitely in the pulseaudio code.
* I do remember reading there was one feature they intentionally dropped because it was extremely rarely useful and could be handled in a different way, but don't remember what it was.
So one audio server managed to provide a shim for another audio server, great.
But it absolutely doesn't follow from that that pulseaudio was somehow bad. There was more than a decade where audio drivers were slowly getting bug fixes to get to a state where they are working okay for the most part. Pipewire would have experienced many of the same issues as pulseaudio, and we would similarly attribute those errors incorrectly to the audio server.
My laptop would regularly freeze and need a hard reboot, and I never could figure out why. One day for a completely unrelated reason I decided to try switching from pulseaudio to pipewire, with no other changes (including no other upgrades; I'm lazy and like stability), and months later I realized it hadn't frozen at all. Still hasn't, years later. The problem was definitely pulseaudio making the whole system unstable, not just causing audio issues.
Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.
I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things.
I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.
> Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now.
Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted.
I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles.
But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC.
And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon.
Meanwhile ALSA with an up to date default dmix configuration worked just fine.
When it comes to incorrect profiles, I suggest making a pull request to alsa-project/alsa-ucm-conf with correct configuration. I had similar issue with my audio interface a couple years ago but it was quickly merged and now it works better than on Windows or macOS.
Before that I did have custom config, it was not that hard to set up, there are great examples and explanations on Arch wiki: https://wiki.archlinux.org/title/PipeWire
So he creates a program that was good enough that pretty much everyone started using it.
And he complained about a lot of dependencies but then went and actually wrote fixes/solutions for them that was so good that nearly everyone started using and even depending on it.
It sounds like the people who were sitting on the sidelines complaining about his complaining had ample opportunities to write better alternatives than the programs he wrote but didn’t do so. Instead they relied on character attacks and FUD (well, except the folks who developed pipewire), while Poettering wa engage in elite hacking by implementing solutions and letting users and distro makers decide whether they wanted to use those solutions.
A son of GDR diplomats, according to an old version of his Wikipedia page. That information seems to be memory-holed now. Now you only find that he grew up in South America without any hint of a reason.
Look, I was in CS101 back in those days so I'm not really qualified to say who was right about where/with-what responsibility for bugs lied. Maybe he was completely right and just kind of a dick about it. I'm just reporting that no one liked him and that carried over to the introduction of systemd.
I buy Jovial which is a just straight brown rice flour and as long as you cook it right (which in Albuquerque is a problem with wheat pasta too) it's great.
It can also map unto "maybe", which opens another can of worms.
Not that there's anything wrong with having an extra value "unknown", but it doesn't fundamentally alter the logic. As unknown in most cases means "it will be true or false at some point", its usage in computing is that of a singleton (who needs a word with 64 potentially unknown bits?), so dealing with unknown values as an exception is easier than permeating hardware with it. Using ternary to represent unknown is just not efficient.
That's mostly incorrect. In Maryland, like in most places in the country, the distribution infrastructure is controlled by regulated monopolies that buy power on the market from generators. Your bills separate out the fees for usage and the fees for distribution, and the Maryland PSC has to approve both.
Yes, but the cost per kilowatt is at least partially based on capex recovery. That might be approved by the PSC but what they approve are capex projects and the recovery of them.
Because there's this belief that a for-profit company will naturally be more efficient. No idea if that's actually true in practice though. Or if efficiency > the profits the company takes.
I don't know of any large community ran utilities, just small ones. I'm guessing the scale starts being a problem eventually.
They can be efficient, but I ly if the incentives align towards the desired definition of efficiency.
If you give a company a natural monopoly and protection from competition. Then it's most efficient way to make money is just to raise rates
They basically are. It really isn’t anything resembling an open market. They are effectively extensions of the state that happen to be funded by user fees rather than general funds.
Thank you for sharing this.
I get that the company making the capital investment wants to get a return of 10% from their investment.
The part I don’t understand is, why aren’t the return on investment being covered by the increased usage from the data centers (while the rate per usage stays flat)?
If the increase in usage (with rates staying flat) is insufficient to cover for the return on investment, then who is making the decision to take the risk for making these capital investment? The risk taker can definitely ‘pay’ for an over confidence in the market.
If it is because the increased usage of the grid as a whole reaches a step function requiring more investment, the system can have a gradually increasing usage price rate.
I am trying to find out if someone in the system is trying to eat up the benefits and publicly say “it’s because of AI” or maybe I am not understanding the situation well.
1) the first MW is cheaper to generate than the 100th. Newer plants. Cheaper fuels. More efficient. You run your good stuff always, for peak it’s on demand.
2) the cost of the old plants are already paid for, if adding a new data center requires a new plant; may add a big cost with a 50 year payback.
With respect to the Dawkins quote: Claude doesn't survive we just built it, like yesterday, the Claude that Dawkins is interacting with might be replaced next month because it can't survive.
Just once I want to see some old dude waxing about LLM-conciousness post a chat log where the LLM is like "your book is an incoherent mess of tautologies and incorrect statistics. I bet your dick looks like a road kill squirrel".
reply