It should be fairly obvious to anyone who's been paying attention to the tech news that many companies are pushing the adoption of "AI" (large language models) among their own employees--from software developers to management--and the push is coming from the top down, as C-suite executives order their staff to use AI, Or Else. But we know that LLMs reduce programmer productivity-- one major study showed that "developers believed that using AI tools helped them perform 20% faster -- but they actually worked 19% slower." (Source.)

Another recent study found that 87% of executives are using AI on the job, compared with just 27% of employees: "AI adoption varies by seniority, with 87% of executives using it on the job, compared with 57% of managers and 27% of employees. It also finds that executives are 45% more likely to use the technology on the job than Gen Zers, the youngest members of today's workforce and the first generation to have grown up with the internet.

"The findings are based on a survey of roughly 7,000 professionals age 18 and older who work in the US, the UK, Australia, Canada, Germany, and New Zealand. It was commissioned by HR software company Dayforce and conducted online from July 22 to August 6."

Why are executives pushing the use of new and highly questionable tools on their subordinates, even when they reduce productivity?

I speculate that to understand this disconnect, you need to look at what executives do.

Gordon Moore, long-time co-founder and CEO of Intel, explained how he saw the CEO's job in his book on management: a CEO is a tie-breaker. Effective enterprises delegate decision making to the lowest level possible, because obviously decisions should be made by the people most closely involved in the work. But if a dispute arises, for example between two business units disagreeing on which of two projects to assign scarce resources to, the two units need to consult a higher level management team about where their projects fit into the enterprise's priorities. Then the argument can be settled ... or not, in which case it propagates up through the layers of the management tree until it lands in the CEO's in-tray. At which point, the buck can no longer be passed on and someone (the CEO) has to make a ruling.

So a lot of a CEO's job, aside from leading on strategic policy, is to arbitrate between conflicting sides in an argument. They're a referee, or maybe a judge.

Now, today's LLMs are not intelligent. But they're very good at generating plausible-sounding arguments, because they're language models. If you ask an LLM a question it does not answer the question, but it uses its probabilistic model of language to generate something that closely resembles the semantic structure of an answer.

LLMs are effectively optimized for bamboozling CEOs into mistaking them for intelligent activity, rather than autocomplete on steroids. And so the corporate leaders extrapolate from their own experience to that of their employees, and assume that anyone not sprinkling magic AI pixie dust on their work is obviously a dirty slacker or a luddite.

(And this false optimization serves the purposes of the AI companies very well indeed because CEOs make the big ticket buying decisions, and internally all corporations ultimately turn out to be Stalinist command economies.)

Anyway, this is my hypothesis: we're seeing an insane push for LLM adoption in all lines of work, however inappropriate, because they directly exploit a cognitive bias to which senior management is vulnerable.

How many times does it take to make something a tradition? Well, this is our third installment of Christmas in the Server Room, which seems pretty traditional at this point. Someday we'll run out of Christmas movies that I've watched, and then I'll need to start watching them intentionally. I'm dreading having to sit through some adaptation of the Christmas Shoes or whatever.

In any case, we're going to rate Christmas movies on their accuracy of representing the experience of IT workers. One 💾 grants it the realism of that movie where Adam Sandler fights Pac-Man, while 💾💾💾💾💾 tells us that it's as realistic as an instructional video about the Turbo-Encabulator.

Home Alone

A Rube-Goldberg-quality series of misunderstandings and coincidences lead to bratty child Kevin being left… home alone through the holidays, defending his home from burglars, using a series of improvised, Rube-Golberg-quality booby traps, that escalate to cartoonish violence. The important lesson, however, is that the true meaning of Christmas is family.

Like most cybersecurity teams, Kevin is under-resourced, defending an incredibly vulnerable system from attackers. His MacGyvered together collection of countermeasures all work, in the film, but none of them actually address the true vulnerabilities and could all be easily bypassed by a competent attacker.

Kevin's traps are very much temporary solutions. But when temporary solutions become permanent, awful things can happen.

Rating: 💾💾

Santa Claus

This one will be familiar to any MST3k fans. Santa Claus runs a North Pole factory on child labor and whimsical inventions. Oh, also, his North Pole factory is in space. On Christmas Eve, as he tours the world to reward good boys and girls, Satan sends a demon to tempt children into mild naughtiness. Once again, the true meaning of Christmas is being with those you love, unless you're one of the children in Santa's workshop. Those kids are working on Christmas.

When things get truly dire for Santa, the children junior engineers staffing his workshop recognize that they can't manage the problem, so they fetch Merlin, the original greybeard. Yes, Merlin works for Santa, which implies that Santa and King Arthur may have met, and honestly, I'd rather watch that team-up movie. In any case, "terrified juniors clinging to a senior" is actually not very realistic. These days, the kids would just ask ChatGPT what to do, and end up putting glue on pizza.

Rating: 💾

Violent Night

What happens when we combine Santa Claus with Home Alone? We get the ultimate Santa-does-a-Die-Hard movie, Violent Night. Beverly D'Angelo plays Dick Cheney, an evil matriarch who runs a private military contractor and has stolen millions from US military operations abroad. Even more evil criminals take her family hostage to steal those millions. How are the criminals more evil than Dick Cheney? They're not only thieves, they also hate Christmas!

The family is all horrible people, except for Trudy, the young girl who has been good all year and still believes in Santa Claus. And that means Santa is coming to town. With grenades and sledge hammers and machine guns. The movie also features one of the "best" uses of "Santa uses Christmas magic to go up the chimney" at the end.

The entire villain plan is built around breaking into a super-protected electronic safe, and without spoiling too much, there's a twist in the film where someone has already broken into the safe, which makes one wonder how stupid the villains are (pretty stupid, actually). Also, while I understand the need for narrative convenience (and the Die Hard reference), the idea that the encrypted radios used by the evil villains, and the walkie talkie toy Trudy has to talk to Santa can actually operate on the same bands is… a bit of a stretch. RF bands and allocations and where and when you can use encryption is a whole thing.

Rating: 💾💾

Christmas Card from a Hooker in Minneapolis - Tom Waits

A sex worker in Minneapolis sends a Christmas card to Charlie, presumably a former client or supervisor of hers, updating him on her life. With each verse her life seems to be getting better- until the final verse, which reveals it's all been a charade and she needs help. Like most Tom Waits songs, it's the story of the kind of person who is pushed to the fringes of society, tragic but hopeful, and loaded with empathy.

I've recently been doing a job search of my own, and part of that has been "what dates did you work at $place?" and "give us some references?" and I realized that I'm terrible about keeping tabs on these kinds of things. The idea that I could send a Christmas card to a former client from years ago is absurd. Then again, how do we even know these cards get to Charlie? We just know that she wrote them, not that Charlie got them.

Rating: 🫦🫦🫦

I Am the Antichrist - The Dream Eaters

Two songs this year? Are there even any rules anymore? The lord of the damned has a poppy intro track. I suppose this shouldn't go on a Christmas list, because it likely belongs at the antipodal part of the year. Y'know. Being the Antichrist and all.

Rating: 🪩🪩🪩🪩🪩

Star Trek II: The Wrath of Khan

An aging Captain Kirk is haunted by a mistake of his past: Khan Noonien Singh is back for revenge. This "Horatio Hornblower in Space" riff on Trek is packed with themes: revenge, sacrifice, the frightening power of technology, and an object lesson on why you shouldn't put things in your ears. It also proves that the best, most exciting space battles aren't swooping, wooshing, pew pew pews, but tense games of cat-and-mouse.

As for its Christmas connections? What greater gift can Spock give to his crew but himself? His ultimate sacrifice is what ties the movie together, and of course, it means we got this incredible Christmas ornament out of it. Of all the Christmas spirits I have ever known, his was the most human.

The whole prefix-code thing is a pretty incredible security blunder. A remote back door into any Starfleet vessel, guarded only by a 5 digit code? A 5 digit code that's stored in a database on every other starship? So if an enemy captures one vessel, they can thwart the entire fleet unless everyone updates their prefix code? That's a terribly security posture! And incredibly realistic! That is likely what the future will look like. So I guess that's a credible security blunder, if we're being pedantic.

I bet they store the passwords in plain text too!

Rating: 💾💾💾💾💾

[Advertisement] Keep the plebs out of prod. Restrict NuGet feed privileges with ProGet. Learn more.

Author: Daniel Miltz They live remote, because living remote they remember everything. The neighborhood leans inward like old men listening, and the people hold faces that don’t blink. During the day, the ghosts come out wearing the habits they died in: a man still counting coins that lost their value in another country, a woman […]

The post The Ghosts of the City appeared first on 365tomorrows.

Review: Machine, by Elizabeth Bear

Machine is a far-future space opera. It is a loose sequel to Ancestral Night, but you do not have to remember the first book to enjoy this book and they have only a couple of secondary characters in common. There are passing spoilers for Ancestral Night in the story, though, if you care.

Dr. Brookllyn Jens is a rescue paramedic on Synarche Medical Vessel I Race To Seek the Living. That means she goes into dangerous situations to get you out of them, patches you up enough to not die, and brings you to doctors who can do the slower and more time-consuming work. She was previously a cop (well, Judiciary, which in this universe is mostly the same thing) and then found that medicine, and specifically the flagship Synarche hospital Core General, was the institution in all the universe that she believed in the most.

As Machine opens, Jens is boarding the Big Rock Candy Mountain, a generation ship launched from Earth during the bad era before right-minding and joining the Synarche, back when it looked like humanity on Earth wouldn't survive. Big Rock Candy Mountain was discovered by accident in the wrong place, going faster than it was supposed to be going and not responding to hails. The Synarche ship that first discovered and docked with it is also mysteriously silent. It's the job of Jens and her colleagues to get on board, see if anyone is still alive, and rescue them if possible.

What they find is a corpse and a disturbingly servile early AI guarding a whole lot of people frozen in primitive cryobeds, along with odd artificial machinery that seems to be controlled by the AI. Or possibly controlling the AI.

Jens assumes her job will be complete once she gets the cryobeds and the AI back to Core General where both the humans and the AI can be treated by appropriate doctors. Jens is very wrong.

Machine is Elizabeth Bear's version of a James White Sector General novel. If one reads this book without any prior knowledge, the way that I did, you may not realize this until the characters make it to Core General, but then it becomes obvious to anyone who has read White's series. Most of the standard Sector General elements are here: A vast space station with rings at different gravity levels and atmospheres, a baffling array of species, and the ability to load other people's personalities into your head to treat other species at the cost of discomfort and body dysmorphia. There's a gruff supervisor, a fragile alien doctor, and a whole lot of idealistic and well-meaning people working around complex interspecies differences. Sadly, Bear does drop White's entertainingly oversimplified species classification codes; this is the correct call for suspension of disbelief, but I kind of missed them.

I thoroughly enjoy the idea of the Sector General series, so I was delighted by an updated version that drops the sexism and the doctor/nurse hierarchy and adds AIs, doctors for AIs, and a more complicated political structure. The hospital is even run by a sentient tree, which is an inspired choice.

Bear, of course, doesn't settle for a relatively simple James White problem-solving plot. There are interlocking, layered problems here, medical and political, immediate and structural, that unwind in ways that I found satisfyingly twisty. As with Ancestral Night, Bear has some complex points to make about morality. I think that aspect of the story was a bit less convincing than Ancestral Night, in part because some of the characters use rather bizarre tactics (although I will grant they are the sort of bizarre tactics that I could imagine would be used by well-meaning people using who didn't think through all of the possible consequences). I enjoyed the ethical dilemmas here, but they didn't grab me the way that Ancestral Night did. The setting, though, is even better: An interspecies hospital was a brilliant setting when James White used it, and it continues to be a brilliant setting in Bear's hands.

It's also worth mentioning that Jens has a chronic inflammatory disease and uses an exoskeleton for mobility, and (as much as I can judge while not being disabled myself) everything about this aspect of the character was excellent. It's rare to see characters with meaningful disabilities in far-future science fiction. When present at all, they're usually treated like Geordi's sight: something little different than the differential abilities of the various aliens, or even a backdoor advantage. Jens has a true, meaningful disability that she has to manage and that causes a constant cognitive drain, and the treatment of her assistive device is complex and nuanced in a way that I found thoughtful and satisfying.

The one structural complaint that I will make is that Jens is an astonishingly talkative first-person protagonist, particularly for an Elizabeth Bear novel. This is still better than being inscrutable, but she is prone to such extended philosophical digressions or infodumps in the middle of a scene that I found myself wishing she'd get on with it already in a few places. This provides good characterization, in the sense that the reader certainly gets inside Jens's head, but I think Bear didn't get the balance quite right.

That complaint aside, this was very fun, and I am certainly going to keep reading this series. Recommended, particularly if you like James White, or want to see why other people do.

The most important thing in the universe is not, it turns out, a single, objective truth. It's not a hospital whose ideals you love, that treats all comers. It's not a lover; it's not a job. It's not friends and teammates.

It's not even a child that rarely writes me back, and to be honest I probably earned that. I could have been there for her. I didn't know how to be there for anybody, though. Not even for me.

The most important thing in the universe, it turns out, is a complex of subjective and individual approximations. Of tries and fails. Of ideals, and things we do to try to get close to those ideals.

It's who we are when nobody is looking.

Followed by The Folded Sky.

Rating: 8 out of 10

So: I've had surgery on one eye, and have new glasses to tide me over while the cataract in my other eye worsens enough to require surgery (I'm on the low priority waiting list in the meantime). And I'm about to head off for a fortnight of vacation time, mostly in Germany (which has the best Christmas markets) before coming home in mid-December and getting down to work on the final draft of Starter Pack.

Starter Pack is a book I wrote on spec--without a contracted publisher--this summer when Ghost Engine just got a bit too much. It's a spin-off of Ghost Engine, which started out as a joke mashup of two genres: "what if ... The Stainless Steel Rat got Isekai'd?" Nobody's writing the Rat these days, which I feel is a Mistake, so I decided to remedy it. This is my own take on the ideas, not a copy of Harry Harrison's late 1950s original, so it's a bit different, but it's mostly there now and it works as its own thing. Meanwhile, my agent read it and made some really good suggestions for how to make it more commercial, and "more commercial" is what pays the bills so I'm all on board with that. Especially as it's not sold yet.

Ghost Engine is still in progress: I hit a wall and needed to rethink the ending, again. But at least I am writing: having working binocular vision is a sadly underrated luxury--at least, it's underrated until you have to do without it for a few months. Along the way, Ghost Engine required me to come up with a new story setting in which there is no general AI, no superintelligent AI, no mind uploading to non-biological substrates, and above all no singularity--but our descendants have gone interstellar in a big way thanks to that One Neat Magictech Trick I trialed in my novella Palimpsest back in 2009. (Yes, Ghost Engine and Starter Pack are both set very loosely in the same continuum as Palimpsest. Or maybe it's more accurate to say that Palimpsest is to these new novels what A Colder War was to the Laundry Files.) So I finally got back to writing far future wide screen space opera, even if you aren't going to be able to read any of it for at least a year.

Why do this, though?

Bluntly: I needed to change course. After the US election outcome of November 2024 it was pretty clear that we were in for a very bumpy ride over the next few years. The lunatics have taken over the asylum and the economy is teetering on the edge of a very steep precipice. It's not just the over-hyped AI bubble that's propping up the US tech sector and global stock markets--that would be bad enough, but macro policy is being set by feces-hurling baboons and it really looks as if Trump is willing to invade Central America as a distraction gambit. All the world's a Reality TV show right now, and Reality TV is all about indulging our worst collective instincts.

It's too depressing to contemplate writing more Laundry Files stories; I get email from people who read the New Management as a happy, escapist fantasy these days because we've got a bunch of competent people battling to hold the centre together, under the aegis of a horrific ancient evil who is nevertheless a competent ancient evil. Unfortunately the ancient evil wins, and that's just not something I want to explore further right now.

I'm a popular entertainer and it seems to me that in bad times people want entertainments that take them out of their current quagmire and offers them escape, or at least gratuitous adventures with a side-order of humour. I'm not much of an optimist about our short-term future (I don't expect to survive long enough to see the light at the end of the tunnel) so I can't really write solarpunk or hopepunk utopias, but I can write space operas in which absolutely horrible people are viciously mocked and my new protagonists can at least hope for a happy ending.

Upcoming Events

In the new year, I've got three SF conventions planned already: Iridescence (Eastercon 2026), Birmingham UK, 3-6 April: Satellite 9, Glasgow, 22-24 May: and Metropol con Berlin (Eurocon 2026), Berlin, 2-5 July. I'm also going to try and set up a reading/signing/book launch for The Regicide Report in Edinburgh; more here if I manage it.

As during previous Republican presidencies in the USA it does not feel safe to visit that country, so I won't be attending the 2026 worldcon. However the 2027 world science fiction convention will almost certainly take place in Montreal, which is in North America but not part of Trumpistan, so (health and budget permitting) I'll try to make it there.

(Assuming we've still got a habitable planet and a working economy, which kind of presupposes the POTUS isn't biting the heads off live chickens or rogering a plush sofa in the Oval Office, of course, neither of which can be taken for granted this century.)

Trixie ships Gimp 3.0.4 and the 3.x series has gotten incompatible to XSane, the common frontend for scanners on Linux.

Hence the maintainer, Jörg Frings-Fürst, has disabled the Gimp integration temporarily in response to a Debian bug #1088080.

There seems to be no tracking bug for getting the functionality back but people have been commenting on Debian bug #993293 as that is ... loosely related .

There are two options to get the Scanning functionality back in Trixie until this is properly resolved by an updated XSane in Debian (e.g. via trixie-backports):

Lee Yingtong Li (RunasSudo) has created a Python script that calls XSane as a cli application and published it at https://yingtongli.me/git/gimp-xsanecli/. This worked okish for me but needed me to find the scan in /tmp/ a number of times. This is a good stop-gap script if you need to scan from Gimp $now and look for a quick solution.

Upstream has completed the necessary steps to get XSane working as a Gimp 3.x plugin at https://gitlab.com/sane-project/frontend/xsane. Unfortunately compiling this is a bit involved but I made a version that can be dropped into /usr/local/bin or $HOME/bin and works alongside Gimp and the system-installed XSane.

So:

1. sudo apt install gimp xsane
2. Download xsane-1.0.0-fit-003 (752kB, AMD64 executable for Trixie) and place it in /usr/local/bin (as root)
3. sha256sum /usr/local/bin/xsane-1.0.0-fit-003
   # result needs to be af04c1a83c41cd2e48e82d04b6017ee0b29d555390ca706e4603378b401e91b2
4. sudo chmod +x /usr/local/bin/xsane-1.0.0-fit-003
5. # Link the executable into the Gimp plugin directory as the user running Gimp:
   mkdir -p $HOME/.config/GIMP/3.0/plug-ins/xsane/
ln -s /usr/local/bin/xsane-1.0.0-fit-003 $HOME/.config/GIMP/3.0/plug-ins/xsane/
6. Restart Gimp
7. Scan from Gimp via File → Create → Acquire → XSane

The source code for the xsane executable above is available under GPL-2 at https://gitlab.com/sane-project/frontend/xsane/-/tree/c5ac0d921606309169067041931e3b0c73436f00. This points to the last upstream commit from 27. September 2025 at the time of writing this blog article.

The holiday season is an opportunity for employers to show their appreciation for their staff. Lavish parties, extra time off, whatever. Even some of the worst employers I've had could put together a decent Christmas party.

But that doesn't mean they all go right.

For example, Mike S worked for one of those early music streaming startups. One year, the company booked a Russian restaurant in the neighborhood for the party. The restaurant was a gigantic space, with a ground level and a balcony level, but the company was only 70 people, so the company perhaps overbought for the party. Everyone stuffed themselves on appetizers and when the main course came out, it ended up as extremely fishy smelling leftovers in the office kitchen.

Two years later, they booked a party at the same place. But lessons were learned: they only booked the balcony. This meant the ground floor was free for someone else to book, and someone else did. Another party booked the ground floor, and they booked an extremely loud Russian pop band to play it.

The band was deafening and took absolutely no breaks. And while the previous time, everyone stuffed themselves on appetizers, this time there were barely any. But there also wasn't much main course coming out either. By 10PM, Mike was starving and deaf, so he left. At about 10:15, the food came out. But by then, most of the staff had left, which meant once again, the office kitchen got stuffed with very fishy smelling leftovers.

There was not a third Russian party.

Rachel went to her partner's holiday party. This large tech company was notorious for spending loads of money on the party, and they certainly booked a fairly amazing venue for it. But there was confusion with the catering order; while the company shelled out for a full buffet, the caterer decided to only provide finger foods, circulated through the party by waiters carrying plates. By 9PM, the employees had figured out where the kitchen was and were lying in ambush for the waiters. The small plates of chicken tenders and crab rangoons and spring rolls never made it more than two or three steps out of the kitchen before they were picked clean.

At least the company learned that lesson and stopped using that caterer. Though I think some of the wait staff may have been permanently traumatized by the corporate party version of The Most Dangerous Game.

But you know, not everything is about holiday parties, or days off. Companies have plenty of other ways to make their staff happy. Little benefits and perks can go a long way. Just take a page from Doug B's company, which put this sign on the badge reader:

Christmas will be a casual dress day.

I hear Doug's co-worker Bob Cratchit is going through some rough times.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.

Author: Keisha Hartley Amara’s head knocked against the cold car window, jolting her awake. Her fingers were numb from clutching the long black case on her lap. The Uber driver sped down the winding path unbothered by the rain. Ahead, the dark spires of her grandmother’s home jutted above the crest of the driveway hill […]

The post Alone appeared first on 365tomorrows.

This is pretty scary:

Urban VPN Proxy targets conversations across ten AI platforms: ChatGPT, Claude, Gemini, Microsoft Copilot, Perplexity, DeepSeek, Grok (xAI), Meta AI.

For each platform, the extension includes a dedicated “executor” script designed to intercept and capture conversations. The harvesting is enabled by default through hardcoded flags in the extension’s configuration.

There is no user-facing toggle to disable this. The only way to stop the data collection is to uninstall the extension entirely.

[…]

The data collection operates independently of the VPN functionality. Whether the VPN is connected or not, the harvesting runs continuously in the background.

[…]

What gets captured:

• Every prompt you send to the AI
  Every response you receive

• Conversation identifiers and timestamps
• Session metadata
• The specific AI platform and model used

Boing Boing post.

My Remarkable tablet, displaying my 2025 planner.

During my PhD, on a sunny summer’s day, I copied some papers to read onto an iPad and cycled down to an outdoor cafe next to the beach. armed with a coffee and an ice cream, I sat and enjoyed the warmth. The only problem was that due to the bright sunlight, I couldn’t see a damn thing.

In 2021 I decided to take the plunge and buy the Remarkable 2 that has been heavily advertised at the time. Over the next four or so years, I made good use of it to read papers; read drafts of my own papers and chapters; read a small number of technical books; use as a daily planner; take meeting notes for work, PhD and later, personal matters.

I didn’t buy the remarkable stylus or folio cover instead opting for a (at the time, slightly cheaper) LAMY AL-star EMR. And a fantastic fabric sleeve cover from Emmerson Gray.

I installed a hack which let me use the Lamy’s button to activate an eraser and also added a bunch of other tweaks. I wouldn’t recommend that specific hack anymore as there are safer alternatives (personally untested, but e.g. https://github.com/isaacwisdom/RemarkableLamyEraser)

Pros: the writing experience is unparalleled. Excellent. I enjoy writing with fountain pens on good paper but that experience comes with inky fingers, dried up nibs, and a growing pile of paper notebooks. The remarkable is very nearly as good without those drawbacks.

Cons: lower contrast than black on white paper and no built in illumination. It needs good light to read. Almost the opposite problem to the iPad! I’ve tried a limited number of external clip on lights but nothing is frictionless to use.

The traditional two-column, wide margin formatting for academic papers is a bad fit for the remarkable’s size (just as it is for computer display sizes. Really is it good for anything people use anymore?). You can pinch to zoom which is OK, or pre-process papers (with e.g. Briss) to reframe them to be more suitable but that’s laborious.

The newer model, the Remarkable Paper Pro, might address both those issues: its bigger; has illumination and has also added colour which would be a nice to have. It’s also a lot more expensive.

I had considered selling on the tablet after I finished my PhD. My current plan, inspired to some extent by my former colleague Aleksey Shipilëv, who makes great use of his, is to have a go at using it more often, to see if it continues to provide value for me: more noodling out thoughts for work tasks, more drawings (e.g. plans for 3D models) and more reading of tech books.

We've talked about the For-Case anti-pattern many, many times. And while we've seen some wild variations, and some pretty hideous versions, I think we have yet to see the exact example Ashley H sends us:

for (int i = 0; i < 4; i++) {
    if (i == 0) {
        step1();
    } else if (i == 1) {
        step2();
    } else if (i == 2) {
        step3();
    } else if (i == 3){
        finalStep();
    }
}    

The specific names of the functions have been anonymized, but this illustrates the key points of what Ashley found.

It's been in the code base for some time, so she's not entirely certain where it came from, or what the company's code review practices were like at the time.

You see, this kind of code doesn't appear fully formed. It gets created, one step, after another, after another, after another. It's like a loop, but… uh… in a line. Without looping.

Author: Majoki Well into the neopandemic I noticed the countdown. Inside my left eyelid. A faint image, like a digital timer flickering. I couldn’t make out distinct digits in the rolling blur of numbers so there was no real way of knowing if it was counting up or down. But my gut knew. Immediately. Things […]

The post Countdowner appeared first on 365tomorrows.

AI and Secure Messaging Don't Mix

Over on the ACLU's Free Future blog, I just published an article titled AI and Secure Messaging Don't Mix.

The blogpost assumes for the sake of the argument that people might actually want to have an AI involved in their personal conversations, and explores why Meta's Private Processing doesn't offer the level of assurance that they want it to offer.

In short, the promises of "confidential cloud computing" are built on shaky foundations, especially against adversaries as powerful as Meta themselves.

If you really want AI in your chat, the baseline step for privacy preservation is to include it in your local compute base, not to use a network service! But these operators clearly don't value private communication as much as they value binding you to their services.

But let's imagine some secure messenger that actually does put message confidentiality first -- and imagine they had integrated some sort of AI capability into the messenger. That at least bypasses the privacy questions around AI use.

Would you really want to talk with your friends, as augmented by their local AI, though? Would you want an AI, even one running locally with perfect privacy, intervening in your social connections?

What if it summarized your friend's messages to you in a way that led you to misunderstand (or ignore) an important point your friend had made? What if it encouraged you to make an edgy joke that comes across wrong? Or to say something that seriously upsets a friend? How would you respond? How would you even know that it had happened?

My handle is dkg. More times than i can count, i've had someone address me in a chat as "dog" and then cringe and apologize and blame their spellchecker/autocorrect. I can laugh these off because the failure mode is so obvious and transparent -- and repeatable. (also, dogs are awesome, so i don't really mind!)

But when our attention (and our responses!) are being shaped and molded by these plausibility engines, how will we even know that mistakes are being made? What if the plausibility engine you've hooked into your messenger embeds subtle (or unsubtle!) bias?

Don't we owe it to each other to engage with actual human attention?

That’s right: everyone struggles. You could be working on a project only to find a mountain of new things to learn, or your code might keep failing until you start to doubt yourself. I feel like that sometimes, wondering if I’m good enough. But in those moments, I whisper to myself: “You don’t know it yet; once you do, it will get easy.”

While contributing to the Debian openQA project, there was so much to learn, from understanding what Debian actually is to learning the various installation methods and image types. I then had to tackle the installation and usage of openQA itself. I am incredibly grateful for the installation guideprovided by Roland Clobus and the documentation on writing code for openQA.

Overcoming Technical Hurdles

Even with amazing guides, I hit major roadblocks. Initially, I was using Windows with VirtualBox, but openQA couldn’t seem to run the tests properly. Despite my mentors (Roland and Phil) suggesting alternatives, the issues persisted. I actually installed openQA twice on VirtualBox and realized that if you miss even one small step in the installation, it becomes very difficult to move forward. Eventually, I took the big step and dual-booted my machine to Linux. Even then, the challenges didn’t stop. My openQA Virtual Machine (VM) ran out of allocated space and froze, halting my testing. I reached out on the IRC chat and received the help I needed to get back on track.

My Research Line-up

When I’m struggling for information, I follow my go-to first step for research, followed by other alternatives:

1. Google: This is my first stop. It helped me navigate the switch to a Linux OS and troubleshoot KVM connection issues for the VM. Whether it’s an Ubuntu forum or a technical blog, I skim through until I find what can help.
2. The “Upstream” Documentation: If Google doesn’t have the answer, I go straight to the official openQA documentation. This is a goldmine. It explains functions, how to use them, and lists usable test variables.
3. The Debian openQA UI: While working on the apps_startstop tests, I look at previous similar tests on openqa.debian.net/tests. I checked the “Settings” tab to see exactly what variables were used and how the test was configured.

4. Salsa (Debian’s GitLab): I reference the Salsa Debian openQA README and the developer guides sometimes; Getting started, Developer docs on how to write tests

I also had to learn the basics of the Perl programming language during the four-week contribution stage. While we don’t need to be Perl experts, I found it essential to understand the logic so I can explain my work to others.

I’ve spent a lot of time studying the codebase, which is time-consuming but incredibly valuable. For example, my apps_startstop test command originally used a long list of applications via ENTRYPOINT. I began to wonder if there was a more efficient way. With Roland’s guidance, I explored the main.pm file. This helped me understand how the apps_startstop function works and how it calls variables. I also noticed there are utility functions that are called in tests. I also check them and try to understand their function, so I know if I need them or not.

I know I still have a lot to learn, and yes, the doubt still creeps in sometimes. But I am encouraged by the support of my mentors and the fact that they believe in my ability to contribute to this project.
If you’re struggling too, just remember: you don’t know it yet; once you do, it will get easy.

I bought a NanoKVM. I’d heard some of the stories about how terrible it was beforehand, and some I didn’t learn about until afterwards, but at £52, including VAT + P&P, that seemed like an excellent bargain for something I was planning to use in my home network environment.

Let’s cover the bad press first. apalrd did a video, entitled NanoKVM: The S stands for Security (Armen Barsegyan has a write up recommending a PiKVM instead that lists the objections raised in the video). Matej Kovačič wrote an article about the hidden microphone on a Chinese NanoKVM. Various other places have picked up both of these and still seem to be running with them, 10 months later.

Next, let me explain where I’m coming from here. I have over 2 decades of experience with terrible out-of-band access devices. I still wince when I think of the Sun Opteron servers that shipped with an iLOM that needed a 32-bit Windows browser in order to access it (IIRC some 32 bit binary JNI blob). It was a 64 bit x86 server from a company who, at the time, still had a major non-Windows OS. Sheesh. I do not assume these devices are fit for exposure to the public internet, even if they come from “reputable” vendors. Add into that the fact the NanoKVM is very much based on a development board (the LicheeRV Nano), and I felt I knew what I was getting into here.

And, as a TL;DR, I am perfectly happy with my purchase. Sipeed have actually dealt with a bunch of apalrd’s concerns (GitHub ticket), which I consider to be an impressive level of support for this price point. Equally the microphone is explained by the fact this is a £52 device based on a development board. You’re giving it USB + HDMI access to a host on your network, if you’re worried about the microphone then you’re concentrating on the wrong bit here.

I started out by hooking the NanoKVM up to my Raspberry Pi classic, which I use as a serial console / network boot tool for working on random bits of hardware. That meant the NanoKVM had no access to the outside world (the Pi is not configured to route, or NAT, for the test network interface), and I could observe what went on. As it happens you can do an SSH port forward of port 80 with this sort of setup and it all works fine - no need for the NanoKVM to have any external access, and it copes happily with being accessed as http://localhost:8000/ (though you do need to choose MJPEG as the video mode, more forwarding or enabling HTTPS is needed for an H.264 WebRTC session).

IPv6 is enabled in the kernel. My test setup doesn’t have a router advertisements configured, but I could connect to the web application over the v6 link-local address that came up automatically.

My device reports:

Image version:              v1.4.1
Application version:        2.2.9

That’s recent, but the GitHub releases page has 2.3.0 listed as more recent.

Out of the box it’s listening on TCP port 80. SSH is not running, but there’s a toggle to turn it on and the web interface offers a web based shell (with no extra authentication over the normal login). On first use I was asked to set a username + password. Default access, as you’d expect from port 80, is HTTP, but there’s a toggle to enable HTTPS. It generates a self signed certificate - for me it had the CN localhost but that might have been due to my use of port forwarding. Enabling HTTPS does not disable HTTP, but HTTP just redirects to the HTTPS URL.

As others have discussed it does a bunch of DNS lookups, primarily for NTP servers but also for cdn.sipeed.com. The DNS servers are hard coded:

~ # cat /etc/resolv.conf
nameserver 192.168.0.1
nameserver 8.8.4.4
nameserver 8.8.8.8
nameserver 114.114.114.114
nameserver 119.29.29.29
nameserver 223.5.5.5

This is actually restored on boot from /boot/resolv.conf, so if you want changes to persist you can just edit that file. NTP is configured with a standard set of pool.ntp.org services in /etc/ntp.conf (this does not get restored on reboot, so can just be edited in place). I had dnsmasq on the Pi setup to hand out DNS + NTP servers, but both were ignored (though actually udhcpc does write the DNS details to /etc/resolv.conf.dhcp).

My assumption is the lookup to cdn.sipeed.com is for firmware updates (as I bought the NanoKVM cube it came fully installed, so no need for a .so download to make things work); when working DNS was provided I witness attempts to connect to HTTPS. I’ve not bothered digging further into this. I did go grab the latest.zip being served from the URL, which turned out to be v2.2.9, matching what I have installed, not the latest on GitHub.

I note there’s an iptables setup (with nftables underneath) that’s not fully realised - it seems to be trying to allow inbound HTTP + WebRTC, as well as outbound SSH, but everything is default accept so none of it gets hit. Setting up a default deny outbound and tweaking a little should provide a bit more reassurance it’s not going to try and connect out somewhere it shouldn’t.

It looks like updates focus solely on the KVM application, so I wanted to take a look at the underlying OS. This is buildroot based:

~ # cat /etc/os-release
NAME=Buildroot
VERSION=-g98d17d2c0-dirty
ID=buildroot
VERSION_ID=2023.11.2
PRETTY_NAME="Buildroot 2023.11.2"

The kernel reports itself as 5.10.4-tag-. Somewhat ancient, but actually an LTS kernel. Except we’re now up to 5.10.247, so it obviously hasn’t been updated in some time.

TBH, this is what I expect (and fear) from embedded devices. They end up with some ancient base OS revision and a kernel with a bunch of hacks that mean it’s not easily updated. I get that the margins on this stuff are tiny, but I do wish folk would spend more time upstreaming. Or at least updating to the latest LTS point release for their kernel.

The SSH client/daemon is full-fat OpenSSH:

~ # sshd -V
OpenSSH_9.6p1, OpenSSL 3.1.4 24 Oct 2023

There are a number of CVEs fixed in later OpenSSL 3.1 versions, though at present nothing that looks too concerning from the server side. Yes, the image has tcpdump + aircrack installed. I’m a little surprised at aircrack (the device has no WiFi and even though I know there’s a variant that does, it’s not a standard debug tool the way tcpdump is), but there’s a copy of GNU Chess in there too, so it’s obvious this is just a kitchen-sink image. FWIW it looks like the buildroot config is here.

Sadly the UART that I believe the bootloader/kernel are talking to is not exposed externally - the UART pin headers are for UART1 + 2, and I’d have to open up the device to get to UART0. I’ve not yet done this (but doing so would also allow access to the SD card, which would make trying to compile + test my own kernel easier).

In terms of actual functionality it did what I’d expect. 1080p HDMI capture was fine. I’d have gone for a lower resolution, but I think that would have required tweaking on the client side. It looks like the 2.3.0 release allows EDID tweaking, so I might have to investigate that. The keyboard defaults to a US layout, which caused some problems with the | symbol until I reconfigured the target machine not to expect a GB layout.

There’s also the potential to share out images via USB. I copied a Debian trixie netinst image to /data on the NanoKVM and was able to select it in the web interface and have it appear on the target machine easily. There’s also the option to fetch direct from a URL in the web interface, but I was still testing without routable network access, so didn’t try that. There’s plenty of room for images:

~ # df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/mmcblk0p2            7.6G    823.3M      6.4G  11% /
devtmpfs                 77.7M         0     77.7M   0% /dev
tmpfs                    79.0M         0     79.0M   0% /dev/shm
tmpfs                    79.0M     30.2M     48.8M  38% /tmp
tmpfs                    79.0M    124.0K     78.9M   0% /run
/dev/mmcblk0p1           16.0M     11.5M      4.5M  72% /boot
/dev/mmcblk0p3           22.2G    160.0K     22.2G   0% /data

The NanoKVM also appears as an RNDIS USB network device, with udhcpd running on the interface. IP forwarding is not enabled, and there’s no masquerading rules setup, so this doesn’t give the target host access to the “management” LAN by default. I guess it could be useful for copying things over to the target host, as a more flexible approach than a virtual disk image.

One thing to note is this makes for a bunch of devices over the composite USB interface. There are 3 HID devices (keyboard, absolute mouse, relative mouse), the RNDIS interface, and the USB mass storage. I had a few occasions where the keyboard input got stuck after I’d been playing about with big data copies over the network and using the USB mass storage emulation. There is a HID-only mode (no network/mass storage) to try and help with this, and a restart of the NanoKVM generally brought things back, but something to watch out for. Again I see that the 2.3.0 application update mentions resetting the USB hardware on a HID reset, which might well help.

As I stated at the start, I’m happy with this purchase. Would I leave it exposed to the internet without suitable firewalling? No, but then I wouldn’t do so for any KVM. I wanted a lightweight KVM suitable for use in my home network, something unlikely to see heavy use but that would save me hooking up an actual monitor + keyboard when things were misbehaving. So far everything I’ve seen says I’ve got my money’s worth from it.

News:

The Danish Defence Intelligence Service (DDIS) announced on Thursday that Moscow was behind a cyber-attack on a Danish water utility in 2024 and a series of distributed denial-of-service (DDoS) attacks on Danish websites in the lead-up to the municipal and regional council elections in November.

The first, it said, was carried out by the pro-Russian group known as Z-Pentest and the second by NoName057(16), which has links to the Russian state.

Slashdot thread.

After twenty-six years, Microsoft is finally upgrading the last remaining instance of the encryption algorithm RC4 in Windows.

of the most visible holdouts in supporting RC4 has been Microsoft. Eventually, Microsoft upgraded Active Directory to support the much more secure AES encryption standard. But by default, Windows servers have continued to respond to RC4-based authentication requests and return an RC4-based response. The RC4 fallback has been a favorite weakness hackers have exploited to compromise enterprise networks. Use of RC4 played a key role in last year’s breach of health giant Ascension. The breach caused life-threatening disruptions at 140 hospitals and put the medical records of 5.6 million patients into the hands of the attackers. US Senator Ron Wyden (D-Ore.) in September called on the Federal Trade Commission to investigate Microsoft for “gross cybersecurity negligence,” citing the continued default support for RC4.

Last week, Microsoft said it was finally deprecating RC4 and cited its susceptibility to Kerberoasting, the form of attack, known since 2014, that was the root cause of the initial intrusion into Ascension’s network.

Fun fact: RC4 was a trade secret until I published the algorithm in the second edition of Applied Cryptography in 1995.

Hello there . Today will be an in depth review on my work with the Debian OpenQA images testing team. I will highlight the struggles that I have had so far during my Outreachy internship.

The OpenQA images testing team uses OpenQA to automatically install images e.g. Gnome Images. The images are then tested using tests written in Perl. My current tasks include speech install and capture all audio. I am also installing Live Gnome image to Windows using BalenaEtcher then testing it. A set of similar tasks will also be collaborated on. While working on tasks, I have to go through the guides. I also learn how Perl works so as to edit and create tests. For every change made, I have to re-run the job in developer mode. I have to create needles that have matches and click co-ordinates. I have been stuck on some of these instances:

1. During installation, my job would not process a second HDD I had added. Roland Clobus , one of my mentors from the team gave me a variable to work with. The solution was adding “NUMDISKS=2� as part of the command.
2. While working on a file, one of the needles would only work after file edits. Afterwards it would fail to “assert_and_click�. What kept bugging me was why it was passing after the first instance then failing after. The solution was adding a “wait_still_screen� to the code. This would ensure any screen changes loaded first before clicking happened.
3. I was stuck on finding the keys that would be needed for a context menu. I added “button => ‘right’ � in the “assert_and_click � code.
4. Windows 11 installation was constantly failing. Roland pointed out he was working on it so I had to use Windows 10.
5. Windows 10 Virtual Machine does not connect to the internet because of update restrictions. I had to switch to Linux Virtual Machine for a download job.

When I get stuck, at times I seek guidance from the mentors. I still look for solutions in the documentation. Here are some of the documentation that have helped me get through some of these challenges.

1. Installation and creating tests guide – https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/tree/debian/documentation . These guides help in installation and creating of tests.
2. OpenQA official documentation – https://open.qa/docs/ . This documentation is very comprehensive. I used it recently to read about PUBLISH_HDD_n to save the updated version of a HDD_n I am using.
3. OpenQA test API documentation – https://open.qa/api/testapi/ . This documentation shows me which parameters to use. I have used it recently to find how to right click on a mouse and special characters.
4. OpenQA variables file in Gitlab – https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/blob/debian/VARIABLES.md . This has explanations of the most commonly used variables .
5. OpenQA repository in Gitlab – https://salsa.debian.org/qa/openqa/openqa-tests-debian . I go through the Perl tests. Understand how they work . Then integrate my tests using the a similar manner so that it would look uniform.
6. OpenQa tests – https://openqa.debian.net/tests. I use these tests to find machine settings. I also find test sequences and the assets I would need to create similar tests. I used it recently to look at how graphical login was being implemented then shutdown.

The list above are the documentation that are supposed to be used for these tests and finding solutions. If I don’t find anything within these, I then ask Roland for help. I try to go through the autoinst documentation that are from the links provided in the Gitlab README.md file : https://salsa.debian.org/qa/openqa/openqa-tests-debian/-/blob/debian/README.md . They are also comprehensive but are very technical .

In general, I get challenges but there is always a means to solve them through documentation provided. The mentors are also very helpful whenever we get challenges. I have gained team contribution skills , upgraded my git skills, learned Perl and how to test using OpenQA. I am still polishing on how to make my needles better. My current progress is thus good. We learn one day at a time.

As a follow up from my last post about my 8K TV [1] I tested out a Samsung 65″ QN900C Neo QLED 8K that’s on sale in JB Hifi. According to the JB employee I spoke to they are running out the last 8K TVs and have no plans to get more.

In my testing of that 8K TV YouTube had a 3840*2160 viewport which is better than the 1920*1080 of my Hisense TV. When running a web browser the codeshack page reported it as 1920*1080 with a 1.25* pixel density (presumably a configuration option) that gave a usable resolution of 1536*749.

The JB Hifi employee wouldn’t let me connect my own device via HDMI but said that it would work at 8K. I said “so if I buy it I can return it if it doesn’t do 8K HDMI?” and then he looked up the specs and found that it would only do 4K input on HDMI. It seems that actual 8K resolution might work on a Samsung streaming device but that’s not very useful particularly as there probably isn’t much 8K content on any streaming service.

Basically that Samsung allegedly 8K TV only works at 4K at best.

It seems to be impossible to buy an 8K TV or monitor in Australia that will actually display 8K content. ASUS has a 6K 32″ monitor with 6016*3384 resolution for $2016 [2]. When counting for inflation $2016 wouldn’t be the most expensive monitor I’ve ever bought and hopefully prices will continue to drop.

Rumour has it that there are 8K TVs available in China that actually take 8K input. Getting one to Australia might not be easy but it’s something that I will investigate.

Also I’m trying to sell my allegedly 8K TV.

• [1] https://etbe.coker.com.au/2025/11/25/edid-and-my-8k-tv/
• [2] https://tinyurl.com/2arl3al7

So, I'm cross-eyed and typing with one eye screwed shut, which sucks. Seeing an ophthalmologist tomorrow, expecting a priority referral to get the other eyeball stabbed. (It was not made clear to me at the time of the last stabbing that the hospital wouldn't see me again until my ophthalmologist referred me back to them. I'm fixing that oversight—hah—now.)

Anyway, my reading fatigue has gotten bad again, to about the same extent it had gotten to when I more or less stopped reading for fun and writing ground to a halt (because what do you spend most writing time doing, if not re-reading?). So don't expect to hear much from me until I've been operated on and ideally gotten a new set of prescription lenses.

Book news: A Conventional Boy is getting a UK paperback release (from Orbit), on January 6th 2026. And The Regicide Report, the 11th and final book in the main Laundry Files series, comes out on January 27th, 2026 in hardcover and ebook—from Orbit in the UK/EU/Aus/NZ, and from Tor.com in the USA.

Note that if you want a complete run of the series in a uniform binding and page size you will need to wait until probably January 6th-ish, give or take, in 2027, then you'll need to order the British paperbacks because There is no single US publisher of the series. The first two books were published by Golden Gryphon (who no longer exist), then it was picked up by Ace in hardcover and sometimes paperback (The Nightmare Stacks never made it into paperback in the USA as the mass market distribution channel was imploding at the time), then got taken on by Tor.com from The Delirium Brief onwards, and Tor.com don't really do paperbacks at all—they're an ebook publisher who also distribute hardcovers via original-Tor. I sincerely doubt that a US limited edition publisher would be interested in picking up and repackaging a series of 14 novels (and probably a short story collection that doesn't exist yet), some of which have been in print for 25 years. I mean, a complete run of the British paperbacks is more than a foot thick already and there are two books still to go in that format.

(Ordering the books: Transreal Books in Edinburgh will take orders by email and will get me in to sign stock, but is no longer shipping to the United States—blame Trump and his idiotic tariff war. (Mike is a sole trader and can't afford the risk of doofuses buying a bunch of books then refusing to pay the import and duty fees. Hitherto books were duty-exempt in the US market, but under Trump, who the hell knows?) I believe amazon.co.uk will still ship UK physical book orders to the USA, but I won't be signing them. If you're in North America your next opportunity to get anything signed is therefore to wait for the worldcon in 2027, which I believe is locked in now and will take place in Montreal.)

What happens after these books is an open question. As I noted in my last update, I'm working on two space operas. Or I would be working if I could stare at the screen for long enough to make headway. If the eyeball fairy would wave a magic wand over my left eye, I could finish both Starter Pack (a straightforward job—I have edit notes) and Ghost Engine (less straightforward but not really impossible) by the end of the year. But as matters stand, you should consider me to be off sick until further notice. Talking about anything that happens after those two is wildly ungrounded speculation: lets just say I expect a spurt of rebound productivity once I have my eyes working appropriately again, and I have some ideas.

For the same reason, blogging's going to be scarce around these parts. So feel free to talk among yourselves.

Edit: remaining cataract not bad enough for surgery—yet—but my prescription has changed (in both eyes). New glasses coming in a week or two: I'm not pushing on the surgery because eye surgery is not on my list of happy fun recreational activities. So normal service should resume by mid-November-ish.

Meanwhile I'm working on another big idea for blogging, riffing off the idea that nation-states are the products of (or are generated as a by-product of) secular religions. It's easiest to see if you look at your neighbours' weirdnesses: Americans, contemplate the British monarchy (hereditary theocracy that supplants the papacy as intercessionary with Jesus, how much clearer could it be than that?); Brits, look to the USA (holy scripture written down in that constitution, daily prayers pledge of allegiance in schools, and all the flag-shagging). Or Israel, and the whole "holy land/chosen people" narrative underpinning political zionism. Patriotism is an affirmation of religious zeal. In this reframing, extremist nationalism is religious evangelism. Now ask, what are the implications, looking forward?

Many of us who fly for business and/or pleasure are all too aware of the myriad issues plaguing the 21st-century airline industry: everything from cybercrime targeting ailing IT systems and Boeing's ongoing nightmare to US commercial airline pilots being forced to retire at age 65, contributing to a diminishing workforce that has less of the sort of wisdom that can't be picked up in a flight simulator. The exact sort of experience you want your flight crew to have if, say, your aircraft loses an engine during takeoff.

This is only the tip of the iceberg. And our submitter Greta, reporting from the inside, shows us that even a win could be a dangerous loss waiting to happen:

This will be a departure in that it's about something that is soon to happen, rather than that which already was. Looming in the near distance is an event about which I'm trying my best not to give into apocalypse fetishism, but it's difficult not to.

We make aircraft. They're large, expensive flying robots. Our company is tiny. We're slowly growing, but could very comfortably fit in the 1966 General Motors New Look bus featured in Speed. We've produced, on a good year, up to three aircraft, with all design, programming, assembly and testing done in-house.

This quarter (and into next quarter), we're about to have a whole lot of the right kind of problem; our orders have approximately quintupled, and they're for a heavily revised version of the aircraft that is still partially theoretical. The designs are sort of done, we have some of the hardware that will be running our code, and some of the code is written and working. Some of it is written and non-working. Some of it is yet unwritten. The code carried forward from the previous version has been flown, but none of the new code has flown.

Our development team is facing a fascinating pile-up of pressures.

There is a contingent of fixed-term contracted interns who have been doing some heroic heavy lifting but whose contracts are up in a couple of weeks due to the college schedule; new blood will need to be trained and in the trenches to backfill them.

Some of our (custom) hardware has known design faults and needs modification and re-production, or is in the middle of production and we all hope and pray that no modification requests are needed.

We're doing our damnedest to write production-worthy code and tests as we go, and I would describe the design and review atmosphere as healthy, but bugs can happen and are happening: bugs of the category where, if they were released to an aircraft in the sky, the aircraft would become suddenly reacquainted with the ground. Some of those bugs can be fixed in firmware, and for some of them we need to ask our long-suffering electrical engineer to pretty please pull off a miracle with a soldering iron so that we can continue development before a new board is released.

Fully-functioning test hardware is scarce, and on a near daily basis developers need to have a polite conversation about who gets to perform a flash validation (I have not observed rock-paper-scissors yet).

We also simply don't have the bodies to physically build aircraft in the way we have in the past. Upper management has painted a picture for me where six weeks from now, the CEO, managers, all of my developers and me may be assembling and testing one or two hundred batteries by hand. (I have demanded pizza if this comes to pass.)

All of this in service of an early Spring deadline, with a parade of non-negotiable activities like careful flight testing before it.

Safety is paramount, and no corners will be cut. But picture where we are now: a frenzy of development, then the eye of the storm, the company holiday shutdown, where we all try our best to enjoy the time off without dwelling on what we're getting ourselves into in 2026.

I've always purposely avoided jobs where my screw-ups might produce serious injury or death. I have the utmost respect for those who assume this awesome responsibility and care about doing the best job possible. I feel for Greta and others like her, and I really hope that if or when push comes to shove, her company prioritizes safety over all else. We've already endured too many horrific examples of what happens when corners are cut in service of budget and time constraints that were never realistic to begin with.

[Advertisement] ProGet’s got you covered with security and access controls on your NuGet feeds. Learn more.

Author: Julian Miles, Staff Writer Jingle bells my ass. Actually, if I’d had one, the ex-wife probably would have. Covered it’s harness in fairy lights, too. She loved sparkly tat. Guess that’s why she hooked up with the bright-eyed pretty boy I used to be. Then she got pregnant and we both got ugly. I […]

The post Smite appeared first on 365tomorrows.

Similar to what I wrote for Ubuntu 18.04, here is how to setup an LXC container on Debian forky.

Installing the required packages

Start by installing the necessary packages on the host:

apt install lxc libvirt-clients debootstrap

Network setup

Ensure the veth kernel module is loaded by adding the following to /etc/modules-load.d/lxc-local.conf:

veth

and then loading it manually for now:

modprobe veth

Enable IPv4 forwarding by putting this in /etc/sysctl.d/lxc-local.conf:

net.ipv4.ip_forward=1

and applying it:

sysctl -p /etc/sysctl.d/lxc-local.conf

Restart the LXC network bridge:

systemctl restart lxc-net.service

Ensure that container traffic is not blocked by the host firewall, for example by adding the following to /etc/network/iptables.up.rules:

-A FORWARD -d 10.0.3.0/24 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.0.3.0/24 -j ACCEPT
-A INPUT -d 224.0.0.251 -s 10.0.3.1 -j ACCEPT
-A INPUT -d 239.255.255.250 -s 10.0.3.1 -j ACCEPT
-A INPUT -d 10.0.3.255 -s 10.0.3.1 -j ACCEPT
-A INPUT -d 10.0.3.1 -s 10.0.3.0/24 -j ACCEPT

and applying the rules:

iptables-apply

Creating a container

To see all available images, run:

lxc-create -n foo --template=download -- --list

and then create a Debian forky container using:

lxc-create -n forky -t download -- -d debian -r forky -a amd64

Start and stop the container like this:

lxc-start -n forky
lxc-stop -n forky

Connecting to the container

Attach to the running container's console:

lxc-attach -n forky

Inside the container, you can change the root password by typing:

passwd

and install some essential packages:

apt install openssh-server vim

To find the container's IP address (for example, so that you can ssh to it from the host):

lxc-ls --fancy

## 0.23	2025-12-20

commit be15aa25dea40aea66a8534143fb81b29d2e6c08
Author: C.J. Collier 
Date:   Sat Dec 20 22:40:44 2025 +0000

    Fixes C-level test infrastructure and adds more test cases for upb_to_sv conversions.
    
    - **Makefile.PL:**
        - Allow `extra_src` in `c_test_config.json` to be an array.
        - Add ASan flags to CCFLAGS and LDDLFLAGS for better debugging.
        - Corrected echo newlines in `test_c` target.
    - **c_test_config.json:**
        - Added missing type test files to `deps` and `extra_src` for `convert/sv_to_upb` and `convert/upb_to_sv` test runners.
    - **t/c/convert/upb_to_sv.c:**
        - Fixed a double free of `test_pool`.
        - Added missing includes for type test headers.
        - Updated test plan counts.
    - **t/c/convert/sv_to_upb.c:**
        - Added missing includes for type test headers.
        - Updated test plan counts.
        - Corrected Perl interpreter initialization.
    - **t/c/convert/types/**:
        - Added missing `test_util.h` include in new type test headers.
        - Completed the set of `upb_to_sv` test cases for all scalar types by adding optional and repeated tests for `sfixed32`, `sfixed64`, `sint32`, and `sint64`, and adding repeated tests to the remaining scalar type files.
    - **Documentation:**
        - Updated `01-xs-testing.md` with more debugging tips, including ASan usage and checking for double frees and typos.
        - Updated `xs_learnings.md` with details from the recent segfault.
        - Updated `llm-plan-execution-instructions.md` to emphasize debugging steps.


## 0.22	2025-12-19

commit 2c171d9a5027e0150eae629729c9104e7f6b9d2b
Author: C.J. Collier 
Date:   Fri Dec 19 23:41:02 2025 +0000

    feat(perl,testing): Initialize C test framework and build system
    
    This commit sets up the foundation for the C-level tests and the build system for the Perl Protobuf module:
    
    1.  **Makefile.PL Enhancements:**
        *   Integrates `Devel::PPPort` to generate `ppport.h` for better portability.
        *   Object files now retain their path structure (e.g., `xs/convert/sv_to_upb.o`) instead of being flattened, improving build clarity.
        *   The `MY::postamble` is significantly revamped to dynamically generate build rules for all C tests located in `t/c/` based on the `t/c/c_test_config.json` file.
        *   C tests are linked against `libprotobuf_common.a` and use `ExtUtils::Embed` flags.
        *   Added `JSON::MaybeXS` to `PREREQ_PM`.
        *   The `test` target now also depends on the `test_c` target.
    
    2.  **C Test Infrastructure (`t/c/`):
        *   Introduced `t/c/c_test_config.json` to configure individual C test builds, specifying dependencies and extra source files.
        *   Created `t/c/convert/test_util.c` and `.h` for shared test functions like loading descriptors.
        *   Initial `t/c/convert/upb_to_sv.c` and `t/c/convert/sv_to_upb.c` test runners.
        *   Basic `t/c/integration/030_protobuf_coro.c` for Coro safety testing on core utils using `libcoro`.
        *   Basic `t/c/integration/035_croak_test.c` for testing exception handling.
        *   Basic `t/c/integration/050_convert.c` for integration testing conversions.
    
    3.  **Test Proto:** Updated `t/data/test.proto` with more field types for conversion testing and regenerated `test_descriptor.bin`.
    
    4.  **XS Test Harness (`t/c/upb-perl-test.h`):** Added `like_n` macro for length-aware regex matching.
    
    5.  **Documentation:** Updated architecture and plan documents to reflect the C test structure.
    6.  **ERRSV Testing:** Note that the C tests (`t/c/`) will primarily check *if* a `croak` occurs (i.e., that the exception path is taken), but will not assert on the string content of `ERRSV`. Reliably testing `$@` content requires the full Perl test environment with `Test::More`, which will be done in the `.t` files when testing the Perl API.
    
    This provides a solid base for developing and testing the XS and C components of the module.


## 0.21	2025-12-18

commit a8b6b6100b2cf29c6df1358adddb291537d979bc
Author: C.J. Collier 
Date:   Thu Dec 18 04:20:47 2025 +0000

    test(C): Add integration tests for Milestone 2 components
    
    - Created t/c/integration/030_protobuf.c to test interactions
      between obj_cache, arena, and utils.
    - Added this test to t/c/c_test_config.json.
    - Verified that all C tests for Milestones 2 and 3 pass,
      including the libcoro-based stress test.


## 0.20	2025-12-18

commit 0fcad68680b1f700a83972a7c1c48bf3a6958695
Author: C.J. Collier 
Date:   Thu Dec 18 04:14:04 2025 +0000

    docs(plan): Add guideline review reminders to milestones
    
    - Added a "[ ] REFRESH: Review all documents in @perl/doc/guidelines/**"
      checklist item to the start of each component implementation
      milestone (C and Perl layers).
    - This excludes Integration Test milestones.


## 0.19	2025-12-18

commit 987126c4b09fcdf06967a98fa3adb63d7de59a34
Author: C.J. Collier 
Date:   Thu Dec 18 04:05:53 2025 +0000

    docs(plan): Add C-level and Perl-level Coro tests to milestones
    
    - Added checklist items for `libcoro`-based C tests
      (e.g., `t/c/integration/050_convert_coro.c`) to all C layer
      integration milestones (050 through 220).
    - Updated `030_Integration_Protobuf.md` to standardise checklist
      items for the existing `030_protobuf_coro.c` test.
    - Removed the single `xt/author/coro-safe.t` item from
      `010_Build.md`.
    - Added checklist items for Perl-level `Coro` tests
      (e.g., `xt/coro/240_arena.t`) to each Perl layer
      integration milestone (240 through 400).
    - Created `perl/t/c/c_test_config.json` to manage C test
      configurations externally.
    - Updated `perl/doc/architecture/testing/01-xs-testing.md` to describe
      both C-level `libcoro` and Perl-level `Coro` testing strategies.


## 0.18	2025-12-18

commit 6095a5a610401a6035a81429d0ccb9884d53687b
Author: C.J. Collier 
Date:   Thu Dec 18 02:34:31 2025 +0000

    added coro testing to c layer milestones


## 0.17	2025-12-18

commit cc0aae78b1f7f675fc8a1e99aa876c0764ea1cce
Author: C.J. Collier 
Date:   Thu Dec 18 02:26:59 2025 +0000

    docs(plan): Refine test coverage checklist items for SMARTness
    
    - Updated the "Tests provide full coverage" checklist items in
      C layer plan files (020, 040, 060, 080, 100, 120, 140, 160, 180, 200)
      to explicitly mention testing all public functions in the
      corresponding header files.
    - Expanded placeholder checklists in 140, 160, 180, 200.
    - Updated the "Tests provide full coverage" and "Add coverage checks"
      checklist items in Perl layer plan files (230, 250, 270, 290, 310, 330,
      350, 370, 390) to be more specific about the scope of testing
      and the use of `Test::TestCoverage`.
    - Expanded Well-Known Types milestone (350) to detail each type.


## 0.16	2025-12-18

commit e4b601f14e3817a17b0f4a38698d981dd4cb2818
Author: C.J. Collier 
Date:   Thu Dec 18 02:07:35 2025 +0000

    docs(plan): Full refactoring of C and Perl plan files
    
    - Split both ProtobufPlan-C.md and ProtobufPlan-Perl.md into
      per-milestone files under the `perl/doc/plan/` directory.
    - Introduced Integration Test milestones after each component
      milestone in both C and Perl plans.
    - Numbered milestone files sequentially (e.g., 010_Build.md,
      230_Perl_Arena.md).
    - Updated main ProtobufPlan-C.md and ProtobufPlan-Perl.md to
      act as Tables of Contents.
    - Ensured consistent naming for integration test files
      (e.g., `t/c/integration/030_protobuf.c`, `t/integration/260_descriptor_pool.t`).
    - Added architecture review steps to the end of all milestones.
    - Moved Coro safety test to C layer Milestone 1.
    - Updated Makefile.PL to support new test structure and added Coro.
    - Moved and split t/c/convert.c into t/c/convert/*.c.
    - Moved other t/c/*.c tests into t/c/protobuf/*.c.
    - Deleted old t/c/convert.c.


## 0.15	2025-12-17

commit 649cbacf03abb5e7293e3038bb451c0406e9d0ce
Author: C.J. Collier 
Date:   Wed Dec 17 23:51:22 2025 +0000

    docs(plan): Refactor and reset ProtobufPlan.md
    
    - Split the plan into ProtobufPlan-C.md and ProtobufPlan-Perl.md.
    - Reorganized milestones to clearly separate C layer and Perl layer development.
    - Added more granular checkboxes for each component:
      - C Layer: Create test, Test coverage, Implement, Tests pass.
      - Perl Layer: Create test, Test coverage, Implement Module/XS, Tests pass, C-Layer adjustments.
    - Reset all checkboxes to `[ ]` to prepare for a full audit.
    - Updated status in architecture/api and architecture/core documents to "Not Started".
    
    feat(obj_cache): Add unregister function and enhance tests
    
    - Added `protobuf_unregister_object` to `xs/protobuf/obj_cache.c`.
    - Updated `xs/protobuf/obj_cache.h` with the new function declaration.
    - Expanded tests in `t/c/protobuf_obj_cache.c` to cover unregistering,
      overwriting keys, and unregistering non-existent keys.
    - Corrected the test plan count in `t/c/protobuf_obj_cache.c` to 17.


## 0.14	2025-12-17

commit 40b6ad14ca32cf16958d490bb575962f88d868a1
Author: C.J. Collier 
Date:   Wed Dec 17 23:18:27 2025 +0000

    feat(arena): Complete C layer for Arena wrapper
    
    This commit finalizes the C-level implementation for the Protobuf::Arena wrapper.
    
    - Adds `PerlUpb_Arena_Destroy` for proper cleanup from Perl's DEMOLISH.
    - Enhances error checking in `PerlUpb_Arena_Get`.
    - Expands C-level tests in `t/c/protobuf_arena.c` to cover memory allocation
      on the arena and lifecycle through `PerlUpb_Arena_Destroy`.
    - Corrects embedded Perl initialization in the C test.
    
    docs(plan): Refactor ProtobufPlan.md
    
    - Restructures the development plan to clearly separate "C Layer" and
      "Perl Layer" tasks within each milestone.
    - This aligns the plan with the "C-First Implementation Strategy" and improves progress tracking.


## 0.13	2025-12-17

commit c1e566c25f62d0ae9f195a6df43b895682652c71
Author: C.J. Collier 
Date:   Wed Dec 17 22:00:40 2025 +0000

    refactor(perl): Rename C tests and enhance Makefile.PL
    
    - Renamed test files in `t/c/` to better match the `xs` module structure:
        - `01-cache.c` -> `protobuf_obj_cache.c`
        - `02-arena.c` -> `protobuf_arena.c`
        - `03-utils.c` -> `protobuf_utils.c`
        - `04-convert.c` -> `convert.c`
        - `load_test.c` -> `upb_descriptor_load.c`
    - Updated `perl/Makefile.PL` to reflect the new test names in `MY::postamble`'s `$c_test_config`.
    - Refactored the `$c_test_config` generation in `Makefile.PL` to reduce repetition by using a default flags hash and common dependencies array.
    - Added a `fail()` macro to `perl/t/c/upb-perl-test.h` for consistency.
    - Modified `t/c/upb_descriptor_load.c` to use the `t/c/upb-perl-test.h` macros, making its output consistent with other C tests.
    - Added a skeleton for `t/c/convert.c` to test the conversion functions.
    - Updated documentation in `ProtobufPlan.md` and `architecture/testing/01-xs-testing.md` to reflect new test names.


## 0.12	2025-12-17

commit d8cb5dd415c6c129e71cd452f78e29de398a82c9
Author: C.J. Collier 
Date:   Wed Dec 17 20:47:38 2025 +0000

    feat(perl): Refactor XS code into subdirectories
    
    This commit reorganizes the C code in the `perl/xs/` directory into subdirectories, mirroring the structure of the Python UPB extension. This enhances modularity and maintainability.
    
    - Created subdirectories for each major component: `convert`, `descriptor`, `descriptor_containers`, `descriptor_pool`, `extension_dict`, `map`, `message`, `protobuf`, `repeated`, and `unknown_fields`.
    - Created skeleton `.h` and `.c` files within each subdirectory to house the component-specific logic.
    - Updated top-level component headers (e.g., `perl/xs/descriptor.h`) to include the new sub-headers.
    - Updated top-level component source files (e.g., `perl/xs/descriptor.c`) to include their main header and added stub initialization functions (e.g., `PerlUpb_InitDescriptor`).
    - Moved code from the original `perl/xs/protobuf.c` to new files in `perl/xs/protobuf/` (arena, obj_cache, utils).
    - Moved code from the original `perl/xs/convert.c` to new files in `perl/xs/convert/` (upb_to_sv, sv_to_upb).
    - Updated `perl/Makefile.PL` to use a glob (`xs/*/*.c`) to find the new C source files in the subdirectories.
    - Added `perl/doc/architecture/core/07-xs-file-organization.md` to document the new structure.
    - Updated `perl/doc/ProtobufPlan.md` and other architecture documents to reference the new organization.
    - Corrected self-referential includes in the newly created .c files.
    
    This restructuring provides a solid foundation for further development and makes it easier to port logic from the Python implementation.


## 0.11	2025-12-17

commit cdedcd13ded4511b0464f5d3bdd72ce6d34e73fc
Author: C.J. Collier 
Date:   Wed Dec 17 19:57:52 2025 +0000

    feat(perl): Implement C-first testing and core XS infrastructure
    
    This commit introduces a significant refactoring of the Perl XS extension, adopting a C-first development approach to ensure a robust foundation.
    
    Key changes include:
    
    -   **C-Level Testing Framework:** Established a C-level testing system in `t/c/` with a dedicated Makefile, using an embedded Perl interpreter. Initial tests cover the object cache (`01-cache.c`), arena wrapper (`02-arena.c`), and utility functions (`03-utils.c`).
    -   **Core XS Infrastructure:**
        -   Implemented a global object cache (`xs/protobuf.c`) to manage Perl wrappers for UPB objects, using weak references.
        -   Created an `upb_Arena` wrapper (`xs/protobuf.c`).
        -   Consolidated common XS helper functions into `xs/protobuf.h` and `xs/protobuf.c`.
    -   **Makefile.PL Enhancements:** Updated to support building and linking C tests, incorporating flags from `ExtUtils::Embed`, and handling both `.c` and `.cc` source files.
    -   **XS File Reorganization:** Restructured XS files to mirror the Python UPB extension's layout (e.g., `message.c`, `descriptor.c`). Removed older, monolithic `.xs` files.
    -   **Typemap Expansion:** Added extensive typemap entries in `perl/typemap` to handle conversions between Perl objects and various `const upb_*Def*` pointers.
    -   **Descriptor Tests:** Added a new test suite `t/02-descriptor.t` to validate descriptor loading and accessor methods.
    -   **Documentation:** Updated development plans and guidelines (`ProtobufPlan.md`, `xs_learnings.md`, etc.) to reflect the C-first strategy, new testing methods, and lessons learned.
    -   **Build Cleanup:** Removed `ppport.h` from `.gitignore` as it's no longer used, due to `-DPERL_NO_PPPORT` being set in `Makefile.PL`.
    
    This C-first approach allows for more isolated and reliable testing of the core logic interacting with the UPB library before higher-level Perl APIs are built upon it.


## 0.10	2025-12-17

commit 1ef20ade24603573905cb0376670945f1ab5d829
Author: C.J. Collier 
Date:   Wed Dec 17 07:08:29 2025 +0000

    feat(perl): Implement C-level tests and core XS utils
    
    This commit introduces a C-level testing framework for the XS layer and implements key components:
    
    1.  **C-Level Tests (`t/c/`)**:
        *   Added `t/c/Makefile` to build standalone C tests.
        *   Created `t/c/upb-perl-test.h` with macros for TAP-compliant C tests (`plan`, `ok`, `is`, `is_string`, `diag`).
        *   Implemented `t/c/01-cache.c` to test the object cache.
        *   Implemented `t/c/02-arena.c` to test `Protobuf::Arena` wrappers.
        *   Implemented `t/c/03-utils.c` to test string utility functions.
        *   Corrected include paths and diagnostic messages in C tests.
    
    2.  **XS Object Cache (`xs/protobuf.c`)**:
        *   Switched to using stringified pointers (`%p`) as hash keys for stability.
        *   Fixed a critical double-free bug in `PerlUpb_ObjCache_Delete` by removing an extra `SvREFCNT_dec` on the lookup key.
    
    3.  **XS Arena Wrapper (`xs/protobuf.c`)**:
        *   Corrected `PerlUpb_Arena_New` to use `newSVrv` and `PTR2IV` for opaque object wrapping.
        *   Corrected `PerlUpb_Arena_Get` to safely unwrap the arena pointer.
    
    4.  **Makefile.PL (`perl/Makefile.PL`)**:
        *   Added `-Ixs` to `INC` to allow C tests to find `t/c/upb-perl-test.h` and `xs/protobuf.h`.
        *   Added `LIBS` to link `libprotobuf_common.a` into the main `Protobuf.so`.
        *   Added C test targets `01-cache`, `02-arena`, `03-utils` to the test config in `MY::postamble`.
    
    5.  **Protobuf.pm (`perl/lib/Protobuf.pm`)**:
        *   Added `use XSLoader;` to load the compiled XS code.
    
    6.  **New files `xs/util.h`**:
        *   Added initial type conversion function.
    
    These changes establish a foundation for testing the C-level interface with UPB and fix crucial bugs in the object cache implementation.


## 0.09	2025-12-17

commit 07d61652b032b32790ca2d3848243f9d75ea98f4
Author: C.J. Collier 
Date:   Wed Dec 17 04:53:34 2025 +0000

    feat(perl): Build system and C cache test for Perl XS
    
    This commit introduces the foundational pieces for the Perl XS implementation, focusing on the build system and a C-level test for the object cache.
    
    -   **Makefile.PL:**
        -   Refactored C test compilation rules in `MY::postamble` to use a hash (`$c_test_config`) for better organization and test-specific flags.
        -   Integrated `ExtUtils::Embed` to provide necessary compiler and linker flags for embedding the Perl interpreter, specifically for the `t/c/01-cache.c` test.
        -   Correctly constructs the path to the versioned Perl library (`libperl.so.X.Y.Z`) using `$Config{archlib}` and `$Config{libperl}` to ensure portability.
        -   Removed `VERSION_FROM` and `ABSTRACT_FROM` to avoid dependency on `.pm` files for now.
    
    -   **C Cache Test (t/c/01-cache.c):**
        -   Added a C test to exercise the object cache functions implemented in `xs/protobuf.c`.
        -   Includes tests for adding, getting, deleting, and weak reference behavior.
    
    -   **XS Cache Implementation (xs/protobuf.c, xs/protobuf.h):**
        -   Implemented `PerlUpb_ObjCache_Init`, `PerlUpb_ObjCache_Add`, `PerlUpb_ObjCache_Get`, `PerlUpb_ObjCache_Delete`, and `PerlUpb_ObjCache_Destroy`.
        -   Uses a Perl hash (`HV*`) for the cache.
        -   Keys are string representations of the C pointers, created using `snprintf` with `"%llx"`.
        -   Values are weak references (`sv_rvweaken`) to the Perl objects (`SV*`).
        -   `PerlUpb_ObjCache_Get` now correctly returns an incremented reference to the original SV, not a copy.
        -   `PerlUpb_ObjCache_Destroy` now clears the hash before decrementing its refcount.
    
    -   **t/c/upb-perl-test.h:**
        -   Updated `is_sv` to perform direct pointer comparison (`got == expected`).
    
    -   **Minor:** Added `util.h` (currently empty), updated `typemap`.
    
    These changes establish a working C-level test environment for the XS components.


## 0.08	2025-12-17

commit d131fd22ea3ed8158acb9b0b1fe6efd856dc380e
Author: C.J. Collier 
Date:   Wed Dec 17 02:57:48 2025 +0000

    feat(perl): Update docs and core XS files
    
    - Explicitly add TDD cycle to ProtobufPlan.md.
    - Clarify mirroring of Python implementation in upb-interfacing.md for both C and Perl layers.
    - Branch and adapt python/protobuf.h and python/protobuf.c to perl/xs/protobuf.h and perl/xs/protobuf.c, including the object cache implementation. Removed old cache.* files.
    - Create initial C test for the object cache in t/c/01-cache.c.


## 0.07	2025-12-17

commit 56fd6862732c423736a2f9a9fb1a2816fc59e9b0
Author: C.J. Collier 
Date:   Wed Dec 17 01:09:18 2025 +0000

    feat(perl): Align Perl UPB architecture docs with Python
    
    Updates the Perl Protobuf architecture documents to more closely align with the design and implementation strategies used in the Python UPB extension.
    
    Key changes:
    
    -   **Object Caching:** Mandates a global, per-interpreter cache using weak references for all UPB-derived objects, mirroring Python's `PyUpb_ObjCache`.
    -   **Descriptor Containers:** Introduces a new document outlining the plan to use generic XS container types (Sequence, ByNameMap, ByNumberMap) with vtables to handle collections of descriptors, similar to Python's `descriptor_containers.c`.
    -   **Testing:** Adds a note to the testing strategy to port relevant test cases from the Python implementation to ensure feature parity.


## 0.06	2025-12-17

commit 6009ce6ab64eccce5c48729128e5adf3ef98e9ae
Author: C.J. Collier 
Date:   Wed Dec 17 00:28:20 2025 +0000

    feat(perl): Implement object caching and fix build
    
    This commit introduces several key improvements to the Perl XS build system and core functionality:
    
    1.  **Object Caching:**
        *   Introduces `xs/protobuf.c` and `xs/protobuf.h` to implement a caching mechanism (`protobuf_c_to_perl_obj`) for wrapping UPB C pointers into Perl objects. This uses a hash and weak references to ensure object identity and prevent memory leaks.
        *   Updates the `typemap` to use `protobuf_c_to_perl_obj` for `upb_MessageDef *` output, ensuring descriptor objects are cached.
        *   Corrected `sv_weaken` to the correct `sv_rvweaken` function.
    
    2.  **Makefile.PL Enhancements:**
        *   Switched to using the Bazel-generated UPB descriptor sources from `bazel-bin/src/google/protobuf/_virtual_imports/descriptor_proto/google/protobuf/`.
        *   Updated `INC` paths to correctly locate the generated headers.
        *   Refactored `MY::dynamic_lib` to ensure the static library `libprotobuf_common.a` is correctly linked into each generated `.so` module, resolving undefined symbol errors.
        *   Overrode `MY::test` to use `prove -b -j$(nproc) t/*.t xt/*.t` for running tests.
        *   Cleaned up `LIBS` and `LDDLFLAGS` usage.
    
    3.  **Documentation:**
        *   Updated `ProtobufPlan.md` to reflect the current status and design decisions.
        *   Reorganized architecture documents into subdirectories.
        *   Added `object-caching.md` and `c-perl-interface.md`.
        *   Updated `llm-guidance.md` with notes on `upb/upb.h` and `sv_rvweaken`.
    
    4.  **Testing:**
        *   Fixed `xt/03-moo_immutable.t` to skip tests if no Moo modules are found.
    
    This resolves the build issues and makes the core test suite pass.


## 0.05	2025-12-16

commit 177d2f3b2608b9d9c415994e076a77d8560423b8
Author: C.J. Collier 
Date:   Tue Dec 16 19:51:36 2025 +0000

    Refactor: Rename namespace to Protobuf, build system and doc updates
    
    This commit refactors the primary namespace from `ProtoBuf` to `Protobuf`
    to align with the style guide. This involves renaming files, directories,
    and updating package names within all Perl and XS files.
    
    **Namespace Changes:**
    
    *   Renamed `perl/lib/ProtoBuf` to `perl/lib/Protobuf`.
    *   Moved and updated `ProtoBuf.pm` to `Protobuf.pm`.
    *   Moved and updated `ProtoBuf::Descriptor` to `Protobuf::Descriptor` (.pm & .xs).
    *   Removed other `ProtoBuf::*` stubs (Arena, DescriptorPool, Message).
    *   Updated `MODULE` and `PACKAGE` in `Descriptor.xs`.
    *   Updated `NAME`, `*_FROM` in `perl/Makefile.PL`.
    *   Replaced `ProtoBuf` with `Protobuf` throughout `perl/typemap`.
    *   Updated namespaces in test files `t/01-load-protobuf-descriptor.t` and `t/02-descriptor.t`.
    *   Updated namespaces in all documentation files under `perl/doc/`.
    *   Updated paths in `perl/.gitignore`.
    
    **Build System Enhancements (Makefile.PL):**
    
    *   Included `xs/*.c` files in the common object files list.
    *   Added `-I.` to the `INC` paths.
    *   Switched from `MYEXTLIB` to `LIBS => ['-L$(CURDIR) -lprotobuf_common']` for linking.
    *   Removed custom keys passed to `WriteMakefile` for postamble.
    *   `MY::postamble` now sources variables directly from the main script scope.
    *   Added `all :: ${common_lib}` dependency in `MY::postamble`.
    *   Added `t/c/load_test.c` compilation rule in `MY::postamble`.
    *   Updated `clean` target to include `blib`.
    *   Added more modules to `TEST_REQUIRES`.
    *   Removed the explicit `PM` and `XS` keys from `WriteMakefile`, relying on `XSMULTI => 1`.
    
    **New Files:**
    
    *   `perl/lib/Protobuf.pm`
    *   `perl/lib/Protobuf/Descriptor.pm`
    *   `perl/lib/Protobuf/Descriptor.xs`
    *   `perl/t/01-load-protobuf-descriptor.t`
    *   `perl/t/02-descriptor.t`
    *   `perl/t/c/load_test.c`: Standalone C test for UPB.
    *   `perl/xs/types.c` & `perl/xs/types.h`: For Perl/C type conversions.
    *   `perl/doc/architecture/upb-interfacing.md`
    *   `perl/xt/03-moo_immutable.t`: Test for Moo immutability.
    
    **Deletions:**
    
    *   Old test files: `t/00_load.t`, `t/01_basic.t`, `t/02_serialize.t`, `t/03_message.t`, `t/04_descriptor_pool.t`, `t/05_arena.t`, `t/05_message.t`.
    *   Removed `lib/ProtoBuf.xs` as it's not needed with `XSMULTI`.
    
    **Other:**
    
    *   Updated `test_descriptor.bin` (binary change).
    *   Significant content updates to markdown documentation files in `perl/doc/architecture` and `perl/doc/internal` reflecting the new architecture and learnings.


## 0.04	2025-12-14

commit 92de5d482c8deb9af228f4b5ce31715d3664d6ee
Author: C.J. Collier 
Date:   Sun Dec 14 21:28:19 2025 +0000

    feat(perl): Implement Message object creation and fix lifecycles
    
    This commit introduces the basic structure for `ProtoBuf::Message` object
    creation, linking it with `ProtoBuf::Descriptor` and `ProtoBuf::DescriptorPool`,
    and crucially resolves a SEGV by fixing object lifecycle management.
    
    Key Changes:
    
    1.  **`ProtoBuf::Descriptor`:** Added `_pool` attribute to hold a strong
        reference to the parent `ProtoBuf::DescriptorPool`. This is essential to
        prevent the pool and its C `upb_DefPool` from being garbage collected
        while a descriptor is still in use.
    
    2.  **`ProtoBuf::DescriptorPool`:**
        *   `find_message_by_name`: Now passes the `$self` (the pool object) to the
            `ProtoBuf::Descriptor` constructor to establish the lifecycle link.
        *   XSUB `pb_dp_find_message_by_name`: Updated to accept the pool `SV*` and
            store it in the descriptor's `_pool` attribute.
        *   XSUB `_load_serialized_descriptor_set`: Renamed to avoid clashing with the
            Perl method name. The Perl wrapper now correctly calls this internal XSUB.
        *   `DEMOLISH`: Made safer by checking for attribute existence.
    
    3.  **`ProtoBuf::Message`:**
        *   Implemented using Moo with lazy builders for `_upb_arena` and
            `_upb_message`.
        *   `_descriptor` is a required argument to `new()`.
        *   XS functions added for creating the arena (`pb_msg_create_arena`) and
            the `upb_Message` (`pb_msg_create_upb_message`).
        *   `pb_msg_create_upb_message` now extracts the `upb_MessageDef*` from the
            descriptor and uses `upb_MessageDef_MiniTable()` to get the minitable
            for `upb_Message_New()`.
        *   `DEMOLISH`: Added to free the message's arena.
    
    4.  **`Makefile.PL`:**
        *   Added `-g` to `CCFLAGS` for debugging symbols.
        *   Added Perl CORE include path to `MY::postamble`'s `base_flags`.
    
    5.  **Tests:**
        *   `t/04_descriptor_pool.t`: Updated to check the structure of the
            returned `ProtoBuf::Descriptor`.
        *   `t/05_message.t`: Now uses a descriptor obtained from a real pool to
            test `ProtoBuf::Message->new()`.
    
    6.  **Documentation:**
        *   Updated `ProtobufPlan.md` to reflect progress.
        *   Updated several files in `doc/architecture/` to match the current
            implementation details, especially regarding arena management and object
            lifecycles.
        *   Added `doc/internal/development_cycle.md` and `doc/internal/xs_learnings.md`.
    
    With these changes, the SEGV is resolved, and message objects can be successfully
    created from descriptors.


## 0.03	2025-12-14

commit 6537ad23e93680c2385e1b571d84ed8dbe2f68e8
Author: C.J. Collier 
Date:   Sun Dec 14 20:23:41 2025 +0000

    Refactor(perl): Object-Oriented DescriptorPool with Moo
    
    This commit refactors the `ProtoBuf::DescriptorPool` to be fully object-oriented using Moo, and resolves several issues related to XS, typemaps, and test data.
    
    Key Changes:
    
    1.  **Moo Object:** `ProtoBuf::DescriptorPool.pm` now uses `Moo` to define the class. The `upb_DefPool` pointer is stored as a lazy attribute `_upb_defpool`.
    2.  **XS Lifecycle:** `DescriptorPool.xs` now has `pb_dp_create_pool` called by the Moo builder and `pb_dp_free_pool` called from `DEMOLISH` to manage the `upb_DefPool` lifecycle per object.
    3.  **Typemap:** The `perl/typemap` file has been significantly updated to handle the conversion between the `ProtoBuf::DescriptorPool` Perl object and the `upb_DefPool *` C pointer. This includes:
        *   Mapping `upb_DefPool *` to `T_PTR`.
        *   An `INPUT` section for `ProtoBuf::DescriptorPool` to extract the pointer from the object's hash, triggering the lazy builder if needed via `call_method`.
        *   An `OUTPUT` section for `upb_DefPool *` to convert the pointer back to a Perl integer, used by the builder.
    4.  **Method Renaming:** `add_file_descriptor_set_binary` is now `load_serialized_descriptor_set`.
    5.  **Test Data:**
        *   Added `perl/t/data/test.proto` with a sample message and enum.
        *   Generated `perl/t/data/test_descriptor.bin` using `protoc`.
        *   Removed `t/data/` from `.gitignore` to ensure test data is versioned.
    6.  **Test Update:** `t/04_descriptor_pool.t` is updated to use the new OO interface, load the generated descriptor set, and check for message definitions.
    7.  **Build Fixes:**
        *   Corrected `#include` paths in `DescriptorPool.xs` to be relative to the `upb/` directory (e.g., `upb/wire/decode.h`).
        *   Added `-I../upb` to `CCFLAGS` in `Makefile.PL`.
        *   Reordered `INC` paths in `Makefile.PL` to prioritize local headers.
    
    **Note:** While tests now pass in some environments, a SEGV issue persists in `make test` runs, indicating a potential memory or lifecycle issue within the XS layer that needs further investigation.


## 0.02	2025-12-14

commit 6c9a6f1a5f774dae176beff02219f504ea3a6e07
Author: C.J. Collier 
Date:   Sun Dec 14 20:13:09 2025 +0000

    Fix(perl): Correct UPB build integration and generated file handling
    
    This commit resolves several issues to achieve a successful build of the Perl extension:
    
    1.  **Use Bazel Generated Files:** Switched from compiling UPB's stage0 descriptor.upb.c to using the Bazel-generated `descriptor.upb.c` and `descriptor.upb_minitable.c` located in `bazel-bin/src/google/protobuf/_virtual_imports/descriptor_proto/google/protobuf/`.
    2.  **Updated Include Paths:** Added the `bazel-bin` path to `INC` in `WriteMakefile` and to `base_flags` in `MY::postamble` to ensure the generated headers are found during both XS and static library compilation.
    3.  **Removed Stage0:** Removed references to `UPB_STAGE0_DIR` and no longer include headers or source files from `upb/reflection/stage0/`.
    4.  **-fPIC:** Explicitly added `-fPIC` to `CCFLAGS` in `WriteMakefile` and ensured `$(CCFLAGS)` is used in the custom compilation rules in `MY::postamble`. This guarantees all object files in the static library are compiled with position-independent code, resolving linker errors when creating the shared objects for the XS modules.
    5.  **Refined UPB Sources:** Used `File::Find` to recursively find UPB C sources, excluding `/conformance/` and `/reflection/stage0/` to avoid conflicts and unnecessary compilations.
    6.  **Arena Constructor:** Modified `ProtoBuf::Arena::pb_arena_new` XSUB to accept the class name argument passed from Perl, making it a proper constructor.
    7.  **.gitignore:** Added patterns to `perl/.gitignore` to ignore generated C files from XS (`lib/*.c`, `lib/ProtoBuf/*.c`), the copied `src_google_protobuf_descriptor.pb.cc`, and the `t/data` directory.
    8.  **Build Documentation:** Updated `perl/doc/architecture/upb-build-integration.md` to reflect the new build process, including the Bazel prerequisite, include paths, `-fPIC` usage, and `File::Find`.
    
    Build Steps:
    1.  `bazel build //src/google/protobuf:descriptor_upb_proto` (from repo root)
    2.  `cd perl`
    3.  `perl Makefile.PL`
    4.  `make`
    5.  `make test` (Currently has expected failures due to missing test data implementation).


## 0.01	2025-12-14

commit 3e237e8a26442558c94075766e0d4456daaeb71d
Author: C.J. Collier 
Date:   Sun Dec 14 19:34:28 2025 +0000

    feat(perl): Initialize Perl extension scaffold and build system
    
    This commit introduces the `perl/` directory, laying the groundwork for the Perl Protocol Buffers extension. It includes the essential build files, linters, formatter configurations, and a vendored Devel::PPPort for XS portability.
    
    Key components added:
    
    *   **`Makefile.PL`**: The core `ExtUtils::MakeMaker` build script. It's configured to:
        *   Build a static library (`libprotobuf_common.a`) from UPB, UTF8_Range, and generated protobuf C/C++ sources.
        *   Utilize `XSMULTI => 1` to create separate shared objects for `ProtoBuf`, `ProtoBuf::Arena`, and `ProtoBuf::DescriptorPool`.
        *   Link each XS module against the common static library.
        *   Define custom compilation rules in `MY::postamble` to handle C vs. C++ flags and build the static library.
        *   Set up include paths for the project root, UPB, and other dependencies.
    
    *   **XS Stubs (`.xs` files)**:
        *   `lib/ProtoBuf.xs`: Placeholder for the main module's XS functions.
        *   `lib/ProtoBuf/Arena.xs`: XS interface for `upb_Arena` management.
        *   `lib/ProtoBuf/DescriptorPool.xs`: XS interface for `upb_DefPool` management.
    
    *   **Perl Module Stubs (`.pm` files)**:
        *   `lib/ProtoBuf.pm`: Main module, loads XS.
        *   `lib/ProtoBuf/Arena.pm`: Perl class for Arenas.
        *   `lib/ProtoBuf/DescriptorPool.pm`: Perl class for Descriptor Pools.
        *   `lib/ProtoBuf/Message.pm`: Base class for messages (TBD).
    
    *   **Configuration Files**:
        *   `.gitignore`: Ignores build artifacts, editor files, etc.
        *   `.perlcriticrc`: Configures Perl::Critic for static analysis.
        *   `.perltidyrc`: Configures perltidy for code formatting.
    
    *   **`Devel::PPPort`**: Vendored version 3.72 to generate `ppport.h` for XS compatibility across different Perl versions.
    
    *   **`typemap`**: Custom typemap for XS argument/result conversion.
    
    *   **Documentation (`doc/`)**: Initial architecture and plan documents.
    
    This provides a solid foundation for developing the UPB-based Perl extension.

tl;dr:

There is a Debian git transition plan. It’s going OK so far but we need help, especially with outreach and updating Debian’s documentation.

• Goals of the Debian git transition project
  • Achievements so far, and current status
• Core engineering principle
  • Correspondence between dsc and git
  • Patches-applied vs patches-unapplied
  • Consequences, some of which are annoying
• Distributing the source code as git
  • Tracking the relevant git data, when changes are made in the legacy Archive
  • Why *.dgit.debian.org is not Salsa
• Roadmap
  • In progress
  • Future Technology
• Mindshare and adoption - please help!
  • A rant about publishing the source code
  • Documentation
• Personnel
  • Thanks

Goals of the Debian git transition project

0. Everyone who interacts with Debian source code should be able to do so entirely in git.

That means, more specifically:

1. All examination and edits to the source should be performed via normal git operations.

2. Source code should be transferred and exchanged as git data, not tarballs. git should be the canonical form everywhere.

3. Upstream git histories should be re-published, traceably, as part of formal git releases published by Debian.

4. No-one should have to learn about Debian Source Packages, which are bizarre, and have been obsoleted by modern version control.

This is very ambitious, but we have come a long way!

Achievements so far, and current status

We have come a very long way. But, there is still much to do - especially, the git transition team needs your help with adoption, developer outreach, and developer documentation overhaul.

We’ve made big strides towards goals 1 and 4. Goal 2 is partially achieved: we currently have dual running. Goal 3 is within our reach but depends on widespread adoption of tag2upload (and/or dgit push).

Downstreams and users can obtain the source code of any Debian package in git form. (dgit clone, 2013). They can then work with this source code completely in git, including building binaries, merging new versions, even automatically (eg Raspbian, 2016), and all without having to deal with source packages at all (eg Wikimedia 2025).

A Debian maintainer can maintain their own package entirely in git. They can obtain upstream source code from git, and do their packaging work in git (git-buildpackage, 2006).

Every Debian maintainer can (and should!) release their package from git reliably and in a standard form (dgit push, 2013; tag2upload, 2025). This is not only more principled, but also more convenient, and with better UX, than pre-dgit tooling like dput.

Indeed a Debian maintainer can now often release their changes to Debian, from git, using only git branches (so no tarballs). Releasing to Debian can be simply pushing a signed tag (tag2upload, 2025).

A Debian maintainer can maintain a stack of changes to upstream source code in git (gbp pq 2009). They can even maintain such a delta series as a rebasing git branch, directly buildable, and use normal git rebase style operations to edit their changes, (git-dpm, 2010; git-debrebase, 2018)

An authorised Debian developer can do a modest update to any package in Debian, even one maintained by someone else, working entirely in git in a standard and convenient way (dgit, 2013).

Debian contributors can share their work-in-progress on git forges and collaborate using merge requests, git based code review, and so on. (Alioth, 2003; Salsa, 2018.)

Core engineering principle

The Debian git transition project is based on one core engineering principle:

Every Debian Source Package can be losslessly converted to and from git.

In order to transition away from Debian Source Packages, we need to gateway between the old dsc approach, and the new git approach.

This gateway obviously needs to be bidirectional: source packages uploaded with legacy tooling like dput need to be imported into a canonical git representation; and of course git branches prepared by developers need to be converted to source packages for the benefit of legacy downstream systems (such as the Debian Archive and apt source).

This bidirectional gateway is implemented in src:dgit, and is allowing us to gradually replace dsc-based parts of the Debian system with git-based ones.

Correspondence between dsc and git

A faithful bidirectional gateway must define an invariant:

The canonical git tree, corresponding to a .dsc, is the tree resulting from dpkg-source -x.

This canonical form is sometimes called the “dgit view”. It’s sometimes not the same as the maintainer’s git branch, because many maintainers are still working with “patches-unapplied” git branches. More on this below.

(For 3.0 (quilt) .dscs, the canonical git tree doesn’t include the quilt .pc directory.)

Patches-applied vs patches-unapplied

The canonical git format is “patches applied”. That is:

If Debian has modified the upstream source code, a normal git clone of the canonical branch gives the modified source tree, ready for reading and building.

Many Debian maintainers keep their packages in a different git branch format, where the changes made by Debian, to the upstream source code, are in actual patch files in a debian/patches/ subdirectory.

Patches-applied has a number of important advantages over patches-unapplied:

• It is familiar to, and doesn’t trick, outsiders to Debian. Debian insiders radically underestimate how weird “patches-unapplied” is. Even expert software developers can get very confused or even accidentally build binaries without security patches!

• Making changes can be done with just normal git commands, eg git commit. Many Debian insiders working with patches-unapplied are still using quilt(1), a footgun-rich contraption for working with patch files!

• When developing, one can make changes to upstream code, and to Debian packaging, together, without ceremony. There is no need to switch back and forth between patch queue and packaging branches (as with gbp pq), no need to “commit” patch files, etc. One can always edit every file and commit it with git commit.

The downside is that, with the (bizarre) 3.0 (quilt) source format, the patch files files in debian/patches/ must somehow be kept up to date. Nowadays though, tools like git-debrebase and git-dpm (and dgit for NMUs) make it very easy to work with patches-applied git branches. git-debrebase can deal very ergonomically even with big patch stacks.

(For smaller packages which usually have no patches, plain git merge with an upstream git branch, and a much simpler dsc format, sidesteps the problem entirely.)

Prioritising Debian’s users (and other outsiders)

We want everyone to be able to share and modify the software that they interact with. That means we should make source code truly accessible, on the user’s terms.

Many of Debian’s processes assume everyone is an insider. It’s okay that there are Debian insiders and that people feel part of something that they worked hard to become involved with. But lack of perspective can lead to software which fails to uphold our values.

Our source code practices — in particular, our determination to share properly (and systematically) — are a key part of what makes Debian worthwhile at all. Like Debian’s installer, we want our source code to be useable by Debian outsiders.

This is why we have chosen to privilege a git branch format which is more familiar to the world at large, even if it’s less popular in Debian.

Consequences, some of which are annoying

The requirement that the conversion be bidirectional, lossless, and context-free can be inconvenient.

For example, we cannot support .gitattributes which modify files during git checkin and checkout. .gitattributes cause the meaning of a git tree to depend on the context, in possibly arbitrary ways, so the conversion from git to source package wouldn’t be stable. And, worse, some source packages might not to be representable in git at all.

Another example: Maintainers often have existing git branches for their packages, generated with pre-dgit tooling which is less careful and less principled than ours. That can result in discrepancies between git and dsc, which need to be resolved before a proper git-based upload can succeed.

That some maintainers use patches-unapplied, and some patches-unapplied, means that there has to be some kind of conversion to a standard git representation. Choosing the less-popular patches-applied format as the canonical form, means that many packages need their git representation converted. It also means that user- and outsider-facing branches from {browse,git}.dgit.d.o and dgit clone are not always compatible with maintainer branches on Salsa. User-contributed changes need cherry-picking rather than merging, or conversion back to the maintainer format. The good news is that dgit can automate much of this, and the manual parts are usually easy git operations.

Distributing the source code as git

Our source code management should be normal, modern, and based on git. That means the Debian Archive is obsolete and needs to be replaced with a set of git repositories.

The replacement repository for source code formally released to Debian is *.dgit.debian.org. This contains all the git objects for every git-based upload since 2013, including the signed tag for each released package version.

The plan is that it will contain a git view of every uploaded Debian package, by centrally importing all legacy uploads into git.

Tracking the relevant git data, when changes are made in the legacy Archive

Currently, many critical source code management tasks are done by changes to the legacy Debian Archive, which works entirely with dsc files (and the associated tarballs etc). The contents of the Archive are therefore still an important source of truth. But, the Archive’s architecture means it cannot sensibly directly contain git data.

To track changes made in the Archive, we added the Dgit: field to the .dsc of a git-based upload (2013). This declares which git commit this package was converted from. and where those git objects can be obtained.

Thus, given a Debian Source Package from a git-based upload, it is possible for the new git tooling to obtain the equivalent git objects. If the user is going to work in git, there is no need for any tarballs to be downloaded: the git data could be obtained from the depository using the git protocol.

The signed tags, available from the git depository, have standardised metdata which gives traceability back to the uploading Debian contributor.

Why *.dgit.debian.org is not Salsa

We need a git depository - a formal, reliable and permanent git repository of source code actually released to Debian.

Git forges like Gitlab can be very convenient. But Gitlab is not sufficiently secure, and too full of bugs, to be the principal and only archive of all our source code. (The “open core” business model of the Gitlab corporation, and the constant-churn development approach, are critical underlying problems.)

Our git depository lacks forge features like Merge Requests. But:

• It is dependable, both in terms of reliability and security.
• It is append-only: once something is pushed, it is permanently recorded.
• Its access control is precisely that of the Debian Archive.
• Its ref namespace is standardised and corresponds to Debian releases.
• Pushes are authorised by PGP signatures, not ssh keys, so traceable.

The dgit git depository outlasted Alioth and it may well outlast Salsa.

We need both a good forge, and the *.dgit.debian.org formal git depository.

Roadmap

In progress

Right now we are quite focused on tag2upload.

We are working hard on eliminating the remaining issues that we feel need to be addressed before declaring the service out of beta.

Future Technology

Whole-archive dsc importer

Currently, the git depository only has git data for git-based package updates (tag2upload and dgit push). Legacy dput-based uploads are not currently present there. This means that the git-based and legacy uploads must be resolved client-side, by dgit clone.

We will want to start importing legacy uploads to git.

Then downstreams and users will be able to get the source code for any package simply with git clone, even if the maintainer is using legacy upload tools like dput.

Support for git-based uploads to security.debian.org

Security patching is a task which would particularly benefit from better and more formal use of git. git-based approaches to applying and backporting security patches are much more convenient than messing about with actual patch files.

Currently, one can use git to help prepare a security upload, but it often involves starting with a dsc import (which lacks the proper git history) or figuring out a package maintainer’s unstandardised git usage conventions on Salsa.

And it is not possible to properly perform the security release as git.

Internal Debian consumers switch to getting source from git

Buildds, QA work such as lintian checks, and so on, could be simpler if they don’t need to deal with source packages.

And since git is actually the canonical form, we want them to use it directly.

Problems for the distant future

For decades, Debian has been built around source packages. Replacing them is a long and complex process. Certainly source packages are going to continue to be supported for the foreseeable future.

There are no doubt going to be unanticipated problems. There are also foreseeable issues: for example, perhaps there are packages that work very badly when represented in git. We think we can rise to these challenges as they come up.

Mindshare and adoption - please help!

We and our users are very pleased with our technology. It is convenient and highly dependable.

dgit in particular is superb, even if we say so ourselves. As technologists, we have been very focused on building good software, but it seems we have fallen short in the marketing department.

A rant about publishing the source code

git is the preferred form for modification.

Our upstreams are overwhelmingly using git. We are overwhelmingly using git. It is a scandal that for many packages, Debian does not properly, formally and officially publish the git history.

Properly publishing the source code as git means publishing it in a way that means that anyone can automatically and reliably obtain and build the exact source code corresponding to the binaries. The test is: could you use that to build a derivative?

Putting a package in git on Salsa is often a good idea, but it is not sufficient. No standard branch structure git on Salsa is enforced, nor should it be (so it can’t be automatically and reliably obtained), the tree is not in a standard form (so it can’t be automatically built), and is not necessarily identical to the source package. So Vcs-Git fields, and git from Salsa, will never be sufficient to make a derivative.

Debian is not publishing the source code!

The time has come for proper publication of source code by Debian to no longer be a minority sport. Every maintainer of a package whose upstream is using git (which is nearly all packages nowadays) should be basing their work on upstream git, and properly publishing that via tag2upload or dgit.

And it’s not even difficult! The modern git-based tooling provides a far superior upload experience.

A common misunderstanding

dgit push is not an alternative to gbp pq or quilt. Nor is tag2upload. These upload tools complement your existing git workflow. They replace and improve source package building/signing and the subsequent dput. If you are using one of the usual git layouts on salsa, and your package is in good shape, you can adopt tag2upload and/or dgit push right away.

git-debrebase is distinct and does provides an alternative way to manage your git packaging, do your upstream rebases, etc.

Documentation

Debian’s documentation all needs to be updated, including particularly instructions for packaging, to recommend use of git-first workflows. Debian should not be importing git-using upstreams’ “release tarballs” into git. (Debian outsiders who discover this practice are typically horrified.) We should use only upstream git, work only in git, and properly release (and publish) in git form.

We, the git transition team, are experts in the technology, and can provide good suggestions. But we do not have the bandwidth to also engage in the massive campaigns of education and documentation updates that are necessary — especially given that (as with any programme for change) many people will be sceptical or even hostile.

So we would greatly appreciate help with writing and outreach.

Personnel

We consider ourselves the Debian git transition team.

Currently we are:

• Ian Jackson. Author and maintainer of dgit and git-debrebase. Co-creator of tag2upload. Original author of dpkg-source, and inventor in 1996 of Debian Source Packages. Alumnus of the Debian Technical Committee.

• Sean Whitton. Co-creator of the tag2upload system; author and maintainer of git-debpush. Co-maintainer of dgit. Debian Policy co-Editor. Former Chair of the Debian Technical Committee.

We wear the following hats related to the git transition:

• Maintainers of src:dgit
• tag2upload Delegates; operators of the tag2upload service.
• service operators of the git depository *.dgit.debian.org.

You can contact us:

• By email: Ian Jackson ijackson@chiark.greenend.org.uk; Sean Whitton spwhitton@spwhitton.name; git-debpush@packages.d.o.

• By filing bugs in the Debian Bug System against src:dgit.

• On OFTC IRC, as Diziet and spwhitton.

We do most of our heavy-duty development on Salsa.

Thanks

Particular thanks are due to Joey Hess, who, in the now-famous design session in Vaumarcus in 2013, helped invent dgit. Since then we have had a lot of support: most recently political support to help get tag2upload deployed, but also, over the years, helpful bug reports and kind words from our users, as well as translations and code contributions.

Many other people have contributed more generally to support for working with Debian source code in git. We particularly want to mention Guido Günther (git-buildpackage); and of course Alexander Wirt, Joerg Jaspert, Thomas Goirand and Antonio Terceiro (Salsa administrators); and before them the Alioth administrators.

comments

Russ Allbery wrote an interesting review of Politics on the Edge, by Rory Stewart who sems like one of the few conservative politicians I could respect and possibly even like [1]. It has some good insights about the problems with our current political environment.

The NY Times has an amusing article about the attempt to sell the solution to the CIA’s encrypted artwork [2].

Wired has an interesting article about computer face recognition systems failing on people with facial disabilities or scars [3]. This is a major accessibility issue potentially violating disability legislation and a demonstration of the problems of fully automating systems when there should be a human in the loop.

The October 2025 report from the Debian Reproducible Builds team is particularly interesting [4]. “kpcyrd forwarded a fascinating tidbit regarding so-called ninja and samurai build ordering, that uses data structures in which the pointer values returned from malloc are used to determine some order of execution” LOL

Louis Rossmann made an insightful youtube video about the moral case for piracy of software and media [5].

Louis Rossman made an insightful video about the way that Hyundai is circumventing Right to Repair laws to make repairs needlessly expensive [6]. Korean cars aren’t much good nowadays. Their prices keep increasing and the quality doesn’t.

Brian Krebs wrote an interesting article about how Google is taking legal action against SMS phishing crime groups [7]. We need more of this!

Josh Griffiths wrote an informative blog post about how YouTube is awful [8]. I really should investigate Peertube.

Louis Rossman made an informative YouTube video about Right to Repair and the US military, if even the US military is getting ripped off by this it’s a bigger problem than most people realise [9]. He also asks the rhetorical question of whether politicians are bought or whether it’s a “subscription model”.

Brian Krebs wrote an informative article about the US plans to ban TP Link devices, OpenWRT seems like a good option [10].

Brian Krebs wrote an informative article about “free streaming” Android TV boxes that act as hidden residential VPN proxies [11]. Also the “free streaming” violates copyright law.

Bruce Schneier and Nathan E. Sanders wrote an interesting article about ways that AI is being used to strengthen democracy [12].

Cory Doctorow wrote an insightful article about the incentives for making shitty goods and services and why we need legislation to protect consumers [13].

Linus Tech Tips has an interesting interview with Linus Torvalds [14].

Interesting video about the Kowloon Walled City [15]. It would be nice if a government deliberately created a hive city like that, the only example I know of is the Alaskan town in a single building.

David Brin wrote an insightful set of 3 blog posts about a Democratic American deal that could improve the situation there [16].

• [1] https://tinyurl.com/2czzxp77
• [2] https://tinyurl.com/22k6yo6s
• [3] https://tinyurl.com/29fg9ses
• [4] https://reproducible-builds.org/reports/2025-10/
• [5] https://www.youtube.com/watch?v=YAx3yCNomkg
• [6] https://www.youtube.com/watch?v=uv9jAQ_MiK0
• [7] https://tinyurl.com/276qmbuh
• [8] https://tinyurl.com/2bhp6sa2
• [9] https://www.youtube.com/watch?v=C0LmjzXV7IA
• [10] https://tinyurl.com/22pgz36h
• [11] https://tinyurl.com/2xveozvd
• [12] https://tinyurl.com/2bjs4g2j
• [13] https://tinyurl.com/2bsh3wbt
• [14] https://www.youtube.com/watch?v=mfv0V1SxbNA
• [15] https://www.youtube.com/watch?v=hoNclh1K_zY
• [16] https://tinyurl.com/29opfj43

Author: Alastair Millar Grandpa Jack had a generous ‘meritorious service’ pension from his time in the Terran Space Force, but he never talked about his time in uniform, or shared war stories. “I’d rather not,” he’d say diffidently, or, if pressed, “Just not much to tell, really”. Everyone around him quietly assumed that his off-world […]

The post Veteran’s Christmas appeared first on 365tomorrows.

Continuing my series about a proposed Democratic Newer Deal. 

Here I'll dive deeply into four more of the 30+ suggested reforms that were briefly listed here... organized in a way that both learns-from and satirizes the hypocritical but politically effective 1994 Republican Contract With America. 

But first some pertinent news. A couple of weeks after I started posting this series -- offering voters a clear agenda of positive steps -- economist and columnist Robert Reich issued a shorter list of “What Democrats Must Pledge to America.” And no, I am not asserting that my series triggered him to hurry his. 

Well, probably not. Though Reich's list overlaps mine in overall intent! We both aim to make progress toward better health care, aid to parents and children, and sound economics while limiting the power of oligarchies and cheaters and monopolies. Alas, Reich's 'pledges' also make up a wish list that might as well be directed at Santa Claus, for all of its political impracticality.

Alas, not one of Reich’s proposals satisfies the “60%+ Rule” that was so politically-effective for Newt Gingrich in 1994, and that Pelosi-Schumer-Sanders applied with terrific effectiveness in 2021-22.  

Start with steps that can be steam-rollered quickly, with 60%+ strong public support, right away! Only after that do you try for the long pass.

Big Gulp endeavors, like those tried by Clinton and Obama, always get bogged down and savaged by "Who pays for it?" and "They want communism!" Then, the GOP wins the next Congress and that's that - opportunity window closed. What we discovered in the 2021-22 Pelosi miracle year was that you can make great strides in multiple directions, if you start from that 60% consensus in order to push solid increments. Steps that then create those new plateaus!

Contrasting with Reich's "pledges," my list emphasizes restoring a functioning republic - civil service, reliable institutions, elections and rule-of-law - in ways that can't be withdrawn by future demagogues... along with incremental steps toward our shared goals (e.g. get all CHILDREN coverable under Medicare, in a single stroke, easily afforded and canceling every objection to Medicare-for-all.)

Look, I like and respect Robert Reich. But here he should have added an equally realistic 11th wish to the other ten... that every American gets a unicorn or pegasus, or at least a pony

== Those "Newer Deal" proposals we appraised last time ==

Could the news this month have better supported my list? If we had the Inspectorate right now, under IGUS (a totally independent Inspector General of the United States), Trump could not have fired or transferred most of the IGs and JAGs in the federal government. Honest scrutiny would abound when we need it most! And officers would have somewhere to turn, when given illegal orders. (I have recommended IGUS for fifteen years.)

The Truth & Reconciliation Act - discussed last time - would have staunched Trump's tsunami of corrupt pardons and the Immunity Limitation Act would clarify that no President is above the law. And yes, there are ways to judo-bypass the Roberts Court in both of those realms.

Some other proposals from my last two postings may seem obscure, like the Cyber Hygiene Act that could eliminate 90%+ of the 'botnets' that now infest tens of millions of home and small business computers, empowering our enemies and criminals. Or one that I personally like most... a simple House-internal reform to give every member one subpoena per year, which would likely transform the entire mental ecology in Congress!

But onward to more proposals! Most of which (again) you'll see nowhere else.

== Appraising another four "Newer Deal" proposals ==

I've mentioned the 1994 Newt Gingrich Contract With America several times and in so doing I likely triggered visceral, gut wrenching loathing from many of you! 

Well tough. You must understand how the 'contract' seemingly offered voters clear and crisp reforms of a system that most citizens now distrust. 

Yes, Newt and especially his replacement - the deeply-evil Dennis Hastert - betrayed every promise when they took power. Still, some (a minority) of those promises merit another look. Moreover, Democrats can say "WATCH as we actually enact them, unlike our lying opponents!

Among the good ideas the GOP betrayed are these:

•   Require all laws that apply to the rest of the country also apply to Congress; 

•   Arrange regular audits of Congress for waste or abuse;

•   Limit the terms of all committee chairs and party leadership posts;

•   Ban the casting of proxy votes in committee and law-writing by lobbyists;

•   Require that committee meetings be open to the public;

•   Guarantee honest accounting of our Federal Budget.

…and in the same spirit…

Members of Congress shall report openly all stock and other trades by members or their families, especially those trades which might be affected by the member’s inside knowledge.

Some members may resist some of those measures. But those are the sorts of House internal reforms that could truly persuade voters. Especially with the contrast. "Republicans betrayed these promises. We are keeping them."

Here's another one that'd be simple to implement. Even entertaining! While somewhat favoring the Party that has more younger members. Fewer creaky near-zombies. And so, swinging from the House to the Senate:

While continuing ongoing public debate over the Senate’s practice of filibuster, we shall use our next majority in the Senate to restore the original practice: that senators invoking a filibuster must speak on the chamber floor the entire time.

No explanation is needed on that one! Bring back the spirit of Jimmy Stewart.

Only now, here's one that I very much care about. Do any of you remember when Gingrich and then Hastert fired all the staff in Congress that advised members about matters of actual fact, especially science and technology? Why on Earth would they do such a thing? 

Simple. The Congressional Office of Technology Assessment (OTA) would often say to members: "I'm sorry (sir or madam), but that's not actually true."

Oh, no, we can't have that! Gingrich asserted that OTA said that dreaded phrase far more often to Republicans than to Democrats. And... well... yes, that is true enough. There's a reason for that. But true or not, it's time for this proposal to be enacted:

Independent congressional advisory offices for science, technology and other areas of skilled, fact-based analysis will be restored, in order to counsel Congress on matters of fact without bias or dogma-driven pressure. 

Rules shall ensure that technical reports may not be re-written by politicians, changing their meaning to bend to political desires. 

Every member of Congress shall be encouraged and funded to appoint from their home district a science-and-fact advisor who may interrogate the advisory panels and/or answer questions of fact on the member’s behalf.

Notice how this pre-empts all plausible objections in advance! By challenging (and funding) every representative to hire a science and fact adviser from their home district, you achieve several things:

1. Each member gets trusted factual guidance -- someone who can interrogate OTA and other experts, on the member's behalf. And this, in turn, addresses the earlier Gingrich calumny about "OTA bias."

2. Members would no longer get to wriggle and squirm out of answering fact or science questions -- e.g. re: Climate Change -- evading with the blithe shrug that's used by almost all current Republicans: "I'm not a scientist." 

So? Now you have someone you trust who can answer technical or factual or scientific questions for you. So step up to the microphone with your team.

3. Any member who refuses to name such an adviser risks ridicule; "What? Your home district hasn't got savvy experts you could pick from?" That potential blowback could ensure that every member participates.

4. Remember, this is about fact-determination and not policy! Policy and law remain the member's domain. Only now they will be less unconstrained in asserting false, counter-factual justifications for dumb policies.

And finally (for this time)... a problem that every Congress has promised to address, that of PORK spending. Look, you will never eliminate it! Members want to bring stuff home to their district. 

But by constraining pork to a very specific part of the budget, they'll have to wrangle with each other, divvying that single slice of pie among themselves. And it will lead to scrutiny of each other's picks, giving each pork belly a strong sniff for potential corruption.

New rules shall limit “pork” earmarking of tax dollars to benefit special interests or specific districts. Exceptions must come from a single pool, totaling no more than one half of a percent of the discretionary budget. These exceptions must be placed in clearly marked and severable portions of a bill, at least two weeks before the bill is voted upon. (More details here.)

Notice that all four of the proposals that we covered this time are internal procedure reforms for the houses of Congress! Which means they would not be subject to presidential veto. 

These... and several others... could be passed if Democrats take either house of Congress in January 2027, no matter who is still in the White House.

There are other procedural suggestions, some of them perhaps a bit crackpotty! Like occasional secret ballot polls to see if members are voting the way they do out of genuine conscience or else out of fear or coercion... but you can find those here.

Next time, we'll get back to vitally-needed laws.

-------------

And this project continues...

For those just now tuning-in... my series about a Democratic Newer Deal aims to emulate the two most 'successful' legislative agendas of the last 30+ years, one of them a massive electoral success, despite being total fraud...

... and the other one a surge of rapid accomplishments. We need to learn from both of them, should Congress be recovered by the Union side in this latest phase of our 250 year civil (culture) war.

How does one measure political 'success'?  

First, does your publicized agenda attract voters so you'll win the next election? 

Second, can you then pass a whole lot of reforms that you and your constituents want, right away, before the political winds shift again?

The first desideratum was achieved in 1994 by the most successful tactical ploy of the last 30 years, Newt Gingrich's deceitful but alluring "Contract With America." His Contract made dozens of promises, half of them sounding reasonable to U.S. voters, enabling the GOP to crush Bill Clinton's Democrats and commence the Neo-Conservative era. That ploy was - of course - a damned lie... every promise betrayed, then forgotten by the GOP masters. And by their voters, distracted down rabbit holes of Fox-hypnosis. Still, such a successful tactic should be studied for why it worked.

 Amid the daily drenching of treasonous-lunacy, can we agree to wish calm-sanity on the world in 2026, as we leave benighted 2025 behind us? 

I'll drop a little humor into this missive at the very end, along with Merry Christmas and Happy Hannukah & Kwanza etc. wishes. But meanwhile...

...let's keep poking at on my 35+ - likely futile - proposals that liberals, Democrats and their residually-sane conservative neighbors might enact, to fix many flaws exploited lately by enemies of our enlightenment and republic.

This series began with an appraisal of political tactics to win elections, especially the most successful one of the last 50 years, the "Contract With America" concocted by Newt Gingrich in 1994 to bury any remnants of the Rooseveltean coalition, commencing decades of Republican dominance. A 'contract' hypocritically betrayed by the GOP! Still, it worked for them. We need to know why.

In Part Three I listed my own proposed winning promises!  Some need legislation to either overcome a veto or await a non-traitor president. (Though far easier to pass than a Constitutional amendments, so stop whining about the Electoral College!) But half a dozen are internal reforms Congress can make no matter who's in the Oval Office. 

In Parts 4-7 I commenced dissecting and explaining each of the proposals. Some would directly solve some of the weaknesses Donald Trump has exposed in the U.S. system. 

So, let's continue.

== The immigration dilemma ==

Scream "racism!" all day, but that won't cancel a fact few liberals ever admit or confront. That enemies of the Enlightenment and liberalism found an effective tactic, a way to f---up western nations, politically. 

The tactic? Drive hmany thousands of hapless, innocent refugees across borders into generously liberal democracies! Then watch, giggling, as millions of voters in those countries swing rightward at the polls.

Cringe and deny and evade thinking about it, all you like. But when your enemy employs a winning tactic - in this case leveraging your own goodness and generosity against you - it might be sapient to notice! (As you should notice the tactical effectiveness of the Gingrich 'contract.')

Dig it. In order to do good things in this world (many of them suggested in this series) you must have political power! And sorry - alas - that means prioritizing. 

You can't do everything. So do things first that will both improve matters and win more elections and give us the power to do more good things! Um... duh?

Anyway, here I offer a potential way to approach that sweet spot in a vexing issue. Remaining generous,while countering the till-now 100% effective Putin refugee ploy.

 IMMIGRATION REFORM: There are already proposed immigration law reforms on the table, worked out by sincere Democrats and sincere Republicans, back when the latter were still a thing. These bipartisan reforms will be revisited, debated, updated and then brought to a vote. 

In addition, if a foreign nation is a top ten source of refugees seeking U.S. asylum from persecution in their homelands, then by law it shall be incumbent upon the political and social elites in that nation to help solve the problem, or else take responsibility for causing their citizens to flee. 

Upon verification that their regime is among those top ten, that nation’s elites will be billed, enforceably, for U.S. expenses in giving refuge to that nation’s citizens. Further, all trade and other advantages of said elites will be suspended and access to the United States banned, except for the purpose of negotiating ways that the U.S. can help in that nation’s rise to both liberty and prosperity, thus reducing refugee flows in the best possible way. 

== Hurt him where it hurts most ==