William “the Jar” Mason is a semi famous programmer. Mostly retired, but his website still has some classic postings from early days working on essential software tools like vi and lynx. Unzealous Association is a link aggregator popular among people who like to read Mason’s articles.

The trouble begins one day when wjm decides that UA sends too much traffic his way. Like a denial of service. And so wjm responds by redirecting anyone with a referer of UA to a picture of a roast ham. (This is probably an overreaction. It’s not really the UA users at fault, but the many aggressively stupid bots that scrape all linked sites. But it has the desired effect of keeping links to wjm’s site off the front page.)

This action is not without collateral damage. It’s not just that headline links disappear, but also less trafficked links in comments are affected. This then incites an unhelpful mini thread on UA about how the internet works.

The UA response is to autokill any comments linking to wjm. The comment is hidden from most users, but remains visible to the author without any indication of what went wrong. (Also Known as hellbanning, the nuclear option of troll containment.)

There are a couple other ways this could have played out. Possibly, if the UA software can detect wjm links in order to kill them, it could also skip adding the <a> tags. Users who cut and paste the link don’t have referer headers. Problem solved. Another option might be to simply ride it out and see if the complaint threads dissipate. Maybe wjm will even change his mind some day.

Unfortunately, when all you have is a trollhammer, all you see are trolls.

Some recent flak outages were mysterious. One day things would be working, but the next they wouldn’t. All the flak.lua processes had disappeared. No error messages were reported in any observable location. No unusual looking requests were observed in any recorded location. Sometimes a process would survive days of heavy traffic. Other times it would die after only a few hours of light traffic. It was as if the process involved simply lost the will to live.

more...

Yesterday Reyk fixed a tiny bug in vmd. It wasn’t possible to kill the process by pressing ^C. As explained in the commit, the accept4 system call was being restarted after the signal.

By default, most signal handlers that a program establishes have the SA_RESTART flag set, which causes an interrupted system call to be restarted. Actually, by default signals are either ignored or cause the program to terminate, so this isn’t a problem at all, but any handler installed by calling signal sets this flag. More control over signal actions is possible using the appropriately named sigaction function.

On the kernel side, system calls that need to block call tsleep which usually waits for a corresponding wakeup or a timeout to expire. However, it may also return an error (ERESTART) if it’s interrupted by a signal. Most system calls don’t inspect the error code, they simply pass it along. But when the kernel is about to return to userland, it will notice this error code and run the syscall again.

Among the system calls that handle ERESTART specially are poll, select, and kevent. All of them check for ERESTART and immediately map it to EINTR so it gets returned to userland.

Back in vmd, it had installed a SIGTERM handler that set a quit flag variable to true, but was getting stuck in accept. The code looking at quit never had a chance to run. The fix was to add a call to poll before accept.

Most of the time the default behaviors make sense. Restarting system calls prevents a lot of spurious failures from propagating. Applications that install signal handlers usually use one of the interruptible functions in the core of their event loop. vmd happened to be an exception, that only needed to handle one event and tried to take a shortcut.

Additional commentary about history of EINTR.

Looking at Theo’s status of pledge update there’s a lot of programs on the list, including some which may seem a bit silly. But the effort has turned up some interesting bugs and misfeatures along the way.

more...

Previous post on rough code had some notes notes on a few of the issues we faced at ü2k15. I also collected some notes and links about utf-8 and unicode that weren’t directly OpenBSD related.

more...

The “traditional” way of writing a for loop looks something like this:

more...

On their better days, standards groups follow a principle of rough consensus and working code. Somebody builds something, announces it to some friends and maybe a few competitors, and says, hey, if you build something similar, it’s possible for our implementations to interoperate. Everyone’s a winner. Sometimes the design isn’t perfect, but the fact that at least one person/group has built an implementation is an existence proof that it can be built. Valuable knowledge to have.

more...

The recent fuss about f.lux on iPhone made me take another look at desktop solutions for shifting the screen’s color temperature. f.lux is only available as a linux binary, but there’s a program called redshift that may work.

more...

Or everything I didn’t know about unix. The OpenBSD source tree has lots of example code for solving any number of problems, but I like to do things my own way. Occasionally this means something gets overlooked. A few examples. Previous thoughts on rewrites and reuse: out with the old, in with the less and hoarding and reuse.

more...

A few funnies sprinkled with a bit of insight and disappointment. And regret.

It’s 2015. Your team has to wake up determined and put in one hell of a work week to get web pages to render slowly. And yet so many succeed. tweet.

My modest proposal: your website should not exceed in file size the major works of Russian literature. Anna Karenina, for example, is 1.8 MB. tweet.

If your design team insists on including a lot of Javascript cruft and CSS resets, make them write it all out longhand with a quill pen. tweet.

Two steps to better mobile design: 1) Make sure that the most critical elements of the page download and render first. 2) Stop right there. tweet.

If you’re a web designer/front-end developer, It may help to think of the fan on your laptop as a shaming rather than a cooling device. tweet.

The only honest measure of page load speed: time from initial TLS handshake to when the user has finally stopped closing all the ads. tweet.

More generally, there should be an attribute to allow non-designers’ browsers to only load useful images. tweet.

Astonished to find that a blog site needs a Bloom filter daemon and has Product Scientists. “On the web we want to stay close to the metal” tweet.

I move that the web get faster as computers and networks get faster. tweet.

“We aspire to simple, powerful, yet revenue-free systems that can turn a 500 word blog post into a multi-megabyte user experience” tweet.

All this and more also collected in The Website Obesity Crisis talk.