BartyDeCanter

Immich is great. I run a small friends and family instance on a NAS and I’ve never had a hiccup that took more than ten minutes to fix. My backup system is borg to a Hetzner storage box nightly with a healthchecks.io check set to email me if it goes more than 48 hours without a success. Cheap, reliable, and fast enough for me.

Serious question: Why can you handle the ads? I’m serious. Why do you accept that something you have purchased, something you own, should be pushing ads at you? Broadcast services makes some sense, they have to make money somewhere. But something you bought? Why?

• I have the radical idea that when I own something, I should actually own it.
• I’m a software engineer, both professionally and hobby. Developing on a non Unix platform is bullshit
• HaikuOS is 20 years too late
• What is the alternative? Windows is user hostile ad infested crap, MacOS is a prettier flavor of user hostile ad infested crap. The BSDs have their place, but a daily desktop or laptop isn’t really it.
• Copyleft FOSS or GTFO
• I don’t do a massive amount of customization, but the things I do I want to have. I know that will be the case with Linux. Who the fuck knows with closed source software
• When I find a bug, missing feature, or something just isn’t right I can fix it, file a bug, or just talk to the actual human beings who wrote it. Good luck with any of that in non-FOSS unless you are spending $$$ on a corporate account.

In iOS there is an app called ShutterDeclutter that every day shows you the all photos you took on that day of the year in your collection and has a swipe left/right to delete or keep each one. It makes the job of reviewing photos manageable for people with multi decade long albums. I really want Immich to add that feature.

You mean run TaskWarrior and host a sync server, right?

Take my upvote and get out.

Congratulations! I’ve been using Jellyfin for several years now and the quality has consistently improved. It’s a great tool.

I run Vaultwarden on a VPS for some family and friends, along with a few other services. The way I have dealt with this is a physical printed out letter that explains the basic setup, where my digital notes/config/dockerfiles are, and most importantly what bills need paid to keep it all running. Next to that is a sealed envelope with recovery passwords to my vault and some other things.

Both of them are kept next to my will in a filing cabinet, so that if I’m hit by a bus my family will have the info on what to do. The system is stable and the bills are on autopay, so they won’t have to immediately deal with it, but the instructions are there when ready. As part of it I have designated a friend as my “digital executor” to follow the instructions.

The general outline of the letter is:

To whoever is handling my affairs, thank you for reading this. This letter explains a small collection of computers I run that some friends and family rely on for photos, passwords, and a few other things. Nothing here is an emergency in the first hours or days. The goal of this letter is to help you keep things running long enough for those people to copy their own data out, and then shut everything down cleanly. You do not need to be technical to do the first and most important parts. The later parts will need a technical person, and I name one below.

A companion to this letter is a SEALED ENVELOPE that contains the passwords, keys, and account logins. This letter deliberately contains NO passwords or secrets. If you have this letter but not the sealed envelope, find the envelope before going further - almost nothing can be accessed without it. Checklist of what the envelope should contain is in Section 7.

1. Short Overview
2. Service/Hardware/Users Chart
3. The Bills to Pay
4. The Password Manager
5. What to Do
6. Full Instructions and Notes Location
7. The Sealed Envelope Contents
8. Digital Executor

I’m a middle aged white guy. Most of the time a stranger talks to me in public it’s to ask me for money or try to convert me. But twice this year someone just wanted to compliment my outfit. I was flying high from that for days and still smile thinking about it.

So, thoughtful words every time.

20 years?!? 20 years ago I was reading documentation on open source projects that were 20 years old then.

I remember hearing about D fairly early on and thought it sounded interesting, but there wasn’t a compiler for the kind of targets that I was working on. And then every time I’ve heard about it since it’s been that there was some interesting things being developed for it, but that some inscrutable community drama meant that it once again was floundering. ciiiiiircle of life

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.

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.