As I move around, I roam between wifi networks, but sometimes lose the connection. Then I click a link and watch in vain as it fails to load. So I’d like an easy way to check which, if any, wifi network I’m connected to, such as by putting it in my dwm status bar. I could run ifconfig and parse the output, but that’s excessively wasteful. I need to get the info myself.
more...
It’s been three years since our previous counting of lines, so let’s check back in and see how OpenBSD is growing. Instead of just looking at the kernel, this time we’ll zoom out and look at the entire src tree.
. 20.54M lines 954.56M bytes
├──sys 9.70M lines 627.17M bytes
│ ├──dev 8.49M lines 593.52M bytes
│ │ ├──pci 7.14M lines 549.14M bytes
│ │ │ └──drm 6.58M lines 532.33M bytes
│ │ │ ├──amd 5.81M lines 509.00M bytes (7)
│ │ │ └──(other) 696.08k lines 21.03M bytes (7)
│ │ └──(other) 1.33M lines 43.74M bytes (36)
│ └──(other) 1.21M lines 33.66M bytes (22)
├──gnu 7.65M lines 238.82M bytes
│ ├──usr.bin 4.72M lines 140.19M bytes
│ │ ├──binutils 1.42M lines 42.64M bytes (12)
│ │ ├──binutils-2.17 1.14M lines 39.34M bytes (12)
│ │ ├──gcc 1.18M lines 35.25M bytes (3)
│ │ └──(other) 981.74k lines 22.96M bytes (5)
│ ├──llvm 1.52M lines 55.85M bytes (8)
│ ├──gcc 1.25M lines 37.88M bytes (11)
│ └──(other) 164.69k lines 4.89M bytes (3)
└──(other) 3.19M lines 88.57M bytes (12)As some of the more knowing members of the audience may have predicted, the AMD GPU driver wins the prestigious Most Growth award, nearly doubling in size. It’s gone from being more than the half the kernel to more than half of the entire operating system. Quite the achievement! No other subdirectory even comes close.
AMD was up against some stiff competition in the past, including Team Toolchain featuring two copies of binutils, two copies of gcc (4.2 and 3.old), and llvm, but even their combined efforts now come in at only half an AMD.
There are some other programs and utilities included in OpenBSD as well, but at less than 10% of the codebase, they’re probably not worth further consideration. Too far out of competition.
I don’t usually recommend budget laptops, which end up being useful for little more than getting online and ordering a real replacement, but occasionally there’s exceptions. Like the ASUS Vivobook 14 (X1404ZA) from 2023, which apparently was made in great numbers but didn’t sell very well, because stores are still trying to unload it. It’s not a great laptop, but for $225 or so, it’s better than most of the alternatives. (Unless you find a good deal on an ebay thinkpad, etc. An X1 Carbon G3 from 2015 seems to be about the same price.) I picked it up specifically because I wanted an Alder Lake CPU for reasons, and I’m happy that it hasn’t been a waste of money.
more...
The OpenBSD kernel has a set of functions to help detect memory corruption, the poison subroutines. The memory management code uses these functions, but they themselves have a very simple interface, no complicated types or data structures, meaning they’re easy to replace. What if we rewrite the memory corruption detection functions in rust so it’s impossible for them to cause memory corruption?
more...
Or perhaps more precisely, how do they get there? What happens when you call write?
more...
The OpenBSD kernel is getting to be really old, like really, really old, mid 40s old, and consequently it doesn’t like surprises, so programs have to tell it where their syscalls are. In today’s edition of the polite programmer, we’ll learn the proper etiquette for doing so.
more...
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...
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...
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 intThe 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.
I like using pledge and unveil in my web apps. Especially unveil offers a nice degree of protection against common web app problems, like the dreaded double dot traversal. For go, I use a simple wrapper which gets pasted into each project.
more...