lpribis

The fare is the same as contactless, but this is only worth it if you're doing many journeys as cards themselves cost £7 each.

You can get contactless PAYG prices without any identification in London by using an Oyster card. You can buy them from corner shops without ID, and top them up at the same places with cash.

I doubt this really affords you any extra anonymity though. Tube and rail stations are so heavily covered by CCTV, and the police have many times tracked peoples entire commutes and movement through CCTV only.

Sorry, what is CSD? I can't find any reference to this acronym.

> Is the Rust ecosystem just dependency hell?

Not quite to the extent of the js ecosystem, but yes. Especially for a purported systems language there's a lefpad-esque problem of people making tiny and somewhat useless libraries to learn or pad their resume which then get depended on by the world.

For Linux there is Pinta, which is a very similar UI to pdn. It works well enough much of the time but I've found it way more unstable than pdn (and without the plugin ecosystem).

Funny, the first time I read about uxn I went down almost the same rabbit-hole and was investigating local used sailboat prices within an hour.

"INI" is not a specification. All INI parsers are slightly different, such that people refer to any file with

    [Section]
    Key = Value

Format as "INI" or INI-like, including the xdg format.

It was because of weight constraints. Spirit and Opportunity weighed 185 kg, while Curiosity and Preseverance both weighed around 1000kg. At that weight airbags large enough to cushion down the payload sufficiently would weigh too much. Just look at how large the spirit airbags were to support a rover that was only 1.5m square.

https://en.m.wikipedia.org/wiki/Sky_crane_(landing_system)#/...

The latest dotnet plays reasonably well with Linux and supports latest framework and language version.

This is one of my big frustrations with the embedded rust ecosystem (not a problem with the language IMO). They are so hell-bent on taking the typestate pattern and various abstractions to their extreme to prevent you from ever doing anything bad with the registers that the cognitive overhead of the API is unusable.

It's all great and clean if you're just writing led blinky examples. As soon as you need to dig down to some obscure datasheet minutia (as you invariably have to for any decent size embedded project), it becomes very annoying to map this back to the safe API. The code also becomes less readable since you can no longer look up things you don't understand in the datasheet.

The other this is that because of the excessive use of typestate, any driver struct needs to have a separate generic parameter for each io pin.

Maybe thinking of Spirit and Opportunity rovers which had a truncated tetrahedron shape of airbags (kinda) and unfolded to the upright position?

https://en.wikipedia.org/wiki/Mars_Exploration_Rover

Sure, the US has never done _anything_ that violates expectations about good and evil.

Back in my day you would do

    for (size_t i = 0; i < -10; i++) {
        panic
    }

And it would panic 18446744073709551606 times.

No so, even if VCC and GND are on opposite ends of the TRRS, they will pass by eachother as the cable is unplugged.

Think about unplugging from the side thats _delivering_ the power. As you pull it out, the GND (which is further in and needs to travel out as it's unplugged) will contact the live VCC.

Even from the power consumer side, there is a chance that a single female side contact (eg VCC) may touch two adjacent TRRS sections as the plug is being removed.

While it is quite popular, TRRS is one of the worst connectors possible for a power rail (eg usb VBUS) because it all but guarantees that VBUS will be shorted to ground if you ever accidentally hot-plug it.

Aside from video games, another place you commonly see pie menues is in 3D CAD software (Blender, Inventor, I think SolidWorks has one?). I guess it's because these programs are inherently more mouse-reliant than other software.

You mean RTTI instead of RAII, right? Google definitely uses RAII.

There's a difference between OS core programs and third party apps though.

What about baremetal embedded system code where there is no concept of a 'crash'? Sure you can emit a trap instruction/bus fault/etc, but what to emit for the trap handler code?

In think they just mean "on-chip/integrated DAC peripheral" when they say DAC (which is what a lot of hobbyists/non EE folk think of from the term). The article's just trying to say you don't need one for an audio use case and can use a discreet RC.

In theory, correctly filtered PWM or PDM at a correct modulation rate is identical to the original audio (nyquist-shannon). In practice the square waves produced have so much harmonic content that you need a good filter (like the active opamp filter in the article), and the simple RC filter that a lot of these projects use will sound terrible due to their long cutoff slope.

Very high fidelity sigma delta DACs are filtered PDM, they just use high modulation rate and good filters.