Now that we’ve found the best way to find the “default network interface”… what can we do with that interface?

Well, listen for network traffic of course!

use rawsock::open_best_library; use std::time::Instant; fn main() -> Result<(), Error> { let lib = open_best_library()?; let iface_name = format!(r#"\Device\NPF_{}"#, netinfo::default_nic_guid()?); let iface = lib.open_interface(&iface_name)?; println!("Listening for packets..."); // doing some low-cost logging over here let start = Instant::now(); iface.loop_infinite_dyn(&mut |packet| { println!( "{:?} | received {} bytes", start.elapsed(), packet.len() ); })?; Ok(()) }

So!

I have no shortage of ongoing writing projects - I still need to edit and publish the final parts of making our own executable packer, and I’ve recently announced I was working on a Rust book/series. Those are still both on the table.

Buuut… I’m also looking at other things. My best writing happens when I’m learning about something at the same time I’m writing about it. So for example, the Rust book is a bit harder to write, because I’m mostly trying to distill knowledge I’ve already absorbed (for the most part).

I’ve been banging the same drum for years: APIs must be carefully designed.

This statement doesn’t resonate the same way with everyone. In order to really understand what I mean by “careful API design”, one has to have experienced both ends of the spectrum.

But there is a silver lining - once you have experienced “good design”, it’s really hard to go back to the other kind. Even after acknowledging that “good design” inevitably comes at a cost, whether it’s cognitive load, compile times, making hiring more challenging, etc.

Addressing the rumors

There have been rumors going around, in the Reddit thread for facet, my take on reflection in Rust, which happened a bit too early, but here we are, cat’s out of the bag, let’s talk about it!

Rumors that I, podcaster/youtuber fasterthanlime, want to kill serde, serialization / deserialization framework loved by many and which contributed greatly to Rust’s success, and I just wanted to address those rumors and say that…

Despite their peaceful appearance, game developers actually lead thrilling lives! Here are three things I learned (or re-learned) about yesterday that I’d like to share with you, in the form of assumptions that revealed false.

VSync is relatively straightforward. Right?

As an obsessive-compulsive, bipolar, perfectionist game dev, getting your game to run smoothly on all kinds of operating systems, graphics cards, and drivers combination is something of a holy grail. Many look for it, but let’s be honest here, it never really turns out as expected.

The day 15 puzzle falls into the “math puzzle” territory more than “let’s learn something new about Rust”, but since several folks asked if I was going to continue… let’s continue.

The sample input is as follows:

Sensor at x=2, y=18: closest beacon is at x=-2, y=15 Sensor at x=9, y=16: closest beacon is at x=10, y=16 Sensor at x=13, y=2: closest beacon is at x=15, y=3 Sensor at x=12, y=14: closest beacon is at x=10, y=16 Sensor at x=10, y=20: closest beacon is at x=10, y=16 Sensor at x=14, y=17: closest beacon is at x=10, y=16 Sensor at x=8, y=7: closest beacon is at x=2, y=10 Sensor at x=2, y=0: closest beacon is at x=2, y=10 Sensor at x=0, y=11: closest beacon is at x=2, y=10 Sensor at x=20, y=14: closest beacon is at x=25, y=17 Sensor at x=17, y=20: closest beacon is at x=21, y=22 Sensor at x=16, y=7: closest beacon is at x=15, y=3 Sensor at x=14, y=3: closest beacon is at x=15, y=3 Sensor at x=20, y=1: closest beacon is at x=15, y=3

Being creative is hard work, let’s go optimizing instead! My graphics engine dye was pretty naive about displaying text, and it was wasteful. Let’s see how I made it all better with this one weird tip.

Disclaimer: Even after a few years I’m still very much an OpenGL newbie. Please don’t hit me with crowbars.

Once upon a time, OpenGL was easy to use - and also falling out of relevancy as far as high-performance 3D graphics were concerned. But it wasn’t all bad! You could basically pick up any library out there and integrate it with your existing GL project. Not that it’s a good idea, but it usually just worked.

Alright! The day 12 puzzle involves path finding, and it seems like a good time to lean more heavily on the WASM embeds I’ve set up for the previous parts.

Let’s start by setting up the types we’ll want!

Types and parsing

Our input is a heightmap, like so:

Sabqponm abcryxxl accszExk acctuvwj abdefghi

Where 'a'..='z' is a square with a given elevation (from lowest to highest), S is the start, and E is the end.

Wait wait wait, so we’re not talking about nix yet?

Well, no! The service we have is pretty simple, and I want to complicate things a bit, to show how things would work in both the Dockerfile and the nix scenario.

And because I don’t like contrived examples, we’re going to do something somewhat real-world: we’re going to geo-locate visitors, and track how many visits we get from each country.

Day 2, Day 2! Woo!

The Advent of Code 2020, Day 2 problem talks about passwords. Sounds familiar.

Basically, our input looks like this:

1-3 a: abcde 1-3 b: cdefg 2-9 c: ccccccccc

Each line contains a “password policy” and a “password”. For the first line, the policy is that the password must contain between 1 and 3 (inclusive) times the letter “a”.