• irotsoma@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    edit-2
    1 hour ago

    I mean this is pretty standard in all industries regardless of whether it’s a software flaw or a physical flaw in any other kind of product. What’s the likelihood of a vacuum manufacturer replacing a part in a 15 year old product that had a 1 year warrantee even if it’s a safety issue? Sure the delivery and installation is cheaper with software, but the engineering and development isn’t, especially if the environment for building it has to be recreated.

    • SplashJackson@lemmy.ca
      link
      fedilink
      English
      arrow-up
      2
      ·
      38 minutes ago

      I work for a manufacturer with part catalogues going back to 1921, and while the telegraph codes no longer work, you could absolutely still order up a given part, or request from us the engineering diagram for it to aid in fabricating a replacement. You can also request service manuals, wiring diagrams, etc. Don’t all half-decent manufacturers do this?

      • TheGrandNagus@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        14 minutes ago

        Don’t all half-decent manufacturers do this?

        No. That is phenomenally uncommon. To the point it’s almost unheard of.

      • SaharaMaleikuhm@feddit.org
        link
        fedilink
        English
        arrow-up
        9
        arrow-down
        1
        ·
        2 hours ago

        Companies should be forced to release all source code for products that are “EOL”. I will never change my mind on this.

      • tiredofsametab@fedia.io
        link
        fedilink
        arrow-up
        26
        ·
        7 hours ago

        May 1st 2024 was a decade ago? (The article has a list and only two are old as you mention, though not quite a decade yet)

      • Dran@lemmy.world
        link
        fedilink
        English
        arrow-up
        16
        ·
        7 hours ago

        Because that bug was so egregious, it demonstrates a rare level of incompetence.

        • NaibofTabr@infosec.pub
          link
          fedilink
          English
          arrow-up
          9
          ·
          7 hours ago

          that bug was so egregious, it demonstrates a rare level of incompetence

          I wish so much this was true, but it super isn’t. Some of the recent Cisco security flaws are just so brain-dead stupid you wonder if they have any internal quality control at all… and, well, there was the Crowdstrike thing…

          • Dran@lemmy.world
            link
            fedilink
            English
            arrow-up
            7
            ·
            edit-2
            5 hours ago

            Idk, this was kind of a rare combination of “write secure function; proceed to ignore secure function and rawdog strings instead” + “it can be exploited by entering a string with a semicolon”. Neither of those are anything near as egregious as a use after free or buffer overflow. I get programming is hard but like, yikes. It should have been caught on both ends

  • tal@lemmy.today
    link
    fedilink
    English
    arrow-up
    96
    arrow-down
    2
    ·
    edit-2
    9 hours ago

    I mean, some of those EOLed nearly a decade ago.

    You can argue over what a reasonable EOL is, but all hardware is going to EOL at some point, and at that point, it isn’t going to keep getting updates.

    Throw enough money at a vendor, and I’m sure that you can get extended support contracts that will keep it going for however long people are willing to keep chucking money at a vendor – some businesses pay for support on truly ancient hardware – but this is a consumer broadband router. It’s unlikely to make a lot of sense to do so on this – the hardware isn’t worth much, nor is it going to be terribly expensive to replace, and especially if you’re using the wireless functionality, you probably want support for newer WiFi standards anyway that updated hardware will bring.

    I do think that there’s maybe a good argument that EOLing hardware should be handled in a better way. Like, maybe hardware should ship with an EOL sticker, so that someone can glance at hardware and see if it’s “expired”. Or maybe network hardware should have some sort of way of reporting EOL in response to a network query, so that someone can audit a network for EOLed hardware.

    But EOLing hardware is gonna happen.

    • shininghero@pawb.social
      link
      fedilink
      English
      arrow-up
      9
      ·
      6 hours ago

      I think there should be a handoff procedure, or whatever you want to call it.

      As EOL approaches, work with whatever open router OS maker is available (currently OpenWRT) to make sure it’s supported, and configs migrate over nicely. Then drop one last update, designed to do a full OS replacement.

      Boom, handoff complete.

      • Brkdncr@lemmy.world
        cake
        link
        fedilink
        English
        arrow-up
        6
        ·
        5 hours ago

        I’d support a regulation that defines either an expiration date or commitment to open source at the time the hardware is sold.

    • db2@lemmy.world
      link
      fedilink
      English
      arrow-up
      43
      arrow-down
      2
      ·
      8 hours ago

      all hardware is going to EOL at some point, and at that point, it isn’t going to keep getting updates

      EOLing hardware should be handled in a better way

      Both of these are solved by one thing: open platforms. If I can flash OpenWRT on to an older router then it becomes useful again.

      • Rivalarrival@lemmy.today
        link
        fedilink
        English
        arrow-up
        21
        ·
        7 hours ago

        Bingo.

        Either support the device until the heat death of the universe, or provide consumers with the access to maintain it themselves.

      • thejml@lemm.ee
        link
        fedilink
        English
        arrow-up
        6
        ·
        edit-2
        7 hours ago

        Definitely don’t this in the past (Linksys WRT54G!) but let’s be honest, the kind of people running 10yo Dlink routers aren’t going to flash new firmware, let alone OpenWRT or even know to look for it. It would have to come that way from the factory. And even then I doubt most people even do regular updates, sadly.

      • BearOfaTime@lemm.ee
        link
        fedilink
        English
        arrow-up
        14
        arrow-down
        3
        ·
        9 hours ago

        Right?

        Something this old is going to be power inefficient compared to newer stuff, and simply not perform as well.

        I would know, I just booted up a 10 year old consumer router last night, because the current one died. It’ll be OK for a few days until I can get a replacement. Boy, is this thing slow.

        • metaStatic@kbin.earth
          link
          fedilink
          arrow-up
          4
          arrow-down
          1
          ·
          9 hours ago

          I have a netgear router that isn’t even that old and it doesn’t have gigabit ports.

          even though I was able to throw openwrt on there to mess around with it’s still e-waste

    • tabular@lemmy.world
      link
      fedilink
      English
      arrow-up
      5
      ·
      7 hours ago

      When the users are in control of the software running on their devices then “EOL” is dependent the user community’s willingness to work on it themselves.

  • sunbeam60@lemmy.one
    link
    fedilink
    English
    arrow-up
    5
    ·
    6 hours ago

    I moved to an OPNsense router a couple of years ago and I’ve never looked back. Hell is shitty consumer routers.

  • andyortlieb@lemmy.sdf.org
    link
    fedilink
    English
    arrow-up
    5
    ·
    edit-2
    7 hours ago

    Commodity hardware & open source software for the win.

    When my Western Digital NAS was never going to get critical security patches, I was so freaking glad to find out that they just used software raid… I threw the HDDs in a Debian server and never looked back.

    It’s certainly nice to have things that are turn-key, but if you can find your way around any OS, just avoid proprietary everything.

  • skillissuer@discuss.tchncs.de
    link
    fedilink
    English
    arrow-up
    11
    ·
    edit-2
    9 hours ago

    but does it run openwrt?

    e: no it doesn’t, only one model had half-baked image made and available for download from some sketchy forum post made in 2014

    • Deebster@infosec.pub
      link
      fedilink
      English
      arrow-up
      6
      ·
      7 hours ago

      I watched and enjoyed that one yesterday, and he’s bang on the money. People here are saying “well it’s EoL” but that means it’s got all the way through development and its full lifetime with such a prominent set of bugs.

      I don’t think I’ll be buying D-Link if that’s what supported means.

  • Someonelol@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    1
    ·
    6 hours ago

    Instead of trusting DLink with an off the shelf NAS, it might be easier to build your own with a Raspberry Pi running openmediavault hooked up to a couple of USB hard drives. It’s worked well for me for over 6 years now with no issue and could cost way less.

  • FutileRecipe@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    2
    ·
    8 hours ago

    Same website (granted, different author, but), same inflammatory language, same vendor, referencing previous erroneous article…I’m not even gonna read this one. Just going to copy/paste my previous response from the previous post:

    At a certain point it’s the consumer’s (and blog writer’s) fault, and that’s after EoL. Not patching a supported one and just getting rid of support, saying buy a newer one? Yeah, that’s bad.

    Continuing to not support an EoL model that you already don’t support due to EoL (or even dropping support for an EoL model that no one expected you to support in the first place due to EoL)? Non-issue.