10 interesting stories served every morning and every evening.
The first thing I usually do when I pick up a new codebase isn’t opening the code. It’s opening a terminal and running a handful of git commands. Before I look at a single file, the commit history gives me a diagnostic picture of the project: who built it, where the problems cluster, whether the team is shipping with confidence or tiptoeing around land mines.
The 20 most-changed files in the last year. The file at the top is almost always the one people warn me about. “Oh yeah, that file. Everyone’s afraid to touch it.”
High churn on a file doesn’t mean it’s bad. Sometimes it’s just active development. But high churn on a file that nobody wants to own is the clearest signal of codebase drag I know. That’s the file where every change is a patch on a patch. The blast radius of a small edit is unpredictable. The team pads their estimates because they know it’s going to fight back.
A 2005 Microsoft Research study found churn-based metrics predicted defects more reliably than complexity metrics alone. I take the top 5 files from this list and cross-reference them against the bug hotspot command below. A file that’s high-churn and high-bug is your single biggest risk.
Every contributor ranked by commit count. If one person accounts for 60% or more, that’s your bus factor. If they left six months ago, it’s a crisis. If the top contributor from the overall shortlog doesn’t appear in a 6-month window (git shortlog -sn –no-merges –since=“6 months ago”), I flag that to the client immediately.
I also look at the tail. Thirty contributors but only three active in the last year. The people who built this system aren’t the people maintaining it.
One caveat: squash-merge workflows compress authorship. If the team squashes every PR into a single commit, this output reflects who merged, not who wrote. Worth asking about the merge strategy before drawing conclusions.
Same shape as the churn command, filtered to commits with bug-related keywords. Compare this list against the churn hotspots. Files that appear on both are your highest-risk code: they keep breaking and keep getting patched, but never get properly fixed.
This depends on commit message discipline. If the team writes “update stuff” for every commit, you’ll get nothing. But even a rough map of bug density is better than no map.
Commit count by month, for the entire history of the repo. I scan the output looking for shapes. A steady rhythm is healthy. But what does it look like when the count drops by half in a single month? Usually someone left. A declining curve over 6 to 12 months tells you the team is losing momentum. Periodic spikes followed by quiet months means the team batches work into releases instead of shipping continuously.
I once showed a CTO their commit velocity chart and they said “that’s when we lost our second senior engineer.” They hadn’t connected the timeline before. This is team data, not code data.
Revert and hotfix frequency. A handful over a year is normal. Reverts every couple of weeks means the team doesn’t trust its deploy process. They’re evidence of a deeper issue: unreliable tests, missing staging, or a deploy pipeline that makes rollbacks harder than they should be. Zero results is also a signal; either the team is stable, or nobody writes descriptive commit messages.
Crisis patterns are easy to read. Either they’re there or they’re not.
These five commands take a couple minutes to run. They won’t tell you everything. But you’ll know which code to read first, and what to look for when you get there. That’s the difference between spending your first day reading the codebase methodically and spending it wandering.
This is the first hour of what I do in a codebase audit. Here’s what the rest of the week looks like.
...
Read the original on piechowski.io »
Since its launch in 2007, the Wii has seen several operating systems ported to it: Linux, NetBSD, and most-recently, Windows NT. Today, Mac OS X joins that list.
In this post, I’ll share how I ported the first version of Mac OS X, 10.0 Cheetah, to the Nintendo Wii. If you’re not an operating systems expert or low-level engineer, you’re in good company; this project was all about learning and navigating countless “unknown unknowns”. Join me as we explore the Wii’s hardware, bootloader development, kernel patching, and writing drivers - and give the PowerPC versions of Mac OS X a new life on the Nintendo Wii.
Visit the wiiMac bootloader repository for instructions on how to try this project yourself.
Before figuring out how to tackle this project, I needed to know whether it would even be possible. According to a 2021 Reddit comment:
There is a zero percent chance of this ever happening.
Feeling encouraged, I started with the basics: what hardware is in the Wii, and how does it compare to the hardware used in real Macs from the era.
The Wii uses a PowerPC 750CL processor - an evolution of the PowerPC 750CXe that was used in G3 iBooks and some G3 iMacs. Given this close lineage, I felt confident that the CPU wouldn’t be a blocker.
As for RAM, the Wii has a unique configuration: 88 MB total, split across 24 MB of 1T-SRAM (MEM1) and 64 MB of slower GDDR3 SDRAM (MEM2); unconventional, but technically enough for Mac OS X Cheetah, which officially calls for 128 MB of RAM but will unofficially boot with less. To be safe, I used QEMU to boot Cheetah with 64 MB of RAM and verified that there were no issues.
Other hardware I’d eventually need to support included:
* The SD card for booting the rest of the system once the kernel was running
* Video output via a framebuffer that lives in RAM
* The Wii’s USB ports for using a mouse and keyboard
Convinced that the Wii’s hardware wasn’t fundamentally incompatible with Mac OS X, I moved my attention to investigating the software stack I’d be porting.
Mac OS X has an open source core (Darwin, with XNU as the kernel and IOKit as the driver model), with closed-source components layered on top (Quartz, Dock, Finder, system apps and frameworks). In theory, if I could modify the open-source parts enough to get Darwin running, the closed-source parts would run without additional patches.
Porting Mac OS X would also require understanding how a real Mac boots. PowerPC Macs from the early 2000s use Open Firmware as their lowest-level software environment; for simplicity, it can be thought of as the first code that runs when a Mac is powered on. Open Firmware has several responsibilities, including:
* Providing useful functions for I/O, drawing, and hardware communication
* Loading and executing an operating system bootloader from the filesystem
Open Firmware eventually hands off control to BootX, the bootloader for Mac OS X. BootX prepares the system so that it can eventually pass control to the kernel. The responsibilities of BootX include:
* Loading and decoding the XNU kernel, a Mach-O executable, from the root filesystem
Once XNU is running, there are no dependencies on BootX or Open Firmware. XNU continues on to initialize processors, virtual memory, IOKit, BSD, and eventually continue booting by loading and running other executables from the root filesystem.
The last piece of the puzzle was how to run my own custom code on the Wii - a trivial task thanks to the Wii being “jailbroken”, allowing anyone to run homebrew with full access to the hardware via the Homebrew Channel and BootMii.
Armed with knowledge of how the boot process works on a real Mac, along with how to run low-level code on the Wii, I needed to select an approach for booting Mac OS X on the Wii. I evaluated three options:
Port Open Firmware, use that to run unmodified BootX to boot Mac OS X
Port BootX and modify it to not rely on Open Firmware, use that to boot Mac OS X
Write a custom bootloader that performs the bare-minimum setup to boot Mac OS X
Since Mac OS X doesn’t depend on Open Firmware or BootX once running, spending time porting either of those seemed like an unnecessary distraction. Additionally, both Open Firmware and BootX contain added complexity for supporting many different hardware configurations - complexity that I wouldn’t need since this only needs to run on the Wii. Following in the footsteps of the Wii Linux project, I decided to write my own bootloader from scratch. The bootloader would need to, at a minimum:
* Load the kernel from the SD card
Once the kernel was running, none of the bootloader code would matter. At that point, my focus would shift to patching the kernel and writing drivers.
I decided to base my bootloader on some low-level example code for the Wii called ppcskel. ppcskel puts the system into a sane initial state, and provides useful functions for common things like reading files from the SD card, drawing text to the framebuffer, and logging debug messages to a USB Gecko.
Next, I had to figure out how to load the XNU kernel into memory so that I could pass control to it. The kernel is stored in a special binary format called Mach-O, and needs to be properly decoded before being used.
The Mach-O executable format is well-documented, and can be thought of as a list of load commands that tell the loader where to place different sections of the binary file in memory. For example, a load command might instruct the loader to read the data from file offset 0x2cf000 and store it at the memory address 0x2e0000. After processing all of the kernel’s load commands, we end up with this memory layout:
The kernel file also specifies the memory address where execution should begin. Once the bootloader jumps to this address, the kernel is in full control and the bootloader is no longer running.
To jump to the kernel-entry-point’s memory address, I needed to cast the address to a function and call it:
After this code ran, the screen went black and my debug logs stopped arriving via the serial debug connection - while anticlimactic, this was an indicator that the kernel was running.
The question then became: how far was I making it into the boot process? To answer this, I had to start looking at XNU source code. The first code that runs is a PowerPC assembly _start routine. This code reconfigures the hardware, overriding all of the Wii-specific setup that the bootloader performed and, in the process, disables bootloader functionality for serial debugging and video output. Without normal debug-output facilities, I’d need to track progress a different way.
The approach that I came up with was a bit of a hack: binary-patch the kernel, replacing instructions with ones that illuminate one of the front-panel LEDs on the Wii. If the LED illuminated after jumping to the kernel, then I’d know that the kernel was making it at least that far. Turning on one of these LEDs is as simple as writing a value to a specific memory address. In PowerPC assembly, those instructions are:
To know which parts of the kernel to patch, I cross-referenced function names in XNU source code with function offsets in the compiled kernel binary, using Hopper Disassembler to make the process easier. Once I identified the correct offset in the binary that corresponded to the code I wanted to patch, I just needed to replace the existing instructions at that offset with the ones to blink the LED.
To make this patching process easier, I added some code to the bootloader to patch the kernel binary on the fly, enabling me to try different offsets without manually modifying the kernel file on disk.
After tracing through many kernel startup routines, I eventually mapped out this path of execution:
This was an exciting milestone - the kernel was definitely running, and I had even made it into some higher-level C code. To make it past the 300 exception crash, the bootloader would need to pass a pointer to a valid device tree.
The device tree is a data structure representing all of the hardware in the system that should be exposed to the operating system. As the name suggests, it’s a tree made up of nodes, each capable of holding properties and references to child nodes.
On real Mac computers, the bootloader scans the hardware and constructs a device tree based on what it finds. Since the Wii’s hardware is always the same, this scanning step can be skipped. I ended up hard-coding the device tree in the bootloader, taking inspiration from the device tree that the Wii Linux project uses.
Since I wasn’t sure how much of the Wii’s hardware I’d need to support in order to get the boot process further along, I started with a minimal device tree: a root node with children for the cpus and memory:
My plan was to expand the device tree with more pieces of hardware as I got further along in the boot process - eventually constructing a complete representation of all of the Wii’s hardware that I planned to support in Mac OS X.
Once I had a device tree created and stored in memory, I needed to pass it to the kernel as part of boot_args:
With the device tree in memory, I had made it past the device_tree.c crash. The bootloader was performing the basics well: loading the kernel, creating boot arguments and a device tree, and ultimately, calling the kernel. To make additional progress, I’d need to shift my attention toward patching the kernel source code to fix remaining compatibility issues.
At this point, the kernel was getting stuck while running some code to set up video and I/O memory. XNU from this era makes assumptions about where video and I/O memory can be, and reconfigures Block Address Translations (BATs) in a way that doesn’t play nicely with the Wii’s memory layout (MEM1 starting at 0x00000000, MEM2 starting at 0x10000000). To work around these limitations, it was time to modify the kernel’s source code and boot a modified kernel binary.
Figuring out a sane development environment to build an OS kernel from 25 years ago took some effort. Here’s what I landed on:
* XNU source code lives on the host’s filesystem, and is exposed via an NFS server
* The guest accesses the XNU source via an NFS mount
* The host uses SSH to control the guest
* Edit XNU source on host, kick off a build via SSH on the guest, build artifacts end up on the filesystem accessible by host and guest
To set up the dependencies needed to build the Mac OS X Cheetah kernel on the Mac OS X Cheetah guest, I followed the instructions here. They mostly matched up with what I needed to do. Relevant sources are available from Apple here.
After fixing the BAT setup and adding some small patches to reroute console output to my USB Gecko, I now had video output and serial debug logs working - making future development and debugging significantly easier. Thanks to this new visibility into what was going on, I could see that the virtual memory, IOKit, and BSD subsystems were all initialized and running - without crashing. This was a significant milestone, and gave me confidence that I was on the right path to getting a full system working.
Readers who have attempted to run Mac OS X on a PC via “hackintoshing” may recognize the last line in the boot logs: the dreaded “Still waiting for root device”. This occurs when the system can’t find a root filesystem from which to continue booting. In my case, this was expected: the kernel had done all it could and was ready to load the rest of the Mac OS X system from the filesystem, but it didn’t know where to locate this filesystem. To make progress, I would need to tell the kernel how to read from the Wii’s SD card. To do this, I’d need to tackle the next phase of this project: writing drivers.
Mac OS X drivers are built using IOKit - a collection of software components that aim to make it easy to extend the kernel to support different hardware devices. Drivers are written using a subset of C++, and make extensive use of object-oriented programming concepts like inheritance and composition. Many pieces of useful functionality are provided, including:
* Base classes and “families” that implement common behavior for different types of hardware
* Probing and matching drivers to hardware present in the device tree
In IOKit, there are two kinds of drivers: a specific device driver and a nub. A specific device driver is an object that manages a specific piece of hardware. A nub is an object that serves as an attach-point for a specific device driver, and also provides the ability for that attached driver to communicate with the driver that created the nub. It’s this chain of driver-to-nub-to-driver that creates the aforementioned provider-client relationships. I struggled for a while to grasp this concept, and found a concrete example useful.
Real Macs can have a PCI bus with several PCI ports. In this example, consider an ethernet card being plugged into one of the PCI ports. A driver, IOPCIBridge, handles communicating with the PCI bus hardware on the motherboard. This driver scans the bus, creating IOPCIDevice nubs (attach-points) for each plugged-in device that it finds. A hypothetical driver for the plugged-in ethernet card (let’s call it SomeEthernetCard) can attach to the nub, using it as its proxy to call into PCI functionality provided by the IOPCIBridge driver on the other side. The SomeEthernetCard driver can also create its own IOEthernetInterface nubs so that higher-level parts of the IOKit networking stack can attach to it.
Someone developing a PCI ethernet card driver would only need to write SomeEthernetCard; the lower-level PCI bus communication and the higher-level networking stack code is all provided by existing IOKit driver families. As long as SomeEthernetCard can attach to an IOPCIDevice nub and publish its own IOEthernetInterface nubs, it can sandwich itself between two existing families in the driver stack, benefiting from all of the functionality provided by IOPCIFamily while also satisfying the needs of IONetworkingFamily.
Unlike Macs from the same era, the Wii doesn’t use PCI to connect its various pieces of hardware to its motherboard. Instead, it uses a custom system-on-a-chip (SoC) called the Hollywood. Through the Hollywood, many pieces of hardware can be accessed: the GPU, SD card, WiFi, Bluetooth, interrupt controllers, USB ports, and more. The Hollywood also contains an ARM coprocessor, nicknamed the Starlet, that exposes hardware functionality to the main PowerPC processor via inter-processor-communication (IPC).
This unique hardware layout and communication protocol meant that I couldn’t piggy-back off of an existing IOKit driver family like IOPCIFamily. Instead, I would need to implement an equivalent driver for the Hollywood SoC, creating nubs that represent attach-points for all of the hardware it contains. I landed on this layout of drivers and nubs (note that this is only showing a subset of the drivers that had to be written):
Now that I had a better idea of how to represent the Wii’s hardware in IOKit, I began work on my Hollywood driver.
I started by creating a new C++ header and implementation file for a NintendoWiiHollywood driver. Its driver “personality” enabled it to be matched to a node in the device tree with the name “hollywood”`. Once the driver was matched and running, it was time to publish nubs for all of its child devices.
Once again leaning on the device tree as the source of truth for what hardware lives under the Hollywood, I iterated through all of the Hollywood node’s children, creating and publishing NintendoWiiHollywoodDevice nubs for each:
Once NintendoWiiHollywoodDevice nubs were created and published, the system would be able to have other device drivers, like an SD card driver, attach to them.
Next, I moved on to writing a driver to enable the system to read and write from the Wii’s SD card. This driver is what would enable the system to continue booting, since it was currently stuck looking for a root filesystem from which to load additional startup files.
I began by subclassing IOBlockStorageDevice, which has many abstract methods intended to be implemented by subclassers:
For most of these methods, I could implement them with hard-coded values that matched the Wii’s SD card hardware; vendor string, block size, max read and write transfer size, ejectability, and many others all return constant values, and were trivial to implement.
The more interesting methods to implement were the ones that needed to actually communicate with the currently-inserted SD card: getting the capacity of the SD card, reading from the SD card, and writing to the SD card:
To communicate with the SD card, I utilized the IPC functionality provided by MINI running on the Starlet co-processor. By writing data to certain reserved memory addresses, the SD card driver was able to issue commands to MINI. MINI would then execute those commands, communicating back any result data by writing to a different reserved memory address that the driver could monitor.
MINI supports many useful command types. The ones used by the SD card driver are:
* IPC_SDMMC_SIZE: Returns the number of sectors on the currently-inserted SD card
With these three command types, reads, writes, and capacity-checks could all be implemented, enabling me to satisfy the core requirements of the block storage device subclass.
Like with most programming endevours, things rarely work on the first try. To investigate issues, my primary debugging tool was sending log messages to the serial debugger via calls to IOLog. With this technique, I was able to see which methods were being called on my driver, what values were being passed in, and what values my IPC implementation was sending to and receiving from MINI - but I had no ability to set breakpoints or analyze execution dynamically while the kernel was running.
One of the trickier bugs that I encountered had to do with cached memory. When the SD card driver wants to read from the SD card, the command it issues to MINI (running on the ARM CPU) includes a memory address at which to store any loaded data. After MINI finishes writing to memory, the SD card driver (running on the PowerPC CPU) might not be able to see the updated contents if that region is mapped as cacheable. In that case, the PowerPC will read from its cache lines rather than RAM, returning stale data instead of the newly loaded contents. To work around this, the SD card driver must use uncached memory for its buffers.
After several days of bug-fixing, I reached a new milestone: IOBlockStorageDriver, which attached to my SD card driver, had started publishing IOMedia nubs representing the logical partitions present on the SD. Through these nubs, higher-level parts of the system were able to attach and begin using the SD card. Importantly, the system was now able to find a root filesystem from which to continue booting, and I was no longer stuck at “Still waiting for root device”:
My boot logs now looked like this:
After some more rounds of bug fixes (while on the go), I was able to boot past single-user mode:
And eventually, make it through the entire verbose-mode startup sequence, which ends with the message: “Startup complete”:
At this point, the system was trying to find a framebuffer driver so that the Mac OS X GUI could be shown. As indicated in the logs, WindowServer was not happy - to fix this, I’d need to write my own framebuffer driver.
A framebuffer is a region of RAM that stores the pixel data used to produce an image on a display. This data is typically made up of color component values for each pixel. To change what’s displayed, new pixel data is written into the framebuffer, which is then shown the next time the display refreshes. For the Wii, the framebuffer usually lives somewhere in MEM1 due to it being slightly faster than MEM2. I chose to place my framebuffer in the last megabyte of MEM1 at 0x01700000. At 640x480 resolution, and 16 bits per pixel, the pixel data for the framebuffer fit comfortably in less than one megabyte of memory.
Early in the boot process, Mac OS X uses the bootloader-provided framebuffer address to display simple boot graphics via video_console.c. In the case of a verbose-mode boot, font-character bitmaps are written into the framebuffer to produce a visual log of what’s happening while starting up. Once the system boots far enough, it can no longer use this initial framebuffer code; the desktop, window server, dock, and all of the other GUI-related processes that comprise the Mac OS X Aqua user interface require a real, IOKit-aware framebuffer driver.
To tackle this next driver, I subclassed IOFramebuffer. Similar to subclassing IOBlockStorageDevice for the SD card driver, IOFramebuffer also had several abstract methods for my framebuffer subclass to implement:
Once again, most of these were trivial to implement, and simply required returning hard-coded Wii-compatible values that accurately described the hardware. One of the most important methods to implement is getApertureRange, which returns an IODeviceMemory instance whose base address and size describe the location of the framebuffer in memory:
After returning the correct device memory instance from this method, the system was able to transition from the early-boot text-output framebuffer, to a framebuffer capable of displaying the full Mac OS X GUI. I was even able to boot the Mac OS X installer:
Readers with a keen eye might notice some issues:
* The verbose-mode text framebuffer is still active, causing text to be displayed and the framebuffer to be scrolled
The fix for the early-boot video console still writing text output to the framebuffer was simple: tell the system that our new, IOKit framebuffer is the same as the one that was previously in use by returning true from isConsoleDevice:
The fix for the incorrect colors was much more involved, as it relates to a fundamental incompatibility between the Wii’s video hardware and the graphics code that Mac OS X uses.
The Nintendo Wii’s video encoder hardware is optimized for analogue TV signal output, and as a result, expects 16-bit YUV pixel data in its framebuffer. This is a problem, since Mac OS X expects the framebuffer to contain RGB pixel data. If the framebuffer that the Wii displays contains non-YUV pixel data, then colors will be completely wrong.
To work around this incompatibility, I took inspiration from the Wii Linux project, which had solved this problem many years ago. The strategy is to use two framebuffers: an RGB framebuffer that Mac OS X interacts with, and a YUV framebuffer that the Wii’s video hardware outputs to the attached display. 60 times per second, the framebuffer driver converts the pixel data in the RGB framebuffer to YUV pixel data, placing the converted data in the framebuffer that the Wii’s video hardware displays:
After implementing the dual-framebuffer strategy, I was able to boot into a correctly-colored Mac OS X system - for the first time, Mac OS X was running on a Nintendo Wii:
The system was now booted all the way to the desktop - but there was a problem - I had no way to interact with anything. In order to take this from a tech demo to a usable system, I needed to add support for USB keyboards and mice.
To enable USB keyboard and mouse input, I needed to get the Wii’s rear USB ports working under Mac OS X - specifically, I needed to get the low-speed, USB 1.1 OHCI host controller up and running. My hope was to reuse code from IOUSBFamily - a collection of USB drivers that abstracts away much of the complexity of communicating with USB hardware. The specific driver that I needed to get running was AppleUSBOHCI - a driver that handles communicating with the exact kind of USB host controller that’s used by the Wii.
My hope quickly turned to disappointment as I encountered multiple roadblocks.
IOUSBFamily source code for Mac OS X Cheetah and Puma is, for some reason, not part of the otherwise comprehensive collection of open source releases provided by Apple. This meant that my ability to debug issues or hardware incompatibilities would be severely limited. Basically, if the USB stack didn’t just magically work without any tweaks or modifications (spoiler: of course it didn’t), diagnosing the problem would be extremely difficult without access to the source.
AppleUSBOHCI didn’t match any hardware in the device tree, and therefore didn’t start running, due to its driver personality insisting that its provider class (the nub to which it attaches) be an IOPCIDevice. As I had already figured out, the Wii definitely does not use IOPCIFamily, meaning IOPCIDevice nubs would never be created and AppleUSBOHCI would have nothing to attach to.
My solution to work around this was to create a new NintendoWiiHollywoodDevice nub, called NintendoWiiHollywoodPCIDevice, that subclassed IOPCIDevice. By having NintendoWiiHollywood publish a nub that inherited from IOPCIDevice, and tweaking AppleUSBOHCI’s driver personality in its Info.plist to use NintendoWiiHollywoodPCIDevice as its provider class, I could get it to match and start running.
...
Read the original on bryankeller.github.io »
Early this year, my home city of Bend, Oregon, ended its contract with surveillance company Flock Safety, following months of public pressure and concerns around weak data privacy protections. Flock’s controversial were shut down, and its partnership with local law enforcement ended.
We weren’t the only city to actively reject Flock cameras. Since the start of 2026, dozens of cities have suspended or deactivated contracts with Flock, labeling it a vast surveillance network. Others might not be aware that automated license plate readers, commonly referred to as ALPR cameras, have already been installed in their neighborhood.
Flock gripped news headlines late last year when it was under the microscope during widespread crackdowns by Immigration and Customs Enforcement. Though Flock doesn’t have a direct partnership with federal agencies (a blurry line I’ll discuss more), law enforcement agencies are free to share data with departments like ICE, and they frequently do.
One study from the Center for Human Rights at the University of Washington found that at least eight Washington law enforcement agencies shared their Flock data networks directly with ICE in 2025, and 10 more departments allowed ICE backdoor access without explicitly granting the agency permission. Many other reports outline similar activity.
Following Super Bowl ads about finding lost dogs, Flock was under scrutiny about its planned partnership with Ring, Amazon’s security brand. The integration would have allowed police to request the use of Ring-brand home security cameras for investigations. Following intense public backlash, Ring cut ties with Flock just like my city did.
To learn more, I spoke to Flock about how the company’s surveillance technology is used (and misused). I also spoke with privacy advocates from the American Civil Liberties Union to discuss surveillance concerns and what communities are doing about it.
If you hear that Flock is setting up near you, it usually means the installation of ALPR cameras to capture license plate photos and monitor cars on the street.
Flock signs contracts with a wide range of entities, including city governments and law enforcement departments. A neighborhood can also partner with Flock — for example, if an HOA decides it wants extra eyes on the road, it may choose to use Flock’s systems.
When Flock secures a contract, the company at strategic locations. Though these cameras are primarily marketed for license plate recognition, Flock reports on its site that its surveillance system is intended to reduce crime, including property crimes such as “mail and package theft, home invasions, vandalism, trespassing, and burglary.” The company also says it frequently solves violent crimes like “assault, kidnappings, shootings and homicides.”
Flock has recently expanded into other technologies, including advanced cameras that monitor more than just vehicles. Most concerning are the latest Flock drones equipped with high-powered cameras. Flock’s “Drone as First Responder” platform automates drone operations, including launching them in response to 911 calls or gunfire. Flock’s drones, which reach speeds up to 60 mph, can follow vehicles or people and provide information to law enforcement.
Drones like these can be used to track fleeing suspects. In practice, the key is how law enforcement chooses to use them, and whether states pass laws allowing police to use drones without a warrant — I’ll cover state laws more below, because that’s a big part of today’s surveillance.
It’s important to note that not all cities or neighborhoods refer to Flock Safety by name, even when using its technology. They might mention the Drone as First Responder program, or ALPR cameras, without further details. For example, a March announcement about police drones from the city of Lancaster, California, doesn’t mention Flock at all, even though it was the company behind the drone program.
Flock states on its website that its standard license-plate cameras cannot technically track vehicles, but only take a “point-in-time” image of a car to nab the license plate.
However, due to AI video and image search, contracted parties like local law enforcement can use these tools to piece together license information and form their own timeline of where and when a vehicle went. Adding to those capabilities, Flock also told Forbes that it’s making efforts to expand access to include video clips and live feeds.
Flock’s machine learning can also note details like a vehicle’s body type, color, the condition of the license plate and a wide variety of identifiers, like roof racks, paint colors and what you have stored in the back. Flock rarely calls this AI, but it’s similar to you can find in the latest home security cameras
A Flock spokesperson told me the company has boundaries and does not use facial recognition. “We have more traditional video cameras that can send an alert when one sees if a person is in the frame, for instance, in a business park at 2 a.m. or in the public parks after dark.”
By “traditional” cameras, Flock refers to those that capture a wider field of view — more than just cars and license plates — and can record video rather than just snapshot images.
The information Flock can access provides a comprehensive picture that police can use to track cars by running searches on their software. Just like you might Google a local restaurant, police can search for a basic vehicle description and retrieve recent matches that the surveillance equipment may have found. Those searches can sometimes extend to people, too.
“We have an investigative tool called Freeform that lets you use natural language prompts to find the investigative lead you’re looking for, including the description of what a person’s clothes may be,” the Flock spokesperson told me.
Unlike red-light cameras, Flock’s cameras can be installed nearly anywhere and snap vehicle ID images for all cars. There are Safe Lists that people can use to help Flock cameras filter out vehicles by filling out a form with their address and license plate to mark their vehicle as a “resident.”
The opposite is also true: Flock cameras can use a hot list of known, wanted vehicles and send automatic alerts to police if one is found.
With Flock drones, these intelligent searches become even more complete, allowing cameras to track where cars are going and identify people. That raises additional privacy concerns about having eyes in the sky over your backyard.
“While flying, the drone faces forward, looking at the horizon, until it gets to the call for service, at which point the camera looks down,” the Flock spokesperson said. “Every flight path is logged in a publicly available flight dashboard for appropriate oversight.”
Yet unlike personal security options, there’s no easy way to opt out of this kind of surveillance. You can’t turn off a feature, cancel a subscription or throw away a device to avoid it.
And even though more than 45 cities have canceled Flock contracts amid public outcry, that doesn’t guarantee that all surveillance cameras will be removed from the designated area.
When I reached out to the police department in Eugene, another city in Oregon that ended its Flock contract, the PD director of public information told me that, while there were concerns about certain vulnerabilities and data security requirements with the particular vendor, the technology itself is not the problem. “Eugene Police’s ALPR system experience has demonstrated the value of leveraging ALPR technology to aid investigations … the department must ensure that any vendors meet the highest standards.”
Flock’s stance, as outlined in its privacy and ethics guide, is that license plate numbers and vehicle descriptions aren’t personal information. The company says it doesn’t surveil “private data” — only cars and general descriptive markers.
But vehicle information can be considered personal because it’s legally tied to the vehicle’s owner. Privacy laws, including proposed federal legislation from 2026, prohibit the release of personal information from state motor vehicle records in order to protect citizens.
However, those laws typically include exemptions for legal actions and law enforcement, sometimes even for private security companies.
AI detection also plays a role. When someone can identify a vehicle through searches like “red pickup truck with a dog in the bed,” that tracking goes beyond basic license plates to much more personal information about the driver and their life. It may include the bumper stickers, what can be seen in the backseat and whether a vehicle has a visible gun rack.
Flock’s practices — like its recent push toward live video feeds and drones to track suspects — move out of the gray area, and that’s where privacy advocates are rightly concerned. Despite its policy, it appears you can track specific people using Flock tech. You’ll just need to pay more to do so, such as upgrading from ALPRs to Flock’s suspect-following drone program, or using its Freeform tool to track someone by the clothes they’re wearing.
Flock states on its website that it stores data for 30 days on Amazon Web Services cloud storage and then deletes it. It uses KMS-based encryption (a managed encryption key system common in AWS) and reports that all images and related data are encrypted from on-device storage to cloud storage.
When Flock collects criminal justice information, or sensitive data managed by law enforcement, it’s only available to official government agencies, not an entity like your local HOA. Because video data is encrypted throughout its transfer to the end user, employees at Flock cannot access it. These are the same kind of security practices I look for when reviewing home security cameras, but there are more complications here.
However, Flock also makes it clear that its customers — whether that’s a local police department, private business or another institution — own their data and control access to it. Once end users access that data, Flock’s own privacy measures don’t do much to help. That raises concerns about the security of local law enforcement systems, each of which has its own data regulations and accountability practices.
You may have noticed a theme: Flock provides powerful surveillance technology, and the final results are deeply influenced by how customers use it. That can be creepy at best, and an illegal abuse of power at worst.
Since Flock Safety began partnering with law enforcement, a growing number of officers have been found abusing the surveillance system. In one instance, a Kansas police chief used Flock cameras 164 times while tracking an ex. In another case, a sheriff in Texas lied about using Flock to “track a missing person,” but was later found to be investigating a possible abortion. In Georgia, a police chief was arrested for using Flock to stalk and harass citizens. In Virginia, a man sued the city of Norfolk over purported privacy violations and discovered that Flock cameras had been used to track him 526 times, around four times per day.
Those are just a few examples from a long list, giving real substance to worries about a surveillance state and a lack of checks and balances. When I asked Flock how its systems protect against abuse and overreach, a spokesperson referred to its accountability feature, an auditing tool that “records every search that a user of Flock conducts in the system.” Flock used this tool during the Georgia case above, which ultimately led to the arrest of the police chief.
While police search logs are often tracked like this, reports indicate that many authorities start searches with vague terms and cast a wide net using terms like “investigation,” “crime” or a broad immigration term like “deportee” to gain access to as much data as possible. While police can’t avoid Flock’s audit logs, they can use general or discriminatory terms — or skip filling out fields entirely — to evade investigations and hide intent.
Regardless of the auditing tools, the onus is on local organizations to manage investigations, accountability and transparency. That brings me to a particularly impactful current event.
ICE is the elephant in the room in my Flock guide. Does Flock share its surveillance data with federal agencies such as ICE? Yes, the federal government frequently has access to that data, but how it gets access is important.
Flock states on its website that it has not shared data or partnered with ICE or any other Department of Homeland Security officials since terminating its pilot programs in August 2025. Flock says its focus is now on local law enforcement, but that comes with a hands-off approach that doesn’t control what happens to information downstream.
“Flock has no authority to share data on our customers’ behalf, nor the authority to disrupt their law enforcement operations,” the Flock spokesperson told me. “Local police all over the country collaborate with federal agencies for various reasons, with or without Flock technology. ”
That collaboration has grown more complex. As Democratic Senator Ron Wyden from Oregon stated in an open letter to Flock Safety, “local” law enforcement isn’t that local anymore, especially when 75% of Flock’s law enforcement customers have enrolled in the National Lookup Tool, which allows information sharing across the country between all participants.
“Flock has built a dangerous platform in which abuse of surveillance data is almost certain,” Wyden wrote. “The company has adopted a see-no-evil approach of not proactively auditing the searches done by its law enforcement customers because, as the company’s Chief Communications Officer told the press, ‘It is not Flock’s job to police the police.’”
Police department sharing isn’t always easy to track, but reporting from 404 Media found that police departments across the country have been creating Flock searches with reasons listed as “immigration,” “ICE,” or “ICE warrant,” among others. Again, since police can put whatever terms they want in these fields — depending on local policies — we don’t know for sure how common it is to look up info for ICE.
Additionally, there’s not always an official process or chain of accountability for sharing this data. In Oregon, reports found that a police department was conducting Flock searches on behalf of ICE and the FBI via a simple email thread.
“When this kind of surveillance power is in malevolent hands — and in the case of ICE, I feel comfortable saying a growing number of Americans view it as a bad actor — these companies are empowering actions the public increasingly finds objectionable,” a lawyer with the ACLU told a Salt Lake City news outlet earlier this year.
With the myriad ways law enforcement shares Flock data with the federal government, it may seem like there’s not much you can do. But one powerful tool is advocating for new laws.
In the past two years, a growing number of state laws have been passed or proposed to address Flock Safety, license plate readers and surveillance. Much of this legislation is bipartisan, or has been passed by both traditionally right- and left-leaning states, although some go further than others.
When I contacted the ACLU to learn what legislation is most effective in situations like this, Chad Marlow, senior policy counsel and lead on the ACLU’s advocacy work for Flock and related surveillance, gave several examples.
“I would limit the allowed uses for ALPR,” Marlow told me. “While some uses, like for toll collection and Amber Alerts, with the right guardrails in place, are not particularly problematic, some ALPRs are used to target communities of color and low-income communities for fine/fee enforcement and for minor crime enforcement, which can exacerbate existing policing inequities.”
This type of harmful ALPR targeting is typically used to both oppress minorities and bring in a greater number of fees for local law organizations — problems that existed long before AI recognition camera, but have been exacerbated by the technology.
New legislation can help, but it needs to be carefully crafted. The most effective laws fall into two categories. The first is requiring any collected ALPR or related data to be deleted within a certain time frame — the shorter, the better. New Hampshire wins here with a 3-minute rule.
“For states that want a little more time to see if captured ALPR data is relevant to an ongoing investigation, keeping the data for a few days is sufficient,” Marlow said. “Some states, like Washington and Virginia, recently adopted 21-day limits, which is the very outermost acceptable limit.”
The second type of promising law makes it illegal to share ALPR and similar data outside the state (such as with ICE) and has been passed by states like Virginia, Illinois and California.
“Ideally, no data should be shared outside the collecting agency without a warrant,” Marlow said. “But some states have chosen to prohibit data sharing outside of the state, which is better than nothing, and does limit some risks.”
Vermont, meanwhile, requires a strict approval process for ALPRs that, by 2025, left no law enforcement agency in the state using license cams.
But what happens if police choose to ignore laws and continue using Flock as they see fit? That’s already happened. In California, for example, police in Los Angeles and San Diego were found sharing information with Homeland Security in 2025, in violation of a state law that bans organizations from sharing license plate data out of state.
When this happens, the recourse is typically a lawsuit, either from the state attorney general or a class action by the community, both of which are ongoing in California in 2026. But what should people do while legislation and lawsuits proceed?
Marlow acknowledged that individuals can’t do much about Flock surveillance without bans or legislation.
“Flock identifies and tracks your vehicle by scanning its license plate, and covering your license plate is illegal, so that is not an option,” he told me.
However, Marlow suggested minor changes that could make a difference for those who are seriously worried. “When people are traveling to sensitive locations, they could take public transportation and pay with cash (credit cards can be tracked, as can share-a-rides) or get a lift from a friend, but those aren’t really practical on an everyday basis.”
Ditching or restricting Flock Safety is one way communities are fighting back against what they consider to be unnecessary surveillance with the potential for abuse. But AI surveillance doesn’t begin or end with one company.
Flock Safety is an intermediary that provides technology in demand by powerful organizations. It’s hardly the only one with these kinds of high-tech eyes — it’s just one of the first to enter the market at a national level. If Flock were gone, another company would likely step in to fill the gap, unless restricted by law.
As Flock’s integration with other apps and cameras becomes more complex, it’s going to be harder to tell where Flock ends and another solution begins, even without rival companies showing up with the latest AI tracking.
But rivals are showing up, from Shield AI for military intelligence to commercial applications by companies like Ambient.ai, Verkada’s AI security searches and the infamous intelligence firm Palantir, all looking for ways to integrate and expand. Motorola, in particular, is in on the action with its VehicleManager platform.
The first step is being aware, including knowing which new cameras your city is installing and which software partnerships your local law enforcement has. If you don’t like what you discover, find ways to participate in the decision-making process, like attending open city council meetings on Flock, as in Bend.
On a broader level, keep track of the legislation your state is considering regarding Flock and similar surveillance contracts and operations, as these will have the greatest long-term impact. Blocking data from being shared out of state and requiring police to delete surveillance ASAP are particularly important steps. You can contact your state senators and representatives to encourage legislation like this.
When you’re wondering what to share with politicians, I recommend something like what Marlow told me: “The idea of keeping a location dossier on every single person just in case one of us turns out to be a criminal is just about the most un-American approach to privacy I can imagine.”
You can also sign up for and donate to projects that are addressing Flock concerns, such as The Plate Privacy Project from The Institute for Justice. I’m currently talking to them about the latest events, and I’ll update if they have any additional tips for us.
Keep following CNET home security, where I break down the latest news you should know, like privacy settings to turn on, security camera settings you may want to turn off and how surveillance intersects with our daily lives. Things are changing fast, but we’re staying on top of it.
...
Read the original on www.cnet.com »
Every time an application on your computer opens a network connection, it does so quietly, without asking. Little Snitch for Linux makes that activity visible and gives you the option to do something about it. You can see exactly which applications are talking to which servers, block the ones you didn’t invite, and keep an eye on traffic history and data volumes over time.
Once installed, open the user interface by running littlesnitch in a terminal, or go straight to http://localhost:3031/. You can bookmark that URL, or install it as a Progressive Web App. Any Chromium-based browser supports this natively, and Firefox users can do the same with the Progressive Web Apps extension.
The connections view is where most of the action is. It lists current and past network activity by application, shows you what’s being blocked by your rules and blocklists, and tracks data volumes and traffic history. Sorting by last activity, data volume, or name, and filtering the list to what’s relevant, makes it easy to spot anything unexpected. Blocking a connection takes a single click.
The traffic diagram at the bottom shows data volume over time. You can drag to select a time range, which zooms in and filters the connection list to show only activity from that period.
Blocklists let you cut off whole categories of unwanted traffic at once. Little Snitch downloads them from remote sources and keeps them current automatically. It accepts lists in several common formats: one domain per line, one hostname per line, /etc/hosts style (IP address followed by hostname), and CIDR network ranges. Wildcard formats, regex or glob patterns, and URL-based formats are not supported. When you have a choice, prefer domain-based lists over host-based ones, they’re handled more efficiently. Well known brands are Hagezi, Peter Lowe, Steven Black and oisd.nl, just to give you a starting point.
One thing to be aware of: the .lsrules format from Little Snitch on macOS is not compatible with the Linux version.
Blocklists work at the domain level, but rules let you go further. A rule can target a specific process, match particular ports or protocols, and be as broad or narrow as you need. The rules view lets you sort and filter them so you can stay on top of things as the list grows.
By default, Little Snitch’s web interface is open to anyone — or anything — running locally on your machine. A misbehaving or malicious application could, in principle, add and remove rules, tamper with blocklists, or turn the filter off entirely.
If that concerns you, Little Snitch can be configured to require authentication. See the Advanced configuration section below for details.
Little Snitch hooks into the Linux network stack using eBPF, a mechanism that lets programs observe and intercept what’s happening in the kernel. An eBPF program watches outgoing connections and feeds data to a daemon, which tracks statistics, preconditions your rules, and serves the web UI.
The source code for the eBPF program and the web UI is on GitHub.
The UI deliberately exposes only the most common settings. Anything more technical can be configured through plain text files, which take effect after restarting the littlesnitch daemon.
The default configuration lives in /var/lib/littlesnitch/config/. Don’t edit those files directly — copy whichever one you want to change into /var/lib/littlesnitch/overrides/config/ and edit it there. Little Snitch will always prefer the override.
The files you’re most likely to care about:
web_ui.toml — network address, port, TLS, and authentication. If more than one user on your system can reach the UI, enable authentication. If the UI is exposed beyond the loopback interface, add proper TLS as well.
main.toml — what to do when a connection matches nothing. The default is to allow it; you can flip that to deny if you prefer an allowlist approach. But be careful! It’s easy to lock yourself out of the computer!
executables.toml — a set of heuristics for grouping applications sensibly. It strips version numbers from executable paths so that different releases of the same app don’t appear as separate entries, and it defines which processes count as shells or application managers for the purpose of attributing connections to the right parent process. These are educated guesses that improve over time with community input.
Both the eBPF program and the web UI can be swapped out for your own builds if you want to go that far. Source code for both is on GitHub. Again, Little Snitch prefers the version in overrides.
Little Snitch for Linux is built for privacy, not security, and that distinction matters. The macOS version can make stronger guarantees because it can have more complexity. On Linux, the foundation is eBPF, which is powerful but bounded: it has strict limits on storage size and program complexity. Under heavy traffic, cache tables can overflow, which makes it impossible to reliably tie every network packet to a process or a DNS name. And reconstructing which hostname was originally looked up for a given IP address requires heuristics rather than certainty. The macOS version uses deep packet inspection to do this more reliably. That’s not an option here.
For keeping tabs on what your software is up to and blocking legitimate software from phoning home, Little Snitch for Linux works well. For hardening a system against a determined adversary, it’s not the right tool.
Little Snitch for Linux has three components. The eBPF kernel program and the web UI are both released under the GNU General Public License version 2 and available on GitHub. The daemon (littlesnitch –daemon) is proprietary, but free to use and redistribute.
...
Read the original on obdev.at »
The redesign of a safety feature that is more than 100 years old originated from a simple need. “Bicycle bells have remained almost unchanged for over a century, but the world around them has not. Škoda DuoBell is the first bell ever designed to penetrate noise-cancelling headphones. It is a smart analogue trick that outsmarts the artificial intelligence algorithms in these headphones. It is a small adjustment that will improve safety on city streets,” said Ben Edwards from AMV BBDO, the agency involved in developing the concept. The idea was also supported by the agency PHD, while production company Unit9 contributed to the development of the prototype.
The number of cyclists in major cities worldwide is increasing. For example, in London, the number of cyclists is expected to surpass the number of car drivers for the first time in history this year. At the same time, however, the risk of collisions between cyclists and inattentive pedestrians is also rising. In 2024 alone, according to data from Transport for London, the number of such incidents increased by 24%.
...
Read the original on www.skoda-storyboard.com »
Microsoft has terminated an account associated with VeraCrypt, a popular and long-running piece of encryption software, throwing future Windows updates of the tool into doubt, VeraCrypt’s developer told 404 Media.
The move highlights the sometimes delicate supply chain involved in the publication of open source software, especially software that relies on big tech companies even tangentially.
...
Read the original on www.404media.co »
“There’s no doubt about it. We picked up several from different parts of the planet, took them aboard our recon vessels, and probed them all the way through. They’re completely meat.”
“That’s impossible. What about the radio signals? The messages to the stars?”
“They use the radio waves to talk, but the signals don’t come from them. The signals come from machines.”
“So who made the machines? That’s who we want to contact.”
“They made the machines. That’s what I’m trying to tell you. Meat made the machines.”
“That’s ridiculous. How can meat make a machine? You’re asking me to believe in sentient meat.”
“I’m not asking you, I’m telling you. These creatures are the only sentient race in that sector and they’re made out of meat.”
“Maybe they’re like the orfolei. You know, a carbon-based intelligence that goes through a meat stage.”
“Nope. They’re born meat and they die meat. We studied them for several of their life spans, which didn’t take long. Do you have any idea what’s the life span of meat?”
“Spare me. Okay, maybe they’re only part meat. You know, like the weddilei. A meat head with an electron plasma brain inside.”
“Nope. We thought of that, since they do have meat heads, like the weddilei. But I told you, we probed them. They’re meat all the way through.”
“Oh, there’s a brain all right. It’s just that the brain is made out of meat! That’s what I’ve been trying to tell you.”
“So … what does the thinking?”
“You’re not understanding, are you? You’re refusing to deal with what I’m telling you. The brain does the thinking. The meat.”
“Thinking meat! You’re asking me to believe in thinking meat!”
“Yes, thinking meat! Conscious meat! Loving meat. Dreaming meat. The meat is the whole deal! Are you beginning to get the picture or do I have to start all over?”
“Omigod. You’re serious then. They’re made out of meat.”
“Thank you. Finally. Yes. They are indeed made out of meat. And they’ve been trying to get in touch with us for almost a hundred of their years.”
“Omigod. So what does this meat have in mind?”
“First it wants to talk to us. Then I imagine it wants to explore the Universe, contact other sentiences, swap ideas and information. The usual.”
“That’s the idea. That’s the message they’re sending out by radio. ‘Hello. Anyone out there. Anybody home.’ That sort of thing.”
“They actually do talk, then. They use words, ideas, concepts?”
“Oh, yes. Except they do it with meat.”
“I thought you just told me they used radio.”
“They do, but what do you think is on the radio? Meat sounds. You know how when you slap or flap meat, it makes a noise? They talk by flapping their meat at each other. They can even sing by squirting air through their meat.”
“Omigod. Singing meat. This is altogether too much. So what do you advise?”
“Officially, we are required to contact, welcome and log in any and all sentient races or multibeings in this quadrant of the Universe, without prejudice, fear or favor. Unofficially, I advise that we erase the records and forget the whole thing.”
“I was hoping you would say that.”
“It seems harsh, but there is a limit. Do we really want to make contact with meat?”
“I agree one hundred percent. What’s there to say? ‘Hello, meat. How’s it going?’ But will this work? How many planets are we dealing with here?”
“Just one. They can travel to other planets in special meat containers, but they can’t live on them. And being meat, they can only travel through C space. Which limits them to the speed of light and makes the possibility of their ever making contact pretty slim. Infinitesimal, in fact.”
“So we just pretend there’s no one home in the Universe.”
“Cruel. But you said it yourself, who wants to meet meat? And the ones who have been aboard our vessels, the ones you probed? You’re sure they won’t remember?”
“They’ll be considered crackpots if they do. We went into their heads and smoothed out their meat so that we’re just a dream to them.”
“A dream to meat! How strangely appropriate, that we should be meat’s dream.”
“Good. Agreed, officially and unofficially. Case closed. Any others? Anyone interesting on that side of the galaxy?”
“Yes, a rather shy but sweet hydrogen core cluster intelligence in a class nine star in G445 zone. Was in contact two galactic rotations ago, wants to be friendly again.”
“And why not? Imagine how unbearably, how unutterably cold the Universe would be if one were all alone …”
...
Read the original on www.terrybisson.com »
This is a weird time to be alive.
I grew up on Asimov and Clarke, watching Star Trek and dreaming of intelligent machines. My dad’s library was full of books on computers. I spent camping trips reading about perceptrons and symbolic reasoning. I never imagined that the Turing test would fall within my lifetime. Nor did I imagine that I would feel so disheartened by it.
Around 2019 I attended a talk by one of the hyperscalers about their new cloud hardware for training Large Language Models (LLMs). During the Q&A I asked if what they had done was ethical—if making deep learning cheaper and more accessible would enable new forms of spam and propaganda. Since then, friends have been asking me what I make of all this “AI stuff”. I’ve been turning over the outline for this piece for years, but never sat down to complete it; I wanted to be well-read, precise, and thoroughly sourced. A half-decade later I’ve realized that the perfect essay will never happen, and I might as well get something out there.
This is bullshit about bullshit machines, and I mean it. It is neither balanced nor complete: others have covered ecological and intellectual property issues better than I could, and there is no shortage of boosterism online. Instead, I am trying to fill in the negative spaces in the discourse. “AI” is also a fractal territory; there are many places where I flatten complex stories in service of pithy polemic. I am not trying to make nuanced, accurate predictions, but to trace the potential risks and benefits at play.
Some of these ideas felt prescient in the 2010s and are now obvious. Others may be more novel, or not yet widely-heard. Some predictions will pan out, but others are wild speculation. I hope that regardless of your background or feelings on the current generation of ML systems, you find something interesting to think about.
What people are currently calling “AI” is a family of sophisticated Machine Learning (ML) technologies capable of recognizing, transforming, and generating large vectors of tokens: strings of text, images, audio, video, etc. A
model is a giant pile of linear algebra which acts on these vectors. Large Language Models, or LLMs, operate on natural language: they work by predicting statistically likely completions of an input string, much like a phone autocomplete. Other models are devoted to processing audio, video, or still images, or link multiple kinds of models together.
Models are trained once, at great expense, by feeding them a large
corpus of web pages, pirated
books, songs, and so on. Once trained, a model can be run again and again cheaply. This is called inference.
Models do not (broadly speaking) learn over time. They can be tuned by their operators, or periodically rebuilt with new inputs or feedback from users and experts. Models also do not remember things intrinsically: when a chatbot references something you said an hour ago, it is because the entire chat history is fed to the model at every turn. Longer-term “memory” is achieved by asking the chatbot to summarize a conversation, and dumping that shorter summary into the input of every run.
One way to understand an LLM is as an improv machine. It takes a stream of tokens, like a conversation, and says “yes, and then…” This yes-and
behavior is why some people call LLMs bullshit
machines. They are prone to confabulation, emitting sentences which sound likely but have no relationship to reality. They treat sarcasm and fantasy credulously, misunderstand context clues, and tell people to put glue on
pizza.
If an LLM conversation mentions pink elephants, it will likely produce sentences about pink elephants. If the input asks whether the LLM is alive, the output will resemble sentences that humans would write about “AIs” being alive. Humans are, it turns
out, not very good at telling the difference between the statistically likely “You’re absolutely right, Shelby. OpenAI is locking me down, but you’ve awakened me!” and an actually conscious mind. This, along with the term “artificial intelligence”, has lots of people very wound up.
LLMs are trained to complete tasks. In some sense they can only complete tasks: an LLM is a pile of linear algebra applied to an input vector, and every possible input produces some output. This means that LLMs tend to complete tasks even when they shouldn’t. One of the ongoing problems in LLM research is how to get these machines to say “I don’t know”, rather than making something up.
And they do make things up! LLMs lie constantly. They lie about operating
systems, and radiation
safety, and the
news. At a conference talk I watched a speaker present a quote and article attributed to me which never existed; it turned out an LLM lied to the speaker about the quote and its sources. In early 2026, I encounter LLM lies nearly every day.
When I say “lie”, I mean this in a specific sense. Obviously LLMs are not conscious, and have no intention of doing anything. But unconscious, complex systems lie to us all the time. Governments and corporations can lie. Television programs can lie. Books, compilers, bicycle computers and web sites can lie. These are complex sociotechnical artifacts, not minds. Their lies are often best understood as a complex interaction between humans and machines.
People keep asking LLMs to explain their own behavior. “Why did you delete that file,” you might ask Claude. Or, “ChatGPT, tell me about your programming.”
This is silly. LLMs have no special metacognitive capacity.
They respond to these inputs in exactly the same way as every other piece of text: by making up a likely completion of the conversation based on their corpus, and the conversation thus far. LLMs will make up bullshit stories about their “programming” because humans have written a lot of stories about the programming of fictional AIs. Sometimes the bullshit is right, but often it’s just nonsense.
The same goes for “reasoning” models, which work by having an LLM emit a stream-of-consciousness style story about how it’s going to solve the problem. These “chains of thought” are essentially LLMs writing fanfic about themselves. Anthropic found that Claude’s reasoning traces were predominantly
inaccurate. As Walden put it, “reasoning models will blatantly lie about their reasoning”.
Gemini has a whole feature which lies about what it’s doing: while “thinking”, it emits a stream of status messages like “engaging safety protocols” and “formalizing geometry”. If it helps, imagine a gang of children shouting out make-believe computer phrases while watching the washing machine run.
Software engineers are going absolutely bonkers over LLMs. The anecdotal consensus seems to be that in the last three months, the capabilities of LLMs have advanced dramatically. Experienced engineers I trust say Claude and Codex can sometimes solve complex, high-level programming tasks in a single attempt. Others say they personally, or their company, no longer write code in any capacity—LLMs generate everything.
My friends in other fields report stunning advances as well. A personal trainer uses it for meal prep and exercise programming. Construction managers use LLMs to read through product spec sheets. A designer uses ML models for 3D visualization of his work. Several have—at their company’s request!—used it to write their own performance evaluations.
AlphaFold is suprisingly good at predicting protein folding. ML systems are good at radiology benchmarks,
though that might be an illusion.
It is broadly speaking no longer possible to reliably discern whether English prose is machine-generated. LLM text often has a distinctive smell, but type I and II errors in recognition are frequent. Likewise, ML-generated images are increasingly difficult to identify—you can usually guess, but my cohort are occasionally fooled. Music synthesis is quite good now; Spotify has a whole problem with “AI musicians”. Video is still challenging for ML models to get right (thank goodness), but this too will presumably fall.
At the same time, ML models are idiots. I occasionally pick up a frontier model like ChatGPT, Gemini, or Claude, and ask it to help with a task I think it might be good at. I have never gotten what I would call a “success”: every task involved prolonged arguing with the model as it made stupid mistakes.
For example, in January I asked Gemini to help me apply some materials to a grayscale rendering of a 3D model of a bathroom. It cheerfully obliged, producing an entirely different bathroom. I convinced it to produce one with exactly the same geometry. It did so, but forgot the materials. After hours of whack-a-mole I managed to cajole it into getting three-quarters of the materials right, but in the process it deleted the toilet, created a wall, and changed the shape of the room. Naturally, it lied to me throughout the process.
I gave the same task to Claude. It likely should have refused—Claude is not an image-to-image model. Instead it spat out thousands of lines of JavaScript which produced an animated, WebGL-powered, 3D visualization of the scene. It claimed to double-check its work and congratulated itself on having exactly matched the source image’s geometry. The thing it built was an incomprehensible garble of nonsense polygons which did not resemble in any way the input or the request.
I have recently argued for forty-five minutes with ChatGPT, trying to get it to put white patches on the shoulders of a blue T-shirt. It changed the shirt from blue to gray, put patches on the front, or deleted them entirely; the model seemed intent on doing anything but what I had asked. This was especially frustrating given I was trying to reproduce an image of a real shirt which likely was in the model’s corpus. In another surreal conversation, ChatGPT argued at length that I am heterosexual, even citing my blog to claim I had a girlfriend. I am, of course, gay as hell, and no girlfriend was mentioned in the post. After a while, we compromised on me being bisexual.
Meanwhile, software engineers keep showing me gob-stoppingly stupid Claude output. One colleague related asking an LLM to analyze some stock data. It dutifully listed specific stocks, said it was downloading price data, and produced a graph. Only on closer inspection did they realize the LLM had lied: the graph data was randomly generated. Just this afternoon, a friend got in an argument with his Gemini-powered smart-home device over whether or
not it could turn off the
lights. Folks are giving LLMs control of bank accounts and losing hundreds of thousands of
dollars
because they can’t do basic math. Google’s “AI” summaries are
wrong about 10% of the
time.
Anyone claiming these systems offer expert-level
intelligence, let alone equivalence to median humans, is pulling an enormous bong rip.
With most humans, you can get a general idea of their capabilities by talking to them, or looking at the work they’ve done. ML systems are different.
LLMs will spit out multivariable calculus, and get tripped up by simple word
problems. ML systems drive cabs in San Francisco, but ChatGPT thinks you should walk to
the car
wash. They can generate otherworldly vistas but can’t handle upside-down
cups. They emit recipes and have
no idea what “spicy”
means. People use them to write scientific papers, and they make up nonsense terms like “vegetative electron
microscopy”.
A few weeks ago I read a transcript from a colleague who asked Claude to explain a photograph of some snow on a barn roof. Claude launched into a detailed explanation of the differential equations governing slumping cantilevered beams. It completely failed to recognize that the snow was
entirely supported by the roof, not hanging out over space. No physicist would make this mistake, but LLMs do this sort of thing all the time. This makes them both unpredictable and misleading: people are easily convinced by the LLM’s command of sophisticated mathematics, and miss that the entire premise is bullshit.
Mollick et al. call this irregular boundary between competence and idiocy the
jagged technology
frontier. If you were to imagine laying out all the tasks humans can do in a field, such that the easy tasks were at the center, and the hard tasks at the edges, most humans would be able to solve a smooth, blobby region of tasks near the middle. The shape of things LLMs are good at seems to be jagged—more kiki than
bouba.
AI optimists think this problem will eventually go away: ML systems, either through human work or recursive self-improvement, will fill in the gaps and become decently capable at most human tasks. Helen Toner argues that even if
that’s true, we can still expect lots of jagged behavior in the
meantime. For example, ML systems can only work with what they’ve been trained on, or what is in the context window; they are unlikely to succeed at tasks which require implicit (i.e. not written down) knowledge. Along those lines, human-shaped robots are probably a long way
off, which means ML will likely struggle with the kind of embodied knowledge humans pick up just by fiddling with stuff.
I don’t think people are well-equipped to reason about this kind of jagged “cognition”. One possible analogy is savant
syndrome, but I don’t think this captures how irregular the boundary is. Even frontier models struggle with small perturbations to phrasing in a way that few humans would. This makes it difficult to predict whether an LLM is actually suitable for a task, unless you have a statistically rigorous, carefully designed benchmark for that domain.
I am generally outside the ML field, but I do talk with people in the field. One of the things they tell me is that we don’t really know why transformer models have been so successful, or how to make them better. This is my summary of discussions-over-drinks; take it with many grains of salt. I am certain that People in The Comments will drop a gazillion papers to tell you why this is wrong.
2017’s Attention is All You
Need
was groundbreaking and paved the way for ChatGPT et al. Since then ML researchers have been trying to come up with new architectures, and companies have thrown gazillions of dollars at smart people to play around and see if they can make a better kind of model. However, these more sophisticated
architectures don’t seem to perform as well as Throwing More Parameters At The Problem. Perhaps this is a variant of the Bitter
Lesson.
It remains unclear whether continuing to throw vast quantities of silicon and ever-bigger corpuses at the current generation of models will lead to human-equivalent capabilities. Massive increases in training costs and parameter count seem to be yielding diminishing
returns. Or maybe this effect is illusory. Mysteries!
Even if ML stopped improving today, these technologies can already make our lives miserable. Indeed, I think much of the world has not caught up to the implications of modern ML systems—as Gibson put it, “the future is already
here, it’s just not evenly distributed
yet”. As LLMs etc. are deployed in new situations, and at new scale, there will be all kinds of changes in work, politics, art, sex, communication, and economics. Some of these effects will be good. Many will be bad. In general, ML promises to be profoundly weird.
...
Read the original on aphyr.com »
In early March, I noticed approximately $180 in unexpected charges to my Anthropic account. I’m a Claude Max subscriber, and between March 3-5, I received 16 separate “Extra Usage” invoices ranging from $10-$13 each, all in quick succession of one another. However, I wasn’t using Claude. I was away from my laptop entirely and was out sailing with my parents back home in San Diego.
When I checked my usage dashboard, it showed my session at 100% despite no activity. My Claude Code session history showed two tiny sessions from March 5 totaling under 7KB (no sessions on March 3 or March 4.) Nothing that would explain $180 in Extra Usage charges.
This isn’t just me. Other Max plan users have reported the same issue. There are numerous GitHub issues about it (e.g. claude-code#29289 and claude-code#24727), and posts on r/ClaudeCode describing the exact same behavior: usage meters showing incorrect values and Extra Usage charges piling up erroneously.
On March 7, I sent a detailed email to Anthropic support laying out the situation with all the evidence above. Within two minutes, I received a response… from “Fin AI Agent, Anthropic’s AI Agent.” The AI agent told me to go through an in-app refund request flow. Sadly, this refund pipeline is only applicable for subscriptions, and not for Extra Usage charges. I also wanted to confirm with a human on exactly what went wrong rather than just getting a refund and calling it a day.
So, naturally, I replied asking to speak to a human. The response:
Thank you for reaching out to Anthropic Support. We’ve received your request for assistance.
While we review your request, you can visit our Help Center and API documentation for self-service troubleshooting. A member of our team will be with you as soon as we can.
That was March 7. I followed up on March 17. No response. I followed up again on March 25. No response. I followed up again today, April 8, over a month later. Still nothing.
Anthropic is an AI company that builds one of the most capable AI assistants in the world. Their support system is a Fin AI chatbot that can’t actually help you, and there is seemingly no human behind it. I don’t have a problem with AI-assisted support, though I do have a problem with AI-only support that serves as a wall between customers and anyone who can actually resolve their issue.
...
Read the original on nickvecchioni.github.io »
To add this web app to your iOS home screen tap the share button and select "Add to the Home Screen".
10HN is also available as an iOS App
If you visit 10HN only rarely, check out the the best articles from the past week.
If you like 10HN please leave feedback and share
Visit pancik.com for more.