The globally recognized tech and engineering company has quietly shut down the OpenRadioss project at the start of this month, keeping the GitHub page around but completely removing the repository.

I sound complainy because usually when an open project is discontinued, the maintainers put it into a read-only, public archive state, which allows other developers to learn and fork off it.

OpenRadioss was the open source release of Radioss, a finite element solver Altair Engineering developed for crash testing, blast response, impact analysis, and other structure loading scenarios.

They had released it in September 2022, drawing in a multinational community of researchers, software developers, and industry contributors who extended the solver and built upon the code.

Siemens, which acquired Altair last year, kept the repo and its contents publicly available for more than a year after the acquisition before abruptly deleting it and redirecting people to its transition page for Simcenter Radioss.

A fork appears

Brian Clemens, the co-founder of Rocky Linux has already got an OpenRadioss fork up and running, which carries the full OpenRadioss commit history, ships under the same GNU AGPLv3 license, and is hosted on GitHub.

It's called OpenCourant, named after mathematician Richard Courant and the Courant-Friedrichs-Lewy (CFL) condition, a stability criterion central to solvers like this one.

In fact, this fork owes its existence to the AGPL. You see, Siemens is legally within its rights to take down the repository, but the license applying to every commit gave anyone the right to fork, distribute, and build on the code.

It's just sad to see how abruptly the takedown was carried out; makes you think they didn't want people to get a heads-up.

Also worth noting is that OpenCourant is an independent community project, and it is actively looking for past OpenRadioss contributors to pitch in.

What's already shipping?

Initially, the upstream build pipeline that depended on proprietary Siemens infrastructure could not be transferred. That was rebuilt from scratch, and the results appear promising.

Just days since its inception, the project is already distributing Linux and Windows x86_64 packages.

And before that, a closed-source hm_reader input-reader binary that was never committed to the git history disappeared along with the upstream OpenRadioss repository.

Thankfully, an unnamed community member who had kept a copy came forward, the OpenCourant team independently verified it, and it now ships in every build. Though they are still looking for specific release archives to start work on ARM64 support and improve current platform compatibility.

If you are interested in OpenCourant, then its package options include the Starter and Engine offerings in single and double precision, SMP builds, and converters for animation files and time history data.

You can download the latest builds from the official downloads page.

If you get lost, the INSTALL.md file can be a good resource, though keep in mind it is still the OpenRadioss version, as the OpenCourant team has yet to update it to reflect the new project.

You already know that Canonical has been selectively replacing Ubuntu's C-based system components with Rust-written equivalents that don't compromise in terms of functionality, most of the time.

Now it looks like the distro's OpenPGP implementation is next, with Sequoia PGP coming preinstalled in Ubuntu 26.10. Canonical wants it to eventually replace GnuPG as the default toolchain, though that switch has not happened yet.

What's OpenPGP?

Before getting into Sequoia, it helps to know what OpenPGP actually is. It's not a tool but rather a widely adopted standard.

Phil Zimmermann created the original PGP in 1991, and the IETF now maintains the open version of that work. The specification defines how software should encrypt, decrypt, sign, and verify data so that any two implementations following it can work with each other's data.

On Linux, GnuPG has been the dominant implementation of that standard. Written in C, it implements RFC 4880 and offers the gpg and gpgv commands on the platform. These handle everything from encryption and key management to standalone signature verification.

Sequoia PGP is different

It was started in 2017 by three former GnuPG developers who chose to build a new OpenPGP implementation in Rust rather than keep evolving GnuPG’s existing codebase.

Sequoia PGP is designed as a library that other software can use directly, rather than a standalone command-line tool. sq sits on top of that for encryption, decryption, signing, and key management, and sqv handles signature verification, filling in for gpg and gpgv in GnuPG.

Sequoia also implements RFC 9580, the 2024 revision of the OpenPGP standard, whereas GnuPG has continued from the RFC 4880 branch, pursuing its own newer extensions and the LibrePGP specification rather than adopting RFC 9580 as its primary standard.

What's already in?

Ubuntu 26.10 "Stonking Stingray" already pulls in Sequoia PGP from the main archive (look under rust-sequoia-xx) as part of the default installation. I ran sq and sqv on a development build of 26.10, and both were working correctly.

Here, sq acts as the main interface for encryption, decryption, signing, and key management, while sqv handles signature verification. And typing gpg and gpgv still routes to GnuPG, so these two OpenPGP implementations sit alongside each other.

If Sequoia PGP is made the default, you can expect those commands and other GnuPG ones to route to Sequoia instead, similar to how we saw with sudo-rs.

Still a long way to go

The release notes for Ubuntu 26.10 and a recent announcement clearly mention that Sequoia PGP becoming Ubuntu's default OpenPGP toolchain is a future goal, not something that's already the default experience.

The coreutils transition started in 2025 and only reached 100% with 26.10. The sudo-rs switch was shown off well in advance before it became the default. Each of these components had to earn their place over multiple release cycles before anything changed for users.

Sequoia PGP is at the start of that process. Landing in the main archive is the first milestone. Whether it eventually replaces GnuPG as the default remains to be seen.

Canonical has not shared a specific inclusion timeline. Given how carefully they have moved on every other Rust transition so far, that caution is unlikely to disappear for something as foundational as OpenPGP.

The VPN industry runs on a promise. Pick almost any provider and the pitch is the same: "we don't keep logs." You hand over your entire internet connection and, in return, you get a pinky-promise that nobody is writing anything down.

For a lot of privacy-minded people, that promise stopped being good enough a while ago. A no-logs policy is only as honest as the company making it, and even an honest company can be hacked, subpoenaed, or quietly acquired.

Obscura VPN is trying to answer to that problem. Instead of asking you to trust its word, it splits the job across two independent companies so that neither one can tie your identity to your browsing. The first hop is Obscura's own servers; the exit hop is run by Mullvad. a respected VPM company out of Sweden. Your traffic is end-to-end encrypted to Mullvad's keys, so Obscura literally can't read it, and Mullvad never sees who you are.

The person behind it is Carl Dong, a former top-5 Bitcoin Core contributor who signs off his own website as "head-janitor" and "I fight for the users." I sent him a set of questions around Obscura. Here's the conversation.

You went from being a top contributor to Bitcoin Core to founding a VPN company. What convinced you the VPN space needed rebuilding rather than just improving?

"Don't Trust, Verify" is a cornerstone of the cypherpunk principles I grew up with. I see this Trust Minimization as crucial when building human-centric, security- and privacy-critical technologies. Yet the VPN industry is riddled with scandals (e.g., Onavo), broken promises, and "no-log" pinky promises. This never sat right with me.

When I saw what Apple's iCloud Private Relay was doing under the hood, I saw what the next generation of VPNs would look like: VPNs that are verifiably private and that outsmart internet censorship. I wanted to make this a reality outside of Apple's walled garden. The world doesn't need another VPN company; it needs a totally new approach to privacy.

Your whole pitch takes direct aim at the "no-logs" model everyone else uses. Why has that promise become inadequate?

The VPN industry is living in the past. Three conglomerates dominate and give the illusion of choice, while betraying their users' trust and operating a payola scheme using media cut-outs to push their talking points. The no-logs pinky-promise has never been adequate for software that can access the entirety of your internet traffic, and verges on being useless in 2026 when LLM-driven cyberattacks run rampant.

At the end of the day, even honest VPN providers who abide by their no-logs policy can be hacked. Users are waking up to this, and there's been an increasing call within the cybersecurity community to stop using VPNs altogether. Obscura is a direct answer to this: you no longer have to trust any single company's word for your internet privacy. That's the way it should have always been.

Walk our readers through the two-party relay in plain terms. How does it actually change the trust model compared to a normal multi-hop VPN?

When you use a traditional VPN, a single company sees your identity (via your connecting IP + your payment information) and your internet traffic. Using a multi-hop option doesn't change the fact that it's still a single company, and oftentimes just adds additional latency for no good reason.

With Obscura's Two-Party Relay, we use a fully independent company (Mullvad) as our second exit hop, with Obscura as the first hop. All of your internet traffic is encrypted to a key controlled by Mullvad's servers, and only relayed through Obscura's servers. That way, Obscura's relay servers never see your actual internet traffic, and Mullvad's exit servers never see your identity (connecting IP or payment information).

For those familiar with Tor, it's like if Tor only had 2 hops, but the hops were dedicated, high-performance hops optimized for maximum speed and reliability.

A skeptic could say you've just moved the trust problem around. Now users trust two companies instead of one, and the two of you could collude or be compelled together. How do you respond?

I'd first lightheartedly point out that using traditional VPNs is just moving trust from your (possibly regulated) ISP to a single wholly unregulated private company. 😆

In all seriousness though, our goal with Obscura is to make sure there's no single party that can jeopardize your internet privacy. No one entity should have that power. With Obscura, as long as either Obscura or Mullvad isn't compromised, no one can correlate your personal identity with your internet activity. This is strictly better than trusting either your ISP or a traditional VPN's pinky-promise.

Let's get technical. Your stealth protocol is built on QUIC to mimic HTTP/3 traffic. Why QUIC specifically, and how does it hold up against serious censorship?

We chose QUIC not only because it looks like HTTP/3, but also because its Unreliable Datagram extension allows us to avoid the TCP-over-TCP meltdown problem that plagues TCP-based VPNs. I'd encourage folks to read this for more details.

As for outsmarting censorship, QUIC has been notably harder for middleboxes to do Deep Packet Inspection on. QUIC allows messages to be fragmented and shuffled across UDP datagrams, which means censorship systems have to reassemble them, making it far more costly. I don't know of any QUIC censorship system currently deployed that does reassembly. More information can be found here.

You accept Monero and Bitcoin over Lightning, need no email, and log in with just a random account number. But Obscura still sees the user's connecting IP. How anonymous can a user really be, and where's the honest limit?

We view consumer data as toxic waste. We don't want it, don't need it, and do as much as possible to make sure you don't have to give us any. Aside from what you mentioned, our website is also accessible over Tor.

But you're absolutely right. We can still see the user's connecting IP address. That will not change unless humanity completely rethinks the OSI stack, which will make the IPv6 transition look like a walk in the park. 😆

The fact that we can't avoid seeing your connecting IP address is the point of Obscura though: if we have to see it, then the most private thing to do is to completely decouple that information from your internet traffic. That's what our Two-Party Relay does.

You've open-sourced the client and talk a lot about reproducible builds, clearly something you carried over from Bitcoin Core. For a non-developer, why do reproducible builds matter for a VPN?

I did a lot of reproducible builds work for Bitcoin Core, so this is near and dear to my heart. I believe that reproducible builds matter for any piece of open-source security-critical software. Even if the published source code is not malicious, that says nothing about the app you download. It essentially answers this question: does the app that I download correspond to the source code that is on GitHub (or whatever other forge you may use).

For Bitcoin Core, a malicious app could mean loss/theft of funds. For VPNs, a malicious app has access to the entirety of your internet traffic and can leak that regardless of the security of your VPN provider.

At Obscura, we of course take reproducible builds seriously. We already have a prototype for Android reproducible builds, and are looking to make other platforms work as well.

Obscura is $8/month, and reviewers note that stacking two providers can cost more than one. Beyond the privacy story, how do you make the economics work as a small team without VC pressure to monetize users?

First, we have no user data to monetize. Second, I think in the tech world we've vastly overcomplicated our businesses. For a business to work, you need your costs to be lower than your revenue over time. That's it. We aren't going to construct a massive data center. We aren't going to put tens of millions into R&D in a lab in Switzerland. We're a small group of six people, working remotely, charging fair prices. As long as we keep our customers happy, we don't have anything to worry about. My goal was never to compare yachts with Bezos.

There's a classic tension between maximum privacy and everyday usability, with Tor as the usual cautionary tale. Where do you draw that line?

The goal is for my mom to use Obscura, and she does! (Hopefully not just because I'm her son.)

I don't think that tension between privacy and usability is always inherent: a VPN doesn't have to be complicated. You should flip a switch and it should just work and you should forget you have it on. The goal is to be seamless. Power users and technical folks who want more should always have the ability to tinker, and we offer that, but the goal is to build a product so good that both feel right at home.

Oftentimes we've also found that giving users a choice is the way to go: while cryptocurrencies may be the most private way to pay for Obscura, my mom is likely to want a credit card option. 😄

Looking at the next few years, with encryption under legislative pressure and tracking everywhere, what worries you most about online privacy?

Every day there is another story about a country or international body proposing new rules that jeopardize the open and free internet we all love. Sometimes these are well-meaning protections that legislators don't fully grasp the ramifications of; other times their motivations are less noble.

What all these scenarios have in common is that, somewhere along the way, behavior that was once considered odd and Orwellian became normalized. You go grab a coffee and you give them your phone number, then you download an app (and allow location permissions), and before you know it companies know every aspect of your life.

Then when you read about how the government can legally purchase this data from data brokers, you start to appreciate just how much of your life can be reconstructed to where you essentially have given away every aspect of your privacy for a free coffee on your birthday. (I'm as guilty as anyone.) So what really worries me is our own complicity in trading privacy for convenience. And I hope with Obscura and other smaller privacy-focused start-ups we can make an easier, simpler to use tech that helps protect people and allows them to make better privacy decisions where there is no trade-off between convenience and privacy.

Finally, a fun one. Your site has a "Cursed Knowledge" page. What's the most cursed thing you've learned about how the internet actually works since starting Obscura?

I think the TLS SNI extension has gotta be one of the most cursed things about how the internet works.

Most people assume that if a connection is encrypted by TLS, then it's fully encrypted. What they don't know is that there's a part of every TLS connection called the SNI where the server's domain name is in plaintext, completely unencrypted! In fact, ISPs and middleboxes often use this as a way to enact internet censorship, since it's a much more reliable mechanism than trying to match connections with DNS requests.

Last year, Obscura was erroneously blocked by a few US ISPs, and SNI was exactly what they used. Of course, using a VPN protects you against that, but it's still quite cursed that TLS has this at all. Hopefully Encrypted Client Hello gets adopted soon so that we can have actual secure TLS!

Whether Obscura's split-trust model is right for you is up to you to decide, but it's definitely a different approach to a problem the VPN world has glossed over for years. The client is open source, so you don't have to take any of this on faith. You can read the code, check your exit hop's key against Mullvad's published list, and verify the claims yourself.

You can learn more at obscura.com, and the source is up on GitHub.

Canonical is moving Ubuntu's kernel update cycle from four weeks to two, with the expected result being a kernel release landing every week due to cycle overlap. They did this because AI-assisted vulnerability hunting is causing CVEs to land faster than the old timeline could respond to.

They have also enabled upgrades from Ubuntu 24.04 LTS to Ubuntu 26.04.1. And the delayed beta release of Ubuntu 26.10 should arrive today.

AlmaLinux now has software certification, which means publishers can list products and users can confirm what runs on their hardware, with everything going into a public catalog with a free read-only API facilitating bulk data export.

GhostBSD's lead developer is building a new desktop called Mocka to eventually replace MATE. It is built from scratch with no shared code from the MATE project, and the name comes from a typo.

postmarketOS is now Nura. The rename has been in the works since March 2025, drew over 300 community submissions, and went through a trademark review and a vote before it was finalized. On the same note, F-Droid has a major revamp. In case you did not know, F-Droid is the FOSS alternative to Google Play Store.

openSUSE is consolidating its distro lineup. Leap Micro, the separate immutable flavor for container and edge workloads, is going away, and Leap 16.1 absorbs its functionality via an optional installer mode.

This edition of FOSS Weekly is supported by Dawarich, an open source alternative to Google Timeline.

🧠 What We’re Thinking About

The Netherlands is building a NixOS-powered work environment after watching Microsoft cut off ICC access in 2025. Though it turns out France's digital agency had beat them to it, already running their own version of NixOS on internal workstations.

🐧 Tuxdle is rising

Last week I shared my weekend project, Tuxdle. It's a word game where you have to guess the Linux term within six attempts. The game has gained good popularity. We are getting more than 500 plays every day. A good number for a game that is less than a week old.

I have made some enhancements to the game. You can see your stats and you can also see stats on the day's puzzle. That tells you how many people played the game and how many people actually solved it. Streak badges have also been added.

Want more fun and challenges? On Linux Handbook, we have created a fun Capture the Flag game. You have 10 levels to solve. When you solve a level, the next level gets unlocked. The challenges run in custom docker containers. Everything on your system really. No sign up is needed.

🧮 Linux Tips, Tutorials, and Learnings

I am also enhancing the user experience on the It's FOSS website. One of the first things I did was organize the series/courses in a proper format.

If you visit the terminal course or bash scripting course, you will see the chapters in the series in the left sidebar. This will give you easier navigation.

There are many Linux distros that don't provide a dock by default, and if you want one, there's no dearth of options: Latte for KDE users, Cairo for old-school animations, and Dash to Dock for GNOME users; there's something for every taste and desktop setup.

You've seen "upstream" and "downstream" in patch notes, bug trackers, and forum replies without it ever being fully explained. We have already tackled what the terms actually mean, both for the kernel and for applications, and why it matters when you're deciding where to file a bug report.

👷 AI, Homelab and Hardware Corner

One of the biggest annoyances of homelab is accessing services by using IP address and port number. I fixed this by giving a custom domain name to every service I run. I used AdGuard as DNS and Nginx Proxy Manager for reverse proxy. And the end result is that I can use Jellyfin by typing jellyfin.internal instead of typing 192.168.0.23:8097.

Most SBC projects end with your drawer filling up with HATs for different use cases. Vicharak's Axon-Lite tries a different approach where it offers swappable interface modules for voice, vision, sensing, and AI data.

✨ Apps and Projects Highlights

Firefox's Nova redesign is finally here, and it looks good! There's also a neat toggle for anyone who doesn't prefer it's pill-shapedness.

📽️ Videos for You

And here's 21 useful Firefox features to give you a reminder why this browser keeps coming back, even after the wrong turns it has taken these past few years.

💡 Quick Handy Tip

In KDE Plasma, you can copy a wide range of time/date formats to the clipboard by right-clicking on the Clock widget in the panel.

All you have to do is right-click on the digital clock in the panel, hover your mouse cursor over the "Copy to Clipboard" option, and click on the format you want copied.

🎋 Fun in the FOSSverse

Sharpen your networking command knowledge by completing this crossword!

Linux is for power users. 💪

🗓️ Tech Trivia: On September 27, 1983, Richard Stallman announced the GNU Project, an effort to build a completely free Unix-compatible operating system. It helped spark the free software movement and popularize copyleft through the GPL, shaping how software is shared, modified, and built collaboratively.

🧑‍🤝‍🧑 From the Community: Neville is making the case for small, well-written programs; do you have an opposing view to present?

Since 2010, F-Droid has been the go-to place for downloading free and open source apps for Android. Its client app is the one people interact with the most, and it has received many upgrades over the years.

But now it's time for a massive rewrite that has emerged from more than a year of development and numerous test releases.

A comprehensive redesign

Kotlin replaces the original Java codebase, and the interface has been rebuilt on Jetpack Compose. The result is an app that follows Material Design throughout, so that it looks and behaves like it belongs on a modern Android device.

The app's bottom bar now has three sections: Discover for browsing, Search for queries and quick access to categories, and My Apps for tracking installed apps, updates, and issues.

You will also find that the Settings menu has moved to the top-right, being placed alongside the new Repositories menu.

Coming back to the Discover page, it has been configured to highlight newly added apps, recently updated ones, and the most downloaded ones in the repository. Related categories are grouped together, making it easier to browse the full catalog without getting lost in a long list.

Search now handles categories, app descriptions, and translated content in addition to app names, and results for Chinese, Japanese, and Korean queries have improved. Your search history is also saved for future queries.

Filtering has been reworked too; results can be narrowed by anti-features, device compatibility, and category all at once.

What else's changed?

The app now checks for updates in the background by default, removing the need for the pull-to-refresh gesture that used to trigger repository scans. Of course the manual check is still available from the My Apps page once you go into the three-dot menu.

Similarly, the app hiding feature for changing F-Droid's logo to a calculator app has been moved into the Settings menu under "App Icon," and the Nearby app sharing tool has been temporarily removed.

Concluding their announcement, F-Droid stated that:

F-Droid 2.0 represents a major milestone, but it is not the end of the story. Rebuilding the app has given us a stronger foundation, yet there is still plenty of work ahead.

As the rollout reaches more users, we expect to learn a great deal from real-world usage. Community feedback has shaped F-Droid 2.0 from its earliest design discussions through many alpha and RC releases, and it will continue to guide future improvements.

A looming threat

Last year in August, Google announced that starting 2027, every Android app developer would need to register with the company, providing government-issued ID, signing key evidence, and a fee.

This way, apps from unregistered developers would be blocked from running on certified Android devices.

Of course F-Droid didn't sit by idly; one of their board members, Marc Prud'hommeaux, launched the Keep Android Open campaign in response, which has since brought together over 70 organizations from 20+ countries.

Its signatories include big names like the Electronic Frontier Foundation, the Free Software Foundation, KDE, Proton, Codeberg, VideoLAN, LineageOS, CryptPad and the Tor Project.

Seeing that we are shy of the 90-day mark for this absurd lockdown to occur, F-Droid introducing such a major update only strengthens their stance of not backing down to Google's strongarming tactics.

Get F-Droid 2.0

This revamp is rolling out gradually over the coming weeks, so if you haven't received this on your existing installation, just wait. For new installations, it is a similar situation, as the latest stable release is still v1.23.2.

On the other hand, if you can't be bothered with practicing the virtue of patience, then you could download the latest 2.0 beta build from the packages portal.

My homelab started small, and so did the annoyance.

To open Jellyfin, I typed 192.168.0.x:8097. For Home Assistant, it was another IP and :8123. For Karakeep, Ollama and the rest, even more IP and port combinations to either remember or bookmark.

The bookmarks weren't reliable either. My ZimaCube got its IP address from the router like any other device. Swap a cable or let it reconnect, and it mostly came back with a different IP, breaking every bookmark and config pointing to it. That's worse for Jellyfin because typing a full combination IP address and port number with a TV remote will give you a taste of medieval torture.

So, one weekend I decided to fix it. I started with assigning dedicated IP address to my Zima devices (ZimaBoard and ZimaCube) but ended up with a full network clean up.

Now my setup is smooth with all the regular services running with a .internal domain. Now I just type jellyfin.internal in the browser. No IP, no port number. Saved me a midlife crisis.

My setup, before and after

Here's what my network looked like before the cleanup. The router from my ISP feeds a TP-Link router, which runs the homelab network, with a OneMesh node extending the Wi-Fi.

ZimaBoard consumes less power and runs services like Jellyfin that need to be on all the time. ZimaCube is a powerful device, and with Nvidia Ada RTX on it, I use it for local AI exploration. To cut down on my electricity bill, I only turn it on when I need it.

And here's what it looks like now. Both Zima devices have fixed IPs, the ZimaBoard handles DNS and the reverse proxy, and every service has a proper name.

The idea in a nutshell: AdGuard as DNS and Nginx Proxy Manager

The whole setup rests on two pieces working together. AdGuard Home, running as the network's DNS server, turns a name like jellyfin.internal into an IP address.

Nginx Proxy Manager then looks at which name you asked for and forwards the request to the right port. Because AdGuard can only work on the IP address, not port numbers.

Once that's in place, adding a new service is a two-step routine: one DNS rewrite in AdGuard, one proxy host in Nginx Proxy Manager. That's it.

Step 1: Give the core devices fixed IPs

Everything in this setup depends on IP addresses that never change. If the DNS server's IP changes, the entire setup breaks. So the first job was setting DHCP reservations on the router.

On my TP-Link, this lives under Advanced -> Network -> DHCP Server -> Address Reservation.

It actually shows me the connected device and gives the option to reserve the IP from there itself.

That may not always be the case for all the routers. So, you can find the MAC address on Linux with:

ip link show

That will show the MAC address of the current device. You can use a networking command like arp to scan the mac address of other devices connected to your network. The best place still is the router for this activity because it sees all the connected devices to the network anyways.

Here's the addressing scheme I ended up with:

I have also assigned fixed IPs to Raspberry Pi and other SBCs in this setup. They are used for running local AI harnesses like Nanoclaw and Hermes agents. I am also setting up Frigate for the cameras. I will share my experience with those things in some later article.

Note that some devices may need to be rebooted or renew its DHCP lease to pick up the reserved IP.

Step 2: Install AdGuard Home on the always-on box

AdGuard Home becomes the DNS server for the entire homelab network, so it has to be up all the time. My ZimaBoard runs 24x7 while the ZimaCube doesn't, so the choice was easy.

In the ZimaOS App Store, I installed the AdGuard Home (HOST) variant, not the regular one. Host networking lets AdGuard bind directly to port 53 and see the real IPs of clients. With Docker's default bridge network, traffic gets NATed through the container and you lose both.

The install shows a tips popup with a config script. Its wget command failed on my system with a "Can't be verbose and quiet at the same time" error, so I ran the same script with curl instead:

sudo bash -c "$(curl -fsSL https://raw.githubusercontent.com/bigbeartechworld/big-bear-scripts/master/generate-adguard-home-config/run.sh)"

Don't skip sudo here. Without it, the script fails to create directories but still prints a success message.

I accepted the default config path, restarted the app from the ZimaOS dashboard, and opened http://192.168.0.4:3000 manually. Clicking the app icon doesn't work for host-mode apps.

When ports are already taken

The setup wizard asks for an admin port and a DNS port, and both clashed with something. Port 80 for the web UI was taken, so I set AdGuard's admin UI to 3786 instead.

Port 53 was more surprising. Unusual, right? Turns out I had a Pi-hole container running that I had completely forgotten about. I found it with:

sudo docker ps --format "{{.Names}}: {{.Ports}}"

Pi-hole and AdGuard do the same job, so there was no point running both. I removed Pi-hole.

Step 3: Point the network at AdGuard

AdGuard was running, but no device was using it yet. On my TP Link, I went to Advanced -> Network -> Internet, expanded Advanced Settings, and switched DNS Address to "Use the Following DNS Addresses".

Primary DNS is AdGuard at 192.168.0.4, and secondary is 1.1.1.1. Here. 192.168.0.4 is the IP address of the ZimaBoard that has AdGuard running on it.

Here's what this setting actually does. Devices on the network still use the router as their DNS server, and the router forwards their queries to AdGuard. That's why AdGuard's query log mostly shows the router as the client, not individual devices. For per-device stats, setting AdGuard's IP in the DHCP Server page should work, so that the router hands it to devices directly.

When a device ignores the new DNS

While testing, I manually set 192.168.0.4 as DNS on a Linux laptop through GNOME's network settings. dig @192.168.0.4 google.com worked, but browser traffic never showed up in AdGuard's log. Running resolvectl status revealed the system was still using the router, as GNOME hadn't applied the change to the live connection.

Reconnecting to Wi-Fi fixed it. The more dependable way is doing it through nmcli:

nmcli connection modify "<connection-name>" ipv4.dns "192.168.0.4"
nmcli connection modify "<connection-name>" ipv4.ignore-auto-dns yes
nmcli connection down "<connection-name>" && nmcli connection up "<connection-name>"

Step 4: Create the .internal names with DNS rewrites

This is where the hostnames come to life. In AdGuard, go to Filters -> DNS rewrites -> Add DNS rewrite, enter a domain like jellyfin.internal, and point it to an IP address.

Here's the thing. ZimaBoard runs multiple services. DNS rewrite only accepts IP address, not port numbers. If I have to add jellyfin.internal and homeassistant.internal in the DNS, both will be pointed to the same 192.168.0.4 IP address. And they won't be resolved.

I mean, I could do zimaboard.internal:8097 and that would land me on Jellyfin but what's the point? A proper jellyfin.internal is what I would want. We need the port numbers.

This is why we need a proxy manager to properly map the domain names with both IP addresses and the port numbers. But a proxy manager cannot act as DNS and hence we need both AdGuard DNS in combination with a tool like Ngnix Proxy Manager.

Step 5: Use the port numbers with Nginx Proxy Manager

DNS only translates a name into an IP. It knows nothing about ports. To make http://jellyfin.internal work without :8097, something has to listen on port 80, check which hostname was requested, and forward it to the right port. That's a reverse proxy.

I'd have preferred Caddy, as that's what I use on some of my servers. But Caddy wasn't available as a one-click app in ZimaOS and I want to keep everything in Zima ecosystem. So I opted for Nginx Proxy Manager (NPM) as it does the same job with a web interface instead of a config file. Like AdGuard, it went on the always-on ZimaBoard.

Port 80 issue, again

NPM needs ports 80, 443 and 81 (its own admin UI). Port 80 was taken again, this time by zimaos-gateway, the process serving the ZimaOS dashboard for ZimaBoard. I confirmed it with:

sudo ss -tulpn | grep :80

The tempting fix is giving NPM a different port, but that defeats the whole purpose. You'd be back to typing port numbers.

Instead, I moved the ZimaOS dashboard to port 8888 from its Settings page. That was easy and that's why I like ZimaOS. It makes managing homelab a lot easier.

Anyways, the NPM install dialog still complained about port 80 for a while, and a full ZimaBoard reboot cleared that stale check.

Adding proxy hosts

Once installed, NPM's admin UI is at http://192.168.0.4:81. Log in with the default admin@example.com and changeme, and it asks you to set new credentials right away.

To add a service, go to Hosts -> Proxy Hosts -> Add Proxy Host and fill in the details.

1. Domain Names: the hostname, like jellyfin.internal
2. Scheme: http
3. Forward Hostname / IP: the IP of the device running the service
4. Forward Port: the service's actual port, like 8097
5. Websockets Support: on (Jellyfin and Home Assistant need it for live updates, and it doesn't hurt the rest so I always enable it)

Save it, open http://jellyfin.internal in a new tab, and there it is. No port number.

Here's how my proxy hosts look right now:

Troubleshooting afterwards

Network setup never goes 100% trouble free. I did a face a couple of issues. Here are at least two that I recall (and have recorded):

Home Assistant threw a 400 error

Everything worked except Home Assistant, which returned 400: Bad Request through homeassistant.internal. Direct access on port 8123 was fine. Home Assistant rejects proxied requests unless it explicitly trusts the proxy, as protection against spoofed headers.

The fix goes in Home Assistant's configuration.yaml:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.17.0.3   # NPM container's IP on the Docker bridge network

I found the NPM container's IP with sudo docker inspect nginxproxymanager | grep IPAddress, then restarted Home Assistant with sudo docker restart homeassistant.

One catch: this IP can change if the NPM container gets recreated. Trusting the whole bridge subnet (172.17.0.0/16) instead of a single IP is more durable.

Netflix stopped working on the TV

Shortly after switching DNS, Netflix on my smart TV refused to connect. AdGuard's query log showed two blocked domains in red: logs.netflix.com and nrdp26.logs.netflix.com. They're telemetry endpoints, but the Netflix app treats them as part of its connectivity check.

You can unblock an entry from the query log's menu in AdGuard, or add allowlist rules under Filters -> Custom filtering rules:

@@||logs.netflix.com^
@@||nrdp26.logs.netflix.com^

Restart the app on the TV and it should work again.

Port conflicts

Port conflicts came up three times during this project, so this little drill is worth keeping handy. To see which process is using a port:

sudo ss -tulpn | grep :<port>

The process name in the output tells you who the culprit is. If it says docker-proxy, check which container it belongs to:

sudo docker ps --format "{{.Names}}: {{.Ports}}"

Then decide whether to remove the conflicting container or move the other service to a different port. Just don't remap the port of the thing you're trying to make port-free, like NPM.

One more thing to keep in mind: all of this works only inside your home network. The .internal names exist only in your AdGuard, so they won't resolve when you're outside, unless you bring a VPN into the picture.

Adding a new service later

This is where all the effort I put in this setup pays off. When I deployed Karakeep a few days later, giving it a proper name took just two steps:

1. In AdGuard, add a DNS rewrite: karakeep.internal pointing to the ZimaBoard (192.168.0.4).
2. In Nginx Proxy Manager, add a proxy host: karakeep.internal forwarding to the service's IP and port (14592 in my case).

If the service does its own host validation, like Home Assistant, it may also need to trust the proxy.

Wrapping up

I did all this a few months ago and it has been running smoothly so far. HTTPS for the .internal names would be nice to have. Perhaps I will think about implementing it some weekend.

I am sure there are other, perhaps better (?) ways of doing this. For now, this setup works for me, and I no longer have to remember a single IP address or port number in my homelab. I hope it gives you a few ideas for taming your own.

I welcome your questions and suggestions. What else could I do here? What would you like to do about a similar setup?

Welcome to Local AI Weekly #4.

"Local AI" keeps meaning different things these days. Sometimes the model runs on your computer. Sometimes only the app does, while the model and your chat still run elsewhere.

There are lots of such "local AI" tools that are not really local. Before you pick a local AI tool, ask three things: where does inference happen, what account or network service is still required, and what does the license let you do? The best local AI tool is the one that doesn't need any of that.

🧪 On my bench

Team It's FOSS has moved from Discord to Buzz for internal chat. Buzz, from Jack Dorsey of Twitter fame, is a decentralized communication tool for humans and agents. Agents can run on remote servers or a local harness over ACP.

It has quirks. Clipboard screenshots won't paste into chat, and desktop notifications only fire for direct messages. Manageable for now.

🔍 Discover AI tools

Kubutu developer Rick Timmis is working on Klara, a local desktop AI assistant for KDE Plasma. The idea is to let you control the desktop via voice input. It is a work in progress for now.

OpenMuse is an MIT-licensed personal-agent app with a browser worker, durable tasks, and an optional Docker-based Linux computer. You can host it yourself, but setup still needs a CopilotKit Intelligence key, and open-ended tasks default to cloud providers. You can point it at an OpenAI-compatible endpoint, but there's no documented native Ollama path. Self-hosted software, not an assured offline agent.

🎫 Get MCP Certified

The Linux Foundation now offers AI certifications. The Model Context Protocol Associate one could interest you if you're building MCP integrations, or want an AI credential on your resume. I plan to take it just for the sake of learning new skills.

📡 Open Model News

OpenDecider is a more modest use for local models: answer bounded questions, like which queue a ticket should go to, instead of writing long replies. Its nano model is about 400M parameters; the 4B small model is a Qwen-based adapter. The author says both were distilled from larger teachers, and reports 2.0 GiB for nano and 8.9 GiB for small in the tested setups.

Basically, you don't always need a giant model to route routine requests. A small student model can be the triage step ahead of a slower agent.

👀 Big Tech Watch

NVIDIA's September PAIR announcement also promises easier local-model setup in Hermes and OpenClaw. The one-click Hermes path launched on Windows, with Linux "coming soon." Don't confuse that future path with the Linux PAIR beta available now.

NVIDIA also quotes up to 1.9x throughput from llama.cpp optimizations on an RTX 5090. That's a vendor number on specific hardware, not a speedup I'd expect on yours.

🗂 AI Jargon: Distillation

Imagine you have a giant, super-smart teacher who knows everything about the world. This teacher has a massive brain, but its so big that it can only stay inside a giant school building.

AI distillation is like that big teacher sharing all their secrets with a little kid (the student).

Instead of making the kid read millions of textbooks, the big teacher says: "Don't worry, just watch how I solve these puzzles, and listen to how I think."

The little kid watches closely and learns the teacher's smart shortcuts. Soon, the kid becomes almost as smart as the teacher, but with a much smaller brain!

You can learn more about distillation here. And you will see that teacher-student is kind of official term in this context.

😂 Meme

When the open-weights drop looks a little too familiar...

⚡ Quick Tip: Back up your Hermes agent before you need to rebuild the harness

Last issue: ollama ps, to see if your model was really on the GPU. This week, make sure you could rebuild the setup around it too.

If you run Hermes, run hermes backup. It writes a ZIP of your Hermes home, config and state included, restored later with hermes import path/to/backup.zip. hermes backup --keep N caps retained backups, and a script-only cron job runs it on schedule without starting an agent.

Then move one encrypted copy off the machine. That archive can hold credentials, sessions, memory, and config, so don't drop the raw ZIP in Git, even a private repo. It won't be wise.

See you next week.

Announced via a two-part series of blogs, Microsoft has moved WSL containers (WSLC) out of public preview and into general availability. Let's take a look at what it offers.

The new release comes with wslc.exe, a dedicated command-line tool for Linux container workflows on Windows. It ships with a built-in alias, container.exe, for those who prefer that syntax.

A Windows API also ships alongside it, giving native Windows applications a way to spin up and manage containers directly from code, as well as some new commands that include wslc events for tracking container activity, and --mount and --stop-timeout flags on create and run operations.

Networking is handled through a new model called Consommé, where container traffic leaves the virtual machine as Ethernet frames and is picked up by a Windows process running under the calling user's account. That process handles DNS, routing, and port mapping, letting traffic pass through VPNs and firewalls like any other Windows process.

For organizations, Microsoft Intune has gained two new settings specific to WSL containers. The first lets administrators enable or disable access to the WSLC feature entirely across managed devices. The second is a container registry allow list, which restricts image pulls to a defined set of approved sources.

Microsoft Defender for Endpoint's WSL plugin has also been extended to cover container activity. It can retrieve process, file, and network events from inside WSLC, connecting them back to the Windows host.

What is WSLC?

First you have to know about WSL, which stands for Windows Subsystem for Linux, that lets developers run Linux environments directly on Windows without needing to partition their drive or setting up a separate Linux machine.

Since WSL 2, it has shipped with a real Linux kernel inside a managed virtual machine, giving users access to Linux tools, distributions, and command-line workflows from within Windows.

WSLC extends this further by adding a dedicated layer for creating and managing Linux containers within that same WSL environment, making containerized workflows a native part of the setup.

It also separates container operations from the main WSL service by routing them through a dedicated child process, wslcsession.exe, which runs under the current user's account. This keeps each session isolated and container operations in a less privileged state than the WSL service itself.

For developers already working inside WSL, this means containerized applications can run in the same environment without reaching for a separate tool. The Windows API exposure also means native Windows applications can interact with containers programmatically.

Microsoft's WSLC architecture deep dive is a must-read if you want to know more.

Get it now

Running wsl --update in your terminal pulls in the latest WSL release, which includes WSL containers. Once updated, wslc is ready to use.

You can use these new commands to manage your containers. 👇

For the full changelog and access to the source, head to WSL 3.0.1's release page on GitHub.

When we heard about the Netherlands' DAWO initiative, a formal mandate to replace outside software across Dutch public institutions with a NixOS-powered platform, we asked ourselves: How could France miss out on this?

Turns out, they didn't. DINUM, the country's Interministerial Directorate for Digital Affairs, has been running its own NixOS-based workstation setup on internal machines for months now.

Sécurix and its NixOS Bet

DINUM has developed Sécurix, a security-hardened NixOS setup aimed at system administrators. It builds on top of NixOS without forking it, applying the security guidelines published by ANSSI, France's national cybersecurity authority.

The project is MIT licensed, lives under the cloud-gouv GitHub organization, and is currently in alpha, with v0.20.1 being its newest release having been introduced just a few hours ago.

According to Emilien Ercolani of The Stack, who attended a DINUM briefing in April, they are targeting implementation across ~250 of their staff's workstations. This comes after a successful pilot run across 70 machines.

In its current avatar, Sécurix uses FIDO2 hardware security keys as the main login method, supports TPM2 and YubiKey, and leans on NixOS's reproducible build model.

Keep in mind that this is not meant to be a Linux distro but rather a foundation from which workstations can be operated and managed centrally.

Alongside it, DINUM has published Bureautix, a companion reference template for regular office workstations. It ships with KDE Plasma, LibreOffice, ONLYOFFICE, and WPS Office.

The docs describe it as a "dummy example" that organizations are meant to fork and adapt privately, not a separately running system.

Why is NixOS the go-to?

The project itself has a European origin. Eelco Dolstra created it at Utrecht University in the Netherlands, and the NixOS Foundation is a Dutch nonprofit. For European governments, the appeal is obvious.

Mainstream Linux distro offerings like Fedora trace back to Red Hat, which is owned by the US-based IBM; openSUSE is tied to the Luxembourg-based SUSE; and Ubuntu is from England's Canonical.

The underlying approach here seems to be avoiding projects that are based in foreign countries that could be forced to comply with the whims of their leaders.

From what I can see, France, the Netherlands, and Denmark are each taking a different path to the same place. In the end, if one wants control over their infrastructure, vendor-neutral and reproducible is the way to go.

Suggested Read 📖: postmarketOS is no more; not in that sense! It has undergone a rebrand.

openSUSE is known for shipping four main Linux distributions. Leap is the stable, fixed-release option built on the same source as SUSE Linux Enterprise (SLES). Tumbleweed is the rolling release for those who want the latest packages. MicroOS is the immutable, rolling variant that tracks Tumbleweed.

And finally there's Leap Micro, the immutable, fixed-release counterpart to Leap, built for container hosts, edge devices, and virtual machine workloads. Its job was to bring immutability as well as stability to openSUSE without affecting Leap itself.

That separation is ending as the project has now decided to ship immutable Linux as a separate mode inside the main Leap installer.

A new mode

Leap Micro existed as its own product because immutable systems required a separate installation path. With Leap 16.1, the Agama installer has gained an "Immutable" mode option that can be toggled on during setup.

If you go with that, your system will be configured to have a read-only root filesystem with transactional updates and snapshot-based rollback. The technical foundation is identical to what Leap Micro offered; the difference is that it now lives inside Leap rather than alongside it.

System updates run through transactional-update, which applies changes in a new snapshot before the reboot, letting you roll back when a bad update causes issues. For installing new software, Podman and Distrobox cover containers, while Flatpak handles desktop apps.

Don't worry, you can still opt for the usual desktop experience if you choose the "Standard" mode.

And thanks to this, there will be no Leap Micro 6.3 or 7.0 releases as they have decided that Leap Immutable is the successor for anyone running container workloads, edge deployments, or setups that benefit from atomic updates.

For existing Leap Micro 6.2 users, the project offers the experimental openSUSE Migration Tool as a path forward.

Anything else?

As this is a new Leap release, there's a lot packed in other than the new mode. You get a range of upgrades that include KDE Plasma 6.6 with its OCR support in Spectacle and accessibility upgrades, as well as GNOME 48 with its HDR support and the new default audio player.

The latter is the same version that shipped with Leap 16.0 but with a gnome-shell bug fix patch bundled in. The openSUSE devs are staging the GNOME upgrade gradually over the next couple of releases rather than jumping versions all at once.

You can expect the stable release of Leap 16.1 to land the same day as SLES 16.1.

Get the RC

For now, only the release candidate (RC) is available, with the project committed to publishing one RC build a week before they reach Gold Master Candidate (GMC) status.

You will find RC images for x86_64, aarch64, ppc64le, and s390x from the Leap website.

Firefox has a new look that brings it up to 2026 web browser standards, where having a clean, minimal user experience is a growing phenomenon.

Called "Nova," the redesign leaked before an official announcement was ever made, with Mozilla playing catch-up a few months later via a technical blog outlining how they were approaching this major transition.

That transition turned out to be more work than the mockups made it look.

Six months after the leak

When the internal design files were made public in March, the mockups looked unlike any Firefox build before it. The tab bar, toolbar, and address bar were pulled into a single floating island at the top, with a visible gap between them and the page below.

Web content got the same treatment in those designs, sitting inside a rounded container lifted away from the browser's edges rather than running along with them. But the thing is, neither idea made it into the final release.

What we see in Firefox 157 is more refined. Tabs, menus, and the address bar are noticeably rounder, with a subtle gradient on the active tab that adds warmth to the interface.

Come, have a look

I pitched Firefox 156 against 157 to see what changed, and I came out impressed.

Opening a new browser tab showed me where the most effort was put, with the tab bar being visibly rounder and the address bar corners being softer, giving the interface a very polished look.

Before this, I was already beginning to dislike the flat/bland look Firefox had; it bugged me whenever I would return from using another browser like Vivaldi or Chrome.

You see, both of them have already embraced a pill-shaped design philosophy that I quite like.

Loading up a website was more of the same, with the slimmer footprint of the interface leaving the webpage more real estate to use, and the toolbar has fewer dividing lines between its elements than before.

The settings menu has also been refreshed. In 156, the sidebar was presented as a compact list with fairly simple content panels. In 157, those panels sit inside rounded cards, with sections that give each settings area more visual room and better readability.

What else's new?

Tab Groups has changed considerably since I last used it. The Nova redesign has given it a more complete feel compared to when the feature first landed in Firefox 138.

Back then, groups showed as colored labeled strips in the tab bar, and management options were limited to naming and collapsing. While the feature worked, it felt like an early implementation.

Now, tab groups sit more naturally in the tab bar, and switching between them or collapsing one out of the way feels less clunky and more intuitive to use.

The "List all tabs" button has been changed too, featuring a different icon (instead of the downward arrow) and visual style that ties well into the overall pill-shaped design. You can use it to get a full view of every tab across all groups at once.

A feature that was stripped out back in 2021 has made a return. Compact mode is now available in Settings > Appearance under the "Window density" selector in addition to the Automatic, Standard, and Touch options.

You will also find many new themes that can be installed via the Add-ons manager, as well as a new Classic/Smart Window switcher button on top-right for quickly switching between traditional and AI-powered browsing.

You can disable it

If you are not impressed by what Nova has to offer, then you could disable it to get back the old Firefox experience, and it's quite simple to do. In the address bar, type about:config, and accept the scary-looking warning.

Now, go into the search bar and type this "browser.nova.enabled" without the quotes. The final step is to either double-click on the entry or on the "Toggle" button to move Nova's activation state to "False."

That's it; you have successfully reverted to the earlier design.

Download Firefox

This is the obligatory installation section of the article, where you will find that Firefox can be downloaded from the official website. Though, when I was testing the redesign, I had to rely on Mozilla's FTP mirror to get the Firefox 157 release early.

I went with the package meant for my test setup: linux-x86_64 > en-US > firefox-157.0.deb

If you are on Debian or any of its derivatives, like Ubuntu, you can add the APT repository to get it installed.

And for existing users, by the time you read this, the various mainstream Linux distributions (e.g., Ubuntu/Fedora) should already be serving this redesign as part of a routine system update.

Suggested Read 📖: Smart Window users now get to use French AI.

postmarketOS, the Linux-based operating system that many of you turn to for reviving your old smartphones, has undergone a name change, and it is now called "Nura."

This was announced during the project's conference recently, where the rebranding closed a long-running process that started last year in March, drawing more than 300 name submissions from the community.

It took a dedicated selection team and a trademark review aimed at accommodating languages from every continent to ensure that the new name didn't have any offensive meanings across different cultures.

postmarketOS had to go

The old name worked against the project in ways that compounded over time.

It was long, difficult to pronounce across many languages, and its mid-word capitalization had no obvious logic for anyone coming to it fresh. The project says that people were mischaracterizing it as "PostmarketOS," "Postmarketos," and "post-market OS."

Then there was the problem of scope; initially, when the project was focused on reviving old smartphones, it was an appropriate moniker to flaunt. But when PINE64 began shipping phones with postmarketOS pre-installed, it became a liability as they couldn't trademark a descriptive name.

That left the project with no legal standing to protect its identity against misrepresentation.

With Nura, a trademark application has already been filed, though it has not yet appeared in public trademark databases so far (I searched USPTO and EUIPO).

What's Nura?

Nura is short for Nuraghe, which are granite constructions scattered across Sardinia, Italy, with some of these being traced as far back as 3000 BC. Many of those structures are still standing, giving us a glimpse of what the Nuragic civilization built back in the day.

The project draws inspiration from that, seeing longevity as a direct match for its own goal of keeping smartphones useful for a decade or more.

The name itself came from Davide Depau, who submitted it during the project's open call for community contributions.

The selection team, consisting of Pablo C. Gómez, Pan Ortiz, Ranny Bergamotte, and Sriram Ramkrishna, worked through more than 300 submissions and narrowed the field to four finalists.

The team voted, and Nura won.

They also went for the .eco domain knowingly, as it is reserved for organizations committed to positive environmental change and comes with enforceable policies against greenwashing.

The project's current status

The new website presents a very straight-forward look at Nura's status, mentioning that it works best for people willing to learn how it works, contribute to testing, or help with development.

Its current release is v26.06, and for anyone getting started with Linux on mobile, the project points to second-hand Snapdragon 845 or Snapdragon 410/412-powered devices as the most sensible entry points.

Currently supported devices include the Fairphone 4, OnePlus 6 and 6T, PINE64 PinePhone and PinePhone Pro, Purism Librem 5, and several older Samsung and Xiaomi devices.

Suggested Read 📖: Your search for a Linux phone ends here.