I think you are doing the post injustice by hijacking it. FOSS maintainers can get a burnout even without toxic users - hard deadlines and the understanding that people really rely on your project can do that to you.
e.g.: About 25 years I had developed some blogging software in the style of usemod (single executable, data stored in ./data) for coordination of and reporting about protests on throwaway VMs. This initially was a weekend project but spiraled out of control when it made its way through Europe and people called me for setups or features for other actions. My burnout was the result of trying to help grass root organizations while also being politically active myself and having a full time job. The solution was basically what the article says:
* invited more maintainers by dumbing down the implementation so that one does not need a black belt in perl to hack on it
* created minimal docs
* I found hoster in the scene who was competent and willing to do pro bono hosting in exchange for me being available in case of problems (he never called me).
If those "many successful services" are FOSS, you are a very rare breed of developers - one I have not yet encountered in almost 30 years of FOSS development.
Could you please link some of your projects? I could use some inspiration how to deal with entitled FOSS users who do not understand that they already got much more than what they paid for.
My initial reaction was that I have to use this just because of the buzzword density in the title. But after reading up, it looks like the author was pretty successful in moving the bloat from code to announcement title. I'll give this a try!
They should name their team DNS because that is what will be shown on scoreboards of all tournaments to which their players will have to travel with DB anyway.
Their reliability is so abysmal that I fly multi-hop flights from Berlin or to airports a few hundred miles off my destination if that allows me to not rely on them. Boats that go up and down the Amazon have not let me down the way DB reliably did.
This is regular reporting using end-consumer market rates to inflate numbers.
Just as you could not sell 127,271 bitcoins all at once at market value, you could not just sell cocaine worth $1.4 billion but still confiscated drugs, even in large quantities, are reported with end consumer market rates. Nowadays, if a report mentions that is talking about "street value", that is already a big plus in my book.
> I could be wrong, but I recall in many developing countries phones there are many teenagers who code on their phone because laptops (even tablets) are prohibitively costly.
Yes, I see that a lot here in the far south of Morocco.
> They might be wiring their phones up to some cheap keyboards, which is technically possible but I don't know if they're doing that.
I did not "get it" from the post itself, but it linked to a post that mentioned "subed", subtitle editing for emacs with syncing with/control of video playback in mpv. I could see myself doing that and then would be happy if I could also trim the video while I am at it.
> One question - how does this prevent mosquitos from breeding in other bits of standing water that I can't locate?
It cannot and that is not its purpose. Practically you should be able to locate any other breeding grounds by mere observation and then you have to eliminate them one by one until the mosquitos are left with the ones you set up.
> it is (from my experience) way more dangerous than LSD.
That is not necessarily related to the compound but the method of consumption. Natural sources of psychedelic compounds have, naturally, variances in potency. With Morning Glory seeds you also ingest some other probably pharmacologically active compounds, again in amounts that vary from seed to seed.
> Only if it doesn't matter that the script fails non-gracefully. Some scripts are better to either have explicit error handling code, or simply never fail.
Then handle those errors explicitly. The above will catch those error that you did not think about.
> If you're running earnestly, I would argue that the hardest thing about a SOC2 is ensuring that you stick to your guns on approaches that work for you and not adding cruft that you don't care about. If you let the latter happen, you will invariably end up a box-checker, and being a box-checker eventually contaminates a robust engineering / security culture.
That's spot on, not only for SOC2 but for many, if not most, relevant certifications. The most important part is "not adding cruft". Nothing sucks like being stuck in a ISO9xxx certified process because you over-specified your processes even though you'd get the "ISO9xxx-certified" label for 10% of what you did. Suddenly you cannot react with common sense anymore because doing so would violate contracts you made with exactly those big customers you got the certification for in first place.
OTOH the time of jumpers and dip-switches for configuring hardware state is over; I am not sure I want to give any gaming company any chance to persist not only in some management layer of my computer but also in peripherals.
It's a sad comment on society, that this comment is automatically flagged offensive because it contains the word "fuck". -- paraphrased from fortune files, offensive section
> [...] if you allow me to use that lingo which you won't but I don't care
> [...] + lots of text I didn't read
Understood.