• LovableSidekick@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    edit-2
    3 days ago

    Getting ready to go back to Linux, just waiting to get some other stuff out of the way. Taskbar autohide on my Win10 box stopped working this morning. Minor annoyance, I looked it up and found a simple fix - restart the Windows Explorer process. Okay, did that, autohide started working. Bur srsly, the taskbar is almost 30 years old, low-level shit like this SHOULD JUST WORK. Now 12 hours later I just noticed it’s not working again. What the Actual Fuck, guys? Unbelievable.

    • ordellrb@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      2 days ago

      And for some reason the file Explorer and the Desktop/Taskbar are connected and you can end up with just a black Screen

    • 0^2@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      0
      ·
      3 days ago

      chkdsk /scan If any errors found, stop and /f them

      Then:

      DISM.exe /Online /Cleanup-image /Restorehealth

      Finally:

      sfc /scannow

        • DacoTaco@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          3 days ago

          Sure, but then they shouldnt complain. Stuff break on linux too and when fixing them you also often have to open a terminal. When things are broken, a terminal is often the goto on any system…

        • madeline@lemmy.blahaj.zone
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 days ago

          yes, it is. those are pretty much the definitive windows commands to try to fix random stuff like this too, if they fail then it’s reinstall time lmao

    • Neshura@bookwormstory.social
      link
      fedilink
      English
      arrow-up
      0
      ·
      3 days ago

      Technically yes but (without reading the article) going by what drivers were removed previously any affected device has been incompatible with modern linux kernels for a while so this probably doesn’t affect anyone’s experience using linux

  • ayyy@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    3 days ago

    Have you seen old 80’s-90’s style C driver code? Lines of code is an even more terrible metric for this than it usually is.

    • somtwo@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      3 days ago

      I think the fact that any old code is being removed at all is a good thing. The point of the post (at least from my perspective) is that deleting old code is something necessary for prolonged support of a codebase and it’s not something Microsoft is or maybe even ever will prioritize.

  • finitebanjo@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    4 days ago

    I’m sure a lot of people started taking unnecessary code executed at low levels a lot more seriously after the Crowdstrike fiasco.

    • Tux@lemmy.worldOP
      link
      fedilink
      arrow-up
      0
      ·
      4 days ago

      Well, Windows implemented kernel-level protection to prevent another Crowdstrike situation. lt actually makes kernel-level game anti-cheats to break.

      • far_university190@feddit.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        3 days ago

        Source? I only see thing about not do that. Maybe plan (unsure?), but not done.

        https://blogs.windows.com/windowsexperience/2024/09/12/taking-steps-that-drive-resiliency-and-security-for-windows-customers/

        ESET: … It remains imperative that kernel access remains an option for use by cybersecurity products to allow continued innovation and the ability to detect and block future cyberthreats.

        another based on above:

        https://www.gamingonlinux.com/2024/09/microsoft-windows-kernel-changes-dont-suddenly-mean-big-things-for-linux-gaming/

        One that has been really doing the rounds lately, especially across Reddit and other social media is from Notebookcheck, with a rather sensational article title of “Microsoft paves the way for Linux gaming success with plan that would kill kernel-level anti-cheat”.

        Here’s the thing: Microsoft don’tactually say they will kill off kernel-level access, and if they tried that (again - they tried with Vista before), they will no doubt again face some pretty serious push-back from both cybersecurity vendors and regulators across various countries. Something that would likely be more hassle than its actually worth. What Microsoft doactually talk about, is providing additional options that are outside of kernel mode - a whole new platform to “meet the needs of security vendors”.

        • far_university190@feddit.org
          link
          fedilink
          English
          arrow-up
          0
          ·
          3 days ago

          Nope

          https://www.gamingonlinux.com/2024/09/microsoft-windows-kernel-changes-dont-suddenly-mean-big-things-for-linux-gaming/

          This new security platform, if vendors chose to actually go ahead and use it, could mean the oppositefor Linux gaming, and cause a whole bunch of new headaches when it comes to supporting it regardless of it being via Native Linux games, or Windows games through Wine and Proton. So if anything, I would say that rather than paving the way for Linux gaming to get better, it’s just going to be another hurdle. As annoying as that is.

          Just because some things may move out of the kernel-level, also doesn’t mean things will suddenly work on Linux (or get any easier to support via Wine / Proton). There will be various ways for developers to detect Linux, and continue to block it.

          Just look at Destiny 2 as the easy and simple example here, they very clearly check for and completely block Linux platforms from playing Destiny 2 via Proton with no way around it.

          Roblox is an additional easy example here to really make the point. Their latest anti-cheat is not kernel level, and completely blocks Linux. Something doesn’t need to be in the kernel to block Linux-based systems.