Show HN: Docker-boot – Run a system from RAM without LiveCD(github.com)
github.com
Show HN: Docker-boot – Run a system from RAM without LiveCD
https://github.com/purplesyringa/docker-boot
9 コメント
>also drives libostree and Nix users mad
no, it really doesn't. (nixos-generators has multiple ready-to-go kexec options, nixos-anywhere is entirely built on the concept, etc, etc. It would be a two-line change to pull in the kexec module into any of my computers configurations [or all of them!], and another single command to kexec reboot into it.)
> How often do you screw up the system so much you have to reformat the disk (without losing data) to fix it?
Have you heard of NixOS? Where this is nigh impossible?
lol
no, it really doesn't. (nixos-generators has multiple ready-to-go kexec options, nixos-anywhere is entirely built on the concept, etc, etc. It would be a two-line change to pull in the kexec module into any of my computers configurations [or all of them!], and another single command to kexec reboot into it.)
> How often do you screw up the system so much you have to reformat the disk (without losing data) to fix it?
Have you heard of NixOS? Where this is nigh impossible?
lol
> Have you heard of NixOS? Where this is nigh impossible?
I'm with you. I stopped nuking and paving when I switched to NixOS. It's nice. Maybe in a few more years it'll have saved me more time than I've put into it, but it has been fun anyhow.
It's not quite utopia however. Now I have bugs which I've perfectly replicated across all of my machines. So on the one hand: I don't need any nukes. On the other hand: my nukes are now useless anyway.
I'm with you. I stopped nuking and paving when I switched to NixOS. It's nice. Maybe in a few more years it'll have saved me more time than I've put into it, but it has been fun anyhow.
It's not quite utopia however. Now I have bugs which I've perfectly replicated across all of my machines. So on the one hand: I don't need any nukes. On the other hand: my nukes are now useless anyway.
> How often do you screw up the system so much you have to reformat the disk (without losing data) to fix it?
Never. But I am curious as to what you are doing to get into this situation so often.
Never. But I am curious as to what you are doing to get into this situation so often.
For me it's usually related to modifying partitions, changing disks, OS upgrades going wrong, or some minor disk corruption.
It's not common, but if you manage enough systems then even rare things happen enough that you'll need tools like this in your tool belt.
I usually reach for a live-OS booted off a USB drive (Ventoy is good for having lots of OS options on a single USB drive) but I'd be interested in giving this a try.
It's not common, but if you manage enough systems then even rare things happen enough that you'll need tools like this in your tool belt.
I usually reach for a live-OS booted off a USB drive (Ventoy is good for having lots of OS options on a single USB drive) but I'd be interested in giving this a try.
It doesn't happen to me frequently anymore, but it's not terribly hard if you're tinkering and not super experienced (not a dig; this kind of slightly-beyond-your-comfort-zone tinkering is often a good way to become experienced). Install a couple packages from source, mix in a 3rd-party PPA, hand-edit a bunch of files under /etc, upgrade across a major distro version, and it's not that hard to get into a state where you probably could unwind things but it's so much easier to just reset the whole thing.
Edit: Phrased differently, doing the opposite of this advice: https://wiki.debian.org/DontBreakDebian is a great way to get into a situation where reinstalling is easier than fixing it.
Edit: Phrased differently, doing the opposite of this advice: https://wiki.debian.org/DontBreakDebian is a great way to get into a situation where reinstalling is easier than fixing it.
I've been using my Ubuntu installation for eight years straight. The choices regarding the size of swap and the EFI system partition made sense back then, now they don't. I used to use Windows more often than Linux, now it's the other way round, so it makes sense to shrink Windows partitions and grow Linux partitions. I'm stuck with all sorts of legacy decisions that take time to redo correctly, and doing anything related to partitions online is hard.
Broadly a neat idea, and props for actually following through. I am in fact a big fan of:
> I'm a Nix contrarian, so naturally I wanted something to be to Docker like NixOS is to Nix. docker-boot fills this niche.
not least because I've also been trying to figure out if there isn't a way to do nearly everything nix does with way better ease of use using docker or something similar.
That said,
> It also drives libostree and Nix users mad, because it can be used to try out a new DE or even a whole OS without polluting the host filesystem or spawning a virtual machine. The video in the README shows me trying out KDE + SDDM from a host running GNOME + GDM3.
is needlessly combative and also not really a comparison that makes your solution look good; neither of those options "pollute" the host filesystem, they at most cache results thereby saving work until you tell them to garbage collect at which point it goes away (and this also means that they're not limited to the size of RAM), and neither of them needs a VM in order to cleanly transition from one configuration to another.
> I'm a Nix contrarian, so naturally I wanted something to be to Docker like NixOS is to Nix. docker-boot fills this niche.
not least because I've also been trying to figure out if there isn't a way to do nearly everything nix does with way better ease of use using docker or something similar.
That said,
> It also drives libostree and Nix users mad, because it can be used to try out a new DE or even a whole OS without polluting the host filesystem or spawning a virtual machine. The video in the README shows me trying out KDE + SDDM from a host running GNOME + GDM3.
is needlessly combative and also not really a comparison that makes your solution look good; neither of those options "pollute" the host filesystem, they at most cache results thereby saving work until you tell them to garbage collect at which point it goes away (and this also means that they're not limited to the size of RAM), and neither of them needs a VM in order to cleanly transition from one configuration to another.
> is needlessly combative and also not really a comparison that makes your solution look good
Sorry, wasn't my intention. I didn't mean libostree or Nix pollute the filesystem, I meant that installing a DE on a typical mainstream OS like Debian would pollute the fs. I have nothing against libostree/Nix users :)
Sorry, wasn't my intention. I didn't mean libostree or Nix pollute the filesystem, I meant that installing a DE on a typical mainstream OS like Debian would pollute the fs. I have nothing against libostree/Nix users :)
I read this as a tongue in cheek take on isolation of your os. I mean, the ability of nix to install stuff isolated from the rest of the os is a point I make about stuff that nix can do. But I wouldn’t be mad as it’s not the only thing it can do :-)
My go-to solution has typically been to create a chroot with busybox and a few utilities in /tmp, chroot into it, and then kill services that use the solid drive so that I can unmount it. That's an error-prone process, and sometimes systemd itself uses disk, so you can't unmount the drive despite killing all the userland but PID 1.
This script improves the UX. It uses a Docker image as the chroot base, which is much easier to tailor to your needs, and automagically commits all the atrocities, such as tearing down all the userland processes, including PID 1, and re-spawning the host system from the container filesystem.
It also drives libostree and Nix users mad, because it can be used to try out a new DE or even a whole OS without polluting the host filesystem or spawning a virtual machine. The video in the README shows me trying out KDE + SDDM from a host running GNOME + GDM3.