Executable

Stop putting your crap in my system!

We have a 2 fold problem. One is a searching for a solution. The second is created by trying to solve the first problem, but poorly. I’m talking about software distribution.

I’ve lived this problem for the last 3 decades. Either as the recipient or as the creator (I really wanted to type victim and perpetrator there). I’ve sent scripts, source code, executables, tar/zip files, installers, VMs, containers, and actual preinstalled hardware (appliance) to customers and received all of the same and more.

This morning I’m looking for a slicer for a new open source resin printer. One of the best slicer options is the Prusa Slicer. It is well regarded and Prusa puts a lot of effort into the open source movement and I appreciate that.

The problem is that they only distribute the Linux executable as a Flatpak. Full stop. Why is that a problem and what alternatives are there? I’ll get to that in a moment. First, let’s look at the problem in more depth.

Sending code to someone else

It’s never been easy to send code to someone else. Unless you control their environment (the nice thing about an appliance in this case), you don’t know what you will find. Code can’t expect libraries to be available, underlying OS to be a version designed for, or even that the instruction set for the CPU is just of one type (32 bit vs 64 bit, Intel vs ARM vs RISC-V).

Most of my career I have had a limited audience for my efforts. One large customer, a couple of end users, or a single industrial site. In those cases I could often install the software myself, or at least rely on a competent user to follow an installation script. CPU type was a given, OS was within a limited range, and libraries were either prearranged or delivered as part of the process. In these cases I’ve used tarballs of source, bare exectubales, installation scripts, VMs, containers, or actual hardware that is forklift replaced.

I’ve done some stints where the software has a larger user base. In those cases we have used installers. The first time, 25 years ago, it was variations on any number of commercial installers that would basically pack up a survival kit of everything they thought they might need and then throw them onto the target system following some basic heuristics. Worked 99% of the time and the other 1% used up 50% of our support team’s time.

solutions?

We have seen a lot of ways to fix this problem. All of them work well for a subset of customers. Industrial customers would default to an appliance in a heartbeat. Enterprise customers loved getting VMs for large systems (virtual appliances). Desktop users assume an installer process that does “magic” for them. Mobile phone users love their app stores. Controlled environments to achieve a controlled user experience. The closest software comes to the broadcast TV model.

Want to do something a little different? Well you are either going to pull those apart for what you need, or you want something a little more low level. I’m almost always in that camp (why I can’t stand the Apple iPhone and iPad). If I need a hammer or a drill, it had better be something that can be picked up and just used in any which way.

I started my career with this being tar balls (also cpio and zip). A directory of files that I would put somewhere and then follow build and installation instructions. Sure, it required me to do a bit of leg work, but I had a general tool in the end. I can still get software this way, and am looking at the GitHub for Prusa slicer for that very reason right now.

Some software started to rely on a wide range of dependencies and not always libraries. Do you have libraries between version X & Y? Were they compiled with feature Z on? Does your version of systemd or dbus provide left handed function calls, etc. This got to be a nightmare and people started to package the whole system with the application. VMs and containers are just that. Can’t trust the system to be compatible? Bring the whole system with you.

While some of these things are great technology, they aren’t appropriate for a simple tool. I’m not going to spin up a VM to run a command line function. Containers have an equivalent, yet lighter weight structure. I don’t want to run something, to run something. Is that too much to ask for?

In the Linux world we have a number of options to solve this problem. The easiest is if your distro provides a package for the tool. Followed by a distro install package from the tool creator. Easy and it handles dependencies.

Many vendors are not wanting to lock themselves into Debian and/or Redhat though. Many don’t like building both, so they have been looking for something in between the container and the install package that runs on almost any Linux system.

The contenders

I’ve previously talked about the mess that Snap creates, and to be honest it’s gotten a lot better. At the same time it is pretty much an Ubuntu package manager at this point, so let’s take it off the table.

That leaves AppImage and Flatpak. The idea is that you download a single thing and it just runs on your system. There are people that get religious one way or another between these two. I’m about to do the exact same thing, but from the context of Anticryptography.

I often want a system that will just run. Power it up 20 years from now and it can still do what it did the first time. That may sound like an extreme requirement, but I would actually like to make 20 turn into 100 or more. This lets us not only push data forward in time, but the tools to work with the data. Sure, the future may have better ways to play with the data, but what if they can’t read your dBaseIII file anymore?

AppImage fills that perfectly. It just assumes a basic Linux system with FUSE installed. Granted, the underlying APIs may change, but it will always work in the general class of machines that I first used it on. Also, writing a shim for FUSE shouldn’t be that hard if I wanted to make a whole class of old AppImages work in the future.

Flatpak on the other hand is more of a repo system. It “integrates” with your GUI, and manages the system interfaces for you. You have to run your command with their command (yeah, that pissed me off). It also installs a system service to “manage” the flatpaks for you, or be a “helper” (yeah, that’s when I uninstalled it). Want to sum it up, Snap that runs every time you type the command.

So let’s run this down in a table (a feature I don’t use enough).

Some people may love the Flatpak column. I hate it, and I reserve the word hate for special cases. To me AppImage is almost ideal.

The examples

In 3D printing there are 2 big software packages out there, Cura and Prusa Slicer. They also straddle this divide as of a few weeks ago. I run Cura as I have an Ultimaker printer. Prusa Slicer supports resin printers and I was looking for that functionality. I’ve also been very interested in the 2 new Prusa printers, so trying their slicer was good when considering that investment.

Cura

Cura comes as an AppImage. I keep a few versions laying around in case the newest one isn’t behaving the way I want. This let’s me try beta versions and switch between stable and beta with no hassle. It just works and I never have to worry about what’s installed on any fairly standard system. Win, Win, Win.

I can drag and drop files into it (not something I do a lot, but I know it works). Created one file and it now sits in my Gnome menu system, although I prefer to run it from the command line. I’ve also mapped the STL and 3MF mime types to offer Cura as an option on a right click. What’s not to like?

Prusa Slicer

I went to download it, and found instructions for installing Flatpak. The hairs on the back of my neck went up. In software this should be considered like a stranger asking you to go to another location. There is the potential for danger that you don’t know. Could be perfectly safe. Could be dangerous (I am willing to trust Prusa, but who is maintaining Flatpak? Two security surfaces?).

Ok, let’s go through the process. System install Flatpak first. At least that is overseen by Ubuntu for me. Wait, what is that new daemon running?

1flatpak-system-helper.service   loaded active     running   flatpak system helper

So something is running on my system all the time? I minimize what’s running on my system and things have gotten worse over time. Requiring a new service just for running Prusa Slicer is not going to work.

Oh, want to run an older version? Yeah, you can do it as described in this “github issue” for flatpak. Just look through the old commits and then “update” your flatpak to the older version using this HUGE string. Oh, you want to run both versions? Um….

Flatpak users have just accepted this problem to the point where 42 of them give this answer a thumbs up and 12 people give it a heart? Is this some sort of software Stockholm syndrome?

Sure it ingrates into the GUI without user interaction, but is that really that hard? No, Flatpak is bringing the consumer mentality of the mobile app market to the Linux command line world. If I wanted that I would have a windows box and an iPad. Read the room!

Wrap it up

Look, I like Prusa as a company. I bought one of their printers for my daughter. They have a real commitment to open source that others have been abusing, yet they are trying to make it work. I have also bought 5 of their printers at work.

I’m going to try and install it without Flatpak because Prusa is that good of a company that I don’t want to dismiss them. If I’m forced into Flatpak I’ll probably just stop working with Prusa all together. I can’t be held hostage by what Flatpak thinks I should be doing.

Ultimaker can be a pain in the ass now that they have been bought, but they do Cura right. I never have a problem, and when I do, I just run an older version. Nothing is installed at the system level, it just runs in it’s little sandbox and does it correctly. I have no fear that I can run Cura as long as my hardware still works, and that’s how it should be.

Cover photo is from Wikipedia under the CC license included at that link.

Figure 1 is a screenshot from GitHub and so unbelievable I had to share it.