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.

Yep. It's incredibly annoying.

"One $250 million dollar hookerbot, or 250 million one-dollar hookerbots?"

Huang's not an idiot, his security team would be handing out his money, because nVidia's money would be documented. Lord knows Huang can afford it.

The overwhelming majority of his nVidia shares are vested so it doesn't matter. This guy could acquire a $10,000-dollar-a-day cocaine and escort habit and he would still probably end his life richer than he is now.

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.

From a cost benefit analysis he has spent a tremendous amount of money to pick up a modest amount of plastic. And he hit every problem that actual experts predicted would happen.

https://therevelator.org/why-o...

"plastic going into the ocean (via interceptors)"

The funny thing is people told him that would be more effective because people had already deployed river interceptors and they were effective, and it took years before his techbro ego let him finally do it. At which point he claimed to have invented the technology which was a lie.

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

There's no such thing as clean natural gas. Even if you have no methane leaks, you're still producing CO2.

And no, the solar farm to power a gigawatt data center would be only about 10 square miles or so. It's big, but it's not "small state" big.