In theory, it's a wonderful idea, because it means you can run the same distro on your RPis as on the rest of your fleet (architecture differences notwithstanding), and therefore have consistent patching requirements, etc. In practice, as frustrating as it is that the RPi kernel patches haven't been upstreamed, they exist for a reason and I think by not having them, you're shooting yourself in the foot (even if you only hit a toe or two). Two things I observed recently when directly comparing stock Debian aarch64 with Raspberry Pi OS on an RPi4 was a 40%+ reduction in SD card read performance, and nonfunctional power control of the USB ports.
Fwiw I still have a “poor man's NAS” RPi4 running Debian, and it works great. (The SD card throughput deficiencies don't affect me there because the system boots from a USB-attached SSD.) If you're able to take the time to make a situation-specific assessment of what works (and what works “well enough”) vs. what doesn't, then in the long term, you can reap the benefits of not having to remember how to handle a single oddball OS in your fleet (especially given RPi OS' particularly consumer-oriented whims).
Yes, it is. And that in turn enables fairly simple installation of NetBSD and suchlike, which have ARM ports that know how to talk to and layer themselves on top of EFI firmware.
An interesting further little feature of TianoCore particularly for Pi 4 users is that it maintains a fake hardware clock. It only ticks forward when the firmware is in boot services mode; it is persisted to the firmware's own image file in the EFI System Partition; and it isn't as effective as even a simple fake-hwclock utility. But it does satisfy the operating systems that assume that there must be a hardware clock, because every computer is PC98-compatible.
Yes; it means you can, for example, install an off-the-shelf copy of Debian. See https://github.com/pftf/RPi4.
In theory, it's a wonderful idea, because it means you can run the same distro on your RPis as on the rest of your fleet (architecture differences notwithstanding), and therefore have consistent patching requirements, etc. In practice, as frustrating as it is that the RPi kernel patches haven't been upstreamed, they exist for a reason and I think by not having them, you're shooting yourself in the foot (even if you only hit a toe or two). Two things I observed recently when directly comparing stock Debian aarch64 with Raspberry Pi OS on an RPi4 was a 40%+ reduction in SD card read performance, and nonfunctional power control of the USB ports.
Fwiw I still have a “poor man's NAS” RPi4 running Debian, and it works great. (The SD card throughput deficiencies don't affect me there because the system boots from a USB-attached SSD.) If you're able to take the time to make a situation-specific assessment of what works (and what works “well enough”) vs. what doesn't, then in the long term, you can reap the benefits of not having to remember how to handle a single oddball OS in your fleet (especially given RPi OS' particularly consumer-oriented whims).
Yes, it is. And that in turn enables fairly simple installation of NetBSD and suchlike, which have ARM ports that know how to talk to and layer themselves on top of EFI firmware.
An interesting further little feature of TianoCore particularly for Pi 4 users is that it maintains a fake hardware clock. It only ticks forward when the firmware is in boot services mode; it is persisted to the firmware's own image file in the EFI System Partition; and it isn't as effective as even a simple fake-hwclock utility. But it does satisfy the operating systems that assume that there must be a hardware clock, because every computer is PC98-compatible.