If there’s moisture in the filament it vaporises in the extruder, causing steam bubbles that expand and disrupt the laying down of plastic, usually causing inconsistent extrusion lines (which itself causes poor layer adhesion). Some of the filament may end up being heated in the extruder slightly longer than other bits depending on these steam bubbles, which can cause overheating issues like stringing and oozing, etc…

Not to mention that filament that has absorbed water tends to become more brittle, which can lead to the filament snapping off before reaching the extruder. As a result, a filament’s shelf-life is usually dictated by how quickly it absorbs moisture (and also whether UV from the sun weakens it at all, but that’s a lot easier to manage).

What’s your ambient humidity? It’s usually around 80% here and I can barely get my dryboxes down to 30%

AES-256 is fine actually. The best known quantum attack reduces key strength from 256 bits to 254.4 bits. The problem is that in order to use AES (which is a symmetric encryption scheme) you need to exchange keys using an asymmetric system like RSA, which is known to be weak to quantum attacks.

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.

C++ actually does this ‘optimisation’ for std::vector<bool>. I say ‘optimisation’ because it effectively trades time for space, which is usually the opposite of what you want - space is cheap, time usually isn’t. Sometimes it’s a good tradeoff though - it’s common in embedded development where you might only have a few kB of RAM.

I got through two chapters of Artemis before I gave up. Project Hail Mary, however, is very good.

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

Bubbles are not an existential threat to society. We’ve had like four bubbles in the past 20 years.

This is how bubbles always go, see the Gartner hype cycle. People always overextend, try to apply new tools/tech into places that it doesn’t belong, and only then do people realise the limitations of technology. This is common in business, C-suites explicitly exploit the hype cycle to secure naive investor funding, but investors always become wise eventually - it’s a game to see how much money can be extracted from them before they become increasingly aware of the limitations of the technology. There will be niches where the tech actually settles, but it’s always much smaller than what’s promised. I’m a programmer, I’ve been listening to people say that LLMs are going to take my job for the past five years, and yet every time I’ve actually tried to apply an LLM directly to my work it’s failed in a pretty drastic manner. I find existing systems useful as a tool, but that’s about it.

Don’t forget this is all under the umbrella of the initial hypothetical where AI stalled at it’s current level. I don’t believe that existing LLMs systems will destroy the economy. They’re a tool that people are trying to fit into every hole, much like blockchain during the crypto bubble. We’ve already seen companies fire their customer service departments, try to replace them with LLMs, then have to go crawling back when that failed catastrophically.

If AI systems continue to improve, however? As I said previously, all bets are off.

Fine, you want me to be pedantic? When prompted with tokens that appear in an order that humans understand as a question that corresponds to some aspect of the universe as we understand it, the tokens predicted by the LLM correspond to an answer that humans agree is more representative than the tokens provided by the average human.

Tell me where in my initial comment I said they weren’t an economic threat. I never said they weren’t. I said they aren’t an existential economic threat. Please read my comment.

I don’t want to get into an argument of semantics, whatever your definition of ‘knowledge’ is, LLMs can recall a greater number of factoids than any individual human. That’s all I meant. Are they perfect? No, I never said that. They’re still far beyond the average human, however, hence superhuman.

I said that LLMs are not an existential threat to humanity, even economically. I never said that they wouldn’t threaten individual jobs, or cause a bubble. Please don’t strawman me. You and I are looking at completely different levels of effects, I’m looking at the big picture - is humanity or society as we know it going to continue to exist in 100 years (in this hypothetical where AI and/or LLMs stagnated)? If yes, then LLMs are not an existential threat. That’s what an existential threat means, after all.

Is AI causing en economic bubble? Sure, but like all bubbles they will burst when people realise that they have limited use due to their drawbacks. The world will then return to some semblance of normalcy. That’s a non-existential threat.

Now, if we’re talking about a world in which AI systems continue to evolve? All bets are off the table, which is why AI somehow stagnating to where it is now is the best case scenario.

Honestly? If AI systems stopped improving forever? That’s probably best case scenario. LLMs are already superhuman on a knowledge level, human-level in terms of speed (tokens per sec, etc), but subhuman in many other areas. This makes them useful for some tasks, but not so useful that they could cause any sort of existential threat to humanity (either in an economic sense or in a misalignment sense). If LLMs stagnate here then we have at least one tool in our AI toolbox that we’re pretty sure isn’t conscious/sentient/etc., which is useful since that makes them predictable on some level. Humans can deal with that.

Unfortunately, I see no reason why AI systems in general wouldn’t continue to improve. Even if LLMs do stagnate they’re only one tiny branch of a much larger tree, and we already have at least one example of an AI system that is conscious and sentient - a human. This means even if somehow the human brain was the only architecture ever capable of sentience (incredibly unlikely), we could always simulate/emulate a human brain to get human-level AGI. Simulate/emulate it faster? Superhuman AGI.

New Zealand.

Our laws make carrying anything with the intent to use it as a weapon (in self defence or not) a crime - whether it’s a gun, sword, pepper spray, cricket bat, screwdriver, or lollipop stick. This makes sure that when someone robs a corner store the owner gets jailed for having a baseball bat behind the counter. It’s absurd.

The law not only doesn’t equalise your chances, it actively forces you to be at a disadvantage when defending yourself, and by the time any police arrive the assailant is long gone. Most criminals don’t have guns (except for the multiple armed gangs of course), but plenty of them bring bladed weapons, there have been multiple cases of machete attacks.

I’m all for gun ownership for the purpose of property defence. Including strong legal defences for home and store owners repelling assailants.

I don’t think just anyone should be able to go and purchase a gun no questions asked, it should probably be tied to some kind of mandatory formal training, e.g. participation in army reserves. It should definitely be more difficult than getting a driver’s licence (but I also think a driver’s licence should be harder to get than it is now. The idea that you can go and sit a written test and then legally pilot a two ton steel box in areas constantly surrounded by very squishy people is kind of absurd to me).

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.