To the degree that's true, it's nothing inherent in the processor generations. What's happened is that Moore's Law has slowed dramatically. If there were as much performance difference between a 2026 CPU and a 2020 CPU as there was between a 2006 CPU and a 2000 CPU, we'd still be feeling the need to upgrade regularly.

Consider, for example that between 2000 and 2006, clock speeds tripled, CPUs went from single to dual core, and instructions per clock went up. A 2006 flagship CPU was ~20X faster than a 2000 flagship CPU. From 2020 to 2026 we saw, what, 2X? And most of that gain came from increasing core counts and hybrid big/little cores, which means that most workloads don't realize the full benefit.

When machines are getting an order of magnitude faster every five years, you're going to be upgrading frequently. That hasn't been happening for a while. If we have some major shift in CPU tech that give us 10X faster machines by 2030, the upgrade treadmill will resume.

That should have been km^3, obviously.

Do the math! The Earth is ~12,800 km in diameter, so a LEO shell from 350-450 km up is about 13,300 km in diameter and about 100 km thick. That gives a volume of about 56 billion km^2. If we give every satellite 100 km^3, that means we're limited to about 56 million satellites.

Oh, you want geostationary orbit? That's way, way, way bigger (though possibly subject to Kessler syndrome, unlike LEO).

Basically every space agency does this.

This is a potential concern for high orbits, not so much for where most of the satellites are being deployed.

Space getting "full" is never going to be a constraint on SpaceX's growth, so you should probably look for some different signals.

I absolutely review all of the code, telling the AI to rewrite parts of it, and occasionally doing it myself. I take advantage of the AI to produce not only more code, but higher-quality code (because I will make the AI do refactors that I'd previously have dismissed as not worth the effort). I now get more done in a day than I used to do in a week and, as I said, with higher quality: more/better documentation, cleaner code, more comprehensive test suites, etc.

AI is a huge productivity boost, and it's actually that boost that creates the review and merge bottlenecks. A four-hour merge process isn't a problem when you only produce two merge-ready PRs per week. But I average one merge-ready PR every 2-3 hours.

I've been trying for a while to use a "loop" to optimize one particularly-tedious part of my workflow: Merging.

My employer uses Github with an extensive CI infrastructure to validate all sorts of things. After CI passes, trunk-io takes the commit and retests it in a batch with other commits and if they all pass, merges them as a set of squash commits. If something goes wrong, I have to figure out whether it's a transient failure (in which case I can tell the system to re-run the tests), or whether it requires me to fix and re-push. My commits typically build on one another so I end up with a stack of PRs that have to go through this process. When a commit finally merges the next commit up the stack has to be rebased and re-pushed.

Start to end, getting a commit to merge takes between one and four hours. This is slow enough that even though I don't have to watch the process continuously, just check in on it every half hour or so, it puts a major crimp in my productivity. If I only merge during working hours I can only merge 2-4 commits per day, but on a good day I create double that. This means that I have to be merging evenings and weekends too, or my backlog builds up. (Code review is another obstacle, but I'm focused only on the merge process here.)

There are enough possible odd failure cases in the merge process that I haven't been successful at writing a script to manage it. So I thought "Hey, why not have Claude supervise it? Claude is capable of exercising some judgment and problem-solving, right?".

Not really. If there's a problem blocking the PR at the bottom of the stack from merging, Claude is perfectly capable of analyzing the situation and determining what needs to be done to unblock it, and of performing the operations necessary -- but only with active prompting. Claude can set a timer to go periodically check the status and recognize the problem, but no matter what I do I can't get it to autonomously take the next step of correctly diagnosing and then acting on that diagnosis. Even given explicit instructions to do so, Claude either (a) fails to investigate enough, (b) fails to identify correct actions or (c) fails to perform them. When I wake up in the morning and ask Claude what the situation is, it generally correctly and accurately summarizes exactly what's wrong and exactly what needs to be done to fix it, and then when I ask why it didn't do those things it tells me that it clearly should have, but it just didn't.

I've tried various architectures, using one instance to prompt another one, using pairs of instances set up with distinct, complementary responsibilities, using instances set up with adversarial responsibilities (this is the most effective), but I just can't get it do to this work effectively.

Cite?

I find that extremely unlikely. The cryptography behind BTC is very simple and very robust. Oh, it's certainly the case that if someone were to break any of the cryptographic elements they'd have made a name for themselves that would result in them being showered with opportunities in both academia and industry, but (a) that's extraordinarily unlikely and (b) the primary benefit of doing that work wouldn't be related in any way to BTC. Oh, and it would also take down lots of other important uses of cryptography, like TLS. That doesn't make it not worth doing. The fact that it would break so much other stuff is what makes it worth doing.

"Value" is too variable and subjective to be a global concept. The only useful way to define "value" is "What a given person or entity will pay". Your gamr-boi puts a very high value on a game. I would value the game at very close to zero. Probably not actually zero... if you offered me a big bundle of games for a penny, I'd buy them because a there's some tiny possibility that I might want to play one or two of them sometime in the future. Especially if the purchase is digital (e.g. Steam) so I don't actually have to store them anywhere. Another person might place the value somewhere between the gamr-boi's "lots" and my "almost nothing".

And "price" is just the aggregate combination of all the potential buyers' values, matched against suppliers' offerings. So price is inherently and inextricably associated with value. Specifically, the value that everyone puts on a good defines the shape of the demand curve, and the price is where the demand curve meets the supply curve.

Your video game example is not a great one, because non-rivalrous goods (my having the game doesn't preclude you from also having it, unlike, say, socks, where my possession of a particular pair of socks means you can't have them) introduce some complications into this analysis. It's much easier to understand the relationship between value and price with traditional physical goods first.

Where the curves cross is the highest profit the seller can get away with. This is precisely how the curves are defined.

When talking about supply and demand, people commonly misunderstand that both curves are fundamentally about price, not availability or desirability. The supply curve is "How much is available at each price level". The demand curve is "How much will be bought at each price level". At prices above or below the intersection point, sellers are failing to maximize their profit.

It's profit-maximization that pushes prices to the supply/demand intersection point.

Note that monopoly or monopsony don't invalidate the supply/demand curves, they just alter them. Even with a perfect monopoly, the supply and demand curves still exist; at different price levels the monopolist can obtain more or less to sell, and at different price levels the buyers will purchase more or less. Supply and demand curves don't work or not work in different market conditions. Supply and demand curves always hold, non-competitive market conditions just shift the curves. Even government price setting doesn't change this fundamental reality... it makes price ranges legally inaccessible, which just alters the curve shapes by adding legal risk to the "price".

Supply/demand curves aren't a prediction, they're an observation, and the basic concept is near-tautological.

Here's hoping he leans into crypto currencies big time, then.

I have no knowledge of that, for which I'm happy. But... Windows 10 was released in 2015 and will apparently be supported through late 2027. Outside of RHEL no Linux distro comes close.

Well, if by "many, many, many" you mean "about five". Red Hat provides longer support terms, but not for free.

True, sort of. Assuming the upgrade works, which it often does... but not always.

I'm no Windows fanboy, in fact the last version of Windows I used was Windows 2000. I switched to Linux completely by mid-2001 and I've never looked back. But it's really not as rosy as you paint it. The commercial OSes (Windows and OS X) actually do a much better job of delivering long-term support and (in the case of OS X) upgrades. I don't personally care about that for my machines, because I have no problem managing them, and even debugging the occasional update or upgrade failure. But I'm actually glad most of my relatives use Windows, because I would not enjoy having to help them do the same.

You seem to have completely missed the point, which is that what Biden *should* have done -- while his party held both houses -- is changed the law, rather than issuing an order that broke the law. Trump has been far, far worse about this, but it's clear that part of Trump's goal (or the goal of someone with his ear, since I'm not sure he is capable of making and pursuing goals over longer time periods than a few days) is to establish that the president doesn't need Congress.

What do you think he's going to do with it?

Early access games getting faster after release is probably more a result of removing debugging from the build more than outright optimization.

My voltage doesn't vary much at all no matter how much power I'm pushing. And, unfortunately, I couldn't set my inverters to derate if I wanted. I'm fighting with the installer over access to configure/manager my inverters. They offer quite a good repair/service warranty and also a production guarantee, and won't give me control without voiding both of those so I'm debating which I care about most.