4 ms·
As a general principle, I think low-level APIs shouldn’t provide abstractions that are both expensive and have no clear “best” design: in those cases, you want
by codeflo 4y ago
As a general principle, I think low-level APIs shouldn’t provide abstractions that are both expensive and have no clear “best” design: in those cases, you want your applications to have the ability to make different trade-offs, rather than being locked in to a design that might be suboptimal for your usecase. I think sibling comments explain nicely how that’s the case for transactions; I just wanted to point out why that matters in the big picture. Similar arguments can be made for other higher-level features that someone might wish their OS provided, like (tracing) GC.
- klodolph 4y agoOur existing file APIs already provide abstractions that are both expensive and have no clear best design. There’s a lot that these APIs hide from you in order to make it so you can pretend that this is the 1970s and your file is essentially a piece of tape. We’ve then built filesystems and directory structures on top of this piecemeal. The abstraction covers all these fancy journaling structures and a whole page cache. For something that dives into the consequences, the classic paper “Don’t stack your log on my log” https://www.usenix.org/system/files/conference/inflow14/inflow14-yang.pdf https://www.usenix.org/system/files/conference/inflow14/infl...
- deadmutex 4y ago> Our existing file APIs already provide abstractions that are both expensive and have no clear best design. Even if that is the case, lets not make it worse :).