Merkle trees and build systems

Well, rpm and apt systems implement all this from archives (cpio or or) so it’s perfectly practical and has been done for a long time now. Maybe ostree makes it more practical, maybe not. It’s hard to compare a mature ecosystem that had to solve the 20% of make-it-fully-work problems that take 80% of implementation energy with an ecosystem that implemented the 80% easy part and had not have to deal with the 20% hard part yet (and does not have the warts and scars resulting with this part).

And I strongly suspect that a lot of the parts where you would find existing systems inefficient, are inefficient because rpm and apt systems have to deal with the real world, where code maintenance and ownership is distributed, and you do no have a single dev entity owning the whole codebase that can do whatever it wants at all stages of the build in its own custom (ostree) sets.

From this POW the article (IMHO) mistakes the convenience of a single unified BSD-style build tree with the convenience of ostree itself. Unified build trees *are* definitely more convenient, they just do not scale to the messiness of real life dev organization structures.

Anyway, I did write that the result looked convenient, so no criticism of the ostree implementation on my part, just reacting to people that implied ostree invented hot water.