BartyDeCanter

deleted by creator

deleted by creator

Happy to help! And yes, I have no idea what they’re talking about. If you don’t have snapshots (commits) you don’t have version control.

Let me know when you get your game going, I’d love to check it out. I’m working on a few myself.

The biggest silicon wafer is going to be your CPU or GPU. The motherboard is mostly fiberglass and copper.

I don’t have an exact number, but backing from California to a Hetzner box in Germany via Borg has always been surprisingly fast for the price and that it’s going halfway around the world. I want to say 25-30MB/s? I think people in the EU are reporting getting over 100MB/s.

If you just want one point of truth, the minimal version is to create a bare repo somewhere that you have ssh access to or your local machine. Then you can clone/pull/push from it.

A bare repo is a special kind of repo meant for exactly this, but can be a bit confusing at first. A normal repo contains all of your current working files and a special .git directory that holds all the files/blobs/history that git needs to work. A bare repo is just the .git as a top directory with bare=true in its config. So you can use it as a remote, but it never has a working set. They are usually named something like my_repo.git.

Edit:

Here’s a basic example for setting it all up in a fully local way:

mkdir ~/bares  
git init --bare ~/bares/my_repo.git  
mkdir ~/code  
git clone ~/bares/my_repo.git ~/code/my_repo  

And then you have remotes as your main source of truth in ~/bares and your working copies in ~/code. If you want to access from another machine that has ssh access to the first, you can do:

mkdir ~/code  
git clone user@host:~/bares/my_repo.git ~/code/my_repo  

And then use git pull/push to keep it all in sync. Don’t use Syncthing on a git repo, it eventually goes badly.

The number one thing to remember about git is that you don’t need a full hosting service around it for basic functionality. If it’s just you, a single local repo will probably serve you just fine, maybe use a bare repo on your main machine or a Pi-level device if you like as a remote/backup. Just git init or git init --bare and you’re good to go. GitHub, Codeberg, Forgejo, and all the others exist to serve multi-contributor and/or public project-level needs.

The number two thing to remember is that it is based around graph theory.

Remember that Git is a distributed VCS, so no git repo is dependent on a central server. Everything else about the project might be heavily dependent on GH, but any active developer is going to have a full copy of the code with history on their main workstation.

That being said, it highly depends on the project, but I’d put it into a few buckets.

1. Un/barely maintained projects - This is by far the largest number of repos, and many of them are used as dependencies by all sorts of projects. The truly unmaintained ones would vanish, and I bet most of the barely maintained ones would as well. The most important of these would probably be resurrected since their code will be sitting on all sorts of drives, but it will be a mess. Take a look at https://nesbitt.io/2026/05/08/weekend-at-bernies.html for an idea.
2. Small individually actively maintained projects - There are a lot of these and many of them could continue to be just fine, depending on how much of the full GH feature set they use. They would lose all the PRs, wiki spaces, discussions, issues, and maybe even the project page itself that are hosted on GH. For most projects it would be an annoyance to have lost all that, but if it’s a small enough project that one person is maintaining it, it’s probably small enough to pull over to something else reasonably easily depending on how all in they are on GH tools and their use of type 1repos. And a project with only one main contributor is unlikely to fragment.
3. Mid-sized active projects - Probably the hardest hit. A lot of these are all-in on the GH tools, particularly issues and CI. Losing that would hurt a lot because the project is big enough to really need those tools and uses them at a volume that they can’t just host on the leads laptop. These are also going to take a lot of work to set up the project infrastructure elsewhere. And this would probably be the sort of thing to push and simmering tensions to erupt, leading to fragmentation.
4. The big projects - Probably the least hardest hit. Most of these are just using GH as a push mirror. The core team probably has a functioning private communication and governance system, their own issue tracker (even if it pulls from GH), documentation, and public discussion groups. Most of these run their own private CI. And they are the ones most likely for another host to step in and offer to help.

So the little stuff? Probably going to be annoyed or not care a lot. The big stuff? Same thing. But that middle group would be hurt.

1. CI runners - GH offers free CI runners for a variety of OSs. I can automatically test my code on Linux/Mac/Windows for free on GH. No one else offers that because it is very expensive. You need windows licenses and Apple hardware. And Codeberg only offers it on Linux after a back and forth discussion. Plus, while simple GH CI Actions move to Forgejo Actions pretty easily, more complex ones require a complete rewrite.
2. Better issue tracking - FJ’s issue tracking is pretty good, and perfetcly fine for small projects, but GH’s is better.
3. Better CLI - fj is decent and improving, but gh is better
4. Better project pages - Codeberg Pages is decent and improving, but GH Pages are better.
5. Lots of other small things - Codeberg is decent and improving, GH is better.

For most people, myself included, the only thing that really matters are the CI runners. But that is also the one thing that costs the most to support.

Two main reasons: history and network effects.

GitHub was an independent company for a decade that provided a vastly superior service to what it replaced, primarily SourceForge. And it was free for FOSS projects, while charging for closed ones.

The improvements paid for by the closed source customers trickled out to everyone. So, it became the best place for FOSS developers, large and small. And as more people moved to GH, the more reason there was to move to it.

Of course, it was constantly bleeding money and eventually had to do something. That ended up being selling to MS.

There was a lot of trepidation about this, but for the first few years they not only kept their promise about supporting FOSS, but actually made it better by allowing small private repos to get many of the services that were previously gated for open FOSS or paid repos.

And the alternatives were stil not as good, and just as importantly didn’t have the user networking that GH does.

Now, some FOSS people are starting to look elsewhere, Codeberg, self-hosted Forgejo, and others. They have come a long way and are nearing feature parity, particularly for smallish projects. But the network effects of discovery and reputation are strong, and GH still provides a few more useful features.

I’ve moved my private repos to self hosted Forgejo, but my public ones are still on GH as push mirrors. I’m not ready to give up the discoverability and Mac/Windows CI runners that I can get from GH for free. I hope to be able to some day, but not yet.

While it seems like everyone here hates it, I’ve been looking for a minimal phone for when my current one dies. This seems to hit the exact sweet spot of functionality I want vs what I don’t want. As for the price, well, I’m spending at least that much on my next phone anyway so it seems fine by me.

And I have a huge nostalgia for flip phones and transparent electronics. So yeah, signed up to preorder.

1. Follow the Trash Guides exactly for your arr stack setup. Don’t try to get fancy or take a shortcut. If you’ve already set up something differently, just redo it. Better to spend a little time now than a lot later.
2. Set up Tailscale. The free tier is probably fine for you, but if you’re extra paranoid you can run your own Headscale server instead.
3. Take notes. What you set up, what your docker files and configs are, and add any troubleshooting info as it comes up.
4. Use a password manager and keep everything in it.

Sure, if that’s what you want to do. Though, you’ll probably find less references and expertise here. There is a reason that even Microsoft runs Linux on most of its own servers.

And if you don’t have any friends or a bank, put it in a double ziplock, then drop it in a Tupperware of water and freeze it.

I run Debian on a Thinkpad x130e. systemd bloat is basically a myth, and of all the things to work on reducing system resource use, it’s not quite last in line, but pretty close to it. In general systemd has been a complete, utter, unmitigated success.

Setup a PiHole and add them to the blocklist. Then make the PiHole password stupid long and write it down. Then take the paper, put it in a safe, and put it in the highest shelf in the back of your closet. Recurse safes and passwords as much as needed.

lol, I kinda do. It’s this weirdly and wonderfully idyllic town that feels like what a small town should be, while still being very progressive and queer friendly.

As for the meds, I’m trying to stock up, but mine are pretty restricted so at most I’m getting one or two spares per month. My partners are more reasonable, so they have a larger cushion.

In that level of extreme disaster, honestly not going to be caring. But I do have a layered approach to less extreme more realistic likely scenarios.

Neighbors and Community

The most important thing in a real emergency. We know our neighbors, chat with them on the street and in line for the weekly ice cream truck. We have several close friends within an easy walk or bike ride and are part of a local social club that we go to every week. We’ve had the emergency chat with many of them.

Power

15 minute UPS on my NAS will get me through small power bumps. I also have a large backup battery meant for camping with solar panels that lets my partner and I go indefinitely without city power for our medical devices, with enough to spare most days to keep our phones topped off. I’m currently using it a a oversized UPS for my desktop, but in a real emergency I’ll shut that down and move it to the bedroom.

Longer term, we’re planning on getting solar+house scale battery. I had one before and it got us though multiple days without power as long as we were careful.

Food, water and general supplies

55 gallon food safe drum of drinking water with the tablets that keep it safe for years. I have a todo item that reminds me to rotate it out every three years. We have two emergency bins, one with a hand crank/solar/usb powered radio and flashlight and assorted emergency supplies. The other has freeze dried hiking meals. They were the cheapest per meal per year of shelf life last time I did the math.

Medications

A real gap. I can’t get more than a one month supply of my meds, similar for my partner. While neither of us have immediate life threatening problems without them, we’d both be in rough shape in different ways. Don’t know what to do about this.

Backups

My desktop, my partners laptop, the NAS, and my VPS all have offsite backups to another country halfway around the world. I test recovery annually, and use healthchecks.io to notify me if they stop doing their daily backup. I need to finish getting my laptop backup running, but it’s been low priority as I mostly use it as a thin client for my desktop and keep a few files synced with Syncthing.

VPS

A few critical services run on it instead of my at-home NAS in case our home internet connection fails. It’s physically located several hundred miles away. Again, backed up elsewhere so I can relatively quickly recover it if needed.

NAS

Hot-swappable 4-disk raid with a spare sitting in the closet. That should get me through most issues, with the offsite backups for things that don’t. It also pings healthchecks with a few daily self diagnostics.

RaspPi

Really just running PiHole, so the only data to back up is the split dns config which lives in my notes on my desktop. Seems like a weak point, but could be replaced by the NAS, router, or my laptop pretty quickly.

Mobile devices

Backed up to their corresponding corporate overlords, except for photos and videos which go to immich on the NAS. I wish I had a better solution here.

Me

I have a notes directory describing the setup with configuration, docker files and playbooks for the various services in a local git repo on my desktop. I have printouts of the assorted recovery codes and a letter explaining all this in my filing cabinet alongside my will and advanced directives. We have enough technical friends that my partner can ask one to help, or just point an LLM at the note files and have it walk them through most things. I’ve audited the notes and git history for credentials and it’s clean. Just IPs and machine names, lists of services on each, clean docker files and basic maintenance instructions.

I think my biggest gap is what to do in a dual-failure case where I lose my home internet connection, and my desktop ssd fails. My data would be safe in the offsite, but I wouldn’t be able to reinstall Debian. My laptop would let me take care of most things for a while, but maybe I need to set up a mirror…

topgrade

I’m a simple man. Default Gnome on my desktop, i3 on my low end laptop. I don’t even really use the DE-ness of Gnome, I’m just too lazy to bother switching. On my laptop I also don’t even really need i3. kmscon + tmux would probably be fine except for those few times when I have to use a full browser for some stupid logon permissions or QR code jank.