2. Launch a container with Ubuntu 12.04, an adequately old Ubuntu version, which is still support. Command:
lxc launch ubuntu:12.04 mycontainer --profile default --profile gui
3. Copy the deb package of Machinarium into the container. Command:
lxc file push machinarium_20121106-ubuntu_i386.deb mycontainer/home/ubuntu/
3. Get a shell into the container. Command:
lxc exec mycontainer -- sudo --user ubuntu --login
4. Install the deb package. Commands:
sudo dpkg -i machinarium_20121106-ubuntu_i386.deb &&
sudo apt-get install -f
5. Run Machinarium. Command:
/opt/machinarium/Machinarium
You can reuse the container to install more software, or dedicate a container for each game.
Rather than just posting the end result that worked, this is my trial-and-error "walthrough" of building a container from start to finish, in order to run several games from a while back.
Hopefully, this can get you started with playing these and other games again, or discovering them for the first time! Let me know what you think and if you'd like to see more of this in the future.
I think this is an excellent post, because you demonstrate an applied use of a bunch of excellent *nix tools, combined with a presentation of the mental model that helped you put it all together.
I am largely self taught, and I didn't touch C/C++ for a long time, so there's a lot of stuff people might take for granted (like the use of ldd), which for a long time I had never encountered.
> Your email is nowhere to be found, so it's impossible to email you about typos or bugs. Typos in this case.
You're right, I don't post my email address on my blog, and yet it's widely available and discoverable (which leads to spam, so...). That said, you can find me on Twitter and LinkedIn, and send me a private message there.
Public comments on HN also work. :-)
Back to your original point:
> Anyways search for:
> Thus, it is imperative to avoid giving these containers running old software no access to the network
> and remove the "no" I suppose? I might be wrong. Only one 'no' there, so it should be gone, afaik.
You're absolutely right; that's a double negative—that "no" should either be dropped or replaced with "any". I'll fix that in a bit.
Thanks again for your careful reading and letting me know!
I'm bit befuddled why the author decided to use volumes for /source and /install instead of just installing the game into the container image. That way you wouldn't need to keep the game files floating around on the host system and overall would have more self-contained container. You could even get fancy and use multi-stage container so that the installer wouldn't need to be included in the final image.
The installer could be run under `expect` so that human interaction is not needed.
They could make a base image and then an image layer that contains the game files only. Now you have a single file image per game with a consistent base.
My point is that by separating the layers it does fulfill the declared goals but in a more portable way. As implemented, there could be hidden dependencies on the local file system or across game installs.
I guess one concern might be the author wanting to push the images to a public repo so other people can use them - which would probably get the author into a bit of trouble for distributing paid content.
I'd really love to see a similar approach but applied to games much older, like the ones you have to pull out a DOSBOX to play, or a Win95 virtual machine. The Win95 games are going to be much more difficult to set up because the VM needs a bunch of stuffs to work properly (sound, video) while the DOSBOX does everything for you.
Yes, I'm planning to do this for much older games in the future, and you're also right that DOSBox does a lot of that for you!
One thing I've noticed is websites that let you play using old DOS games via DOSBox right from your browser (e.g., see https://www.dosgames.com/), so I was going to make a blog post for how to do that yourself, from scratch.
BTW is there some way to perform save/load functionality without log-in? Maybe we can use cookies to identify users? Just a thought as I'm not a programmer...
Note that I'm not the owner/developer of that site, so I can only guess how it's implemented there. However, I can give you a general overview for why logins are typically required for such use cases.
While you're correct that cookies is a good way to identify users, they could be faked by other users (to steal or change your saved games), which is why websites typically have user accounts where you have to prove you know something (such as a password) in order to claim to be user id 12345.
If you don't have to prove anything to claim to be user 12345, then some creative users on the internet will write bots that will claim to be every possible user (in sequence), and either trash or delete their saved games, or do something else to affect them in the future.
Thus, we have the need for user accounts on websites to securely identify users and their settings, saved games, shopping carts, purchase history, etc.
If you're interested in learning more, take a look at:
If I were to guess, I'd try to run qemu-kvm with exposed VNC... a "builder" intermediate that installs w95 as a base image, with a second dockerfile using that as base and installs the game in the virtual disk using overlay images.
That should be decently fast, the only thing I dunno is how easy it is to automate a w95 install when you only have an 1:1 iso image of a retail setup CD/diskette.
I did a project back in 2013 that made unikernels for really old games. One was a bare-metal z-machine interpreter to instantly bootup interactive fiction game. Another was a Linux+C64 emulator+modded game (one of the first graphical adventure games, Below The Root, from 1984).
i managed to run diablo2 (release 2000) on wine in a docker container. with ffmepg streaming it as a video. Was a real eye opener moment to realize what can fit in these things.
It's kind of playable using XQuartz on mac. But i'm only using that for debugging the setup really. This is intended as a test bed for keras bot experiments, so controls are not important to me.
Main components are wine, ffmpeg, nginx+nginx-ts-module and xvfb. It runs diablo2 and livestreams the screen capture.
I'd love to push this to git or docker, but it's currently littered with blizzards game files. I'm most likely not allowed to share the current state.
I put some files together to get a rough look. I'll try to make it a bit more usefull when i'm done with actual work and not exhausted.
and then ended up migrating to Netlify when I upgraded Hugo to a new version to support a different theme (Netlify has additional benefits, like automatic live previews):
If it runs on 16.04 you could put it in a snap package. I really like it for installing older software. I created a snap package for Scratch For Arduino (S4A), which is a pain to get working natively, but in the snap I can mess with multilib and weird dependencies without it affecting my main install.
I think the advantage of snaps is that you can get easy access to the host system using interfaces. S4A requires access to the USB Serial devices of the host. In snap the snap I just added the `serial` interface but I'm not sure if Docker has an elegant way to do that.
Had some luck with Windows version of Obsidian. Using Ubuntu 20.04, should work on other distributions too.
1. Install wine and timidity. I presume xephyr server is installed.
2. Insert CD and run setup.exe with wine. Install game to default location, install QuickTime when it asks.
3. In one terminal window run timidity midi server (if you want background music): `$ timidity -iA -B128,8 -Os`
4. In another terminal window start the game like this: `$ Xephyr :1 -ac -screen 640x480x16 & DISPLAY=:1 wine "C:\\Program Files\\Segasoft\\Obsidian\\Obsidian.exe"`
In case you don't have physical optical drive you can use CDEmu to mount disk images, but it has to be installed from additional repository and has a bit of complicated setup.
Machinarium and Botanicula on Steam doesn't provide native Linux versions, but at least both games have "Platinum" support on Proton.
Found a native Linux copy of Machinarium from HumbleBundle. To get it running on Fedora 31 I had only to install single missing dependency:
`sudo yum install libXt.i686`
Well, now I'll probably have to beat the game, while I'm at it.
On of the first Humble Bundles for Linux games came with a Deb package of the game.
The game is a Linux i386 binary, which means that installing directly on your host will pull in all sorts of i386 libraries. If you host is amd64, it is quite messy.
Looks like Proton does a better job than snap or rpm. I don't get why there is no Linux layer dedicated to translating x32 library calls into x64 calls. The other way around is often impossible I know.
Proton is a packaged Wine (Windows emulator) with DXVK (like DirectX for Linux).
Snap packages are based on core images, so if there was interest, they could create a core image that has Wine and DXVK. Then any game would result Wine and DXVK.
RPM is comparable to Deb packages. There is no significant separation of one package from another apart from file permissions.
I haven't tried it myself (yet), but I don't see why Wine wouldn't work from a container, if you propagate access to the display into the container, as I have done in the Dockerfiles in my post.
Here are some quick references I found that suggest this works:
A virtual machine solution (such as VirtualBox) requires more CPU/RAM resources than a container, because you're running an extra copy of the entire operating system, in addition to your base system that you're always running.
A container is much more light-weight than a VM because it relies on the services of the underlying OS and just provides the runtime environment, but not the OS; please see https://www.backblaze.com/blog/vm-vs-containers/ for more detains on the distinction.
In any case, it would actually be more complex to use a VM, because I would first have to do a full installation of Ubuntu in the VM, before I could get started with installing the game, whereas with Docker, I can just build a container image starting with ubuntu:14.04 as a base, and have it working in seconds (minute or two once I started installing the required i386 packages, but that's unavoidable).
If you look at the end result, it's actually quite a simple Dockerfile, and the installation from start to playing will take you less time than installing a full Ubuntu distribution in a VM.
Looks like Crysis (https://www.gog.com/game/crysis) is a Windows-only game, so you'll need a different approach than what I've described in my blog post, which is running Ubuntu inside containers.
If you want to play it on Linux, you may be able to do it using Wine (https://www.winehq.org/), which you can run directly, or inside a Docker container.
1. First, setup your host according to the instructions at https://blog.simos.info/how-to-easily-run-graphics-accelerat... You will be creating a LXD profile called `gui` on top of the default LXD installation.
2. Launch a container with Ubuntu 12.04, an adequately old Ubuntu version, which is still support. Command: lxc launch ubuntu:12.04 mycontainer --profile default --profile gui
3. Copy the deb package of Machinarium into the container. Command: lxc file push machinarium_20121106-ubuntu_i386.deb mycontainer/home/ubuntu/
3. Get a shell into the container. Command: lxc exec mycontainer -- sudo --user ubuntu --login
4. Install the deb package. Commands: sudo dpkg -i machinarium_20121106-ubuntu_i386.deb && sudo apt-get install -f
5. Run Machinarium. Command: /opt/machinarium/Machinarium
You can reuse the container to install more software, or dedicate a container for each game.