Arnavion

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.

You're right, I missed the article specifically mentions Meltdown in that sentence, not Spectre.

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.

Ah yes, in that case the relevant limit would be one on total handles, which doesn't seem to exist.

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

https://learn.microsoft.com/en-us/windows/win32/procthread/j...

https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns...

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.

[1] https://commiesubs.com/shingeki-no-kyojin-01/

No need for a new format, just use ASS itself! https://github.com/libass/JavascriptSubtitlesOctopus

The answers to negative questions are the other way around in Japanese compared to English.

"Are you not a student?"

In English, the non-student speaker would respond with "No", short for "No, I am not."

In Japanese, the non-student speaker would respond with "Yes", short for "Yes that's correct."

A literal translation would make this mistake.

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.

See also unanimated's typesetting guide: https://unanimated.github.io/ts/index.htm

CR rips (like SubsPlease, mentioned in the article) have jp audio and softsubs for en+signs, so I assume you can turn them off on CR's website too.

I don't see anything wrong or confusing in them.

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.

>the Merge Request that finalizes the initial work will be merged. Any new __edge__ installations will be /usr-merged from this point onwards.

>Release of Alpine Linux __3.23: [...] From this point onwards,__ users are encouraged to migrate existing installs.

And updating Alpine to a new release is already a manual action.

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.

As TFA says, currently the usr-merge and the script for it is only in Edge, and it will come to stable in 3.23

If I was sufficiently motivated to leave GH for such idealistic reasons, it wouldn't be worth moving to another third-party host. That just means a few years later there will be some new idealistic reason to leave the new host, and I'll have to make the effort of switching all over again. If I ever leave GH, it'll be to self-hosting.

Hold on. This wasn't a wrapper around a loop pattern - this was a first-class atomic operation, sitting right there next to fetch_add and fetch_or. Java doesn't have this. C++ doesn't have this. How could Rust just... have this?

C++26 (work-in-progress) does have std::atomic<T>::fetch_max . Not implemented in any toolchains yet, though.

https://en.cppreference.com/w/cpp/atomic/atomic/fetch_max

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p04...

I checked Godbolt, with RISC-V instead of ARM since I'm more familiar with that, and it doesn't look like it.

https://gcc.godbolt.org/z/b5s4WjnTG

(amomax is the atomic fetch-max instruction. lr and sc are load-reserved and store-conditional instructions; sc is like a regular store except it only succeeds if the address was not modified since the previous lr that accessed it. IOW the assembly is basically one-to-one with the C source.)

You can't build and application with the specialized thread-per core or single-threaded runtime thing if you wanted to because of pervasive incidental complexity. [...] It's frustrating and I go out of my way to avoid Tokio because of it.

At $dayjob we have built a large codebase (high-throughput message broker) using the thread-per-core model with tokio (ie one worker thread per CPU, pinned to that CPU, driving a single-threaded tokio Runtime) and have not had any problems. Much of our async code is !Send or !Sync (Rc, RefCell, etc) precisely because we want it to benefit from not needing to run under the default tokio multi-threaded runtime.

We don't use many external libs for async though, which is what seems to be the source of your problems. Mostly just tokio and futures-* crates.

Garbage collection generally refers to more complex systems that periodically identify and free unused objects in a less deterministic manner.

No, this is a subset of garbage collection called tracing garbage collection. "Garbage collection" absolutely includes refcounting.

Doing things based on exe filename is quite standard in Windows land. There's literally a registry key called "Image File Execution Options" where you can add a subkey with the name of the exe and then add values to control things like what interpreter to launch it under by default. Similar to Linux's binfmt registration, but based on filename rather than magic bytes. Very useful for attaching debuggers to specific subprocesses that you can't launch manually, as long as the process is named sufficiently uniquely.

https://techcommunity.microsoft.com/blog/askperf/two-minute-...

The ShowError() API they're talking about doesn't take a format string. It takes a resource ID which is an integer that's essentially an index in the resource table. So running the message compiler produces a C header that defines ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG to an integer constant, and then ShowError(ERROR_BITLOCKER_PASSPHRASE_MINIMUM_TOO_LONG) looks up the string at that index in the resource table and displays it.

https://learn.microsoft.com/en-us/windows/win32/eventlog/mes...

(You'll note that that page mentions that FormatMessage() does support printf-style format specifiers in the string resource. That's why I'm saying that their ShowError() specifically is the one that doesn't.)

(in fact, no device at all is reported as having a fully functioning camera, let alone everything else)

Nit: The Pine64 PinePhone's cameras at least have been fully functional since 2021. It's a very shitty pair of cameras, but they're definitely fully functional.

I know the wiki.postmarketos.org page for it says the camera support is "Partial" and that a bunch of drivers are out-of-tree. This and much of the rest of the page is extremely outdated, and I (maintainer) just haven't had the time to go through that page and fix it up.

Two days ago, in https://news.ycombinator.com/item?id=45240682

This one by the original author was submitted earlier but got no engagement, and is now back with falsified timestamps because of the "second chance pool".

getaddrinfo_a is available, but not widely adopted (*BSD and Linux), probably because you can't guarantee it'll be available on every computer/phone/modem. This is only an issue if you're targeting POSIX rather than modern operating systems.

To be precise, even on Linux getaddrinfo_a is not guaranteed to be present. It's a glibc extension. musl doesn't have it.