HN user
As far as I can see (and comparing with the output on the github page), the only thing missing from dmesg is the amount of cache and byte order within the first 20 or so lines. One depends on CPU purchase, the other depends on the ISA. Either way, they're not something I can do anything about even if I need to know them - which, most of the time, I don't.
I'd argue that the reason you think lscpu is predictable and concise is that you're used to reading it.
I'm a sysadmin, not a programmer, so maybe that's why it seems like the Haskell solution is more complicated to me - but can someone explain why a supposed improvement for something is more complicated, and involves a bunch of stuff that can't be expected to be included on any Unix-like system you sit down in front of?
It's especially confusing, considering that the blogger claims to have changed their opinion, but doesn't bother to clarify what has changed on the new blog that he "helpfully" links to. It's also interesting that the author claims that McIllroy would approve of his solution, without checking with him. McIllroys email isn't exactly hidden if you know where to look, and I know he still posts on a few mailing lists regularily, so it's not like he's completely unavailable.
McIlroys solution works on any POSIX compatible system. Feel free to check for yourself: http://shellhaters.org/
This is neat and all, but I'm not sure I understand how it's better than 'less /var/run/dmesg.boot'? Which is not to say that this doesn't have any merit, I just don't understand it.
Ultimately, even if you ignore FreeBSDs and OpenBSDs history of cooperation (or the lack thereof, either of which I won't get into), the projects have different values that don't necessarily mix - so I'm not sure it's possible. It's okay to have different values, we don't all need to think a certain way.
Personally, I'd also begin worrying about mono-cultures and a lack of competition, if they were to be forced together. In the market-place of ideas, it's good to have multiple approaches to a single problem, because it lets you shop around, evaluate, and pick whatever solution fits you and your requirements best.
May I suggest w3m-img, tmux and uxrvt compiled with mouse support?
Hotmail and Windows Update used to be hosted on FreeBSD, yes.
https://github.com/dspinellis/unix-history-repo is a project that attempts to document Unix from its very first line all the way up to FreeBSDs HEAD (at least whenever it's imported, which might only be once a year). There's even a gource video showing the evolution.
My guess would be that it's because jails are exclusive to FreeBSD, and not that many people (compared to Linux, that is) run FreeBSD. Jails were also devised as a tool for the sysadmins toolbox, whereas docker is a tool for developers toolbox - and each has its own strengths and weaknesses.
Finally, jails do lack a bit of the functionality that lets docker do some things - but that isn't something that can't exist, an in fact there are certain signs that such instrumentation might be in the process of being written: https://twitter.com/FiLiS/status/894651614002393088.
Docker runs on FreeBSD too, and it'll hopefully run even better in the future once the results from https://wiki.freebsd.org/DockerHackDay2017 come in.
FreeBSD jails can't just be easily ported to any platform, as they're not designed for portability - kernel-features being portable wasn't really a thing back in the late 1990s when jails were developed. They're designed to contain software (in fact, the title of the original paper is quite demonstrably "confining the omnipotent root"), which is why they're the first actual type of container (chroots original purpose isn't known by anyone but Bill Joy and while he isn't saying anything much on the subject, its first documented use that I know of was building BSD in a clean enviroment).