I want to inspire a renewed tradition of deliberate, planned software engineering, where quality and reliability are paramount, and flashy eye candy is an afterthought.
We need to defeat this bizzare cognative dissonance people face when they have to re-evaluate the place email holds in their mind. It's not some useless relic of the last generation to cast off in the course of chasing the shiny new.
- Built with open standards
- Fault tolerant
- Enjoys a wide variety of open-source clients & servers
- Has widely available implementations for almost every programming language
- Already being used for software development at scales greater than GitHub-style development has ever dreamed of
Screw that noise. Set aside your preconceptions and look at email for what it is. The things that make you "yuck" about email are more related to the bastardization of email *software* by corporate interests like Google and Microsoft, and have next to nothing to do with email itself.
Imagine if we lived in a world where reliable, cost-effective software was the norm, and failures were as rare as they are in other engineering domains. Instead we have a world where everything is fucking half-assed bargain bin shit piled upon 30 layers of abstractions, huge hulking Goliaths made entirely from feces, shoving everything else out of the way as it stumbles painfully slowly towards the window to paint a cat gif on your screen, then failing halfway through and burning your house down instead.
AND THIS IS CONSIDERED NORMAL
WHY ARE WE OKAY WITH THIS
Honestly if I could boil all design advice down to a single tip, "make it difficult to do the wrong thing" would be it
itch.io has a huge bundle going to support 'Racial Justice and Equality' https://www.gamingonlinux.com/2020/06/itchio-bundle-to-support-racial-justice-and-equality #GameBundle #Charity
Just a reminder to people @gamingonlinux doesn't need to cover what *you* want and skip over what *you* don't like.
We serve the Linux gaming community, not single interests. We try to cover a bit of everything. Deal with it.
You know, I empathise with GitLab here. git.sr.ht had a memory leak once. My solution was pretty interesting: I wrote a shell script on a cronjob set to every 5 minutes, which checked the heap size of the git.sr.ht backend and, if it was within a certain percentage of system memory, it sent a SIGTERM along and
Wait, no, none of that is what happened. What happened is I fixed the memory leak.
"GitLab has memory leaks."
Their solution is monkey patching their application to check its memory usage after every 16th HTTP request and commit suicide if it's too much. This page is telling sysadmins who install their own GitLab instance how to configure this.
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!