Alright. ALRIGHT. I know, we’re all excited, but let’s think about what we’re doing again.

So we’ve managed to look at real network traffic and parse it completely. We’ve also taken some ICMP packets, parsed them, and then serialized them right back and we got the exact same result.

So I know what you’re thinking - let’s just move our way down the stack again - stuff that ICMP packet in an IP packet, then in an Ethernet frame, and then serialize the whole thing.

I’d like to think that my understanding of “async Rust” has increased over the past year or so. I’m 100% onboard with the basic principle: I would like to handle thousands of concurrent tasks using a handful of threads. That sounds great!

A little while ago, I wrote an article on things that can go wrong when downloading, it listed a series of reasons, from network problems to invalid content to imperfect hardware that may occur when initially installing a game.

This article discusses what methods we can use to upgrade a game to a later version, when an older version has been successfully installed.

I know what you’re thinking: haven’t we strayed from the whole “content pipeline” theme in this series?

Well… fair. But compiling and distributing software is part of software engineering, and unless you’re in specific circles, I see that taught a lot less than the “just write code and stuff happens” part.

I’ve been working on the itch.io desktop app for about a year now, so I thought I’d make a quick recap:

At the time of this writing, the app has been downloaded about 460K times (including updates). Not counting the back-end, the app and its various components are made up of around 100K lines of code (mostly javascript and golang), most of which is open-source.

In the last article, we found where code was hiding in our samples/hello executable, by disassembling the whole file and then looking for syscalls.

Later on, we learned how to inspect which memory ranges are mapped for a given PID (process identifier). We saw that memory areas weren’t all equal: they can be readable, writable, and/or executable.

Async fn in trait… not

I was planning on showing the in-progress async_fn_in_trait feature in the context of my website, but it turns out, I can’t!

My website uses two databases: one local SQLite database for content, and a shared Postgres database for user credentials, preferences etc. Migrations are run on startup, and each migration implements one of the following traits:

Just 8 days after the last release, rock 0.9.6 is out.

To update, run git pull && make rescue as usual. To install from scratch, clone the repo, cd into it, and run make rescue from there - it’ll download the latest bootstrap, compile itself from C, then recompile itself from ooc.

Running rock -V should give you something like this:

rock 0.9.6 codename loki, built on Wed Feb 20 15:09:08 2013

rock 0.9.5 is out! It’s the meanest, slimmest, baddest rock release yet.

To update, run git pull && make rescue as usual. To install from scratch, clone the repo, cd into it, and run make rescue from there - it’ll download the latest bootstrap, compile itself from C, then recompile itself from ooc.

Running rock -V should print this happy little version line:

Disclaimer:

At the time of this writing, I benefit from the fly.io “Employee Free Tier”. I don’t pay for side projects hosted there “within reasonable limits”. The project discussed here qualifies for that.

Why you might want a remote dev environment

Fearmongering aside — and Cthulhu knows there’s been a bunch, since this unfortunate tweet — there’s a bunch of reasons to want a remote dev environment.