kokada
Joined 12 years ago
Joined 12 years ago
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).
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?
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.
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).
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".
[1]: https://support.mozilla.org/en-US/kb/how-use-firefox-contain...
Oh ok, thanks for clarifying why this is a thing.
The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.
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.
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.
[1]: https://github.com/anthropics/claude-code/issues/69238#issue...
Edit: I think I misunderstood OP, they're saying that CC is even worse and not better than Codex CLI.