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