llm

I’ve been doing a lot of thinking about my choices of software of late in the face of “the sloppening”. LLMs have infiltrated many open-source projects, some of these being ones I’ve used for decades.

This has put me between a rock and a hard place. On the one hand, I wish to support ethical choices in technology. LLMs are not ethical. On the other, security vulnerabilities will drag me down the road of LLM use whether I want it or not: we can’t simply ask attackers “please don’t use LLMs” — if that worked then our prison systems should be empty.

My objections to LLM use

I covered this in detail in my last post, but it boils down to this:

1. LLM output, whilst itself not directly applicable to copyright (as it is not the work of a human), can sometimes contain the copyrighted work of other humans (e.g. like this) in violation of the license agreements that those copyrighted works are distributed. There exists a legal risk that users of “derivative works” of copyrighted material may be found liable for unauthorised use of this copyrighted material. — I don’t want that risk!
2. Current generation LLMs are trained on material that is merely scraped off the Internet using poorly coded and highly inefficient scraper bots, then labelled with the aide of humans — often slave labour in developing countries. — I do not wish to support the slave trade!
3. Whilst the effort right now with LLMs is to achieve “human-level” intelligence, the ability of current technology to effectively simulate a neural network with the complexity and density of a human brain is severely lacking, requiring vast data centres that consume exorbitant amounts of electrical energy and producing vast amounts of thermal energy that must then be radiated away, represents a threat to our climate ecosystem that cannot be justified at any cost. — I value the natural environment that our society exists in!
4. Development of these tools is progressing at such a rapid pace, that current generation equipment depreciates at a rapid rate, requiring frequent replacement. Semiconductor production is necessarily a resource intensive industry and the frequent manufacture–commissioning–decommissioning cycle is producing massive amounts of e-waste whilst putting heavy demand on these facilities, further compounding the already poor environmental footprint.
5. The output of these tools is often wrong, requiring the user to send the work back to be re-worked. Wasted time and effort. Computers in the 1950s might’ve been wrong occasionally, but it was generally traced down to failure of hardware components, the mathematical concepts underpinning this were sound, better manufacturing and components fixed this. “Hallucination” (really confabulation) is presently believed to be unfixable.
6. It is said that relying on these tools has been shown to reduce one’s cognitive abilities, increasing dependence on these tools for functional work.
7. Financially, the companies running these systems are a house of cards on the verge of collapse. No LLM vendor right now is making a profit. When the real bills finally arrive, will you be able to afford them? If they go bust, can your work continue without?

My legal objection to LLM use

The first of these is a legal argument, and really it’s going to take time, but eventually there will be a test case that will confirm whether my suspicions are founded. I am not a lawyer, so take what you see there with a grain of salt, but to be a successful software developer, one must have at least some basic understanding of the legal principles at play here, otherwise you find yourself in court (or in gaol) instead of in front of the computer.

I don’t have the money to fend off a potential case of copyright infringement, nor do I want to spend time having to mop up after someone is found guilty of such infringement. Code from a LLM, even if it looks novel and new to us because we’ve never seen it before, existed somewhere, and few have the resources to properly conduct a check to see where it came from.

Ethical objections

Points 2-4 point out the ethical issues, notably sourcing of training material, slavery and environmental concerns.

I fully expect that as technology gets better, we may see hardware that is better able to simulate the biological systems these tools try to emulate. Greater density, lower power consumption, less thermal waste output. The Manchester Baby was an early implementation of the Von-Neumann computer architecture that underpins the basic principles of every personal computer today… it needed 3.5kW to run this early 32-bit computer which had a mere 128 bytes (in today’s measurement; 1024 bits) of memory and ran at around 1100 instructions per second. There are ARM Cortex M0+ cores today (also 32-bits) with thousands of times more memory, clock speeds in the hundreds of megahertz and run full speed with less than 1W of power.

That part will get better. Even if they do fix that problem though, they still likely will be enslaving people to do the labelling skulduggery and using pirated material to boot. They need to solve this problem too, but so far, their efforts have been on trying to be made exempt from those rules.

Practical concerns

The financial situation suggests prices will skyrocket once funding dries up, and when that happens, people using these tools will face a choice: hike their fees to cover the increased costs, or abandon the tools en masse and return to the “old way” of doing things.

I also question the logic of feeding tokens into a machine and pushing a button, hoping that this time, we’ll hit the jackpot and get useful output. If I wanted to earn an income that way, I’d visit the local poker machine.

My actions going forward

There are two classes of software I need to consider, the software packages I simply use, and those which I actually contribute to. In both cases, some have viable replacements that I can switch to, some may have viable replacements in the future, some I still need to keep using, some I can abandon.

Linux kernel

Dealing with this is a tough nut. The core kernel project is now using LLMs as part of their core workflow. Linus Torvalds basically told us to fork it or leave if we don’t like it. I considered both:

“Fork off”, use something else

This isn’t a full list, but I looked at several options:

• NetBSD looks like a good option for a lot of my servers. It is open-source, POSIX-compatible and does many of the things I need of a server. At the moment this blog runs on AlpineLinux, but moving it over to NetBSD is very doable.
  
  As a desktop I gave it a try, hardware support being its big Achilles heel — it can’t tap into the hardware support Linux has without tainting the kernel with GPLv2-licensed code, so drivers must be written from first principles. Support for interfaces like Bluetooth are really lacking (mind you, it at least supports it unlike OpenBSD). It feels a lot like Linux circa early 2000s. It’s a good base we could build from, but lots of work is needed.
  
  For non-x86 platforms, the situation is quite spotty. My TS-7670s basically would require me to dig through the Freescale i.MX28 user manual and port the kernel to this new (to NetBSD) SoC, before then porting the TS-7670 rev D board. My Raspberry Pis are harder still, because much of the documentation for these is under a NDA from Broadcom. A Linux fork is really my best option for these.
  
  While the kernel is free of slop, there are some packages shipped in the base OS that have some slop in them (e.g. Postfix). Not a lot we can do there.
• OpenBSD is also an option on the servers, and I already do run some with OpenBSD. tmux is vibe-coded now, but that’s not a core component of the OS (despite being shipped in base) and can be safely ignored — I use GNU screen anyway.
• I can rule out FreeBSD as they now embrace the slop. Might as well stay with Linux in that case.
• Similarly, I can strike out 4.4BSD fork DragonFlyBSD as they embrace slop too.
• RedoxOS has a no-AI policy, but is a long way from being usable as a desktop as it lacks support for common hardware such as WiFi and is still in an early development phase. Worth looking at later, but not viable yet.
• HaikuOS has come a long way. It’s a re-implementation of BeOS, and like RedoxOS, has a no-AI policy. Many common software packages run on it. I played with it in a VM and it actually did feel like a nice desktop OS. There is an ARM64 port of it, but when I tried that on my Raspberry Pi 400, it refused to boot. So not ready to displace Linux yet, but looking good.
• Illumos is a fork of OpenSolaris, so basically a genetic Unix rooted in BSD and Sun ancestry. Has an anti-AI policy, supports a lot of software, but hardware support is lacking.
• 9Front looks interesting, but very esoteric. It is a continuation of Bell Labs Plan9. It too has a no-AI policy, but hardware and software support is probably not going to make it a practical choice for me.
• GNU Hurd doesn’t seem to have moved far from where it was in the 90s when Linux first started and displaced it as “the” GNU kernel. It is clean of slop as far as I can tell, and it is even supported by Debian and Gentoo, Hardware support is lacking, but being a GPLv2 kernel, we could possibly port Linux drivers and features over to it — this would be a big job though.

I might’ve missed something, but that looks like a pretty extensive list. Of that list, NetBSD seems to be the best approach, failing that maybe getting behind HaikuOS (for a desktop) or filling the gaps in Hurd (if we want to re-purpose GPLv2 code).

“Fork it” approach

Under the terms of the GPLv2, we’re allowed to do this. The “Linux™” name is trademarked, and while it’s tempting to mention an alternate name just now, I know the moment such a name is mentioned, it’ll be off to the races to the nearest domain registrar to snag the .org domain for it ahead of the squatters. Linus himself already knows about people squatting names and profiting from it, which is why he now holds the trademark in the first place.

This is not something I can do alone. Arguably, I don’t feel I’m a skilled enough coder to do this either. I know enough C code to be dangerous, but this is playing with stuff deep in a system where I have never needed to stray before. That said, in the aim of “getting the ball rolling”, I made a start. I also made a map of where known slop is in the kernel so in the meantime, I can avoid touching it.

An uncomfortable truth with this: we will get security vulnerability reports from people that used LLMs to discover them even if we ask them not to use such tools.

I don’t want to condone such use in any way, but nonetheless, a security bug is a security bug. I don’t think it’s unreasonable to push back on submitters and ask for a human-written-and-verified proof-of-concept, but people will be feeding this code to LLMs to find holes whether we like it or not. Such a fork should aim to patch vulnerabilities with slop-free commits, but refusing to fix it at all because a LLM was involved isn’t a viable option as the bug can still be exploited.

Another uncomfortable truth, people will sometimes neglect to disclose LLM use, either accidentally or deliberately. Where we have obvious and clear evidence, we should reject such commits. Otherwise I’m willing to operate on the principle of “innocent until found guilty”, as its nearly impossible to tell just scrutinising a commit in isolation.

That said, I feel like maintaining a long-term support fork that just focusses on keeping the security updates maintained will give those of us with existing systems a viable platform that will allow us to run our existing software stacks. This won’t be “big and professional” like Linux (yeah, I know), but if a few of us band together and pitch in, it’ll give many of us what we need in the immediate term whilst the alternatives get up to speed.

Linux distributions

I already use Gentoo as my desktop OS of choice, so there I’m clear. I have a few machines that run other OSes, notably a couple of Ubuntu and Debian servers, my Ceph storage cluster all run Debian, my Mastodon instance is Debian. I have a tablet running Debian 13, and Raspberry Pi OS on a few Raspberry Pis.

Most of my servers run AlpineLinux, I do not know what their policy is, but so far I’ve not seen any slop creeping in.

I have run Gentoo on servers before, but I think if a re-load is on the cards, I’ll be looking at NetBSD first. Failing that, it may be a case of I figure out a build environment that can keep grinding away at security updates for my fleet so I can perform updates in a timely manner.

Desktop environment

My current desktop is FVWM. This is a X11 window manager, and while FVWM itself is slop-free, the next release of X.org server is not. I am watching CoW very closely, and have given it a try from time to time. Wayland itself seems to be slop-free, but it is lacking some features of X11, notably accessibility is a big issue.

For my tablet, a decent on-screen keyboard is a must, right now I use Onboard which I’ve found to be the best option (although I note now, they have jumped in bed with Claude as of June this year), but this only works on X11. Things I need: basically look at any laptop keyboard — letters and digits, with symbols in their usual places, all modifier keys, function keys and navigation keys. Just because I’m using a tablet does not mean I won’t be interacting with pointer-naïve terminal applications, possibly via SSH… and sometimes interacting with a text field is easier done with on-screen arrow keys than with touch, not even Apple or Google can make pure-touch work.

I need to figure out a screen locking solution, I use XScreensaver at present which is a good option, but it depends on features that are X11-only. It also does not work with on-screen keyboards. I theoretically could fork it, but given recent experience, I’m not sure that my derivative work would be welcome. Better approach might be to deal with a screen locker that maybe isn’t as pretty, but achieves the necessary job: locking the workstation securely on a Wayland desktop. For the tablet, it’ll need on-screen keyboard support — I need to be able to unlock without a USB keyboard plugged in.

I have not seen a Wayland launcher that I like, so I’m quietly working on my own based on ideas I came up with when I last pondered desktop environments.

Other applications, I’ve previously used a lot from the KDE desktop, but that is something I’m starting to review as they embrace the slop. I historically have disliked GTK+ for its insistence on spewing error logs to stderr, but nonetheless, as at this time, this is the only main-stream widget set now that remains slop-free with Qt, wxWidgets and FLTK all embracing slop.

So where I had a Qt preference years ago, I’m now moving to GTK+: it appears the UI toolkit might be finally over, with the opposition choosing self-sacrifice and GTK+ winning by default.

Bluetooth stack

Right now I use BlueZ, and it is useful as a means of moving files to/from the mobile phone as well as a key part in managing the audio links to headsets. If I switched OSes, I’d be looking at something with a similar feature-set.

Sadly it embraces the slop now. Thankfully I haven’t needed to dig into its code… I can put up with it for now, but a more ethical option would be welcome.

Audio subsystem

Right now I use pipewire for managing audio as it is a very usable blend of features from PulseAudio and JACK. I like the ability to filter audio through applications where needed and would like to keep this feature. Its integration into the BlueZ Bluetooth stack is good too.

I think JACK is cross-platform, but PipeWire is likely Linux-only, and it recently has embraced the slop. I know OpenBSD has its own called sndiod, this probably can compete with PulseAudio but not with JACK/Pipewire.

For now unless I need to actually debug it, I can “put up” with it.

Web Browser

I dislike Chromium because of its multi-day long builds from source code, it’s a very time consuming package to compile from source. As a Gentoo user, that is the default way it is shipped, as source code you compile yourself. I also dislike the idea of an Internet web browser mono-culture. We had this 25 years ago with IE and it was hell.

The only thing in Chromium’s favour is that it is open-source, so we can port it and build it ourselves, but that’s about where the advantages end. The principle maintainer, Google, are a major LLM vendor, and very much want to encourage people to use their services including Gemeni. I haven’t checked, but I can’t imagine Google not using LLMs to code their browser engine.

I’m a Netscape user from way back: in 1997 it was the only viable option for getting on the Internet with Linux and so that’s what I got to know. When Mozilla formed from Netscape’s ashes, I switched over to using the full Mozilla suite (which lives on as Seamonkey) and when Firefox came, I switched to that. Building Firefox from source can be done in a couple of hours on even reasonably modest hardware, vs about 5 days for my teenage laptop to build Chromium.

Mozilla have since come out as pro-LLM, a tone-deaf stance if ever I heard one, so much they not only use LLMs to code, they also integrate LLM features in the browser.

That said, they do include an OFF switch for the LLM features, and that I do respect. I’d have preferred if they made it an extension you chose to install if you wanted it, but they at least let me turn it off. This is akin to having a gun in a safe at home but not possessing any ammunition for it. I’d rather not have the gun in the house at all, but at least I’m not forced to have it loaded.

Servo Browser is one to watch in this space. It’s a ground-up implementation of a new HTML renderer to compete with Blink/Webkit/KHTML and Netscape Gecko. It’s a long way from daily driver status, but well worth getting behind, and they are making good progress. I wish them well and continue to follow from a distance. I’ll probably be testing some of my web-based projects with this engine going forward.

I’ve tried building Waterfox, but so far haven’t cracked it… so for now I stick with Firefox ESR. Last time I had to delve into its source code, it was trying to produce a compromise patch that would enable Firefox to build on more common MIPS platforms (e.g. SGI and Lemote) whilst retaining the compatibility for the PlayStation II that the Mozilla developers wanted to keep. Firefox is partially coded in Rust now so this is a moot point: Rust doesn’t work on MIPS.

As such, I haven’t needed to mess with its code in a long time. So short term, I’ll stay where I am, and start looking at getting behind Servo as the replacement.

Office Suite

Text documents I tend to do with LaTeX. This so far remains slop-free, but they’ve recently adopted a policy that permits LLM-generated commits so it won’t remain that way for long.

For spreadsheeting, gnumeric is “good enough”, and in fact its Engineering notation I find is a killer feature. It remains slop-free.

I do have LibreOffice installed for more complex tasks and interfacing with Microsofties. They’ve said they won’t add LLM features to LibreOffice (a stance I appreciate), but they have allowed its use with writing its code. Again, I don’t need to debug it, so I’ll deal with that later.

EDA

I don’t just write code, I design circuits too. I’ve bounced between a few, but the two I’ve used in the open-source world are KiCAD and GEDA. KiCAD is by far the better supported package. Sadly contains a lot of slop in it now, but once again, so long as I don’t interact with its code I’m not tainting myself.

There are alternative toolchains too, maybe the answer isn’t a “graphical” schematic capture, but to do something more like is done for FPGAs, a hardware-description language that translates to a netlist?

Graphics

Right now I use three tools principally: GIMP, Krita and Inkscape. GIMP recently started accepting slop (just the one commit) as have Inkscape (two commits). Krita remains clean (for now).

I mostly still use GIMP v2 because of my use of the XSane plug-in which has not yet been ported to GIMP v3. Inkscape taking this slop on is annoying, but so far I’ve not needed to debug it, so I can possibly put up with it for now until I can jump ship to an alternative.

Audio editing

I normally use Audacity for basic needs, I should give Tenacity a look.

For more advanced tasks I’ve used Ardour but given I’ve not gone deep into learning Ardour, switching to something like LMMS isn’t a big issue.

Video editing

Historically I’ve used Kdenlive, so far it remains clean. ffmpeg though is a mess.

Text editing

My bread-and-butter, editing plain text files is how I’ve been earning a living for the past 18 years or so of professional life. My go-to until recently was gvim, but as they now embrace the slop, I switched over to hard fork gevi. An easy switch because EVi at this time, is practically identical to Vim, all my plug-ins and configs JustWork™.

This blog

This blog currently uses WordPress 7.1, which includes their Gutenberg block editor. I did look at alternatives some time back, I use this WordPress instance as an ActivityPub node, and that’s not something that’s well supported in the other platforms.

Migrating to something else is also not so easy… thankfully I host it myself so I have control of my data either way.

My social media instance

I run my own Mastodon server, have done for a couple of years now. There is some (two commits) slop there, but generally things have remained clean. The modifications I’ve made were done long before this slop appeared, and I’ve merely been using git stash save / update / git stash pop to move the patch between releases.

Migrating to something else is not exactly trivial, even changing hostnames isn’t easy.

Writing my own software

So I write a lot of my own software. When I needed an embedded AX.25 stack for a project for Brisbane WICEN, I wrote aioax25. When I needed a SSTV encoder after finding pySSTV wasn’t performant-enough, I wrote libsstvenc. I’m in the process of writing my on launcher.

You’ll see lots of examples on my Github and Codeberg repositories.

Going forward, I’ll probably start looking more carefully at my dependencies. Notably, I do not wish to force a hard-dependency on a LLM-infected project unless there is no viable alternative.

aioax25 is actually tested on Python 3.9 and up, and I’ll keep supporting this as long as I practically can. The code is written with Python 3.5 in mind, so it should still work there too even though I don’t regularly test it on that. This in theory opens the door to use on other Python-compatible language interpreters like Omegathon (untested). It also has no hard dependency on an OS: it should in theory work just fine on NetBSD/OpenBSD as it does on Linux.

libsstvenc is straight C and doesn’t itself have any dependencies, the example programs support libgd which is clean of slop for now. GNU GCC have stated they won’t allow LLM-generated commits for the compiler itself, although there are a couple of commits already for their Fortran compiler, their C/C++ compiler remains clean for now. If I remain conservative with the version of C standard, this allows use of any pre-slop C compiler that meets the spec.

Checkpoint Reporter is written in pure Java using the OpenJDK v8 SDK. I can confirm it runs fine on NetBSD, and so far, big LLM boosters Oracle have requested that people not use LLMs for contributing to OpenJDK. This position I do welcome, but it does make me raise an eyebrow given how pro-LLM, if it’s supposedly so good, why not? Their lawyers must know something they’re not willing to share. I might have to review its use of Maven, this was a default option when creating a project in Netbeans, it may be that good ol’e Ant might be the better option. I’ll have a look.

My biggest gripe with Java remains their reluctance to consider serial devices: all solutions I can find require JNI (with bindings compiled for each desired platform, so much for write-once-run-everywhere, Ugh!). Highly annoying.

The launcher I’m writing, right now I’m trying gtkmm and friends as an alternative to Qt, which was my previous go-to UI toolkit. Again, if I stick to older C++ standards (gtkmm requires C++11, C++20 is widely supported too), people can choose to use an older release of GCC or LLVM that’s pre-slop, or in theory, any other compiler that supports that revision of C++. gtkmm itself too, is clean, and if I support as old a release as practical, that’ll enable the launcher’s use on many pre-slop versions of Linux distributions and other Unix-like OSes. I use C++ here because it allows the tools use on platforms where more recent languages such as Rust and Zig are not available.

I might have a closer look at Rust, I’ve done some hello-world level stuff with it. The memory-management approach is an interesting one, and while their policy allows “LLM ingestion” (meaning they let people feed its code to a LLM), they’ve stated that any contributions must be human-written (not just human-reviewed).

Zig may also be worth a look, it is manual memory management like C/C++, but it doesn’t have some of C’s flaws, and they have an anti-AI policy. Right now they use the LLVM back-end (which is itself, quite heavily LLM-tainted) but I hear they’re working on an alternative, so maybe in time they may sever that dependency (at least on common platforms).

eC is another I might look at. Rather than implementing the full compiler, theirs is effectively a transpiler to C. So it can sit atop gcc, clang or anything else.

I have written Go code in the past, but won’t be doing so from here on in. Especially as Go as a language isn’t anything special memory-management wise: it uses garbage-collection the same as Java and C#.

I mentioned Omegathon which is a Python 3.9 fork, Tauthon forks Python 2.7 and adds some interesting features from Python 3. Given I usually enjoy working with Python, these might be worth looking at closer.

For JavaScript, I lately have been using ReactJS because of my need to understand it at work, but I really haven’t enjoyed dealing with ReactJS and so will look at other options. The elephant in the room here is tools like webpack that are LLM-infested. Avoiding slop in this ecosystem is not an easy or trivial task, especially as there isn’t a mainstream open-source browser that is clean.

In short, while slop is invading a lot of projects, there looks to be some scope to dodge the slop when creating new software, and there are things I can do to ensure existing software I write can be used in a mostly slop-free environment if that is something people want. I aim to try to do this where practical.