
Don’t Get Mad, Get Triggered: 4 Home Assistant Automations I’m Finally Trying


The Genius Bar For The Free & Open Source Community


In operating systems, file systems are the foundation of stability. Users expect their storage layer to be uneventful, predictable, and above all, safe.
But behind the scenes of the Linux kernel, the development of Bcachefs—the modern Copy-on-Write (COW) file system slated to compete with Btrfs and ZFS—has been anything but boring.
Following a series of heated standoffs between Linus Torvalds and Bcachefs lead maintainer Kent Overstreet, the Linux creator made a dramatic executive decision: Bcachefs has been dropped from the mainline Linux kernel.
This conflict highlights the tension between rapid, visionary development and the strict discipline needed to manage software for billions of devices worldwide.
Merged into the mainline Linux kernel late in 2023, Bcachefs was hailed as the next-generation file system for the Linux ecosystem.
For years, Linux users have faced challenges with advanced storage features:
Bcachefs promised to bridge this gap with a high-performance, feature-rich, Copy-on-Write design. Its message was simple: “The file system that doesn’t eat your data.” It brought snapshotting, encryption, multi-drive management, and ZFS caching directly into Linux.
The breaking point did not occur because of a bug. It occurred because of a fundamental breach of the Linux kernel’s development protocol.
During the release cycle, kernel development follows a strict, consensus-based timeline:
1. The Merge Window: A two-week period where new features, drivers, and subsystems are merged into the upcoming kernel version.
2. The RC Phase: Code is frozen; developers may only fix bugs and regressions to ensure release stability.
During the RC phase, Kent Overstreet submitted a pull request containing a major change called “journal-rewind.” The feature was designed to improve Bcachefs’ repair and recovery functionality—a highly sensitive part of any file system.
Linus Torvalds objected. Introducing a structural change to journaling during the RC phase violates the kernel’s core safety rules.
Theodore Ts’o, the long-time maintainer of the robust ext4 file system, also weighed in. He pointed out that modifying journaling code so late in the cycle risks introducing severe, unpredictable regressions that could destroy user data—the exact opposite of what a file system is supposed to do.
The debate quickly devolved from a technical discussion into a clash of development philosophies.
Kent Overstreet argued that rules should be flexible when fixing data integrity. He felt delivering critical recovery features outweighed following the standard timeline, claiming Bcachefs needed more agility than traditional file systems like ext4.
Torvalds and Ts’o countered with a different reality: the rules are what protect user data.
In Linux’s vast ecosystem, a regression in a core file system can brick servers and corrupt data. Strict merge windows are crucial safety gates, proven over decades.
After a tense back-and-forth, Overstreet resubmitted the patch, arguing that other file systems, such as XFS and Btrfs, had been granted similar flexibility in the past.
Linus merged the patch to unblock the immediate release, but reached his limit. He made it clear that because Overstreet rejected the consensus-based rules of kernel development and refused to accept standard oversight, Bcachefs could no longer remain in mainline Linux.
Torvalds officially dropped support for Bcachefs, parting ways with the filesystem.
The removal of Bcachefs from the mainline kernel is a significant setback for the project, influencing not only its immediate trajectory but also shaping how future filesystems might approach kernel integration and community process.
Bcachefs will now be maintained “out-of-tree,” as ZFS is. Developers must package and compile modules for each release, which creates friction for users because Bcachefs won’t work natively with standard distributions.
Mainstream distributions are unlikely to support filesystems not in the mainline Linux kernel. Bcachefs will likely be limited to homelabbers, power users, and custom distributions.
This incident reinforces the authority of mainline kernel maintainers and sets a precedent for how future contributors should navigate development protocols. It signals to all developers that adherence to established processes will remain essential for the inclusion and long-term success of new filesystems in Linux.
The Bcachefs drama is a tragedy of open-source engineering. Bcachefs is a brilliant, highly innovative filesystem that solved problems other filesystems spent decades avoiding.
But in enterprise and system-level software, how you build is just as important as what you build.
The Linux kernel is the most successful collaborative software project in human history because it prioritizes safety, discipline, and consensus over individual speed. When a developer refuses to play by those rules, the system self-corrects—even if it means losing some of the most promising storage technology of the decade.
Support stable systems, open standards, and the rigorous engineering that keeps our digital world running.

But with great hardware success comes a classic software dilemma.
This month, a quiet storm flashed into the spotlight when Bambu Lab pressured a solo open-source developer to take down a fork of **OrcaSlicer** that reconnected the slicer directly to Bambu’s proprietary cloud infrastructure.
By trying to protect their API, Bambu Lab angered power users. They gave the open-source alternative a megaphone. Their relationship with the open-source community came under a microscope.
Before we dig into what happened, why it backfired, and what it means for the future of smart hardware, let’s take a step back and understand the roots of this controversy.
To understand the community’s reaction, it is necessary to examine the history of 3D printing software.
1. **Slic3r** was the original pioneer.
2. **Prusa Research** took Slic3r and heavily evolved it into the incredible **PrusaSlicer** (under the open-source GNU GPL v3 license).
3. **Bambu Lab** entered the market and built its own slicer, **Bambu Studio**, by forking PrusaSlicer.
4. The community, wanting even more advanced calibration tools and experimental features, then forked Bambu Studio to create **OrcaSlicer**.
Forking and modifying are allowed under the GPL v3 license. Bambu Lab had to keep Bambu Studio open source because it was built on PrusaSlicer. This open ecosystem enabled Bambu Lab to release a world-class slicer on day one.
But there was one proprietary element: **The Bambu Network Plugin**.
Bambu Studio is open-source. But the plugin that connects to Bambu’s cloud servers is closed-source and proprietary. This allows you to send prints over the internet, watch your camera feed, and monitor prints via Bambu Handy.
This created a major friction point. Many users prefer **OrcaSlicer** because of its superior calibration patterns and fine-grained controls, but they still own Bambu printers and want to use Bambu’s cloud features.
To address this issue, a solo developer wrote code to interface with Bambu’s cloud APIs, creating a fork that allowed OrcaSlicer to connect directly to the Bambu cloud.
Following this, legal representatives became involved.
Bambu Labs cited security and terms of service on unauthorized API use. They pressured the developer to take down the repository. The developer complied.
From a traditional corporate legal perspective, this was a standard intellectual property win. But in the tech world, this is where the **Streisand Effect** kicks in.
The Streisand Effect is a phenomenon in which an attempt to hide, remove, or censor a piece of information has the unintended consequence of publicizing it further.
By forcing the takedown, Bambu Lab triggered several things:
Bambu Lab’s official stance is that restricting access to their cloud API is necessary for security reasons. They argue that if third-party software gains uncontrolled access to their cloud servers, it could increase the risk of unauthorized actions, disrupt server operations, cause instability, expose user credentials, or leave printers more vulnerable to attack. Bambu Labs maintains that controlling API access helps ensure only trusted software can interact with their cloud infrastructure, protecting users and devices.
While security is a valid concern, the open-source community remains highly skeptical.
If security were the sole motivator, the solution would be documentation and open authorization. For example, OAuth. If Bambu Lab provided a secure, rate-limited way for third-party tools to authenticate with their cloud API, developers wouldn’t need to write “unauthorized” forks.
When a company uses legal pressure rather than enabling developers, it signals a prioritization of control over genuine security—heightening the core tension at stake.
The “Bambura Streisand” incident is a warning shot for every modern hardware company.
Building your product on open-source means following those rules. You cannot rely on community goodwill to build your software. Then use corporate gatekeeping to lock users out of the hardware they purchased.
Bambu Lab should recognize **interoperability as a feature, not a threat**. Embracing developers who want to build integrations for OrcaSlicer, Home Assistant, or custom dashboards adds value. It makes their printers more valuable.
Until such changes are made, the community will continue its development efforts and advocate for open local control.
Support open hardware and free code for the benefit of the entire community.
[{.alignleft}](/wp-content/uploads/2025/11/NixOS-Icon-02.png)
For years, Linux enthusiasts, **including myself**, have chased the “perfect distro.” Some want stability. Some want bleeding-edge packages. Some want reproducibility. And some—let’s be honest—just want something cool to tinker with at 2 a.m.
But **NixOS** quietly sidesteps this entire debate. It doesn’t compete with Ubuntu, Fedora, or Arch in the traditional sense. Instead, it **redefines what a Linux distribution can be**. We warned, **NixOS does have a steep learning curve**, but if you haven’t tried it, you’re missing one of the most transformative distros in modern computing.
## A Paradigm Shift, Not a Distro Hop
Most distributions configure the system through a web of package managers, shell scripts, and config files. NixOS ignores all of that and says: *”What if your entire system was a single, declarative, version-controlled document?”*
With NixOS, your system _is_ code. Not metaphorically, but literally. One file (*configuration.nix*, or a *flake*) describes:
– Installed software
– System services
– Users and groups
– Networking
– Hardware support
– Desktop environment
– Custom system tweaks
Change the file → rebuild the system → done.
If you can manage a Git repo, you can manage your entire OS.
## Reproducibility: The Superpower Other Distros Wish They Had
Imagine the following scenario: You set up the perfect workstation, terminal tools, development environments, fonts, and drivers. Then your SSD dies. Typically, you’d spend hours reinstalling.
On NixOS: **Git clone → nixos-rebuild switch → your entire system is back.**
Not just installed packages—the **entire configured system**, down to the kernel modules and systemd services.
## Below are some reasons why NixOS has a cult following among:
– DevOps engineers
– Software developers
– Homelabbers
– HPC folks
– Tinkerers and power users
### The Nix Package Manager
Nix, the package manager behind NixOS, is a beast—beautiful, powerful, and occasionally intimidating.
Here’s why it matters:
#### 1. Atomic upgrades
If an update breaks something, you can roll back your entire system in seconds.
#### 2. Zero dependency hell
Packages are built in isolated environments, so no more:
– Library conflicts
– Version clashes
– ABI breakage
– “This requires Python 3.12, but your system is on 3.11.”
#### 3. Multiple versions of the same software
Need Python 3.10 **and** Python 3.12?
Need two versions of Node?
Want three versions of GCC?
*No problem with Nix.* This flexibility makes NixOS feel like Linux in cheat mode.
## Home Manager: Your Dotfiles, Evolved
If NixOS handles system configuration, **Home Manager** handles user-level configuration—dotfiles, packages, shells, editors, theming, and more.
Home Manager lets you:
– Version-control your dotfiles
– Reproduce them on any machine
– Avoid “dotfile drift” across systems
– Switch between laptops/workstations effortlessly
Example:
home.username = {
programs.zsh.enable = true;
programs.starship.enable = true;
home.packages = [ pkgs.fastfetch pkgs.bat pkgs.exa ];
};
Rebuild → your environment is instantly standardized.
##### Home Manager is so good that even non-NixOS users install it. But on NixOS? It’s a match made in config-management heaven.
## Flakes: The Future of NixOS (and Why You Should Care)
Flakes add:
– Inputs (like package sources)
– Outputs (like your system config)
– Pinning (so updates never surprise you)
– Reproducibility across machines
Example:
nixosConfigurations.nixos = { system = “x86_64-linux”; modules = [ ./configuration.nix ]; };
Flakes lets you share your system between machines, maintain multiple configurations, and track changes.
## Why NixOS Feels Like Magic for Power Users
You’ll love NixOS if any of these statements hit home:
– “I want my whole system in Git.”
– “I want to rebuild a machine in 10 minutes.”
– “I’m tired of fixing dependency issues.”
– “I want the same environment on every machine.”
– “I want to understand _exactly_ how my system is built.”
NixOS gives you **control without chaos**, **flexibility without breakage**, and **power without fragility**.
## The Learning Curve: Real but Worth It
NixOS isn’t plug-and-play like **Pop!OS** or **Linux Mint**.
You will have to:
– Read docs
– Learn the Nix language
– Debug your configuration, and
– Occasionally mutter “Why isn’t this service starting?”
But once you get past the initial bump, something flips in your brain. You realize: *”This isn’t just a distro, but a better way to run computers.”*
## So, why haven’t you mastered it yet?
Not because it’s too hard—because it’s too _different_.
It asks you to let go of the old way of managing Linux.
But if you’re a Linux enthusiast, a sysadmin, or anyone who wants a smarter, reproducible, future-proof workflow, then NixOS isn’t just worth learning—it’s essential.
## Final Thoughts
I believe **NixOS** is the most important distro you haven’t mastered yet because it represents the next evolution of Linux use. Declarative systems, reproducibility, atomic upgrades, isolated builds, multiple versions, and Git-managed everything.
NixOS doesn’t just add features; it solves problems other distros have lived with for decades.
If you want a Linux environment that’s efficient, elegant, and engineered for power users, it’s time to give NixOS the attention it deserves.
And as always—welcome to the Saloon. Pull up a stool, grab a coffee, and let’s build your next great Linux system together!