Whenever you make a String you’re saying that you need a string that can grow or shrink, and all the extra code required to make that work. Because it can grow or shrink it can’t be stored on the (fast and efficient) stack, instead we need to ask the OS for some space on the heap, which is slow but usually has extra space around it so it can grow if needed. The OS gives back some heap space, which we can then use as a buffer to store the contents of the string.

If you just need to use the contents of a string you can accept a &str instead. A &str is really just a reference to an existing buffer (which can be either on the stack or in the heap), so if the buffer the user passes in is on the stack then we can avoid that whole ‘asking the OS for heap space’ part, and if it’s on the heap then we can use the existing buffer on the heap at no extra cost. Compare this to taking a &String which is basically saying ‘this string must be on the heap in case it grows or shrinks, but because it’s an immutable reference I promise I won’t grow or shrink it’ which is a bit silly.

Here’s a little secret: All data types don’t actually exist. When your code is compiled down to machine code your computer just operates on collections of bits. Types are a tool we use to make code more understandable to humans. int and unsigned int tell us information about how numerical values are interpreted. bool tells you that only two values are going to be used and that the value will somehow relate to true/false. char tells us that the value is probably some sort of text. But again, everything is just stored as bits under the hood.

You can go even further and define new types, even though they might still just be numbers under the hood - you could for instance define a new type, e.g. Age, which is still just an integer, but it tells you the reader more information about what it is and what it might be used for. You might define a new type just for error codes, so at a glance you can see that this function doesn’t return an int, it returns an OsError, even if the errors are actually still just integer values.

C does however play somewhat loosely by these rules, and to try and ‘make your life easier’ will often ‘coerce’ types between eachother to make everything work. For instance, integer types can be coerced to booleans - 0 is false, everything else is true (even negative values). Later on you’ll find that arrays can ‘decay’ to pointers, and other fun surprises. Personally, I think this implicit coercion between types is one of C’s biggest mistakes. If types exist to help humans reason about code, what does it mean if the compiler needs to silently change types behind the scenes to make things work? It means the humans were sloppy and the compiler can only guess at what they actually wanted to do (and this is the best case scenario! What happens if the compiler coerces types in places humans didn’t expect? Bugs!).

There exist a spectrum of different behaviours in this regard, some languages are what we call ‘weakly typed’ (like Javascript, or to a lesser extent C) and other languages which are ‘strongly typed’. Weakly typed languages will try to implicitly convert types together to make things work: In Javascript if you try and add an integer to text "Hello!" + 52 the compiler will try to implicitly convert types until something makes sense, for instance in this case the compiler would say ‘oh, they probably want to add the text “52” onto the end’ and will produce "Hello!52". Sometimes this is handy, sometimes it introduces bugs. A strongly typed language will instead simply refuse to compile until you make the types line up.

There’s nothing inherently wrong with digital ID, provided it’s implemented in a zero-knowledge-style manner. In fact, it would be much better than what we have now: Uploading your physical photo ID to every company that is legally required to ask for it.

That’s one of the methods that SKG has suggested - just publishing the server API and leaving the actual (re)implementation of the server program to the community. That still leaves a lot of work for the community but at least it’s tractable, much more than reverse engineering raw network packets from scratch.

The servers may include third-party licensed code that the developers don’t have the rights to release

It’s pretty standard practise these days to have some form of secure enclave on an SoC - Arm’s TrustZone, Intel’s SGX, AMD’s SME/SEV. This wouldn’t be any different. Many camera ICs are already using an Arm CPU internally already.

As with everything, trust is required eventually. It’s more about reducing the amount of trust required than removing it entirely. It’s the same with HTTPS - website certificates only work if you trust the root certificate authorities, for example. Root manufacturer keys may only be certified if they have passed some level of trust with the root authority/authorities. Proving that trust is well-founded is more a physical issue than an algorithmic one. As it is with root CAs it may involve physical cybersecurity audits, etc.

This is just standard public key cryptography, we already do this for website certificates. Your browser puts a little lock icon next to the URL if it’s legit, or provides you with a big, full-page warning if something’s wrong with the cert.

You, the end user, don’t have access to your camera’s private key. Only the camera IC does. When your phone / SD card first receives the image/video it’s already been signed by the hardware.

Video evidence is relatively easy to fix, you just need camera ICs to cryptographically sign their outputs. If the image/video is tampered with (or even re-encoded) the signature won’t match. As the private key is (hopefully!) stored securely in the hardware IC taking the photo/video, any generated images or videos can’t be signed by such a private key.

Under the Dewey Decimal System, books on wood carving and river systems would not be placed together, nor would books on conflict resolution and gardening.

It’s almost like they’d be placed with books on related topics instead. This Maori traditional system is… not good. Imagine a system where the books are sorted by which Catholic patron saint they fall under, or which greek god they best represent. The librarians even admit in the article that it’s only practical if you’re already well aware of Maori mythos, everyone else gets ‘an opportunity to learn’ (i.e. be completely lost).

Rust has support for many embedded targets. I can personally vouch for the MSP430. Rust compiles down to an intermediate language which can then use the same compilers and linkers as C. For instance when compiling Rust for the MSP430, GCC-MSP430 is actually part of the toolchain.

Not really. While working at the OS-level can typically require ‘unsafe’ operations a core tenet of writing Rust is making safe abstractions around unsafe operations. Rust’s ‘unsafe’ mode doesn’t disable all safety checks either - there are still many invariants that the Rust compiler enforces that a C compiler won’t, even in an ‘unsafe’ block.

And even ignoring all of that, if 10% of the code needs to be written in Rust’s ‘unsafe’ mode that means the other 90% is automatically error-checked for you, compared with 0% if you’re writing C.

Here’s the generation statistics of the BN-800 reactor I mentioned before: https://pris.iaea.org/PRIS/CountryStatistics/ReactorDetails.aspx?current=451 It’s been operating at about 70% of it’s rated capacity basically since it was first turned on, that’s large scale power generation. Breeder reactors have been in commercial use for decades (see also: Phenix and Superphenix).

The simple reason why breeder reactors aren’t the default is because most reactors don’t need to be breeders. The two main upsides of a breeder reactor is a) breeding of nuclear material, which as I said before was only ever a concern in the very early days of nuclear power. We have thousands of years’ worth of fuel available now. b) The reuse of nuclear waste for additional power generation. Of course you have to have nuclear waste to reuse first, which necessitates many other, non-breeder reactors already being in use, so breeder reactors are usually restricted to countries that already have significant investment into nuclear power, like France, Russia, China, etc… If you don’t need to breed more nuclear fuel, and you don’t have waste to reprocess you might as well keep it simple and build a regular LWR reactor.

The Wikipedia page for breeder reactors has a whole list you can even sort by output capacity. For example, the BN-800.

There have been plenty. For example, the CANDU series of reactors developed in the 1950s and 60s. Breeder reactors were quite popular during the early days of nuclear power, as it was initially thought that there was maybe only 100 years’ worth of (easily accessible) nuclear material on earth, rather than the thousands (or tens of thousands) of years’ worth we know of now, due to both more reserves being discovered and also easier methods of fuel enrichment being developed. The fact that breeder reactors have fallen out of favour due to abundant fuel reserves certainly says something.

Breeder reactors produce more fissile material than they consume.

Not many people know the history of the treaty. It basically was signed under duress. Prior to the meeting where it was signed all but one of the Maori tribal leaders were against signing the treaty, even the Maori version. What was said at the signing was purposely never recorded, but considering the existential threat of the New Zealand Company (NZC) on the horizon (the primary reason a treaty was even being discussed), it is believed that the Maori leaders were basically given the choice of ‘sign this treaty and be a part of the British empire, or don’t and have no legal rights against the whims of the New Zealand Company’.

The New Zealand Company was a private British company with the goal of obtaining as much land as possible at any cost, and the Maori would have had zero legal protections unless they were part of the British empire. Without a treaty the NZC would have been able to push out the Maori entirely with no repercussions. The British people who brought the treaty to the Maori leaders knew this was coming, and wanted to avoid it.

Signing the treaty was a quick and dirty solution to the quickly approaching NZC and was responsible for preventing the worst of the damage, but it is a very flawed document. The translations were rushed, and vague. Basically everyone was against signing it, but they knew it was the least worst option available. It was never designed to be the core document underpinning a nation, merely a speed bump to stall the private annexation of New Zealand.

The MSP430 is just the chip I happen to use at work, if you’re not convinced you could try looking for an actual ultra low power chip, I found the STM32U0 at 70uA/MHz and the STM32U5 at 16uA/MHz in the first result.

Even ignoring selecting a more efficient micro, a smattering of tiny ceramic caps will buy you a few hundred microjoules for bursts. If you’re already operating at 2V you can get a 6V rated 100uF cap in a 1210 package - and that’s after considering the capacitance drop with DC biasing. Each one of those would buy you 200 microjoules, even just one ought to be plenty to wake up for a few tens of milliseconds every second to get a reading from some onboard peripheral (as an example) then go to sleep again.

For sure, you’re not going to be doing any heavy lifting and external peripherals could be tricky, but there are certainly embedded sensor use cases where this could be sufficient.

It’s more than you think. I work with the MSP430 microcontroller, which is capable of a sleep current of 40nA @ 2V, full active mode at 140uA/MHz with all onboard peripherals turned on. With this you could achieve almost a 20% on-off ratio with a 1MHz clock, or keep it in active mode all the time at ~150kHz, which is sufficient for many embedded sensor applications.