Post AhrZyeSIDnSsky0s2i by kravemir@hometech.social
(DIR) More posts by kravemir@hometech.social
(DIR) Post #AhrZydTfrAyXixeSYa by fabio@manganiello.social
2024-04-27T07:53:03.424172Z
0 likes, 0 repeats
Just migrated from #Bitwarden to #Vaultwarden.Same API, same features, same UI, and support for other DBs than MSSQL.One single stand-alone application vs. Bitwarden’s 10 Docker containers. 70MB of RAM vs. 2GB. 3MB of db storage vs. 300MB.Why is a password manager supposed to take so many resources in the first place? Just because it runs on a Microsoft-only stack and on .NET’s inefficient VM? Just because somebody thought that it was a good idea to separate everything into different containers (even icons and 2fa are modeled as separate services in Bitwarden)?It reminds me of my recent migration from Mastodon to Akkoma. I got 5GB of RAM and 300GB of storage freed up almost overnight, saved $70/month on running the server, while getting many more features. And that also makes me wonder why people still spend money on big machines to run bloated crap like Mastodon when alternatives exist that do the same job (and more) with 10% of the resources.Writing and running inefficient software that pointlessly consumes all the resources available on a machine should be a crime in a world with limited resources.Today’s developers, spoiled by IDEs, powerful machines, docker-compose and shortsighted “just throw more RAM at the problem” approaches, have forgotten how to write efficient software. Unjustifiably bloated projects like Mastodon and Bitwarden are the proof of how bad software quality has gotten over the past decade (and I would add also stuff like Kafka and Elasticsearch to the list).Unless you’re running weather simulations, real-time 4k rendering or deep learning models, a service with low-medium traffic should never take more than 2GB of RAM (and I’d argue that even 1GB should suffice).A password manager, a message broker or an ActivityPub service shouldn’t take more resources than a heavy OpenGL/ActiveX videogame to run. You should always be able to run a simple service with an API, some storage and a thin layer of processing on a RaspberryPi 3. If that’s not the case, then the service is badly designed, or built using bad frameworks (.NET, Java and Ruby on Rails, I’m looking at you).Time for developers to learn how to write good efficient software again. Even if that means giving them development machines with 2GB of RAM. After all, if we’ve sent people to the moon and probes to the outer solar system with machines equipped with just 0.1% of that memory, I don’t see why a program that memorizes your passwords is supposed to require much more.Software doesn’t eat the world. Only shitty software built on shitty frameworks does.
(DIR) Post #AhrZyeSIDnSsky0s2i by kravemir@hometech.social
2024-04-28T16:46:58Z
0 likes, 0 repeats
@fabio the most of today's technology is designed to scale,...But, non-linearly, where it becomes efficient with thousands (and more) of users on a single centralized cloud / SaaS.Rather than scaling via self-hosting, where groups / companies / projects would have their own (mini) instances running efficiently, even if they are of small or medium size yet.Things are moving towards global centralization...
(DIR) Post #AhrZyfYi7QC0BA1VgW by fabio@manganiello.social
2024-04-28T17:03:01.681082Z
0 likes, 0 repeats
@kravemir very good point there. I feel like we should make a distinguish between centralized and decentralized scalability.Scalability along the lines of “anyone can run the service on a machine with at least 1-2GB of RAM” isn’t the same as “your business can run the service by adding another razor server to their rack, or renting out another XXL instance on AWS”. We should definitely favour the first.