GNOME Boxes lead developer Felipe Borges has been overhauling the application with a major rewrite and today announced the new beta release. GNOME Boxes has migrated to using the GTK4 toolkit and libadwaita. The new GNOME Boxes code can also handle installing Microsoft Windows 11 now without needing any manual workarounds for Secure Boot or TPM requirements.

The new GNOME Boxes code also introduces a VSOCK device for accessing VM contexts and other improvements. With the revamped GNOME Boxes, it's also shifting to a Flatpak-first and only model for distributing of new GNOME Boxes releases.

all 41 comments

sorted by: hot top controversial new old
[–] 13 points 3 weeks ago (2 children)

I will stick with Virtual Machine Manager. They both use the libvert back end and qemu, but gnome boxes is way too dumbed down.

  • source
  • hideshow 4 child comments
  • [–] 1 point 3 weeks ago

    You can't even access the LAN on gnome boxes. I searched for workaround for many hours but found no solution. Many of the solutions included modifying the box with VMM anyway.

    Maybe boxes is only good for using Microsoft office...

  • source
  • parent
  • [–] 10 points 3 weeks ago* (last edited 2 weeks ago)

    I gave up with boxes many years ago as it would not restore vms from snapshot reliably, something I use a lot.

  • source
  • [–] 8 points 3 weeks ago (1 child)

    Great. Love the improvement.

  • source
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago (1 child)

    I just don't understand some of the downvotes on Lemmy. It's happened to me too. I wrote what I thought was an entirely positive post without anything controversial and one person downvoted me. I wonder if this is some cultural thing that came over from Reddit.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 3 weeks ago (1 child)

    i REALLY needed this when my everything server was running since i managed it headlessly using vnc w a minimal installation of gnome.

    virt-manager works okay, but it would be nicer not to have to install more than what's needed for a headless setup.

  • source
  • hideshow 2 child comments
  • [–] 13 points 3 weeks ago (1 child)

    You can use virt-manager over ssh, and you only need libvirt installed so probably already good if it's a vm host. It works better for me than a full gui over vnc.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago (2 children)

    i tried that with x forwarding over ssh and it didn't work all that well; what's why i switched to vnc.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 6 points 3 weeks ago (2 children)

    Like arsecroft says, virt manager has this ability built into the application itself. You add another session to the ui and choose ssh. No X forwarding needed, no gui needed on the server at all, don't need the virt manager app on the server just the client. Cockpit also works as a web based ui.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 4 points 3 weeks ago (1 child)

    NICE! i didn't catch that part and thank you for making me aware.

    i did try cockpit and i had better luck with it too.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago (1 child)

    If you give it a shot make sure you use an ssh key, it doesn't like passwords.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago

    Oh that's good to know. I've got roughly the same VNC setup with virt-manager, so I'll have to try it out. I would get rid of this VM if I could, but it runs CI for my Windows builds. Since I daily Linux now, it's the only way I'll know if I break MSVC.

  • source
  • parent
  • [–] 5 points 3 weeks ago (2 children)

    This rewriting almost killed the project and I still fear for Bottles.

  • source
  • hideshow 4 child comments
  • [–] 4 points 3 weeks ago (1 child)

    what's going on with Bottles?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago* (3 children)

    Bottles Next, the successor of the current Bottles is in development. Of course it's a Rust rewrite. 🤦‍♂️ The project has slowed down since then considerably.

  • source
  • parent
  • hideshow 6 child comments
  • [–] 2 points 3 weeks ago (2 children)
  • [–] 2 points 3 weeks ago (1 child)

    Not rust itself, it is a great language with lot of upsides. The problem is the rewirte part. A lot of projects underestimate the burden of rewriting your code from the ground up. A lot focus power on a "new and improved codebase" that is never finished while to old codebase isn't properly supported anymore due to the focus on the rewrite. Rust is just notorious for these kind of rewrites as ist a fast and memory safe language where a lot of developers see advantages for their project (sometimes rightly so).

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago (1 child)

    they also got distracted by a project rolling their own distro instead of focusing on Bottles. same fate has befallen lutris

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago* (last edited 3 weeks ago) (1 child)

    I may aswell ask here: suppose I have a bunch (like, a lot of them) of Wine / Proton prefixes managed by Botttles and want to move on with the least of hassle, keeping these prefixes and my preferences intact. Is this possible with some other solution? I'm not a strict gamer, my prefixes have more productivity applications than games per si. So I didn't look into Steam, Lutris, etc.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago (3 children)

    I avoid Bottles out of principle because one of the devs doesn't understand what open source means and harasses distros to remove older versions.

    https://github.com/bottlesdevs/Bottles/issues/2345

    Also referring to "inferior package manager" in that post.

    Same dev harassed Mint for shipping Gnome Calendar in their repositories.

    https://gitlab.com/linuxmint/pins/mint/gnome-calendar/-/work_items/1

  • source
  • parent
  • hideshow 6 child comments
  • [–] 9 points 3 weeks ago (1 child)

    The issue seems to be mostly about the support overhead from really outdated versions still shipped to the public. This seems to be a legitimate concern and why I avoid the distros in question myself.

    The issue about "inferior" package managers is not that wrong as well. Version mismatches between dependencies is a big issue in development and why stuff like docker, nix and even atomic desktops are so successful.

    I'm a big fan of the classical package managers, especially for my base system but the overhead on developers and packagers is definitely not negligible especially if they use pre release versions of dependencies like bottles did.

    Lastly I completely get that you don't like the tone, the mint/home calendar issue was, while I get the concern, a hard read

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 3 weeks ago (1 child)

    If you’re shipping an out of date package with your own customizations then uses should at least be redirected towards your own bug tracking services instead of sending them to waste the maintainers time on bugs that either have already been fixed or aren’t present without the tweaks applied by the distribution.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago (1 child)

    You can't prevent people from using older versions. New versions need to be tested, by the time this process is finished, upstream already released a newer version.

    If you use the talking point of "own customizations", did you get that from the mint thread and did you read it through? Software should come as is, but in some cases devs work slower or have other priorities so I understand bugs get fixed some other way. The whole pipeline from dev to user isn't as simple as you think.

  • source
  • parent
  • hideshow 2 child comments
  • I had read a blog post about this conflict a week or two ago (and I just pulled up an article by a gnome maintainer to refresh on details).

    People are of course allowed to use older versions, but if a distribution, by policy, lags significantly (2-4 years) behind the normal release schedule of a piece of software it distributes, while at the same time leaving feedback pointed towards the original devs, it creates a completely unnecessary burden on the developers.

    And regarding the “modifications”, it appears like mint had used the GTK4 library libAdapta instead of libAdwaita now several versions ahead of libAdapta. I don’t know how extensively this effects that app but the point is the user facing experience of the software is being modified by mint. I don’t believe it’s unreasonable for the maintainers to take the responsibility of handling bug reports and such, even if it just acts as a filter for relevant bugs to be reported upstream.

  • source
  • parent
  • [–] 4 points 3 weeks ago
    [–] 1 point 3 weeks ago (1 child)

    What was wrong with the old Boxes?

    It didn’t support containers or the more advanced features of libvirtd like virt-manager does, but it seemed fine for what it was the couple of times I tried it out.

  • source
  • hideshow 2 child comments
  • [–] 2 points 3 weeks ago (1 child)

    The main issue is that old Boxes is based on SPICE. It was/is a Red Hat project, but they stopped caring for it and deprecated it. So old Boxes is built on legacy tech that will pretty much just bit rot over time.

  • source
  • parent
  • hideshow 2 child comments