I think their legitimate concerns were more about AI slop.... which is technically a form of spam.
While it was difficult to make it follow instructions, GPT-2 was still reasonably good at generating SEO-spam websites, and reasonably easy to make it do so. AI slop was a very obvious usecase for LLMs as capable as GPT-2, and we are talking about an era were everyone was already concerned about the way "fake news" on social media was being used to manipulate people. Perhaps even more concerned than we are today.
But all evidence suggests OpenAI also had strong ulterior motives. They were busy readying the API groundwork for monetising it, and wanted to delay any competition by as much as possible.
Also, even if ignored the fact that it was a co-processor, we don't generally count the width of the floating point and vector registers.
Otherwise most modern CPUs would be labeled as either 256-bit or 512-bit.
These days we generally label CPUs based on the width of the general purpose registers (though, it gets messy with things like the 68000). I personally suspect we won't ever see GPRs wider than 64 bits.
Isn’t there a regulation for idle to full go-around thrust in a maximum of 8 seconds?
If so, it’s tight… but i feel like they should have made it if they had stuck to that plan. They commanded full power 15 seconds before the crash, and were pretty close to (if not slightly above) their stall speed (depends on load). I suspect they just needed another 10-20 knots and enough energy to climb.
The fact they were even in that situation is only worth philosophizing about to a point. Because they were only in that situation due to what appears to be a series of totally unacceptable decisions that got them there. Based on everything that's come out, I'm comfortable saying as a former military aviator that in my opinion, this crash happened due to a complete failure of airmanship on the part of both crew members.
- a) Flying an unacceptably sloppy approach that put them on short final going that fast, high, and overpowered. Professionalism is being on airspeed and/or angle of attack and on glidepath . . . no excuses.
- b) Responding to a) by trying to force the jet onto the runway, when any aircrew member with half a brain should understand how badly you're going to float in ground effect when you're that fast and that overpowered. And what that's going to in turn do to your spoilers and thrust reversers that depend on weight-on-wheels before activating. Professionalism is recognizing a botched approach, swallowing your ego, and taking it the hell around.
- c) The pilot not flying sitting there like a coward and not taking the controls from the pilot flying. If someone hits a go-around criterion and isn't going around, YOU TAKE THE CONTROLS AND EXECUTE ONE. Professionalism is proper crew coordination and proper assertiveness in the cockpit.
This whole thing seems to just boil down to a complete failure of airmanship and a complete failure of professionalism all around. If I'd done that or allowed my pilot to do that, I'd expect to have had my wings pulled. If the investigation reveals more, I'll change my mind. But it ain't looking good.
Advice I've seen many experienced captains give when you're FO and captain is fixated on landing: declare going around to tower. It avoids a fight over controls or the captain trying to override you; in that moment they're unlikely to jump on the radio and say "no we aren't".
> They commanded full power 15 seconds before the crash
Not 15 seconds before the crash, 15 seconds before the end of the recording. Then overran the runway 10 seconds before the end of the recording, then started crashing into objects 7 seconds before the end of the recording.
Thrust was reduced back to idle 11 seconds before the end of the recording, so just before departing the runway.
They aborted the go-around attempt because they were literally at the end of the runway; Probably because they thought it would be "safer" to run off the end without the engines rapidly reaching full thrust.
How sure are you? Could it actually happen that way 95% of the time, which means they don’t crash and we never hear about it? Likely a pilot gets disciplined for the other errors and nobody else cares? This exact thing could happen 20 times with everything turning up relatively ok and we only heard about it because they didn’t make that final call correctly either.
To be clear I’m not an aviator, just an armchair statistician with an interest in aviation
> This exact thing could happen 20 times with everything turning up relatively ok and we only heard about it because they didn’t make that final call correctly either
This concept is called normalization of deviance and is the cause of a lot of accidents in aviation and other fields.
This was a discussion in the aviation subreddit too. I am also not an aviator, but just someone with an interest.
What the outcome of the discussion was that it depends on the culture and training of the organisation. It could be possible that it does happen like this 95% of the time with no crash in that specific organisation.
> the "decoy notes" may be considered an "effective technical measure" from the "Digital Millennium Copyright Act".
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.
shitty CAPTCHA’s and simple checksums have been ruled to be “effective measures”, so this would probably be too.
However, Section 1201(f) is designed to allow developers leeway in reverse engineering to make "independently created computer programs" talk to other "computer programs". But this usually distinguishes between talking to a binary (good) and reading a media file (bad).
My guess is the encoder is probably legal under 1201(f) because it’s reverse engineering a DMCA covered application to create new media files for it to use. But the decoder would be illegal because it reverse engineers a DMCA covered application to extract copyrighted media.
No, on appeal the simple checksum was ruled to NOT be an effective measure. [0]
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.
You're underselling this report. The court found that a whole lot of computer code that's intended to be a roadblock to interoperability isn't copyrightable - great news for adversarial reverse engineers everywhere. Recommend reading.
Also it was an appeal to a preliminary judgement. The lower court said: okay, you're most likely going to lose so you have to stop selling these until we find out whether you lose. The appeal court said: actually this case is almost completely bogus and you're probably going to win, so you can keep selling them.
The problem is that unlike data prefetch, the so-called "instruction prefetch" is not actually prefetch at all.
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.
Well yes. That is why the "prefetch" is a problem.
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.
The fact it does speculative execution and dual-issue is well documented. The chipsandcheese article [0] is probably the best overview.
The "how" it does dual-issue is not documented at all, so I'm speculating. There is no smoking gun saying "register renaming". While it would be possible to implement its known capabilities without any kind of renaming, it would be so much simpler to implement it with register renaming.
The thing is.. once your forwarding network and hazard detection gets complicated enough, it basically becomes a janky form of register renaming. So it's cleaner to just implement proper register renaming, and actually saves hardware.
While the A53 might issue in-order, the pipelines have different lengths and they don't finish executing in order.
I find the fact the A53 can speculate a few instructions past a cache miss to be very interesting, along with the fact it can issue two writes to the same logical register in a single cycle.
Also, the smoking gun is that the A510 (same lineage as the A53) is documented to do out-of-order issue (see chipsandcheese again [1]), so it must be doing register renaming. ARM still insist on still calling it an in-order core because it's OoO is so much more limited to modern OoO cores, but it's more OoO than early PowerPC designs (including the G3) that everyone is happy applying the OoO label to.
I suspect it's actually possible to prove such an algorithm can't exist.
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.
COM would ask the object for its canonical IUnknown pointer. Rust answers that the question has been optimized away.
A ZST has one possible value, not one possible occurrence. That doesn't prove that no identity-dependent algorithm can exist; it proves that a ZST cannot carry the identity such an algorithm requires. If identity matters, it must be represented somewhere -- and then it is no longer zero-overhead.
COM is essentially a language-neutral ABI built from C++-style vtables, and QueryInterface is essentially a type-safe dynamic_cast.
In Rumsfeldian terms, IUnknown provides a known way to interrogate an otherwise unknown object. QueryInterface resolves known unknowns by asking about specific interface IDs; it cannot ask about unknown unknowns.
> COM is essentially a formal way of using C++ vtables [1] from C and other languages, so you can create and consume components in any language, and call back and forth between them. It's a way of expressing a rational subset of how C++ classes work and format in memory, in a way that can be implemented in other languages.
> It was the outcome of the C / C++ / Visual Basic language wars at Microsoft.
> whereas a Rust object only has identity if it has a non-zero size.
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.
If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore
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.
I was not expecting the CT scan to be able to identify the cores within the die.
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.
You can typically see the L1/L2 SRAM cache regions just by looking for continuous patterns, then try to divide it into the number of cores or core groups you're looking for.
This is only applicable to die photographs of the silicon layer.
For CT scans, which use X-rays, the visible structure is very likely due to the metallic (copper) interconnect, clock- and power-delivery layers, which are generally quite different from the underlying transistors.
These layers are larger-scale, and copper also absorbs X-rays much more strongly than silicon.
While it was difficult to make it follow instructions, GPT-2 was still reasonably good at generating SEO-spam websites, and reasonably easy to make it do so. AI slop was a very obvious usecase for LLMs as capable as GPT-2, and we are talking about an era were everyone was already concerned about the way "fake news" on social media was being used to manipulate people. Perhaps even more concerned than we are today.
But all evidence suggests OpenAI also had strong ulterior motives. They were busy readying the API groundwork for monetising it, and wanted to delay any competition by as much as possible.
reply