Comment by neckardt
8 years ago
I've always found it too difficult to choose the "decentralized" option for many services. It's just not convenient enough to spin up my own gitlab server, or own email. I tried to do both of those things a while ago when I was still new to Linux, and gave up due to the number of steps involved which I inevitably fucked up.
The solution for me would be packages which hold my hand through the install process to make installing such software as easy as possible. Obviously, packaging software in this way would take way more work, and people qualified to do this would rather package more software rather than hold some noob's hand.
That being said, hopefully in the future when software gets even more mature, repackaging will become less necessary, and this type of packages might become more common, allowing decentralized systems to be easy enough to set up that they become common.
I saw someone post on Twitter saying they were tired of being their own sysadmin.
It's true - I could set up my own mail server, my own Git hosting etc etc, but why would I? I'd rather just pay Fastmail for email and GitHub for some private repos.
I'm my own sysadmin (for personal email, small HTTP server, an OpenVPN and a few other minor services for personal use) and while it did take me a non-negligible amount of time to get things running smoothly it now only requires a few minutes of attention every other week to apply security updates and make sure my backups are running smoothly. In exchange for that I have total control over my data and basically unlimited customization potential. I'm definitely not planning on stopping that.
I do use Github regularly however, but it's because of the "social network" aspect. If you want to interact with many open source projects it has to be on github nowadays. The network effect is strong.
Congratulations, you can configure your own mail server. You're already one in a million. Out of that group, maybe one in a hundred can do it nearly as securely as one of the big services. This is the reason why people use the big centralised services, and also the reason smaller ones don't survive: email is ridiculously over-complicated. You won't convince anyone it isn't by explaining that you managed to DIY in under a week.
Fortunately, rolling your own git isn't nearly as hard, and the percentage of people who could run a node compared to total users is larger. Hell, every person using git also has a fully-functional, secure and standard self-hosting stack already installed. Getting a GitHub-like web interface is similarly easy. This fundamentally reduces the risk of centralising, which conversely means that people don't have any qualms about using GitHub, since they can leave at any time. (Less true of issues, PRs, community, but hey.)
In either case, centralising has large benefits: one for handling complexity, one for giving you a community.
When you want decentralisation, it's because you don't want a single entity controlling what the ecosystem becomes. The circumstances where this is true are typically big utility-like things, where we care more about guaranteeing that water and electricity exist than the top end of providers' profits. Email is like this. You would never build your own power station, just like these days it would be bordering on negligent to use anything except Office365/GSuite/etc as your corporate email host. Lots of jurisdictions will create highly regulated marketplaces so you don't get Enron-California-style anti-competition. When things get that bad in Gmail-land, let us know.
[Edit: I was pretty snarky just there, but not at you! It was in general, I swear.]
I want to make that switch, but am rather intimidated by my inexperience in that domain. Are there any guides or tutorials you've used that you'd recommend?
2 replies →
Have you tried mailcow? I find it strikes a pretty good balance between running your own mailserver while not getting overwhelmed with details.
It runs in containers and provides a webserver, webmail, caldav, spam filter, updater... I have made an ansible role that will back up to a Borg repository every hour as well as restoring the latest backup upon installation if you need inspiration: https://galaxy.ansible.com/coaxial/mailcow/
If you use your own domain name, you can set mailcow to sync with your Gmail account so you have all your emails in mailcow and then pull the plug on Gmail without losing anything. I find it runs pretty well for me on a server with only 2gb of ram.
If you are on Windows, the equivalent is smartermail. For a fee it also supports ActiveSync, which simplifies client configuration and gives pseudo-push.
Decentralized =! inconvenience
Except that, 99% of the time, it does.
For the same reason that you don't opt for a dictator even though it is more convenient than democracy (until it isn't, at which point there is little you can do about it).
Also, you could also instead pay people to develop easier solutions for self-hosting. Or you could buy a service from a smaller hosting provider. There is more than the extremes of "google is email" and "I have to hand-carve my mail server".
So you are suggesting it is a moral obligation to choose a smaller provider, even if the largest provider is better?
Centralization happens because someone ends up doing it better than everyone else, and so everyone chooses to use that provider and they become the dominant force.
I get the need for diversity, but as an individual, I am going to choose the best provider, even if they are the biggest one.
5 replies →
Decentralized doesn't mean you have to host everything yourself, there are many other companies to pay to host things outside your server. You don't want everything hanging centralized on your hardware anyway, if your server dies, everything is down.
That's true, except it is not common for a server to "die" every second day. It is not a problem to have uptimes in years. But due to updates it is reasonable to have a few minute downtime every few months. If you require 100% high availability (which only handful of people and companies really need) then you can set up a cluser on Kubernetes/Docker.
We package GitLab with Omnibus - it makes the installation experience a breeze. See https://docs.gitlab.com/omnibus/ for more info.
We also offer a hosted service (GitLab.com), if that's more convenient.
Eh? It’s literally three shell commands to install GitLab. One to add their GPG key, one to add the upstream repo, and one to apt-get install the package. I bet there’s a curl | bash script to do all three as “one step”.
If you’re going to complain about something, at least pick something legit like managing backups or server uptime. The install itself couldn’t be simpler.
>Eh? It’s literally three shell commands to install GitLab
As if installing gitlab was the last step in setting up a highly available and disaster safe git server.
100% agreed. Maintaining a self hosted web service is a demanding task. It's not about updating to get some new features right when they're out - it's about security, and it's a real pain. The installation can get messed, so what? You're not using the tool yet. You can get a new VM. But when you're updating the machine the holds your code (heck, even GitLab.com had their issues with updates!), or the machine that holds your mail service - things get scary. Installation is not at all the issue.
6 replies →
for the one step curl | bash glory:
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash
For EE:
curl -s https://packages.gitlab.com/install/repositories/gitlab/gitl... | sudo bash
>>Eh? It’s literally three shell commands to install GitLab
It was not always that way, they have made huge improvements on the install path over the last couple of years.
I got tired of managing all that software so I just moved to containers. The Docker Hub has pretty much all I need, and if it doesn't, it's much easier to get it working than spinning a new VM or trying to install it together with a bunch of other software and keep them all up to date.
Have you tried Gitea [0]? It's incredibly easy to setup, and if you run it on Debian you can setup Unattended Upgrades [1] once then you pretty much never have to worry about it again.
[0] https://docs.gitea.io/en-US/
[1] https://wiki.debian.org/UnattendedUpgrades