The problem with asserts is that they are pretty dramatic and you crash the entire program.
We generally did this in the avahi libraries, be fairly liberal with asserts that "shouldn't happen", it is a source of complaints though because basically you can be using a third party library that uses avahi and have your program crash due to a bug in that library, or in avahi. It's extra fun when using some historical libc systems such as "NSS" and you load a plugin to do hostname resolution, which nss-mdns does.. now you can have any program on the entire system crash if you are assert happy.
On the one hand I agree that if the result is going to be memory un-safety then perhaps you should assert, but more ideally you'd just fail gracefully and throw or return an error. That can sometimes be tricky though, if there is no good way to return an error or return a NULL value or similar. Depending on the API.
But in the case of curl_getenv, returning NULL seems a valid possibility (https://curl.se/libcurl/c/curl_getenv.html) as that is indicated to be done if you don't find the requested environment variable. Arguably the NULL environment variable is not found. so, this feels likely to be acceptable. Though I could see an argument for you now assuming the environment variable you were actually looking for not existing, but you didn't actually ask for one, and now your logic is broken and maybe you introduce a different class of security bug because you change your behaviour based on some environment variable not existing.
Currently my biggest problem isn't ads, it's all the apps now will find ANY excuse to send you a notification in order to keep their "Daily Active User" count high.
You turn off more and more categories and they'll still find a reason.
In Sydney, south-facing panels typically produce around 30% less energy than north-facing ones. The steeper the roof, the less they’ll produce. They’ll also produce much more energy in summer than winter.
In the far north, the difference isn’t as great and in Townsville south-facing solar panels will only produce around 15% less energy overall than north-facing ones. Because Queenslanders generally use more electricity in summer than winter due to air conditioner demand, the fact that south-facing panels have considerably higher output in summer can improve self-consumption.
In Darwin, south-facing panels produce about 17% less electricity overall than north-facing ones, and, like in Townsville, they have considerably higher output in summer than winter.
In Australia where North is “optimal”, even South facing panels produce only 20-30% less and East/West about 15%. It does vary a bit by latitude but it’s not at all pointless to install them in other orientations in many places. I have not done the math to see how much of the world this extends to, but it applies to a fairly large chunk of Australia.
Source: https://www.solarquotes.com.au/panels/direction/
Tesla’s system also had non solar tiles so you could just skip the panels in whichever parts you wanted.
Roof construction is quite different here to the US though. We never have the plywood layer, it’s either ceramic tile or Colorbond steel directly onto usually wooden sometimes steel beams.
I remember the talk about the Wii/WiiU hacking they intentionally kept the early boot code in cache so that the memory couldn’t be sniffed or modified on the ram bus which was external to the CPU and thus glitchable.
Have been using that weekly since probably 20 years. Will change your life :)
My other favourite is I very often SSH with -v to figure out why the connection is hanging, you rapidly figure out if DNS is failing, the TCP connection doesn't open, it does open but no traffic flows at all or it opens and SSH negotiation starts but never finishes. You can learn a lot just from this about what is wrong.
Back in the day (MySQL 5.0-5.5 era, when I was working at MySQL/Sun/Oracle in the MySQL support team) the MySQL documentation team was truly amazing and sets the standard for me even today compared to many other docs teams I see.
They had a very long and comprehensive manual. The manual on each page inter-linked easily to switch between the relevant page for different major versions with a dropdown version selector (3.x, 4.x, 5.0, 5.1, 5.5..etc).. and if a page had moved or didn't exist it always accurately redirect to the correct page as you did that switch.
And almost every single engineering change that ever mattered to me made it into the changelog and also had relevant docs. I could largely rely on it and didn't need "git log" like I mostly need today to figure out what changed in a version.
Partly this was process, every closed bug/change went to the docs team to process.. but the team was also fantastic and converting that into relevant docs and writing great docs.
A shame if that has been lost, they did have a stack of layoffs recently in MySQL.. apparently the developer team is also heavily down from where it was. I am sure this writing is a little biased but interesting reading never the less:
https://mariadb.org/reading-the-room-what-europes-mysql-comm...
I still have one of the early green OLPC laptops kicking around that I got at linux.conf.au 2005, in part because they were (or were thinking of) making use of avahi as part of the mesh stuff. They are quite fun to look at.
The project was quite interesting and exciting, and I really miss the era of custom linux desktops, phones, tablets etc being viable projects, it's a shame the project never really directly worked out.
I would argue that iPadOS (built on iPhone's coat tails) moved the field forward significantly in terms of isolation and user security.
While this has left a long tail of inconveniences, many resolved and some not, I am very confident that using 1 app on my iPhone/iPad will not leak data to another in any case that I am likely to care about as a non-significantly interesting person (political figure, etc).
... and for those people Apple even makes lockdown mode to move the bar, while acknowledging it adds extra inconvenience: https://support.apple.com/en-au/105120
I have no such confidence about macOS, Linux or Windows, in fact the reverse. macOS has done the best at trying to bolt on some sandboxing (and linux has it too) but that's still very holey and not all-in like iOS/iPadOS has ended up.
Yes, I know there have been many bugs and leaks in iOS but the security level is far and above the desktops currently, and designed that way from the ground up. So when they finally make something work like copy and paste or sharing between apps, etc... it's by and large done very well.
It's been very difficult to add that kind of thing to Linux because you're trying to do the reverse and lock things down and it breaks everything... making it very challenging.. as opposed to Apple where basically nothing useful worked at the start (no copy/paste, one app at a time, no meaningful filesystem, etc).. but managed to get the product successful in the limited state and has slowly unlocked that stuff over time. Admittedly very slowly.
I cannot speak for Android as I just have never used it or surrounded myself in info about it's design, security, etc.. it may well be very similar although they from my casual observation seemed to do a much worse job at granular privacy permissions (e.g. for the longest time permissions were all granted at install time, and so many apps want so many most people are blind to it.. as opposed to Apple's model where even if notarised for something on the app store in most cases you have to agree to it when the app first uses it.. I know they fixed that a while back but I have no idea how well things have transitioned to that now). As a very techy person deeply knowledge in many things, and using desktop Linux since 2002, it's kindof a hilarious personal failing that I have never used Android.. I really should try and resolve that at some point.
It wouldn't surprise if Apple had fixed this, it's the sortof thing they would fix, but it may be worth trying with 2 devices not from the same iCloud account. Wouldn't surprise me if the code paths were subtly different in that case.