Signal is an end-to-end encrypted messenger that doesn't really need an introduction in this age of authoritarian overreach. Since the beginning, it has required a phone number at signup, even after it gained username support.
It's been quite weird to see, given that other privacy-focused messengers like Session and Matrix have never required a phone number to get started.
The beta release of Signal 8.28 for Android changes that with Signal Login, an optional registration path that skips the phone number requirement entirely. The existing flow remains in place for anyone who wants to stick with the standard registration method.
How numberless logins work
The pricing shown changes according to your device's region.
Instead of asking for your mobile number, Signal will ask you to pay a one-time $2.99 fee via Google Pay, and the exact pricing depends on your device's region.
I say that because even with an active VPN connection that was pointing to the United States, Signal still showed me pricing in INR instead of USD.
And if you are worried about Google's involvement in this, Greyson Parrelli of the Signal team points out that the payment runs through the same zero-knowledge proof setup it uses for donations.
This way, no link is created between the purchase and the new account.
Once payment completes, Signal generates two keys. A 32-character Account ID and a 64-character Recovery Key replace the phone number as the account's identity. Keep in mind that Signal doesn't have a recovery mechanism for these if either is lost.
Two-factor authentication via TOTP can be added after registration as extra protection, and passkey support, including hardware keys, has been confirmed.
If you were looking for the details on iOS support, then know that Signal Login won't be arriving on that platform anytime soon.
The Play Services caveat
The feature currently requires Google Play Services, as payments run through the Play Store, making it such that devices without Play Services cannot access it. If you are running a de-Googled smartphone, then you will have to wait as more payment methods are planned.
While the support documentation for this feature lists Apple Pay alongside Google Pay as a payment option, this contradicts what I saw in the beta app, as well as what Greyson has written in the Signal forum.
You can test it now
The latest packages in the 8.28.x beta series can be downloaded from Signal's GitHub releases page. To sideload it on your Android device, follow these instructions:
Find the latest version in the 8.28.x series and download the universal-release APK file from the "Assets" dropdown.
Install it on your Android device; you might need to allow installs from unknown sources to get this done.
Open Signal, tap "Continue", then select "Register Without Phone Number."
Complete the $2.99 purchase via Google Pay.
Save your Account ID and Recovery Key on a notepad or a password manager before proceeding.
No Starch Press is one of my favorite indie tech publishers. I am a fan of their Linux titles like How Linux Works and System Programming in Linux. This is why I get excited when I see a new book from them.
You can start with 4 books for $11.80 or get all 18 for $47.20. The full tier includes Think Like a Programmer, The Rust Programming Language, 3rd Edition, and How Computers Really Work, along with books on C, ARM assembly, algorithms, and computer architecture.
Part of your purchase automatically goes to the Electronic Frontier Foundation. The books are DRM-free downloads in PDF, EPUB, and MOBI formats.
⏲️ The deal ends on September 28, 2026, at 11:30 PM IST (6:00 PM UTC).
📋
The article contains affiliate links. Please read our affiliate policy.
Tier 1: Pay $11.80 or More for 4 eBooks
The first tier is a compact introduction to programs, software, and the machine underneath.
The title "Think Like a Programmer" starts to make sense here as this tier focuses on problem-solving instead of a single programming language. How Software Works explains common software ideas in plain terms, while The Secret Life of Programs and How Computers Really Work walk through what your code is actually doing on real hardware.
If you want a foundation before picking up a language like C, Rust, or even assembly, this is the small but useful starting point.
Tier 2: Pay $23.60 or More for 10 eBooks
The second tier includes the first 4 books and adds 6 more on top of that.
Effective C, 2nd Edition and Write Great Code, Volume 2, 2nd Edition move you into C and lower-level implementation. Data Structures and Algorithms in JavaScript covers the usual structures and algorithm patterns in a language many people already know.
The math side includes Math for Programming and The Art of Randomness. Computer Graphics from Scratch still fits in this trier if you like seeing algorithms draw something on screen.
Tier 3: Pay $47.20 or More for 18 eBooks
The top tier adds 8 more books and brings the total to 18. This is where Rust, compilers, ARM, and heavier CS material show up.
For languages and compilers, you get the Rust book, Total TypeScript, and Writing a C Compiler. Algorithmic Thinking, 2nd Edition is the extra algorithms title if you want more practice than the JavaScript data structures book.
The hardware group includes Computer Architecture, Introduction to Computer Organization: ARM Edition, and The Art of ARM Assembly, Volume 1. Quantum Computing is the most specialized add-on in this tier.
Paying above $47.20 can increase your contribution, but it doesn't add more books.
Your purchase supports EFF
EFF (Electronic Frontier Foundation) is a nonprofit defending digital rights, i.e., free speech, privacy, security, and innovation online. Founded in 1990, it fights surveillance and censorship in court, lobbies for encryption rights and net neutrality, builds free privacy tools like Privacy Badger, and defends coders and researchers facing legal threats.
Your bundle purchase funds this work directly. The lawyers, policy experts, and technologists keeping the internet open, which lines up closely with FOSS community values.
So you are not just purchasing DRM-free ebooks. You are also contributing to a better digital world.
🛒 Get the Bundle
This bundle gives you DRM-free ebooks in PDF, EPUB, and MOBI files, so you can keep the books and read them on Linux or an e-reader or use the MOBI files on Amazon Kindle device. As mentioned above, part of the purchase goes to EFF.
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.
