Because, for sure, some of the real bangers of comments I've posted on HN and similar forums—all my XCompose-configuration aside—have gotten relatively few upvotes!

Same thing with conference talks. The ones with half a million or a million views on YouTube… the real magical ones, I think, are the ones no one seemed to pay any attention to… e.g., https://www.youtube.com/@PyDataTV/search?query=james%20powel...

Because many good ideas are not immediately obvious good ideas, in an environment at risk of information overload, we need some way to quickly vet ideas to see whether they are worth investing the time to consider them. (It is often the case that the best ideas require considerable investment of time and effort to be judged as good, and, it's also often the case that this determination can be made only at the very end of such a process.)

“Don't judge a book by its cover,” sure, but, historically, there have been superficial markers of care and attention that we've used to these ends. These are obviously very flawed signals, but, you know, maybe if you took a lot of time to craft a message, I don't feel that bad if I waste a bunch of time trying to decode it. These markers—attention to detail (e.g., spell and grammar checking,) clear-structure (e.g., “bottom line up front,”) and typographical flourishes (e.g., smart quotes and em-dashes and extended unicode like diæreses…)—were an indication of some modicum of quality control and care. I, myself, used to brag about or show-off having set up .Xcompose keybindings (https://wiki.archlinux.org/title/Xorg/Keyboard_configuration...) which was just rare enough across the general population to be noteworthy.

All of this that was once somewhat expensive is now cheap or basically free.

Even if I make a point of going back to a pre-UTF-8 Usenet style (or even intentionally insert run-on sentences or misspellings or grammatical errors,) the cost of an LLM to style-transfer its output to match this is barely much of anything. All it means is I wrote one prompt for the first draft, and then one more prompt for the refinement.

Additionally, some LLM habits are actually good habits. Putting the bottom-line up front (in bold, even!) is a great habit in a business e-mail! Decision-makers genuinely struggle with reading through long paragraphs of detail!

Unfortunately, the problem with the LLM output is that it takes good, valuable, superficial or structural habits that it can cheaply apply, and it drapes those around inane, banal, cloying, muddy, meandering meaninglessness.

Today, we can maybe still judge a book by its cover, because even one more prompt worth of refinement is still too much effort, but I don't think that's amounts to much, since the frequency and loudness of complaints of LLM writing means that model trainers are going to train their models to adapt to whatever signals we use for quick vetting. I am skeptical whether this training will concurrently improve the novelty, innovativeness, or other intangible qualities of the actual message. (With the models, as they exist today, and as we use them today, at least in the field of software development, I see extremely poor capability at generating innovation… Personally, I don't even like the quality of the Python code they spit out, but they sure do type real fast, and, like, pejoratives aside, unexciting, mediocre, corporate-y code does have a real place in the world.)

So what happens when the economics of production in the medium significantly outpace the capabilities of production in the message? The LLM can write a comment nearly indistinguishable from any given human… except when you actually take the time to read through it, it's just inane drivel. Thoughtless and a waste-of-time. And there's basically no way to manage your investment of time and effort to tell one way or the other.

If I remember correctly, we would have one pointed deducted for every instance we failed to eliminate.

I suspect this would be nearly trivial to get train (or get an existing model) to do, but, like writing in cursive, one could argue that these activities (as absurd as they may seem…) genuinely and positively contribute to a child's growth and development.

(In fact, I'm actually slowly reteaching myself a proper cursive…)

In fact, input methods like this not only exist—https://en.wikipedia.org/wiki/Cangjie_input_method—but are in more common use than you might expect! I've met more than one (regular-person, non-technical) office worker who could barely hunt & peck on a coworker's Chewing but could fly with Cangjie. e.g., https://youtu.be/sVAQSBU5OOo?t=98

Coïncidentally (or not,) they also had very high written character recall and speed… (a skill that is notably very weak among syllabic-IME users…)

The authoritative answer for this question would best come from the millions (or tens of millions) of Chinese-speakers who are currently using LLMs to write software.

However, it is my suspicion that you would see no advantages using any language other than English. While there is a certain token-level density to written texts, it seems the benefits of this (and the more recent discussion around “caveman talk”) are quite limited.

Furthermore, consider that the vast majority of textbooks, technical documentation, blog posts, StackOverflow answers, &c. are originally in English. Historically, where these have been translated to Chinese, the translations have often been of very poor quality (and the terminology and phraseology is often incomprehensible unless you also understand some English.) I would suspect that this makes up the overwhelming majority of the training sets for these models.

That said, my experience using the most recent models, is that they are surprisingly language-agnostic in a way that surpasses readily-available human capability. For example, I can prompt the LLM to translate English into something that uses German grammar, Chinese vocabulary, and Japanese characters, and I'll get an output that is worse than what a human expert could do… but where am I going to find a multilingual expert?

(Of course, I have so far only ever been impressed that a model could generate an output but never impressed with the output it did generate. Everything—translations, prose, code—seems universally sloppy and bland and muddy.)

So what I would anticipate the biggest benefit for a Chinese-speaker today… is that if they are disinterested in working internationally, they have significantly less dependency on learning English.

But, to borrow a line from Warren VanderBurgh's ‘Children of the Magenta’: “(in the industry) we created you like this.”

Another key flaw of precomposed automations for rigidly-defined work-flows is that they usually exist in precisely the circumstances that give rise to their own subversion. (I might even go so far as to suggest that the circumstances are the cause of both the mistake and the maladaptive behaviours that address the mistake…)

Ultimately, deep stacks of tightly-integrated components forming a precomposed automation that enacts some work-flow—“vertical integration” as the post frames it—is obvious enough that it seems every big company tries it… only to fail in basically the same ways every time.

This kind of rigid, singular view of operational workflows based on precomposed automations not only constantly break but also inevitably introduce huge inefficiences.

I posted a longer comment on lobste.rs: https://lobste.rs/s/azpsqe/vertical_integration_is_only_thin...

Yes, the CPython `PyDictObject` has been subject to a lot of optimisation work, and it is both high-quality and high-performance. I should not have implied that this is not the case.

However, there's a lot of ongoing research into even further improving the performance of hash tables, and there are regular posts discussing the nature of these kinds of improvements: e.g., https://news.ycombinator.com/item?id=17176713

I have colleagues who have wanted to improve the performance of their use of `dict` (within the parts of their code that are firmly within the structural/Python domain,) who have wanted to integrate these alternate implementations. For the most part, these implementations do not guarantee “human ordering” so this means that they can provide these tools only as supplements (and not replacements) of the Python built-in `dict`.

> moving your data into an environment that lets you make more assumptions and be more restrictive with your data and operate on it there. It's how numpy, polaris, and pandas work.

Yes, the idea of a heterogeneous topology of Python code, wherein “programme structuring” is done in pure Python, and “computation” is done in aggregate types that lower to C/C++/Rust/Zig (thus eliminating dynamic dispatch, ensuring contiguity, &c.) is common in Python. As you note, this is the pattern that we see with NumPy, Polars, pandas, and other tools. We might put a name to this pattern: the idea of a “restricted computation domain.” (I believe I introduced this terminology into wide-use within the Python community.)

However, not all code shows such a stark division between work that can be done at high-generality (and, correspondingly, low-performance) in pure Python and work that can be done at low-generality (but very high-performance) within a “restricted computation domain.) There are many types of problems wherein the line between these are blurred, and it is in this region where improvements to the performance of pure Python code may be desired.

In fact, we see this with CPython `set`, controlled by `_Py_HashSecret`:

https://github.com/python/cpython/blob/6eb6c5dbfb528bd07d77b...

https://github.com/python/cpython/blob/6eb6c5dbfb528bd07d77b...

https://github.com/python/cpython/blob/6eb6c5dbfb528bd07d77b...

https://github.com/python/cpython/blob/6eb6c5dbfb528bd07d77b...

All of the Python builtin data structures are ordered.

The distinction we should make is not between ordered and unordered data structures. Instead, we should distinguish between human ordered and machine ordered data structures.

In the former, the data structure maintains an ordering that a human being can used as part of their understanding of the programme. A `list` is human-ordered (and its order typically connotes “processing” order,) a `tuple` is human-ordered (and its order typically connotes “semantic” ordering, which is why `sorted(…)` and `reversed(…)` is rarely a meaningful operation,) a `str` is human-ordered, and `int` is ordered (if we consider `int` in Python to be a container type, despite our inability to easily iterate over its contents. Whether or not `complex` is a container or not, is pushing this idea a bit too far, in part because I don't think anyone really uses `complex`, since NumPy dtype='complex128' is likely to be far more useful in circumstances where we're working within .)

In the latter, the data structure maintains an ordering that a human being cannot use as part of their understanding of a programme (usually as a consequence of a mechanism that the machine uses as part of its execution of the programme.) A `set` is machine-ordered, not unordered. If we iterate over a `set` multiple times in a row, we see the same ordering (even though we cannot predict this ordering.) In fact, the ordering of a `set` is intentionally made difficult for a human being to predict or use, by means of hash “salting”/seeding (that can only be controlled externally via, e.g., the https://docs.python.org/3.3/using/cmdline.html#envvar-PYTHON... `PYTHONHASHSEED` environment variable.)

Historically, the Python `dict` was machine ordered. If we looped over a `dict` multiple times in a row (without changes made in between,) we were guaranteed a consistent ordering. In fact, for `dict`, the guarantee of consistency in this ordering was actually useful: we were guaranteed that `[d]` and `[d.values()]` on a `dict` (with no intervening changes) would maintain the same correspondence order (thus `[zip(d, d.values())]` would match exactly to `[d.items()]`!)

When the split-table optimisation was added to Python, the Python `dict` became a very interesting structure. Note that, from a semantic perspective, there are actually two distinct uses of `dict` that we see in use: as a “structural” or as “data” entity. (Ordering is largely meaningless for the former, so we'll ignore it for this discussion.) When the split-table optimisation was added in Python, the underlying storage for the `dict` became two separate C-level blocks of contiguous memory, one of which was machine-ordered (in hash-subject-to-seeding-and-probing/perturbation order) and one of which was human-ordered (in insertion order.) (From this perspective, we could argue that a `dict` is both human and machine-ordered, though it stands to reason that the only useful artefact we see of the latter is with `__eq__` behaviour, which this article discusses. Since “human ordering” is a guarantee, it supersedes “machine ordering.”)

However, the ship has already sailed here. I think that once insertion-ordering became the standard, this creates a guarantee that we can't easily back down from.

Of course, this video is just stupid accent comedy, but we should be careful not to draw too much from it. (Let's also set aside the specifics of making fried rice.) The implication of the section of the clip you linked is that the presenter (Hersha Patel) does not know how to make rice properly, and this is evidenced by her cooking it in too much water and draining it.

But this is not correct.

There are, in fact, many different varieties of rice, different cuisines that incorporate rice as a major component, and different styles of cooking rice. Cooking (certain varieties of long-grained? rice) in an open vessel, cooking with an excess of water, and draining the water afterwards is an extremely common and popular way to prepare it for use in some cuisines: e.g., https://youtu.be/TARO_R4cE24?t=420

When this video first made the rounds some years ago, it was surprising to see how confidently people would weigh-in on this topic, despite demonstrating very little background or knowledge. (There's a big difference between saying “that's not the appropriate way to do this in this circumstance” and “that's completely wrong,” and the former creates space to derive knowledge. After all, the dish in the video is a popular one, even in cultures that predominantly eat jasmine or basmati rice, and there are interesting variations in technique and flavour that arise as a consequence!)

> Mexican moms react to Rachael Ray trying to cook (https://www.youtube.com/watch?v=zFN2g1FBgVA)

I similarly do not understand why these kind of reaction videos are popular. There are slightly better versions of this format (e.g., https://youtu.be/DsyfYJ5Ou3g?t=182) but they are drowned out by this kind of fluff. What does one really gain from interacting with such criticism?

Perhaps there is something to be learnt from these situations: ones where, equipped with just a little bit of knowledge, we derive unearned confidence, and use this confidence not to venture forth more boldly in search of knowledge, but to convince ourselves of our own superiority.

(I'm trying to start with a positive tone, since I have only negative things to say about the site itself. I want to make sure that I'm coming across a critical without coming across as mean.)

I spent a few minutes generating a couple of sample stories using their prompts for the pair that I'm most qualified to evaluate “English”→“Chinese (Traditional)” and just wasn't very impressed. Honestly, I think the approach is largely a dead-end.

Let's set aside that “Chinese (Traditional)” is not a language, and that someone with experience learning or teaching Chinese ought to know this (and, as I will argue, knowing this is critical to producing high-quality educational materials!) That the creators of this tool aren't particularly familiar with the languages themselves is probably much less consequential than that they don't really appear to be familiar with the pedagogy of teaching or learning languages.

One would anticipate that the languages that most learners want to learn are subject to broad market forces, and that, as a consequence, these languages already have a variety of high-quality, human-written primary texts and educational texts (many of which may even be free-to-access!) For the language pair I tested, this is definitely true, and I would encourage every learner to start with those materials (and to avoid anything AI-generated.)

(Of course, if I wanted to learn a less-common language where materials are hard to find this might be marginally useful—e.g., Telugu probably has more total speakers than Italian, but my local high school probably has an Italian class—but I would wonder whether the training set would be good enough to accurately reproduce the language. I suppose if I wanted to learn an endangered language, where they may simply not be enough native speakers to maintain a rich catalogue of written language, then someone could train an AI to reproduce this language to aid in learning, but a similar question arises as to whether this kind of preservation or reconstruction is sufficiently “faithful.”)

It's absolutely the case that AI tools are at a point where (for common languages) they are able to reliably generate grammatically accurate language, independent of its factual accuracy. Indeed, while I could spot fluency issues in the sample stories I reviewed (since, of course, “Chinese (Traditional)” is not a language,) I could not spot outright grammatical errors. (This is an impressive accomplishment for AI models!)

But this is really a solution looking for a problem (and, in my opinion, finding the most obvious but also least useful.)

Contrast these randomly generated story with the equivalent from a human-generated educational resource. In the case of a human-generated educational resource, the quality of language may actually be worse than than that in the AI generated resource (even in the face of sloppy AI writing tends to be!) In fact, in the case of Chinese (“Traditional” or otherwise,) this is absolutely guaranteed to be the case for an introductory text. Almost all introductory texts will be written in a very choppy, repetitive style: e.g., 「那隻狗很可愛。我養的狗也很可愛。」

(It's likely the case that even intermediate and advanced learning materials will not resemble actual primary texts. e.g., I was reading the news the other day and came across the sentence 「北捷重申，無論任何年齡，各車站閘門前的黃色標線內一律禁止喝水等飲食行為，除非是身體不適或母乳哺育」 which is perfectly appropriate for an intermediate learner… except 「閘門」 is simply not useful or appropriate textbook vocabulary!)

So why is the human-generated educational material better? Well, there's a lot of design to writing these kinds of materials. How do we teach and reïterate the most broadly useful grammatical structures and vocabulary? How do we teach this in a way that maximises retention? (And, often, how do we expose the learner to useful cultural background that will help them when they visit a region where the language is spoken?)

All of this is visible in human-generated materials, yet none of this is evident in these AI-generated materials. It is, in fact, this design that makes these materials useful in the first place. In the absence of it, we end up with vocabulary lists that define 「狗：dog」 next to 「呈現：to emerge」 where a human educator would align the difficulty of these terms to the order and process in which a human learner would learn them. Similarly, a human educator knows how to evolve a student's fluency with language and understanding of tone and register, taking them from 「媽媽: mother」 to 「母親: mother」 perhaps even strategically including 「媽咪: mommy」 or even 「阿母 a-bú: mother （台）」 to engage the student. (Real educators do this very often, and students tend to really like it when they get “fun fact”-style local flavour!) I have not seen anyone attempt to introduce any of this design into AI-generated learning materials, and I suspect this is why they always come across as being so bland and mushy. Instead, the AI-generated materials are creating only rote practice items (which is why their prompts typically include things like “limit the generated text to use only vocabulary as published in the prep materials for such-and-such language proficiency exam.”) This kind of practice is, indeed, useful, but it's debatable whether it's measurably more useful than just spaced-repetition with flashcards.

Now, contrast these materials with primary texts (i.e., written language artefacts produced for an audience of native speakers.) Primary texts are often very difficult to incorporate into language learning, especially for languages like Chinese. This is probably because at the introductory level, the materials simply aren't dense enough for an adult learner, and at the advanced level, probably because these materials are far too challenging given the amount of specialised terminology and vocabulary used. (There are, in fact, very appropriate materials that sit between these extremes, such as news magazines or short stories written for middle schoolers, but these materials can be hard to access.)

The benefit of the primary text is that it is very close to the actual goal of the learner: I really don't want to read a story about a lost dog, and I only do it, because with enough practice reading such drivel, I might eventually read ‘Dream of the Red Mansion’ or ‘Red Sorghum.’ As a consequence, what most learners will reach for are “graded readers” which are adaptations of well-known works with simplified language and grammar. I'm on the fence with how well AI can create these for us. On the one hand, there is a pedagogical and creative dimension to producing a good graded reader. The former may be possible to approximate with additional prompting (“use only vocabulary from this list; use only grammatical structures familiar to a learner at this tested level,”) but I'm not sure about the latter. The reader is probably losing a lot when we simplify Gandalf to ‘Run away now!’

So while I'm quite hopeful that AI technologies can improve language learning, this kind of tool just doesn't seem to add anything to what already exists and is already much better.

The approach is just too obvious. I think it's too focused on finding a way to adapt something we know that AI can do well (generate grammatically correct text) to something we want to be able to do more cheaply or effectively (teach language learners how to read) without really considering how to solve this problem.

I have first-hand experience across five distinct AMD 7840U and AMD 8840U devices that near-perfect, out-of-the-box Linux-support (with stock kernels and no dodgy kernel flags!) is possible. This includes support for S0ix suspend.

https://news.ycombinator.com/item?id=43083669

I don't doubt it when people recount their bad experiences with AMD devices; however, my experience should serve as an existence proof that it's not a universal experience.

In the case of each device mentioned in the comment above, I followed a standard installation procedure from an Arch installer USB. I use only stock kernels: linux, linux-lts, and linux-zen. For almost all of the devices, the only kernel flags I pass are for enabling hibernate or handling FDE. (In one or two cases, the devices have portrait displays that have been installed for use in landscape-orientation. These need an `fbcon=rotate:…` kernel flag.)

In all but one case (the OneXPlayer X1 Ryzen) everything (except fingerprint readers) works flawlessly. In the case of the OneXPlayer X1 Ryzen, there is an intermittent issue with hang on suspend, but that may have gone away with a recent kernel update. If not, I'll probably come back to this blog post and see what I can do…

A lot of workarounds that are suggested for various issues are also not really viable. Some of the workarounds involve turning off different power-saving modes; however, the point of enabling sleep is often to increase the amount of usable time between charges, and turning off these power-saving modes can often dramatically shorten battery life.

But getting sleep to work (even S0ix!) is not impossible.

I have a bunch of handheld AMD 7840U and AMD 8840U devices that I have installed Arch Linux on: GPD Win Max 2, GPD Win Mini, GPD Win 4, Minisforum V3, OneXPlayer X1 Ryzen. These devices were not designed with Linux support in mind. I would be very surprised if the companies that made them ever tested them with Linux. Yet with just a small amount of work (generally fiddling with `/proc/acpi/wakeup` and `/sys/devices/*/*/*/power/wakeup` to disable sources of spurious wakeups,) I have gotten essentially flawless S0ix support (… on all but the newest OneXPlayer X1 Ryzen.)

(In general, out-of-the-box stock Linux kernel support on these devices is fantastic. Touchscreens work, pen input works, wifi and Bluetooth work well. The only gap I've seen is fingerprint reader support.)

I suspect that given how small these manufacturers are (and how small their production batches must be,) there's much less extreme-customization and tight-integration of components. This is visibly evident in the form-factors of these devices, which many millimeters thicker than they might otherwise be. (Of course, these devices are primarily advertised to a gaming audience who are eager to avoid the thermal-throttling that happens with ultra-thin devices like Surface Pro…) I partially suspect that the lack of extreme-customization, the lack of tight-integration, and the smaller production batches means that the manufacturers make much more conservative choices in components. Maybe this explains the exceptional Linux support?

Whatever your own position on this matter may be, it is important that we factually describe the positions of the parties directly involved.

Hopefully we can use this as an opportunity to spread a more accurate description of the dynamics at play.

For reference, here is a speech by William 賴清德 (https://en.wikipedia.org/wiki/Lai_Ching-te) outlining the position under which he operates. The phrasing he uses is one that is consistent across all of his public remarks; consistent with remarks by Louise 蕭美琴(https://en.wikipedia.org/wiki/Hsiao_Bi-khim) and other close associates of William 賴清德; consistent with remarks made by 蔡英文 (https://en.wikipedia.org/wiki/Tsai_Ing-wen); and consistent with how the structures in Taiwan have operated over at least the last decade.

《賴清德就職演說：兩岸「互不隸屬」》: https://youtu.be/oLO5bYF8lDs?t=139

The relevant remark is: 「由此可見，中華民國與中華人民共和國『戶不隸屬』」

Here is my (manual) translation: “From this it can be seen that the Republic of China and the People's Republic of China are ‘not subordinate to each other.’”

Here is a Whisper-generated transcript of the entire speech, with an OpenAI generated translation inline. I skimmed the translation, and it adequately conveys the speaker's meaning and intention. (It does fail to convey the delicacy, careful phrasing, and specific rhetorical choices made by the speaker that are extremely clearly visible in the Chinese. However, this aspects are harder to convey if you don't have minimal prior knowledge on this topic.) https://pastebin.com/fGxHUpXN

It is true that there are historical positions, (historical) on-paper claims, and even a variety of differing positions and lively debate on this issue across all of the populations involved. But the conclusion one might draw from the comment above is wholly incorrect. It simply isn't the framing within which William 賴清德 and associated parties are actually navigating this issue.

    bwrap --dev-bind / / --clearenv --tmpfs ~ --unshare-pid --as-pid-1 --die-with-parent ssh terminal.shop

Unfortunately, the API design in the example is just not very good:

    (
       GT(simple_table, rowname_col='Name')
      .tab_header(title='Names, Addresses, and Characteristics of Remote Correspondents')
      .tab_stubhead(label=md('*Name*'))
      ...
    )

Of course, for ad hoc, in-a-notebook, cut-and-paste/written-from-scratch use, the API design doesn't really matter that match. Usually, users will readily memorise the required incantations then fiddle with the result until they get what they want or they give up.

It's probably the case that for most tools that produce visual outputs, a majority of users are creating things in this style. (There are, e.g., millions of casual Matplotlib users out there.) But programmatic use is not too far off. Tools that produce visual outputs (even those as formally rigidly at display tables,) are often subject to consistency requirements, which directly implies programmatic use.

So, when I discover that my colleagues and I have six tables across three notebooks that need a consistent look, and I decide to interact with this tool programmatically, am I expected to write…?

    def standard_table(source, /, rowname_col, header_title, stubhead_label, weight_columns):
      return (
        GT(source, rowname_col=rowname_col)
        .tab_header(title=header_title)
        .tab_stubhead(label=md(f"*{stubhead_label}*"))
        .fmt_integer(columns=weight_columns, pattern="{x} lbs")
        ...
      )

    standard_table(simple_table, rowname_col='Name', header_title='Names, Addresses, and Characteristics of Remote Correspondents', stubhead_label='Name', weight_columns='Weight')

    def format_table(weight_columns):
      return (
        tbl
        .tab_stubhead(label=md(f"*{tbl.stubhead.label}*")) # what if not present?
        .fmt_integer(columns=weight_columns, pattern="{x} lbs")
        ...
      )

    format_table(
      GT(simple_table, rowname_col='Name')
      .tab_header(title='Names, Addresses, and Characteristics of Remote Correspondents')
      .tab_stubhead(label='Name')
      ...
    )

     class StandardTable(GT):
       def tab_stubhead(self, *a, **kw):
         # inspect.signature.bind(...) # ...
         return super().tab_stubhead(*a, **kw)

    StandardTable(...)

My assumption prior to purchasing these devices was that AMD support would be the main reason for me returning them.

I was quite surprised to see just how well everything worked, and, in fact, these devices have given me much less trouble than my i7-1165G7 Dell XPS 13".

In fact, these devices has worked so well that it's really made me more excited about consumer technology and new laptops and portables than I have been in a long time!

I am worried that I may be mistakenly generalising this to all AMD devices. I have even been considering ditching Intel for my next laptop upgrade…

I installed Archlinux on both and the support has been very solid with the `linux-lts` kernel and only one kernel flag (`amd_pstate=guided`.)

The following work: touchscreen; suspend (s2idle, which correctly enters S0ix state giving ≥100h battery life suspended but requiring I disable entries in `/proc/acpi/wakeup`); audio; media keys; game controls; wifi; Bluetooth; USB; SecureBoot (with `systemd-boot`); webcam (available only on Win Max 2.) The TPM2 works, but I haven't done anything with it yet (and it's an fTPM.)

Battery life is quite good (8~10h with the `acpi-cpufreq` `powersave` governor.) If I dial down the TDP, I can eke out even more battery life than that. If I dial it up to performance, I get 1~2h of battery life (and the exhaust from the fan port runs very hot.) I plan to try the `amd_pstate` governor (kernel flag `amd_pstate=active`) once support is available in the LTS kernel, though I like being able to control TDP via the CLI with AUR packages like `ryzenadj-git`. (This sounds like a lot of work, but I have a short shell script where I dialed in the right `cpupower` and `ryzenadj-git` commands optimal for my use.)

Hibernate works perfectly on the Win 4; I haven't tested it on the Win Max 2 (since s2idle works so well!)

On the Win 4, I can't get `xrandr` modes at anything other than native resolution (1920×1080) to work, but I am content with scaling via `xrandr --scale-from`. All resolutions display properly on the Win Max 2. Rotation works perfectly on both devices, but I rotate manually (and I haven't bothered to see if there is a gyroscope sensor.) There is minimal to no screen tearing. The displays present to the OS as landscape (i.e., rotation is not necessary from the Linux console.)

The only hardware that outright doesn't work are the fingerprint readers (but I believe Linux support for fingerprint readers is limited to very few devices.)

In short, my recent experience with AMD 7840U/Radeon 780M has been nothing short of amazing, and these devices have been an absolute pleasure to use.

[1] https://www.gpd.hk/gpdwinmax2

[2] https://gpd.hk/gpdwin4

[3] https://aur.archlinux.org/packages/ryzenadj-git