What’s new in security for Ubuntu 26.04 LTS? | Ubuntu
ubuntu.com
Here’s a concise excerpt you can use:> Ubuntu 26.04 LTS significantly raises the security baseline by strengthening defaults across every layer of the system without requiring manual intervention. Key improvements include production-ready hardware-backed encryption, post-quantum–aware cryptographic defaults, modern TLS configurations, and […]

Highlights

  • Rust rewrite of GNU coreutils and sudo-rs
  • TPM-backed Full Disk Encryption now considered stable
  • More secure services (don’t run as root if not needed, AppArmor profiles)
  • AppArmor prompting for snaps is still experiemental unfortunately
    • Nobody@lemmy.worldOP
      62·
      14 hours ago

      I can understand MIT being an issue in some cases. For example, VSCode is a proprietary fork of the MIT open-source Code. If Microsoft wanted, they could stop publishing the MIT open source version. Of course that code would still exist as MIT, but development would slow down without Microsoft.

      But I don’t see uutils being MIT as an issue. It’s primary goal is to be compatible with GNU coreutils. You can’t really rug pull a project with a goal like that. And permissively licensed utils have been around thanks to BSD and it’s never been an issue. You don’t see companies like Apple using proprietary forked versions as benefit. The “value” they add is higher up the tech stack with their own truly proprietary stuff or open stuff that encourages lock-in to its ecosystem, like Swift.

      • GnuLinuxDude@lemmy.ml
        5·
        11 hours ago

        And permissively licensed utils have been around thanks to BSD and it’s never been an issue.

        The distinction is that BSD coreutils are not attempting to be a drop-in 1:1 compatible replacement of GNU coreutils. The Rust coreutils has already accomplished this with its inclusion into Ubuntu 26.04.

        If I wanted a permissively licensed system, I’d use BSD. I don’t, so I primarily use Linux. I think citing a proprietary OS like macOS as a reason why permissively licensed coreutils are OK is kind of funny. It’s easy to forget that before before the GPL there were many incompatible UNIX systems developed by different companies, and IMO the GPL has kept MIT and BSD-licensed projects “Honest”, so-to-speak. Without the GPL to keep things in check, we’d be back to how things were in the 80s.

        So what’s next on the docket for Ubuntu? A permissively licensed libc?

    • Nobody@lemmy.worldOP
      8·
      15 hours ago

      Snap as a technology is so interesting and more versatile than other formats. It’s just unfortunate that Canonical is in charge of the project, they’ve made some baffling decisions and continue to shoot themselves in the foot.

      • ☂️-@lemmy.ml
        101·
        15 hours ago

        no closed down walled garden will ever be interesting or versatile

        • Nobody@lemmy.worldOP
          10·
          14 hours ago

          That’s part of what I mean. Snap could be so much more interesting and useful if not for Canonical doing stuff like only allowing one store and slacking on proper support for non-AppArmor distros.

          One of the more bizarre experiences I’ve had is that a Canonical employee packaged a version of a Minecraft launcher. It was absolutely garbage, didn’t even start. The first thing that comes to mind is that snap is just garbage. But for fun, I made my own package of it, and it just worked perfectly. Which just leaves me the question of why a Canonical employee who works on snap can’t create a good snap package.

          There’s also the weird fact that Ubuntu dropped the ball with its core24 runtime. For some reason, Canonical’s own snaps stuck to core22 up until this month. Like, why wouldn’t they upgrade to their latest runtime? If there was an issue with it, why has it been broken for 2 years? Doesn’t inspire trust.