I get it, but the underlying problem is: we don't have a society-wide, effective solution to counterbalancing extractive systems. Lacking a reliable label, we have to constantly signal what's on the ingredients list.
Okay, but the comment I reacted to was not that. It was simply (paraphrasing) “I won’t use anything from Zuck/Meta.” If it had been, “Be careful because I have insider information that Zuck/Meta is using Muse Spark to do <insert-nefarious-thing-here>, and here’s my substantiation for that…” I’d be okay with it. That’s interesting information that moves a conversation forward. But it wasn’t. It was just content-free “I don’t like Zuck” nonsense.
There are gradations to failure. And "our governments" and "us" also overlap.
I'm probably more on your side than it sounds based on this comment, but I find it frustrating to encounter learned helplessness dressed in profundity.
This was about a year ago, but I had trouble getting podman to add an nvidia GPU so that the container could use it. It was technically possible (I succeeded) but it was annoying and "different".
> LLMs are regression-to-the-mean machines--they pull junior developers up, and drag senior developers down. Taming them requires trading the romance of 'code as craft' for the physics of manufacturing.
The thing I don't know is: how do we decide which direction is most valuable? I can see arguments in both directions--quality vs quantity, essentially. I think there's a strong argument for the value of both:
- we need more quantity of software: for a long time, the ability to write software has been locked up, confined to a closed cabal of specialists
- we need more quality in software: we depend more and more on software in every aspect of our lives, mistakes are intolerable and should be avoided
I have not seen evidence that they are regression to the mean machines.
I'm lucky to work with great engineers and their productivity and code quality has become even higher. Wish that wasn't the case, but it is, and that puts also lots of pressure on myself to work more and better all the time. It's exhausting.
There are cons too, system's understanding sometimes is not as intimate, which in turn produces less "gotcha" moments that may lead to better design. There's less time to review PRs and make it a choral work.
On the other hand way more refactors and experiments can be run, so again, code quality has improved just because if you have a hunch that something could be done better, you can test it for cheap.
I'm curious what you think of as "the mean"? I consider the input training set for an LLM to contain its mean. My hypothesis would be: an LLM alone cannot consistently produce code above the mean of the quality it was trained on.
The input training doesn't matter much, besides, the input training is already skewed for code that has been submitted after much trial and error by a dev locally and possibly reviewed. And input has an over bias over open source projects, not crap internal tools no llm has ever seen.
There's more to the quality of the output, like prompts, the quality of the codebase (from which the llms learn), the documentation/harnessing, the feedback an engineer provides while reviewing multiple times (in the chat, in the diff, in the pr) etc, etc.
I think it depends on which side of the regression-to-the-mean machine that you land on (above or below the mean) for any given skill that is being disrupted by AI. From above, AI is frustrating; from below, it's magical.
This was not always true and running rootless has been a benefit of Podman for a long time. Docker also does not run rootless by default afaik, thus making the attack surface greater by default.
The other main improvement of Podman over Docker is that Podman is daemonless and therefor is incredibly lightweight and portable.
Inertia I guess... We try. I managed to remove it everywhere in our stack in CI and such but in dev everyone is used to docker build.
And I don't have the energy for the team meeting to discuss a change.
And honestly docker compose has been ridiculously stable for us. 2+ services on seperate servers behind haproxy has been as stable as our Kubernetes Cluster for a fraction of the (intellectual) cost.
I mean, if you have zero experience with systemd, then yes. By contrast, if you've ever worked with any systemd unit files at all, then all the "systemd stuff" will be very familiar.
Which, if you're doing sysadmin type things on almost (e.g. not Alpine) any mainstream Linux distro in 2026, you should expect to encounter systemd unit files in your day-to-day.
I'm sorry but this is all just apologism/excuses. Docker's had rootless mode for 7 years. The attack surface is the local system, which always has a privilege escalation vuln of some kind, so Docker isn't a game-changer. And lightweight? I have never heard someone say "that Docker daemon is hogging all my resources".
The frequency of choosing to go out to the movies is also about how often I think "I wish I could do this in VR".
Examples:
- Before going on a trip, pre-visiting the destination in Google Earth with VR is very spatially informative & makes directional intuition memorable upon arrival at the real world destination.
- Virtual role-play with environmental cues that cause make-believe to be ever more real.
But most people don't need this very often. Picking up a book or throwing on some earbuds to listen to a book are far more frequent and compatible with simultaneous other activities. VR feels the same--a high-demand focused experience that is infrequently worth the effort.
