Hacker News Reader

Comment by dilap | Hacker News Reader

I half agree, but I also half-sympathize with them, because it really wasn't their fault -- it was a quite-bad bug in a very fundamental library.

Bugs happen, though. Especially in Python.

View on HN

Instead of spending engineering time, they used a free and open-source library to do less work.

The license they agreed to in order to use this library has this in capital letters. [THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND].

After agreeing to this license and using the library for free, they charged people money and sold them a service. And when that library they got for free, which they read and agreed that had no warranty of any kind, had a software bug, they wrote a blog post and blamed the outage of their paid service on this free library.

This is not another open-source project, or a small business. This is a company that got billions of dollars in investment, and a lot of income by selling services to businesses and individuals. They don't get to use free, no-warranty code written by others to save their own money, and then blame it and complain about it loudly for bugs.

> it really wasn't their fault -- it was a quite-bad bug in a very fundamental library.

It's still their fault. When you ship code, you are responsible for how that code behaves regardless of where the code came from.

Only for some incredibly broad definition of fault that almost no one uses.

How many people make sure all of the open source libraries they're using are bug free?

Anyone besides maybe NASA?

I've never cared per se that a library was bug free but I've put a lot of effort/$ into making sure the features that used the libraries in my product were bug free (with the amount of effort depending on the sensitivity of the feature, data, etc).

Usually "fix the original library" wasn't as easy or immediate a fix as "hack around it" which is sad just re: the overall OSS ecosystem but still the person releasing a product's responsibility.

Unfortunately these sorts of bugs are wildly difficult to predict. Yet it's also a wildly common architecture. That's what's sad for all of us as engineers as a whole. But "caching credit card details and home addresses", for instance, is... particularly dicey. That's very sensitive, and you're tossing it into more DBs, without good access control restrictions?

> Only for some incredibly broad definition of fault that almost no one uses.

It's a definition most laypeople use. It's developers who tend to use a very narrow definition.

I don't think it should be controversial to say that when you ship a product, you are responsible for how that product behaves.

Anywhere where you have payments related or any other PII data, then transitive dependencies, framework and language choices, memory sharing and other risks are taken into account as something that you as someone developing and operating a service is solely responsible for.

Anyone that has to pay from their own pocket when things go wrong, like consulting warranties, liabitiliy in security exploits,...

There have been several reports of this issue in Feb/early March on r/ChatGPT subreddit - OpenAI could have known if they listened to community.

Alternatively, they knew about it, and didn't fix the bug until it bit them

> Especially in Python.

as opposed to...?

Go, for one.

In my experience errors are more common (for both cultural and technological reasons) in Python than in Go.

I would guess something similar applies to Rust, though I don't have personal experience.

There's wide variation in C, but with careful discrimination, you can find very high-quality libraries or software (redis itself being an excellent example).

I don't have rigourous data to baack this stuff up, but I'm pretty convinced it's true, based on my own experience.

As opposed to not in Python.

… like JavaScript? Bash? C? PHP?

Certainly none of those are widely used and have a reputation for making it easy to keep the gun aimed squarely at the foot.

Those would be roughly similar. The main difference would be between dynamically typed interpreted languages and statically typed compiled ones I guess. At least I think I make less mistakes when the compiler literally tells me what's wrong before I even run the thing. It's awful and slow to develop that way, but it is more reliable for when that's a requirement.

So compared to ones like Kotlin or Rust.

it really was their fault. they chose to ship the bug. it doesn't matter in the last that someone else previously published the code under a license with no warranty whatsoever.

I was upvoting you, but then reading

> Especially in Python.

made me unvote.

Reply on news.ycombinator.com