Can buy brick pavers for that and you still have to purchase the pebbles to go in it…

https://ubuntu.com/server/docs/

I do not lock forward to needing to upgrade the TV.

Going to need containerised vscode in this world.

But I never see them anywhere else. Especially streaming. A real loss.

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.

Of course, this is the entire reason behind the error return traditions of Golang and Rust, e.g: https://doc.rust-lang.org/book/ch09-00-error-handling.html

Which basically says what I said above :)

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.

As always everything is a trade-off...

You turn off more and more categories and they'll still find a reason.

Quote from the article:

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.

This hotel and the one which has a red phone “Popsicle Hotline” at the pool to order a waiter to bring your kids a tray of icy poles: https://www.gsb.stanford.edu/insights/power-free-popsicle

Sort of though. Still private beta since July 2025.

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.

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...

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.