Same as me. I started subscribing LWN when I was a Linux enthusiast from my early college days, because the content was so good and interesting. Nowadays I barely read it but I still keep my subscription alive, just because I think the content is worth it.
> I had to swap my Wi-Fi card and/or stop using the HDMI module in order to get my Framework 13 to stop locking up.
This is really weird. Did you try to run the latest kernel?
I have nothing but praise for what Framework did with 13 Pro at least, it was the only Linux laptop that I ever had that everything really just works(TM). Even my ThinkPad that had really good support for Linux still had some weirdness that I need to patch manually (the microphone indicator led stays on even if the microphone was turned off).
It is funny that while I learned about Dev-C++ during my university course but it was mostly considered a joke by anyone that used Linux (including myself). I think the issue was because it shipped with a really old version of GCC even at the time, so something that compiled on it had lots of issues running in the more recent GCCs that Linux/Ubuntu used (including the teacher for this particular course).
Not related to the Microsoft gaming division, but yes, Microsoft products are a mess. I am forced to use Office 365 to do some slides for work, and I decided to use Office for macOS so I could use Claude extension.
All went relatively well, until I needed to share the slides with others using Office 365: my first try of sharing the slides by clicking the Share button inside Office for macOS caused it to upload to SharePoint as read-only: not even myself (the document owner) could edit it.
I said "fine, I will just upload the .pptx file manually", and it worked well enough, until the file came back with some comments for fixes: now if I clicked the "Open on desktop" button, it kinda created a local copy that I could never sync with the remote one, but they're still clearly the same file because it did show as the same file when I went to properties on both desktop and web versions.
At that point I was getting really pissed off, so I started editing locally and copying my changes to the remote version. Office still had one more surprise: I could copy whole slides remotely, but copying part of a slide (say a rectangle form with some text) would instead convert that part to an image. Seriously, what the f*ck Microsoft?
Technical debt, sure. But you could argue the same for any new feature added to a programming language, without having X you will need to workaround with Y, generating technical debt.
To be clear, I was one of those people that only started to use Go after generics. But for most of my projects, generics is less than 1% of the code base, so it is not like lack of generics was a huge issue. I think it is more of a problem for libraries in general.
> It would be great if we could have open ebook reader software that could display these books.
I agree, but it also would be great if DRM wouldn't be use to restrict your device choice. The only reason Kindle DRM "works well" is because Amazon is basically the biggest eBook store in the world and Kindle are the most popular brand. But you can't buy a book in Kindle and use it in a Kobo device, for example.
DRM would be slightly more acceptable if the companies themselves didn't use it to also enforce their device lock-in (e.g., license their DRM to other companies), and so we are in the current situation where there is device lock-in and you are required to buy a eReader from Amazon if you want to read Kindle books, or at minimum buy one of those Android eReader devices since you can install Kindle app on it (but in this case you have all the other issues that you get by running Android in a eReader).
> Digital book readers are getting smaller and smaller
I am not sure this is true. Yes, Xteink is investing in small eReader devices to fill a particular niche, but I am not sure any other company also creating small eReaders, and especially from the big known names like Kindle/Kobo/PocketBook the minimum size they generally have is around 6'' to 7''. Also nowadays we have a big market for Note-style eInk devices, like the Kindle Scrible or Remarkable that fills the niche of "I want a really big eInk device".
It seems so, especially because they explicitly say in the help page[1] that "Multi-Account Containers" brings "a few benefits on top of the native container functionality like site-specific container assignments, syncing across devices, and integration with Mozilla VPN or your own proxy".
While it is certainly an interesting bug, I kinda feel that the title is click bait? Because this `cryptsetup luksSuspend` from what I understood is not really officially supported but an extension done in Debian, so if anything this regression only affected Debian? I am not sure if you can blame the kernel for something that is not supported or even widely tested.
I still find this impressive, and it is nice that we now have a test (NixOSTests BTW are awesome, I agree with OP) to avoid this regression from coming back. But from the title it seems to be a widespread issue, not something that affects only one Distro.
Sorry, aimed for a technically precise title and didn't want to bait clicks.
Yes, this does not affect people on stock configurations for the plain reason that they wouldn't expect the volume key to be safe during suspend anyway.
Debian's solution was ported to several (most?) other distributions and I guess quite a few people maintained private ports.
The thread-keyring(7) manpage promises: "A thread keyring is destroyed when the thread that refers to it terminates." For their key upload (from userspace to kernelspace) mechanism, the cryptsetup project relied on this property; but kernel 6.9 introduced a regression invalidating this property.
Thanks for the explanation, I am really not that familiar with `cryptsetup luksSuspend` and it is the first time I ever heard it exists.
Like other people in this thread I first got confused "wait, how would this work since if you cleanup the keys from the disk during suspend you couldn't access the disk anymore after resuming", but after reading your thread in Mastodon plus other comments here it eventually became clear that this is a special case that you need both the correct patches plus the correct setup to use `cryptsetup luksSuspend` in place of the normal suspend.
Can I ask one question? Why not use hibernation at that point? The reason I generally suspend to RAM is exactly because my password is long and annoying to type enough that if I know I am going to use the device soon I prefer to suspend instead of hibernation. Yes, technically resuming from suspend is faster, but it is also less secure (there are other interesting things in memory besides the LUKS keys) and also it uses more power.
> Can I ask one question? Why not use hibernation at that point?
Not GP but hibernation is completely disabled for lockdown kernels[1], which is always enabled when booting under secure boot for kernels trusted by the Microsoft secure boot keys (it is considered a requirement to get you shim signed by rhboot[2] as it is believed that Microsoft considers it a hard requirement, as otherwise you could chain-load a patched version of Windows under secure boot).
This doesn't matter for custom kernels but most official distro kernels are built this way to be signed, as otherwise they won't Just Work (TM) on modern laptops. If you disable secure boot then hibernation works again, though I must admit I'm a little surprised how many people seem to disable secure boot.
To be fair the security argument for secure boot is weakened by the fact that everything is signed by the same set of trusted keys when using the default Microsoft trust root, but on paper it does protect against certain kinds of attacks. (In theory, distros could use UEFI setup mode to only trust their own keys but this causes issues with signed firmware and there have been cases of bricked devices.)
Even if you use full disk encryption, without secure boot someone can replace your kernel (or bootloader to inject a bad kernel) with one that is backdoored without you noticing. So someone only needs temporary access to your powered off laptop to gain access to your data once you use it again. I've had my devices taken away from me at airports and I know people who have had their laptops mysteriously missing screws when travelling overseas, so this is not an entirely hypothetical problem.
Of course, the fact that hibernation doesn't work on Linux is a negative from a practical security perspective, and so stuff like luksSuspend on suspend end up being quite important. And trusting the Microsoft keys is a little concerning if you're worried about state actors.
If you use TPM-backed keys with tools like systemd-pcrlock you can get some similar (and arguably nicer) protections but in practice nobody locks to enough PCRs to provide more protection than you would get if you also enabled secure boot.
The man page does say that but there is no mechanism to actually make use of that at the moment.
It's not enough for it to be encrypted, it needs to be encrypted with a single-purpose key that is not known by the user. Otherwise the user could replace the hibernation image with a malicious one and chain-load a backdoored version of Windows in secure boot mode, which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.
It is my understanding that there is work on generating a non-exportable single-purpose key using the TPM to make this work, but that's still a WIP.
> Can I ask one question? Why not use hibernation at that point?
The sibling post by cyphar gives a good reason; while UEFI Secure Boot has its own share of issues, it can be a valuable ingredient in defending against evil maid attacks.
But another reason is... convenience. Resuming from RAM is faster than resuming from disk, especially so if your "disk" is actually just a USB flash drive. I know that it might be a bit weird to ask for convenience when the motivation is security. But I argue that there are use cases where the tradeoff is sound.
With hibernation, all your data is safe but the inconvenience might seduce you not to use it.
With suspend to RAM and your distro's version of cryptsetup-suspend (and the kernel patch or alternatively the cryptsetup workaround), only your volume key (and hence the bulk of your data, potentially terabytes worth of sensitive information) is safe, but sensitive data in memory (recent files, recent chat messages, session cookies, ...) is not. But on the other hand it's quick.
Some people use a combination: suspend to RAM for short breaks, where they expect to remain physically able to fully switch off the laptop when something happens; and suspend to disk for longer breaks.
I'm confused why you're saying this is a Debian-specific thing -- luksSuspend is upstream and was added back in 2009[1] in release v1.1.0[2]. I've used it (though somewhat sparingly) on Arch and openSUSE in the past and it definitely exists on non-Debian distributions. Maybe you're thinking of the automatic integration with system suspend? If so, that's kind of besides the point -- luksSuspend documents itself as clearing the keys from system memory, which stopped happening in Linux 6.9 due to the referenced refactor patch.
Though it should be noted that it seems that this is actually a bug in cryptsetup in that it was depending on very specific lifetime behaviour of kernel keyring keys, when it arguably should've been more explicitly cleared by userspace[3].
I've used this feature on arch its available on bog standard luks but as far as I know it's not used by default when you suspend.
You are thinking of the machinery to actually actuate suspend to ram after a luks suspend in a way that is actually useful which was first a Debian targeted thing then arch and used by default by neither.
reply