He should have divorced first, as expensive as it would have been. Being a single/divorced billionaire playboy is understandable, being a married billionaire playboy is going to be messy.
Why do their models always get Nerf'ed? Is Anthropic doing planned obsolescence or are they trying to encourage use of their latest models? Opus 5.5 was clearly Nerf'ed last week. I think they are at risk of getting a class action lawsuit for deceptive practices with this unannounced "model optimization" that actually changes performance as compared to the advertised performance in the official model cards.
It's frustrating they can't be transparent that they're even doing it, let alone why they're doing it.
They still charge you full price and don't offer any quota resets even though you're getting less value for money while you're working with a nerfed model.
>Why do their models always get Nerf'ed? Is Anthropic doing planned obsolescence or are they trying to encourage use of their latest models? Opus 5.5 was clearly Nerf'ed last week. I think they are at risk of getting a class action lawsuit for deceptive practices with this unannounced "model optimization" that actually changes performance as compared to the advertised performance in the official model cards.
You have psychosis my friend. They don't nerf the models.
> Jpeg-XL's key win was only lossless translation of existing jpeg to a modern format.
Huh?
JpegXL is the only widely supported format (once it comes to the various browser as is planned) that can store true HDR linear images in floating point (fp16 and fp32) formats.
AVIF can only do 10 bit integer ranges, sure that HDR compared to 8bit but it is not sufficient for useful extended range color spaces.
The format is widely supported, but I'd be very surprised if linear HDR becomes widely supported outside of image editors. JPEG-XR supported fp32 linear HDR way earlier anyway, and no one cared because no one cares about linear HDR after editing.
> At the same time I wonder if we are entering an era in which it’s just better to build your own tools
I wonder if Claude Code and other similar tools start to maintain their own base apps that everyone keeps asking for? This would be like a "cache" that makes the requests cheaper/easier to deliver?
Then everyone's "own" apps is really just a customization layer on top of a solid base that already does all the heavy lifting.
So many people are building their own versions of:
- PDF editors
- Word processors
- 3D editors
- Video editors
- Pixel-based image editors
- Vector-based image editors
- CAD editors
etc.
In some of these there are a few flavors as well that are major architectural choices. But most of what people are doing is just playing around with UI and file formats. Much of the functionality is generally the same.
I guess I'm too used to the collaboration features of word processors like Google Docs. If I build my own, those go out the window otherwise everyone has to sign up for my word processor and learn my word processor's UX.
For the rest, at least so far, I haven't had the collaboration experience but for word processors I can't go back to local files that can't easily be edited/viewed/commented on by multiple people or myself on every device I own.
I'm pretty sure this already happens to some extend. Look at the default website output you get from the different models, there tends to be a 'default' look/approach it takes.
I think they all have been post-trained on specific tasks like building sites, apps, etc and that is a large part of the reason they are pretty good at it.
Honestly i think that now is the chance for established software to go with the flow and I think the major way to go with the flow is create are adapt software to be extensible (so that everyone can let claude or opencode or whatever add their functionality of choice without having to rebuilt the wheel from scratch everytime) and secondly direct mcp access to the software itself.
We do need a safe layer for non-engineers to customize apps.
All these clones of Photoshop and similar tools are mostly dead ends, they are experiments to see if you can do it, but there will be a consolidation around regularly maintained and powerful and complete apps that likely also offer support.
These experiments are dead-ends for the most part long-term. Fun play things, but they will not gain significantly user bases.
Isn't this more of an argument to use common OSS choices? Like, encourage people to use Blender for 3d modelling; LibreOffice for documents; Gimp, Krita, or one of the many other art programs for ... art; OBS for simple video stuff; and so on and so forth?
Plugins have long been troubled. It’s hard to make a plugin interface that is actually useful while also not breaking on every app update. And plugins have been such a massive vector for distributing malware.
It's a fun tech demo, egui isn't meant to make websites. It's primarily for integration into games/other real-time-3D-rendered applications, and secondarily for GUI applications via eframe.
But I agree, I think they would be better served by making a normal website and linking to the demo prominently (For comparison, see iced's website https://iced.rs, which is great IMO)
Another way to avoid having to maximize download speed is to use a global git cache per machine in a similar way that pnpm optimizes installing packages:
There is always something useful to learn, even if it's a mistake. pnpm in particular centralizes your packages, and symlinks them to each project that needs them, which cuts down on file copy and disk usage significantly. The same principle could be applied to cargo/rust, python venvs, dotnet, or even large C++ projects could improve their disk usage and file copy significantly if they followed the same idea. Why do you have to have a massive target folder in every rust project if all that could live in a hash addressable shared store. Its the same basic idea of CoW or deduping file systems, but done in the application for far better result.
> This doesn't work if the pulls are happening in swarms of ephemeral sandboxes.
This is incorrect.
It actually will work if you mount a drive. Github mirrors can be on separate drives. Now I haven't fully tested it's safety in that situation yet, like I have with local dev on Windows and MacOS.
> Also, maybe FUD, but is there anything useful to learn from (p)npm other than cautionary tales?
This is also incorrect.
Denigrating pnpm's well regarded optimizations because NPM packages have vulnerabilities unrelated to NPM is missing the point.
reply