• 7 Posts
  • 1.88K Comments
Joined 2 years ago
cake
Cake day: June 6th, 2023

help-circle








  • I haven’t been keeping up super close with this, but from the posts by Linus I have seen, I got the sense that he doesn’t really care about bcachefs stability as much as the fact that Kent’s changes keep touching common code at a time when they’re hardening. If they were isolated to bcachefs I don’t think Linus would care at all. And Linus keeps telling him not to try that, and Kent acts like he’s being singled out and persecuted. That’s my current understanding.









  • Yeah, so that’s possible because Canonical has enough sway to get their key to play nice with manufacturers’ firmware. If you are on almost any other distro (arch included) or if you build your own kernel, it’s a headache just to get it to work at all even without dual boot. It also just might not even be possible due to a bad implementation on your motherboard (results ranging from dual boot windows refusing to boot, to a bricked motherboard).

    Here’s the process for enabling secure boot for arch users. Make sure to peruse the section on dual booting.

    If you’re wondering why it’s so complicated, it’s because of what secure boot is: you want to be sure you’re booting into binary that’s signed by a set of special keys. But Linux is not one binary that can be signed by Linus Torvalds, it’s a bundle of source code that is built by end-users. So if you decide to make any changes to the kernel you have on ububtu, you won’t be able to convince Canonical to sign your build, and you will need to jump through all the hoops on that arch wiki.

    There are many reasons for the headache, but primarily I’d say it’s because UEFI is closed source, and msft designed Secure Boot for it, and then manufacturers didn’t care about supporting it any more than the bare minimum. And all of that together results in an ecosystem of devices that favor MSFT. That’s why Linux users don’t like secure boot.