kevincox

I'm strongly in favour of this. I think income tax should approach 100%. So your second billion you still make more. But not twice as much. The exact decay function is up to date. But I really don't think your post-tax take home should scale linearly with your income once you hit the max bracket.

We can also remove all of the loopholes that result in the biggest companies paying basically no taxes. I also think it may make sense to have a dramatically different tax structure for businesses than effectively income tax.

The problem isn't that we are gaining more knowledge and better technology. The problem is that we are allowing the rich to use the technology to subjugate the majority.

If AI improves human productivity so much that millions of people no longer need to work that should be an incredible thing. But the flawed structure of our society punishes those people rather than freeing them to persue endeavors that interest then.

Dead-man's switch means triggering when something doesn't happen. (The name comes from a switch that an alive operator would need to hold in such a way that if they died they would stop holding.) So in this case she means that her monitoring will fire if there wasn't a successful backup within some configured period of time.

I assume this is opposed to alerting when the backup job fails, which is an issue if the job never runs, or hangs forever, or crashes in a way that doesn't trigger your monitoring.

However I don't see how any of this solves the issue of not testing your backup. Because you can definitely have a backup task succeed regularly but the thing it is backing up is still unusable.

A USB drive with FLAC files works pretty well. It doesn't have the same feel as a CD with art though.

For movies there isn't a legal way to acquire proper files unfortunately.

But even that isn't the whole story because the models can produce wildly amount of thinking output as well as regular output for a similar query. Sometimes you can take a cheap model and have it think a ton or an expensive model that thinks little and get similar results. But the number of tokens generated will be wildly different.

I think 10 t/s output is usable for many coding workflows if the input speed is much much higher (~100 t/s is a rough minimum line). The low output speed can really hurt for heavy reasoning output but it can still be used to get some jobs done as long as you don't expect highly interactive use.

Because the web browser can't make arbitrary network connections. Even if it was implemented intercepting at the HTTP layer (which would probably be much more difficult than just intercepting the low level socket operations) you wouldn't be able to properly manage CORS headers, cookies and various other things.

Yes, I especially see this in code comments. You will get a PR where the comments reference an approach that wasn't the previous state and isn't the state of the PR. You can basically hear the dev telling Claude to take a new approach and now it is so fixated on the old approach being wrong that it litters the whole patch with traces of it despite now being irrelevant.

It reminds me of https://silverspaceship.com/static/

In practice you don't convince Rust that everything is right. You let it prove that most of the code is right and you promise it (via unsafe) that the rest is. Ideally these unsafe blocks would be carefully documented, reviewed and ideally enclosed in small modules that makes correctness easier to ascertain.

Rust is no panacea, but in my experience it is far easier to write memory safe code when the risky bits are discouraged and explicitly highlighted rather than every line of code being a possible risk. Humans are pretty bad at reviewing 100 lines of boring looking code (especially if this is one of dozens of patches this week) but much better (although by no means excellent at) reviewing 5 2-line unsafe blocks amongst 90 other lines of code.

I would say that Rust has a good story here. The simple form of this wouldn't compile. So you are generally presented two options:

1. Slap a reference count on it.

2. Use `unsafe` to promise the compiler that your code is right.

I would say that 1 is a pretty good habit to have. It may open you to memory leaks if you aren't careful but those are much less bad than a use-after-free or other memory management issues. And of course the fact that this was the route the patch took is a good sign. I think this is a pretty good default option.

Now if performance is a major issue you may consider going to 2, so it is impossible to say "Rust would have prevented this" because if it was originally written in Rust this may have been the route taken. But I think it is still very valuable to make that an explicit choice and obvious to reviewers and readers.

It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.

For me it is a mix. I mostly get my content from feeds. But I also aggressively prune my subscriptions so that I catch up, I don't have so much that I fall behind.

When I do catch up in happy to burn a bit of time on Hacker News, Lobsters or Lemmy. But if I like an article I usually subscribe to the feed. So this discovery is an important part of my system.

The algorithmic options can turn into doom scrolling if I'm really bored or similar but since I am not checking too often to start and I am decent at identifying it it isn't a problem for me.

The problem in my experience is that while nil is a perfectly reasonable default 9/10 times that 1/10 happens often enough and causes major problems that it is worth taking the extra few seconds to write it explicitly in the code to acknowledge that case and that you have checked that it is fine in the 9/10 cases or handle it in the 1/10 case.

I have seen multiple major production outages in Golang code because people accidentally read a non-existent map key and used the default value. As a funny bonus in one of those cases we were stumped when debugging because this code had tests, but the tests were also reading the default values out of the map and asserting that "" was in fact a valid textproto (it always is!) so silently testing nothing.

So even if defaults are useful 9/10 times that 1/10 is so painful and expensive that it isn't worth it in my experience. The time spent responding to, debugging and fixing those outages far, far outweighed the time saved by the convenient default values in the 9/10 times.

Or even better, just let the website return a set of flags (like age_rating=18) in a header and let the user agent decide if it wants to show it, block it, ask for approval, ...

Then the policy lives on the user agent.

I imagine that this is primarily for preorders and will be dropped as soon as there is sufficient stock.

We do it. We give the user the option to export debugging information and send it to us.

But the streamlined manufacturing is still more expensive than no heated seats. So someone needs to pay for it. There are two reasonable options 1. charge everyone a bit more by including it as a standard feature 2. charge only some people significantly more so that only the people who find heated seats worth it pay the cost.

It isn't double dipping, in no scenario does it make sense to physically make two models, it is more expensive for no gain. The question is just how you charge people for it.

(Now subscription seems like an awful model, but a paid upgrade for some people makes sense to me)

The global/user wide exclude is a feature that should be more widely known. I frequently have people submitting changes to add their IDE/OS/AI/... files to every project's .gitignore. They are almost always pleasantly surprised when I tell them that they can add them to their standard configuration and have them ignored everywhere without bothering every project and without risk of accidentally committing them on a project where they haven't updated the .gitignore yet.

My general rule is that in-repo .gitignore should only be used for repo-specific things (build outputs, dependency folders, ...) and most user tools should be in their own user config.

There is some rework needed to "bootstrap" the agent each time it has to descend back into Narnia

Makes me wonder if it would be best to have some sort of "fork" operation to start the new agent. Rather than starting from blank it inherits the existing context (which is already cached for evaluation) plus a bit on top for its specific task. Much like the system call there would essentially be two returns, the one in the agent says "You are the agent, perform the discussed work" and the parent gets the result produced by the agent.

I think the question is it a per-feed rate limit or an all-feeda rate limit. If the former then yeah, a complete non-issue. But if it is a global limit than for people following a decent number of feeds it can definitely be an issue.

Is it that unfortunate? Tasks that don't require high-quality translation now don't need human labor. We should be celebrating.

The sad part is that we haven't figured out how to distribute our resources fairly to these people even thought their services aren't required as often. Instead we just take their wages and give them to the top 0.1%

I agree. I much prefer OpenCode (with the web UI). My idea combo would be Claude models with opencode but of course that is far more expensive because Anthropic wants to lock you in.

Teslas also can't drive themselves so I doubt Waymo is worried much about them.

"Kill everyone in the area" is probably the least harmful for the reason described.

It is much more dangerous when they start to be selective. Then people start trusting the selection capabilities and use them in cases where they wouldn't use a "kill everyone" weapon.

It adds another provider that you have to trust with your data. Previously the assumption is that AWS was securely handling your data and you may have the data on AWS to start with anyways. Now you have two providers handling your data which doubles your risk if you trust them equally. If you think AWS has more robust data controls than Anthropic then it more than doubles your risk.

You may also have data management requirements such as allowed storage and transit countries as well as various certifications and contracts that you now need to extend to the second data processor.

Basically if you are already using AWS just adding the AWS-only bedrock model is legally easy and doesn't really change your security posture. If you need to now also log your data to Anthropic it makes the choice much more complicated.

I think playing something when I hit the play button makes a lot of sense. (The headphones auto-play is a bit less obvious than the keyboard key, I would probably want that to do nothing in this case.)

The issue IMHO is that this is not configurable. Apple Music may even be a reasonable default (being the built-in music player). But it should provide options for Apple Music, whatever other apps I have installed, or nothing.

This is true but some sites handle it well. My browser auto-fills the email and password properly even though they are on separate "steps". Other sites the email field doesn't auto-complete in any way (but the password later usually does).

I don't know what the magic is here. If I had to guess they have both fields in the DOM but one is visually hidden. Then if your email is marked as SSO it is just never read.

I can only assume that every time I back out of these sites because I don't want to check the box or just don't want to wait a few seconds that is marketed to the site owner as a GREAT VICTORY as I am clearly a EVIL BOT that they have defended the site from.

I think the attack looks more like this:

1. I log into service X with account A1 via Mullvad from country C1.

2. I log into service X with account A2 via Mullvad from country C2.

If the service wanted they can calculate how likely it is that A1 and A2 are the same WireGuard key. If you only use one exit server this probability won't be very precise. But the more exits you use the more accurate it will be even if the sets of exits are distinct between the two accounts.

If the egress IPs were assigned randomly all that service X would know is that these were both Mullvad users but the IPs alone wouldn't allow them to correlate the two users further than that.