Of course, the language lets you decide. I think this anti feature is actually a feature.

The main issue I've seen is it writing passing tests, the code being correct is a big (and often incorrect) assumption.

The majority of devs do the same thing.

Couldn't agree more! I have been purchasing on steam due to the lack of a native client, especially save game syncing. As a bonus, as a greenfields project, maybe we'll see less cruft than the native Steam client.

> We do not make this decision lightly, but we will not remain silent.

While I fully support this, this irony is a little amusing. By closing they are actually staying silent for a single day.

> By closing they are actually staying silent for a single day.

If they were just staying home, yes, but that's not what they're doing, so they're not "staying silent".

You can find out where everyone is going instead of working here: https://nationalshutdown.org/actions

I really hope it's a massive success.

I'm surprised that metastudies are inconsistent. Vit D and O-3 probably do have a large effect in a deficient populace (so, like, Seattle or landlocked areas respectively). Metastudies should be good at mitigating that (but I guess you can choose the studies that coincide with the outcome you want).

Either way, the conclusion to this whole debate is incredibly simple: get a blood panel done and go from there - it might not even be one of these that ails you.

If you have trip insurance and your sleeping over is "an act of god", you have a high chance of qualifying for one of the in-airport bed businesses. It's been a few years so I forget the name, but an actual bed is really amazing. I can't remember what it would have cost us, but I do recall was on the very edge of what I would have considered paying myself - so worth looking at even if your layover was planned.

> I worry about the "brain atrophy" part, as I've felt this too. And not just atrophy, but even moreso I think it's evolving into "complacency".

Not trusting the ML's output is step one here, that keeps you intellectually involved - but it's still a far cry from solving the majority of problems yourself (instead you only solve problems ML did a poor job at).

Step two: I delineate interesting and uninteresting work, and Claude becomes a pair programmer without keyboard access for the latter - I bounce ideas off of it etc. making it an intelligent rubber duck. [Edit to clarify, a caveat is that] I do not bore myself with trivialities such as retrieving a customer from the DB in a REST call (but again, I do verify the output).

> I do not bore myself with trivialities such as retrieving a customer from the DB in a REST call

Genuine question, why isn't your ORM doing that? I see a lot of use cases for LLMs that seem to be more expensive ways to do snippets and frameworks...

An ORM doesn't generate REST endpoints?

Everyone has settled on an accessibility standard (Matt Campbell's). So it's not "your" accessibility protocol, it's already "the" accessibility protocol. This is working as intended IMO: allow things to compete and future in the wild and then pick the fittest.

Right. The push based accessibility that is only supported by GNOME's compositor, mutter, and GNOME's DE's userland as of this last 6 months. I would very happy to hear about even this extension supported under other wayland compositors and software. Do you know of any?

Since you seem informed perhaps you can clear something up for me, when Cambpell says "push full accessibility tree to trusted clients" does that mean you get the entire desktop tree, or only for that application?

Because if you don't get the entire window tree, because you only get the single windows information when that application provides it, it is highly incompatible with existing solutions. They say it is compatible because application developers can create a new virtualized thing themselves. But that's not compatible. And beyond that, it is a "solution" that prevents me from controlling my own computer. I understand GNOME is targeting everyone not just power users. But as a power user I am someone. I am a human being.

And Campbell's assertions that push is more performant than pull and full tree are being backed by arguments informed from problems that don't even apply generally. GTK 4 broke this, not GTK 3. It's not a push versus pull thing. It's wayland architecture focused Gtk4 causing the problem when things are fine in X11 focused GTK 3. ref: https://gitlab.gnome.org/GNOME/gtk/-/issues/6269 a11y: No API for supporting a11y Selection interface , https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 a11y AT-SPI: get_child_count implementation iterating over all children causes freeze for objects with many a11y children

> On Wayland, you in theory have to do a late more...

This is vaguely a double-edged sword. Yes, more code duplication across disparate projects - but that also allows people who _really care_ (such as the xfce team) to roll up their sleeves and do more. Any WM will only ever be as good as the X11 baseline, Wayland servers have the opportunity to compete on this front.

Although I'm probably permanently stuck with the Niri workflow, I am looking forward to seeing what the xfce developers come up with.

By the time we get to that utopia someone will declare Wayland obsolete and we'll all be arguing over how Nextfad is the best/worst thing ever.

And technically, nothing has been stopping the xfce devs or anyone from making their own X11 server / X.org fork if the window manager interface was too limiting.

I have no doubt about it, but for my use-cases Wayland definitely is a step up. It's definitely a first-world-problem, but somehow typing feels more enjoyable at low latency - back when I still had a backup X11 session, I could instantly tell that I had left it on: the mouse cursor, input, everything felt like soup.