systemd is not responsible for allowing kernel code that I wrote to destroy your shitty firmware. I think you get to blame me instead.
-
-
@RichFelker it was intended to be globally accessible because it's incredibly useful -
@mjg59 You should be able to count the # of programs that need to access any particular hardware-related thing on one hand. Pref one finger. -
@mjg59 EFI should be completely out of the way as soon as bootloader has transferred control to kernel and kernel has enumerated devices. -
@RichFelker cool story but no -
@mjg59 So you like having hardware-vendor-provided binary blobs compromising your system? Fun. -
@RichFelker no, which is why I support people producing open implementations -
@mjg59 Well most users don't have the luxury of open implementations. Running firmware code with kernel privs compromises their security. -
@RichFelker Running on closed hardware compromises security. We all make choices about what level of risk we accept.
End of conversation
New conversation -
-
-
@mjg59 Making unsafe/unstable/dangerous kernel code enabled-by-default is the fault of the distro/sw that enables it. In this case systemd. -
@RichFelker the fault is the kernel, not systemd. Changing systemd's behaviour would break userland and still allow bricking. - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.