I'm not sure how you get that from the article (maybe it was pointed to a different article earlier?).

I don't have a Steam Deck, but as I understand it, it does not support Secure Boot out-of-the-box. Also, SteamOS is Arch-based, and it doesn't look like Arch is listed among the "well-known" signing keys that EACv2 lists as trusted.

But not supporting the EACv2's requirements today, doesn't mean that Valve is inherently opposed to doing so. If you have a statement from Valve claiming that, please share it.

It's a shame. It would be the perfect application for my basic image editing needs, if only I could actually rely on it to work.

These days, I just use Krita. It's on the heavier side, but functionally, it does what I need.

Students have been cheating and taking shortcuts on their work long before the current generation of AI tools existed (and probably for as long as graded exams have existed).

Somehow, civilization has managed to survive.

Windows XP is where Microsoft themselves pushed the consumer market onto the NT line, but Windows 2000 was fully functional as a consumer desktop.

Every native UI framework I've ever used allows drawing directly to a canvas, and can have literally any visual style that can be created with pixels.

As far as cheap, low-spec, disposable laptops go, Chromebooks are the spiritual successor to netbooks.

I recently had to log into it for the first time in a few years to make a config change to the domain, and it wouldn't let me in because the 2FA code wasn't working, and a recovery code wasn't sufficient to enable privileged access. I had to reach out to Google Workspace support to regain admin access to my domain.

Thankfully, they were able to do so (although it took a few days and I had prove ownership of it).

So there's an example of a situation where an account that's not logged into for a long time doesn't mean that it's forgotten or unused.

It does admittedly take some effort to set up; I assume Google is hesitant to enable it by default because of issues with Nvidia GPUs. But when configured, it works and has for years.

> I work at Red Hat. Mostly on AArch64 support in several projects.

So an ARM developer, working for a major Linux distro vendor and trying to dogfood their work, used the closest thing to an ARM workstation that Linux can run on.

What other alternatives would you suggest? The various Apple Silicon or Snapdragon laptops that have their own well-documented problems running Linux? A smartphone running as a desktop?

There aren't very many ARM-based options that are even feasible for use as a developer desktop, even if the software did work correctly.

I think there's another world event that happened in that time span that might better explain America's world-wide industrial dominance.

Citation very much needed for this claim.

Maybe it sounds weird to you, but it's a well-understood term in the management profession.

If one of my direct reports came to me and said they were interested in working on, say... AI observability (replace with whatever interests you), and that was something I had any influence over (even if only indirectly), I'd be finding whatever way I could to connect my report with that kind of work.

It's all well and good to say that you're in control of your own career advancement, but that's not in conflict with working with your manager on supporting your career development. Even if they don't have anything to teach you, they will necessarily have some influence of your scope/area of work, so it only makes sense to work them on aligning your work with your interests.

It's a reasonably well-built system, but $3,500 USD is hard to justify for a basic system with an 8-core CPU, 32 GB of RAM, and no discrete GPU, especially given that it's using parts that you can just purchase and assemble yourself.

I know that prices of some components have increased significantly, but not by THAT much.

[1] https://www.pugetsystems.com/solutions/more-workstations/qui...

[2] https://www.pugetsystems.com/parts/photography/Additional-Co...

TL;DR: It runs, but not well, and performance has regressed since the last published benchmark.

Not only does grafting this functionality onto a language after-the-fact inevitably result in a usability nightmare, it also gets in the way of enabling developer self-service for these tools.

When a developer used to the features and functionality of full-featured language sees something ridiculous like Terraform's `count` parameter being overloaded as a conditional (because Terraform's HCL wasn't designed with conditional logic support, even though every tool in this class has always needed it), they go JoePesciWhatTheFuckIsThisPieceOfShit.mp4 at it, and just kick it over to Ops (or whoever gets saddled with grunt work) to deal with.

I'm seeing the team I'm working with going down that same road with Helm right now. It's just layers of templating YAML, and in addition to looking completely ugly and having no real support for introspection (so in order to see what the Helm chart actually does, you essentially have to compile it first), it has such a steep learning curve that no one other than the person that come up with this approach wants to even touch it, even though enabling developer self-service was an explicit goal of our Kubernetes efforts. It's absolutely maddening.

I'm using Ubuntu 24.04 LTS with a Radeon RX 9070 XT (currently the most recent and highest-end discrete GPU that AMD makes), and it works fine, both functionally and in terms of performance.

> I run Arch and my 9070 xt experience was poor for several months after release. I can't imagine modern gaming on an lts release.

Maybe instead of imagining it, you should just try it?

Have you ever had situations where Foo has an urgent security or reliability update that you can't apply, because Bar only works with an earlier version of Foo, and updating or replacing Bar involves a significant amount of work because of breaking changes?

I won't deny that there's value in having the latest versions of software applications, especially for things like GPU drivers or compatibility layers like Proton where updates frequently have major performance or compatibility improvements.

But there's also value in having a stable base of software that you can depend on to be there when you wake up in the morning, and that has a dependable update schedule that you can plan around.

English has a specific word for that: reliable.

Pedantry aside, having a complex system filled with hundreds (thousands?) of software packages whose versions are constantly changing, and whose updates may have breaking changes and/or regressions, is a quick way of ending up with software that crashes or breaks through no fault of the user (save for the decision to use a rolling release distro).

Arch follows a rolling release model. It's inherently unstable, by design.