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."
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.
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).
📋
Think of it as the basic keypad phone but one you can customize on your own with new apps and additional hardware modules. If you have teenage kids interested in STEM in your family, add it to your Christmas shopping list for 2027.
🛒 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.
🚧
As with any crowdfunding campaign, treat the timeline as an estimate. Back it because you want to support the project, not because you're counting on the ship date.
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.
📋
Immurok supplied this unit for review. They had no control over my conclusions. Also note that this is a pre-release unit and the software is changing quickly, so the version that ships to backers is likely to behave differently. Another thing is that this is a usage review, not an independent audit of the hardware, firmware, or cryptography.
I also have a video review of Immurok, if you prefer watching over reading.
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.
Spec
Detail
Processor
RISC-V, up to 60 MHz
Connectivity
Bluetooth Low Energy
Sensor
Capacitive fingerprint, under 500 ms claimed recognition
Dimensions
44 x 44 mm, 14.2 mm thick
Weight
~40 g
Body
CNC aluminium
Battery
110 mAh, USB-C charging
Standby draw
~50 µA claimed
Fingerprint slots
Up to 5 authentication fingerprints
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.
Immurok Linux app needs to be built from source code
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.
📋
This is a recurring pattern in the CLI tool. The device often knows exactly what it needs from you, but the software does not always tell you.
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.
📋
Update: This bug has been fixed by Immurok in a recent update.
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.
📋
After a firmware update, I can now see a dual-host option in the Linux TUI, which is an important change because earlier notes described this workflow as unfinished. But seeing the option is not the same as testing it. I have not yet confirmed that a second computer can pair successfully, or that the keys already stored on Immurok can then be used from that second host. For now, dual-host support is visible but the full cross-host SSH workflow is unverified.
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.
📋
My recordings do not include a complete, successful API-secret test. The intended design is to inject a secret only into the approved child process, without placing it in the agent's conversation. That is a good idea, but I am not claiming that part as fully tested here.
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.
✅ Real, working fingerprint approval for sudo, polkit, SSH, TOTP, and screen unlock ✅ Private keys and fingerprint data stay on the device, with sensible password and key fallback ✅ Compact, well-built aluminium hardware with promising battery life ❎ Linux install means building from source; there is no packaged app yet ❎ The CLI is buggy, TUI is okay. Docs need to be included. Software update should fix the issue.
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.
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.
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.
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.
Let's start with the good news. Switzerland is on track to kick out Microsoft across 3,000 workstations in its Federal Chancellery.
The Firefox Nova redesign lands for everyone in Firefox 157 on September 29, six months after it leaked. The version shipping is noticeably less aggressive than the March mockups.
Bottles, the tool that makes running Windows software on Linux easier now has an experimental ARM64 build, delivered through cpak rather than Flatpak for now.
KDE is considering replacing the Gwenview image viewer with Photos, a proposed replacement that would perform better, be mobile-friendly, and offer a bunch of really cool features.
Elon Musk's X Corp sent out a cease-and-desist letter to Nitter, ordering them to shut down. Two weeks later, after legal advice, the project and at least one popular instance are back, with a proper announcement following soon.
This edition of FOSS Weekly is supported by, Bitwarden.
📣 Event alert
Join Bitwarden for the 7th annual Open Source Security Summit, a free, virtual event bringing together cybersecurity leaders, journalists, and the open source community for conversations on geopolitics, security culture, and protecting critical industries.
Featured speakers include:
- David Sanger, New York Times White House correspondent and author of New Cold Wars and The Perfect Weapon
- Joseph Menn, cybersecurity journalist and author of Cult of the Dead Cow
September 17, 2026 | 8-10 a.m. PDT • 11-1 p.m. EDT • 5-7 p.m. CEST
Ikey Doherty, creator of Solus and AerynOS, has come out of retirement triggered by Omarchy's $13+ million funding and DHH's comments about nomadic people. His response is Barney, a Rust-based tool for building Linux distros from source, named after his son.
The rise of Omarchy can be attributed to two things: built-in AI features and DHH's determination to make it work. Some people may not like either or both, but for now Omarchy is an unstoppable force.
You might have never heard of GNU Readline, but it's a library included with your Linux installation that implements Bash's interactive command-line editing and various other features.
And seeing as we are on an open platform like Linux, this too can be customized! Flyline is a Rust-powered Readline replacement that brings intelligent suggestions, fuzzy search, syntax highlighting, and modern completion to Bash.
If that doesn't scratch your itch of trying something new, why not get started with NixOS? It's immutable nature, and package management ought to keep you occupied for a while.
Desktop Linux is mostly neglected by the industry but loved by the community. For the past 14 years, It's FOSS has been helping people use Linux on their personal computers. And we are now facing the existential threat from AI models stealing our content.
If you like what we do and would love to support our work, please become It's FOSS Plus member. It costs $49 a year (less than the cost of a McDonald's burger a month), and you get an ad-free reading experience with the satisfaction of helping the desktop Linux community. And there are also free Linux ebooks.
FreeCORE is for NAS setups that are still stuck on TrueNAS CORE. While AI is clearly involved in development, you can still check it out.
Jellyfin has done away with its older version naming scheme, jumping straight from 10.11 to 12. The release also brings proper books and comics metadata without needing the Bookshelf plugin, and music recommendations can now pull from ListenBrainz listening data instead of relying on tags alone.
✨ Apps and Projects Highlights
I tested out an app after ages, and Privacy Notes was the one I went with. It's a markdown editor that does many things and even comes with an encrypted vault.
📽️ Videos for You
Angry IP Scanner is an open source tool that I have been using for the past 20+ years.
🗓️ Tech Trivia: On September 9, 1947, engineers working on Harvard’s Mark II computer discovered a real moth trapped in Relay #70, causing a malfunction. They taped the moth into the logbook, calling it the “first actual case of bug being found.”
🧑🤝🧑 From the Community: FOSSers are discussing the recent CERN move to opt for Debian instead of a Red Hat for their particle accelerator computers.
Omarchy has gained so much popularity, and if you are one of the fans, how about you answer a few questions and we see if you really are a true Omarchy lover.
🚧
Some browsers block the JavaScript-based quiz units. Disable your ad blocker to enjoy the quizzes and puzzles.
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.
