I’m sitting in a lobby with a book in my hands. The display systems in this fine establishment are undergoing their routine restart. It takes anywhere between half an hour and an hour; at this point, I’ve memorized the rhythm. I sigh, open my book, and wait. This happens every single time I visit, and I don’t mean the book part.

A friend of mine was once called in to advise this establishment¹.

— You seem to deeply love Linux.

— Why are you trying to frame your business’s problem as a matter of my feelings?

Instead of addressing his architectural concerns, they insisted on keeping this layer of several complex, interdependent systems. Looking back, his concerns made perfect sense.

This is the deflection your own team may be making when someone flags a real problem, a rhetorical self-defense. And the business is paying for it.

I can already hear the argument:

You don’t understand how things work here, retraining staff is a real cost.

Fair enough.

Ask your support team what a typical workday actually looks like. A large share of it is remote-rebooting things.

That’s not support work. It’s absorbing a design flaw. A properly built system recovers itself: it restarts frozen programs from where they stopped, survives a power cut without corrupting anything, comes back online without anyone filing a ticket. Your home router does all of this. So can a lobby display.

Other systems exist to do one narrow job: display a schedule, play a playlist, present a menu. Nothing more. Most of us have seen train schedules, jumbotrons, and heard some music in public. These don’t need a massive general-purpose system on a general-purpose computer.

Fifteen, maybe ten years ago, wheeling in a desktop PC to run a lobby display was the sensible call. The small-board alternatives weren’t mature, the tooling wasn’t there, and a tower PC was what every vendor knew how to sell you. That’s no longer the situation. Hardware miniaturized a decade ago. What you’re running is technical debt² in its purest form. It may have been reasonable when it was installed. Keeping it now is an active choice.

It’s different here: our workflows entirely depend on the vendor software and replacing it properly requires an upfront budget.

So does keeping a full-time IT squad on standby to perform CPR on a fragile mess.

The engineering work this used to require has gotten dramatically cheaper. Mature open-source build systems, well-documented embedded SDKs, and the kind of senior engineer who can stitch them together over a couple of evenings: none of these were realistically available to a small business ten years ago. They are now.

What you’re running now isn’t just inefficient. It’s malpractice.

On hardware choices

There’s an entirely different category of hardware built for limited, dedicated tasks: embedded systems.

Microcontrollers were once seen as something to run a boring kind of watch with a boring-looking display. Nowadays, one powers a smartwatch I wear with a brilliant screen and a custom firmware I wrote for my specific tasks. It can play music, run visuals, and react to touch very well. And the processing chip driving it all costs pennies in bulk.

This watch runs exactly the hardware it needs. Because the hardware is lean, the software can be too. For a jumbotron, the business logic³ is typically simple: connect to a server, receive playlist data, play it. When you use a full PC for this, you are wrapping that simple task inside a massive, chaotic ecosystem of OS updates, background tasks, and system registries that have nothing to do with playing music. A real-time operating system strips all that noise away. It doesn’t do anything else. It just executes your business logic, flawlessly and instantly.

SoC boards for anything video. MCUs and RTOSes for anything simpler. When you need x86, a stripped-down Linux does the job without the desktop overhead. You probably carry a similar system in your pocket already. Your smartphone runs on the same family of chips and rarely crashes. That’s not an accident. It’s the right hardware for the task.

Back to the things keeping you stuck

The wrong class of hardware costs money in the long run. Expensive general-purpose PCs are one way to bleed it. Cheap, outdated general-purpose PCs, which is what many places actually buy, are the other.

A wrong choice of the hardware and software stack kills client loyalty, destroys your reputation, and eventually shows up on your KPIs, after the customers start leaving.

Making the right choices will help you serve clients better and eventually turn a long pile of technical complaints into a long list of solved problems.

You don’t need to use a full-fledged PC to play music

There’s no integration problem to solve here. You already have a server. Embedded devices speak the same standard protocols the rest of your stack already uses, the same way your phone talks to a website, and beyond. Let an MCU do its job of playing music, providing basic UIs and reacting to the touchscreens. For anything more complex, stream it. The display doesn’t need to generate the visuals, just show them.

You’ll get a device that responds faster, handles touch better, and boots in seconds instead of an hour. That’s exactly the gap your customers notice when they’re deciding whether to keep coming back.

You don’t need to use a full-fledged PC to show videos

Most jobs you currently throw a PC at will run on a Raspberry Pi. Smaller footprint, no fans, boot time measured in seconds. And if you absolutely need the x86 ecosystem but still want to shrink your hardware footprint, there’s LattePanda. LattePanda Mu is a very tiny x86 computer (69.6mm x 60mm), while the LattePanda Sigma packs a serious punch for heavier workloads while still being pretty small.

You don’t need to run a desktop OS to display three buttons

Windows is the canonical offender, but any desktop-first OS does the same damage when you conscript it into kiosk duty. Some operating systems do a ton of heavy lifting so a human can switch between spreadsheets, games, and browsers.

By deploying that same OS to act as an interactive panel, you are essentially hiring a neurosurgeon to flip burgers. You voluntarily invite the downtimes of system updates, the broad surface area for kernel bugs, a system registry, and network vulnerabilities. I’ve seen rooms full of well-paid professionals doing exactly this work.

Your move

As Rory Sutherland puts it:

Good customer service doesn’t look good on a spreadsheet⁴

— Rory Sutherland

Unless you have unlimited money and your customers have nowhere else to go, you don’t have infinite time to decide.

You already know who sent you this link. They can probably help. That’s why they sent it. If they’re not able to, there’s no shortage of people who solve real problems for real money. Start by listening to the person who sat down and spelled out your symptoms instead of billing you for another deployment of the same wrong stack.

Acknowledgments

This piece wouldn’t exist without a friend who prefers to stay unnamed. He diagnosed these problems long before I sat down to write about them. Thanks, man.