TehPers

why would something have to be closed source in order to optionally provide secure boot? Couldn’t you provide the secure-boot-enabled binaries in addition to the source for everything except the boot keys?

This is also something I don’t fully understand. Unfortunately it’s not easy to find what the requirements are to get a bootloader signed by MS. It’s possible I’m mixing up these requirements with requirements for something else that requires a NDA, but it’s really not that simple to find the requirements online.

It’s possible that the latter is actually the case and it’s not secure boot that requires it to be closed source. It’s also possible I’m entirely mistaken and they don’t need to make it closed source at all. I wish TrueNAS would give more details why it needs to be closed source - whether it’s due to a NDA or whatnot.

You can use self-signed keys.

It’s basically like saying you can trust your own certificates used by TLS on your own machine rather than going through a CA, but realistically businesses would rather use a CA.

Self sign doesn’t defeat the purpose

The whole point of signing is that the BIOS can verify that the bootloader is legitimate. For a local Arch install, it doesn’t matter because Arch doesn’t distribute signed bootloaders and the environment is wholly personal. TrueNAS sells products and services though, such as enterprise-level support. It isn’t just something used in home labs. Their customers may require things we do not, and secure boot support appears to be one of them.

Self-signing to work around the idiotic restrictions Microsoft imposes to get it signed would be one way to do that, but then the software is essentially acting as its own authority that it is legitimate. Customers would realistically rather the bootloader’s signature is valid with the built-in key provided by MS since it means that MS is confirming its validity instead - not exactly a name I would trust, but I’m personally not a TrueNAS enterprise customer either.

This transition was necessary to meet new security requirements, including support for Secure Boot

Secure boot is dumb, but explains why they’d need a repo to be closed source. To summarize it briefly, you need your bootloader to be signed to work at all with secure boot, which means you have two options: self-sign (which defeats the purpose, though some Linux distros let you do this if you want), or follow all the requirements imposed by Microsoft. As far as I’m aware, one of those requirements is that it must be closed source.

HeliBoard is a privacy-conscious and customizable open-source keyboard, based on AOSP / OpenBoard. Does not use internet permission, and thus is 100% offline.

Pre-LLM translation services also generally used AI, just via more traditional machine learning. The only difference is introducing a locally run LLM.

If it runs locally and is openly available, then it doesn’t make much difference to me if it’s a traditional model or a LLM.

There’s also Chocolatey but I don’t know if that gets used anymore.

When I first installed N++, none of these were a thing yet though. It was just the MSI installer.

The author seems to be more interested in generating outrage than anything, but I think the point about AI still stands. From a UX standpoint, key points that may be incorrect are a terrible idea. That they originally intended to force AI on the user, at least from how it seems, is problematic.

The author’s privacy and accessibility concerns seem artifical to me.

The feature was introduced as a way for users to get relevant information faster, by providing them with an image, the webpage title, and AI-generated key points.

The AI part was made optional. That doesn’t mean they didn’t try.

Zen figured out link previews without using AI and the solution is really as simple as it gets. Maybe stop trying to manufacture problems for AI to solve?