• 53 Posts
  • 37 Comments
Joined 3 months ago
cake
Cake day: April 25th, 2026

help-circle












  • Yes, but still important to keep in mind because it broke release expectations. Pop!_OS used release new versions every 6 months and then stopped releasing new versions while working on COSMIC and now only does LTS releases.

    And now that COSMIC is “done”, it’s still not quite clear when they will release 26.04. I actually just found a quote from the CEO of System76 where he said “Future Pop!_OS releases, starting with Pop!_OS 26.04 LTS, will now align with the Ubuntu LTS release timing (approximately two weeks after the Ubuntu release date)” but that obviously didn’t happen.



  • Pop!_OS gets Cosmic updates before they are even technically released.

    Pop!_OS packages are not cutting edge. They are based on Ubuntu LTS. They do keep some packages more up to date than Ubuntu, such as Cosmic, kernel, mesa. But the vast majority of packages are from Ubuntu LTS unmodified.

    Pop!_OS has also been lagging in using the latest Ubuntu LTS. They stuck to 22.04 for almost 4 years before releasing 24.04. It’s also not clear when they will update Pop!_OS to 26.04, but that should not take as long as 24.04.


  • We’ve heard from a lot of developers working on lower level system components that on package-based systems they can easily install niche command line tools for developers.

    …However, after some discussions with the Flatpak developers, we have a plan for how to approach the distribution of third-party tools and we’ve already began prototyping. We’ll share more about this soon in a dedicated post.

    I hope this system at least shares runtimes with Flatpak or else I will be severely disappointed. I’d be giddy if it’s actually a case of flatpak offiically supporting CLI tools. It already does, and does it well, just missing a tiny bit of plumbing.



  • Yes, the packaging mess that Atomic distros cause.

    I want a couple of functional things:

    • To be able to safely upgrade my system silently, without interruptions, and rollback of necessary
    • To know my system is not drifting away from upstream defaults and to restore it to a “factory” state
    • To sandbox applications

    I’d like to be able to do all that efficiently and cleanly too. Atomic systems generally fulfill those first two while traditional distros struggle, which is why I stick to Atomic distros.

    But whereas you can use a single package manager on Arch and get everything (albeit without easy sandboxing), Atomics keep adding more and more. Here’s your rpm-ostree, flatpak, toolbox, homebrew, sysexts, etc.

    I find sysexts particularly insulting because they regress so much on traditional packages for so little upside. Doesn’t even have dependency management.

    I would wish we would stop creating so many package managers and just focus on improving existing ones.

    In a more ideal world we would have something like

    • Distro based on Freedesktop runtimes
    • Flatpak that officially supports both GUI applications, CLI applications, and even daemons/services
    • Flatpak would also be able to reuse the Freedesktop runtimes of the host system



  • Certainly an interesting vulnerability, but one you shouldn’t worry about.

    If you do really care about sandbox security, the first thing I would recommend doing is globally blocking filesystem access to anywhere in your $HOME that runs script code, such as:

    • bash files like ~/.bashrc and ~/.bash_profile
    • ~/.local/bin and ~/bin
    • ~/.ssh

    I have a script that I use to control flatpak overrides and I do something like this:

    # paths to block
    GLOBAL_RESTRICTION_PATHS=(
        "~/.bash_logout"
        "~/.bash_profile"
        "~/.bashrc"
        "~/.profile"
        "~/.ssh"
        "~/.zshenv"
            "xdg-config/zsh"
        "~/.local/bin"
        "xdg-config/systemd"
    )
    
    # globally block these paths
    for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
        flatpak --user override --nofilesystem="$path"
    done
    
    # but allow some apps like text editors to access them
    for path in "${GLOBAL_RESTRICTION_PATHS[@]}"; do
        flatpak --user override --filesystem="$path" org.gnome.TextEditor
    done
    





  • novafunc@discuss.tchncs.detoLinux@lemmy.mlThoughts LMDE?
    link
    fedilink
    arrow-up
    3
    arrow-down
    1
    ·
    1 month ago

    I don’t think there’s much of a package up-to-date difference between LMDE and Linux Mint. Both Debian and Ubuntu LTS are released every two years. Ubuntu in even years, Debian in odd years. So every year they trade being more up to date.

    Main difference now is that Linux Mint has access to Ubuntu’s hardware ennoblement stack.