> Buy a $300 motherboard now in case you need future features, or buy a $100 motherboard now that does everything you currently need and then buy a second or even third $100 motherboard if you ever actually need those future improvements.

Right, but the problem is that by now your $100 new motherboard requires a new CPU and new RAM. Which is very much not $100.

In the past we got away with PCI cards to add features without changing the motherboard, but we still ended up changing everything every 2 years anyway…

When you try to future proof, you are basically hedging. It’s a kind of insurance; sometimes it pays off, sometimes it does not. Having more disposable income now than I did 10 years ago I tend to pay more attention to this sort of things, but everyone can choose where they put the cursor. Someone who overestimated their RAM needs when buying a computer last year are probably pretty happy about it, but it could have swung the other way.

The problem with old Python code is that you then have to hunt for exactly the right version of the right libraries that can work together when the stars are aligned.

Isn't that true of any packaging system? (npm, RubyGems, etc) Perhaps it's a bit easier, with the respective spec files, but it's still a bit of a hunt.

Depends on exactly how the project is managed. Older python tooling (`pip` module) doesn't have a native mechanism to differentiate between the spec (direct dependencies) and freeze (all dependencies, including transitive).

I suppose at some point enough of them will get burned, there will be a swing back and everything old will be new again, and so on and so on.

Luckily for me the company that hosted mine went under, nothing is accessible anymore, and there is no snapshot in the Internet Archive.

> They're transitioning away from the making money off of hardware phase, and into the making money off of you phase.

As a result, I am transitioning away from being one of their customers.

For as cursed as our timeline is, "Linux desktop is solid, LLMs exempt you from the fiddly bits, and valve fixed gaming" was not on my bingo card 10 years ago, but hot damn, we just might be okay.

To who?

Linux, mostly, and other companies’ services. Though I am really not prepared to jump to Android.

GrapheneOS works great and does not want to push ads, subscriptions, and whatnot. Now Pixel-only, next year also certain Motorola models.

> What does an 80 year old (or anyone really) need with more than one or two cards on a daily basis where this would be an issue?

In my physical wallet I can take the card I use daily (which is on a limited account and no big deal if I lose it) and leave the others at home. On my phone, there are all the cards I ever used or plan to use at some point in the future.

To that end, I do wish there was a way to hide some cards in wallet inside a "folder" or something. As is, they're there front and center, or not added at all.

Indeed, and it is a complicated problem to solve. A GUI or CLI can hide footguns or make them less likely to be misused. But an AI agent is perfectly happy to use a wrecking ball to put a nail without any second thought or confirmation.

Even then. I don’t have an example off the top of my head but even perfectly clear sentences can lead the agent to strange places. Even between humans, miscommunication is easy, but then anyone sensible would ask for confirmation if their interpretation is weird. But the LLM very rarely questions the user.

I don’t think it’s fair to blame the user here. The tool must be operated by normal users.

I'm trying to think of other types of tooling that normal users can all use equally well, or in the best ways possible.

> The slot machine can drop any hard requirement that you specifically in your AGENTS.md, memory.md or your dozens of skill markdowns. Pretty much guaranteed.

Indeed. That said, I’ve had some success with agent skills, but I use them to make the LLM aware of things it can do using specific external tools. I think it is a really bad idea to use this mechanism to enforce safety rules. We need good sandboxing for this, and promises from a model prone to getting off the rails is not a good substitute.

But I have taught my coding agent to use some ad hoc tools to gather statistics from a directory containing experimental data and things like that. Nobody is going to fine tune a LLM specifically for my field (condensed matter Physics) but using skills I still can make it useful work. Like monitoring simulations where some runs can fail for various reasons and each time we must choose whether to run another iteration or re-start from a previous point, based on eyeballing the results ("the energy is very strange, we should restart properly and flag for review if it is still weird", this sort of things). I don’t give too many rules to the agent, I just give it ways of solving specific problems that may arise.

Do you have any information on skills you've found useful here?

Not really, unfortunately. I took some inspiration from existing skills, mostly in the official GitHub repo https://github.com/agentskills/ . But mostly I had to come up with them myself. I try to use Claude to help but it was not that useful.

> 10x better than safari and it won’t consume all my RAM like google

Using the 3 regularly, no, Firefox is not "10 times better than Safari". Though, yes, Chrome(ium) is a ressource hog.