Most of us carry a phone every day, but very few of us could say what's actually going on inside one. That gap is exactly what CircuitMess is trying to fill or should I say, has been trying to fill.

The Croatian company CircuitMess, founded by Albert Gajšak, ran its first MAKERphone campaign back in 2018, a build-it-yourself phone kit that raised over $324,000 and eventually shipped to more than 6,000 people as "Ringo."

Now there's a sequel. MAKERphone 2.0 is live on Kickstarter (partner link) and it has already sailed past its goal with weeks left to go.

The pitch is the same as before: you assemble a working mobile phone yourself, then learn to code on it. The major difference this time is that you don't need a soldering iron to do it. That's a big relief, for me at least, as I am terrible at soldering.

📝 Key Specifications of MAKERphone 2.0

As you can see, the MAKERphone looks like the normal keypad cellphones. Here are the main details:

• Processor: ESP32-S3, dual-core, 4 MB flash, 4 MB PSRAM
• Cellular: 4G LTE Cat-1 with 2G fallback, Nano SIM
• Display: 1.77-inch color, 160×128
• Input: 12-key numpad, nav joystick, 4 function keys, volume keys
• Audio: DAC, speaker, I²S mic, 3.5 mm headphone jack
• Battery: 1000 mAh, USB-C charging
• Storage: microSD slot
• Connectivity: Wi-Fi, Bluetooth, USB
• Expansion: UMAX modular connector
• Assembly: no soldering required this time
• Coding: MicroPython, Arduino C++, VibeBoy (AI-assisted)
• Price: starts at $119 for early backers, $169 otherwise

The kit starts at $119 for super early backers and climbs from there and goes for a retail price of $169.

This is a DIY gadget, the phone that arrives as a box of parts and a build guide, and you put it together into something that makes real calls and sends real texts over 4G LTE. Pop in a SIM and it behaves like an actual phone.

Now 4G seems like a step down from the usual 5G but the device is not supposed to replace your smartphone. If you are not going to use all those internet connected social media and apps, you don't really need 5G. I explain the concept later.

At the core, there is ESP32-S3, the same family of low-power microcontroller you'll find in countless hobbyist boards. So no, this is not going to compare or compete with Snapdragon or Apple Bionic chip and they don't even pretend to do so.

The original MAKERphone asked you to solder the whole board together. Version 2.0 drops that requirement, which lowers the barrier a lot if you've never touched an soldering iron. CircuitMess says it's built to be assembled by kids from around 11 up, so a functional adult should manage fine.

From the official assembly video, it seems like just putting the pieces together.

There's a 1.77-inch color display, a headphone jack (yes, in 2026), and a modular design that lets you bolt on extra hardware. More on that below.

Modules, coding, and a smart band

The part that makes this more than a nostalgia kit is the module system. MAKERphone 2.0 takes add-on modules that change what the phone can do. Several of these modules come in the box.

There's an infrared module for controlling an old TV, a camera module, a 2W speaker, an LED module, and a temperature and humidity sensor. There's also a perfboard so you can wire in your own sensors.

Once it's built, you code it. You can write for it in MicroPython or Arduino C++. CircuitMess is also pushing an AI-assisted coding tool it calls VibeBoy, so the "vibe coding" fad has officially reached the DIY phone aisle.

And that's not a bad thing entirely. Not everyone can code or make a custom app in MicroPython. But LLMs have removed that barrier. You have the hardware; you use a LLM and let it generate the kind of software you want. That's the reason that Seeed Studio and many other hobbyist hardware makers are promoting their own AI-assisted platforms. It makes hardware more enjoyable for bigger group of people.

CircuitMess is selling a companion too: a programmable smart band that pairs with the phone over Bluetooth. Think of it as a semi-smartwatch as it can show you time, let you play games and use timer and stopwatch functionality. There are no sensors here to track your health and activities, as far as I can see.

It's a separate accessory rather than part of the base kit, so treat it as an add-on if the idea appeals.

The idea behind this DIY phone

A 4G phone seems like an outdated device in 2026. After all, 5G is everywhere and even the most basic smartphones support 5G these days. But the premise of MAKERphone is entirely different. It's not a smartphone by choice.

We have seen such devices in the 'maker space' in the past. There is Flipper Zero that has an entire different purpose, then there are handheld retro gaming devices, pocket computers, etc.

This is a similar idea where kids in STEM or hobbyist adults can build the device as per the liking, by adding the desired modules.

To give it more functionality, there is the scope of a 4G sim card. This gives you the ability to make calls and text messages.

With that, it becomes a bar phone that you assemble and design new games and apps for your own self.

And the device is still useful as a phone. If you want kids to stay connected with you, not the social media, it works. The same goes for adults who deliberately want to stay away from the internet (except when using a proper computer).

🛒 Pricing and Availability

MAKERphone 2.0 is live on Kickstarter now and has already hit roughly 790% of its funding goal, with about 27 days left on the campaign as of writing.

Pricing starts at $199 for the early bird tier, with higher tiers as the discounts sell out. There are way too many tiers to fit in all here.

US, EU, UK and Canada residents do not need to pay any import fee. VAT is likely to be extera depending upon your location. Shipping cost are not clear to me but the device should start shipping in July-August 2027.

If you just want an inexpensive (smart)phone, this isn't the device for you. If you want to understand phones, or hand a kid something that turns screen time into build time, and the budget and wait time is okay for you, you can make a purchase.

A laptop fingerprint sensor unlocks the laptop and usually stops there. Immurok wants to do quite a bit more than that.

It is a tiny wireless box that can unlock your desktop session, approve a sudo command, authenticate via polkit, log you into a server over SSH, generate TOTP codes for 2FA, and put a physical touch in front of an AI coding agent. And it does all of that with the same finger, over Bluetooth.

The good news is that the core features work. The less good news is that on Linux, getting there was not as simple as touching a sensor. During my testing I ran into bugs, missing prompts, confusing behaviour, and one timing issue that made the initial setup a little challenging. But once things were setup, the device worked smooth and that's what matters, right?

Let's take a detailed look at what Immurok gets right, what still needs work, and whether this little box could earn a place on your desk.

I also have a video review of Immurok, if you prefer watching over reading.

What Immurok actually does

At its simplest, Immurok is a wireless fingerprint reader for a desktop or a laptop that does not already have one. But the feature list goes well beyond unlocking a screen.

You can use it to unlock an existing desktop session. Through Linux PAM integration, it can approve sudo and other supported authentication prompts such as polkit. It can generate and store SSH private keys on the device itself, and it can release a TOTP code only after it recognises your fingerprint.

Then there is the more unusual usage: AI-agent approval. The idea is that a coding agent can prepare a privileged command, an SSH operation, or a request for a secret, but it cannot complete the protected action until you physically touch the sensor.

According to Immurok, fingerprint templates and private keys stay on the device. There is no cloud account and no telemetry. Pairing uses P-256 ECDH with HMAC-SHA256, and authentication responses are cryptographically signed.

Those are the company's security claims, and as I said above, this review tests how the device behaves in use rather than auditing that cryptography.

The hardware

The hardware makes a good first impression. Here is what you are getting.

There are controls at the back for power and for actions such as pairing or confirmation. The silver finish, rounded corners, and proportions make it look like a tiny Mac mini. That is not a complaint and even works well for people in the Apple ecosystem. It is neat enough to sit on a desk without looking like a random security dongle.

My review box contained only the device. There was not even a USB cable and I am not complaining. The battery life is pretty good, so charge is needed like once a month and type C cable is in every household, I presume.

Immurok claims more than a month of normal use per charge. When I started testing, the Linux TUI showed 84% battery on the first run. After roughly a week, it was at 78%, so about 6 percentage points in that period. That looks promising for the month-long claim, but one week is not enough to confirm it, especially since battery-percentage readings are not always perfectly linear.

Installing on Linux means building it yourself

Windows and macOS get graphical applications. On Linux, the version I tested used a Rust daemon, a command-line client, and a terminal user interface. There was no equivalent graphical management app and no easy-to-install binary as well.

On my Ubuntu 26.04, I first installed the required development and runtime packages, then Rust through Rustup. The make check-deps command was helpful here, because it listed the missing components instead of making me discover them one build error at a time.

Then came the first Rust build, with around 200 crates to download and compile. It kept the CPU busy and produced plenty of warnings, though these were warnings and not compilation failures.

After that, make install was fairly quick. It installed the daemon, the command-line tools, the PAM module, the authentication helper, and the system integration, and the user-level daemon was already running when the install finished.

For an experienced Linux user, this is all doable. But for a device that presents itself as a simple replacement for typing passwords, it is too much friction. Before this ships to general users, Linux needs straightforward packages for the supported distributions and a much clearer first-run flow.

Pairing: connected is not the same as paired

The first pairing attempt immediately showed how early the software was.

I powered on the device and tried pairing from the TUI. It said the device was not connected. The CLI told me to press the device button within 30 seconds, but then failed immediately. It did not wait for 30 seconds at all.

What eventually worked was connecting Immurok manually through Ubuntu's Bluetooth settings first. Once the operating system showed it as connected, I went back to the Immurok TUI, pressed p, and then pressed the button on the device. It exchanged keys and reported that pairing had succeeded.

So there are two separate states here: connected over Bluetooth, and paired inside Immurok. That distinction may be technically reasonable, but the application never explained the required sequence when I actually needed it.

The product should walk you through this step by step, including the LED state, the operating-system connection, the Immurok pairing action, and the button press.

Enrolling fingerprints

Once the device was connected and paired, enrolling the first fingerprint went more smoothly.

In the TUI, I pressed e, placed my finger on the sensor, lifted it, and repeated. My test firmware asked for 12 captures before it enrolled the finger in slot zero.

The device supports up to 5 normal authentication fingerprints, and when you add more after the first one, an existing authorised finger has to approve the new enrolment. That is a sensible security requirement, but again, it needs to be stated clearly on screen.

The command line interface is finiky at times. At one point, trying to enrol again failed because the fingerprint was already present, and a deletion attempt simply failed without explaining why.

The bug that stopped sudo from working

With a fingerprint enrolled, I tested sudo apt update. Nothing happened. Touching the sensor did not authenticate me, even though the fingerprint was clearly there.

The problem turned out to be a race in the Linux daemon. When the Bluetooth session began, the daemon immediately asked the device for its status. But a Python notification helper was still starting up its D-Bus connection. On my machine, that helper took about 5.2 seconds to become ready, while the status request timed out after 5 seconds. That tiny difference left the daemon with no device status for the rest of the session, which showed up as NO_STATUS.

Since I had installed Claude for testing the agent specific features of Immurok, I let it handle the issue and it fixed that by increasing the limit to 15 seconds.

After rebuilding and installing the patched version, sudo authentication worked. I ran the command, touched the sensor, and it continued without asking me to type the account password.

It is a good thing that the code is open enough to inspect and fix. But this was also a basic authentication path failing because one helper started a fraction of a second slower than expected. These things should be fixed before the mass release.

Unlocking Ubuntu, and why fallback matters

With the patched client, Immurok could unlock an Ubuntu session that I had already logged into and then locked. I touched the sensor and the desktop opened.

It did not work at the very first login screen after powering on the computer, though. That is intentional behavior applicable to macOS and Windows too. The user-level service is available for unlocking an existing session, but the initial login still needs the normal account password. This distinction matters, because "screen unlock" can easily sound like "replace your password at every login," and they are not the same thing.

The fallback behaviour was good. When I disabled Bluetooth or disconnected Immurok, sudo and login did not leave me waiting for a fingerprint device that was no longer there. They went straight to the usual password field. That is essential. A convenience device should never turn a temporary Bluetooth glitch or a flat battery into a lockout.

SSH keys are the highlight

SSH is where Immurok starts to become more interesting than an ordinary fingerprint reader.

It can generate an ECDSA P-256 SSH key on the device. The private key stays there, and you export only the public key to place in the remote server's authorized_keys file.

ECDSA is a practical choice here because it can deliver security comparable to RSA using much smaller keys. That means less storage, less data to transfer, and lower processing overhead, making it suitable for a small battery-powered device.

The first time I generated a key through the CLI (not the TUI), it appeared to just stop. The missing piece of information was that Immurok was waiting for my fingerprint authorization. There was no prompt telling me to touch the sensor, and no useful feedback when I did. I only knew what to try because I had already been digging into the behaviour. Once I touched the sensor, the key was generated.

If an action requires physical authentication, the interface has to say so. The TUI was better here. When I generated another key there, it explicitly told me to touch the sensor to authorise the action, and the key then appeared in the next slot.

I exported the public key, added it to my Raspberry Pi Pironman Max, and enabled Immurok's SSH takeover. This adds the Immurok agent socket as the SSH IdentityAgent, which gives the device-backed keys priority.

When I connected to the Pi, Immurok asked for my fingerprint, I touched the sensor, and the SSH login succeeded.

Importantly, my normal SSH setup was not destroyed. Existing keys on the computer stayed available as a fallback, so when I connected to a server that did not have the Immurok public key, SSH just continued using my existing key.

That is the right approach. You can introduce Immurok gradually instead of forcing every server to change on day one.

You can delete keys through the TUI after fingerprint approval, or through the CLI, though the CLI again failed to show the required fingerprint instruction during deletion. You can also import an existing private key onto the device, but with two limitations.

Import was only available through the CLI in my tested version, and it accepted only ECDSA P-256 keys. If your existing key is Ed25519, RSA, or another format, you cannot simply move it over to Immurok.

TOTP just works

Immurok can also hold TOTP secrets, and this was one of the smoother experiences.

I added a GitHub TOTP entry, went into Immurok TUI, and then requested a code. Fetching the code required another fingerprint touch. I entered that code into GitHub, and it worked.

This is a simple feature, but a useful one. The TOTP seed is not sitting in a general desktop authenticator, and someone using your unlocked computer still needs your fingerprint before Immurok will release a code. As always, recovery codes still matter. If the device is lost, damaged, discharged, or reset, you need another way into the account.

Putting a fingerprint in front of an AI agent

The most distinctive pitch is using Immurok as a human-in-the-loop control for AI coding agents.

I installed the Immurok plugin for Claude and activated it for the project. Immurok also provides an imk wrapper that can launch a command in agent mode. In one test, the agent tried to connect to my Raspberry Pi over SSH, Immurok requested fingerprint verification, and after I touched the sensor, the agent connected to the Pi.

The idea is that even if the computer is unlocked, the agent cannot complete a protected wrapped action while you are away from the desk.

But there is an important limitation: this is only a gate if the action actually goes through the gate. Project instructions may tell an agent to use imk, and a plugin may make that tool available, but an ordinary command can still take the normal route if the wrapper is bypassed. My earlier Git push did exactly that, because it was not wrapped.

So this is not automatic enforcement just because a file tells the agent what to do. A serious setup has to arrange for sensitive operations to always run through imk run --agent, or to enforce the protected path at a lower level. Immurok can provide a valuable physical approval mechanism. It cannot secure a workflow that still leaves an unprotected path open right beside it.

Things that could be better

Even with the core features working smoothly after the setup, a few rough edges are worth calling out clearly. None of these are dealbreakers on their own, but together they are the difference between "promising" and "ready."

The TUI and CLI need serious polish

The Linux TUI brings together the dashboard, keys, PAM integration, logs, firmware updates, and settings. It shows connection state and battery percentage, and for most tasks it communicates better than the CLI does.

The CLI version lacks tab completion, which made nested commands harder to discover. Pairing claimed it would wait and then failed. Failed enrolment and deletion did not give useful explanations, and SSH import lived only in the CLI while other actions were easier to follow in the TUI.

Documentation is not optional for a tool like this. Immurok touches PAM, Bluetooth, SSH configuration, private keys, TOTP, etc. The GitHub README has details, but buyers need a stable setup guide, clear in-app prompts.

The log file that never stops growing

There is one smaller issue that gets bigger with time. The daemon continuously writes to ~/.immurok/logs.txt. After about a week, mine had reached roughly 4 MB. After 2 weeks, it is 15 MB.

At a steady rate, that is closer to 200 MB a year than multiple gigabytes. But the real problem is that the file looks unbounded, and a persistent reconnect loop or a recurring failure could make it grow much faster. The application needs log rotation with a sensible size and retention limit.

On Linux, sending routine logs to the journal would make far more sense than quietly maintaining an ever-growing private text file.

Is Immurok worth it?

After more than a week, I am more than happy to use Immurok as a daily driver. The trouble was mostly at the initial setup stage, and I am way past that now.

I liked the fingerprint reader on my Dell XPS in the past. My present laptop, Asus Zenbook, doesn't have one, so the Immurok fingerprint reader complements it very well.

The hardware is attractive, compact, and useful, and the core features work well. I used a fingerprint to approve sudo, unlock an existing Ubuntu session, authenticate an SSH connection to a Raspberry Pi, retrieve a working GitHub TOTP code, and approve an agent-run SSH action.

I also like the fallback design. A disconnected device did not block password login, and servers that were not configured for the Immurok key kept working with my existing SSH keys.

The hardware works great and the software on Linux needs upgrade. Source code build should not be forced onto users in 2026. The CLI needs to be better at showing the appropriate feedback message.

I have already seen two firmware updates and there is a software update already on their repo. So, it's just a matter for software updates and the device would become suitable for even the beginners.

So, if you think that the device suits your workflow and it doesn't dent your budget, you can opt for Immurok.

Getting Immurok fingerprint key

At the time of writing this article, Immurok is still in crowdfunding. It is available through Kickstarter for $59 US, with a stated retail price of $69 and estimated delivery in November 2026.

Please readhe their terms and conditions on shipping, custom fee and return policy.

I tested the pre-release review unit and the software is already changing quickly. The version shipping to backers is still a few months away, so there is time for the Linux experience to improve before customers receive the device. I do hope the installation, pairing, prompts, documentation, and reliability are all much better by November.

For now, I am happy to have Immurok on my desk.

Mirko Brombin, the creator of Bottles, has got Microsoft 365 running on Linux. His posts on X showcase an installation that completes on a Windows 10 or 11 Wine prefix, signs in with his existing license, and launches at least one editor.

He achieved this using two things, an unreleased version of Soda and Bottles 67.4. If you remember, Soda is a Wine-based runner that facilitates easy running of Windows games and applications.

On first glance, what he posted might look like a developer-focused log, but these changes are the foundation of what full Microsoft 365 support via Bottles will one day hopefully look like.

The results of his work

Mirko was able to login into the MS 365 app using his credentials and was able to launch MS Word and use it. Of course that's not the only thing he got working; since two-factor authentication passed, the suite detected his license, and OneDrive integration was functional.

The memory footprint of the office suite was less than 500MB, so this should be light on your Linux system.

The build he is currently testing is 2608 (20326.20144), which he says is the last build the installer will offer for Windows 10 and 11. And before you get all hyped up, wanting to try this out on your computer, know that you will have to wait.

Soda 11.0-11 (error 404 for now) has no release yet, and the component catalog that ships with Bottles 67.4 stops at Soda 11.0-10. Even the long-standing community request for a Microsoft Office installer in Bottles is still open.

Suggested Read 📖: Bottles offers hope for running Windows-only software on ARM devices.

Do we need Microsoft 365 on Linux?

Till date, there's not been an official Linux desktop build of Microsoft 365, and seeing how Microsoft currently operates, I don't expect one to appear anytime soon.

What's been achieved here is remarkable. Once fully implemented, this will help draw in people into Linux, as many shudder at the thought of switching to the platform because their preferred office suite doesn't work here.

For context, CodeWeavers sells a paid Wine product, CrossOver, and its database still lists Microsoft Office 365 on Linux as "Installs, Will Not Run," last tested against CrossOver 26.3.0.

Which is why I hope the fix travels further than Bottles. Wine sits beneath every one of these projects, including Soda. So a patch that lands upstream reaches all of them at once, and you would not need a particular runner to get Office working.

💬 If Mirko gets it all working, do you think other projects will start integrating his work?

A few days ago, thirteen patches were sent to the kernel mailing lists that are looking to delete some of the 32-bit Arm platform code that the upcoming Linux 7.3 release cycle has marked as deprecated.

While none of them have been merged yet, Arnd Bergmann, who has been trying to retire this code for years now, has finally made some good progress.

His suggestion is to do these removals in Linux 7.4, which is supposed to land sometime between December 2026 and January 2027, with the CPU support getting dropped a release after that.

The plan has been around for some time; the earlier proposition was removal in 2025 or 2026, after the matching LTS kernel shipped. Arnd opened his July thread by apologizing for letting the earlier attempt remain idle for almost two years.

What he calls cleaning out the deprecated platform code now runs to about 300 patches. This first series removes just the arch/arm/mach-* code and the Kconfig bits that depend on it.

What's going away

These will sound like a collection of 1990s and 2000s hardware that used to be relevant but aren't anymore.

The platforms losing support are the SA1100 boards, the Acorn RiscPC, Footbridge, the legacy PXA board files, and the Orion, Dove, and MV78xx0 boards.

The same series also takes out the OMAP24xx, i.MX31, and no-MMU i.MX chips, LPC18xx and Axxia, along with the STM32F4, F7 and H7 microcontrollers, Versatile MPS2, and AT91 SAMV7.

Of course, this doesn't mean that these boards will suddenly stop working (stating the obvious, I know). Any one of the devices listed above just won't be able to run a mainline kernel from 7.4 or 7.5 onwards since the code that lets them boot is slated for deletion.

Another thing worth knowing is that in the same 7.3 cycle, Linux has gained support for other Arm-powered chips like Apple's M3 Pro, Max, and Ultra, Samsung's Exynos 1580, and Qualcomm's Shikra.

This shows the continuously shifting nature of the kernel, which has to regularly adapt to new hardware while also ditching old support that isn't used by many.

Linus has been here before

If you think about it, Linus Torvalds has been a strong proponent of removing such old code.

Back in 2022, he asked whether it was time for the i486 series of CPUs to be dropped from Linux, seeing that i386 was already gone in 2012. By 2025, Linus was saying that there was no real reason for anybody to waste their time developing for the platform.

So I anticipate that he will accept these removals, unless there are any shortcomings that have gone by unchecked.

Even so, old hardware has its advocates. People and enterprises do keep these machines running, and Arnd has left the window open for anyone who wants to argue against their removal before the drivers go.

Broadcom has taken down the public download pages for the VMware Virtual Disk Development Kit (VDDK). The pages for VDDK 8 and 9, along with the landing page, now return a generic error message.

So far, there has been no formal announcement from Broadcom.

The removal was carried out sometime last month, as people on Reddit and vendor forums started reporting dead links in mid-August. ShapeBlue, an Apache CloudStack services firm, documented the change on August 25. Red Hat followed days later with a support note for its Migration Toolkit for Virtualization.

While existing copies will still be functional, meaning implementations that currently use VDDK will continue working as usual, those who want fresh copies are out of luck.

What's the fuss about?

The VDDK is a library that lets backup and migration tools read VMware virtual disks from outside the hypervisor. VMware launched it in 2008 as an easily accessible SDK for customers building disk utilities, and it soon became the backbone of image-level backups and agentless migrations.

Unfortunately, its license makes things complicated. The library cannot be redistributed, so no Linux distribution provides it, and no open source project can bundle it for users. Everyone has to point to Broadcom's download page, and that page is now gone.

Convenient, not for users but for VMware's owner, Broadcom, who has managed to cut off public access to a tool many relied on to move away from the platform.

The ones who are stuck

Microsoft's Azure Migrate documentation is one example of the disarray caused by the silence. It tells admins to download VDDK 8.0 or 9.0 from the Broadcom portal for agentless migration, and the links embedded there point to a page that isn't accessible.

The docs suggest falling back to agent-based migration if VDDK is unreachable.

Red Hat is in the same boat. Its support note reports customers hitting "not found" or "access denied" errors while trying to access the public download links for VDDK, further noting that it cannot host or redistribute the kit.

They are directing their customers to contact Broadcom support while the Red Hat Engineering team hunts for an alternative, long-term path out of this dilemma.

On Reddit, a user, bobdrakken, already did that, and what they received as a response ought to show you where Broadcom stands on this. 👇

Hi ****,

Greetings from Broadcom Customer Care.

To ensure the highest standard of security, reliability, and product features, the Virtual Disk Development Kit (VDDK) is no longer available for use or download.

Broadcom continues to actively maintain a variety of APIs and SDKs to enable authorized technology alliance partners to build backup and recovery software solutions that are validated and authorized to integrate, interoperate, or be compatible with Broadcom products.

For all backup and recovery requirements, customers should rely on such solutions from Broadcom authorized technology alliance partners."

I hope this helps you.

Please get in touch with your Partner for better assistance, since there is no pending action from our end hence this case will be archived now.

I would be glad to assist you if you have additional support requests.

A pattern unfolds

This takedown fits a pattern running since Broadcom closed its $69 billion acquisition of VMware in November 2023. The subscription-only overhaul followed within weeks, ending perpetual licenses and folding standalone products into bundles.

European customers later reported renewal prices climbing massively, enough to draw formal complaints from industry bodies.

It's not entirely been about extracting the maximum out of VMware; Broadcom has thrown in some goodwill along the way too. Workstation Pro and Fusion Pro went free for everyone in November 2024, and a free ESXi build returned in limited form in 2025.

Each move can be defended on its own; licensing overhauls and price changes are normal business; so is tightening download access.

But taken together, these paint a picture that while VMware itself is running just fine, the ones trying to move off VMware need to jump a few more hoops before they can achieve that.

Via: Virtualization Howto

Seeing all the hype surrounding AI in the Linux ecosystem, you might've asked yourself, What makes a Linux distro "AI-focused"? If you go looking for an answer, you will get all kinds of results depending on which project you look at.

One wires an AI agent into first boot, right next to picking a desktop environment. Another keeps every model running air-gapped with no network access.

There's no established approach here; every project is going at it differently. The distros listed below are each building toward their own idea of what an AI-native desktop should look like.

1. Omarchy

While Omarchy started off as a simple script to get Hyprland running on a stock Arch install, it has since grown into a full-blown, AI-agent-first Linux distribution with its own foundation and eight-figure funding behind it.

The project markets itself as "the malleable OS for the age of agents," and that framing shows up the moment you boot it for the first time. Setup asks you to pick a default AI agent from a list that spans Claude Code, Codex, Copilot CLI, and several others, then signs you in so it can start working on the system right away.

Once configured, the agent can then help you troubleshoot crashed programs, build out plugins and themes, and put together apps from nothing more than a description of what you want.

And underneath all of that is Arch Linux, so you know you are working on a proven base.

2. Shadowfetch Linux

Shadowfetch Linux is built around something it calls "Mission Control," a system for giving an AI agent a task and then actually checking its work.

Nothing from an agent locks in without your sign-off. Once a task is completed, Shadowfetch lays out everything that happened, what changed, which tests ran, what the output looked like, and waits for you to approve it.

It comes with two modes, "Fire," which keeps the system connected to the internet, handing over tasks to cloud agents. While "Ice" works offline, relying on local files and standard media export tools like FFmpeg instead, though it doesn't run local AI models yet.

This distro also limits what an agent can actually touch with a feature called "Firebreak" which keeps the agent inside a defined boundary where it only ever sees the project it's working on and whatever system files that task calls for.

3. Gnoppix AI Linux

Gnoppix AI Linux, or Gnoppix Linux as it used to be known, traces back to 2002, when its founder Andreas Müller built it on Debian 3.0 "Woody." That work got him hired by Canonical as one of Ubuntu's earliest developers.

Anyhow, Gnoppix keeps AI local and off the network by default. Its homepage showcases a Mistral 7B model running locally, with it being "AIR-GAPPED," meaning that the model has no network access.

That same privacy-focused approach carries through the rest of the OS, with no telemetry, a built-in encrypted messenger, a VPN, and a search tool that strips identifying details before a query goes anywhere.

There's also a space for testing and fine-tuning models like Mistral, Llama, and Qwen on Gnoppix's own servers without needing the hardware to run them yourself, and the project itself is Debian-based.

Official material describes the project being run out of Panama with an AI lab in Japan, and there are many pricing tiers for this one, so choose the one that suits your use case.

4. MakuluLinux

MakuluLinux comes with Electra, an AI assistant you control from a floating bar at the top of the screen. Type what you want in plain English, and it figures out whether that means chatting, writing code, drafting an article, or running a system command.

Electra isn't locked to MakuluLinux either. It installs on Ubuntu, Debian, Arch, Fedora, and a few other distros too; MakuluLinux just ships it by default. The developers say that they built and operate the AI backend instead of wrapping someone else's API, and there's no key needed to use it.

If you lose your internet connection, it switches to a local model automatically and can even remember past conversations.

Though the company's pages don't agree on how many models are actually available. The number ranges from the low seventies to over ninety, depending on which page you check.

5. Deepin

This distro can be regarded as one of the early adopters of AI in a Linux distro, while most of this list only started moving in this direction over the past year. deepin weaves its AI layer, called UOS AI, directly into the browser, mail client, and system-wide search instead of keeping it in a separate app.

That search piece, branded "Grand Search", is the most visible desktop-focused part of it, and deepin's most recent stable release, 25.2.1, pushed it further with something called Intelligent Search.

Instead of remembering an exact filename, you can type a phrase like "financial spreadsheets modified yesterday" or "videos larger than 1 GB," and the system parses that into filters for time, file type, location, and size on its own.

Honarable Mention

Ubuntu isn't trying to be an AI-native distro yet, but it's taking the first step toward being one. Ubuntu 26.10, which is scheduled for an October release, is going to feature its first AI-powered feature.

Myna is a dictation tool that runs entirely on the machine itself, triggered via a keyboard shortcut, dropping transcribed text into whatever you were typing into without needing an internet connection.

This comes after Canonical's VP of Engineering, Jon Seager, revealed their plan for splitting AI work across Ubuntu into two categories earlier this year.

Thanks to Joey Sneddon of OMG! Ubuntu, we now know that local speech models for Myna will ship as separate, removable snaps matched to your hardware, some built for NVIDIA GPUs specifically, others CPU-only, with broader language support planned for later.

If you aren't a big fan of AI in your Linux distro, then I recommend going through ZDNet's roundup of the distros that plan to stay that way. There are six of them: AerynOS, MX Linux, Debian, Arch Linux, Slackware, and Void Linux.

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.