Here's a long text on what we are working on inrecently, and are probably going to work on for the next year. It's a great read to start your monday with.
198 plus ones
Shared publicly•View activity
View 127 previous comments
- A few questions, thanks!
1. root: and home: carry state. Booting a new version of usr: may cause backwards incompatible changes to said state. Updates to this state are not likely to be atomic. This makes possible two scenarios.
First, the half-updated scenario still remains a possibility (though greatly reduced). In the half-updated state, boot may be impossible with any usr:, causing irrecoverable breakage.
Second, even in a successful state update, it may be impossible to go backwards. There is no guarantee that once you have booted with v24 that you can ever boot v23 again.
This seems like this may be solvable by an automated snapshot before the first boot of a new version. Attempts to boot v23 after having booted v24 would simply use the old snapshot. Of course, this problem is much more complex given all the possible variants of usr:+app:. Apps too could do snapshots. With some properly smart garbage collection, this could even be somewhat manageable.
Has any thought been put into this problem?
2. The line between usr: and app: seems a bit blurry to me. Is gdm, for instance, part of usr: or apps:? PAM?
FreeIPA seems like a clear app: to me. However, FreeIPA is also basically a pile of plugins for other apps (http, bind, 389, PAM, krb5, etc). For some of these, we'd probably just ship our own daemons (389, krb5). But for several others, custom configurations are exceedingly common (http, bind, PAM).
Where is the line between usr: and app:? What does "everything necessary to boot it up" mean? How are app: unit files discovered? Can apps autorun? etc...Sep 8, 2014
- Why do you limit yourself to btrfs? The discussed features should be available at the VFS layer, not FS dependent. What does Linus think? Have you considered some level of integration with the package manager?Sep 10, 2014
Wanted to know if you'd be willing to do an interview with us for the Linux Action Show. With all your work on systemd and pushing for its capabilities, as well as your recent post about package management, via btrfs... it comes across to me that you have some vision in mind of what the future could hold for us in the Linux world. I would be really interested in hearing you talk candidly about your views, opinions, and hopes to where all this is heading.
Would you have time on some Sunday for this? And would this even be something you'd be interested in doing?Sep 24, 2014
- Thanks to, we happy few of Slackware and BSD users have a great future behind us.Sep 24, 2014
- a comment on an old (unrelated) google plus story is not the best way to contact me for questions like yours. Please send me an email instead. Thanks.Sep 30, 2014
- http://nixos.org solves this? Nowhere do you mention it specifically (perhaps maybe in the homework remark to ) and IMHO it's a superior solution for several of the goals.I don't want to be a prick, but I'll be it anyway: Have you actually looked at how
- With Nix, you package things to exist under /nix/store/HASH_OF_ALL_BUILD_INPUTS-name/, read-only
- You refer only to /nix/store/... for all dependencies
- Thus, you can have multiple versions of a library/app/etc installed and in use simultaneously, even multiple compilations of the same library version with different flags.
- All configuration is defined declaratively in the Nix language (functional, lazy): how to build or binary-patch any package, systemd configurations, service configuration etc.
- All configuration files are compiled into /nix/store/HASH_OF_ALL_BUILD_INPUTS-$configname/, read-only
- The system is all packages and configurations symlinked together in a tree and only exists if everything built (or was reused) successfully
- Thus, installation and rollback consist of copying all the needed files and switching the system configuration symlink to the new version/old version and telling systemd to handle the different service configuration
This doesn't need btrfs (but works fine with it of course) and even works on Mac. It can do cryptographic signing of build products too. It shares build products where they are identical and provides a solution for every level of the problem space: users, admins, developers, distributions. NixOS is an implementation of it, RedHat could use it too and still be RedHat.
If Android or iOS were to implement something like this, system upgrades would be a lazy download and a 30-second reboot with rollback available (apart from the application state of course)Nov 3, 2014
Add a comment...