Perry Lorier

This is my face that the ISC Kea DHCP server configuration file is apparently JSON with no comments. And ISC wants people to replace the traditional ISC DHCP server with this hot piece of garbage? As a system administrator, these are two middle fingers. We have lots of comments in our DHCP […]

Color Survey Results > Who in the rainbow can draw the line where the violet tint ends and the orange tint begins? Distinctly we see the difference of the colors, but where exactly does the one first blendingly enter into the other? So with sanity and insanity. > —Herman Melville, _Billy Budd_ > Orange, red? I don’t know what to believe anymore! > —Anonymous, Color Survey > I WILL EAT YOUR HEART WITH A FUCKING SPOON IF YOU AKS ANY MORE QUESTIONS ABOUT COLORS > —Anonymous, Color Survey Thank you so much for all the help on the color survey. Over five million colors were named across 222,500 user sessions. If you never got around to taking it, it’s too late to contribute any data, but if you want you can see how it worked and take it for fun here. First, a few basic discoveries: * If you ask people to name colors long enough, they go totally crazy. * “Puke” and “vomit” are totally real colors. * Colorblind people are more likely than non-colorblind people to type “fuck this” (or some variant) and quit in frustration. * Indigo was totally just added to the rainbow so it would have 7 colors and make that “ROY G. BIV” acronym work, just like you always suspected. It should really be ROY GBP, with maybe a C or T thrown in there between G and B depending on how the spectrum was converted to RGB. * A couple dozen people embedded SQL ‘drop table’ statements in the color names. Nice try, kids. * _Nobody_ can spell “fuchsia”. Overall, the results were really cool and a lot of fun to analyze. There are some basic limitations of this survey, which are discussed toward the bottom of this post. But the sheer amount of data here is cool. **Sex** By a strange coincidence, the same night I first made the color survey public, the webcomic Doghouse Diaries put up this comic (which I altered slightly to fit in this blog, click for original): It was funny, but I realized I could test whether it was accurate (as far as chromosomal sex goes, anyway, which we asked about because it’s tied to colorblindness) _[Note: For more on this distinction, see my_ _follow-up post_ _]_. After the survey closed, I generated a version of the Doghouse Diaries comic with actual data, using the most frequent color name for the handful of colors in the survey closest to the ones in the comic: Basically, women were slightly more liberal with the modifiers, but otherwise they generally agreed (and some of the differences may be sampling noise). The results were similar across the survey—men and women tended on average to call colors the same names. So I was feeling pretty good about equality. Then I decided to calculate the ‘most masculine’ and ‘most feminine’ colors. I was looking for the color names most disproportionately popular among each group; that is, the names that the most women came up with compared to the fewest men (or vice versa). Here are the color names most disproportionately popular among women: 1. Dusty Teal 2. Blush Pink 3. Dusty Lavender 4. Butter Yellow 5. Dusky Rose Okay, pretty flowery, certainly. Kind of an incense-bomb-set-off-in-a-Bed-Bath-&-Beyond vibe. Well, let’s take a look at the other list. Here are the color names most disproportionately popular among men: 1. Penis 2. Gay 3. WTF 4. Dunno 5. Baige I … that’s not my typo in #5—t _he only actual color_ in the list really is a misspelling of “beige”. And keep in mind, this is based on the number of unique people who answered the color, not the number of times they typed it. This isn’t just the effect of a couple spammers. In fact, this is _after_ the spamfilter. I weep for my gender. But, on to: **RGB Values** Here are RGB values for the first 48 out of about a thousand colors whose RGB values (across the average monitor, shown on a white background) I was able to pin down with a fairly high degree of precision: The full table of 954 colors is here, also available as a text file here (I have no opinion about whether it should be used to build a new X11 rgb.txt except that seems like the transition would be a huge headache.) The RGB value for a name is based on the location in the RGB color space where there was the highest frequency of responses choosing that name. This was tricky to calculate. I tried simple geometric means (conceptually flawed), a brute force survey of all potential center points (too slow), and fitting kernel density functions (math is hard). In the end, I used the average of a bunch of runs of a stochastic hillclimbing algorithm. For mostly boring notes on my data handling for this list, see the comments at the bottom of the xkcd.com/color/rgb/ page. **Spelling and Spam** Spelling was an issue for a lot of users: Now, you may notice that the correct spelling is missing. This is because I can’t spell it either, and when running the analysis, used Google’s suggestion feature as a spellchecker: A friend pointed out that to spell it right, you can think of it as “fuck-sia” (“fuch-sia”). Misspellings aside, a lot of people spammed the database, but there were some decent filters in place. I dropped out people who gave too many answers which weren’t colors used by many other people. I also looked at the variation in hue; if people gave the same answer repeatedly for colors of wildly varying hue, I threw out all their results. This mainly caught people who typed the same thing over and over. Some were obviously using scripts; based on the filter’s certainty, the #1 spammer in the database was someone who named 2,400 colors—all with the same racial slur. **Map** Here’s a map of color boundaries for a particular part of the RGB cube. The data here comes from a portion of the survey (1.5 million results) which sampled only this region and showed the colors against both black and white backgrounds. The data for this chart is here (3.6 MB text file with each RGB triplet named). Despite some requests, I’m not planning to make a poster of any of this, since it seems wrong to take advantage of all this volunteer effort for a profit; I just wanted to see what the results looked like. You’re welcome to print one up yourself (huge copy here), but keep in mind that print color spaces are different from monitor ones. **Basic Issues** Of course, there are basic issues with this color survey. People are primed by the colors they saw previously, which adds overall noise and some biases to the data (although it all seemed to even out in the end). Moreover, monitors vary; RGB is not an absolute color space. Fortunately, what I’m really interested in is what colors will look like on a typical monitors, so most of this data is across the sample of all non-colorblind users on all types of monitors (>90% LCD, roughly 6% CRT). Color is a really fascinating topic, especially since we’re taught so many different and often contradictory ideas about rainbows, different primary colors, and frequencies of light. If you want to understand it better, you might try the neat introduction in Chapter 35 ofThe Feynman Lectures on Physics (Vol. 1), read Charles Poynton’s Color FAQ, or just peruse links from the Wikipedia article on color. For the purposes of this survey, we’re working inside the RGB space of the average monitor, so this data is useful for picking and naming screen colors. And really, if you’re reading this blog, odds are you probably—like me—spend more time looking at a monitor than at the outdoors anyway. **Miscellaneous** Lastly, here are some assorted things people came up with while labeling colors: Thank you so much to relsqui for writing the survey frontend, and to everyone else who sacrificed their eyeballs for this project. If you have ideas and want to analyze these results further, I’ve posted the raw data as an SQLite dump here (84 MB .tar.gz file). It’s been anonymized, with IPs, URLs, and emails removed. I also have GeoIP information; if you’d like to do geocorrelation of some kind, I’ll be providing a version of the data with basic region-level lat/long information (limited to protect privacy) sometime in the next few days. _Note: The ColorDB data is the main survey. The SatOnly data is the supplementary survey covering only the RGB faces in the map, and was presented on a half-black half-white background.)_ And, of course, if you do anything fun with this data, I’d love to see the results—let me know at xkcd@xkcd.com. ### Share this: * Click to share on X (Opens in new window) X * Click to share on Facebook (Opens in new window) Facebook * Like Loading... ### _Related_

TIL: matplotlib supports specifying colors using standard X11/CSS4 names, but also supports the names from the xkcd color survey.

(While looking this up, I also learned about the full-on xkcd mode, but different topic!)

#python #matplotlib

@0xabad1dea Fun fact! Mobile phone networks don't have the concept of an "emergency number", the network provides a special "emergency call setup" feature. Your phone and SIM card establish a list of "emergency call numbers", which trigger this feature. (Or you just hit the big red button on the […]

Did you know your MacBook has a sensor that knows the exact angle of the screen hinge?

It’s not exposed as a public API, but I figured out a way to read it and make it sound like an old wooden door.

Source code and a downloadable app to try it yourself […]

[Original post on hachyderm.io]

✨ Big O ✨

Let me take you on a visual introduction to what big O notation is in my new blog post: samwho.dev/big-o.

With big O notation you can better understand how algorithms will perform in practice, finding orders of magnitude improvements often with very simple changes to your code.

Urgh, why does everyone that builds a webdav server library use a "filesystem" abstraction?
Filesystems have very different semantics (eg
directories in urls end in a /
directories in a filesystem end without a /) and I'm often not backing it from a FS but some other kind of storage (eg sql or […]

https://github.com/isomer/alsa/blob/main/src/main.rs#L265

If I set use_sink to false, then the program works as expected. New audio data is queued when buffer space is available.

If I set use_sink to true, then as soon as the audio buffer fills up, the program blocks forever, and no wake up […]

If you've worked with SDRs professionally, either at the hardware level or at the e.g. RF protocol implementation levels, I'd love to buy an hour of your time for a validation conversation about a potential project. DM if you're interested; boosts welcome.

"If you only praise last-minute saves, you’ll keep getting last-minute problems. Make sure to recognize the engineer who reduced incidents, the PM who saw the risk a month out, the designer who caught the complexity before it shipped. Make that kind of foresight just as visible and valuable as […]

Grr. Why don't people write reentrant memory allocators?

If you have an Intel Raptor Lake system and you're in the northern hemisphere, chances are that your machine is crashing more often because of the summer heat. I know because I can literally see which EU countries have been affected by heat waves by looking at the locales of Firefox crash […]

A family of forks curl supports getting built with _eleven_ different TLS libraries. Six of these libraries are OpenSSL or forks of OpenSSL. Allow me to give you a glimpse of their differences, similarities and some insights into what it takes to support them all. ## SSLeay It all started with SSLeay. This was the first SSL library I found out to exist and we added the first HTTPS support to curl using this library in the spring of 1998. Apparently the SSLeay project was started already back in 1995. This was back in the days we still only had SSL; TLS would come later. ## OpenSSL This project was created (forked) from the ashes of SSLeay in late 1998 and curl supported it already from its start. SSLeay was abandoned. OpenSSL always had a quirky, inconsistent and extremely large API set (a good chunk of that was inherited from SSLeay), that is further complicated by documentation that is sparse at best and leaves a lot to the users’ imagination and skill to dig through source code to get the last details answered (still today in 2025). In curl we keep getting occasional problems reported with how we use this library even decades in. Presumably this is the same for every OpenSSL user out there. The OpenSSL project is often criticized for having dropped the ball on performance since they went to version 3 a few years back. They have also been slow and/or unwilling at adopt new TLS technologies like for QUIC and ECH. In spite of all this, OpenSSL has become a dominant TLS library especially in Open Source. ## LibreSSL Back in the days of Heartbleed, the LibreSSL forked off and became its own. They trimmed off things they think didn’t belong in the library, they created their own TLS library API and a few years in, Apple ships curl on macOS using LibreSSL. They have some local patches on their build to make it behave differently than others. LibreSSL was late to offer QUIC, they don’t support SSLKEYLOGFILE, ECH and generally seem to be even slower than OpenSSL to implement new things these days. curl has worked perfectly with LibreSSL since it was created. ## BoringSSL Forked off by Google in the Heartbleed days. _Done by Google for Google_ without any public releases they have cleaned up the prototypes and variable types a lot, and were leading the QUIC API push. In general, most new TLS inventions have since been implemented and supported by BoringSSL before the other forks. Google uses this in Android in other places. curl has worked perfectly with BoringSSL since it was created. ## AmiSSL A fork or _flavor_ of OpenSSL done for the sole purpose of making it build and run properly on AmigaOS. I don’t know much about it but included it here for completeness. It seems to be more or less a port of OpenSSL for Amiga. curl works with AmiSSL when built for AmigaOS. ## QuicTLS As OpenSSL dragged their feet and refused to provide the QUIC API the other forks did back in the early 2020s (for reasons I have yet to see anyone explain), Microsoft and Akamai forked OpenSSL and produced _QuicTLS_ which has since tried to be a _light-weight_ fork that mostly just adds the QUIC API in the same style BoringSSL and LibreSSL support. _Light-weight_ in the meaning that they were tracking upstream closely and did not intend to deviate from that in other ways than the QUIC API. With OpenSSL3.5 they finally shipped a QUIC API that is different than the QUIC API the forks (including QuicTLS) provide. I believe this triggered QuicTLS to reconsider their direction going forward but we are still waiting to see exactly how. curl has worked perfectly with QuicTLS since it was created. ## AWS-LC This is a fork off BoringSSL maintained by Amazon. As opposed to BoringSSL, they do actual (frequent) releases and therefore seem like a project even non-Amazon users could actually use and rely on – even though their stated purpose for existing is _to maintain a secure libcrypto that is compatible with software and applications used at AWS_. Strikingly, they maintain more than “just” libcrypto though. This fork has shown a lot of activity recently, even in the core parts. Benchmarks done by the HAProxy team in May 2025 shows that AWS-LC outperforms OpenSSL significantly. The API AWS-LC offers is not identical to BoringSSL’s. curl works perfectly with AWS-LC since early 2023. ## Family Tree The OpenSSL fork family tree ## The family life Each of these six different forks has its own specifics, APIs and features that also change and varies over their different versions. We remain supporting these six forks for now as people still seem to use them and maintenance is manageable. We support all of them using the same single source code with an ever-growing #ifdef maze, and we verify builds using the forks in CI – albeit only with a limited set of recent versions. Over time, the forks seem to be slowly drifting apart more and more. I don’t think it has yet become a concern, but we are of course monitoring the situation and might at some point have to do some internal refactors to cater for this. ## Future I can’t foresee what is going to happen. If history is a lesson, we seem to rather go towards _more_ forks rather than _fewer_ , but every reader of this blog post of course now ponders over how much duplicated efforts are spent on all these forks and the implied inefficiencies of that. On the libraries themselves but also on users such as curl. I suppose we just have to wait and see.

A family of forks.

Allow me to give you a glimpse of their differences, similarities and some insights into what it takes to support them all in #curl.

https://daniel.haxx.se/blog/2025/06/23/a-family-of-forks/

If you work with a database and are asked to alter the table structure to comply in advance for citizenship or gender categorizations it's really important to NOT do it.

"The governor is concerned about all this stuff they want us to update our record keeping so we store both gender AND […]

A set of white cylindrical TP-link mesh wireless devices

A TP-link router that looks like a black slab bristling with sharp angular towers on three sides.

Consumer networking devices come in two varieties: Altar to a Dark God and Aromatherapy Machine.

Pushing 240 Watts through a USB-C connector is not a thing that you will ever be able to convince me should happen on purpose. 48V at 5A over wires barely the size of human hair is pure sorcery.

Have a couple more openings on my team for folks if you want to come play:

First up is a Rust developer, mostly working on things like Luwen and working on moving some of our python based tools down to rust based tools. Lots of things coming, and all down in the systems stack […]

Team: what x509 parser does ISE Crypto recommend?
Me: ISE Crypto recommends that x509 is cast back into the fiery pit of hell from hence it came

I can't resist mentioning (again) one of my favourite bugs:

The Atari 2600 game Haunted Mansion has an incorrect instruction which showed up in the emulator I wrote and yet the game works fine on most real consoles.

It turns out that if you accidentally use SBC 15 on a real console (subtract […]

OH: DAMN YOU AGAIN rustc! YOU HAVE ONCE MORE REFUSED TO ALLOW ME TO CAST MYSELF INTO A TRAP OF MY OWN MAKING BY CALMLY BUT RESOLUTELY REFUSED TO CARRY OUT ORDERS THAT WOULD BREAK TYPE THEORY!

Sigh.

Gnome keeps changing the default key bindings for everything. I get that you want to be "friendly" to new users. But I've been using Unix for 30ish years. I'm the definition of a power user - which is why I'm using a Linux desktop in the first place.

STOP THROWING OUT MY 30 YEARS OF […]

Is there anything more Swiss than partial public holidays where people are expected to work only for 4 hours and 12 minutes?

My theory is that in the 1990s you would use C for systems programming, Java for business logic programming and perl for web applications.

By 2010 this had mostly moved to C++, Python and Ruby.

By 2020 this moved to Rust, Go and NodeJS.

This isn't strict. PHP had a stint there around 2000 […]

OpenSSH 10.0 just landed, now completely removing DSA signature support (you've been warned, repeatedly :-) and finite-field diffie-hellman key exchange.

The new version string ("OpenSSH_10.0") is also likely to confuse a bunch of stupid scanners that assume anything starting with "OpenSSH_1" […]

So, my point in all of this, is that if you're trying to do some network policy thing, try and create an interface and attach it to the interface. (eg as an ebpf program or something). Everyone can have their own networking interface and not interfere with each other.

Here ends my epiphany.

But network policy (especially firewalling) generally doesn't compose _at all_. Generally only one system can be in control of network policy at a time, and if two programs both want to deal with network policies they need to deeply integrate and understand each other.

I've not seen a good way […]