whirlog VS illumos-gate

There are many kinds of databases, I've used similar designs to [0] (Lisp warning, ymmv) successfully in several projects.

[0] https://github.com/codr7/whirlog

I've built several versions of a log based db with composite keys over the years, the most complete version so far in Common Lisp:

https://github.com/codr7/whirlog

I have a fairly comprehensible left leaning rb tree implementation that I've been porting along my travels.

I keep it around for situations where a binary searched array isn't doable or good enough, but I still want ordered set functionality that isn't in the stdlib.

https://github.com/codr7/whirlog/blob/main/rb.lisp

https://github.com/codr7/libcodr7/blob/master/source/codr7/t...

It’s still going, in the form of Illumos: https://illumos.org/

DTrace and eBPF are "not so different" in the sense that dtrace programs / hooks are also a form of low-level code / instruction set that the kernel (dtrace driver) validates at load. It's an "internal" artifact of dtrace though, https://github.com/illumos/illumos-gate/blob/master/usr/src/... and to my knowledge, nothing like a clang/gcc "dtrace target" exists to translate more-or-less arbitrary higher-level language "to low-level dtrace".

The additional flexibility eBPF gets from this is amazing really. While dtrace is a more-targeted (and for its intended usecases, in some situations still superior to eBPF) but also less-general tool.

(citrus vs. stone fruit ...)

We can see it is called sched. Why sched? This article talked about the historic role of PID 0 in process swapping. Process swapping is a scheduling problem (like a lot of problems in software). This is why swappers are traditionally called medium-term or memory schedulers. Illumos generally gives most groupings of kernel worker threads their own processes with their own PIDs, but one, called "sched", remains in PID 0, and its responsibility? Process swapping:

https://github.com/illumos/illumos-gate/blob/579c23696ac6891...

The Wikipedia article has now been hastily edited, and replaces a claim that was true only of certain Unixes other than Linux with a claim true only of certain Unixes including Linux. Is this an improvement?

It may become a footnote on Linux, but Linux isn't the only system out there -- and DTrace remains alive and well in many systems (not least in its reference implementation in illumos[0]).

[0] https://github.com/illumos/illumos-gate

Nobody's paid to have it pass Open Group Unix Branding certification tests

https://www.opengroup.org/openbrand/register/

so it can't use the UNIX™ trade mark.

But it's got the AT&T Unix kernel & userland sources contained in it.

PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...

IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...

> it seems like this bug might actually date back to the very beginning of ZFS with Sun

Looks like you might be right about that. The oldest commit referenced in the fix [0] was from 2006[1], which was just months after Sun released ZFS.

[0] https://github.com/openzfs/zfs/pull/15571

[1] https://github.com/illumos/illumos-gate/commit/c543ec060d

It could be good for in memory stores / log-structured merged trees / other data store applications although it isn't used much now-days. I find them simpler to implement and understand than red-black trees -- although that's a matter of taste I suppose. They beat red-black trees in read-heavy loads (i.e. writes / updates are more costly for AVL trees than for Red-Black trees although they beat R-B trees for read-heavy loads). You can find another implementation in Illumos (an open source Unix operating system) available here: https://github.com/illumos/illumos-gate/blob/master/usr/src/...