How I Fixed the Biggest Annoyance of My Homelab

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.

🚧

This is my setup, built around my routers, my Zima devices, and the services I run in my homelab. Take inspiration from it and use it as a reference, but don't copy it blindly. Your IP addresses, ports, router menus and commands will almost certainly be different.

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.

💡

I also moved the start of the DHCP pool to 192.168.0.10, so no phone or laptop ever grabs an IP I've reserved.

Here's the addressing scheme I ended up with:

Device	IP	Notes
Router	192.168.0.1	Homelab network gateway
ZimaBoard	192.168.0.4	Runs 24x7, hosts AdGuard and Nginx Proxy Manager
ZimaCube 2 Pro	192.168.0.5	Not always on, runs heavier services
Dynamic pool	192.168.0.10 to 253	Phones, laptops, everything else

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.

📋

Since I used ZimaOS, things were more click click and install. For other setup, you will have to install and setup AdGuard DNS and Nginx Proxy Manager. Instructions can be found on their respective websites.

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.

💡

AdGuard offers AdGuard DNS as a paid cloud service. But its open source equivalent is free to install and use on your own device. That's what I used here.

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.

📋

The 1.1.1.1 secondary is a safety net, so the internet doesn't go dark when the ZimaBoard is down. It comes with a trade-off, though. DNS clients don't always wait for the primary to fail before trying the secondary. When a query goes to Cloudflare instead, the ad slips through and .internal names don't resolve, since Cloudflare has no idea they exist. If you notice a hostname failing occasionally, this is the likely culprit.

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.

📋

Why .internal? A good option was .local but it is reserved for mDNS (Bonjour, Avahi), so many devices resolve it outside your DNS server, which could lead to inconsistent results. .lan and .home aren't reserved and could become real domains someday, just like .dev did when Google bought it. .home.arpa is official but clunky to type. In 2024, ICANN permanently reserved .internal for private networks. It's short, readable, and will never clash with a real website. And it fits the entire homelab narrative.

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)

📋

I left the SSL tab alone, since this traffic never leaves my home network.

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:

💡

The "Public" access label might look scary, but it only means NPM doesn't add its own login prompt. These names resolve only through my AdGuard, so nobody outside my network can reach them. To access it from outside, a service like Tailscale should be used.

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.

💡

If something else breaks after you enable AdGuard, the query log is the first place to look.

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?

from It's FOSS https://ift.tt/E5bmxQJ
via IFTTT

Local AI Weekly #4: The Fine Print of Running AI Locally

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.

Explore MCPA Certification

📡 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.

If you have not subscribed to Local AI Weekly yet, you can subscribe from this page.

Subscribe to Local AI Weekly

See you next week.

from It's FOSS https://ift.tt/2zLDaTK
via IFTTT

Microsoft Has Made WSL Containers Available to Everyone

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. 👇

Command	What it does
wslc container restart	Restart a container.
wslc container cp	Transfer files to and from a container as a tar archive.
wslc system info	Check the state of your WSLC environment.
wslc network connect / wslc network disconnect	Join or remove a container from a network.
wslc network create	Create a network, with support for custom driver options.

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

from It's FOSS https://ift.tt/1njvFUR
via IFTTT

The Netherlands Picked NixOS. France Was Already Using It

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.

from It's FOSS https://ift.tt/amo9sAW
via IFTTT

Firefox in a New Skin! Nova Redesign Has Become The Default

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

Firefox Nova is on the right.

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.

Compact density, new themes, and window switcher.

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 how I installed the DEB file from the FTP mirror.

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.

Firefox

---

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

from It's FOSS https://ift.tt/jRqf6dB
via IFTTT

postmarketOS is No More, At Least Under That Name

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.

from It's FOSS https://ift.tt/tnJzsxf
via IFTTT

GhostBSD is Replacing MATE With a New Desktop Named After a Typo

The man leading GhostBSD, Eric Turgeon, has come up with Mocka, a new desktop for this BSD distribution that would eventually replace MATE. So far, he has unveiled the dock that will go into it, as well as some preliminary concepts and specifications that show us where Mocka will head next.

Existing users of GhostBSD don't need to do anything now since nothing has changed on their machines. All of this is still under heavy development after all. 🤷

Grammar nazis won't like this

Eric has shown off a demo for the Mocka Dock.

In his search for projects named "Mocha," the caffeinated drink, Eric made a typo and ended up naming his new creation "Mocka," where every component has been built from scratch, taking in nothing from the MATE project.

He plans to replace one component at a time, reverse-engineering what MATE already provides until full feature parity has been achieved. Once this is complete, I assume that GhostBSD will default to using Mocka as its default desktop environment.

And this is not his first time carrying out such a major change. In February, he came to the conclusion that MATE was not ready for Wayland and GhostBSD would switch to XLibre to keep its X11 session intact.

That line of thinking also checks out with what Eric's doing now.

The desktop's first component, a taskbar-style dock applet for the MATE panel called Mocka Dock, is already out now as an alpha for early testers. It lets you open apps, view their thumbnails, bring them forward into focus, and manage multiple windows of an app—basically doing what a dock worth its salt should do.

People who have the skills can build it from source right now to see what it offers, while the rest of us will have to wait for it to show up as an GhostBSD package update. Though it is not becoming the default experience yet, you will have to manually set it using the "Add to Panel" button on the taskbar.

Mocka Dock

What's planned?

If you take a look at Mocka's GitHub page, you will get a better understanding of what's being worked on apart from the dock. There's Mocka Menu, which has a proper PLAN.md file that lays out what work has already been completed and what's to be done.

The document shows us how a meson build and schema work has been done, with a long list of work yet to be carried out. This would give Mocka the ability to show a menu with listed items, the ability to handle search and keyboard inputs, integrate with the dock, and much more.

Eric has plans for a settings app too. Once complete, it would give users a single-access point for managing their GhostBSD machine's desktop appearance, network config, power management, keyboard layouts, and other UI-focused options.

There's also a separate repo that hosts the code for Mocka's official website. It is considerably behind in terms of development than the menu component we saw earlier and only contained placeholder content at the time of writing.

The project is hoping to ensure that these new Mocka components remain compatible with MATE so that users can mix-match during this transitional phase to a full Mocka desktop on GhostBSD.

from It's FOSS https://ift.tt/Bl3u2Ms
via IFTTT