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

They went with AppImage for Linux so it should run across most major distributions.

I wished more devs wold opt for this for their software. Some things shouldn't need you to plug a new repository, compile code or anything that requires a admin password. Just run it from the Download folder without much fuss.

I can hear the security minded folks furiously typing right now, but remember, I said "some things", not all apps.

They went with AppImage for Linux so it should run across most major distributions.

I wished more devs wold opt for this for their software. Some things shouldn't need you to plug a new repository, compile code or anything that requires a admin password. Just run it from the Download folder without much fuss.

I can hear the security minded folks furiously typing right now, but remember, I said "some things", not all apps.

I agree with "some things", not sure if this type of application fits that category, for me that is. However I think the main problem is that distros don't add new software to their repos until they release a new version of the distro, sometimes I wish that they would just add new interesting software to the existing repos as long as they don't come with dependency breaking stuff.

They went with AppImage for Linux so it should run across most major distributions.

I wished more devs wold opt for this for their software. Some things shouldn't need you to plug a new repository, compile code or anything that requires a admin password. Just run it from the Download folder without much fuss.

I can hear the security minded folks furiously typing right now, but remember, I said "some things", not all apps.

Nope.
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.


Last edited by kokoko3k on 17 February 2022 at 4:52 pm UTC

QEMU clearly prioritizes emulating modern systems, so it's becoming harder and harder to getting stuff like BeOS or Windows 3.11 running. This sounds like a much better option for those computational niches!

Dev: Hey, take a look at this new interesting software I just released.
Linux users: Screw that! Let's argue about how the software is packaged and distributed instead!

Says it also supports doing various old Linux distributions. Maybe I could use it to play my old Loki games.

Representing 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?

Representing 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?

Super over-simplification:
DOSBox is for running games mostly from the late 80's to the mid nineties etc. This if for when you want to your software to think you're running some sort of IBM PC or PC Compatible (Clone) which did run DOS but also ran any number of other tools. Think of this as more of a VM like platform rather than a games playground like DOSBox.

Dev: Hey, take a look at this new interesting software I just released.
Linux users: Screw that! Let's argue about how the software is packaged and distributed instead!

Of course, because there are Linux users more concerned about the proliferation of appimages than interested in a particular software.

Says 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?

Nope.
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.

Nope.
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.

I 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.

I 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.

Says 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.

Representing 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

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.

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.

I 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

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.

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

trying 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

That 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...