a couple things 1: this looks like a really cool podcast i will def be following and watching all the older ones 2: i know quite a few large scale systems use that system for example the nintendo 3ds has a mcu that does all the leds and the power button. the recently released pi 500 uses a pi pico chip for the keyboard controller

Framework laptops (and loads of others!) have SODIMM slots (that accept DDR5-5600)

As excited as I am for a mixed-criticality software future, a dedicated processor sure is easy to reason about at this scale.

In my last project I tried to do the opposite: all in one big microcontroller. I didn’t want to deal with developing multiple firmware and dealing with updating them and communication etc. I ended up regretting it. The big microcontroller is running out of pins as we needed more functionality and the firmware is really complex because it interfaces with 20 different hardware devices. I ended up begrudgingly adding another microcontroller just to read a photodiode because I couldn’t find a standalone ADC chip which had a programmable interrupt pin which met my requirements. But using an stm32 as a glorified ADC worked just fine. A few hundred lines of code and I never had to worry about it again.

I use mcu's for products that have either extreme low power requirements or very hard real time requirements regarding motor controls, so I've never actually had the opportunity yet in my career to use embedded linux. Would be fun to try something without such restrictions. And I'm not sure I'd use rust for the mcu side... Zig does seem to treat embedded as more of a first class citizen, but it's of course way too early and unstable.

I settled on a buddy system approach to my last embedded project, and it was a great decision!

A lot of the links in the description include the closing parenthesis which are leading them to 404 pages

In the car example: run the brakes, speedometer and engine tuning on the small mcus. Run the entertainment system, GPS and system updates on the big Linux chip. (For system updates and debugging let the Linux system check the versions of the small mcu's and flash them needed, when parked and after user confirmation.) Keys is a funny thing. I may want the key fob or your cellphone "key" to interface with the Linux system, because it's an over the air protocol to the outside...

It's pronounced "meerdee"

There would be a slope up thing on the e if it was serdAY.

check merde version oh it is at version 10

around 34:00: this sounds a lot like coroutines! I like that trick!

39:00 postcard-ebpf when? :D

Big up to all french speakers

Amos says that he doesn't know how to grow stack, makes a guess that it works by allocating a new stack region and going there (that's actually pretty easy to do), and then explains how he did exactly the same with asyncs (since Rust asyncs are basically partial stack coroutines). Nice!

22:29 I think the original term “splat” comes from ruby/perl.

I wonder what tool/app he used to make this presentation, its pretty

Interesting. I was looking at CBOR for this.

casting any type to char* is well defined C++ ... And everyone uses x86-64 right? [N]RVO isnt guaranteed by LLVM? Thats odd given that the c++ standard does and LLVM is a C[++] [and swift can't forget swift or Tim Cook will personally come after me] compiler first and foremost

I’m not convinced this isn’t an AI conversation

Wanted to watch but morally cant if yall are calling twitter x 😢

memcpy is still the best serializer 😛

I pronounce it serde, not serde *flips table*. LOL

Oooh, nice! It also somewhat mirrors the reflection research.

13:40 There is not only a deserialize in_place method (about which I hadn't heard before), but there also is DeserializeSeed thingy, which might allow directly serializing into a `&mut [_]`. (Though IIRC that is a bit more annoying to set up and might need a manual implementation.)

On "Siri shut down everything!" my siri kindly asked "What exactly, like really EVERYTHING?"

16:06 That's because technically it's just Philipses Lighting division spun off under a different name

8:49 The fact i can immediately see this is some Tuya contraption probably isnt good is it

That's the story of my life!

how does putting your iot and your phone on different wifi networks even work? won't you have to switch networks every time?

*Sees the title: Immediately says:* “Oh, no.”

I hate that const limitations were one of the first things that stumped me in rust and I couldn't figure them out and when I showed my attempts to my friends, yes, they joked about never touching rust, but now 2 years later I look at this and I find it kind of genius

23:59 this is exactly what happened to me when i started trying to use compile time rust. I really like the language, i like a lot of the features, and I think learning it has made be better, but I switched back to C++ for my day-to-day because of garbage like this. It felt like the Rust STL and compile time stuff is extremely not-fit for production quite yet, and I'll be following the changes, but I'm still not switching over to it for large projects just yet.

Important clarification: zig currently does not allow allocations in comptime

Why using the O(n^2) loop if you could use sort instead. Implementing merge sort is easy. After you sorted your array, it is easy to extract unique values into result array. Easy in C++14 constexpr.

What about the dead simple approach Ethernet takes: 8b10 or 64b66 for newest faster variants

Interesting. I made the Serial Chinese Room, Interproces, and Telemetry Script, AKA Script2 and the SCRIPT Protocol for RPC, which is hybrid byte encoded and human readable based on contiguous data types.

16:25 I know this is not very rust-like, but do you even need the maybe-uninit? Just initialize everything with zero, you already unwrap everything that is below the current output index, so you don't even use the fact that it's an Option (you also return the number of `Some` values, so it doesn't even help on the consumer side)

"It's O(n^2) but that's the compiler's problem" its not even a problem if your n is small anyway.

20:32 oh no typo on the slides, second loop needs an increment... very good episode tho! I'm in the midst of some compile-time crimes myself, w/ a proc_macro tho, neat to see const fn crimes too :)

Wow this is just like C++ constexpr but more painful. I thought C++ is already too restrictive for when you use vectors in constexpr code but not being able to even use for loops seems annoying as hell to me. Props to you for getting it working.

I dont think most people in my life would und erstand why someone would watch this for and reason but I enjoeyed it nonetheless :)

I'd say, while having async allocator for general purpose might be questionable(since if you plan to schedule other work.while waiting for the allocation, the work might need an allocation too and it all turns onto itself perpetually), you can have a niche applIcation where you want to use Huge Pages but say implement your own allocation on top of them with whatever guarantees yoh like, since bigger page means lesser virtual page table(trivially speaking) and while Linux kernel for example can us free huge pages for general purpose also, if you really want you can and then the global allocator can still do most of the general purpose lifting while you have a clear interface to cooperatively manage "the new thing"

The reason aaui for the file uri is the os-x capability sandbox. Sandboxed applications can't just enumerate the filesystem, instead, to gain access to a file at the user's request they need to perform an NSLookup on the request. This prevents applications from gaining access to files not explicitly shared with the app by the user.

This was super fun! On FP registers: besides the fact that these are sometimes different sizes to gp registers, another reason they are often separate is that adding additional ports to a register file is very costly in space. There's additional circuitry per-register-per-port. Add to that, many implementations duplicate register files to get more fast read ports, but you still need to write to all of the register files whenever you update. Separating out the FP path, then, makes sense for FP heavy workloads. Also, I think POWER predates PowerPC, but I could be misremembering. The thinking was that when IBM, Apple, and Motarola came together to design the RISC they could all standardise on, they ended up starting from IBMs ISA and pruning out COBOL-specific instructions.

This episode had all so many little details that give great perspective on what I was already familiar with. Thanks!

There are a bunch of Power architecture CPU cores with a variable length encoding extension (VLE) in the automotive embedded space. These are like the thumb-only ARM cores, except based on PPC rather than Arm. When I started using them, you couldn't even get an upstream GCC release that supported them. There's also an arch named Coldfire which is the name under which the 68k arch lives on.

6:18 - Saying Siri turned on all of the lights in my house for some reason. LOL. Thanks Amos!

That's quite a lot of advertisement in the first minutes for such a small channel. 👋

Seems brilliant