And while courts might have ruled that a CAPTCHA might count as a "technological measure" they haven't gotten as far as ruling them as "effective" yet.

But in general yes. The protection scheme doesn't need to be well designed or free of design flaws to count as "effective". But from what I can tell, it does need to be a valid attempt at some cryptographic scheme requiring a secret known only to the copyright holder.

[0] https://law.justia.com/cases/federal/appellate-courts/F3/387...

But the original question was asking why disabling data prefetching to a memory region didn't automatically disable instruction prefetching at the same time.

And the answer is that speculative execution is a completely different mechanism that I'm not even sure can be disabled, at least not per memory region.

I really hope not. My understanding is that to be "effective" it needs to at least be a form of encryption with a secret key. At least, I'm not aware of any case law that allowed anything less than that.

IMO, "dummy notes" are nothing more than a form of obfuscation. If it's obvious how to filter them out, then I don't think it comes close to meeting the bare minimum of what might count as an "effective technical measure".

Of course, who knows what way the courts will rule if it ever reached that far.

It's simply speculative execution. Which doesn't look any different to regular execution. The fetcher has no idea that its predicted branch is about to invalidated and flushed, otherwise it would never have issued that fetch.

Actually, on a modern OoO core, [0] it's very rare for the instruction fetcher to not be doing speculative fetches. Even when it's not predicting a branch, the fact that it has "predicted" the lack of a branch is speculative in itself. It assumes it didn't fetch a branch in the last cycle, but it can't be sure until after instruction decoding, which takes at least 2 cycles (more on larger L1i caches).

About the only time the instruction fetcher is not doing speculative fetching is for a single cycle after each miss-predicted branch.

[0] Or even something technically in-order, like the Cortex A53 cores here. They might issue in-order, but because of how they implement dual issue, they look somewhat close to a simple OoO core... I suspect they actually do register renaming. And (most importantly) importantly they have a branch predictor.

By definition, a ZST hold no runtime data. It does hold some compile-time data based on its existence, but after compiling, that has been type erased away.

Since a ZST holds zero bits of state, there can only be one valid instance of it. You can't have multiple different versions of the same ZST representing different things.

So if you have one, you automatically know it's going to be equal to all other instances of the same ZST type. And not equal to any other ZSTs. There is no point doing a pointer comparison, as that gives you no extra information, type ownership is enough.

Rust also has the complication that function pointers are not guaranteed to have an unique identity; If multiple functions compile to the same code, the compiler is allowed de-duplicate them.

The documentation [0] also warns it's also possible for the compiler to create multiple versions of the same function. And while I've absolutely seen the compiler to create multiple optimised versions of functions in disassembled code (partial inlining based on the caller), I'm not sure it's possible to get pointers to more than one version.

[0] https://doc.rust-lang.org/std/ptr/fn.fn_addr_eq.html

Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?

But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.

But now I think about it, the metal layers (especially traces carrying power) are probably think enough, and different enough to show up. And even just power distribution is enough for the shape of the cores to be visible.

The pilots took exactly enough fuel to reach their destination. They didn't have enough fuel to divert to an alternative airport. They didn't even have the mandatory 30min of reserve fuel. They did not account for a minor holding pattern just before landing (ironically, because another plane had a fuel leak).

The crew failed to declare a fuel emergency, and crashed 18km from the airport. They had only been in the hold for 10 min when their engines ran out.. they were very short of fuel, the pilots knew they were short. They should have diverted (or declared a fuel emergency) almost an hour earlier, but they didn't want anyone to know how close they were cutting it.

There aren't that many existing flight routes that will fit into the 125 mile range (though the existence of this plane might change that), so I suspect we will see most of these planes go into service on slightly longer routes. So they will probably still need one cycle per flight.

Though... The video isn't quite clear if the 125 miles is what they can fly without starting the turbines or if it's what they can fly without needing the turbines ready to act as an emergency reserve. I actually suspect it's the later and this aircraft can make it to 200+ miles without starting the turbines.

Where I live, there aren't that many 125 mile flights, but there are a lot of 200 mile fights.

I also suspect the turbines are sized so that only need to start one of the two turbines on most flights, which would extend lifetime a lot. Ideally the turbines would be sized so that one is enough for cruising, and with two you can actually charge the batteries after a go-around (enough to enable a second and third go-around)

But still very serious. 9 simultaneous fuel emergencies could have easily overwhelmed ATC and snowballed to worse issues.

Something lead 10 different aircraft to make the exact same mistake and find themselves without enough fuel for a safe diversion. There will be recommendations to try and prevent it from happening again.

You make it sound like it is acceptable for a badly planned flight to have a fuel emergency. It is not.

If there is a fuel emergency (or the plane lands with less than 30min of fuel) there will be an incident investigation that treats the situation as serious as if the plane had crashed. If the investigation discovers it was nothing more than bad planning, (at minimum) the planning procedures will be changed to ensure it never happens again.

I somewhat doubt that. Part of the advantage of the design is that the generators don't need to be sized as big enough to power take off, climb and a potential go-around on landing. They only need to be sized as big enough for cruising.

So powering them up during critical phases wouldn't help with safety. If anything, normal operating procedures might actually require shutting them down during critical phases.

What this does mean is that the batteries need to be reasonably full when it comes into land, possibly as high as 50%. And most go arounds will require immediately powering up the generators, so it probably needs to be fuelled for all but the shortest flights.

Looks like the most important step towards tier two is mostly about proving the CI infrastructure is reliable (which takes time at tier 3), and have at least two core developers committed to fixing any issues (within 24 hours)

It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.

The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.

Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.

What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it). And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.

The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see/argue that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?

For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get anywhere near proper experience that it just wasn't worth it, and even then many apps were starting to throw a fit when they detected a rooted device.

And at the same time, the stock android experience from most vendors was now good enough. I didn't even check custom ROM compatibly for my last Android two purchases (both Samsung). But it was nice to have the option of rooting and maybe finding/making a custom ROM Samsung removed that in their last update to One UI :(

But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.

Interesting choice of cropping for that quote.

If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”

You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.

And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.