I knew before I opened the article that this was going to be about or at least include the Jumping <Food> entries. Happy to be right, and for them to be gone.
Why? Sqlite and LMDB make fantastic use of it. For anyone doing a single writer db it's a no brainer. It does so much for you and it does it very well. All the things you don't have to implement because it does it for you:
- Reading the data from disk
- Concurrency between different threads reading the same data
- Caching and buffer management
- Eviction of pages from memory
- Playing nice with other processes in the machine
Why would you not leverage it? It's such a great fit for scaling reads.
The strongest argument as far as I can see it is... the problem is you now lose control over all those things. It's a black box with effectively no knobs.
Anyways, read for yourself, Pavlo & Leis get into it in detail, and there's benchmarks:
What am I missing? The transactional safety problem (the bulk of the paper) is solved simply with a single writer. Which is where you want to be anyway for efficient batching throughput (and isolation).
The other concerns seem to imply there are no other programs running on the same machine as the database. The minute that's not true (is it ever true?). Then OS will do a better job (as seen with LMDB etc).
I think it's telling that the paper focuses on mongoDB not LMDB.
Fun footnote: SQLite only got on board with mmap after I demonstrated how slow their code was without it. I.e., getting a 22x speedup by replacing SQLite's btree code with LMDB https://github.com/LMDB/sqlightning
One foundational misunderstanding in your very first bullet - Universal Blue distros are installable operating systems that happen to use container image formats as a file representation for network distribution and update mechanisms, but you're expected to be running it on actual hardware or as a traditional VM. The outermost "container" part is largely an incidental implementation detail. You don't run these as a workload on like, a Kube cluster, or anything like that.
The underlying project in question for the next conceptual layer down is rpm-ostree:
Why does her hair color matter to you? Why is open source longevity and viability not on-topic for LWN discussion?
Dr Foster holds a PhD, did her dissertation about the Linux kernel, and has had a respectably long career in technology with a focus on open source and governance. The topic is literally straight in her professional wheelhouse.
Very very much so. The project also includes separate binary releases with this feature compiled out altogether, but I'd much rather this sort of feature was never ideated or acted upon in this first place.
Generally speaking I don't want a terminal multiplexer to be doing network IO of any sort, so I also didn't love it when they shipped "load WASM plugins from a non-checksummed arbitrary URL via your config file" in a previous release.
As with my comment in another tree, no, none of the Elixir core team or Dashbit employees are directly involved with this effort, though they may be advising informally and will likely submit a PR here and there.
Nit: there has never been an official LSP implementation until now, only community-authored. Even now no Dashbit employees or language core members are directly involved in this project in an ongoing basis.
IMO that contributes powerfully to the quality of the experiences of using any of the options.
