So one of the ways to pad your resume is to contribute to open source projects and this is been one of the drivers for open source.

So what we are seeing now is AI slop submissions flooding open source projects from people trying to get a credit without actually doing any work. It's no skin off their backs if you waste the reviewer's time and if your AI slop happens to be legit because you did three or four 500 submissions then that's just fine. Because all you were really after is getting your name on the project for when you apply for a job.

With how hyper competitive life is now because we're all Fighting for our lives out here I suppose I can't blame them but it's fucking things up. It's just another twisted distortion you get when you tie somebody's ability to access food and shelter to their job performance.

Even if the company has a crap product as long as they have a product they can keep taking money from investors and the CEOs can keep paying themselves out of that money. Maybe someday they will have a working product maybe they won't but either way the CEOs didn't have to have real jobs for quite some time.

They deliberately but in a system for verifying that the software is allowed to run, and deliberately used a certificate that has a fixed expiration date. Whether through incompetence or malice, Microsoft deliberately bricked the software. Technically, they did it a decade ago, and it is only just now being revealed that their time bomb is about to go off, but the effect is the same.

It is per se fraudulent dealing/false advertising to sell a perpetual license to software with full knowledge that it will stop working on a specific date.

This is, IMO, an open-and-shut Lanham Act/false advertising case. And any even remotely competent judge should absolutely throw the book at them.

If the class action lawyers are at all competent and the primary plaintiffs are not horrible people (bought off), the class action should demand that Microsoft release a hot fix that turns off the relevant validation. It's an hour of coding effort for Microsoft, though it would probably take half a dozen engineers a week or two to spin up a build environment capable of building it. The hassle of being forced to unlock the software would do far more to make them and other companies wary of such shenanigans in the future than any mere financial penalty ever could.

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

What we need is a clear duck typing law for digital purchases. If a purchase of a digital product looks like a sale, it is a sale, and there must be no known technological provision that is even capable of preventing its indefinite use. It must be possible to freely transfer it to new machines, to new users, etc. without limitation. Period. It must not be possible for the company to prevent this, either through action (deliberately disabling it) or inaction (failing to renew a certificate, failing to keep activation servers online, etc.).

If you can't do that, you should not be allowed to sell digital products. No grey area.

This means that your licensing servers must be available forever, or else you must not require their use. This means that when you buy a movie, it doesn't matter if the distributor's license for that movie is no longer valid, because you, the customer, bought a license that is perpetual, and it must be honored. And so on.

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.

They are also one of the few parts of the electronics hobby that isn't toxic. A very welcome change.

Long term, there won't be many working on leading edge who deal with the USA government...

Have you seen Trumps plan to destroy research in the USA yet?

https://arstechnica.com/scienc...

I misremembered. It's been some years since I did it.

We found that submersion to 10cm was often worse than submersion beyond 1m. I think it was the lack of compression on gaskets. Our pre-compliance test was a drainpipe blocked off at the bottom, and string.

Samsung used to make waterproof phones where you could replace the battery. I'd give up the ability to fully submerge if it meant the battery could be swapped out.

For me it's a big deal. I had a hell of a time replacing my Pixel XL battery. I'm keeping that thing alive forever, because it has unlimited full quality photo uploads to Google Photos.

The grid was part of the problem. Texas' grid is largely disconnected from the rest of the country. So when there are failures, they can cascade quickly. The issue was not an area of Texas lost power. The issue was MOST of Texas lost power.

Shhhh. If you talk too loudly about Texas, Tony Isaac will start posting here about how wrong you are about Texas. See Tony Isaac is a Texan and lives specifically near Houston. Based on that, he can boldly claim things for all of Texas. For example did you know that " We don't have snow plows either, nor should we invest in them. We just shut down when it snows, and that's OK." When pointed out that parts of Texas like the panhandle gets annual snow and thus have snow plows, he was not wrong. Nothing gets in the way of narrative.

See major cities like Dallas do not actually use snow plows according to Tony. "No, Dallas, Austin, and San Antonio do NOT clear the vast majority of their streets with snow plows. The vast majority of them are just allowed to thaw on their own, or at most, saline solution is dispersed." So every time the local Dallas TV news shows Texas Department of Transportation (TxDOT) snow plows on the road, they do not exist according to Tony.

When pointed to actual articles from TxDOT using 30 snow plows in North Texas storm, Tony says the population of Dallas is large so those snow plows don't count. Also the 700 snow plows that TxDOT has across the state don't count because Texas has a large population. So No "True" Snow Plows exist.

What the article seems to be trying to say is that adafruit criticized flux ai's low quality product so flux AI is abusing a law to go after them.