You can start an update without authentication, but not cancel it. This
is just weird, and likely an upstream bug:
https://github.com/systemd/systemd/issues/38568
Until that bug is resolved, work around it here.
Resolves#235
BUG: 502189
bit awkward but this should produce more reliably results. in particular
for flatpak the previous naive approach could easily fail because of the
ostree repo content being files or dirs depending on unknown factors,
making it super difficult to copy them reliably. by composing first we
defer that problem to overlayfs, which is how this was used in rootfsv1
anyway.
with this we also no longer need the erofs /usr mount
The defaults are currently very harsh: each failed authentication
attempt makes you wait for 3 seconds, and 3 failed attempts lock you
out of the system for 10 minutes.
These defaults are tuned for high security, but Bugzilla is full of
complaints about it from Arch users who placed the blame on KDE. These
defaults are not well-tuned for normal users in normal environments, so
let's soften them a bit to offer a less harsh experience.
Resolves#222
We want for at least the pre-installed KDE software to be buildable on
the OS image with no hassle. Add some packages to the
packages-development.conf file.
Fixes#220
These aren't strictly speaking development tools. We don't want them to
disappear should we ever make the developer packages an optional overlay
or something.
Right now we don't have any swap, which can cause various memory
management complications, especially on systems with little physical
RAM.
Let's remedy this by using zram. This makes the system much less likely
to OOM in memory pressure situations, while being much faster than
disk-backed swap and avoiding the security issues of having RAM
contents on disk.
I chose some fairly aggressive settings based on research and testing:
- zram value of double the physical RAM, because it gets compressed
anyway and appears to have internal limits to avoid letting the
compressed memory completely crowd out the uncompressed memory.
- lz4 as the compression algorithm because it's super fast at the
expense of worse compression compared to zstd (the second best
option), but this is mitigated by having a large zram value.
- Tune the kernel parameters to make sense for swap being fast, since
the defaults assume slow swap which isn't true for us now.
The only thing we don't gain is hibernation support, but that can be
done later; these aren't mutually exclusive.
Resolves#84
