Solar panels in low earth orbit get only about 5x as much power per square meter as solar panels on the ground. A modern AI data center uses upwards of 1 gigawatt of power. In low earth orbit, at 1.361 kW irradiance per square meter, even if your solar panels were 100% efficient, a data center would need 735,000 square meters of solar panels, or almost 1.5x the size of Vatican City, or 137 football fields, or...

Mind you, presumably an in-space data center would be broken into hundreds or thousands of satellites operating together, but the largest in-space solar array ever built is only 3,244 square meters, and that's on ISS, and was assembled by people over many *years*. (The original was 2500 square meters, and it took eight years to expand it to 3,244.) Even if you divide that a thousand times, it would still be about three times as big as the largest solar array ever deployed automatically from a satellite (as opposed to being built in space like ISS).

And real-world panels are only about 30% efficient, so multiply those numbers by three.

I'm not saying it's impossible, because it isn't, but even if we optimistically assume that a launch can lift 1,000 square meters of panels (4x the monster satellites SpaceX is planning), you're talking about 2,200 launches for the panels alone, and probably at least 20,000 launches for the trusses to hold them. Even if SpaceX's peak launch rate of 3 per day is sustainable, a single data center would still take well over two decades to build. And this is probably optimistic by a factor of two to four.

So not impossible, just completely and utterly infeasible without multiple-order-of-magnitude improvements in efficiency.

This is not to say that having that sort of capacity in space won't be useful for certain purposes. The planned SpaceX satellites are supposedly going to have solar arrays of 250 kW, which is enough to power basically a single rack in an AI data center, so if that's enough compute power for you, great. But realistically, you're more likely to see data centers in space powered by nuclear power than solar power, assuming politics allows that to happen. The size requirements just don't work without being able to spread the panels out on the ground over many miles.

I like to think the delay is justified by the fact that IF you think in terms of 1800s tech, America is huge and it can take a while for horses to pull a wagon from sea to shining sea.

It's November 1860 and you just won your election to be the new Senator from Oregon. You have two months to get to DC. Can you do it? (Yes, you can do it in a "mere" 3-4 weeks thanks to rail. But before rail? No way two months is enough.)

The first thing will probably be to do something think of the children bullshit to ban local AI instances.

Are you seeing a lot of support for the "people should be forced to use a data center to run AIs, instead of being allowed to do it at home using solar power" position?

What I saw last week, is that "think of the children" means that no one should ever fucking ever let a Republican anywhere within ten feet of a child, rather than it meaning we need to give data centers a monopoly on running AI.

The RAM crisis is it. This is the high-water mark on suppressing competition. It was a clever move, but the consumer market isn't going to tolerate electronic gizmos and video games being expensive forever. As soon as someone decides they want money and opens another RAM factory, the AI companies are in trouble. They have this brief pre-Personal-Computer-Revolution situation going on like 1960s IBM, and the 1970s are coming to fuck their shit up.

Yo dawg, I heard you like DMCA, so I sent you a DMCA notice (Title 17 Section 512) about DMCA-prohibited circumvention (Title 17 Section 1201).

Capping the capital gains tax break is, of course, the right answer.

The capital gains special tax rate should apply to a maximum of $500k in income plus any gains from the sale of your primary residence (and only your primary residence, not any other real estate). Everything above that should be taxed as ordinary income. And critically, that $500k number should be automatically adjusted annually, indexed to the CPI or some other reasonable inflation metric of your choice.

Maybe also allow a once-per-decade exemption for sale of a partnership or sole proprietorship. Maybe. I could go either way on that.

But the special treatment for income from stock sales, stock dividends, and interest should be capped.

Oh, yeah. GPL V3 is spectacularly unfriendly to commercial development of anything — enough so that Apple created Clang, which has cut GCC's market share almost in half, massively damaging the long-term viability of the FSF's golden goose. And since the release of V3, GPL development has declined massively to maybe a third of what it was before GPL v3.

GPL v3 was widely regarded by almost everyone in the tech industry as a boneheaded move. It still is.

The reality is, if you're a BSD distro, folks kind of expect the whole thing to be BSD-licensed, or else what's the point. So having GPL-licensed bits is the sort of thing that they try to avoid. They held their noses and put up with gcc until clang got good enough. There are probably other examples. But there are really good reasons from a "we want you to be able to drop our stuff into any commercial situation and use it without worrying about licensing" perspective why they would want to avoid bringing in additional GPL if at all possible. :-)

A lot of us who do understand it very well also shirk away from GPL, and V3 in particular. It's messy when you're shipping a boot loader that gets loaded onto hardware. This is not to say that having the source available isn't a good thing, but there's no guarantee that users will be able to update it even if they have the source, thanks to code signing requirements, etc.

Besides, consider how many ARM board manufacturers don't bother to contribute their patches to mainline Linux and end up with hardware that is borderline unsupported after a couple of years, rather than contribute back. They comply with the GPL fully, making their code available, but the notion that the GPL somehow magically forces them to contribute back in a meaningful way is just wishful thinking. In reality, it's a giant pile of forks.

It may surprise you that most bigger developers do share it back. A sizable percentage of the development work done on *BSD comes from commercial contributors who are hired by companies that use the software. Turns out it's really beneficial to have your code merged in so that you're not constantly chasing a moving target or re-fixing bugs that other people have fixed because you decided to close things off and fork.

They can, but those "plenty of examples" tend to get rewritten eventually, because GPL code in *BSD has a bit of a stench.

Either way, they probably won't use it at all. Realistically speaking, here's what you can expect: The OpenBSD folks will fork at the last version that was licensed under MIT. They'll continue doing development on their fork, independently fixing bugs that affect them, and not contributing them upstream to the GPL-contaminated fork. After all, it's not like the OpenBSD folks are strangers to forking things. L8-)

Not really. MIT licenses might not give an incentive to contribute back, but most larger companies that use MIT-licensed code do, in fact, contribute back. By contrast, GPL v3 is so toxic that with the sole exception of my first tech employer (which was a Linux distro), no company I've ever worked at will touch it with a ten-meter pole.

Moreover, the GPL does not force you to give back, either. You can GPL something, and someone can use it indefinitely in a modified state without ever giving you the changes back. Someone can even create their own fork on GitHub and commit millions of changes and never send you a pull request or tell you that they did it. They have to give the source to their users, not yours. And this problem exists even in V3, and indeed, even in Affero V3.

So the notion that GPL somehow makes a project less stagnant is seriously wishful thinking. All the GPL does is eliminate most corporate contributors. The problem of getting people who change your code to actually give the code back to you in a usable form is exactly the same regardless of license.

It may have been generated in 2025, but the copyright on the man page itself says OpenWall 2017.

C-SPAN is the closest I can think of. I do like C-SPAN.

Realistically, I don't care what language Claude runs commands in when working on a project. That doesn't have to match the language of the project. My preferences for what commands the tool is allowed to run have basically nothing to do with the project, with the exception of me expecting it to not access files outside a per-project sandbox, which should be just a list of directories that are part of the project.

Either way, the fact that a project can encompass multiple directories means that metadata about the project shouldn't live in that directory.

But even if we assume that for some reason, I care whether it tries to use the wrong git repo and the wrong password (which wouldn't make a lot of sense, given that the .git file should tell what repo to use), the list of allowed commands still does not belong as part of the project data, because what I as a developer am willing to tolerate is not necessarily the same as what someone else as a developer on that same project is wiling to tolerate. It is inherently a per-user choice, not a per-project choice, which means it doesn't belong within ten thousand miles of the project directory.

There are exactly two valid places to store it: the app's preferences or a separate per-project configuration file that lives outside the data container (e.g. $HOME/.claude/projects/project_name). And in an ideal world, you'd have multiple configurations that you can choose from, e.g. one permission set that grants it more access than others, depending on what you're working on. And when you create a new project, you'd choose which permission set to use, e.g. "Project directory only", "Team Drive and project", "YOLO", etc.

But either way, no matter where it lives, it should not there.

Just because other questionably designed systems made the same mistake, that doesn't mean it isn't a mistake. For one thing, it's a security red flag the size of a planet in this context. If that file lives in the project directory, that means it's presumptively inside the writable part of the sandbox, which means nothing prevents Claude from rewriting that file to grant itself additional permissions. Compared with that, the potential for leaks is just the icing on the cake.

This isn't a grey area. That data has security implications at multiple levels, and it *absolutely* should *never* be anywhere *near* the project directory, period.

Next to is not inside. If it were up one level, right next to the git root, we wouldn't be having this discussion. It wouldn't end up in the repository, it wouldn't be inside Claude's sandbox, and it wouldn't be a security hole from h**l.

But I'd prefer it to be in the app's preferences, so that it gets nuked when the app settings get nuked.

There’s a trivial fix: Sue Anthropic for storing this in the project directory instead of in a centralized preferences file like any remotely competent software developer would have done. The only reason this is a problem is because they deliberately mixed public data and private metadata in the same directory.

I'm not saying that the mode doesn't exist, and I'm not saying Tesla isn't saying that they will disclaim warranty coverage if you wash your car without using it. I'm just saying that none of the things that it does should reasonably cause the car to be seriously damaged, and if that happens, something was wrong with the car to begin with.

More to the point, I'd be willing to bet that a court would laugh at them and find them liable anyway because of the sheer unreasonableness of expecting someone to put a car in a mode just to wash it, not to mention that they would have to prove that the car wash mode somehow would have prevented whatever the damage was, which just seems really unlikely given what it does, and also prove that a reasonable person would not consider whatever design decision made that unnecessary to be a defect in design or workmanship.

In other words, my words to Tesla are "Good luck with that."

The law doesn't explicitly define the term repeat infringer, nor does it say how many piracy accusations it takes before a subscriber can be cut off.

[emphasis mine] Surely they mean convictions, no?

Why would accusations be relevant? I accuse every single member of the Mexican government of having violated the copyright on my work, four times each. They all did it four times. No, I can't prove it, but the accusation stands.