aecsocket

Holy shit, Christopher Domas is back. I remember watching his Defcon talks on x86 shenanigans[^1][^2] and being amazed at what he's been able to discover. Then he got whisked away by Intel and now drops this. I'm excited.

[^1]: https://www.youtube.com/watch?v=XH0F9r0siTI

[^2]: https://www.youtube.com/watch?v=jmTwlEh8L7g

I'm excited for the new speakers - that's been one of the biggest pain points on my 13.

- Is the Dolby Atmos configuration available for Linux as well as Windows? Or more generally, will the speakers sound as good on Linux as they do on Windows?

- Will we be able to get audio comparison samples between the old and new speakers?

I don't really care about that, since my threat model doesn't involve Hetzner looking through my photos and training an AI model on them. If/when I move this off to my own hardware, then I'll do full disk encryption, since my threat model may involve someone stealing my hardware.

The cheapest possible Hetzner VPS (2 vCPU 40GB SSD) and a Hetzner storage box (1TB) works alright for cheap (less than EUR 10/mo). I store my database on the SSD, and the `/uploads` folder on the storage box attached as a CIFS drive. Put it behind Tailscale and it's worked fine for the past few months.

I didn't make this clear enough in the article, sorry for the mix-up! Yes, iPhones support Osaifu-Keitai, and it's Android phones which have this problem. I've now updated the article to clarify this.

This is an interesting find and the author's ideas make sense to me. I can't confirm them of course, this is all probably hidden behind legal documents, but I've updated the article to a link with this repo. Thanks for the link!

Author here, this is my fault for not proof reading this part properly! The part about non-Japan SKUs is generally true for Android phone manufacturers, but Apple eats the cost and gives all phones Osaifi-Keitai. You do not need to root an iPhone to get this functionality, even on a non-Japan unit.

I will write a correction for this section to clear up the confusion.

It depends. Usually you'd be right, but for some big events, the stations and platforms can be incredibly packed. In those cases the extra delay from gates could really hurt. One example is Comiket, where you have thousands of attendees all coming to the same few stations around the venue. Both times I was there, there was a massive crowd spanning from the platform to the outside. Having to wait the extra few hundred milliseconds on each card tap would have been painful.

Here's an example video to show the gates in action: https://www.youtube.com/watch?v=YffjxN3KsD4

The magnitude to which FeliCa was faster shocked me as well when I found out. But it's not like the latency is insignificant: it's obvious how much faster people can get through a Tokyo metro gate than a London one. So clearly it must have some kind of financial impact as well, if an entire city's public transport system works slower because of it. Even ignoring empathy for a second, isn't this the kind of thing that a Western capital ideology is supposed to improve? Some food for thought.

Yeah, I should have clarified that by "your desktop" I mean "your GNOME desktop" - i.e. "if you run GNOME, it'll look good no matter your preferences". But wrt "your desktop" - even if I wanted to, I couldn't guarantee that my app looks good on your desktop specifically, because I have no clue what your desktop looks like! Which is why I want to target a large common denominator of desktops instead, where I know it can look good.

The counter argument to that is "so let the user theme the app, to suit their own desktop", which would be a decent solution, but:

1. My vision for my app might conflict with your vision for your desktop. Maybe I want this button to be a light blue because it meshes well with some other elements in the app, but you want it to be a darker blue because it fits with your desktop's color scheme. What happens then?

2. This still doesn't guarantee that the app will look good. If you theme my app's home page, but don't theme the rest of the pages, then sure it'll look good at the home page - but as soon as you start using it, the look will fall apart. Or, what if I push an update to my app which adds a new page with a new kind of UI element? Do you really want to be maintaining your desktop theme for every single app you have?

3. This adds a burden on me as the developer to make parts customizable. This is the least convincing argument in this list IMO, since if there was better tooling and infrastructure for theming in GTK this wouldn't be a problem - but there isn't, so it is still a problem.

As a practical example, my app makes use of a WebViewGTK to display some info. I inject some custom CSS into this web view to make it look like Adwaita. This touches on points 2 and 3:

2. The webview has some UI widgets which aren't present in the rest of GTK, like a sticky header bar. You would have to manually maintain a stylesheet for this single element.

3. I now need to write a way to let users theme the custom CSS inside the webview, rather than just the CSS of the GTK widgets themselves. (I have already written this, but it's still a maintenance burden.)

Interesting, I didn't know there was a theming presence on OS X! I agree with you in that consistency and themability can exist together (and I suppose your example proves that), and that had GNOME decided to prioritize themability we could have had something like that on the Linux desktop. I suppose this is a question of priority and where to allocate effort, rather than what is technically possible and not. Building a UI framework and HIG is already not an easy task, and making it customizable in the way you describe would be an even bigger burden on developers - many of which are, I assume, doing this work for free. But admittedly I haven't looked much into GNOME's funding or organizational structure, so maybe they are capable of it, but just haven't bothered.

This opinion of "Gnome is killing customization" is something I see quite a lot, but which I think people take the wrong way. It's absolutely true that Gnome is designed to be less themeable than other DEs like KDE, or individual WMs - and by extension, GTK apps and apps designed to be used on Gnome are harder to customize/break more when you do theme them. But I disagree that "customization of Linux [being] half-dead" is a bad thing; on the contrary, I support the lack of theming options, and I like that there's someone on the Linux desktop that pushes this hard for consistency.

To make my biases clear: I'm a software developer that uses Gnome daily, and is developing a GTK/Adwaita app. I used to rice a lot back in the i3 days, but I don't particularly care about that nowadays, and stick to the defaults when I can. For my purposes, GNOME and Adwaita is perfect since it's very opinionated by default, and you can make good looking apps with minimal effort. Since all Adwaita apps are supposed to look similar and follow the same HIG, most of my desktop apps have the same look - but more importantly, the developers of the apps can also be confident that their apps look correct on my desktop. This is something that developers in the GTK space generally want, and for good reason[0].

One argument is that you as a user of the desktop should be able to have the final say on how your apps look, which is a totally valid take! And there are DEs, WMs, and apps which give you this freedom like Hyprland. But this doesn't guarantee that those apps will look good, or look consistent with each other, or even act consistently across apps. On the other hand, I as an app developer want to guarantee that my app looks good on your desktop, and the easiest way to achieve that is to target a single desktop environment, rather than an infinite combination of possibly-similar-but-maybe-completely-different desktops. Every preference has a cost[1][2], and when you take this philosophy beyond just preferences and expand it to color schemes, padding, margin, iconography, typography, it becomes unmanageable.

This isn't to say that GNOME is perfect, and I disagree with the project on some fundamental technical things like not supporting xdg-layer-shell[3], and refusing to accommodate server-side decorations for apps which don't want to render decorations themselves. (On the cultural side I can't comment, since I have no experience with that.) But in my opinion, this is the project that can deliver a usable and consistent Linux desktop to the average person the most effectively.

[0]: https://stopthemingmy.app/

[1]: https://blogs.gnome.org/tbernard/2021/07/13/community-power-...

[2]: https://ometer.com/preferences.html

[3]: https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/1141

Interesting app, I haven't heard of Manabi before! How does it compare to other apps like Jidousho? And other, more general desktop tools like Yomitan? On mobile, I'm currently using Yomitan on Firefox for mining, but I'm curious about other mobile-specific approaches and apps that people have made.

Rust already asserts that a match is exhaustive at compile time - if you don't include a branch for each option, it will fail to compile. This extends to integer range matching and string matching as well.

It's just that with #[non_exhaustive], you must specify a default branch (`_ => { .. }`), even if you've already explicitly matched on all the values. The idea being that you've written code which matches on all the values which exist right now, but the library author is free to add new variants without breaking your code - since it's now your responsibility as a user of the library to handle the default case.