• 0 Posts
  • 198 Comments
Joined 1 year ago
Cake day: August 17th, 2023
  • FooBarrington@lemmy.worldtomemes@lemmy.world•We're being short-sighted
    2·
    8 days ago

    I’m 100% with you - it’s the dangerous level of knowledge where someone understands the technical background for the most part, but is lacking real world experience. Reminds me of the blog posts titled “Misconceptions programmers have about X” - almost everything we touch in IT is complicated if you get deep enough.

    But their style of commenting really jives with Lemmy on technical topics. I can’t count the number of posts where people proudly shout fundamentally wrong explanations for current AI models, yet any corrections are downvoted to oblivion. It’s not as bad on non-AI-topics, but I can’t imagine anyone in the field reading GPs comment and agreeing…

  • FooBarrington@lemmy.worldtomemes@lemmy.world•We're being short-sighted
    4·
    9 days ago

    I think you might be underestimating the potential impact.

    Remember the Crowdstrike Windows BSOD? It caused billions in damages, and it’s the absolute best case scenario for this kind of issue. Our potential Y10K bug has a bunch of additional issues:

    • you don’t just have to patch one piece of software, but potentially all software ever written that’s still in use, a bunch of which won’t have active maintainers
    • hitting the bug won’t necessarily cause crashes (which are easy to recognize), it can also lead to wrong behavior, which will take time to identify. Now imagine hundreds of companies hitting the bug in different environments, each with their own wrong behavior. Can you imagine the amount of continuous supply chain disruptions?
    • fixes have to be thought about and implemented per-application. There’s no panacea, so it will be an incredible amount of work.

    I really don’t see how this scenario is comparable to anything we’ve faced, beyond Y2K.

  • FooBarrington@lemmy.worldtomemes@lemmy.world•We're being short-sighted
    5·
    9 days ago

    Even if such parsers aren’t used directly in critical systems, they’ll surely be used in the supply chains of critical systems. Your train won’t randomly derail, but disruptions in the supply chain can cause repair parts not to be delivered, that kind of thing.

    And you can be certain such parsers are used in almost every application dealing with datetimes that hasn’t been specifically audited or secured. 99% of software is held together with duct tape.

  • FooBarrington@lemmy.worldtomemes@lemmy.world•We're being short-sighted
    17·
    9 days ago

    My brother in Christ, there’s more to time than just storing it. Every datetime library I’ve ever used only documents formatting/parsing support up to four year digits. If they suddenly also supported five digits, I guarantee it will lead to bugs in handling existing dates, as not all date formats could still be parsed unambiguously.

    It won’t help you if time is stored perfectly, while none of your applications support it.

    Regarding Y2K, it wasn’t horse shit - thousands upon thousands of developer hours were invested to prevent these issues before they occurred. Had they not done so, a bunch of systems would have broken, because parsing time isn’t just about displaying 19 or 20.