Highlighting personal experiences with rampant censorship on major platforms, the article advocates for the adoption of Free and Open Source Software (FOSS) as alternatives, emphasizing the importance of open dialogue in digital communities.
Seems like a fresh mirror here https://gitea.eponym.info/Mirrors/youtube-dl to fork and start it over somewhere else. Gitea is a great project. Now we need someone to fork and publish it over Tor or something. Decentralized solution would be a next step.
Diff between that mirror and the one from the web.archive.com looks good. I.e. no hidden/evil things inside. Looks safe to start over.
This is why the important projects must be thoroughly planned and tested in order avoid non-trivial infra or a blind cat situation.
And then it is a really good idea to leverage IaaC (Infrastructure as a code) which would bring the whole thing up really quick.
Yep, but how can you be sure the serverless provider will never go down? I've witnessed multiple times when AWS's services went down.
> If you're running a saas and the increased traffic comes from paying customers, you likely prefer a huge bill to downtime.
Well, in such situation, I would probably run more advanced container orchestrators such as Kubernetes which you will then configure to automatically spawn the additional server instances.
Of course there are certain advantages in running a serverless code as you have just mentioned, but since my primary concerns are "my data is mine" + "no vendor lock-in" + "I control all the gears", it is not the best option for me. Unless I want to run & provide the serverless services by & for myself.
It's always a game between the security (more freedom) and the convenience (less freedom). Though, for some, there is more freedom in the convenience (until they start to see their hands are in the digital cuffs :P)
Probably this means that there is no server you can SSH to nor need to maintain.
It could probably be called a serverhostage/server-lock-in computing, where someone else keeps the _shared_ server(s) away from you and runs other people's, potentially harmful, instructions as well :-)
Yeah, this is normal.
One bus can't fit more people than it physically can.
The high load can be alleviated by the use of more MX server DNS records (and the MX servers of course, across the different locations), LBs, smarter thresholds.
Of course nothing is a panacea.
Either way you will hit the AWS's limits or will get a huge bill. And then, even if you set up the budget limits, it still won't make the service more available once you reach the limits.
> This stack was created out of frustration due to the fact that to this day there's no easy way to have a full email server without the overhead of installing and configuring all servers needed to handle incoming and outgoing messages.
Interesting approach, though I solved this frustration by the use of a Docker and kept "my data is mine" + "no vendor lock-in" + "I control all the gears" approach. (Though, it's not perfect since VPS is ran by "someone" else.. but that place where you run this stack can be easily changed at your convenience).
Simple docker-compose.yml with 3 images and voila.
This AWS S3 SES setup looks far more complex than what I did using only 3 docker images: the postfix (for smtp), dovecot (for imap), opendkim (for email sigining & verification).
It's really easy to fire-up a VPS with a single click nowadays.
If someone is interested in the images I am using:
Then you just feed the images with the right configs (main.cf, master.cf, .., dovecot.conf, opendkim.conf).
It's also possible to template the configs and make the variable-based configs. Make things scale friendly.
I am also using Terraform to automate the server deployment/DNS record updates so it is easy to get from 0 to 100.
The only drawback is that you are the one to maintain the OS/SW upgrades, security, etc.. but that's something I really want to do by myself instead of relying on someone else :-)