Sounds good - DDG is pretty bad lately, it typically just returns a list of AI generated SEO slop pages, so I've been switching back to Google in a private tab for a lot of things. Might be worth trying this one now!

If they leave them there, the next administration might be able to switch them back on and start gathering woke climate science data again.

(that 16 is 16 of my NiMH AA devices, part of the 20 "nicd/nimh cells")

According to my notes, I have here:

9v: 13
AA: 13
AAA: 17
AAAA: 1
C: 8
D: 2
coin: about 30
SLA/FLA: 5
LIFE: 4
lipo/nimh pouch and pack: 25
lipo cell: 9
nicd/nimh cells: 20
sealed plug-in charged: 16
sealed usb-charged: 27
uncommon disposable: 3

Those are not battery cells, those are devices. So for example, 16 of my AA devices use six AAs. (I have a crap-ton of NiMH AA, well over 100) and all of my C devices use at least three cells. So, sadly for me, there's a huge amount to keep an eye on. I realize I'm somewhat of an edge-case here, but that also makes me a good "how bad can it really get?" case study.

UCS32 is certainly an option. It would probably turn me off from Rust entirely, though, at least for my current work. When your device only has a few KB of RAM, quadrupling the size of your strings would be really painful. I'm unhappy that my pointers and register-sized integers are each 8 bytes, so a slice consumes 16 bytes (pointer plus length), minimum. I hate it so much I might consider creating my own string type that only handles strings < 64kb in length, so I could use an 8-byte pointer and a two-byte length -- but ARM has pretty strict alignment requirements so the compiler would pad the u16 out to eight bytes anyway. And all of my strings are error messages which are seven-bit ASCII.

As for your abstracted version... note that in my code I not only don't have GC, I don't even have a heap... no dynamic allocation :-)

With Rust as-is, that means I don't actually have String, but I *do* have &str.

You can certainly argue that one language shouldn't try to address the requirements of tiny microcontrollers to servers with hundreds of GB of RAM... but it's actually really nice that it does.

Rust doesn't try to prevent devs from writing bad code, it tries to prevent devs from writing unsafe code (i.e. code that can exhibit undefined behavior), and the approach to strings is safe. If you index a string at byte offsets, and try to use that data as a string and it's not valid UTF-8, your program panics in a safe, well-defined way :-D

I reviewed all the gadgets in my house that have batteries. Not just non-replaceable or rechargeable, but ALL batteries. I'm a bit tech-heavy here so I was expecting there to be a lot, but the final count still surprised me. (and I'm still finding stragglers from time to time)

The "biggest offenders" I have are flashlights. I've got a few cheap "webcam" lights, as well as several house flashlights that all use built-in lipo pouches, which I can replace, but not the average consumer. And I've had to replace my car GPS batteries several times over the years. I'd bet 98% of these are thrown away as soon as their battery gets marginal. I like to maintain and repair my stuff, and it "grinds my gears" to see these made to be thrown away.

The other thing that annoys me is that most of these gadgets have almost no "battery management". When you plug them in, they charge to full, and hold at full charge if left plugged in, which will inflate a lipo pouch in a few months at most. And many of the others will allow their battery to deep-discharge to the point of battery damage or even placing the device in an unrecoverable loop. My Garmin GPSs are terrible that way. If they get too low, they'd be bricked for most people because they always boot up when their dead battery gets a little bit of a charge in it, which isn't enough to boot the device, and then the boot process crashes, draining the battery faster than it can charge. Recovering that requires removing the battery and manually charging it, which most users can't do since the battery isn't "user" removable.

And then I have the related problem of dozens of infrequently used devices that I could easily go a year between uses on, and when I get them out their battery is dead and probably slightly deeply-discharged. And I can't leave it on charge because it'll cook off the battery by the next time I need it. Which again is really frustrating.

Then there's the "big ticket items like the exploding (pun intended?) market on rechargeable yard maintenance. Be it a hedge trimmer or a mower. Nobody knows how to take care of their batteries, they don't tell you in the manual, and few have management, so they leave them on charge over the winter and the battery is half cooked by spring. Then after another winter on charge the battery is totally cooked and they have to replace a $40-$150 battery. It's quite the scam! Along with removable batteries, built-in management needs to be legally required for batteries over a certain price. Even my quad (DJI Spark)'s batteries are smart and will self-discharge to 65% if not used for 10 days straight - so it's not difficult to do even for smaller batteries, they just refuse to do it because they want to sell you new batteries regularly instead of making the batteries last.

Perhaps not "as easy", but certainly not hard. Spend some time thinking about what kinds of covert and overt pressures might be brought to bear.

Aside: As an American, I think it's very sad that people lump the US and Russia together in this way. I think it's even sadder that I can't honestly argue that they're wrong. At most I can try to argue that there is still a significant difference of degree, if not kind, but it's not really worth making the argument because the degree of different is heading rapidly to zero. I deeply hope we can turn it around, and I'm doing what I can in that direction, but...

The latter. I'm pretty confident that TLS is secure. The modern ciphersuites are tight and things like the certificate transparency log make it so that while the TLAs might be able to subvert the CA process, they can only do it in small-scale, tightly-scoped ways. If you are a personal target of interest of any national security agency, you're screwed. They absolutely can get into every aspect of a private citizen's life if they want to put some effort into it. But the transparency log means that if they attempted to do this in any kind of large-scale way it would be discovered and publicized, so the fact that we don't hear about it truly does mean that they're not doing TLS penetration at scale.

However, even if they can't get the content of the connections, they can see where you're connecting to, and when. That sort of traffic analysis provides a surprising amount of information, and it can be done at scale -- and using a third-party VPN generally makes it easier, not harder. Layering VPNs can help a lot. Done carefully, you can structure it so that someone would have to control all of the layered VPN servers in order to track your connections. Layering plus multiplexing (using multiple providers and picking different routes and exit nodes for every connection) could make it really hard.

And if you don't really believe that traffic analysis is a concern, then there's really no point to using a VPN at all (except for location shifting), because TLS really is quite secure. It's definitely silly to, for example, fire up a VPN before connecting to your bank while at a coffee shop or an airport, which is exactly the pitch that many VPN services make. "Be wary of untrusted networks" is their pitch, and it's stupid[*]. If you're concerned about your online activity being tracked it's the "trusted" networks you're on most of the time that are the point of concern for traffic analysis. And the "trusted network" that may be the biggest concern is your VPN provider.

[*] Note that it's not stupid to be frightened of untrusted networks, but kinds of risks that exist with untrusted networks are generally not mitigated by VPNs. The best solution to those risks is keeping your device patched up.

There are a few ways to do it. The most common is to use the chars() method, which gives you an iterator over characters. So, for your example, something like "s.chars().skip(5).take(5).collect()". If you really need to do heavy unicode text manipulation (e.g. you're writing a text editor or something), you probably want to use some of the available crates, e.g. unicode-segmentation.

Clearly, as you say, this isn't what a lot of people would consider full, native support for UTF-8. Really doing it right would impose a heavy runtime penalty on the vast majority of simple string usage that doesn't need it, so Rust compromised: If you have a &str or a String in Rust, you know that what it contains is valid UTF-8 -- which means that when you create one you're paying the validation penalty, even if you don't need it... however, the penalties scale in an unsurprising way. When you create a string from bytes, the validation is an O(n) operation, but you also have to copy the bytes, so it's already O(n). When you slice a string, the slice validation only has to check the first and last characters of the slice, so it's O(1), as you would expect slicing to be. You might not naively expect slicing to panic with a UTF-8 validation error, but you should expect that it might panic with a bounds-checking error so the fact that it might panic isn't surprising. And, of course, you can use the get() method to get Err() instead of a panic.

Full native UTF-8 support would be a lot heavier. Many common String operations would be O(n) rather than O(1) -- including indexing! The APIs would be quite confusing to people accustomed to C-style strings, too, another cost. So, Rust doesn't do that. Instead, if you want the length of a string in Unicode characters, you use s.chars().count(). If you want a substring with character offsets you use s.chars().skip(n).take(m).collect(), or similar. These operations do not look like they're O(1) which is good, because they're not. They're also not nearly as slow/heavy as they look.

Like most compromises, this one makes no one really happy, and many people will disagree that it's the right choice. But I don't really see a better option, do you? Keeping in mind that everything from device drivers and bare-metal microcontroller code to browsers and editors is included in the target space, and that having different wide and narrow string types has proven to be a bad idea.

What kills me is how Repubs constantly use "BUT CHINA!!1!" as their go-to boogeyman for everything from technology and AI to the economy and trade, and yet they conveniently ignore their massive buildup of renewables and nuclear. One of the few instances where the divergence between the US and China actually matters and they pretend it doesn't exist.

Imagine if the party in power actually cared about the energy future of the US. We could be setting ourselves up for the next 50 years of growth by electrifying everything and upgrading the national grid to support it. Instead we're DIRLL BBY DIRLLing, building new pipelines, and putting up as many methane power plants as possible. Stupid old fucks.

The real friends are the terrorists we made along the way.

I should have included organized crime syndicates in that list, though thanks to Google's TLS-all-the-things push traffic sniffing is less useful for stealing money, and criminals generally have less interest in spying on people by doing traffic analysis.

Because Russia and the US are incapable of compromising or suborning providers from elsewhere?

Those are all ways to avoid installing questionable software on your primary machine, which is good, but they don't address the fact that you're still routing all of your traffic through someone else's server -- a server that tends to concentrate lots of potentially interesting traffic in one place, making it a much higher priority target than your typical ISP.

If the various intelligence and law enforcement agencies around the world don't own or at least have significant hooks into all of the major VPN service providers, someone should be fired for not doing their job.

Yeah, you shouldn't let LLM's do these things, lol

LLM's are like idiot savants - they can definitely be useful. You don't want to give them the launch codes though ...