So, this certainly was a valid argument. But it seems to me that the whole value proposition behind these agentic AI coding tools is to be able to move beyond this. Are we very far from being able to define some Figmas and technical specs and have Codex generate the UIs in 5 different stacks? If that isn't a reality in the near future, then why should we buy AI Tools?
It's possible to build an identity system that can assert certain properties about a person (eg. "older than 16") without revealing any other details about that person. Similarly, it's also possible to build such a system where the identity system can attest these details without knowing which website is being accessed. That way, the social media site (or whatever other "adult" service) can validate the user is old enough, while the identity system doesnt track who is using what.
Doesn't Apple have an ARM "Architectural License" arising from being one of the original founding firms behind ARM, which they helped create back in the 90s for the Apple Newton. That license allows them to design their own ARM-compatible chips. The companies they bought more recently gave them the talent to use their existing license, but they always had the right to design their own chips.
It's interesting to think that Google's Antigravity is a forked version of MSFT's VS Code, which uses a browser engine built by Google, which they forked from Apple, which they forked from KHTML.
I would have expected that consumer GPUs still have higher volume, but that Datacenter GPUs have much, much higher margin and therefore significantly higher revenue and profit. Is that not the case?
Datacenter GPUs definitely amount to a bigger volumn in 2025[0]. But even when it wasn't the case, Nvidia had been running at a very high margin for years.
If Nvidia made SoC GPUs for mobile devides, then they'd might have higher volume, depending on market share. But gaming and workstation PCs that benefit from a high-performance discrete GPU are a pretty niche market these days, whether laptop or desktop.
It also seems like a really bad decision from Slack's POV.
1) They should know that this is unaffordable for a nonprofit like this. By doing this, they will almost certainly lose them and their thousands of aspiring teenage developers as users. The chance of actually booking that 200K are next to 0.
2) Microsoft learned a long time ago the value of getting young developers using your software to learn. Once those teens start working, maybe starting their own companies or choosing which tools to use at their future empoyers, if they know Slack they are very likely to pick Slack. This is a very short sighted shakedown attempt that wont work in the short term but will drive people away in the medium term.
JSON Web Tokens are part of the JSON Object Signing and Encryption (JOSE) family of standards which are really just containers for cryptographic primitives in a web-friendly representation. Most people are aware of JWS (signed payloads) but there are also JWE (encrypted payloads) and JWK (key payloads). If you're building any sort of cryptographic system that needs to represent encrypted/signed values or keys, you can use JOSE to represent these primitives without having to reinvent the wheel. By far the biggest use of JOSE is in authentication systems where JWS are used as signed bearer tokens but that's just one application and there are many others. They arent perfect, but they filled an important gap when they were created and made it much easier to deal with crypto at an application layer compared with all of hte binary formats that are used in things like TLS.
Enterprise customers often have split tunnel VPNs or proxies (with PAC configs) where part of the traffic may go through a VPN and another part goes directly. So for example a customer admin might configure an app that does email and webRTC so that the real time traffic (media and the associated signalling) goes directly and the email traffic goes via some TLS intercepting proxy for some compliance reason or DLP. This can result in one application having multiple public IPs for different network requests, even while they are on one internal network (not even jumping between networks like you say). That isnt something that the application author can control, it's the customer admin that decides to do that.
Whenever they have, they have been bought by larger and richer (mostloy US) tech companies. Look at Deepmind, Skype, Nokia, Tandberg, etc... Arm is another (although Japanese rather than US-owned). There are also many cases where European founders base their companies out the States for access to higher funding (eg Stripe, Spotify). Another factor is that US multinationals have a large presence across Europe in terms of employment - if a large component of the top tech talent of Europe is employed by US companies then they are less likely to build large European companies.
reply