Ever since arch got an installer I’m not sure I’d consider it hard anymore. Still dumps you into a command line sure but it’s a long way away from the days of trying to figure out arcane partition block math
RIP "I use arch btw"
Self-Host and Tech Independence: The Joy of Building Your Own
41–50 of 247 posts
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#42I 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…
> 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.
I completely disagree.
> Docker adds indirection on storage, networking, etc.,
What do you mean by "indirection"? It adds OS level isolation. It's not an overhead or a bad thing.
> makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates.
Literally the entire selfhost stack could be updated and redeployed in a matter of:
docker compose pull
docker compose build .
docker compose up -d
You have clean separation between your applications/services and their versions/configurations (docker-compose.yml), and yous state/storage (usually a NAS share or a drive mount somewhere).
Not only are you no longer depended on a particular OS vendor (wanna move your setup to a cheap instance on a random VPS provider but they only have CentOS for some reason?), but also the clean seperation of all the parts allows to very easily scale individual components as needed.
There is 1 place where everything goes. With the OS vendor package everytime you need to check is it in systemd unit? is it a config file in /etc/? wth?
Then next time you're trying to move the host, you forget the random /etc/foo.d/conf change you made. With docker-compose, that change has to be stored somewhere for the docker-compose to mount or rebuild, so moving is trivial.
It's not Nixos, sure. but it's much much better than a list of APT or dnf or yum packages and scripts to copy files around
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#43Earlier quoted context omitted.
If your trust is violated, typically the worst that happens is you are fed a couple more relevant ads or your data is used for some commercial purpose that has little to no effect on your life. Is it really worth going through so much effort to mitigate that risk?
Again, it's a value judgement, so the answer is largely personal. For me, yes. The social license we give these larger companies after all the violated trust doesn't make sense. If your local shop owner/operator that you talked to everyday had the same attitude towards your when you went shopping and exchanged pleasantries with most weeks, people would confront them about their actions, and that shop wouldn't last lo…
The cloud is someone else’s computer and an apartment is just someone else’s property.
How far do we take this philosophy?
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#44Earlier 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…
How can running a single binary under systemd need more memory/disk space than having that identical binary with supporting docker container layers under it on the same system, plus the overhead of all of docker?
Conflicting versions, I'll give you that, but how frequently does that happen, especially if you mostly source from upstream OS vendor repos?
The most frequent conflict is if everything wants port 80/443, and for most self-hosted services you can have them listen on internal ports and be fronted by a single instance of a webserver (take your pick of apache/nginx/caddy).
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#45Earlier 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.
I completely disagree. > Docker adds indirection on storage, networking, etc., What do you mean by "indirection"? It adds OS level isolation. It's not an overhead or a bad thing. > makes upgrades difficult as you have to either rebuild the container, or rely on others to do so to get security and other updates. Literally the entire selfhost stack could be updated and redeployed in a matter of: docker compose pull doc…
Tools like Ansible exist and can do everything you mention on the deploy side and more, and are also cross platform to a wider range of platforms than Linux-only Docker.
Isolation technologies are also available outside of docker, through systemd, jails, and other similar tools.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#46I propose a slightly different boundary: not ”to self-host” but ”ability to self-host”. It simply means that you can if you want to, but you can let someone else host it. This is a lot more inclusive, both to those who are less technical and those who are willing to pay for it.
People who don’t care, ”I’ll just pay”, are especially affected, and the ones who should care the most. Why? Because today, businesses are more predatory, preying on future technical dependence of their victims. Even if you don’t care about FOSS, it’s incredibly important to be able to migrate providers. If you are locked in they will exploit that. Some do it so systematically they are not interested in any other kind of business.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#47> The premise is that by learning some of the fundamentals, in this case Linux, you can host most things yourself. Not because you need to, but because you want to, and the feeling of using your own services just gives you pleasure. And you learn from it. Not only that, but it helps to eliminate the very real risk that you get kicked off of a platform that you depend on without recourse. Imagine if you lost your Gmai…
The risk may be real, but is it likely to happen to many people?
The reason why I bring this up is because many early adopters of Gmail switched to it or grew to rely upon it because the alternatives were much worse. The account through your ISP, gone as soon as you switched to another ISP. That switch may have been a necessary switch if you moved to a place the ISP did not service. University email address, gone soon after graduation. Employer's email address, gone as soon as you switched employers (and risky to use for personal use anyhow). Through another dedicated provider, I suspect most of those dedicated providers are now gone.
Yeap, self-hosting can sort of resolve the problem. The key word being sort of. Controlling your identity doesn't mean terribly much if you don't have the knowledge to setup and maintain a secure email server. If you know how to do it, and noone is targetting you in particular, you'll probably be fine. Otherwise, all bets are off. Any you don't have total control anyhow. You still have the domain name to deal with after all. You should be okay if you do your homework and stay on top of renewals, almost certainly better off than you would be with Google, but again it is only as reliable as you are.
There are reasons why people go with Gmail, and a handful of other providers. In the end, virtually all of those people will be better off in both the short to mid-term.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#48Earlier quoted context omitted.
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…
How can running a single binary under systemd need more memory/disk space than having that identical binary with supporting docker container layers under it on the same system, plus the overhead of all of docker? Conflicting versions, I'll give you that, but how frequently does that happen, especially if you mostly source from upstream OS vendor repos? The most frequent conflict is if everything wants port 80/443, an…
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.
Re: Self-Host and Tech Independence: The Joy of Building Your Own
#49I 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.