They're talking about Windows Bitlocker. It used to be able to use hardware encryption if the drive supported it, then there were sufficient vulnerabilities in implementations that it now always does software encryption.
I can't say anything about dual-booting Windows. I have heard that Windows Updates will frequently overwrite your custom EFI vars setup and reinstate the Windows bootloader etc.
Other than that, FDE and Secure Boot are unrelated.
The board's UEFI will boot the EFI binary that is either your kernel + initramfs (UKI binary), or a bootloader of your choice that then boots your kernel + initramfs. Depending on your distro, you may have a bootloader like grub or systemd-boot that is already signed by the MS third-party CA and your board may already allow the third-party CA, in which case you don't need to generate and sign with your own keys. Otherwise generate your own keys, set up Secure Boot with them, and then figure out how to sign your UKI binary / bootloader binary with those keys.
This initramfs will then be responsible for locating and mounting your root etc partitions. For a systemd distro using the UAPI Discoverable Partitions spec (use a specific type ID for the root partition), systemd has a builtin cryptsetup target that will prompt you on tty to enter the LUKS password for that partition. Otherwise investigate your distro's initramfs options for doing that.
>* Dual-boot where I choose in BIOS/UEFI to go to either the existing Win10 drive or new Linux drive.
grub and systemd-boot both show menus to select one of the available EFI binaries to chain to. Otherwise your UEFI might give you a similar menu.
>* I want to be able to take my drive out of a dead computer and access it elsewhere if something goes wrong, as opposed to needing to reformat and reload from backups.
Any other PC can mount and decrypt the drive with cryptsetup just like your original PC could, as long as you specify the same password.
>* If I install a distro with secure-boot off, can I turn it on later for benefits, or vice-versa?
Yes. You will launch board's UEFI, set the SB status to "Setup mode", boot your OS, then generate and enroll new keys which will set the SB to "User mode" and start enforcing signatures on next boot. And if it breaks you can set it back to "Setup mode" in board's UEFI, boot the OS and troubleshoot / re-enroll keys. The OS wouldn't care that you had previously enabled SB but are now booting with SB disabled.
Note that Secure Boot != Measured Boot. With a standard Measured Boot setup the disk encryption key is protected by secure element on the board (eg TPM) measuring the boot chain, so your disk will automatically decrypt when the boot chain matches the previous measurement and automatically fail to decrypt when it doesn't match. Your concerns about failing to decrypt the disk apply to this setup, not to SB. But also LUKS-encrypted partitions can have multiple keys to unlock them, so you can have both a Measured Boot-guarded encryption key and an emergency fallback password to unlock the disk manually.
The fetch stage of the pipeline will have needed to predict the branch N cycles before the execute stage of the pipeline actually gets around to evaluating it, in order to continue fetching the post-branch instructions. Without branch prediction the fetch stage would need to stall until that happens, which decreases throughput. The point of branch prediction and the subsequent speculative execution is to optimistically avoid that stall.
Speculative execution does not require out-of-order execution. When you predict a branch, you're speculatively executing the predicted branch. Whether you're doing it in the same order as instruction order or out of order is independent of that.
Yes, I run Waydroid (LineageOS in a Linux container) in an Ubuntu x86_64 VM on my home PC using their default installation method, plus libhoudini via https://github.com/casualsnek/waydroid_script to be able to run arm64-only apps, and waypipe the UI to my (Linux) phone that is connected to my home LAN via Wireguard.
I used to run Waydroid directly on the phone, but the phone has terrible specs and Waydroid had become frustrating in the last few months, when it updated its LineageOS image to a new Android version. It would frequently crash or pop up an infinite series of "app is not responding" dialog boxes, even though whatever app it was was responding just fine. With my new VM + waypipe setup, Waydroid launches in ~10s instead of ~3 minutes, and everything is reasonably snappy despite now traveling over the network, so I'm happy.
There are job objects which are similar to Linux cgroups, including the ability to set a limit on the number of processes. But I'm not sure if that limit will be tripped in this case or not because the child processes have exited, whereas the job object parameter is specifically called LIMIT_ACTIVE_PROCESS
Somewhat related is the situation with Shingeki no Kyojin / Attack on Titan. "Attack on Titan" was the manga author's chosen English title, except the story does not take place on the moon of Titan but is instead about giants attacking a human settlement. The Japanese title could be interpreted as "Attack of Titans" so everyone assumed "Attack on Titan" was just Engrish for that, and why CommieSubs' fan translation for example went with "The Eotena Onslaught". [1]
Years later it turned out some of the giants had classes / types and the title was a reference to the Attack type of giant. Thus the English title would've been better as "The Attack Titan", and indeed the Japanese title could also have been interpreted as that, though it's only obvious in hindsight. The Japanese title was likely deliberately intended to have the double-meaning "Attack of Titans" and "The Attack Titan", though this double-meaning cannot be conveyed in English, and in fact we're now stuck due to inertia with a third English rendering that is completely disconnected from either meaning.
>A character may say "I've missed you so much. It's been so long." The subtitles will read "Hey. Long time. " (both quotes would be Japanese)
This is standard in closed captions and is not specific to Japan. So perhaps the service you're talking about only has closed captions and is incorrectly marking them as subtitles.
On running the merge-usr script, the contents of /lib will be moved to /usr/lib, and /lib will become a symlink to /usr/lib. The same will happen with /bin (merged with /usr/bin) and /sbin (merged with /usr/sbin).
/usr/bin and /usr/sbin will remain separate directories as they are today (and as /bin and /sbin are today). Some other distros have also merged /usr/sbin into /usr/bin, but Alpine is not doing that for now, as it's still being discussed by the FHS.
They didn't understand the version numbers (notice they were complaining that the blog post jumped the gun because there is no merge-usr in 3.22) and wanted dates. I explained the version numbers to them. Yes, there are no dates; Alpine never gives expected dates for future releases because nobody knows what they are.
There's no need to interpret anything. It's spelled out in the list in the Timeline section already. Point 1 tells you it's in Edge. Point 2 tells you that stable will be able to start migrating with 3.23, ie when current Edge becomes stable.