Comment by nurettin

4 days ago

> should never see production use.

I have an issue with high strung opinions like this. I wrote plenty of crappy delphi code while learning the language that saw production use and made a living from it.

Sure, it wasn't the best experience for users, it took years to iron out all the bugs and there was plenty of frustration during the support phase (mostly null pointer exceptions and db locks in gui).

But nobody would be better off now if that code never saw production use. A lot of business was built around it.

10 comments

nurettin

Reply
zdragnar  4 days ago

Buggy code that just crashes or produces incorrect results are a whole different category. In C a bug can compromise a server and your users. See the openssl heart bleed vulnerability as a prime example.

Once upon a time, you could put up a relatively vulnerable server, and unless you got a ton of traffic, there weren't too many things that would attack it. Nowadays, pretty much anything Internet facing will get a constant stream of probes. Putting up a server requires a stricter mindset than it used to.

jacquesm  4 days ago

There are minimum standards for deployment to the open web. I think - and you're of course entirely free to have a different opinion - that those are not met with this code.

  • nurettin  4 days ago

    Yes, I have lots of opinions!

    I guess the question at spotlight is: At what point would your custom server's buffer overflow when reading a header matter and would that bug even exist at that point?

    Could a determined hacker get to your server without even knowing what weird software you cooked up and how to exploit your binary?

    We have a lot of success stories born from bad code. I mean look at Micro$oft.

    Look at all the big players like discord leaking user credentials. Why would you still call out the little fish?

    Maybe I should create a form for all these ahah.