but wouldn’t only the bootloader need to be signed

So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?

To my understanding a tamper-proof system already assumes full disk-encryption anyway

Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one:

1. I am a laptop owner who wants to prevent tampering with the software on my system by someone with physical access to my device
2. I am a server operator who wants to enforce usage of only signed drivers and kernels. This locks down modification/insertion of drivers and kernels as a method of obtaining a rootkit on my servers.

The second person does not use full disk encryption, or care about physical security at all, really (because they physically lock up the server racks).

What happens in this setup is that the bootloader checks the kernel's signature, and the kernel checks the driver's signature... and they enable this feature depending on whether or not the secure boot EFI motherboard variable is enabled. So this feature isn't actually tied to the motherboard's ability to verify the bootloader. For example, grub has it's own signature verification that can be enabled seperately.

The first person does not have malware in their system in their threat model. So they can enable full disk encryption, and then they don't care about the kernel and drivers being signed.

EXCEPT THEY ACTUALLY DO BECAUSE NOBODY DOES THE SETUP WHERE THE KERNELS AND DRIVERS ARE ENCRYPTED BY DEFAULT.

You must explicitly ask for this setup from the Linux distro installers (at least, all the one's I've used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.

What I do, is I have /boot/efi be the external EFI partiion. /boot/efi is where the bootloader is installed, and the kernels are stored in /boot, which is located on my encrypted BTRFS partition. The grub bootloader is the only unencrypted part of my system, like the setup you suggested. But I had to ask for this by changing the partitioning scheme on CachyOS, and on other distros I used before this one.

Very interestingly about this setup, is that grub cannot see the config it needs to boot. It guesses at which disk it should decrypt, and if I have a usb drive plugged in, it guesses wrong and my system won't boot.

Continuing, the problem with setups like this is that in order to verify the bootloader, you must have secure boot enabled. Grub will then read this EFI configuration, and attempt to verify the kernels and drivers. As far as I can tell, there is no way to disable this other than changing the source code or binary patching grub.

I have a blog post where I explored this: https://moonpiedumplings.github.io/playground/arch-secureboot/index.html

So this means that even in setups where everything is encrypted except grub, you still have to sign the kernels and drivers in order to have a bootable system (unless you patch grub).

I eventually decided that this wasn't worth it, and gave up on secure boot for now.

I think a browser extension, similar to tor snowflake would be a good way to do this.

There a source port of at least portal 1.

https://github.com/AruMoon/source-engine

Here's the active fork of the original project. Going through the issues of the original project, it seems to have support for building for 64 bit platforms.

No portal 2 support though. Although mentioned in the issues of nileusr's repo is this: https://github.com/EpicSentry/P2ASW , which is interesting

I use quarto: https://quarto.org/

The big thing I like is that it has fulltext local search, built in and easy to enable.

Search is possible on hugo, but it's not built in, you have to get a plugin, etc etc. Same for many other options you mentioned.

Heres my website: https://moonpiedumplings.github.io/

Big bluebutton is now integrated into Canvas, an open source learning management software (LMS) that every school I have went to has used.

Docker doesn't do this anymore. Their install script got moved to "only do this for testing".

Use a convenience script. Only recommended for testing and development environments.

Now, their install page recommends packages/repos first, and then a manual install of the binaries second.

Wish I could transcend into declarativity but the thread’s nix survivor ratio is grim

Yeah lol.

I will say, that for my server, I decided to use kubernetes + fluxcd for declaratively. My entire kubernetes "state" is declared in a git repo, and this is the popular, industry standard for things like this, called GitOps. It makes it very easy to add an app, since it's just adding a folder + some new config files. And unlike Nix, Kubernetes and Flux are very well documented with much tooling as well. Nix doesn't really have a working LSP or good code autocomplete, but with kubernetes, I can just start typing in a yaml file and then hit tab and it spits out the template for me. Code autocompletion with kubernetes feels much more similar to the tooling of other, more mature tooling

It's not as declarative as nix though. There are things missing, like OCI containers could theoretically shift if you don't rely on hashes and some other nitpicks. But declarativity is a spectrum, and I feel like, outside of scientific scenarios (think simulations where versioning, hardware, runtime etc being the same is very important), I think many non-nixos solutions are declarative enough.

What made it better?

I used to spend a ton of time helping people on reddit with linux and related things, and the "why" matters immensely in that case.

XY problem was extremely common, where someone was trying to achieve a goal through "incorrect" means.

I also saw many, many people's issues where they wanted something, but were referring to it by a different name, ending up confused and lost. All I had to do was say "you actually want Y" and point them on their way, and they would be happy.

And then of course, sometimes people try to do something that's simply not possible (or more usually, not implemented in software.).

But in general, it's very difficult to help people who don't make it easy for you to help them, and part of that is explaining the "why", in addition to their issue.

Can you elaborate on what you found lacking in kasm? Because afaik, kasm is one of the best solutions for this, giving you a full desktop session inside a docker container.

https://dontasktoask.com/

Definitely the clipboard manager. On kde, it's klipper. This is actually such an underrated piece of software that I can't live without. Windows has one too, but they added their's a little after all the linux desktop environments got one by default.