One of the little traps in standard C and POSIX is that malloc(0)is allowed to return NULL instead of a pointer .This makes people unhappy for various reasons. Today I wound upreading 017. malloc(0) & realloc(…, 0) ≠ 0 , whichruns through a whole collection of Unix malloc() versions and findsalmost none of them which return NULL on malloc(0) except for someUnix System V releases that ship with an optional 'fast' malloclibrary

Back in the early days of GPU computation, the hardware, drivers,and software were so relatively untrustworthy that our early GPUmachines had to be specifically reserved by people and that reservationgave them the ability to remotely power cycle the machine to recoverit (this was in the days before our SLURM cluster ). Things have gotten much better sincethen, with things like hardware and driver changes so that programswith bugs couldn't hard-lock the GPU hardware. But every so oftenwe run into odd failures where

For a while, X terminals were a reasonably popular way to give people comparatively inexpensiveX desktops. These X terminals relied on X's network transparencyso that only the X server had to run on the X terminal itself, withall of your terminal windows and other programs running on a serversomewhere and just displaying on the X terminal. For a long time,using a big server and a lab full of X terminals was significantlycheaper than setting up a lab full of actual workstations ( untilinexpensive and capable PCs

I recently read z3bra's 2014 Avoid workspaces ( via ) which startsout with the tag "Virtual desktops considered harmful". At onelevel I don't disagree with z3bra's conclusion that you probablywant flexible groupings of windows, and I also (mostly) don't usesingle-purpose virtual screens. But I do it another way, which Ithink is easier than z3bra's (2014) approach.

I've written

Our general purpose departmentalweb server has supported HTTP/2 for a while. When we added HTTP/2support it was basically because it was there; HTTP/2 was the newand shiny thing, our Apache configuration could support it, and soit seemed like a friendly gesture to turn HTTP/2 on. Until now, I'venever looked at the statistics for how many HTTP requests use HTTP/2and how many use other HTTP versions.

Our general purpose web server supports both HTTP access and

I wrote about a performance mystery with WireGuard on 10G Ethernet , and since then I've done additionalmeasurements with results that both give some clarity and leave mescratching my head a bit more. So here is what I know about thegeneral performance characteristics of Linux kernel WireGuard on amixture of Ubuntu 22.04 and 24.04 servers with stock settings, andusing TCP streams inside the WireGuard tunnels (because the highbandwidth thing we care about runs overTCP).

• CPU performance

One piece of open source news of the time interval is that thesole maintainer of libxml2 will no longer be treating securityissues any differently than bugs ( also ,via Fediverse discussions). In my circles, the reaction to thishas generally been positive , and it's seenas an early sign of more of this to come, as more open sourcemaintainers revolt. I have various thoughts on this, but in lightof what I wrote about open source moral obligation and popularity , one thing this incident has

As a followup on discovering that WireGuard can saturate a 1GEthernet (on Linux) , I set up WireGuard onsome slower servers here that have 10G networking. This isn't anideal test but it's more representative of what we would see withour actual fileservers , since I used sparefileserver hardware. What I got out of it was a performance and CPUusage mystery.

What I expected to see was that WireGuard performance would top outat some level above 1G as the slower CPUs

I'm used to thinking of encryption as a slow thing that can't deliveranywhere near to network saturation, even on basic gigabit Ethernetconnections. This is broadly the experience we see with our current VPN servers,which struggle to turn in more than relatively anemic bandwidthwith OpenVPN and L2TP, and so for a long time I assumed it wouldalso be our experience with WireGuard if we tried to put anything serious behind it. I'd seen the 2023Tailscale blog post about this