24 Feb
2021
24 Feb
'21
7:37 p.m.
On Wed, Feb 24, 2021 at 10:50:03AM -0700, Grant Taylor via TUHS wrote:
Oh, sure. I agree completely that it's 180 degrees from the original
golden rule; it had intended to be a joke. Unfortunately, years of
living in a country whre the ones with the Gold really do make all of
the Rules has gotten me to the point where if I don't laugh at it, I
would have to cry....
I would call
this the "Tyrany of Gold", as in the reformulated Golden
Rule, "The ones with the Gold, makes the Rules".
Being a fan of the golden rule, I would not make, much less use, that
derivation. I think it completely changes the meaning of the spirit behind
the golden rule. I seem to recall hearing about a problem where a rogue
rm could accidentally
wipe out part of the UEFI. Maybe it was the contents of the /boot/efi
partition. So, I'd suggest a happy medium of mounting it Read-Only. That
way it's known to be used /and/ it's protected from a simple rogue rm. It
can relatively easily be re-mounted as Read-Write when necessary. As well
as subsequently re-mounted back to Read-Only.
So technically it doesn't wipe out UEFI; it just will destroy the
ability to boot the system. (e.g., this is where Grub lives, and if
you delete it, UEFI will no longer be able to launch Grub, and hence,
not boot Linux.) Fortunately, if you have a rescue CD / USB Thumb
drive, it's relatively easy to recover from this.
A rogue rm which deletes /bin (even if /bin is a symlink to /usr/bin,
all of the shell scripts and /etc/passwd entries probably still refer
to /bin/sh) is going to make the system similarly unbootable.
As far as making a system more robust against rogue rm's, I really
like scheme used by ChromeOS, where the entire file system is not only
read-only, but protected by a cryptographic Merkle Tree such that if
malware attempts to modify it, the system will crash. This is
combined with firmware which will only load a kernel with a valid
digital signature, and the user data is stored on an encrypted file
system mounted on /mnt/stateful_partition and it is the only file
system mounted read/write on a ChromeOS system. It violates a lot of
expectations about where files should live on a "normal" Unix or Linux
system, but it's defnitely way more safe and secure.
I feel like we've already abandoned i386 as in
80386 (or compatible)
architecture. I think we now require Pentium (586?) or better. At some
point, we'll completely remove 32-bit support from mainstream Linux
distributions, thus requiring something from the 21st century.
For now, as far as I know, Debian still supports a 486 (or i386 with
an i387 co-processor, which was my first Linux system). But yes, it
is very likely, absent people showing up to volunteer to support
32-bit userspace at Debian (e.g., ongoing security updates, support
for the i386 build farm, reporting and triaging build failures of
packages on i386, etc.), that the i386 arch will probably get dropped
after Debian Bullseye release (which will probably happpen sometime in
mid-2021 if I had to guess).
I'm not sure there are any 486's around any more, and it's likely most
uses of systems with i386 binaries are on 64-bit processors running in
32-bit mode, so 486 vs 586 is probably not all that important in the
grand scheme of things.
- Ted