Garuda Linux has started nudging its userbase toward Nix. The distro's maintainers have just renamed the Garuda Nix Subsystem to Garuda Nix, and you will find that the move is more nuanced than something purely cosmetic.
What used to be a side project for dual-booting NixOS is now also its own bootable installer. The flake ships a dedicated ISO with a Calamares GUI, alongside a command-line install-garuda-nix tool for scripted setups.
This isn't something new. As a subsystem, it has offered a way to run NixOS alongside Garuda on the same drive, keeping both separate through a BTRFS subvolume rather than a dedicated partition.
So what does it offer?
Garuda Nix 'Mokka' and 'Dr460nized' flavors (Source: dr460nf1r3).
Suggested Read 📖: Get started using NixOS with us.
If you set out to install this, you will find that Calamares handles most of it, asking you to select an edition, Dr460nized or Mokka, and letting you opt for extras to gain better gaming and printing support along the way.
The CLI tool is where it gets interesting; it covers the basics of installing a Linux distro such as this one, while also providing presets for desktop, laptop, server, and handheld setups, plus eight partition layouts spanning ext4 and BTRFS, encrypted and unencrypted alike.
Impermanence, though, is the real draw. Switch it on, and the root filesystem gets wiped clean each time the machine restarts, either through a BTRFS rollback to a saved snapshot or by running root out of tmpfs on ext4 systems.
Don't worry, those wipes don't touch login credentials. Both the user and root passwords go through yescrypt hashing before landing in the generated config, which is what lets them persist across a rollback.
Garuda Nix also keeps a handful of essentials persistent by default, so things like your Wi-Fi credentials and per-user config folders stay safe. Anything outside that short list needs to be declared manually, or Impermanence deletes it along with everything else on the next restart.
It's already live
Both editions are available now as daily ISO builds. Anyone already running NixOS can skip the download entirely and pull the installer straight from the published flake with a single nix run command.
That flake reference points at the same stable branch by default, irrespective of the installation method you used to set things up. Keeping a system current from there is nothing exotic, just the usual nixos-rebuild switch command NixOS users already know.
On the other hand, if you are new to NixOS, then you will have to take some time out to learn your way around, since nearly everything here gets configured through text files rather than a settings panel.
Also, this isn't the first time the Garuda Linux team has done something of this magnitude. Their FireDragon offering is a web browser that was rewritten from scratch to deliver an improved browsing experience.
Ubuntu 26.10 is changing what your machine kills when memory runs out. Applications are meant to go first, and the services that hold the session together now sit behind them. Thirty-nine of those services move to an OOM score of -500, with GNOME Shell and two D-Bus services among them.
That makes them a far less likely pick for the kernel's OOM killer. Instead, something like a web browser holding the majority of the memory on your machine becomes the likelier candidate to be pruned.
Canonical has also switched off the systemd-oomd check that could take out your whole session on memory pressure alone. Though that change comes with a caveat where apps can still be terminated when memory runs out.
Under pressure, the kernel draws up a list of every process. It scores each one on the memory it can account for, then adds a user-space number on top. That second number is the one Ubuntu gets to set for you. It runs from -1000 up to 1000, and staying at the bottom of that range means a process is kicked out of the running order.
An earlier report cited by Canonical shows what that list looked like on an Ubuntu 24.10 desktop in 2024. GNOME Shell sat at 100, so did Firefox, and so did every content process it spawned.
The system daemons already sat far lower. dbus-daemon and systemd-oomd were at -900, and systemd-journald at -250. What caused the squeeze was a logic error in the reporter's own code, which set off a run of virtual machines and left the machine starved of memory.
It resulted in the killer picking one small app, gnome-characters, and killing it, leaving the virtual machines untouched.
Scores were only half of it
The kernel is not the only thing on a desktop that kills. systemd-oomd watches memory pressure instead, and it acts earlier than the kernel does without ever looking at those scores.
Ubuntu ships it set to act on the user session at 50% pressure, so the -500 values could not have saved anything on their own. The same ubuntu-settings patch handles the oomd side as well.
ManagedOOMMemoryPressure is now set to auto on user@.service, over systemd-oomd's "kill" setting it had before. In Canonical's own testing, seven out of ten sessions died without the fix, and none died with it.
Want to try it?
If you want to see the new behavior now, the change is already in the development release. Canonical is asking people to put it to the test under workloads that eat memory on a machine short of RAM or swap.
If you face any unexpected behavior, like abrupt terminations or session crashes, then you can report those via Launchpad.
I have been (mostly) happily running Home Assistant in my homelab for a while now. There is a tiny issue, though. While my wife and I can manage most devices through the companion app, kids or guests cannot.
Reaching out for a phone is not always convenient, and of course, I cannot handover my phone to guests. Home Assistant's own Voice Preview device is not a capable device if you are not connected to the cloud.
So when I got my hands on the Elecrow CrowPanel Advanced 10.1", a big ESP32-P4 touchscreen, I got some ideas. I could configure this device to allow access to some connected devices and put it in a common area where anyone in the household could use it.
It's an ESP32 device, and I already tinkered a little with ESPHome on my ZimaBoard so it was kind of a natural fit.
Note that this is a developer board with a screen. It's not an out-of-the-box smart home panel you just take out of the box and mount on your wall. If you enjoy tinkering, building things, you will like the device. If you want something that just works, it's not for you.
📋
Elecrow sent me this device for review. The views expressed are my own.
Hardware specification
Here is a quick look at what this device is packing inside it:
Component
Detail
Main SoC
ESP32-P4 (dual-core RISC-V)
Wireless
ESP32-C6 co-processor (WiFi 6, Bluetooth 5)
Display
10.1" IPS, 1024x600, MIPI-DSI
Touch
Capacitive (GT911 controller)
Memory
16MB flash, 32MB PSRAM
Audio
Onboard speaker output (dedicated connector) and microphone
Camera
Camera connector (add-on)
Expansion
Exposed I2C, UART, and GPIO headers
Power
USB-C, plus a battery connector
Model
DHE04310D (hardware revision V1.1)
Price
Around $60
It has interesting hardware, especially since it also offers a camera connector. My package came with a camera as well, not sure if it is included in all the boxes.
And then you also get the options to connect speakers on their own port. Which means that if you connect a LLM to your Home Assistant, and get a reply in audio format. There is a battery connector in case you want to use the device without direct power connection. The I2C, UART, and GPIO pins are accessible, too.
📋
I am using Home Assistant everywhere because this is what I am using this device for. However, this Elcrow display can be configured and used in a number of projects. You just have to put your tinkerer hat on.
Setting up the display with Home Assistant
This is where I spent most of my time, and where you should set your expectations.
Out of the box the board runs Elecrow's demo firmware, which shows off the screen but does nothing useful really. But it is still good enough to test the touchscreen and its connectivity. You would at least know that the device is working.
The demo gives you enough to test its functionality before you build on it
To make it as control panel for the Home Assistant, I flashed it with my own firmware. I went the ESPHome route, since ESPHome talks to Home Assistant over its native API and does not need the Supervisor add-on setup, which matters because I run Home Assistant in a container on Zima OS.
I will be honest, the first flash was not smooth. Getting WiFi up on this board took real work, because the ESP32-P4 has no radio of its own and leans on the ESP32-C6 over an internal SDIO link. On my V1.1 unit, the data line order was reversed compared to the reference configs I was following. Until I sorted that out, the board just kept rebooting. But that's really my fault.
One thing worth mentioning is that the stock demo firmware did not remember my WiFi after a reboot. I had to enter the credentials again. Once I moved to my own ESPHome firmware, it remained connected after reboots. So, if you only ever run the demo, do not expect it to hold settings. Perhaps that's the intentional behavior?
My first test project was really simple. I coded a single button on the screen to work as a switch in Home Assistant for my geyser plug. Tapping it toggled the real device. Also, when I flipped the geyser from the Home Assistant app instead, the button on the screen updated to match. So, things worked as expected.
I am new to LVGL, and thus I tried with a very basic project
Elecrow recommends SquareLine Vision for building the UI visually, which should be easier (more intuitive) than coding in LVGL in Arduino IDE.
📋
The quick test shows that the core promise of the Elecrow CrowPanel works. With ESPHome you can build a touch dashboard that controls real Home Assistant devices and reflects their live state, all running on the board itself with no extra server.
The display in everyday use
The screen itself is fine. It's not top-notch like an iPad. The best way I can describe it is that it feels like an entry-level tablet.
The 1024x600 IPS panel is bright enough and the viewing angles are okay, but it is not going to impress anyone who has looked at a modern premium phone recently. For a control panel stuck on a wall showing buttons, that is completely acceptable.
Touch response was good in my testing. Taps registered reliably and I did not have to poke twice.
Ports, audio, and the room to grow
The CrowPanel display is meant to be more than just a display.
The two small speakers, when paired with the onboard microphone, can work as a voice satellite for Home Assistant Assist. So you get both a screen and a voice endpoint in one device.
Of course, I am limiting it to Home Assistant but you can have more usage in godowns, factories, and even in homelab setups. Your imagination and creativity can be better than me.
Then there is the battery connector. A battery option gives it more flexibility and portability. It may be a good fit where you need the device to survive during a power cut. I did not test battery life as I did not have a spare battery to connect.
The exposed I2C, UART, and GPIO means you can plug in extra sensors, another microcontroller, or your own hardware off this board. For a DIY audience, that flexibility is worth more than a prettier screen.
Elecrow suggests various scenarios where it could be used
The camera and the AI question
Elecrow also mentions "integrated AI vision capabilities" because it has the scope for an add-on camera. The 2 MP camera is optional but it came in the package. I plugged the camera in and it worked.
I have not properly tested the on-device AI feature. The ESP32-C6 is supposed to give edge AI capability to embedded devices. Now this could work with simpler cases like facial recognition for unlocking access, my thinking is that instead of running AI on the display board itself, use it as an interface and let a vision model run on a more capable device.
Is it worth getting?
🚦
Who is it for: Homelab owners and makers who see the setup work as part of the fun. Who is it NOT for: Anyone who wants to mount a panel on the wall in ten minutes and thinks of using Android style apps to control their set up.
This is a decent offering for DIY makers. From homelab to actual industry usage, this device has potential that can be utilized by your requirements and imagination.
If you already tinker with ESPHome or ESP32 projects and you want a large touchscreen to build a project, this board gives you a lot to work with.
Play with LVGL and you can configure the device as per your need. And you don't even need to know coding. LLMs these days can easily help you generate code you want for your project.
I am repeating myself. This is not a plug-and-play smart home panel. You have to build on it. I started with a working control panel, and I plan on expanding that dashboard well beyond one button.
But if you are not comfortable flashing firmware, writing/generating code, it's not for you.
Google's September 2026 Pixel Update Bulletin contains patches beyond what's in that month's regular Android Security Bulletin. According to GrapheneOS, some of those extra patches touch standard Android platform code, the kind that runs on non-Pixel devices, not just Pixel-branded hardware.
None of that platform-level code has reached the regular monthly bulletin or the private preview patches other manufacturers typically draw from to get their own patches ready.
And at this rate, these won't reach non-Pixel OEMs at all until Android 17 QPR2 ships later this year in December.
The project is characterizing this as Google "gatekeeping security patches to the standard Android platform code from Android OEMs."
The complaints
GrapheneOS says Android 17 QPR1 shipped new developer APIs that never made it into AOSP. This is something they claim hasn't happened since Android's Honeycomb days.
Google's API diff report backs this up. Comparing Android 17 to QPR1 shows one new package, android.hardware.hid, plus changes across sixteen others, including android.media, android.os, android.provider, android.telecom, and android.view.
GrapheneOS has ported its code to QPR1 before Google even released it, but still doesn't have permission to ship that work. For now, the project is backporting Pixel firmware, kernel drivers, userspace drivers, and HALs from QPR1 onto Android 17 instead.
On top of all that, there's a compliance issue that seems to be recurring.
Google was slow to comply with a GPL source request. GrapheneOS requested sources for a build (CD1A.260905.001.A1) on September 1, and access only came through more than two weeks later.
Why this is worrying
None of these three issues is catastrophic by itself. A three-month patch delay, a paused API rollout, a two-week wait on source code—each is the kind of thing that could pass as a one-off.
Taken together, however, they point to a recurring theme. Google is holding security fixes back from the wider Android ecosystem, withholding new APIs from AOSP for the first time in over a decade, and slow-walking GPL compliance it's required to meet.
Don't even get me started on what they are doing to the Android app ecosystem.
Google is on track to require every Android app developer, whether on the Play Store, F-Droid, or anywhere else, to register with them. Come 2027, that means handing over legal identification and signing key evidence before an app can run on any certified device.
Sideloading an unverified app following this would mean enabling developer settings, waiting through a mandatory 24-hour cooldown, and clicking past several warning screens (classic scare tactics, btw).
GrapheneOS is one of dozens of organizations that signed onto the Keep Android Open campaign opposing this, alongside F-Droid, the Electronic Frontier Foundation, and the Free Software Foundation.
If you ask me, this Big Tech company is doing what's regrettably natural for it, clamping down open access to things so that its competition cannot benefit.
Yeah, Valve has not bothered putting out a proper announcement for this. I got to know about this thanks to Liam Squires-Hand, who covered it briefly yesterday. The gaming giant has open-sourced the Android compatibility layer it built for the recently launched Steam Frame.
Lepton lets users play games exclusive to Android on Linux by launching them inside a container. Valve says most users will not interact with Lepton directly since the Steam client itself handles that job.
The project is aimed at game developers who want to bring VR-focused Android titles over to Steam Frame, though the repository does note other use cases are possible.
Two licenses, one codebase
The compatibility layer is not released under a single license, as the repository's LICENSE.md file splits the project into two pieces, each governed separately.
The compat tool itself, the part Steam invokes to actually launch a game inside the container, is released under the MIT license. The Android root filesystem that gets built and run inside that container is a different matter. Because it incorporates code from several outside projects, it carries a GPL-3.0 license instead.
What's included?
Lepton's Android image is not built from scratch. It leans on a handful of existing open source projects, each covering a different piece of the puzzle.
Waydroid is the one doing most of the heavy lifting. It already runs a full Android system inside a Linux container using namespaces, and Lepton borrows patches and components from it directly during the build.
LineageOS supplies the actual Android system image that Waydroid, and by extension Lepton, customizes. Waydroid's runtime ships a minimal image based on LineageOS.
AOSP, the Android Open Source Project, sits underneath all of it. It's the base source tree that LineageOS, Waydroid, and, in turn, Lepton all build on top of, and its license terms carry throughout the whole stack.
Boringdroid gets a smaller credit in the same license file, alongside the others, though Valve does not go into detail on what it specifically contributes. You can go through its repo to make an educated guess.
Don't click away yet
This project is not trying to be a general-purpose way to run Android on Linux. It has been trimmed down on purpose.
Every app inside Lepton runs as the same user, with no walls built between them. Each game is instead meant to get its own separate container, and when launching them, Lepton switches off the Android services it does not need.
There's more to it than what I have discussed, so go through the repo if you would like to learn more.
It's good to see that while the Steam Frame has not started shipping yet, parts of its software stack are already being open-sourced. Lepton joins FEX, the x86-to-ARM translation layer Valve relies on for the same headset, as pieces of a stack that developers can now read, inspect, and build against.
Mozilla and Mistral have announced a partnership that brings the Mistral Small 4 model to Firefox Smart Window, the browser's AI-powered window that lets users chat their way through a web browsing session.
Both companies portray this as pushback against a browser ecosystem increasingly dominated by a few large companies. The concern is that one company could end up running the browser, the search results, and the AI answering your questions.
This is followed by the expansion of beta access to the feature in eligible regions as well as improved French language support.
Why go with Mistral?
Firefox 155 was the release that opened up Smart Window to users based in France, though the beta originally ran with three AI models: Google's Gemini, Alibaba's Qwen, and OpenAI's gpt-oss-120B.
None of those came from a European lab. Mozilla says it evaluated the 119-billion-parameter Mistral Small 4, specifically for its multilingual performance, before adding it to the "Personalized" category, replacing OpenAI's offering.
The other models are still available, of course. The company is just pushing Mistral as an additional pick that gives users more choice rather than settling for a few limited options.
And that language support I talked about earlier isn't some half-baked job where a translated interface was bolted on top of an English-first model. Mistral has tuned the model directly on regional languages and dialects, treating multilingual handling as a core feature.
The company says support for more European countries is coming later this year, without naming any specific ones, while Mistral has already confirmed that the UK and Germany are next.
Should you bother?
When I tried Smart Window, it was a beta release limited to people in the US and Canada that I got into through an early-access portal. I found it useful for summarizing a page, discussing certain choices, and asking it follow-up questions about my queries.
What has changed now is that it has reached France and that one of its models comes from a local AI lab. You can see it in how both of these companies are describing the move.
Mistral is pitching this as sovereign AI reaching consumers, while Mozilla calls it an independent browser working with a frontier European AI company.
Coming back to the question, you should care about this if you are someone who wants an AI-powered sidekick for your research sessions without the headache of setting one up manually.
Zsh has become the default shell for a lot of Linux and macOS users, and for good reason. Between Oh My Zsh, autosuggestions, and smarter tab completion, there's a lot going on under the hood.
But how much do you actually know about it? Take this quiz and find out.
🚧
Some browsers block the JavaScript-based quiz units. Disable your ad blocker to enjoy the quizzes and puzzles.
Few people know that Zsh's roots go back to 1990, when Paul Falstad created it as a student project. That means, Zsh is older than Linux.
I've spent a good amount of time customizing my own zsh setup, and honestly, there's more to it than most users realize. Tab completion itself works very differently (or should I say better) from bash. Then there's spelling correction, smarter globbing, and configuration through .zshrc that can get as simple or as complex as you want.
If you want to learn Zsh, try this resource section on Linux Handbook.
