dgroshev

That's a bit simplistic. IP addresses are not unequivocally personal data. Let's rewind back a bit, GDPR Art. 4:

> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

IP addresses only allow to identify a natural person when combined with other data, such as ISP data or a profile built over dozens of websites. This is not the same kind of personal data as a name + address, Breyer notwithstanding (note the bit about the ISP in the judgment).

GDPR is not about identifying an abstract entity, it's about identifying a natural person. Doing the former for long enough/with enough data allows the latter, but especially with time-limited in-memory hashes that's a non-existent window of opportunity.

In practice this'd probably need to be resolved in court, and I'm sure not a single SME using Plausible or similar will even get a stern letter, much less fined.

Laws don't force the cookie banners, laws force requiring consent for personalised tracking. Banners as we know them are malicious compliance. There's a difference.

Same! I'm not a user (somehow), but I really appreciate the thought and polish that went into Muse. It's an incredible piece of design, in the widest sense of the word.

(this should probably be a post)

CRDTs and local first are ideas that is perpetually in the hype cycle for the last decade or so, starting around the time Riak CRDTs became a thing and continuing all the way to today.

Niki's post is a perfect illustration: CRDTs offer this "magical" experience that seems perfectly good until you try building a product with them. Then it becomes a nightmare of tradeoffs:

- state-based or operation-based? do you trim state? how?

- is it truly a CRDT (no conflicts possible), a structure with explicit conflict detection, or last-writer-wins/arbitrary choice in a trench coat that will always lose data? Case in point: Automerge uses pseudo-random conflict resolution, so Niki's solution will drop data if it's added without a direct causal link between the edits. To learn this, you have to go to "under the hood" section in Automerge docs and read about merge rules very attentively. It might be acceptable for a particular use case, but very few people would even read that far!

- what is the worst case complexity? Case in point: yjs offers an interface that looks very much like JSON, but "arrays" are actually linked lists underneath, which makes it easy to accidentally become quadratic.

- how do you surface conflicts and/or lost data to the user in the interface? What are the user expectations?

- how do you add/remove replication nodes? What if they're offline at the time of removal? What if they come online after getting removed?

- what's user experience like for nodes with spotty connection and relatively constrained resources, like mobile phones? Do they have to sync everything after coming online before being able to commit changes?

- what's the authoritative node for side effects like email or push notifications?

- how do you handle data migrations as software gets updated? What about two nodes having wildly different software versions?

- how should search work on constrained devices, unless every device has the full copy of the entire state?

Those tradeoffs infect the entire system, top to bottom, from basic data structures (a CRDT "array" can be many different things with different behaviour) to storage to auth to networking to UI. Because of that, they can't be abstracted away — or more precisely, they can be pretend-abstracted for marketing purposes, until the reality of the problem becomes apparent in production.

From Muse [1] to Linear [2], everyone eventually hits the problems above and has to either abandon features (no need to have an authoritative email log if there are no email notifications), subset data and gradually move from local first to very elaborate caching, or introduce federation of some sort that gravitates towards centralisation anyway (very few people want to run their own persistent nodes).

I think this complexity, essential for local-first in practice, is important to contextualise both Niki's post and the original talk (which mostly brushed over it).

[1]: https://museapp.com/podcast/78-local-first-one-year-later/

[2]: https://www.youtube.com/watch?v=Wo2m3jaJixU

If I get your question right, you still need some host software (like a rust compiler)! It's not exactly micropython experience.

The bare minimum would be one of the examples [1] compiled with a Rust compiler and then transformed into a .uf2 file with elf2uf2 [2]. You can then just drag and drop the .uf2 file into the "mass storage device" presented by the bootloader. To get the bootloader to mount, you press a button on a Raspberry Pico (or short two outputs if you're using bare RP2040) while plugging it in.

You'll probably want a debug probe [3] driven by probe-rs [4] at some point, it's just much more convenient to flash and debug with it.

[1]: https://github.com/embassy-rs/embassy/tree/main/examples/rp/...

[2]: https://github.com/JoNil/elf2uf2-rs

[3]: https://www.raspberrypi.com/documentation/microcontrollers/d...

[4]: https://probe.rs/

I'm not sure how things are in the C land, but if you write Rust take a look at this book [1], Embassy has a very good support for the RP2040.

Probe-rs [2] works perfectly well with GDB and the CLion debugger.

[1]: https://embassy.dev/book/

[2]: https://probe.rs/

You can have several bootloader stages, and in fact that's how the RP2040 works [1]!

Stage 1 bootloader is the one in ROM and it normally just reads stage 2 from the flash chip. Stage 2 then initialises the flash properly, and you can have further stages like [2] to implement the trial-rollback procedure.

Stage 1 is a safety net, even if the trial-rollback procedure goes terribly wrong the device can still be unbricked over USB.

[1]: https://blog.usedbytes.com/2021/12/pico-serial-bootloader/

[2]: https://embassy.dev/book/#_bootloader

I completely agree that it's inconvenient as a developer tool, a debug probe is much, much nicer.

I just think that despite all testing and care bugs are still possible, and the ROM bootloader is a backup that's always there. Plop a tiny switch on the PCB, and even if I screw up an OTA update customers will still be able to flash with no special tools (if the device has a USB port, that is).

I also use it as a recovery state for panics, makes the device impossible to brick by a panic loop.

Personally I wouldn't put it into a toothbrush (the benefit of right sizing is too high when you produce tens of millions of those), but for lower volumes I'd go for it.

Fwiw I'm working on my own consumer product/dev tool and I'm very happy with the RP2040.

I ended up cutting a section on Rust support from the post, but if you're open to Rust (iirc you were sceptical at some point?), async Rust is really pleasant to use in embedded. Dario Nieuwenhuis, one of the main people behind Embassy, gave a great overview talk at RustNL: https://www.youtube.com/watch?v=H7NtzyP9q8E

Ooops, you're right! Fixed & attributed.

This was a very interesting read, thank you.

One often under-appreciated aspect is that they have a tiny set of SKUs, which means opensource contributions/docs/articles/hype are all concentrated on those few SKUs. It's especially true for RP2040, their competitors have massive lineups that help to right-size the MCU, but this also means that any given SKU has less opensource support.

I think people haven't fully clocked yet how foundational this shift is for the wider internet.

For decades now, we had a social contract: Google scrapes our websites and surfaces some of our content, we make it easier for them, Google gets people on our websites, and in exchange Google gets content (links) to stuff with ads (plus they get some tracking on top).

This created an ecosystem where people are incentivised to create better websites. You create good content, Google surfaces it, you get eyeballs, and it's a decent deal overall.

Sure, this dynamic is contingent on Google fighting SEO spam, which they seemingly stopped doing lately, but still there was hope that it's temporary. There was hope that if search gets bad enough they'll start bleeding users to competitors and get their stuff together.

Now Google throws the contract out of the window. Whatever you write or record or snap or shoot, they ingest everything (because we have no choice) and feed it into their Moloch, and out goes unattributed, unverifiable, ad-ridden slop. There is no compensation, no recompense.

Google is midjourneying the entire internet.

I don't think that'd work without a dedicated startup behind it.

The first (and imo the main) hurdle is not reproduction, but just learning to hear the correct sounds. If you don't speak Hindi and are a native English speaker, this [1] is a good example. You can only work on nailing those consonants when they become as distinct to your ear as cUp and cAp are in English.

We can get by by falling back to context (it's unlikely someone would ask for a "shit of paper"!), but it's impossible to confidently reproduce the sounds unless they are already completely distinct in our heads/ears.

That's because we think we hear things as they are, but it's an illusion. Cup/cap distinction is as subtle to an Eastern European as Hindi consonants or Mandarin tones are to English speakers, because the set of meaningful sounds distinctions differs between languages. Relearning the phonetic system requires dedicated work (minimal pairs is one option) and learning enough phonetics to have the vocabulary to discuss sounds as they are. It's not enough to just give feedback.

[1]: https://www.youtube.com/watch?v=-I7iUUp-cX8

Yep.

HMS Dreadnought: Length: 160m / Beam: 25m / Displacement: 18410t

Acorn-class destroyer (contemporary with Dreadnought): Length: 75m / Beam: 8m / Displacement: 780t

Burke Flight III: Length: 155m / Beam: 20m / Displacement: 9900t

ATGMs or drones don't "reduce the value of tank" because there is nothing better than tanks for when you need mobile protected firepower. If you think being vulnerable in a tank sucks, try storming through a field on foot.

Tanks' value doesn't come from their invulnerability. They weren't invulnerable since WW1, if ever. Their value comes from being better than alternatives.

As for Javelins, Javelins don't need operators that have to sit still and blind, guiding their slow drones to targets. Javelins don't need dedicated operator teams, US army more or less hands them to infantry platoons as needed. Javelins don't need "infantry cover", their operators are infantry. Javelins are fire and forget, so you can shoot and immediately leave, unlike drone teams. Javelins don't require extensive training and fine skill.

The only thing Javelins don't do is first person videos. See my original point about drawing wrong conclusions from footage we get to see.

We had man-portable ATGMs for decades, they didn't "lower the value of a tank".

Less than 10% is not good when you consider how much does it cost in practice. Drone teams are often 2 pilots + technician + explosives technician (an incredibly risky job btw, those bastardised RPG warheads are live and sensitive) + infantry cover. At least double that if you want to strike beyond line of sight and need a retransmitter drone. Those teams can only move at night and on foot because they are actively hunted by the other side. They can only have one or two drones simultaneously in the air at best, and the drones need to get to their targets first without giving away the launch point. All of that for less than 10% success rate is not "incredibly effective".

Now compare to fire-and-forget Javelins that are way more lethal and are just something added to a normal infantry platoon.

Basic FPV drones are rapidly getting countered/obsolete. The moment people start doing something smarter/custom the drones stop being cheap.

It's an unavoidable dilemma: commodity stuff is cheap, but easily countered; stuff that isn't easy to counter isn't commodity and isn't cheap. You probably heard "yes but you can JUST add a jamming-resistant radio, and a thermal camera, and autonomous recognition/coordination, and larger payload, and…", but that's just motte-and-bailey.

Plus the drones still need the payload. If they are used against armour, they need shaped charges, which aren't free. In practice they often get random RPG-7 HEAT warheads from Soviet stockpiles, but we can't compare that with newly manufactured western 155mm HE.

They are only a thing for navies that can't afford anything better. We just call our battleships "destroyers" now, Burke Flight III and Type 45 are almost exactly the size of HMS Dreadnought and half the displacement (we don't do armour anymore).

The top end of course got much bigger, CVNs displace almost twice as much as Yamato.

Both sides suffer from shell and ATGM shortage and inability to suppress/destroy air defences, which drives suboptimal adaptations. An FPV drone assembled in a garage from aliexpress components and a tesla battery [1] with a submunition extracted from a cluster shell [2] is more effective than a single old howitzer with 10 shells per 2km of frontline [3], but it's a pretty low bar.

The 10% estimate is not mine, it's from a legitimate expert who regularly goes to the frontline in Ukraine.

[1]: An amusing anecdote from that podcast: Tesla battery packs are a big source of batteries for FPV drones. The packs can be sourced for next to nothing from totaled Teslas, and individual cells are very reliable.

[2]: https://www.twz.com/ukrainians-are-cutting-open-u-s-cluster-...

[3]: https://foreignpolicy.com/2024/04/17/ukraine-frontline-ammo-...

We had pretty smart weapon systems for a while now! P-700 Granit and Brimstone missiles were doing cooperative engagement and target selection for decades. BONUS rounds fit target recognition into small pucks. If we squint just a bit, many naval mines, especially something like CAPTOR, are "vehicles that can identify and change targets fully autonomously".

AI is not the limiting factor as much as sensors, energy, datalinks, logistics, and costs are. Yes we can miniaturise TERCOM now, but then where would the vehicle get maps from (battlefields change!), how would it see the terrain (at night? on a foggy, rainy day? deliberately dazzled/blinded with a cheap laser?), how far can it travel, how much payload can it take, where does it launch from, and how does it get to the launch point? Working through those questions and anticipating cycles of adaptation, I think it's easy to end up with a $1m JASSM-ER or a $3k 155mm shell (neither of which Ukrainians have in sufficient numbers).

For example, if you know there's an enemy platoon in that forest, why would you fly a swarm of autonomous tree-avoiding hunter drones there if you can drop some 155mm instead? The enemy can't blind a 155mm shell, EW wouldn't work, shells don't care about fog or darkness, payload-to-weight ratio is ~100%, and they're cheap. Of course if you don't have shells you have to be creative, but that doesn't mean the creative solutions are better.

On the other hand, according to the episode I linked, humble unarmed non-AI DJI Mavics have a very persistent and systemic impact. They provide 24/7 eyes in the sky over the entire front line, which makes tactical surprise impossible. This is very much not "AI swarming slaughterbots" many seem to imagine and invisible to folks on the sidelines like us, but that's why I'd be cautious of making inferences from the media we get to see.

Can you please elaborate which part of the comment you are refuting?

I don't think we as laypeople should even attempt to draw conclusions from Ukrainian battlefields ourselves, seeing how strong the survivorship bias is.

Take FPV drones. In [1] Michael Kofman estimates (based on talking to a number of frontline units) that on average <10% of FPV drone strikes on armour are successful. The success being a mission kill, not a spectacular turret toss we see on twitter/reddit/telegram. Every strike requires a large support team, strikes can't be massed (because of radio interference and EW), the efficiency is dropping over time because of cheap adaptations (EW, nets/cages, smoke), and the drones aren't that cheap and much less suppressive than 155mm shells. A layperson relying on stuff on social networks would have no way of knowing this, and think of FPV drones as this incredibly effective weapon making tanks (and helicopters) obsolete.

Or TB2s. Remember how they were the future of warfare after their success in Nagorno-Karabakh and the first few weeks in Ukraine? Few months later TB2s completely disappeared from the media, and I don't think many people are aware of how useless they became.

More generally, I think we're seeing a repeat of the century old debate over torpedo boats. People saw how torpedo boats were much cheaper than battleships and thought "hey we can have many of those boats, it'll be cheaper and more lethal". Turns out that range, coordination, sensing, targeting, and logistics are so difficult a smaller number of more capable platforms in well trained hands is both more effective and efficient.

In that analogy, those CCA drones are [torpedo boat] destroyers, not torpedo boats. A small number of somewhat cheaper, but still expensive platforms dependent on the exquisite core of the fleet (battleships, carriers, F-35s, or AH-64s) that doesn't go anywhere.

[1]: https://warontherocks.com/2024/04/mike-kofman-and-rob-lee-on...

Only if plastic packaging ends up in a landfill, if we burn it we still release the carbon into the atmosphere. "Bioplastics" (ie made from atmospheric carbon captured by plants) are a better example, and if we landfill those they're a true carbon sink.

I love Barbican. One often overlooked quality of Barbican is how much design work went into it: these corridors, galleries, balconies are all unique, many design elements are one-off, and there are more than 80 flat types https://www.barbicanliving.co.uk/plans/

This makes it much more organic, surprisingly, than most modern developments. It's not just the same thing copypasted over and over, Barbican has a very human, natural variety to it, despite the superficially harsh appearance.

Sometimes this variety can even backfire, because Barbican can feel like a maze. But that's a consequence of it not being the standard street grid. I wish we had more architecture like that.

Your DJI can't cope with doors. 100g of explosives don't do much, see Ukraine where this was attempted multiple times with very limited effect. And most importantly, your DJI enjoys massive subsidy because it is mass produced for entertainment, any custom weapon system would be at least an order of magnitude more expensive. This is already the case in Ukraine btw, with FPVs being comparable in total cost to entry point Mavics, despite being MUCH cruder.

It's not a winning proposition when you take into account that those FPV launches require teams of dozens of people to support, and that good old artillery is both cheaper, scarier (=more suppressive), and more effective.

Launch 100,000 drones against what target? How do you find the target? How do you get to it without getting detected and destroyed? Where do you launch from, what's your launch platform, and is it survivable (if you just plan to bring trucks to the front line, they'll just get blown up pre launch)? How do you deal with high power directed microwave, lasers, or just basic AA shells filling the air with shrapnel for peanuts? How do you coordinate the attack, especially under EW, without saturating all bandwidth available way before you reach 100,000?

You're severely underestimating the challenges and how much it costs to solve them. There are multiple reasons why torpedo boats never worked against competent navies, despite being theoretically much cheaper than battleships or modern destroyers; many of those reasons still apply to those ideas about cheap drones.

In the end it might very much be cheaper and more effective to use a good old JASSM-ER.

The context of my reply is that "slaughterbot" short video, not 100kg+ drones.

It goes both ways. Just half a century years ago plenty of people were convinced we'd be having flying cars by now, projecting the speed of progress in one particular area forward. It doesn't work like that, progress in any given area is S-shaped, not exponential.

It's even worse when processes are adversarial. Where are the TB2s in Ukraine? Are you aware that FPV drones seem to have less than 10% success ratio nowadays?

They aren't free. Autonomy is computationally and sensor hungry, and consumes a lot of power. The moment a platform approaches the capabilities you are thinking of, it stops being cheap and stops being small. All while those drones are stopped by doors, curtains, strong wind, any kind of mist or darkness (unless you use thermal vision, which is $$$), or rain.

Out of interest, since you seem really knowledgeable: is there any reason no one ever mentions shipping VT fuzes to Ukraine? They seemed to work really nicely in the Battle of the Bulge, and the US is likely to have a vast stockpile of Cold War era fuzes. If they make the sparse shells even marginally more effective, it'd probably be worth it, yet there is not a whisper of their existence.