Nick Gerace Hacks

Personal Rig Update

Mon, 19 Jan 2026 00:00:00 GMT

I've made some updates to my personal rig over the last couple years that were focused on simplifying the build as well as making it easier to work on and transport. The net result is a resounding success!

This is it: the updated build in the Fractal Design Meshify 3 (non-RGB). The build retains the Nvidia RTX 4090 GPU (acquired April 2023) and AMD Ryzen 7 7700X CPU (acquired November 2022) featured in my last update. It's been in service since June 2025, but enough time has passed to talk about my experience with it.

There was little wrong with the existing build. It performed extremely well and the Lian Li O11D EVO XL case was well built, sturdy and easy to work in. However, the sheer weight and size for transporation, upgrades and maintenance was overkill for what I needed. I not only wanted to downsize for ease of use, but I also wanted to fit my desktop computer back onto my desk and off of the floor.

I started experimenting with smaller cases and reducing the total number of fans. The goal was to downsize while achieving a similar noise profile with similar temps.

Lian Li and Dan Cases collaborated on an excellent mATX case that caught my eye: the A3-mATX. I picked up the wood panel version in early 2025 due to the front panel featuring openings in between the wood pieces. In contast, the base version features a solid front panel. This allowed me to face the PSU fan outwards to separate its airflow from the interior.

The problem with this build was how noisy it was. That was true for both the builds using the 360mm AIO I brought over and the Noctua U12A air cooler that I eventually switched to. I was getting used to having my desktop on my desk again with fans spinning near my ears and the all-mesh enclosure didn't help. Fan Control was an excellent utility to help dial everything in for both noise reducation and performance, but I decided that this form factor might not have been for me at that time. I had always been interested in both SFF and mATX form factors, but had never taken the jump because the uncompromising nature of custom desktop computers had always been a key selling point to me.

That being said, I'm very happy I tried the A3-mATX. I'd happily revisit this form factor with a bottom-up approach to cooling (i.e. buying all the parts with a build in mind) or with lower power parts. There are exciting cases in both the SFF and mATX spaces, like the Ncase M3 and Fractal Design Terra, that could make for great builds.

Fortunately, soon after this experiment, Fractal Design released the Meshify 3 series of cases. I had been eyeing the "wind tunnel" sector of PC cases for the past couple of years in particular. Dual chamber cases like the Lian Li 011D series and Phanteks NV series are awesome, but the front-to-back airflow cases lend themselves well to simple builds featuring a small number of fans with air-cooled components.

There were a lot of great cases featured at trade shows, including Computex and CES. Some standouts were the HAVN BF 360, the Antec Flux Pro, the Lian Li Lancool 217 and the Fractal Design North (and North XL). However, the release of the Fractal Design Meshify 3 caught my eye in particular. I used their Meshify C case in a 2019 build and loved it, so checking out the next iteration in the tried-and-true, plain black box, "wind tunnel" series was a natural step to take.

The build plan turned out to be much simpler than my last build plan. In fact, I used no additional fans than what came with the case and CPU cooler.

The air guide was a welcome addition to the newest iteration of the Meshify case. It gives the bottom 140mm fan a reason to exist rather than just shooting air into a squared off PSU shroud.

As far as the fan configuration goes, from both my own (questionable) testing and extensive research online, adding a rear exhaust fans and/or two top fans would have had an insignificant performance impact. I didn't replace the stock fans like I normally would either. I decided to try them and just... haven't swapped them out because they work well. Sure, if one of them ends up having an issue with a ball-bearing or begins to not work well, I'll probably swap it out with a Noctua, Phanteks or Arctic fan. For now though, I've been impressed with Fractal Design's Momentum 14 fans.

Overall, if you mix "low-hassle", "low-number-of-fans", "low-complexity" and "highly-performant" into a blender, you'll get my most of... that... build ever! I'm very happy with it! The case is a particular standout. That's unsurprising given that it won GamersNexus' "Best Overall Case" for 2025, but it's still worth mentioning.

The build has been in use since around June 2025 and I do not have any plans to change it in the near future. So, what about the "not-near" future? Ironically, I've been eyeing up custom loop builds... the exact opposite of most things I put into that blender. Even more ironically, those are the kinds of builds that work well with the O11D EVO XL given its mechanical design and space for big radiators!

With the great performance and reliability of both of air coolers and AIO liquid coolers these days, why build a custom loop build? I've been asking myself that for years, which is why I haven't done it, but I've come to the conclusion custom loop builds are mainly for the artwork, craftsmanship and hands-on fun. The last bit is particularly interesting.

I was listening to Fallthrough episode 53 and the hosts, Matthew and Kris, discussed physical projects they had going on in their lives as well as the cross-functional nature of some of the projects (i.e. things you can tie back to software). I work on software all day, so not only is a physical project a breath of fresh air, but it can also give more exposure to other subjects, sciences, hobbies and communities. I may not end up ever building a custom loop, but its on the radar, perhaps with a component upgrade.

Speaking of "component upgrade", I doubt I'll upgrade my CPU without upgrading my GPU. Sure, I may see a benefit by switching to the Ryzen 7 9800X3D (or its rumored refresh SKU), but I'd rather atomically upgrade both parts and experience a bigger uplift. I haven't upgraded to Nvidia Blackwell (RTX 50 series), AMD Radeon RDNA 4 (RX 9000 series) or Intel Arc Battlemage (BXXX series) for the same reason. Rubin (RTX 60 series) is rumored to be a long way out and there likely won't be a GPU refresh from Nvidia before then. The ongoing RAM shortage certainly isn't helping. That being said, there's a lot of time between now and "2027H2", so we'll see.

What I do know is that this current build is bliss! It's been a blast settling back into a simple, front-to-back "wind tunnel" ATX build.

System Initiative Becomes Generally Available

Wed, 25 Sep 2024 00:00:00 GMT

Today, after more than five years of dedication, the future of DevOps automation is here. System Initiative is now generally available for everyone to use.

Three Years to Three Clicks

About three years ago, Adam took me through a live demo of the System Initiative ("SI"). I wrote about how transformative that experience was when we launched the company publicly, but here's the short version: I dropped everything in the weeks following that demo in order to join as the second engineer and fifth employee of the company.

The following three years have been some of the most rewarding in my career. Our world class team, and steadily growing and passionate community, have been vital to not only reaching this milestone, but also to my own career. I cannot thank them enough.

You may or may not have heard of us over the last year or so, but in any case, let's talk about what's different now.

Last year, we launched the company publicly, open sourced the System Initiative software and steadily built an excellent community of people looking for the future of DevOps in our Discord server. However, all of these steps were taken towards reaching our most ambitious destination yet.

It's incredible to finally say that you, the reader, can now use System Initiative in its generally available, fully-featured form.

Replacing Infrastructure as Code

We've talked about System Initiative many times before, but this time is different: we're now talking about System Initiative in the form that you deserve; over five years in the making.

System Initiative is 100% Open Source, fully multiplayer, and replaces infrastructure as code. It provides a living architecture diagram to manage all of your infrastructure, no matter where it lives. It offers full programmability and customization, and you can get started with over 100 rich models that are 1:1 with upstream APIs, like AWS EC2.

I wrote about the capabilities of the System Initiative software in the past, but a lot has improved and changed since then. Let's talk about it in two parts: features and performance.

Feature Forward Initiative

We provide over 100 assets that richly model upstream APIs 1:1, but what if you want to write your own? What if you want to contribute your own? Maybe you have a small edit to make to an existing asset, just for you. Maybe you want to share your assets with your colleagues. What if you want to change the inputs for functions that your assets use? Maybe you want to add an additional socket to your asset? You can do all of this and more in System Initiative.

Configuration and modeling were first class features in early versions of System Initiative. However, we know that System Initiative thrives when it is customized with maximum programmability. Over the past year, authoring has not only become a first class feature of SI, but it has become a cornerstone of what makes SI transformative and truly special.

Many low-code tools suffer once the honeymoon is over and you need to customize your experience to your needs. System Initiative embraces the power user and provides more flexibility than infrastructure as code has ever done before. Authoring assets and functions allows you to interact with upstream APIs directly without having to deal with abstractions.

Need to model a virtual machine from a cloud provider? You can model their API 1:1 by using the asset builder and authoring interface. Need to provide metadata from the virtual machine to another component on the diagram? You can add an output socket to your new asset and source the value from another prop within the asset. Need to transform the data on the way out into a different shape? You can write a custom attribute function to transform the data for other components to use.

Don't worry, if this terminology is new or confusing, we have tutorials and docs ready for you today at docs.systeminit.com! You can also reach out to us and fellow community members anytime in our Discord server.

Configuration works better and faster than ever too. You can compose secrets throughout the system and have secrets that depend on secrets to be used in other components. You can create complex, nested frames to mass connect sockets without having to draw individual edges. You can see and learn more from the diagram without having to navigate between different screens and views, more than ever before.

Whether you make small edits to a couple properties on a single component or create a hundred AWS EC2 key pairs at once (totally not a performance smoke test of mine), you will be able to compose, configure and manage your infrastructure on one screen to rule them all. The best part? You can do this with your friends and colleagues in real-time.

Say goodbye to pull request ping pong and waiting for long CI/CD queues! Your configurations can be validated and qualified automatically through customizable functions. Not only is deployment native and abstraction-less, but the collaboration we've all been craving is now there.

This is all powered by a living architecture diagram that reflects both the real world through imperative changes and your model through declarative changes.

Infrastructure is a living, breathing thing. It changes, drifts, crashes, reboots, upgrades, and shifts. Declarative infrastructure is great, but giving you the choice is essential. We deserve to have the choice.

Performance Enhanced System

Since the open source launch, performance has dramatically improved through a variety of means; one of which is through our homegrown naxum library. It's an axum-like server that handles core NATS and NATS JetStream messages at lightning fast speeds.

All of our services communicate via core NATS for fan-out and UDP-style messaging, and NATS JetStream for workqueue and durability-sensitive messaging. Creating naxum was a labor of love by Fletcher Nichol and many others at SI, and it's been incredible for building an intensely complex distributed system.

From late July 2023 to March 2024, we worked on a new engine for System Initiative. Powered by petgraph, the new engine switches from a hypergraph of functions powered by PostgreSQL tables and complex queries to an in-memory, directed acyclic graph backed by a multi-layered, distributed database. Complex operations moved out of PostgreSQL moved into our own services, providing substantial speed increases. Questions about lineage for updating existing assets with new versions upstream and providing a fully-featured multiplayer experience became infinitely easier to answer.

Originally, we embarked on the new engine journey to tackle the lifecycle of modules. There was no talk of a "new engine" at the time. We needed to handle the lineage of modules and assets in workspaces and change sets. However, it quickly grew into a journey about performance, features and ultimately, a paradigm shift at the engine-layer of the System Initiative software.

Since May 15th of this year, we've been fine tuning and hardening the new engine since reaching feature parity with the old engine. In fact, we've since made our graphs simpler, dropped their reliance on vector clocks, and have switched to an operational-transform model for eliminating needless conflicts across the board.

The storage layer is powered by our handcrafted layer caching service. The layers include both memory caching and disk caching, and all writes are eventually written to PostgreSQL.

All of these performance optimizations are for naught without horizontal scaling capabilities and effective multi-core utilization. All SI backend services can be horizontally scaled with 1:N instances. They feature both graceful shutdown procedures and are protected against unexpected shutdown scenarios. This is accomplished through a variety of means, but using NATS JetStream for durable messaging, and our layer caching service for fast reads and writes, helps ensure that our distributed system is both fast and correct.

Go try it!

Over five years of handcrafting the future of DevOps automation has been an incredibly tall task, but we are more than excited to give you what our industry needs now, more than ever.

If you made it this far, you owe it to yourself to go to our website and try it. No need for me to keep yappin' here.

Thank you, once again, to my team and our community for everything you've done. As always, I'll see you on our Discord server!

Finishing My Desktop Upgrade After 18 Months

Sun, 25 Feb 2024 00:00:00 GMT

I finally and recently finished my personal desktop upgrade that began in July 2022. Let's talk about it!

This is it: an Nvidia RTX 4090 GPU and an AMD Ryzen 7 7700X CPU inside of a Lian Li O11D EVO XL case.

Knowing that new CPUs and GPUs were around the corner, I decided to upgrade my desktop PC with a full refresh in July 2022. I started with some fan upgrades and a case swap, but the first major upgrade focused on the CPU. I upgraded to an AMD Ryzen 7 7700X CPU in November 2022. I was considering the Intel Core i7 13700K/13700KF or waiting for a potential Zen 4 X3D model down the line, but I ultimately decided on the 7700X.

What led to that decision? A few things. I had been experiencing performance bottlenecks with my old CPU. There was an active Micro Center deal at the time for AM5 CPUs. The lower power draw of the 7700X was a nice bonus in comparison to the 13700K/13700KF. Finally, I believed (and still do) that while AM5 may not live as long as AM4 did, I'd likely be able to drop a future generation 3D V-Cache ("X3D") CPU.

Now, onto the GPU. Given the subpar launches of the Nvidia RTX 40 series ("Ada") and the AMD Radeon RDNA 3 series GPUs, I temporarily stuck it out with the CPU upgrade alone. I was bracing for impact given inflation and the 2020-2022 GPU craze, but I did not expect bad prices and questionable product placement from both product lines.

That being said, I eventually YOLO'd for the RTX 4090 FE (Founder's Edition) in May 2023. The non-FE models were not enticing and were generally more expensive. Moreover, the RTX 4080's pricing was egregious relative to its performance. If the RTX 4080 FE had the RTX 4080 Super FE's MSRP at launch, I probably would have went with the RTX 4080 FE instead of the RTX 4090 FE. Alas, Nvidia got me in the end, like they had for so many others.

With both primary components in hand, I began to evaluate how I could effectively cool them for gaming, graphics, code compilation and AI-based workloads. My focus shifted to the cooling and stayed there for many months to come.

I bounced between a few cases and CPU coolers from July 2022 and January 2024. Due to the increasing size of GPUs and increasing thermal requirements of CPUs over the past half decade or so, few of the existing cases and coolers were appealing to me. Sure, undervolting and power limiting can be effective, but I wanted to build something with headroom for future upgrades that could all-core workloads.

Ironically, I considered a small form factor build at many points in the process. Many cases performed well thermally and were beautiful. Not only that, but the SFF Gurus Discord server and r/sffpc were (and still are) some of the most active and exciting PC communities.

I was very tempted to go with the Dan C4-SFX v1... well, at least I was if I had a chance to get one. The Fractal Design Terra looked great too, but I was worried about thermal constraints. I could have went with an external radiator, like the MO-RA3, I didn't want to. The T1 v2 was the frontrunner, but I eventually concluded that noise, thermals, radiator compatibility and big case features (e.g. removable fan and motherboard trays) were more important to me than I had realized.

After months of research, including announcements from Computex 2023 and CES 2024, I decided to make a move. At the start of 2024, I decided to appease my teenage self, and just go for a big case with maximum cooling. Moreover, I wanted a case that I could keep for a long time and potentially build a custom loop in.

Why didn't I build a custom loop then? While budget custom loops were possible, I preferred to put some money aside for a proper loop in the future. I also loved (and still love) the Founder's Edition cooler design and did not want to put the GPU on a waterblock. Present day CPU AIO coolers for CPUs and GPU air coolers are better than ever too. That all being said, I probably will do try building a custom loop someday, but decided to punt for this build.

With the overall direction in place, I began the case selection and fan configuration design process.

First, I decided on the case. Few mass production cases have the quality of the Lian Li O11 series. Yes, the cases are common and many consider them to be long in the tooth. However, as far as mass production ATX cases go, I cannot find another case that is nearly as flexible and well built as those in the O11 series. Not only that, but Lian Li cases come with many helpful accessories and tools, such as screw separators and GPU anti-sag mounts.

Second, I decided on the CPU cooler. I wanted to maximize CPU performance and radiator space, so I did not look at air coolers and looked exclusively at 360mm and 420mm AIOs. I decided to go with the EK-Nucleus AIO CR360 Dark. It was a 360mm option, but I chose it because I had two 120mm NF-A12x25 chromax.black.swap fans sitting around, they did not offer a 420mm model, and the AIO performed extremely well compared to existing 360mm and 420mm AIOs on the market. I bought a matching fan, though I would have also considered Phanteks T30 fans if I did not already have the other ones. It's hard to go wrong either way.

If I had known about the incoming 420mm Arctic Liquid Freezer III, I would have waited for reviews and compared both AIOs. Alas, such is the way of PC hardware industry: there's always something better on the way.

Third, I decided on the case fans and overall fan configuration. Christopher Flaningan's video was a great place to start and I decided to go with six 140mm intake fans and no rear exhaust fan. Normally, I go with Noctua fans whenever I can, but I prefer the Arctic P14's noise profile over the Noctua NF-A14's noise profile. They are also considerably less expensive than the NF-A14s and can be daisy-chained (i.e. they do not require a Y-splitter or fan hub). That being said, I'm looking forward to reviews of Noctua's next generation 140mm fan. Most of these points are minor, so if you go with Noctua or Arcitc, you are in good hands.

I put it all together into a design diagram to double check...

...and everything looked good! Time to build.

I went to Micro Center to pick up the O11D EVO XL with my fiancée and we could barely fit the box in the car. Of course, the case wasn't as big as Lian Li's monstrous V3000 Plus, but it still couldn't fit into the mouth of the trunk. So... we strapped the case into the passenger seat and she sat in the back. It would be an understatement to say that I was thankful for her that day.

A few weeks went by, working on the build here and there as well as ordering fans, cables, etc. that I needed. After some tests with different power supplies, performing all-core CPU benchmarks, performing GPU-based realtime Path Tracing benchmarks, laying the PC on its side to move air bubbles in the AIO and fixing a noisy rear exhaust FE fan (which had been fine in the previous case), the build went to its home on a wooden plank.

One thing you might have noticed in the build picture is that I stuck with the included PSU cables from SeaSonic's Vertex GX-1000 power supply. While I knew I would have been fine using aftermarket cables, the 12VHPWR connector drama and revisions to popular adapters made me hesitate. It helped that I liked the cables provided too, so I didn't replace what wasn't broken.

I could not be happier with the result. Since July 2022, I had been slowing chipping away at this build. Sure, it only started in full in November 2022 and was "feature complete" in May 2023, but PC builds are a bit of an artform to me. You mostly buy pre-existing parts, but there are subtleties in how it looks to you and feels to use that make it "yours" in the end.

It's safe to say that my desktop upgrade is done. Now and forever. Well... at least until AMD Zen 5, Nvidia RTX 50 series, Intel Arrow Lake, Intel Battlemage, and AMD Radeon RDNA 4 release later this year.

Path Tracing, Ray Reconstruction and Super Resolution Bring on the Future

Tue, 02 Jan 2024 00:00:01 GMT

Today, we talk about the incredible work the teams at CD Projekt Red and Nvidia have done to give us a glimpse of the future of 3D graphics.

In September 2023, CD Projekt Red released their sole expansion for their 2020 game, Cyberpunk 2077. The expansion, "Phantom Liberty", takes the player to a new area of Night City (the game's fictional city placed between San Francisco and Los Angeles).

While the expansion was excellent in its own right, Update 2.0 stood center stage, side by side with it. The free update not only contained a massive rework of in-game systems, but it also contained Nvidia's new "Ray Reconstruction" technology, which "recognizes lighting patterns from training data, such as that of global illumination or ambient occlusion, and recreates it in-game as you play"[^1]. In short, Ray Reconstruction is a feature within the DLSS software suite that uses AI-powered "denoisers" and lighting technology to render more accurate ray-traced rays and diffuse lighting.

The introduction of Ray Reconstruction comes off the heels of the "Path Tracing" update for Cyberpunk 2077 in April. Path Tracing, or "Full Ray Tracing", takes single bounce (i.e. light "bouncing" off an object in a 3D rendered scene) ray tracing techniques to the next level by rendering ray-traced rays with multiple bounces. Its name is derived from "the rendering equation solved along the path of a ray"[^2]. In other words, the game's ray tracing implementation a step further by "accurately represent(ing) the way light scatters throughout a scene"[^2].

Combine these two features with the honed DLSS Super Resolution feature, which performs AI-powered upscaling and anti-aliasing for better performance (and sometimes better presentation with "DLAA" and "Quality" settings at higher resolutions), and Cyberpunk 2077 became one of the most impressive technology showcases of 2023.

I was so impressed with the art and technology that I took many screenshots with the in-game photo mode. After sifting through them for a long time, I've selected my favorite twenty screenshots. All screenshots were captured between 25 September 2023 and 15 October 2023.

If you couldn't tell, I'm a little late to publishing this blog post.

These screenshots were taken from the 2.0 and 2.01 versions of the game, and take place throughout the main game and the new expansion.

All screenshots are "4K" (3840x2160p) images that were originally uncompressed PNG files. They have been converted to slightly lossy WebP images for size reduction. The game was running in HDR10 PQ, but images taken with the in-game photo mode are (I believe?) tone mapped to SDR.

The game's settings were maxed out with Path Tracing, or "Full Ray Tracing", enabled. Ray Reconstruction and Super Resolution were also enabled. I believe Super Resolution was set to "Auto" during the playthough, so I suspect the screenshots were taken at "DLAA" (no upscaling, solely AI-powered anti-aliasing) or "Quality" (highest quality upscaling) levels.

I'll stop talking and let the screenshots speak for themselves. To say that I was impressed with the teams at CD Projekt Red and Nvidia would have been an understatement. If this is a sign of what is to come, bring it on!

[^1]: NVIDIA DLSS 3.5: Enhancing Ray Tracing With AI; Coming This Fall To Alan Wake 2, Cyberpunk 2077: Phantom Liberty, Portal with RTX & More [^2]: What Is Path Tracing?

Creativity

Tue, 02 Jan 2024 00:00:00 GMT

"Creativity is a fundamental aspect of being human. It's our birthright. And it's for all of us"

-- Rick Rubin, The Creative Act: A Way of Being

If my university had an audio engineering degree, you probably wouldn't be reading this blog post. In college, I was a DJ, audio engineer, amateur producer, and a (not good) mixing engineer. I spent a lot of time doing all those things and did so with some grounding to reality.

"Can I make a career out of this?" Surprisingly, the answer was "yes", but it would have required a near-erasure of the line between freeform creativity and required output. In other words, I might have killed my musical hobbies and passions in the process. In fact, I almost did.

In my beginning years of DJing, I practiced a ton. I was pretty busy in high school, but as the years went on, I began taking more and more time to practice. Like something from out of a movie, in my third year heading into my fourth year in particular, I'd run to my bedroom, take my laptop out of my backpack, throw down the backpack, connect the laptop to the budget, magazine controller and get to work. Well... "get to work" meant "flailing and seeing if something sticks".

There was something very pure with those moments. Something I believe I lost in 2023... or, at least thought I did. We'll get back to that later.

Fast forward to the end of my time DJing: I was getting gigs left and right, but my studies in computer science were ramping up. Not only that, but I led a team that founded the university's first ever hackathon series. Something had to change. I chose to wind down my practice and preparation for DJing gigs. Although, I'm not sure what happened first: the gigs beginning to feel more like routine work than fun spontaneity or dwindling amounts of practice and preparation causing the sets to feel stale. Combine both with weeknight gigs that end at 2am and... you can guess what eventually came to pass.

I performed my last gig in May of my third year in university. It felt good to end on a high note as I had multiple back-to-back gigs to celebrate the occasion. Many of my early clients and partners reached out to either work with me one last time or to share kind thoughts on the years working together. All in all, it was a packed calendar of gigs to the end the semester.

I thank my past self often for stopping at this point rather than destroying a passion for music and making creative efforts feel like chores. In fact, that decision is more relevant than ever before.

2023 was a great, but confusing, year for me. From a career perspective, it was the first year where I felt that I was exactly where I wanted and needed to be. Well, that's not entirely true as I joined System Initiative (SI) in December 2021 and have felt that way since joining. However, I believe it took time for me to realize what was happening to my creative energy.

I usually have side project ideas, blog post drafts, and little creative works going on. In 2023, those things took much more of a side seat than I was expecting. While I do believe the decline of Twitter/X negatively impacted my creative energy for infrastructure software, I do not believe it was the primary contributing factor. I was living life, being more social than ever before, and worked hard in my favorite job yet. What was the problem? That sounds good, right?

The problem was that my creativity was more difficult to trace than ever before. Originally, I had thought my ability to be creative had waned. I was wrong and SI's co-founder, Adam, showed me why.

Where I had thought my creative energy had been sapped, it had merely been diverted. Rick Rubin's The Creative Act: A Way of Being was central to our discussion in uncovering this. If you are human, you are automatically an artist. Simply put, deep down, the art I wanted to create in 2023 was System Initiative. That's where my primary, creative energy went.

I've had little to blog about in the industry because I believe in what we are doing more than anything else. I've had little desire to create side projects for the same reason. I've been laser focused on co-designing and co-authoring a new engine for SI since July 2023 too. Finally, in the background, I had my busiest year outside of work yet, so I did not fully process how (and if) I was tapping into my creative spirit.

To be clear, none of that is bad. In fact, it's all great! That's the point. The company had an incredible year, which included exiting stealth, nurturing a growing community on our Discord server, and open sourcing the System Initiative software. Again, what's the problem?

Well, again, the problem was that my creativity was more difficult to trace than ever before. It took me reflecting on my years DJing to realize this, but my creative energy became exclusively tied to professional endeavors.

Again, that's not a bad thing, especially since I joined as the fifth person at System Initiative! In a startup, you need passion and creativity to be ever present. I reflected on where my creativity naturally flew, and it made complete sense: my creative energy naturally flew into SI.

What now then? Well, the primary art I want to create in 2024 is the same as 2023: System Initiative. However, I'd like to do things a little differently. I have a desire to reconnect with my creative side outside of SI. Ironically, if you're reading this around the time of publishing, you likely only know about this blog because of my creative output in the past. This post is a long way of saying that I'd like to create more art... or "art", depending on your interpretation.

I'm unsure what I'm going to do exactly. With DJing, I naturally let my creative energy take me places. Did I know I wanted to become a DJ? I mean, maybe, but I only really know once I was... well... DJing. Adam put it to me best: "how did you become a DJ? Well, you DJed! Now you're a DJ.". Learn something. Write something. Build something. All creative endeavors are like this.

That being said, I have a good idea on where to start. I wrote a new blog post alongside this one: "Path Tracing, Ray Reconstruction and Super Resolution Bring on the Future". I used to hold back on posts like this because they didn't stick with the core themes of the blog, which hover around infrastructure software and software development. To some extent, that's not the worst stance to take. When content creators on YouTube create diverging content and user metrics indicate that something has to give, they may create a second channel. However, I'm passionate about PC and workstation hardware. I feel naturally flowing, creative energy going towards it, so why not create some art... or "art"?

For 2024, I'm going to remembering the teenager rushing into the bedroom to learn how to DJ, flailing and all. Learn something. Write something. Build something. Even if the art I solely work on this year is System Initiative, I'll do so having been re-attuned to my creative spirit. Here's to creativity in 2024!

System Initiative: The Second Wave of DevOps

Wed, 21 Jun 2023 00:00:00 GMT

It's finally time to talk about System Initiative. Since early December 2021, I've had the privilege and honor of working alongside one of the best software teams on the planet to handcraft foundational technology for ushering in the second wave of DevOps.

Today, we are talking about System Initiative publicly for the first time, and in the coming months, we will be open sourcing the System Initiative software. Let's get into it.

Stuck in the Mud

What we've built has not only been an endeavor of passion for all of us at System Initiative, but, for me, it's the direct answer to everything that I've seen in my career thus far.

Before I had written my first line of non-trivial code in university, I was introduced to the world of software via Linux. Tinkering with desktop computer hardware and tweaking desktop environments in Linux VMs in my teenage years set the stage for what was to come. Everything from my first stint in academic research working with Docker containers to writing infrastructure software for Kubernetes in my prior professional endeavors has led to this.

Yet, despite repeated successes witnessed both firsthand and within the industry, the excellent tools we had individually built never met their aspirations in the aggregate. Customers, hobbyists, academics, and developers loved what had been built in vacuums, but rarely carried over those sentiments when the pieces interlocked. The interlocking and frustrations have only increased since I entered the industry. From my first boot of a Linux VM to now, I've been embroiled in the first wave of DevOps.

In the fall of 2021, Adam and I discussed what I wanted to do next in my career. We talked about everything, including becoming a founder, woes in the DevOps space, and, of course, System Initiative. When Adam showed me a prototype of System Initiative, everything halted and our conversations converged on it. It was exactly what our industry needed then and what our industry needs now, more than ever. Even if I was hellbent on becoming a founder then, I knew that I would need to build the same thing. Thus, I joined in December 2021 as the fifth person in the company and have not looked back.

Tip of The Spear

Enter System Initiative. It's a real-time, multiplayer, multi-modal reinvention of DevOps tooling. It's a power tool that re-imagines the user experience by delivering a near real-time, visual modeling system that uses digital twins to give users the power and control they need.

You can collaborate with colleagues across the world at the same time and with immediate feedback. Every change is validated and qualified immediately, so you can ensure your configuration is viable. You can reconcile individually or in batches and decide what you want to do with your model. Collaboration for software-defined infrastructure is back.

Speaking of reconciliation choices, the days of "declarative-only" infrastructure are over. No more individual infrastructure as code files sprawling into several repositories. System Initiative provides bi-directional reconciliation of the simulation with the real system to give you the choices you need to manage your infrastructure.

It's not oversimplified either. Configuration can be inferred through the relationships between models. Changing a value at the source cascades throughout all the dependent models, making complex configurations easy to express. The system will automatically generate code as needed. System Initiative is explicitly a power tool that removes papercuts experienced throughout the first wave of DevOps. You can leverage the intelligence system to tackle your most complex infrastructure stacks.

The best part? It's all customizable. You can publish modules to our open source module index to enable other users to use full-fidelity models in their systems. You can create your own functions and edit existing ones. You can change how code is generated. You're liberated to craft the infrastructure you need.

We're only scratching the surface of what System Initiative can do, and I can't wait for you to try it. Before that, let's talk about what's under the hood.

Under the Hood

System Initiative isn't an addition to an existing stack or platform, it's a bespoke design powered by breaking the rules and learning from DevOps builders. It's powered by Rust, TypeScript, Vue 3, PostgreSQL and many other state-of-the-art technologies that you'll be able to get your hands on soon.

The majority of the System Initiative software is powered by Rust. We make extensive use of the tokio ecosystem, communicate over NATS and heavily use PostgreSQL for a robust backend stack. Vue 3 and TypeScript lead the way for the user interface, which is snappy and responsive to your monitor's native refresh rate. The software is built with Buck2, a cutting-edge build system, with our own, custom prelude.

Our developers use the best tools for the job and measuring "best" does not just include implementation details, but also maintainability and joy. That philosophy is baked into System Initiative. It's not only a joy to develop, it's a joy to use!

Not only will you be able to try out the System Initiative software soon, but you can join us in getting there now.

What's Next?

The System Initiative software will be open sourced in the coming months. Between now and then, we'll give you peeks into what we are up to and the road there. More importantly, you'll be able to join us on this journey in a few places:

In our Discord server, the community for all DevOps builders ready for the second wave. We'll be providing weekly updates, gathering feedback, giving you all sneak peeks on what's to come and just plain ole hanging out!
On systeminit.com as there will be press release(s), podcasts, articles and many other forms of content to let you know what we are up to. We're going in guns blazing.
On social media, where Adam, myself, the company and the team will be talking to about System Initiative with open arms.
On YouTube, by watching and sharing the demo on YouTube and catch the first ever, public look at System Initiative. Be sure to subscribe as more videos are coming!

Welcome to the second wave of DevOps. I can't wait for you all to take a look at and try out the System Initiative software soon. See you in the Discord server!

Converting Rust Cloud Native

Mon, 25 Jul 2022 00:00:00 GMT

Nearly one year ago, a flagpole was planted to launch Rust Cloud Native. We have had great successes since then, including great meetups, great conversations, folks working on and sharing differing projects, and more.

However, after speaking with other folks in the organization, we have decided to convert Rust Cloud Native to Awesome Rust Cloud Native. Since Rust Cloud Native never had any formal communications platforms, I sent a message to the primary channel of the Discord server this morning and we plan on updating the core repository's README as soon as possible. Here are the contents of that message (slightly modified in order to make more sense outside of Discord):

Hi friends @here!

First and foremost, I want to thank you all for being here and hanging out with the meetups we’ve had, the conversations we’ve had, and everything we’ve done together. You are all delights!

The maintainers and I spoke this morning and decided that Rust Cloud Native should not live on as a structured organization at this time. I’ll explain the “what’s happening” before the “why” so folks know.

This server will close sometime on Wednesday, July 28th

Given some feedback, this may be subject to change or there may be plans to have a more conversational/casual server in its place (regardless, it is recommended to prepare for server closure)

The GitHub org will be renamed from “Rust Cloud Native” to “Awesome Rust Cloud Native”

The core repository will be converted to “awesome” list: https://github.com/sindresorhus/awesome

It may also convert from a GitHub Page to just a README, but that one is still in flux (regardless, we will update the README there with more details)

Short version: Rust Cloud Native will be scaled back to solely maintain the “awesome” page that we already mostly have going. Now, this doesn’t mean that things like “beginner resources” and such cannot be added later. However, it does mean that the core repository will be refactored to scale it down for now.

Since this org does not have a blog or Twitter account, I presume we will let folks who have starred the repository know by adding a message at the top of the README and/or website for now.

Now, onto the reasoning: running a structured organization requires time and willingness. I will speak for myself here: I created the organization in a very different world for me personally, and after no longer working on cloud native software and experiencing burnout in 2021, I reeled back many non-essential things to deal with things in my personal life. While it was originally started as a "let's plant a flag pole and get folks to gather" effort, it is evident that it required more curation than I had the volunteer time to give it. I cannot speak for others, and I appreciate your respect to their privacy.

We would hand off the organization to willing parties, but truthfully, there is not much of an organization to hand off. On GitHub, the organization has really only existed to main the core website, which is already like an “awesome” list. At this time, we are interested keeping what we have: the core repository.

Thus, we will be freeing the “Rust Cloud Native” name up for folks who will want to use it. Fortunately, given the successes of kube-rs, youki, krustlet, krunvm and many more projects, as fans of the languages, we think things will be just fine.

I want to apologize that this did not work out as intended. There were definitely successful moments, including the core repository itself, our nice conversation and meetups when they did happen, and a recognition of interest in Cloud Native Rust overall. Thank you for helping us to try to make this work.

Thank you all for reading this post as well. The future of Rust in the Cloud Native space is brighter than ever before, and I am excited to see it continue to shine 🦀.

Announcing gfold 4

Tue, 10 May 2022 00:00:00 GMT

Today marks the release of gfold 4 🎉!

Before we talk about what's been changed, let's talk about how far the project has come. Here are some present day statistics of note:

📦 ~2,650 downloads from crates.io
📚 rank #7 on lib.rs for command-line-utilities
⭐️ 137 stars on GitHub

As some of you might recognize, these metrics are the same as those introduced in the gfold 3 announcement. Here are the statistics from that post:

📦 ~1,600 downloads from crates.io
📚 rank #21 on lib.rs for command-line-utilities
⭐️ 90 stars on GitHub

Those are big leaps! I'm excited for all new and existing users to try out gfold 4, which I think is the best release yet.

There's two technical reasons that fuel a significant portion of my excitement.

I hope this release will contain the last major semver bump that will be needed for a long time (i.e. no more user-facing breaking changes for a long time). It's a polishing iteration on the domain-driven refactor of gfold 3.
There will likely be significant performance improvements for most users. In recent tests mimicking real world use, I've seen up to 5.1x speed increases when loosely benchmarking the most recent release candidate on macOS 12.3.1.

Average: 686.645865ms - /Users/nick - 4.0.0-rc.4
Average: 810.047984ms - /Users/nick - 3.0.0
Average: 6.156336ms - /Users/nick/src - 4.0.0-rc.4
Average: 31.491704ms - /Users/nick/src - 3.0.0

Please note: I use the term "loose benchmarking" to mean measuring average runtime duration with realistically-shaped dummy data and execution scenarios reflecting real world use. The latter translates to direct invocations of the gfold binary on mobile hardware.

True benchmarking is difficult, especially when using consumer-grade mobile processors that can produce highly variable results based on temperature and battery. However, gfold users will likely be using consumer-grade mobile hardware (i.e. laptops) on battery power, so I've been mostly happy with "loosely" benchmarking real world usage scenarios on similar hardware.

TLDR: these benchmarks aren't precise, but they have been useful in making changes that can help result in perceptible performance enhancements for most gfold users.

If gfold 3 was the domain-driven refactor that helped revitalize the project, gfold 4 is the follow-up that takes lessons learned from the initial design and makes breaking changes based on them whilst retaining the skeleton of the previous release. In fact, gfold 4 was originally slated to release as gfold 3.1 due to its core execution loop remaining the same, but I am generally not a fan of deviating from semver rules and since there were user-breaking changes, I bumped the major semver field.

So... what are these major breaking changes that prompted the major semver field bump? Let's go over them.

git2-rs returns and has replaced calling git subcommands
- In previous versions of gfold, git subcommands replaced git2-rs in order to decrease binary size and allow for customization (i.e. "bring your own git")
- Since "speed" was a key driver of gfold 4's design, substantial speed increases could not have been achieved without git2-rs, even if that meant increasing binary size
The --git-path flag has been removed since git subcommands are no longer used
Config file type has changed from JSON to TOML
- JSON is difficult for users to write and edit and since gfold configuration options are pretty "flat"
- TOML felt best for the task
Config file location has been moved from <prefix>/.config/gfold/gfold.json to <prefix>/.config/gfold.toml
- The nested directory structure is unnecessary
The -d/--debug flag has been removed in favor of using RUST_LOG
- This allows for more customization and removes unnecessary code (i.e. the flag set RUST_LOG=debug anyway, which env_logger can handle)
Remove -c/--classic flag in favor of -d/--display flag

Despite these big changes, gfold still follows the same execution pattern as before: no subcommands and operates on the current working directory (or config file setting) if a positional argument is not provided. Migrating exciting scripts, config files, aliases, etc. should be relatively painless since user-facing changes were limited to configuration and not to execution patterns.

That leads us into the best part: what are the improvements, features, and enhancements in this release?

Significant performance gains (observed up to 5.1x speed increases in loose benchmarks of real world usage scenarios on macOS 12.3.1)
- No longer reliant on git subcommand calls
- More consistent behavior since git2-rs is directly tested at a locked version
Color mode option with the following choices: "always", "compatibility" and "never"
- "always": display with rich colors (default)
- "compatibility": display with portable colors
- "never": display with no color
Display flag with the following choices: "standard" (or "default"), "json" and "classic"
- "standard" (or "default") and "classic" output options return from gfold 3
- "json" output is a new option that displays all results in valid JSON, which is useful for third party applications, plugins, parsers, etc.
Overhauled "help" (-h/--help) output with titled sections
- includes a troubleshooting section that explains when to use RUST_LOG and RUST_BACKTRACE
- includes a config file usage section that was originally included in gfold 3

There have also been significant non-user-facing changes both internally and externally to the application that have helped ensure this release is stable.

A large integration test has been added that creates dummy repositories in the crate's target directory
- Past and present GitHub issues have been used to create test scenarios covered by the integration test
- This test has significantly helped in gfold 4 development
Bors has been added to avoid merge / skew conflicts
Documentation comments have been added nearly everywhere for cargo doc
The module layout has been refactored to ensure subdomains exist as submodules when applicable
- display now contains its child, color
- report now contains its child, target
color now uses a harness rather than individual functions for speed and domain separation

Finally, a major shoutout to a community member, AcksID! AcksID has released the excellent Neovim plugin for gfold, nvim-gfold.lua. Please show AcksID some love. The plugin is great and has a bright future ahead of it. I highly recommend Neovim users to try it out!

All in all, this is my favorite release of gfold yet. I'm excited for you to try it out and I hope you enjoy using it.

For more information, access the 4.0.0 changelog or the rolling changelog.

How To Manage Rust Tools and Applications

Tue, 05 Apr 2022 00:00:00 GMT

While Rust tools and applications can be managed by package managers like Homebrew, most can be installed with Cargo. However, we must then ask: how can we manage to keep track of those tools and applications and update them accordingly? Let's talk about it.

Disclaimer

The original title of this post used the word "binaries" instead of "tools and applications", but since this post is meant to be a starting guide, I decided to use the latter.

After all, if you are reading this, you are likely used to using cargo install to install tools like gfold (shameless plug). I suspect many users would refer to most of what they have installed via Cargo to be "tools and applications". Thus, we'll be referring to what we are managing as "tools and applications".

One more thing before we continue: folks reading this may prefer using their system's package manager or something all-encompassing, like topgrade. This guide is aimed at those using Cargo and meant to be flexible with multiple workflows. There is no one way to manage Rust tools and applications. Feel free to pick and choose what you like from this guide.

Choosing to Use the Locked Flag

Let's start by installing gfold with cargo install.

cargo install gfold

This is great and works well. It does especially so for multi-platform use! However, we can modify it a bit by using the --locked flag. What does the --locked flag do?

"By default, the Cargo.lock file that is included with the package will be ignored. This means that Cargo will recompute which versions of dependencies to use, possibly using newer versions that have been released since the package was published. The --locked flag can be used to force Cargo to use the packaged Cargo.lock file if it is available."

- The Cargo Book

Alright, so whether or not we use the flag is preferential. There are benefits and detriments to each approach, so let's see what the docs have to say.

"This may be useful for ensuring reproducible builds, to use the exact same set of dependencies that were available when the package was published. It may also be useful if a newer version of a dependency is published that no longer builds on your system, or has other problems. The downside to using --locked is that you will not receive any fixes or updates to any dependency."

- The Cargo Book

Essentially, the --locked flag ensures reproducible-ish builds by using the dependencies specified in Cargo.lock (if found).

I prefer to use to --locked flag despite missing out on potential bug fixes, performance improvements and security updates to dependencies. This preference stems from my desire to have my experience using the tool or application to match that of the upstream developer's experience and intentions, which translates to using the dependencies they tested with and included in hosted binaries (e.g. binaries on GitHub Release pages).

For the remainder of this post, I'll use the --locked flag, but as you are following along, please feel free to drop the flag wherever you'd like.

cargo install --locked gfold

One thing to keep in mind: we can mix and match which binaries we want installed with the flag. It does not have to be all or nothing! We'll touch on how to do that later.

Ensuring Tools and Applications are Up to Date

Now, you have gfold installed, but we have a new problem: how do we make sure it is up to date? We will use the excellent cargo-update to do so. Let's install it.

cargo install --locked cargo-update

This tool checks if an installed binary (via cargo install) has a newer version available and will update it accordingly. It also has the ability to update all installed binaries (via cargo install) by using the -a/--all as well as force install (i.e. re-install) selected binaries by using the -f/--force flag.

We'll want the former behavior in order to accomplish our overall goal. Therefore, though we have only installed gfold thus far, let's update all potential tools and binaries installed.

cargo install-update -a

Before we continue to the next section, let's say you want to ensure some dependencies are updated with respect to Cargo.lock and others are not. We can use another Cargo subcommand that comes with cargo-update.

cargo install-update-config --enforce-lock <PACKAGE>

With the above command, we can toggle settings for how individual tools and applications are updated. There are more tweaks you can perform and I recommend passing in the --help flag to see what matches your preferences.

Creating a List of Installed Tools and Applications

Some people like to maintain state of what their package managers have installed via files.

For example, you can use Brewfiles, which are leveraged by homebrew-bundle to bundle non-Ruby dependencies for use with the Homebrew package manager.
Another example: you can execute dnf repoquery --userinstalled --queryformat "%{NAME}" > packages.txt on Fedora to display a list of user installed packages with the dnf package manager and redirect the output to a text file.

Similarly to the dnf example, we will manage a crates.txt file that contains out installed tools and applications. When doing so, let's use the multi-platform ripgrep instead of grep for our Windows friends.

cargo install --locked ripgrep

Side note: For Windows and PowerShell users, I have been using pwsh on macOS in addition to zsh throughout this post. I've tried to ensure multi-platform snippets and PowerShell-specific snippets work on your system, but I apologize for any inefficiencies or missed edge cases you may encounter.

Now, we can parse through the output of cargo install --list in order to create a clean list of every installed tool and application by name.

cargo install --list | rg -o "^\S*\S" > crates.txt

Look below for the contents of my crates.txt on the machine I'm writing this post on. Yours will likely look different!

bat
bottom
cargo-audit
cargo-bloat
cargo-expand
cargo-fuzz
cargo-msrv
cargo-nextest
cargo-udeps
cargo-update
cargo-watch
cargo-whatfeatures
cross
exa
fd-find
ferris-fetch
gfold
git-cliff
kubie
nu
onefetch
procs
ripgrep
starship
tokei
tokio-console
toml2json

We can put this file somewhere safe, like a public or private GitHub repository, in order to share it across systems. Homelab users may consider using rsync or a similar tool to manage file sharing and data backup themselves. The possibilities are endless!

Let's say we have a new system and want to install our Rust tools and applications from crates.txt. On macOS, Linux and similar systems, we can use xargs to install everything.

xargs cargo install --locked < crates.txt

On Windows and systems using PowerShell, we can do something roughly equivalent, though not quite the same.

$crates = Get-Content -Raw -Path .\crates.txt | Out-String
foreach($crate in $crates.split("`n")) { if ( $crate -ne "" ) { cargo install --locked $crate } }

We are also able to continually update our list by using the command we used to originally create the file. With that and the other snippets and tips laid out in this section, we can create, update, back up, install from scratch, and manage what we have installed on our system.

Automating Updates

Finally, we can tie this all together with automation. There are a bunch of commands to remember, so adding shell functions or scripts could be a good idea to make our experience better.

For the following example, we are using a zsh function, but transposing similar logic into your shell of choice should work on most popular platforms.

function update {
    if [ "$(command -v rustup)" ]; then
        rustup update
    fi

    if [ "$(command -v cargo)" ]; then
        if [ ! -f $HOME/.cargo/bin/cargo-install-update ]; then
            cargo install --locked cargo-update
        fi
        cargo install-update -a
        cargo install --list | rg -o "^\S*\S" > $SOME_ABSOLUTE_PATH/crates.txt
    fi
}

The above function checks if rustup is installed and updates your Rust toolchains, including Cargo, accordingly. Then, it checks if Cargo is installed, installs cargo-update if it has not been installed, updates all tools and applications installed with cargo install, and then dumps the list of those same tools and applications into a crates.txt file. Whew.

There are a lot of possibilities here for advanced management here. Perhaps, we could explore an opportunity to force updates with for all installed binaries (i.e. cargo install-update -a --force) if the stable toolchain has been updated via rustup update. I say, get creative!

Update Away

With this guide, tips and snippets, we are ready to manage our Rust tools and applications!

There are likely areas for improvement and optimizations that we could make here and there, but this guide is meant to get you started as well as to find and inspire methods that work best for you. Go forth and update away!

Will your PC be able to run Starfield?

Wed, 16 Mar 2022 00:00:00 GMT

Video games are a little off topic for this blog, but what started as a Reddit post draft to help others felt like it would be better served as a blog post to help even more people.

I've seen quite a few posts on r/Starfield and other places online with folks asking the following: "will my PC be able to run Starfield?". With today's new Into the Starfield entry likely bringing in more folks worried about being able to play the game on release, I wrote this collection of speculative answers to help those who have the aforementioned, well-intentioned question.

TL;DR

Let's start with my estimate at what kind of system will be required to play the game and then dive into the reasoning later.

I suspect that your system will likely be fine for at least native 1080p 30fps play at Low-to-Medium settings if it has "near-equivalent-or-better" components to the Xbox Series S. The Xbox Series S is the entry level console that Starfield will be released on, so we should try to match or exceed its relative performance. If we want to do that, but also cover easier-to-upgrade components in the macroeconomic climate, like RAM and storage, our system might look at a bit like the following:

GPU: Various
- Slightly Less Optimistic: Nvidia GTX 1060, AMD RX 580
- Slightly More Optimistic: Nvidia GTX 1070 Ti, Nvidia GTX 1660 Ti, AMD RX 6600 XT, Nvidia RTX 3050
CPU: Intel Core i5-9400F, AMD Ryzen 5 3600
RAM: Mid-range 16 GB DDR4
SSD: Mid-range PCIe Gen 3 SATA SSD

I suspect that your system will likely be fine for at least native 1080p 30fps play at low to medium settings if it has "near-equivalent-or-better" components. Even then, for components like the CPU, you could likely use older components than what I've listed. The variability is just too wide without any concrete data on how Creation Engine 2 works or how Starfield performs, so I'm playing it a bit safe with this estimation.

Want to know how this estimate came to fruition? Read on!

Context

The quick answer to "will my PC be able to run this unreleased game?": we have no idea.

We may not even have the full idea when BGS (Bethesda Game Studios) announces minimum and recommended specs because the depth of those lists can vary between developers. Until independent reviewers, specifically performance-focused ones like Digital Foundry, meaningfully benchmark the game, we will not have substantive answers to that question.

On the other hand, many folks are new to PC gaming, not interested in the more technical aspects of the hobby, and/or have other situations where they are just looking for help to ensure that they can play the game when it comes out. This post aims to help those folks and possibly others.

Short disclaimer: I've been playing PC games with a discrete GPU for over a decade, but I am not a game developer.

I'm a software engineer who has mainly worked on cloud infrastructure software. Sure, I've dabbled in graphics APIs here and there, have made tiny, unreleased mods for Skyrim and Fallout 4, and try to keep up with the technical aspects of game development at a high level. However, I do not consider myself qualified to give answers on how games exactly work or what to fully expect out of Starfield's performance on your PC.

I share my background to be transparent: I am writing this post from the propsective of a fan and player, not a game developer (though that could be fun at some point).

With those bits of context out of the way, please take the following thoughts with a huge grain of salt as they are merely meant to help folks between today and the day we will begin to see actual benchmarks before the game's release.

Compare to BGS' Latest Title, Fallout 76

You can look at how your system performs with Fallout 76 as a start, but since that game is an online, AAA game using a modified version the first Creation Engine, it might play "differently" to BGS' offline singleplayer titles.

Example of playing "differently": using VATS in Fallout 76 PvP might not necessarily indicate that Starfield will behave similarly due to networking and major gameplay differences
- I would ask myself, "could this similar type of system taxing behavior happen often (or at all) in Starfield?"
Example where the games may perform similarly: private Fallout 76 worlds where you are exploring areas of the game where you get "average" framerate
- Removing "best case" and "worst case" performance areas from your benchmarks may help since since we do not know the performance demands of Starfield and its use of Creation Engine 2

Compare to the Entry Level Console, the Xbox Series S, Across Several Titles

I would expect for the worst and hope for the best when comparing relative performance between your system and the Xbox Series S in modern, AAA offline-or-mostly-offline titles.

Short note on "equivalent" hardware: you are going to see me put the word "equivalent" in double quotes everywhere. I do this because it is difficult to discern which discrete GPU produces "equivalent" performance to the Xbox Series S in one game, let alone several games. The Xbox Series S may architecturally look like a PC more than the vast majority of consoles preceding it, but it still differs in key areas that we will touch on later. It is helpful to keep this in mind since console and "equivalent" PC performance can vary depending on a lot of factors.

The Xbox Series S rasterization performance ("how many frames can I pump out without doing anything fancy, like ray-tracing") is difficult to declare "equivalent" to one from a discrete GPU, but let's say it lands somewhere between a GTX 1060 and GTX 1070 Ti
- This estimate is based on anecdotal knowledge from several titles, videos, articles, etc. and is purely meant to provide a baseline for the rest of the article
The Xbox Series S shares memory between the CPU and GPU, meaning recommended RAM quantity is difficult to calculate (i.e. unlike the Xbox Series S, a discrete GPU in your PC, like the GTX 1060, has its own RAM called VRAM)
- It may be best to see how the Xbox Series S performs in other cross-platform titles
The Xbox Series S has a fast SSD that works in tandem with the DirectStorage API, meaning that it may be able to take advantage of loading objects, areas, NPCs, etc. compared to an average gaming PC
- This is coming to Windows 11, but we don't know the full extent to how and if this will work with the PC version of Starfield (and even PC games in general)
The Xbox Series S will likely get special tuning and treatment for Starfield, meaning that an "equivalent-ish" PC may experience slightly worse performance
- This point is very speculative, but I want to highlight that it may be a good idea to ensure that your rig overshoots anticipated Xbox Series S performance for "equivalent" hardware (if you can swing it!)
The Xbox Series S may have dynamic resolution scaling, checkerboarding and similar methods that the PC version may not have
- Essentially, these strategies aim to run the game (or objects in your game) at a resolution lower than your monitor's native resolution and upscale to your native resolution while trying to do so in ways that aren't easily perceptible to the everyday player
The Xbox Series S version may feature lightly implemented, well-tuned ray-tracing and/or real time lighting/shadow effects in Starfield that "equivalent" discrete GPUs might not be able to do
- Remember, the GTX 1060 and GTX 1070 Ti do not feature ray-tracing
In general, "equivalent" discrete GPUs might not be able to take advantage of the exact same graphics "settings" as the console version
The Xbox Series S might have better frametime consistency than "equivalent" hardware due to tuning and optimization
- On frametime consistency: a lack of frametime consistency is when frames aren't delivered at smooth intervals, so even if you get an average 60fps in your game, if an average set of frames is delivered "choppily" and each frame is not spaced out "evenly", then the experience will feel worse than another system with good frametime consistency at 60fps (this explanation is a tad reductive, but a high level understanding of this phenomenon can be helpful for the greater context)
- From my experience, less-than-ideal console ports to PC can have worse frametime consistency, but since BGS has solid history with PC releases, I bring this up purely for anticipating "worst case" scenarios
Anticipate playing at 1080p if you are slightly above, around, or below the "equivalent" Xbox Series X spec
- My guess: the Xbox Series S will likely play at dynamic 1440p 30fps using resolution scaling methods
- Anticipating playing at native 1080p 30fps with near "equivalent" systems may set some good expectations
All of the above points reflect the following fact: the RDNA 2 and Zen 2 based Xbox Series S hardware is newer than the GTX 1060 and GTX 1070 Ti, despite boasting similar performance
- There might be a feature or optimization here and there that makes the console perform better or more consistently than PCs using the aforementioned GPUs

Potential PC Advantage, Even With Older Hardware

While I've been assuming native resolution for a lot of these thoughts, we have no idea if Creation Engine 2 has DLSS, FSR, dynamic resolution scaling, checkerboarding, and/or other similar features. If any those features are included in the PC version, the answer to our big question may be dramatically different.

The second that you can run Starfield at an internal resolution of ~720p at 30 FPS with FSR 2.0, the second a lot more players will likely be able to enjoy the game
Easy to upgrade parts (in the current macroeconomic climate) that may impact gameplay: RAM and SSD
For RAM, I recommend having at least 16 GB
- Despite its performance issues, Elden Ring comes to mind, which "requires" 12 GB of RAM
For SSDs, I recommend most mid-range-or-above SATA SSDs
- I would not plan on using a mechanical hard drive to play the game
While the unknown nature Windows 11 and the DirectStorage API from before is something to keep in mind here, the performance of mid-range PCIe Gen 3 SATA SSDs ("average" SSD of the 2010s) have been enough for games in recent years and will likely be enough for Starfield
- That being said, keep an eye on this space...

Looking at Similar, Previously Released Games

Look at Skyrim and Fallout 4: barring certain areas of these games, like parts of downtown Boston in the latter title, these games ran well relative to their hardware at the time, including lower-to-middle-range systems.

Fallout 76 is worth considering too, as previously mentioned
- Searching for performance-focused reviews might not tell the whole story since, at present, performance is likely a different story from launch (ensure your sources are based on newer builds of the game)
- If you have the game, it might be a good idea to boot it up with an FPS counter (while I recommend Shadowplay for Nvidia GPU owners, the Steam FPS counter shoud work for everyone)
Look at the newest, biggest open world, mostly-offline-or-offline, AAA games
- Forza Horizon 5 and the Halo Infinite campaign are other titles potentially worth using for comparison
- Elden Ring and some other AAA, cross-platform titles on PC have had a host of performance-related issues on launch, so if you plan to play any massive AAA game on day one, you should prepare for a non-ideal experience, but hope for a great one!
- I say the above understanding the difficulty of game development and have immense respect for game development teams
Many Intel Core i5 and AMD Ryzen 5 CPUs will likely be more than enough for 30 to 60 FPS gameplay
- Perhaps, there will be CPU-bound areas and scenarios, but based on prior BGS releases, we can hope that this is the exception rather than the rule
- Remember, the goal is to answer whether the game will run Starfield, and not whether it'll run well in all areas of the game
The GPU will likely be the bottleneck, as it is for most PC titles
- This part is a bit annoying as the current GPU market is dramatically improving but is still... a bit annoying
- BGS games have often been relatively easy to run and scale relatively well with the available GPUs of each games' time

Concluding Thoughts

I hope my speculative answers and thoughts help folks that are preparing to play Starfield on PC when it releases!

As a reminder though, these are just thoughts from a software engineer way out of his lane in hopes of helping others. Take everything with a grain salt and thank you for reading.

Announcing gfold 3

Tue, 04 Jan 2022 00:00:00 GMT

Today marks the release of gfold 3 🎉!

It's a bit surreal, given that this project started in a private repository from my early days of learning Rust.

I began to learn Rust in the middle of 2019, for many of the reasons popular among newcomers: safe concurrency, compile-time reliability, great community, etc. Leading into 2020, my Rust code steadily improved, I started iterating on public projects (as well as many more private projects), and gfold's codebase aged quickly.

All of my other Rust projects were better designed, better written, and more interesting in a technical sense than gfold. Yet, I continued to use it more than any of those projects. Despite the state of the codebase, my favorite part about gfold was that I was using it daily, and multiple times throughout the day. Thus, I decided to open source what I had in early April 2020.

Many of you decided to try it out since then! At least, it seems as such because, as of version 3.0.0-rc.4, the project has seen the following:

📦 ~1,600 downloads from crates.io
📚 rank #21 on lib.rs for command-line-utilities
⭐️ 90 stars on GitHub

For a project that was not originally intended to live past my earliest days of learning Rust, that's pretty great! I'm thankful for all users of gfold, and I am excited for you to try out version 3.0.0.

Design

gfold 3.0.0 is centered around a domain-driven refactor. Its focus areas include the following:

Targets: focus on generating targets with a given config
Reports: generate reports given generated targets
Displays: display results for generated reports

These focus areas contain separate entities that try to be self-contained. However, gfold is a small, "single-execution" binary, so these focus areas may intersect with one another in practice. For example, it might be optimal to combine and parallelize everything:

    ┌──────────────────────────┐
    │ perform a directory walk │
┌───► with each "dive" opened  │
│   │ as a (green) thread      │
│   └─────────────┬────────────┘
│                 │
│   ┌─────────────▼─────────────────┐
│   │    determine if the           │
│   │    child path is a target     │
│   └────────┬───────────────────┬──┘
│            │                   │
│          false               true
│            │                   │
│            │  ┌────────────────▼──┐
│            │  │ generate a report │
│            │  │ with that path    │
│            │  └────────────────┬──┘
│            │                   │
│   ┌────────▼───────────────┐   │
│   │ create another (green) │   │
└───┤ thread with that path  │   │
    └────────────────────────┘   │
                                 │
               ┌─────────────────▼─────┐
               │ display that report   │
               │ immediately to STDOUT │
               └───────────────────────┘

That could result in incredibly fast execution, but you would run into a number of other problems:

Do we have to worry about a maximum number of threads?
What if certain display settings need to be context-aware and pad with whitespaces according to other reports?
Should we parallelize report generation, and keep directory walking sequential, if the latter is much less expensive than executing several libgit2 or git subcommand calls?

All of these questions were similar to those that arose during gfold 3.0.0 development.

The final architecture diagram contained more discrete parts; making each focus area a little more extendable. While they might not be co-joined, trading minor performance hits for extensibility was well worth it in the final design. Overall, the goal was to strike a balance between being a fast, glorified script runner and being a slower, complex application.

New Features

Aside from the design philosophy change and overall refactor, there are a number of new features. They include, but are not limited to, the following:

Ability to store options in an optional config file
- Ability to ignore the config file and only use CLI options
- Ability to merge CLI options with config file options (default behavior if config file exists)
Brand new display mode
- This is the new default display mode
- The old display mode is available via a flag and can be used by default if set in the config file
- Primary motivation for the display mode change was to minimize line length (classic display mode can result in very long lines)
- Repositories are not grouped by parent directory, unlike the classic display mode
Ability to print merged config options (CLI options + config file options)
- Since the config is printed as valid JSON, you can direct the output in your config file (e.g. gfold --classic ~/src --print > gfold.json)
Ability to specify path to git
- By default, gfold tries to find git in your PATH, but you provide another git binary by its path
- Since version 2.0.0, libgit2 is not used in order to reduce binary size, minimize divergent behavior, reduce attack surface, and remove a redundant dependency (i.e. you likely have git installed if you are using gfold)
Ability to store default path target in config file
- By default, the the target is (and has been) the current working directory
- If you'd like to target the same directory from anywhere, you can provide it in the config file

There have been numerous performance improvements, a new CLI parsing structure, and other smaller changes, but the above features encompass the end user goals for this release.

Closing

Thank you for reading and enjoy gfold 3!

A special thank you to those who have helped along the way:

@jrcichra for adding multi-OS support to the very early CI pipeline
@orhun for adding gfold to the AUR, which caused a significant increase in users
@wezm for including gfold in the "One Hundred Rust Binaries" series, which caused a significant increase in users
@yaahc for helping with a very early refactor through Awesome Rust Mentors

Launching Rust Cloud Native

Tue, 03 Aug 2021 00:00:00 GMT

Update (25 Jul 2022): Converting Rust Cloud Native

Today, we launch a new GitHub organization, Rust Cloud Native.

This organization exists to enable the usage of Rust in the "cloud", which focuses on infrastructure software and related components.

You may be familiar with "cloud" technologies, such as Docker and Kubernetes. Our organization exists to promote projects that exist within the same technology sector.

Admittedly, the frequent usage of "cloud" and "cloud native" at large can induce eyerolls. However, we felt that the actual definition of cloud native computing defined our organization's focus area nicely:

"Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach."

CNCF Cloud Native Definition v1.0

Taking inspiration from Rust Embedded and the definition above, we decided on the name: Rust Cloud Native.

An Update to this Post

Based on discussions throughout various tech communities, I wanted to clarify my intent with this post: this announcement is largely symbolic. The substance is minimal because this is a "call to arms" more than anything. Since there is currently not a central location for cloud native Rust anything, I mainly just wanted to start something.

With that being said, there has been some great feedback thus far that I want to address:

Who are the members?

I can see how the exchange of "I" and "we" throughout this post can be confusing. I talked to several folks about how to start this, including the organization members, so I did not want to claim sole ownership of ideas. However, the bootstrapping of the repositories was done by me.

Why the minimal scope?

This organization was created entirely with volunteer time, and would ideally not have its course determined from a BDFL (me, in this case). If people want a Discord server, Zoom meetups, events hosted, etc., we will do that. I do not want to burn out by creating a bunch of low quality community locations prematurely.

Why create the GitHub organization first?

The reason why the GitHub organization was created/announced before anything else was because of a tweet. I originally tweeted that I created the organization, and wanted to see if people were interested in using it (regardless of ownership). It unexpectedly blew up, and with encouragement from replies/DMs, I decided to add least plant a flag to brute force the "chicken or the egg" problem.

This might not have been the ideal approach, but with few volunteer hours, my objective was to at least start the conversation with some ground rules and goal(s).

Next Steps

These intentions could have be articulated more clearly in the first publication, so I've added this section to do so now. I'll reiterate: thank you all for the great feedback.

(original post continues below)

Mission

We are focused on strictly one goal: enabling the usage of Rust in the "cloud".

In the future, our organization may formalize a secondary goal to create an official Rust working group. For now, we are focused on our aforementioned goal with the intent to provide a home for folks interested in cloud native Rust.

History

You might have seen the GitHub organization pushing commits, creating issues, and polishing things up since late spring, but the idea began as a natural evolution of events prior. I began writing Rust in mid-2019, as a break from Go at work and a return to lower-level language fun from university. Between then and now, I have seen projects and initiatives related to cloud native Rust greatly expand:

Concurrent to these events, back channel conversations, threads on forums, threads on social media, and community content were also propelling many folks to the idea. Those back channel conversations always ended with "no, someone should actually do this."

Approach

It's taken a relatively long time to launch, and it's important to discuss why. Technical obstacles and content generation were not the reasons. The primary reason was the approach: we needed a GitHub organization that is safe and welcoming while leaving direction and organic growth entirely up to the community.

First and foremost, any and all spaces related to Rust Cloud Native will enforce the Rust Programming Language's Code of Conduct.

Violations of the Code can (eventually or instantly) result in a block from the organization's public repositories.
If Code violations occur "off-site", stemming from our GitHub organization's spaces, Rust Cloud Native members will inform adjacent community leaders of misconduct and refer to the above point for action.

As far as leadership goes, our organization contains very few members at this point. While we are still ideating on processes related to membership, such as the Rust Embedded WG's RFC 0136, we do not plan to significantly extend membership at this time.

At the moment, our scope is relatively small: maintain existing repositories and listen to the community's desires and new ideas. Thus, we do not want to misuse volunteer time by prematurely and rapidly expanding organizational membership.

I do see a future where frequent contributors eventually become organizational members. Regardless, we must consider the following: will the organization exist to maintain the same repositories, or will the organization begin to host projects and events? The answer to that that question dictates our membership goals.

I will admit that the initial members are folks whom I have worked with or met online. I am personally weary about accidentally creating a clique, so if we ever need to rapidly expand membership, we will focus on doing it the right way.

This section is arguably the most important, but since you are likely here to not read my rambles and tangents (or are you?), I'll be clear in our intent: given our small scope and structure, it's our hope that we will cultivate a safe and welcoming community that ultimately dictates the course of this organization.

Launch

Our "launch" refers to our readiness to promote the organization and its contents, and is mostly symbolic. All of our repositories were publicly available before this was written. With that being said, we are "launching" with one repository and may expand in the future. The repository, rust-cloud-native.github.io contains the following:

website: the website showcasing projects and resources about cloud native Rust as well as information on the organization itself
core/meta: charters, goals, processes, "meta" considerations, etc.
logo: the logo and its related files

You may notice that there isn't an "awesome" repository or a hosted technical project, such as rust-embedded/cross.

I do not frequently reference Rust Embedded by accident. We are proud to model a significant percentage of our organizational makeup off of their's.

Since our organization is run entirely by volunteers in their spare time, it's designed to act as launchpad into the greater cloud native Rust community. You can think of this organization as maintainers of a single website, a logo, and itself... at least, at the time of writing.

End

As mentioned above, this organization is the launchpad and not the destination. I can see our organization enabling the creation of a working group, partnering with companies and organizations, hosting events, etc. I can also see our organization continuing to maintain our current repository for a happy, close-knit community.

We want to do what you want to do. We hope to see your creative projects, books, podcasts, livestreams, talks, shows, events, repositories, art, games, and more. This is the start to your community, and we cannot wait to take feedback on making it a safe, fun, and informative place for navigating the world of cloud native Rust.

As always, please do not hesitate to reach out.

Do Not Rewrite Your Bash Script In Another Programming Language

Mon, 05 Apr 2021 00:00:00 GMT

Alright. We're starting off with a fiery blog post title. Let's do this.

One of my biggest pieces of technical advice to new software engineers is to not write something in another language that could be written in Bash.

By "Bash", I mean Bash, Zsh, PowerShell, Fish, Nushell, etc. Saying "shell" might not immediately register with some folks, and might even be an incorrect generalization since, colloquially, "shell" widely differs in definition.

There are two exceptions to this piece of advice:

Multi-platform support: even if you require external command execution, choosing one programming language can still be preferred for multi-platform usage and maintenance.
No external commands: even if your program is written in a Bash-script-like format, having advanced error handling, great runtime performance, and no PATH dependencies can advantageous.

My most popular GitHub repository, gfold, was intended to be a small application to help me learn Rust. It does many of the same things that the git CLI can do, but I still attempted to ensure that it satisfied the above two exceptions.

Fun fact: gfold started in a private repository in the second half of 2019. It was never intended to be maintained, but here we are!

With that being said, I'm writing this post because I still run into the Bash-rewrite trap.

Let's go back in time a bit. I was (read: probably still am) a huge Linux fanboy in high school and college. Surfing my favorite subreddits, I was enamored with the beautiful terminals, desktop environments, and TUIs that people created and curated on Linux.

I wanted to help these communities in some fashion, but I did not have any unique, helpful ideas for new software at the time. Thus, I defaulted to wrapping my favorite CLI applications from Reddit with Python and Go code. Most of these programs were related to networking and system monitoring, and my programs did not fundamentally bring "new tech" to the user.

I'm telling you this to save yourself: do not be me, unless you are doing it for fun, or for programming exercise. Documentation changes, unique blog posts, community involvement, etc. are much more important than writing the type of software that I did. Arguably, even writing nonsensical software that does not execute external commands would still have been more useful (though, that's arguable). Yet... I had fun writing some "useless" software. Programming is fun!

After an internship, higher-level undergraduate courses, and some industry experience, I began to write software that I believed was fundamentally "my own". I'm not claiming that my early projects provided useful code to the world, but I believe that they were a step in the right direction.

Fast forward to this past weekend: I was writing a new Rust CLI application for personal use when working with Kubernetes clusters, and realized that I needed the Helm API.

Before we continue, I understand that this would have been easier to write in Go (though I adore kube-rs). My personal projects do not always make sense and often exist as programming exercises.

I could generate a helm crate with its proto files, similar to the crate already available, but this felt a little extreme for such a small CLI program. Thus, I wrote a concise helm external command library that handled various failure scenarios and wrapped the subcommands I needed.

The allure of downloading files with asynchronous code and programmatically handling edge cases was immense, but it was so immense that I did not realize that I was misusing my time. It was only after that I had the program working that the realization kicked in. If had not be using any external commands, then it may have never kicked in. Regardless, the following questions began to flow in:

What was this CLI application solving that my Bash scripts with set -ex couldn't already do?
Would my kube-rs + reqwest implementation truly surpass what kubectl create -f could do when I was going to be using other external commands anyway?
Even if I did not need to execute any external commands, was this software fundamentally worth writing?
Were the speed and reliability increases substantial enough to warrant writing a new program?

The answers to these questions were what you might expect:

No, but it did some things a little bit better.
Yes, but not in a substantial manner since I was already going to be calling helm externally.
Potentially, but that is a hypothetical question.
If there were no external commands, then maybe?

I decided that writing a Bash script was a better use of my time. However, I still had some internal conflict over the matter. As I said earlier, "I still run into the Bash-rewrite trap".

This trap is so pervasive because it can be easily forgetten when paired with a strong desire to write performant, useful, and reliable software that has multi-platform support (when possible). Bash scripts can be prone to human error and sometimes do not provide any of the aforementioned benefits. However, re-writing anything without provable, substantial advantages over the original implementation is usually a bad idea.

Thus, I have stuck to the following mantra: do not write software that could be written in Bash unless you need multi-platform support, or you are not executing any external commands. Obviously, the real world is messy and there's much more nuance to deciding the right tool for the job, but this mantra has generally helped me make better use of my time.

Well... it has "generally" helped me. We are here, writing this post, aren't we?

There's Nothing Like Local Development

Tue, 09 Mar 2021 00:00:00 GMT

I spent the last two months switching between hundreds of remote development environments so you don't have to. Well... okay, maybe not hundreds, but it sure felt like it.

Days of long compilation times, seemingly-frequent battery drain, loud fan noise, and inconsistencies between local and production OSes led me to solve my problems with laptop-based development. Some solutions took the form of a compromise: headless NixOS VMs, full-GUI Fedora Workstation VMs, etc. Other solutions were uncompromising: a physical remote workstation built with PC parts, a shared remote system with multiple laptops, etc.

However, reflecting on these last two months, these "solutions" were a waste of time (kinda, sorta). Washing away my worries with laptop-based development revealed large flaws with remote-based development that I did not take into account before my journey. Without beating myself up too much, I did try to anticipate pitfalls with my new development workflows. In fact, I anticipated enough pitfalls that this blog post would have been titled "I'm Done With Laptops" a month ago. It was that close.

So... why the sudden change? That's a drastic transition from "#@$% Laptops" to "There's Nothing Like Local Development".

Spoiler alert: It's complicated.

Remotely Similar Definitions

I'd like to help us both get through this blog post, so let's modify some established definitions to make this journey as smooth as possible. These definitions are only valid within this blog post. You can think of them like pre-pending your Bash and Zsh variables with local, or defining a variable within a scope, or... uh... just ignore me, actually.

"Remote" development refers to not only actual remote development environments, such as physical servers and cloud-based VMs, but also to internal development environments that reside on/above the host OS.
- For instance, WSL2 can feel like a native development environment, but the architecture leverages a minimal VM, and a lot of networking tricks, to make it feel like one (e.g. accessing a WSL2-based webserver via localhost in your Windows 10 browser without manual configuration).
- WSL2 would count as a "remote" development environment with this definition.
"Native" or "local" development refers to writing software directly on the host OS, or running a VM on something like Proxmox or ESXi.
- The reason why VMs on Proxmox, ESXi, etc. get a pass over WSL2 VMs is because they are the lowest level OS for feasible/realistic daily development. With WSL2, you have the option to develop natively on Windows 10.
- Although, using a Proxmox or ESXi VM from another system counts as "remote development". I never promised this would make sense.

I wanted to be internally consistent when evaluating remote versus local development environments, so these definitions helped me decide what makes me happiest and most productive.

TLDR: if I can open a laptop lid (or boot a desktop with a monitor), open my editor/IDE and web browser, and get straight to work without any further configuration, it is probably a local development environment. If I have to mount a filesystem, use SSH, change networking options, or download a remote extension for my editor/IDE, it is probably a remote development environment.

Virtual Machines: The "Remote" Software Approach

I use a variety of development environments for my personal workflow/setup, so we are going to focus solely on the professional side of things. These environments needed to facilitate writing and building containerized services in Go, and deploying those services to a local Kubernetes cluster via Helm. That's a fairly low barrier to entry, especially since nearly all of my work is spent in userspace, Go programs are statically compiled, and that using k3s and k3d makes local cluster management easy.

This journey started when I wanted to revisit dedicated, headless, development Linux VMs on macOS desktops. That desire arose from the following thoughts...

"Using Docker in a Linux VM would be better than using Docker Desktop."
"I miss using Linux for daily work."
"I will be able to use systemd for deploying k3s, use kernel-specific libraries and services, and work closer to where Rancher apps will actually live in production."

Yes, these thoughts were only tangentially related to my local development frustrations, but I thought using a Linux VM may indirectly solve at least some problems.

I had NixOS on my list of Linux distributions to try for nearly a year, and with @theprincessxena's, @mitchellh's, and @dave_universetf's recommendations, I began to use NixOS in my daily workflow.

Actually, using a NixOS VM was arguably my most successful "remote" development environment. The reproducible builds are very important when using NixOS Unstable for the latest packages, even though I never encountered a single breakage. Other than Fedora Silverblue, I had never felt more confident in using a Linux distribution. The stability and consistency are addicting.

What about Nix directly on macOS?

Before using NixOS, I tried Nix with home-manager on macOS. This setup was very effective, and it rivaled using homebrew with a manual dotfiles setup. However, Nix creates a new APFS volume called Nix Store, which can be undesirable if you only intend to use Nix in a limited capacity. It would be incorrect to call Nix "invasive", but it is definitely "involved" since it requires more setup than a traditional package manager. Thus, I recommend trying Nix with home-manager in a VM, Linux or macOS, before using Nix directly on your desktop.

Sounds great, right? Yes, but I never realized how integral FHS-compliance was to my daily workflow. Sure, there were issues when using the Visual Studio Code Remote Extension...

% strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
strings: '/usr/lib64/libstdc++.so.6': No such file

...but these can be remedied by mounting ("sharing") the guest OS's filesystem with the host OS.

The bigger problems arose when varying projects and applications relied on PATH to function properly.

Please, let's discuss alternatives to the PATH concept at a different time. I can hear you ~~cheering~~ screaming!

Bottom line: I needed to be able to clone project repositories with minimal tweaking to get make targets to work. You might find this ironic, given the length of this post, but I decided that configuring symlinks, generating FHS-compliant configurations for NixOS, etc. would be too time-consuming for my daily development workflow.

It's worth noting that I adored NixOS for rapid teardown/setup environments and production deployments. Definitely going to keep an eye on the NixOS community and project moving forward.

After NixOS, I tried some old favorites again in a VM: Arch, Ubuntu, openSUSE Tumbleweed and, of course, Fedora. From what I recall, Arch had the most usage due its fast package manager, rolling release model, and that one of my projects was (and still is) in the AUR (thanks @orhunp_).

Before we continue into distro madness, I'll remind myself that this post is not about Linux distributions. It's about why "There's Nothing Like Local Development".

I am also pretty tired of talking about Linux distros, and would much rather talk about other things. Yeah... apologies, folks. It's not you, and it's not me either.

*glares in r/unixporn*

However, NixOS was worth diving into because the reproducible builds are very unique in comparison to macOS and many other Linux distributions. Yet, the uniqueness ends there. My experiences with the headless NixOS VM shared many similarities to headless VMs running my "old favorites". The guest VM approach exacerbated battery drain, fan noise, and compile-time issues on the laptop, regardless of the distribution. Running the virtual machine, alongside all the tooling and extensions required to interact with the guest VM from the host OS, was not an ideal solution to my problems.

Moreover, revisiting the "old favorites" reminded me that non-headless VMs (e.g. full-GUI, even with only a window manager) were not preferable. While full-GUI VMs solve some issues encountered with headless VMs, they exacerbate my frustrations with local laptop development on the laptop even further. Not to mention, there were drawbacks unique to this approach: hindered font rendering, using multiple web browsers (host and guest), and general resource wastefulness from running a full-GUI.

At this point, I had realized that the benefits of using a Linux VM did not justify including it in my daily workflow. There was no tangible benefit to having a "remote" Linux VM directly running on my host OS. If I needed a real Linux kernel, I could use "hypervisors as a service", like Vagrant, VirtualBox, Hypervisor frontends, etc. at a moment's notice.

In fact, using desktop Linux would even further defeat the purpose of a "pet" Linux VM for full-time development. As a reminder, this Linux VM workflow experiment was conducted with a company-provided MacBook Pro.

Then it hit me: what if I could get the benefits of a dedicated, development, headless Linux environment while eliminating the detriments of using a laptop for development? What if there was a separate box that I could access via SSH, VNC, and Cockpit? Folks, I might as well have discovered fire because it was time to build a remote development workstation.

Workstations: The "Remote" Hardware Approach

The parts arrived days later. With a Noctua CPU cooler in hand, it was time to benchmark ridiculously fast compilation times while generating noise in an entirely different room of my apartment. After weighing a few Linux distributions, I installed Fedora Server on the newly built system and got moving.

Side Story on Ethernet Drivers

There was an issue with the 2.5G Realtek ethernet port on my Z490 motherboard. This was patched in Linux 5.9, but the Fedora Server 33 ISO came with kernel 5.8. Yes, there were many reasonable ways to fix this, but I used my Pixel 4's USB-C tethering to deliver an internet connection to the system because it made me laugh. After a dnf upgrade --refresh and sudo reboot, the system successfully connected to the internet over ethernet with a 5.10 kernel. Got to love Linux.

Much like the NixOS VM, this development approach seemed perfect at first. I could use a VPN to access my home network, and access my remote workstation easily. The compilation times were that fast, and my laptop became much quieter than ever before.

Why not use a cloud provider and let them handle the hardware?

Something like a DigitalOcean Droplet or an Amazon EC2 instance would be enticing, but the recurring cost of a moderately powerful VM would be too high for daily development. I use VMs from cloud providers for persistent services, different platforms when I need them, and for ease of use during development. Requesting and decommissioning cloud VMs, depending on project, time of day, and time of year is much more cost-efficient than reserving a powerful VM persistently. Moreover, reduced compilation times are an unnecessarily expensive goal in the cloud when you have a moderately powerful laptop.

However, the issues began to reveal themselves over time. Managing a remote system alongside your laptop increases your sysadmin workload by 100% (which is also true for the aforementioned guest VM approach). Yes, an upgrade + reboot with your favorite package manager was all you usually need to do, but networking is where things got tricky. Managing SSH keys was easy, but wrangling firewalld and setting up automation on my MacBook Pro proved to be doable -- albeit time-consuming.

"I just want to generate and look at these docs using localhost and Hugo".

"Oh no big deal. Just use ngrok, change this SELinux policy, ensure that CSS is being forwarded from localhost, and you are good to go! Also, don't forget to stop your docs webserver or ngrok service. If you're not using SELinux, you have even less work! You now only have to worry about your system's firewall settings, latency between systems, and-"

"Or... I could just execute make run on my laptop..."

"Yeah... or that."

The issues with my remote workstation were never matters of ability, but matters of feasibility. It was never the case that using k3d via SSH was meaningfully different than using it on my laptop's host OS. Networking edge cases when using the remote system became more apparent when actual "remote" hardware came into the mix, rather than just using a guest VM on the laptop.

Speaking of which, neovim and tmux only took me so far, and GoLand's remote extension proved to be useful, but not as useful as using a local filesystem. Thus, it was time to try macFUSE with SSHFS to mount the remote filesystem for development.

I stepped back and paused... this a lot of effort to work with a remote system. I reminded myself: battery drain, long compilation times, and fan noise were my primary drivers for this journey. I was still determined, but it was time to think about this physical server-like approach differently: what if I only used VNC, RDP, XRDP, or NoMachine and avoided networking issues altogether?

LOL... that didn't work either. I not only tried some of my favorite Linux desktop distributions; I even tried Windows 10 Pro with WSL2 over RDP. The problem is that while the laptop was quieter and ran smoother than ever, the visual degradation and network latency were severe with a remote desktop environment. Native, local performance is unbeatable for GUI applications, full stop. Over SSH, the threshold for manageable lag is much higher than over protocols like VNC. The latency would be passable in a pinch, but not for 40 hours per week. Thus, pushing a full-desktop environment remotely quickly became unappealing.

Why not use the workstation locally?

This is a reasonable question. For some full-time, self-employed "open-sourcers", this might be the right approach to daily development. For me, I only wish to sign into company services and applications from the company-provided laptop. I would rather take one laptop over one workstation in this context.

If these compounding issues were not enough, the environmental impact of this setup began to become more and more apparent. Would I have to keep this system on 24/7 when traveling? What if there was an outage? Is this a waste of hardware given how infrequently I actually compile and run my code? Of course, the power usage would be minimal with average US electricity prices, but I began to view this remote workstation as "wasteful", nonetheless.

Alright, well, what about going back to VMs? Virtual machine platforms provide directory sharing with the host, port forwarding via NAT, and other solutions that make "remote" work easier. However, I am still managing another system in a full-time capacity with this approach. Even though guest VMs strike a compromise between truly remote systems and native/local environments, setup and maintenance are still required for daily use -- even if the impact is minimal.

It was at this point that I realized that, over two months, I spent too much free time tweaking/trying these setups on weeknights and weekends. The intention was to write code. The intention was to clone and test open source projects. The intention was to spend time on developer productivity and happiness.

Well, I lost the plot. I learned a lot, but admitted to myself that this experiment was a failure. That's okay! I was fine with that admission, yet... I needed to figure out what happened. Where did the original intentions slip?

Local Development Happiness

Let's step back and look at my primary issues with local development on a laptop:

Long compilation times
Fan noise
Battery drain
Inconsistencies between host OS and production OS

You might have noticed something throughout this post: I did not include the frequency at which I hit these issues anywhere.

How often do I actually compile code?
How often do the fans actually get loud? (without the snarky answers for specific applications)
How often does battery drain actually matter at a desk or table with a power outlet nearby?
How practical is it to match your local OS with the OS your services use in production, and how often am I using kernel-specific features?

My answers to these questions included the phrases: "not often", "not practical", and "not realistic". Granted, these are absolutely valid complaints for local development on a laptop. Every one of my solutions tried to answer at least one of these questions, if not all of them sometimes.

A note on matching local and production OSes

When I say "inconsistencies between local and production OSes", I do not explicitly mean writing Linux-specific software on a non-Linux desktop OS. Runtime testing is important, but it is entirely valid to cross-compile when possible and create VMs on the fly, depending on the use case.

I firmly believe that choosing a host OS should be based on productivity and happiness rather than architectural proximity to your production environment. If your productivity and happiness are derived from using an Ubuntu Desktop for developing apps that are deployed on Ubuntu Server, that is entirely valid. There is a measure benefit in matching both environments. On the other hand, unless development is platform-locked, like iOS application development, choosing your desktop OS does not have to be driven by your production environment.

Things I took for granted with local development became apparent over the past two months. My dotfiles, editor, IDE, browser, and command-line apps all live on my laptop now -- just like before this experiment began. I love having everything in one place.

I took native desktop and CLI applications for granted. Docker Desktop may demand a lot from my host system, but the ability to execute docker run and k3d cluster create, and to access everything I need to on localhost without any additional configuration, is an experience that "remote" development cannot match for me.

Of course, I still need create S3 buckets and EC2 instances in the cloud, but they are only extensions of my daily development workflow. These things are nothing that rke or terraform cannot solve.

Regardless, I had to remind myself that the majority of developers use Windows 10 and, most likely, only have access to one device: a laptop. I was hyper-optimizing a development workflow that is simply an impossibility for many folks in the world to access. Even at 45W or 15W, a new Core i5/i7/i9, Ryzen 5/7/9, or M1 processor will absolutely excel for the vast majority of software development. When you do need that heavy lifting, the local workstation or cloud provider service can suffice, but how often do most developers need that muscle?

The battery will drain, the fans will spin, and the compile times will be "long" (read: not really), but the ease of use and accessibility will be front and center for local development, which are essential to the software development experience. At the end of the day, maximizing my time writing code, collaborating with co-workers, blogging, and researching new projects, and minimizing my time managing my system and "solving" lower priority issues are what make me happy and productive.

For all of these reasons, I returned to local development with my company-provided MacBook Pro. It's what I continue to use now, during the workday. My local development preference remains the same, regardless of the OS. If the company-provided laptop becomes a System76 Lemur Pro or a Microsoft Surface Laptop 3, I'll still be focused on writing code directly on the host OS of the physical device.

This post is a self-reflection in developer priority management and identifying pitfalls when optimizing my workflow. However, I'm also not going to dunk on myself: the motivations behind the experiment were clear and well-founded. I want to do the best work I can, as efficiently as I can, and with as much developer happiness as possible.

This was a learning experience, and it's one that I'm happy with its conclusion. I hope that my experiences, self-owns, and ramblings helped convey my message: "There's Nothing Like Local Development".

How I Read "The Rust Programming Language"

Wed, 19 Aug 2020 00:00:00 GMT

With RustConf 2020 coming tomorrow, I want to tell folks about how I have been "re-reading" The Rust Programming Language. Affectionately known as "The Book", this resource is the ultimate guide on how to get started with the Rust programming language. You can buy it at almost any storefront, or view it online for free.

This post is aimed primarily at Rust beginners, and people who want to develop a deeper understanding of the language. Much like studying for exams, there are efficient ways to use your time, and uh... inefficient ways (read: playing Destiny 2)... to use your time.

Everyone has their own learning preferences and requirements, but I'd like to share a method that worked for me. It's my hope that it may work for other folks reading this as well.

But first, let's talk about why I am bothering with this. The resulting perspective may provide some insight into why I chose this method, and how you may relate to that experience.

Motivation

After an "okay-ish" first pass (nearly a year ago), I tried editing, compiling, and using different projects throughout the ecosystem. My goal was to use trivial, Rust-based, software on a daily basis before I dove deeper.

I eventually created a gfold, a small, command-line application, as my first public foray into Rust. I polished the pet project, and proceeded to check out, edit, and compile, several well-known projects afterwards. Everything was rolling smoothly early on.

Well, months later, I wanted to shift my focus towards larger, non-trivial projects. I decided to double down and try (read: faceplant) to become an intermediate, or expert, user of the language.

Even though I primarily work in userspace, the promise of a non-garbage collected language, without the pitfalls of traditional memory management, is vital to my interests. As cloud-native circles look into edge compute, and IoT, I believe that Rust is already beginning to play a major role in their ecosystems.

The language's community is also incredible. The amount of mentors, Discord groups, and people supporting each other is... yeah, incredible. I hope that future tech circles use this community as a blueprint going forward.

For all of those reasons and more, I decided to return to "The Book" to internalize the fundamentals of the language.

The Method

This strategy revolves around writing a crate (code that can be compiled into a binary, or library, in Rust) for every section of every chapter. While this might seem as rudimentary as writing some Bash and Make code, I actually leverage Cargo, Rust's package manager, for the entire repository.

The goal is to have as little friction as possible between writing down notes/code, and reading the book. Even in a world of beautiful tablets and stylus/pencil devices, many opt for pencil and paper. Whether its for muscle memory, force of habit, accessibility, or just to get eyes off the screen, there are undeniable benefits to pencil and paper that technology has not (and may never) be able to implement.

To reduce friction as much as possible, I opted to write (type) down my chapter notes as comments within the "section crates" themselves. This system allows me to co-locate my notes with my Rust code, and learn a bit extra about Cargo along the way. It also keeps me on the keyboard, either writing code or taking notes in the same files.

That's enough theory-crafting though. Time to get started!

1. Setting Up The Repository

You can use the version control system of your choice, but for those looking for guidance, I recommend using the following resources...

GitHub offers unlimited, free, private repositories for individual users. Since you most likely do not want to "learn out loud" with a public repository, toggling this feature is key.

For those new to the Git CLI, GitHub Desktop is a nice GUI for smaller, solo projects, like ours. While I recommend learning the CLI, I wanted to add an accessible option that folks have enjoyed using in the past.

Finally, if we are using Git, we have to make sure that we do not commit unwanted files. Create a file named .gitignore at the base of your repository, and write the following to it...

# Generated by Cargo. These sub-directories will contain compiled files and executables.
**/debug/
**/target/

# More information on Cargo.lock: https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html
**/Cargo.lock

# These are backup files generated by rustfmt.
**/*.rs.bk

You may notice that this is nearly identical to GitHub's default Rust .gitignore file. That .gitignore file is great for a single crate repository. However, our file contains a few modifications to work with our repository.

The **/debug/ and **/target/ directories contain our executables and related artifacts, while the Cargo.lock file contains the exact information about our crate's dependencies. Since we are building many sub-crates, we need to make sure that our generated artifacts do not get committed. We solve this by prepending the double-asterisk string, and... we are done (so far).

2. Setting Up Your Editor

With that file created, and the repository set up, let's catch ourselves a break in advance, and set up our favorite editor for success. I recommend setting up the following...

Rust Analyzer
A TOML file plug-in or extension

Rust Analyzer is an incredibly good compiler frontend for the language. It provides best-in-class support for writing Rust code in your preferred editor. While I use it with Neovim, you can use it with most popular editors, and IDEs. For folks without a favorite, I recommend VS Code.

Support for TOML does not come by default in all editors. Since we use the format frequently with Cargo.toml, I recommend installing a reputable plug-in, or extension, when working with Rust. I prefer to use vim-toml (also, with Neovim).

3. The Virtual Manifest

This is where we begin to learn a little bit about Cargo before even reading "The Book". Let's take a look at the following excerpt from the Cargo documentation:

"Alternatively, a Cargo.toml file can be created with a [workspace] section but without a [package] section. This is called a virtual manifest. This is typically useful when there isn't a "primary" package, or you want to keep all the packages organized in separate directories."

Cargo documentation

While Cargo.toml files are typically used for simple dependency management in your single crate repositories, they can do so much more. For our use case, we need to have a "meta" Cargo.toml file to manage our sub-crates in a workspace. Specifically, we need a "virtual manifest", as mentioned above.

"What does this do for us?" Glad you asked.

cargo fmt
cargo build --verbose

Running the above commands in the base of this repository will format, and compile, the code of every sub-crate in one fell swoop. For your first sub-crates, I recommend using Cargo (and rustc) as "The Book" intends, but after the early tutorials, you can switch to using the virtual manifest.

Before we continue, we have to edit our Cargo.toml to find all of our sub-crates in the repository. Create the file, and write the following to it...

[workspace]
members = [
    "ch*/*"
]

Non-beginners: do not accidentally include "package", as we need this to be virtual manifest.

I've already given away the naming pattern, but the key here is that we want to keep a consistent scheme. We don't necessarily need to, but we do this so that we do not have to edit this file again.

4. Creating Sub-Crates

This section is a little more straightforward. Our naming scheme, hinted at in the virtual manifest, leads Cargo to look for all base directories beginning with ch, and target all crates within those directories. For this to work, we need to make sure that our sub-crates maintain the same scheme.

Cargo offers a sub-command that scaffolds a crate for the user. A crate can either be compiled to a binary (default), or a library, specified by the --lib flag. Ultimately, the choice will depend on the specific section's requirements, and code block examples.

mkdir ch01-name
cd ch01-name
cargo new ch01-s01-section-one-name
cargo new --lib ch01-s02-section-two-name

The above Bash commands can be translated to your preferred GUI workflow.

mkdir : creates a new directory (folder), which stores all sub-crates for a specific chapter.
cd : changes the current working directory (current folder) to make sure that we create our sub-crates in the right place.

Now, within every sub-crate, we can take notes within our new .rs files, and our Cargo.toml file. It's all co-located, and compilable from one location. Pretty cool!

5. Keeping a boilerplate.txt File

Nothing here is dangerous, but misusing a boilerplate.txt file can lead to bad programming practices, and code hygiene. I am going to be 100% clear: do not use the following macros without knowing what they do, and why they exist.

"Whoa, what's a macro? Why are you telling me all this?" Do not worry! "The Book" will teach you all about macros, give some examples, and recommend some best practices. For now, I'll give some examples of macros to (not hastily) paste at the top of our .rs files.

Here's the thing: many sections will often reuse variables, or not use those variables at all after showing them in the code block examples. It can be annoying to have clogged STDOUT from compiler warnings when you are trying to follow these examples. This is to no fault of the book authors (love you Carol, Steve, and all other contributors!). We leverage it as housekeeping that comes along with using our learning methodology. Essentially, our goal is to minimize compiler warning clutter when we purposefully want to ignore warnings.

As I mentioned earlier in this post, the key to this method is minimize friction when taking notes and learning. Therefore, I recommend keeping a boilerplate.txt file handy, which should contain useful macros for de-cluttering your STDOUT. Here are some examples...

#![allow(dead_code)]
#![allow(unused_imports)]  
#![allow(unused_variables)]  
#![allow(unused_assignments)]

I strongly recommend encountering frequent warning clutter first before using these macros. All of my warnings aside, I get a lot of use out of my pet boilerplate.txt at the base of my repository. It works well, and keeps me moving from section to section.

6. Continuous Integration (Bonus)

With our learning environment ready to go, you might have noticed that this project can be cleanly translated into your favorite CI system. This step is optional, but for those familiar with GitHub Actions, Travis CI, CircleCI, etc., it might be worth implementing here.

This code is not continuously deployed, nor is it (most likely) in use by anyone other than you. I believe that you can forgo using a CI pipeline here, and save on the compute cost. However, I still wanted to mention the option.

Read On!

I hope that this method works for (at least some) newcomers and aspiring intermediate/expert users alike. Please let me know what you think, and how this method works out for you!

I'm looking forward to all the new friends joining the Rust community in the time following RustConf 2020. Have fun reading The Rust Programming Language, whether it's for the first or one hundredth time, and catch you at the conference!

Why I Use Fedora

Fri, 22 May 2020 00:00:00 GMT

Let's talk about why I use Fedora... among many other Linux distributions.

Cue the dramatic music and dim lights: it's October 2018.

the 28th: IBM to Acquire Red Hat.
the 30th: Announcing the Release of Fedora 29.

Busy week, huh? Ironically, it was the week that I began to use Fedora Workstation for the first time (in earnest). I chose Fedora that week just because it was the "next one on the list"... and because of a headline that I'll go over later.

I've "distro hopped" for years before that. In fact, I still do. Yet, there's just something about Fedora that has kept it my rotation from Fedora 29 to Fedora 32, which recently released a few weeks ago.

Fedora is a community-driven, Red Hat sponsored, Linux desktop-oriented distribution. I've been driving it on at least one bare metal machine or VM (Workstation and Server) since Fedora 29, which equates to about a bit over a year and half of daily usage.

Honest feelings? I've generally loved my time with it.

In my opinion, transparent biases make for a better review of a product, service, application, etc. Knowing that a music reviewer prefers novelty over cultural influence, or that a laptop reviewer prefers keyboard quality to screen (panel) quality over thermal design, can provide a consistent and clear frame of reference to the reader or viewer.

However, I'm not formally reviewing my experience with Fedora 29, 30, 31, and (so far) 32. This is more of a reflection of what Fedora does for me that other Linux distributions do not.

For transparency's sake and quality assurance, I'll kick this off with the following: I value well-designed, high quality software before Free and Open Source Software (FOSS).

Blasphemy! Alright, fair. Let me explain: a substantial portion of my "well-designed, high quality" software of choice is FOSS. However, my aforementioned preference has been a primary driver in using a MacBook Pro throughout college, and running Windows 10 on my gaming PC.

That's not to say that open source and open standard technologies are not important to me. In fact, I believe that they will continue to displace proprietary solutions.

Kubernetes is one prominent example. The open standard ISA, RISC-V, and the open firmware platform, coreboot may be blueprints for the future. Open source software is getting better, and growing, quickly.

What's unique about Fedora to me compared to other Linux distributions is how it threads the needle while retaining a consistent vision and focus.

"Fedora Workstation is a polished, easy to use operating system for laptop and desktop computers, with a complete set of tools for developers and makers of all kinds." -getfedora.org

Under the leadership of Matthew Miller, the awesome teams behind Fedora, and its great community, this distribution has streamlined itself in recent years. Sure, the Fedora CoreOS project and Fedora Silverblue projects present unique opportunities, but they differentiate themselves by use cases, not desktop spins. (Although, you can choose different, unofficial desktop spins if you would like.)

I like my desktop to work out of the box. A singular, consistent vision for desktop design is very important to me. Of course, I've loved my time with window managers like i3 and Sway, as well as desktop environments like KDE and XFCE, but consistency and focus in a distribution are important for me.

Do my preferences dismiss distributions, like Arch Linux? No, actually. Arch's KISS design is prevalent and well-explained through its extensive wiki. Customization is part of its design. Thus, I really like using that distribution when it makes sense for me.

However, when using a laptop, my preferences become much more picky. I sway towards having extensive hardware support, enterprise presence in the upstream distribution (and/or packages), and a singular vision at the GUI-level. This generally leaves me with distributions like Ubuntu, Pop!_OS, and, of course, Fedora. I have great things to say about those distributions, but I have unique and specific reasons for using Fedora.

Ubuntu's Dash to Dock integration is welcoming to users of all kinds. Pop!_OS' Pop Shell is a power user's dream. I'm actually writing this from a system running Pop!_OS 20.04.

Yet... I admire the Fedora team's insistence on using vanilla GNOME.

Fedora 29 was the first Linux distribution where I felt like I didn't have to install GNOME Tweaks (Tweak Tool) in order to be comfortable with GNOME. I opened the settings, chose some preferences, and went to work.

From the Fedora team's close working relationship with the GNOME team, I have confidence that new releases of the desktop environment will integrate nicely with the distribution underneath. To be clear, I don't hold lesser confidence in other distributions in delivering quality releases, but the partnership between the Fedora team and the GNOME team gives me that much more confidence in my OS.

This vanilla nature extends to the rest of the operating system. The "Is Fedora For Me?" page highlights commitments to keeping upstream pure, providing sustainable updates, and upholding advancements in FOSS.

We will get to FOSS later, but let's talk about upstream and everyday usage.

TLP can often be a necessity for "Linux on the laptop" users. When the news broke that TLP was no longer needed for Fedora users, the distribution immediately caught my attention. Flicker-free boot shipped with Fedora 29. Your hardware's OEM logo flashed on the screen, just like Ubuntu 20.04 LTS does now.

I noticed the "quality of life" changes more and more as I used Fedora. Over time, I began to see them appear in other distributions. A lot of changes that eventually reach most distributions start with Fedora. Even between 6 month releases, updates occur frequently.

Well, wait... What about stability?

I've mentioned the partnership between the GNOME team and Fedora team above, and I think that trend extends into many other components of the distribution. Teamwork doesn't ensure quality, but it most definitely helps.

Red Hat sponsorship
Kernel contributors following Linus Torvalds' lead in using Fedora
Rapid systemd updates
Frequent kernel updates
A good balance between a completely static 6 month release-model, and a rolling release-model

A clear vision, good frameworks for teamwork, and a balanced release cycle are what make Fedora stand out amongst other distributions.

As far as my personal beliefs go, Ubuntu and Pop!_OS actually align more closely to them than Fedora does. If Nvidia's proprietary driver is well-designed and significantly better than the FOSS alternative, I'll use it. Would I prefer the open source alternative, if it was nearly as performant and consistent? Sure, but that is not always the case.

May folks reading this may feel strongly about FOSS, and I highly respect that. Fortunately, Fedora does as well. "Do you care about sustainable progress in software freedom and innovation?" This distribution does not ship with non-proprietary software.

Note: I'm unsure if there is an edge case, but AFAIK, it's FOSS-friendly for legal and idealistic reasons.

Personally, I use RPMFusion and install packages, like multimedia codecs, to get the "best" (subjective-ish) software I can. While the Fedora project holds FOSS as fundamental value, their documentation helps users interested in RPMFusion. This process is entirely optional too.

I'm just happy that I can enjoy a Fedora release alongside 100% FOSS-driven users.

I cannot cover everything, nor will I try to compare and contrast my experiences using Fedora to using other distributions. Trying to draw lines between your motivations and the software you use is... actually more difficult than you would think.

"Why do you use <tool>?"

"I dunno. My professor thought it was dope."

Maybe, I'll do a post on other distributions in the future. It depends on how much time my significant other and I play Animal Crossing together.

However, it's my hope that this post laid out why I use Fedora, and why you might as well. I recommend trying out every distribution in this post, but when in doubt... give Fedora a try!