Readit NewsDeleted Comment
Deleted Comment
> - Possibility to chainload from Linux while using Secure / Trusted boot: Dual-booting, although not supported on RHEL, is important for Fedora. While there are attempts to kexec any PE binary, our plan is to set BootNext and then reset, which will preserve the chain of trust that originates in firmware, while not interfering with other bootloaders.
It could be seen as an advantage to do chainloading by setting BootNext and resetting. I think Windows even does this now. However, it certainly is a different approach with more moving parts (e.g. the firmware has to not interfere or do anything stupid, harder than you'd hope) and it's definitely slower. It'd be ideal if both options were on the table (being able to `kexec` arbitrary UEFI PE binaries) but I can't imagine kexec'ing random UEFI binaries will ever be ideal. It took long enough to really feel like kexec'ing other Linux kernels was somewhat reliable.
[1]: https://fizuxchyk.wordpress.com/2024/06/13/nmbl-we-dont-need...
Why? What advantage is there for Windows to do this?
Deleted Comment
The decentralized internet, the blockchain, the darkweb and I2P all need someone to pay for hosting costs. If you don't get a corporation in your pocket early and fast, then you won't be able to scale your website reliably. It's a common constraint across most networked platforms.
Of course it would, for it already did. It might not be as polished, and there would be more issues with hardware, but it would certainly still exist, and even thrive. Because enough people want it and can put in the manpower to create it.
> but there's really no possibility a social media platform (or the internet at-large) could adopt a similar strategy.
By decentralizing it could.
> Hosting is expensive
Decentralizing would work around that.
> Blind authoritarianism is ironically one of it's strongest defenses.
The strongest defense is GPL, because if a company tried to do that then the same thing that happened with nginx would happen.
> The decentralized internet, the blockchain, the darkweb and I2P all need someone to pay for hosting costs.
With a properly designed protocol these costs would be neglibile.
I wrote a guide on this topic of ensure platform integrity of system level (See https://wmealing.github.io/tpm-pcr07.html ) its not too hard.
Yup. I was just referencing wanting to obtain keys from the TPM to decrypt a partition. This is useful for me to have the following setup:
- Laptop turned on, no keys pressed, boots into super locked down guest OS.
- Laptop turned on, certain key pressed within 2 seconds, boot into 'hidden' OS.
- In both cases, HDD is encrypted, decrypted automatically via retrieving keys stored in the TPM. This means the harddrive cannot be read outside of that particular laptop, unless keys are extracted from the TPM.
- Bootloader signed with own key, any and all existing keys wiped, so laptop cannot be booted with any external OS.
How would I recreate that setup with nmbl?
That's a good link by the way, thanks - saved.
I love that we have pretty powerful laptops with 20 hours of battery that only weigh a pound or so. I remember 20 years ago lugging around a 2kh brick with only 2 hours of battery.
The key point is remembering that copyright isn't some divine right stemming from the muses blessing the author with their own exclusively-owned words; it's a right societies fabricate because we believe it will incentivize people to build new knowledge that eventually benefits everyone. It's that incentivization that's the goal.
I do think UBI should be a minimum, and people should still receive compensation for work they produce that people enjoy. Just not exclusive rights and perpetual royalties and all this nonsense.
This is not an acceptable way to install anything on Linux. If you want to target Linux users you can't distribute with a shell script for installation.
I get that the idea is to reduce friction to installation and trying it out, but most Linux users - the ones you want filing bug reports anyway - are ones who will do due diligence and inspect the shell script to see what kind of opinions it makes about how to install the software.
For example, I see that the shell script downloads a tarball and unpacks it to `~/.local`, then tries to mess with my PATH variable.
Well, my local directory is `~/local`. So that's not where I want it. Actually, I would want it in `~/local/zed`, isolated from the rest of the installations in there. Then the PATH variable stuff just creates junk files since I don't use zsh. So I end up having to figure out the URL to the tarball and install it myself.
My point is that if you just listed the download link to the tarball, it would actually be closer to your own goal of reducing installation friction. The shell script is so much more friction because I have to read bash code instead of just clicking a download link.
You can just move it after. .local is different from local so there is no clash.