We use them to pay online, of course. But the payment mechanism is different because most of the time they’re debit accounts not credit.

Most online places are now aware of Revolut’s disposable CC numbers and reject them. They haven’t worked for at least a year now. They’re basically useless.

I like the way Bunny.net does paid DNS, 20M monthly queries for $1 and $0.1/M after that. With an API included, ofc. Now that’s the kind of pricing I can get into as a self-hoster, not $20/mo.

GoDaddy advertises a lot, basically. So whenever a person who’s never owned a domain before searches for “get a new domain” they’re gonna get GoDaddy, NameCheap and (ironically) Google Domains as the top results. That’s pretty much all there is to it.

But you don’t have to develop anything. There are plenty of ready-made excellent tools you can just drop-in. The main fallacy is that what Github does is actually useful, or that the pieces it integrates are useful. 90% of Github is subpar for any given purpose. Consider all the possible types of software being developed and all the different release flows and support/issue flows, how could they possibly be shoehorned into a one-size-fits-all? Yet people try their damnest to do exactly that.

To do software development you need (A) issue tracking, (B) a clear release flow, and © a deploy mechanism that’s easy to use. A is a drop-in tool with lots of alternatives, B is unrestricted since Git is very flexible in this regard, and C is typically included with any cloud infrastructure, unless you’re doing on premise in which case there are also drop-in tools.

A, B, C are three distinct, orthogonal topics that can and should be handled separately. There’s no logical reason to shape any of them after the other. They have to work together, sure, but the design considerations of one must not affect the others.

It depends a lot on the setup you have, how many people, release flow etc. Issue tracking depends on the kind of software you do and whether you want a programmer-only flow or a full support flow.

Deploy pipelines will usually depend on the infrastructure, cloud solutions usually can integrate with several and there’s also common solutions and even FOSS ones, like Terraform vs OpenTofu.

Git frontends are a very mixed bag, generally speaking their main purpose is to hide Git as much as possible and allow programmers to contribute changes upstream without knowing much beyond the nebulous “PR” concept. Basically they’re mostly useless other than enabling people to remain dumb. A good Git tutorial and a good history visualization tool (git happens to include one called gitk out of the box) will do so much more to teach people Git, and there’s really no substitute for communication – using annotations to discuss pros and cons for a PR is badly inadequate.

These are ancient holdovers. Nowadays DNS hosting with API is a dime a dozen. You may have to pay for it occasionally but it’s not going to be even close to $20/mo.

Again, like OP said, those are typically distinct functionality: issue tracking, source control, deployment etc. GitHub bringing everything into one platform is atypical and obviously done for the goal of centralization. The more stuff you add to a platform the harder it makes it to leave or replicate.

But no, technically speaking you don’t need to have all of it in one place. There’s no reason for which you must manage everything together.

I don’t even understand why people like GitHub so much, its source management sucks. The fact it still doesn’t have a decent history visualization to this day is mind-boggling.

Look for ways to do things separately and you will find much better tools. GitHub’s “one size fits all” approach is terrible and only holds because people are too lazy to look for any alternative.

Time travel? It never stopped. Agriculture was always rife with legal child labor. Now it’s just seeping into other industries.

https://en.m.wikipedia.org/wiki/Child_labor_in_the_United_States#21st_century

What does “old network” and “new network” mean? What are they, LAN setup? Docker setup? Describe them better (netmasks, routing etc.)

Right, right, you just have to reinvent a dozen wheels, use only software that Kubernetes knows how to work with, and learn a bunch of new names for everything.

I do all that with docker… I fail to see what Kubernetes adds to that on a single machine.

She had a swimming ring.

https://geek-cookbook.funkypenguin.co.nz/recipes/keycloak/authenticate-against-openldap/

It builds on the Keycloak and OpenLDAP tutorials but they’re all very well covered.

I use Flym on Android. Sadly abandoned but still working great. It can import and export OPML, has an RSS search built-in and can retrieve the full version of a piece from the original website.

Write a document that describes the main points of your setup. That’s about it. You don’t have to teach them everything, just guide them. Like, if you use a certain Linux distro and Docker just say “I use Docker on Debian and the compose files are in that directory”. That should be enough to get someone started if they know Linux and Docker, and if they don’t they’re not going to learn it from your doc, they should go looking for someone who does.

Let’s face it, many of our self-hosted setups are DIY setups we make as a hobby. If you really want an out-of-the-box experience that can be administered by a non-techy there will be limits to what you can achieve.

All the apps on your phone have access to the phone identifier. As well as other information, like your Google account. It’s pretty trivial to tie a phone to you.

They have your identity the moment you put the sim in the phone. The phone have unique identifiers that are recorded when sold.

I check the return code from the borg backup job and issue a notification to my phone via NTFY if there was a problem.

Please note that return code 1 (warning) will be issued if a file changes while borg is backing it up so it’s very common if you backup log files for example. Which is why I only notify for code 2 or greater.

You can also do it the other way and simply issue a notification no matter what happened, and just list the return code as-is. This is probably better since you also get confirmation that the backup job is actually running.

desec.io

If you don’t already know the benefits it’s unlikely it solves a problem you have.

Even among its users many are using it because it’s cool rather than because they actually need it.

It’s a declarative system, meaning you can describe how it should be setup (using a magic strings you have to look up online) and then it “sets up itself” according to the description.

It’s normally something you’d use for mass and/or repetitive deployments.

It’s usefulness for a single system is debatable, considering you can achieve very close to 100% of “reproducibility” anyway by copying /home and /etc and fetching a copy of the package list.

Where the prescriptive approach is supposed to help is when you attempt to reproduce the system a long time later, after things like config files and packages have changed. But it doesn’t help with /home, it hasn’t been tested over long intervals, and in fact nobody guarantees long term compatibility for Nix state.