There's no atmosphere to attenuate hard radiation, so rock overhead is the next best thing.
There's no gravity to contain an atmosphere, and domes are expensive and time consuming to build. Meanwhile the crews are exposed to radiation.
There's nothing but regolith on the surface of the moon-- finely powdered rock of unknown (and likely poor) assay for vital ores and minerals useful to bootstrap a colony.
A cave provides shelter, more assay-ably dense ore resources, potentially water in the form of subsurface ice, and potentially a vitrable (melted, glassified rock) cavity to contain a viable, pressurized atmosphere on the quick.
A cave on the moon is a find. Given the potential for neocolonialism in the next decade or three, it's a boon for whatever program discovers one.
Unbound will take updates via API. You could either write exit hooks on your clients, or use the "on commit" event on isc-dhcp-server to construct parameters and execute a script when a new lease is handed out.
I used to selfhost more, but honestly it started to feel like a job, and it was getting exhausting (maybe also irritating) to keep up with patches & updates across all of my services. I made decisions about risks to compromise and data loss from breaches and system failures. In the end, In decided my time was more valuable so now I pay someone to incur those risks for me.
For my outward facing stuff, I used to selfhost my own DNS domains, email + IMAP, web services, and an XMPP service for friends and family. Most of that I've moved off to paid private hosting. Now I maintain my DNS through Porkbun, email through MXroute, and we use Signal instead of XMPP. I still host and manage my own websites but am considering moving to a ghost.org account, or perhaps just host my blogs on a droplet at DO. My needs are modest and it's all just personal stuff. I learned what I wanted, and I'm content to be someone else's customer now.
At home, I still maintain my custom router/firewall services, Unifi wireless controller, Pihole + unbound recursive resolver, Wireguard, Jellyfin, homeassistant, Frigate NVR, and a couple of ADS-B feeders. Since it's all on my home LAN and for my and my wife's personal use, I can afford to let things be down a day or two til I get around to fixing it.
Still need to do better on my backup strategies, but it's getting there.
Gandi changed their TOS and price structure last year, so I ported everything over to Porkbun for a small savings, but mostly as a big middle finger to Gandi.
If you're gonna get banged that kind of cash for functions you're already using, you may as well look at better registrars, and get better value for your spend.
Many apps can act as installer aps. Installing an app is basically the process of unpacking the APK file into a directory where all the other user.apps are stored and registering it with the system.
The challenge, such as it is, is making sure two different installer apps aren't trying to manage the same app package.
So if you've installed an app that's available from one of the F-Droid repos that's also available on Play Store, both apps may try to update it. Its not a common conflict since the F-Droid versions tend to have a different signature than the Play Store versions, so the other installer tends not to try and overwrite it.
As for how the F-Droid scene works, there are different collections of packages curated by different teams. These curated collections are called repositories, or repos as I mentioned above. Each repo tends to have a unique focus for the apps they support. They build and sign the apps so the installers know the provenance of a given package.
As for the installer apps, they are simply clients that can subscribe to different repos and collate the indexes of applications available on each. When you search for an app, you're really searching the index and in the event you get multiple hits, your client app should let you select which repo you want to pull the APK file from. That client app may then attempt to update that app as newer versions become available.
Finally, to come to the point and answer your question: You can install the new app (e.g., Droid-ify) alongside F-Droid and begin configuring it. Maybe just only have auto-updates enabled in one of them. They will both provide similar functionality for supporting multiple repos, installing and auto-updating apps, though they have different UIs with different ergonomics and workflows.
Myself, I have both F-Droid and Droid-ify installed, and I still use the Play Store. I mainly use Droid-ify because I like the cleaner UI, but I understand F-Droid finally updated their UI as well. (It was needed, IMO). Droid-ify has the auto-update job for now.
edit: Apparently I forgot that I uninstalled F-Droid some time ago. Just checked and its not there anymore. Oops, I lied.
My question here is directed to other readers: I find the traffic layer in Gmaps to be my most used feature for local navigation. It's the one feature I really do use every day before I drive home from work to decide which way I'm going to take to get home.
I see there are tutorials to define a map overlay in OsmAnd for traffic using Google's API that are dated from a few years ago. Has anyone here successfully done this, and do these tutorials still work in 2024?
It's not FOSS but you can do this in Tasker easily enough.
edit: I wasn't satisfied with what I said, so here's another approach using things available on F-Droid.
With Termux, Termux:API, and Termux:boot, you can use termux-job-scheduler to run a script to calculate your remaining time to a target date-time (use UNIX timestamp for the calculation and strftime to format it) and then use termux-notification to publish a notification on your system bar. You'd use termux:boot to make sure the script gets (re-)scheduled after each reboot.
Termux is just generally useful for a lot of things. I think its worth the storage to maintain it, and I use it quite a bit myself like I use Linux terminal on the daily.
I also use Tasker quite a bit, and have your specific countdown use case implemented already. It was counting down the number of days remaining to 9am local time of a specific date, and would notify me every morning at 9am. I can share an export if you'd like.
More, shelter.
There's no atmosphere to attenuate hard radiation, so rock overhead is the next best thing.
There's no gravity to contain an atmosphere, and domes are expensive and time consuming to build. Meanwhile the crews are exposed to radiation.
There's nothing but regolith on the surface of the moon-- finely powdered rock of unknown (and likely poor) assay for vital ores and minerals useful to bootstrap a colony.
A cave provides shelter, more assay-ably dense ore resources, potentially water in the form of subsurface ice, and potentially a vitrable (melted, glassified rock) cavity to contain a viable, pressurized atmosphere on the quick.
A cave on the moon is a find. Given the potential for neocolonialism in the next decade or three, it's a boon for whatever program discovers one.
edit: typos