Andrew Kesterson

"Love God. Live Righteously. Die Well."
Source Code || LinkedIn
29 Posts 9 Categories 0 Tags
Categories
Books 14
Technology 11
Faith 6
Outdoors 1
Leadership 8
Current-Events 5
Philosophy 5
History 1
Liberal-Education 1
hot tags

# News - 2026 - Week 1

2026-01-08 Technology Current Events 3k words

Here are my thoughts on the news this week. It’s worth what you paid for it.

## AOSP twice yearly releases? Calm down, F/OSS advocates.

AndroidAuthority reports that Google will only be releasing the source code for AOSP, Android Open Source Platform, twice a year.

> “Effective in 2026, to align with our trunk-stable development model and ensure platform stability for the ecosystem, we will publish source code to AOSP in Q2 and Q4. For building and contributing to AOSP, we recommend utilizing android-latest-release instead of aosp-main. The aosp-latest-release manifest branch will always reference the most recent release pushed to AOSP. For more information, see Changes to AOSP.”

Reactions on slashdot and other places are typically upset. “Android isn’t open source”, “Time to find an alternative”, etc. While I don’t necessarily disagree with some of these commenters, I think they’re misunderstanding (or choosing to distort) what’s happening here. They feel like Google is doing the Evil thing again (which they are frequently guilty of) and withholding source code from certain releases that fall between the twice yearly releases. They see this as a stepping stone towards Android becoming closed source. I’m inclined to read the announcement at face value, and believe what it says: They’re transitioning to twice yearly releases, and asking everyone to start doing the same, and are aligning their source releases with that process. I don’t really see the problem with that.

Now whether or not Android is truly open source is an entirely different (and nuanced) question, and some of us do feel a certain kind of way about that. But this announcement is a bit of a nothing burger.

## Everything old is new again: the return of the keyboard computer

Remember the home computers of the 1980s? Remember how their form factor tended to be that of a big bulky keyboard you plugged in to a monitor (or, if you were spendy, a special monitor)? Commodore VIC-20, 64 and 128, ZX Spectrum and Spectrum +2, Amiga 500, Amstad CPC 464, BBC Micro, etc. This form factor essentially defined personal computers in the late 1970s and early 1980s.

Now, we see this form factor as a quaint reminder of a simpler time, and there is even some nostalgia around it. The Commodore 64 has always had a really strong cult following, and with the recent acquisition of Commodore by (essentially) the fan community itself, there is even a new Commodore computer being released for the first time in decades, the Commodore Ultimate - and you can guess the form factor on this bad boy. Thus far, I have resisted the completely nonsensical urge to buy one of these things and put it on my desk. We’ll see how long the $350 price tag helps me keep such a level headed position.

I like to say “everything old is new again”, because we tend to live in a circle of trends, and things keep coming back around. Apparently it is the time of the keyboard computer once again, because - believe it or not! - there is a brand new keyboard form factor PC for the enterprise. Yes, you read that right, HP’s enterprise PC lineup now includes a keyboard PC, the HP EliteBoard G1a.

The Register ran a story about this little curiosity recently, and they note that it is intended to fill a very specific niche: for enterprises which use “hot desks” or “hotel cubes” where an employee might pop in and work for a day, but they may not use the same hot desk or hotel cube every day, so leaving a permanent workstation doesn’t make sense. I guess that HP also assumes A) these workers do not work when away from their desk (a blessed expectation in this modern age), or B) these enterprises are going to choose not to simply issue laptops to these workers.

Personally, it’s charming, and I love to see it. But as a former enterprise IT manager, it’s a baffling choice. Issuing laptops seems like the smarter thing to do as an enterprise - your IT team is probably already issuing them, already storing them, already has a support contract for keeping them running, already has spare parts, your workforce is already using them, and you don’t have to equip desks with separate monitors and mice. Mice are going to get lost. Monitors are going to get moved away from the hotel cube/hot desk when someone’s “give me a second monitor” IT ticket takes too long to fulfill. And the workers who are issued these things are absolutely not going to be inclined to open them and work from home, let alone a coffee shop. You’d better have very strict expectations that these workers only do work in the hot desk, at the office.

And if that’s your expectation …. why not just put a frickin desktop there? I don’t get it.

## There is nothing new under the sun, AI just does it faster

This one probably should’ve gotten its own post.

The New Stack ran a story recently about how traditional methods of monitoring and reacting to events in your IT infrastructure are out of date in the age of AI. Specifically they mention dashboards, but that’s not what they’re actually talking about. They’re talking about having humans in the incident response loop.

In the article, they make the point that the traditional incident response workflow is slow. Consider:

1. An event occurs somewhere in your IT infrastructure or application
2. Some sensor detects this event
3. Some sensor sends the event to a centralized tool for monitoring such events
4. The centralized tool slaps a timestamp on the event and aggregates it with everything else
5. Something notices that event, and decides it needs to alert a human. Incident Response procedures for your organization begins here.
6. A human receives the alert, reads it with their eyeballs, and process it with their smartmeat.
7. That human consults with other humans, and they combine their smartmeat about what to do about the event
8. Some human (maybe the same human) uses their fingermeat to twiddle some bits, reacting to the event, and hopefully resolving it. If not, GOTO 3.

The argument in the article is that AI tools make your dashboards obsolete because steps 6, 7, and 8 of the process can now be automated by AI, and executed faster than a human team could ever hope to do so. And, yes, that’s true, automation can react faster than humans. But that’s no secret to those of us who have actually been in this industry for more than a few days, and we don’t need AI to do it.

Anyone hear of “event driven architecture”? This is a very old idea that predates AI. The idea is that you have an architecture where decoupled systems don’t really know about each other’s guts, and they just respond to events occurring, with those events coming over standardized interfaces. It’s a good idea. It’s also been coupled with incident response by DevOps folks for nearly as long to automate systems in response to bad things happening.

The AI driven workflows that the New Stack article refers to are really no different than what your DevOps/DevSecOps/NoOps/SRE team has been doing alrady. The difference is that these flows:

1. Probably use some amount of automatic introspection (AI tools inspecting the output of a set of components to determine how to parse that output, and classify it into normal and error conditions)
2. Probably use some amount of automatic code generation (AI tools generating code that should work to reset a given system to a normal state when an error condition is detected)
3. Probably replace humans in steps 6, 7, 8 of the previous flow with multiple AI agents that can reach consensus (according to business rules codified by humans) about when it is time to execute the code from item #2

Which I think is just hilarious, because it flies in the face of what we got told by the enterprise for so long. Your human automation teams have been capable of delivering this functionality to you all along - in fact we’ve been BEGGING you to let us write the software and turn it on, and you have continuously refused. And the reasoning is always the same. “You want to automatically change the production system in response to a change? We aren’t comfortable with that. A human must be in charge of deciding to throw that lever.” And even when the business may have been comfortable with allowing automation to do it, frequently change controls were in place that prevented such activities, often in response to regulatory or legal requirements that prevented the automation from doing the needful.

So how is this suddenly okay now that it’s AI doing it? AI is less deterministic, less idempotent, less comprehensible, and less predictable. And yet we expect enterprises to allow AI to have the keys to prod when the deterministic, idempotent, comprehensible, utterly predictable code from their automation teams, has been refused for so long?

Whatever. Do what you want, man. But when your agents hallucinate something and fire when they shouldn’t, or don’t fire when they should, your SRE team is gonna have a bash script that can fix your problems. This problem, and the solution, is not new, you’re just finding a new, faster, and arguably worse way to handle it.

Get off my lawn.

## Sociopaths and hardcore gamers in civil service

Slashdot reports on a Chinese paper thusly

> A new working paper from researchers at the University of Hong Kong has found that Chinese graduate students who plagiarized more heavily in their master’s theses were significantly more likely to pursue careers in the civil service and to climb the ranks faster once inside. John Liu and co-authors analyzed 6 million dissertations from CNKI, a Chinese academic repository, and cross-referenced them against public records of civil-service exam-takers to identify 120,000 civil servants and their academic work. Those who entered the public sector had plagiarism scores 15.6% above average. Customs and tax officials fared worst – their scores ran 25% and 26% higher than private-sector peers respectively. Within the civil service, those who plagiarized more were promoted 9% faster during the first five years of their careers. The researchers validated their plagiarism metric through an experiment involving 443 job applicants who were asked to roll dice for rewards without monitoring. Those who had plagiarized more also reported improbably high rolls.

This shouldn’t really surprise anyone who has spent any time working in civil service - whether in government, police, fire, or EMS. For whatever reason, these positions tend to attract a certain kind of people who tend to either be the absolute best kind of person, or the absolute worst kind of person. (And sometimes they are both, unfortunately.) We also know that civil service somehow tends to wind up promoting and rewarding nepotists and sociopaths, because they’ve learned how to play the game, and to rig it. What’s worse is that, often times, they are doing it from a place of positive moral justification - “the ends justify the means”. And history has shown us, over and over, why that’s a very dangerous line to walk, and we shouldn’t tolerate it. But we do, because ultimately, we need results from the people in these positions. And we are often willing to either look the other way, or simply not look too hard into the details, when someone is getting results.

Sociopaths are great at getting results. They also scare the hell out of us. But sociopaths are great at understanding the rules, and maximizing their ability to operate in those rules for their own benefit. They learn what people expect to see, and they use their chameleon superpowers to show that on the outside, while still getting what they want through other less visible means. Cheating is fine, as long as the social expectations are met on the outside. Dirty deeds are fine, as long as the socially acceptable outcome is achieved, and nobody can really see how that sausage is getting made. The ends justify the means.

Back in the early 2000s, The Escapist was still being published as a zine. (Personally I miss it.) It was released as a PDF with pages you would turn and everything (anyone remember PDF readers that animated pages turning and made the paper shuffling noise? I do, and I don’t miss that at all.) One article from Volume 1 Issue 22 struck me as being so damned good that I’ve saved a copy of that on my NAS ever since, and every once in a while, something happens that makes me bring it up again.

Escapist Volume 1 Issue 22 is still available on the Internet Archive as of the time of this writing. Just in case, I also have a local copy of it attached to this article. In this issue, John Tynes wrote an article called “The Contrarian: Why We Fight”. In the article, he explains why hardcore gamers so often tended to gravitate towards games about war and conquest with violent themes. It’s a really great article that says more about human psychology than maybe the author meant to say, and I recommend reading it. But when thinking of sociopaths in civil service, I’m remindeded of this part of the article:

> I believe humans have a deep longing for authority, to possess it or to obey it. It is tempered by our empathy, our ability to view another’s situation and project it onto ourselves. But our games know nothing of empathy. We optimize our play to reach the solution in the most direct way possible. When you watch a video of someone completing the entirety of Half-Life in 45 minutes, you have to think: That guy could make the trains run on time. There is no pause for conversation or exploration. There is merely the fanatical implementation of an optimal result.

> A final solution.

> Somebody has to save the world. And that means somebody has to rule it. We gamers have had the training. We’ve learned the mindset. We know the score. We are efficient, deadly, methodical. If only we were in charge – then, oh then, we could show the world how much we care about it. We could wrap our arms around all that suffering and whisper over our speed runs, our fervent smashing of crates, the countless times we’ve saved them all already. And if any of them talked back or questioned our wisdom we could show them exactly what we’ve learned.

> Press the button.

## Goodbye APIs, hello AI interfaces

The New Stack ran a story recently about how data management is going to change in 2026, for a bunch of reasons. In the article, there was an interesting claim made about how systems will interact in the future.

> Such collaboration will range the gamut of data-centric resources, from federation infrastructure to traditional databases supporting different modalities, vector embeddings, and protocols such as MCP, Agent-User Interaction (AG-UI), and Agent to UI (A2UI). Users will no longer look for a single hyperscaler or vendor offering these things, but rather “the ability to plug and play,” commented Yugabyte CEO Karthik Ranganathan. “Just saying one thing will do it all is like saying we know the answer to a question even before you’ve asked it.”

Imagine the horror of your only programmatic interface to a given system being, not a well defined API, with defined and structured inputs and outputs on a contract with a schema, but an agentic interface that you talk to, in awful natural language, and hope it does the right thing.

Sweet Jesus. And developers think they have it bad now.

## Quantum computing, complexity, and comprehension

I am not a quantum computing expert, but a recent article about wires and qubits got me thinking.

> “If you think about how the semiconducting industry evolved, you’ve got chips in your phone and your laptop with billions of transistors. There’s absolutely not billions of control lines that go down to the chip,”

It’s been said that you haven’t achieved mastery of something until you can explain it to a non-technical person outside of your field. It’s also been said that genius is the ability to reduce the complex to the simple.

The shrinking number of control lines on a chip represent an increasing understanding of the utility of the chip, thereby allowing us to present a more narrow interface to the device. In the early days there was a 1:1 number of lines on a CPU for memory address, data, etc. An 8 bit machine had 8 address lines and 8 data lines. Over time we’ve been able to improve performance and simplify the API on these components to reduce the number of directly exposed items. Even in the 80s, computers did not have instructions for referencing individual bits in memory, they dealt only in bytes (logical operations not excepted). As our understanding of the machine and its use cases proceeded, the interfaces got smaller and simpler.

On a long enough timeline Quantum computing will, assuming the technology has sufficient utility to drive continued development and refinement, reach the point where binary von neumann general purpose computers reached in the 80s. When that happens, I wonder what the languages and tooling to communicate with them is going to look like, as the interfaces (once standardized) will undoubtedly look nothing like what we’re used to.

Just as one example, the idea of a “General Purpose Computer” is so intrinsically tied to our idea of a “Computer” that Wikipedia has no separate article for a General Purpose Computer. Quantum Computing is going to be a whole new frontier.

Recent Posts
2026-05-27
News-2026-Week-2
2026-05-15
Devlog Entry
2026-02-23
Why Firefighting
2026-02-09
News 2026 Week 5