DEV Community: VintageTechie

Building My System, Piece by Piece

VintageTechie — Mon, 09 Feb 2026 23:11:44 +0000

Building My System, Piece by Piece

In Still Skidding Broadside I wrote about spending 43 years using other people's tools and finally getting to build my own system in retirement. Here's how I layer CachyOS repos on vanilla Arch, why I run dual kernels, and what BTRFS snapshots have to do with staying sane on a rolling release.

Starting with Vanilla Arch

I started with vanilla Arch, not Manjaro or EndeavourOS or one of the "easy Arch" derivatives, just plain Arch. Throughout my career I've used a lot of systems other people configured, like Windows desktops across multiple companies, four years working on an AWS transition, company data centers before that. They all worked, most of them worked well, but I never really knew what was under the hood because someone else made those choices and I just lived with them.

Retirement meant I could finally build something from scratch, learn what actually matters and what's just noise, understand the pieces before I put them together. That said, I'm not a masochist, so I used archinstall to handle the setup. I picked manual partitioning and set up the BTRFS subvolumes myself based on what Arch recommends, giving myself a 24GB EFI partition because if I'm building this thing I might as well never worry about running out of boot space. Let archinstall set up Limine as the bootloader and get me to a working desktop. No shame in using good tools when the point isn't to prove I can do everything by hand but to understand what those pieces do and why they're structured that way.

The BTRFS layout has @ holding root with @home, @log, @pkg all separate, plus Limine as the bootloader which is simpler than GRUB with no auto-generation complexity, and linux-zen kernel which comes desktop-optimized from the start. Good bones to build on.

Layering CachyOS

Once I had a working base, I added the CachyOS repositories, which recompile Arch packages targeting x86-64-v3 and x86-64-v4 feature levels along with compiler optimizations including LTO, PGO, and BOLT. On my Ryzen 7 9800X3D the theory is you get 5-20% performance gains, though the reality turns out to be more nuanced than the benchmarks suggest.

I added them with their automated script, downloaded it and ran ./cachyos-repo.sh, which detected my CPU's instruction set and configured pacman in maybe two minutes. Did I see massive speed improvements in day-to-day use? Not really. Opening my browser, editing code, running pacman -Syu all feel the same as before.

But compiling Rust projects is where I notice the difference, not in raw speed numbers I never bothered measuring, but in the fact that I can keep working on other things without feeling any lag while a heavy build runs in the background. That's what actually matters when you're iterating through development cycles.

The performance claims aren't lies, they're just workload-dependent in ways the benchmarks don't always make clear. If you spend your day in a terminal and a browser, you probably won't notice much difference, but if you're compiling large codebases regularly, the gains can be real.

I kept the repos enabled because they don't hurt anything and occasionally they help, though if they caused problems I'd drop them without hesitation.

Running Two Kernels

I run two kernels on this system, linux-zen for daily work and linux-cachyos for gaming. linux-zen is Arch's desktop-optimized kernel with low-latency patches, the BFQ I/O scheduler, and CPU scheduling tweaks built specifically for interactive workloads, prioritizing responsiveness over raw throughput.

linux-cachyos uses the BORE scheduler, which stands for Burst-Oriented Response Enhancer and works by tracking how much CPU time a task burns before yielding, then adjusting priorities dynamically to keep interactive tasks responsive even when background processes are hammering the CPU.

In practice, Zen handles my normal workflow fine. Coding, browsing, watching videos all stay smooth without any issues. But when I'm gaming and running other stuff in the background like Discord and Steam, BORE handles the chaos better with no stuttering, no audio dropouts, and the game staying responsive while everything else keeps running.

Is it placebo? Maybe, though I've got the disk space for two kernels and switching between them in the Limine boot menu takes all of three seconds, so I keep both around. Installing a new kernel is automatic anyway thanks to the limine-mkinitcpio-hook, which updates the boot menu entries whenever pacman installs a kernel without any manual config file editing.

BTRFS Snapshots as Safety Net

Running a rolling release without snapshots is like walking a tightrope without a net, you can do it and lots of people do, but one bad update and you're rebuilding from scratch. I use Snapper with the archinstall default layout where the .snapshots subvolume lives inside @, not beside it like some guides recommend.

Some older guides will tell you this is wrong, that you need the OpenSUSE-style layout with .snapshots as a sibling to @ for proper rollbacks, but those guides are outdated now. With btrfs-assistant and limine-snapper-sync, the archinstall layout works perfectly fine for rollbacks without any manual intervention.

When I update the system, snap-pac creates automatic before and after snapshots that show up in the Limine boot menu if I ever need them. I tested the rollback process early on by installing KDE to try it out, hated it, opened btrfs-assistant while the system was running, selected the snapshot from before I installed KDE, clicked restore, rebooted, and I was back to where I started. Then I tried GNOME, found it boring, and rolled back the same way. The whole process takes maybe two minutes and works exactly like it should.

That's what good infrastructure does, it stays invisible until you need it, and then it just works without making you think about the mechanics.

Custom Subvolumes and Ramdisk

Beyond the base setup, I created custom BTRFS subvolumes on a separate 4TB drive for @code, @storage, @games, and @symlinks. I keep these separate because I don't want my Rust projects or Steam library included in root snapshots, they're large, they change constantly, and rolling them back makes no sense when snapshots are meant for the system, not user data.

The @symlinks subvolume holds directories I symlink into my home folder like Downloads, Documents, .ssh, and .gnupg for the same reason. These shouldn't be part of system snapshots, but I want them on BTRFS anyway for compression and data safety without the snapshot overhead.

For @code, @storage, and @games, I set the nodatacow attribute (chattr +C) because these directories have files that change frequently and don't benefit from BTRFS copy-on-write behavior. Database files, game assets, compiled binaries, they're better off without COW overhead.

I also set up a 12GB ramdisk mounted at /mnt/ramdisk for Cargo build targets and browser cache, because Rust compilation generates massive amounts of temporary files and browsers write cache constantly. Building on RAM instead of SSD reduces wear on the drives while also being faster. When I'm done coding for the day or close the browser, the ramdisk contents disappear, which is fine because I don't need them since the actual source code lives on the SSD where it belongs.

This is the kind of tuning you can do when you understand the pieces well enough to know what you actually need. It's not about following a guide or copying someone else's setup, it's about knowing your workflow and building the infrastructure around it instead of adapting your workflow to fit someone else's infrastructure.

Control Over Defaults

My career in backend development taught me how systems work from the inside out, but I spent those years using systems other people built, Windows desktops and corporate infrastructure where the decisions were already made and the tools were already chosen. I never got to ask "what if we did it differently?" because the infrastructure was already there.

Building this Arch system from vanilla up, choosing each piece and understanding what it does before deciding whether to keep it, that's what I wanted retirement for. Not because vanilla Arch is objectively better than the alternatives or because there's some moral superiority in doing things the hard way, but because building it myself means I know every layer of the stack.

When something breaks, I know where to look. When I want to change something, I know what's safe to touch and what will cascade into other systems. CachyOS repos for optimized packages when they matter, dual kernels for different workloads, BTRFS snapshots for safety, custom subvolumes for workflow optimization, ramdisk for performance where it counts.

None of this is magic or rocket science, it's just paying attention to what I actually need instead of accepting what came in the box and hoping it matches my use case. This is the starting point, the foundation that actually works the way I need it to work, and now I can build the desktop environment on top of it.

That's next time.

Still Skidding Broadside

VintageTechie — Sun, 08 Feb 2026 05:41:05 +0000

"Life is not a journey to the grave with the intention of arriving safely in a well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming, 'Wow! What a ride!'"

I heard that quote sometime around 2000 and it stopped me cold, not because it was something I wanted to be but because it was something I already was. Somebody had managed to put words around a thing I'd been living for twenty plus years without ever naming it. I didn't choose that philosophy. You don't choose a philosophy when you're burying friends in their twenties and thirties.

Someone once said about me that I don't dip my toe in the water to test it, I just dive right in. That's true. It's been true my whole life. But it wasn't some personality quirk I was born with. It was beaten into me by circumstances that didn't leave room for careful.

The Default World Wasn't Built for Me

I'm 69 years old and most of my friends are gone. Not from age, but from AIDS.

I always knew I was different and I always knew I liked boys. That's not the kind of thing you announce in the late 60s and early 70s, you just carry it around and hope nobody notices. I grew up with nuclear drills in elementary school, duck under your desk and kiss your sweet ass goodbye, and then JFK got shot, and then MLK, and then Bobby Kennedy, and Stonewall happened when I was thirteen years old. Innocence left me early. By the time I started coming out in the mid 70s I'd already learned that the world was not a safe or predictable place and that the people in charge of it didn't have my best interests at heart. I didn't come out because I wanted to. I came out because I had to. Nobody else was going to build community for us. Nobody else was going to fight for our rights. If you stayed hidden you stayed safe but nothing changed, and I'd already seen enough of the world to know that nothing changing meant people keep dying.

Then Reagan and the gay plague (AIDS). And whatever innocence was left got burned out completely.

If you weren't there it's hard to fully explain and if you were there you can't forget and I won't forget. Reagan was in the White House and wouldn't say the word AIDS while people were dying. Rock Hudson, a personal friend of the Reagans who'd sat at Nancy's table at a state dinner, pleaded for White House help getting AIDS treatment in Paris. Nancy turned him down. He was dead nine weeks later. The culture had opinions about who I was and none of them were good. The institutions that were supposed to protect people, government, churches, sometimes even hospitals, had decided that people like me weren't really their problem.

Most of my family couldn't or wouldn't accept who I loved. That's a sentence that's easier to write now than it was to live through then. You figure out pretty quick when you're young and gay in that era that the default world, the one everybody else seems to get handed, is actively excluding you. Nobody is building a place for you at the table. If you want a family you build one yourself, out of the people who show up when the people who were supposed to show up don't.

And we did. We built families. When AIDS hit and people were dying their biological families would sometimes just vanish. Wouldn't visit. Wouldn't call. Would let their own son or brother or cousin die in a hospital room with nobody holding their hand because they were too ashamed or too scared or too hateful to be there. So we showed up instead. We took care of people whose families had abandoned them to die alone because somebody had to and nobody else was going to.

My first boyfriend and I were together thirteen years. He committed suicide. AIDS had already taught me what loss looked like, had already taught me that you can build something real and have it taken from you and have to start over with nothing but the knowledge that you did it before so you can probably do it again. Too many years later the Supreme Court decided Obergefell v. Hodges and same-sex marriage became legal in every state. I wish he could have seen it.

His death broke me. I found him. I called 911. I had to tell his family he was gone. I had to make the funeral arrangements, and this time it wasn't for a friend from the community, it was for the person I loved. I'd spent years taking care of others, taking care of him, building and rebuilding and showing up, but I'd never taken care of myself. Somewhere in all that loss and all that pain I couldn't find a reason to keep going, and I became a drug addict because the alternative was feeling everything I'd been carrying for thirty years.

I came back from it. That's a longer story than I'm going to tell here, but I came back. Once more I had to rebuild, and this time what I was rebuilding was me.

After that you don't expect the world to include you and you don't trust anyone else's defaults because you've seen where that gets people. And you stop caring about risk, because when you don't know if you're next, playing it safe starts to feel like a waste of whatever time you've got.

That's where the quote comes from. That's why it hit me the way it did. I'd already been skidding broadside for twenty plus years by the time I heard it. Marching, fighting for equal rights, building community, burying friends, starting over, doing it again. I never learned to dip my toe in first because the water never waited for me to be ready.

Building Things

I built my first PC. This was back when that meant something, when you were picking components and putting them together yourself because the off the shelf options were either too expensive or too limited or just not what you needed. I stood up my own BBS on an acoustic coupled modem, one user at a time, with set hours that people knew to call in on, which for anyone who doesn't remember was basically a small online community running on hardware in your house before the internet made that seem quaint. My own machine, my own software, my own space, my own rules.

Forty-Three Years of Someone Else's Tools

Then the career happened and I spent the next four decades using whatever the job put in front of me.

Clarion and Visual Basic in the DOS days, writing database applications on machines where you knew exactly what was in memory and what wasn't because you put it there. Then a side venture into OS/2 because someone somewhere made a bet on IBM, and OS/2 was genuinely impressive technology that couldn't decide what it wanted to be and eventually collapsed under the weight of trying to be everything. Back to Windows when OS/2 died, because that's where the work was. C# and .NET, which is honestly some of Microsoft's best engineering, a solid language on a solid runtime, but welded to an ecosystem that got heavier and more opinionated with every release. Then Apple, because that's what was on the desk. Then AWS and Java, because enterprise architecture doesn't care what you'd rather be writing, it cares what the infrastructure team already bought.

Every one of those platforms was someone else's decision. I didn't pick Clarion because I loved Clarion, I picked it because the project needed it. I didn't go back to Windows because I missed it, I went back because OS/2 was dead and the contracts were in Redmond's ecosystem. Nobody chooses Java, you just end up writing it because that's what the AWS shop was running. Forty-three years of being good at tools I didn't choose, on platforms I didn't pick, building things that belonged to someone else.

I was good at it. That wasn't the problem. The problem was spending four decades knowing what I would have done differently and having it not matter because it wasn't my call. If you've ever sat in a corporate environment staring at a technology decision that was made three levels above you by someone who doesn't write code, you know exactly what I mean.

Retirement

When I retired I knew two things. First, I was done with Windows. Not angry at it. Just done. Forty years is enough. Second, I wanted Linux. Not because I had some ideological commitment to open source, but because for the first time in forty-three years nobody was telling me what to run and I wanted something that was mine.

I bought a System76 Adder WS because the hardware was right, and it came with Pop!_OS 22.04 installed, which meant that even my first Linux experience was technically someone else's choice riding along with the hardware purchase. The pattern was hard to break apparently.

Pop was fine. It was more than fine actually, it's what got me into the Linux world and eventually into COSMIC and into creating applets for it. But Pop is built on Ubuntu LTS, which means packages that are months behind and a desktop environment that moves faster than the base it's sitting on. I've spent forty-three years waiting on other people's release schedules. I wasn't about to start a new career of it.

So I went looking.

The Distro Graveyard

Fedora. RPM annoyed me.

Linux Mint. I genuinely loved it. Great desktop, great community, everything works. But I'd just spent forty-three years on Windows and Mint felt so much like Windows that it triggered something between nostalgia and PTSD. I didn't leave Microsoft's ecosystem to land in something that reminded me of it every time I opened the file manager.

Manjaro. Meh.

Garuda. Garish, loud, and KDE.

CachyOS. Now this one was interesting. The performance was real, the custom kernels were fast, the optimized packages made a noticeable difference. But it was the same old story wearing new clothes. Somebody else's desktop theme, somebody else's default terminal, somebody else's keybindings, somebody else's idea of what my computer should look like when I sit down in the morning. Great engine. Too many opinions.

Each one was fine. Each one had somebody else's fingerprints all over it. I kept moving.

Arch

I installed Arch Linux on a bare drive and for the first time since the BBS, every single thing on my machine was there because I put it there. Every package. Every service. Every kernel. Every config file. Nothing was installed because a committee decided it should ship by default. Nothing was themed to match someone else's aesthetic. Nothing was running that I didn't start.

I pulled in the CachyOS repositories because their engineering is genuinely good, optimized packages, custom kernels compiled with flags that actually matter on modern hardware, stuff that makes a measurable difference. But I left their desktop opinions on the shelf. Their kernel, my system. That's the whole point.

But this post is already long enough, and the Arch setup is its own story. How I layer CachyOS repos on vanilla Arch, why I run dual kernels, what BTRFS snapshots have to do with any of it, and why the CachyOS vs EndeavourOS debate that's all over Reddit right now is asking the wrong question. That's next time.

What a Ride

I started building my own things because the world didn't have room for me in it. Built my own family because the one I was born into couldn't handle who I loved. Built families for people who were dying alone because theirs walked away. Built my own PC and stood up my own BBS because the spaces and the machines I needed didn't exist. Spent forty-three years building on other people's platforms because that's what the work required, and then finally, in retirement, got to build my own system again.

The blog is called VintageTechie and people probably assume that's about old hardware or retro computing. It's not. It's about me. I'm the vintage. I was there for the BBS era, the DOS era, the OS/2 detour, the Windows decades, the Apple years, the AWS sprawl, and now Linux. I've been building things my entire life, not because it's a hobby but because it's how I survived, and I'm not done yet.

What a ride.

The Desktop Outgrew the Distro

VintageTechie — Wed, 04 Feb 2026 19:11:35 +0000

I loved Pop!_OS and ran 22.04 for years. System76 built something special with that distro, and when they announced they were writing a new desktop environment from scratch in Rust, I was all in. Three years of alphas and betas later, COSMIC shipped in December 2025 and it's everything they promised: fast, stable, with tiling that actually works without a PhD in config files.

Here's the problem: COSMIC is moving faster than Pop can carry it.

Pop!_OS 24.04 dropped in December, and System76 keeps the kernel and NVIDIA drivers current. I'm looking at 6.17.x and the 580 series drivers right now, so that's not the issue. The issue is everything else. Pop is built on Ubuntu 24.04, which means the repos are from April 2024. Mesa, GTK, glibc, toolchains, libraries—nearly two years old. System76 can ship their own kernel, but they can't fork every package in the Ubuntu repos.

Meanwhile, COSMIC is getting point releases every few weeks. Version 1.0.3 landed in mid-January, 1.0.4 came a few days later, and 1.0.5 just dropped. The desktop is evolving at rolling-release speed while the underlying system is frozen in time. If you're doing Rust development on COSMIC itself, this matters. You want current tooling and libraries that were built this year, not dependency hell because rustc in the repos is 22 months old.

System76 didn't build COSMIC just for Pop. It's already in the official Arch repos, Fedora has it, and NixOS has it too. They want it to spread because that's how you build an ecosystem. So I stopped fighting the mismatch.

Vanilla Arch. COSMIC selected right in archinstall. As of version 3.0.15, it's a standard option now with no flags or workarounds required—just pick it from the menu. The result is COSMIC running on a base that actually keeps pace with it. When System76 ships a fix, I get it. When Mesa updates or a library gets a security patch, I get it. The desktop and the system move together instead of one waiting for the other.

My setup ended up being vanilla Arch with Limine as the bootloader because it's lightweight, fast, and plays nice with BTRFS snapshots. BTRFS on all drives with compression enabled. I run two kernels: Zen for daily coding work because it's stable with good latency, and the CachyOS kernel for gaming with the BORE scheduler and optimizations tuned for that workload. I just swap at the boot menu depending on what I'm doing.

Here's the trick though. You can add the CachyOS optimized repos to vanilla Arch without running CachyOS. They compile packages for x86-64-v3, x86-64-v4, and Zen4 architectures. On a Ryzen 9 9800X3D, that's a measurable performance bump—Phoronix benchmarked it at 5-20% depending on the workload. Same packages, compiled for your actual hardware. So I get the purity and control of vanilla Arch, the desktop philosophy of System76, and the performance tuning of CachyOS. Best of all three worlds.

COSMIC scratches the tiling itch that Hyprland fills for a lot of people, but Hyprland has a maintenance problem. I've been doing this for 43 years, and one principle has never failed me: thou shalt not break API. Hyprland breaks things constantly. Every major update can blow up your plugins, your configs, sometimes basic functionality. If you're running Hyprland, you accept that your setup might need fixing after any update. COSMIC gives you tiling without the maintenance tax, and it's backed by a company that sells hardware. System76 can't afford to ship something that breaks their customers' workflows, and that's skin in the game.

Vaxry wrote a critical blog post when COSMIC was in alpha, calling it buggy and goalless while complaining that the devs were dismissive of his bug reports. Worth noting: he's the Hyprland dev. A competitor showing up during your alpha to file bugs and then complaining publicly that you weren't receptive enough might have an ax to grind. Since the 1.0 stable release? Radio silence. The criticism aged poorly.

I'm not abandoning System76. I'm running their desktop every day, I bought my Thelio and my laptop from them, and I'll probably buy more. But the desktop outgrew the distro. COSMIC is too good to be held back by Ubuntu's release cadence. System76 can maintain the kernel and drivers, but they can't outrun Canonical's repos for everything else. The math doesn't work.

Pop!_OS 26.04 might change the equation. They've said they're aligning with Ubuntu's release timing going forward, which means faster turnaround, but that's still point releases tied to LTS cycles. COSMIC is moving at a different pace.

If you love COSMIC and you're feeling the friction of stale packages, you don't have to wait. The desktop works on Arch, Fedora, and wherever else you want to put it. That's the whole point. System76 built COSMIC to travel. So can you.

Death by Yes

VintageTechie — Fri, 30 Jan 2026 05:00:00 +0000

I've been doing this for a long time. Forty-three years of backend work, most of it in or adjacent to environments where security wasn't optional. ACH and credit card processing, HIPAA compliance, air-gapped systems, some of it for entities I can't name and projects I'll never talk about. The through-line in all of it was always the same, which is to reduce attack surface. Ports you don't open can't be exploited, services you don't run can't be compromised, and features you don't ship can't betray you.

This shapes how I think about software, even the software on my personal machines. My home network looks like something out of a paranoid sysadmin's fever dream because that's the only way I know how to build things. Pi-hole feeding into Unbound for recursive DNS so no single provider builds a profile of my queries, a UISP Router Pro with VLANs segmenting my network so the IoT garbage can't talk to my workstations, UPnP disabled, no port forwards, and no remote access at all. If I'm not home, I'm not home, and the convenience isn't worth the attack surface.

So when I sit down with a piece of software and it feels like a committee designed it, that stands out to me. A browser that ships with a built-in mail client, calendar, feed reader, and Mastodon panel? I don't see features. I see code, dependencies, and attack surface.

Engineers love building things. That's why we got into this. The dopamine hit of solving a problem, shipping a feature, watching something work that didn't exist yesterday. I get it. I've felt it. But somewhere along the way, the question shifted from "should we build this?" to "can we build this?" And those are very different questions.

I've been testing Vivaldi lately. It's a capable browser with some genuinely nice tab management features, and I wanted to see if it could replace Brave for my daily use. But the longer I spend with it, the more it reminds me of KDE, and that's not a compliment. Both projects feel like someone in a meeting said "oh hey, we could also add this" and nobody in the room had the authority or the inclination to say no.

Vivaldi ships with a mail client, a calendar, a feed reader, translation tools, a notes feature, web panels, and roughly five hundred settings spread across nested menus. The Vivaldi forums have users complaining about feature creep, and the official response boils down to "the reason Vivaldi exists is to have all this stuff built in." That's not a defense, it's an admission that the project has no limiting principle.

KDE has the same energy. The KDE Frameworks consist of 83 separate libraries. After Plasma 6 launched, bug reports jumped from the usual 30-50 per day to 150-200. A KDE developer publicly acknowledged that the project's configurability creates more bugs because there's simply more to test. A bug that only appears when you're using an alternate theme with auto-hiding panels on multiple monitors can't be dismissed as a niche edge case when the software explicitly supports all of those options out of the box, and if you shipped it, you own it.

Here's what bothers me from a security standpoint. Every feature is code, every code path needs to be maintained, and every integration point is a potential vulnerability. When you ship software that tries to do everything, you're not giving users flexibility. You're giving attackers options.

Both Vivaldi and KDE have had real security issues that trace back to this philosophy. KDE's had a screen lock bypass where turning all screens off and back on could unlock the session, notifications that leaked user IP addresses, and X11 clients able to eavesdrop on input events while the screen was supposedly locked. Vivaldi's had an installer vulnerability that allowed arbitrary code execution. These aren't theoretical concerns, they're the natural result of sprawling codebases that try to be everything to everyone.

And then there's the language problem. Vivaldi's UI is built with JavaScript and React running on top of a C++ backend, and KDE uses QML (also JavaScript-based) on top of C++ and Qt. You end up with two languages, two paradigms, and two sets of potential failure modes. The JavaScript layer might be flexible and easy to iterate on, but it's another moving part in a system that already has too many.

Compare this to projects that have a clear vision and stick to it.

Brave is a browser that blocks ads and trackers by default, randomizes your fingerprint, and ships with Tor integration for when you need it. It doesn't have a mail client or a calendar or a feed reader because Brave is a browser and those things are not a browser. The team picked a lane and stayed in it, and the settings fit on a couple of screens because most users don't need to change them. The defaults are the product.

COSMIC is a desktop environment built by System76 entirely in Rust, one language top to bottom, memory-safe by design. They're not bolting features onto GNOME or forking KDE or trying to be everything. They identified what they wanted, which is a tiling-capable desktop that's fast, stable, and doesn't get in your way, and they're building exactly that and nothing else. When I switched to COSMIC on my Thelio, the contrast with KDE was immediate. COSMIC has fewer features because that's the point, not because it's immature.

Good defaults beat infinite toggles, and software that knows what it is beats software that's still figuring it out.

I'm not here to tell anyone what to run. If you love ricing your desktop, rice away because KDE and Vivaldi exist for you. Some people find joy in tweaking every pixel, and I'm not going to pretend that's wrong. Just know what you're trading for those pixels.

For me, the tradeoff isn't worth it. Forty-three years of thinking about attack surface has made me allergic to software that can't define its own boundaries. A project that can't say no to features can't say yes to security, and if everything is configurable, the product doesn't really stand for anything. If the answer to "why does a browser have a mail client?" is "because we could," then I don't trust the team to make harder decisions when the stakes are higher.

I'll stick with Brave and COSMIC, software that knows what it is and isn't embarrassed to ship with defaults.

You Built a Network of Snitches

VintageTechie — Wed, 28 Jan 2026 18:53:04 +0000

Most home network security advice gets the threat model backwards. You'll read about keeping hackers out, changing default passwords, maybe setting up a VPN if you're feeling fancy, and all of that is fine as far as it goes, but it completely misses where the actual problem is. The bigger threat to your privacy isn't some attacker trying to break in from the outside,it's all the traffic flowing out from the inside, from devices you bought and paid for and invited onto your network because they promised to make your life more convenient.

Your smart TV reports what you watch back to Samsung or LG or whoever made it, and this isn't some secret conspiracy, it's right there in the terms of service that nobody reads. Your phone maintains a constant connection to Google or Apple, feeding back location data and app usage and search history and god knows what else. That cheap smart plug you grabbed off Amazon is chattering away to a server somewhere in Shenzhen. Meanwhile your ISP sits in the middle of all of it, logging every DNS request that passes through their infrastructure, building a tidy profile of everywhere you go online even if you're using HTTPS for everything, because DNS happens before the encryption and they can see every domain you're trying to reach.

None of this requires a security breach or a sophisticated attack. You weren't hacked. These devices are working exactly as designed, and they were designed to extract as much data from you as possible.

What You're Actually Defending Against

When I started thinking seriously about my home network, I had to get honest about what I was actually worried about, because "security" is a vague concept that can mean anything from nation-state attacks to keeping your neighbor off your wifi. My actual concerns came down to a handful of things that probably overlap with yours if you're reading this.

ISP snooping was near the top of the list, because I'm paying these people a hundred bucks a month and they're turning around and monetizing my browsing history on top of it, which feels like getting pickpocketed by the bus driver. DNS requests are sent in plain text by default, so even if every website you visit uses HTTPS, your ISP can still see that you visited i, they just can't see what you did once you got there. That's enough to build a pretty comprehensive profile of who you are, what you're interested in, what your politics are, what medical conditions you might be researching, whether you're looking for a new job, all of it.

Then there's the telemetry problem, which is really just corporate surveillance that we've all been trained to accept as normal. Google and Apple and Microsoft and Amazon have built their entire business models around knowing as much about you as possible, and they've conveniently put the tools for that data collection into every device you own. Your Android phone is basically a Google sensor package that also makes calls. Your Windows machine is constantly chattering back to Redmond. Apple talks a big game about privacy but still collects plenty of data, they're just slightly less creepy about it.

The IoT situation is even worse because at least Google and Apple are known quantities with reputations to protect. That no name smart bulb you bought runs firmware written by god knows who, phones home to servers you've never heard of, and will never receive a security update in its life. The attack surface on most IoT devices is horrifying, but even if they're not actively compromised, they're still collecting data about your home and your habits and shipping it off somewhere.

And then there's plain old advertising, the trackers embedded in every website and app, the fingerprinting and the pixels and the cookies, all of it designed to follow you around the internet and build a profile that can be sold to whoever wants it. You can run an ad blocker in your browser, but that doesn't help your TV or your tablet or your kid's devices or anything else that connects to your network.

The through line connecting all of this is that the problem isn't primarily about keeping bad actors out it's about controlling what your own devices are sending out without your knowledge or meaningful consent.

Taking Control of DNS

DNS is the foundation of everything else because it's the first thing that happens when any device tries to reach anything on the internet. Before your browser can load a webpage, before your TV can stream a show, before your smart thermostat can phone home, something has to translate that domain name into an IP address, and by default that translation request goes to your ISP in plain text where they can log it and do whatever they want with it.

The simplest fix is to change your DNS provider to something like Cloudflare or Quad9, and that's a reasonable first step that takes about thirty seconds, but you're still funneling all your queries through a single third party who can see everywhere you go online. Maybe you trust Cloudflare more than Comcast, and that's probably fair, but the ideal scenario is not having to trust anyone at all.

That's where running your own recursive resolver comes in. I use Unbound, which is a piece of software that does DNS resolution the way it was originally designed to work, before everyone started relying on big upstream providers. When you ask Unbound where reddit.com is, it doesn't forward that question to Cloudflare,it goes directly to the root DNS servers, then to the .com servers, then to Reddit's authoritative nameservers, piecing together the answer from the source. Your queries get distributed across thousands of different servers instead of concentrated with one provider, and nobody except you has a complete picture of everywhere you're going.

Pi-hole sits in front of Unbound and handles the filtering, which is where things get interesting. Pi-hole maintains blocklists of known advertising, tracking, and telemetry domains, and when any device on your network tries to resolve one of those domains, Pi-hole just returns nothing. The request never makes it past your own network. That Samsung TV trying to reach samsungads.com? As far as it knows, that domain doesn't exist. The Microsoft telemetry endpoints that Windows is constantly trying to reach? Gone. The dozens of tracking domains that load in the background every time you visit a news website? Blocked before your browser even knows they exist.

The beautiful thing about DNS level blocking is that it works for every device on your network without having to configure each one individually. You can't install an ad blocker on your smart TV or your game console or your IoT devices, but if the blocking happens at DNS, it doesn't matter what the device is or what operating system it runs. If it uses your network, it plays by your rules.

Setting up Unbound and Pi-hole on a Linux box isn't particularly difficult—Unbound is in most package managers and Pi-hole has a one liner install script but the real work is tuning your blocklists and figuring out what to whitelist when things break. You'll discover pretty quickly just how much of the modern internet is tracking infrastructure when you see the sheer volume of requests getting blocked in your logs.

Firewall Thinking Beyond the Basics

Everyone knows the basic firewall advice: default deny from WAN, don't forward ports you don't need, change your default passwords. That's all correct and you should do it, but it's also the bare minimum and it's focused almost entirely on keeping things out when the more interesting question is what you're letting out.

UPnP is a perfect example of a feature that exists purely for convenience and creates a massive hole in your security posture. The idea behind UPnP is that devices on your network can automatically open ports to the internet without you having to configure anything, which sounds great if you're trying to get your Xbox to work with voice chat or whatever, but think about what that actually means: any device on your network can punch holes in your firewall without asking permission. Malware loves UPnP because it means that once something gets onto your network, it can open up its own back door to the outside world. Turn it off. If something legitimately needs a port opened, you can do it manually, and then you'll actually know what's exposed instead of trusting every random device to make that decision for you.

Port forwarding in general is something I've become increasingly aggressive about avoiding entirely. Every port you forward to the internet is an invitation, a service sitting there waiting for connections from anyone who finds it, and unless you're absolutely certain that service is hardened and patched and configured correctly, you're taking a risk that probably isn't worth whatever convenience you're getting. I don't allow any remote access to my network at all, which some people think is extreme, but I've come to the conclusion that if I'm not home, I'm not home. I don't need to check on my security cameras from vacation badly enough to expose a video stream to the internet. I don't need to access my files remotely badly enough to run a VPN endpoint that could be compromised. The attack surface reduction from just not doing any of that is significant, and I've adjusted my habits around the limitation rather than introducing risk for convenience.

The outbound side of firewall configuration is where things get more interesting and where most people don't spend enough time thinking. Your devices are constantly making outbound connections, and most of them are connections you never asked for and don't benefit from. If your router supports it, you can get granular about what's allowed to leave, some people block entire IP ranges for countries they have no reason to communicate with, others maintain blocklists of known advertising and telemetry IPs as a backup to DNS filtering, because some particularly aggressive software will try to bypass DNS and connect directly to hardcoded IP addresses. The goal is making your network hostile to the surveillance and tracking that all these devices are trying to do, layering defenses so that even if something gets past one layer, there's another one waiting.

Segmentation and the Art of Containment

Here's the uncomfortable reality about IoT devices: most of us aren't going to throw them all away. The smart TV has a nice screen and it would be annoying to replace it with a dumb monitor. The voice assistant is genuinely useful sometimes, even if it is an always on microphone connected to Amazon's servers. The robot vacuum actually does keep the floors clean. You can take a hardline stance and refuse to have any of this stuff in your house, which is a valid choice, but most people are going to end up with at least some devices they don't fully trust but still want to use.

VLANs let you have it both ways by creating network segments that are isolated from each other. The concept is straightforward: instead of having one flat network where every device can see and communicate with every other device, you create separate zones with rules about what traffic can pass between them. Your computers and phones and other devices you actually trust go on one VLAN. The IoT garbage goes on another. Maybe you have a third for guest devices, or a fourth for work stuff if you're keeping that separate from personal, whatever makes sense for your situation.

The practical effect is that your smart TV can reach the internet to stream Netflix, but it can't see your NAS or your workstation or anything else on your trusted network. If that TV turns out to be doing something sketchy, or if it gets compromised because it's running ancient unpatched firmware with known vulnerabilities, the blast radius is contained to its own little sandbox. It can't be used as a jumping off point to attack the rest of your network because as far as it can tell, the rest of your network doesn't exist.

Setting this up requires hardware that actually supports VLANs, which immediately rules out most consumer grade routers and switches. This is one of the reasons I ended up moving to Ubiquiti equipment, not because it's the only option, there are plenty of choices in the prosumer and enterprise space, but because I needed something that would let me actually configure my network the way I wanted instead of being limited to whatever the manufacturer decided to expose through their app. The configuration isn't particularly difficult if you have a basic understanding of networking concepts, but it's definitely more involved than plugging in a consumer router and letting the wizard handle everything.

One underrated benefit of segmentation is the visibility it gives you into what your devices are actually doing. Once your IoT stuff is on its own VLAN, you can monitor that traffic and see exactly what it's trying to reach, and the results are often educational in a depressing sort of way. That robot vacuum that "just needs wifi to work" turns out to be making connections to half a dozen different servers across multiple continents. That smart plug is chattering away constantly even when you're not using it. You knew intellectually that these devices were phoning home, but seeing it in your logs makes it concrete in a way that reading about it doesn't.

Living With It

Once everything is set up, the day to day experience is mostly invisible, which is kind of the point. Pi-hole sits there quietly blocking a few thousand requests every day, Unbound resolves everything else, the firewall does its thing, and the VLANs keep everything in their respective lanes. You don't think about it most of the time because there's nothing to think about.

The main ongoing maintenance is supposedly checking Pi-hole when something breaks, because occasionally a legitimate service can get caught in a blocklist and you'll need to whitelist it. This is something you'll see mentioned constantly in Pi-hole forums and guides, and I'm sure it happens to people depending on their blocklists and what services they use, but I'll be honest,it's never actually happened to me. I set it up, tuned the blocklists, and it's just worked. Your experience might vary, especially if you're using more aggressive blocklists or you rely on services that are particularly intertwined with tracking infrastructure, but don't let the fear of constant maintenance scare you off. It might be a non issue for you too.

The other thing that becomes part of your routine, at least if you're the kind of person who finds this stuff interesting, is occasionally checking the logs to see what's being blocked and what your devices are trying to do. There's something satisfying about watching the blocked request counter tick up, knowing that each one of those is a tracking pixel or a telemetry endpoint or an ad that never made it through. You can see exactly how much of the modern internet is surveillance infrastructure, because you're watching it all bounce off your network in real time.

Is all of this paranoid? I've thought about that question a lot, and I keep coming back to the same answer: I don't think it's paranoid to want control over my own network and my own data. These companies have made it abundantly clear that they see us as products to be monetized, that our attention and our data and our habits are the raw material for their business models, and the only reason we put up with it is because opting out used to be hard. But it's not that hard. A cheap mini PC running Linux, some networking equipment that doesn't treat you like an idiot, and a weekend of configuration, and suddenly you're not participating in the surveillance economy anymore, at least not from your home network.

The devices still try to phone home, of course. They'll never stop trying. But now you can see them doing it, and you can tell them no.

Why I Left GitHub

VintageTechie — Fri, 26 Dec 2025 20:31:00 +0000

After 40 years in software engineering, I've learned to recognize when a platform stops serving its community and starts exploiting it. GitHub crossed that line. I've moved my projects to Codeberg, and I think you should consider doing the same.

The short version: GitHub is owned by Microsoft. Microsoft uses code hosted on GitHub to train AI models, including GitHub Copilot. I did not consent to my code being used this way. Neither did millions of other developers whose work now powers a $19/month subscription service.

That's it, that's the reason, But if you want the longer version, keep reading.

When Microsoft acquired GitHub for $7.5 billion in 2018, many of us were concerned. GitHub had become the de facto home for open source development, and Microsoft's historical relationship with open source was adversarial at best. Remember "Linux is a cancer"? Microsoft assured the community that GitHub would remain independent. Then came Copilot.

GitHub Copilot is an AI coding assistant trained on billions of lines of code from public GitHub repositories. According to GitHub's own statements, the training data includes code licensed under GPL, MIT, Apache, and other open source licenses. These licenses have requirements: attribution, share-alike provisions, and other terms that exist for good reasons. Copilot ignores all of them.

When Copilot suggests code to a developer, it provides no attribution. It doesn't indicate which license the original code was under. It doesn't tell you if that suggestion came from a GPL-licensed project that would require your derivative work to also be GPL-licensed. It just outputs code and leaves you holding the bag for any license violations.

GitHub's former CEO claimed that "training ML systems on public data is fair use" and "the output belongs to the operator, just like with a compiler." This is a bold legal theory that has never been tested in court, until now.

In November 2022, a class-action lawsuit was filed against GitHub, Microsoft, and OpenAI by the Joseph Saveri Law Firm and Matthew Butterick, an open source programmer and attorney. The lawsuit alleges violations of open source licenses and the Digital Millennium Copyright Act.

The case is ongoing. In June 2024, a judge dismissed several claims, including the primary DMCA claim, finding that Copilot's output wasn't identical enough to the original code to constitute a violation. However, two significant claims survived: breach of contract (GitHub's own terms of service) and open source license violations.

An appeal was filed in October 2024 and this case is far from over.

Regardless of how the courts ultimately rule, the ethical problem remains. Open source developers contributed their work under specific terms. Microsoft took that work, fed it into a proprietary system, and now charges $19/month for access. The open source community built something valuable through collective effort, and a trillion-dollar corporation is monetizing it without respecting the terms under which it was shared.

The Software Freedom Conservancy, a nonprofit that supports free and open source software projects, quit GitHub in June 2022 and urged other developers to do the same. Their statement is worth reading in full, but the core argument is simple: "Launching a for-profit product that disrespects the FOSS community in the way Copilot does simply makes the weight of GitHub's bad behavior too much to bear."

The SFC tried for over a year to get answers from Microsoft and GitHub about Copilot's training data, the legal basis for their fair use claims, and why they trained on open source code but not on proprietary Windows code. GitHub refused to engage.

That silence tells you everything you need to know about how Microsoft views the open source community: as a resource to be extracted, not a partner to be respected.

The AI training issue is the most egregious problem, but it's not the only one. GitHub is proprietary software built on top of Git, an open source tool specifically designed to enable distributed, decentralized development. GitHub has systematically added features that create lock-in and centralization, the opposite of what Git was built for.

Every issue, pull request, discussion, and wiki page you create on GitHub lives in a proprietary database that you cannot fully export. Your contribution graph, your followers, your repository stars, all of that lives on Microsoft's servers, under Microsoft's control.

And let's not forget that GitHub has a contract with U.S. Immigration and Customs Enforcement. When GitHub employees and community members raised concerns about this, GitHub's response was dismissive.

I moved my projects to Codeberg. It's a nonprofit, community-run Git hosting service based in Germany with strong privacy protections. It runs on Forgejo, a community fork of Gitea that explicitly exists to prevent corporate capture.

Codeberg has everything I need: full Git hosting with tags and releases, issue tracking, CI/CD through Woodpecker, no AI training on my code, no telemetry, no ads, no venture capital demanding growth at any cost.

For my COSMIC desktop applets, the workflow is simple: I develop on Codeberg, tag releases there, and submit pull requests to the cosmic-flatpak repository on GitHub when needed. GitHub becomes a delivery mechanism, not my home.

I'm not going to tell you that leaving GitHub is easy. It's not. GitHub has network effects that make it the default choice for collaboration. Many employers require it. Many open source projects live there.

But every developer who moves to an alternative weakens GitHub's grip. Every project that hosts its canonical repository elsewhere demonstrates that alternatives exist. Every conversation about why developers are leaving puts pressure on Microsoft to change its behavior, or at least makes other developers think twice about where they host their work.

Here's what you can do: Evaluate your options. Codeberg, GitLab (self-hosted community edition), sourcehut, and self-hosted Forgejo are all viable alternatives. Start with new projects. You don't have to migrate everything at once. Put your next project somewhere else. Mirror strategically. If you need GitHub for discoverability or collaboration, mirror your repository there but keep your canonical source elsewhere. Talk about it. When people ask why you moved, tell them. The more developers understand what Microsoft is doing with their code, the more will consider alternatives.

I spent 40 years writing software. I've seen platforms come and go. I watched SourceForge go from essential infrastructure to adware-infested cautionary tale. I'm watching GitHub follow the same trajectory, except this time the exploitation is more sophisticated.

Your code has value. The terms under which you share it matter. Don't let a trillion-dollar corporation pretend otherwise.

My COSMIC applets are now hosted at https://codeberg.org/VintageTechie. The GitHub repositories have been archived with a pointer to the new location.

Distro Hopping to Nowhere: How I Landed on Vanilla Arch for COSMIC

VintageTechie — Wed, 24 Dec 2025 20:37:00 +0000

Forty years in R&D. Bleeding edge was the job description. If it wasn't broken, you weren't pushing hard enough. That mindset doesn't retire when you do.

April 2024. Burned out. Done with code. Just wanted to game and forget that compilers exist. Pop!_OS 22.04 was the daily driver, stable, familiar, fine.

Except "fine" started feeling like an insult.

Packages lagged. Performance felt sluggish. Running an LTS base when you've spent four decades refusing "good enough" is like wearing someone else's shoes. Technically functional. Constantly annoying.

I wasn't looking for a project. I just wanted a distro that didn't irritate me. Famous last words.

CachyOS showed up in my feed. Performance-focused, Arch-based, promising optimizations for the gamer brain I was trying to appease. Started with KDE because the internet said it was "better for gaming."

You know the saying: an elephant is a mouse built to government standards.

That's KDE. Powerful, capable, endlessly configurable, and fragmented beyond reason. Too many moving parts. No cohesion. Every setting spawns three more settings. It felt like a desktop designed by committee, where every feature request got approved and nothing got edited.

Switched to CachyOS with Gnome. Closer to Pop, more familiar. Still wrong.

Somewhere in there I tried Garuda, too much flash, not enough substance. Ubuntu briefly, back to the Gnome I knew. Debian, because maybe I needed boring and stable. Nothing stuck. Every distro solved one problem and introduced two more. Classic.

Then I found Hyprland.

Tiling window managers are hard to explain to people who haven't used them. Windows don't overlap. They tile. Hands stay on the keyboard. Everything has a place. For someone who spent decades optimizing workflows, it felt like the desktop finally got it.

CachyOS + Hyprland clicked. The aesthetic, the speed, the control. This was home.

Except Hyprland has a problem: Vaxry moves fast and breaks things. Config changes between versions. What worked yesterday throws errors today. For a window manager, the foundation everything else sits on, that's not quirky. That's exhausting.

I could have stayed. Kept patching my config every update. But something else was pulling my attention. System76 was building COSMIC.

COSMIC promised everything I loved about Hyprland, tiling, keyboard-driven, Wayland-native, but from a team building a complete desktop, not just a window manager. Written in Rust. Designed with intention. Backed by a company that ships hardware and has actual skin in the game.

Pop!_OS 24.04 alpha dropped with COSMIC. I jumped. Too soon.

Alpha means alpha. Too many things didn't work. Not daily driver territory. Back to CachyOS, now with their COSMIC build.

Somewhere in this shuffle, my husband saw what I couldn't admit.

The restlessness was back. The curiosity creeping in. He pointed me toward Rust, a language I'd been circling but hadn't committed to. He could see it: retirement wasn't going to be golf and gardening. The burned-out phase was ending.

I started reading COSMIC's source code. Not just using the desktop, reading it. Rust, with a real project to apply it to, finally clicked.

Then I found the weather applet situation.

There was a weather app for COSMIC. It required manually entering longitude and latitude. No location detection. No alerts. In 2024. I spent 40 years building systems that scaled to billions of messages, and this applet couldn't look up a ZIP code.

Tempest started there. Not because I wanted to write an applet, because the existing solution was unacceptable. I could fix it. So I did.

Suddenly the distro mattered differently. I wasn't just a user anymore. I was contributing. And contributing to a Rust-based desktop environment means you need current toolchains, current libraries, a foundation that isn't fighting upstream.

The burned out gamer was gone. The R&D engineer was back.

CachyOS with COSMIC worked. For a while. Pre-built packages meant no waiting for compiles. Performance optimizations felt real. Gaming was solid.

Then CachyOS started cracking.

ISO rollbacks. Package conflicts with upstream. Things broke, not because COSMIC changed, but because CachyOS's layer introduced variance. When you're developing against a moving target, you need to know which target is actually moving.

CachyOS adds value. Their kernel optimizations, the gaming-focused packages. But for COSMIC development, their repos became a variable I couldn't control. And I've spent too many years debugging to voluntarily add variables.

Tried the Fedora COSMIC Spin. Different base, same desktop. Maybe that was the answer.

Fedora's solid. COSMIC ran fine. Then came the NVIDIA stack.

RPM Fusion. Kernel module signing. Secure boot complications. Multiple repos with different priorities. Getting my RTX 4070 Super working correctly felt like assembling IKEA furniture with instructions in three languages, none of them complete.

I've debugged worse. But at some point you realize complexity isn't buying you anything. Fedora wasn't it.

Pop!_OS 24.04 hit stable. COSMIC from the team that builds COSMIC. The obvious choice.

It worked. Stable, polished, daily-driver ready. The friction crept back anyway.

Ubuntu 24.04 LTS underneath means older kernel, older Mesa, older everything. For a desktop environment in active development, an LTS base feels like driving a sports car with the parking brake on.

MangoHud? Compile it yourself. Latest Rust toolchain? Not in repos. BTRFS with Snapper for proper snapshots? Not default, not integrated, not trivial.

My Rule #1: Blessed are the pessimists, for they maketh backups.

Pop 24.04 made following that rule harder than it needed to be.

I found myself compiling packages just to get current versions. Building tools instead of using them. Fighting the base instead of working with it.

Pop plans to move to 26.04 in March. That helps. But LTS means packages are behind the moment they release. For developing COSMIC applets with current tooling, it's friction I don't need.

Nuked everything. Vanilla Arch.

No CachyOS repos. No third-party COSMIC builds. Just core, extra, multilib, and AUR.

Here's what Arch gives me that nothing else did: I install exactly what I want. Not what someone thinks I need. Not what a distro decided to bundle. No bloat, no extras, no "we included this for convenience." My system, my choices.

COSMIC from AUR means compiling, but it means compiling exactly what upstream ships. Zen kernel gives me desktop optimizations without CachyOS-specific patches I can't debug. BTRFS and Snapper work out of the box, snapshots before every pacman transaction, exactly how it should be.

Current kernel. Current Mesa. Current Rust. When COSMIC updates, I'm building against the same foundation the developers use.

More work than Pop? In some ways. But predictable work. When something breaks, I know where to look. The variables are controlled.

Forty years of R&D taught me one thing: the bleeding edge is only sustainable when your foundation is solid. Arch gives me that. COSMIC gives me the desktop I want to use and develop for.

A year of distro hopping. Here's what stuck:

COSMIC deserves a current base. It's built on modern Rust, targeting Wayland, actively developed. Running it on LTS creates friction between what COSMIC wants to be and what the base allows.

The grass isn't greener. CachyOS has real optimizations and real complexity. Fedora is solid until NVIDIA. Pop is stable and stale. Every distro is a tradeoff. Pick your pain.

Know what you're optimizing for. Burned out and gaming? CachyOS made sense. Developing applets? Different calculus. The best distro depends on what you're actually doing.

Your nature doesn't retire. Forty years on the bleeding edge. I thought burnout meant I was done with that. Turns out I just needed a break. The R&D mindset came back, and when it did, I needed a distro that could keep up.

Vanilla Arch with COSMIC isn't for everyone. But for developing COSMIC applets, gaming on an ultrawide with an NVIDIA GPU, and sleeping well because Snapper has my back?