repiret

I discovered this algorithm a month ago or so, and have been telling everyone I can about it. I think it’s so damn cool.

My present Rust implementation can keep a sliding window sum of f32 at 300M/s.

I assert that onions and potatoes have roughly the same durability and ease of transport.

Lettuce and Tomatoes don't keep well, which adds more seasonal variability and reduces the ability of a futures market to smooth prices.

Compare with potatoes, which keep about as well an onions, and are farmed in the same areas. Look at onions and potatoes over a 5-year time span (because the default all-data time span is silly for this). It doesn't give enough control of the Y axis to make the comparison easy - for potatoes it shows me Y=40-320, for a range of 280; for onions it shows me Y=120-440, for a range of 320. This means that potatoes are more "zoomed in" and it's graph will exaggerate volatility relative to onions, but qualitatively, I'd say the potato graph looks smother just the same. This is exactly what economic theory says a futures market should do to the price.

No, the problem really is the prefetch itself when there are undesirable side-effects if the bus sees that memory read.

Speculative instruction fetches fetch code from "a location that you never asked it to execute code at" by design. If it already knew you asked it to execute code there, it wouldn't be speculative.

The Armv8/9-A architecture reference manual is clear that speculative instruction fetches are permitted in Device memory unless that memory is also marked NX. So if your hardware has side-effects from a certain address, but it maps it as Device non-NX memory, then your code is not "perfectly good and correct". Assigning correct memory attributes is one of the many things needed for correct code.

"Speculative instruction fetch to device memory crashes device" is in my list of favorite bugs ever found. I had ran into it on a Cortex-M4 without an MPU, so I couldn't even fix the memory attributes, the only solution was to gerrymander the compiled code to prevent the speculative fetch.

It's crazy that Armv8/9-A permits speculative instruction fetches to device memory. Crazy enough that I had to look it up to believe it:

"Hardware does not prevent speculative instruction fetches from a memory location with any of the Device memory attributes unless the memory location is also marked as execute-never for all Exception levels." - ARM DDI 0487K.a § B2.15.2

The Armv7-M spec is less clear. It does say: "The architecture does not permit speculative accesses to memory marked as Device," in contrast to Armv8/9-A which qualifies a similar statement with "data accesses". But then it later says "To ensure correctness, read-sensitive locations must be marked as non-executable". (This is all from ARM DDI 0403E.e § A3.5.7)

I don't have v7-A older handy to compare what they say.

I configure Mutt to run the HTML part through w3m and show me that instead of the text part, because of this exact misuse of multipart/alternative.

Most transport category aircraft have a better glide ratio than most single engine GA planes when configured for best glide. But they don’t cruise descend at best glide speeds or at idle thrust.

I’m talking about turbo props because the article’s hybrid technology is specifically for turbo props.

My challenge stands: find me a turbo prop that would be happy at idle thrust for either approach or cruise descent.

A car going down a slight hill on the freeway still needs a bit of gas to maintain speed.

My assertion is that there are no turboprop plans that can maintain a 3° glideslope at normal approach speed without thrust from the engines. If you think there is such a plane, name the type, and show me a citation from it's POH to support the claim.

Not really much room. Unlike a car going down a hill, an airplane descending still wants thrust from the engines, just not as much as in cruise.

Don’t conflate airplanes with rockets.

On an airplane, most of the energy in cruise is spent overcoming parasitic drag, not induced drag. It’s spent pushing the airmass out of the way as it moves forward, not creating lift to stay aloft.

For that reason, a change in weight does not significantly change cruise fuel usage.

Weight is still precious, but that’s because airplanes’ load are more often weight constrained than volume constrained, and capital and operating costs are such that you want to maximize the load.

strlen for netstring is O(log n).

It's mathematically impossible to describe an arbitrary length in a fixed length.

Because then the caller needs to treat it differently from non-empty buffers.

I live in the United States. I write software for a living. My wife is a physician.

If I had a need to spend $2k, I could do so easily, but I still think it’s a lot of money to burn. I wouldn’t spend it on a whim; I would not spend it without carefully, considering the value of what I get.

I would not even spend that much money in the businesses that I own, or recommended that my well capitalized employer spend that much money without being reasonably confident that the business would get good value for its money.

This feels like too far the other direction. I am of the opinion that the following are all reasonable, and I think most people would agree with me:

* Toll enforcement (the only thing allowed by the law)

* Speeding enforcement

* Parking enforcement

* Real-time alerting for vehicles that could be pulled over if you knew nothing other than the vehicle's identity. Stolen, unregistered, uninsured, amber-alert, etc. [1]

I think the following are all unreasonable, and I think most people would agree with me:

* Selling the data for any commercial purposes (perhaps with the exception of aggregated statistical data)

* Mining the data "suspicious patterns of activity".

I think the following is reasonable, but some people may disagree:

* Retaining the data for a limited time, so that if a crime is reported involving a specific vehicle, you can look back for sightings of the vehicle contemporaneous with the crime to help catch the bad guys.

Given my thoughts on what is and is not reasonable, I think the ideal policy is one that focuses on limiting retention, limiting sharing, and limiting the types of queries that can be performed on the data. Something like:

* Can retain the data for 90 days. Data that is evidence of a specific crime can be kept longer with the evidence file for that crime, and destroyed when the investigation is done.

* Can use the data where knowing a series of (time, place) pairs for a vehicle is probable cause of an infraction (or toll due). This covers speeding and parking and tools and red lights and registration/etc, but doesn't allow looking for suspicious patterns of activity.

* Can query the data for sightings of a specific vehicle with reasonable suspicion that the vehicle was involved in a crime. Need to keep records of these queries to identify abuse. Maybe need to notify owner when such a query is made.

* Can not disclose the data to third parties, except in the case when they agree to follow all these same rules (so you can share with other departments or law enforcement service providers, but that doesn't enable an end-run around the rules)

[1]: And I think it's important here that if data about a vehicle be eligible to be pulled over knowing nothing but it's license plate is out of date or otherwise wrong, then someone gets in serious trouble. Otherwise nobody is incentivized to keep their database up to date.

I don't care too much about hot-rodders either. California specifically requires the original emissions equipment remain intact. Here's two cases where that fails:

1. Close to 20 years ago I read about someone who converted a car to an EV with an old electric forklift motor, but then couldn't register the car. It was a model year that still required smog checks, but it couldn't pass a smog check because the original emissions equipment wasn't installed anymore.

2. My brother inherited our dad's 1992 pickup, and tries to keep it in running order mostly out of nostalgia. He would like to replace the engine with a newer model that would burn less fuel, produce more power, and correctly installed, no doubt would have lower emissions. But then it wouldn't pass the smog check, because it wouldn't still have the original emissions equipment.

Having said all that, I agree that it disproportionately impacts the poor, because the poor tend to drive older cars that are more likely to need repairs to pass an inspection, and because the inspection fees make a larger impact on the budget of the poor, and because the employment flexibility to be without their car for half a day for the inspection, or longer if repairs are needed, is not as common among the poor. You could subsidize the inspections for low value cars, which would help with the cost aspect, but I don't know a way to solve the other aspects beyond trying to find the minimum amount of inspection that meets the policy goals.

Periodic vehicle inspection for emissions and safety compliance. Many jurisdictions already have this for gas engine emissions, a handful of states already have safety inspections. Done right, it can be low burden and low cost, and basically put an end to Def deletion. Done poorly it's grift to the shops that do the inspections, and an economically external annoyance to vehicle owners, and unnecessarily limits the ability of people to tinker with their own vehicles.

My experience is that there's a correlation between powerful type systems and the property that once your program compiles, it's correct. Compiles == correct is rarely true in C or JavaScript. It's often true in Haskell and Rust. TypeScript is somewhere in between C and Rust.

There's a niche available for a language which is relatively easy for a human to read, but with a very powerful at the expense of difficult to use type system. The language would let you make all sorts of assertions whose meaning are easy for the human to see, but to compile would need to come along with correctness proofs. The language is meant to be written by AI, which can battle the compiler, and write the proofs, but then read by humans who can verify that the AI wrote the program they wanted and/or direct the AI to make changes.

Assuming you mean in the United Stares, can you cite a specific law or court case to support your position?

It occurs to me that the existence of paparazzi seems to be evidence against your position.

Or just `strace`.

This isn't the first time this month I've read about someone suffering consequences of mistaken identity after their facial recognition said they look like someone who committed a crime. I'm sure this is starting to happen at an alarming rate.

The fundamental problem is that among the 350 million people living in the United States, there are a lot of pairs of people who look pretty darn similar. It used to be impractical to ask a question like "who in the US looks like the person in this security footage", and so as a matter of practicality, once you found someone who looks like the suspect, you probably also have other evidence, even if it's pretty weak, linking them to the crime.

But with AI, you can ask "who in the US looks like this person", and so we need to re-calibrate what it means if all you know is that someone looks like a suspect. I am of the opinion that "looks like someone," in the absence of any other evidence, is reasonable suspicion, but not probable cause, that you are the person you look like. Reasonable suspicion is enough for the police to stop you on the street and ask for your ID, but not enough to arrest you. There are other data points that alone might not even be reasonable suspicion, but could be combined with "looks like someone" to make probable cause, such as "was near the place at the time the crime happened".

AI isn't really the problem, even whether or not the AI's determination that two people look alike is valid or reviewed by a human isn't the problem. The problem is assuming that because two people look alike they must be the same person, even if you have no other evidence of them being the same person.

If, like me, you were wondering how a 52 year old could have been a developer on a game you remember playing on an NES in the late 80s or early 90s: It looks like Īda's Castlevania involvement started around 2003, working in increasingly senior roles on Castlevania games released since then.

My insurance agent has recommended that once a year or so I carefully walk through the house with a video recorder, opening every cabinet and drawer and tool box and so on. It's easier than constructing a detailed inventory, but gives you the raw data you need to construct one in the unlikely even that you need it.

This is what I do too, but be warned about “fire proof” - a fire that results in the total loss of your house will create enough heat for enough time that fireproof gun safes and smaller fireproof lockboxes will be destroyed, or even if not, their contents will get hot enough to combust anyway.

A bank safe deposit box offers a different security profile that’s probably more robust against fire because banks burn less often than houses.

It’s probably not practical to really be robust against fire without being buried several feet deep.

As someone who recently replaced a few windows in my house, I can say in no uncertain terms that spending $1200 for a lamp and paying to feed it 0.58kW is cheaper than hiring a contractor to add another window. And it works all day.

This is really useful for those of us who are really only familiar with the US system. Let me restate a few things to make sure I understand, and follow with some questions:

1. The "procureur" and "juge d'instruction" are chosen from the same pool of judges, with the former appointed by the government executive, and the latter nominated by the judges themselves.

2. Does the executive choose one "procureur" to serve a particular region for a particular span of time, or do they choose a "procureur" every time there's some sort of criminal activity they think needs investigation?

3. How is the pool of judges themselves chosen? In the US, for example, federal judges are chosen by the president and confirmed by the senate, and serve for life. While state court judges are typically elected for a specified term.

4. Supposing we both live in France and I break into your house and steal from you. What happens next? For the sake of telling a story, suppose that you have a security camera from which I could be recognized, but not so clearly that anybody can be certain it's me until someone searches my garage and finds your stolen things. Walk me through the process of who does what?

I'm reminded of the monologue from Terminator 2:

> Watching John with the machine, it was suddenly so clear. The Terminator would never stop, it would never leave him... it would always be there. And it would never hurt him, never shout at him or get drunk and hit him, or say it couldn't spend time with him because it was too busy. And it would die to protect him. Of all the would-be fathers who came and went over the years, this thing, this machine, was the only one who measured up. In an insane world, it was the sanest choice.

The AI doctor will always have enough time for you, and always be at the top of their game with you. It becomes useful when it works better than an overworked midlevel, not when it competes with the best doctor on their best day. If we're not there already, we're darn close.

100ns intervals. My favorite part of that story is how long after Windows 95 was released before anybody discovered the bug.

> CPUs fetch data from memory in fixed-size blocks of so-many bytes, and performance degrades when data is misaligned.

A memory bus supports memory transactions of various sizes, with the largest size supported being a function of how many data lines there are. The following two statements are true of every memory bus with which I'm familiar, and I probably every bus in popular use: (1) only power-of-two sizes are supported; (2) only aligned transactions are supported.

Arm, x86, and RISC-V are relatively unique among the multitude of CPU architectures in that if they are asked to make an unaligned memory transaction, they will compose that transaction from multiple aligned transactions. Or maybe service it in cache and it never has to hit a memory bus.

Most CPU architectures, including PPC, MIPS, Sparc, and ColdFire/68k, will raise an exception when asked to perform a misaligned memory transaction.

The tradition of aligning data originated when in popular CPU architectures, if you couldn't assume that data was aligned, you would need to use many CPU instructions to simulate misalinged access in software. It continued in compilers for Arm and x86 because even though those CPUs could make multiple bus transactions in response to a single mis-aligned memory read, that takes time and so it was much slower.

I don't know for sure, but I would expect that on modern x86 and high performance Arm, the performance penalty is quite small, if there's any at all.