Key point here: what country or company, in light of this memo, would permit American corporation-owned tech anywhere in their stack, knowing it could be turned into a threat actor's beachhead at any moment?
https://postquantum.com/cyber-kinetic-security/cyber-privateers-what-breaks/
Ordered 2 new kufiyas from the latest Hirbawi restock at https://www.kufiya.org/collections/restock for my collection. If you want a kufiya made in Palestine, this is your source.
A programmer who won't read source code is a writer who won't read prose.
By which I mean, in the wrong job.
Luigi made himself a folk hero.
The billionaires need reminding that more people support him than them.
With a cold cache, a random access workload will always be bounded by your storage device's IOPS spec, minus any other system/software overheads. There's no magic to avoid that. LMDB wins because it's the simplest, lightest weight code with the least overhead.
In the benchmark of 40,000 24kB image files, he notes that LMDB shows the largest drop in performance between sequential and random ordered lookup. But he fails to mention that LMDB's slowest performance is still the fastest in both workloads. A 74% drop in perf is a bit of a shame but immaterial when everything else is always slower.
When the dataset does not fit in RAM
Parquet, WebDataset and #LMDB solve the same problem by different routes: making it possible not to read. Anatomy of the columnar format, batch reading with constant memory, and a benchmark measured cold over 30 million rows and 40,000 samples — with the numbers, the code and the primary sources.
https://manpla.net/en/posts/when-the-dataset-does-not-fit-in-ram/
A high-performance #LMDB backend for konserve using Project Panama FFI (Java 22+).
* Zero-copy reads via LMDB's memory-mapped architecture
* Projection: read one field out of a range of values without decoding them (below) — 49x PostgreSQL JSONB on the case it is built for
https://github.com/replikativ/konserve-lmdb
These guys get it: store records in a format that requires no deserialization, then you can get direct access to subfields of large complex records instantly.
RE: https://beige.party/@cap_ybarra/117078920641433367
Present company excepted
Cats never complain that the bed isn't made #catsofMastodon
This was published 114 years ago Today
The #LDAPCon 2026 programme is now online!
We’re excited to share the programme for this year’s conference.
👉 https://www.conftool.net/ldapcon2026/sessions.php
Three days packed with technical talks, practical insights, and plenty of opportunities to connect with the #LDAP and identity community.
If you haven’t got your ticket yet: Early Bird tickets are available until 31 August.
Explore the programme, plan your LDAPCon experience and secure your place at the conference.
We look forward to seeing you in Tübingen!
Surprising good news from 🇫🇷 !
"France's Constitutional Council strikes down social media ban for under-15s"
"In its decision, the Constitutional Council raised concerns about the possible impact on privacy from instituting an age-verification system for all users."
Wow! I was not expecting this at all.
Never fall for the seductive idea that wealth tax is just about raising money. It would still help the economy if you taxed them and then set fire to the money.
Reason being that excessive money is used to out compete you for all your real resources, from housing, to medicine, to food. The price goes up because they can always pay more.
What we really need is rebalancing of power.
Thought about switching to a binary log format. We could just use pcap, and then use tcpdump or wireshark to view our logs. https://lists.openldap.org/hyperkitty/list/openldap-devel@openldap.org/thread/QR5VU4PKPXBXMO5NLHKMEP6L64UGKFBP/#R7DBSYSAFVDBLIYROMNO3MC3TVKTJJLG
But in the end, we decided to just keep appending messages to a plaintext file. It's still a bit slow, but nowhere near as bad as sending syslog messages to systemd-journald.
Syslog has been a pain point for OpenLDAP for a long time; enabling logging would drop our query rate by around 100x. Slapd would actually hang waiting for journald to flush its messages.
There were problems on the glibc side too, which we hacked around https://lists.openldap.org/hyperkitty/list/openldap-devel@openldap.org/message/XTRFXDT3LSW2DHT4HJANORHFXIBJNJQE/
It's most likely zeros anyway, since it's probably a fresh page at the end of the file.
When you're appending data to a file, a normal write() syscall is the most efficient approach. Appending via mmap is at least 2x slower because of the wasted page-in.
Obviously I'm a major proponent of the use of mmap but there are some things it's bad for, and this is one of them. They clearly didn't know wtf they were doing.
Their decision to do all log writes via mmap is horrible, though. A writable mmap is only a performance win when you're rewriting memory pages that are already in RAM.
But a log workload is always writing new data to new disk pages. This is the worst possible way to do writes, because the pages are always absent first. The kernel must page them in on reference, but that's a wasted I/O because you're just going to overwrite the page, you don't need the data that got paged in.
A discussion of how atrociously bad systemd-journald is https://news.ycombinator.com/item?id=49290215
It's shocking how ignorant the journald guys are of how file I/O and storage devices work, and how utterly unreliable their code is.
Someone suggested using LMDB as the backing store instead but I'm not convinced that's the right answer either.
The main task, *being a log*, is purely append-only. Adding indexing of specific fields could use anything, I guess LMDB would be ok.