Retro x86-based machine emulator 86Box v3.2 brings Linux support

Quoting: kokoko3kNope.
At least, not for me,thanks.
This is GPL 2.0 code that can be packaged by your distribution and installed and uninstalled by your package manager.
I can understand that for proprietary apps, or if you just need to test the software.
More appimages mean more bloat/useless duplication, more memory use.

Someone's already got a PKGBUILD in AUR (and -git version) I might try later; just because the 86box team offers a distro-agnostic AppImage doesn't prevent everyone else from doing the 'right' thing with their distro of choice. I'm sure someone'll have a PPA for Ubuntu users, too, in time, etc.

Quoting: Kithop

Quoting: kokoko3kNope.
At least, not for me,thanks.
This is GPL 2.0 code that can be packaged by your distribution and installed and uninstalled by your package manager.
I can understand that for proprietary apps, or if you just need to test the software.
More appimages mean more bloat/useless duplication, more memory use.

Someone's already got a PKGBUILD in AUR (and -git version) I might try later; just because the 86box team offers a distro-agnostic AppImage doesn't prevent everyone else from doing the 'right' thing with their distro of choice. I'm sure someone'll have a PPA for Ubuntu users, too, in time, etc.

I never said that.

Quoting: kokoko3kI never said that.

Apologies - I must have fumbled trying to trim down the quote on my phone :p Meant to be a reply to this one further up I think? https://www.gamingonlinux.com/2022/02/retro-x86-based-machine-emulator-86box-32-brings-linux-support/comment_id=220331

Either way - more just general info for anyone who might think their AppImage is the only route.

Quoting: Kithop

Quoting: kokoko3kI never said that.

Apologies - I must have fumbled trying to trim down the quote on my phone :p Meant to be a reply to this one further up I think? https://www.gamingonlinux.com/2022/02/retro-x86-based-machine-emulator-86box-32-brings-linux-support/comment_id=220331

Either way - more just general info for anyone who might think their AppImage is the only route.

That's not the one either ;). I don't think any one is protesting the devs of 86Box to provide an AppImage image at their web site for people to download and use. The discussion is more that we would like the regular distributions to include new software in their repos so that people could install them "the proper way" to avoid the problems of security and bloat.

Quoting: Hamish

Quoting: Purple Library GuySays it also supports doing various old Linux distributions. Maybe I could use it to play my old Loki games.

What is the support for GPU pasthrough like with this I wonder?

None I would imagine. It looks like they emulate various old graphics cards from the 80:ies up to VoodoFX.

Quoting: GeamanduraRepresenting all the noobs out there, and taking one for the team.

Could anyone kindly explain the difference between this, and DosBox? As long as I can run Transport tycoon and Sim city 2K and Mortal kombat in DosBox, what can I use this tool for?

DosBox emulates MS-DOS so you can run MS-DOS software like old PC games. This emulates various old style PC:s at the hardware level so you could install MS-DOS on it to turn it into a slower but very accurate version of DoSBOX but that would probably be way overkill. This is mostly for people wanting to play around with old hardware and not so much play old games.


Last edited by F.Ultra on 17 February 2022 at 11:24 pm UTC

Quoting: KithopSomeone's already got a PKGBUILD in AUR (and -git version) I might try later; just because the 86box team offers a distro-agnostic AppImage doesn't prevent everyone else from doing the 'right' thing with their distro of choice. I'm sure someone'll have a PPA for Ubuntu users, too, in time, etc.

Ok for the appimage, but also building a apt would cover most beginner populations. I never built a appimage or a apt myself, so I imagine that should be a hard task for devs to do it routinely?

I don't understand how it's such a mess to package something in linux. From a beginner point of view, the fact that each distro proposes its own packaging method looks like old proprietary OS trying to keep captive their pools of users and exclude the possibility to change.
Like for phone cables, we need a clear, stable common basement so that the free (like in freedom) exists, and at a level beginners can handle, not at a level that only kernel pros can manage.

Quoting: Kithop

Quoting: kokoko3kI never said that.

Apologies - I must have fumbled trying to trim down the quote on my phone :p Meant to be a reply to this one further up I think? https://www.gamingonlinux.com/2022/02/retro-x86-based-machine-emulator-86box-32-brings-linux-support/comment_id=220331

Either way - more just general info for anyone who might think their AppImage is the only route.

You quoted right, no need to apologies, but thank you anyway
What i didn't said is that a dev deciding to offer a package type doesn't prevent everyone from packaging it differently.
Like many, I think one of the advantages of linux is the centralization of the packages mantainance and I thank everyone involved in keeping the AUR alive (I use arch and mantain a bunch of PKGBUILDS there too).
But the fact that appimages and similar containers are surely handy and quick and, in the short term, appealing for users, may pose a threat to the established packaging ecosystem.
When an user sees an appimage and think: "Yay!", it means it prefers it over his distro package or, worse, it means there is no package for his distro or that the package for his distro have problems.
Appimages are not only the indication of the problem they try to patch, but the possibility that the patch itself will become its solution; they are (should be) not.
So my concern is not about the appimage itself, of course, but about more users starting to use them -> less interest versus distro packages -> less distro packages.

I hope to be too pessimistic here.


Last edited by kokoko3k on 18 February 2022 at 10:46 am UTC

Quoting: Geppeto35I don't understand how it's such a mess to package something in linux. From a beginner point of view, the fact that each distro proposes its own packaging method looks like old proprietary OS trying to keep captive their pools of users and exclude the possibility to change.
Like for phone cables, we need a clear, stable common basement so that the free (like in freedom) exists, and at a level beginners can handle, not at a level that only kernel pros can manage.

From what I know by using arch, packaging a software is not a mess at all.
If by mess you mean the fact that there are more package managers, well it is about choice/user tastes.
What you seem not to consider is that even if there was only a package manager, the packages would not be interchangeable between distros (you can't just take a package from arch, put it into manjaro and be sure it will work, even if both packages have the same format), this is because -say- the executable X contained in package P could have been built to use library L at version 3 while the executable P contained in package P2 could have been built to use library L at version 2 which is not compatible with version 3.
For the same reason, you can hardly hope to pick an updated package built for ubuntu 33 and make it run on ubuntu 10, same package manager, same distro, different dependancies. Nobody is

Quoting: Geppeto35trying to keep captive their pools of users and exclude the possibility to change.

If there is interest in a sofware, users are expected to ask their distro mantainers to package it, this is the saner way to use it.


Last edited by kokoko3k on 18 February 2022 at 2:53 pm UTC

Quoting: GuestThat doesn't mean there can't be popular approaches however, and actually it's highly likely that only a couple of package formats will be required (probably only .deb, and a tarball as a distro-agnostic approach) to cover the majority of users.

Just as an aside, I must admit to getting some small satisfaction when using Red Hat Linux 7.3 at how it was RPM packages that were the expected default with the software available at the time, with .deb packages being an afterthought. By the time I was using Fedora as my daily driver that had already switched outside of enterprise environments, so it did sometimes feel like you were being treated as a second class citizen.

Of course now I am on Arch with the wonder that is the AUR. I actually just setup vkQuake and Yamagi Quake II on my brother's new Pangolin laptop running Fedora 35, and I just got lazy and copied over the builds I made on my Arch machine using makepkg. These worked great, and better than the actually packaged version of Yamagi Quake II for Fedora which refused to play the music and videos properly.

Regardless of your preference for application delivery method (I prefer flatpaks, for instance), 86box looks like a neat tool for retro enthusiasts like myself.

To test this, I dug out my old OS/2 Warp 3.2 diskettes, and so far it performs better for old systems than using DosBox, Qemu, and Virtualbox. DosBox is fine if all you want to do is play old dos games, but I like to dabble in a bit of OS/2, OpenStep, IRIX, System V Unix and the like. And for that, DosBox just doesn't cut the mustard...