Seventeen Years of Misunderstanding
The story is supposed to begin with a Gundam model.
Yeah, no. I actually know nothing about Gundam. But during a visit to a friend’s place, he insisted on showing me his collection. Dozens of models lined neatly in a display cabinet. I nodded along as he explained the different suits and variants, only half understanding him while carefully inspecting the rest of the cabinet. That was when I noticed it.
“So you have a printer. Looks like it’s been collecting dust forever. How come you never mentioned it?”
“Oh that?” he said. “Picked it up on Facebook Marketplace for fifty bucks (Canadian), and the seller threw in a bunch of ink cartridges. Problem is, it’s ancient. No WiFi. It needs a dedicated computer over USB. But I don’t have a spare machine for it. Maybe I’ll buy a cheap used PC for it someday.”
“No need. We can get it online today.”
It was a Canon MX850, an inkjet all-in-one with printing, copying, scanning, and faxing. It even had both a paper cassette and a rear feeder, plus two types of scanners: a flatbed and an automatic document feeder. That ADF even supported duplex scanning, something I’d never seen before because I grew up with the sort of bargain-bin printers. Released in 2008, and it definitely couldn’t get on the network by itself, requiring a wired USB connection to a computer.
But the answer came to me immediately: Raspberry Pi. CUPS. Turning it into a network printer.
And conveniently, I happened to have a spare Raspberry Pi 3 sitting under my bed. Perfect.
The war against the printer began.
Resurrecting an Antique Printer with a Raspberry Pi and CUPS
I had never used CUPS on Linux before, so some trial and error was inevitable. Installing and configuring CUPS was the easy part. First step: flash Raspberry Pi OS onto the Pi. It’s basically Debian with some Pi-specific drivers sprinkled in. Then:
sudo apt update
sudo apt install cups
sudo systemctl enable cups --now
And that was it. The Pi was now a CUPS server.
Since the Pi wouldn’t be exposed to the public internet and everyone on the home network was trusted, I relaxed the default CUPS security settings. That way both of my friend and I could configure the printer directly from our browsers. Edit /etc/cups/cupsd.conf and find these blocks:
Listen localhost:631
...
<Location />
Order allow,deny
</Location>
<Location /admin>
Order allow,deny
</Location>
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
</Location>
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Order allow,deny
</Location>
Change them to:
Listen localhost:631
Listen 10.0.0.250:631 # add the raspberry pi's local ip address
...
<Location />
Order allow,deny
Allow from 10.0.0.*
</Location>
<Location /admin>
Order allow,deny
Allow from 10.0.0.*
</Location>
<Location /admin/conf>
AuthType Default
Require user @SYSTEM
Order allow,deny
Allow from 10.0.0.*
</Location>
<Location /admin/log>
AuthType Default
Require user @SYSTEM
Order allow,deny
Allow from 10.0.0.*
</Location>
Restart CUPS:
sudo systemctl restart cups
I also added avahi-daemon, which lets devices on the network automatically discover the printer and access it through an address like http://raspberrypi.local:631.
sudo apt install avahi-daemon
sudo systemctl enable avahi-daemon --now
At this point, every device on the local network could detect the printer and send print jobs to it, just as if it were connected over USB.
The “PC to Raspberry Pi” part was done. The next step was to complete the “Raspberry Pi to printer” part. I powered on the printer, connected it to the Pi with a USB cable, opened the CUPS web interface at http://raspberrypi.local:631, went to the “Administration” tab, clicked “Add Printer,” logged in with my Linux account, selected the MX850 under USB, and then…
Make sure to check “Share This Printer”, otherwise it won’t be visible to other devices on the network.
And then came the part everyone dreads: the driver.
Please Enjoy the Inevitable Pain Known as Printer Drivers
Fighting with printer drivers is an eternal curse. The Canon MX850 had been discontinued for years, and Canon’s official site only offered Linux drivers for x86, and they were unbelievably bloated. Even if I managed to run them under qemu-user by sheer luck, I still had no idea how to integrate them into CUPS. Third-party drivers were the only option.
Fortunately, others had been down this road already, and there was more than one choice.
Gutenprint is an open-source driver that supports a huge number of older printers, including the MX850. Installing and configuring it is straightforward. Just install it with apt:
sudo apt install printer-driver-gutenprint
After installation, open the “Add Printer” page in CUPS again. This time, “Canon” shows up in the “Make” list. Select it, then find “Canon MX850 series - CUPS+Gutenprint v5.x.x” in the “Model” list, proceeded to the next step, and that is it.
The printer was now fully usable. Windows, macOS, and even iPhones could discover it automatically and send print jobs to it. As for print quality, I had no original Canon driver to compare against, so I couldn’t say whether it was good or bad. But for monochrome documents, it was completely acceptable. Color and duplex printing both worked too.
But the story didn’t end there.
Remember how I said there was more than one option? Besides Gutenprint, there was another: TurboPrint.
TurboPrint is a commercial printer driver. Like Gutenprint, it supports various ancient printers and claims to offer better output quality, along with advanced features such as color calibration. Since the MX850 is an inkjet printer, of course I hoped it could reach photo-grade quality, so color calibration was especially tempting.
TurboPrint isn’t in most Linux distro repositories, but it provides a downloadable tgz package. After installing it, TurboPrint automatically integrates with CUPS. Opening the “Add Printer” page again, there is a new “CANON TurboPrint” entry along with several other TurboPrint-specific options in the “Make” list. Selecting one, then choosing “Canon MX850 series - TurboPrint v2.xx” in the “Model” list, and moving to the next step completes the setup.
But… it’s commercial software. Meaning it costs money. TurboPrint does allow free use, but all printouts from the free version have a watermark. A very large, fully opaque watermark. In other words, the free version is effectively unusable.
TurboPrint offers a 30-day trial period. During those 30 days, every feature is enabled and there are no watermarks. Except on my Raspberry Pi, the moment I finished installing TurboPrint, it immediately told me the trial had expired.
$ tpconfig
**************************************************************************
TurboPrint Studio XL 2.55-1 (20-SEP-2023) (c) ZEDOnet GmbH
Demo version expired
**************************************************************************
I checked the system clock. It was correct. Something must have been wrong with TurboPrint’s DRM. Still, I didn’t think much of it at the time. Gutenprint already covered the basics, and from that point on we simply stuck with it.
That was in March 2025.
Taihen (Plot Twist)
Half a year passed.
Debian 13 was released. The new Raspberry Pi OS hadn’t caught up yet, so I decided to upgrade manually. The process wasn’t smooth, and I later learned that Raspberry Pi OS officially discourages major-version in-place upgrades. That’s a story for another time.
Although discouraged, in-place upgrades are still possible. Make sure to follow this guide: https://gist.github.com/jauderho/5f73f16cac28669e56608be14c41006c
The Pi’s proprietary components caused many issues. I repeatedly had to respond to apt’s intervention prompts - unmet dependencies here, modified configuration files there.
But among all those messages, as if arranged by fate, one particular prompt jumped out at me:
Configuration file '/etc/mime.types'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** mime.types (Y/I/N/O/D/Z) [default=N] ?
Something was wrong. mime.types? I had never touched it.
This file is a core configuration that tells all other Linux programs how to interpret file types. It rarely changes. Usually it’s only updated during major system upgrades. It shouldn’t have been modified at all. Something was definitely off - something, or someone, had tampered with it.
Pressing “D” to view the diff didn’t help. There were too many lines of change mixed with the legitimate Debian 12 to 13 updates. I couldn’t immediately identify what was altered. So I stopped apt and decided to investigate manually.
First, I downloaded the Debian 12 version of mime.types:
apt download media-types=10.0.0 # if this fails, revert your source.list to bookworm, then run apt update
dpkg-deb -x media-types_10.0.0_all.deb /tmp/mime12
Then compared the files:
$ diff -u /tmp/mime12/etc/mime.types /etc/mime.types
--- /tmp/mime12/etc/mime.types 2023-02-11 06:45:22.000000000 -0700
+++ /etc/mime.types 2023-03-20 19:46:13.000000000 -0600
@@ -1574,6 +1574,7 @@
application/x-oz-application oza
application/x-pkcs7-certreqresp p7r
application/x-pki-message
+application/x-posiwgnpntxd
application/x-python-code pyc pyo
application/x-qgis qgs shp shx
application/x-quicktimeplayer qtl
It was meaningless gibberish. Maybe some kind of encoded text. Google didn’t help. The strangest part? The modification timestamp matched the day I installed the system.
…
Great. An assassin.
All the worst scenarios flashed through my mind. A hacker? A supply-chain attack? Is that you, Jia Tan?
I checked the journald logs for unusual login attempts. Nothing. The Pi was never exposed to the internet, and my friend doesn’t know Linux.
So I checked the bash history. As I scrolled through it, I reviewed everything I had installed on this system.
Every package had come from apt… except for one thing.
TurboPrint.
It is closed-source. And instead of apt, it used its own binary installer.
Prime suspect.
I ran strings on its binaries to see what was inside:
$ strings /usr/bin/turboprint | grep mime
/etc/mime.types
$ strings /usr/bin/turboprint | grep application
application/x-p
...
Other TurboPrint executables - /usr/bin/tpconfig, /usr/bin/tpsetup, and so on - showed the same results. At this point, I was ninety-nine percent sure. It had to be the one.
But I didn’t have proof. I needed that last one percent. And more importantly, I needed to decide what to do next.
The Investigation
Once I calmed down a little, I decided to run an experiment. I would install TurboPrint on a clean machine and see whether it really tampers with mime.types. This time I tested on an x86 virtual machine, using inotifywait to monitor system file changes, hoping to catch anything unusual.
$ sudo inotifywait -m -r /etc /usr /bin /sbin /boot /var /home /root /opt --exclude '^/var/log(/|$)' -e create -e modify -e delete -e attrib -e move > inotifywait_install.log
Setting up watches. Beware: since -r was given, this may take a while!
Watches established.
Then I went ahead and installed TurboPrint.
$ wget https://www.zedonet.com/download/tp2/turboprint-2.58-1.x86_64.tgz
$ tar -zxf turboprint-2.58-1.x86_64.tgz
$ cd turboprint-2.58-1
$ sudo ./setup
TURBOPRINT 2 INSTALLATION
Installation language (e)nglish or (d)eutsch? e
./setup.sh: line 201: /var/log/turboprint/install.log: No such file or directory
./setup.sh: line 202: /var/log/turboprint/install.log: No such file or directory
./setup.sh: line 207: /var/log/turboprint/install.log: No such file or directory
Installation for CUPS printing system (TP_CUPS=1)
Configuration files will go to.. /etc/turboprint
Shared files will go to......... /usr/share/turboprint
Executable files will go to..... /usr/bin
Logfiles files will go to....... /var/log
Documentation will go to........ /usr/share/doc/turboprint
Browser for documentation....... firefox
(edit system.cfg to change installation paths)
Begin installation now (y/n)? y
Copying program files...
install: omitting directory 'lib/appindicator'
install: omitting directory 'lib/gimpplugin'
install: omitting directory 'lib/gnomeapplet'
install: omitting directory 'lib/kde3applet'
install: omitting directory 'lib/kde41applet'
install: omitting directory 'lib/kde42applet'
install: omitting directory 'lib/kde5applet'
done
Installing TurboPrint daemon with systemd
Restarting TurboPrint printer port daemon
Creating PPD printer description files...
done
Updating existing TurboPrint printer entries...
done
Installing bjnp network backend for canon printers
Installing Ghostscript version for TurboPrint
E: Unable to locate package python-gobject
RESULT 0
Checking shared libraries:
(add missing libraries with your package manager)
* gdk library NOT found (part of gtk)
* gdk library NOT found (part of gtk)
* gtk library NOT found
Checking filter programs:
(if required, add missing packages with your package manager)
gs found (needed for PS,PDF,FIG,DVI,troff,html,ASCII)
lp found (command line printing)
Installation completed
HTML documentation can be found in /html /usr/share/doc/turboprint/html
Do you want to read the manual now (y/n)? n
$
Now, what did inotifywait.log capture?
/usr/bin/ CREATE csrh
/usr/bin/ MODIFY csrh
/usr/bin/ ATTRIB csrh
...
/etc/ MODIFY mime.types
/etc/ ATTRIB mime.types
And take another look at mime.types:
$ cat /etc/mime.types | grep application/x-p
...
application/x-pojqujcbptxd
...
The same unreadable text showed up again. Caught red-handed.
So what happens if I uninstall it? Same monitoring setup, then remove the package:
$ sudo ./uninstall.sh
Turboprint deinstallation
=========================
Will delete the following directories:
/etc/turboprint
/usr/share/turboprint
/usr/lib/turboprint
/var/log/turboprint
/var/spool/turboprint
And the following files:
/usr/bin/tpprint
/usr/bin/tpsetup
/usr/bin/tpconfig
/usr/bin/turboprint
/usr/share/man/man1/tpprint.1
/usr/share/man/man1/tpsetup.1
/usr/share/man/man1/tpconfig.1
/usr/share/man/man7/tpfilter.7
/usr/share/man/man7/turboprint.7
/usr/share/cups/model/turboprint
Start deinstallation now? y
Removing TurboPrint files...
Deinstallation complete
RESULT 0
$
/var/spool/ DELETE,ISDIR turboprint
...
/usr/local/share/ DELETE,ISDIR gpturboprint
/usr/bin/ DELETE gszedo
...
/etc/ DELETE,ISDIR turboprint
...
/usr/lib/ DELETE,ISDIR turboprint
/usr/bin/ DELETE tpprint
/usr/bin/ DELETE tpsetup
/usr/bin/ DELETE tpconfig
/usr/bin/ DELETE turboprint
/usr/bin/ DELETE turboprint-monitor
...
(Link to the full inotifywait_install.log and inotifywait_uninstall.log)
It did clean up almost all of its files. That part was handled quite neatly. But there were two exceptions.
/usr/bin/csrh was still there, and /etc/mime.types stayed modified.
$ cat /etc/mime.types | grep application/x-p
...
application/x-pojqujcbptxd
...
Not very tidy of it.
So what exactly is this leftover executable csrh supposed to be?
$ strings /usr/bin/csrh
...
fxww
w6Zxdg7n
j4e;
BXa6
...
No human-readable strings. Try running it directly.
$ csrh
bash: /usr/bin/csrh: cannot execute binary file: Exec format error
Something was wrong. Look closer:
$ file /usr/bin/csrh
/usr/bin/csrh: data
$ cat /usr/bin/csrh | head -c 30
`Ö�[]}�i]�T䆁�w�8�p퉏>m
It was not an executable at all. It was a block of unreadable data.
So what on earth was TurboPrint actually doing with it? I reinstalled TurboPrint once more and watched its behavior.
/usr/bin/turboprint required X11, so I switched to another executable. It required root to run:
$ sudo strace tpsetup
...
openat(AT_FDCWD, "/usr/bin/csrh", O_RDONLY) = 3
openat(AT_FDCWD, "/etc/mime.types", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=78309, ...}) = 0
fstat(4, {st_mode=S_IFREG|0644, st_size=78309, ...}) = 0
lseek(4, 77824, SEEK_SET) = 77824
read(4, "ttools.smacker\t\t\tsmk\nvideo/vnd.s"..., 485) = 485
lseek(4, 0, SEEK_SET) = 0
read(4, "################################"..., 77824) = 77824
read(4, "ttools.smacker\t\t\tsmk\nvideo/vnd.s"..., 4096) = 485
close(4) = 0
close(3) = 0
openat(AT_FDCWD, "/usr/bin/csrh", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1976, ...}) = 0
read(3, "`\303\226\243[]}\366i]\371T\344\206\201\310w\2558\364\3p\24\33<\355\211\217>m\375\333"..., 4096) = 1976
close(3) = 0
openat(AT_FDCWD, "/usr/bin/csrh", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=1976, ...}) = 0
read(3, "`\303\226\243[]}\366i]\371T\344\206\201\310w\2558\364\3p\24\33<\355\211\217>m\375\333"..., 4096) = 1976
close(3) = 0
...
(Link to the full strace_tpsetup.log)
It read those files many times but never modified them. Even so, I could not understand what it was trying to accomplish.
It opened /usr/bin/csrh several times. One time it did nothing. Another time it read its contents. It also opened /etc/mime.types, immediately seeking far into the file, clearly searching for that encoded piece of data.
I stared at the strace output without any clear idea of what to make of it. I wandered through the logs without direction. I doubted I could extract truly useful information from strace alone. At that point, reverse engineering seemed like the only path left. Then, suddenly, one line caught my eye:
write(1, "Demo version - trial period unti"..., 52Demo version - trial period until 13-Dec-2025 23:52
) = 52
Since I lack the original screenshot, the log here was reconstructed from bash history.
What exactly did it print? Run it again for a clearer look:
$ sudo tpsetup
**************************************************************************
TurboPrint Studio XL 2.58-1 (02-JUN-2025) (c) ZEDOnet GmbH
Demo version - trial period until 13-Dec-2025 23:52
**************************************************************************
=========================================================
TurboPrint printer config - main menu
=========================================================
Nr.Def.Short Configuration Connect Paper Quality Mode
------------------------------------------------------------------------------
<number> - change settings for a printer
S - Save changes & exit Q - Quit without saving
Your choice:
23:52. That was a few minutes ago, when I installed it for the first time.
This looked like DRM. Could it be?
I did not try to decipher their algorithm, nor did I want to reverse engineer it right away. I just wanted to see how it would react if I removed the traces it left behind.
I tried wiping them, one by one.
Here is what happened:
# first remove /usr/bin/csrh
$ sudo mv /usr/bin/csrh /usr/bin/csrh.bak
$ sudo tpsetup
**************************************************************************
TurboPrint Studio XL 2.58-1 (02-JUN-2025) (c) ZEDOnet GmbH
Demo version expired
**************************************************************************
...
$ sudo nano /etc/mime.types
# remove the garbled line in mime.types
$ sudo tpsetup
**************************************************************************
TurboPrint Studio XL 2.58-1 (02-JUN-2025) (c) ZEDOnet GmbH
*** unregistered ***
**************************************************************************
If I removed csrh, the trial expired immediately. If I removed the encoded line in mime.types, the trial switched to an “unregistered” state, which behaved the same as expired, still printing with a watermark. The only difference was that this state revealed an extra detail: TurboPrint no longer believed any DRM data existed in the system.
That was it. Everything became clear. This was TurboPrint’s DRM.
TurboPrint encrypts the installation time and hides it in two places. It leaves them behind after uninstallation so users can’t reset the trial by reinstalling. The files validate each other. If either one fails integrity checks, the system locks the trial. Break both, and it locks anyway.
Excellent. I could rule out hackers.
The Ghost of Technical Debt
Still, the whole matter keeps lingering in my mind.
Is this acceptable? Is this truly reasonable?
TurboPrint never mentions in its manual or license that it’ll touch /etc/mime.types, a core file in any Linux system. Hiding its data there is, in theory, a violation of system integrity, and in practice it caused real trouble - I ran into problems during the system upgrade.
And the sense of intrusion and alarm I felt was entirely genuine. In that moment, my immediate reaction was a supply chain attack.
Then there was /usr/bin/csrh. It was not an executable at all, yet it had execute permissions. /usr/bin/ is meant for real executables.
Imagine a sysadmin running a production environment. If they discovered something like this, their reaction would certainly be far more extreme than mine.
What If the System is Immutable…
If this had taken place a bit earlier, back when I was running openSUSE MicroOS on the same Raspberry Pi, what would have happened if I had tried to install TurboPrint?
MicroOS is an immutable system. Its root filesystem is read-only, and /etc/mime.types cannot be modified externally. Technically, make install or any self-contained installer like TurboPrint should never be used on it. But suppose I insisted. Would TurboPrint’s installer simply fail? And if I had to unlock the root filesystem to install it, would the system still behave correctly afterward? Would upgrades still work?
Even sneakier: TurboPrint provides both deb and rpm packages on x86, yet in my testing both formats left behind the same DRM traces after removal.
If you have used immutable systems, you probably already feel uneasy. Let me spell out the scenario.
Imagine a (very unlucky) Fedora Silverblue user with an ancient printer like mine, who needs to print special media such as CD covers. They have no choice but to use TurboPrint. They download the rpm package and run rpm-ostree install. Installation succeeds, and the printer works.
Later, they decide they no longer need TurboPrint. They run rpm-ostree uninstall turboprint. Everything seems fine.
But TurboPrint’s DRM leftovers remain in the root filesystem. Silverblue now enters an unstable, or at least uncertain state. The next time they use rpm-ostree, it may fail due to this unexpected contamination, forcing a rollback of the entire system. Let us assume they wouldn’t continue running it in that compromised state.
I am not nitpicking here. Immutable systems are slowly moving into the mainstream, and TurboPrint is, in some cases, the only viable option.
The Shadow of Supply Chain Attacks
Back to the moment that nearly made my heart stop:
Configuration file '/etc/mime.types'
==> Modified (by you or by a script) since installation.
...
+++ /etc/mime.types 2023-03-20 19:46:13.000000000 -0600
Why was my first thought a supply chain attack?
Because of the 2024 XZ Utils backdoor incident.
A maintainer who went by “Jia Tan” spent years building trust in the community, then introduced a backdoor into xz. That backdoor nearly entered every major Linux system worldwide.
Technically, TurboPrint’s DRM has nothing in common with the xz backdoor. But after that event, the entire Linux community’s security mindset changed forever.
Any unexpected modification to system files is no longer viewed as sloppy or unprofessional. It is recognized as a danger signal.
I initially wanted to rip TurboPrint apart in a scathing post, post it to Hacker News, maybe even give it some free publicity. But then I calmed down and realized… it wasn’t malicious.
It’s just outdated.
Generational Clash
To untangle the mystery of this DRM design, we need to go back to TurboPrint’s origins.
In 1988, TurboPrint was created as a printer driver for the Amiga.
In 1991, Linux 1.0 was released.
Around 1999–2000, the first version of TurboPrint for Linux appeared.
In 2007, TurboPrint for the Amiga received its final update.
In 2008, TurboPrint for Linux 2.0 was released, introducing the DRM mechanism we see today.
2008. Seventeen years ago.
What was Linux like back then?
- The latest Debian release was 5.x (Lenny).
- GNOME 2 and KDE 3 were the mainstream desktop environments.
- systemd didn’t yet exist.
- SELinux existed but was far from widespread.
Containers and immutable systems were nowhere near the horizon.
More importantly, package managers were not the unbreakable rule they are today. If you experienced Linux over a decade ago, you’ll remember this standard procedure:
./configure
make
sudo make install
make install copied files directly into system paths, completely bypassing the package manager. Manually appending new types to /etc/mime.types was taken for granted.
TurboPrint’s ./setup followed the same philosophy. The only difference was that it provided a GUI.
No one saw an issue. It was simply how things worked.
But seventeen years passed. We lived through the xz backdoor incident. We now have Docker, Snap Flatpak, and immutable systems like Silverblue and MicroOS. Supply chain attacks are real concerns, and system integrity matters.
The world changed, yet TurboPrint’s DRM design remains frozen in 2008.
No Perfect Answers
TurboPrint does break the expectations of modern Linux.
But the problem is not just the seventeen-year gap. It is also the eternal dilemma of offline DRM.
If I travelled back to 2008 and tried to think like a developer of that era: I need to prevent trial resets, but many machines might not be online and hardware fingerprints aren’t reliable.
What would I do?
I might have hidden a marker inside /etc/mime.types as well.
Fast forward to 2025, is that design completely indefensible?
From a privacy standpoint, TurboPrint’s approach is actually restrained.
It collects no user data, doesn’t access hardware identifiers, and doesn’t even touch the internet. It simply hides the installation time in an inconspicuous location.
Under GDPR, this may well be the safest path - after all, ZEDOnet GmbH, TurboPrint’s developer, is based in Germany.
Online DRM irritates users. Offline DRM either leaks or frustrates sysadmins.
Linux system integrity and perfect offline privacy - suddenly, it’s impossible to have both.
An Insect in Amber
And with that, the story of TurboPrint nears its end.
I understand the full history. I accept its limitations.
Yet I still feel conflicted.
It’s like an insect trapped in amber, suspended in the world seventeen years ago.
How should I view it?
With tolerance, or with criticism?
Maybe no clear answer is needed.
It simply stands there, the last witness of a bygone era.
One Last Puzzle
Remember the Raspberry Pi (arm64) where TurboPrint displayed “Demo version expired” from the moment it was installed?
I tested it later on another arm64 virtual machine, and the result was the same. The arm64 build of TurboPrint has a broken trial mode, identical to what I saw on the Pi. x86 versions worked fine.
Can I fix it? Stay tuned for the next episode.