So I'm looking at this stack of boxes in the living room, and I'm thinking about how every single one of them has a barcode, and there's a cart with a laptop taped to it, and Daniel's been muttering about URL patterns for three days.
The unpacking cart. He mentioned it last week — I thought he was joking about the VHB tape.
He was not joking. Here's what he sent us. Daniel's finishing the unpacking process in the new apartment, and he's built what he calls a makeshift restocking trolley. The job is simple: gather up loose items from around the living room, scan them, assign them to a storage box, and move on. The inventory system he's built is a fork of an open-source project called Homebox — hay-kot's project on GitHub, web-based, Docker-deployed, barcode support built in. His fork has become, in his words, its own thing at this point. The workflow he wants: scan an item's barcode, enter the box number, hit save. That's the whole interaction. The hardware he's imagining is an old laptop with a USB barcode scanner, and a battery VHB'd to the underside of the cart because a power cord is a trip hazard. His question is whether a whole laptop is overkill, whether a tablet with a Bluetooth scanner would be more natural, and what the right software stack is for making Linux handle a driverless USB scanner and automatically route barcode input to a web application. He knows there are off-the-shelf warehouse solutions for this — he's asking about the hacky DIY version, using whatever old hardware he can find.
There's a lot in there. The hardware question, the software question, the battery question — and underneath all of it, the question of whether dedicating an entire computer to one task is actually smart or just fun.
We're going to build this thing on paper today. Laptop versus tablet versus single-board computer, Linux kiosk mode, HID keyboard emulation, battery engineering, and whether the DIY path saves you money or just costs you weekends.
And the answer to that last one is usually both.
It really is.
Let's start with what this is really about, because it's bigger than a barcode scanner on a cart. This is about the gap between general-purpose computing and task-specific appliances — and how Linux blurs that line. A general-purpose computer is designed to do everything tolerably well and nothing perfectly. A task-specific appliance does exactly one thing and does it every time you turn it on. The kiosk mode concept — and the Arch Wiki has a whole page on this — is the bridge between those two worlds. You take a general-purpose machine, strip away everything that isn't your one task, and you're left with something that behaves like an appliance.
The Raspberry Pi version of this is well-trodden territory. Digital signage, information terminals, point-of-sale systems — a single-board computer running one full-screen application, no desktop, no notifications, no surprises. What Daniel's asking is whether the same philosophy works at laptop scale, with a web application as the interface and a barcode scanner as the only input device.
And Homebox is the right starting point for understanding why this makes sense. It's an open-source home inventory system — web UI, barcode support, Docker-based deployment, SQLite or Postgres on the back end. The quick-start guide shows a Docker Compose setup that spins up the whole thing in one command. Daniel's fork is a customization of that — he's built on top of it, added his own asset and storage box model, presumably tweaked the scanning workflow to match how he actually organizes things.
The fork is its own thing now, he says. Which is a phrase that should make anyone who's maintained software pause for a moment — but we'll get to that.
We will. But first, the hardware decision tree, because that's where the physical reality of this project lives. You've got three broad options: an old laptop, a tablet, or a single-board computer with a screen attached. Each one forces different tradeoffs, and the right answer depends on which tradeoffs you actually care about.
Walk me through them.
The laptop case is the one Daniel's already leaning toward, and it's got real advantages. Built-in screen, built-in keyboard, built-in battery, USB ports that Just Work, and — this is the part people don't think about — a VESA mount pattern on the back of a lot of older ThinkPads. You can bolt a laptop to a cart arm with a fifteen-dollar mount. The cons are bulk, weight, and power draw. A laptop is a whole computer, and it's designed to be a whole computer even when you're only using it as a barcode terminal.
The tablet path seems cleaner on paper. Better form factor for a cart, touch interface that makes the box-number entry feel natural, battery life measured in days rather than hours. The problem is Bluetooth.
The problem is absolutely Bluetooth. Most barcode scanners that connect over Bluetooth present themselves as HID keyboard devices — same as their USB counterparts. The scanner reads a barcode, converts it to keystrokes, and sends those keystrokes to the host device exactly as if someone typed the barcode number and pressed Enter. On a desktop operating system, this works transparently. On Android or iOS, it works most of the time, until it doesn't. The issue is that mobile operating systems handle HID keyboard input differently than desktop operating systems, and inconsistently across versions. Non-ASCII characters get mangled. Rapid-fire scanning sequences can drop characters or insert them out of order because the OS buffers keyboard input in ways not designed for a scanner firing at a hundred characters per second.
So the scanner works perfectly in the demo and then fails silently on box number three when you're actually trying to get things done.
That's the failure mode. And it's the kind of failure that drives people to throw things across the room, because there's no error message — the barcode just doesn't register, or it registers wrong, and you don't notice until you can't find the thing you scanned three days ago.
Which brings us back to USB.
USB is the simplest part of this entire project. A USB barcode scanner is a keyboard. That's it. It's a keyboard with exactly one key — the barcode — and it types that key followed by Enter. The operating system sees a standard HID keyboard device. No drivers, no configuration, no special software. You plug it in, you open a text editor, you scan a barcode, and the number appears. This has been true for decades — it's why barcode scanners work with everything from DOS terminals to modern Linux distributions without anyone writing a driver.
So the challenge isn't getting the scanner to work. The challenge is getting the operating system to do the right thing with the input once it arrives.
And this is where Linux kiosk mode becomes the right answer. The Arch Wiki page on kiosk mode lays out the approach: a minimal X session with a single application, auto-login, no desktop environment, no notification daemon, no window manager chrome. You boot the machine and it goes straight to a full-screen browser pointed at your web application. The user never sees a desktop, never sees a login screen, never interacts with anything that isn't the Homebox web UI.
The specific components: a minimal window manager like Openbox or i3, configured to launch exactly one window — the browser — in full-screen mode. Auto-login via a display manager or a systemd override that logs in a dedicated kiosk user on boot. The browser itself launched with kiosk flags — Chromium has a kiosk mode flag that hides all UI chrome, Firefox has something similar. The result is a machine that, from cold boot to ready-to-scan, takes maybe fifteen seconds and presents nothing but the inventory interface.
And the barcode routing — this is the part Daniel was asking about with the URL pattern detection. The elegant way is a tool like xdotool or a custom udev rule that watches for input from a specific USB device and routes it to the browser window. You write a small script that detects when the scanner sends a string matching a barcode pattern — typically a sequence of digits of a known length, terminated by a newline — and then constructs the appropriate URL and sends it to the browser.
The simpler way, and the one I'd probably start with, is to just let the web application handle it. Homebox already has a barcode input field. If that field is always focused — if the page loads with the cursor in the scan input — then the scanner's output lands there automatically. The web app receives the barcode number, does its lookup, and populates the item. No OS-level routing needed at all.
That's the pragmatic answer. The scanner types into the focused field, the web app does the rest. The only thing you need to ensure is that the field never loses focus — which is a JavaScript problem, not an operating system problem. A few lines of code to refocus the input if the user clicks elsewhere, and you're done.
So the software stack for the laptop approach is: minimal Linux install, no desktop environment, Openbox or i3, auto-login, Chromium in kiosk mode pointed at the Homebox instance, scanner plugged into USB, input field always focused. That's a Saturday afternoon of configuration, not a month-long project.
And once you've done it once, you can image that setup onto any old laptop and have a dedicated inventory terminal in under an hour. The configuration is reproducible. That matters when the hardware eventually dies and you need to swap in a replacement.
Let's talk about where the Homebox instance actually lives, because that's a design decision that changes the shape of the project. You can run Homebox locally on the same laptop — Docker on the cart machine, SQLite database, everything self-contained. Or you can run Homebox on a server elsewhere on the home network and have the cart laptop be a thin client that just points a browser at it.
The local approach means the cart works even if the network is down, but it means maintaining a Docker installation and a database on a machine that's bolted to a trolley and running off a VHB'd battery. The networked approach means the cart is just a browser — lighter, simpler, fewer things to break — but you need reliable WiFi everywhere you're pushing the cart.
In an apartment, WiFi coverage is probably fine. For Daniel's use case, I'd lean toward the thin client model — run Homebox on whatever machine is already serving his other Docker containers and point the cart browser at it. One less thing to manage on the cart itself.
Agreed. And that also solves the data persistence problem — if the cart laptop dies, the inventory database is safe on the server.
Now the battery. This is where the DIY approach hits real engineering constraints, and it's the part most people skip past because it's not fun to think about.
It's the hidden gotcha. A laptop battery is designed for intermittent use — you charge it, you unplug it, you use it for a few hours, you plug it back in. If you leave a laptop plugged in and running twenty-four seven — which is what a cart-mounted inventory terminal effectively does — the battery sits at one hundred percent charge constantly, which degrades lithium-ion cells faster than anything except deep discharge. And if you're also drawing power for a USB scanner and the screen is on all day, the battery is cycling in tiny increments — discharge a few percent, charge back up — which is even worse for longevity.
So the laptop battery that seemed like a feature becomes a liability within six months. Capacity drops, runtime shrinks, and eventually the thing won't hold a charge at all.
There are mitigations. Some laptops let you set a charge threshold in the BIOS — ThinkPads have this, you can cap charging at eighty percent or sixty percent, which dramatically extends battery life when the machine is mostly plugged in. But that's still a laptop battery doing a job it wasn't designed for.
The alternative is to treat the power problem as a separate engineering task. Remove the laptop's internal battery entirely — or use a machine where it's already dead — and build an external power system. A small twelve-volt LiFePO4 battery pack with a buck converter to step down to the laptop's input voltage, mounted to the cart. Or, even simpler, a sealed lead-acid battery — the kind used in UPS units and mobility scooters — with a charger module and a car lighter socket wired to a laptop car charger.
That sounds absurdly heavy for a cart that's being pushed around an apartment.
It does. But it would work for years with basically zero maintenance.
The weight is the tradeoff. A twelve-volt seven-amp-hour SLA battery weighs about five pounds. A LiFePO4 pack of equivalent capacity weighs maybe two pounds and costs three times as much. Either one, properly mounted, solves the battery degradation problem completely because you're using a chemistry designed for float charging — sitting at full charge and delivering power continuously.
And the VHB tape. Daniel mentioned VHB-ing the battery to the underside of the cart, and I just want to note that VHB tape is remarkable stuff — it's used in construction to bond structural panels — but it's also a permanent solution to a temporary problem. Once that battery is taped to the cart, it's not coming off without a fight.
The cart is already a dedicated inventory station. I don't think permanence is the problem there.
Fair.
Let's talk about the off-the-shelf comparison, because Daniel mentioned he knows this exists in warehousing, and the contrast is instructive. A Zebra TC53 mobile computer — a current enterprise handheld — costs somewhere between fifteen hundred and three thousand dollars depending on configuration. It's ruggedized, it has a hot-swappable battery, it has a purpose-built barcode scanning engine that's faster and more accurate than any USB scanner, and it runs Android with Zebra's enterprise mobility stack on top. It's designed to be dropped onto concrete, used in the rain, and scanned ten thousand times a day for five years.
Daniel's version is a fifty-dollar ThinkPad T430 from eBay and a twenty-dollar USB scanner from Amazon. That's two orders of magnitude difference in cost.
And the Zebra will work perfectly out of the box, every time, for years. The ThinkPad will work perfectly after you configure it, most of the time, until the battery degrades or the WiFi drops or the Docker container needs restarting. The question isn't which one is better — the Zebra is objectively better at being a barcode scanner. The question is whether the gap between them matters for scanning a few dozen items in a living room.
For Daniel's use case, the DIY version is probably the right answer, but not because it's cheaper. It's the right answer because it's his system. He built the inventory software. He knows how it works. If something breaks, he can fix it. With the Zebra, he'd be adapting his workflow to someone else's scanning application, someone else's data model, someone else's idea of how inventory should work.
The flexibility is the real value proposition of the DIY path. Once you have a Linux machine on a cart with a scanner and a browser, you can add features that no off-the-shelf terminal would support. Label printing — plug in a thermal printer and add a print button to the web UI. Location tracking — add a field for shelf number or room and update the database schema. The off-the-shelf path gives you reliability but locks you into the feature set someone else designed. The DIY path gives you exactly the features you need and nothing you don't.
Which brings us to the fork question. Daniel said his Homebox fork is its own thing at this point. That's a statement that carries weight.
It does. Maintaining a fork of an active open-source project is a commitment. Homebox is under active development — hay-kot is pushing commits, fixing bugs, adding features. Every time the upstream project releases a new version, Daniel has to decide whether to merge those changes into his fork. If his customizations are deep enough — if he's changed the data model, rewritten the scanning workflow, modified the UI in ways that conflict with upstream changes — merging becomes progressively harder over time. Eventually it becomes impossible, and the fork is truly its own project.
Which is fine, as long as you know that's what you're signing up for. The burden isn't the initial fork — that's a weekend of work. The burden is year three, when upstream has added features you want but your codebase has diverged so far that merging them is a rewrite.
And the security angle. Web applications have dependencies, dependencies have vulnerabilities, vulnerabilities get patched in upstream releases. If you're not merging upstream, you're on the hook for tracking and applying those patches yourself. For a home inventory system, the attack surface is small — it's on a local network, behind a router, not exposed to the internet. But it's not zero, and it's worth being aware of.
The flip side is that a fork that's its own thing is also fit for purpose. Homebox is designed for general home inventory — it has features Daniel doesn't need and probably lacks features he does need. His fork presumably strips out the irrelevant parts and adds the asset-to-box association workflow that's central to his system. That's not technical debt, that's customization. The question is whether the customization is worth the maintenance burden, and for someone who's already invested what Daniel has in this inventory system, I suspect the answer is yes.
I think so too. And the cart project is the natural extension of that investment. He's built the database, he's built the web interface, he's labelled everything with barcodes — the cart is the physical interface that makes the whole system usable day to day. Without it, he's walking back and forth to a desktop computer every time he wants to scan something. The cart closes the loop.
So where does that leave us on the hardware recommendation? If I'm Daniel, I'm looking at this and thinking: old laptop, USB scanner, minimal Linux install with kiosk mode, Homebox running on the home server, cart browser pointed at it, battery solution to be determined once I've seen how the laptop battery actually holds up.
That's the sensible path. Start with the laptop's internal battery — set a charge threshold if the BIOS supports it — and see how it goes. If the battery degrades in six months, that's when you look at external power solutions. The laptop itself is the right form factor for this. A tablet with Bluetooth introduces reliability problems you don't need. A single-board computer with a separate screen introduces cabling and mounting complexity you don't need. An old laptop is a self-contained unit with a screen, keyboard, battery, and USB ports in one package. For a cart-mounted terminal, that's hard to beat.
The one thing I'd add: pick a laptop with a matte screen. Glossy screens are miserable under overhead lighting, and a cart is going to be pushed under every light fixture in the apartment.
That's a practical detail. Matte screen, USB ports on the side rather than the back so the scanner cable doesn't get crushed against the cart handle, and a machine that boots from an SSD rather than a spinning disk because the cart is going to get bumped.
The SSD point is real. A spinning hard drive on a moving cart is a data loss waiting to happen. Even a cheap SATA SSD eliminates that failure pattern entirely.
Let's zoom out for a moment, because there's a broader principle here that's worth naming. What Daniel's building is a task-specific computing appliance using general-purpose hardware and open-source software. That's a pattern that shows up everywhere once you start looking for it. The point-of-sale terminal at a coffee shop — that's a PC running a full-screen POS application. The check-in kiosk at a doctor's office — that's a tablet locked to a single app. The flight information display at an airport — that's a Linux box driving a screen. None of these are custom hardware. They're general-purpose machines stripped down to one function.
The difference is that those are commercial deployments with support contracts and managed fleets. Daniel's version is one guy with a cart and a GitHub fork. But the principle is identical — take a general-purpose machine, remove everything that isn't the task, and you have an appliance.
And Linux is the operating system that makes this pattern possible at zero cost. Try building a kiosk-mode appliance on Windows and you're fighting the OS every step of the way — forced updates, license activation, Cortana popping up to ask if you need help. Try it on macOS and you can't even run it on arbitrary hardware. Linux lets you strip the OS down to exactly the components you need and nothing else. That's not a feature, it's the defining characteristic of the platform.
The other thing Linux gives you is reproducibility. Once you've written the configuration — the package list, the window manager config, the systemd unit files, the browser launch script — you can reproduce that exact setup on any machine. The cart laptop dies? Grab another old laptop, run the setup script, swap the USB scanner, and you're back in business in twenty minutes. That's the kind of resilience that matters for a system you actually depend on.
I want to circle back to something Daniel mentioned in passing — the URL pattern detection. He said if a URL pattern is detected, it should be automatically launched in the default browser. I think he might be overcomplicating this. The scanner doesn't produce URLs. It produces barcode numbers. The web application is what turns a barcode number into a URL — or more likely, into an API call or a form submission. The OS doesn't need to detect URL patterns because there are no URL patterns to detect. The scanner types a number, the web app receives it, the web app does the lookup.
Unless he's thinking of encoding URLs directly in barcodes — QR codes can contain URLs, and some inventory systems use that pattern. Scan a QR code on a box, the scanner outputs a URL, the OS opens it in a browser. That's a valid approach, but it's not what he described. He described scanning an item barcode and then entering a box number — two separate inputs that the web application combines into an association.
Right. And for that workflow, the always-focused input field is the right solution. The scanner types the item barcode, the web app looks it up and displays the item, Daniel types or selects the box number, hits save. No OS-level routing, no URL detection, no custom udev rules. Just a web form that's designed for the workflow.
The elegance of that approach is that it works exactly the same whether the scanner is USB or Bluetooth, whether the OS is Linux or Windows or Android, whether the browser is Chromium or Firefox. The scanner is just a keyboard. The web app is just a web app. The complexity lives in the application layer, where it belongs.
I've been hearing something for the last few minutes.
What?
Hilbert. He's been unusually quiet.
He's been making a face.
I wasn't going to say it.
You didn't have to.
Hilbert: Nineteen ninety-eight. I spent a summer working in a warehouse in New Britain, Connecticut. They had a DOS-based inventory system running on a clamshell terminal with a tethered CCD scanner. The thing weighed about twelve pounds. The battery was a lead-acid gel cell from a mobility scooter, strapped to the bottom with two metal brackets and a bungee cord. It ran for eight years.
Eight years on a single battery?
Hilbert: Same battery the whole time I was there. I checked in with a guy a few years later — still going. The trick was the charger. It was a dumb trickle charger, maybe half an amp. The battery sat at float voltage its entire life. Never cycled, never deep-discharged, never got hot. Lead-acid loves that. Lithium hates it.
So you're saying skip the laptop battery entirely.
Hilbert: I'm saying you're overthinking the battery. A twelve-volt seven-amp-hour SLA battery is thirty dollars. A charger module is ten. A car lighter socket is five. Wire it up, VHB it to the cart, plug in a laptop car charger. Done. It'll outlast the laptop.
That's... actually a completely reasonable solution. The weight is the only downside.
Hilbert: Five pounds. The cart's already got a laptop on it.
He's not wrong.
Hilbert: The software, though. That's where this falls apart. That terminal I used — it ran the same inventory software the whole time I was there, and it was never updated. Not once. The vendor released three new versions while I worked there. My boss had the floppy disks sitting on his desk. Never installed them.
Why not?
Hilbert: The update procedure required a serial cable and a specific baud rate — nine-six-hundred, eight data bits, no parity, one stop bit. The cable was missing. Nobody could figure out the baud rate settings in the terminal's BIOS. So the software stayed frozen at version two-point-one until the hardware died. Which it never did. I went back in two thousand four — same terminal, same software, same barcode labels peeling off the same shelving units.
So the fork maintenance problem is real, and you're living proof that set-and-forget becomes set-and-fossilize.
Hilbert: The system worked fine. It didn't need updates. It scanned barcodes, looked up part numbers, printed pick lists. That's all it ever needed to do. Your friend's Homebox fork — if it does what he needs today, it'll do what he needs in five years. The barcode standard hasn't changed since the nineteen seventies. The only thing that breaks is the hardware.
And when the hardware breaks, you swap in a new laptop and reimage it from the setup script.
Hilbert: If you remembered to write the setup script.
That's the real insurance policy. Document the configuration. Script the setup. Store it somewhere that isn't the cart laptop. Because the cart laptop will die, and when it does, you won't remember which three config files you edited at two in the morning six months ago.
Hilbert: I still have that terminal. It's in my garage. The battery's dead now — finally gave out around twenty-ten. But the machine still boots. DOS six-point-two-two. Forty megabyte hard drive. The inventory database has parts in it that haven't been manufactured since the Clinton administration.
Do you ever fire it up?
Hilbert: Every few years. The barcodes still scan.
There's something almost poetic about a machine that does one thing for decades and never asks for an update.
Hilbert: It's not poetry. It's a tool. Tools don't need updates. They need to work.
The cutting-room floor detail I keep coming back to is the Arch Wiki's kiosk mode page. It recommends a dedicated user account with no password, auto-login via systemd, and a minimal X session that launches exactly one application. But the part that surprised me is the security consideration — they recommend locking down the session so the user can't escape the browser with keyboard shortcuts. Control-W, Alt-F4, Control-Alt-Delete — every one of those is a way to break out of kiosk mode and get to a desktop. The solution is to configure the window manager to ignore those key combinations entirely. It's a small detail, but it's the difference between a kiosk that stays in kiosk mode and one that doesn't.
That's the kind of thing you discover on day three of using the cart, when you accidentally hit Control-W and your inventory interface disappears and you're staring at an empty desktop with no idea how to get back.
The configuration is the product. The hardware is just what it runs on.
Which leaves us with one open question. Is the cart the right abstraction at all? Daniel's workflow is gather items, scan them, assign them to boxes. That could also be done at a fixed scanning station — a desk with a scanner and a computer, where you bring items to the station rather than bringing the station to the items. The cart solves the gather-and-sort problem by making the scanning mobile, but it introduces the battery problem, the mounting problem, the bumping-into-furniture problem. A fixed station eliminates all of that at the cost of more walking back and forth.
For an apartment, I think the cart makes sense. The distances are short, the number of items is finite, and the whole project is temporary — once everything is unpacked and sorted, the cart goes into storage. For a warehouse, a fixed station would be the right call. For a living room with boxes everywhere, mobility wins.
And the broader principle — task-specific Linux appliances — that outlives the barcode scanner. Phone cameras are already doing barcode scanning via machine learning. Object recognition is getting good enough that you might not need barcodes at all in a few years. But the idea of taking a general-purpose computer and stripping it down to one function — that's not going anywhere. If anything, it's becoming more relevant as general-purpose operating systems get more complex and more distracting.
The single-purpose machine is a reaction against the everything machine. Your phone does everything, so it does nothing particularly well. Your laptop does everything, so it's constantly interrupting you with updates and notifications. The kiosk-mode terminal on a cart does exactly one thing, and it does it every time, and it never asks for your attention unless there's a barcode to scan. There's a kind of clarity in that.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop, who apparently has a DOS terminal from the nineties in his garage and has been waiting twenty-eight years to tell someone about it.
If you want to hear more about kiosk mode Linux, single-board computer projects, or the Homebox inventory system, let us know — email the show at show at my weird prompts dot com. And if you've built your own task-specific Linux appliance, we want to hear about it.
We'll be back soon.
