I've been selfhosting for like dunno 10-15 years. Cheap kimsufi box, opensmtp, dovecot, later then rspamd, done. Never really had a problem. At one point telekom.de blocked my mailserver. I contacted them via postmaster@telekom.de (or something) explaining that while kimsufix boxes are notorious for shady stuff, this is actually a legit mailserver and they whitelisted me shortly after (yeah I was surprised too how smooth that went). So, yeah, can't confirm all the troubles everyone seems to get on about. However I do own the kimsufi box (and the corresponding IP) for a long time now, so maybe I'm just lucky.
Fully agree.
Also, jq exists, a simple example how open and simple interfaces (text streams) allow for extensibility. There is a reason why so much is built on top of "simple terminals".
> That means you have a mix of FORTRAN, ada, c, rust, some custom internal corporate language, and so on all mixed with the C++. If your build system cannot handle that mess i'm not interested
In that case I would just use the rust toolchain which I'm sure can handle this stew.
I'm using C/C++, which do provide a good level of type safety.
And no, types are absolutely not my problem. In fact, rigid type systems are a frequent source of practical problems, and they often shift the game to one where you're solving type puzzles -- instead of working on the actual functionality.
Come on, dude. C provides almost no type safety whatsoever. There’s no point in saying “C/C++” here, because you won’t adopt the C++ solutions for making your code actually typesafe.
Type safety is not a standardized term, and it is not binary. Being black and white about things is almost always bad. One needs to weigh and balance a large number of different concerns.
A lot of "modern C++" is terrible, terrible code precisely because of failing to find a balance.
I work for a Japanese company and if you've ever worked with them you know they go crazy with testing (often automated). I get bugreports like this constantly. And while you might argue if that's a use case or not (mostly it's not), a crash is still a crash! We do go the extra mile to analyze and fix those. It makes the software overall more robust and on occasion you really find a much severe underlying issue that would have exploded in your face also in other, more realistic workflows. Don't dismiss bugs without at least understanding what's happening! As others have stated, a lot of these weird issues are race conditions which might suggest a bigger problem in the design.
Yes! This sort of thing is always, always a real bug which can sometimes randomly show up in normal usage. Figuring out the root cause is really satisfying, so a good repro case (even if it’s just “spam this button a whole bunch and it usually crashes”) is valuable.
Or you can just shrug it off as a mysterious unknown glitch, and live with software that mostly works but occasionally crashes - like almost all software, sadly.
I still remember (well, have screenshotted) this amazing error I encountered in my first exposure to C++. I was writing code for an assignment implementing my own vector container from scratch, and got "no suitable user-defined conversion from "CSXXX::vector::r_iterator" to "CSXXX::vector::r_iterator" exists".
Thank you GCC for telling me that I'm missing a copy/move constructor (can't remember which it was). Clear as mud as always. At least with the several pages of template instantiation errors you can scroll to the top where useful information can sometimes be found.
