Okay, what engineer sent out a BGP message claiming a hop count of 1 to 0.0.0.0 and routed the entire Internet through his workstation this time?

But practically speaking, the most common ways to meet a future spouse organically (as opposed to through dating apps) are meeting through friends, meeting at bars, and meeting at work. If you're at that level of a company, your friends mostly are as well, so you're mostly going to meet other execs, and Nvidia sells to almost everybody, so your rules put all of them off the table. You're unlikely to have time to go to bars after work, so that's probably out. And anyone you meet at work will be your subordinate, so that's out.

This leaves... basically no opportunities for naturally meeting someone and striking up a relationship.

Just saying.

Sure. But bear in mind that the heat dissipation is caused by the power consumption, because approximately all of that power consumption eventually becomes heat. So it's two sides of the same coin.

The 1 GW power consumption for a data center is more than four orders of magnitude greater than the most powerful satellite solar arrays ever built to date. (The current record is about 30 kW, I think.) And as long as that is true, it won't really be feasible to put anything approaching an actual data center in space. The tens of thousands of additional launches to get giant fin radiators for the heat dissipation are just the icing on top of an already absurdly impractical cake.

Musk's proposed 250 kW satellite is almost an order of magnitude bigger than anything that has ever been built, and will need an order of magnitude more fin area, but that's at least maybe within the realm of modern heavy launch systems. So again, a single rack in space *might* be feasible, but you'd only have fast access to other stuff within a single rack, which likely limits you to a single instance of current frontier data models, give or take. And one rack likely won't be enough for much longer.

Couple that with 6-year depreciation, where it is expected that the hardware will be so outdated in 6 years that it won't be useful to keep it running, combined with the comical levels of effort required to upgrade a data center in space and the high probability of something that big causing actual damage if you were to deorbit it rather than upgrade it in place, and you have a recipe for bankruptcy.

So this isn't practical on many, many, many levels, not just power consumption or heat dissipation. It's neat from a "Look at us! We can put data centers in space!" perspective, but it's about as practical as a unicycle for quadriplegics.

Could, sure, but there are also very easy ways to mitigate that risk. You can have someone else write that person's performance reviews and manage that person.

Also, when that person is a VP, there's not a whole lot of manager discretion when it comes to performance reviewing, choice assignments, mentoring, or discretionary rewards anyway. Each VP is in charge of a specific area, and the choice of who becomes CEO later is made by the board, not the outgoing CEO, so it's not like he has any say over who gets promoted.

But either way, he could put it in the hands of the board, and that would be the end of the problem.

The challenge, of course, is that when you're in that position, everyone at the company is your subordinate, so if you want a relationship, your choice are execs at other companies or a subordinate. The guy is married, so he shouldn't have had another relationship at all, but if we ignore that moral question for the moment and pretend that he was single at the time, you've just eliminated pretty much every kind of relationship he could realistically have, and that bothers me a bit.

IMO, when someone in a position of authority over someone does something like that, the right questions to ask are who initiated the relationship, whether the other person felt pressured to accept, whether it happened suddenly at the start of the job or after years of spending time together, whether he took steps to protect her from retaliation (e.g. talking to the board about it), etc.

Of course, whether women felt harassed or not, there's still a bright-line problem; he is married, and shouldn't have gotten involved with someone else. But that's a moral concern, not an ethical or legal one. Is that adequate reason to force him to step down? Depends on the company and the image they want to convey.

The real question in my mind is whether the people wanting him back are women or just men. If only men are complaining, then that means the women have concerns, and we should err on the side of caution and listen to the women. If both are complaining equiproportionally, then we should listen to them.

... with the caveat that they all just lost a lot of money, which might bias their attitudes more than just a bit, and those biases should also be taken into consideration.

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.

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.

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."