How do namespaces help? I'm building a package registry and I've decided against namespacing because I can not see how to implement it in a way that doesn't just lead to even worse problems.
Because @apache/solr would be easier to disambiguate vs @randomuser/solr.
You should really build namespaces in from the start, or at least reserve the capability to do so in the future. Unless you want to speed run all the lessons already learned.
What stops someone from just squatting the namespace? What is the concrete value? Who gets a namespace? Who gets "apache"'s namespace? Is it a problem if a user takes "apache" or "anthropic"? Do you use domain registration to determine who owns a namespace?
I'll read the article soon fwiw, but those questions come to mind. I'm definitely open to it.
For now I have:
1. Minimum "typo distance" between package names, unless within the same author.
2. Trusted Publishing + 2FA to promote from "published" to "released" required, no API keys.
3. 1 day dependency cooldown by default.
4. The language (and the build system, built in the language) has explicit capabilities model so you can statically verify what build scripts are allowed to do.
I feel like the benefit of namespacing must be quite low at this point but perhaps I need to reevaluate.
If you can’t be bothered to read the paper that covers all of it, why should I be bothered to respond? Do whatever you want, I’m just highlighting this space is well studied and you’re insisting on retreading ground where the consequences are well-studied.
How is Google doing "everything they can to sabotage you"? MV2's deprecation timeline was set in 2021, slipping further repeatedly. This is after they had already started the plan in 2018. It's been nearly a decade.
I feel like you can justify literally anything as "doing everything they can" if "they did it fast" and "they did it over the course of a decade, replaced the API, the API still supports ad blockers, etc" are treated the same way.
It's not a trade. It isn't "because we got memory safety we have to lose supply chain security". Rust, like every other language, has put minimal preemptive effort into supply chain security. There's recently basic stuff like Trusted Publishing and dependency cooldowns are on the way, but that's it in terms of native features - nothing novel or special, really.
Thankfully the community has built `cargo-vet`, which is basically a best-in-class distributed auditing system.
There's certainly assembly that maps directly to the machine language bytes, I assume you are talking about the version of assembly with the high level loop macros
Apr Fools Day really is the shittiest day to be online. For one thing, practical jokes/pranks are just gussied-up asshole behavior. For another thing, nerds generally SUCK at information-delivery pranks, which is what the Internet is full of on Apr 1.
Back in 2004 when free email services like hotmail were limited to 10-15mb, on April 1st the evening standard front page headline, which I saw in the office around 2pm, was something “Google lunched 1gb email”
I couldn’t believe they had fallen for an April fools so hard.
> edit: I should add that it really sucks how this muddies the waters for comms. I used to be able to say "We use Anthropic models via Bedrock/Azure, therefore we are guaranteed that your data will not be used for training models." That was simple comms. Now, it's not that simple.
This is massive and an insane move from Anthropic. They should have worked with AWS to have the retention done entirely in AWS infra and disabled the retention on their side.
Exactly. See my downthread comment. That is my proposal as well. I understand that Anthropic and Azure/AWS have different priorities, so even if Anthropic forward-deployed/embedded/rotated their own people into those teams to keep them honest, as long as user data didn't flow back... I would be fine with that.
reply