On OpenBSD, there is a rule that you link with libc to interface with the kernel, because that’s where the syscall stubs live. This causes a great deal of consternation for partisans of other languages, because they don’t want to link “all of libc”. But when does anything link all of libc?

more...

Because I am a glutton for exploitation, I bought another Kindle. The tiny entry level model, unlike the Scribe I currently have.

more...

The internet is filled with stories that purport to teach us a valuable lesson or something about how the world works, and they’re really important because they really happened. NASA spent millions of dollars designing a space pen, which was really foolish when they could have just used a pencil like the Russians. I think not as many people believe that anymore, but it’s still floating around out there.

more...

We have a new edition of POSIX, which means new rules, new regulations, new red tape. But not new lines. Which is to say, posix at long last banishes new lines in file names.

more...

What if we want a grep that doesn’t stuck but we don’t want to resort to wild hacks like editing the source? What if there was some way to flush stdout automatically?

The auto flusher is a very simple preload.

#include <stdio.h>
#include <unistd.h>
#include <pthread.h>

static void *
flusher(void *arg)
{
        while (1) {
                sleep(3);
                fflush(stdout);
        }
}

__attribute__((constructor))
void
herewego(void)
{
        pthread_t thread;

        pthread_create(&thread, NULL, flusher, NULL);
}

Magic constructor attribute for initializers in C, and then we create a thread which loops around occasionally flushing stdout, so if there’s any data left lingering, it will eventually find it’s way out instead of waiting forever.

$ cc -shared -lpthread -o libflusher.so flusher.c
$ env LD_PRELOAD=./libflusher.so grep ...

Sometimes pipes get stuck. To recap, if we run this command...

~/src/usr.bin/grep> tail -200 util.c | grep unsigned | grep int
grep_revstr(unsigned char *str, int len)

... we get the expected output. If we run it this way, however, there’s no output.

~/src/usr.bin/grep> tail -f -200 util.c | grep unsigned | grep int

The file isn’t being appended, meaning tail won’t exit, so we don’t expect the pipeline to ever finish, but we would like to see the current results.

Fortunately, grep provides an lbflag we can set. In this case, if the input is a pipe, we’ll assume there’s something fancy going on, and switch to line buffering.

        struct stat sb;
        fstat(0, &sb);
        if ((sb.st_mode & S_IFMT) == S_IFIFO)
                lbflag = 1;

Easy fix. (Or one can read the manual.)

But this is excessive. What about those times when we want the efficiency of buffering? There are lots of possible pipelines that don’t involve tail. What we can do instead is take a peek at some of our neighbors and see what’s really going on. Not perfectly accurate, but probably good enough.

static void
checklbflag()
{
        pid_t pgrp = getpgrp();
        struct kinfo_proc ki[24];
        size_t len = sizeof(ki);
        int mib[6] = { CTL_KERN, KERN_PROC, KERN_PROC_PGRP, pgrp,
                sizeof(ki[0]), sizeof(ki)/sizeof(ki[0]) };

        sysctl(mib, 6, ki, &len, NULL, 0);
        for (size_t i = 0; i < len / sizeof(ki[0]); i++)
                if (strcmp(ki[i].p_comm, "tail") == 0)
                        lbflag = 1;
}

Alas, this requires including <sys/sysctl.h> which will slow down our compiles.

It is also possible, using forbidden magic, to determine whether the pipe we are reading from is being written to by tail, as opposed to a tail at the end of the pipeline, but that’s left as an exercise for the reader.

As noted, Valve uses the same flicker effect for broken lights in all their games. What if I want a broken web page?

more...

The Honk Foundation is pleased to announce the initial release of Enterprise Social, previously known as Honk Enterprise, previously known as honk3. It’s reworked and retuned, reimagined and remade. A social network for the future.

more...

A response of sorts to commit robbery.

I’ve been on both sides of commit misattribution. Sometimes my commit gets sniped. Sometimes I’m the one doing the sniping. It’s very rarely intentional.

In a project like OpenBSD, we’d have three Todds and four Jasons, which led to frequent confusion. Forgetting exactly who contributed what would happen occasionally. Emails get forwarded around. And I think every new OpenBSD developer goes through the experience of having half their commits sniped for the first month because other developers think you’re submitting a patch, not requesting review.

I’d guess 1% of commits are misattributed in some way. There’s an acknowledgement, but it’s incomplete. Or it’s omitted. Or it credits somebody else entirely. I think that’s not bad overall, though it does mean 1% of first time contributors have a suboptimal experience. It sucks to be the statistic.

Could the 1% be improved? Sure, just require a few more TPS reports before commits are permitted. If the solution is that we simply need to ask the maintainers to care more, are we sure they don’t care? There’s already enough people burning out and dropping out of open source work.

I think Ariel’s story could have been framed better, with a rather less villainous counterparty. I almost didn’t read it, because I don’t care about commit drama, but the story of the debugging was really interesting. I’m glad I read that! But hey, your blog, your story. That said, I don’t think it’s possible to generalize from one event to sweeping conclusions like this is why people don’t contribute to open source. This is, maybe, why 1% of people don’t contribute to open source.

Big Stomper is out to get you. Better watch what you say, or you’ll get stomped.

Of course, they won’t admit to stomping you. They’ll even deny it. Make it look like an accident or natural causes, an unfortunate rockslide. But you’ll be stomped just the same. All for speaking out about their misdeeds.

Not everyone believes Big Stomper is even responsible, but I hang out on the Stomp Watch forum, where we catalog and discuss the evil things Big Stomper is up to. So we know that when something bad happens, Big Stomper is to blame. Sometimes we debate if the stomping is carried out in house, or contracted out, but we are all agreed that the murky lack of evidence is a clear sign that professionals are involved. These are not amateur stompers.

Because I know what Big Stomper is capable of, it would be irresponsible not to warn you what happens to anyone who reveals their secrets. Everyone at Stomp Watch would love to discuss your revelations, but you need to know that you will definitely get stomped. Big Stomper does this to dissuade future leakers.

Some people (there’s always that “someone” on the internet, right?) will tell that it’s safe to come forward, these are just rumors and wild speculation. Well, they’re not the ones risking their lives, are they? Anyone inside Big Stomper who feels obligated to disclose the truth should come check out Stomp Watch first to know the risks.