Renee Good. Alex Pretti. It's a sickness.

Fuck this shit.

These current events transcend politics. It is not a "left" or a "right" issue; it is an American issue. For this Administration to immediately come out after each of these killings with their "narrative" of easily disputed "facts" that blindly support Federal agents is fundamentally un-American.

It is incredibly disconcerting that this Administration has no interest in investigating these tragedies. Rather, such blind support operates to instead encourage future attacks.

In a sane government, facts would be collected and a thorough investigation would be completed before any official statement is made. While the outcome of such investigations has historically been met with mixed reception (i.e., depending on one's political leaning), it is critical that these investigations be undertaken. The Federal government cannot be permitted to execute people with no due process and no oversight.

Instead, Donald and his Toadies have characterized both Renee Good and Alex Pretti as domestic terrorists. The Department of JuStIcE even declined to investigate Good's killing, instead attempting to launch an investigation into Good's partner. How asinine.

I write this as I watch a steady stream of shit flow from Greg Bovino's lips, dodging questions by claiming that there will be an investigation. And yet, he already characterizes Pretti as a "suspect" and not a "victim". Even in the face of the utter absence of evidence (and, indeed, ample evidence to the contrary), Bovino repeatedly asserts Pretti was there to assault ICE agents and commends the ICE agents for moving quickly to preserve their own lives. Righteous mag dump, maaan! So strange that the "life-saving aid" administered to Pretti was ineffective. Fuck all these assholes.

You'll have to forgive me if I don't trust this Administration to effectuate a thorough, unbiased investigation. This Administration has given us reason to distrust them at literally every turn.

Which brings me to the continued disintegration of our shared lexicon.

The first time I heard the word "insurrection"? Following Donald's "Day of Love" 😍™ on January 6, 2021. I spent the entire day glued to coverage of the US Capitol. You don't even have to take my word for it (or Donald's) that it was not a spirited tour of the Capitol.

That day was fundamentally un-American and should have disqualified Donald from Office. But heaven forbid his army of delicate snowflakes be offended that their Orange Jesus be prohibited to run again for attempting to interrupt the peaceful transfer of power. Very legal and very cool.

Now? Donald characterizes people as "seditious" or "insurrectionists" with abandon. The video reminding Service Members of their obligation to disobey illegal orders is factual and, in a sane environment, should not be contentious. And yet, Donald characterized those that participated in the video as seditious insurrectionists. Hang them! But pardon those involved in Donald's Day of Love and settle with Ashli Babbitt's family (who was, rightly, killed while she tried to attack members of Congress). The facts surrounding the killings of Ashli and Renee could not be more different, and yet Ashli apparently should be revered while Renee is villainized? Guess Renee wasn't driving for the benefit of DJT, bummer.

Even yesterday, as Minneapolis leadership spoke out against the Federal occupation of their state, Donald similarly asserted these leaders are "inciting insurrection" (something with which Donald is, in fact, uniquely familiar).

"Domestic terrorism" and "enemies from within" are also terms that have been bastardized by this Administration. Forgive me if I find it hard to believe that the unarmed victims who were brutally murdered by the Federal government are the "domestic terrorists" in these tragedies.

Are people scared to go to the grocery store and get haircuts because of Renee Good and Alex Pretti? Are they really the "terrorists" here?? Or are people staying in because of the current Federal occupation of their city? Gee hmm, I guess it is really hard to say until Bovino finishes his investigation of Pretti's aCtS of TeRrOr. We had best wait with bated breath.

But don't worry, you can't get shot if you stay indoors. Except maybe now you can, since ICE has decided to not only flout the First and Second Amendments, but now to also, allegedly, flout the Fourth Amendment. I fear next we'll see someone get shot for having a gun in their own house during a Donald-sponsored attempted-kidnapping-turned-murder.

In closing, I will acknowledge that I, too, have been using loaded language. "Suspect" versus "victim" and, indeed, "killing" versus "murder". As an aside, Babbitt was not just a killing, but actually even a justified "execution" (i.e., having a legal basis). Having cognized videos of these most recent events from many angles, which is more than it seems Donald, Bovino, and Noem have done, I feel at least somewhat more qualified to call Good and Pretti "victims" and these tragedies "murders". There sure is a dearth of facts to support an opposite conclusion.

We are due investigations that will bear out more facts (even as Bovino decries the "freeze-frame adjudication of a crime scene" that counters his entirely fictitious narrative). I am hopeful Minnesota can effectuate these investigations, as this Administration cannot be trusted. I am comforted that murder does not have a statute of limitations, nor can a State murder charge be pardoned by our malignant-narcissist-in-chief. The pendulum will swing the other way eventually, and I hold out hope for inevitable Justice (not JuStIcE, as Bondi, Noem, and this Administration at large are wont to dispense).

Do not kid yourself: Good and Pretti are not "domestic terrorists". These people are you, and these people are me. They are US citizens who were documenting a tyrannical government as it continues to violate constitutional rights (which are inherent in people, citizens or otherwise), as enabled by a complicit, spineless Congress. We should all aspire to be so courageous as Good and Pretti.

So fuck Donald. Fuck Hegseth. Fuck Bondi. Fuck Noem. And fuck Bovino.

These people are dishonest in the worst way (as much as I like to believe that Donald is also incompetent) and are entirely divorced from reality, as it does not serve them. We must reject their fictitious, curated "narrative" and must not lose footing in our shared, fact-based reality, especially as their language is specifically engineered to erode the very words we rightly use to describe them and their abhorrent actions.

Donald is an insurrectionist, these people are seditious, they do encourage domestic terrorism, Congress is complicit, and Good and Pretti were murdered. May we not be next.

This post has been percolating for a while, and I received an email today that finally helped crystalize some thoughts. The email, titled "We asked ChatGPT what makes the perfect charger", made me wonder: "who even cares?"

(btw the image for this post is shitty on purpose, so you know a human made it)

Fuck AI

It isn't like ChatGPT actually reasons or even thinks, as much as the apparent majority of people want to believe that it does. Barring any such genuine thought, why should anybody care what ChatGPT has to say? At best, "AI" mashes up sentiment from various corners of the internet (and other plagiarized sources; pls @me, Zuck) and vomits out seemingly coherent slop that tricks readers into placing some level of importance on its output. But hey, thanks for sending me an email with a bulleted list that your product happens to satisfy. So cool. #unsubscribe

Could "AI" be more useful than a search engine someday? Maybe. Especially given the SEO hell that we've been enduring for some time now. Thanks for sucking, Google. But do I trust "AI" in its current iteration? Not even a little.

I can't stand when people try to parrot an "AI Summary" at me like it's an authoritative source. The vast majority of questions that I've posed to AI have yielded incorrect answers. I tried my hand at "vibe coding" last weekend (what a rush!), and ChatGPT was wholly ineffective at resolving my issues. They were issues that it even created! It turned out there was a whole separate library that ChatGPT did not know to reveal, but which Google readily surfaced.

Could it be my own personal failing as a reluctant "prompt engineer"? 🤮 Perhaps, at least in that instance.

Other "AI" failings include incorrectly listing product specs when asked to compare different binocular offerings (what a challenging problem), manufacturing textual excerpts of website "sources", and providing an incomplete answer when asked for a bike tyre recommendation (i.e., only offering a strong recommendation for a specific rubber compound at the very end of the chat; where was that insight earlier!).

But does any of this even matter? The public, AI companies, and especially company execs, are blindly forging ahead. Racing, allegedly, ever closer to AGI. So, so magnificent. "It will save time but it still needs human supervision," they say. "Everyone else is doing this, so we must, too."

To which I says: a tool that is right only 99% of the time is still fundamentally worthless, at least in some applications, as humans will be lulled into a sense of complacency. Either people will not fully appreciate the limits of the tool or they will be too time-constrained to properly review the output, ultimately inadvertently introducing (subtle?) errors into the world. Made all the more dangerous by the heady façade of genuine conception.

Case in point: people blindly relying on AI summaries; chatting with AI on a daily basis and taking its slop as gospel; or extolling its virtues and claiming it engaged in actual innovation (I had someone tell me they asked it to invent a dog poop removal device). Sure.

AI slop is also particularly insidious. It is so, so easy to generate an incredible amount of content. Content that is then much more slowly consumed (I absolutely cannot stand that term; that's been a potential post topic for some time). It's basically a DDOS attack, but for the human attention span.

Why do people pass along content that they themselves likely haven't taken the time to fully digest? (In stark contrast to human-produced content, where the author actually bears the disproportionate burden of creation; btw you're welcome for this absolute gem of a post, and I haven't even been drinking... yet).

Fuck Donald

Eerily, all of this seems to mirror the current political climate, where a certain orange and not-yet-Luigied snowflake frames anything negative as a hoax, a political hit job, or just plain nasty. Please, slurp down a gigantic bowl of dicks, Donald. Really swish them around on their way down your turkey neck. And maybe give me a mean nickname. That'll really show me.

The shear amount of shit produced by this administration has been incredible. We are only six months in, and every day feels like we are plumbing new depths, delving ever deeper into the pit of despair.

Even in spite of Donald's Daily Deluge of Dogshit™, half of the country is still apparently happy to take what he and his other complicit shitbags say as gospel, having no question as to veracity. By contrast, anything from the "legacy media" must be approached with cRiTiCaL ThInKiNg. But yes, please, let's all defer to the octogenarians, pedophiles, influences, and whatever the hell the manosphere is. Praise be, thank God for the new media!

And Fuck All This Shit

All that to say: there is one population of people who are happy to have AI lube them up in slop, greasing their eyeballs until their brain is numb with content in an effort to stave off boredom from real life, and there is another population of people who have been diverging from our formerly shared political reality, guzzling down asinine falsehoods from our Pedo in Chief (and Karoline Leavitt, what an abhorrent human) and begging for more. These populations are certainly not mutually exclusive.

I hope there are still (many?🤞🏼) people who fall outside these circles and that actually apply critical thinking, and not in the "Take America Back" (from what, liberty? freedom?) sense of the term.

Sadly, it is easier to take both ChatGPT's extreme indifference toward accurate/inaccurate statements (again, it can't think; it doesn't know what is true) and Donald's chronic NPD-riddled version reality (he does not know Truth™, either) at face value. To actually interrogate and engage with statements takes time, effort, and care, and sadly most people just don't seem to have that to give. Especially not when faced with the sheer volume of utter tripe that roams the Internet and spews from Donald's gullet.

I feel like this post has big "old man yells at cloud" energy (BOM-YACE, not to be confused with BDE), and maybe I'm just getting old. But I make no apologies: I don't think this iteration of "AI" is it, and I really don't think subsequent iterations will manifest AGI (as much as Sam, Elon, and Zuck want us all to believe that).

All that notwithstanding: please, MechaHitler, tell me what to feel.

Imagine my surprise when I learned that CFexpress cards actually use NVMe at their core. It turns out CFexpress Type B uses two PCIe Gen3 lanes, with a maximum duplex speed of 2 GB/s. Conveniently, the Type B form factor is big enough that a 2230 M.2 drive can fit within it.

As a result, the "DIY CFexpress" adapters use a PCB that has no active components to effectively translate one connector to another connector. I really like that these adapters have no active components, because, it seems to me, that should limit the potential for variability between sellers/products (barring signal quality issues, but the traces are quite short). Also, as compared to a normal CFexpress card, these adapters include an outer case that is entirely CNC'd aluminum. I am hopeful that will to dissipate heat better than the normal plastic/metal mix.

Pictured above are two adapters from Sintech, which are also linked here for convenience (raw aluminum | anodized black). Surprisingly, buying from AliExpress doesn't seem to offer much in the way of savings (at least that I could see).

That said, going the DIY route has the potential to offer substantial cost savings. Call it $45 for an adapter and $160 for a 1 TB 2230 M.2 drive (or even apparently $170 for a 2 TB drive), and you have a capac-eous (pronounced kuh-PAY-shus) CFexpress card for ~$150-$750 less higher-end CFexpress card options. As an aside, that 2 TB price seems shockingly low to me; I paid closer ot $400 for the 2 TB drive that I had handy, but that was a long time ago and flash prices are rumored to continue plummeting this year.

Having put together two DIY cards using the above-linked drives (the raw aluminum is the 1 TB Sabrent 2230 and the anodized black is the 2 TB Micron 2400), I can say that my initial impression was very favorable. Yes, you give up two PCIe lanes and it's only Gen3, but cameras don't really need that much bandwidth (I mean, beyond the already generous 2 GB/s bandwidth contemplated by the Type B specification).

So, where's the catch?

Well, physically speaking, it is a tight fit. I think I remember the documentation mentioning not to use too much thermal paste (yes, paste; what a mess), otherwise it could negatively impact the thickness of the card and cause fitment issues. I had initially used a graphite sheet and I also tried a 0.5 mm thermal pad, and both definitely made it difficult to pop the card in and out of the camera. Beyond that, I'm pretty happy with the design and the included stickers are a nice thought (though there is no 2 TB sticker!).

Technologically speaking, I think there is a bit more of a catch. And that brings us to the motivation for this blog post. After the realization that CFexpress cards are really just NVMe drives, I sicced smartctl on my 256 GB SanDisk card to see what was reported back:

=== START OF INFORMATION SECTION ===
Model Number:                       WDC SanDisk CFexpress B SDCFE-256G NVMFW
Serial Number:                      --
Firmware Version:                   RO106CFP
PCI Vendor/Subsystem ID:            0x15b7
IEEE OUI Identifier:                0x001b44
Total NVM Capacity:                 256,060,514,304 [256 GB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.3
Number of Namespaces:               1
Local Time is:                      Sun Apr 30 16:38:47 2023
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0016):   Format Frmw_DL Self_Test
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Log Page Attributes (0x02):         Cmd_Eff_Lg
Maximum Data Transfer Size:         8192 Pages
Warning  Comp. Temp. Threshold:     80 Celsius
Critical Comp. Temp. Threshold:     90 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     2.50W       -        -    0  0  0  0        0       0
 1 +     2.50W       -        -    1  1  1  1        0       0
 2 +     1.70W       -        -    2  2  2  2        0       0
 3 -   0.0250W       -        -    3  3  3  3     5000    9000
 4 -   0.0025W       -        -    4  4  4  4     5000   44000

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        31 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    702,309 [359 GB]
Data Units Written:                 622,354 [318 GB]
Host Read Commands:                 4,701,192
Host Write Commands:                630,513
Controller Busy Time:               40
Power Cycles:                       5,015
Power On Hours:                     61
Unsafe Shutdowns:                   43
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Thermal Temp. 1 Transition Count:   15
Thermal Temp. 1 Total Time:         2554

Interesting. But mainly for reasons that will become apparent later.

Now, I didn't actually look at the SanDisk CFexpress card first. I had only looked at the SanDisk card after evaluating the performance of the DIY cards. In testing, the 1 TB card appeared to perform better than the 2 TB card. The 1 TB Sabrent M.2 drive is TLC, while the 2 TB Micron M.2 drive is QLC. There actually isn't much discussion of DIY CFexpress cards that I could find, but I did see some suggestion that TLC flash would fare better than QLC flash, so perhaps that result wasn't surprising.

Don't get me wrong, I could write unlimited burst RAW to both DIY cards, and 4k30 wasn't a problem either. The difference was only apparent when trying to record 4k60. The 1 TB card seemingly had no problems writing "up to 360 Mbps," per the camera manual, while the 2 TB card would choke. It didn't really make sense though, because, at least in testing using a CFexpress reader, both cards were more than capable.

I'd also seen something on Anglebird's website that I thought was strange. Angelbird notes that the 4 TB card is only compatible with the Nikon Z9 and a RED 8K camera:

I have nothing to corroborate what follows, because I'm not going to spend $1.8k on a CFexpress card (and I haven't reached out to Angelbird), but I'm wondering if it isn't because of power consumption. I'll note that other (more?) plausible explanations include, but are not limited to, firmware limitations (hellooooo FAT) or even just a slight increase in card thickness.

But, before I continue blathering, let's take a look at the smartctl output for the other cards.

For the 1 TB Sabrent card:

=== START OF INFORMATION SECTION ===
Model Number:                       Sabrent SB-2130-1TB
Serial Number:                      --
Firmware Version:                   R21B47.1
PCI Vendor/Subsystem ID:            0x1987
IEEE OUI Identifier:                0x6479a7
Total NVM Capacity:                 1,024,209,543,168 [1.02 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Local Time is:                      Sun Apr 30 14:47:39 2023 MDT
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x1e):         Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Pers_Ev_Lg
Maximum Data Transfer Size:         64 Pages
Warning  Comp. Temp. Threshold:     83 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     5.00W       -        -    0  0  0  0        0       0
 1 +     2.40W       -        -    1  1  1  1        0       0
 2 +     1.92W       -        -    2  2  2  2        0       0
 3 -   0.0700W       -        -    3  3  3  3     5000   10000
 4 -   0.0050W       -        -    4  4  4  4     6000   44000

And for the 2 TB Micron card:

=== START OF INFORMATION SECTION ===
Model Number:                       Micron_2400_EEFDKBK2T0QFM
Serial Number:                      --
Firmware Version:                   23A24013
PCI Vendor/Subsystem ID:            0x1344
IEEE OUI Identifier:                0x00a075
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Local Time is:                      Sun Apr 30 14:53:28 2023 MDT
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x1e):         Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Pers_Ev_Lg
Maximum Data Transfer Size:         32 Pages
Warning  Comp. Temp. Threshold:     87 Celsius
Critical Comp. Temp. Threshold:     90 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     9.00W       -        -    0  0  0  0        0       0
 1 +     4.60W       -        -    1  1  1  1        0       0
 2 +     3.80W       -        -    2  2  2  2        0       0
 3 -   0.0250W       -        -    3  3  3  3     5000    3000
 4 -   0.0040W       -        -    3  3  3  3     8000   35000

Do you see Watt I mean?

And finally, my theory:

I'm wondering if CFexpress cards are as expensive as they are because their firmware is specially tuned to provide consistent/minimum write speeds within a certain power budget. Take a look at the maximum Power State that was reported for each of the three cards:

• 2.5 W for the 256 GB SanDisk card
• 5.0 W for the 1 TB Sabrent card (+100% compared to SanDisk)
• 9.0 W for the 2 TB Micron card (+260% compared to SanDisk)

Interestingly, Angelbird lists the maximum power consumption as 2.4 W for the whole line of MK2 cards, but maybe the website is wrong and the 4 TB card is different? Who knows. It's literally unknowable.

But maybe, just maybe, my camera did not like supplying NINE watts to the Micron card. I actually hadn't paid much attention to NVMe Power States in the past, but it turns out that they are configurable!

Throttle Thyself

In researching NVMe Power States, I found a blog post where one enterprising individual was trying to achieve the opposite goal: they had a drive that was exhibiting reduced performance due to Power State limitations and they were trying to UNLEASH THE DRIVE.

Armed with the Power States returned by smartctl and the knowledge I'd gleaned from the blog post, I used the command below to set a different, lower maximum power state:

$ sudo nvme set-feature /dev/nvme1 -f 2 -v 2 -s

To break it down: nvme is in the nvme-cli package, set-feature sets a specified NVMe feature (i.e., 2 for Power Management, as specified by -f). The value -v is specified to be 2, which corresponds to Power State #2 (3.8 W) as reported by smartctl. I'll also note that -s is needed to ensure the change persists across resets (which was unfortunately omitted from the blog post I found). Finally, one can confirm that the change was successful using the  command below, which should thus indicate Power State #2 is set rather than Power State #0.

$ sudo nvme get-feature /dev/nvme1 -f 2 -H

In testing the card's speed using a CFexpress card reader, the card definitely does exhibit reduced performance (now writing closer to 400 MB/s), but hopefully it also consumes less power and generates less heat. When tested in the camera, Power State #1 (4.6 W, which is closer to the Sabrent card) enabled longer 4k60 recording, though it still ultimately failed. I eventually settled on Power State #2, since all other functionality remained unchanged at a lower maximum power drawn and 4k60 still failed.

Closing Thoughts

Overall, I feel good about the 2 TB Micron card and hopefully having changed the maximum power consumption from 9.0 W to 3.8 W. I say "hopefully", becuase I wonder if the camera might still set its own Power State (in which case real CFexpress cards would still be desirable for their more specialized firmware and Power States). I suppose this could be established through testing, and I will update this post if I do so.

I may also try to change the maximum Power State for the 1 TB Sabrent card (e.g., from 5.0 W to 2.4 W) to see how that impacts performance, given Power State #1 is the same as the stated power draw for the Angelbird cards and slightly below the SanDisk card that I have. Again, I will update this if I end up testing that.

Other Notes

Unfortunately, nvme-cli doesn't know how to work with NVMe drives via USB, which is most CFexpress card readers. I have a Thunderbolt CFexpress card reader that I use on my Apple Silicon Mac (which properly reports the cards as NVMe devices), but nvme-cli does not compile on macOS. Super.

So what did I do? Well, perhaps obviously, you can plop the 2230 M.2 drive in a normal M.2 slot, which is what I did using one of my Linux machines. It was very slow and inconvenient, as I had to move the M.2 drive between the Linux box and the CFexpress card adapter (not to mention the thermal paste mess that ensued).

To the extent I engage in future testing, I've ordered a CFexpress to PCIe adapter to enable me to use nvme-cli with the DIY CFexpress cards, which should alleviate some of that friction. (And, for those keeping track, will mean I'm going from 2230 M.2 => CFexpress adapter => PCIe slot, which just makes sense.)

2023.05.08 Update: The CFexpress to PCIe adapter didn't work... I'll have to see if there's another option.

2023.05.17 Update: I ordered Sabrent's new 2 TB CFexpress card. Output of smartctl is below:

=== START OF INFORMATION SECTION ===
Model Number:                       Sabrent Rocket CFX Pro
Serial Number:                      --
Firmware Version:                   XXIB47.1
PCI Vendor/Subsystem ID:            0x1987
IEEE OUI Identifier:                0x6479a7
Total NVM Capacity:                 2,048,408,248,320 [2.04 TB]
Unallocated NVM Capacity:           0
Controller ID:                      1
NVMe Version:                       1.4
Number of Namespaces:               1
Local Time is:                      Wed May 17 13:49:04 2023 MDT
Firmware Updates (0x14):            2 Slots, no Reset required
Optional Admin Commands (0x0017):   Security Format Frmw_DL Self_Test
Optional NVM Commands (0x005f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat Timestmp
Log Page Attributes (0x1e):         Cmd_Eff_Lg Ext_Get_Lg Telmtry_Lg Pers_Ev_Lg
Maximum Data Transfer Size:         8192 Pages
Warning  Comp. Temp. Threshold:     83 Celsius
Critical Comp. Temp. Threshold:     85 Celsius

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     5.00W       -        -    0  0  0  0        0       0
 1 +     2.40W       -        -    1  1  1  1        0       0
 2 +     1.92W       -        -    2  2  2  2        0       0
 3 -   0.0300W       -        -    3  3  3  3     5000   10000
 4 -   0.0050W       -        -    4  4  4  4     6000   44000

I'll note this is largely similar to the 1 TB 2230 NVMe drive, including a max power consumption of 5 W. I may try to set a max Power State of 2.4 W if I can find a good CFexpress/PCIe solution and see what happens. Also, makes me want to get a card that is actually advertised at 2.4 W, but is reduced power consumption worth spending 2x more?? ...probably. I think first I will need to confirm whether these cards actually exhibit increased power consumption.

Interestingly, "Maximum Data Transfer Size" for the CFexpress card is 8,192 pages, which is consistent with the SanDisk card and substantially more than either M.2 NVMe drive (32 or 64 pages).

My other thought is my DIY 1 TB Sabrent CFexpress card is probably actually pretty close to the actual 1 TB Sabrent CFexpress card, for probably nearly $250 less. Heckin' deal.

In short, it's been an incredibly busy year, work-wise. While I have had time for numerous projects and hobbies (yay, photography!), most haven't really warranted a blog post. There hasn't been much (any) progress on the Xsata project, though that remains a priority, time and space permitting.

I did design two circuit boards this year: one for a totally custom keyboard that I'm working on and the other for a weather station. Both projects are coming along nicely, though I still need to design a case for the keyboard. The goal is to have the keyboard case CNC'd out of aluminum; it should look pretty svelte if it ever comes to fruition.

I've built several weather stations over the years, but they've always been handwired and the PCBs definitely make it much easier to assemble more of them. I've toyed with selling them on Etsy, but that's contrary to my goal of never providing support for anything done as a hobby.

I suppose there are also still a couple blog posts in the works, namely about my VPN/network setup. I think about starting those from time to time, but, again, I've been pretty spent at the ends of most days lately.

I would also like to continue developing my DNS-based shortcut service that I run on my local network, which is apparently akin to Google's "golinks." [1] [2] [3] That will also hopefully be the subject of a post someday, though I think at this point I coded a minimum viable product of it about a year ago and it's seen little development ever since.

And lastly, I still need to finish the blog post that was the reason for starting this blog in the first place. A little ridiculous to think that the primary reason for screaming into the void still hasn't seen the light of day, but here we are. That's been getting less thought in my day-to-day life, but the problem it aims to address is as relevant as ever.

On a personal note, I am pleased to report that I did a good job of getting out and seeing the world this year (thanks, COVID). But really, that is only another excuse to drop one last picture in before wrapping up.

All that to say: "I'm still here! And I'm not going anywhere." Perhaps I shouldn't be surprised that my initial hopes for this blog were overly ambitious (as so often is the case), but I do hope to have more time in the new year (and to make progress on the Xsata project once I have more space to actually work on it, c'mon housing market 🤞🏼).

With the increasing prevalence of QR code-based menus, there have been a growing number of articles discussing privacy concerns. Personally, I've noticed that some of the QR codes I encounter first direct me to a third-party website before redirecting me to the website of the restaurant in question. While this apparently might be done to enable "dynamic" QR codes (where the target of the QR code can be changed after the fact), this bothers me because it introduces a more centralized third party that has the potential to track patrons across multiple restaurants.

Granted, addressing this issue does nothing to tackle tracking by third-party restaurant platforms (as might be used for online or mobile ordering). However, I would argue that maintaining decentralized access to restaurant websites still improves privacy, especially in instances where such platforms are not used and the websites are instead standalone or, even better, in PDF form. To date, I have only encountered one restaurant that uses a third-party platform for dining in, though I have continued to be a bit of a hermit with the ongoing pandemic so my experience is not likely to be representative.

Anyways, enough with the "what," on to the "how"

This project started by looking specifically at qrco.de, as most of the third-party QR codes I've encountered are for that domain (and who could forget such a memorable domain name). One of the goals going into this project was to have minimal impact on the usual QR code workflow. I really like that the scanner is integrated into the camera on iOS.

My initial thought was to do some DNS-based request hijacking to intercept requests for qrco.de (and others, as I happen across them) and process them at a server internal to my home network. Turns out qrco.de provides a 302 Found response to redirect requests, which could be processed server-side in a way that doesn't store any cookies (hello, curl -I). The target URL could then be provided in response to the intercepted request.

I initially liked this option, because it would enable more complex processing as needed, for example if a site has a landing page prior to redirection. It also sounded like a lot of interesting problems to solve. For example, qrco.de appears to typically use HTTPS, so I would need to generate a TLS certificate using my personal certificate authority. I would also likely do the interception on the same (virtual) machine that serves my Pi-hole, so I was thinking I would need another IPv4 address to receive the intercepted requests. Downsides of this plan? I would need to always be on my VPN and I think it would likely be less robust.

And so, my focus instead turned client side. How cool would a QR scanner iOS app be?! But seriously, there is a certain amount of sense to having a privacy-minded QR code scanner app. I haven't done any iOS / macOS app development for the better part of a decade (and a whole application does seem a little ham-handed), so that option wasn't a serious one. However, what was a serious option was Shortcuts.

But seriously, the "how"

I think I first looked at Shortcuts becuase I was thinking I could call a script via SSH (to run the curl command) and then open the result in a browser. A little clunky, but it would have worked. Thankfully, it turns out Shortcuts offers an "Expand URL" function, which "expands and cleans up URLs [that] have been shortened using a URL shortening service." Perfect.

I was curious to see how the "Expand URL" function worked, namely whether it maintainied cookies across invocations. It wouldn't do me much good if I were resolving redirects and passing them to Safari, all the while unknowingly collecting cookies.

So I did what any self-actualized human bean would do and set up a dummy webserver. With some help from my frriend php -S [bind addr]:80, I wrote a simple PHP script to dump cookies and view requests from my phone.

<?php
// Launch PHP server with 'sudo php -S [bind addr]:80'

// Simple console debugging
error_log("\n");
error_log(implode($_SERVER,", "));
error_log(implode($_COOKIE,", "));

// Borrowed function: "based on original work from the PHP Laravel framework"
if (!function_exists('str_contains')) {
    function str_contains($haystack, $needle) {
        return $needle !== '' && mb_strpos($haystack, $needle) !== false;
    }
}

// Name to easily change the cookie we're setting
$cookieName = "trackingCookie";

// If we are accessing the tracking URL (i.e., '?trackingURL'), set a cookie and redirect
if(str_contains("$_SERVER[HTTP_HOST]$_SERVER[REQUEST_URI]", "trackingURL")) {
	setcookie($cookieName, time(), time() + 3600, '/');
	header("Location: http://$_SERVER[HTTP_HOST]/?destination");
// If we are accessing a normal URL (e.g., '?destination'), check for tracking cookie
} else if(isset($_COOKIE[$cookieName])) {
	echo "Cookie '" . $cookieName  . "' has been set!<br>";    
	echo "Value in cookie is: " . $_COOKIE[$cookieName];
} else {
	echo "No cookie.";
}

?>

Super simple. The important bits are where a cookie is set if the URL is accessed with ?trackingURL and then a redirect occurs (i.e., to ?destination), at which point the destination page prints whether a cookie was actually set. Ideally, the "Expand URL" function would eat the cookie, such that Safari arrives unfed at the ?destination URL.

Onwards, to the results!

When the ?trackingURL URL is called via the Shortcut, a User Agent of BackgroundShortcutRunner/1137.4 CFNetwork/1312 Darwin/21.0.0 is used to access the page. The cookie is then set, the redirect to ?destination is followed, and the ?destination URL is ultimately returned by the function. Not really relevant, but I assume that the function follows the ?destination URL to see if there is yet another redirect, which is good to see. Also, it makes sense to collect cookies along the way in case they are needed at the destination URL.

The important part: when the ?destination URL is accessed in Safari (with a User Agent of Mozilla/5.0 (iPhone; CPU iPhone OS 15_0_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.0 Mobile/15E148 Safari/604.1), it is apparent that no cookie is set yet. So, yes! The "Expand URL" function will work to protect from tracking cookies coming from QR code redirects. Super fucking yay.

But wait: another Shortcuts function?

I should mention that there was another candidate function that I encountered when I was evalauting options. Hellooooooo "Show Web Page." Just imagine: you scan a QR code, get redirected to whatever website in a WebKit view, and then, once you're done, you can close the view and all the cookies are gone with it. Bango bongo, right?

Sadly, not. Interestingly, it turns out that the "Show Web Page" function and Safari share cookies. That means that, unlike "Expand URL," "Show Web Page" can't be used to follow redirects and happily discard cookies at the end of the journey. What a world it almost was, though.

Imple-menu-tation

Enough lollydicking, finally it's actually time the "how." The implementation I arrived at is a Shortcut that either parses a URL (obtained via the Share Sheet) or pops up a QR code capture screen, "Expand[s that] URL," and passes the resulting URL to Safari. This workflow is further simplified by tying the Shortcut to Back Tap, so I can easily scan the QR code through the Shortcut rather than the Camera app.

Conclusion

Is it perfect? No. But it is serviceable, at least to a point. It does not address whatever tracking cookies might be waiting at the destination, which seems like a logical step for implementing tracking across a number of dining establishments. For that, I will rely on pihole-based DNS filtering and whatever tracking protections are offered by Safari, at least for now.

Which brings me back to my initial comment about a privacy-minded QR scanner. It feels like scanning QR codes involves a certain reduction in control. In closing, it would be really nice if QR code interactions could basically be sandboxed, which would likely make the most sense as an OS-level feature. Even the ability to open a private tab in Safari via Shortcuts would be helpful. Alas, a pipe can dream. Until that day, I guess "Expand URL" it is.

It has been about two months since my first post regarding the Xserve RAID ("XR"). Since then, I have explored the caddy design in greater detail, including the PCB discussed in the earlier post, the geometry of the caddy itself, and potential options for a SATA backplane. While the latter two topics will be discussed in forthcoming posts, this post will again focus on the PCB included in every non-blank caddy. Oh, and I've decided to call the (hopefully inevitable) fruit of this project the "Xsata." Cool.

I think one of the goals of this project will be to mangle as little of the original XR as possible. That said, the chassis will likely be on the receiving end of some more destructive modifications (thanks, rivets). For... some reason, I guess? Though I am pretty sure that most (if not all) of the soon-to-be-redundant parts will likely be never used again.

In that vein, I started by ordering a new "cable assembly" that fits the 6-pin header on the PCB (above). That way, the original connector (and associated SCSI PCB) can remain intact. It is probably also worth noting that the housing and leads could have each been ordered separately and then assembled, which would likely have been more cost effective at the expense of my time and patience.

Anyways. Once I had the cable assemblies in-hand, evaluating the PCB was much easier. I started by soldering the leads from the caddy PCB to the pads of a test backplane PCB, as I laid out in my earlier blog post:

So, my plan will be to find a backplane PCB with activity and power leads / LEDs, so I can wire pins 1, 3, and 6 for power (i.e., yielding a green color on the status LED of the caddy) and pin 4 (and pin 6) for disk activity.
~me, 2021.05.10

Boy, I made it sound so easy. The status/power LED lit up with seemingly no problems. Unfortunately, so did the activity LED, which is to say that both LEDs stayed lit. Not only that, the caddy PCB also became very hot to the touch shortly thereafter. Just super.

Turns out the caddy PCB isn't used to 5V. After some testing and additional research (SCSI operated at 15V and 3.3V, instead of SATA's 12V and 5V), it seems that 3.3V likely makes more sense. I have since updated the earlier blog post to include this discovery.

Now is probably as good a time as any to mention my total lack of experience with circuits. I was supposed to take a class on circuits in college and, yet, I didn't. So this project was coming along exactly as expected.

I initially considered a voltage divider as a potential solution to drop 5V to 3.3V, but settled on a linear voltage regulator for fear that the input voltage and output current draw may not be reliable/constant.

Failings of yours truly aside, the activity LED was still a problem. I had expected the SATA PCB to signal using the positive pad rather than the negative pad. This wouldn't be a problem if the LEDs of the caddy PCB didn't share a common ground lead. But they do!

I thought this was an oddity of the SATA PCB that I was using, but, in actuality, it appears this is part of the SATA power connector. Enter: pin 11. Per Wikipedia, pins 1-3 are 3.3v (if you're into shucking HDDs, you may be familiar with pin 3), pins 5-6, 10, and 12 are ground, pins 7-9 are +5V, and pins 13-15 are +12V. Pin 11, however, is described as follows:

Pin 11 can function for staggered spinup, activity indication, both, or nothing. It is an open-collector signal, which may be pulled down by the connector or the drive. If pulled down at the connector (as it is on most cable-style SATA power connectors), the drive spins up as soon as power is applied. If left floating, the drive waits until it is spoken to. This prevents many drives from spinning up simultaneously, which might draw too much power. The pin is also pulled low by the drive to indicate drive activity. This may be used to give feedback to the user through an LED.
~Wikipedia, Serial ATA § Standard Connector (emphasis mine)

Based on my incredibly limited understanding, I took this to mean that pin 11 may be left floating, until it is pulled low by the drive to indicate activity. Super helpful; that explained the unexpected-to-me behavior of the "Activity –" pad on the SATA PCB.

Armed with knowledge and a renewed sense of give-a-fuck-edness, I broke out my super shitty breadboard, 5V power source (USB: putting the "U" in "USB" since 1996), 3.3V linear voltage regulator, resistors, transistors, and, eventually, MOSFETs. Behold the resulting circuit:

It's been a multi-week process at this point, so I am a little foggy on the details (read: past failures), but the ultimate design uses a PNP transistor (Q1) in combination with an n-channel MOSFET (Q2) to control the Activity LED (and, more specifically, to conditionally provide +3.3V from the voltage regulator (U1) to pin 4 of the caddy PCB).

It will be more soldering than I had wanted to do (especially when I have to do it for each caddy–14 times over), but let's walk through each of the components and why they're there.

To start, the left connector is intended to connect to the SATA PCB, where pad 1 = power +, pad 2 = power –, pad 3 = activity +, and pad 4 = activity –. The caddy PCB is on the right, where pins 1 and 3 provide +3.3V to the power LED, pin 4 provides +3.3V to the activity LED, and pin 6 is ground.

Moving to the middle of the schematic, the top portion (enlarged above) is easiest to explain. U1 is a 3.3V linear voltage regulator, where pin 1 is VIN (i.e., +5V from pin 1 of the SATA PCB connector), pin 2 in GND (i.e., ground from pin 2 of the SATA PCB connector), pin 3 is the enable pin (which, per the spec sheet, is pulled high to enable the regulator), pin 4 is unused, and pin 5 is VOUT (i.e., +3.3V to one or both caddy PCB LEDs).

C1 (1µF) and C2 (4.7µF) are capacitors that smooth the input to and output from the voltage regulator, respectively. I can't take credit for the inclusion and values of C1 and C2; the spec sheet recommended their inclusion for improved stability.

Let's turn now to the bottom portion of the schematic (reproduced above). At its core, Q1 controls the gate of the MOSFET (i.e., pin 1 of Q2), thereby causing electricity to flow from the linear regulator to the activity LED (i.e., from the drain, pin 3, of Q1 to the source, pin 2) when current flows from pin 2 to pin 1 of the PNP transistor (Q1). Put another way, when current flows from pin 2 to pin 1 of Q1 (as a result of a drive pulling pin 4 of the illustrated connector low), Q1 is "on," such that the voltage at the gate of Q2 is +5V. As a result, Q2 is "on" too, thereby causing the activity LED to be illuminated.

With respect to the resistors, R1 limits the current passing through Q1 (as well as R3). R3 is a pull-up resistor, which causes the emitter (pin 2) and the base (pin 1) of Q1 to have a similar voltage so Q1 is not "on" when pin 4 of the SATA PCB connector (i.e., pin 11 of the SATA power connector, as discussed above) is floating.

It is not visible in the excerpt above, but R2 is a pull-down resistor (connecting the gate, a.k.a. pin 1, of Q2 to power –, or ground). This ensures that, unless Q1 is "on," Q2 does not receive a sufficient positive voltage to itself be "on." The values of R1, R2, and R3 were determined experimentally using my breadboard and are deliberately high values in an effort to reduce wasted current. These values may change in the final design, but at least resistors are cheap.

I have also designed and ordered a batch of PCBs based on the above schematic, but that is the topic for a future post; this one is long enough. Hopefully I will have the PCBs in hand soon (and determine that the design works), at which point I will add another post to the growing Xsata saga (hmm, perhaps this is the Xsaga?). Fingers crossed.

Last year, I replaced all eight drives in my NAS with larger drives. However, I saved the old drives with the thinking that I could eventually upgrade from an 8-bay NAS to something with more bays. A 24-bay Supermicro device was the original plan, but I recently remembered that the 14-bay Xserve RAID is gorgeous. Unfortunately, the Xserve RAID was discontinued in 2008 and, barring the Xeon Xserve (non-RAID) models, never supported modern SATA drives.

This is the first in what will likely be a series of posts regarding my attempt to convert an Xserve RAID (hereinafter "XR") to a modern storage device. To date, I have ordered an XR midplane (pictured above, basically a backplane to which drive caddies connect) and two empty (but not "blank") drive caddies. I have also explored a handful of SATA backplanes, though the backplanes I have found so far do not have the correct drive spacing (≈30mm from the start of one SCSI-esque(?) connector to the start of another). No matter, I have a couple other ideas for how to handle upgrading the XR from Ultra ATA to SATA.

Which brings me to the topic of this post: the indicator lights in the drive caddies. Even though I would ultimately like all of the LEDs on the front of the XR to work, it makes sense to start with the drive caddies and, more specifically, the tiny PCB used by each drive caddy. Interestingly, there was a related project four years ago that seemingly never came to fruition.

The top LED is the status indicator and can be green or red, while the bottom LED is the drive activity indicator is a pleasant shade of blue. Flipping the board over (below), the notable features are the 6-pin connector (right) and the reflectivity (?) sensor (left, with the two thick horizontal pins). The sensor is interesting, because, using white or black regions on the inside of the caddy, it detects whether the caddy is open / unlocked (e.g., for drive removal) or closed / locked.

A thin, tiny cable plugs into the 6-pin connector and runs under the drive area to a PCB in the back of the caddy, where the traces ultimately lead to the connector for the caddy (which is what plugs into the midplane). The connector is interesting, because the ultimate goal is to connect the baby PCB to SATA power and activity leads so the lights on the front of the caddy behave as expected.

Using the above cable, I was able to easily supply +5V/GND to various pins of the PCB. The "V" and associated red coloring on the cable that connects to the PCB (not pictured 🤷🏻‍♂️) was a good indicator of where the positive pin is, but the rest required some guesswork. One fried sensor later, below is the pinout:

A quick edit regarding the voltage: after some additional testing at 5V, parts of the board became extremely hot (but it didn't let the smoke out). Upon further review of the SCSI connector, it appears SCSI operated at 15V and 3.3V, rather than the 12V and 5V typically used by SATA. So I think 3.3V is a safe bet.

I am guessing on the pin marked "SENS," but it isn't a pin that I need anyway. I am also unsure whether I'm conforming to normal pinout conventions, so I will write out the various states, too.

In order to produce a red color on the status indicator, +3.3V is applied to pins 1 and 2, with GND on pin 6. However, I don't anticipate using that state (as much as I would like to, I just don't see how it would be easily implemented). In order to produce a green color on the status indicator, +3.3V is applied to pins 1 and 3, with GND on pin 6. Finally, the activity LED can be illuminated by supplying +3.3V to pin 4 and, unsurprisingly, GND to pin 6. I may play around with supplying lower voltage on pins 1, 2, or 3; I haven't decided yet.

So, my plan will be to find a backplane PCB with activity and power leads / LEDs, so I can wire pins 1, 3, and 6 for power (i.e., yielding a green color on the status LED of the caddy) and pin 4 (and pin 6) for disk activity.

Edit 2021.06.14: After further experimentation, this post has been updated to reflect a voltage of 3.3V, not 5V.

Over the past year, I've become weirdly infatuated with fans. The beginning might actually date back further than that (I rigged some fans to run off a 12V wall wart several years back to keep my media center cool), but things really took off when I became the proud owner of a fanless Core i5 Microsoft Surface that really should've had a fan (and it turns out that even the fan-full Core i7 model needs a fan). Short story long, I've bought probably 15-20 fans over the last year. Quick shout out to Noctua's eBay shop, where they ship straight from Austria (helpful for when Amazon and Newegg are out of stock). #covidhobbies #onlyfans

Most recently, a fan on my AMD Radeon VII started sounding sickly: at speeds above ≈70%, there was a high-pitched whine. Unfortunately, the GPU is no longer in production and I was unable to find OEM replacement parts. "But a fan is a fan," you're thinking. Short of buying some off-brand replacement fans off AliExpress or buying a GPU "for parts" off eBay (unappealing since even seemingly dead GPUs seem to be selling for $450+), it seemed I was out of luck.

Just kidding, I have a 3D printer. Watch out, world.

The no-name fans off AliExpress probably would have been fine (though they certainly lack the stellar name recognition of the original "First D" brand fans). However, the GPU has always been a little loud, so it seemed this was an opportunity for improvement on many fronts. That said, after finding that AliExpress link, fair warning that what follows is not remotely cost-effective ($14 + free 3-6 week shipping versus $60+ on three fancy-ass chromax.black.swap Noctua fans). But, as momma always heard me say: "anything worth doing is worth overdoing."

To start, I had to find some potential replacement fans. The original fans are approximately 75mm x 15mm fans. Noctua makes a 92mm fan that is 14mm thick, but unfortunately the regions in the GPU shroud are too small to accommodate such a large diameter. The next best option turned out to be their 80mm fan, which is 25mm thick.

I had also done some research to see what I was up against. First, this excellent video from GamersNexus was helpful in disassembling the Radeon VII. Second, I scrubbed through this disassembly video of a Noctua fan. The Noctua video made the disassembly it look harder than it actually is, and I don't know whether a heat gun would actually make things easier.

In short: there is a bushing that keeps the shaft of the fan in place, and the bushing is retained by friction. Knowing this, I was able to disassemble the fan by firmly pushing the blades out of the case from the back. This is different than other fans I have encountered, where there is a lock ring(?) behind the center label of the fan that can be removed to free the shaft from the bushing. No need to remove the stickers here! (Quick note: I doubt this technique applies to all their fans, since the 120mm fans seem to use a different construction.)

The next stage of the project was to model a replacement base to hold the PCB in place with respect to the fan rotor. I expected the modeling process to be somewhat tedious and have a low margin for error, given the relatively tight fit between the electromagnets on the PCB and the corresponding magnet in the fan rotor. Thankfully, duplicating Noctua's design was actually surprisingly simple and relatively forgiving.

I ended up printing five or six iterations of the design, and every single version was functional. Definitely not the norm. It may eventually be worth writing a post about my approach to 3D modeling, but generally I start with a relatively simple / naïve model and iterate from there. It helps make sure I get the dimensions right along the way, and I can also iron out any kinks introduced by FDM printing.

For example, I had expected the top of the model to be difficult to print given its relatively thin walls and quick print time (some things get melty when that's the case), but it again turned out to be a non-issue. How often and how quickly I can iterate depends on how long the print time is, but thankfully this part only takes 25-30 minutes to print.

There is one trick worth mentioning here, which I think I picked up from Maker's Muse on YouTube. The original fan has a magnet embedded at the bottom of the rotor shaft. The fan works fine without the magnet, but I assume the magnet is to keep the rotor in place rather than having it inadvertently ride up during operation.

Being anally receptive retentive, I decided to duplicate this feature anyway, using a 6mm x 1.5mm cylindrical cavity to retain a neodymium magnet. The magnet cavity then gives way to a differently shaped, but narrower, cavity in which the shaft of the rotor can move freely.

If you are unfamiliar with 3D printing (and more specifically FDM 3D printing), moving from a big hole to a small hole is problematic, because the walls for the smaller hole will be printed when the nozzle is over thin air. The trick here is to leave a single solid layer between the boundary for the magnet cavity and the shaft cavity, so there is a thin layer of plastic upon which to build the walls for the shaft cavity.

The sacrificial layer is easy to clean up once the print is done, for example by puncturing it with a screwdriver. I also considered entirely closing off the two cavities from one another, but it turned out to be helpful during assembly and testing for reasons discussed below.

Anyways, it was upon attempting to assemble the fan using the 3D-printed part that I decided this project was worthy of a blog post. To this point, I hadn't attempted to disassemble the rotor assembly, partly because I hate grease (truly, can't stand it), but also because I was worried it would affect the fan's operation.

{I just returned to finish this post after three months away from it, so I don't fully remember the epiphany that I was building up to here}

In short, the rotor assembly is comprised of four-ish pieces: the blades / hub / shaft (effectively all once piece), a ring that sits between the bushing and the hub, the bushing, and a retention washer. Alas, I wish I had a picture of the assembly on its own. In the picture above, you can at least see (from top to bottom): the shaft, the retention washer (with grease!), and a small portion of the copper bushing.

In my initial reassembly attempts, I put the PCB (above) onto the 3D-printed part and  pushed the whole rotor assembly into the shaft cavity. In doing so, my concern was that the ring between the bushing and the hub (which I assume is to limit grease egress from the shaft cavity) was not positioned correctly. And, based on how the fan rotated in subsequent testing, it seemed I was right: the ring was not seated properly and was in contact with the hub.

It seems that the only way to properly assemble the fan is to break down the rotor assembly and put its constituent parts into the 3D-printed part one by one. Trying this technique, the retention washer sat nicely at the bottom of the shaft cavity (which I was able to position using tweezers, thanks to the hole between the magnet cavity and the shaft cavity), followed by the bearing. I was then able to press the ring onto the top of the cylinder. It was a perfect, snug fit. I slid the shaft into the bushing and through the retention ring, at which point the rotor assembly was properly reassembled within the 3D-printed part.

Weird Noctua erotic fan fanfic aside, the result worked perfectly. And so, my epiphany: in modeling a different base for the fan, I'd gained a better understanding for not only the parts that form the fan, but also how the fan is assembled and some of the associated engineering decisions.

I made two more fans, soldered them all together, and used a GPU fan connector to reassemble the graphics card. The result (#restofthefuckingowl)? Well, having used the fan for nearly three months now (thanks, procrastination!), I can say the project was a resounding success.

I will say that the BIOS of the Radeon VII has no idea what to do with the RPM reported by the new fans, so running the fans at 100% registers as only 60%. Overall, I can't say for a fact that cooling performance has increased, but, even at 100% 60%, the Radeon VII stays quite cool and it is so, so much quieter than the stock fans.

Long story short, after trying to upgrade to macOS Big Suck Sur 11.1 (but I'm not still bitter, honest), I was left with a computer that no longer booted past the loading screen—though Safe Mode worked for some reason. I thought perhaps downgrading to 11.0.1 might restore things to working order, but after inadvertently separating my Data volume from its System sibling, I decided maybe it was time for some long overdue spring cleaning anyway. Well, that paired with noticing files from February of 2012 that were still lingering after many migrations over the better part of a decade.

After reinstalling applications and copying over associated preference plists, there were some applications whose menu bar icons were missing. There is some discussion online of what appeared to be the same issue, but none of the suggested remedies had any effect.

Back before Apple offered a public API for menu items, developers used the private NSMenuExtra API. SystemUIServer was (and apparently still is, in some cases) responsible for displaying the menu items in the menu bar, so I thought perhaps ~/Library/Preferences/com.apple.systemuiserver.plist was a good place to start. Unfortunately, the only menu item mentioned there was for Time Machine. Surprising that the other Apple-approved menu items are no longer technically "menu extras." But I digress.

I decided it might be helpful to identify which preference plists were updated when I changed the visibility setting for a missing menu item. Fortunately, HammerSpoon has preference window that is both accessible by means other than the menu item and offers the ability to toggle menu item visibility in preferences.

Sorting by "Date Modified," it turns out that the visibility and "preferred position" of an application's menu item is stored in the application's preference plist. Shocker:

<plist version="1.0">
<dict>
	<key>NSStatusItem Preferred Position Item-0</key>
	<real>1018</real>
	<key>NSStatusItem Visible Item-0</key>
	<true/>
</dict>
</plist>

I tried changing the NSStatusItem Visible key to <true/> and relaunching the application, but it appears that the property is cached such that it is reset when the application launches.

While I didn't delve into which process manages the NSStatusItem menu items (I can, however, confirm that it definitely isn't SystemUIServer), the solution that I found was to edit the plist and leave the application as-is (either running or closed). After rebooting, the missing menu items were back!

Quick aside: If you are not familiar with editing plists, they tend to be stored in a binary format. They can be converted to XML using the plutil command in Terminal so they can be edited with a regular text editor.

% plutil -convert xml1 /Users/me/Library/Preferences/com.protonmail.bridge.plist

For example, the above command will convert the binary plist file com.protonmail.bridge.plist into a normal XML file. No need to convert it back to a binary plist, as that will happen when the file is updated by the system (though using binary1 in place of xml1 will perform the opposite conversion).

In the past, my main hesitation was that I would spend an inordinate amount of time revising content for a blog and nothing would ever get posted. Even now, the preceding sentence underwent countless iterations until it was well-worded. And it still has passive voice. My day job is writing, and blogging is far less appealing if the objective is proper English. Also relevant: my writing in that context typically avoids the first person, so I am adjusting to that as well.

My next hesitation? Who even cares! I am fighting the urge to delete everything I've written and pick this post up some other day. ⌘𝖠, ⌫, I say. But, over the years I have encountered countless other blogs (as an aside: a list of inspirational blogs will likely be forthcoming). I have looked on with admiration as people seemingly unencumbered by these thoughts publish posts, projects, and other miscellany.

And I am thankful for it. Typically when Stack Overflow and Wikipedia are unavailing, I happen across the website of some kind Internet stranger that took the time to write about something. Or sometimes, the Internet has no answers.

So, here's the deal. I am framing this blog as an internal monologue; not polished for public consumption. I am sure I will still get caught up in the details (for example, I just went through and cleaned up most contractions; so informal), but that should take some pressure off.

I intend to write about various side projects that occupy my free time (thanks, COVID!). I am passionate about most facets of computer technology, from computer networking to cybersecurity, programming to virtualization, and 3D printing to cryptomining. Most recently, it turns out that I also enjoy clocks and I have a couple clock-related posts in mind, so watch out for those. Frankly, someday I would like to also play the role of kind Internet stranger in someone else's search for answers, as I have encountered a handful of issues that, at least at that time, were not discussed anywhere that I could find.

And my final hesitation? I am incredibly self-conscious. None of this works if I worry that anyone I know will be reading. Which, playing to the preceding hesitation, is probably a moot point anyway. In any event, I intend to remain a kind Internet stranger, occupying only this domain and no other.

Indeed, as the title says: "here we are;" "we" in the royal sense of the word. And after a long, 19-hour day, we are going to sleep.

~me