“The reasonable man adapts himself to the world: the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man.”
> Mach’s virtual memory (VM) system was influential beyond the project – it was adopted by 4.4BSD and later FreeBSD as their memory management subsystem.
…and NetBSD[0], OpenBSD[1], but apparently not DragonFly BSD[2].
Whilst all three BSDs (386BSD, FreeBSD, and NetBSD; there was no OpenBSD in the beginning) did inherit the legacy Mach 2.5-style design, it did not live on in FreeBSD, whose core team started pretty quickly replacing all remaining vestiges of the Mach VM[0] with a complete, modern, and highly performant rewrite of the entire VM. FreeBSD 4 had none of the original Mach code left in the kernel codebase, and that happened in the late 1990s. Therefore, FreeBSD can't be referenced in a relationship to Mach apart from the initial separation/very early foundation stage.
NetBSD (and OpenBSD) went on for a while but also quickly hit the wall with the Mach design (performance, SMP/scalability, networking) and also set out on a complete rewrite with UVM (unified virtual memory) designed and led by Chuck Cranor, who wrote his dissertation on the UVM. OpenBSD later borrowed and adopted the UVM implementation, which remains in use today.
So out of all living BSD's[1], only XNU/Darwin continues to use Mach, and not Mach 2.5 but Mach 3. There have been Mach 2.5, 3 and 4 (GNU/Hurd uses Mach 4) in existence, and the compatibility between them is rather low, and remains mostly at the overall architectural level. They are better to be treated as distinct design with shared influence.
[0] Of which there were not that many to start off with.
[1] I am not sure whether DragonBSD is dead or alive today at all.
The last release being «Version 6.4.0 released 2022 12 30», links from 2007 and 2012 do not lend much assurance that the project is still alive in 2025 – compared to other similar projects.
Also note that HAMMER (the previous design) and HAMMER2 (the current design, since 2018) are two distinct, incompatible file system designs. I am not sure what is the value of mentioning the previous and abandoned design in the this context.
> The last release being «Version 6.4.0 released 2022 12 30», links from 2007 and 2012 do not lend much assurance that the project is still alive in 2025 – compared to other similar projects.
Right - the git repo has commits from yesterday, but it ain’t no NetBSD… (h/t ‘o11c)
> Also note that HAMMER (the previous design) and HAMMER2 (the current design, since 2018) are two distinct, incompatible file system designs. I am not sure what is the value of mentioning the previous and abandoned design in the this context.
Sure - I linked to the first for the general intro, which mentions Hammer2 in the first paragraph if anybody reads through… my mistake.
I was going to say releases are published to Sorceforge[0] but indeed those look to be all src too. That said: I’d be surprised to find a distro that doesn’t have Tcl available in whatever package manager(s) they support.
I think he was worried about Sun Microsystems involvement[0] w Tcl when John Ousterhout went there[1], too. But mostly seems like a collection of unsolicited strawmen[2]. Also probably love-of-lisp.
Hi Don. I think this stuff is great, and applaud your work, so don’t think of this as a slight (depending on the answer, of course): how practical is this? Again, if the answer is approximately “not at all practical”, that’s fair, but I guess I could also see it fitting somewhere on a spectrum like emacs vs vi, QWERTY vs Dvorak, etc…
I’m doing it for the looks and feels. Making it public and open so others can take a look and feel free. (Ha ha, I got a billion of 'em!) ;)
It does have a distinctive visual look and physical feel. And while it’s not as sleek or ergonomic as the latest Logitech mouse (who gave him an office at their headquarters from 1992 to 2007), it’s pretty great to actually touch and hold -- just to grasp firsthand how far input devices have come.
(Okay, now I’ve got nine hundred ninety-nine million, nine hundred ninety-nine thousand, nine hundred ninety-something of 'em!)
>Logitech celebrates "ONE BILLION MICE SOLD!" making headlines in 2008. See their press release, blog post, and billionth mouse celebration page with links to press kits, fun facts, and timelines. The event coincided with our 40th anniversary celebration of Doug's landmark demo, titled "Engelbart and the Dawn of Interactive Computing". Enjoy the following timeline from Logitech's celebrations.
1.0e+9) Logitech Ships Billionth Mouse. Coincides with Fortieth Anniversary of First Computer Mouse Public:
>"What a wonderful coincidence that the leading mouse manufacturer has announced such a significant milestone in the same month that we celebrate Doug Engelbart's legendary public debut of the computer mouse," said Curt Carlson, president and chief executive officer of SRI International. "Logitech's product innovations support Engelbart's vision of human-computer tools for interactive and collaborative work."
>After that, Engelbart set up the tiny Bootstrap Institute with his daughter Christina, which survives as the Doug Engelbart Institute, providing a useful history of his life and times. From 1992 to 2007, Engelbart was given an office at Logitech's headquarters, before finally returning to SRI some 30 years after he had left it.
I might be misunderstanding, but are you talking solely about the most here? I'm mostly curious about the chorded "keyboard"(?) as an input device - have you spent time with it as a daily driver? How does it compare to a traditional keyboard? I would guess a keyboard would be easier for a beginner, because ~1 key per symbol, and the keycaps are all printed (though I'm sure many of us remember our untrained selves scanning the entire keyboard intently, looking for whatever letter had eluded us) - so chorded input would be more of a learning wall than a learning curve, but once that's achieved... is chorded input ~100% speed of a QWERTY kb, or 10%, or 150%? Is it more or less tiring, physically and mentally? Very interested in your experience.
This is well-put. I think it speaks to "its the journey, not the destination", not learning to ski by only reading books, and Chesterson's Fence[0], off the top of my head.
I'm not sure what the reference to "modern CPUs" is, but a common complaint is that most reasonable reference counting implementations suffer very badly under contention. Specifically, if an object's reference count is contended (an object is being accessed/its pointer copied by many threads), it's possible that incrementing and then decrementing the reference count can take several hundred cycles due to either cache lines ping-ponging between cores or relatively expensive remote atomics (some Arm CPUs, I believe, allow the memory system to execute atomic operations in caches themselves to try and cope with contention/avoid moving cache lines back and forth by simply leaving them in a shared cache).
In reality, your milage will heavily vary. If you don't have contention (you don't commonly share objects across multiple threads concurrently), it's likely that reference counting will perform very well. Whether this is the common case really depends on the kinds of software you write.
Same object doesn't have to be contended if the reference count is sharing cache line with another reference count.
I've seen this happen in cases arrays of objects are allocated, ie one per thread, and then handed to a thread pool to work on.
Even if heap allocated, if the object is just a reference counter and a few pointers, the memory allocator can fit several of them next to each other causing them to share cache lines, which causes the performance issues with atomic operations.
Depends on implementation of things of course, but can be a pitfall.
> For example, I am writing some driver software for a USB device right now. It is so easy to get the device into a bad state, even when staying within the documented protocol. Every time I implement a workaround, or figure out exactly how the device expects a message to appear, I put in a comment to document it. Otherwise, when (inevitably) the code needs to have features added, or refactoring, I will completely forget why I wrote it that way.
I believe in general there is a case for this (your case sounds like a perfect candidate). The implementation of Dtrace is another example[0] full of good description, including ASCII diagrams (aside: a case for knowing a bit of Emacs (though I'm sure vim has diagramming too, which I would know if I pulled myself out of nvi long enough to find out)).
George Bernard Shaw, Man and Superman