Agreguesi i feed

I’ve been using Fedora Silverblue on my desktop and laptop for the past, what, five years? Silverblue is Fedora’s main atomic variant, a spiritual counterpart to Fedora Workstation. I also make niri, a scrollable-tiling Wayland compositor. In other words, a core system component that you cannot properly test from inside a container or VM—you really want it directly on the host. So, why would I choose an… immutable distro? How does that even work?

Fedora Silverblue makes a frequent occurrence in my niri release notes screenshots.

Atomic distributions have been slowly rising in popularity. Their main selling point is reliability: upgrades work by swapping the old system for the new one in one go across a reboot, rather than modifying the files in-place. Package conflicts and other errors are caught at the time of assembling the new version (in a separate folder), and therefore cannot break your running system. And if a successful update turns out buggy, atomic distros let you simply reboot back into the old version and keep using it as if nothing happened.

This “being able to reboot back” thing becomes even cooler once you realize that it works even across major distro upgrades! When the next Fedora Beta rolls around, I can just rebase my system on top of it to kick the tires, and if anything is broken, I can simply reboot back to stable Fedora (and then undo the rebase).

This is like learning about source code version control. A big weight off your mind any time you want to mess around with your OS. You can just go back.

So, by now there are plenty of atomic distributions to choose from. There’s a whole host of Fedora atomic desktops, Endless OS, the gaming-focused Bazzite and other Universal Blue images. GNOME OS Nightly is atomic, as well as SteamOS powering the Steam Deck. Many of these are built with OSTree which is something of a “git for operating system binaries”.

But, you may ask. What if I develop these operating system binaries? Aren’t atomic distros immutable and all, how do I test my work?

Turns out, this is not a problem at all! In fact, the same tech that lets you go back after an update can also let you freely tinker with your host system and safely go back after a reboot. I’d say that thanks to this ability, atomic distributions provide even more benefit for system component developers than for others, given that they’re constantly testing changes that may break their install.

So, let me show you how I do compositor development on Fedora Silverblue. We’ll start with toolbox where most of the work happens, then proceed to the fun stuff.

Toolbox #

On your immutable host system, you need a place where you can install the development environment. Fedora Silverblue comes pre-installed with Toolbox, which provides just that—a terminal in a normal, mutable Fedora where you can sudo dnf install to your heart’s content.

Under the hood, it’s just a podman container with a whole range of things auto-mounted from the host: the Wayland socket, networking, devices, D-Bus, and everything else needed for apps to “just work” as much as possible from inside the container. You can even interact with it through podman commands:

┌ ~ └─ podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6ceccce5581e registry.fedoraproject.org/fedora-toolbox:44 toolbox --log-lev... 2 months ago Up 41 minutes fedora-toolbox-44

Most of your development work happens here. Install all the libraries, compilers, editors, LSPs, debuggers, and the rest of the kitchen sink. Since all of this resides inside the same container, it can all talk to each other and work together.

One slightly annoying detail is that since your fully-configured editor is inside the toolbox, you can’t use it to edit files accessible only on the host (e.g. configs in /etc—the system inside the toolbox has its own files there), but that is honestly a fairly minor problem in practice. Fedora Silverblue comes with nano, which works, and if editing host-only files is a frequent occurrence for you, you can always rpm-ostree install a more featureful editor. Another annoying problem is that currently, toolbox prevents SIGHUP from reaching apps, so if you run your favorite editor then close the terminal window, it will happily keep running in the background (along with all its rust-analyzers and such, eating several gigabytes of RAM).

So, running things in a toolbox works perfectly well for most development. CLI tools will run fine, GUI apps will run fine, you can build and install libraries inside the toolbox and test them on apps inside the same toolbox. Even with Wayland compositors, most of them can run as a window (gnome-shell --nested, or simply sway or niri), which is enough to test the majority of the code base.

Moreover, since ~2023, toolbox exposes everything necessary to run compositors on a TTY directly. You can switch to a different VT with CtrlAltF3, toolbox enter, then start a compositor, and it will work as is. This way you can test different input devices directly (trackpad, tablet, touchscreen), test monitor and GPU handling, do proper performance profiling, and so on. Just remember to install a terminal and some GUI apps inside the toolbox because launching the host ones into a toolbox compositor is a bit annoying.

While toolbox is somewhat Fedora-specific, for everything else there’s distrobox. It’s a separate project, but by and large has the same idea—let you easily install different distros as podman containers with automatic host integration. I mainly use it to build or test things on Arch, but I imagine most of what I wrote above works just as well with distrobox.

What if this isn’t enough, though? Say, you’re working on a component like NetworkManager or systemd that must run on the host system. Or, you want to be able to log in to a test build of your compositor along with the rest of the full desktop session. Let’s look at an easy way to do that.

Unlocking the host #

Run sudo ostree admin unlock, also known as rpm-ostree usroverlay.12 This will mount a mutable overlay filesystem over /usr for you to play around in. The overlay will last until the next reboot, at which point you’ll be back to a clean working system.

Now you can simply sudo cp your development build into /usr/bin and restart the service you’re testing.

This also works with libraries. Say, you want to test your changes in GTK against apps installed on the host.3 Build it inside the toolbox, then copy the binaries to the (unlocked) host, and there you have it. Binary compatibility is generally not a concern since Silverblue updates daily and very closely matches the regular Fedora that you build against inside the toolbox.

sudo cp is not a proper substitute for installing though, and you cannot use it as easily for many projects. So let’s get some proper tooling on the host.

Layering development tooling #

Contrary to an apparently widespread belief, you can install packages on the host in Silverblue. This is called layering and is a perfectly normal and supported operation, primarily useful for adding system components such as terminals, window managers, or GPU drivers. Running rpm-ostree install alacritty will cause rpm-ostree to install, or layer, this package on top of the base Silverblue image every time it updates. After a reboot, you’ll have Fedora with Alacritty, as if you installed it on a regular, non-atomic system.

If the change is sufficiently non-invasive, running sudo rpm-ostree apply-live lets you skip the reboot and have a newly installed program available right away.4

When should you layer (as opposed to installing in a toolbox)? Layering is more annoying and slower, and misses the benefit of throwing away a toolbox to start fresh. So, I limit layering to programs that must run on the host, and tools that I frequently need on the host.

Here’s my list of layered packages that’s been more or less unchanged for several Fedora releases:

┌ ~ └─ rpm-ostree status State: idle Deployments: fedora:fedora/42/x86_64/silverblue Version: 42.20250824.0 (2025-08-24T02:55:42Z) BaseCommit: d58dc92e5b05b6a95a0d9352edd864f1292c1883b9b32ac2e6f0af1a2263395a GPGSignature: Valid signature by B0F4950458F69E1150C6C5EDC8AC4916105EF944 Diff: 12 upgraded RemovedBasePackages: firefox firefox-langpacks 142.0-1.fc42 LayeredPackages: alacritty distrobox dnf fastfetch fish foot fuzzel gamescope gdb gnome-console google-roboto-fonts htop hyprlock i3 kanshi labwc langpacks-ru lm_sensors lxqt-policykit mako nautilus-python netconsole-service niri perf quickshell-git rocminfo strace sway syncthing sysprof tmux trash-cli waybar wlsunset LocalPackages: edid-asus-1-1.fc34.noarch Initramfs: --include /etc/initramfs-overlay /

In this output, you can find:

• I removed Firefox with rpm-ostree override remove—I prefer the official build from Flathub.
• Terminals (must run on the host to access the full host filesystem5): alacritty, foot, gnome-console. My preferred shell: fish. Tool I frequently need: tmux.
• Services and tools that I want to run without a toolbox: syncthing, distrobox, netconsole-service, trash-cli, htop, fastfetch, lm_sensors, rocminfo.
• Desktop components: fuzzel, hyprlock, i3, kanshi, labwc, lxqt-policykit, mako, quickshell-git, sway, waybar, wlsunset.
• edid-asus and the initramfs-overlay provide the EDID for one of my monitors after AMDGPU broke it back in kernel 4.19.6

Along with these, I layer several development tools: gdb, strace, perf, sysprof. These frequently come in handy whenever I need to debug or profile programs running on the host (or do full-system profiling in case of Sysprof).

And then there’s dnf. What?

Layering dnf #

What is dnf, a regular Fedora package manager, doing on an immutable Silverblue host system? By itself, it’s not very useful indeed, since it can’t modify /usr. (Though, it can dnf copr enable, which is convenient. rpm-ostree copr when?)

Where dnf on the host shines, however, is when you combine it with sudo ostree admin unlock. After unlocking, you can install whatever you need in the moment with dnf. This is much faster than rpm-ostree, never requires a reboot, and in fact a reboot makes it all clean up and go away, since it was all in a transient /usr overlayfs.

Example workflows:

• dnf debuginfo-install to debug/profile something on the host with symbols, report crashes, etc.
• dnf install some host-only program to test it. Follow up with rpm-ostree install if you decide to keep it.
• dnf builddep gtk4, then build and sudo ninja install GTK 4 right on the host to test it against host apps. If anything breaks, just reboot, and you’re back to a clean working state.

Unlocking + layering dnf is a very powerful development workflow to the point where I’d almost want dnf included in Silverblue by default. Unfortunately, this workflow is also unobvious enough that the dnf maintainers accidentally prevented it from working some time ago (thankfully, quickly corrected). I understand the UX concern about having dnf visibly available when it cannot work outside this specific workflow, but perhaps Silverblue could just hide it somehow unless the host is unlocked, or rename the dnf binary?

Persistent unlocking #

Generally to put something persistently on the host, you’d just layer it with rpm-ostree install. However, sometimes what you want is a temporary change that also happens to persist across reboots.

This sounds weird, but consider testing a kernel build. You want it to be temporary and easy to roll back, but you kinda have to reboot into the new kernel. And you also don’t want to spend extra time building and layering .rpms.

For this situation, ostree admin unlock comes with a --hotfix flag. It’ll persist the temporary overlay across reboots, and will only reset itself once you explicitly make some change with rpm-ostree. Note that you never lose the ability to reboot into the previous, working system.

Summing it all up #

So, this is what my development workflow looks like.

• Most work happens in one kitchen-sink toolbox that I (like to but am not required to) reinstall every Fedora release to keep cruft from building up. This includes building and running niri on a TTY.
• After finishing a change, I unlock the host with sudo ostree admin unlock, copy over the niri binary, and re-log in to test it in my real session. This will automatically reset upon a reboot.
• When working on a long-running branch, I’ll build a work-in-progress niri .rpm and layer it with rpm-ostree install to persist the new version across reboots.
• I use dnf install on the host when I want to throwaway-test something host-specific and have it automatically reset upon a reboot.

Over time I made a few small quality-of-life tweaks to smooth out some rough edges in this workflow.

For example, toolbox enter is a mouthful and always drops me into bash. Enter t, a script in my ~/.local/bin/, always available in $PATH:

#!/bin/bash if [ $# -eq 0 ]; then command=fish else command="$(printf "%q " "$@")" fi exec toolbox run -c fedora-toolbox-44 bash -ic "$command"

Now, typing t puts me in the toolbox directly into my dear fish shell. Typing

t some-program "with complex" arguments | grep "and stuff"

also works as expected, with correct argument passing thanks to printf "%q ".

This works for .desktop files too. Say, you installed VSCode in the toolbox and got a .desktop file. Just change:

Exec=/usr/share/code/code --ozone-platform-hint=auto %F

to:

Exec=t /usr/share/code/code --ozone-platform-hint=auto %F

and it’ll run in the toolbox. (I understand distrobox handles .desktop files automatically.)

Note that I use toolbox run but route the command through bash. This is necessary to get all environment variables like $DEBUGINFOD_URLS that distros keep stubbornly putting in /etc/profile.d/ scripts, which of course don’t get sourced without a bash -i.

Another quality-of-life improvement was binding a separate hotkey to spawning a terminal directly in the toolbox. I actually noticed that most of the time, when I open a terminal, I want to be in the toolbox, so now my SuperT spawns the toolbox Alacritty, while the less convenient SuperShiftT spawns the host Alacritty.

Furthermore, at some point I got tired of waiting for the…

┌ ~ └─ hyperfine -w 3 --shell=none 'true' 't true' Benchmark 1: true Time (mean ± σ): 411.9 µs ± 35.8 µs [User: 248.9 µs, System: 111.3 µs] Range (min … max): 374.1 µs … 1147.6 µs 5794 runs Benchmark 2: t true Time (mean ± σ): 257.8 ms ± 2.0 ms [User: 3.0 ms, System: 6.1 ms] Range (min … max): 255.2 ms … 260.5 ms 11 runs Summary true ran 625.92 ± 54.60 times faster than t true

…extra 250 ms for toolbox run, and wrote a script that keeps Alacritty running as a daemon inside (and outside) the toolbox, making opening a new terminal window always instant. As a bonus, this happens to fix the SIGHUP problem that I mentioned above: since Alacritty runs directly inside the toolbox, closing its window will properly close the terminal app running inside.

(Eventually I went even further and made a tiny service for fun that runs inside the toolbox, listens to a socket, and runs the command it receives. I only use it in .desktop files though instead of t to avoid the 250 ms delay.7)

What about other systems? #

I quite like my Silverblue setup. It very much works, and with the tools that it has, it lets me do anything that I might need.

Silverblue is not without its problems however, so I’ve been thinking about what parts of the experience I find important, and how well other distributions currently satisfy them.

1. The ability to reboot to a previous, working system. Most new atomic/immutable distros can do this since it’s the main value proposition. It’s also possible on NixOS. On traditional distros I think you can get something close with btrfs snapshots, but it requires a complex setup.

A/B updates tie closely into this, where rather than mutating the running system, an update is prepared in a separate folder, then atomically swapped with the previous system version (which remains available to boot into should something go awry).

2. Anti-hysteresis. The host system always stays clean, packages don’t build up over time.

On a normal distro, a few months is enough for you to scarcely have any idea about all the random one-off packages you installed and forgot about, especially various development tooling and build dependencies not to mention the texlive-full installation. They use up disk space and time during system updates, sometimes cause conflicts and other annoying issues. Config migrations build up, and your system gradually drifts away from a clean well-tested upstream state.

Immutable distros solve this by not letting you install stuff on the host, and every updated rebuild of the host system starts from a fresh state, so there’s no accumulation of junk.

NixOS and Silverblue do let you add (layer) packages, so they can build up, but:

• they make it sufficiently annoying, making you prefer non-host environments such as toolbox for one-off packages;
• even with layered packages, the system is rebuilt from a fresh state every update.

Technically, you could use toolbox for everything even on a normal Fedora Workstation, but this requires discipline and doesn’t save you from config migrations, SELinux labeling changes, etc.

3. The ability to easily install things on the host. This is the part where many newer immutable distros fail to provide a good experience. I need to install programs on the host, whether it’s because I want some host desktop components, or to test my own compositor, or whatever.

Often, I want to install something on the host quickly. For distros such as Universal Blue spins and other bootc-based systems, the suggested way to include components on the host is making your own downstream spin. But this works only for long-term packages: I don’t want to spend time editing and kicking off a full system build just to test some new terminal or notification daemon, not to mention the whole question of how to keep such a custom system always up to date with its base distro.

Compare this with rpm-ostree install on Silverblue: one command, slow but tolerable, and the OS remains automatically updated with no extra setup.

Some systems are even more limited, like GNOME OS which is based on the Freedesktop SDK. The selection of tools and libraries available in the Freedesktop SDK is (intentionally) much more limited compared to most distros, so in many cases you’ll find yourself having to go and build whatever you need from source. If that happens to be something big and complex like Qt (to try a hot new Quickshell-based desktop): good luck; I hope you didn’t have plans for the weekend.

A common suggestion for these OSes is systemd-sysext that lets you build an image and overlay it over /usr. Florian Müllner gave a talk at the 2025 GUADEC showing a nice workflow for using sysexts for Mutter and GNOME Shell development and testing on immutable distros.

It’s also possible to enforce system version compatibility checks in sysexts. A system like GNOME OS could build and ship a collection of sysexts version-locked to the runtime they were built against, and automatically updated together with the rest of the system using systemd-sysupdate, resulting in an experience similar to layered packages. (In fact, GNOME OS does have that, just the selection of sysexts is fairly small.)

Some software can be packaged into self-contained sysexts that work on most distros. The Flatcar sysext-bakery is one repository of such sysexts.

What’s wrong then? Well, the main limitation of sysexts is that they are meant for tools without dependencies. They do not do any dependency resolution or support any dependencies other than, optionally, the base OS itself. Back to my example, while it’s possible to build and ship sysexts for Qt apps that bundle Qt itself, all of those sysexts will carry their own copies of Qt. Even worse, since they are mounted into the same filesystem tree, conflicting files (say, different-version Qt binaries) will get mounted only from one of the sysexts, whichever one happens to mount last. So sysexts aren’t a complete replacement for packages (nor are they intended to be).

4. The ability to make transient changes to the host. While I don’t immediately see why you couldn’t put a writable overlay on any regular distro like what ostree admin unlock does, I haven’t seen anyone doing it, or any simple “no thinking necessary” tools for it.1 Perhaps it’s too easy to mess up outside immutable systems?

It’s worth noting that some paths like /etc aren’t usually covered by immutability and overlays, so you still need to be a bit careful.

Conclusion #

All in all, Silverblue appears to be a sweet spot between offering immutable/atomic guarantees with plenty of useful tooling bundled in, while also being a normal Fedora with a wide package selection available for both persistent layering and quick transient installation. I appreciate the QA and other behind-the-scenes work that goes into my ability to install Silverblue and be reasonably sure that it will work, and keep working, with all of my hardware, and that I won’t have to hunt for packages to get a working bluetooth or what have you. My Silverblue installs are the longest I’ve kept any single distro, and I have no urge to reinstall because my host system remains clean and I know exactly what it comprises.

My issues with Silverblue mostly boil down to some rough edges and slowness of rpm-ostree, and some less than ideal Flatpak repository defaults. Having to do most of the work in a container is somewhat annoying at times, especially when dealing with nested containerization or VMs. But I’m not sure there’s a better way fundamentally, without trading host system robustness. For the few things that do require it, I can always unlock the host.

I hope this post sheds some light on immutable system workflows and perhaps inspires you to try one. I’d also love to hear your feedback and suggestions! Did I miss something? Is there a better way of doing things? A new system that solves all problems and makes everything better? Please reach out to me on Mastodon or by email, linked at the bottom of the page!

1. I’m told the modern alternative is systemd-sysext merge --mutable=ephemeral, which works across all distros and not just Silverblue. Haven’t tried it myself yet! ↩︎ ↩︎

2. I didn’t quite realize this before, but rpm-ostree usroverlay seems to literally exec ostree admin unlock:

   ┌ ~ └─ rpm-ostree usroverlay -h Usage: ostree admin unlock [OPTION…] Make the current deployment mutable (as a hotfix or development) (...) ┌ ~ └─ rpm-ostree usroverlay --version libostree: Version: '2025.4' Git: 99a03a7bb8caa774668222a0caace3b7e734042e (...)  ↩︎

3. Which is, uhh, not a lot of apps come to think of it. Nautilus, Ptyxis, Software, System Monitor, Settings, xdg-desktop-portal-gnome dialogs—the rest come as Flatpaks on Silverblue. How to test your GTK changes against those Flatpak apps? Uhhhhhh ↩︎

4. For years, it’s been rpm-ostree ex apply-live, where ex stood for experimental. I guess I’ve been procrastinating on this blogpost long enough that it had time to graduate to non-experimental rpm-ostree apply-live. ↩︎

5. The Ptyxis terminal can work properly on the host even when installed as a Flatpak. It does this by spawning a small binary on the host (through a host-run permission) that does all command spawning and PTY communication, while the Ptyxis GUI remains inside Flatpak. This is a clever workaround, but requires a sandbox hole and very careful engineering, and arguably runs somewhat at odds with the point of Flatpak. ↩︎

6. Since writing that example, I replaced that monitor and finally got rid of the custom initramfs. This is faster because without overrides, Silverblue directly uses an initramfs built on Fedora servers, and I think it also works better with secure boot? Either way, I wanted to leave it in as an example that you can customize the initramfs on Silverblue if needed. ↩︎

7. See for yourself:

   ┌ ~ └─ hyperfine -w 3 --shell=none 't true' 'true' 'tb true' Benchmark 1: t true Time (mean ± σ): 259.5 ms ± 3.6 ms [User: 2.9 ms, System: 6.2 ms] Range (min … max): 255.7 ms … 266.6 ms 11 runs Benchmark 2: true Time (mean ± σ): 408.7 µs ± 34.2 µs [User: 248.6 µs, System: 107.1 µs] Range (min … max): 370.2 µs … 1152.8 µs 6665 runs Benchmark 3: tb true Time (mean ± σ): 462.8 µs ± 41.7 µs [User: 264.2 µs, System: 135.6 µs] Range (min … max): 399.2 µs … 786.4 µs 6688 runs Summary true ran 1.13 ± 0.14 times faster than tb true 635.00 ± 53.80 times faster than t true  ↩︎

• Up too early. Dropped H. into XJTAG before her epic Asian trip. Lovely to meet up with John Hall and catch up after a couple of decades.
• Tried to pack, and gather together things for the Church's Men's walking weekend.
• Published the next strip: Ejecting a do-er, "if in doubt, kick them out!"; cancellation based on un-proven allegation seems to be the spirit of the age:

Do not let the AI to remove the fun part from software development. We shouldn't allow gen AI to write software just because it "can". First, we must ask if it "should" do it, and even then, we should ask if we want to delegate the fun part, the thinking, the writing, the learning.

Remember what's important, journey before destination, we are the Code:

Do not let AI to destroy the community, do not let it destroy the technological knowledge commons.

tl;dr

Open Source maintainers are dealing with a lot of new reports and pressure to "fix" the project due to generative AI.

We need to find a way of stopping this and get back to something maintainable before all maintainers get burned out and look for a job in a farm:

• 100% secure software doesn't exists, so there will be always a possible CVE there. As Spaf said in 1989:

The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards - and even then I have my doubts.

• Fixing bugs, adds new bugs, and if you need to fix something quick, the probability of new bugs will be higher. Do not forget about the First Law of Programming:

If it works, don't touch it

• The amount of CVE reports is lowering the CVE credibility and quality, so if everything is a "high" security issue, we can't prioritize now and these reports are not different from random issues in github. Do not listen to The Boy Who Cried Wolf

• Stable software is sable because it doesn't change too much. It's something that we are willing to loose trying to reach the impossible of 100% secure software?

The actual problem

There's a lot of money in AI tech right now, and everyone is trying to make the best gen AI tool or just pretend that their tool is the best.

In relation with the software analysis and writing, targeting the open source is the obvious strategy.

1. It's interesting to scrap every line of code, patch, pull request, issue and discussion around software to train your model, so AI scrappers are DDoSing open source projects infrastructure.

2. To promote their tools or themselves, Security Researches are using AI to target any project, reporting High security vulnerabilities, with the only goal of getting a CVE number to say how good they are.

This second point is affecting maintainers, because now you are receiving a lot of poor quality security reports, that are generated with AI and that looks plausible and are hard to read. You need to spend a lot of time to check if there's an actual wolf there or if it's again this boy that's tricking me.

This is burning the energy of maintainers, that instead of doing something productive are wasting their limited time talking with a Stocatic Parrot.

Do not let the AI Bros to use classic manipulation techniques on you!

A lot of open source projects are maintained by volunteers that do the work with passion and love. And even if it's the job that paid your bills, the maintainer can feel the pressure. When someone put a lot of love in something and work on it during years, it's part of his identity, so attacking the software is like attacking the person behind it.

This is nothing new, and a lot of people take advantage of this emotional link to manipulate the maintainer to do something that he do not want to do.

AI bros are using these techniques, do not let them to manipulate you and define your project agenda.

Here's a (not complete) list of known manipulation techniques that you can detect (and disarm!) in your daily community work:

• Flooding the queue. Just create so many new issues that the actual maintainers can't deal with it. You feel responsible for the project and feel bad because your TO-DO list is growing.

• This software is not secure (doesn't do what I want), I will use this other one instead that's better. The classic, "GNOME doesn't allow me to change this specific preference, I'll use KDE from now on".

• This software is low quality, it doesn't follow the (my random) quality standards. Direct attack to the maintainer self-esteem.

• Gaslighting software development. LLM are expert at this and people that uses it just copy the tactic. When the maintainer detects something weird and just tries to blame the other person for reporting nonsense and wasting all people time, it starts to invent new arguments and ignore the previous interaction.

So, take it easy, and remember the best clause in almost any software project, THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU:

Disclaimer of Warranty. THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. Is the software more insecure in 2026?

No. Anyone old enough could remember how insecure old software was. Do you remember windows 98? Do you remember the internet when everything was http (without that little s at the end), when people use ftp to logging into their server and modify the php code directly on production?

It's true that today we have more dependency on technology, but it's also true that everything is more secure, we have more and better cryptography, we have different levels of isolation, virtual environments, containers, virtual machines...

But we have the feeling that since AI can analyse all the software and look for vulnerabilities, we are doomed, because any stupid kid can hack my over engineered GNU/Linux machine!

First, that's not true, you need to know about security to get something useful from any AI tool. But even if it was true, what can you do about it? We need to be practical and find a balance between risk and usefulness, so do not overestimate the risk just because everyone is talking about it right now.

But even then, the security paranoia is not good for anyone. Software is inherently buggy, people write software and makes mistakes, so a possible vulnerability appears. In theory, these bugs are fixed when discovered, so it's always recommended to update to the latest version, because almost all known bugs will be fixed.

But it's also known that new versions comes with new functionality and code, and that means new "unknown" bugs or different behavior. That's a headache, so that's why the stable and Long Term Support are popular distributions, because "if it works, don't touch it".

Stable packages just get the fixes, not new features, but fixes are also code changes, so there's always a possibility to break something, even with a patch update.

The stable software has a lot of value, do not let the AI security paranoia destroy that, and convert everything in a rolling release with the latest and greatest (and possibly broken) software. Sometimes it's better to keep using something old, with known vulnerabilities that you can mitigate, than use the latest with unknown new vulnerabilities that you can't do anything about.

I will fight AI with AI

Please, do not do that. What I was trying to argue during this long post is not a technical problem. The current burnout problem in open source is a social problem, you can't fix it with a new layer of probabilistic tokens.

• Community reaction against AI. The current industry push for the usage of AI everywhere is affecting a lot of people, and as a reaction a lot of people are directly fighting back. Using gen AI just sends the message that you do not care enough to do it yourself, and destroy the trust on the project.

• It doesn't worth it. Even if the AI works (that it doesn't) it doesn't worth it. Writing code is easier than reviewing, you learn and grow with every new line of code that you write, delegating the fun part and personal growth part to an AI will make you work more miserable and you will be a junior forever.

• It doesn't create community. Think about it, it's hard to get someone involved in a software project, but who will want to read or improve the code produced by a gen AI? The only future collaborator will be another AI.

Take it easy

Just remember, you can always say no, there's no hurry, and there's no need to work on something that you don't want just because other people consider that important.

Free Source is something done by people, for people. The software is important, but the community around it is sometimes more important. We use Free source not because it's technically better (that it is), but because we trust who, how and why are writing it.

Remember why are you doing this, do not remove the Fun part, continue with the Just for Fun mood.

• Up much too early, train into London. Met up with some interesting folk from HCL. Pod-cast recording, lunch re-recording a second take; interesting perspectives, fun people.
• Worked on trains home, caught up with J.
• Home group bible study on Malachi.
• Worked until almost midnight to get a response in to the CMA SMS investigation of Microsoft submitted in time; tiring.

schwit1 shares a report from NJ.com: Samsung is pulling up stakes in New Jersey and heading to Texas, a move that could leave roughly 1,000 Garden State workers facing a stark choice: relocate or risk losing their jobs. The South Korean tech giant confirmed this week that it will move its US headquarters from Englewood Cliffs, NJ, to its existing campus in Plano, Texas, marking a stunning reversal less than a year after it celebrated the opening of a new headquarters in Bergen County. The relocation is expected to be completed by the end of the year, according to company statements. "Samsung Electronics America Inc. is undergoing a business transformation designed to better position our organization for long-term growth and future success. As part of this effort, we are relocating our U.S. headquarters from New Jersey to our existing campus in Plano, Texas, building on our 30-year presence in the state," said Samsung in a statement emailed to NJ.com on Tuesday. "As part of this strategy, we will be optimizing parts of the organization to ensure our roles and functions align to key business priorities. We recognize such adjustments will have an impact on our people and we will be providing support to those affected," it continued.

Read more of this story at Slashdot.

Version:next-20260604 (linux-next) Released:2026-06-04

joshuark shares a report from The Verge: Apple will introduce age verification in the App Store for users in Texas starting on Thursday, June 4th. The move, as spotted by MacRumors, comes just days after a federal appeals court allowed Texas' App Store Accountability Act to go into effect while a lawsuit against it proceeds. People in Texas who are creating a new Apple account will need to verify they're over 18 using a credit card or government ID. Apple may also automatically verify users' age using the age of their account and whether they have a credit card on file. Despite Apple's attempts to push back on app store-level age verification, the company has announced plans to implement age checks to comply with laws in places like Utah, Louisiana, Brazil, Australia, Singapore, and the UK. Google is required to make similar changes to the Play Store and is also introducing age-checking tools for developers. Last December, a judge blocked the App Store Accountability Act (SB 2420) from taking effect, but an appeals court has now reversed this decision -- at least while the court figures out whether the law is constitutional. Even if this law gets struck down in Texas, a federal version with the same name is still making its way through Congress and could impose age verification at the app store nationwide.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: UK regulators today ordered (PDF) Google to put clearer attributions and links to publishers' content in its AI-generated search features. The UK's Competition and Markets Authority (CMA) also said Google must give publishers a way to opt out of AI features in search. "In a world first, publishers will now have effective tools to prevent their content being used to power AI features in search, such as AI Overviews," the CMA said today. "This will put publishers, like news organizations, in a stronger position to negotiate content deals with Google. To boost consumer trust, Google is also now required to make sure that publisher content is properly attributed, using clear links, in AI-generated search results." The CMA ruled that Google may not penalize publishers for opting out of AI, meaning that Google can't downrank opted-out publishers in general search results. The CMA said Google will have nine months to comply with all requirements but that the agency "expects important parts of the controls to become available to publishers well before that deadline. Google will also be required to submit and publish compliance reports, supported by key data and metrics, explaining changes it has made and how it has complied." [...] The CMA applied the rules to Google after determining that it has "strategic market status" in general search services, and has ongoing investigations into Apple and Microsoft. Google today said it will comply with the CMA decision. The News Media Association, a trade group in the UK, said that "the legally enforceable Conduct Requirements for Google Search published today are a significant step towards leveling the playing field and building a fair, transparent digital economy where premium content is properly respected and fairly compensated." The group called on the UK to implement "robust enforcement."

Read more of this story at Slashdot.

NASA has officially ended the MAVEN mission after the Mars orbiter stopped responding in December, apparently after an unexpected spin drained its batteries and knocked out communications. Launched in 2013 and orbiting Mars since 2014, MAVEN spent more than a decade studying how the planet lost its atmosphere and helped explain how Mars transformed from a potentially habitable world into the cold, dry planet seen today. The New York Times reports: The NASA spacecraft MAVEN, short for Mars Atmosphere and Volatile Evolution, had been orbiting around the Red Planet since 2014. NASA last received a signal from MAVEN on Dec. 6, shortly before the spacecraft passed behind Mars. Then the spacecraft stopped responding. A review board found that MAVEN began unexpectedly rotating, causing its batteries to drain too quickly and resulting in a loss of power to the communications system. "The team is certainly broken up about this," said Shannon Curry, the principal investigator of the mission and a scientist at the University of Colorado Boulder, at a news conference on Wednesday. "But at the same time, we are incredibly proud of the science we've accomplished over the last decade." NASA officials declined to speculate on the root cause of the mishap. A final report is expected to be released later this year.

Read more of this story at Slashdot.

Amazon has reportedly killed its planned new Stargate series despite giving it a series order in 2025. According to Variety, studio executives were worried it would only appeal to longtime fans. ScreenRant reports: Reports of what became Gero's Stargate series started in 2022, after Amazon acquired MGM Studios. Dean Devlin, who co-wrote the 1994 Stargate movie with Emmerich, was another executive producer for the Amazon show, as were Joby Harold and Tory Tunnell via Safehouse Pictures. The project also had Brad Wright and Joe Mallozzi as consulting producers, with both having had extensive history working within the Stargate franchise. On X, Michael Shanks, who played Daniel Jackson in Stargate SG-1, posted in response to the news that: "Yep. They did that." Mallozzi was resistant to the idea that the series was being geared toward diehard fans: "Nope. No. Sorry. Gonna have to push back on this. We were ever mindful of creating a show that would have broad appeal." In an additional post, Mallozzi went into further detail about why the cancellation is so disappointing: Before the new series was canceled by Amazon, Stargate began with Emmerich and Devlin's movie starring Kurt Russell and James Spader. This paved the way for 10 seasons of Stargate SG-1, followed by five seasons of Stargate Atlantis. There has also been the two-season Stargate Universe, the one-season animated show Stargate Infinity, the web miniseries Stargate Origins, and the 2008 direct-to-video movies Stargate: The Ark of Truth and Stargate Continuum, along with numerous games.

Read more of this story at Slashdot.

An anonymous reader quotes a report from 404 Media: The secondary market for decades old, low-tech John Deere tractors has been booming for years as farmers have sought reliable tractors that they can actually fix without having to deal with John Deere's repair monopoly. A Canadian company has seen that demand and came up with a radical thought: What if they made a new, repairable, "no-tech" tractor to solve what has become a gigantic pain point for farmers? Alberta's Ursa Ag says that it has been inundated with demand after announcing its tractor, which costs roughly half as much as a Deere and has the benefit of not being a repair nightmare. [...] Ursa Ag markets its tractors as "no frills" and "built to last." Ursa Ag's Doug Wilson told me that the company designed the tractor because of a need in the marketplace for a new machine that isn't loaded with tech and is easy to maintain. The company follows in the footsteps of consumer electronics companies like Fairphone, which makes a repairable smartphone and Framework, which makes modular, repairable laptops. The demand Ursa Ag has seen is part of the backlash to manufacturer repair monopolies and the injection of technology and internet-connected sensors and terms of use into even the most basic of gadgets. "I talk to farmers every day and I hear from farmers every day about how they went out and bought machinery from 1987 so that it wouldn't have a computer on it," Wilson said. "All of this came from a simple discussion with a customer who wanted to be able to turn [the tractor] on at the start of the day, to use it, and shut it off at the end of the day. It needed to work, so that's what we built." Ursa Ag's tractor has been hyped in agriculture circles after Wilson showed the tractor off at a Canadian farm show and it was featured by Farms.com. Wilson said more than a thousand farmers have contacted him after that show, from roughly 30 countries. "I got a handwritten letter from a farmer in France who doesn't own a computer and wanted us to mail him information about the tractors," he said. He said the company has thus far made a couple fewer than 100 tractors but is working on tripling its production capacity and has seen a lot of demand over the last few months. "Given the number of my customers that carry flip phones, I would say there is consumer pressure to back away from some of the technology that is unnecessary to perform everyday tasks," Wilson said. "So that is definitely transferable to dishwashers and washing machines, refrigerators. Refrigerators that have screens on them that'll tell you what's inside. It's a little crazy." "That high-tech stuff, the million-dollar John Deere tractor has a place. It has technology that is well worth the money," Wilson said. "But that technology is needed for 5 percent of what a farm does. There are so many applications for tractors on farms that don't require technology. The technology that goes into even a calculator is not required for most farming applications."

Read more of this story at Slashdot.

BrianFagioli writes: Fedora Linux 43 users upgrading to the latest Dovecot mail server discovered something rather unsettling: some older Microsoft Outlook configurations may have been silently ignoring SSL/TLS settings for POP3 email connections for years. According to a Fedora community blog post, affected Outlook clients reportedly continued using insecure port 110 connections even when encryption was enabled in the application settings. The issue surfaced after Dovecot 2.4 disabled plaintext authentication on non secure connections by default, causing Outlook users to suddenly lose mailbox access after the Fedora 43 upgrade. The report suggests the behavior may date back as far as Outlook 2007, although modern Outlook builds were not fully tested. Fedora admins stress that the problem could be limited to legacy account configurations rather than current versions of Outlook itself. Still, the discovery has sparked discussion among Linux admins and security folks because many users likely assumed their email traffic was encrypted simply because Outlook claimed SSL/TLS was enabled. The incident also highlights how stricter defaults in modern open source infrastructure can expose ancient assumptions and questionable behaviors that quietly survived for decades.

Read more of this story at Slashdot.

Ancient Slashdot reader whitroth shares a report from Politico, with the caption: "shutting down Microsoft Office for the International Criminal Court (ICC) was clearly a wake-up call." From the report: The EU is moving to counter American dominance in technology by reaching for one of the oldest tools in its arsenal: industrial strategy. As the European Commission unveiled a plan Wednesday to reduce Europe's reliance on the foreign technology providers that underpin the modern economy, it was careful to stress that it was not picking a fight with U.S. digital giants. Instead, the tech sovereignty package -- motivated in no small part by U.S. President Donald Trump's weaponization of Europe's dependence on American firms -- takes a longer-term view: boost the continent's players so they can eventually challenge their U.S. rivals. [...] If adopted, the package will direct public money toward products that contribute to Europe's economy and independence from foreign firms; cut red tape for data centers; beef up research and innovation through "leadership initiatives"; incentivize countries to share digital capacities in a new "Eurocloud" forum; and require EU governments to come up with national strategies to boost the adoption of cutting-edge tech, including AI. The package will also seek to ramp up the bloc's demand for advanced chips -- a response to criticism by the industry -- with a series of industrial initiatives to revise a 2023 chips law. [...] As part of its proposal to keep a list of trustworthy countries, the Commission would require EU governments to run a so-called "sovereignty risk assessment" for every digital service they rely on, measuring foreign control, potential access to sensitive data and the risk of operational disruption. Within a year, they would have to determine the appropriate level of protection for each public sector and procure digital services accordingly -- unless they can prove doing so would come at a "disproportionate cost," the proposal reads. However, the Commission reserves the right to overrule their assessment in future legislation if it believes they downplayed the risks. The Commission estimated that just one percent of Europe's public services are so sensitive that they would be required under the proposed certification scheme to rely on the strict level that totally excludes foreign technology. "We cannot afford to depend on others for the technologies that keep our hospitals running, our energy grids stable and our services secure," Commission President Ursula von der Leyen said in a statement. "This is about protecting our citizens, defending our interests and making our own choices."

Read more of this story at Slashdot.

I love adaptive interfaces and technology that blends in more than the average human. I’ve spent literally years tinkering with ‘frecency’ ordered lists, bought a meural screen and have recently been glorying in the fantastic GNOME Adaptive Brightness.

On that last point, whilst GNOME already has Automatic Screen Brightness, and it is a good feature, dmy3k’s extension goes further on the specific machines with cool hardware: steadier behaviour with changing light, smoother transitions and brightness curves you can tune. One of the things I’ve been exploring with extensions recently is ’this feature, only more so’ and adaptive brightness is a good example.

Living far from the equator, evenings happen. The room goes grey, the window stops being a useful light source and GNOME is still cheerfully in light mode because I told it to be bright at the time one takes screenshots. Night Light is already doing its bit by then. The display has warmed up, which is nice, but the rest of the interface lacks the level of ‘darque’ required. I wanted the normal GNOME appearance preference to follow the day as well: light while it still feels like day, dark once the evening has properly arrived. Users of other operating systems may be aware of this feature, but for the purposes of this blog post let us pretend that everything below is entirely unique.

So I hacked up Sunset Appearance, a small GNOME Shell extension for GNOME Shell 45 to 50. At civil dusk it writes the same setting GNOME Settings uses:

org.gnome.desktop.interface color-scheme = 'prefer-dark'

At civil dawn it sets it back to:

org.gnome.desktop.interface color-scheme = 'default'

My dad was an aviator, so I got to hear a lot of exciting words growing up, such as ‘civil twilight’, which always makes me think of Romeo and Juliet. Sunset turns out to be a surprisingly slippery concept, and very longitudinally mediated. In London in summer there can be plenty of useful light after the sun has dipped below the horizon, and the desktop does not need to go ‘darque’ the moment the sun touches the skyline. Nautical and astronomical twilight are too late for an interface preference, and in some places at some times of year they can fail to happen in the normal way at all.

Civil twilight is when the centre of the sun is 6 degrees below the horizon and when it really does feel like the world has changed character.

Location is awkward too, because civil dawn and dusk need latitude, longitude and date. There’s some interesting fallback logic to infrequently get a coarse location (good enough for a city) and then fall back to cached data if available as Night Light already needs much the same information. Frequent readers will remember my concerns over London, Ontario being above London, England in many search boxes so there is no virtue in making the user type London into another small box. If neither source has usable coordinates, nothing changes.

Manual override behaviour is another thing that avoids annoyance. If the extension sets dark mode at dusk and I then change GNOME back to light mode, I meant that. After any override, it waits until the next scheduled dawn or dusk transition before touching the setting again.

Solar time code has an unreasonable number of edges for something everyone thinks they intuitively understand. Keeping with my aggressive policy on internationalisation the tests keep London as the ordinary case, then poke at time zones, date line longitudes, DST changes, Antarctic stations, Arctic towns, awkward offsets such as Lord Howe and Chatham and cases where civil dawn or dusk may not exist at all. My time reading brr and pretending to be in New Zealand to solve work bugs was not poorly spent.

Right now Sunset Appearance can be built from source. At some point I may choose to distribute it more widely, or even see if someone has already solved my problem better.

According to supply chain analyst Ming-Chi Kuo, Apple has reportedly doubled 2026 MacBook Neo production from 5 million to 10 million units after stronger-than-expected demand for its $599 budget laptop. MacRumors reports: On an earnings call in late April, Apple's CEO Tim Cook said that customer response to the MacBook Neo was "off the charts," and the popularity of the laptop has reportedly led the company to significantly boost production. [...] Apple was very optimistic about the MacBook Neo before announcing it, but the company still "undercalled" the level of enthusiasm that the laptop would generate, according to Cook. He said that MacBook Neo demand exceeded Apple's expectations and helped to drive a record number of first-time Mac buyers last quarter. New figures from market research firm IDC support Apple's claim that the MacBook Neo is selling well, and the Windows PC industry has taken notice. For example, Dell recently introduced a redesigned XPS 13 laptop from $699 and said it has features "you won't find on a MacBook Neo," such as a touch screen and a backlit keyboard. "Apple's MacBook Neo is a capable machine, and its arrival confirms that there's real appetite for premium quality at accessible prices," admitted Dell.

Read more of this story at Slashdot.

Google has launched Gemma 4 12B, a 12-billion-parameter open AI model designed to run locally on your laptop without depending entirely on cloud infrastructure. WION reports: According to Google, the new model delivers performance close to much larger AI systems while requiring significantly less memory. The company says Gemma 4 12B can run locally on devices equipped with just 16GB of VRAM, making advanced AI more accessible to developers, researchers and businesses. The launch highlights a growing trend across the AI industry: bringing powerful AI models directly to personal computers instead of relying solely on remote data centers. Gemma is Google's family of open AI models built using technology and research from its Gemini program. The new Gemma 4 12B model contains 12 billion parameters and has been designed to handle multiple types of information, including text, images and audio. Unlike traditional AI systems that focus only on text, Gemma 4 12B can understand visual content, process audio inputs and perform advanced reasoning tasks. This makes it suitable for a wider range of applications, from software development and content creation to research and automation. Google says the model is available under the Apache 2.0 licence, allowing developers and organizations to use, modify and deploy it with relatively few restrictions. [...] One of the most significant technical changes in Gemma 4 12B is its new unified architecture. Traditionally, multimodal AI systems use separate components known as encoders to process images, audio and text before combining the information. Google says Gemma 4 12B removes the need for separate multimodal encoders. Instead, the model processes different types of information through a unified architecture. According to the company, this helps improve efficiency while reducing memory requirements and computational overhead. The result is a model that can deliver advanced multimodal capabilities while remaining small enough to run locally on modern hardware.

Read more of this story at Slashdot.

Google has released (PDF) technical specs and 2D CAD drawings for the Fitbit Air to encourage users to make their own accessories. "These CAD drawings include crucial mating dimensions, tolerances, and mating force specifications -- including attach and detach force -- to help you build a high-quality accessory band," Google says on a store page listing. 9to5Google reports: Noting how the "community has already come up with innovative and creative new ideas to make the Fitbit Air [their] own" since launch last month, Google is "officially releasing the hardware specifications and accessory design guidelines for the Fitbit Air tracker to the public." For example, owners have already found their own bicep band solutions. This information would typically just be available for third-party accessory companies, but Google wants to open things up to "independent designers and artisan makers." The Google Store page also lists other things developers should keep in mind, such as sensor clearance, sensor pressure, secure retention, and skin-friendly materials.

Read more of this story at Slashdot.

An anonymous reader quotes a report from Ars Technica: Microsoft's Build developer conference kicked off today, and as with almost everything the company has done in the last few years, Microsoft's opening keynote focused overwhelmingly on AI and other closely related technologies. [...] On the hardware front, we didn't get any updates for existing Surface devices (not counting yesterday's Surface Laptop Ultra announcement), but we did get something new: the Surface RTX Spark Dev Box is "a compact developer PC" built around Nvidia's new RTX Spark chip with up to 128GB of built-in memory. The Dev Box looks a little like a cartoon anvil or piano fell onto an Xbox Series X and flattened it. Its aluminum casing was designed "to double as a heatsink," and its preloaded version of Windows 11 Pro will include a "purposeful" set of developer-centric default settings and preinstalled tools. This is a follow-up of sorts to the Windows Dev Kit 2023, also known as "Project Volterra." This Qualcomm Snapdragon 8cx Gen 3-powered PC was essentially the system board from a Surface Pro tablet stuffed into a plastic box, and it was introduced alongside Arm-native versions of several Microsoft developer tools. It helped to set the stage for the Arm-based flagship Surface devices that launched the next year, which benefitted from a better and faster x86-to-Arm code translation technology called Prism and a greater number of Arm-native third-party apps that didn't need to be translated in the first place. Microsoft didn't announce pricing or specific specs for the RTX Spark Dev Box, but you can probably expect it to cost quite a bit more than the $600 that Project Volterra did. Hopefully, Microsoft can keep the price at least somewhat lower than the $4,699 asking price for Nvidia's similarly specced DGX Spark box. On the software side, several developer-centric changes are coming to Windows 11, particularly for users of the Windows Subsystem for Linux (WSL). Microsoft is introducing a Windows-native version of the coreutils command line tools, so that commands or scripts made for Linux work within Windows and the other way around; the ability to run WSL inside of containers, said to be arriving in "the coming months"; and something called Windows Developer Configurations that uses the WinGet tool to quickly set up "a distraction-free dev environment with VS Code, GitHub Copilot, WSL, PowerShell 7 and developer-optimized settings with one command on any Windows 11 device." Microsoft also introduced Microsoft Execution Containers (MXC), as "enterprise-grade sandboxed environments" that let AI agents like OpenClaw operate on Windows without getting unrestricted access to the whole system. In theory, MXC could let organizations enforce agent-specific limits, such as blocking access to personal accounts, separating work and personal data, or requiring permission before deleting files. The MXC GitHub repo also notes support for "multiple containment backends," meaning the same sandboxing concept could apply beyond AI agents to other plugins, tools, and workloads. Further reading: Microsoft Unveils Scout, an Autonomous AI Agent Built On OpenClaw

Read more of this story at Slashdot.

Meta is scaling back parts of its employee tracking initiative after staff objected to software that collected mouse movements, clicks, keystrokes, and other actions for AI training data. According to Reuters, the company will now let workers pause collection for up to 30 minutes and request exemptions. Reuters reports: [Stephane Kasriel, a vice president in Meta's AI model-building Superintelligence Labs unit] said the team behind the software had also introduced "several optimizations" to reduce its impact on computer battery life, after employees complained it was consuming so much data it was causing their home internet usage to spike. "While we remain confident in the privacy protections we put in place at launch, which went through several layers of risk review, we have heard your concerns about personal data on work devices, battery life, and wanting more control over when capturing happens," Kasriel said in the memo.

Read more of this story at Slashdot.

Microsoft says its new Majorana 2 quantum chip is 1,000 times more reliable than its predecessor, with qubits lasting about 20 seconds instead of milliseconds, and claims it could have a commercially useful quantum machine by 2029. The BBC reports: "We will have a quantum machine in 2029 that can solve commercially viable, reasonable problems," said Zulfi Alam, corporate vice president of Microsoft Quantum. That would still require huge further advances as such a device would require millions of qubits - the current chip, Alam said, has 12. Assessing the firm's claims are difficult because it does not release the full details of what it has discovered publicly, citing commercial confidentiality. Microsoft has spent 20 years pursuing an approach to quantum computing known as "topological." The firm's approach to this is based on exploiting the properties of a so-called quasi-particle, which had existed only in theory, since it was first predicted in the 1930s by Italian physicist Ettore Majorana. To do this it had to exploit a novel state of matter - different from the three familiar states of liquid, solid or gas. Paul Stevenson, a physics professor at the University of Surrey, said the tech giant's timeline sounded plausible - if its research lived up to its claims. "Microsoft appears to have made a leap in their attempt to produce viable topological qubits," he said. "If they succeed, they will leap from being a player with no production quantum computer, to being a serious player in the race to make the next generation of fault-tolerant machines."

Read more of this story at Slashdot.