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.

The Windows kernel is also falling behind. Linux is considerably faster for a wide variety of workloads, so much so that if you're CPU limited at all, moving from Windows to Linux can net you an improvement similar to moving up a CPU generation.

Your anecdote regarding P2P file sharing is ridiculous, and you've almost certainly misunderstood what the author was saying (or the author themselves was an idiot). That there wasn't sufficient bandwidth or computing power to stream 4K video at consumer price points during the heyday of mp3 file sharing, didn't mean that no one knew how to do it. It would be as ridiculous as me today saying that 16K stereoscopic streaming video can't happen. Just because it's infeasible today, doesn't mean that it's impossible.

Regarding ChatGPT, setting aside the fact that the transformer model that ChatGPT is built on was under active research 10 years ago, sure, breakthroughs happen. That doesn't mean that you can linearly extrapolate future breakthroughs. That would be like claiming that if we developer faster and more powerful rockets, then we will eventually be able to travel faster than light.

It obviously wouldn't have the bandwidth to do so in a way that would make a real-time stream feasible, but it doesn't involve any leap of logic to conclude that a higher bandwidth link means being able to transfer more data within a given period of time, which would eventually enable use cases that weren't feasible before.

In contrast, you could throw an essentially unlimited amount of hardware at LLMs, and that still wouldn't mean that they would be able to achieve AGI, because there's no clear mechanism for how they would do so.

The gaming industry is thoroughly multi-platform, and many games that are limited to Windows on general-purpose PCs aren't so because the require DirectX, since they've also been developed for Playstation where DirectX isn't a thing.

Support for Mac can be somewhat challenging, partly because the platform (including the hardware) is so different from other general-purpose PCs, and partly because Apple doesn't particularly care about backwards compatibility, and will happily break applications if it suits their interest.

However, a developer that doesn't support Linux does so because they don't want to for whatever reason, not because the technical bar is too high. With the work that has gone into Wine, Proton, and other Windows compatibility libraries these days, there's a good chance that a Windows game will "just work" unless the developer does something to actively inhibit it.

If you want to hand-wave that away by stating that any company with technology capable of achieving AGI would guard it as the most valuable trade secret in history, then fine. Even if we assume that AGI-capable technology exists in secret somewhere, I've seen no credible explanation from any organization on how they plan to control an AGI and reliably convince it to produce useful work (rather than the AGI just turning into a real-life SHODAN). An uncontrollable AGI would be, at best, functionally useless.

AGI is --- and for the foreseeable future, will continue to be --- science fiction.

Legacy floating-point and SIMD instructions exposed by the ISA (and extensions to it) don't have any bearing on how the hardware works internally.

Additionally, AMD processors haven't supported 3DNow! in over a decade -- K10 was the last processor family to support it.

The margins on their desktop products are also way down, their current desktop product isn't popular due to performance regressions in a number of areas relative to the previous generation (and not being competitive with AMD in general), and their previous generation products continue to suffer reliability problems.

And all this, while they're lighting billions of dollars on fire investing in building a foundry that has yet to attract a single significant customer.

Intel's not in a good spot right now.

Intel has a competitive iGPU in the low-power mobile space. Their iGPUs in general are also pretty solid for general desktop use. But even in the x86 space, AMD has better-performing iGPU options than anything Intel has ever offered.

When I put a machine into standby, I want it to go in a standby state, and then stay there until I explicitly wake it -- not keep doing whatever background tasks the OS developers, app developers, or whatever other third parties think they need to keep doing.