Super short TLDR: I looked at three barcode-scanning boycott apps. "Boycat" and "Boycott for Peace" have reasonable network traces, but loading images exposes your IP to third parties. "No Thanks" has no Privacy Policy, falsely claims to collect no data, and makes numerous unnecessary calls to Facebook and Google.

Longer TLDR:

The iOS versions of these apps were analyzed in February.

"Boycat" and "Boycott for Peace" expose your IPs to some third parties to load images, and have similar features. Both are good and easy to recommend, but Boycat has an overly-broad Privacy Policy and a Terms of Service which includes Arbitration.

Boycat has aims to be a more general purpose boycotting platform, whereas Boycott for Peace is focused singularly on the BDS movement.

"No Thanks" makes many tracking calls to Facebook and Google and has integrated advertisements. It offers no compelling features over Boycat or Boycott for Peace, and cannot be recommended. Further, it does not have a working link to a Privacy Policy, and falsely claims "No Data Collected" on the iOS app store.

Boycotting a corporation is hard to do when there are so many corporations to keep track of.

There are a number of apps coming out lately which promise to make it easier to participate in BDS boycotts. Thirty-seven US states have passed anti-BDS laws alongside Canada, France, Germany, Spain, and the UK. Given the US Government's long history of using apps to spy, such as with the U.S. Military buying location data from Muslim prayer and Quran apps,

I'm one of those big skeptical privacy freaks. Apps, either through malice or unawareness, can leak huge amounts of data that can later be used to surveil and suppress people.

So I decided to take a look into these apps. I used mitmproxy to inspect and modify traffic between the app and the server for this analysis, but I did not touch the server or internal code in any other way.

tldr: Reso has been re-implemented in Rust, deprecating the Python original. The underlying datastructure is new, with an incidence-map based algorithm. This makes Reso very fast, at about 20000x faster than the original in some cases.

Reso is a logic circuit language and simulator, first written in Python and now revived in Rust. It's a visual language, where inputs and outputs are both .png images, making MS Paint a totally appropriate IDE. :)

This post assumes you already know the idea behind Reso. You can check Reso out on GitHub and crates.io. You can install it with cargo install reso.

tldr: A post is titled "My cool new thing, written in Rust." The top comment asks, "Why should I care that it's written in Rust?"

Well, I care! I love knowing when something is written in Rust. The main thing is that it's probably easy to cargo install your_cool_new_thing. I can't say the same for anything asking me to interact with npm, pip, make, apt, flatpaks or appimages, etc.

This post starts with a diatribe about pip and npm, evangelizing the virtues of cargo. The other benefits listed are the performance benefits from Rust's memory safety, and reassurances that Rust won't die anything soon (meaning it won't drag other projects down with it.)

So, yes, I want to know your thing is written in Rust!

Over the past few years, line after line, project after project, I've become one of those annoying Rust evangelists. It's hard to go back to the old way of doing things, and a big reason is cargo.

On occasion, a new Rust project will be posted to a site like lobste.rs, with a title like "A $THING, written in Rust". Somone will invariable reply "Why should I care it's written in Rust?"

Well, I care, and this is why.

2023 has been my year of Rust. I've gotten 50% of the way on my fantasy assembly language Phantasm, the Rust implementation of Reso is nearing the 0.1.0 release. I'm also preparing a Commodore64 emulator Christmas gift for my mother in law.

I've also started publishing arbitration opt-out templates to make it easier for people to opt out of arbitration.

In projects not-even-near completion, I've been drafting up a puzzler with 5 space and 2 time dimensions, and I'm resurrecting drafts for a cryptographic hash primitive with a variable hamming weight digest.

For me, my biggest side project right now is definitely Reso. I'm super proud of it. The language implementation work is done, and I'm excited to build tooling to make it easy and fun to use.

TLDR: In 2014, SSDs were unreliable but cool and new. They've become more reliable over the years, but going into 2024, they're showing a streak of unreliability again. I've had had an SSD fail, an enclosure fail, and an SSD+enclosure which seemed to break eachother.

The worst offenders are SanDisk, Western Digital, Samsung. Backblaze reports roughly confirm this. See their full stats page here.

I didn't even know Dell made SSDs, but BackBlaze reports Dell as the lowest failure rate.