iXsystems put TrueNAS CORE into what it called a sustaining engineering phase back in 2024. Under this, the open source NAS operating system would only receive security and stability fixes, with new features going to the Linux-based SCALE branch instead.

Even its maintenance releases got axed when iXsystems marked 13.3-U1.2 as the final release for the 13.3 series (or train as they call them).

SCALE has since been renamed TrueNAS Community Edition, and users who didn't want to move to a Linux-based OS were stuck with CORE and no actively developed FreeBSD-based path forward.

FreeCORE looks to be that path.

What is FreeCORE?

It traces directly back through TrueNAS CORE to FreeNAS, and it's built on the same foundation CORE always used: FreeBSD and OpenZFS. The current stable release is 15.0-U1.3, and it is aimed at TrueNAS CORE holdouts.

Basically for people who rely on features like FreeBSD jails and bhyve virtual machines who have no interest in moving to TrueNAS Community Edition's Debian Linux base.

It's also worth knowing that FreeCORE is a one-person project. Their motivation for creating this was that they needed a FreeBSD way off their own TrueNAS CORE box instead of migrating to Linux.

So they built one, leaning heavily on AI coding agents for the implementation while directing and validating the work themselves.

FreeCORE's FreeBSD 15 base carries along many practical component upgrades with it too!

OpenZFS climbs from 2.1.14 to 2.4.2, Python from 3.9 to 3.11, and the web interface runs on a much newer build of Angular.

WebAuthn security keys now work as a second login factor, and one-time passwords cover console logins. Jails can share the host GPU through a new DRM driver, and rar2fs mounts RAR archives read-only.

FreeCORE also gets rid of vendor telemetry and offers a web interface that lets you manage everything from jails and virtual machines to storage, sharing, and user accounts.

Jails networking runs through VNET, NAT, or DHCP depending on what the setup needs, and an advanced jail creation form exposes every option for admins who want a greater level of control.

Get started

Most of you arriving at FreeCORE are likely running TrueNAS CORE 13.3, and moving is only a matter of taking a backup and running this script:

fetch https://freecore.org/freecore-enroll.sh && sh freecore-enroll.sh

Running it switches the system's update train and certificate away from iXsystems' servers and points it at FreeCORE's.

From there, the upgrade runs through System › Update like any other update. The configuration database migrates on first boot, though not everything makes it across. OpenVPN gets replaced by WireGuard, and enterprise-licensed features don't carry over.

Of course you could always go the fresh install route, where you write the image to removable media, verify it, and then boot from it to install it on a drive.

The official documentation is a handy resource that covers a range of topics related to FreeCORE installation and usage, while the source code lives on Codeberg.

Suggested Read 📖: Here are your choices for an open source NAS operating system if you don't prefer FreeCORE.

It's been a while since I last wrote about Bottles. For anyone new to it, Bottles runs Windows software on Linux by hiding most of Wine's configuration work behind a straightforward interface.

Its feature list has been growing consistently too. You can pull common Windows components like .NET and Visual C++ runtimes with a single click, or juggle multiple Wine and Proton runners per bottle.

Additionally, UMU support lets you run Proton games outside Steam, and snapshots give every experiment of yours a rollback point.

With its newest offering, Bottles pushes past x86_64 hardware. Bottles 67.4 is a test release aimed at ARM64 on Linux, which is delivered through an experimental cpak package.

And know that the ARM64 rollout actually spanned two releases. 67.3 added the first ARM64 build of the cpak package, and 67.4 followed hours later with a few misc fixes and Soda 11.0-10.

Must-know bits

On ARM64 systems, cpak now fetches the right build for the platform, while Soda, Bottles' Wine-based runner, carries native ARM64 and ARM64EC support. FEX also comes bundled for running x86 and x86_64 Windows software.

All of that makes Bottles genuinely useful on ARM64 Linux hardware, be it single-board computers or Arm-powered laptops.

What surprised me most was the speed at which this was delivered.

The request to add ARM64 (or AArch64) builds was opened a week ago. Within three days, there was a test candidate, the request poster (TCB13) confirmed Bottles launched on their own ARM64 hardware, and the issue was closed and marked as completed soon after.

The tagged releases followed on September 7.

If you were wondering why they chose cpak for the test run, Mirko Brombin from the Bottles team says that:

Cpak is being used for this test because it is the first packaging path where the application, Wine base and native ARM CI are available together.

The other part of the release is the inclusion of Soda 11.0-10, which comes with a range of updates. Battle.net crashing on startup is the issue that some of you will notice first. It has been fixed, and the underlying problem was XInput starting up without a Steam game ID.

For VR workloads, 64-bit Windows OpenXR apps can now connect to a host runtime such as Monado or WiVRn directly without needing to keep Steam or SteamVR running. You can go through the changelog (linked above) to learn more about this Soda release.

Installing it

Currently, the test ARM64 build ships only as a cpak, the OCI-based package format from the Containerpak project. Work is underway on getting the Flatpak release ready for this platform.

That said, you can quickly install the cpak test release on your ARM64 devices by running the following command:

cpak install github.com/bottlesdevs/bottles

If you didn't know, cpak is a packaging format that treats apps as OCI container images, each paired with a small manifest that lists its permissions and dependencies.

How cpak differs from Flatpak is that it does not lean on runtimes and portals the way Flatpak does. The cpak runtime mounts the OCI image directly, the manifest decides what the app can touch, and packages install from a Git origin instead of a central store.

Ikey Doherty is out of retirement, and Omarchy's funding is why.

In a video posted on YouTube, the creator of Solus and AerynOS called the money behind DHH's distro absurd and promised to do it better with nothing. His answer is Barney, a Rust-based tool for building Linux distros from source.

Omarchy's Omacom Foundation has already crossed $13 million in pledges since its August launch, when eight tech executives, including Michael Dell, put in a million each.

The run has drawn its share of pushback, most recently when 1Password pledged $300,000 and its own employees objected. Ikey's video arrived a day after the foundation announced $1.95 million in AI tokens from Meta, Anthropic, OpenAI, and Fireworks.

Not a distro, but a stance

Barney is a tool meant to help you build Linux distros; the repo describes it as "yet another feckin' tool to build a Linux distro" and notes that delivering a distro is not the intended goal.

Ikey plans to show how distros get built instead of shipping what he calls a "wallpaper respin" via a series on his YouTube channel.

Everything gets built from source, and the outputs are cached against what produced them. Change a dependency, and anything built on top of it gets rebuilt. Layouts stay stateless, a concept Doherty says he helped pioneer on Intel's Clear Linux team and later pushed in Solus and AerynOS (formerly Serpent OS).

Builds run in containers, and the results are stored by content, so identical files across packages only get stored once. The plan even includes rebuilding the toolchain from scratch.

Everything is written in Rust and released under the MPL-2.0 license. The project's name itself is personal to him, as Barney is his son's name.

Work on it has started already. The first episode of the series is live, titled "Episode 0: Getting Ready." For access to the behind-the-scenes content, Ikey has set up a Ko-fi page where people can directly support him.

An Irish Traveller's reply

Don't assume that this is something Ikey has no business talking about.

Omarchy's creator, David Heinemeier Hansson, better known as DHH, had written a post comparing Denmark's wolf population with Romani people camping in Copenhagen parks.

Naturally, Ikey, being an Irish Traveller, a group that has faced discrimination for generations, was bound to react. On LinkedIn, sharing his video (the one linked at the very beginning), he called DHH's comments "horrific" and said the funding and the views together had dragged him back into the game.

His laptop buying plans have changed too. Michael Dell was among the launch backers, and Ikey has put the company on his avoid list, while also calling out Omarchy:

Gonna be honest I won’t buy another Dell laptop after Michael Dell showing support for DHH. Skipping the point of it being yet another wallpaper-respin distro.. I cannot possibly tolerate the comments made by DHH (on a number of topics)

As an Irish traveller, I strongly condemn his rhetoric surrounding nomadic people.

As a former Linux distro developer, I wouldn’t touch his shit if you paid me.

Will it do well?

Only time will tell. Right now, my read is that the question misses the point. Barney is not here to become the distro everyone installs. Success, by Doherty's own framing, is showing how a real distro gets built while the industry watches.

You already know that he has walked away from big projects before. Solus and AerynOS both carried on without him. Barney could be next, sure.

What stands out to me is the timing of it all. Another Clear Linux member, Auke Kok, is building The Ur Project from scratch, and neither of them is waiting for a foundation to get going.

The optimist inside me says that if the two of them ever collaborated, they could deliver something that shows the Linux ecosystem that pouring absurd amounts of money into a project isn't the only way to build well.

Nitter, the open source front-end for reading X posts without signing up for an account, is not going anywhere yet.

Weeks after X Corp's lawyers showed up demanding a permanent shutdown, the project's GitHub repository has come out of read-only mode with an updated README that says:

UPDATE: Following legal advice, the Nitter project will continue. More details will be announced soon.

Now, the repository and the homepage carry the same message, with the latter further stating that the flagship instance of Nitter and third-party-hosted ones will be back up soon.

A proper announcement is expected sometime within the next few days.

What X's letter did

On August 24, X Corp sent out cease and desist letters demanding a permanent takedown of Nitter instances and the project's repository. The deadline was 5 PM EST on August 25.

Nitter complied, and the repo was archived and marked as read-only. nitter.net's content was replaced by a short notice (which has since been updated), and a popular instance, XCancel, halted its operations.

TechCrunch, which obtained the letter, reports that X accuses Nitter of an "unlawful use and circumvention of X's Application Programming Interface (API) and associated data."

X alleges that it has evidence that Nitter scraped X data and accessed X accounts and session tokens in violation of X's rules, citing the Texas Harmful Access by Computer Act and the Lanham Act.

So far, X has not publicly commented on the shutdown or the reversal.

Not the first time

This is not the first time Nitter has been declared dead. In early 2024, X removed the guest account feature the project relied on, resulting in the project's lead, Zedeus, announcing the end.

The project found a workaround and returned sometime in 2025.

Nitter's inspiration, Invidious, a privacy-friendly YouTube front-end that has had its own run-in with big tech lawyers, faced a seven-day shutdown demand from YouTube in June 2023.

Fast forward to now. The project has kept going, and nothing came of the demand.

Makes you think such moves exist to strong-arm open source projects into submission rather than enforce rules. To these companies, any project is worth a lawsuit if there is even a shred of justification.

What remains is that Nitter says legal advice cleared it to continue, but not what that advice was or how instances will operate going forward. The announcement is where those answers come to us.

This could escalate

As far as I can see, X tried to choke such projects by closing the access they relied on back in 2024. It didn't work. Now, in 2026, they tried throwing the book by sending lawyers after them.

Seeing that X leadership has been quite disruptive, I have a feeling that they won't back down this easily, and things will escalate. When they do, I hope the open source community stands behind projects like Nitter.

Most Linux users benefit from GNU Readline without realizing it. It is the library responsible for Bash's interactive command-line editing, providing familiar features like cursor movement, command history, and basic tab completion.

While Readline is highly configurable, Readline's completion remains relatively simple out of the box.

I came across a new tool called Flyline that takes Bash command completion to an entirely different level. No special configuration is required.

For anyone who has control over their shell environment, Flyline could become a must-have terminal tool.

Flyline takes a different approach entirely. Instead of layering on top of Readline, it replaces it outright. It is built in Rust and ratatui to render richer, more interactive terminal interfaces than Readline.

Exploring Flyline features

When I installed Flyline for the first time and started using it, the difference was immediately noticeable. Command suggestions appeared as I typed, making it quicker to complete commands and move through my workflow. It makes working in the terminal noticeably faster.

IntelliSense style autosuggestion

As soon as you start typing, Flyline displays a completion popup right next to the cursor with matching suggestions. This keeps the suggestions close to where you're working, making it easy to complete commands without breaking your typing flow.

You can cycle through the available suggestions by pressing the Tab key, with the selected entry being updated on the command line in real time. If you prefer, the Up and Down arrow keys work just as well, and the completion list can also be navigated using the mouse.

For longer lists, Flyline includes a functional scrollbar that lets you quickly jump through the available suggestions. Personally, I found it faster to keep typing and narrow down the results rather than reaching for the mouse, but it's nice to have the option.

Once you've found the suggestion you want, press Enter to insert it into the command line and close the completion popup.

Fuzzy search and path completion

Traditional command completion usually expects you to type characters in the correct order. For example, typing pamc won't normally suggest pacman, since the entered characters don't match the expected sequence.

Flyline addresses this with fuzzy search support. Instead of requiring an exact character order, it tolerates minor typos and partial matches, making it much easier to find the command you're looking for. This means you can type a bit more naturally without worrying about getting every character in the right place.

The same fuzzy matching also works for file and directory paths. As you type, Flyline presents matching paths based on your input, allowing you to navigate deep directory structures with fewer keystrokes. I found this particularly useful when working with long or nested paths, where a small typo would normally require me to backtrack and start over.

Automatic completion synthesis (a lifesaver)

Not every command line tool ships with a completion script. Install a new CLI tool and you keep on pressing tab, and nothing happens. No suggestions appear.

When that's the case, Flyline can generate one automatically by parsing the command's --help output and available man pages.

I noticed this while trying ffmpeg, which didn't have a completion script on my system. When I typed:

ffmpeg --<Tab>

Flyline prompted me to generate a completion script for the command. After confirming, it analyzed the available documentation and created a completion definition on the fly. From that point onward, option completion for ffmpeg worked as expected.

This is also useful for commands with dozens, or even hundreds, of available options. Instead of repeatedly opening the man page or running --help to look up an argument, I could simply rely on the generated completions and discover the available options as I typed.

It makes working with feature-rich command-line tools much more convenient.

Customize the cursor (for vanity)

This isn't exactly a productivity feature, but it does make the terminal feel a bit more lively.

If you've used the Kitty terminal emulator, you might be familiar with its cursor animations. Flyline brings similar effects to virtually any terminal emulator, letting you customize how the cursor looks and behaves.

To explore the available cursor options, run:

flyline set-cursor --help

This displays the various settings you can tweak, including cursor style and animation effects.

For example, the following command adds a cursor trail that closely resembles Kitty's animated cursor, even if your terminal emulator doesn't support it natively.

flyline set-cursor \
  --backend flyline \
  --style "#33ccff" \
  --interpolate 1.5 \
  --interpolate-easing out-elastic \
  --effect fade \
  --effect-easing in-out-sine \
  --effect-speed 2.0

A refined shell history

Flyline also gives Bash's reverse history search a much nicer interface. Instead of the traditional incremental search prompt, it presents your command history in a dedicated view where you can see each command in full, search through previous entries, and even check when a command was executed.

Just like command completion, history search also supports fuzzy matching. This makes it easier to find an older typed command, even if you don't remember the exact sequence of characters.

What impressed me the most, though, was the Canceled Commands feature. The first time I pressed Alt+R, the list was empty. However, every command I subsequently interrupted with Ctrl+C, was automatically added there.

Remember, it is the commands that are interrupted without executing are added to the cancelled list, and not those commands that are executed and then pressed CTRL+C.

This list is kept separate from your regular shell history, so searching your normal command history with Ctrl+R remains unaffected, while cancelled commands are available through Alt+R. The only limitation is that the list is maintained per terminal session, so it is cleared once you close or reset the terminal.

Working with AI agents

Flyline can also work with your favorite AI assistant to turn plain English into executable Bash commands. Once you've configured an AI agent, you can simply describe what you want to do in natural language, and Flyline will ask the agent to generate the corresponding command.

For example, you could type something like:

ai: list files older than three days

Pressing Alt+Enter, or simply Enter if you've configured a trigger prefix such as ai:, sends the prompt to the configured AI agent. Flyline then displays the generated command with syntax highlighting before you decide whether to run it. If the agent returns additional information in Markdown, Flyline renders that as well.

I didn't test this feature personally. I will let you try and comment your experience with it.

Prompt customization

Flyline doesn't just enhance command editing, it also offers extensive prompt customization. You can build rich prompts with dynamic widgets, animations, left and right prompts, transient prompts, live time displays, and even your own custom widgets that run shell commands in the background.

The project's documentation goes into great detail, complete with examples and screenshots for the various customization options. Rather than covering each one here, I've put together a sample configuration that combines several of these features, including a subtle animation. Simply append the following to your ~/.bashrc to give it a try.

# 1. Create the animation widgets
flyline create-prompt-widget animation \
  --name "SPINNER" \
  --fps 12 \
  '\e[38;2;137;180;250m⠋\e[0m' \
  '\e[38;2;137;180;250m⠙\e[0m' \
  '\e[38;2;137;180;250m⠹\e[0m' \
  '\e[38;2;137;180;250m⠸\e[0m' \
  '\e[38;2;137;180;250m⠼\e[0m' \
  '\e[38;2;137;180;250m⠴\e[0m' \
  '\e[38;2;137;180;250m⠦\e[0m' \
  '\e[38;2;137;180;250m⠧\e[0m' \
  '\e[38;2;137;180;250m⠇\e[0m' \
  '\e[38;2;137;180;250m⠏\e[0m'

flyline create-prompt-widget animation \
  --name "PULSE" \
  --fps 6 \
  --ping-pong \
  '\e[38;2;166;227;161m●\e[0m' \
  '\e[38;2;116;199;236m●\e[0m' \
  '\e[38;2;203;166;247m●\e[0m'

# 2. Set prompt variables
PS1='\e[1;32m\u@\h\e[0m:\e[1;34m\w\e[0m\nSPINNER PULSE \e[1;35m❯\e[0m '
PS1_FILL='─'
RPS1='\e[38;2;249;226;175m\t\e[0m'
PS2='\e[2mFLYLINE_PROMPT_LINE_NUMBER ›\e[0m '

# 3. Set transient history cleanup
PS1_FINAL='\e[38;2;166;227;161m✔\e[0m \e[1;34m\w\e[0m \e[1;30m❯\e[0m '
RPS1_FINAL=''
PS1_FILL_FINAL=''

# 4. Enable cursor trail & motion
flyline set-cursor \
  --backend flyline \
  --style "#cba6f7" \
  --interpolate 1.5 \
  --interpolate-easing out-elastic \
  --effect fade \
  --effect-easing in-out-sine \
  --effect-speed 2.0

Restart your terminal and enjoy the effects.

Install Flyline

The easiest way to install Flyline is by using the official installation script. Open a terminal and run:

curl -sSfL https://github.com/HalFrgrd/flyline/releases/latest/download/install.sh | sh

The installer downloads the latest release and automatically updates your ~/.bashrc to load Flyline, so there's no need to perform any additional setup manually.

Once the installation is complete, launch the interactive tutorial with:

flyline run-tutorial

I recommend going through the tutorial before you start using Flyline. It walks you through onboarding, making it much easier to get comfortable with the enhanced editing experience.

Uninstall Flyline

If you decide Flyline is not for you, uninstalling it is straightforward. The installation script does not currently provide a dedicated uninstall option, so you need to remove the Flyline library and the line added to your ~/.bashrc manually.

Here is how the installation script installed Flyline.

So, to uninstall, first, disable Flyline in the current Bash session:

enable -d flyline

Now, remove the installed library:

rm -f ~/.local/lib/libflyline.so*

Finally, open your ~/.bashrc and remove the line that loads Flyline. It should look similar to this:

enable flyline 2>/dev/null || enable -f "~/.local/lib/libflyline.so" flyline

Save the file and start a new terminal session. Flyline should now be completely removed.

Is there anything similar for ZSH?

When I started using Flyline, apart from its intellisense style completion, I can't say it felt like a first in a lifetime moment, because I kind of used a similar functionality in ZSH for some time.

Flyline is designed exclusively for Bash, so you can't use it with Zsh.

But, the combination of zsh-syntax-highlighting, zsh-autosuggestions, and zsh-autocomplete covers many of the features you'd expect from an IntelliSense-like command-line interface.

Together, they offer inline suggestions, syntax highlighting, and interactive command completion that make working in the terminal much more comfortable.

If you pair these plugins with a prompt framework like Starship or a Powerline-style prompt, you can build a polished and highly productive terminal environment.

Wrapping Up

Flyline is one of the new breed of terminal tools that are built in rust to be faster and provide features that either require too much config effort or not possible in classic GNU tools at all.

From intelligent command completion and fuzzy search to AI-assisted command writing and prompt customization, Flyline adds plenty of quality-of-life improvements without changing the shell you've grown accustomed to.

Give Flyline a try. It's already a capable tool, and with active development, it'll be interesting to see how it evolves in the future.

Omarchy has been on something of a roll now. Funding for its foundation has been climbing fast, from an $8 million launch to $10 million a few weeks later, and now crossing $13 million with the most recent pledge.

What's drawn my attention are the first two Corporate Patrons, 1Password and 37signals, both of whom have decided to pitch $100,000 a year for the next three years. Now, 37signals I get; DHH is heavily involved there, but 1Password was a surprise entry.

Naturally, not everyone's onboard with their pledge.

Signs of disagreement

This has not gone well with employees working at 1Password, with company leadership having to take certain damage control measures to assure their staff.

An internal Slack message has surfaced (courtesy of The Verge), which shows cofounder Roustem Karimov downplaying the criticism, telling team members that:

people have different personal opinions. You believe in your heart that DHH is evil, that you have the moral high ground, and that nothing will change your mind.

However, not everyone believes that. It is not fair to claim a monopoly and ostracize team members who might disagree with you. There are people who are afraid to speak up simply because they will be personally attacked.

CEO David Faugno responded on a different note, telling employees the company doesn't endorse DHH's views, while also claiming that Omarchy is the second most used Linux distribution among 1Password's own users.

Why the backlash?

DHH is known to be someone who firmly falls on the "right" side of the political spectrum, someone who doesn't shy away from putting his opinions in public view.

He regularly posts blogs that show where he stands on certain societal issues, and some of his recent writeups are what's fueling this particular backlash.

His recent July post, titled "Wolves, sheep, and gypsies," compares Denmark's wolf population with the Romani people camping in Copenhagen parks, where he argues: "When gypsies take over public spaces, you deport them."

Then there's "As I remember London" from September 2025, where he laments about London losing its native Brit majority and a nod of approval for a Tommy Robinson march.

Of course, these aren't the only factors behind his disapproval, but you get the gist of it, right?

Users could jump ship

If you search for the terms "1Password" and "Omarchy" right now, you are bound to run into the many comments made by disgruntled 1Password users on Reddit and Hacker News.

They are calling the choice tone-deaf, given how many smaller open source projects could've benefited from the money. Some are already jumping to alternatives like Bitwarden, while others suggest self-hosting Vaultwarden or going with KeePass and its forks instead.

I see the issue compounding too. Back in February, 1Password raised subscription prices, taking effect at renewals from March 27. Individual plans went up 33 percent from $35.88 to $47.88 a year, and family plans went up 20 percent from $59.88 to $71.88.

Its community forum already has a long thread full of longtime users saying they were leaving over it. If 1Password continues playing with its users' trust like this, who knows what kind of exodus it will see next?

Debian has gotten some good press thanks to Federico Vaga and Nikos Tsipinakis, who presented a talk at MiniDebConf Winterthur this past weekend.

The two CERN engineers laid out why the organization is moving its particle accelerator control computers onto Debian 13, with more than 2,200 industrial computers and embedded systems set to run it by the end of 2026.

Though this doesn't mean that the whole CERN IT infrastructure is being moved. The migration is specific to the accelerator control layer—the front-end computers that talk directly to the equipment running the beam.

Why move?

CERN ran a risk analysis in the second quarter of 2023, putting a number on what staying in the Red Hat ecosystem would cost them. The estimate came out to roughly CHF 5.4 million, with around 11 hardware boards needing a full redesign, plus hiring two electronic engineers, two software engineers, and two technicians just to handle it.

Racks would need reorganizing and rewiring, and most systems would be affected during commissioning. Even assuming bug-free replacements, CERN's own estimate put the odds of success at an optimistic 20 percent.

The reason for all that was a compiler flag. When Red Hat builds RHEL, it picks a minimum CPU generation the software will run on. RHEL 9's cutoff already excludes CERN's oldest boards, the kind running chips like Intel's old Core 2 Duo, which comprises about 47 percent of their fleet.

RHEL 10 raises that cutoff again, and this time even newer Ivy Bridge-generation boards, another 17 percent, fall on the wrong side of it.

The release strategy

CERN weighed two paths for keeping Debian aligned with its accelerator schedule. Plan A develops on Bookworm through 2026, deploys Trixie as the long-term support release from 2026 to 2030, then moves to Debian 15 "Duke."

Plan B skips that last jump, staying on Trixie under extended long-term support (ELTS) out to 2033 instead. A third option, running Bookworm itself under extended support the whole way, got ruled out.

Either path depends on Debian's LTS and ELTS programs staying healthy, which is part of why CERN has started sponsoring Freexian, the Debian-focused services company behind those support programs.

How it will be built

The old setup ran on NFS and tftpd, a bootserver model that traces back to around 2005.

The new one decouples the bootloader, kernel, init RAM disk, and userspace into separate pieces, then rebuilds delivery around Kubernetes.

A controller compares the configuration CERN wants against what's actually deployed and redeploys automatically when the two fall out of sync, instead of relying on someone pushing files over NFS by hand.

None of this touches CERN's data centers; this is specifically about the machines that keep the accelerator itself running. By the time the last quarter of 2026 closes out, CERN expects to have completed the migration.

Gaming on Linux keeps getting better, Wine and the Proton compatibility layer keep opening up more of the Windows catalog, and community projects continue filling the gaps that big publishers leave behind.

Take Xodus, for instance. The open source effort is looking to bring Xbox and Game Pass titles to Linux. Even though there are no playable builds yet, its direction says a lot about where Linux gaming is headed.

The money aspect of the equation is catching up too. While not strictly a gaming-focused move, the recently launched Omacom Foundation, which backs Omarchy and the open source projects it relies on, already has $12 million in funding.

Then you have Ubisoft, fresh off the success of Assassin's Creed Black Flag Resynced (a mouthful, I know), who are going the other way, breaking something that worked just fine before their meddling.

They kicked out Linux

Ubisoft has announced that For Honor is leaving the Linux platform. Starting September 10, the game will no longer be playable on Linux desktops or the Steam Deck. The removal of support lands the same day its Ranked Dominion and Ranked Duel modes go live.

They are calling it a move intended to safeguard players by introducing additional measures for ranked play to ensure a fair competitive environment, adding that they "cannot meaningfully deploy protection on this platform."

Ubisoft goes on to say that they:

will continue to investigate different ways to improve our anti-cheat with the possibility of reopening the platform in the future.

Which is PR speak for. This has been put on the back burner and is not a priority for us.

That makes me think that they would rather push out new pricey skins than support a minority portion of their player base.

The same old shenanigans

If you have been following Linux gaming-focused news, you might already know the script such big game publishers follow.

Roblox blocked Wine users in 2023, while GTA V Online barred Linux players in 2024, and Apex Legends kicked out Steam Deck owners the same year. For Honor is the newest name on a list that keeps growing, and the provided rationale never really changes.

What makes this one different is that Ubisoft once opened the same door it is closing.

The company enabled Easy Anti-Cheat support for the Steam Deck back in July 2023, and the game has been playable there since. Now it is closing that door, saying protection cannot be meaningfully deployed on Linux, even though Easy Anti-Cheat has supported the platform for years.

Heck, even Electronic Arts seemed to be coming around earlier this year when a job listing outlining a path for its Javelin anti-cheat to support Linux and Proton appeared.

Though it is unclear how the new owners and leadership will steer the company, that plan may not survive in the end. Meanwhile, the handheld market keeps getting stronger, with SteamOS spreading to more devices than just the Deck.

And you know what's the more troubling thing here?

Cheaters always find a way in, on Windows or anywhere else.

If your Raspberry Pi can no longer connect to Wi-Fi because the SSID or password changed, you can update the Wi-Fi configuration directly from its SD card. This helps when you cannot connect the device to a monitor and keyboard.

That's what I did. I had switched to a different internet provider, and that changed the router, its SSID and the password. I was using a Raspberry Pi Pico W in my Pi Dog. Connecting it to a screen and keyboard would have been a pain.

The easier option was to just take out the SD card and edit the WiFi details directly there. The entire process is composed of the following step:

• Insert the SD card with Raspberry Pi OS on it on your (Linux) computer
• Go to the mounted rootfs partition and go to /etc/NetworkManager/system-connections/ location
• Here, either create or edit .nmconnection file and enter the wifi name (SSID) and password

Let me show that in detail for you.

Step 1: Connect the SD card to your computer

Shut down the Raspberry Pi, remove the microSD card, and insert it into your Linux laptop or desktop using an SD card reader.

Raspberry Pi OS usually has two partitions:

bootfs
rootfs

The Wi-Fi configuration is stored inside the rootfs partition.

Step 2. Find the SD card mount points

Open a terminal and run:

lsblk -f

You should see something similar to:

sda
├─sda1   vfat     FAT32 bootfs B2F0-82D2                             438.1M    13% /run/media/abhishek/bootfs
└─sda2   ext4     1.0   rootfs 15f4c6be-1102-4331-9904-f78e78afd1fd   21.9G    18% /run/media/abhishek/rootfs

If you only see bootfs, mounted, you can mount rootfs from the file explorer.

As you can see, for me, the Raspberry Pi root filesystem is available at:

/run/media/abhishek/rootfs

You can also confirm it with:

mount | grep rootfs
/dev/sda2 on /run/media/abhishek/rootfs type ext4 (rw,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2

Step 3. Check the existing Wi-Fi configuration

Recent Raspberry Pi OS releases store NetworkManager connection profiles here:

/etc/NetworkManager/system-connections/

Since we are accessing Raspberry Pi OS through its SD card, run:

sudo ls -la /run/media/$USER/rootfs/etc/NetworkManager/system-connections/

If you already see a .nmconnection file, you can edit that file.

No nmconnection file? Create one

If the directory is empty, create a new Wi-Fi profile.

touch /run/media/$USER/rootfs/etc/NetworkManager/system-connections/home-wifi.nmconnection

And then use a terminal-based text editor like Nano or even Micro and add the following details:

[connection]
id=home-wifi
type=wifi
interface-name=wlan0
autoconnect=true

[wifi]
mode=infrastructure
ssid=YOUR-WIFI-SSID

[wifi-security]
key-mgmt=wpa-psk
psk=YOUR-WIFI-PASSWORD

[ipv4]
method=auto

[ipv6]
method=auto
EOF

Step 4. Set the correct file permissions

Your work is almost done. You just need to set the correct file permissions. That's because NetworkManager expects connection files to be readable only by root.

To give it the correct file permissions, use the following command:

sudo chmod 600 /run/media/$USER/rootfs/etc/NetworkManager/system-connections/home-wifi.nmconnection

Verify the permissions:

sudo ls -l /run/media/$USER/rootfs/etc/NetworkManager/system-connections/

The file should look something like:

-rw------- 1 root root ... home-wifi.nmconnection

Step 5. Flush the changes to the SD card before removing

This is an important step. After making all the changes, run this command:

sync

The sync command makes sure any pending writes cached in memory are actually written to the SD card.

And then you can either unmount from the file explorer or use the umount command for both partitions:

sudo umount /run/media/$USER/rootfs
sudo umount /run/media/$USER/bootfs

You can now safely remove the SD card.

Step 6. Verifying the connection

Insert the card back into the Raspberry Pi and power it on. After it boots, check the devices connected on your network to find the Raspberry Pi's IP address.

The simplest way would be to log in to your router and see the connected devices.

Otherwise, Angry IP Scanner is a good graphical tool for scanning your network. Command line tool nmap also does the job:

sudo nmap -sn 192.168.0.0/24

Normally, it should show your Raspberry Pi's hostname. You can also try to run scan before turning on Pi and a few minutes after turning it on. This should show the new devices that turn up between the two scans.

Finally, check the connectivity with:

ping RASPBERRY_PI_IP

Or, if SSH is enabled on your Raspberry Pi, connect to it:

ssh username@RASPBERRY_PI_IP

By the way, if you have forgotten the user password of your Raspberry Pi, that can be easily reset too.

Pironman 5 Case With Tower Cooler and Fan

This dope Raspberry Pi 5 case has a tower cooler and dual RGB fans to keep the device cool. It also extends your Pi 5 with M.2 SSD slot and 2 standard HDMI ports.

Explore Pironman 5

Enjoy your Raspberry Pi 😄

My history with Vanilla OS goes back to 2022, when I covered its debut stable release, just a month after I landed this gig at It's FOSS (yapping about open source and Linux).

Since then, my focus has moved to other distros and governance-focused developments, though I did watch it swap its Ubuntu base for a Debian Sid one and, from a distance, then go through an Orchid-themed overhaul in 2024.

I never got around to actually running it later on (or even reviewing it), but that's how things go, I guess.

If you haven't come across it before, Vanilla OS is an immutable, atomic distro built around ABRoot, with Apx facilitating package installation inside containers instead of touching the base system directly.

What's new in Reunion?

Well, if you are someone who is running an ARM64-based setup, be it a single-board computer, laptop, or a fully-fledged workstation that boots UEFI, then you will be glad to know that Vanilla OS now has proper support for the ARM64 platform.

Every package now builds for both ARM64 and x86_64, and the team isn't treating ARM64 as the lesser platform; functionality-wise, it's supposed to match the other one for one.

And, with the exception of NVIDIA builds, most images of Vanilla OS are now bit-for-bit reproducible. That means you can rebuild an image yourself and check it matches what the project ships instead of just blindly trusting what their build infrastructure pumped out.

The desktop-facing upgrades

Powering the release is Linux kernel 7.1.3, which is accompanied by GNOME 50. While we have already talked a fair bit about this desktop environment release across other distro releases, here's a refresher for you.

GDM now runs Wayland only, following through on the X11 removal GNOME backed away earlier. Fractional scaling also graduates out of its experimental flag this time around.

You get a bunch of new default apps too. Ptyxis takes over from Black Box, and its container support is the reason why you should keep an eye out for it.

Papers steps in for Evince with a noticeably more modern PDF reading experience, and Resources replaces GNOME System Monitor, giving you a clean look at what your apps and hardware are actually doing.

Underneath, Apx and VSO now share the same SDK, so config handling, permissions, and logging finally work the same way across both tools instead of each doing its own thing.

Another new addition is Vanilla Continuity, a snapshot-based backup and restore tool that works alongside ABRoot. If configured properly, it can save your home directory, whatever Flatpaks you have installed, and ABRoot's own metadata.

Where those snapshots land is up to you. A local directory works by default, but you can also point Continuity at an external drive it encrypts with LUKS2, or send backups to a remote server over SFTP, FTP, or NFS.

There's also the push for community-built images through a Vanilla-Flavors org on GitHub, which currently hosts the china-image flavor, which caters to people living in mainland China.

If you want to build and maintain your own flavor, the Vanilla OS devs are open to hearing from you.

Download Vanilla OS 3

Images for Vanilla OS 3 'Reunion' are live on the official website right now. Though keep in mind that the download page will make you pick an architecture, then a donation amount.

You can enter "0" as the amount to get the free download link, or you could enter a donation amount greater than zero to directly support the project and then download the ISO.

At the time of writing, donations were not working via the PayPal integration the project has implemented.

If you're already on Vanilla OS 2 Orchid (v1.4.0), this release will arrive as a normal system upgrade. If it's taking too much time, you can run this to get the release:

abroot upgrade

Auke Kok spent eight years working on Clear Linux OS at Intel. Now he thinks he knows exactly what broke it, and he's trying to fix that by himself.

In a LinkedIn post this week, Auke, now a Linux Distribution Architect at Verge.io, introduced The Ur Project. It's a from-scratch Linux distribution build system he's been putting together in whatever spare time he has.

"This project is not a corporate effort," he writes, and as far as I can see, no company, or even foundation for that matter, is backing it. Besides, as you might remember, Intel discontinued Clear Linux OS last year.

Where Clear Linux fell short

Auke has been writing regularly on The Ur Project website about what he thinks went wrong the first time. The biggest one, in his own words, was that they "made it way too hard for the community to contribute."

Simple things, like testing his own code change or carrying out regular incremental development, were needlessly painful, he says.

The release process didn't help either. Mismatched dashboards and a combination of old and new tooling were bolted together just to track daily updates.

Keeping pace with an assortment of daily updates meant stitching together a growing pile of disconnected tools and interfaces, all running on CDN and hardware resources a solo project at this stage will never have access to.

A build system, not a distro

The Ur Project isn't meant to be some shiny new atomic distro, at least not yet. The priority right now is to work on the machinery behind it, not offer a polished product.

Everything runs on Rust, on both the part that builds packages and the part that installs them, sharing the same underlying code.

Packages are defined through what Auke calls recipes, declarative TOML files that describe what a package needs without prescribing exactly how to build it, an idea he compares to "your grandmother's collection of cooking recipes."

Build steps aren't scripted by hand. Instead, a set of probes inspects the source and decides how to compile it. Repositories run on TUF to keep updates signed and verifiable, with content-addressed storage handling deduplication so identical files across packages only get stored once.

Every package carries provenance data documenting how it was built, and Auke says the system is designed so builds can be reproduced bit for bit. The same underlying system can output an OCI container, a live USB image, a cloud image, or a plain installed system.

AI is involved

LLMs are only tasked with writing test suites and build definitions for specific package types.

The build system itself stays deterministic. It runs without any AI agent present, and MCP integrations were deliberately kept out of routine packaging work.

For now, what's available is the website, Auke's regular blog posts on The Ur Project, and the Forgejo instance that hosts the code.

He is currently in the process of figuring out the hosting, letting people actually pull images and repositories. That will take a few more days before it's ready.

Once that's sorted, he plans to publish bootable images for both cloud deployments and live USB use.