https://github.com/NixOS/nixpkgs/pull/480686 made getty unconditional, fixing
several bugs and bad interactions. This imposes no runtime costs due to lazy
systemd-based activation, but it does drag getty and its closure in to images.
For many NixOS installations, this is fine - they want console login and such
anyway - but it's a burden on lights-out containers aiming for minimal image
sizes.
This change adds a new configuration knob to totally disable getty for these
sorts of headless/lights-out/appliance-style set-ups. The option's description
is deliberately made stern to hopefully dissuade anyone from toggling it if
their system isn't in that class. As the option defaults to enabling getty,
there should be no behaviour change for anyone not explicitly opting themselves
in - hopefully with full knowledge of the consequences.
My local testing chopped a whole 15% off one of my images by being able to
remove getty (the big contributor being util-linux and its friends), and that's
just for one random image - others might be even bigger relative gains. I think
that's more than enough to justify this configuration knob.
I had a look for uses of getty in NixOS to see if anywhere wanted to either
have a hard dependency on getty and hence explicitly enable it (so that weird
configurations get picked up at evaluation time rather than runtime) or disable
it. The use sites fall into two categories:
0. Virtualised set-ups that wire up units to getty listening on ttyS0. These
probably don't want a hard dependency: it's reasonable to run these lights-out,
and just disabling getty will DTRT here.
1. `modules/profiles/headless.nix`, which disables some of the getty units.
This _could_ instead disable getty as a whole, but that might break e.g.
`machinectl shell`, and I can imagine set-ups where you want that even without
console login, so I have left it alone. Maybe someone else feels differently
and more strongly, and then that someone else can put together a PR and argue
their case.
I have effectively renounced on maintaining all these packages and I do
not plan to return them except if I'm forced to.
I am also fine with most of these packages being dropped for next
releases if no maintainer shows up.
Change-Id: I8d167c8029b6991181bd7a094af21c3313af2b51
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Sam Pointon