People just seem to get really hung up on the point that error bars exist in the first place, and combine.

I suspect it has a lot to do with the way that rounding is taught in school. It's absolutely hammered into use that you should never round until the very end, otherwise you lose precision.

You can also reduce peek deceleration forces by using aerodynamic lift to stretch out the reentry over a longer period.

Seems more likely that Japan is designing this engine for a hypersonic cruise missile program, and the passenger aircraft concept is somewhat of a cover.

IMO, there is no point in a Mach-5 Aircraft (other than cruise missiles). There is potentially some point in Mach 2-3 aircraft, (not that we have ever made them commercially viable) but at the boundary to hypersonic, you might as well just switch to a suborbital hop concept.

A suborbital hop gets you to anywhere in the world within ~90min, avoids issues of supersonic overflight and you don't need to worry about the massive engineering issues caused by sustaining hypersonic flight. And as a bonus, the passengers get a hour of weightlessness.

The roughly equivalent VexRISC configuration (full with MMU) is only 2736 LUTs, running at 124 Mhz (on Cyclone V, which I'm pretty sure is the same arch)

I don’t think anyone would actually label it as microcode (not when the entire point of RISC was to avoid microcode) they would call it a sequencer or finite state machine; But really it’s the same thing. It’s certainly much simpler than the full microcode of any contemporary CISC, and the bulk of instructions execute in a single cycle without using it.

If you want a design with zero microcode, you really need to look at MIPS, or the original Berkeley RISC. Those ISAs go out of their way to avoid multicycle instructions. Not entirely successfully, but they don't use PLAs [1] to implement any state machines for the few remaining instructions like multiply and divide.

[0] http://daveshacks.blogspot.com/2016/01/inside-armv1-instruct...

[1] At least on the few MIPS designs I've looked at. And I'm not sure if they deliberately avoided PLAs for doctrine reasons, or it was just more efficient to do so.

More importantly, it's not the same thing at all. All the code in windows (at least until recently) was written by humans, understood by humans and reviewed by humans. And that code has stood the test of time, proven its value and stability in the wild, on billions of systems. The fact that the current maintainers haven't needed to understand or replace the code is some indication of the code's quality.

Almost none of Bun's rust code has been even seen by a human, and it's only about two weeks old.

I'm somewhat willing to accept vibe-coded code if it's either absolutely non-critical, well reviewed, or maybe in the long term if it's proven itself. But not two week old code.

That exception is experimental and somewhat limited; Only allows "well tested, high-quality" PRs on parts of the codebase that have a low probability of causing soundness issues, and it has a seperate review process with much higher standards.

And it requires the reviewer to agree to the use of LLMs ahead of time, before the PR is opened.

IMO, it has a high likelihood of degrading to a closed system, where some programmers with a good track record have little issue merging LLM generated PRs, while anyone without a reputation will struggle to even open an ai-assisted PR.

Bluetooth tethering is a thing, actually predates wifi tethering. Though it's not enabled unless you enable Personal Hotspot in your phone settings (and Android requires it to be enabled separately).

CarPlay complicates things, as it only uses bluetooth to pair, then it switches to using a wifi network (as bluetooth doesn't have anywhere near enough bandwidth). Maybe Apple automatically shares internet over that carplay connection?

I have no doubt that the car will use the internet connection if one is exposed, I just doubt it will be exposed automatically.

Using IFUNC to patch sshd was kind of elegant, it achieved rootkit like behaviour with a pre-existing mechanism. And sure, it might be possible for a secure daemon like sshd to drop enough privileges that it could protect itself from a malicious dynamically linked library.

But IFUNC was not required, neither was systemd. The game was lost as soon as the attacker had arbitrary code installed in a semi-common library. It doesn't have to get linked directly with sshd, it only needed to be linked into any program running as root, at least one time.

Most programs make zero effort to sandbox themselves, and as soon as one of those links with the malicious library, it could do anything. Like indirectly targeting sshd by patching its binary on disk (optionally hiding it with a rootkit), or using debug APIs to patch sshd in memory.

IFUNC, systemd, and the patched openssh are all irrelevant to the issue, that was simply the route this attacker took to leverage their foothold in libxz. There are thousands of potential routes the attacker could have taken, and we simply can't defend from all of them.

And skimming through the paper; the answer to this inverse is obviously yes. The model often outputs gibberish, which doesn't matter because it still round-trips. The fact that often lines up near a good english representation of the activation is simply because that's what compresses/roundtrips well.

So a malicious LLM/NLA pair could just use gibberish to conceal intentions. Or if it's been forced to avoid gibberish, it can conceal information with stenography.

And the experiment where they change "rabbit" to "mouse" in the explanation provides evidence that this might be happening. It was only successful 50% of the time, which might mean they failed to eliminate all "rabbitness" from the activation.

However, I suspect this is solvable with future work.

During training of the NLA, just munge the textural representation through a 3rd LLM: Have it randomly reorder and reword the explication into various different forms (use synonyms, different dialects), destroying any side-channels that aren't human readable.

The NLA would be forced to use human readable representations to get a successful round trip.

But it's a useful approximation for auditing.

Another bit of evidence for that: While they merged all the audio chips into a single S-APU chip, and both PPUs and the CPU into the 1CHIP, they never went the final step of merging the APU, PPU and CPU into a single chip. And they never shrunk the PCB to move the two chips closer.

------------

My other theory is that if the audio clock was derived from the video clock, then it would have a different sample rate on NSTC and PAL consoles; By giving it an independent crystal, they can make sure both models have the same audio sample rate.

It's probably a combination of many of these small factors prevented them from ever going to the effort of trying to make it work from a single crystal.

Was it that important to have an exactly 32000 Hz sample rate? They could have used a divide-by-21 to get within 0.2%, which would have been more accurate than that ceramic resonator. Or keep the existing divider and run resample all the audio to 27.97 KHz, which IMO would have been acceptable.

I've only really looked at a single AM2900 implementation (and it was far from optimal). Guess I need to dig deeper at some point.

> The ONES operation forces all the carry chain to 1 (ignoring operand) (you can do a ONES+1 to get arithmetic 0, but why?)

Forcing all carries to 1 inverts the output.

If I'm understanding the ALU correctly, (the datasheet doesn't show that part) it only implements OR and XOR. When combined with the ability to invert both inputs, AND can be implemented as !(!A OR !B), NAND is (!A OR !B) and so on.

Or maybe the ALU implements NOR and XNOR, and all the carry logic is physically inverted from what the documentation says.

But high speed lines are expensive, and NZ just doesn't have anywhere near the population density to justify it.

As for night trains, I'm pretty sure they can only exist where they are bridging multiple viable day train routes. Which is why that huge gap between Hamilton and Palmerston North is an issue.

And the route might actually be a bit short for a night train. If they electrified the entire distance (instead of using a diesel the whole way despite the fact 80% of the route is electrified) and did some improvements, they could probably get it down to an 8 hour trip.

> What about options for those living up north?

TBH, I'm not a fan of Auckland and don't really know what's going on with local public transport.

And also the vague idea of local rail service around Christchurch (interestingly, a private company bought the old DMUs from Auckland's local fleet after electrification and are just starting to run special trains for Rugby games).

Part of the problem is that there is only really only three metro areas in New Zealand. Auckland, Wellington and Christchurch. Everything else isn't really large enough to provide enough demand for a proper intercity route. And Christchurch isn't even on the same island, so you can't have a proper intercity train with the ferry getting in the way.

So the only potentially viable intercity route is Auckland to Wellington.

And apart from Hamilton and Palmerston North, (which already have commuter trains) there is absolutely nothing in the middle. The same distance in Europe or the US's eastern corridor would service 4-6 decently sized metro areas, and provide plenty of extra demand.

There just isn't enough potential demand to put a high-speed rail line through there. And without the high-speed rail, it's a 10 hour train trip that has zero chance of competing with a 1 hour plane ride.

Christchurch to Wellington is even worse. 6 hour train ride, at least an hour waiting for the ferry, 3.5 hour ferry ride. The plane does it in at little as 25 min in the air, there isn't enough time to reach cruising altitude. There is a reason why the route used to be serviced by an overnight ferry.

> And to be fair, looks like you can more or less cross the country, as long as you don't plan to get all the way to Invercargill

Yeah... but those aren't "intercity trains". They are scenic tourist trains that just so happen to be running along old intercity routes. Not bad as a tourism experience, but overpriced and not optimised for transportation needs.

The fact that you can't book both the Interislander ferry and costal pacific on the same website is very telling. They are literally run by the same company.

----------------------

If you are serious about the Christchurch to Invercargill, there is now a private company offering the occasional weekend trip: https://www.mainlander.co.nz/train-trips/the-mainlander-rail...

Same company that's providing the Rugby special trains, but this is using the old Capital Connection rolling stock. The train usually runs day trips up to Arthur's pass for cruise ships, but when there is a gap in that schedule they are running these Christchurch to Dunedin and Christchurch to Invercargill excursions.

Even more touristy than great journeys.