> In fact, it’s unlikely such a list is even _allowed_ to exist given the sensitive nature of some areas of the business, being a publicly traded company which works directly with regulated entities and governments.
If the existence of a domain/subdomain is considered sensitive information, then something has gone very wrong.
Companies do register domains before launching products and don't want to leak them. Now, I still support Microsoft and other companies to list the domains they send official emails from.
Why would that not be possible?
You can still do that and then once the rabbit is out add it to the main list.
Come on, don't let the good be the enemy of the perfect.
I'm sure there are several ways to find and list all domains.
What bothers me more is that they allowed to have different domains in the first place. Why not sub domains to make it clear.
That's what I said? Companies can hide domains while they are under development but then they should still maintain a list that they send emails from. I was opposed to legislation that required all registered domains regardless of use being published.
This isn't really about QUIC so much as it is about developer experience. Authentication, confidentiality, integrity, congestion control, reliable+ordered streams etc. are all fundamental features of the protocol, so of course it's a bit beefy. Those LoC have to be written somewhere - whether in the kernel or in userspace makes little difference, semantically. The reason that QUIC is a library is because it's still relatively new. That said, support for creation of QUIC sockets in the Linux kernel is underway (https://lwn.net/Articles/1029851/).
What's to stop Iran from using the threat of cutting those cables as leverage? A speedboat and a depth charge are all it takes, and neither are particularly difficult to make.
The threat of force is much more potent than the actual use of force: this has been the delicate dance that the US has used with Iran since the Revolution.
It took an idiot to try and actually use the full force of the USAF against Iran and reveal that the force was manageable- not great, but not going to topple the regime. And once that force was used and Iran's leaders realized it could be survived, that threat became much weaker, forcing a decision onto that previously mentioned idiot, he could either escalate to use greater force (some form of ground troops) or admit that he made a mistake and lost a war. And I suspect that the same will be true for Iran: the threat of cutting those cables is far more potent than the actual effects of cutting the cables.
The Internet is, it turns out, pretty good at routing around damage. The Russians have done some cable cutting in the Baltic Sea and it is annoying but it is not a winning move.
> The enormous pile of ordnance floating in the gulf of oman that can be easily dropped on Tehran, for one
Probably not. The other comment is right: cutting cables means having its own cables cut. (Tehran is also probably weighing whether it wants to continue mobilising almost all of its neighbors against itself. Trashing e.g. Kuwait for shits and giggles isn't strategically productive.)
> might be a good time for some good old-fashioned false-flag action
It's always "a good time for some good old-fashioned false-flag action" if you can pull it off. Given Riyadh and Abu Dhabi are already bombing Iran, and are now unaligned, there wouldn't be much for the U.S. to gain from something like this. (And if Israel were to pull off a false-flag operation against the U.S. now isn't better or worse than tomorrow or yesterday.)
What do you mean by safe config? If you're trying to mandate a cooldown period or a whitelist/blacklist of packages, the correct approach is to configure a company-controlled registry that pulls from the upstream npm registry while enforcing your desired policies.
Whether the config is the registry URL or the cooldown timer you still need it on your dev machines and people to use tools that use it (the latter is especially a problem with docker in my experience, people find out testcontainers or whatever is pulling from docker hub rather than the company registry only when their CI build fails from rate limits)
What I'm saying is that the policy should be enforced server-side. So you block the npm registry in the company firewall, and set up a company-specific registry that acts as a blessed proxy to the npm registry but enforces your desired policies. For example, if you configure your registry to refuse to pull packages published less than a week ago, then it doesn't matter if a client disables dependency cooldowns in their npm config - they still won't be able to "npm install totally-new-not-a-virus-pkg".
People can still bypass these measures if they're determined enough (offline package installs, vendoring dependencies, etc.) but making circumvention impossible to do accidentally and inconvenient to do deliberately solves the problem 99% of the way.
Which isn't particularly difficult - the language docs and std source come with the installation, so all you need to do is tell Claude where those directories are in your skill/plugin/CLAUDE.md.
> and guide it closely (in which case it's useful for focused work)
It does struggle sometimes with writing code that compiles and uses the APIs correctly. My approach to that so far has been to write test blocks describing the desired interface + semantics, and asking Claude to (`zig test` -> fix errors) in a loop until all the tests pass.
You're already at a disadvantage having to stuff the context and spend extra tokens coercing the model in the correct direction compared to it already knowing what to do (rust, ts, go, etc.)
Here, I just did a quick test with claude.
1. "make a simple tcp echo server that uses rust"
compiles and runs - took a few seconds to generate.
2. "make a simple tcp echo server that uses zig"
result: compile error, took literal minutes of spinning and thinking to generate
response: "ziglang.org isn't in the allowed domains. Let me check if there's another way, or just verify the code compiles conceptually and present it clean."
/opt/homebrew/Cellar/zig/0.15.2/lib/zig/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it
@compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it");
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3. "make a simple tcp echo server that uses zig 0.16"
result: compile error:
zig build-exe main.zig
main.zig:30:21: error: no field named 'io' in struct 'process.Init.Minimal'
const io = init.io;
^~
4. "make a simple tcp echo server that uses zig 0.15"
result: compile error
zig build-exe main.zig
/nix/store/as1zlvrrwwh69ii56xg6yd7f6xyjx8mv-zig-0.15.2/lib/std/Io/Writer.zig:1200:9: error: ambiguous format string; specify {f} to call format method, or {any} to skip it
@compileError("ambiguous format string; specify {f} to call format method, or {any} to skip it");
Rust took seconds and just works. Zig examples took minutes and don't work out of the box. The DX & velocity isn't even close.
i mean, if zig is doing its best (inadvertently) at shooing off slop jockeys, then i already have more confidence that:
1. the language and stdlib are written by people who know what they're doing
2. packages in the ecosystem, at the barest level, are written by those who didn't leave after a few compile errors they couldn't reason about
The agents will churn their way through the errors. The new users whose learning material is out of date, as well as the existing users that have an insurmountable task in updating their code, will give up instead.
I think the changes are improvements, but there's a real cost to language churn, and every time it happens, the graveyard of projects grows just that little bit larger.
The cost plan is a crude approximation of the actual query cost. Sometimes, the query planner makes a terrible guess. Your resident DBA won't appreciate being sometimes paged at 3 AM on a Sunday. A good strategy is to freeze the query plan once you have sufficient sample size of data in the involved tables.
Perhaps not every aspect of the query plan can be dictated, but both MySQL and Postgres (with pg_hint_plan) allow you to specify hints that enforce specify join order and scan behavior for the tables in your query, which is where the majority of "unexpected change in query plan" problems will arise. As for SQLite, I'm less familiar with the knobs available for query tuning, but a cursory Google tells me that join order is respected when using CROSS JOIN, and index usage can be forced with INDEXED BY/NOT INDEXED.
As a corollary, will we see a recurrence of congestion in the middle as FttH sees increased adoption? It's easy to believe that 10 Gbps ought to be enough for everyone, but history tells us that people will find a way to saturate any unused bandwidth (8K video with crazy bitrates, 1 TB video game installs, etc).
A content delivery network (CDN) or content distribution network is a geographically distributed network of proxy servers and corresponding data centers. CDNs provide high availability and performance ("speed") through geographical distribution relative to end users, and arose in the late 1990s to alleviate the performance bottlenecks of the Internet[1][2] as it was becoming a critical medium. Since then, CDNs have grown to serve a large portion of Internet content, including text, graphics and scripts, downloadable objects (media files, software, and documents), applications (e-commerce, portals), live streaming media, on-demand streaming media, and social media services.
That's why you sandbox. You can mitigate most low-hanging DoS fruits by running your server side hooks in a per-tenant cgroup that limits CPU and memory usage. One tenant per public key for trusted contributors, and one general-purpose tenant shared by all new/unknown contributors.
If the existence of a domain/subdomain is considered sensitive information, then something has gone very wrong.
reply