[OS Compatibility] by
# The Situation
Although the core software underlying the PiDP-8/I software distribution is broadly portable, the dominance of Raspbian in the Raspberry Pi space means it gets the most attention when it comes to testing and development. This article documents what it known to work, where, today.
If you need the software to work on some platform where it currently doesn't, [we accept patches!](/doc/trunk/HACKERS.md) You can also send problem reports [to our development forum](/forum), file a [bug report](/bugs), or [discuss it on the users' mailing list][ml].
# Raspbian, Debian, Ubuntu
The current stable release of the PiDP-8/I software distribution was built for and tested with the [Raspbian Stretch Lite](https://www.raspberrypi.org/blog/raspbian-stretch/) (v9) distribution. The software should also work well on the non-Lite version.
Prior releases were built atop the [Raspbian Jessie Lite](https://www.raspberrypi.org/blog/raspbian-jessie-is-here/) (v8) distribution, but somewhere along the line, we broke compatibility with Jessie. It's probably simple to fix the problem — we think it's a systemd version compatibility issue — but if you need to keep running on Jessie, which is now out of support, we recommend that you keep running contemporaneous versions of the PiDP-8/I software atop it. Version 2017.04.04 was the last version specifically tested atop Jessie.
We have not yet tried the PiDP-8/I software on Raspbian Buster (v10), released in early July 2019. If you've tried it, please report it [on the forum](/forum) or [on the mailing list][ml], whether successful or not.
Raspbian-based OSes like [pipaOS](http://pipaos.mitako.eu/) should also work, but this is not tested by the project's current developers.
The project's primary maintainer occasionally builds the software on Debian and Ubuntu systems as well, which works fine, since Raspbian and Ubuntu are both derivatives of Debian. On such systems, the software is designed to detect the absence of the PiDP-8/I front panel hardware and work without it.
Because of that success, we expect it will run on any other Debian derivative, too.
The configuration script and documentation advice on installing third-party dependencies is given in terms of Debian type OSes. That makes using the PiDP-8/I software distribution on this class of OSes the most straightforward.
# Non-Debian Linuxes
There are non-Debian type Linux based OSes for the Raspberry Pi such as [openSuSE for the Pi 3](https://en.opensuse.org/HCL:Raspberry_Pi3) and [CentOS for the Pi 3](https://wiki.centos.org/SpecialInterestGroup/AltArch/Arm32/RaspberryPi3). Since the primary developers on this project haven't tried any of these Pi Linux distros, and no one has reported on their attempts to make it work, we can only speculate on the workarounds required, if any.
Off the Pi, pretty much every Linux distribution should be able to build and run our software, once you've installed all of its prerequisites. We've built and run it successfully a few times on 64-bit Intel boxes under CentOS, for example.
This project's current primary maintainers use macOS at home, so the PiDP-8/I software is frequently built and tested on macOS while we are working on features that do not require the PiDP-8/I front panel hardware.
Why? Because it builds 3-12 times faster than on a Pi 3, depending on what has to be built!
The third party dependency advice given by the configure script and in the documentation needs to be adjusted. We recommend getting such things from [Homebrew](https://brew.sh/).
Because of our regular testing on macOS, the port to FreeBSD was straightforward. On the FreeBSD 11.2 system we did the work on, we had to install the following non-core packages:
$ sudo pkg install coreutils gmake perl5 python py27-pip
Avoid the temptation to install the `python3` package instead: this package follows the Python project's recommendation to install the interpreter only as "`python3`" to avoid conflicts with Python 2. We try to write our Python scripts to work on both versions, but until we [cut over to requiring Python 3 only](/tktview?name=26283b9b30), we can't change our script shebang lines to work with this package.
It is expected that the code that drives the PiDP-8/I front panel hardware will not work on [FreeBSD for the Raspberry Pi](https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). We have an [open feature ticket](/tktview?name=856225858e) for that, if you want to work on it.
The PiDP-8/I software's build system requires a POSIX type environment, so it's far simpler to just add that atop Windows than to port our software to build natively on Windows. You have several choices:
## Linux VM
Currently, for maximum compatibility, your best option is to install some sort of Linux virtual machine on your Windows box.
Windows 10 Pro and up include [Hyper-V](https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v), which runs Linux VMs quite well.
For those running Home class versions of Windows, the best free option is [Oracle's VirtualBox](https://www.virtualbox.org/).
This works, and appears to work *well* besides in the multiple times we've tried it. The most recent test was on 2019.05.11 with 64-bit Cygwin 3.0.7 on Windows 10.
You will have to install the `libncurses-devel` and `python2-pip` packages as well as standard Unix build tools: GCC, GNU Make, etc. Having done all that, the software will build and run.
For `bin/pidp8i` to run properly, you need to run the trunk version of our software: the systemd improvements made to it for the most recent stable release don't work under Cygwin, but we've fixed that on trunk.
## Windows Subsystem for Linux
Terminal emulation and [pty](https://en.wikipedia.org/wiki/Pseudoterminal) handling have been a longstanding problem with WSL, and there were still bugs in it the last time I tried it, on 2019.05.11 with 64-bit Windows 10 Pro 1803 running Ubuntu 18.04.02 LTS. It's much better than the tests we conducted back in 2017, however.
These problems mainly show up when running the simulator under GNU screen, as our `bin/pidp8i` wrapper does. In my latest attempt, the following would result in a "dead" screen session:
$ pidp8i start ← start simulator under GNU screen
$ pidp8i ← attach to screen session
Ctrl-A, d ← detach; leave it running
$ pidp8i ← reattach; reports it "dead"
You can avoid these problems by running the simulator directly:
$ make run
$ bin/pdp8 boot/0.script
...and so forth.
It is possible that the improvements announced at [Build 2019](https://news.microsoft.com/build2019/) to [WSL 2](https://devblogs.microsoft.com/commandline/announcing-wsl-2/) and [the Windows console](https://github.com/microsoft/Terminal) will solve these remaining pty and terminal emulation problems. Until they're addressed, the above choices are better options.
As with Cygwin, there are portability fixes on trunk now that are not yet released.