LLMs remain a divisive topic in these times. Perhaps we all know someone who’s become over-infatuated with their new robotic friend, or who believes it has made them a genius. [Emily M. Bender] and [Nanna Inie] have written about how people anthropomorphise the LLMs they interact with, and suggested some language tips to avoid that. It’s a couple of months old, but we think Hackaday readers will find it interesting.
Their analysis is interesting, because it looks at the way people talk about LLMs and highlights the unconscious anthropomorphism. The LLM is a piece of software not a person, so why does it “recognise” when it does “speech recognition”, for example. They suggest “automatic transcription” instead. Even “hallucination” implies cognisance that evidently isn’t there. They admit that their suggestion of “undesirable output” isn’t entirely appropriate. They’re on safer ground with “input” and “output” instead of “prompt” and “response”.
Whatever your views on them, it’s evident that LLM usage will be a feature of the world for the forseeable future. The language surrounding them is however capable of evolving, and maybe some of the suggestions here are worth taking note of.
Grappling with our new electronic overlords? Have a look at our AI for Skeptics series.
CVSS rankings are determined by the severity of a flaw, the ease of exploiting the bug, if authentication is required for exploitation, if the vulnerability exposes confidential data, and other criteria. A CVSS of 10 is as bad as it gets, and having three of them at once is certainly attention-getting. Of the three vulnerabilities fixed, one allowed unauthenticated modification of data in the hosted instance, a second allowed arbitrary code execution via the GraphQL interface, and the third allowed arbitrary SQL commands that could modify the database.
ServiceNow claims Adobe, Lenovo, Fedex, and Fujitsu among their high-profile customers. With luck, the vulnerabilities were patched before significant public exploitation could happen.
Router Malware
Previously in 2026 the US Government warned against embedded malware found in consumer routers, which may be linked to the FCC enacting bans against certification and import of foreign-made consumer devices. This week, the NVD (National Vulnerability Database) reported specific embedded malware in the Zbtlink and MoreQuick brands of devices.
Multiple versions of the firmware, for multiple lines of products, contain a backdoor service that uses unencrypted UDP to connect to a command and control (C2) service. The service, or anyone able to intercept the network traffic, since it’s unencrypted, can execute commands as root, allowing them to change configurations, open tunnels, or steal ISP credentials.
The malware is baked into the firmware, so removing it is impossible for most users: a factory reset wouldn’t do. In theory if third-party firmware like OpenWRT supports these devices, the hardware could be made safer with a custom install.
Given how commonly the same device is marketed under dozens of names, likely the same devices and firmware have yet to be identified under other brands.
Qubes is built on top of the Xen virtualization system, where each application can be given a dedicated container. The utility to copy files from the primary container into an application container, qvm-copy-to-vm, displays a message if there is an error copying the file. To show the message, the utility launches kdialog with the error as arguments, but fails to ensure that the error doesn’t include shell commands.
The system call used to show the alerts has the dangerous side effect of calling the command as if it was a normal shell. This is extremely powerful, but equally risky: a shell typically allows multiple commands per lines, require quoted strings to protect arguments with spaces or complex text, and can expand variables. Generating an error that escapes out of the message and runs arbitrary commands was all it took.
Qubes already has a fix ready and everyone getting standard updates should have it waiting.
Independent researchers noticed growing reports in Reddit threads that freezer units were out of service, with other service members and families reporting the same. At least fourteen bases throughout the United States appear impacted, and the story has been picked up by the official military newspaper “Stars and Stripes” as well as by mainstream media outlets.
Posts by staff at the bases clarify that it was not a power loss or cooling loss, the fridges and freezers were placed in defrost mode where they self-heated. The commissaries are operated by the Defense Commissary Agency, with central monitoring and control of facilities. Central monitoring makes complete sense when you need to ensure devices are keeping food at a safe temperature, but something definitely seems to have gone wrong.
Diving into it further, M. Elizabeth finds a post from August 9, 2026 describing vulnerabilities in the Danfoss controllers that allow unauthorized access to the refrigeration controller, and a second paper by the same team exposing over 20 vulnerabilities in Copeland refrigeration controllers that included full control of the unit settings. M. Elizabeth is careful to point out that without confirmation from the commissary agency, it’s impossible to know for sure that this was a hack of the control system, but the evidence is mounting.
Border Gateway Protocol (BGP) is a core routing system underlying the Internet at large. Service providers use BGP to announce the ranges of IP addresses they handle and how to reach them. BGP is operated as basically a global gentleman’s agreement: the protocol itself lacks any authentication or encryption. If you think this sounds vulnerable to disruption, you’d be completely right.
Global disruptions have happened accidentally, like when an ISP in Pakistan took down YouTube, deliberately, such as when thieves hijacked the routes to cryptocurrency exchanges, and mysteriously, like when China hijacked parts of the Internet repeatedly with no explanation.
This time, the BGP attack targeted the IP range used by Virtualizor, and was combined with spoofed SSL certificates for the Virtualizor servers to push spoofed updates. The BGP announcement was targeted to a specific class C: a relatively small allocation of 253 addresses, similar to what a home network would use. BGP gives precedence to the smallest announcement for an IP range, so all systems that received the spoofed announcement routed those addresses accordingly. The network advertising the false route was based in Romania, though of course they could also be a victim.
With control over the IP range, the attackers were able to generate a certificate via Lets Encrypt, which was sufficient for browsers and the updater to accept the rerouted addresses. The attackers then published a malicious package that appears to install additional services. The company has not provided details about the trojaned update, so it’s not clear what other risks it poses.
Virtualizor does not have a public list of customers, but one has to assume it includes high-profile companies to make such an attack viable. Hijacking BGP is extremely obvious, and isn’t frequently used for such obvious spoofing attacks.
Relatively recently, some operating systems have added the ability to alert the user when an application access the clipboard. Unfortunately, Linux is not yet one of them, but thanks to other clipboard management tools, Simon noticed that the recent update to Zoom 7.1.5 copies the contents of the clipboard as soon as they change. What happens to the clipboard contents once copied is currently a mystery.
Considering that the clipboard can often contain passwords, authentication tokens, or simply data you might not want to share with Zoom, automatically scraping the contents isn’t what you’d hope for.
Plex Vulnerabilities
The Plex media streaming software sent out an advisory this week warning about security updates for the server and desktop application.
Details are currently thin, with the promise of future details once CVEs have been assigned. For now, make sure you’re on version 1.43.4 or newer. The Plex post has additional directions for updating on platforms that may not have pushed new packages yet.
CrowdStrike observed that 88% of exploits happened with 48 hours of the proof of concept code being released, crediting AI tools for shortening the adaptation. Typically proof of concept code is designed to demonstrate the vulnerability without providing an immediate mechanism for malicious use, and the window from exploit announcement to wide-spread risk was on the order of weeks. The report notes some vulnerabilities being widely exploited in 20 hours after public disclosure.
The tightening window makes patching even more important, but rapid patching caries the risk of instability when the patches themselves haven’t had extensive testing. Unfortunately there’s no simple solution; faster exploitation via AI tools drives faster patching, often also with AI tools that can introduce more bugs as well.
With artificial intelligence being the bête noir of the moment, there are some projects using it which maybe don’t bring much to the table. So it’s nice to see one that uses it in a creative way, and delivers something new. [arnegiacomo]’s e-paper screen is a great example, as it draws a picture in real time of whatever birds are outside.
Behind the quite large screen sits a Raspberry Pi 5, and on that is BirdNet-Go, an AI-powered birdsong classifier. A USB microphone catches the birdsong, and Birdnet comes up with the species. The birds on the display are then those species as pictures from 19th century bird spotters guides, assembled into a collage. You can even see what the current set of birds it hears are, live, and they are a representative cross section of the European birds you’d find in Norway where it’s located.
I’m an experienced programmer, and I’ve worked in many different languages. Sometimes being a programmer is a two-edged sword. You want to accomplish something, and you can do it easily — but it can be a lot of work to do it right. Maybe more work than you want to do.
Normally, I’ll kick out a few lines of script for something I want and be done, accepting that it isn’t production-hardened. This time, however, I decided to try an AI tool to see whether they could do the work I was too lazy to do myself. While I’ve played with chatbots, I wanted to try one of the dedicated coding agents, in this case, Codex. Outside of asking ChatGPT to write a simple function or find the cause of an error message, I haven’t done much coding with AI assistance, so I was interested to see what these agents brought to the table.
A Radio Problem
The problem was simple: I wanted an easy way to put buttons on my Linux desktop that launched Internet radio stations. Sure, I could open a player and paste in a long URL, but I’m far too lazy to remember all those URLs.
I searched for a way to make Shortwave — an Internet radio player — open a URL from the command line. Apparently, you can’t. Google Gemini suggested writing a script that launches cvlc, the command-line VLC player, with the URL as an argument.
That’s easy, so I did it. Of course, then I had to find the stream URLs for all my favorite stations. It turns out that Radio Browser maintains an extensive database of stations. I considered scraping the site or using its API, but honestly, the little script was becoming too much of a project.
Besides, I was already struggling to manage the media player’s lifetime. I didn’t want a new station playing on top of one that was already running, and I wanted a command to stop playback, so the script had already grown larger than I first imagined.
My first version used a temporary file containing the player’s process ID so a future script execution could kill the old player. That usually works, but it isn’t very robust, and I knew it. But how much work did I really want to do here? I decided I had done enough and turned the rest over to Codex, OpenAI’s coding assistant.
What Can Codex Do?
Codex is more than a chatbot that produces code snippets. With access to a project, and limited access to your machine, it can inspect existing files, edit them, run commands and tests, examine Git history, and manage commits and remotes. OpenAI describes Codex workflows as including coding, testing, analysis, code review, and repository automation.
The important distinction is that Codex works on the actual project. Instead of copying code out of a chat window, I could say, “Have a look at this shell script,” and it examined the script in place. It also noticed that I already had an uncommitted modification and avoided overwriting it. It also understands version control, and that turns out to be one of its really nice features.
Fixing Problems
My first request was:
Have a look at this shell script. I know it needs a trap. Is there a better way to keep it from accidentally killing something with a stale playradio.tmp?
Codex pointed out that a trap was not the only solution. The launcher exits immediately after starting VLC, so it is not around later to receive SIGCLD or clean up after the player. Sure, it could run something to wait around, but there was a cleaner way to get the job done.
It initially suggested verifying that the saved PID still belonged to cvlc. Then it caught a subtler problem in its own proposal: if Linux reused the PID for a different cvlc process, the name check could still kill the wrong player. This is probably very rare, but when it does happen, it will be a mysterious, hard-to-reproduce bug.
The final solution records both the PID and Linux’s process start-time token:
Part of a Codex session. Entire transcripts are on GitHub.
Before sending a signal, the script confirms that both still match. It also uses a private per-user runtime directory, serializes concurrent start and stop operations with flock, sends SIGTERM first, waits for a graceful shutdown, and rechecks the process identity before falling back to SIGKILL. That is considerably more thought than I wanted to put into a desktop radio button. Overkill? Maybe, but it is robust.
Another pleasant surprise was that Codex built a suite of tests to ensure that everything worked as it should. It runs these tests when it makes changes. So it doesn’t just create code. It creates code, executes it with test cases, and fixes any issues it discovers.
Searching the Database — and More
Once the process handling was safe, I asked:
Radio Browser allows you to search via API for radio stations. How hard would it be to make $1 a search string and take the best match, while allowing -u for a URL instead?
Codex checked the current API documentation, found that curl and jq were already installed, and implemented the search. It hides broken stations, orders matches by votes, selects the top result, and reports the selection back to Radio Browser’s click counter. I told it I wanted specific command-line options over several iterations. The program can play a URL, search the database for a station, or even just query the database. It can also give you a list and let you pick. (See the README.md for the entire interface.)
RadioBrowser is human-readable, but also provides the same data via API.
I did make a few requests. For example, if you pass a URI, the program should figure it out and skip the database search. I also wanted the player to be configurable through a PLAYRADIO_PLAYER environment variable. I asked it to fall back on wget if curl wasn’t installed. Missing dependencies should produce useful installation advice rather than mysterious failures. I also asked it to produce a GitHub-style README and a traditional Unix man page.
Human Guidance Still Matters
There were a few places where human intervention improved the result. For example, the PLAYRADIO_PLAYER configuration and its explanatory comment originally appeared near the bottom of the script. That works, but it is inconvenient for someone who wanted to edit the file. I asked Codex to move it near the top.
Another example was the first version of --pick. I had specifically suggested Bash’s select command, so Codex printed the formatted list and then let select print a second numbered list. It worked, but the duplication was distracting and, as far as Codex was concerned, it was what I asked for.
I pointed the duplication out. Codex replaced select with a simple numeric read, keeping the detailed table and adding only one extra row:
1 Jazz One
2 Jazz Two
3 Cancel
Station number:
This is a good example of how I think these tools work best. The AI handles the implementation, edge cases, tests, and documentation, while the human provides design input and flags anything awkward or that doesn’t fit the intended experience.
Does It Scale?
I’m not an expert at using these kinds of tools, but I think this worked very well. I generally asked for what I wanted and then made technical observations about the results.
I also tried this with a script, originally from [Petar Marinov], that I’ve used and modified for years to replace the cd command (see GitHub). I didn’t tell it what to do. I just let it look at the code. It correctly determined what it was supposed to do and made solid suggestions for making it more robust. It suggested features and even a major improvement to make it work not just with cd but with anything that changes pwd, like pushd. Of course, I couldn’t resist getting a man page and a README for free.
One feature I asked the tool to create was a simple bookmark system. It proposed and created a way to create and maintain a bash associative array that it persisted in a configuration file. That worked, but I knew it would be better, on many levels, to keep the bookmarks as proper symlinks. When I pointed this out, the AI did get it, saying:
That has several nice consequences:
changes from cdmark are instantly visible in every shell; no reload or synchronization issue
ls -l ~/.config/cdfunc/bookmarks is already a crude cdmark list
bookmarks can be created or removed manually with ordinary Unix tools
Syncthing/git/backup tools handle them naturally
no parsing, quoting, escaping, or rewriting a bookmarks file
no associative-array initialization at shell startup
broken bookmarks are naturally represented as broken symlinks
I think that’s substantially cleaner.
It also noted that this makes shell completion very simple, which I had not thought about. However, its implementation broke normal shell completion for the commands. It fixed that after I pointed it out. Well, actually, it took two tries to work out all the bugs. This is another case where human guidance is critical.
For a more advanced project, I forked a simple editor, kilo, and added a few Emacs commands. I asked Codex to review it. It found a number of bad edge cases, some in the original code, and fixed them. I then asked it to suggest Emacs-like features it could easily do. We added a ton! (see GitHub). It was impressive how well it analyzed and understood the code. I had done similar modifications to the code a few weeks earlier and, I have to admit, Codex understood the original code base much faster than I had.
Again, though, human guidance is necessary. Emacs uses an Esc prefix for some commands. You can also hold down the Alt key to get the same result. So pressing Alt+W in a terminal sends an Esc character and a W.
Initially, Codex wrote code to detect an Esc, wait a short time for a command, and then, if nothing came, treat it as a bare escape. It even understood that this would be a problem and mentioned it. Alt+W would work, but there was no way for a human to press Esc and then W in the time allotted. I prompted:
Yes I see that in the program. Would it be possible to have it wait indefinitely for ESC UNLESS a caller set some flag. So when other parts of the editor (search/save/etc.) are prompting for input they would set that flag (or call a separate entry point) and, at that point, ESC=>ESC. Any other time ESC is treated as a prefix (and perhaps ESC ESC gets sent as an escape just as a — ahem — escape hatch.
That fixed the problem. It is hard to remember that while Codex seems smart, it doesn’t have human judgment or human-level problem-solving skills. You have to supply that. Sure, it found problems in its own code. It found problems in my code. It devised solutions. But you still have to make sure those solutions make sense and sometimes nudge it — at least — in the right direction.
If you are interested, each of the GitHub repos (playradio, cdfunc, and kilo) has a session directory that contains transcripts of the AI chats that produced the final versions of the code. Admittedly, none of these started from a totally blank slate, but working on an existing code base is certainly a realistic test.
The Git Assistant
One feature I particularly liked was Codex’s ability to manage Git. I didn’t even try the GitHub plugin for Codex, which would probably be even better. I asked it to commit the current version before starting a new feature, which gave me a clean checkpoint. Later I said:
Commit please. I’m going to add a remote GitHub repo. Can you set this as origin and push it after the commit?
Codex committed the changes, added the remote, pushed the branch, configured upstream tracking, and verified that the working tree was clean. The entire evolution is visible in the repository’s history — from process-safety changes, to Radio Browser search, to configuration and documentation, to the interactive station picker.
You can see the final project and follow each commit in the repositories along with transcripts of the AI sessions. Having things in version control is especially useful with a tool like Codex. You can easily see what has changed and roll back if you like.
Wrap Up
The original script solved my immediate problem in a handful of lines. The finished utility solves the same problem safely, handles failures, searches a public database, supports different players, has good documentation, and leaves a traceable Git history. One important note. Codex and other agents have a limited context window, so you won’t get the same results trying to work with extremely large code bases unless you pay for a larger model. But for these tasks, normal consumer Codex worked well.
Could I have written all of that myself? Certainly. Would I have bothered to go this far? Probably not for what is basically a one-off desktop hack.
That may be the most useful role for a coding agent: They don’t always enable you to do something you couldn’t otherwise do. But they make it cheap enough in time and attention span to do all the boring and defensive coding and testing that you know you should do, but so often don’t. Codex didn’t replace me. It just augmented my patience.
This week Jonathan chats with Benjamin Samuels of Trail of Bits! The conversation focuses on Patch the Planet, a new initiative to help Open Source projects deal with the fallout from AI coding and vulnerability research. What’s the unexpected dichotomy driving the polarized response to LLMs? And what does the future look like for Open Source in the age of AI? Watch to find out!
Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.
In the business world, a moat is a quality of a business that makes it difficult for competitors to take that company’s profits. With how hard it is to train models for large language models (LLMs) and generative AI, it might seem like Anthropic, Open AI, and other LLM companies would have huge moats given the amount of compute it takes to build models. But open source models are quickly draining that moat, and now the only thing standing in the way of a customer using one of these models on their own hardware instead one from the larger companies is physical computing resources. [TerminalBytes] demonstrates a few of these models on personally owned computers to show the current state of the art.
[TerminalBytes] started off running the 27B version of the Qwen3.8 on a Mac Studio with 256 GB of unified RAM, which is plenty for this task. But it’s also enough to benchmark a few different models. Qwen3.6 is compared to 3.8, and then the different quants of each model are also compared. Quants are compressed versions of models that need fewer bits to store weights, meaning that the same models can run in less memory with smaller losses in fidelity. Many of these quants run on machines with 32 GB of RAM or less, encompassing many average gaming PCs. There’s even a 1-bit quant that [TerminalBytes] tested which can easily run on a machine with 16 GB, although with mixed results.
Keep in mind that this is just the current state of affairs with open LLMs. Future versions of these models are likely to optimize the number of tokens produced per unit time, or otherwise increase quality of responses while requiring less computer resources. We don’t really think that the ease of running local models will be the sole reason that the AI bubble pops, though. The fact that not every computer user is running Linux is proof enough of that.
Whether you like it or not, the use of LLMs to write code is kind of a big deal at the moment. We’ve been asking ourselves what, if anything, this means for us here at Hackaday. Should we try to figure out what percentage of a project was done by an actual human and how much was done by a machine? Does it really matter? What is our AI policy anyway?
Clearly, Hackaday is pro-human. We’re in it for the hackers as much as for the hacks. Our community is, like Soylent Green, made of people. It’s your inspirations and innovations that keep us reading and writing every day. And we produce 100% of our content the old-fashioned way, with projects selected through the taste and judgement of our writers, and their own words telling the story.
What about the hacks? We’ve seen a lot of projects recently that were coded with the help of an LLM. Does that diminish the work? In the end, what rings truest to us is what has always been Hackaday’s editorial guiding star: Is there something special in the hack that makes it worth talking about? Then we write about it. Was it written using vim or emacs? Did the author consult friends or a chatbot while working on the project? That’s not really relevant.
But in the past few years, the BS-generation machines have found our hobby, and we’re finding a lot more projects that don’t have any spark to them. We’re seeing circuits that make no sense, and claims that defy physics. Of course, we always have. The LLM-nonsense project is today’s version of the perpetual motion machines of old. Just like we never trust a hardware project that is all renders, seeing only AI-generated images is a huge red flag. It’s our job to separate out the wheat from the chaff for you all, but it’s something that you must be doing everyday as well.
We’ve seen amazing hacks over Hackaday’s 22-year history. Hackaday is older than YouTube and older than Stack Overflow. We’ve seen technology come and go. We’ve seen C-beams glitter in the dark near the Tannhäuser gate. (OK, maybe not.) And in the end, our AI policy is our same-old policy: we write up hacks that inspire us in the hope that they inspire you.
So if you’re using Claude to help you with the UI bits, or if you’re hand-writing it all in assembly, or wiring up the logic in diodes, we just want to see your cool hacks. And we hope that our collective signal will be so loud that we drown out the noise, at least in our own little corner of the hacker universe.
This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter.
Want this type of article to hit your inbox every Friday morning? You should sign up!
For decades now many of us have lived in surveillance societies where it’s difficult not to be within the view of a camera. When being noticed depended on the attention span of a minimum wage security guard perhaps this mattered less, but in an age of AI, the vigilance has become always-on. To address this problem the German designer [Simon Weckert] has created a fabric designed to confuse an AI scanning an image, and cause it to not recognize the wearer as a person.
The result is perhaps best described as “loud”, a pattern of saturated colors that targets the algorithms used in recognition. The tests he shows appear to work, but perhaps the most obvious thing from them is that he sticks out like the proverbial sore thumb to the eye wearing such a… vibrant garment. Also we wonder for how long it will remain effective, as algorithmic improvements seek to mitigate its attack.
[Matt Lenhard] has an interesting writeup explaining exactly how fraudsters offer access to cutting-edge AI models at a tenth of the price. Perhaps unsurprisingly, the secret is to get tokens for free from anywhere they can and by any means necessary. Then wrap them in a pretty relay API, and sell access to it.
Relaying tokens is not by itself a shady practice. That distinction belongs to services that obtain tokens fraudulently, opening the door to selling them at rates far below market value. This practice is widespread and profitable, in part because the abuse is so hard to pin down and stop.
One source of tokens is free credits on new accounts. New accounts are spooled up as fast as possible, hammered until they’re empty, then it’s done all over again. Another method is to sign up as pay-after, possibly with a stolen card, and simply ensure the account has no valid payment method once the bill comes due. Or set up a temporary card, pay some minimum up front and consume as much as possible, then initiate a chargeback. It doesn’t matter if individually each of these doesn’t amount to much before they get flagged, because it’s being leveraged relentlessly on a massive scale by automated systems.
There are the shadier methods, too. Fraudsters don’t just target providers directly. Consumer software products with AI features get reverse-engineered, then the back ends hammered for all they are worth. Poorly-coded support chatbots can be highjacked into serving fraudsters’ traffic instead of just their own. It doesn’t actually matter where the tokens come from, after all. As long as the fraudsters are obtaining them for free (or at least below their costs) then it’s profit.
That last point is one [Matt] zeroes in on with advice on how to mitigate this abuse. He goes into detail in his writeup but what it comes down to is recognizing that it’s a numbers game. Fraudsters depend entirely on obtaining tokens for free, or nearly free. So just like using an AI to keep phone scammers tied up, anything that raises friction increases the fraudster’s costs, in turn encouraging them to find an easier target.
One of the stories of the last few weeks has been that AI companies have been scanning books in very large numbers in order to train their models with content guaranteed to have been written before 2002, and thus AI free. It’s caused some outrage, because of the size of the operation, and because the scanning process is destructive. In particular the phrase being bandied around is that these are rare books, and it’s this phraseology I find problematic. I think it’s time to unpack why that is the case.
It’s Not Book Burning, Folks
Before I worked for Hackaday I had a long career in and around the publishing industry, mostly on the electronic side, but from time to time crossing paths with my colleagues in the world of paper-based publishing. I understand the appeal of a good book, I’ve spend a lot of my life among bibliophiles, and let’s just say I own a few books myself. In particular I understand the symbolism of destroying books, bringing to mind as it does the actions of repressive regimes. I have stood in Bebelplatz in Berlin where the photo of Nazi student organisation members burning the library of Magnus Hirschfeld’s institute was taken in 1933, and if you know me, you’ll have an idea why that’s close to home. But for all that, what the AI companies are doing is not the same thing.
In this case they’re destroying the books for two reasons. Firstly, as I remember from a previous employer in the publishing world, it’s much easier to digitise a stack of papers than it is a bound book. Thus I’m pretty sure that’s one reason they remove the binding before digitising the pages. Then secondly, as I understand it it’s a copyright issue. If they buy a book, digitise it, and destroy the physical copy, they can legitimately claim that only one copy of it exists, and they hope, sidestep copyright claims from publishers.
When Rare Maybe Isn’t Really Rare At All
You’ll only see one of these numbers on a book published since 1970.
Perhaps the most pertinent question then is just what are the books being scanned and destroyed? They’re almost universally described as “rare”, but is that accurate or sensationalist? It brings to mind a dusty library filled with priceless tomes hand-transcribed by monks which it would be a crime to destroy, but there’s something that explodes that vision in an instant.
If you read the reports of what’s happening, they are ordering books by ISBN number. That’s an international system for identifying books, which was only introduced in 1970. If they’re ordering a book by its ISBN, it’s no medieval illuminated manuscript.
So the books being scanned and destroyed are relatively new, but can they still be described as rare? In that case just like anything else mass-produced since 1970, how many survive depends on the size of the original print run and how valued they have been since. So a few of these books can be physically rare in the sense of being uncommon, but if they are next-to-valueless, it’s fairly obvious nobody has particularly cared about their survival up to now. It’s likely that any books printed since 1970 which are both rare and of value will have their future assured, so the AI industry is not committing the wanton destruction of culture the reports would like to suggest.
You Need To Know Just How Many Books Get Pulped Every Year
People are often shocked when they find a dumpster full of books for recycling. Ricky Shore, CC BY-NC-ND 2.0.
I’m left feeling that a combination of the symbolism of destroying books along with a distaste for AI companies has inflated the status of these books well beyond their worth. If people truly had a care for old books they would be shocked to know how many are pulped each year by the paper recycling industry.
The publishing industry has been churning out mass-produced books for centuries now, so the world is awash with old books. Where do these newly-minted bibliophiles imagine they all go, to the Great Library In The Sky? I haven’t even touched yet upon the publishing industry, which pulps vast quantities of brand new unsold books every year. Where is the outrage, I ask?
We all love to dunk on AI companies, and Heaven knows, there are plenty of reasons to do so. Among all those reasons, sadly destructively digitising books is pretty low on the list. Please, ask the other questions, the ones they really don’t want to answer!
One day, people will look back at what we call Artificial Intelligence and laugh. We do the same thing today, as chat bots totally outstrip what the computer industry called AI up until pretty recently. This didn’t escape curators at the Internet Archive, apparently, and [Jason Scott] tells us about a recent collection, “Vintage Artificial Intelligence.”
These are old software titles that will run for you in emulated machines right in your browser, ranging from somewhere in the 1970s to the 1990s. There’s Eliza, of course. Actually, there are several copies of Eliza. Given how simple it was to write Eliza, it did a pretty good job. Then there are adventure games that are pretty conversational, Lisp, Prolog, which was going to spawn expert systems to replace us all, and Racter, which tried to write fiction.
There was even Alter Ego that was supposed to help you explore life decisions, maybe? There are a couple different versions of even a few versions of Conway’s Game of Life. We aren’t sure that’s ever really been AI, but perhaps it depends on your definition. We’re happy to see Sargon, the chess program, represented.
We didn’t see Hexapawn, which is a shame. We also didn’t see Parry (the paranoid counterpart to Eliza) or that elusive software we remember but can never find that built word chains from text called George.
Login
