Classic ThinkPad Thermal Paste Change
Those who know me know that I am a bit fan of the oldschool Lenovo ThinkPad laptops with real 7-row keyboards. I own several *20 models from 2011 including W520, T420s and X220 ones. They still rock when it comes to ‘laptop computing’ and they are dirt cheap on any auction platform. They only got one flaw … that thermal compound on CPU (and sometimes GPU) gets older a lot faster then these laptops.
The FreeBSD-linuxulator explained (for users)
First, the linuxulator is not an emulation. It is “just” a binary interface which is a little bit different from the FreeBSD-“native”-one. This means that the binary files in FreeBSD and Linux are both files which comply to the ELF specification.
oxbar - configurable X11 status bar for OpenBSD
oxbar is a X11 status bar for OpenBSD showing various system stats. It has a configurable display and works out-of-the-box on most modern window managers in an intuitive fashion. oxbar supports FreeType font rendering and styling, true transparency & alpha blending on all UI components (including the root window), and a simple configuration format that can concisely support multiple themes.
My infrastructure as of 2019
The goal for my infrastructure is to run the services I need. While a lot of people in the homelab community experiment and play with software for its own sake, I actively use the stuff I host. When I stop, I kill the service (though I’m not as proficient at this as Google). These are my production systems, and when one of them is down, I do miss it.
OpenBSD in 2019
I’ve used OpenBSD on and off since 2.1. More back then than in the last 10 years or so though, so I thought I’d try it again.
Some good, some bad.
OpenBSD on Google Compute Engine
This tutorial outlines a simple way to get OpenBSD working on GCE, utilizing only OpenBSD to create the image and send up into gcloud.
FreeBSD'fy ZFS zlib zalloc/zfree callbacks
The previous code came from OpenSolaris, which in my understanding require allocation size to be known to free memory. To store that size previous code allocated additional 8 byte header. But I have noticed that zlib with present settings allocates 64KB context buffers for each call, that could be efficiently cached by UMA, but addition of those 8 bytes makes them fall back to physical RAM allocations, that cause huge overhead and lock congestion on small blocks. Since FreeBSD’s free() does not have the size argument, switching to it solves the problem, increasing write speed to ZVOLs with 4KB block size and GZIP compression on my 40-threads test system from ~60MB/s to ~600MB/s.
Sun Microsystems: A Look Back at a Tech Company Ahead of its Time
Sun Microsystems is a Silicon Valley legend. Ten years after it was acquired by Oracle, the company’s past employees still have fond feelings for their former home — and a historic reunion happened two weeks ago at the Hyatt Regency by the San Francisco airport. Over 1,000 former Sun employees reunited for an evening to re-connect and to reminisce.
Understanding modern UEFI-based platform boot
To many, the (UEFI-based) boot process is like voodoo; interesting in that it’s something that most of us use extensively but is - in a technical-understanding sense - generally avoided by all but those that work in this space. In this article, I hope to present a technical overview of how modern PCs boot using UEFI (Unified Extensible Firmware Interface).
Quite the overview.
Provide protection against starvation of the ll/sc loops when accessing userpace.
Casueword(9) on ll/sc architectures must be prepared for userspace constantly modifying the same cache line as containing the CAS word, and not loop infinitely. Otherwise, rogue userspace livelock kernel.
Why you should learn just a little Awk: An Awk tutorial by Example
In grad school, I once saw a prof I was working with grab a text file and in seconds manipulate it into little pieces so deftly it blew my mind. I immediately decided it was time for me to learn awk, which he had so clearly mastered.
Bad utmp implementations in Glibc and FreeBSD
I wondered: If the files consist of fixed-sized records, and are readable by regular users, how is consistency maintained? That is – how can a process ensure that, when it updates the database, it doesn’t conflict with another process also attempting to update the database at the same time? Similarly, how can a process reading an entry from the database be sure that it receives a consistent, full record and not a record which has been partially updated? (after all, POSIX allows that a write(2) call can return without having written all the requested bytes, and I’m not aware of Linux or any of the *BSDs documenting that this cannot happen for regular files). Clearly, some kind of locking is needed; a process that wants to write to or read from the database locks it first, performs its operation, and then unlocks the database. Once again, this happens under the hood, in the implementation of the getutent/pututline functions or their equivalents.
The Urgent Quest for Slower, Better News
Media outlets have been reduced to fighting over a shrinking share of our attention online; as Facebook, Google, and other tech platforms have come to monopolize our digital lives, news organizations have had to assume a subsidiary role, relying on those sites for traffic. That dependence exerts a powerful influence on which stories are pursued, how they’re presented, and the speed and volume at which they’re turned out.
Lately, I have begun to wonder, like Newport, whether the sheer volume of online news actually runs counter to the goal of keeping people informed.
hey - HTTP load generator
hey is a tiny program that sends some load to a web application.
Increasing coverage of signal semantics in regression tests
Kernel signal code is a complex maze, it’s very difficult to introduce non-trivial changes without regressions. Over the past month I worked on covering missing elementary scenarios involving the ptrace(2) API. Part of the new tests were marked as expected to success, however a number of them are expected to fail.
NES/Famicom: a visual compendium
NES/Famicom: a visual compendium aims to showcase the very best pixel art, box art and product design on each system. Spread over 536 pages, it features more than 170 classic games, with articles on the leading developers, interviews with key figures in the industry and mini-features on subjects such as packaging, fan art and unreleased games.