The printout may be dead but that beast of a print queue lives on

Opinion Just like an owner of a new puppy waking up to a scene of destruction, 3D printer users who leave long jobs running overnight may be appalled to see what they find in the morning.

In some cases, your printer might even create a phantom model without being instructed, print on top of another model sitting in the in-tray, or even break itself. Yes, really.

That's what happened to groups of Bambu Labs' 3S printer users in the middle of August. It was as if some ghostly power seized their robotic sculptors in their absence and commanded them to lose control. Sometimes the result was benign, or an attentive human managed to put a stop to it. Sometimes it was a disaster.

What had caused this "spooky action at a distance" was soon made plain: and it was because Bambu printers, like so many modern devices, relied on Bambu cloud services. And Bambu's cloud services had apparently gone haywire.

Bambu was quick to take responsibility, create a detailed report once it had established what went wrong, and put in place a range of fixes to stop it happening again. Meanwhile, the basic engine of the fibrillating filaments was nothing to do with 3D printing, but one that goes back to the days of dot matrix, daisy wheels, and DOS.

Queue you!

The fully paperless office may stay a fantasy for years yet. Many of us, probably including the youthful Bambu engineers, have paperless jobs, where powerful mobile devices, workable if unpleasant groupware, and ubiquitous connectivity have killed the printout. With the death of the printout came the extinguishing of that unspeakable beast, the print queue. Or so we thought.

Print queues were, and are, a necessary evil that show how a simple concept can evolve into a complex problem because it doesn't quite fit how people and computers actually work. In the days when you had to choose between saving a family holiday memory and a megabyte of the stuff, you plugged a printer into a personal computer with the brains of a trilobite that could do nothing except send your document, a byte at a time, until the deed was done.

Then multitasking and more memory arrived, and along came print spooler software. The spooler software took a copy of the printout and "told" the main system that everything was done.

But this was a lie. The spooler still had to spool the data to the printer, byte by byte, but telling that lie meant the user could get on with something else. If that something else was also a print job, the spooler had to manage a list of pending outputs – and so the print queue was born.

If everything worked, great. The lie became good. But there was one small problem – printers do not work. They jam, they run out of paper, ink, toner, and patience with humans. Their interfaces garble. They choke on unexpected items in documents.

The print queue knows nothing of this. It just keeps growing, until someone notices that their document has not been printed. Normally, this means they try printing it again.

When service is restored, chaos makes its happy entrance as duplicate jobs are churned out. And this is manageable on a single user system: you learn to cancel stuff and add printer queue management to your skill set. On a networked printer – oh boy.

This is so bad because of dishonesty. The spooler has lied that things are good, and has no way to tell whichever application, or user, when things break. Things pile up until some user fixes things, which brings in more horror. Giving everyone access to a shared print queue, which is rather the point, is a security nightmare. This was much more so in the time of fax, many a corporation's medium of choice to swap contracts and financial statements. Fax servers always had the most fascinating of queues.

Is it all just history now? No. What was going on then was a foreshadowing of IoT and edge. Bambu has managed to recreate the sins of the 1980s printer queue at scale, across the globe, and with far more catastrophic consequences.

A document printer can print a tray full of different output before a human shows up, and it's OK. But a 3D printer that tries to print a new job before the old one has been cleared off the plate? It is going to, at best, produce a mess, and at worst break itself.

Under no circumstances does it make sense to send out jobs without a human at the far end confirming that it's safe to proceed. That's just the headline no-no in a list of problems that Bambu has discovered as a result of the incident, and it has done a good job of addressing them, pushing updates to their own server logic, printer firmware, and operating procedures.

What's striking is how many of the fixes were either technically possible but not implemented, or implemented and disabled by default. The most telling fix is that the company will enhance LAN-only mode, where printers use local data, so that it will work if the cloud services are down. People had already asked for this – and why wouldn't they – but it took an embarrassing failure to make it happen. 

• Intel seems to think Wi-Fi 7 is too cool for old-school Windows 10
• Miscreants exploit five Microsoft bugs as Windows giant addresses 130 flaws
• We need to talk about criminal adversaries who want you to eat undercooked onion rings
• Rigorous dev courageously lied about exec's NSFW printouts – and survived long enough to quit with dignity

This is the Achilles' heel of IoT and the edge model. You can design things to be secure, safe, with sensible failure modes and local failover – but you don't have to. You can make a viable product, and one that costs less to develop and test, if you just don't bother.

Users have no way of telling. Nobody's testing this stuff for robustness, nobody's publishing their infrastructure, control logic, data flows, and edge/central system architectures.

We could demand these things: mandated standard documentation is a known and powerful regulatory tool. Or we could buy cheap and shiny products and hope for the best.

Wait for the really bad stuff

Regulation only happens after something goes badly wrong, and a few messed-up 3D prints and broken printers is nowhere near wrong enough.

Yet if you look at 3D printers not as sophisticated, precise robots, but as machines that have to control a mass of motors, heaters, and complex materials, the picture changes. They have incredibly powerful control code to translate model data to final output.

How destructive could this be to the printers and their surroundings under malicious attack? How robustly do the devices protect themselves? Who's auditing this? While this may not be the case for Bambu Labs, in many vendors' situations, nobody knows and nobody cares.

And in many cases, including Bambu's, all this is on the cloud, mediated through the hostile environment of the public internet, because of a business model that wants to dissuade users from disconnecting. This is despite the fact that for most users it's natural to want local control of a local model, and a local printer makes far more sense.

The IoT and edge proponents talk of production automation, consumer service delivery, revolutions in transport and city infrastructures. It's all very exciting, but if we as users and developers don't demand responsibility and honesty in design, regulation by disaster will surely follow. And if Bambu is anything to go by, we'll just have to join the queue. ®