4 ms·

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,

by dilap 4y ago

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.

airstrike 4y ago
> Especially in Python. as opposed to...?
- moffkalast 4y ago
  As opposed to not in Python.
  - deathanatos 4y ago
    … 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.
    - moffkalast 4y ago
      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.
- dilap 4y ago
  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.
kljhghfgdfjkgh 4y ago
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.
JohnFen 4y ago
> 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.
- JamesBarney 4y ago
  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?
  - majormajor 4y ago
    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?
  - JohnFen 4y ago
    > 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.
  - rschoultz 4y ago
    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.
qwertox 4y ago
I was upvoting you, but then reading > Especially in Python. made me unvote.
gkbrk 4y ago
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.

by dilap 4y ago

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.

airstrike 4y ago

> Especially in Python. as opposed to...?

moffkalast 4y ago
As opposed to not in Python.
- deathanatos 4y ago
  … 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.
  - moffkalast 4y ago
    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.
dilap 4y ago
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.

kljhghfgdfjkgh 4y ago

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.

JohnFen 4y ago

> 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.

JamesBarney 4y ago
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?
- majormajor 4y ago
  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?
- JohnFen 4y ago
  > 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.
- rschoultz 4y ago
  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.

qwertox 4y ago

I was upvoting you, but then reading > Especially in Python. made me unvote.

gkbrk 4y ago

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.