eyJhb has quit [Remote host closed the connection]
lopsided98 has quit [Ping timeout: 264 seconds]
lopsided98 has joined #nixos-chat
Drakonis has quit [Quit: WeeChat 2.4]
<elvishjerricco>
Interesting idea: NixOS upgrades aren't quite atomic, because the activation script does a bunch of imperative stuff that can be interrupted. But, kinda like a journaling file system, a crash during activation is corrected at reboot. Instead, you could prepare the root file system in a separate place, then atomically remount / to the new directory when finished.
<pie_>
on on hand, cool on the other hand, ehh?
<pie_>
what about things that are still open?
<pie_>
not sure how linux normally handles this but i think those inodes just dont get deleted or something but idk
<elvishjerricco>
Yea that's a good point. Plenty of /etc files would be open
<elvishjerricco>
You'd need a custom FS designed for this specific purpose
<elvishjerricco>
It'd be cool if ZFS had some way to mount a snapshot readonly and then fastforward the mount to a future snapshot, retaining all the same inodes and stuff, just like rollback.
<pie_>
elvishjerricco, ok i was thinking user stuff but i guess sure
<pie_>
i suppose you could restart services but at that point its basically a reboot?
<pie_>
im kind of tired though so i might have made some unnecessary connections there
<elvishjerricco>
Well if ZFS could do a fast forward like that, nothing would necessarily need to be restarted. It'd behave like a zfs rollback
<elvishjerricco>
So all the open files would continue to work and reference the same files correctly
<pie_>
i dont follow
<pie_>
do you mean invisibly switch file contents out under you?
<pie_>
sounds bad because of state maintained in running applications
<elvishjerricco>
Yea, and maybe throw some fs notify events or whatever to make it look exactly as though writes had occurred all over those files simultaneously
<elvishjerricco>
As if the activation script did exactly what it does now, but instantaneously
<pie_>
i guess you could pause writes during the switching operation for similar effect
<pie_>
maybe you can test this with FUSE :p
<elvishjerricco>
Well this would only work for a readonly file system, since snapshots can only be mounted readonly
<elvishjerricco>
Otherwise we'd have merge problems
<elvishjerricco>
But readonly /, /etc, and so on isn't unheard of :P
<pie_>
pausing writes is basically the same as read only i guess (?)
<pie_>
well, its an implementation detail for the moment :p
<{^_^}>
webpack/webpack-cli#962 (by DJ-MATAIL, 3 weeks ago, closed): Webpack crushes when tries to print a message about donating in Windows 8.1
<pie_>
well noone likes mondays right
<pie_>
elvishjerricco, i think this would be cool if it worked! :3 . i have a hunch that stuff around ...whats the word..."runtime" things (as opposed to on disk nixy stuff) like activation scripts and such are not so nice because you dont have the whole functional purity isolation stuff going on and you have the whole unmanageable complexity of corellated states and everything gets breaky
<pie_>
dunno what to do about it
<pie_>
(contianerize all the things?)
<pie_>
(did that make any sense)
<elvishjerricco>
Well in theory it could be implemented such that it's impossible to observe it as any different than the current activation behavior but instantaneous.
<pie_>
i guess that was kind of orthogonal. the current ativation behaviour is also breaky :D
<Shados>
elvishjerricco: Files on mostly / aren't the non-atomic bits, though, from what I understand. The non-atomic bits are mostly to do with the bootloader. The rest of the file-level stuff can be atomic if you ditch having any non-Nix-managed /etc files, because it can then be a single symlink change, which I think is an atomic op in linux.
<Shados>
(Which reminds me... I've seen software (ab)use symlink creation/renaming-over being atomic to implement file/directory locking...)
<elvishjerricco>
Ah, yea I guess there's not really a way to make writing the boot loader atomic, unless there were a way to do a ring buffer style thing like ZFS's uberblocks, where you keep a couple boot loaders and only the most recent fully written one gets booted
<Shados>
Well, with EFI boot entries I suspect there is, but you can't make "updating the bootloader + changing the filesystem symlink" as a whole atomic
<Shados>
(To be clear, you could keep a 'current' and a 'next' boot entry in the EFI menu entry list, and update the config of the 'next' bootloader, then swap their order in the EFI menu entry list)
<elvishjerricco>
You could if you program the bootloader to look for config files at distinct paths.
<elvishjerricco>
e.g. grub-1.cfg grub-2.cfg. This way failing to completely write the new grub efi entry will leave the old one usable
<elvishjerricco>
Course it begs the question... is creating an efi boot entry atomic? If there's a power outage while creating it, does efi recover gracefully?
<pie_>
upgrades are now only considered atomic if you have an bootable external usb device attached to the system :p
<elvishjerricco>
On a different subject, if you keep a local backup and a remote backup, each with identical, long histories of old snapshots, is there any reason to keep a long snapshot history on the live system? I figure using `zfs rollback` to a snapshot from months or years ago isn't actually a common use case, and that you really only keep history so you can go and read old files ad-hoc. In that case, I figure one local and one remote backup is
<elvishjerricco>
probably sufficient, and the longterm history can stay off the live system
<pie_>
its not really a backup if there's only one copy?
<pie_>
but if thats fine, *shrug*
<elvishjerricco>
pie_: There'd be two copies. One local backup and one remote.
<elvishjerricco>
Three pools. Live system, local backup, remote backup. Backups have long history, live system only has recent history.
endformationage has quit [Quit: WeeChat 2.5]
Arahael has joined #nixos-chat
<gchristensen>
elvishjerricco: you can atomically move the entry in to place, with a `vm`
<gchristensen>
`mv`*
<pie_>
too soon? :P
<pie_>
or maybe "freudian slip" would be more appropriate
<elvishjerricco>
gchristensen: Yea, I guess if EFI doesn't see a file mentioned in the nvram, maybe it'll just skip it.
veske has quit [Quit: This computer has gone to sleep]
vdemeester_ has joined #nixos-chat
pie_ has quit [Ping timeout: 272 seconds]
vdemeester_ has quit [Quit: vdemeester_]
vdemeester_ has joined #nixos-chat
vdemeester_ has quit [Quit: vdemeester_]
vdemeester_ has joined #nixos-chat
vdemeester_ has quit [Quit: vdemeester_]
vdemeester_ has joined #nixos-chat
jackdk has quit [Quit: Connection closed for inactivity]
pie_ has joined #nixos-chat
vdemeester_ has quit [Quit: vdemeester_]
__monty__ has joined #nixos-chat
Miyu-chan has joined #nixos-chat
<Miyu-chan>
clever: Spacemacs + EXWM is actually good. What the fuck
<Miyu-chan>
I'm back to Vim keybindings after ~3 years.
vdemeester_ has joined #nixos-chat
<etu>
Miyu-chan: I'm using EXWM and emacs, but is not a fan of Vim bindings. But I've been saying that evil should work fine for exwm to people for months :D
<Miyu-chan>
I'm not much of a fan either, but I got tired of maintaining my .emacs.
<Miyu-chan>
(And I do know Spacemacs has Emacs mode, but I feel like that's less maintained)
vdemeester_ has quit [Quit: vdemeester_]
eacameron has quit [*.net *.split]
PyroLagus has quit [*.net *.split]
tazjin has quit [*.net *.split]
nand0p has quit [*.net *.split]
lucus16 has quit [*.net *.split]
sdier has quit [*.net *.split]
manveru has quit [*.net *.split]
vdemeester_ has joined #nixos-chat
<steveeJ>
is there a way to get metadata for packages on the command line?
<{^_^}>
johnfactotum/foliate#44 (by probonopd, 4 weeks ago, open): Please provide an AppImage for Linux
* infinisil
laughs in Nix
<eyJhb>
infinisil: be nice to the nonNixabled
<eyJhb>
;) :p
<colemickens>
The prepare root and then switch has other fun implications, you could go further and do the chromeos model, where the partition is prebuilt and signed for verified boot
<colemickens>
"It is written in Perl with extensibility in mind." lol
<gchristensen>
no :( how about we "just do one" when I get back in town
<ajs124>
Assuming I would want to put /nix and /tmp on a different filesystem from the rest of my / and assuming I also wouldn't want to use a filesystem for /nix and /tmp which supports subvolumes, could I mount it somewhere and bind mount two folders to /nix and /tmp or would that break everything?
<gchristensen>
#nixos would be a good place ajs124 :)
<ajs124>
gchristensen, right, that's another channel. I'll crosspost there.
<gchristensen>
:)
__monty__ has quit [Ping timeout: 245 seconds]
<eyJhb>
Sounds cool!
<eyJhb>
Reminds me of Gitlab, where they record the meetings and put online
<gchristensen>
Our evaluation against a diverse set of real-world applications, among others Nginx, Lighttpd, and the PHP interpreter, removes on average 71.3% of the code in musl-libc, a popular libc implementation.