zbentley

I remember Postgres in the early 2000s. And early Mongo. And many others.

And bugs like “WHERE 4 = 5”, or selecting from nonexistent columns, or selects permanently modifying table behavior, or any of a dozen others that Jepsen found … didn’t happen in released databases. Even young ones.

Prior to the age of LLMs, that level of bugginess wasn’t “everything has growing pains”. That’s the kind of thing previously associated with poor undergraduate CS homework or “the CEO’s kid wrote our database” corporate horrorshows.

> with no QA

That’s not immaturity. That is a choice. A “the car we are selling does not have airbags, seat belts, or brakes” kind of choice.

> Maybe you don't know too much about engineering

Save it. You have no idea what you are talking about.

The principal values of things like the Jepsen reports is to the community of potential users/purchasers.

I agree with GP, that vendors should be somehow required or very strongly encouraged to participate in such audits. Not because they want to (as you say, most wouldn't like their dirty laundry aired thus), but because consumers deserve to know. U.S. government software groups don't like FISMA/RMF audits either, but they have to do them anyway.

I do not know in what order Kyle et al. wrote the report, but as I progressed through different parts I think I could detect instances of an increasingly fatigued/disheartened/unhinged tone--without compromising the professionalism we expect from Jepsen analyses, of course. These moments of humanity brought me joy.

More cynically, I suspect that many low-quality database projects succeed or fail based more on marketing and hype than robustness. A dishonest product could simply take the line "engineers at Orkes were able to produce a highly sophisticated database system" from the report out of context, quote it on their homepage attributed to aphyr/Kyle/Jepsen, and reap short-term rewards and popularity. I hope I'm wrong.

Hard disagree. Software is designed to be run. If a developer is not experienced at running the software they write, they are necessarily much less effective than a developer who is.

That’s not to say you can’t have operations experts or ops-only roles. You can. But if the developers don’t participate in operations at all, they are doing themselves and the business a disservice.

It’s exactly like having a chef who doesn’t taste food, or a car mechanic that doesn’t drive. Some savants exist who can do good work even then, but they’re vanishingly rare.

You're not wrong, but both "nobody should be using musl" and "nobody's forcing you to use a full-fat distro image" often run into the reality that the choice of base image, security posture, and libc/linkage environment for distributables are, by policy or technical requirements imposed by third parties, not under the control of the person who is trying to make Docker images behave.

That, and I think the cache busting based on CPU/environment probing logic will need to be significantly improved. Any difference in CPU features should not bust the cache; specific differences should bust the cache.

There also might be a need for "downgrading" cross-compilation profiles a la "don't compile/AOT-cache this app for the current CPU, compile/cache it for <the kind of CPU that I have 10k EC2 instances running>". You'd think that would be easier to achieve by just compiling on a production-like machine, and you'd be disappointed by the number of shops running Java apps hand-built on a Windows laptop across millions of cloud Linux cores.

Agreed, but that's not really relevant to the GP, who was comparing Java deployment ease vs. other platforms. NPM hell doesn't make deployment hard (quite the contrary); it makes security and stability/maintenance hard.

Server-Side/Desktop JavaScript, I think, has a much better/more polished deployment experience than Java...at the cost of having a much worse build (ES module hell, bundler hell...) and maintenance (dependency hell, security hell, constantly changing APIs hell...) experience than Java, which excels at both of those.

At least there's that :)

…which is still limited compared to IOCP. I’d love to be able to wait for locks, semaphores, etc. using uring. But no, even if you fall back to POSIX semaphores, the “everything is a file” paradigm has far too many asterisks to deliver on its promise.

Pop quiz: across all kinds of FDs (including block files, dirfds, sockets, signalfds, eventfds, lock descriptors, /proc files, tmpfs files, timerfds, and so on), which features of {select/epoll, io_uring, O_NOBLOCK, inotify/fanotify, etc.} are supported?

> which was selling people only for people that either don't understand docker layers or can't make Dockerfile correctly.

...or people who had a test/deploy/debug cycle on environments that necessarily had no layer cache (ephemeral VMs, one-shot kubernetes clusters, OpenWRT routers that lost the layer cache on reboot). Or people with network-constrained traffic from registries or mirrors thereof.

Or people in environments that took container security findings (perhaps too) seriously and were tired of triaging endless reports for random dependencies in "FROM ubuntu" containers, and wanted a default required-by-policy base image that didn't come with the world.

Or people who needed a relatively full-featured build environment against musl without having to do bizarre incantations in e.g. a Fedora image to switch away from libc while still being able to link against other system libraries.

Sometimes--very rarely--one's ethics may dictate not taking it, as with the "fork" email to U.S. Federal Government employees. Or when an early-stage company layoff is being done in tandem with a buyback/tender to reduce employee ownership before the board does something crazy.

Most of the time, though, you're right. Take it.

Sort of. If they can rely on differentiation and loyalty now, pre-IPO, from their large-but-cheap customer base, they can focus their growth on serving enterprise/other markets, and lean on their existing base as a low-churn-risk (compared to the rest of the AI ecosystem) customer and marketing surplus. Focus is good.

All true and fair. But I do like having the instrumentation API in your code speak wide events. Then have your telemetry config decide what you want to transmit as a verbatim big event, what you want to sample/transmit as a metric, or a trace (or whether you, at the moment of transmission, need to go grab a few things out of the local tracing context stack and use them for preprocessing), and so on.

If you do all that on the client side (not in a sidecar, ideally: actually in your client code when deciding what to transmit) you have a fairly nice way to temporarily turn on e.g. rich trace recording to hunt a bug, or start spraying event bodies to a local file when debugging a troublesome service instance, and so on. The rest of the time, things can transmit a few big payloads and a lot of small metrics, and things stay cheap.

In other words, it's easy to go from "recorder.record_rich_typed_event(...)" to capturing any or all of events, traces, metrics, or logs. It's not easy to go from e.g. "metrics.record_integer_metric("somemetric", 15)" to recording a richer, more complex event in a pinch.