pradn

They have a super fast and slick file storage app. Some of the features that are natural additions to that feature set work quite well, like document scanning. But so much of what Dropbox does seems like they can't stay put and be happy with their core offering. Of course, they have to do this to increase revenue, for fear of becoming a mere commodity. It's tough.

Thanks for writing a balanced article - much easier to take your arguments seriously! And a sign of expertise.

How can anyone actually defend these silly, self-defeating tariff maneuvers?

There's already this hilarious bot. It's able to use people's outfits to woo them, or insult them. It's pretty good!

https://www.instagram.com/rizzbot_official/

Random sampling over time is substantially as effective as having someone enforce the law 100% of the time. It's something like how randomized algorithms can be faster than their purely-deterministic counterparts, or how sampling a population is quite effective at finding population statistics.

All this points to "personality" being a big -- and sticky -- selling point for consumer-facing chat bots. People really did like the chatty, emoji-filled persona of the previous ChatGPT models. So OpenAI was ~forced to adjust GPT-5 to be closer to that style.

It raises a funny "innovator's dilemma" that might happen. Where an incumbent has to serve chatty consumers, and therefore gets little technical/professional training data. And a more sober workplace chatbot provider is able to advance past the incumbent because they have better training data. Or maybe in a more subtle way, chatbot personas give you access to varying market segments, and varying data flywheels.

I'm sure we're already there with musicians as well. If you take Taylor Swift's annual revenue and multiply it by 5-10, you'll easily cross a billion. But she does require tons of staff for the stadium shows that provide the bulk of the revenue, etc. Not literally one person, but it's a company with a bus factor of one.

Just complaining that the world is bad is a good way to waste your energy and end up being a cynic.

So why is not all information organized in structured, open formats? Because there's not enough of an incentive to label/structure your documents/data that way. That's if you even want to open your data to the public - paywalls fund business models.

There have been some smaller successes with semantic web, however. While a recipe site might not want to make it easy for everyone to scrape their recipes, people do want Twitter to generate a useful link preview from their sites' metadata. They do that with special tags Twitter recognizes, and other sites can use as well.

The good news is that LLMs can generate structured data from unstructured documents. It's not perfect, but has two advantages: it's cheaper than humans doing it manually, and you don't have to ask the author to do anything. The structuring can happen on the read side, not the write side - that's powerful. This means we could generate large corpuses of open data from previously-inaccessible opaque documents.

This massive conversion of unstructured to structured data has already been happening in private, with efforts like Google's internal Knowledge Graph. That project has probably seen billions in cumultative investment over the years.

What we need is open data orgs like Wikipedia pick up this mantle. They already have Wikidata, whose facts you can query with a graph querying language. The flag example in the article could be decomposed into motifs by an LLM and added to the flag's entry. And then you could use SPARQL to do the structured query. (And that structured query can be generated from LLMs, too!)

LLMs and structured data are friends.

Finally, someone from the product side got a word in. Keep it simple!

A silly question: do any of these models generate pixels and also vector overlays? I don't see why we need to solve the text problem pixel-for-pixel if we can just generate higher-level descriptions of the text (text, font, font size, etc). Ofc, it won't work in all situations, but it will result in high fidelity for common business cases (flyers, websites, brochures, etc).

You can't avoid sending the user photos in a news article, for example. So the best you can do is start fetching/rendering the page 200ms early.

I'm with you - there are few elevators, yes. Still somewhat clunky for me.

Cyberpunk is certainly an achievement for technical graphics - fog, light, reflections etc. These are all enhanced with cutting-edge hardware.

What I'm trying to say is that we're quite far along in one visual axis, but for the whole experience to be amazing, we have a lot of work to do in other axes. Clunky character animations and body shapes take away from the amazing fidelity we get with light/fog, etc.

A large section of the gaming public sees photo-realistic games as serious, and prefers them for high-budget games. It's a rat race for devs though - its just incredibly expensive to create high quality models, textures, maps.

I've been playing Cyberpunk 2077, and while the graphics are great, it's clear they could do more in the visual realm. It doesn't use current gen hardware to the maximum, in every way, because they also targeted last-gen consoles. I'm thinking in particular of the PS5s incredibly fast IO engine with specialized decompression hardware. In a game like Rachet and Clank: A Rift Apart, that hardware is used to jump you through multiple worlds incredibly quickly, loading a miraculous amount of assets. In Cyberpunk, you still have to wait around in elevators, which seem like diegetic loading screens.

And also the general clunkiness of the animations, the way there's only like two or three body shapes that everyone conforms to - these things would go farther in creating a living/breathing world, in the visual realm.

In other realms, the way you can't talk to everyone or go into every building is a bit of a bummer.

Recently, some of it seems to be just to highlight raytracing hardware. Cyberpunk uses a lot of metal reflective surfaces to give a futuristic/tech vibe. But that's one sort of futurism. There'll be plenty of use of natural stone, wood, and tile far far into the future.

> Btw, we are releasing GPT-5 soon, and we’re excited for you to try it. But just to be clear: the IMO gold LLM is an experimental research model. We don’t plan to release anything with this level of math capability for several months.

GPT-5 finally on the horizon!

I can't imagine voluntarily giving access to my data and also being "scared". Maybe a tad concerned, but not "scared".

They say its easier to change your company to fit SAP than to mold SAP to fit your company.

I hear about the "Django philosophy" in this thread. What exactly is it?

I’ve bought a bunch of games just to support the creators, to vote with my dollar and say: I want more of this. Dwarf Fortress comes to mind as an example. I’ve got to sit down and learn to play it. Will probably take a week!

I couldn't immediately find information about how the metadata is stored? Is it one shadow file per RAW file, as I've seen in other OSS RAW editors?

I'm not sure what the perfect solution is, but it is hard to sync a ton of shadow files to cloud storage, versus one big catalog file.

Is the metadata in an open format, so I can take the edits to other programs?

I am glad there's alternatives to having to shell out for Light Room every month. I only need to edit RAW files after holidays!

Yes, the field is littered with imperfection.

One thing though - if you do take the time to learn the original "perfect" versions of these things, it helps you become a much better system designer. I'm constantly worried about API design because it has such large and hard-to-change consequences.

On the other hand, we as an industry have also succeeded quite a bit! So many of our abstractions work really well.

In the simple (albeit niche) case, a UI could populate a list of buttons based on the URIs/verbs that the REST API returns. So the UI would be totally dynamic based on the backend - and so, work pretty generically across REST APIs.

But for a client, UI or otherwise, to make use of a dynamic set of URIs/verbs would require it to either look for a specific keyword (hard coding the intents it can satisfy) or be able to semantically understand the API (which is hard, requires a human).

Oddly, all this stuff is full circle with the AI stuff. The MCP protocol is designed to give AIs text-based descriptions of APIs, so they can reason about how to use them.

> REST isn’t about exposing your internal object model over HTTP — it’s about building distributed systems that behave like the web.

I think I finally understand what Fielding is getting at. His REST principles boil down to allowing dynamic discovery of verbs for entities that are typed only by their media types. There's a level of indirection to allow for dynamic discovery. And there's a level of abstraction in saying entities are generic media objects. These two conceptual leaps allow the REST API to be used in a more dynamic, generic way - with benefits at the API level that the other levels of the web stack has ("client decoupling, evolvability, dynamic interaction").

You have to be careful to make a distinction being in the EU and using the Euro as your currency. You can benefit from the EU common market, with its uniform rules/standards, easy capital flows, subsidies, and industrial policy. All without using the Euro as your currency, and being subject to the monetary policy of the ECB.

Being in the EU without using the Euro has been pretty good for Poland.

I think you're right. APIs have a lot of aspects to them, so describing them is hard. API users need to know typical latency bounds, which error codes may be retried, whether an action is atomic or idempotent. HATEOAS gets you none of these things.

So fully implementing a perfect version of REST is usually not necessary for most types of problems users actually encounter.

What REST has given us is an industry-wide lingua franca. At the basic level, it's a basic understanding of how to map nouns/verbs to HTTP verbs and URLs. Users get to use the basic HTTP response codes. There's still a ton of design and subtlety to all this. Do you really get to do things that are technically allowed, but might break at a typical load balancer (returning bodies with certain error codes)? Is your returning 500 retriable in all cases, with what preferred backoff behavior?

"... between 1988 and 2004, hardware got 1600 times faster, and LP solvers got 3300 times faster, allowing for a cumulative speed-up factor higher than 5 × 106, and that was already 20 years ago!"

"The authors observed a speedup of 1000 between [the commercial MILP solvers of] 2001 and 2020 (50 due to algorithms, 20 due to faster computers)."

I wonder if we can collect these speedup factors across computing subfields, decomposed by the contribution of algorithmic improvements, and faster computers.

In compilers, there's "Proebsting's Law": compiler advances double computing power every 18 years.

It's easier to keep doing something incremental than to fundamentally change things.

One avenue these phone OS, and any consumer OS, can pursue is making it easy to string together app sub-steps. An app can be "cracked open" into sub-step a) either by developers themselves b) or by a backend process at app submission time. The backend process could look at the screens, and see what the user journeys are - this is within reach for current LLMs. An "sub-step" here is like taking a flights app and turning it into different types of search functions - search by date, location, points etc. So an app becomes a bunch of interfaces.

Once you have these "sub-steps" a local LLM can string them together, because it can understand their inputs, outputs, and behaviors.

Actually executing the sub-steps would require the OS to execute the app in the background and run the sub-steps for the user. This would be akin to what browser agents do right now

So this is a way of semantically extracting the "verbs" in existing apps.

With a library of these "sub-steps" in apps, combined with similar ones extracted from the internet - you could chain together the web and native worlds, in the service of the user.

It's easier on phone OSs because phone apps are usually already logged in. It's realistic for iOS to just do a bunch of stuff for you in the background. You really can probably get finance info from all your finance apps, for example.

I'm not saying this is necessarily the answer - but re-thinking the OS in this sort of what is what would be an actually ambitious thing for Apple or Google to do. All these small tweaks are opiates.

There's two problems being discussed in this article and thread:

1) Combining OLTP and OLAP databases into one system

2) Using an open data format to be able to read/write from many system (OLTP/PostGres, analytics engine/Spark)

> I'd argue the bigger value is keeping the data in one storage place and bringing the compute to it.

Yes, I agree with you. This observation is the idea behind #2, and why Iceberg has so much momentum now.

Their product looks promising. It looks like the PostGres schema and writes have to be "Iceberg-aware": special work to get around the fact that a small write results in a new, small Parquet file. That's not the end of the world - but perhaps ideally, you wouldn't be aware of Iceberg much at all when using PostGres. That might be a dream though.

Fully using PostGres without awareness of Iceberg would require full decoupling, and a translation layer in between (Debezium, etc). That comes with its own problems.

So perhaps some intimacy between the PostGres and Iceberg schemas is a good thing - especially to support transparent schema evolution.

DuckLake and CrunchyBridge both support SQL queries on the backing Iceberg tables. That's a good option. But a big part of the value of Iceberg comes in being able to read using Spark, Flink, etc.

The small writes problem that Iceberg has is totally silly. They spend so much effort requiring a tree of metadata files, but you still need an ACID DB to manage the pointer to the latest tree. At that point, why not just move all that metadata to the DB itself? It’s not sooo massive in scale.

The current Iceberg architecture requires table reads to do so many small reads, of the files in the metadata tree.

The brand new DuckLake post makes all this clear.

https://duckdb.org/2025/05/27/ducklake.html

Still Iceberg will probably do just fine because every data warehousing vendor is adding support for it. Worse is better.