Obviously I couldn’t resist the opportunity to dive into this, so I gathered the data, and generated this chart:

Or, in table format, the top 10:

The keen-eyed observer will note that the numbers add up quite obviously to more than the actual number of crates published on crates.io. This is because many crates are dual (or even more than dual) licensed: in fact, over 40,000 crates are dual licensed under MIT and Apache 2.0. (This is about a quarter of all crates on crates.io!)

I don’t think cargo has ever prefilled a licence for new projects, so I suspect this is purely the social norm arising from Rust itself being dual MIT and Apache 2.0 licensed: that led to many early and influential crates being dual licensed the same way, and then it snowballed from there.

Update: After publishing this post, Ed Page pointed me to this page on Rust API guidelines which does explicitly recommend the MIT OR Apache-2.0 combination, so that may explain at least some of its dominance.

I tried to visualise the most common combinations of licences, but I don’t think it ended up being all that useful, since I had to take the logarithm of the edge weights due to how dominant the MIT and Apache 2.0 pair was. Nevertheless, here it is:

The processed data (as of November 21, 2024)¹ is available: both the individual licence counts after splitting multi-licensed crates, along with the graph data showing all the pairs found in multi-licensed projects. I’ve also included the raw CSV generated from the crates.io database, which is simply the count of each licence seen in the default version for each crate.

I’ve also published the analysis code to GitHub. It’s a little fiddly, but if anyone wants to replicate or build on this, that’s where to start.

May your crates be forever licensed appropriately! (Or at all.)

For the last few weeks, I’ve been trying out Niri instead. Niri is another Wayland compositor that takes inspiration from a project I haven’t tried called PaperWM to implement a “scrollable tiling” environment. I’ve been enjoying it: my Sway setup is generally to have one app per workspace, with one “chat” workspace in tabbed mode with whatever communication apps I have running at any given moment.¹

I haven’t 100% decided if I’m going to stick with Niri or go back to Sway (truthfully, I’ll probably switch back and forth for a while), but one gap I felt pretty quickly in Niri is that the only option for a running app list in Waybar is the wlr/taskbar module. Happily, Niri does implement the required Wayland protocols for this to work, but less happily, apps essentially show up in random order.² It’s possible to drag to reorder the apps, but that’s obviously a manual process, and because I’m crazy I like things being ordered, I would like everything to be in the same order it’s on screen: first workspace first, then leftmost window first.

An aside: why wasn’t this an issue for me in Sway, you might ask? That’s because I hacked some terrible code that I’m embarrassed of and hence have never released to rename workspaces based on their active window title³, which then meant that the sway/workspaces Waybar module got me close enough to what I wanted.

So, I figured, could I create a Waybar module to do what I wanted?

Waybar has long supported custom modules, which are useful, but limited in what UI they can create: it’s basically just a single label with a single tooltip. That isn’t sufficient here.

About a year ago, I became aware of Waybar’s cffi module, which allows you to implement Waybar modules in anything that can build a shared library with a C API. You get a Gtk 3⁴ container, and can then do whatever you want within that. I threw together a rough Rust binding, couldn’t get one of my demos to work⁵, and then left the code to rot in a directory.⁶

Now, though, I had real motivation to get something useful together, so I blew the dust off the bindings, fixed the bugs, brought them up to date with 2024 edition Rust, and have now published them as the waybar-cffi crate. You implement a Module trait, call a macro, and you have a Waybar module! Obviously I’m biased, but I think the Hello World example is pretty nifty.

Could I implement the taskbar of my dreams using that?

No suspense here: the answer is obviously yes, otherwise I probably wouldn’t be writing a blog post.

This looks pretty similar to wlr/taskbar out of the box: I like that module in general, so there wasn’t much need to change anything. The main differences are that windows and window events are synced via Niri’s IPC protocol, and apps are sorted by workspace index, so they’re mostly in the order they appear on my desktop.

The “mostly” above is because Niri doesn’t yet provide window geometry in its IPC, which means the taskbar can’t order apps within a workspace based on their position.⁷ In practice, this isn’t a huge issue for me because the window ID ordering basically works as a fallback, but I’d love to add that at some point.

The other main thing I implemented in the initial version is app highlighting, which you can kind of see on the Signal icon there. Basically, I’ve written the module configuration to allow this:

{
  "cffi/niri-taskbar": {
    "apps": {
      "signal": [
        {
          "match": "\\([0-9]+\\)$",
          "class": "unread"
        }
      ]
    }
  }
}

Which translates to:

1. If the app ID is signal, and
2. The window title matches the given regex⁸, then
3. Add the unread CSS class to the window button.

At which point I can use Waybar’s normal styling support, built on top of Gtk’s CSS support, to apply a highlighted border.

This is particularly useful in Niri because, unlike Sway, Niri doesn’t currently implement a Wayland protocol to indicate that a toplevel window is “urgent” (or, put another way, has a notification pending). But, even on Sway, I actually prefer to have a middle ground quiet way of being notified that something might be pending.

Anyway, this is the dictionary definition of “works for me” right now. I don’t know if it’ll be useful to anyone else.

I do have some rough plans for the taskbar module. In no particular order:

1. I haven’t even considered multiple outputs yet. That’ll probably need something.
2. I don’t know if I want this, but some way of putting a border or number between workspaces for additional visual grouping would probably be nice.
3. I wonder if it’s possible to fake urgency by peeking⁹ on notifications on D-Bus and highlighting those apps until they become focused.

But we’ll see how far I get on this. Like I said, I’m not even totally sure I’ll keep using Niri in the longer term, in which case the taskbar module would no longer be useful to me. Regardless, though, I’m glad to finally get the Rust bindings out for Waybar CFFI, and I hope those are more generally useful to others no matter what happens with the taskbar.

I’ve been comparing crates on crates.io against their upstream repositories in an effect to detect (and, ultimately, help prevent) supply chain attacks like the xz backdoor¹, where the code published in a package doesn’t match the code in its repository.

The results of these comparisons for the most popular 999² crates by download count are now available. These come with a bunch of caveats that I’ll get into below, but I hope it’s a useful starting point for discussing code provenance in the Rust ecosystem.

No evidence of malicious activity was detected as part of this work, and approximately 83% of the current versions of these popular crates match their upstream repositories exactly.

Background

I’ve been employed by the Rust Foundation³ to work on security matters for a bit over a year now. My focus has mostly been on the crate ecosystem thus far, and especially around supply chain security.

After the xz backdoor¹, one question that immediately came up was “could a crate be compromised in the same way?”. Perhaps an even more urgent question was “is a crate compromised in the same way?”. We need tooling to be able to answer those questions in an ongoing way.

Analysis

I’ve built a standalone tool to analyse crate versions, which I intend to eventually turn into something that performs ongoing analysis of newly published crate files. (Once that’s ready, this will be open sourced — the current tool relies on personal tooling I’ve built to mirror crates.io, which is (a) ugly as hell, and (b) not useful to anyone except me in its current form. The methodology is described below, though.)

For now, I’ve analysed the top 999² crates on crates.io.

As part of that, I also built a rough and ready tool to visualise the results for spot checking purposes, which I’ve now turned into a static site generator and have used to publish the results of that analysis.⁴

Methodology

The short version here is:

1. Take every version of each crate.
2. See if the manifest defines a repository.
3. See if the crate file includes VCS metadata.
4. Clone the repository at the given revision.
5. Run cargo package to rebuild the crate file.⁵
6. See if it matches!

Simple, right? Right?

Well, as it turns out, there are a few issues.

Issues

There are, in fact, a bunch of ways the above can fail.

Symlinks

This isn’t an issue for the vast majority of crates, but I spent a fair bit of time tracking this down.

Basically, if you have a symlink in your repo, and you clone it on Windows without symlink support enabled⁶, Git will helpfully turn each symlink into a regular file. That file’s contents will be the target of the symlink.

Now, if it’s a source file, you’re probably going to notice right away (since your builds will fail), but for things like README files and licences, you probably won’t. And, to make matters worse, they’re pretty much the most commonly symlinked files, particularly in multi-crate workspaces.

For now, I’ve elected to give crate versions that otherwise match their repos a special yellow sort-of-OK state. Still, it’s not lost on me that this might be a potential vector of attack in the future. Realistically, the fix here is probably to encourage crate developers to publish their crates out of (non-Windows) CI. (More on that in a bit.)

Stuff straight up not existing

Just because you declare a repository in a Cargo manifest, doesn’t mean that the repo still exists. (Or, indeed, ever existed.) And that’s before even getting to submodules. Or revisions — just because Cargo saw a revision in a local repository doesn’t mean it ever got pushed to a public code host. It just has to be committed locally to avoid needing to use --allow-dirty.

Speaking of…

Dirty crates

If you publish with something like cargo publish --allow-dirty, then that lovely VCS info file doesn’t get included in the crate file.

This is probably the right choice on the Cargo side, but I do feel that we’ll lose the ability to otherwise verify repos in some cases where someone just has an extra set of test cases in their working directory and used --allow-dirty to get around the requirement that the Git tree is clean.

Build failures

This isn’t really an issue in the top crates, but in testing the deeper reaches of the crate ecosystem, some crate versions just straight up don’t build any more — presumably because they relied on submodules that no longer populate correctly, or because they relied on nightly features that no longer exist.

It’s hard to generate a crate file to test when the crate doesn’t build.

Workspaces, again

I mentioned workspaces earlier, but another problematic case is users of workspaces on older versions of Cargo. Before Cargo 1.57 (December 2021), crate files built from subdirectories of repositories didn’t have that fact annotated in their VCS info.

In theory, it would be possible to search the repository to try to discover where a member crate is built from. Alas, that exercise has been left for another day, so those crates will currently show up as not being found in the repository.

Very old things

And, finally, Cargo added support for generating the VCS info file in version 1.30, which was released in October 2018. Very old crate versions simply won’t have this file, and hence can never be verified.

Results

Given the above, here’s what I found. Of the most recent versions of the top 999 crates:

• 826 crates match their upstream repositories at the revision they were built at.
• 74 crates have revisions that cannot be found in their repositories, whether due to later squash merges, rebases or revisions simply not being pushed.
• 73 crates do not have VCS info, either because they were built with old Cargo versions, built with --allow-dirty, or not built from a repo clone at all.⁷
• 7 crates do not declare a repository in their Cargo manifest.
• 7 crates would match their upstream repository but for one or more symlinks being incorrectly handled.
• 3 crates declare repositories that do not exist.
• 3 crates have submodules that do not exist.
• 3 crates cannot be found within their repositories.
• 3 crates cannot be built due to cargo package errors.

Going back further, those 999 crates have published 33,085 versions in total. The major trends looking back further into history are that fewer crates have repository metadata, and there are more errors related to not being able to find a crate in a workspace and more missing repositories. Both of these feel intuitively correct: the further back into history we go with these crates, the more likely it is that they have were packaged with older versions of Cargo, and the more likely it is that their repository history has shifted in ways that we can’t unpick in 2024.

Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

Future work

An obvious next step here is to extend this to the entire crates.io corpus. I intend to perform this analysis in the next couple of weeks.

Rather than further extending the static site that I’ve published today, I would also like to integrating this into crates.io for every crate, and running this check each time a new crate version is published. Doing this will, of course, require the consensus of the crates.io team, and work to design the UI and UX for this in a way that is immediately useful to the casual Rust user.

I think it’s also critical that we start providing off-the-shelf GitHub actions (and equivalents for other popular code hosts) that make it easier to publish directly out of repositories on the host, rather than crates being published from developer desktops. This is also a critical step on the road towards supporting a full trusted publishing pipeline.

And, of course, there’s plenty that can be done to improve the analysis.

The handling of broken symlinks is a late-added heuristic that I’m still not 100% sure I like.

Discovering crates within workspaces published from old Cargo versions would improve the accuracy of the checks.

Finally, getting a better idea of what types of changes exist is also important: analysing the top 999 crates didn’t really result in enough crate versions that didn’t match their upstreams to perform any real analysis, but a larger dataset will likely give us a lot to dig into. This is important because it will allow us to develop tailored best practice advice for different real world scenarios.

In summary

If there’s a backdoor attack lurking in the crates ecosystem, then it’s lurking pretty deep at present. The popular crates that we all rely on day to day generally appear to be what they say they are.

Of course, just because a package is the same as its upstream repository, that doesn’t mean that the repository itself is safe. This just mitigates one potential area of supply chain interest. (Alas, there are no silver bullets.)

I’m looking forward to developing this work further in conjunction with the Rust project, Rust Foundation, crates.io team, and others, but also ensuring that we broaden the analysis and scanning work that we do as we go.

Lots to be done!

From the perspective of actually getting to use it, though, it’s maybe more the end of the beginning.

Implementing this on crates.io² will require code changes, so isn’t going to be immediate. There’s nothing there that strikes me as particularly problematic from an implementation perspective: crate search will presumably need some tweaking, we’ll have to figure out if this changes how we rate limit crate publication, and the inherited ownership semantics in the RFC — while likely sufficient for the initial, single level implementations — will probably eventually need more refinement to handle less common scenarios.³

Policy

crates.io policy, however, is an area that will need more work.

Owners of existing crates will likely be largely unaffected here. To use serde as an example, there are already a handful of existing serde_* crates. This RFC will provide the option to migrate to serde::*, and will (at the very least) prevent others from publishing crates within that namespace.

I fear, though, that there will be a landrush of users who want to grab good namespaces for their own use.

In some cases, this will simply be spam, and can be dealt with accordingly per crates.io policy.

Some may be attempts at typosquatting, although top level crate owners controlling their namespaces means that there aren’t any new opportunities here. (For example, were someone to want to namespace a hypothetical serde::json crate, they could try serd::json⁴, but serde::json2 wouldn’t be an option.) Also, we’re pretty vigilant on this now, and I won’t be comfortable with crates.io accepting namespaced crates until we know the existing typosquatting checks⁵ are extended to handle them appropriately.

Finally, I suspect the crates.io team will have to field more requests based on trademark and other intellectual property rights. These are going to be time-consuming and potentially expensive⁶ to deal with, not to mention the issues that will be caused if a commonly used crate has to be removed or renamed, since much of the Rust ecosystem assumes an immutable crates.io index.

Verification

I also think we’re going to have to figure out a story around namespace verification over time. Put simply, this would give us a way of saying that the northwind-traders namespace belongs to the actual Northwind Traders company, and indicating that somehow in the crates.io UI.

This already exists in Java’s Maven Central⁷ and .NET’s NuGet⁸, and the research⁹ I did for my What’s in a Namespace talk last year at PackagingCon suggests that good top level namespace verification policies discourage typosquatting attacks, presumably because users have been trained to expect some sort of signal in their registry that the package is authentic¹⁰.

To me, it makes sense that we should provide a way of saying that a namespace prefix is reserved (or owned, or verified, or whatever word you’d like to use) by the entity that you’d expect. I think this need would increase significantly if multi-level namespaces¹¹ are ultimately provided, but I think it will still exist even today.

Maybe there’s a world in which signing completely solves this (BigCorp signs a key for ProductTeam, who uses that key to sign their crates, and then crates.io has some way of displaying that chain of trust), but that feels a long way off.

Doom and gloom?

All that said, though, I really don’t think this is a bad thing. (No matter what the last few paragraphs suggest.)

Namespacing is a new thing for Rust, and it’s going to bring new challenges (for other teams as well, I’m sure), but we’re not treading completely new ground here, and none of these issues are critical, day zero things. They’re just going to require careful thinking and planning.

I’m looking forward to us figuring them out together.

I am, in principle, supportive of adding a new resolver version that is Rust version aware, although I’m unsure if resolver.precedence = "rust-version" is the right default. (I won’t rehash this in any detail; others have covered the same ground. I basically agree with @mitsuhiko here that shipping just the new resolver as an opt-in — maybe even requiring an explicit resolver.precedence initially — would be a good way of gathering more data.)

I also strongly support the changes to cargo update and friends that will result in more obvious notices to users when they have old versions of dependencies, and the idea of making a MSRV violation an overridable lint.

From where I sit, I see three distinct problems with the current RFC, all around rust-version.

rust-version becomes semantically overloaded

rust-version is currently clearly defined as the minimum version supported by a crate.

This clarity is removed in the proposed documentation update, by weakening the definition of the field to “what version of the Rust language and compiler your package can be compiled with”.

It feels like rust-version now has three different meanings, depending on which part of the RFC you’re reading:

1. The existing meaning: the minimum supported Rust version.
2. A version that just happens to work with the given package.
3. With auto, possibly even a statement of policy (latest only)?

These are different concerns, and shouldn’t be overloaded into a single field.

The last point could be dealt with by introducing (in a later RFC, presumably) the hinted at rust-version-policy field, which would be a good piece of policy documentation that could be surfaced on crates.io alongside the minimum version, since it tells the reader both what the current MSRV is and what to expect on the next release of a crate.

For the other meanings, I would argue that the minimum version is still the definition we should use for rust-version, and that this RFC shouldn’t change that.

rust-version = "auto" isn’t an expression of a minimum version policy

OK, so if you accept the previous section’s contention that rust-version should continue to only express the minimum supported Rust version¹, then something else falls out: auto isn’t a valid expression of a minimum version.

The persona that develops a quick and dirty crate, starting with cargo new, and throws it over the wall at crates.io probably isn’t thinking about minimum supported Rust versions. If cargo new adds rust-version = "auto"², some users may take that as a hint to figure out their MSRV, but I suspect many would either miss it, or they may see auto as something that’s probably super safe and not worth investigating further.³

I would like people to think about their MSRV. I’d support changing the template used by cargo new to include a commented out rust-version field along with a link to best practice documentation.⁴

But the problem I have with rust-version = "auto" is how its behaviour shifts based on its environment, and environments are implicit, not explicit. With auto, and assuming I run rustup update reasonably often, if I publish my-shiny-new-crate 0.1.0 today, I’m saying that the MSRV is 1.76.0[^rustup]. If I fix a bug in six months and publish my-shiny-new-crate 0.1.1, now my MSRV is going to be something like 1.80.0⁵, even if I changed one inconsequential line.

If auto doesn’t exist, one of two things happens:

1. I may have taken the hint from the template, or read some documentation, and declared rust-version = "1.76.0" when I published the first version, This is probably still true, and it’s right in front of me in the manifest to change if it’s not. (And, if I’m wrong, it’s a really straightforward bug report from a user down the line, and an obvious fix for me as the maintainer: I can either make it compatible, or bump rust-version and republish.)
2. If I didn’t specify rust-version at all, then that’s definitely still true. Caveat emptor for my users. And that’s OK: as a crate consumer, I’d much rather know that the maintainer hasn’t thought about MSRV at all (through the omission of rust-version) than get a fake value that doesn’t really express their opinion.

In practice, I also think that the motivation for auto (which, as I perceive it, is basically a lack of rust-version usage thus far) will eventually correct itself.

Going back to PHP, composer init⁶ doesn’t include a PHP requirement at all in its default output, and there’s no equivalent to rust-version = "auto" in Composer. Yet ~78%⁷ of PHP packages on Packagist do include minimum PHP requirements, expressed as a semver constraint, likely because it’s prominently documented on the first real page of Composer documentation. The situation is different in some ways — Composer always (to my recollection) supported PHP requirements, so users learned to write Composer manifests with PHP requirements from early on — but I think over time crate authors would do the same thing. We just need to bring the documentation to the users, provide tooling to help, and be patient.

rust-version = "auto" can cause security problems for crate consumers

To shorten this section, let’s just assume I agree with basically everything @jonhoo said.

But, at the risk of repeating others, the specific scenario — related to the above — that worries me is this:

1. Maintainer Alex publishes buffer-thing 1.0.0 with rust-version = "auto". They use Rust 1.76, so that’s what the crate MSRV is set to.
2. Consumer Bobbie adds buffer-thing = "1.0.0" as a dependency in their project that uses Rust 1.77. No problem.
3. Alex fixes a security bug and publishes buffer-thing = "1.0.1", but publishes from an environment (whether their workstation or CI) that uses Rust 1.78. cargo publish sets the MSRV to 1.78.
4. Bobbie hasn’t updated their Rust version for whatever reason, rebuilds their project on Rust 1.77, and still gets the vulnerable version even if they run cargo update.

Yes, Bobbie will get a warning here from cargo update, and that’s good! But now they’re in a difficult position:

1. Bobbie could use --ignore-rust-version, but they don’t have any way of knowing if buffer-thing 1.0.1 actually works on Rust 1.77, and they have what seems like an authoritative statement from Alex on crates.io that it actually requires Rust 1.78.⁸ They’re probably not going to do this.
2. Bobbie could upgrade their local toolchain, but they may not be able to — it may be a certified fork like Ferrocene, or something else might not work with a newer version, or they just might need to conform with Big Company policies that they don’t necessarily even agree with but have no control over.⁹
3. If there are more changes than just the security fix, Bobbie could try to fork the last version that supported Rust 1.77, cherry pick the security fix in, and vendor that. That is both time-consuming and error-prone.

Again, all of this goes away if rust-version = "auto" doesn’t exist. Alex either published buffer-thing 1.0.0 with an explicit rust-version, which probably only gets incremented when it actually needs to be or per a clear policy that Bobbie hopefully already knew about, or they published it without a rust-version at all, in which case Bobbie gets to try it and can then decide to either report or fix a build failure. In some respects, this is essentially the same decision tree as above, but without the uncertainty of having a piece of seemingly authoritative information that purports to state Alex’s intentions around the minimum version. Whatever they choose, their path is clearer.

OK, that was a lot of words. I’m sorry. Really.

To put this into something actionable: my suggestion is that rust-version = "auto" should be dropped from the RFC. I also agree with @mitsuhiko that it probably makes sense to slow roll these changes more generally: it makes sense to me to ship the v3 resolver as soon as it’s ready, but I think it’s premature to commit to making it the default in the next edition without some real world experience reports, particularly around whether the default resolver.precedence is appropriate. (Could we ship it and require resolver.precedence initially, and ask for feedback?)

I decided a while back to start running again. It’s been a few years since I broke my ankle, I’m not getting any younger, and there’s some vague glimmer of hope that we might get a bit of a cricket season in here in Vancouver¹, so it felt like it was time.

Unfortunately, a combination of being old, lazy, and beer mean that I probably can’t just go run several kilometres any more, so I’ve been doing something I’ve always hated: intervals. Specifically, the Couch to 5K programme. Which means that I need to time things, and remember things like how many reps I’ve done.

I am, in related news, really bad at remembering things like that when exercising.

I also don’t really want to be holding a phone when I exercise, so I dusted off my old Pebble Time² and went hunting for apps. There are two apps on the Rebble store. They’re both functional, but have a significant flaw for me: you don’t get much of a sense of how you’re doing overall. Since I’ve never had an endorphin from exercise ever, in order to convince my body that idle exercise is worth it I badly need to know that there is a finish line after which the pain will subside.³

Therefore, I decided to also dust off my Pebble app making skills⁴ and see where that led. Specifically, it led here:

I built a thing!. It is, naturally, open source. It has not been submitted to the Rebble store as yet, mostly because I don’t really like Discord or bugging people and the submission process involves both.

I hadn’t used the Pebble SDK since the version 2 days. By the time Pebble folded, they were up to version 4.5, and there was a pre-release 4.6 out there.⁵ This was a huge improvement on the early days of Pebble development: there were emulators! The build process only involved one weird Python thing! The API had lost most of its rough edges and allowed you to pass userdata to almost all the callbacks!⁶

And, as it turns out, writing basic graphics code is still fun. The Pebble SDK provides a bunch of drawing primitives for things like arcs, circles, and rectangles, and you can also just grab the framebuffer and bitbang that if you really want to. Of course, it’s running on a Cortex-M3 or Cortex-M4 with a few hundred kilobytes of RAM, so you can’t go too crazy, but it’s nice to just have the possibility.

In the end, I really only hit two problems:

1. I wanted to use Rust, because obviously. A couple of people have tried and apparently succeeded with trivial apps, but I wasn’t able to join their ranks: with a lot of swearing and excursions into corners of the Rust toolchain I’d never been to before⁷, I could get something to link and be apparently valid, but not something that would do anything other than (a) crash on startup, or (b) lock up the watch.⁸

   I wrote it off as a bad job after a couple of evenings, but it’s bugging me. It’s a bog standard THUMB chipset running a hacked up version of FreeRTOS, and the interesting bits of generating code for that are all in LLVM once you disable the Rust standard library and accept that unsafe will be your best friend. I’m annoyed I couldn’t get it to work, even given some of the weirdness in the Pebble app build process.⁹

2. I got sad about Pebble. After they failed, they were bought by Fitbit, who were pretty generous with the grace period but eventually shut all the online services and support down.

   But the Pebble’s actually still a really handy device. The battery life is great, and it’s in a weird spot where it’s not quite a true smartwatch, but it nailed the things I actually want a device to do on my wrist: my phone can provide the smarts; I just need something that’s in a nice form factor and can perform a small number of actions.

   Plus, it’s actually pretty fun to develop for. The SDK really was quite good by the end, and it’s a full featured enough environment to not feel like you’re constantly running into arbitrary limitations, unless you need more than 64 kB of heap. (Nobody needs more than 64 kB, right?)

   In retrospect, Pebble’s biggest failing seemed to be that they didn’t quite know what they wanted to be. Pebbles were absolutely niche devices, but there was a period where Pebble (the company) was trying to take them mainstream — into brick and mortar stores, and into the consciousness. And maybe that’s what they had to do if they were going to make the economics work.

   But it feels like there’s a hole in the market for a modern Pebble-like device, and it almost makes me want to look into it. (Until I remember all the blog posts Pebble posted at the start of the process about how hard it was to get stuff manufactured, anyway.) It wouldn’t be a huge seller, but I’d buy one. You wouldn’t sell millions, but you’d sell thousands. Probably tens of thousands.

   I wish there was room for that in the modern tech world.

So, when people ask me what I did during COVID-19, I can say — hand on heart — that I did something productive¹⁰ and didn’t spend the whole time drinking beer.

Except for the parts where I was drinking beer while working on this.

Which was the whole development process.

Better get back to running to offset that, I guess.