Really? I've never, ever heard that pitch for AI.

Also, the amount of energy required to reverse it... it's hard to see where that could possibly have come from.

The name of the product is "Bomb", and "Bomb" is the default Bluetooth name.

I don't know whether that makes you advice invalid, or all the more salient.

ROTFL

Social engineering redux... except now you only have to convince a sycophantic and overly helpful AI.

Many people incorrectly think of proxies and VPNs (especially VPNs) as a security and privacy enhancement, but unless you're operating the proxy/VPN server yourself they're just as likely to be a massive security and privacy risk. The problem is that they concentrate all of the traffic you'd most like to keep secret in one server, and depending on exactly how the system works, may require installing software on your local machine with ~root permissions. If the operator is malicious, this is a really dangerous combination.

These are useful tools for location shifting and -- in fairly rare cases, and with VPNs only -- from hiding traffic from malicious. But third-party proxy/VPN services should always be viewed with suspicion. Obviously this is even more true when the provider is Russian... though it's pretty likely that wasn't made clear to the people who used the service.

A person can be sane and immoral, sane and moral, insane and immoral or insane and moral. "Orthogonal" is perhaps a little too strong, since it implies the absence of any relationship, but certainly all the combinations are possible.

Just read her Wikipedia article. Should have thought of that sooner. Thanks for the push.

Yup, 2016 was the most recent crime she was convicted of, and it says terrorism in Germany does have a statute of limitation.

Thank you. Answers a lot of questions, such as did they artificially age 40-year old photos for the facial recognition.

Far as I know, there is no statute of limitations for major crimes like murder and terrorism. But it varies by state and has varied over time.

I spent four years in the navy as a supply clerk dealing with paper work and petty bureaucrats. I learned an outrageous number of ways to not cooperate while seeming to cooperate.

I appreciate digging up the response. I have long since lost the patience to deal with bureaucrats.

Sanity and morality are orthogonal.

There is something decidedly amiss when the monopolist defines its own limits.

One vote every 2 or 4 years, for which insider controls the monopoly, is a pathetic outsider limitation on government.

heapless is quite useful in many contexts, yes.

As for what my design goals are, it's a pretty typical LRU map. I assumed that the name would tell you what the purpose is, but perhaps not. Please excuse me for belaboring if you are already familiar with these concepts; I don't know what you know, so I figure it's better to be clear. If you do, skip the next paragraph.

An LRU (Least Recently Used) cache is a cache that has a fixed maximum size and when a new item is added that would cause it to exceed that upper bound, it discards the "oldest" entry in the cache, where "oldest" is defined as least-recently used. An LRU map is similar but it is "primary storage" not cache, but still with a fixed capacity so when you try to put more in it than it can hold it has to discard something, and it does that by discarding the least-recently used item.

In my case, I'm writing code that services client code running on other CPUs in the same SoC. The client transactions are moderately long-running, each involving a sequence of requests delivered over the course of a few seconds, though some sessions legitimately go much, much, longer, and each such session requires me to track a non-trivial amount of state, not so much for efficiency as for security; I can't hand the internal state back to the caller because that might allow an attacker to mutate it or roll it back (if rollback weren't a concern, I could outsource a MACed copy of the state). I keep the operation state in a map structure, keyed by an operation ID. But clients can die and clients can misbehave, so I can't safely rely on the clients to always send me the termination message that allows me to clear the operation state.

So, I need some way to ensure that my map doesn't fill up with stale operation data, preventing new operations from being started. LRU eviction is a cheap and effective method. But this means that sometimes clients are going to send a request for an operation that I have evicted, so I have to return an error message. I could just always say "Operation ID not found", but then clients have no way to distinguish between cases where they just waited too long and cases where I suffered a failure or was reset. The clients often respond to these different failure modes in different ways.

For that reason, I keep a "recently-evicted" list -- but that also has to have a fixed size limit. In practice, my recently-evicted list consists of two lists, an "old generation" list and a "new generation" list, both with fixed size limits. Every time an operation is evicted, it's added to the "new generation" list. When the new-gen list is full, I move it to the old-gen list (in practice, I really just change which list is considered new and which old; no need to copy it). This is a cheap way to "age" the eviction records, without actually having to track their age in an LRU fashion (which would ~double the per-entry storage required, halving the number of evictions I can track). When a request for an unknown operation ID comes in, I search both lists to see if the ID has been recently evicted. If so, I remove the ID from the list and report the error to the caller. The reason for removing is to make space for a new eviction record, to maximize the scenarios in which I can notify clients.

Regarding your comment about encapsulation being overused... this is not such a case. The purpose of encapsulation, properly applied, is invariant maintenance, and there are some important invariants that have to be maintained for the LRU map to work. One of those is that insertion must execute the eviction logic, so even if I could move the map out temporarily, that would create an opportunity for bugs if the calling code does not correctly handle eviction and maintenance of the recently-evicted list. Another (less crucial, but still important) is that the recently-evicted list should only contain entries for clients that haven't yet been notified.

That said, there actually a good argument that the `recently_evicted` method is conceptually non-mutating and I should use interior mutability. Either that or I should rename it to "remove_eviction_record", so it's clear that it is inherently a mutating operation. I will do one of those two things on Monday -- thanks for helping to improve my code. I would prefer the rename for clearer semantics, but interior mutability will allow me to avoid the extra map lookup, so I'm leaning that way.

One other comment about something you said, which you might find interesting: You said that in Rust, moves are cheap. This isn't really true. More precisely, it isn't any more or less true in Rust than in any other language. Regardless of language, when you move data, you must copy it, and you're paying the cost of that copy. What makes moves so useful in Rust is not that they're cheaper in time or space but because of the marvelous move invariant that is enforced by the compiler. Namely, that moved-from values cannot be referenced.

To see how important that is, compare with C++, which also allegedly supports move semantics. The modern C++ style makes heavy use of move semantics. But C++'s move semantics are broken in a way that makes them less efficient and more difficult to use safely, and that's because C++, like C, always allows code to reference any value that has a name. That means that moved-from values can be referenced, which means it's critical that moved-from memory not be left in an invalid state when interpreted under the invariants of its type. So the rule is that moved-from C++ objects must be left in a "valid but unspecified state". In practice, this translates into the move ctor/optor having to do work in the moved-from memory, zeroing pointers and whatnot, in order to ensure that what's left behind upholds the invariants of the type, and it means that C++ structs that support move-from must have some valid but not semantically-significant state they can be in.

What makes Rust's move semantics easier to work with, more efficient and safe is that there's no need to ensure that the moved-from memory is in any kind of valid state, because the compiler will not allow the moved-from memory to be accessed. Another way to think about it is that the moved-from memory no longer has any type, so no longer has to maintain any type invariants. It's fine to leave behind bit patterns that used to be pointers or whatever, because those bit patterns will never be used.

Coming from 35 years of C++ programming, this was something of a revelation to me when it hit me a few months ago. And it's the real meaning of "moves are cheap", which isn't a comment about time or space, but a comment about invariant maintenance.

What is the logic there? How do you get from "police have misused it" to "police should be banned from using it"? I feel a few steps are missing.

Easy - the justice system isn't doing the proper checks. Police use it, and it returns a list of names of people WHO LOOK NOTHING LIKE the person of interest. And police do not even perform a preliminary check of whether or not the person could have committed the crime (they may have an alibi). And the judges do not even take 5 seconds to look at the photos of the suspect or the person identified. And then you arrest a random stranger who is then locked up for several weeks, ruining their lives (lose their job, lose their house, etc).

No, they're not supposed to be using the software and going from "surveillance video" to "arrest"

It should not take a judge in a courtroom to have to dismiss the case for obvious "this guy should never have been arrested in the first place".

It's only a matter of time before facial recognition says a black guy did the crime when it was clearly a white guy in the surveillance video. Or vice-versa.

And as long as police do not use their tools properly they shouldn't have access to them. And using the tools properly means understanding the limitations of it. Facial recognition is not a magic box where you insert video on one end and it spits out the name of the culprit on the other.

No, facial recognition is a tool, and it can be used, when used responsibly. The problem is, the police have not shown to be responsible users of the technology.

Especially when they can ruin lives due to misidentification. Once arrested, it can take 2 or 3 weeks before anyone processes your case. Which means you're stuck in jail for 2-3 weeks. Your job will likely fire you for not showing up to work. And you can lose your house because without money, no job, there goes your rent or mortgage payment. 21 days later someone goes "Oops, you look nothing like the suspect, sorry!" and then they dump you on the street. You lost your job, your house, your family is likely somewhere where you don't know.

(And yes, ICE uses the same tactics for those people they wrongly arrest)

If you're lucky great, you can get a lawyer who can expedite matters - but that shouldn't be the determining factor on whether a false arrest ruins your life.

time_t has been 64 bit on Linux for a long time now (over a decade). You haven't needed a 64-bit system for 64-bit time_t.

x32 changes the model for 64-bit computing - these are the C semantics.

Remember in C, sizeof(int) = sizeof(long) = sizeof(long long)

You can have 32 bit ints, 64 bit longs (long longs are 64-bit), and 64 bit pointers - referred to as ILP64 (int, long, pointer). This is traditional in Linux and similar operating systems.

Or you can have 32-bit int, 32-bit long, and 64-bit long longs (and 64-bit pointers) - LLP64 (long long, pointer) - this is Windows where lots of code assumed ints and longs were 32 bit.

x32 is where int is 64-bits, longs are 64-bit, but pointers are 32-bit. The code runs in 64-bit mode (on amd64 systems, this has benefits because amd64 has access to many more registers than in ia32), but pointers and address space is 32-bits (4GiB max for the application - note the kernel does not have to live in the upper memory).

It's a weird mode of operation because it's based on something where having the extra wide register set but limited memory space is a benefit, or for some architectures like ARM where AArch64 is much more efficient. Likely this is for operations where the data to be worked on is wide but streamed - think DSP or other signal processing applications where you don't need 64-bit pointers because your code is tiny, your data is moved back and forth between several buffers, but would like 64-bit wide registers to process with and having a lot of them is useful. Having 64-bit pointers would just be a waste.

But it's really a niche application where you're having so many pointers it might have an impact on RAM usage if you needed to keep them 64-bit.

Thanks, that is very interesting. But something smells fishy.

1. 1 false positive from "over 641,533 faces" seems too good to be true. Very few systems of any kind are that good, and facial recognition? I don't buy it. And that's an oddly specific number to be "over". It does not pass the smell test.

2. "Shows no bias" is similarly too good to be true and doesn't pass the smell test. Didn't Apple have some problem in the last year or two with trying to spiff up faces, where black skin didn't work as well? "No bias" is not credible.

3. "Zero unlawful arrests" is weasel words. Just because an arrest has conformed to various legal standards, such as having a warrant, being cautioned, not beaten up, etc, does not make it a proper arrest. Lots of people are acquitted at trial after having been lawfully arrested.

4. The rate has not changed. Well, yes, it must have, if this is the false positive rate, since it presumably once upon a time had 0 false positives and now has 1, and the denominator has been increasing all this time unless the first 641,533 faces were all recognized in the first day.

5. The only credible answer. There may well be no national false positive rate.

But it's an interesting response. Thanks.