maltalex

> They would recover the training cost eventually if they stop training

"if they stop training" is exactly the point I'm making. They can't stop training if the competition is still training.

It's hard to say anything about the actual financials with the main players being private companies.

However, we know that users frequently switch models/providers, and that models stay relevant for (increasingly) short periods release. I don't know what the training costs are, but I bet they're very substantial.

These companies have a coordination problem.

They're all burning billions to incrementally one-up each other with no hope of these investments ever paying off since models are interchangeable and have no moat. They're trying to get regulators to step in and force a pause.

This is a very promising idea - a model that takes arbitrary text input (which can be a complex json), plus a set of questions (yes/no, multiple-choice, or score) and quickly (milliseconds) and cheaply ($0.042/MTok) answers those questions.

Unfortunately, none of this is explained in the announcement, but the documentation [0] is pretty good.

[0]: https://docs.typesafe.ai/concepts/how-to-build-with-system-o...

This looks suspiciously cheap.

The same model hosted by other providers is much more expensive [0]. So either DeepSeek can host it much cheaper than anyone else, or their business model is different. I suspect the latter, especially since their privacy policy [1] says personal data, including “User Input,” can be used "To improve and develop the Services and to train and improve our technology".

[0]: https://openrouter.ai/deepseek/deepseek-v4-pro/providers

[1]: https://cdn.deepseek.com/policies/en-US/deepseek-privacy-pol...

Any automation-friendly email hosting is going to have a serious spam problem, and therefore a blacklisting problem.

I suggest taking a look at what providers like Sendgrid, Mailchimp, etc are doing to prevent abuse.

An alternative explanation for this “over-hiring” is that many companies’ operating expenses have grown substantially because of AI spending. Companies can either eat the additional expense, hope AI adoption offsets it, or cut costs.

For most software companies, operating expenses are mostly wages. So, cutting costs means reducing headcount, which is likely especially true in lower-wage regions. If an engineer costs $4K/month, adding $1K/month in token costs increases employment cost by 25%. If an engineer costs $2K/month, the same $1K raises costs by only 5%.

So, I'd argue that everyone should be worried at least to some degree until the industry finds a new equilibrium.

> 1. human verification for auth.

How, at scale?

Wouldn't a "WebRip" have to come from a streaming service by definition?

Only with certificate pinning or something similar. Otherwise, the attacker can get valid TLS certificates for any domain hosted on the hijacked IP addresses.

Here are some examples:

The attacker can impersonate the victim, get a valid x509 certificate issued to it, and create a perfect replica of their website/api/whatever.

The attacker can perform a man-in-the-middle attack on the victim - record traffic, inject traffic, manipulate traffic, etc.

The attacker can just deny access to the victim - just drop packets meant for the victim.

RPKI doesn't make BGP safe, it makes it safer. BGP hijacks can still happen.

RPKI only secures the ownership information of a given prefix, not the path to that prefix. Under RPKI, an attacker can still claim to be on the path to a victim AS, and get the victim's traffic sent to it.

The solution to this was supposed to be BGPSec, but it's widely seen as un-deployable.

Absolutely. They've made the same mess with "Copilot" as with ".NET" in the early 00's [0]. Everything was ".NET" from consumer oriented services (".NET Passport"), to "Visual Studio .NET" without anyone understanding what ".NET" was.

Now it's "Microsoft Copilot" which is different from "Microsoft 365 Copilot", which is different from "Copilot Chat" and from "GitHub Copilot", and the many other flavors.

It's a mess.

Still, their developer-focused offering seems to be "GitHub Copilot", which among other things includes "GitHub Copilot CLI" [1], their terminal-based agent. It's not bad.

[0]: https://en.wikipedia.org/wiki/Microsoft_.NET_strategy

[1]: https://github.com/features/copilot/cli/

“Copilot” is not one product, it’s around 15 different products, seriously.

I think that people often compare apples to oranges by comparing the “copilot” they have in Windows/Office/Teams etc to Claude Code which is ridiculous.

A better product to compare Claude Code to would be “Github Copilot CLI”, but I haven’t seen the two seriously compared anywhere.

> and nobody cares

Everyone cares. In fact, there's an entire industry of tools being developed to solve this very problem. The current governance gaps are obvious to anyone who's ever used an agent.

We are still in the very early stages of all of this. The capabilities of current models are ahead of our engineering practices, and other organizational practices for that matter. Everyone is new to this.

Maybe I'm missing something, but isn't this the same as writing code, but with extra steps?

Currently, engineers work with loose specifications, which they translate into code. With the proposed approach, they would need to first convert those specifications into a formally verifiable form before using LLMs to generate the implementation.

But to be production-ready, that spec would have to cover all possible use-cases, edge cases, error handling, performance targets, security and privacy controls, etc. That sounds awfully close to being an actual implementation, only in a different language.

> Dependabot has some value IME, but all naïve tools that only check software and version numbers against a vulnerability database tend to be noisy if they don’t then do something else to determine whether your code is actually exposed to a matching vulnerability.

For non-SaaS products it doesn’t matter. Your customer’s security teams have their own scanners. If you ship them vulnerable binaries, they’ll complain even if the vulnerable code is never used or isn’t exploitable in your product.

It's not just open source though. Many high quality sources of information are being (over-)exploited and hurt in the process. StackOverflow is effectively dead [0], the internet archive is being shunned by publishers [1], scientific journals are bombarded by fake papers [2] (and anecdotally, low-effort LLM-driven reviews), projects like OpenStreetMap incur significant costs due to scraping [3], and many more.

We went from data mining to data fracking.

[0]: https://blog.pragmaticengineer.com/stack-overflow-is-almost-...

[1]: https://www.niemanlab.org/2026/01/news-publishers-limit-inte...

[2]: https://www.theregister.com/2024/05/16/wiley_journals_ai/

[3]: https://www.heise.de/en/news/OpenStreetMap-is-concerned-thou...

> you are both confusing two issues.

How am I confusing the two? My whole point was the same as yours - that the existence of lawful intercept is a separate issue and that the focus should be on securing telecoms.

I get that you don't like lawful intercept. That's fine. But focusing on only that aspect of telcos derails the conversation and prevents us (in the very broad sense of "us") from making progress on things we all agree on. Can we stop bikeshedding and agree that telcos are critical infrastructure and need to be highly secure in general?

A hacker in control of a telco can do as they please regardless of any backdoors or lawful intercept systems. They can just use regular network functions to route calls wherever they want.

Even if the back door wasn't there, you wouldn't want nation state hackers anywhere near telecoms since they're critical infrastructure. Telecoms should be highly secure. Period.

Yes, telecoms should be forced to invest in their own security if they're not doing it. But the focus on the back door misses the point in my opinion. Even if the back door wasn't there, you wouldn't want nation state hackers anywhere near telecoms since they're critical infrastructure.

The problem isn't the back door. Every telecom company in every country provides access for "lawful intercept". Phone taps have been a thing for decades and as far as I know, require a warrant.

The problem is that telecoms are very large, very complex environments, often with poor security controls. Investing in better controls is hard, time-consuming and expensive, and many telecoms are reluctant to do it. That's not great great since telcos are prime targets for nation state hackers as Salt Typhoon shows.

Hacking the lawful intercept systems is very brazen, but even if the hackers didn't don't go as far, and "only" gained control of normal telco stuff like call routing, numbering, billing, etc. it still would have been incredibly dangerous.

Nice website, but I feel like calling it "wire wiki" is quite ambitious. Currently, it's a (beautiful) DNS lookup tool, but that's about it. I expected something like RIPE Stat [0], or something like the undersea cable map [1] (based on the "wire" in the name). Also, if you're doing DNS, take a look at resolve.rs [2], they have some nice DNS tools, though not as pretty as yours :)

And since you mentioned scanning the IPv4 address space for DNS servers - I did that as well at a some point for a product I've built (and even have a patent on). The list of servers you're going to get with a naive scanning approach is not what you want. It won't include the servers you probably want (such as the customer-facing DNS servers of ISPs) and will include an insane amount of junk like home routers or weird IoT devices that expose their port 53. Hit me up via the email in my profile if you want to chat.

[0]: https://stat.ripe.net/

[1]: https://www.submarinecablemap.com/

[2]: https://resolve.rs/