kokada

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".

[1] https://support.mozilla.org/en-US/kb/how-use-firefox-contain...

which violates the security model that Windows has and Linux needs to uphold to continue to get signed by Microsoft.

Oh ok, thanks for clarifying why this is a thing.

Not GP but hibernation is completely disabled for lockdown kernels[1]

The manpage that you linked says that unencrypted hibernation/suspend is disabled, but this seems a bad idea anyway if you're using FDE.

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.

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.

Not that Claude Code is much better, I just hit this issue[1] because it seems setting DO_NOT_TRACK=1 seems enough to get a really strange behavior in the newest versions of CC.

[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.

I think it is fair to encrypt the user hard drive since the majority of users are unaware that they're even leaking secrets and PII when e.g., they sell a laptop without wiping the disk first.

But I think it is also fair if the user was opening a CMD during install just to type `oobe /bypassnro` the user is advanced enough to understand the risks of not encrypting the hard drive (it is really easy to activate the BitLocker afterwards anyway, and for example in my case instead of storing the secret key in Microsoft I decided to store it in my password manager). So I really don't buy the excuses of this article.

Also WTH Microsoft, why it is so easy to reset the TPM key during e.g., a bios update and lose access to all your TPM keys (so you need to type your BitLocker key again). It should be a requirement from Microsoft laptops that the TPM contents are never lost unless the user explicitly asks for it.

Haha, yes. Track cyclists are a different breed.

Lost the opportunity to say "bread".

NVIDIA ended support for their 10xx series [1]. To be clear, AMD also moved support for their equivalent 5xxx series to legacy drivers [2], but "supports their cards for many years" doesn't hold value if both companies stopped their respective GPUs at basically the same time.

Also remember that one of those 2 companies has opensource drivers for Linux for their old GPUs, while the other doesn't (newer NVIDIA GPUs have an opensource driver but this isn't the case for the 10xx series). Users of legacy NVIDIA cards needs on Linux needs to use their old driver branches, with results that are less than optimal to say the least.

[1] https://videocardz.com/newz/nvidia-officially-ends-geforce-g...

[2] https://arstechnica.com/gadgets/2025/11/amd-says-that-its-no...

It's better that everything be a bit too big that requires tinkering than everything being way too small (where you can't read the text on the screen). The 2x scale is pretty usable for even 150PPI.

I think it depends. 2x in my 14' 1080p laptop makes text and UI elements so huge that I can barely interact with the screen, so it is unusable either way.

A 14 inch laptop with a 1080p display is already at close to 160PPI.

I have one of those, this kinda of screen is uncomfortable at 2x scale (everything gets too big), so I generally set up to 1.25x or 1.5x. This is not what is being set by default by Omarchy though.

A huge portion of the pc laptop market has high PPI displays and it's becoming increasingly rare to see anything that'd comfortably display at 1x scaling.

That is true, but you're moving the goal posts. This thread was talking about the 2x scale set by Omarchy by default, that is really only good if you have 200+ DPI.

This is still the minority of users even nowadays, and definitely not "98% of the user base" of the distro.

Why go through the ceremony of `public static void main(String[] args)` when Python just executes the script line by line at the top level? Oh wait, now you have things like `import` actually executing code instead of simply being a compile-time namespace convenience, and you need weird techniques like `if __name__ == "__main__"`.

I don't think this is a fair criticism. Python is a scripting language, it makes sense that the code is executed line by line at the top level. This is also how other programming languages from its time like Perl or Bash does it. Even newer scripting languages like Ruby does something similar.

Why `System.out.println()` when `print()` is so much more concise? But now you're polluting the global namespace, and `print(file=sys.stderr)` isn't that elegant either.

Another criticism that I don't think it is fair. Lots of other languages "polutes" the global namespace. I actually can't think another language other than Java that doesn't. Python at least still allow you to manually `import builtins`, but Go for example AFAIK has no mechanism for you to reference builtins if you end up shadowing them.

Also I find `print(file=sys.stderr)` pretty much elegant, it works exactly how I would expect, it also means I can open a file and write to it using `print`.

And so Python 3 enabled static type hints... which, like I said before, Java had from day zero.

Again, I don't think this is fair. I find Python 3 type-hints much more powerful than whatever type system Java has, especially because Python has Option types that actually make the type system useful (Java is infamous for its NullPointerException for a reason).

If they have a mac laptop or iMac they have a >200 PPI monitor.

Almost no-one is running Linux in a MacBook or iMac though.

Even Omarchy itself only supports Intel Macs: https://learn.omacom.io/2/the-omarchy-manual/97/mac-support. So the point is moot.

Would like to know where are you getting this information. I don't know a single person that has a >200PPI monitor, and most of them are Mac users and also programmers.

The author of the blog post makes valid criticisms, I remember when Ubuntu had a shortcut for Amazon in the default desktop installation because they had a sponsorship with Amazon and people rightfully criticized the distro for it. The author is doing the same for DHH promoting things like Grok/Hey/X. Also I am sure if any distro started shipping things like NordVPN in the default installation people would complain.

and _why_ does it have a conference, sponsors, and merchandise? especially when longstanding distros like Debian have struggled with funding and sponsorship for decades?

I agree with the author that this is the thing that mostly gets me about Omarchy: yes, it is fine for you to use Omarchy, but in the end this is just a collection of dotfiles from DHH. We should be investing this money in some other distro that is actually doing some actual work (like packaging programs, maintaining infrastructure, etc.), instead of a hobby project from a millionaire.

it seems pretty common for dynamically typed languages and pretty much entirely absent from statically typed ones

Counter-example is Go and init() function.

From this example:

    lazy from typing import Iterator

    def stream_events(...) -> Iterator[str]:
        while True:
            yield blocking_get_event(...)

    events = stream_events(...)

    for event in events:
        consume(event)

That is also my dream, iPads Pro are very expensive but the hardware is so good (that is including the Magic Keyboard).

BTW OP, have you ever tried a hybrid Chromebook tablet like Lenovo Duet 3? This is my favorite device for travel exactly because it is so good as a small Linux machine. Crostini fits the "I want to run a Linux VM". You can even use postmarketOS if you want an even more "traditional" Linux experience.

I wrote about it here :

- https://kokada.dev/blog/my-favorite-device-is-a-chromebook/

- https://kokada.dev/blog/my-favorite-device-is-a-chromebook-w...

Yes, this is why I am saying your idea of just reinventing the FS doesn't make sense. You don't get neither the wider ecosystem you get by having an OS compatible with e.g., POSIX semantics nor all the benefits you could get if you reinvent the whole OS.

But it is also rare cases where a a few percent points actually make a huge difference. Remember when reviewers are doing benchmarks they're generally using a standardised test suite with uncapped framerates. For most people they would be perfectly happy to hit a target framerate, or if they really want to play uncapped they would first reduce a few graphical setting to archive good performance (most of time with imperceptible changes in the graphics). It is rare when the performance of the game is so tight in a hardware that a few percent points actually matter.

To give a particular example, I started playing GTAV on Windows after building a new PC since I had no spare drives. After finally installing Linux I decided to try GTAV on Linux just to see how well it would run. And it runs amazingly well, and yes, it runs a few percent points slower than Windows, but the only tradeoff I did was slightly increase FSR4 and the game still looks amazing. I didn't really notice any graphics issues, especially not during actual gameplay (if I stayed at the same place and started to nitpick I could notice differences).

If we are going so far to only guarantee correctness if we are using a FS that implements ACID semantics, why not just reinvent the whole kernel and remove all footguns, including memory safety? We could have a OS that each syscall to memory allocation can only be done through safe API.

Otherwise, it doesn't really make sense. The only reason we have things like Rust and other memory safe languages is because we want to create safer programs in the existing imperfect OSes that we have currently.

Not sure how reliable this site is, but if it is correct it looks like 10: https://www.cvedetails.com/vulnerability-list/vendor_id-72/p....

Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).

I was using GNOME Console in a postmarketOS install in my Chromebook. The fact that it is lightweight compared to say Ghostty (my main terminal everywhere else) made a difference in performance for such a constraint device.

And I didn't really miss any features to be honest, it has the basic that you expect (things like tabs). It is less customizable than other options, but the defaults were good enough for me.

Wait, what? ptyxis is not the default GNOME termjnal. It is the terminal of choice for both Ubuntu and Fedora, but the default terminal in GNOME is Console, internally known as kgx: https://en.wikipedia.org/wiki/GNOME_Terminal.

but then, like, what do you actually want?

As an author of some homebrewed Go software in the past and trying to distribute in all 3 big OSes, I completely understand the blog post author's points. The problem is not Gatekeeper per see, it is just the combination of things that makes everything infuriating:

- I could justify going for the whole "Apple Developer Program" even with all the bullshit things you need to do to get certified if this was a one time payment like in Google Play Store. But it is yearly. Like the author, I would probably get 0 (or close to 0) dollars in recurrent revenue for those apps, I could justify a one time payment but a yearly one is ridiculous, it is not like Apple needs this money to be profitable (they probably get a much higher margins on selling things on Apple Store)

- Gatekeeper UX is infuriating. The equivalent on Windows (SmartScreen, as the author also cited) is still basically the same as Gatekeeper as far I understand (e.g., you need to have a valid certificate on your app or SmartScreen will deny the app execution until you clear the safety bit). But SmartScreen, different from Gatekeeper, has an actual good UX, as the error messages are clear and actionable (and also don't require a command line command to bypass)

- The author was still in a more "happy path" than me since their app seems to be a CLI only app. In this case just removing the quarantine bit with `xattr` works fine. In my case I was trying to distribute a desktop app, and I needed some special permissions to show notifications. This means I need to package my app in a proper `.app` bundle, include the required XML requesting the permissions and I am now required to sign the app. And since I am required to sign my app, I either pay the yearly payment fee to Apple to get a certificate to sign my app or I ask the users to resign the app with a self-signed certificate before launching

So really, I don't want that much actually. I can definitely handle all bullshit Apple wants, but I want at least a cheaper way to develop apps in their ecossystem. Maybe a new basic certification program that you have a one time fee and you can sign your apps but not notarize them. That way Gatekeeper would still complain, but at least my app would work without resign.

Or limit notarization to X amount of users (non-stabled notarized apps talks with Apple servers during the app first run, so they could just limit the amount of allowed tickets to X amount of users). If my app ever pass X amount of users, I will gladly pay the Apple tax, but 99USD/year for something that I will never see it back is too much.

Edit: BTW, I know, maybe 99USD/year doesn't seem too much for some. But Apple also doesn't do any regional pricing as far I know, and 99USD/year is crazy expensive in the country where I come from for example.

Edit 2: I am sure things are better nowadays with Claude/ChatGPT, but also trying to understand how to do the correct thing for your app is very difficult, especially if you're not using Xcode, since Apple assumes you're using it so all documentation refers to Xcode.

I think there is a very specific niche that this notebook is target for, and this definitely doesn't seem for you, the kind of person that having a cheaper laptop is more important than some of the unique features than this one or a Framework 13 Pro have.

For the unique part of this laptop that AFAIK a Dell XPS won't have is the Coreboot BIOS, that also probably means better support in the long term for BIOS updates.

To be clear, this is also not a laptop for me (but I did pre-order a Framework 13 Pro), but saying "nerd tax" or "anyone who buys one is either giving a donation or an idiot" like the other comment is just focusing in one part (the price) and not looking at the other.

The author sounds knowledgeable enough to me.

Nope, their complaint about having an API ask if you should delete or not clearly shows the author has no idea how API works. They could have said that a deletion API could require 2 different requests, one for the deletion request that returns a token and another for confirmation with the token returned by the first request, but this is not what they said so.

Also as others have said, this wouldn't have helped anyway because the AI could just call both APIs one after another and the result would be the same, especially if the first request returns "call this other endpoint with this token to confirm your deletion request".

Exactly, that just reinforces the fact that the author is just blaming others instead of getting any valuable insights about this "postmortem analysis".