Input: random noise
Output: still noise, but packaged in neat little boxes

https://techhub.social/@qcon/117452363635213656

RE: https://techhub.social/@qcon/117452363611498402

So I guess everyone presenting at QCon these days is on drugs.

The paper identifies the same trend we capitalized on in #LMDB: pure in-memory database designs are stupid. Workloads always grow to exceed the size of RAM.

This is especially true today as RAM prices continue to skyrocket. The smartest approach is a design that lends itself to being paged out to secondary storage.

And yes, the same problem we noted when designing LMDB: textbooks only show fixed-size records. Useless for real-world work.

B-Trees Are Back: Engineering Fast and Pageable Node Layouts (2025)

Large main memory capacity and even larger data sets have motivated hybrid storage systems, which serve most transactions from memory, but can seamlessly transition to flash storage. In such systems, the data structure of choice is usually a B-Tree with pageable nodes. Most academic B-Tree work considers only fixed size records, making them unsuitable for most practical applications.

https://www.cs.cit.tum.de/fileadmin/w00cfj/dis/papers/btrees-are-back.pdf

Ironically, all of these LLMs are powered by OpenLDAP software now (LMDB). They would never have been practical without it.

https://mastodon.social/@hyc/116092813763297005

It's taken years of intensive testing, profiling, benchmarking, and design to turn OpenLDAP into the world's most efficient and reliable directory software. No LLM could ever produce anything close to it. (Some have tried https://mastodon.social/@hyc/116125968443855083
)

#OpenLDAP has always been and will always be purely human-crafted code. #NeverSlop.

https://mastodon.social/@hyc/112881667025867206

Shake to summarize page? Yeah definitely don't need that in my car

A memorial to SleepyCat Software, the makers of BerkeleyDB. https://rip.so/sleepycat-software.html

With a brief mention of #LMDB

LMDB was designed to streamline the workflow we arrived at with BerkeleyDB, for maximum efficiency. Doing extraneous steps like repetitive DB open/close defeats the purpose.

Much of what was necessary with BDB was eliminated. E.g., BDB used special options to retrieve portions of a value, when you only wanted a small piece of it. Necessary because BDB had to copy the piece into a buffer to return. LMDB just gives you a pointer, whether you need a small piece or the whole thing doesn't matter.

Using #LMDB from Common Lisp

https://borretti.me/article/lmdb-from-common-lisp

Seems ok but makes a common mistake: DB handles are meant to be opened and stay open after a txn commits. Opening and closing them in every txn is a waste of time.

RE: https://c.im/@cdarwin/117289566525453322

Nobody gets memorialized on monuments while they're alive. If trump wants to be on so many monuments, he's missing Step 1...

Tfw... you had a great new pun in mind, but then got distracted by work and forgot it, and spend the following day trying to remember what it was

RE: https://mastodon.acm.org/@avandeursen/117246078091448872

Idly wishing that everyone comes to their senses and starts running their own servers again...

#LMDB 1.0.2 released. This is mainly just a small fix for Windows WRITEMAP support, other platforms have no functional changes. https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/thread/NALMGAVWIBY7YR4RT4JQERKIX72JNTFH/

RE: https://kolektiva.social/@BASH/117176376939682397

Maybe this will get people writing lightweight web pages again. LoRa data rates are in the tens of kbits/sec. Comparable to GPRS speeds.

It's all fine by me; when I wrote the highlandsun.com page I tuned it for 1sec download at 38.4kbps.

Mesh networking is cool, btw.

RE: https://mastodon.bsd.cafe/@gumnos/117218442940653329

Seems like it's also always rust these days. Rust & LLMs, go together like cholera and dysentery

I would continue to advocate for "Computer Engineer" as the profession. I.e., the education must include both hardware and software principles, because you can't write good software if you're totally ignorant of how the hardware works. https://ruby.social/@CoralineAda/117185994234823373

To deal with that, I added mark/release functions, which I first encountered doing dynamic memory in Turbo Pascal back in the 1980s.

So the idea was, at the beginning of generating one search response, set a Mark in the slab. After the response is sent, do a Release which resets the slab state back to where the Mark was set. This gave us lightning fast request processing. But then we had further complications...

I first wrote sl_malloc.c in April 2003. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/sl_malloc.c?ref_type=heads

The intention was to grab a slab of memory on every incoming operation, allocate from it as needed like a stack to process the request and generate the response, never do frees, and just reset the slab when the processing completed.

It was complicated by the fact that a Search request usually yields multiple response messages.