• Mio@feddit.nu
    link
    fedilink
    arrow-up
    0
    ·
    14 hours ago

    And cloudstike did never happen…

    I have Timeshift setup for fast and easy rollback.

    Bad updates will happen to any OS. It is about if you want to update fast and having a rollback plan. There are dostros that updates more slow as they actually do their own testing and hence was not affected at all.

    For me the lock screen instructions worked fine. The kernel update only broke Ghostty but a workaround fix was available the same day. I could also just have booted into the older kernel from Grub.

    • MudMan@fedia.io
      link
      fedilink
      arrow-up
      0
      ·
      13 hours ago

      It did happen, but that wasn’t an OS update, it was a third party update that bricked the OS. The fact that it could do that exposed some Windows practices that are a bigger deal than Linux’s general jankyness when they happen, but they also surface less often for end users.

      I thought this particular boo-boo was revelatory because Linux is relatively on the ball anticipating updates breaking the system entirely (one wonders if it should have to be, but whatever). But this was a widespread but specific issue within a random system component. Without googling for it an end user wouldn’t immediately understand what’s going on, and even then there was a fair amount of confusion for at least a day. There wasn’t “a workaround”, there were serveral, as normies and newer users struggled to understand what had broken and how to fix it, and people weren’t very clear in reporting what worked and what didn’t. This all happened within forums and bug reports, with no central source of information or even a centralized official organization informing of the status. Definitely not how that would have played out in a commercial environment, for better and worse.

      Also, this is a slight tangent, but can I flag a couple of frequent Linux community behaviors you’re engaging in here that I wish we would get rid of?

      One, “it works in my machine” is a meaningless statement. It adds nothing to the conversation and it doesn’t mean the issue is less important. It works on your machine, your version or your distro but not in others. That is every bug, it adds no useful information. In this case, a static screen contains specific instructions that report a common default but don’t match implementation on every distro, so this warning screen isn’t always accurate. That, in itself, is a problem.

      Two, “here’s all the smart stuff I did to fix it” (or the smart stuff I do to prevent it) is also entirely useless. The issue came and went, everybody fixed it. The goal isn’t to work around the OS or the DE’s jankiness, it is to have it not be janky in the first place. Putting the onus on the user to fix the shortcomings of the product is… a mitigation, I guess, but the goal is to compete with the paid alternatives on a mass scale, which has different requirements. Complaints about a wonky area of Linux shouldn’t be dismissed or excused with offers to teach people manual workarounds or even best practices, they should be addressed with fixes from the developers of the components that have issues.