Now that’s a clickbaity title, you might say, but it’s actually the title of a video I watched the other day:

Linus Torvalds is a fun speaker, so go watch the video. I’ll wait here.

That was the bait, now here is the switch: I don’t think that Linux sucks as a desktop. I have been using Linux as my desktop computing environment since SGI IRIX stopped being a thing, so maybe in 2001, and it’s fine. There have been advances, there have been serious setbacks (Gnome 3, anyone?), but overall it lets me do what I need to do and otherwise doesn’t try to get in my way. I even gave Mac OS X an honest shot when I bought a Macbook Pro in 2008, but it just felt really constraining, so I wiped it after about a month and installed Linux instead and never regretted it. I have a partition with Windows 10 in it on my home computer’s hard drive, but I can’t remember the last time I booted into it.

Side note: How fun it is to have a dual-boot Windows 10 partition to play video games! Hey, I have an hour of free time, let’s play something quick. Okay, shut down Linux, boot into Windows, no problem. Oh, I haven’t booted into Windows in a few weeks, so there is an OS update that needs to be installed. Oh, I can’t skip this and have to wait for it to complete before I can log in. Oh, it took 30 minutes to install the OS update. Well, I guess I’ll switch back over to Linux and try playing a game again in a few weeks or so. At which point there will be another OS update and the cycle repeats.

The Horrors of Distributing Linux Software

But back to the topic at hand. The reason I’m linking this video is that Mr. Torvalds talks about the difficulty of distributing desktop software for Linux, and on that I agree with him 100%. I have created and am maintaining several Linux-exclusive software packages that are used by a significant number of non-technical people, the Augmented Reality Sandbox being the main one. It’s a pretty big piece of software comprising three components: the Vrui VR toolkit, the Kinect 3D video capture package, and the AR Sandbox application itself. Vrui is a general-purpose VR toolkit that covers the gamut from tracking 6-DOF input devices and reprojecting and distortion-correcting rendered images onto an HMD’s display to high-level user interaction and UI widgets. It does a lot more than that, too. The main point is that Vrui is system software, and is therefore deeply tied into the operating system, and relies on a large number of system libraries and interfaces. Which means that packaging and releasing it in binary form is an absolute nightmare. This video spoke to me.

I did at some point offer RPM packages for download, and made a system that pretty much automated package creation for me, but of course I didn’t have some release farm set up, so I only made packages for whatever version of Fedora I was using on my development computer at the time. I don’t know if anybody ever actually downloaded any of them. Some time later I looked into creating packages for Ubuntu, but I threw up my hands after reading about half-way through the deb package documentation. I gave up on the whole binary package idea a little while later.

When the AR Sandbox became popular, I decided to use that as a teaching opportunity and treat the AR Sandbox not just as a fun computational appliance, but also as a way for non-technical people to pick up some “computational thinking” along the way. Did that work? I guess in a way it did, as there are thousands of AR Sandboxes out there in the wild, meaning that “regular people” were able to install the software from source. Many schools, for example, made AR Sandbox installation a project for their computer science classes, which I think is great. I did write up detailed installation documents that have received very positive feedback, but I honestly don’t know if people hated the installation, and how many tried to install the software but didn’t manage in the end.

Regardless, it was always clear that this was not the way to go forward, and I needed an easier way for myself and others to install my software. So I did what I do and re-invented the wheel. I call the result “PullPackage.”

Yet Another Package Manager

At its core, PullPackage is a source code-based package manager. Instead of downloading pre-built libraries and executables, it downloads a software package’s source code, and configures, builds, and installs it behind the scenes without user input. Overall, it works remarkably well. For me as the developer, it means I don’t have to build binaries for a combinatorial explosion of Linux distributions, versions, sub-versions, package managers, what have you. For each package, I just create a build script that only gets updated when something fundamental changes with Linux, such as a new major version of a system library, or when I add new features such as new application launchers or configuration options. The build scripts work across many distributions, with differences such as how to install required system libraries (yum/dnf vs apt etc.) centralized in a few places.

For the users, it’s also simple. Bootstrapping the system requires two commands in a terminal:

$ wget http://vroom.library.ucdavis.edu/Software/PullPackage
$ bash ./PullPackage PullPackage

Afterwards, installing packages is a single command each. For example, getting an AR Sandbox up and running only requires three commands (each of which might ask for an administrator password):

$ PullPackage Vrui
$ PullPackage Kinect
$ PullPackage SARndbox

If the user wants to get updated versions of any of the packages, they just need to run the respective PullPackage command again. If the user updates their operating system and something breaks because an ABI changed somewhere, they just need to run the respective PullPackage command again to sort it out. It’s quite nice, really.

Now, this is still work in progress, and I haven’t rolled it out widely yet. The AR Sandbox installation instructions don’t mention it yet. Creating build scripts is not as easy as it could be. While packages get installed in /opt by default, the PullPackage system itself (scripts, package metadata, etc.) is installed in the home directory of the user who installed it, not in a system location. That’s an urgent fix. There is no dependency tracking: for example, PullPackage SARndbox doesn’t check whether Vrui and Kinect are already installed, and doesn’t pull them if they aren’t. But even at this stage, for making my life and the lives of users of my software easier, it’s a pretty good tool. I have been using it internally to keep my constantly evolving VR software installed and up-to-date on our production VR systems, and it has been a godsend. It has happened several times that I had someone come in to use one of the systems, and things weren’t working for whatever reason (well, usually the reason is an OS update), and I was able to do a PullPackage Vrui or PullPackage LidarViewer or whatever, and 30 seconds later we were back in business.

So in conclusion, did I re-invent the wheel again? Yes. Did I do a half-assed re-implementation of something that already existed, and that could have been found with a five-minute Google search? Most probably. Did I learn something and did I have fun with it? Absolutely! In other words, business as usual. At least now if someone asks why I made Yet Another Package Manager, I can point them at this video and say “that’s why!”