-
Notifications
You must be signed in to change notification settings - Fork 449
Running Linux apps on BOINC
Most scientific programs are developed on Linux. The computers running BOINC are diverse: 85% run Windows, Linux and Mac are 7% each, and lots of them have old system software. So we face the issue of how to run Linux applications on these computers.
Science applications are also diverse.
-
The simplest type of application is a compiled C/C++ program. Even these are not completely portable, even to Linux hosts. They dynamically link the C library (libc) and won't run on a host with a too-old version.
-
Some applications consist of a set of programs, executed in order by a shell script.
-
Some applications use libraries (numerical, GPU) and require them to be installed in system directories like
/usr/local/lib. -
Some Python applications require a particular version of Python, and require various Python modules to be installed.
-
Combinations of the above.
Originally, BOINC required that projects build versions of their applications for Windows and Mac, together with the libraries and components they need. This is difficult and time-consuming in many cases, and often impossible.
More recently, BOINC has developed other approaches that simplify the task of packaging Linux applications.
In this approach, you create a virtual machine (VM) image containing the app's software environment. This is combined with vboxwrapper, which launches the virtual machine and mounts the slot and project directories into its filesystem. Application executables may be baked into the VM, or included as files in the app version or the workunit.
This has been used for years by LHC@home, and it's been optimized e.g. to use a single VM image file for multiple concurrent jobs. It works on all platforms: a Linux host with VirtualBox installed can run a Linux VM.
But it was some drawbacks:
- No GPU access from VMs.
- VMs consume a lot of memory, disk, and CPU (especially at startup).
- Creating VM images is complex.
- Volunteers have to install VirtualBox, and in some cases have to tweak BIOS settings to enable it.
In this approach, you create a 'Dockerfile' describing a software environment: a base operating system, and 'layers' that install libraries and components. This is then combined with a BOINC-supplied 'docker_wrapper' program and with application executables. This can then be run on:
- A Linux computer with Docker or Podman installed.
- A Windows computer with WSL enabled, and a 'BOINC WSL distro' installed from the Windows Store (or any WSL distro that has Docker or Podman installed).
- A Mac with Docker Desktop installed.
This approach has several advantages over VMs:
- GPUs can be accessed from Docker containers.
- The Docker approach to building software environments is simple.
- Many scientists already use Docker for running programs on cluster and cloud nodes.
- Relative to VMs, Docker containers take up less disk and RAM, and they start faster.
This approach lets you run self-contained Linux executables on Windows hosts that have WSL enabled and have at least one WSL distro. Docker is not involved.
In this approach your app version includes the BOINC-supplied 'WSL wrapper'. Your Linux executables can be part of either the app version or the workunit.
All the above approaches use the plan class mechanism to decide what hosts the app version can run on. For example, the plan class name for a WSL app must include 'wsl', and the XML spec can include regular expressions limiting what Linux distros the app can use.