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.
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.
The article is talking about OoO which is why I mentioned it. My point is that branch prediction and speculative execution are different things. You can do speculative execution without a branch predictor (run both branches and throw out the one that's wrong).
You're starting them in order and you're ending (retiring) them in order, but you're not necessarily ending one instruction before you're starting the next one. For instance, in a very simple pipeline, you can start decoding the next instruction before you've completed the previous one, so you can do some work in parallel.
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.
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
OpenProcess retrieves a handle to an existing process rather than creating a process so it won't be governed by JOB_OBJECT_LIMIT_ACTIVE_PROCESS, the bug here is that it's leaking handles, not processes.
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.
Most fans I saw called it by the Japanese title, Shingeki no Kyojin. You could almost tell whether someone watched the official licensed translation or not, based on what they called the series.
Actually, another quirk is the German lyric in the first season's opening theme. Crunchyroll doesn't usually translate opening or ending lyrics, but translating the lyrics was standard practice in the fansub era, so the. However, they misheard the lyric as "Sie sind das Essen und wir sind die Jäger" - "You are the food and we are the hunters" - as if the line is spoken by the Titans (perhaps the English-speaking audience is primed to the Germans being the bad guys in movies). The actual lyric was revealed in official Japanese sources as spoken from the perspective of the humans: "Seid ihr das Essen? Nein, wir sind die Jäger!" - "Are we the food? No, we are the hunters!" However, the incorrect lyric persists among fans because the second opening theme superceded the first before the error was widely noted in the English speaking anime community.
Source: I once said "So I guess you don't want to do the long-distance thing" to a native English speaker and she said "no" meaning she did, while I interpreted it the way you suggest and we (briefly) were not on the same page as to whether or not we were in a relationship.
My native Germanic language has a specific variant of 'yes' which is perfect for when both 'no' and 'yes' alone would be ambiguous. Not sure why not more languages have that.
Japanese 'hai' isn't really 'yes' though.. so it's used way differently than you would use just 'yes'. In colloquial speech it's more common uttering various sounds instead.
> My native Germanic language has a specific variant of 'yes' which is perfect for when both 'no' and 'yes' alone would be ambiguous. Not sure why not more languages have that.
French draws this distinction; ordinary 'yes' is oui; 'yes' contradicting a negative is si instead.
Mandarin gives you a variety of options for how to respond. You can use equivalents of 'yes' and 'no', but it's more common to echo the verb in the question.
你喜欢吃辣的吗？("Do you like eating spicy food?")
不喜欢 ("[I] don't like [it].")
Here we have no need to worry about whether the question was positive or negative; if I like the food I'll say 喜欢 and if I don't I'll say 不喜欢.
It's also possible to say 对 "correct", in which case it does matter how the question was phrased.
The specific question here, 你不是学生吗 "Are you not a student?", might be a little odder than usual because the verb 是 is also what's used for a simple "yes". But for "No, I'm not" 不是 is unambiguous, and I have a vague gut feeling that 是啊 would probably be taken as "Yes, I am". And of course you have the option of continuing your response ("yes, I'm a student, I've been enrolled here for two years") if you feel the short answer was too cryptic.
>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.
