Monopoly isn't the only thing that allows you to charge large margins.
API inference access is naturally a lot more costly to provide compared to Chat UI and Claude Code, as there is a lot more load to handle with less latency. In the products they can just smooth over load curves by handling some of the requests slower (which the majority of users in a background Code session won't even notice).
It's why every integration basically tries to piggyback off of a subscription, and why Anthropic has to continuously play whack-a-mole trying to shut those services down.
> - A Cmd+C to copy and Ctrl+C for the interruption 7 in the terminal,
I really miss that in Linux. That said, some terminals implement smart Ctrl+C which will interrupt if there's no text selected and copy otherwise. But terminal I use (Gnome Console) does not, so I have to press Ctrl+Shift+C to copy text and then I press that in browser and everything exploded because it opens developer tools. So annoying.
16 random bytes is not a valid UUIDv4. I don’t think it needs to be in the standard library, but implementing the spec yourself is also not the right choice for 99% of cases.
If you generate random bytes, which are unlikely to conform to the UUIDv4 spec, my guess is that most libraries will silently accept the id. That is, generating random bytes, will probably work just work.
I didn't say about 16 random bytes. But you're almost there. You generate 16 random bytes and perform few bitwise operations to set version and variant bits correctly.
Not that it matters. I don't even think that there's a single piece of software in the world which would actually care about these bits rather than treating the whole byte array as opaque thing.
I think it saves labor and eventual bug hunting to include these in a stdlib. We should not be expected to look up the UUIDv4 spec and make sure you’re following it correctly. This feels like exactly what reasonable encapsulation should be.
I had a similar thought a while back. Looking at the code for existing UUID projects, issues they fixed, and in some cases the CVEs, is a good way to form a different opinion.
Some things are actually hard to implement. I'd spent a lot of time trying to implement concurrent hashmap, for example. UUID is not one of these things.
I know it sounds like a good take, but I don’t really see it happening much in real life anymore.
It’s more like the 1x developer gets frustrated and defensive, and shows the 5 stages of grief, try using AI and finds all the reason why it’s bad. Then goes ahead and refactors everything and breaks production.
I’m at this point too. I desperately want to hate AI, but it’s so incredibly competent. People who say LLM’s aren’t good generally just aren’t good at them
> The LFG system basically killed most social interaction in WoW.
I started playing Anniversary vanilla one year ago. I played through it all and now I'm playing Anniversary TBC. I visited many dungeons. There's no LFG system, yet I didn't find any social interactions in dungeons. I'm pretty sure the whole social interactions thing is overblown. 99% of dungeons is like leader silently invites you or you write "inv holy pala GS 1400" and he silently invites you. You silently run through dungeons, silently leave. That's about it. There are no interactions. Zero. Some people write "hi" and "ty", some don't bother.
That's exactly what's happening on Anniversary servers. They crammed like 20 servers into one megaserver, so there are like 100 000 players on the same server and you're very unlikely to meet the same person twice.
> Blizzard could have rolled back LFR/LFG, class homogenization, brought back complicated and unique talent trees, remove heirlooms, re-add group guests and world mini-bosses, remove flying, etc. and players likely would have been happy.
That would be a tremendous failure. There are millions of players who love LFR/LFG, who love somewhat balanced nature of the game, etc. You would lost all of them in favor of Classic players.
The truth is, a lot of changes Blizzard made to the game, were good ones. If you would browse WoW Classic forums, you'd find plenty of players requesting retail features to be added to Classic game. They want LFD because they're tired sitting for hours being denied for dungeons, because their class is not very good. They want class homogenization, because their beloved class is genuinely lacks tools to be useful.
When you make any change to the game, some player will love it and some player will hate it. Over time more and more players will feel alienated. But other players will come and they won't know other game. There's no simple solution here, other than maintain several versions of the game for different players. One size does not fit all.
XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps. That fundamental mismatch caused a lot of friction when people use XML for data exchange between programs. JSON is clear winner here.
XML is absolutely fine for data that maps naturally to it. For example text markup. While HTML technically is not XML, it's very close to it and XHTML still is a thing. Probably most people wouldn't enjoy using JSON to encode HTML pages.
> Probably most people wouldn't enjoy using JSON to encode HTML pages.
Probably yeah, but also, people don't know how enjoyable it is to just use lists and elements within it to represent HTML. Hiccup is a great example of this where you can do something like:
"XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps. That fundamental mismatch caused a lot of friction when people use XML for data exchange between programs. JSON is clear winner here."
I'm not so sure about this. When you have a schema it becomes possible to generate your object code, and then your only immediate interface with the XML file is a rather simple instruction to unmarshal it, the rest of the time you're dabbling within your programming language of choice.
> XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps.
Another way to say this is XML is a grammar formalism that deals purely with serialisation rather than higher-level structures that might be serialised such as co-inductive data structures.
> While HTML technically is not XML, it's very close to it and XHTML still is a thing.
XML and HTML-as-serialisation-format are both subsets of SGML.
I don't think it's a superset. You can represent any structs-and-arrays data in XML, but you have to make non-trivial mappings to make it work.
The obvious way is to use elements for everything, but then you're mapping both structs and their fields (very different concepts in e.g. C) to elements. Attributes map nicely to struct fields, but they only admit string values.
You can map anything to it but that flexibility means you then need to define schemas et al to ensure compliance
The schema thing isn’t actually unique to XML either. you can do the same thing with JSON and YAML too. But in my opinion, if you get into the realm of needing schemas in JSON then you’re at the point where you shouldn’t be using JSON any longer since you’re now violating the “simplicity” argument which is JSONs only real advantage over other formats.
Eh, XML is as much of a superset of JSON as the Turing machine is a superset of context-free grammars. The former has all the _power_ of the latter and more, but the mapping between them is non-trivial, far from an embedding.
I think it's fine to say C#'s data model is a superset of Java's or Rust's a superset of C's, but XML and JSON is too far for me, personally.
Watch how dict2xml or xml2dict handle JSON to XML automatic mapping. Both format carry 99% of the same structural infos in their respective serialization.
Huh? I always felt some of the failure/ bad reputation of XML was how it got tortured by devs who did not understand database normalization. If you “get” 3rd form normalization, xml works fine for the relations you describe, unless I am missing something.
To be clear, I am not being snide and would be interested in the cases you’re thinking of.
For some people maybe. I don't want to use local AI and NPU will be dead weight for me. Can't imagine a single task in my workflow that would benefit from AI.
It's similar to performance/effiency cores. I don't need power efficiency and I'd actually buy CPU that doesn't make that distinction.
> Can't imagine a single task in my workflow that would benefit from AI.
You don't do anything involving realtime image, video, or sound processing? You don't want ML-powered denoising and other enhancements for your webcam, live captions/transcription for video, OCR allowing you to select and copy text out of any image, object and face recognition for your photo library enabling semantic search? I can agree that local LLMs aren't for everybody—especially the kind of models you can fit on a consumer machine that isn't very high-end—but NPUs aren't really meant for LLMs, anyways, and there are still other kinds of ML tasks.
> It's similar to performance/effiency cores. I don't need power efficiency and I'd actually buy CPU that doesn't make that distinction.
Do you insist that your CPU cores must be completely homogeneous? AMD, Intel, Qualcomm and Apple are all making at least some processors where the smaller CPU cores aren't optimized for power efficiency so much as maximizing total multi-core throughput with the available die area. It's a pretty straightforward consequence of Amdahl's Law that only a few of your CPU cores need the absolute highest single-thread performance, and if you have the option of replacing the rest with a significantly larger number of smaller cores that individually have most of the performance of the larger cores, you'll come out ahead.
* You don't do anything involving realtime image, video, or sound processing?
I don't
* You don't want ML-powered denoising and other enhancements for your webcam,
Maybe, but I don't care. The webcam is good or bad as it stands.
* live captions/transcription for video,
YouTube has them. I don't need it for live calls.
* OCR allowing you to select and copy text out of any image,
Maybe
* object and face recognition for your photo library enabling semantic search?
Maybe but I think that most people have their photo library on a cloud service that does AI in the cloud. My photos are on a SSD attached to a little single board ARM machine at home, so no AI.
What I would like to be able to do is running the latest Sonnet locally.
In general I think that every provider will do their best to centralize AI in their servers, much like Adobe did for their suite and Microsoft did for Office so local AI will be marginal, maybe OCR, maybe not even blurring the room behind my back (the server could do it.)
There are alternatives to Adobe and Office, because I don't care about more than the very basic functionality: running Gimp and Libreoffice on my laptop costs zero. How much would it cost to run Sonnet with the same performances of Claude's free tier? Start with a new machine and add every piece of hardware. I bet that's not a trivial amount of money.
None of what I listed was in any way specific to "content creators". They're not the only ones who participate in video calls or take photos.
And on the platforms that have a NPU with a usable programming model and good vendor support, the NPU absolutely does get used for those tasks. More fragmented platforms like Windows PCs are least likely to make good use of their NPUs, but it's still common to see laptop OEMs shipping the right software components to get some of those tasks running on the NPU. (And Microsoft does still seem to want to promote that; their AI PC branding efforts aren't pure marketing BS.)
The issue is that the consumer strongly associates "AI" with LLMs specifically. The fact that machine learning is used to blur your background in a video call, for example, is irrelevant to the consumer and isn't thought of as AI.
Never wanted to do high quality voice recognition? No need for face/object detection in near instant speed for your photos, embedding based indexing and RAG for your local documents with free text search where synonyms also work? All locally, real-time, with minimal energy use.
That is fine. Most ordinary users can benefit from these very basic use cases which can be accelerated.
Guess people also said this for video encoding acceleration, and now they use it on a daily basis for video conferencing, for example.
Those usecases are at least 5 years if not 10 years out. They require software support which won't come until a significant part of the pc market has the necessary hardware for it. Until then, paying extra for the hardware is foolish.
This will only come if Windows 12 requires a TPU and most of the old hardware is decommissioned.
Also similar to GPU + CPU on the same die, yet here we are. In a sense, AI is already in every x86 CPU for many years, and you already benefit from using it locally (branch prediction in modern processors is ML-based).
> Also similar to GPU + CPU on the same die, yet here we are.
I think the overall trend is now moving somewhat away from having the CPU and GPU on one die. Intel's been splitting things up into several chiplets for most of their recent generations of processors, AMD's desktop processors have been putting the iGPU on a different die than the CPU cores for both of the generations that have an iGPU, their high-end mobile part does the same, even NVIDIA has done it that way.
Where we still see monolithic SoCs as a single die is mostly smaller, low-power parts used in devices that wouldn't have the power budget for a discrete GPU. But as this article shows, sometimes those mobile parts get packaged for a desktop socket to fill a hole in the product line without designing an entirely new piece of silicon.
There are Intel CPUs which come with bundled RAM. For example Intel Core Ultra 5 238V. It's like SoM: RAM is mounted directly on the CPU package, not even soldered on the motherboard. I'm not sure what particular advantages does that bring over traditional packaging, maybe shorter wires to allow for faster turnarounds between CPU and RAM. But there's zero chance of upgrading or replacing RAM for sure.
In theory, but that is not the case with Lunar Lake, which nowadays does not have a greater bandwidth than the current CPUs with external LPDDR memory.
However, at launch, a year and a half ago, it had a bandwidth about 15% higher than competing CPUs.
For a really "massive increase in bandwidth", it would have needed a wider memory interface, like AMD Ryzen Max, which has a 256-bit memory interface, instead of the 128-bit memory interface of most Intel/AMD laptop CPUs.
As I understand that situation, GrapheneOS developers are super picky about hardware they want to support. So out of all android phones they decided to support only Google Pixel because only these phones provide good enough hardware support for security features they want to provide.
So likely no existing Motorola phones are good enough and only new ones, developed in collaboration with GrapheneOS developers, will be suitable.
reply