I'd usually rather have a nice language-level interface for customizing implementation, but ELF and Linux scripting is typically good enough. Binary patching is in a much easier to use place these days with good free tooling and plenty of (admittedly exploit-oriented) tutorials to extrapolate from as examples.

Why: you might be concerned with network connectivity (you don't get to choose which data center you launch in and it might not be exactly equal), noisy neighbors on shared hosts, etc. if you're measuring for networking, you probably are spinning ups separate accounts/using a bank of accounts and something in every az until you find what you're looking for.

I realize not everyone is using a physically stripped burner, a graphene os install, etc and not everyone works at a high value financial, govt, or infra target but for those of us who need to deal with opsec or are commonly targeted by spear phishing this advice seems abysmal.

In the current political climate of the US, if you are living or traveling here and the current party isn't cheering for you personally, you really should be considering both state-sponsored attacks and no longer have the luxury of assuming good faith by the state. Telling people to enable cheap drive by attacks that are in active use by certain government agencies is irresponsible malpractice at best and actively evil at worst.

Source: I've worked at analytics companies that actively deanonymized users using cookies when available. We used wifi and Bluetooth details when available. We built "multi channel marketing" which was just taking any information we could scrape from the user to fingerprint them and cross reference and deanonymize them so we could sell interactions to businesses like geofenced price discrimination, value of users, and could offer cross website information on shopping habits/financial profile. The shit I did 15 years ago didn't go away and no matter how much I wish I didn't write that, it was the tip of the iceberg and relatively benign.

My Lexus is afraid of a bush behind my garage in the alley. It's on a neighbors property and not really overgrown, but my car refuses to get within about 5 ft of it. Makes backing out a nightmare. I haven't figured out a way to disable it, and have considered just selling this 2025 NX.

The CAN traffic is unencrypted. It was pretty easy to MITM this module with a cheap arm Linux board and a can transceiver to enable writing a two way filter capable of blocking the traffic that didn't raise any DTCs (that I observed) and could be turned on/off by the user. I preferred this approach to complete disconnection of the module (which is noticeable via errors at the diagnostic port) or trying to faraday cage or disable the antennae on the TCU so it can't remotely send/receive. I can also turn off my module or completely remove it before I sell it.

I fear the next version of Miata will be an encrypted CAN like most other cars have moved to and even with my expertise I won't be able to access the latest safety features from new cars without surrendering what little privacy I've been able to claw back.

The sum size of a dynamic binary plus the dynamic libraries may be larger than one static linked binary, but whether that holds for more static binaries (2, 3, or 100s) depends on the surface area your application uses of those libraries. It's relatively common to see certain large libraries only dynamically linked, with the build going to great lengths to build certain libraries as shared objects with the executables linking them using a location-relative RPATH (using the $ORIGIN feature) to avoid the extra binary size bloat over large sets of binaries.

I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.

It would be fun to pair this with Gambas[0], a free VB6 clone that works with GTK.

[0] https://gambaswiki.org/website/en/main.html

Browser / JavaScript environments -> ClojureScript

General Purpose (JVM) -> Clojure

Fast Scripting -> Babashka (although I've used ClojureScript for this in the past)

C/C++ Interop (LLVM-based) -> Jank (new, but progressing rapidly and already useful)

I can largely write the same expressive code in each environment, playing to the platform strengths as needed. I can combine these languages inside the same project, and have libraries that have unified APIs across implementation. I can generally print and read EDN across implementations, provided I register the right tag handlers for custom types (this is one area jank still has to catch up). Reader conditionals allow implementation-specific code as needed.

I'm really excited about Jank giving me a good alternative to JNI/JNA/Panama when I need my Clojure to touch OS parts the JVM hasn't wrapped.

Sure somebody might not have Python experience, but it's pretty easy to just not hire someone who says they don't know Python and isn't willing to learn for the role. I don't know that you'd filter out many candidates out of any random 100 devs.

Did we read the same book?