A year-end wrapup of responses to reader feedback

A year-end wrapup of responses to reader feedback

It's time for some end of the year feedback. I get a bunch of comments and questions from people through my contact page, and sometimes this is the only way to reply. Other times, a response is also suitable for a wider audience.

Igor asks:

Have you played around with cling? Seems you may have the knowledge to break it or request the developers to enhance it with some useful feature(s). Like suppose doing scripting in it?

I didn't even know what cling was until I read this and went looking. It seems to be a clang/LLVM-based C++ interpreter that's interactive. I guess I don't have a need for something like that. As far as deliberately breaking things, I have no doubt that my luck would lead to any number of bad outcomes. However, I have enough of that in my life already without seeking out new stuff just for the sake of having something to break.

Now, if there was a good reason for me to do it, that would be another story. (I am available for mercenary purposes, put it that way.)

An anonymous reader asks:

What's the specs of this new web server?

It's only new to me. It's actually fairly old. I think it's roughly 2014 vintage. I bought it from one of those vendors who resell old servers. I figured "it's a server, not a toothbrush" and so the notion of using some random old box was not a problem for me. It runs Linux and is plenty quick, so I'm happy enough.

I guess this is a good point to tell the story of actually installing this thing. Despite working at places with millions of Linux boxes over the years, I'd never hung a server. I'd done routers and dialup boxes, but those were all relatively short. They'd hang from the front posts and were plenty happy with life that way.

flicker, on the other hand, is a monster. It's so long the cabinet doors almost didn't close. I had no idea that length was a dimension that might be a problem. I clearly didn't realize just what I was getting when that order was placed, and when it showed up in a giant box, I started thinking "what have I done?"...

Initially, the machine barely fit into the cabinet with the power cord being squished on one end and the network cables being squished on the other. I came back about a month later and swapped it to a new power cord that has a 90 degree bend built into the server-side plug. This clawed back about an inch on that side and let the whole thing slide back a little bit which took the pressure off the Ethernet cables.

I took the now-permanently-crimped (and damaged) power cable, cut it in half so nobody would find it and try to use it, and tossed it.

It was the sort of thing that anyone with experience would point at and go "ha, you screwed up", and indeed, I did. It turned out to not be fatal to the project of moving to colocation, but it was mighty close.

Next time, I'll pay attention to this sort of thing.

Lesson learned: go see the cabinet and measure it before ordering something that's almost three feet long!

(It's an Ivy Bridge flavored dual-socket hex core Xeon with 128 GB of memory and a couple of SSDs. It also has a far faster pipe than the previous box. It's a complete monster for how I use it. Oh, and it's not in Texas, which has turned out to be very important.)

Regarding my "char buf[1048576]" thing from the other day where I blew the stack, a reader says:

You can use boost::thread instead. It lets you specify the stack size.

Honestly though, I don't *want* to specify the stack size. I'm fine with defaults. Also, any answer which involves "boost" means I'm asking the wrong question. I don't ever want to get stuck with something like that. There's been too much drama in my life from boost dependencies in years gone by.

The obvious way around the "problem" for me is to do something like a vector<char>, push it out to whatever size, and then let read() use it as a buffer. This is pretty much what I end up doing any time I have to deal with old-school C library functions from my C++ code.

Like, okay, mkdtemp(). It wants a char* template, like "/tmp/test_thingy.XXXXXXXX". It *reaches into* that space and alters it, changing the Xs to some random gunk that turned out to be unique - this is how you avoid /tmp race attacks. This is more annoying than it sounds.

You might think "oh I know, I'll use a string, then hand the .c_str() pointer from it to mkdtemp". But, no, c_str() gives you a *const* pointer, and mkdtemp is going to violate that const-ness. Your compiler will stop you from doing this. You then must either lie to it and do some nasty casting, or you decide that's not going to work and find another way.

This is why I have a bunch of stupid shims to deal with these scenarios. It's just that I never really shimmed read() before - the old hacky way of having a buffer on the stack was never a problem.

As for "why is that buffer so big", well, I like to cut down on the number of syscalls required to inhale a file: a bigger buffer eats the whole thing in a single go. A tiny buffer would need to keep coming back until it finished. This sort of thing used to matter more when machines were much slower.

Besides, I hate spammy syscall situations. read() or write() with a single byte? Argh!

From another reader:

hey are you still running wg barebones on your mac? I just made the mistake of installing and got the 'cant uninstall' behavior with additional 'nothing happens when you dbl click on app icon' . just wanted to compare notes

Yep, I still am doing this on my personal machine and also those of family members (in my duties as "holiday sysadmin), having removed the "app store" version a while back. I get feedback from random people who find that three year old post about once a quarter, and they all seem to have the same problems. I take that as a pretty strong signal to not try it again just yet.

I should note that if you're using Macports, upgrade to Sonoma, and then try to build wireguard-tools or several other packages, it'll fail due to various Apple-related stupidity. I'll do another post about that eventually.

Finally, a bunch of people wrote in about the "clang + C++ + original armv6 Raspberry Pi = unusable binaries" to say that it explained some oddities they had been seeing on their own stuff, so I think that turned out okay. That's really what I aim for in writing these posts: visibility into problems, and confirmation that you aren't alone in experiencing something. Sometimes it's technical, but other times it's about squishy meatspace stuff. Both are valid.