Especially because TypeScript compiles down to JavaScript JS

SmegmaScript is just too close

Reddit is free. Other people paying for your free service is a very weak argument to bring up. If Lemmy dies today, nobody but hobbyists and amateurs will care. Just like with LE.

I’ve been there. Not every CA is equal. Those kind of CAs were shit. LE is convenient. There are more options though.

I actually agree. For the majority of sites and/or use cases, it probably is sufficient.

Explaining properly why LE is generally problematic, takes considerable depth of information, that I’m just not able to relay easily right now. But consider this:

LE is mostly a convenience. They save an operator $1 per month per certificate. For everyone with hosting costs beyond $1000, this is laughable savings. People who take TLS seriously often have more demands than “padlock in the browser UI”. If a free service decides they no longer want to use OCSP, that’s an annoying disruption that was entirely not worth the $1 https://www.abetterinternet.org/post/replacing-ocsp-with-crls/

LE has no SLA. You have no guarantee to be able to ever renew your certificate again. A risk not anyone should take.

Who is paying for LE? If you’re not paying, how can you rely on the service to exist tomorrow?

It’s not too long ago that people said “only some sites need HTTPS, HTTP is fine for most”. It never was, and people should not build anything relevant on “free” security today either.

People who have actually relevant use cases with the need for a reliable partner would never use LE. It’s a gimmick for hobbyists and people who suck at their job.

If you have never revoked a certificate, you don’t really know what you’re doing. If you have never run into rate-limiting issues with LE that block a rollout, you don’t know what you’re doing.

LE works until it doesn’t, and then it’s like every other free service on the internet: no guarantees If your setup relies on the goodwill of a single entity handing out shit for free, it’s not a robust setup. If you rely on that entity to keep an OCSP responder alive for free so all your consumers can verify the validity of your certificate, that’s not great. And people do this to save their company $1 a month for the real thing? Even running the shitty certbot in compute has a larger cost. People are so blindly in love with this “free” garbage. The fanboys will never die off

Following along with the style of your own post: YAML doesn’t suck, because I feel so.

Thanks for asking.

I get that, I really do, and I honestly believe you have exactly the right idea.

But on the other hand, you have to realize that not all of the money purely goes to enabling knowledge sharing with Wikimedia. This is not an election, it’s a company, non-profit or for-profit doesn’t really matter. There are still people paying off business expenses from your donations.

I fully understand the necessity of this, but you might just feel better if your $5 literally bought someone a meal or if it paid for a fraction of a business flight to promote Wikimedia.

I do give in small streams and I do large annual contributions. I’m entirely not opposed to sharing.

I prefer to keep the small donations to individuals who also prefer a reliable stream of goodwill. Larger organizations also prefer reliable streams, but they also receive millions in donations overall, usually with significant large donors.

If you look long enough, you’ll find enough material to not want to contribute to Wikimedia. If your contribution was only a drop in the pool to begin with, maybe this is one of the expenses that is not for you to carry.

https://wikimediafoundation.org/support/where-your-money-goes/ might be a good starting point.

https://www.wikimedia.de/2022/en/finances/ has some clear numbers up front, but I’m not sure if these only relate to Germany. I haven’t been following the sources recently.

Makes sense. If you’re contributing less than $1000 monthly to anything, you’re not making a difference. If you want dedicated people to be on the receiving end, who also do a great job, every single person will cost thousands each month. Wikimedia is literally spending millions each year.

Honestly, don’t try to hunt for the “best” spot to contribute your exact amount of spare money to, with the hope of having the largest possible impact. It won’t happen. Treat a good friend to some food instead.

If you really feel like you already got some value out of a service in the past, give what you can, without limiting yourself financially in the process. If you feel like you don’t have the $1 to spend for Wikipedia, don’t spend it. Don’t guilt trip yourself into donations ever. Your donation today will not prevent a service from turning into shit tomorrow. Pay for what you got

I’ve been a funding member of the Wikimedia Foundation for over a decade. I have looked at their finances several times before and during financing them.

As with a lot of similar non-profits, a considerable amount of donations does not go into “running the servers”. You have to judge this by yourself, but they don’t embezzle any money and there is a reasonable bottom line. Wikipedia continuously helps tons of people, and the people who run the operation enable that.

You can download a full dump of Wikipedia any day. Compared to other lying companies, they have been true on their promises for some time.

Of all the $1 I could spend in a year, the one I give to Wikipedia is probably the least wrong invested, and that $1 actually already makes a difference

We need it for IPv6. Don’t hate

Depends on the product. It’s just something to think about when signaling errors. There is information for the API client developer, there is information for the client code, and there’s information for the user of the client. Remembering these distinct concerns, and providing distinct solutions, helps. I don’t think there is a single approach that is always correct.

I don’t necessarily disagree, but I have spent considerable time on this subject and can see merit in decoupling your own error signaling from the HTTP layer.

No matter how you design your API, if you’re passing through additional layers, like load balancers and CDNs, you no longer have full control over all responses your clients receive. At this point it may be viable to always signal a successful backend connection with a 200, even if the process resulted in a failure.

Going further, your API may include partial success scenarios, think batch processing, then the result could be a mix of success and failure that doesn’t translate to HTTP status.

You could even argue that there is really no reason to couple your API so tightly with a concept of the transport layer it uses.

Respect the Accept header from the client. If they need JSON, send JSON, otherwise don’t.

Repeating an HTTP status code in the body is redundant and error prone. Never do it.

Error codes are great. Ensure to prefix yours and keep them unique.

Error messages can be helpful, but often lead developers to just display them in the frontend, breaking i18n. Some people supply error messages in multiple languages, depending on the Accept-Language header.

I feel like the time to hide information behind YouTube links is over. Feels like a link to a paywall article at this point.

5 nines imply a downtime of 6 minutes a year, or every 100,000th operation failing. That’s not great for a file system. I assume you picked the number arbitrarily, but still think about it.

And has been for so long, they already went through it once

Numbers give the wrong impression that one version follows another. Debian release channels exit alongside each other individually. Giving the release channels names helps to make that distinction. It also makes for an easy layout of packages in APT repositories.

Sid is and always has been Sid. If you were to assign numbers, what number should replace that name? There are perfectly working labels for release channels and there is no reasonable replacement.