Mint is easy mode, but has no secure boot shim implemented. It makes gaming accessible.
Pop is made for System76 and does some stuff funny IMO, and is like Mint with no secure boot if you are not running 76’s proprietary bootloader on their hardware
Ubuntu is easy but has its quirks (most are fixed by Mint which is based on Debian/Ubuntu)
Debian is hard mode and is an advanced distro. There are a ton of tools that are unique to Debian. It is used mostly for people running their own servers and custom purpose machines from home or work. It is also the primary distro for hacking hardware and reverse engineering stuff that has no other way to create Linux kernel support.
Every distro has some things that they are specialized for. You can do almost anything with any of them, but it will depend on your skill level. Something to keep in mind here is that Linux is not a consumerism branding contest. We are not choosing our frivolous teams. This is the place where everyone can learn. While beginners and users are welcome, you will find many aspects of Linux are the study and thesis projects for many computer science students. All levels are present here. This is why so many options exist.
All distros “support” SB because SB is not part of Linux and it requires setting your own SB keys. That is outside of easy scope. The question is if they support the m$ signed shim and what system is used to achieve this. Fed uses Anaconda (unrelated to Python container system). It is something unique to Fedora as far as I know. Linux refuses to support SB because SB is a scheme to steal hardware ownership. The standard implementation is only a suggestion and bootloaders are not required to give you access to the custom keys implementation in the specification. Microsoft controls the shim for SB. It is extremely decisive and controversial.
“Linux” doesn’t support secure boot because it’s distributed as source rather than binaries. As far as I’m aware Linux actually has special handling for secure boot (there’s a kernel mode where it refuses to load unsigned drivers).
Also, I think as part of the secure boot spec, implementations are required to let you enroll your own keys. Whether that’s still true or if it even works on many motherboards is another question.
Anyway Unbuntu (and thus Mint) should take care of the signing for you. Although when I tried it didn’t work, but that could have because I use a fancy gamer kernel rather than the default.
The mechanism for not loading signed drivers is outside of the kernel. In Fedora, this is handled by Anaconda.
The last time I checked a few months ago, only Fedora and Ubuntu participate in the Microsoft 3rd party key signing arrangement. This shim signed aspect is done at the final stage of distro packaging. There is no upstream so it is not a Debian or downstream thing.
There can only be the one kernel they sign. This is a problem for Nvidia because Nvidia modules are unsigned upstream. They only do their binary BS and supply kernel source code that is different from that binary. We must build that source to make a module but this is unsigned. The only way to have Nvidia drivers under a shim is to build a system that can shim into the gap between boot and kernel init. This must build the Nvidia module from source in a way that is totally secure so that it may never be modified inside Linux or used as an entry point to add a root kit to the UEFI bootloader. Once the Nvidia module is built, then Linux is initialized. This is the only way to have secure boot functioning unless the user manually adds custom keys to the bootloader and signs their own kernel modules. Most distros leave this aspect of the system entirely up to the end user because it is not part of Linux. Most distros tell you to turn off secure boot. The bootloader is the largest attack surface in modern computers.
The secure boot specification is only a set of guidelines and not a required implementation. Indeed, my laptop does not have the functionality implemented to enable this, thus the reason I know all of this so well. There is still another way that I have not explored, but it is generally less known and lesser documented. There is a tool called Keytool that can boot directly into UEFI. Supposedly it can manually alter the keys outside of the bootloader implemented features set. The only documentation I have ever come across for Keytool is in the gentoo handbook, but gentoo documentation assumes a very high level of competence.
Mint is easy mode, but has no secure boot shim implemented. It makes gaming accessible.
Pop is made for System76 and does some stuff funny IMO, and is like Mint with no secure boot if you are not running 76’s proprietary bootloader on their hardware
Ubuntu is easy but has its quirks (most are fixed by Mint which is based on Debian/Ubuntu)
Debian is hard mode and is an advanced distro. There are a ton of tools that are unique to Debian. It is used mostly for people running their own servers and custom purpose machines from home or work. It is also the primary distro for hacking hardware and reverse engineering stuff that has no other way to create Linux kernel support.
Every distro has some things that they are specialized for. You can do almost anything with any of them, but it will depend on your skill level. Something to keep in mind here is that Linux is not a consumerism branding contest. We are not choosing our frivolous teams. This is the place where everyone can learn. While beginners and users are welcome, you will find many aspects of Linux are the study and thesis projects for many computer science students. All levels are present here. This is why so many options exist.
Afaik, Mint does support secure boot nowadays.
All distros “support” SB because SB is not part of Linux and it requires setting your own SB keys. That is outside of easy scope. The question is if they support the m$ signed shim and what system is used to achieve this. Fed uses Anaconda (unrelated to Python container system). It is something unique to Fedora as far as I know. Linux refuses to support SB because SB is a scheme to steal hardware ownership. The standard implementation is only a suggestion and bootloaders are not required to give you access to the custom keys implementation in the specification. Microsoft controls the shim for SB. It is extremely decisive and controversial.
“Linux” doesn’t support secure boot because it’s distributed as source rather than binaries. As far as I’m aware Linux actually has special handling for secure boot (there’s a kernel mode where it refuses to load unsigned drivers).
Also, I think as part of the secure boot spec, implementations are required to let you enroll your own keys. Whether that’s still true or if it even works on many motherboards is another question.
Anyway Unbuntu (and thus Mint) should take care of the signing for you. Although when I tried it didn’t work, but that could have because I use a fancy gamer kernel rather than the default.
The mechanism for not loading signed drivers is outside of the kernel. In Fedora, this is handled by Anaconda.
The last time I checked a few months ago, only Fedora and Ubuntu participate in the Microsoft 3rd party key signing arrangement. This shim signed aspect is done at the final stage of distro packaging. There is no upstream so it is not a Debian or downstream thing.
There can only be the one kernel they sign. This is a problem for Nvidia because Nvidia modules are unsigned upstream. They only do their binary BS and supply kernel source code that is different from that binary. We must build that source to make a module but this is unsigned. The only way to have Nvidia drivers under a shim is to build a system that can shim into the gap between boot and kernel init. This must build the Nvidia module from source in a way that is totally secure so that it may never be modified inside Linux or used as an entry point to add a root kit to the UEFI bootloader. Once the Nvidia module is built, then Linux is initialized. This is the only way to have secure boot functioning unless the user manually adds custom keys to the bootloader and signs their own kernel modules. Most distros leave this aspect of the system entirely up to the end user because it is not part of Linux. Most distros tell you to turn off secure boot. The bootloader is the largest attack surface in modern computers.
The secure boot specification is only a set of guidelines and not a required implementation. Indeed, my laptop does not have the functionality implemented to enable this, thus the reason I know all of this so well. There is still another way that I have not explored, but it is generally less known and lesser documented. There is a tool called Keytool that can boot directly into UEFI. Supposedly it can manually alter the keys outside of the bootloader implemented features set. The only documentation I have ever come across for Keytool is in the gentoo handbook, but gentoo documentation assumes a very high level of competence.
Very well put.