phire

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.

We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.

Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.

But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.

Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.

But only the first 256 KB was on the motherboard, you needed a memory expansion card for the extra 384 KB, and I don't think they really existed in 1982.

Actually, you could somewhat break the 640KB limit in the early days (not that most people could afford that much RAM) days. Until EGA came along in 1984, there was free address space upto 704KB that you could use as conventional memory without much issue (or 736KB if you limited yourself to CGA).

And later we had the mess of EMS, which would work on the original 5150 with the right expansion card (and the right software to take advantage of it, like Lotus 123)

I think the CH32v303's single V4F core might be slightly more capable than the Hazard 3 cores RISC-V cores (as it has a hardware FPU), but for everything else the RP2354 is probably better (and the ARM cores do have hardware FPUs)

Not as much freedom as they would get with something open like RISC-V, as ARM have strict rules around private ISA extensions (like how Apple doesn't publicly document AMX). But that extra control is generally a good thing for the health of the wider ARM ecosystem.

And yes, there is a bunch of funding being pumped into it. I do have hope that some kind of RISC-V linux workstation will be viable in the next 5 years, without sacrificing too much performance or my wallet. I just wouldn't expect that to translate into making inroads into existing markets where x86 and arm have moats, like android/apple smartphones and more typical desktop/laptop workloads (even on linux).

I wouldn't count the AI/GPU stuff, those are generally pretty simple RISC pipelines with large vector units. Though TensTorrent do actually have a high-performance out-of-order rva23 core [1] that would be able to compete in this space. They are currently selling it as a "core for agentic workloads"

[1] https://tenstorrent.com/en/ip/risc-v-cpu9719654910d.pdf

Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the lines of minor nitpicks.

The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.

Before this, the author has never recommended others stay away from RISC-V, just stated their own distaste for it and a personal preference to use any other ISA if given a choice.

Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end.

People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria.

The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up.

I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).

Not bizarre.

The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.

It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.

The lack of flags on those ALUs probably tells us more about the lengths CPU designers will go for reasonably small savings than it tells us about how much flags actually costs. And it's probably more of a "our metrics never gave us enough justification to even consider adding flags to the extra three ALUs" than "we considered it, but the cost was too high".

But version 1.0 of the spec [1] was released all the way back in May 2011, and the first RISC-V chip was taped out at the same time. This is 5 months before ARMv8 was even announced, and we didn't start seeing actual aarch64 chips until late 2013.

And TBH, I'm not sure anyone realised just how good of an ISA aarch64 is until quite a bit later.

RISC-V 1.0 isn't binary compatible with modern RISC-V, they hadn't frozen the encoding, but rough design is all there.

[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2011/Archive/EE...

That's a good point.

If some RISC-V μarch was going to invest the extra gates for a complex fusion setup, the search isn't actually going to slow anything down, as it can run in parallel with other frontend operations (like renaming).

I always just assumed fusion was done as early as possible, only considering instructions that are right next to each-other (that's certainly the intent of the RISC-V spec), and then resolved immediately after decode.

But maybe it's better to do it right at the end of the front end; After renaming, during insertion into the scheduler.

Despite my curiosity, I explicitly refused to agree to Apples terms for accessing those documents, because they were very draconian. The terms absolutely forbids using the information for anything other than optimising software for apple devices.

Discussing the design tradeoffs of RISC-V μarches couldn't be further from "optimising software for apple's devices".

Though, I guess fusing after cracking makes things easier because you don't actually have to search for fusion candidates (supported by the fact that Apple's Firestorm doesn't seem to make any effort to fuse things that aren't alu + branch, crypto, or amx)

But the argument in the spec explicitly uses the "added complexity to out-of-order microarchitectures" as a part of the justification for not having conditional move (and flags). It's the most commonly parroted part of the argument (see above) and the part of the argument I'm responding to.

I actually agree with much of the spec's argument. The cost of not having flags is pretty low, the MIPS approach does work pretty well, and it does simply things.

I'm just not sure it was the right trade off, and I strongly disagree with its attempt to use OoO cores as part of the justification.