144
GNOME Boxes Preparing To Deliver Much Improved Virtualization Experience
(www.phoronix.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 03 Aug 2026
144 points (98.6% liked)
Linux
66833 readers
75 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 7 years ago
MODERATORS
This rewriting almost killed the project and I still fear for Bottles.
what's going on with Bottles?
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.
Whats wrong with rust?
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).
Ah, makes sense, thanks! I can imagine small projects must be careful. On the other hand if someone does it for fun and learning that is fine even despite the risk of not finishing :)
Heute nicht, Mann. Kein Bock auf den Scheiß.
they also got distracted by a project rolling their own distro instead of focusing on Bottles. same fate has befallen lutris
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.
ive added existing prefixes to heroic without issue so far
Maybe a fork is in order by new devs who will do good with it
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
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
I'm not arguing any of that. Package maintainers are doing invisible and often thankless work. The way this person communicates really struck a cord.
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.
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.
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.
Wow "the users are too stupid to deserve my package". What a dick take.