So you need a cell signal booster? This is our definitive, 7,000+ word guide on exactly how to find the right cell phone signal booster.

National Airspace System Online Course
computer-tablet-phone-small

$24.99
Add Airspace To Your Cart
Feeling a little unsure about airspace? We've all been there.

Whether you're preparing for a checkride, or trying to knock the rust off before you fly to new airports, airspace is probably the most confusing and challenging part of flying.

If you're trying to get up to speed on airspace, this course is for you. You'll learn everything you need to know, including Class A-G airspace, Special Use Airspace, and Other Airspace in a simple-to-use online course.

Buy the course, and you'll feel confident flying through any airspace. And, we think you'll love it so much, we even have a 30 day no-questions-asked money back guarantee.

Best of all, you get lifetime access to the course. And, you can use it on your computer, tablet and phone.

Quick and dirty cheat sheet for anyone getting ready to set up a new ZFS pool. Here are all the settings you’ll want to think about, and the values I think you’ll probably want to use.

I am not generally a fan of tuning things unless you need to, but unfortunately a lot of the ZFS defaults aren’t optimal for most workloads.

The billionaire Richard Branson went 53.5 miles into the sky on Sunday, short of the Kármán line, which is 62 miles above sea level and where it is generally agreed that space begins. Branson did surpass 50 miles above sea level, above which NASA gives out astronaut wings. But come on, man, Branson’s stunt only barely cleared that. //

let’s accept the 50 mile rule for argument’s sake, anyway, and say that Branson was indeed in space, where he spent about a minute-and-a-half before falling back to earth, which is the functional equivalent of having a layover at JFK and then claiming you’ve been to New York City. That might technically be true but simultaneously be complete hogwash.

Instead, I hereby propose a simple, achievable definition of “going to space,” which is that you must orbit the Earth at least once while you’re up there, something that Branson did not do. And, while Alan Shepard and Gus Grissom might be a little mad that their first flights will no longer count, in Alan Shepard and Gus Grissom’s day there weren’t weirdo billionaires engaged in pointless space races.

How the FAA is Working to Reduce the Impact of Aircraft Noise

By Tom Hoffmann, FAA Safety Briefing Managing Editor

If you still don’t have any internets after power-cycling and your modem showing everything sync’ed and online, you may be falling afoul of a weirdness in OpnSense’s default gateway configs. By default, it will mark a gateway as “down” if it doesn’t return pings… but many ISP gateway addresses (not the WAN address your router gets, the one just upstream of it) don’t return pings. So, OpnSense reports it as down and refuses to even try slinging packets through it.

zfs destroy has a dry-run option, and can be used to delete sequences of snapshots. So you can see before-hand how much space will be reclaimed by deleting a sequence of snapshots, like this:

root@box:~# zfs destroy -nv pool/dataset@snap4%snap8

It seems like a stupid question, if you’re not an IT professional – and maybe even if you are – how much storage does it take to store 1TB of data? Unfortunately, it’s not a stupid question in the vein of “what weighs more, a pound of feathers or a pound of bricks”, and the answer isn’t “one terabyte” either. I’m going to try to break down all the various things that make the answer harder – and unhappier – in easy steps. Not everybody will need all of these things, so I’ll try to lay it out in a reasonably likely order from “affects everybody” to “only affects mission-critical business data with real RTO and RPO defined”. //

TL;DR: If you have 280GiB of existing data, you need 1TB of local capacity. //

8:1 rule of thumb
Based on the same calculations and with a healthy dose of rounding, we come up with another really handy, useful, memorable rule of thumb: when buying, you need eight times as much raw storage in production as the amount of data you have now.

So if you’ve got 1TiB of data, buy servers with 8TB of disks – whether it’s two 4TB disks in a single mirror, or four 2TB disks in two mirrors, or whatever, your rule of thumb is 8:1. Per system, so if you maintain hotspare and DR systems, you’ll need to do that twice more – but it’s still 8:1 in raw storage per machine.

In a scathing response, Jack Pelton called the new interpretation a “solution to a nonexistent problem.” //

Pelton concluded by writing, “This entire episode is a scary example of how new interpretations of the regulations can upend the entire community. While this short-term fix allows operations to continue, it never should have come to this point. Creating more than 30,000 new LODAs and exemptions is a paperwork exercise that does nothing to advance safety.”

As it turns out, the problem is that Dovecot—which handles IMAP duties on the server—doesn’t notice when the certificate has been updated on disk; it will cheerfully keep using an in-memory cached copy of whatever certificate was present when the service started until time immemorial. //

I created a new root cron job to restart Dovecot once every Sunday at midnight:

# m h dom mon dow   command
0 0 *   *   Sun   /etc/init.d/dovecot restart

Since Certbot renews any certificate with 30 days or less until expiration, and the Sunday restart will pick up new certificates within 7 days of their deployment, we should be fine with this simple brute-force approach

I tend to be pretty firm on how disks relate to vdevs, and vdevs relate to pools… but once you veer down deeper into the direct on-disk storage, I get a little hazier. So here’s an attempt to remedy that, with citations, for my benefit (and yours!) down the line. //

The zpool is the topmost unit of storage under ZFS. A zpool is a single, overarching storage system consisting of one or more vdevs. Writes are distributed among the vdevs according to how much FREE space each vdev has available – you may hear urban myths about ZFS distributing them according to the performance level of the disk, such that “faster disks end up with more writes”, but they’re just that – urban myths. //

Also note that the pool’s performance scales with the number of vdevs, not the number of disks within the vdevs. If you have a single 12 disk wide RAIDZ2 vdev in your pool, expect to see roughly the IOPS profile of a single disk, not of ten!

There is absolutely no parity or redundancy at the pool level. If you lose any vdev, you’ve lost the entire pool, plain and simple. Even if you “didn’t write to anything on that vdev yet” – the pool has altered and distributed its metadata accordingly once the vdev was added; if you lose that vdev “with nothing on it” you’ve still lost the pool.

It’s important to realize that the zpool is not a RAID0; in conventional terms, it’s a JBOD – and a fairly unusual one, at that. //

Even if you’ve done your homework and are absolutely certain that your disks use 512B hardware sectors, I strongly advise considering setting ashift=12 or even ashift=13 – because, remember, it’s immutable per vdev, and vdevs cannot be removed from pools. If you ever need to replace a 512B sector disk in a vdev with a 4K or 8K sector disk, you’ll be screwed if that vdev is ashift=9.