Earlier quoted context omitted.
> docker There's your problem. Docker adds indirection on storage, networking, etc., and also makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. If you stick to things that can be deployed as an upstream OS vendor package, or as a single binary (go-based projects frequently do this), you'll likely have a better time in the long run.
Maybe. There are pros and cons. Docker means you can run two+ different things on the same machine and update them separately. This is sometimes important when one project releases a feature you really want, while a different one just did a major update that broke something you care about. Running on the OS often means you have to update both. Single binary sometimes works, but means you need more memory and disk spa…
Self-Host and Tech Independence: The Joy of Building Your Own
61–70 of 247 posts
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#62Earlier quoted context omitted.
I didn't mean the two paragraphs to imply that they are somehow opposites (though on hindsight I obviously did). There are tradeoffs. a single binary is between docker and a library that uses shared libraries. What is right depends on your situation. I use all three in my selfhosted environment - you probably should too.
If you are using docker, do you save anything by using shared libraries? I thought docker copies everything. So every container has its own shared libraries and the OS running all those containers has its own as well.
If your images use the same base container then the libraries exist only once and you get the same benefits of a non-docker setup.
This depends on the storage driver though. It is true at least for the default and most common overlayfs driver [1]
[1] https://docs.docker.com/engine/storage/drivers/overlayfs-dri...
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#63I self-host most of what I need but I recently faced the ultimate test when my Internet went down intermittently. It raised some interesting questions: - How long can I be productive without the Internet? - What am I missing? The answer for me was I should archive more documentation and NixOS is unusable offline if you do not host a cache (so that is pretty bad). Ultimately I also found out self-hosting most of what…
https://kiwix.org/en/ and some jellyfin setups are a great offline resource. But yeah, things like NixOS and Gentoo get very unhappy when they don't have Internet for more things. And mirroring all the packages ain't usually an option.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#64> I always say to buy a domain first. You can only rent a domain. The landlord is merciless if you miss a payment, you are out. There are risks everywhere, and it depresses me how fragile is our online identity.
If ICANN-approved root.zone and ICANN-approved registries are the only options.
As an experiment I created own registry, not shared with anyone. For many years I have run own root server, i.e., I serve own custom root.zone to all computers I own. I have a search experiment that uses a custom TLD that embeds a well-known classification system. The TLD portion of the domainname can catgorise any product or service on Earth.
ICANN TLDs are vague, ambiguous, sometimes even deceptive.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#65Earlier quoted context omitted.
If you are using docker, do you save anything by using shared libraries? I thought docker copies everything. So every container has its own shared libraries and the OS running all those containers has its own as well.
Not necessarily. You are still running within the same kernel. If your images use the same base container then the libraries exist only once and you get the same benefits of a non-docker setup. This depends on the storage driver though. It is true at least for the default and most common overlayfs driver [1] [1] https://docs.docker.com/engine/storage/drivers/overlayfs-dri...
Let's say some Heartbleed (which affected OpenSSL, primarily) happens again. With native packages, you update the package, restart a few things that depend on it with shared libraries, and you're patched. OS vendors are highly motivated to do this update, and often get pre-announcement info around security issues so it tends to go quickly.
With docker, someone has to rebuild every container that contains a copy of the library. This will necessarily lag and be delivered in a piecemeal fashion - if you have 5 containers, all of them need their own updates, which if you don't self-build and self-update, can take a while and is substantially more work than `apt get update && reboot`.
Incidentally, the same applies for most languages that prefer/require static linking.
As mentioned elsewhere in the thread, it's a tradeoff, and people should be aware of the tradeoffs around update and data lifecycle before making deployment decisions.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#66Earlier quoted context omitted.
It introduces some pretty important risks of its own though. If you accidentally delete/forget a local private key or lose your primary email domain there is no recourse. It's significantly easier to set up 2FA and account recovery on a third party service Note that I'm not saying you shouldn't self-host email or anything else. But it's probably more risky for 99% of people compared to just making sure they can recov…
I have seen much more stories about people losing access to their Gmail because of a comment flagged somewhere else (i.e YouTube) than people losing access to their domains (it is hard to miss all these reminders about renewal and you shouldn't wait until then anyway so that's something under you control). And good luck getting anyone from Google to solve your problem assuming you get to a human.
Google will never comment on the reasons they disable an account, so all you've read are the unilateral claims of people who may or may not be admitting what they actually did to lose their accounts.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#67Earlier quoted context omitted.
Isn't depending on Claude to administer your systems rather divergent from the theme of "Self-Host and Tech Independence?"
Not in this case. It's a learning accelerator, like having an experienced engineer sitting next to you.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#68I get why you want to self host, although I also get why you don’t want. Selfhosting is a pain in the ass, it needs updating docker, things break sometimes, sometimes it’s only you and not anyone else so you’re left alone searching the solution, and even when it works it’s often a bit clunky. I have a extremely limited list of self hosted tool that just work and are saving me time (first one on that list would be fir…
>>> if the company is respecting privacy It's very rare to see companies doing it, and moreover it is hard to trust them to even maintain a unique stance as years pass by.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#69> I always say to buy a domain first. You can only rent a domain. The landlord is merciless if you miss a payment, you are out. There are risks everywhere, and it depresses me how fragile is our online identity.
"You can only rent a domain." If ICANN-approved root.zone and ICANN-approved registries are the only options. As an experiment I created own registry, not shared with anyone. For many years I have run own root server, i.e., I serve own custom root.zone to all computers I own. I have a search experiment that uses a custom TLD that embeds a well-known classification system. The TLD portion of the domainname can catgori…
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#70Earlier quoted context omitted.
Similarly, I was reconfiguring my home server and having Claude generate systemd units and timers was very handy. As you said you do need to know the material to fix the few mistakes and know what to ask for. But it can do the busywork of turning "I need this backup job to run once a week" into the .service and .timer file syntax for you to tweak instead of writing it from scratch.
Isn't depending on Claude to administer your systems rather divergent from the theme of "Self-Host and Tech Independence?"
But if I didn't know how to do it myself, it'd be useless- the subtle bugs Claude occasionally includes would be showstopper issues instead of a quick fix.