There was probably a lot going on behind closed doors, but from the outside, it appeared that RedHat was trying to improve the security and technical details of containers, but Docker was just refusing pull requests and not playing nice. This eventually drove RedHat to make their own implementation (i.e. Podman), so it was a self created enemy and not necessarily one that was built-in/inevitable.
I'm definitely not a fan of RedHat's moves since being acquired, but at least from the outside, this looked like Docker being arrogant and problematic and not a "RedHat problem".
I am painfully aware of that narrative. All I can say is that it is a false narrative, deliberately pushed by Red Hat for competitive reasons. There was a deliberate decision to spend marketing dollars making Docker look bad (specifically less secure), at a time where we were competing directly in the datacenter market.
Ask yourself: how many open source projects reject PRs every day because of design disagreements? That's just how open source works. Why did you hear about that specific case of PRs getting rejected, and why do you associate it with vague concepts like "arrogance" and "insecurity"? That's because a marketing team engineered a narrative, then spent money to deploy that narrative - via blog posts, social media posts, talks at conferences, analyst briefings, partner briefings, sales pitches, and so on. This investment was justified by the business imperative of countering what was perceived to be an existential threat to Red Hat's core business.
It opened my eyes to the reality of big business in tech: many of the "vibes" and beliefs held by the software engineering community, are engineered by marketing. If you have enough money to spend, you can get software engineers to believe almost anything. It is a depressing realization that I am still grappling with.
The most damning example I can give you: we once rejected a PR because it broke compatibility with other platforms. Red Hat went ahead and merged it in their downstream RPM package. So, Fedora and RHEL users who thought they were installing Docker, were in fact installing an unauthorized modified version of it. Later, a security vulnerability was discovered in their modified version only, but advertised as a vulnerability in Docker - imagine our confusion, looking for a vulnerability in code that we had not shipped. Then Red Hat used this specific vulnerability, which only existed in their modified version, in their marketing material attacking Docker as "insecure". That was an eye-opening moment for me...
If it is pure marketing, I wonder why docker couldn't play the same game and be better at it?
E.g. for your most damning example: If docker published this story, blogged about it, made noice in places like HN, it is exactly what the press would love: RH breaks docker security while claiming to be more secure! The Emperor has no clothes! If you take security serious, accept no fake substitutes!
In any case I meant it in an informal software engineering sense: it's bad form for a packager to distribute upstream software under its original name, with substantial modifications beyond what users would expect distro packagers to make - backporting, build rules, etc.
For such a downstream change to introduce security vulnerabilities is a major fuckup. To actively blame upstream for said vulnerability, while competing with them in the market, is unethical.
Arrogance was what actually killed them. They picked fights with Google and RedHat and then showing up at conferences with shirts that said "we don't accept pull requests" tipped the scales so that RedHat and Google both went their own way and their technology was now pushed out of 2 of their biggest channels.
(I don't know of any T-shirts saying "we don't accept pull requests". That sounds made up. We very much did accept pull requests... a great many of them).
I've been working with Intel to fix an issue in recent GPU drivers that prevents HEVC playback from working and I believe that's the real issue here rather than the licensing conclusion that this article jumps to.
This feels like a very sudden abrupt change and breaking the build for all old branches/tags feels so odd for such a critical component of the build process for GitHub Actions
Once they get a MacBook Air with an M4, it will become a viable option for developers and other users that want/need 2 external monitors. Definitely looking forward to that happening.
The sensor support added to watchOS 10 is really nice and the live displays of cycling stats in iOS 17 has made it so I can use my phone for stats and feedback while on bike rides
I mean, ok? It's a weird move that doesn't seem to have much of a market, IMO.
I don't know any serious cyclist who uses a phone as a head unit, though.
People just starting out often do, and are mostly using an app like Strava to display speed and track the ride, but once they get into the hobby much further they'll buy a Garmin or Wahoo or Karoo and use that. This purchase seems to come soon after the tight pants and clipless pedals, but not LONG after.
A purpose-built device is a better choice for plenty of reasons.
- Phone batteries are better now, but keeping your screen on for 60 miles is not a great move IF you also want to be sure you can use your phone for calls.
- Device screens are optimized for the kind of direct-sun, off-angle reading you're doing on a bike. Phones work less well.
- Phones are big and awkward compared to even the largest bike computers, which makes for a goofier mounting situation.
Using a phone for navigation on a motorcycle makes a little more sense, because you can have a power feed, and there's more room in the cockpit (typically).
What’s your thought on that air quality monitor released by Amazon? I’d love to see the cost come down even more, but it looks like the most affordable option on the market right now
The Brian Kernighan quote explains this very simply:
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
