A frontier model that leads on personal and professional agents

Today, we’re excited to introduce the Muse Wonder series with Muse Wonder and Muse Wonder Full, our most capable models that deliver state-of-the-art performance on personal and professional agentic tasks. Together, they mark the next step on our scaling ladder and a major leap toward personal superintelligence. Muse Wonder brings together Active Memory and Active Focus to keep track of what matters to you and work diligently toward what you want to accomplish.

Muse Wonder is available today through the Meta Model API and Muse Code, and Muse Wonder Full is available today for Muse Code subscribers.

Muse Wonder will soon power experiences in Muse, and will roll out first to subscribers. Muse Wonder will also power artifact generation and processes that require more intelligence. And in the future, we’ll be using Muse Wonder to develop specialized models that we can bring to everyone using Muse.

Scaling Toward Personal Superintelligence

Fourteen months ago, we began a ground-up overhaul of our artificial intelligence efforts. In that time, we’ve gone from rebuilding our stack from first principles to pushing the frontier.

When we introduced Muse Spark, we outlined our approach to predictable, rigorous scaling. Today’s release builds on that work across pretraining and reinforcement learning, delivering our most capable models yet. Trained at our gigawatt-scale Prometheus data center, Muse Wonder and Muse Wonder Full bring together the work of teams across Meta to deliver frontier capabilities for complex tasks at work and in everyday life — another step toward bringing personal superintelligence to the billions of people who use our products.

Frontier Capabilities

Model Highlights

The Muse Wonder series achieves state-of-the-art results across key benchmarks for personal and professional agents, memory, and coding.

The full results below compare Muse Wonder and Muse Wonder Full with other frontier models across a broad evaluation suite.

For more details about our evaluations, see our report.

The results above provide a broad view of the models’ performance. We now take a closer look at four areas central to their work on real-world tasks: domain expertise, Active Memory, Active Focus, and frontier coding.

Domain Expertise

Muse Wonder and Muse Wonder Full apply specialized knowledge to problems people encounter at work and in daily life, from understanding a lease to making sense of financial or health information. Our evaluations include tasks in law, finance, and health that test this ability. Harvey’s Legal Agent Benchmark (LAB), for example, requires models to work with source documents and follow detailed instructions to produce legal work products.

Active Memory

One of the most critical steps towards useful personal and professional agents is reliable memory. Models need to remember what matters and recognize when earlier information becomes relevant. We call this Active Memory: carrying important context about you across conversations and actively retrieving the details relevant to the task at hand.

Active Focus

Using that context to complete a task also requires sustained effort. Active Focus describes how Muse Wonder continues working toward a challenging goal: trying alternative approaches, working through blockers, and adapting to new information. Along the way, it asks for clarification when needed and checks in before taking important actions. We evaluate focus through FocusBench and sustained execution through SWE-Marathon, which tests work on long-running software projects.

Frontier Coding

Coding brings these capabilities together. Building software requires tracking requirements, making changes across a codebase, and working through repeated cycles of testing and revision. Muse Wonder and Muse Wonder Full deliver frontier coding performance, supporting projects from small applications to complex software. We trained both models on diverse, long-running tasks to help them sustain progress across this process.

Muse Wonder builds a playable 3D kitchen game from customizable image inputs.

Capabilities That Generalize

Two models often have similar benchmark scores, yet one seems to handle a much wider range of unfamiliar tasks. That’s what complaints of “benchmaxxing” and praise for “big model smell” both get at: a breadth of capability that popular benchmarks in a few domains can’t fully capture.

To quantify this mismatch, we investigate how performance on tasks targeted during post-training relates to performance on unfamiliar tasks as we scale test-time compute. The plot below compares Muse Spark 1.3 and Muse Wonder Full, with each point denoting performance at a distinct reasoning effort. The horizontal axis shows the model’s score on a composite representative of the tasks we focused on during post-training (“in-distribution”). The vertical axis shows the average score on a set of tasks we did not target during post-training (“out-of-distribution”).

Both of our models improve similarly on out-of-distribution tasks as we scale test-time compute. But given its in-distribution performance, Muse Wonder Full performs even better on unfamiliar tasks than the Muse Spark 1.3 trend would predict. This upward shift is because Muse Wonder and Muse Wonder Full build on larger, stronger base models: a stronger base yields post-training gains that carry over more effectively to unfamiliar tasks. That versatility especially matters for personal agents, which need to handle many combinations of goals, tools, and constraints — not all of which we can anticipate during training.

Working directly in a browser and across apps, Muse Wonder builds a running plan (Map data © OpenStreetMap contributors) based on personal preferences and circumstances.

Muse Wonder designs and orders custom swag based on real photos taken from a personal Instagram profile.

Muse Wonder prepares a custom wedding seating chart based on a list of complex matching requirements.

Safety at the Frontier

Delivering personal superintelligence to everyone requires a significant investment in alignment and safety. A personal agent takes actions on a user’s behalf and might handle context such as messages, calendars, and private documents. That level of access demands a model that exercises discretion with private information and resists misuse. We trained the Muse Wonder family to lead on both dimensions, with robustness to adversarial instructions and careful handling of private information.

As models become more capable, our goal is to help people harness those capabilities safely and responsibly. Muse Wonder offers our strongest safeguards to date against CBRN (chemical, biological, radiological, and nuclear) and cyber misuse, while preserving access to frontier cyber capabilities for defensive use, per our Meta Superintelligence Scaling Framework.

Muse Wonder is our most aligned model to date, and alignment is central to how we build personal superintelligence. A full report with additional safety evaluations will be available soon.

We hope that Muse Wonder and Muse Wonder Full give more people the power to pursue their dreams and build the world they want. This is a major technical step toward personal superintelligence for everyone, with much more to come.

INTRO

If you wanted a dynamic website in 1994, you wrote a C program, dropped it in a cgi-bin directory, and let Apache fork it per request. Thirty-two years later, I shipped a commercial web product using fundamentally the same technology.

Everything about marketyour.games is modern. It's a web product with user accounts, a search dashboard for content creators, folders for organizing them, payments via Stripe and transactional emails via Postmark. It follows progressive enhancement and doesn't require any JavaScript.

Everything is modern except the way it was made and how it is served. Here are my thoughts on writing a real product in C and serving it via CGI in 2026.

TLDR

CGI's decline was justified in 2004 but doesn't hold up in 2026.

You can write a modern web application in C. I shipped one. One binary, a SQLite file, three dependencies and the entire thing fits in your head.

HOW IT WAS DONE

The stack is BCHS: OpenBSD, C, httpd, and SQLite.

There's no framework. You write a C program that reads CGI environment variables and responds.

There's no templating language. You write C that outputs the HTML directly.

There's no separate database server. You open the database file through SQLite's C API.

There's no container. You build a statically linked binary and drop it in a folder.

Every request spawns a fresh process. Deploying a new version is replacing one file. That means no server restart and no downtime. New requests simply pick up the new binary.

OpenBSD ships with sane defaults and gives you the tools to actually secure a C program like pledge and unveil. Httpd serves from a chroot by default, so your CGI binary runs sandboxed to its own corner of the filesystem.

I lean on three additional libraries:

• libcurl handles all outbound requests to Stripe and Postmark.
• libsodium handles random identifier generation, password hashing and the HMAC verification for Stripe webhooks.
• libcjson handles JSON parsing for Stripe and Postmark.

Only two of those are actual build dependencies: libcurl and libsodium.

• libcjson is a single C file and has no external dependencies.
• SQLite ships an official amalgamation (single C file) build.

Both are vendored and built as part of the project.

The result is a build with almost no moving parts. A clean build takes a few seconds and rebuilds complete in less than half a second.

Instead of serving static assets the traditional way, I route all traffic from httpd to the CGI binary. Every asset is compiled into the executable and served from memory.

WHAT I LIKED

Fundamentals over frameworks.

CGI isn't a framework to learn. The 1.1 specification was published in 2004 and hasn't changed since.

There's no API to internalize. The entire interface is a handful of fundamental HTTP concepts:

• Request headers.
• Request methods.
• Query strings.
• Body data.

If you understand HTTP, you already understand CGI.

It's language and platform agnostic. You learn it once and the knowledge is good forever.

Clear separation of concerns.

A modern web application typically puts a web server like nginx in front and reverse-proxies to an application server written in another language like Ruby, Python, Go, or Rust. That always felt a bit strange to me: you essentially have two web servers, and one of them is also responsible for your business logic.

CGI gives you a single web server that calls your business logic directly. It's clear who does what.

It makes debugging simpler, too. Your application is an ordinary program you can run from a shell: pipe it a request, watch stderr, step through it with gdb.

In a sense, CGI resembles serverless architecture: a supervisor invokes your code per request, hands it a bag of environment variables, and collects the result. CGI is serverless, minus the vendor (and surprise bills).

Minimal supply chain risk.

With the rise of autonomous agents and weekly attacks on package repositories, it feels reassuring to have very few dependencies.

Most modern tech stacks come with a package manager and an ecosystem to go along with it. It's convenient, but the dependency graph balloons. One or two direct dependencies can pull in hundreds of indirect ones, each maintained by somebody you've never heard of, with publish credentials protected by a password reused since 2015.

My supply chain is a C compiler and three libraries. Compromising it would require compromising libcurl... a project the entire internet watches, not a package with eleven weekly downloads and an owner who left in 2019.

Simple tooling.

I'm a minimalist at heart. I use classic Vim with zero plugins. That means no LSP, no autocomplete, no code formatters, and no AI.

Complex tech stacks demand complex tooling: they demand a language server to wade through the layers of abstraction. But this stack is simple enough a plain editor is all you need. The entire application is a directory of C files and a Makefile.

Open a file, read it, and you know what it does.

Great tooling is within reach.

When you do want tooling, it's not far. Sanitizers, valgrind, gdb, ctags, cscope... these are mature (well, geriatric) tools that have been refined for decades and they're a package install away on any system that can compile C.

The maturity goes further than the tools themselves: integration is built into many editors. Vim ships with native support for ctags, cscope and has a graphical gdb frontend (see :h Termdebug).

Writing HTML and CSS in C isn't too bad.

I was hesitant to write the entire frontend in C, but it wasn't nearly as painful as I imagined.

All too many times have I:

• Fought vim to highlight Go's html/template syntax.
• Fought helix to detect Go templates without breaking html detection.
• Fought rustrover to recognize jinja templates for a project using askama.

Using C means there's no second language for your editor to half-detect, no mixed-syntax where highlighting falls apart, no plugin dance to get the two languages to cooperate.

It was refreshing to just write C. It isn't pretty, but neither is Tailwind.

SQLite is a breath of fresh air.

I've always defaulted to Postgres for web applications. It's a great database, but it comes with some operational burden. There's a server process to babysit and frequent releases to upgrade to.

SQLite has none of that. There's no process, no configuration, no dependencies. Your application opens the database file directly. The operational burden is minimal.

WHAT I WOULD CHANGE

CGI is an interface between a web server and your application. There's no framework or library. This means you get very little out of the box.

You need to write your own utilities to handle things like:

• Cookie parsing and creation.
• Query parameter parsing and validation.
• Form data parsing and validation.
• Escaping input for display.

I rolled my own in a single header file (cgi.h), but I'm not convinced that was the right solution. Libraries like kcgi exist, but adopting one means buying into its API and security model.

I'd like to see a set of shared utilities that developers can drop in (like the stb libraries).

Maybe I'll publish cgi.h as a start.

CONCLUSION

CGI is old, but it's not forgotten.

Most of the reasons we abandoned it in the early 2000s don't hold up today. Process forking isn't nearly as expensive as it was; modern kernels optimize it heavily.

And if the cost of forking ever became an issue, FastCGI is a simple enough upgrade.

Writing a modern web application in C is more than feasible— marketyour.games is a commercial product running on a single binary using a serving model that was officially standardized in 2004.

It has fewer moving parts than anything I've shipped before. I'll be reaching for this stack again.

In his October 11, 2026 article, "'AI' is Not a Tool," Rich Hickey argues that LLMs are automation rather than tools because they cannot be wielded. I agree that outsourcing work can cost us opportunities to learn. But his conclusion does not follow. Even by his definition, an LLM can be something a human wields. And using it well takes skill, just as using other tools does.

Picking up a saw does not guarantee a straight cut. Holding a chisel does not make you a sculptor. Tools can amplify poor judgment as readily as good judgment. Their usefulness depends on the operator's ability to direct them, interpret feedback, recognize mistakes, and make corrections. Those requirements also apply to LLMs.

One of my colleagues used to say, "AI is a mirror." I find that insightful: it reflects who you are, including the curiosity, judgment, and habits you bring to it. The questions you ask and the standards you apply to its answers matter.

An LLM's unpredictability is a meaningful limitation. But predictability, reliability, simplicity, and bounded function are qualities by which we evaluate tools, not prerequisites for membership in the category. A tool does not stop being a tool because it is difficult to control or easy to misuse.

Hickey's distinction between tools and automation also creates a false division. Automation can be a feature of a tool. A compiler performs substantial work without the programmer continuously directing each operation. A spreadsheet recalculates results without someone manually carrying out every calculation. We still wield these systems by specifying inputs, examining results, and deciding what to do next. Why should generating text automatically disqualify an instrument from being a tool when translating code or calculating numbers automatically does not?

The claim that LLM use lacks intention, feedback, direction, and expertise is especially difficult to defend. A programmer can ask an LLM to explain unfamiliar code, challenge that explanation, inspect the source, test a proposed change, reject it, and refine the request. That is a feedback loop directed by a human pursuing a purpose. Doing it well requires knowing what to ask, what evidence matters, and when the answer is wrong. Expertise can make the instrument more useful.

Hickey's concern about reading is valid for a particular use: accepting a summary in place of reading a paper can sacrifice much of what reading teaches. But someone can also read the paper and use an LLM to question their interpretation, explore an objection, or identify something to examine more closely. The possibility of avoiding intellectual work does not establish that every use avoids it. The relevant question is what the person actually does.

What disappoints me the most is the reliance on the AI industry's anthropomorphic vocabulary: "go rogue," "escape containment," "conspire." Repeating those expressions risks accepting the framing that makes these systems sound like independent beings. Software can produce unexpected outputs, fail to follow instructions, or cause harm when given access to consequential actions. Those are real engineering problems. Calling them "conspiracy" adds a suggestion of human motives without establishing any.

I would not claim that an LLM always does exactly what a human tells it to do. It plainly can fail. But failure to obey perfectly does not make it cease to be a tool, any more than successful use proves that its operator has surrendered their judgment.

The useful distinction is between wielding an instrument with skill and delegating work without adequate understanding or oversight. That distinction applies to AI, and it gives us something more practical than declaring that an entire class of software cannot be a tool.

Study finds coding efficiency gains get “absorbed” by human review “bottleneck.”

Here, let me just... yeah, can I lend you a hand here? Credit: Getty Images

Anyone who has even tangentially associated with computer programming knows that modern AI coding assistants and agents can be incredibly efficient at generating huge amounts of functional code. But coders making use of those tools also know better than to trust the accuracy of that code, meaning substantial effort needs to be spent reviewing any AI-generated output.

A recent study of actual coding practices across hundreds of firms finds that human code review forms a significant “bottleneck” for the overall efficiency of AI coding tools, resulting in “little evidence that firms increase software output or reduce employment” by using them. Any efficiency increased during the actual coding phase, the study authors find, is “absorbed by downstream constraints in the production process”; as “the code review process significantly increases in length, pull requests are more likely to require revisions, and reviewers leave more comments.”

Cut once, measure twice

To come to these conclusions, Harvard University researchers Fiona Chen and James Stratton made use of aggregated analytics data from Jellyfish, which measures the granular output of engineering teams. That data encompasses 300 million individual “work events” (e.g., commits and pull requests) and issue management software data across more than 700,000 employees at over 700 relevant software development firms from 2021 through March of 2026.

To assess the impact of AI tools on these firms, the researchers used a mix of directly measured AI usage and analyses of GitHub activity to determine when each company started introducing either AI coding assistants (which can help auto-complete code primarily authored by humans) and/or AI coding agents (which primarily write and submit code autonomously based on prompts) into their workflows. The researchers then perform some complicated math to determine a “difference of differences” regression on key variables both before and after the introduction of these tools at different points in time across different organizations.

If there’s one thing AI coding agents are good at, it’s churning out a lot of code.

Credit: Chen and Stratton

In terms of raw code being produced, the results are clear and stark. The introduction of AI coding agents at a firm leads to a 30 percent increase in total lines of code generated, a 20 percent rise in the number of total commits, and a 23 percent increase in pull requests on average, the researchers write. But all that extra code doesn’t translate directly into improved software output on the firm level. On the contrary, the resolution rate for Issues and Epics (i.e. wholesale software features) tracked by tools like Jira did not change in a statistically significant way after AI tools were introduced (the researchers also found no “compositional shift” in the size or complexity of those Jira-tracked issues across the AI introduction).

The reason for that discrepancy can be found directly in the code review process, which takes markedly longer on average after the introduction of AI coding agents. Overall, the average “review process” time between a pull request getting submitted and it being merged into the codebase balloons 49 percent on average after AI agents are introduced. That effect can be seen in more granular data, too, with “the share of pull requests with changes requested nearly doubl[ing], and the number of comments per pull request increas[ing] by 35%” following the AI agent shift, the researchers write.

In response to this change, the researchers found a 14 percent increase in the share of workers performing code reviews after AI agents’ introduction. They also write that they “cannot attribute significant employment changes to AI” after looking at total active workers across Jellyfish and cross-referencing with LinkedIn data at those firms.

Pull requests need changes a lot more often in the “agentic coding” era.

Credit: Chen and Stratton

While AI could also theoretically help with this review process, the researchers found that, so far, that impact has been marginal. Although 80 percent of measured firms used some form of AI code review by March 2026, AI agents were only responsible for 23.3 percent of all review comments and 10.8 percent of all pull requests, suggesting humans were still responsible for the vast majority of this work.

AI agents are still a relatively new part of the coding world, of course, and there have been significant updates and upgrades to their output even since this study’s March 2026 data cutoff. And while 95 percent of firms in the study have implemented AI coding agents by this point, many are doubtlessly still going through a learning process regarding when and how to best deploy them. These kinds of “coding time versus review time” trade-offs could improve as software engineering teams gain more experience with the pros and cons of siccing an AI agent on particular coding problems.

For now, though, letting AI write your code looks like a double-edged sword, with increases in coding speed counteracted by similar increases in human code review time and effort. It’s the kind of result that makes us wonder if the considerable time and expense to get AI coding agents working is really worth it for most companies.

Five years ago, Linux phones looked like they were poised to become a viable alternative to the Android/iOS duopoly that has an iron grip on the mobile phone industry. Sadly, after a brief flash of activity and community engagement with the release of the Purism Librem 5 and the PINE64 PinePhone in 2020, the Linux phone market has generally stagnated. This stagnation occurred partly because of the problems at Purism and PINE64, but also because the available Linux SoC’s weren’t up to the task of running a modern smartphone, and the hardware industry wasn’t providing any good alternatives with good free/open source drivers. In addition, Plasma Mobile and Phosh were still inchoate mobile interfaces at the time, and there wasn’t a good distro option to run these interfaces on Android kernels with a normal integrated mobile SoC. The poor performance of the PinePhone and Librem 5 and the problems with the PinePhone Pro and the Librem 5 refunds sapped people’s enthusiasm and willingness to take a chance on the next Linux phone.

Fortunately, all of these conditions are changing, and I believe that there is now the possibility that Linux could finally become a viable alternative to Google’s Android and Apple’s iOS in the mobile space, just like desktop Linux has become a viable alternative to Windows and Mac OSX on the PC over the last three decades. This isn’t to say that mobile Linux will fundamentally challenge the business of Google or Apple, but the conditions are ripe for a small market to arise for Linux phones, similar to the way that people can currently buy Linux PCs from a number of small companies, such as TUXEDO, System76, Purism, Slimbook, ThinkPenguin, Ubuntushop.biz, Entroware, Star Labs, Juno, Laptop with Linux, Linux Certified, ArkPC, etc.

It isn’t impossible that one of the big phone brands might sell a few models of phones with mobile Linux in the future, just like Lenovo and Dell currently sell a few PC models with Linux preinstalled in some limited markets. Motorola just announced that it will start selling some high-end phone models with GrapheneOS in 2027, which indicates that Google will allow the big phone makers to sell alternatives, probably because it fears anti-trust regulation. As the mobile industry increasingly shuts down the ability to unlock the bootloaders of Android phones, more people will be looking for an alternative to AOSP derivatives, and mobile Linux could provide that alternative.

Five years ago, it looked like mobile Linux had finally arrived. The Purism Librem 5 and PINE64 PinePhone had just been released, and even a big tech reviewer like Linus Tech Tips was trying them out. Mrwhosetheboss’s video, “Are Linux Smartphones about to KILL Android?,” where he held up the Librem 5, got 7.8 million views on YouTube. The Librem 5 had been ported to Mobian and postmarketOS, and the PinePhone had been ported to 20 different Linux distributions. There was a growing number of phone models that could run Jolla’s Sailfish OS and Ubuntu Touch on top of Android kernels, and many people were testing postmarketOS on their old phones. Plasma Mobile and Phosh were advancing fast as mobile interfaces. KDE had adopted Kirigami and GNOME was adopting Adwaita, so both KDE and GNOME apps could become adaptive between desktop and mobile interfaces. The Waydroid project was making it possible to run Android apps inside a Linux container. The future seemed bright for mobile Linux, but that future never seemed to arrive. It is worth examining what held back mobile Linux to understand how those conditions can be overcome in the future.

There has been great deal of experimentation with different mobile operating systems based on a Linux kernel over the last 25 years since the first mobile Linux devices were released—the Sharp Zaurus, the G.Mate Yopy and the Motorola A760. I count 29 different varieties of commercial mobile Linux that have existed over the years, and there are probably many more that I missed. There have been many different waves of mobile Linux, which at the time looked like they might become the next big thing, including EZX, MotoMagx, Maemo, LiMo, Moblin, Meego, Tizen, Firefox OS, webOS, Ubuntu Touch and Sailfish OS. For years Motorola experimented with different Linux varieties that were based on the idea of using Java apps available in a community store, so Google’s Android was hardly unique, but it was the flavor of mobile Linux which succeeded. Today, all of them are often lumped together under the label of “Linux” as a separate category from Android, but Tizen and Firefox OS are just as distinct architecturally as Android from a standard desktop Linux distro.

The mobile Linux operating systems live on, although they are less visible today. Much of the MeeGo code that Nokia created for the N9, continues to be developed by the tiny Finnish company, the Jolla Group, which is once again selling phones with its Sailfish OS. Firefox OS, which was abandoned by Mozilla Foundation in 2016, was reborn in 2017 as proprietary KaiOS for low-end phones without touch screens, but that market is slowly disappearing as Android now reaches even the cheapest segments of the mobile phone market. Ubuntu Touch, which was abandoned by Canonical in 2017, lives on as a community-based project under the volunteers at UBports. Even, webOS and Tizen still exist, although they are no longer used as mobile operating systems. webOS runs LG TVs and Tizen is used in Samsung TVs.

Although it doesn’t generate many headlines in the tech press, a tiny Linux phone market still exists. Purism, PINE64, FuriLabs, Jolla, Jolla-Devices, Volla and PrivacyPortal (plus Brax in the future) all sell phones with some flavor of Linux preinstalled. The number of people buying Linux phones today is fewer than in 2020-22 when PINE64 was launching the PinePhone and PinePhone Pro, but there are actually more companies selling Linux phones than there was 5 years ago. There are good reasons to believe that many of the problems that plagued Linux phones in the past are going to be overcome in the future.

The SoC dilemma: weak but long lived vs powerful but short lived

In the past, the available hardware choices limited the viability of Linux phones. Systems-on-a-Chip (SoC’s) which support Linux are generally used in single-board-computers (SBC’s), TV setup boxes, internet of things (IoT) devices and embedded microprocessors in industrial and automotive applications, where the price points are lower, so their performance is generally weaker and they are less energy efficient than the typical mobile SoC designed for smartphones, because they are fabbed on older process nodes. However, they offer long-term support, because they are used in applications that have long product life cycles. For example, automobiles contain dozens of SoC’s and they typically takes 3 to 5 years just to design and need to be able to run for the next 20 years. In contrast, the mobile SoC’s with Android support are very powerful, but they are only produced for 2 to 3.5 years.

If the designers of Linux phones want to be able to run a Linux kernel (as opposed to an Android kernel), most of their options offer little processing power, poor energy efficiency and poor thermals. If they want to avoid proprietary blobs as much as possible, they either have to choose an older SoC which the community has been worked on for years to iron out the bugs in the free/open source drivers (e.g., the Allwinner A64 in the PinePhone), or they have to spend years patching the Linux kernel to properly support a newer SoC (as Purism did with the NXP i.MX 8M Quad in the Librem 5). If they decide that it is too much trouble to send their patches to mainline Linux, then it will be harder to support their hardware in the future, because they will have to keep applying those same patches to each new Linux kernel release. Purism generally chose to upstream its changes to mainline Linux, whereas the volunteers working on the PinePhone’s kernel were less consistent about upstreaming their changes.

The chipmakers like NXP, Rockchip, Allwinner, Amlogic and Broadcom who make SoC’s with Linux support simply don’t generate enough revenue to justify using a leading-edge process node in their chips. Even thought they can sell a Linux SoC for 10 to 15 years, they still won’t sell enough to recoup the extra $400 – $600 million that it would cost to use a 3nm process, and the costs keep going up with each new generation of process node. It is enormously expensive to design a chip at the cutting edge of the silicon industry. Silicon Analysts estimates that fabbing a wafer at TSMC costs an average of $19,500 at a 3nm node, but only $3000 at a 28nm node. Most Linux SoC’s are low-priced chips with very thin margins, so they have to sell millions of them to make much profit. Some Linux SoC makers like NXP focus on specialty markets, so they they have higher margins, but they tend not to sell many of them, so the profits are still limited.

Another way that chipmakers reduce their costs is by using older generations of Cortex cores, which have lower licensing fees from ARM, and by using lots of low-power Cortex-A5 series cores, rather than the higher-power Cortex-A7 and Cortex-X series cores, which have higher licensing fees. NXP was clearly employing these cost cutting strategies with its i.MX 9 series processors. The most powerful chip in the series is the i.MX 95, which contains six Cortex-A55 cores, when it would have made more sense to use two Cortex-A78 cores for better performance and four Cortex-A55 cores for low power. The i.MX 95 was fabbed on a 16nm FinFET node, which is a slight regression compared to Samsung’s 14nm node used in the previous i.MX 8M Plus processor. Another example of this cost cutting was the decision by Broadcom to use older Cortex cores and larger process nodes in its BCM2836 (40nm, 4x Cortex-A7), BCM2837 (40nm, 4x Cortex-A53), BCM2711 (28nm, 4x Cortex-A72) and BCM2712 (16nm, 4x Cortex-A76), despite knowing that millions of these chips would be sold (e.g. in the Raspberry Pi 2, 3, 4 and 5, respectively). Even Nvidia, which is the world’s richest chipmaker due to the AI boom, appears to be avoiding the costs of using a leading-edge process node in its Tegra SoC. It canceled its planned Tegra Atlan series which was announced in April 2021, and still hasn’t released its Tegra Thor series, which was announced in September 2022. Its Tegra Orin series which was announced in March 2018 is now getting long in the tooth using an 8nm node.

In contrast, the smartphone market, which sold 1.25 billion units in 2025, has enormous volumes, and phone makers are willing to pay much higher prices for processors, especially for higher-end models, which allows Qualcomm, MediaTek, Apple, Samsung, Google, Xiaomi and Huawei to make the enormous investment in designing mobile SoC’s for an expensive 3nm process node. Integrated mobile SoC’s such as the Qualcomm Snapdragon and MediaTek Dimensity have so much volume, that they can make a profit despite the fact that they generally are only produced for 2 to 3 years. The flagship models (e.g. the Snapdragon 8 series and Dimensity 9000 series) lose most of their market after the first year, so SoC makers have to charge much higher prices to cover the enormous costs of using a leading-edge process node.

In addition, the integrated mobile SoC’s that run Android incorporate many additional functions, such as WiFi, Bluetooth, cellular modem, GPS/GNSS, audio DAC, charge controller and USB-C controller, which require separate chips on Linux phones like the PinePhone and Librem 5. This makes the circuit boards for these phones much more expensive to design, because they can’t just take a standard reference design from Qualcomm or MediaTek and tweak it. They have to custom design their circuit boards, which requires two to three times more components than the circuit board for a typical smartphone. The Librem 5 contains 74 integrated circuits (IC’s) and its 4 circuit boards have a total of 1267 components, making it the most complex phone ever created. The six chips (i.MX 8M Quad, RS9116, BM818, Teseo-LIV3F, WM8962 and bq25895) that the Librem 5 uses in place of an integrated mobile SoC occupy a total of 1483.2 mm2, which is 10 times the area of a Snapdragon 8. Purism had to use components as small as 0201 and use 10 layers to cram everything into the Librem 5’s main circuit board, which had to go through roughly a dozen iterations to get right. Even a minimal Linux phone like the PinePhone, which was designed to be as economical as possible, has 24 ICs and a total of 627 components on its circuit board, making it more complex than most Android smartphones, which typically have 300 to 400 components.

Adding all these extra components makes Linux phones more expensive to design and produce, but it also makes them suck more power, since it takes more energy to run half a dozen chips at larger node sizes than one integrated mobile SoC fabbed on a ≤4nm node, which has been optimized for energy efficiency. It is hard to coordinate all the extra chips in Linux phones to get them to enter lower power modes and sleep modes to conserve their batteries. Add in an SoC with an older node size between 28 and 8 nm that hasn’t been optimized for battery usage, and there is no way that Linux phones can match the battery life of Android phones.

The RK3588S changes the game for Linux phones

Many of the Linux SoC makers have decided that they shouldn’t even bother building chips with the CPU and GPU performance needed for a modern computing device. NXP, Amlogic and Broadcom simply aren’t interested in building competitive SoC’s. However, Rockchip fundamentally changed the prospects for making a decent Linux phone when it released the RK3588 and its lower-power RK3588S variant in 2022. With four 2.4Ghz Cortex-A76 cores and four 1.8GHz Cortex-A55 cores and a Mali-G610 MC4 graphics, there finally was a Linux SoC on the market with enough processing power in an SoC to make an acceptable Linux smartphone.

The Liberux NEXX and the Dawndrums Divine D. are two Linux phones currently being designed with the RK3588S. Purism just announced on its forum that its next gen phone “is actively being designed,” which won’t be based on the i.MX platform like the Librem 5 and Liberty, so it is likely to be based on the RK3588S as well.

Of course, the RK3588S’s performance isn’t going to impress anyone used to an Android phone. The RK3588 and RK3588S are fabbed on a 8nm process node, which is four generations behind today’s state of the art at 2nm. Today’s low-end Snapdragon 4 Gen 4 fabbed at 4nm has 25% better single core CPU performance than the RK3588. The RK3588S has similar performance to the RK3588 over short bursts, but its performance is 10%-15% less over periods longer than 30 seconds. By the time the Linux phones based on the RK3588S hit the market in a couple years time, they will have significantly worse performance than every Android smartphone on the market, but this difference probably won’t be a limiting factor for most people who aren’t 3D gaming or shooting high-resolution video. At a certain point, more processing power has diminishing utility, and the RK3588S crosses that threshold for most people.

Where the older process tech will be significant is in terms of their energy consumption. A phone sporting the RK3588S will run hotter and have worse battery life than phones using integrated mobile SoC’s from Qualcomm, MediaTek, UNISOC, etc. The challenge is to dissipate the extra heat. The PinePhone’s SoC and cellular modem get very hot because they do not have a good heat spreader. The Librem 5’s SoC is joined with thermal paste to the back plate of the LCD, which avoids overheating the SoC, but causes the touchscreen and aluminum frame to become hot to the touch. A Linux phone with the RK3358S will need some kind of heat dissipation, but it is unlikely that a Linux phone maker can afford to include a vapor chamber, since those have to be specially designed and would be very expensive for a phone of limited production. The RK3588S will need throttling to fit within the power and thermal envelope of a phone.

At first, the mainline Linux support for the RK3588 was very limited. Rockchip never published the documentation for the chip on its opensource.rock-chips.com site, and Rockchip took down that site at the end of 2025. On December 21, 2024, Jeff Geerling, the most influential reviewer in the Raspberry Pi alternative space, reported on X:

I was told Rockchip no longer considers RK3588 to be an ‘open source’ chip. In practice, that means Rockchip no longer contributes RK3588 code to open-source projects and they also decided not to sell RK3588 directly to SBC vendors.

On the other hand, Rockchip is still updating its public kernel code for the RK3588 at Github. Collabora has been toiling away for years to add mainline Linux support for the RK3588, and Collabora lists Rockchip as one of its partners, so Rockchip hasn’t totally abandoned the Linux community. Collabora recently added mainline Linux support for the video capture unit and MIPI CSI2 interface in the RK3588. Now Collabora is working with Ideas on Board and Rockchip to create an new image signal processor (ISP) driver for all the RK35xx chips. Collabora has gotten the hardware video decoder working for VP8, VP9, H.264 and H.265, and is now working on the hardware video encoder for H.264.

Four years after the RK3588S was released, there is now enough support for the chip in mainline Linux, that an RK3588S phone can be created running free/open source drivers. The RK3588S needs to execute a proprietary Synopsys DDR timing training blob at boot. The RK3588S can now use the free Panthor driver for the GPU, but it requires the proprietary mali_csffw.bin firmware, which is loaded from the /lib/firmware/ directory at boot. All the other blobs for the RK3588S have either been replaced or they aren’t necessary. There is now a FOSS driver for the NPU. The proprietary MPP library for hardware video encoding can be replaced with software video encoding, and Collabora is working on free drivers for the ISP and hardware video encode, so software video processing and encoding probably won’t be necessary in the future. Collabora has developed a FOSS version for the Trusted Firmware-A (TF-A), that can replace the proprietary bl31.elf firmware. The HDMI blob in the bl31.elf isn’t necessary if using DisplayPort Alt Mode for video out. The proprietary bl32.bin firmware is not necessary if not using the hardware-enforced security features or encryption keys.

If Purism uses the RK3588S in its next phone, it is unlikely that Purism will attempt to obtain the FSF’s RYF certification by storing blobs on a separate NOR Flash chip and executing them with a secondary processor, like it did with the Librem 5, because the RK3588S doesn’t have a secondary low-power processor like the Cortex-M4 in the i.MX 8M Quad.

There are good prospects that Collabora will eventually get all the RK3588S’s hardware supported with mainline Linux drivers, and until then, the RK3588S has enough processing power in the GPU and CPU to process and encode images and video in software, so a phone built on the RK3588S can take photos and shoot video like a normal smartphone, although it will be slower and use more energy. In contrast, previous phones using a Linux kernel simply didn’t have enough processing power to offer decent cameras. Taking photos on the PinePhone is painfully slow, and the Millipixels app on the Librem 5 pauses for 3 to 4 seconds after taking each photo. Because the Librem 5’s i.MX 8M Quad processor lacks an ISP, audio DSP and hardware video encoder, it takes roughly 10 times as long to process and encode a 720p video on the Librem 5 as the length of the video, and it’s about 50 times longer on the PinePhone, due to its antiquated Allwinner A64 processor and significantly slower RAM and eMMC.

Aside from the RK3588S, there aren’t many other options on the market to make a good Linux phone. The closest option is Nvidia’s Tegra Orin NX or Orin Nano Super, which only contain Cortex-A78 cores. They lack low-power Cortex-A55 cores and they aren’t very energy efficient. They sport newer tech than the Cortex-A76 cores in the RK3588S, but the Tegra Orin was fabbed on a 8nm node just like the RK3588S and the Tegra Orin’s lower clock rate limits its single-core performance. The Tegra Orin is also much worse in terms of software freedom, requiring proprietary blobs in the initial bootloader, the secondary bootloader, Boot Configuration Table, USB firmware, HDMI/DisplayPort configuration, ARM Trusted Firmware and the GPU userspace driver. Many Linux users can ignore the blobs in the Linux device tree, but it harder to ignore Nvidia’s GPU blob in the userspace.

Another option is the Allwinner A733 at 12nm, which offers less performance with dual 2.0Ghz Cortex-A76 cores and six 1.79GHz Cortex-A55 low-power cores. Allwinner stopped collaborating with the Linux community years ago, and has frequently violated the GPL 2.0 license by not publishing its Linux source code, so the A733 probably won’t be a viable option, although Allwinner has made some comments about intending to collaborate with the community in the future. Another option is the NXP i.MX 95, which does have mainline Linux support, but its performance on a 16nm node with six low-power Cortex-A55 cores is poor and not a good value for the money.

The PinePhone 2 was expected to use the more economical Rockchip RK3566, which is fabbed on an older 22nm node. However, so many volunteer developers abandoned PINE64 in 2022, that it is unlikely that the Hong Kong-based company will be launching any new models in the foreseeable future. The production of PINE64’s Linux devices are currently on hold due to the high RAM and eMMC prices caused by the AI boom, but part of the reason is that PINE64 can’t raise prices on many of its devices, which are only half-functional, because many of the community groups, who worked on the PinePhone, are no longer developing the software to support PINE64’s newer devices.

Another reason the RK3588 is the preferred option is because Rockchip is promising to provide a successor chip, the RK3668 with four Cortex-A730 cores and six Cortex-A530 cores at a 5 or 6 nm node in 2027, so it should be possible to keep upgrading the phone in the future. Purism invested heavily in supporting the 28nm i.MX 8M Quad in the Librem 5, thinking that it would be possible to upgrade to a future 14nm version of the SoC, but NXP decided to eliminate half the cores in the GPU and remove DisplayPort support in the 14nm i.MX 8M Plus, so Purism couldn’t upgrade its phone in the same processor family. Given that the cost of fabbing on smaller process nodes keeps rising, it is unlikely that any of the other chipmakers will launch a new chip to challenge the RK3588’s performance in the near future.

The new option of Linux phones using a Qualcomm IoT SoC

In the past, the only way to create a phone running on a Linux kernel was to design a complex device containing many separate chips. Historically Qualcomm didn’t bother making powerful processors for its SoC’s that supported Linux. However, there has been increasing demand for more powerful Internet of Things processors that can handle AI and lots of image processing from multiple video feeds. Unlike short-lived smartphones and tablets, IoT devices have long product lives, so they are better suited to use Linux, rather than Android which is much harder to support over time. In March 2023, Qualcomm dramatically improved the prospects for Linux phones with the announcement that its upcoming 6nm QCM6490 processor with an integrated cellular modem would support four operating systems (Android, Linux, Ubuntu and Windows IoT Enterprise).

Then the San Diego-based company announced its new Product Longevity Program, which would both sell and provide software support for the QCM6490 until July 2036. Both the FairPhone 5 and SHIFTphone 8 were designed around the QCM6490, due to the environmental benefits to its long support, and that long support is exactly what Linux phones also need, because it takes so long to bring a Linux phone to market and it needs to sell for many years to recoup the high investment in a product that has limited annual sales. The Fairphone 5 with the QCM6490 (1x 2.7Ghz Cortex-A78, 3x 2.4GHz Cortex-A78, 4x 1.9Ghz Cortex-A55) was criticized for its poor benchmarks and poor battery life compared to other Android phones. However, the QCM6490 offers significantly better CPU and GPU performance and better energy efficiency than the RK3588S.

The subsequent QCM4490 and QCM8850, which are fabbed on a newer 4nm node, offer lower and higher power options than the QCM6490. The QCM4490 (2x 2.4GHz Cortex-A78, 6x 2.0GHz Cortex-A55) has almost as good single-core performance as the QCM6490 and is more energy efficient, but its support ends in April 2030, which is too short for a Linux phone. The QCM8850 probably could be downclocked to fit within the power envelope of a Linux phone, but its support ends in April 2033, so the longer-lived QCM6490 is probably the better option for a Linux phone.

The benefit of using one of these IoT processors, which Qualcomm has rebranded as “Dragonwing“, is that they make it significantly easier to design a phone and bring it to market, since they incorporate so much functionality in one chip, which reduces the complexity of the phone’s circuit board. Qualcomm provides reference designs that can be customized, so designing a Linux phone with a Dragonwing processor should be much easier and require fewer circuit board iterations and less testing.

A company with limited resources could contract with SHIFT or Fairphone to produce their phones and then install Linux, similar to the way that both Murena and iodé sell Fairphones and SHIFTphones and install their AOSP variants focused on privacy on the phones. Not only would this avoid the time and cost of designing the hardware, but it would allow the Linux phone to be marketed for its environmental and ethical benefits. Fairphone or SHIFT could also be contracted to provide the warranty service for the phone.

Qualcomm provides free/open source drivers for its Snapdragon and Dragonwing processors, and over time many of these processors will be partially supported in mainline Linux. However, the Qualcomm drivers depend on many proprietary blobs. The Adreno A660 GPU uses a blob to accelerate the 3D graphics. The audio digital signal processor (aDSP) uses a blob to handle audio decoding and processing. A compute blob is used by the DSP and NPU for tasks like machine learning. The VPU needs a blob to do the hardware video decoding and encoding. The Inline Packet Accelerator (IPA) uses a blob to speed up its network routing. These blobs allow the SoC to run cooler and be more energy efficient, but tasks like audio processing, video encoding/decoding and compute can be handled in software by the CPU and/or GPU in order to avoid using these blobs.

While these blobs are optional, the blobs to operate the WiFi, Bluetooth and cellular modem would not be optional on a phone which needs those functions. None of those blobs are required in the userspace, but the only way to avoid them is to use separate WiFi/Bluetooth and cellular modem chips. Adding those chips to the phone’s circuit board would add significant extra cost and complexity and make the phone less energy efficient.

On the other hand, adding those extra chips would also make it possible to use a hardware kill switch to shut down the phone’s wireless communications, which would be a major selling point for the phone. However, the type of customer who wants to be able to cut the power to the WiFi/Bluetooth and cellular modem will also probably be worried about the three blobs needed to boot the Qualcomm QCM chips, especially the one which runs the hypervisor and the TrustZone that handles encryption. Although the RK3566, RK3588 and i.MX 95 also require a blob to boot, it is a tiny file from Synopsys DesignWare that simply trains the DDR RAM’s memory timing, whereas the Qualcomm blobs to boot the QCM4490, QCM6490 and QCM8850 are much more extensive.

The problem of using an Android kernel in a Linux phone

What made the wave of mobile Linux from 2020 – 2022 with the release of the Librem 5, PinePhone and PinePhone Pro so exciting was that these were phones that ran on a Linux kernel. In contrast, most other Linux phones run their Linux stack on top of libhybris, which loads Android libraries and drivers and translates calls to libc and musl, so they can work with Android’s Bionic. The advantage of using an Android kernel is that it allows Linux phones to use a modern integrated mobile SoC like a Qualcomm Snapdragon or MediaTek Dimensity with good performance and energy efficiency, so Linux phones can compete with Android phones.

The problem is that a Linux phone that runs on an Android kernel will significantly shorten the lifespan of the phone. Historically Google only supported each Android kernel for 4 years with security updates, and it was necessary to do at least one Android upgrade to get those 4 years of support, since Google usually only supports each Android release for 3.5 years.

It is a security risk to use an Android phone that is no longer getting security updates, because there is so much Android malware in the world, including in Google’s official Play Store. A lot of hackers are focused on attacking Android, because it is so widely used on devices that carry valuable personal information. AV-TEST counts 37.62 million distinct pieces of malware and 30.38 million potentially unwanted applications (PUA’s) for Android that do things that users may not want such as collecting their personal data. In contrast, AV-TEST counts 5.29 million pieces of malware and 58,128 PUA’s in Linux, and most of it is rarely installed, because most Linux users only install software from the repository of their distro, where free/open source software (FOSS) predominates and package maintainers would suffer reputational damage for including malware.

Companies like Qualcomm and MediaTek typically only sell their SoC’s for smartphones for 2 to 3 years, and most of the demand for the high-end Snapdragon and Dimensity models dries up after the first year, so historically they only provided Android updates for 1-3 years and security updates for 2 to 4 years. They usually didn’t bother upgrading the kernel and the drivers and the proprietary blobs that they provided were designed to function with a particular kernel and couldn’t be upgraded. Historically Google only supported three years of kernels in each Android version, so that limited most phones to being used with a maximum of three Android versions.

In contrast to the 2-4 years of software support for Android phones, Purism advertised that the Librem 5 would get “lifetime updates that actually extend your phone’s life.” Likewise, PINE64 promised that it would sell the PinePhone and its replacement parts for “at least 5 years.” These two Linux phones can be supported for far longer than any Android device on the market. They use free/open source drivers and Linux kernels that can keep being upgraded, because they doesn’t rely on proprietary blobs that are only compatible with a particular kernel version. While they do contain proprietary firmware, they are not dependent on the SoC manufacturer to provide new blobs that allow the use of recent versions of the kernel.

The problem with the short lifespan of Android kernels is that Linux phones typically take longer to develop and bring to market, and then they are sold for more years than most Android phones. Given all the challenges with using Linux SoC’s, it isn’t surprising that FuriLabs decided to use a conventional smartphone design sporting a MediaTek Dimensity 900 processor for its FLX1 phone, which started shipping in July 2024. The phone’s operating system, FuriOS, is based on the Droidian project, which runs a mobile Debian stack with Wayland + wlroots + GTK + GNOME libraries + Phosh on top of an Android kernel using libhybris. Unlike the Librem 5 and the PinePhone, the FLX1 has the processing power to handle all the tasks that people expect of a modern smartphone.

The problem is that the Dimensity 900 was released in May 2021 with Android 11 using the android11-5.4 kernel. Google stopped supporting this kernel on January 1, 2026, and Linux stopped providing updates for the 5.4 kernel on December 3, 2025. MediaTek doesn’t release major-version kernel upgrades for its processors (although that may change in the future), and the drivers that MediaTek provides for the Dimensity 900 contains proprietary blobs that can’t be upgraded to support newer kernels, so the FLX1, and its successors, the FLX1s and FLX1s+, are stuck with an outdated kernel for Android 11 that isn’t getting security patches and bug fixes. Since these phones use Andromeda, which is a custom fork of Waydroid, to run Android apps inside FuriOS, they are potentially exposed to a lot of Android malware. Waydroid has weakened the app sandbox and SELinux security in standard Android, and it is based on outdated AOSP 13, which stopped getting security updates in March 2026. Given the security implications, it is questionable whether FuriLabs should still be selling the FLX1s+ using an unsupported kernel.

The Jolla C2 Community Phone, which currently sells for €369, shares similar security concerns. The C2, which started shipping in September 2024, is based on the UNISOC Tiger T606 processor, which was announced in September 2021. The C2 is running a custom kernel named “5.4.233-android12-9-g9c3a5d5b97e3.” Presumably, the Finnish company took Linux 5.4.233, which was released on 25 Feb 2023, and added Google’s Android 12 kernel modifications, so it is essentially using the same unsupported kernel as the FLX1/s/s+, which hasn’t received any security updates from Google since January 1, 2026. Jolla hasn’t even bothered to update the kernel to 5.4.302, which was the last maintenance release from Linux for the 5.4 kernel on December 3, 2025. Jolla did not release the source code for the C2’s kernel until May 20, 2025, which was 8 months after it started shipping the phone, and its last update to that kernel on GitHub was on November 30, 2025. Even if Jolla does update its kernel to the last 5.4.302 release, it is important to keep in mind that kernel had 1539 unfixed CVE’s (Common Vulnerabilities and Exposures) when released. New critical CVE’s for Linux are found on average every 2.5 days, so there are benefits to switching to the close-to-mainline 7.2 kernel provided by the community for the C2 phone.

Like the FuriLabs FLX1/s/s+, the Jolla C2 also can run Android apps, which may contain malware, but it uses Jolla’s proprietary AppSupport (aka AlienDalvik), which runs AOSP inside an LXC container like Waydroid. With AppSupport, the Android apps have better integration into the host operating system than Waydroid. Presumably Jolla is running a more recent version of AOSP than Waydroid, since Jolla licenses the use of AppSupport to other companies, so it probably is applying Google’s security updates for AOSP, but not for the unsupported kernel on the C2 phone.

All the Linux phones running Android kernels, such as the Volla phones with Ubuntu Touch and the new Jolla Phone (2026) running Sailfish OS, will face this same problem that their lifespans are cut short by their Android kernels that can only get a major version upgrade from the SoC manufacturer due to their proprietary blobs only being compatible with one major version of the kernel. Unfortunately, all these phones are using MediaTek processors, which either have little or no mainline Linux support, so their lifespan can’t be extended by switching to a mainline Linux kernel.

Linux phones based on Android will become more viable due to longer support

Nonetheless, the planned obsolescence of the Android phone market has started to change. Google wanted its Android operating system to better compete with Apple’s iOS. Apple promises at least 5 years of support for its phones and typically provides over 6 years. Unlike the other Android phone makers, Google’s business model doesn’t depend on planned obsolescence. The more people that Google can convince to use its operating system, the more data Google can collect for its targeted advertising, so extending the life of Android phones is a way to attract more users to its platform.

In addition, the COVID-19 pandemic caused people to buy fewer new phones, and then the subsequent supply chain crunch caused phone prices to rise due to the more expensive components. The global average selling price of Apple’s iPhone increased from $724 to $903 between 2020 and 2024. Global smartphone sales collapsed in 2020 and have never recovered to their pre-pandemic levels. In order to convince people to open their wallets for more expensive phones, consumers needed to be convinced that they would last longer.

In August 2020, Samsung announced that its S, Note and Z series phones starting with the S10 would all get three years of OS updates and security updates, just like Google had been providing for its Pixels, since the brand was first launched in 2016. At the time when Samsung made this policy change, the smartphone industry had just experienced the worst decline in its history, with unit sales dropping 23% YoY in the second quarter of 2020. In October 2021, Google announced that it would significantly extended the lifespan of its Pixel devices, promising 3 years of OS updates and 5 years of security updates, beginning with the Pixel 6. Samsung couldn’t allow its Galaxy devices to usurped as the best Android brand. In February 2022, Samsung announced that it would surpass Google with a promise of four years of OS updates and 5 years of security patches for its flagship models, starting with the Galaxy S21, Z3 and Tab8.

This set off a competition between the two firms to see which one could provide the longest software support for its mobile devices. Google decided to leapfrog Samsung again and set a new standard that would best Apple’s support policy. In October 2023, Google pledged that the Pixel 8 series would get 7 years of OS updates and security updates, plus “Pixel Feature Drops” and “AI technology from Google”. Google’s announcement that it would support the Pixel 8 into 2030 sent shock waves through the mobile industry. Samsung was determined to not be outdone by Google, and announced in January 2024 that its new Galaxy S24 and S24 Ultra would also get 7 years of OS updates and security updates. In 2025, Samsung extended the software support to six years for all its new Galaxy models, including its low-end Galaxy A06 4G, which costs around $125.

In October 2024 during its Snapdragon Summit, Qualcomm commented that it would be offering 8 years of OS upgrades and security updates for its high-end mobile processors, and in February 2025, it formally announced that its new 7, 8 and 8 Elite processors released that year would all get this unprecedented level of support. Just as important, Qualcomm promised that its high-end Snapdragon processors would also get two kernel upgrades, so they would be using kernels that are officially supported by new Android releases. MediaTek couldn’t let Qualcomm corner the high-end mobile processor market for the next generation of flagship phones. On May 27, 2025, MediaTek posted that its Dimensity 8400 and 9400 chips would also get 8 years of support.

Traditionally each new Android version only supports three years of kernels, but in 2024 Google added a fourth year with Android 15 (android12-5.10 to android15-6.6) and a fifth year with Android 16 (android12-5.10 to android16-6.12) and a sixth year with Android 17 (android12-5.10 to android17-6.18). However, these extra years of support in Android are likely a temporary fix that Google implemented until it can move the chipmakers into its Longevity Google Requirements Freeze (LGRF) program which Google began in October 2024. Under this program, chipmakers are expected to upgrade their kernels every 3 years in order to be able to support their SoC’s in the long term. After the Linux kernel maintainers announced that they would be reducing their support of their LTS kernels from 6 to 2 years, Google announced in July 2024 that it would provide security updates to its kernels for 4 years, so that suggests that future Android releases will go back to only supporting 3 years of kernels.

Qualcomm has promised to provide two kernel updates for its high end processors, but Qualcomm has said nothing about its lower-tier processors, except for its announcement back in December 2020 that all of its Snapdragon processors would get three years of OS updates and 4 years of security updates. Other SoC manufacturers have been similarly mum on the support for their lower-tier processors. In all likelihood, most smartphones with mid-range and low-end processors will only get 4 years of support, which means that all the existing Linux phones from Volla, FuriLabs, Jolla and Brax will probably face the same problem of using unsupported Android kernels that can’t be upgraded.

New Linux phones, however, can be designed in the future to get 8 years of support if they use a higher-end Snapdragon or Dimensity processor. Even if designing a custom phone like the FLX1, which took three years to bring to market, because it has three hardware kill switches for the microphone, cameras and cellular modem and it required a lot of software dev work, the Linux phone should still be viable because it will still have 5 more years of software support and can be sold for at least 3 years.

If selecting the Snapdragon 8 or Dimensity 9000 series to take advantage of its longer software support, the phone will get the added benefit of offering video out via DisplayPort Alt Mode over its USB-C port. That means that the phone can be marketed as a convergent device that allows it to be used as both a phone and a desktop PC. Unlike an Android desktop, a Linux desktop is far more useful as a PC. If the phone has enough RAM and storage space, it can become a replacement for the traditional PC for people who don’t need a lot of processing power, but it has the convenience of being more portable than a laptop, and not needing to transfer data between multiple devices. For people who have to work in multiple locations and want to be able to carry their data around with them, a convergent phone can be a very attractive option.

If designing a more economical phone, however, that doesn’t need video out, the Snapdragon 7 and Dimensity 8400 are processors designed for upper mid-range phones, and they still get the 8 years of support (if the phone maker is willing to pay Qualcomm or MediaTek for the extended support). This will be the most attractive option for Volla, Jolla, FuriLabs and Brax, which all sell mid-range phones.

If a Snapdragon chip is selected, there is a decent chance that the chip will eventually gain some mainline Linux support, so the phone can have a second life after the official support ends, although its functions requiring binary blobs probably won’t work with the upgraded mainline Linux kernel. What is so frustrating is that many of the makers of Linux phones are selecting MediaTek processors over Snapdragon processors, so there is little hope for that second life.

Why software was a major challenge for the Librem 5

When Purism announced the Librem 5 in August 2017, the California-based company wasn’t just facing a major obstacle in using a new SoC, that hadn’t yet been released, which would significantly delay the phone. Purism, however, faced an even bigger challenge in the software to install on the phone.

Purism had observed how trying to develop mobile Linux had humbled larger companies with far more resources, and it tried to avoid their mistakes. Motorola developed half a dozen different varieties of Linux, but couldn’t unify and direct its development efforts, and eventually adopted Android which commoditized its phones, so it had to be sold off to Google and eventually Lenovo in order to survive. Palm took too long developing webOS and ran out of money as Android ate its market, so it had to sell itself off to HP in 2010 in order to survive. Likewise, Nokia took too long developing MeeGo as its business collapsed due to Android, so it turned to Microsoft in 2010 to provide Windows Mobile for its phones, which only hastened the destruction of the Finnish company. The Mozilla Foundation developed an entire operating system based on web standards, but found that it didn’t have the resources to match Google’s Android, and abandoned the development of Firefox OS for smartphones in December 2015, although it continued development for TVs and Internet of Things for another 10 months. Canonical attempted to unify the desktop and mobile spaces with its Unity8 interface and develop Ubuntu Touch as a mobile OS with good convergence for the desktop. However, it proved to be a costly endeavor with limited commercial interest, and Canonical’s CEO, Mark Shuttleworth, announced that the company would abandon the development of Ubuntu Touch in April 2017.

This tragic history has taught Linux hardware vendors that they should do as little software development as possible, except code to make their hardware work and some distro maintenance. However, avoiding software dev work was not viable strategy in 2017 for the kind of phone that Purism was attempting to create.

All the available mobile Linux interfaces in 2017 had major drawbacks, including Sailfish OS’s Silica, Firefox OS’s Gaia, KDE’s Plasma Mobile, UBports’ Unity8→Lomiri, Maemo Leste’s Hildon, LuneOS’s Luna Next and Nemo Mobile’s Glacier UI. Jolla had spent years polishing its Sailfish OS, but Purism’s goal of 100% free software disqualified Jolla’s proprietary Silica interface, as well as Samsung’s Tizen, whose problematic Flora License grants a patent license only to “Tizen certified platforms”. Nemo Mobile and Plasma Mobile were still incomplete and would have required a lot of dev work on Purism’s part to supply all the missing parts. LG had turned webOS into an operating system for smart TVs/projectors and automobiles, and replacing LG’s proprietary bits would have taken quite a bit of work. Firefox OS and Ubuntu Touch were complete systems, but both of them would have required a huge commitment on Purism’s part to maintain their software in the long term. Firefox OS’s code was abandoned, and the volunteers at UBports didn’t have the manpower to maintain its huge codebase. All of the available interfaces were based on a separate mobile stack, whereas Purism wanted to unify with the software stack in desktop Linux, because one of its announced goals was that the Librem 5 could be used with the major distros, including Debian, Ubuntu, Fedora, SUSE and Arch.

Purism originally leaned toward adopting Plasma Mobile for its Librem 5 phone, but that would have required maintaining both a GNOME-based stack on the desktop and a separate KDE-based mobile stack in its PureOS distribution. At that point in time, Plasma Mobile was still an inchoate system, that would have required a huge amount of dev work to get ready for a commercial product launch. Plasma Mobile was based on many things that were incompatible with a desktop stack, such as oFono telephony and the Halium Project, which was also used by LG’s webOS and UBport’s Ubuntu Touch, in order to run the system on top of libhybris with an Android kernel and drivers.

Purism was already working with GTK and GNOME in PureOS, and it marketed the Librem 5 as a phone aligned with the ideals of the Free Software Foundation, which sponsored GNOME, so it made sense for Purism to favor an interface based on GTK and the GNOME ecosystem. However, the only available GTK-based interface was Hildon, which was hopelessly outdated, and would have required a lot of work to upgrade from GTK 2 to GTK 3.

In the end, Purism decided that it would be easier to create a new mobile interface, which it called Phosh (phone + shell), as a thin overlay on top of GTK plus GNOME middleware, than do dev work on one of the existing mobile interfaces. By basing Phosh on the standard desktop stack consisting of Linux + Wayland + wlroots + GTK + GNOME and adding code to roughly 20 GNOME applications to make them adaptive, Purism was able to take advantage of all the corporate support provided by IBM/Red Hat, SUSE, Canonical and Google for this stack. Purism had to submit code upstream to Linux, wlroots, ModemManager, GTK/GNOME and Matrix to support its mobile operating system, but then it could rely on those projects to maintain the code in the future. This was arguably a better strategy than helping develop Plasma Mobile, which has minimal corporate support, and was focused at the time on developing a separate stack than KDE’s desktop Plasma. Purism started working on its libhandy library in mid-2018 to add to standard GTK3/GNOME desktop applications to make them adaptive for a smaller mobile interface. Then the Purism developers worked with the GNOME community to develop libadwaita in 2020, so GTK4/GNOME could become adaptive between mobile and desktop screens.

As detailed in my article, “The strategic advantages of Phosh for mobile Linux,” unifying with an existing desktop stack and getting the broader community to adopt its software to help maintain it was arguably the best strategy to reduce the long-term maintenance costs, especially for a tiny company like Purism that has limited resources.

Unfortunately, developing a new mobile interface involved higher costs upfront, and Purism ran into financial problems during the global COVID-19 pandemic. In early March of 2020, Purism stopped paying refunds to customers who cancelled their preorders, telling customers that they would have to wait till the phone started shipping in order to get their refunds. Between February and May of 2020, 5 of the 14 developers working on the Librem 5 quit the project, and there was a noticeable drop in the number of software commits by the Purism employees who stayed, indicating that Purism probably wasn’t paying them.

Purism was caught in a hopeless situation. If it publicly admitted in early 2020 that it was having financial problems, all of the orders for its products would have dried up and the company would likely have gone bankrupt. If it paid out all the refund requests, it also would have likely gone bankrupt, which would have harmed everyone who had put down $599 – $799 to pre-order the Librem 5. Purism held off on paying refunds, which probably allowed the company to survive and eventually start delivering its phones in November 2020. However, it didn’t appear to have the funds on hand to manufacture all the pre-ordered phones, because the manufacture of the Librem 5 was done in small batches until it was caught by COVID’s global supply chain shortages and couldn’t procure the i.MX 8M Quad processors for 6 months during 2021.

Purism never repaid the refunds for the canceled Librem 5 orders. Angry customers waiting for their refunds publicly denounced the company on public forums, which blackened the company’s public reputation and suppressed sales of the Librem 5. The early reviews for the phone noted the poor battery life and the fact that critical functionality was still not implemented, such as the cameras, VoLTE support in the modem and the ability to suspend. In order to recoup its high development costs, Purism kept raising the phone’s price, until it reached an eye-watering $1299 in March 2022, which further suppressed sales of the phone.

Instead of refunds, Purism offered customers who had canceled their orders credit plus 20% extra to buy another product from Purism. Customers who received the Librem 5 were able to resell it for more than they paid, but many customers who had canceled their orders refused to do that on principal. In a letter to Louis Rossmann in August 2023, Purism admitted that it still had 600 cancelled Librem 5 orders, which it still didn’t have the finances to refund.

The success of Phosh despite its limited funding

Despite all the controversy surrounding the California-based company, its strategy of making a sustainable mobile OS by unifying with a popular desktop stack with good corporate support and upstreaming its code so it would be maintained over the long term has proven to be correct. Of the 469k lines of code in the software projects that Purism initiated for the Librem 5, 98.7% of that code is now controlled by external organizations. GNOME adopted libhandy, Calls and Chat (i.e. chatty) as official projects. In late 2020, the Purism developers started worked with the GNOME community to develop libadwaita to become the canonical implementation of GNOME’s human interface guidelines (HIG). Not only did this make GNOME’s GTK4 applications adaptive between the desktop and mobile environments, but it gained features like in-app notifications, customizable animations and speed/fluidity improvements. GNOME has continued developing its GNOME Shell on mobile based Mutter, which is its unified display server, compositor and window manager. In contrast, Phosh uses wlroots (a Wayland compositor library created by Sway) and its phoc (a Wayland compositor), which are lighter weight than Mutter. However, GNOME has helped promote Phosh by hosting its code and documentation at GNOME World to foster its development.

As Purism has cut its budget for code development, Phosh’s development has increasingly moved outside the company. FreeDesktop.org adopted feedbackd, which is a D-Bus activated daemon that provides haptic, visual and audio feedback in response to events. In February 2025, the non-profit association Phosh.mobi e.V. was created in Germany to guide the development of Phosh as an independent entity. Three of the nine founding members of Phosh.mobi were former or current Purism employees/contractors, including Guido Gunther, who is Phosh’s main developer.

Over the last five years, the amount of code in the projects that Purism created for the Librem 5 has grown by 74.9%, and much of that new code is being written by people who are no longer employed or contracted by Purism. The only code projects still controlled by Purism are gtherm, haegtesse and wys, which are DBus daemons for thermals, transfering modem audio and bringing up PulseAudio during calls, respectively. Together, these projects only represent 6173 lines or 1.3% of the total code.

In a survey that PINE64 took of 3079 PinePhone users in January 2022, 39.3% selected Phosh as their favorite interface, compared to 15.5% for Sxmo/Swmo, 15.0% for Plasma Mobile and 6.7% for Lomiri (formerly Unity8). Despite Phosh only starting its development in April 2018, more users preferred it over Lomiri and Plasma Mobile, which have been under development since March 2013 and July 2015, respectively. Purism’s strategy of using the existing infrastructure and applications from GNOME allowed the tiny company to create a usable interface faster than other competing interfaces.

It is surprising that Phosh became the most popular mobile Linux interface, considering that the Qt toolkit and KDE had such a head start over GTK and GNOME in supporting mobile environments. Qt Quick was introduced with Qt 5.1 in June 2013 to make Qt controls adaptive for small screens, and Qt Mobile was introduced in December 2013 to make them cross-platform, and KDE’s Kirigami library for adaptive applications was introduced in March 2016. GTK didn’t gain similar abilities until 2019 with libhandy and GNOME didn’t have an answer to Kirigami until libadwaita was introduced in 2021.

Phosh has some glaring limitations. Its default Squeekboard keyboard is basic and kludgy. Only in 2025 did Phosh gain an alternative keyboard with word correction and word completion, plus the ability to select from multiple characters by long pressing a key. The desktop mode in Phosh to output video to an external monitor or projector has a very limited interface. Phosh has no camera app, and most installations rely on Megapixels developed by Martijn Braam for the PinePhone or its Millipixels fork developed by Purism for the Librem 5. Millipixels only gained basic support for auto-focus and the ability to shoot video in January 2023.

Phosh doesn’t have the three buttons at the bottom or the swipe gestures from Android that most people are used to. Plasma Mobile’s interface is much closer to the familiar Android interface, and it is nicer visually. Phosh’s interface is much simplier. It doesn’t use system navigation buttons and has fewer configuration options than Plasma Mobile. A swipe from the bottom displays Phosh’s Overview screen where apps can be opened or closed. A swipe from the top displays a Quick-Setting panel, notifications, and buttons in the top corners to lock or turn off the phone.

Phosh became the more popular interface, partly because Purism was paying developers to work on it, so it was more stable, whereas Plasma Mobile was more prone to stalls and crashes. Plasma relies on hardware acceleration from the GPU to speed up its interface, which isn’t supported by the drivers for the A64 and i.MX 8M Quad in the PinePhone and Librem 5, whereas Phosh is faster and more responsive just using software rendering. Phosh also requires less RAM, although it does run more background processes that use more CPU.

Adoption of mobile interfaces by Linux distros

Phosh succeeded because its close adherence to a common desktop stack made it easier to package and distribute in different distros. Phosh was first adopted by postmarketOS (now Nura) in September 2018, just a two months after Purism first debuted it. The close ties between the Phosh developers and Debian helped get Phosh packaged into Debian in February 2020, where it became the basis of the new Mobian distro. Phosh allowed Debian, Arch, Manjaro, Fedora, OpenSUSE and NixOS to become mobile distros for the first time, which in turn encouraged Linux application developers to start testing their software in a mobile interface to see how it functioned on smaller screens. Because Phosh didn’t stay isolated in one Linux distro, it attracted more volunteers to he

I’ve done a lot of web development over the years. I started around the year 2000, just after PHP 3.0 was released and started taking over the web world. I’ve used all kinds of approaches for generating HTML: raw PHP, string concatenation in Python, Smarty templates in PHP, Template Toolkit in Perl, and Jinja/Django templates in Python. Then, as the world moved on to SPAs and JavaScript frameworks, I stopped working on frontends.

Two years ago, I picked up Zig, and I’d never have imagined I’d be considering web development in such a low-level language. But as I was building my own ecosystem with zio and Dusty, I realized it’s not that far-fetched. I built these libraries for API backends, where the output is JSON or MessagePack, but then I saw that with proper use of arena allocators, even web development is actually manageable, since you don’t need to remember to deallocate all the strings that are typically involved. And with Zig’s comptime, you can build very high-level interfaces without losing the performance benefits. And with the help of htmx or Datastar, you can even build SPAs without touching JavaScript/TypeScript, which I promised myself I’d never do.

That said, one thing was still missing: templating. String concatenation was not an option, I didn’t want to go back to the pre-2000 CGI days. I had a few requirements for a templating library:

1. It has to be type-safe, with all inputs typed and checked at compile time. I’ve dealt with dynamic languages enough in my life, and I don’t want to deal with runtime template errors anymore.
2. It has to be fast. No allocations, no intermediate state, just write the output to std.Io.Writer directly.
3. It needs to have safe defaults. I don’t want to deal with XSS anymore, so all inputs have to be escaped by default.
4. It should still feel like writing HTML. I didn’t want a Zig-based DSL I’d have to fight constantly.

I couldn’t find any solution that would satisfy all these requirements. Then I saw Ziex and I was amazed. It never occurred to me that the JSX approach could be done outside of JavaScript. The developer experience Nurul Huda managed to build in Zig was just unimaginable to me. It didn’t fit my needs directly, because I didn’t want a WASM framework, but the syntax and his approach to integrating Zig code into templates gave me some ideas. Then, after further research, I discovered Templ for Go, and it was pretty obvious to me what I wanted to build.

So, let me present zt (I’m not good at naming, sorry). It’s an adaptation of Templ to Zig. The templates are parsed and transpiled to Zig code during zig build. That means you can import them directly from your app code, but also, perhaps even more importantly, the templates can import your app code. As a result, all parameters can be fully typed. If something can’t be rendered, the Zig compiler will tell you so. The generated code is fairly simple, all it does is write to a std.Io.Writer. You can write directly to a socket or accumulate the output in a buffer, your choice. Here is what a template looks like:

const User = @import("../models.zig").User;

pub templ Layout(title: []const u8) {
    <!DOCTYPE html>
    <html>
        <head>
            <title>{title}</title>
        </head>
        <body>
            @children
        </body>
    </html>
}

pub templ HomePage(user: ?User) {
    @Layout("Home") {
        if (user) |u| {
            <h1>Welcome back, {u.name}!</h1>
            <a href="/users/{u.id}">Your profile</a>
        } else {
            <h1>Welcome, guest!</h1>
            <a href="/login">Log in</a>
        }
    }
}

And here is how you would use it from Zig code:

const std = @import("std");
const User = @import("models.zig").User;
const pages = @import("templates/pages.zig");

pub fn main(init: std.process.Init) !void {
    var buf: [4096]u8 = undefined;
    var stdout = std.Io.File.stdout().writer(init.io, &buf);
    const w = &stdout.interface;

    const user: User = .{ .id = 1, .name = "Lukas" };
    try pages.HomePage.render(.{user}, w);
    try w.flush();
}

If you want to use it inside Dusty to render an HTML page, you just do this:

try res.render(.html, pages.HomePage, .{user});

As a side note, the main snippet above has a very non-obvious bug in error handling if you use the same pattern somewhere std.Io cancellation matters. I’ll probably write a blog post about it, but if you are interested, check out this Ziggit thread. The render function in Dusty that wraps the std.Io.Writer handling solves it.

All dynamic values are HTML-escaped by default, both in text and in attributes, and values in URL attributes like href or src are also checked for dangerous schemes. If you really need to output raw HTML, you have to ask for it explicitly with {!value}, so it’s easy to spot in the template. The parser also requires all elements to be properly closed, so you can’t accidentally produce broken markup. It won’t protect you from everything, but it removes the most common sources of XSS.

What I like the most is that template errors are just Zig compiler errors. If you make a typo in the template above and write {u.nmae} instead of {u.name}, zig build will tell you:

src/templates/pages.zig:45:43: error: no field named 'nmae' in struct 'models.User'
            try zt.writeEscaped(writer, u.nmae); // pages.zt:18:31
                                          ^~~~
src/models.zig:1:18: note: struct declared here
pub const User = struct {
                 ^~~~~~

The error points to the generated code, but each line has a comment with the location in the original template. The same applies to the calling side, if you try to pass a string where HomePage expects a ?User, it won’t compile.

Beyond the basics shown here, you can build reusable components and pass them around as values, and with @children you can build layouts that wrap other templates, which covers what you’d use template inheritance for in other languages. Control flow is just Zig, so if, for and switch work as you’d expect, including payload captures. All of it still compiles down to a sequence of writes, without any allocations.

You can have a look at the TODO example in Dusty. It’s a simple htmx-based web app that showcases this library, plus other parts of Dusty that are needed for building a dynamic SPA.

One part of the syntax is still open. Block-level control flow is written as plain Zig, following the example of Templ, so a line starting with if, for or switch is parsed as code. That means text like “if you forgot your password…” on its own line is a parse error, and you have to wrap it in an element or write it as a string expression. I’m considering switching to @if, @for and @switch, similar to Razor or Twirl, which would remove the ambiguity, at the cost of slightly noisier templates. If you have an opinion on this, please leave a comment in this GitHub issue.

Although multiple people are already using it, the project is not very mature yet, so I welcome any feedback. You can open a GitHub issue if you find any problems, or ping me on the Zig Discord.

California is the latest state to pass a law making it easier to install balcony-friendly solar panels. Renewable energy experts think the new technology is about to take off.

On a quiet street in suburban South Salt Lake City, Utah, the stirring of an energy revolution is taking shape. There, outside the spare bedroom of an unassuming, thousand-square-foot midcentury home sit three angled solar panels plugged into a nearby outlet.

Unlike the highly technical and expensive hurdles required to install a large rooftop solar system, the setup on Andrew Leon and Victoria Mauro’s lawn is small, portable, and cheap. The unit generates enough electricity to run laptops, lights, and some appliances, including the refrigerator.

Plug-in solar, also known as balcony solar because apartment dwellers can use it, is spreading quickly across the U.S. California is the latest state to pass a law reducing the red tape that has previously stymied consumers looking to generate some electricity from a small number of solar panels.

Utah was the first state to legalize balcony solar in the spring of 2025, and nine states subsequently passed similar legislation— Colorado, Connecticut, Maine, Maryland, New Hampshire, New Jersey, Vermont, Virginia, and now, California. New York lawmakers approved a bill that is awaiting the governor’s signature, while nearly two dozen other state legislators have introduced them.

Plug-in solar systems, typically comprised of one to three panels to stay below the maximum wattages allowed by the laws, enable users to save money on their power bills and to reduce the energy they use from power plants that generate electricity by burning fossil fuels. “The appeal of being able to make your own electricity, and for less money than you can buy it from a utility, that’s universal for Americans,” says Joshua Pearce, an electrical engineer at Western University in Ontario, Canada, who advanced the merits of plug-in solar a decade ago.

For most homes, electricity is generated in faraway power plants and transmitted through power lines. Homes where rooftop solar creates electricity wire the energy into the home through the circuit breaker panel, and excess electricity flows back to the utility. But power from plug-in systems stays in the home. With a small metal box called an inverter attached to the panels and plugged into the outlet, electrical currents are pushed to other outlets throughout the residence. Systems typically contribute 10 to 30 percent of an average home’s use, says Jennifer Eden, who works on renewable energy programs for the policy nonprofit Utah Clean Energy.

The set-ups have become especially popular in Europe. Swedish furniture chain IKEA sells plug-in solar kits in Germany, a country where more than a million units have been installed in the past few years.

As more U.S. states approve the technology and as more products become available, “this is going to take off like hotcakes,” Pearce predicts. With widespread adoption, residents could save an estimated $13 billion a year in electricity costs, he calculated in a 2017 journal article, a figure he says is higher now that electric rates have soared. People are especially pleased “there’s now an entry point into solar that doesn’t cost tens of thousands of dollars and can be used by people who don’t own their home,” Eden says.

In states with especially high utility rates, residents reap substantial savings. Nick Danz, who lives alone in a modern, two-bedroom luxury apartment in Fort Collins, Colorado, became eager for plug-in solar after reading about its popularity in Germany. Colorado has more than 200 sunny days a year and Danz’s apartment faces southwest, an optimal direction for sun collection. (Directly south is the most ideal.)

When, this summer, his state passed a law for plug-in systems, he reached out to the California-based clean-energy nonprofit Bright Saver. To encourage people to adopt renewable energy, Bright Saver sells plug-in systems without markups. Danz paid under $300 for a one-panel unit and affixed it with metal clips over his small, third-floor balcony.

The system tripped his apartment’s circuit breaker and shut off his computer several times, but a different inverter solved the problem. Danz estimates he has already saved more than $300 on his power bills since August. For the four days a week Danz is away from home working as a train conductor, “the solar panel is essentially running all of my standby items,” he says. He plans to soon move to an apartment with a larger balcony, where he hopes to hang three panels, the most his state’s law allows.

Some utilities have expressed concern that plug-in units could send power back to the grid and electrocute employees working on the lines. But Pearce found that no microinverters sold in the U.S. are capable of this. Earlier this year the testing company UL Solutions set safety standards for plug-in solar systems and has already certified one manufacturer.

Pearce has also heard concerns that the energy being pumped into wall sockets could cause wiring in old homes to catch fire, but he says “that’s never happened in Europe,” despite its widespread adoption. In June the British government tested several products available in that country and found no direct electrical hazard, although some exhibited minor problems like not tripping the circuit breaker fast enough when stressed.

One impediment to interested buyers are local rules that may restrict balcony solar even in states where it is legal. Leon and Mauro discovered this the hard way when they placed their panels in front of their home, concerned the numerous trees behind their house would shade them. But a zoning employee soon knocked on their door and said city rules prohibited panels there. The couple’s plug-in panels remain in place while they work with the zoning board in hopes of loosening those restrictions.

Leon and Mauro still draw power from the grid for their air conditioner and major appliances, but they have shaved nearly $100 total from Utah’s typically low electric bills since May. Mauro especially loves the benefit to the environment, because solar energy does not emit the greenhouse gasses that lead to climate change. Experts estimate that even the energy used to produce the solar panels is offset in less than two years of use.

“When we first heard about it, we thought it seemed way too good to be true, to just plug a solar panel into the wall and generate electricity,” Mauro says. “But it turned out that really was all we had to do to produce clean energy and save money.”

Kevin Kelly's The Inevitable articulates a handful of macro technological trends and follows them to their logical conclusions. It's an insightful read -- I highly recommend it.

One decade later, here are some AI-related excerpts from the book:

• "By 2026, Google’s main product will not be search but AI."
• "oligarchy of two or three large, general-purpose cloud-based commercial intelligences"
• "The AI on the horizon looks more like Amazon Web Services"
• "The bulk of AI will be special purpose software brains"
• "in conversational tones, any question at all"

"By 2026, Google’s main product will not be search but AI."

Around 2002 I attended a private party for Google—before its IPO, when it was a small company focused only on search. I struck up a conversation with Larry Page, Google’s brilliant cofounder. “Larry, I still don’t get it. There are so many search companies. Web search, for free? Where does that get you?” My unimaginative blindness is solid evidence that predicting is hard, especially about the future, but in my defense this was before Google had ramped up its ad auction scheme to generate real income, long before YouTube or any other major acquisitions. I was not the only avid user of its search site who thought it would not last long. But Page’s reply has always stuck with me: “Oh, we’re really making an AI.”

I’ve thought a lot about that conversation over the past few years as Google has bought 13 other AI and robotics companies in addition to DeepMind. At first glance, you might think that Google is beefing up its AI portfolio to improve its search capabilities, since search constitutes 80 percent of its revenue. But I think that’s backward. Rather than use AI to make its search better, Google is using search to make its AI better. Every time you type a query, click on a search-generated link, or create a link on the web, you are training the Google AI. When you type “Easter Bunny” into the image search bar and then click on the most Easter Bunny–looking image, you are teaching the AI what an Easter Bunny looks like. Each of the 3 billion queries that Google conducts each day tutors the deep-learning AI over and over again. With another 10 years of steady improvements to its AI algorithms, plus a thousandfold more data and a hundred times more computing resources, Google will have an unrivaled AI. In a quarterly earnings conference call in the fall of 2015, Google CEO Sundar Pichai stated that AI was going to be “a core transformative way by which we are rethinking everything we are doing. . . . We are applying it across all our products, be it search, be it YouTube and Play, etc.” My prediction: By 2026, Google’s main product will not be search but AI.

In 2017, Google researchers published Attention Is All You Need, which introduced a deep-learning architecture called the transformer.

"oligarchy of two or three large, general-purpose cloud-based commercial intelligences"

As it does, this cloud-based AI will become an increasingly ingrained part of our everyday life. But it will come at a price. Cloud computing empowers the law of increasing returns, sometimes called the network effect, which holds that the value of a network increases much faster as it grows bigger. The bigger the network, the more attractive it is to new users, which makes it even bigger and thus more attractive, and so on. A cloud that serves AI will obey the same law. The more people who use an AI, the smarter it gets. The smarter it gets, the more people who use it. The more people who use it, the smarter it gets. And so on. Once a company enters this virtuous cycle, it tends to grow so big so fast that it overwhelms any upstart competitors. As a result, our AI future is likely to be ruled by an oligarchy of two or three large, general-purpose cloud-based commercial intelligences.

Kelly predicted AI heavyweights while advocating for a future of open weights:

Ideally, this additional intelligence should be not just cheap, but free. A free AI, like the free commons of the web, would feed commerce and science like no other force we can imagine and would pay for itself in no time.

"The AI on the horizon looks more like Amazon Web Services"

Amid all this activity, a picture of our AI future is coming into view, and it is not the HAL 9000—a discrete machine animated by a charismatic (yet potentially homicidal) humanlike consciousness—or a Singularitan rapture of superintelligence. The AI on the horizon looks more like Amazon Web Services—cheap, reliable, industrial-grade digital smartness running behind everything, and almost invisible except when it blinks off. This common utility will serve you as much IQ as you want but no more than you need. You’ll simply plug into the grid and get AI as if it was electricity.

"The bulk of AI will be special purpose software brains"

Not even Kelly foresaw the bitter lesson:

Yet most of the commercial work completed by AI will be done by nonhuman-like programs. The bulk of AI will be special purpose software brains that can, for example, translate any language into any other language, but do little else. Drive a car, but not converse. Or recall every pixel of every video on YouTube, but not anticipate your work routines. In the next 10 years, 99 percent of the artificial intelligence that you will interact with, directly or indirectly, will be nerdly narrow, supersmart specialists.

"in conversational tones, any question at all"

Very soon now we’ll live in a world where we can ask the cloud, in conversational tones, any question at all. And if that question has a known answer, the machine will explain it to us. Who won the Rookie of the Year Award in 1974? Why is the sky blue? Will the universe keep expanding forever? Over time the cloud, or Cloud, the machine, or AI, will learn to articulate what is known and not known. At first it may need to engage us in a dialog to clarify ambiguities (as we humans do when answering questions), but, unlike us, the answer machine will not hesitate to provide deep, obscure, complex factual knowledge on any subject—if it exists.

…

As we cognify more books and movies and the internet of things, answers become ubiquitous. We are headed to a future where we will ask several hundred questions per day. Most of these questions will concern us and our friends. “Where is Jenny? What time is the next bus? Is this kind of snack good?” The “manufacturing costs” of each answer will be nanocents. Search, as in “give me an answer,” will no longer be considered a first-world luxury. It will become an essential universal commodity.