Office furniture: customizing a store-bought wastebasket

I bought a wastebasket that caught my eye at The Container Store while I was there for bamboo drawer organizers. I took a picture of it while I was in the parking lot.

I knew I would need to use bags with it, but when I got home and put a bag in it, I felt it looked like ass. I wanted to hide the bag inside, and also hide the bag flap around the rim. So I lined the inside with some scrap 1/4″ oak plywood I had on hand, and made a drop-on collar out of solid oak to hold the bag in place and hide the flap.

The recess was intentional, so I could create a lid. I wanted a flat lid so that the wastebasket could be used as a tiny table (say for holding a book or my iPad when I doze off on the new window seat). I went with solid 3/4″ oak I had on hand (leftovers from one of the rolling drawer cabinets). I used finger holes instead of a handle, to keep it flat.

After stain and polyurethane, I wound up with this.

In hindsight, I could’ve just built the whole thing from oak scraps I have. But the store-bought wastebasket was the inspiration, and I’m very happy with the result.

Office furniture: window seat/bench gains a drawer and fans

I recently installed the 3U fan panel in the window seat. It’s powered via a Kasa smart plug, so I can turn it on/off via HomeKit (usually using Siri). It’s quiet, but does a nice job. However, it came with ball bearing fans which I know will get loud over time. I’ll replace them with Noctua fans when they get loud enough to be annoying.

I also built and installed a wide wood drawer on 100 lb. drawer slides. I’m using it to store office miscellany. It has built-in finger-jointed dividers, but I also added some bamboo organizers from The Container Store.

I still need to order a cushion from rofielty.com. In the meantime I’m working on end tables to butt against the window seat.

Office furniture: under-desk rack

I recently realized that I never posted pictures of the completed under-desk rack.

Hiding under the desks, where it normally lives.

I guess I never posted about what’s going on in this rack. There are two ethernet switches, a Ubiquiti US24 and a Ubiquity 16XG. They’re connected via a pair of 10G fiber connections with LACP. The 16XG is also connected to the 16XG in the basement via a pair of 10G fiber connections with LACP. I use the copper 10G connections in the 16XG in the under-desk rack for Mac Studios and a Threadripper 3960X Linux workstation in my office. I use the US24 for CalDigit docks (for wired laptop connectivity), Raspberry Pis, etc. There’s a patch panel for each switch that passes through to parallel patch panels in the rear. This lets me keep the cabling in the front super-clean (just short patch cables).

There’s a Middle Atlantic 3U fan panel in the rear, exhausting air. There’s an ancient Best Power UPS in the bottom that just keeps on working (with battery replacements every 3 or 4 years). There’s a Furman PDU in the top with pull-out LED lights.

It’s on casters, and can be rolled out easily to gain some work space (more than shown here). The top insert is porcelain, the same as the rolling drawer cabinets.

There is a lot of ventilation in the front door. The front window is scratch-resistant polycarbonate, but the door box is vented on all 4 sides. There are two layers of stainless steel mesh in the vents. One is coarse for strength, the other is fine to keep pet hair and dust bunnies out. The inspiration here came from a pie cooling cabinet in an old bakery I used to visit. The air flow in this cabinet is front-to-back, for the components and the CloudPlate.

More office furniture: a second rolling drawer cabinet

This was mostly a duplicate of a similar cabinet I had already built. And I already had built the shell, but not the top or the base. It’s taller than the first, to allow for some shelf space. I finished it recently. No in-progress pictures or even nice pictures. 🙂 But it has 21U of rack space. 19U is consumed with old Middle Atlantic TD drawers. 1U is consumed by an old rack mount PDU. The drawers are much deeper front-to-back than the PDU. Hence 1U below the PDU is a blank, which allows space for wall warts to be plugged into the PDU. The shelves are on shelf pins, so it’s easy to get to the outlets on the PDU by pulling out the lower shelf. Having the PDU here let me mount my Lutron and Hue hubs on the wall next to the Unifi in-wall HD WiFi access point. The access point is powered via PoE, but the Lutron and Hue hubs use wall warts. The Hue hub lets me control the Hue table lamps and the Hue bulbs in the floor lamps in the den via HomeKit. The Lutron hub lets me control the recessed lighting via HomeKit. I have Lutron stuff elsewhere in the house, and all of it currently uses this hub for HomeKit control (usually via Siri).

I bought most of my Middle Atlantic drawers about 25 years ago. The price has nearly tripled since that time, so I’m glad I bought so many of them way back when. They were originally in two of my server racks and a pair of MDV-R12 cabinets. I’ve been repurposing them for years. They’re durable, they happily hold more weight than I’ll ever need to put in them, I can reconfigure as desired, and they look good to me. This cabinet has two 5U drawers with locks, a 4U drawer, a 3U drawer and a 2U drawer.

Below is the other cabinet that I mostly duplicated. This one was finished in July 2022 while I was still working on the floor (hadn’t finished the shoe moulding). It’s now on the opposite side of the French doors.

Both of these cabinets are on casters, so I can move them as needed. Both are solid oak with porcelain inserts in the top that are intentionally just taller than the wood frame. So when I slide something a bit off the porcelain, it doesn’t scar the wood frame.

More office furniture: a bench

I’ve been working on a bench for the home office. I wanted something big enough for a short person like me to be able to lie down on (say while waiting for a make -j4 buildworld to finish on FreeBSD on slow hardware), and strong enough to outlive me and a now young oak tree to replace the wood I used.

I also wanted a little bit more drawer space. As is my penchant, I’m using Middle Atlantic TD rack mount drawers (all of my office furniture is sized to accommodate 19″ rack mounted gear). However, the bench spans the only HVAC register in the room (in the floor), and the combination of the position of the register and the width of the window bay meant that I could only put drawers in one side. For now I’m only occupying 5U of the 8U rack space, because I suspect I’m going to want a 3U fan panel to assist the HVAC when summer arrives.

The bench will be getting a cushion, of course. It is solid oak, with the base constructed of 4×4 legs and 2×4 stretchers. The top is 1 3/8″ thick oak butcher block (a workbench top), which I framed with 1×2 oak. It’s 61.5″ wide and 25.5″ deep. The height was dictated by the window sill; I didn’t want to block access to the handle in the lower window sash.

The feet are 1″ thick Delrin, bolted to the bottom of the oak legs via countersunk 5/16″-18 stainless countersunk bolts that thread into threaded inserts installed in the oak. I rough cut the Delrin, then mill the countersinks on the drill press. I then mark for the inserts in the oak.

I then drill the holes for the inserts and install them.

I then bolt the foot to the leg.

I then use a flush cutting bit on my trim router to make the feet match the leg, then run a roundover bit on the edges. Delrin/acetal machines like butter, even with woodworking tools. I use 1″ thick Delrin/acetal for heavy furniture feet, since it allows me to countersink the 5/16″-18 bolt heads more than 1/4″ (zero chance of the bolt heads contacting a floor for the next 75 years), while still having a lot of Delrin/acetal grabbed by the bolts. It’s not cheap, but it is fantastic for this application. If this were going on a wood floor I’d round over the countersink edges, but it’s going to live on porcelain so there’s no need. When I first used these kind of feet on the desks, I used 4 bolts. But 2 is plenty.

I have more than once considered UHMW instead, mostly for the cost saving. But it doesn’t machine quite as nicely, and it’s also not terribly dimensionally stable over temperature and humidity. Of course, neither is wood, but oak sealed with shellac and polyurethane doesn’t move much. And importantly, all of the weight is sitting on the feet. I don’t want them to squish over time. My desks are REALLY heavy, but the feet have held up beautifully. Honestly, if your design affords it, I can heartily recommended Delrin/acetal for feet. But even if you don’t use Delrin/acetal… replaceable feet are awesome. Here they’re on square oak 4x4s, but Delrin/acetal is also easy to lathe if your leg ends are round.

The top also has threaded inserts in the bottom, and the base pieces bolt to the top via countersunk 5/16″-18 bolts through the stretchers from underneath. The next picture shows one of the bolts (washer not shown) threaded into one of the inserts, and an insert installed into the bottom of the top.

The next picture shows the deeply countersunk holes in one of the top stretchers (the bench is upside down here). This is from before I glued and doweled the base pieces together.

The left part of the base is doweled and glued (Titebond III) together, as is the right leg assembly. It looked like this after assembly.

The bench is heavy even without the drawers (I’d guess about 75 pounds), but the Delrin feet allow the bench to glide easily on the porcelain floor when desired.

I am one of those people that likes really solid bench seating and bedding. Something that doesn’t flex or squeak, at all. And doesn’t move unintentionally but can be moved easily as needed. And can be disassembled/reassembled should it need to be carted up/down stairs. And fits the intended space exactly.

Objectives met.

mcrover can now check backup status (dumpdates)

I finally finished the small remaining piece of work to have mcrover monitor my backups. Specifically, those using ‘dump’. I have 10 computers using dump for automated nightly backups, over the network. Once in a while I’ll accidentally create a problem via access configuration and not realize that my nightly backups aren’t happening for one of the 10 computers. Since I run mcroverd on all of these computers, it makes sense for it to be able to tell me when a backup hasn’t occurred as scheduled.

Right now mcrover only looks for any level of dump within a configured interval for the given configured devices, not for specific levels. I’ll augment this with the ability to check specific levels later, once I decide on a sane configuration syntax to support it. At the moment I trust my dump driver, I’ve been using it for more than 20 years at this point and have done multiple partial and full recoveries from the dumps. If dumpdates is correct, it just works.

The current configuration syntax in the local stanza of the configuration looks like this:

 
 #--------------------------------------------------------------------  
 #  Check that a 'dump' of the given devices has occurred within the
 #  given time interval.  
 #--------------------------------------------------------------------  
 DUMPS = [ { device = "/dev/gpt/gprootfs"; period = 1d6h; },
           { device = "/dev/gpt/gpusrfs";  period = 1d6h; },
           { device = "/dev/gpt/gpvarfs";  period = 1d6h; } ];
 

This ticks a box for yet another thing I’ve always wanted at home. mcrover only shows me problems, and that’s what I need. I don’t want a dashboard I have to make time to read. Checking my backups here is handy.

Here we go again… GM killing CarPlay and Android Auto

I wrote this post in April of 2023, but didn’t publish it until now.

https://www.theverge.com/2023/4/4/23669523/gm-apple-carplay-android-auto-ev-restrict-access

My advice to readers: invest in companies that make cell phone mounts for cars.

Does anyone still remember CUE, other than those still suffering with it?

79% of U.S. car buyers today, from polls, say they will not buy a new car that does not have CarPlay.

There are some fundamental disconnects here in GM’s universe. It’s one thing to want to turn us all into a revenue stream. Or follow Tesla and Rivian. However… all of these companies have largely missed the whole reason we want CarPlay and Android Auto. It doesn’t matter how good the infotainment interface is in the car. I’ll ignore the fact that most of them are downright awful. Let’s assume GM somehow comes up with a fantastic HMI.

The fundamental problem: what we, as consumers, want…

Your typical U.S. car owner carries most of their life in their pocket. It’s called a smartphone. It’s with them 16 or more hours per day. It stores piles of entertainment (music, movies, etc.). It stores all of their contact information. Their email. Their text messages. Their huge photo collection. Their digital wallet (credit cards, driver’s license in some states). It has great navigation software from multiple vendors. It has voice assistance that actually works. Oh, it can also be used to place phone calls. If it’s an Apple device, it gets updated very regularly (without a subscription fee). And most of us buy a new smartphone more frequently than we buy a new car. Meaning we don’t just get new software, we get new hardware. Way more frequently than we expect an automobile to be recycled. And… my coworker gets in my car, or I get in a rental car, or my mom borrows my truck… pair a phone (once), go. This universality has been one of the key reasons consumers have loved CarPlay and Android Auto.

It makes absolutely no business sense to cut off Apple CarPlay and Android Auto. We spend how much time in our cars? Maybe an hour a day on average? Versus how much time with our smartphones? 16 hours? More?

I’m all for GM and others improving their HMI, especially for infotainment since it’s been pretty much atrocious forever. But you’re NEVER going to compete with a smartphone I carry with me all day every day. Unless you decide to build a smartphone. It’s not at all about, “I like this interface more.”. It’s “My whole life is on this one device, please let it connect to the infotainment system in my car in an easy-to-use meaningful way. I don’t want a disparate collection of devices for phone calls, meetings, navigation and voice assistants. I want other things to work with this one device that is always with me.”

I’m old. So I can’t speak for the current generation. But what little I know, and from what I see in surveys… today’s 16 year old has WAY less interest in cars or driving than those of my generation. Whether that’s good or bad doesn’t matter. It’s just a business reality. And blocking our far-and-away primary computing devices is a bad business decision. GM, read the surveys instead of putting your head in the sand. This isn’t an either/or thing. For most of us, it will never be the case that we spend enough time in our cars to come even close to the amount of time we spend with the devices we carry 7×24. I’m all for better systems in our cars. But we live in a networked world and if you’re deciding to eliminate what has been a desired connection by 80% of buyers (and in fact a required checkbox when shopping), that’s what I call Ostrich Syndrome. Otherwise known as willful ignorance.

If GM follows through with this, for me it means I’ll be shopping elsewhere. And I’ve had a GM vehicle as my daily commuter for a long time. And I get a discount. None of these things will make me buy a vehicle without CarPlay. And I’m FAR from alone.

Funny conspiracy theory: since GM says it’s going to keep shipping ICE automobiles with CarPlay, is GM trying to kill their EV business and just ride ICE ’til it’s dead?

The other funny part… most of us use our vehicles to get from point A to point B. They lost their cultural significance about 40 years ago. Many of us begrudgingly spend time in them. Sure, luxury vehicles are nice. But nearly none of us ever sit in our car if we can sit outdoors or in our homes. Remember drive-in movie theaters? Gone a long time ago. Sitting in your car to eat at an old school A&W? Pretty much gone a long time ago. Driving up and down Woodward Avenue as the nightly entertainment? Gone. Going out for a drive just for a drive? Mostly gone. And of course the elephant in the room: the person spending the most time in a given vehicle is the driver. Guess what? They’re supposed to be driving. Preferably not distracted. When we get to Level 5 autonomous vehicles… hell yeah, give me a giant 21:9 screen (or 4!) and a recliner! But I honestly don’t see that happening in my lifetime in the U.S.

So until that day arrives, if I’m in my vehicle, I’m driving it. A vehicle has essentially zero chance of entertaining me beyond audio and navigation. I’ll place my phone calls via the device in my pocket, for which I’m already paying monthly communication fees. And most of the time I won’t be using it for calls while driving.

Web server OS upgrade woes (FreeBSD 12.4-STABLE to 13.2-STABLE)

Well, I’m still working on it after 4 days, but… my web server is running FreeBSD 13.2-STABLE.

This all started with the desire to have C++20 on all of my general purpose computers. Obviously I don’t get all of C++20 with clang++ or g++, but my web server was the only machine left that didn’t have the parts of C++20 that I need. And my only FreeBSD host not yet running 13.2-STABLE (I have 5 FreeBSD hosts, 2 of which are Raspberry Pis),

The OS upgrade went fine as usual. It’s dealing with all the other stuff that gave me grief. A biggie was that ‘pkg upgrade’ (which I did not intend to run without arguments) updated mysql57 to mysql80, breaking database access for Randy’s photo gallery and my blog.

The php upgrade meant I had to hack some php in Piwigo, update WordPress for my blog, and fix some of my rudimentary php classes.

A boost library upgrade rendered a bunch of my web apps nonfunctional due to incorrect shared library path.

There’s a long list. But a lot of it is just due to procrastination on my part. Making changes to a ‘production’ server at home is always risky, but it gets worse the longer you wait. I mean, I had waited so long on php that the language changed (and broke existing code).

Lesson learned. I’m mostly back up and running, but I still have a to-do list. That includes possibly migrating to different hardware. My web server was built in November of 2012; it’s old. It was specifically built with an i5 2405S CPU to keep power consumption reasonable. And the load is pretty light. It’s in an overkill 4U case with 12 hot swap bays wired to onboard SATA and an HBA in a PCI slot. It also has a Mellanox 10G ethernet card. All I’d really like is modern I/O (NVMe) and 8 or more cores. The 2405S does not have HyperThreading. The current motherboard is MicroATX, so I think it’s reasonable to find a MicroATX board to replace it.

The other option is to buy a replacement for my storage server (dual Xeon L5640) and then use the existing storage server to replace my web server.

Random thoughts on C and C++ Safety and our path forward

I recently posted a list of recent talks about C and C++ safety. As anyone who works in safety critical space knows, this isn’t a new issue. It’s just finally getting attention outside of the software engineering discipline. As Bob Martin has been predicting for something like 50 years, we either get our act together or the government will impose regulations. The latter is happening and is likely to continue.

C and C++ are unsafe languages. This isn’t news and hasn’t changed since the inception of these languages (1972 for C, 1979 for C++). They are not memory safe, they are not type safe, and they contain a long list of undefined behavior. They have foot guns. This doesn’t make them useless.

So what has changed since C became the system programming language for most of the computing universe? Well, pretty much everything, except our primary system programming languages.

Let’s start with the obvious. Software is everywhere today. Just looking around my office, I can count more than 25 devices with software in them. And I believe all of them are running code that was compiled from C. My workstations, the clock on the wall, the smart light bulbs, my watch, my oscilloscope, my power supply, my USB and Thunderbolt devices, my cell phone and my landline phone, my wireless headphones, my UPS, my ethernet switches, my monitors, the thermostat, Raspberry Pis, my e-bike in the hallway, etc.

Another obvious fact… almost all of these devices have Internet connectivity. They present an attack surface. And security is a prerequisite to safety.

And another… the scale of the systems we’ve built is astounding and has happened in a short period of time. Systems we’re using today were unimaginable 20 years ago.

A key change from a safety perspective is part of the first obvious change, which is that software has deeply penetrated many safety-critical systems, and has added an attack surface (Internet connectivity). This has happened fairly quickly. Cars in the 1970’s had no software at all. That was largely true in the 1980’s as well. Today, a typical luxury car has somewhere in the neighborhood of 150 microcontrollers running independently developed software. In the 1970’s we didn’t have ATMs. We didn’t have Wifi. We didn’t have the public Internet.

C and C++ simply aren’t the right tools in safety critical systems. I say this as someone who loves these languages and has spent a career writing code in these languages.

There’s been a lot of hand-wringing over this for some time, but much of it has occurred within the enclaves of particular industries, i.e. those where safety is required. In particular, where safety is regulated. Medical devices, aviation, automotive, industrial, et al. If you’ve never worked in one of these industries, the odds that you’ve thought at all about software safety are quite low. If you’ve worked in these industries, you’ve seen all of the process and tooling that’s required to certify C and C++ code. And in many environments, the power of these languages is dramatically reduced by only allowing a subset of the language and/or standard library, not to mention the “no dynamic memory allocation” rule present in many environments.

The reality is that C and C++ are going to eventually disappear from safety-critical systems. They will not become memory safe, nor type safe, nor free of most of their undefined behaviors. They won’t be what we think of as C and C++ if they do. We already have significantly safer languages, some of them quite mature (Swift, for example), and C++ inertia will prevent it from competing here. On cost alone, C++ will eventually lose here.

The other reality is that we don’t yet have a suitable replacement. The recent work to certify Rust at ASIL D (ISO 26262) is encouraging, but we’re still in a state where we can’t use it everywhere (deployed target microcontrollers that the Rust compiler does not target), and of course we can’t just rewrite everything. Is Rust worth a look on green field projects? Of course. I can mostly say the same for Swift. But in both cases, we don’t yet have all of the surrounding infrastructure to use either of these languages in a certification-required environment.

C and C++ are going to be present in safety-critical systems for a long time. Well beyond the end of my career and probably yours as well. Victims of their own success.

Which brings us to the real questions…

  1. Can we make our existing C++ code safer?
  2. When might we see a safe successor?

1: yes, of course.

2: I think a good successor is probably 10 years away. Which happens to match Chandler Carruth’s prediction for a fully usable version of Carbon (which is one of many potential successors). It seems an absurdly long time, but until we have regulated accountability, it’s going to be difficult to impossible to argue the return on investment in many environments. And without regulations, there’s going to be a much smaller group of us doing anything at all about it.

In the interim, I expect much “business as usual” in safety-critical systems. We’ll use MISRA, et. al. and all of the processes we see in the industries where safety is already critical. What might change here is the adoption of safety processes and standards in more industries. I kind of shudder at the thought of imposing third-party audits on (for example) all IoT devices. At the same time I’m very aware of the risks of unsafe and insecure software. And of course I worry about government making ignorant legislation. But at this point in civilization, the horse has left the barn. But if you think about it, as Robert Martin has pointed out a zillion times, we brought this attention on ourselves.

If a memory-safe successor to C++ is 10 years away… the hand wringing will continue and I would expect at least some liability legislation in the U.S. and the E.U. before 10 years transpires. And I expect some of it to be controversial, some of it to only be resolved in the courts, etc.

I’m not a gloom and doom sort of person. I’m actually fairly optimistic here. For one, it means those of us who already care deeply about the quality of our work will be valued. Secondly, civilization has always had a tendency to be reactive instead of proactive. Crisis is a mother of invention. We have many ideas and languages coming up to express and test those ideas. Swift, Rust, Val, Carbon, Circle, Cpp2 as examples. And of course we’ll get C++26 and C++29, but C++ will never be a memory-safe language.

Speaking of that, I encourage others to read “The Meaning of Memory Safety“.

Edit: I just saw Timur Doumler’s “C++ and Safety” talk from CppNorth 2023. He covered much of what I’ve been thinking the last 2 to 3 years. I think of all of this as a good sign. Most of us know where we are and the limitations. Some of us have to care because we work on safety-critical systems, while others (say a typical HPC application) have no safety requirements. Timur did a nice job of highlighting the tradeoffs and the audiences.

C and C++ Safety talks, 2022 and 2023

If you’re in the C++ community, you’re presumably aware of all of the recent attention given to ‘safe’ versus ‘unsafe’ code, ‘safe’ versus ‘unsafe’ programming languages, memory safety in general, type safety in general, etc.

This attention is not actually recent. We’ve had IEC 61508 and all of its descendants for a long time. DO-178B is more than 30 years old. The first MISRA C standard was published in 1998.

What is recent is the attention from a broader audience, to include those who are not practitioners. Some of this attention came from the NSA’s publication of https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF in November 2022 and the subsequent press coverage. To the untrained reader, some of the press simply reads as “C and C++ are unsafe languages, don’t use them.”. What was actually said was “NSA recommends using a memory safe language when possible.”

In January of 2023, we saw “Future of Memory Safety” from Consumer Reports. Followed by the National Cybersecurity Strategy in March of 2023. And before we had the reports in the U.S., we had the Cyber Resilience Act in the E.U. (fall of 2022).

“C and C++ are unsafe languages” is a verifiably true statement. Undefined behavior abounds, and by definition, a language with undefined behavior is an unsafe language.

int  a = 0;
int *b = &a;
*b++ = 1;
*b++ = 2;

OK, so it’s a contrived example. But it makes the point; C and C++ are memory unsafe.

This isn’t a simple topic. I started writing C code sometime in the 1980’s. I started using C++ in the mid 1990’s, and have used it heavily since that time. Which is to say that I’ve written a lot of code in unsafe languages. Not because I’m a masochist or a rebel, but because they’ve been the most effective system programming languages at my disposal. Our general purpose operating system universe has been built on C.

The good news, if you need to brush up: there have been numerous conference talks in the last 2 years about C++ safety. Some I can recommend…

Software is a young field filled with young people. Us old people are still around, but as Robert Martin (‘Uncle Bob’) has noted many times, the percentage of practitioners with 5 or fewer years of experience is very large because the growth has been rapid. Meanwhile there are all the surprising and unintuitive behaviors of our primary system programming languages that take time to internalize. Just go look up the probability of an overflow of the multiplication of two integers in C, and ask your coworker what he or she thinks it is. Then proceed to lose sleep thinking about the lines of code in your projects that might trip integer overflow or other undefined behavior. How good is your static analyzer? How much code was changed between the time you reviewed and approved the suppression of a MISRA violation and today?

Even if you’re a relatively new C or C++ programmer, watch the talks above. And here’s a recent link that might be helpful to those new to C.