7 ms·

Running decade-old games in containers

72 points by mbrukman 6y ago

markus_zhang 6y ago
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.
- Groxx 6y ago
  Though I realize it's not the same thing, as a dos-game-fan have you seen https://archive.org/details/softwarelibrary_msdos_games https://archive.org/details/softwarelibrary_msdos_games ?
- mbrukman 6y ago
  Blog post author here. 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/ https://www.dosgames.com/), so I was going to make a blog post for how to do that yourself, from scratch. Would that be of interest?
  - markus_zhang 6y ago
    Yeah that definitely is interesting! Thank you~~ 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...
    - mbrukman 6y ago
      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: * https://en.wikipedia.org/wiki/HTTP_cookie https://en.wikipedia.org/wiki/HTTP_cookie * https://simple.wikipedia.org/wiki/HTTP_cookie https://simple.wikipedia.org/wiki/HTTP_cookie Hope this helps!
- mschuster91 6y ago
  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.
- rabidrat 6y ago
  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). http://arcade.saul.pw/games/ http://arcade.saul.pw/games/
tuco86 6y ago
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.
- zokier 6y ago
  Why would you need docker for wine?
  - tuco86 6y ago
    i was curious if i could run diablo2 on my kubernetes clusters.
    - jwhitlark 6y ago
      That sounds lovely! Was it playable? I'd love to take a look at the manifests, if you could make them available somewhere.
      - tuco86 6y ago
        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. https://github.com/tuco86/docker-diablo2 https://github.com/tuco86/docker-diablo2
    - MrBuddyCasino 6y ago
      this is peak HN
    - sethammons 6y ago
      I literally snorted. This is fantastic and is the reason for HN to exist!
zokier 6y ago
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.
- Groxx 6y ago
  It's covered explicitly in the "goals and principles" section. They're aiming for a reusable environment for older games, not a single-purpose one.
  - jayd16 6y ago
    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.
    - Groxx 6y ago
      Sure, as a follow-up they could do that. That's (very clearly declared to be) not the goal of the author though.
      - jayd16 6y ago
        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.
        reificator 6y ago
        But it then prevents redistribution of the container images in a legal manner, because the game files themselves are still under copyright.
dllthomas 6y ago
I've been trying to get Obsidian (https://en.wikipedia.org/wiki/Obsidian_(1997_video_game) https://en.wikipedia.org/wiki/Obsidian_(1997_video_game)) to run under emulation, but so far it's been too choppy to be playable.
- butz 6y ago
  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.
- butz 6y ago
  How did you run it? WineHQ lists compatibility as "Gold", but report is three years old. Might be worth trying it out on latest Wine version.
  - dllthomas 6y ago
    I put the most effort into QEMU. I think I tried Wine briefly first, but don't recall what trouble I ran into.
- matthewn 6y ago
  I'm glad someone else remembers this forgotten gem. Every couple of years or so, I try to get Obsidian running again. No luck so far. :(
  - dllthomas 6y ago
    My email's on my profile. Shoot me an email and I'll let you know if/when I ever get it working well.
butz 6y ago
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.
- simosx 6y ago
  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.
  - loa_in_ 6y ago
    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.
    - AnIdiotOnTheNet 6y ago
      Because historically the Linux userland community has a willful disregard for binary, and often source, backwards compatibility.
    - simosx 6y ago
      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.
simosx 6y ago
You can also use a GUI LXD container for this. 1. First, setup your host according to the instructions at https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/ 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.
lonelappde 6y ago
Is this easier than VirtualBox?
- mbrukman 6y ago
  Blog post author here. 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/ 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.
4restm 6y ago
can those containers run Crysis?
- mbrukman 6y ago
  Blog post author here. Looks like Crysis (https://www.gog.com/game/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/ https://www.winehq.org/), which you can run directly, or inside a Docker container. Alternatively, if you are using Windows, you may be able to utilize Windows containers (https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/ https://docs.microsoft.com/en-us/virtualization/windowsconta...), but that's not what I did in my blog post, so YMMV. If you do try this out, let us know if it works for you!
naringas 6y ago
having put a few older applications into a Docker container, this article tells it like it is. docker run: some error. fix this error. docker run again: another error, rinse and repeat.
- deleted 6y ago
  [deleted]
mbrukman 6y ago
Hi HN, blog post author here. 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.
- Widdershin 6y ago
  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.
  - mbrukman 6y ago
    Thank you for the kind words! Glad to hear you enjoyed it.
- readwind 6y ago
  Your email is nowhere to be found, so it's impossible to email you about typos or bugs. Typos in this case. 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.
  - mbrukman 6y ago
    > 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!
galgalesh 6y ago
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.
AtlasBarfed 6y ago
Does Wine run well from a container? I always found bottles a bit annoying.
- mbrukman 6y ago
  Blog post author here. 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: * https://github.com/scottyhardy/docker-wine https://github.com/scottyhardy/docker-wine * https://blog.simos.info/how-to-run-wine-graphics-accelerated-in-an-lxd-container-on-ubuntu/ https://blog.simos.info/how-to-run-wine-graphics-accelerated...

72 points by mbrukman 6y ago

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.

Groxx 6y ago
Though I realize it's not the same thing, as a dos-game-fan have you seen https://archive.org/details/softwarelibrary_msdos_games https://archive.org/details/softwarelibrary_msdos_games ?
mbrukman 6y ago
Blog post author here. 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/ https://www.dosgames.com/), so I was going to make a blog post for how to do that yourself, from scratch. Would that be of interest?
- markus_zhang 6y ago
  Yeah that definitely is interesting! Thank you~~ 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...
  - mbrukman 6y ago
    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: * https://en.wikipedia.org/wiki/HTTP_cookie https://en.wikipedia.org/wiki/HTTP_cookie * https://simple.wikipedia.org/wiki/HTTP_cookie https://simple.wikipedia.org/wiki/HTTP_cookie Hope this helps!
mschuster91 6y ago
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.
rabidrat 6y ago
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). http://arcade.saul.pw/games/ http://arcade.saul.pw/games/

tuco86 6y ago

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.

zokier 6y ago
Why would you need docker for wine?
- tuco86 6y ago
  i was curious if i could run diablo2 on my kubernetes clusters.
  - jwhitlark 6y ago
    That sounds lovely! Was it playable? I'd love to take a look at the manifests, if you could make them available somewhere.
    - tuco86 6y ago
      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. https://github.com/tuco86/docker-diablo2 https://github.com/tuco86/docker-diablo2
  - MrBuddyCasino 6y ago
    this is peak HN
  - sethammons 6y ago
    I literally snorted. This is fantastic and is the reason for HN to exist!

zokier 6y ago

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.

Groxx 6y ago
It's covered explicitly in the "goals and principles" section. They're aiming for a reusable environment for older games, not a single-purpose one.
- jayd16 6y ago
  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.
  - Groxx 6y ago
    Sure, as a follow-up they could do that. That's (very clearly declared to be) not the goal of the author though.
    - jayd16 6y ago
      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.
      - reificator 6y ago
        But it then prevents redistribution of the container images in a legal manner, because the game files themselves are still under copyright.

dllthomas 6y ago

I've been trying to get Obsidian (https://en.wikipedia.org/wiki/Obsidian_(1997_video_game) https://en.wikipedia.org/wiki/Obsidian_(1997_video_game)) to run under emulation, but so far it's been too choppy to be playable.

butz 6y ago
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.
butz 6y ago
How did you run it? WineHQ lists compatibility as "Gold", but report is three years old. Might be worth trying it out on latest Wine version.
- dllthomas 6y ago
  I put the most effort into QEMU. I think I tried Wine briefly first, but don't recall what trouble I ran into.
matthewn 6y ago
I'm glad someone else remembers this forgotten gem. Every couple of years or so, I try to get Obsidian running again. No luck so far. :(
- dllthomas 6y ago
  My email's on my profile. Shoot me an email and I'll let you know if/when I ever get it working well.

butz 6y ago

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.

simosx 6y ago
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.
- loa_in_ 6y ago
  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.
  - AnIdiotOnTheNet 6y ago
    Because historically the Linux userland community has a willful disregard for binary, and often source, backwards compatibility.
  - simosx 6y ago
    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.

simosx 6y ago

You can also use a GUI LXD container for this. 1. First, setup your host according to the instructions at https://blog.simos.info/how-to-easily-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/ 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.

lonelappde 6y ago

Is this easier than VirtualBox?

mbrukman 6y ago
Blog post author here. 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/ 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.

4restm 6y ago

can those containers run Crysis?

mbrukman 6y ago
Blog post author here. Looks like Crysis (https://www.gog.com/game/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/ https://www.winehq.org/), which you can run directly, or inside a Docker container. Alternatively, if you are using Windows, you may be able to utilize Windows containers (https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/ https://docs.microsoft.com/en-us/virtualization/windowsconta...), but that's not what I did in my blog post, so YMMV. If you do try this out, let us know if it works for you!

naringas 6y ago

having put a few older applications into a Docker container, this article tells it like it is. docker run: some error. fix this error. docker run again: another error, rinse and repeat.

deleted 6y ago
[deleted]

mbrukman 6y ago

Hi HN, blog post author here. 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.

Widdershin 6y ago
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.
- mbrukman 6y ago
  Thank you for the kind words! Glad to hear you enjoyed it.
readwind 6y ago
Your email is nowhere to be found, so it's impossible to email you about typos or bugs. Typos in this case. 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.
- mbrukman 6y ago
  > 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!

galgalesh 6y ago

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.

AtlasBarfed 6y ago

Does Wine run well from a container? I always found bottles a bit annoying.

mbrukman 6y ago
Blog post author here. 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: * https://github.com/scottyhardy/docker-wine https://github.com/scottyhardy/docker-wine * https://blog.simos.info/how-to-run-wine-graphics-accelerated-in-an-lxd-container-on-ubuntu/ https://blog.simos.info/how-to-run-wine-graphics-accelerated...