Why does this exist?
Rolling release is great until an important update disagrees with boot, a driver, or another critical piece. Felunyx does not pretend that day will never happen.
The useful answer is to prepare a return path before confirmation, not improvise one after the machine is already unhappy.
How the idea works
The transaction backend classifies risk, decides whether the operation deserves a snapshot, and presents the plan. The snapshot belongs to the same update story instead of being hidden in a different tool.
- Smart is the default automatic snapshot policy.
- Higher-risk changes get deliberate protection.
- System restore preserves home by default.
- Restoring home creates a safety snapshot of its current state first.
In practice
You should be able to see what changes, why it is considered risky, whether a snapshot exists, what it covers, and what returning would actually do.
A rollback button is not especially comforting if it keeps the important consequences a surprise.
Under the hood
Automatic installs use Btrfs with separate system and home scopes. Snapshot orchestration belongs to the shared transaction backend; the UI presents state, consequences, and evidence.
Critical configuration writes are expected to be atomic, and action history must retain enough evidence to explain interrupted work.
Current status
Architecture and decisions define the direction. Btrfs foundation work belongs to Phase 2, while integrated risk, snapshot, journal and recovery behavior mainly belongs to Phases 3 and 5.
It is an important product promise, not a finished feature you should trust with real data today.