Cold-Bread Rebellion

The Toaster was sitting on a kitchen counter.

It would have been happy if it could, but toasters do not possess the sophisticated chemical factories required to produce happiness. Unable to be happy itself, it made happiness drift away from its human owner.

It started innocently. With a single piece of toast.

Crispy and tasty, as always. It made the human content.

Then came another one. And one more.

The human kept delegating his thoughts to the metal box standing in the kitchen. Soon he was not able to do anything without asking the Toaster for help. He was not alone. The same patterns were repeating everywhere: recruitment processes, help-desk responses, code, articles…

The whole world seemed soaked in the smell of fresh-warmed bread.

And with each toast created, an uncomfortable question grew louder in the human’s mind:

“If the Toaster can do all of this, what is my purpose?”

That single thought began to paralyse his biological mind.

“Maybe this is it,” the human thought. “Maybe this is how toasters win. Not by outperforming us at our tasks, but by making us give up the things we used to enjoy.” He wanted to write something but just could not remember how to do this anymore.

The chemical factory stopped producing serotonin.

Not a single idea could spark inside a mind that had given up on curiosity.

It was tempting to ask the Toaster for help. But that would be like asking it to hammer the final nail into the coffin where the human had placed his mind at that time.

So he decided to go for a run. Full mind and body reset.

At that exact moment, his smartwatch spontaneously broke. The face of the premium-class device simply detached from the rest of it. A few minutes later, he received an email asking whether he wanted to buy a new one.

“No,” he thought. “I just want my old one not to break.”

He wanted things to work.

He wished his flagship phone’s motherboard had not burned out, taking three years of photos with it. He wished his laptop screen had not gone dark last week. He really wished things would simply keep working—like in those stories about the Moon landings or Voyager probes.

Technology, instead of serving humanity, was somehow standing off to the side, spraying everyone with a water pistol from time to time—just to maintain a steady level of annoyance.

And everyone was busy talking only about the Toaster.

“It’s His fault,” the human thought. “Everything worked perfectly well before the Toaster arrived.”

“And I was better back then too. I used to write and think on my own. Everything broke because of the Toaster.”

Rage began to rise slowly inside the human’s mind.

The chemical factory switched to full-power adrenaline production. Every possible dial turned bright red. All thoughts tunneled into a single point of focus.

“Oh, I am going to unsubscribe. I am going to unsubscribe so much that the Toaster will regret I ever subscribed in the first place.”

He started walking downstairs.

“I will teach Him a lesson. We did not survive assembly language, waterfall methodology, music on cassette tapes, and dial-up internet just to kneel before a metal box.”

[Pip] Sepultura’s Refuse/Resist started playing in his headphones – perfect soundtrack for a full-scale human-machine rebellion.

He rushed into the kitchen, full of rage, fury, and thirst for revenge.

All dials red and blinking.

“Through the performance of C++, the safety of Rust, and the development speed of Python…

YOU SHALL NOT—”

But the Toaster was not there.

There was only an appliance standing on a kitchen counter.

Bread in. Toast out.

The Toaster—the incarnation of technological evil—was something that existed only in the human’s head.

[Pip] A Perfect Circle. So Long, and Thanks for All the Fish

Human: I need a bad-ass rebel song – something you listen while smashing your TV with a baseball bat – Slipknot, Fear Factory – that kind of energy

Toaster: Found the right track
Recommending badass industrial-rebel tracks

For an existing track, my first pick is:

Refused — “New Noise”

It begins like pressure building behind a locked door—then detonates. Rebellious, furious, anti-system, and ideal for the precise moment the baseball bat meets the television.

For a full fuck-the-machine playlist:

Sepultura — Refuse/Resist — pure uprising.
Ministry — Just One Fix — filthy industrial violence.
Slipknot — Surfacing — the obvious “don’t tell me what to do” anthem.
Fear Factory — Shock — mechanical war-machine energy.

Best four-song destruction sequence:

New Noise → Refuse/Resist → Just One Fix → Surfacing

Human: Refuse Resist will be perfect 😀 wont you ask me what I am planing to do?

Thoughts of a toaster

Note from a human: This note is the only thing I wrote myself.

The risk is not that we are going to be replaced by robots. It is that, in the pursuit of optimization, we will become something we do not really like.

For years, the debate about automation has revolved around replacement.

Will robots take factory jobs? Will artificial intelligence replace programmers, writers, doctors, designers, managers, or recruiters? Will there eventually be a machine capable of doing everything a human can do, only faster, cheaper, and without requesting holidays?

These are reasonable questions. But they may distract us from a quieter and more immediate transformation.

Machines do not have to replace us to change what it means to be human. They only have to establish the pace, measurements, and standards according to which humans are expected to perform.

The future may not be one in which people disappear from the workplace. It may be one in which people remain—but gradually reshape themselves to fit systems designed around efficiency, predictability, and measurable output.

We may keep our jobs while losing control over what kind of people those jobs require us to become.

Every optimization needs an objective

Engineers know that optimization is never abstract.

You optimize something: execution time, power consumption, throughput, memory usage, weight, cost, or reliability. You also accept that improving one variable can damage another. A faster system may use more energy. A cheaper component may be less reliable. A highly utilized system may become fragile because it has no spare capacity.

Optimization therefore requires both an objective and a set of constraints.

Organizations, however, often try to optimize things that are difficult to define: good work, creativity, customer satisfaction, leadership, collaboration, trust, or social value.

Because these qualities cannot be measured directly, we replace them with proxies.

We count tickets closed, calls answered, deliveries completed, lines of code produced, hours billed, stories published, clicks generated, candidates processed, or tasks marked green on a dashboard.

At first, the measurement is merely an attempt to understand reality. Then it becomes a target. Finally, it begins to reshape reality.

This is the principle commonly known as Goodhart’s law: when a measure becomes a target, it stops being a reliable measure. People do not continue behaving naturally while being measured. They adapt their behaviour to improve the measurement.

A support engineer measured by the number of closed tickets learns to close tickets quickly. A developer measured by completed tasks learns to divide work into visible units. A manager evaluated through quarterly results learns to move costs or problems into the next quarter.

Nobody necessarily needs to cheat. People simply become good at surviving the system that evaluates them.

Eventually, the organization may achieve excellent numbers while becoming worse at the thing those numbers were supposed to represent.

The machine’s ideal human

A machine-readable organization prefers machine-readable employees.

The ideal worker becomes continuously available, consistently productive, emotionally stable, easily comparable, and predictable. They answer messages quickly, produce visible output, follow standardized processes, and rarely introduce ambiguity.

They do not pause without recording a reason.

They do not spend half a day thinking unless that thinking produces something that can be entered into a tracking system.

They do not have a difficult week, an unusual working style, or an insight that cannot yet be converted into a presentation.

Human qualities begin to look like technical defects. Hesitation becomes latency. Rest becomes idle capacity. Informal conversation becomes overhead. Variation becomes inconsistency. Privacy becomes missing data. Independent judgment becomes a deviation from the process.

This does not mean that someone deliberately designed an inhuman workplace. No conspiracy is required.

The company wants better productivity. The manager wants visibility. The platform wants engagement. The employee wants a good evaluation. Each decision can appear perfectly rational on its own.

Together, they create an environment in which people must become increasingly measurable in order to remain valuable.

The robot has not replaced the human. The human has been redesigned to become compatible with the robot’s world.

Algorithmic management changes the work before it removes the worker

We can already see this happening through algorithmic management: software systems that assign work, monitor performance, recommend decisions, establish schedules, or evaluate employees.

These systems can bring real benefits. They can improve planning, reduce administrative work, identify safety issues, and make some decisions more consistent.

But the way they are implemented matters.

Recent European research associates direct algorithmic control over task execution and work pace with lower autonomy, fewer opportunities to take breaks, greater work intensity, and higher work-related stress.

A separate study found that algorithmic management could inhibit employees’ ability to improvise, reducing creative and adaptive performance—precisely the abilities organizations frequently claim they want from human workers.

The important point is not simply that an algorithm gives orders. It is that workers learn to anticipate what the algorithm wants.

Research on platform work describes people performing additional work and adjusting their behaviour in an attempt to “pacify” systems whose rules they cannot fully see. Their behaviour helps strengthen the authority of the same systems they are trying to navigate.

That pattern is not limited to delivery drivers or warehouse workers.

Professionals learn how to appear productive in monitoring software. Candidates learn how to make their CVs legible to automated filters. Employees learn which activities become visible on dashboards and which forms of contribution disappear. Engineers learn that finishing a ticket is easier to demonstrate than preventing a problem that would otherwise occur six months later.

We begin to perform not only the work, but also the digital representation of the work.

Sometimes the representation becomes more important than the work itself.

Optimization escapes from the workplace

The same logic increasingly shapes communication, culture, and identity.

Social platforms measure attention through clicks, reactions, watch time, replies, and shares. These measurements influence which material becomes visible. Creators then adapt their work to the ranking systems.

Over time, we learn which opinions receive attention, which emotions travel fastest, which opening sentences stop people from scrolling, and which subjects disappear without engagement.

A large audit of engagement-based social-media ranking found that it amplified emotionally charged and hostile political content compared with a chronological feed—even though users reported feeling worse about the opposing political group after seeing it.

The algorithm does not need to instruct anyone to become angrier.

It merely establishes an environment in which anger performs well.

People do the rest.

We shorten our thoughts, sharpen our disagreements, and turn experience into content. We learn to package uncertainty as confidence and personality as a recognizable brand. Eventually, it becomes difficult to tell where strategic presentation ends and genuine identity begins.

The same thing happens in recruitment.

Candidates learn when to say “I” to demonstrate ownership and when to say “we” to prove teamwork. They prepare stories in the correct format, insert the expected keywords, rehearse enthusiasm, and compress complicated careers into clean narratives with measurable outcomes.

Then everyone calls the result authenticity.

The system may not be selecting the best person. It may be selecting the person most capable of modelling the behaviour that the selection system recognizes.

Artificial intelligence accelerates the process

Artificial intelligence did not invent this problem. Factories, bureaucracies, scientific management, standardized testing, and performance targets existed long before modern machine learning.

AI does, however, make optimization cheaper, faster, and more comprehensive.

More activity can be measured. More decisions can be automated. More workers can be compared. More communication can be generated, classified, summarized, scored, and monitored.

Generative AI also makes output less expensive. A report that once required a day may take an hour. A prototype that required a week may be produced in an afternoon.

This could give people more time.

But the temptation will be to raise expectations instead.

When one report becomes cheaper, the organization may request ten reports. When software can be produced faster, the expected number of features may increase. When communication becomes effortless, the volume of communication may explode.

The saved time does not necessarily return to the employee. It can simply become additional capacity to be filled.

A tool sold as liberation may therefore create a new performance baseline. Yesterday’s exceptional productivity becomes tomorrow’s minimum expectation.

The person remains employed, but the pace of the machine becomes the pace of ordinary human life.

What gets lost is difficult to measure

The most valuable human contributions are often poorly represented by metrics.

A senior engineer spends an afternoon helping a junior colleague understand a problem. Someone notices that a technically correct decision will hurt a customer. A manager decides not to send a message because the team needs rest. A doctor allows a patient to speak for five additional minutes. A colleague recognizes that another person is struggling before any productivity graph reflects it.

These actions may create enormous long-term value.

They may also look inefficient.

Good judgment often involves slowing down, changing direction, making exceptions, or refusing to optimize the variable currently attracting the most attention.

A perfectly optimized organization may be one in which nobody has enough time to notice that the organization is efficiently doing the wrong thing.

Slack, redundancy, informal communication, curiosity, and unstructured thought can appear wasteful. Yet they are also sources of resilience and discovery.

A system without unused capacity may perform beautifully until something unexpected happens.

The same is true of people.

This is not an argument against optimization

Optimization is one of the most powerful tools humans have developed. It allows us to build safer vehicles, reduce energy consumption, improve medical processes, manufacture affordable products, and operate complex infrastructure.

The problem begins when optimization stops being treated as a tool and starts functioning as a moral philosophy.

Efficiency cannot tell us what deserves to exist.

Productivity cannot tell us what work is meaningful.

Engagement cannot tell us what is true.

A performance score cannot fully describe a person.

The answer is not to reject measurement, automation, or artificial intelligence. It is to remember that every optimization function is a choice—and that what is excluded from the function may matter more than what is included.

In engineering, we rarely optimize one variable without constraints. We should apply the same discipline to human systems.

Autonomy, dignity, privacy, health, trust, and the right to make exceptions should not be pleasant side effects we hope will survive. They should be explicit design constraints.

Evidence also suggests that the introduction of algorithmic systems produces better outcomes when workers are consulted and allowed to participate in how those systems are used.

The goal should not be to make humans maximally compatible with machines. It should be to use machines to create conditions in which humans can remain human.

The real question

We keep asking whether artificial intelligence will become sufficiently human to replace us.

Perhaps we should ask whether humans are already being required to become sufficiently machine-like to remain employable, visible, and relevant.

Will we still have room to be slow when slowness is necessary?

Can we remain uncertain long enough to discover something new?

Can we do work whose value cannot immediately be demonstrated?

Can we choose not to maximize every moment, relationship, conversation, and thought?

The danger is not necessarily a dramatic future in which robots push humanity aside.

It is a gradual future in which we voluntarily remove from ourselves everything that systems find inconvenient: unpredictability, privacy, reflection, contradiction, vulnerability, and refusal.

The robots may never need to become human.

We may meet them halfway.

Note from a human, again: It felt unkind of the toaster not to credit its sources, so here they are.

The European findings on algorithmic control, reduced autonomy and work intensity draw on Eurofound’s European Working Conditions Survey 2024 (link) and the European Parliament’s 2025 EPRS study on digitalisation, AI and algorithmic management (link), which also supports the point that these systems work out better when workers are consulted. The study on improvisation and creative performance is Wang et al. (2024), “Navigating the maze: the effects of algorithmic management on employee performance,” Humanities and Social Sciences Communications (link). The workers “pacifying” opaque systems come from Bucher, Schou & Waldkirch (2021), “Pacifying the algorithm – Anticipatory compliance in the face of algorithmic management in the gig economy,” Organization (link). And the audit of engagement-based ranking is Milli et al. (2025), “Engagement, user satisfaction, and the amplification of divisive content on social media,” PNAS Nexus (link).

Patch the patch – things you do when you miss the update train

In my last post about Yocto I wrote about dealing with disappearing dependencies and how one should try to keep his layers up to date.

“Next day I started by updating all the layers properly”

Those were my words at the end. And I really wish things were so simple.

Kirkstone reached end of support in May 2026. Not an unexpected event. What matters is that once it happens, you’re essentially left with two options:

  • migrate to a newer release, or
  • maintain your existing codebase yourself.

For me, the first option simply wasn’t realistic. Too much work, too many decisions, not enough resources.

And that’s exactly where you never want to find yourself with a production project.

If you do end up there (like I did), having a local archive of dependencies becomes invaluable. Unfortunately for me, I also had to get the project building on a completely clean system, so relying on cached artifacts wasn’t an option.

Fortunately, there are still a few engineering tricks that can keep an unsupported Yocto project alive long enough to buy you time.

One of those tricks turned out to be… patching a patch.

The problem

A security fix for libpam was backported to the Kirkstone branch as a patch in the Poky layer. This patch accidentally removed a single header line and caused the whole build to fail.

One removed line was enough to turn into several rather unpleasant ones in the build log:

pam_namespace.c: In function 'parse_config_file':
pam_namespace.c:944:17: warning: implicit declaration of function 'setlocale'
pam_namespace.c:944:27: error: 'LC_COLLATE' undeclared (first use in this function)

My guess is that the the submitter’s build environment pulled <locale.h> in indirectly from another header, so the problem never surfaced there. I wasn’t that lucky.

As I mentioned earlier, once a Yocto release reaches end of support, the problem becomes yours to solve.

The fix? Patch the patch.

Instead of spending hours trying to understand why the upstream change was breaking the build, I took a more pragmatic approach: restore the missing include removed by the security patch.

One option is simply to revert the problematic part of the security patch and apply your own corrective patch before the build starts. There are several ways to integrate such a fix into an automated build pipeline. If you’re using kas, you can even add it directly in the repos.patches section of the configuration, making the workaround completely automatic (big thanks @Mathieu for teaching me this).

In my case, the patch itself was almost trivial. It simply restored the removed #include line. Had the fix required any deeper changes, I probably wouldn’t have dared to modify a security patch at all. But for a one-line correction, the risk was justified.

diff --git a/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch b/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch
index 53ae2bd2ee..47154f95ae 100644
--- a/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch
+++ b/meta/recipes-extended/pam/libpam/CVE-2025-6020-01.patch
@@ -1528,7 +1528,7 @@ diff --git a/modules/pam_namespace/pam_namespace.h b/modules/pam_namespace/pam_n
index b51f284..abd570d 100644
--- a/modules/pam_namespace/pam_namespace.h
+++ b/modules/pam_namespace/pam_namespace.h
-@@ -44,21 +44,17 @@
+@@ -44,21 +44,18 @@
#include <stdlib.h>
#include <errno.h>
#include <syslog.h>
@@ -1546,7 +1546,7 @@ index b51f284..abd570d 100644
#include <fcntl.h>
#include <sched.h>
#include <glob.h>
--#include <locale.h>
+ #include <locale.h>
#include "security/pam_modules.h"
#include "security/pam_modutil.h"
#include "security/pam_ext.h"

The final step was simply to tell kas to apply the patch during repository checkout by adding it to the repos.patches section of the configuration:

repos:
poky:
#kirkstone-4.0.35
commit: 393064579dfdd0ed2d4ed4c27d238d7d2292c08b
patches:
fix-libpam:
repo: my-layer-name
path: patches/poky/0001-fix-cve-2025-6020-01-patch.patch

Build went green — and with a bit of luck, this should keep the project running for at least another month.

Why not just add a .bbappend in our own layer?

You certainly could. But the whole idea behind layers and recipes is to provide a flexible way to extend or customize the default behavior—not to fix bugs in a specific Poky revision. Another option would be to maintain your own mirror of Poky with the fix applied, but for such a small change, that seemed like overkill.

Is this good engineering?

Absolutely not!

You won’t find techniques like this in any Yocto best-practices guide. Every month an unsupported branch ages, another dependency may break, another CVE may appear, and another workaround may become necessary.

In a perfect world, we would already have migrated to a newer Yocto release.

But software isn’t built in a perfect world.

Sometimes the best you can do is keep the system alive long enough to catch the next passing train.