> Nuclear has the most bizzare cost curve of any new technology where every year it costs more than the year before; a pattern which makes effectively no sense and is really only explainable by the heavy and effective political attack that nuclear has been under in the US and EU.
Or by generally exploding costs of megaprojects. Look at e.g. high-speed-rail in UK, France, Germany, ... . The first projects were the cheapest, after that it only got more and more expensive.
And the much heavier regulatory environment exists for a bloody reason.
The US alone spent billions to clean up superfund sites on the taxpayers dime (because companies created a huge mess in pursuit of profit and unhampered by regulation in the 20th century).
Everything that exists for a reason; the question is whether the reason is good. We've spent decades being told that climate change is going to cost us percentages of GDP to avoid, and your first counterexample is the suggestion that mitigations might be in the billions for the US over the course of a century.
One of those numbers is bigger than the other; and it favours nuclear pretty decisively. The regulations set up an environment where business as usual appears to be worse than if actual unlikely nuclear catastrophe occurred, all the air pollution in the interim and the reduced access to cheap abundant energy are real problems that have real consequences.
Whoever accepted those reasons has blood on their hands, so well might they be called "bloody reasons". The consequences have been serious and terrible even before getting in to oil-related resource wars and the like.
The PS5 and Xbox are also very close to being an x86 PC, but you're not installing your own OS on there even though there are few technical hurdles if the manufacturer removed the mechanisms to prevent that.
> Nothing stops someone from taking the free Windows Vivado and making it run on Linux
The EULA and the fact that the linux versior runs faster & has fewer bugs.
> just the device-dependent backend would be a major improvement and the frontend and optimizer could be shared with other toolchains
That's yosys and it's used by smaller commercial vendors.
> or reverse engineering then bitstream format for these FPGAs
Getting the timing is the hard part (+ good routing afterwards). The bitstream format has AFAIK mostly been reversed. 7 series has mediocre support , but US, US+ and Versal doesn't (probably because they're too expensive for personal usage).
You can just ignore the EULA. Nobody is coming to get you.
Sounds like yosys is good. Why is nobody using it? Why are we all hoping for Vivado instead of just using Yosys?
You can extract the timing information from Vivado. Such information is not copyrightable. You should be able to extract timing data and connectivity data from anything supported by the free version. You could also collaborate with someone with a really fast oscilloscope to gather some timing yourself, though that'll be extremely tedious.
Even if you just get the connectivity data and bitstream format and no timing, that's massively useful for less-than-high-speed projects. A single open source developer just has to make a contribution, doesn't have to do the whole thing in one go. The reverse engineering parts are often the most valuable, especially if they require access to hardware.
> You can just ignore the EULA. Nobody is coming to get you.
You can, but it's not gonna gain broad attention.
> Why is nobody using it?
It's used for chips with a good open source backend (lattice, gatemate). But it's non-trivial to integrate with the vivado backend and doesn't bring many benefits when used as such.
> You can extract the timing information from Vivado. Such information is not copyrightable.
Yes
> You could also collaborate with someone with a really fast oscilloscope to gather some timing yourself
No. Especially not fast-fast and slow-slow corners.
> Even if you just get the connectivity data and bitstream format and no timing, that's massively useful for less-than-high-speed projects.
Not really, you need at least a rough worst-case estimate. Otherwise even trivial designs might not work.
> A single open source developer just has to make a contribution, doesn't have to do the whole thing in one go.
A large part (clocks, routing, LUTs, BRAM, IO, a basic timing model) has to work, otherwise it's not really usable.
It's really non-trivial to get to a basic usable point. I would estimate at least 4-5 very experienced people working on this 2-3 years. Nothing impossible, but also not something that easily happens.
> > You can just ignore the EULA. Nobody is coming to get you.
> You can, but it's not gonna gain broad attention.
True I guess nobody ever gave a shit about The Pirate Bay. That project died without gathering a single user.
> > Why is nobody using it?
> It's used for chips with a good open source backend (lattice, gatemate). But it's non-trivial to integrate with the vivado backend and doesn't bring many benefits when used as such.
Sounds like someone should reverse engineer the vivado backend so it's not needed any more.
A PDF of a long document such as a standard or reference manual is almost always preferable to an HTML version. HTML versions have issues with formatting, searching (as browsers struggle with multi-thousand page documents and non-native search document search implementations almost always suck), indexing, correct behavior on windows size change (especially a side-by-side pdf view is almost unheard of for webpages), ... . Some vendors have switched to online-only for some documents and it always annoys me.
Except the PDF is not responsive at all and you can't increase or decrease the font size without increasing the whole width of page.
> Some vendors have switched to online-only for some documents and it always annoys me.
HTML shouldn't mean online-only. If the vendor isn't trying to make it hard to download, you should always be able to convert to PDF. But PDF to HTML is very hard or impossible.
In any technical/scientific document I do not want to increase or decrease the size of any element, e.g. of one of the fonts.
You only want to do an overall proportional zoom, when needed.
A well-designed document page has appropriate size ratios between various kinds of texts, formulae, tables and images, which should not be corrupted by changing the size of a single element.
The pages where the author has not formatted them adequately are ugly and hard to understand, which is what you typically see when this kind of content is written as HTML/EPUB documents, which are rendered non-deterministically.
Lazy writers may like HTML, but readers who must read and search through vast amounts of technical documentation do not like it.
There are many good PDF readers that are adequate for reading and searching even huge documents, but I have never seen any tool that works acceptably for EPUB/HTML big documents, which is not surprising because no tool can compensate the fact that the writer of the document did not design the layout of the pages carefully.
I absolutely want to increase or decrease the font while keeping the whole width unchanged. This is not possible with PDF. Or maybe it is, but I've never seen a PDF file that supports it. I may be reading on a tiny phone or on a FULL HD monitor. Or I may want to put the file on the left side of the monitor and something else on the right. If I'm on a huge monitor, I might not be OK with tiny fonts. I actually like tiny fonts sometimes, but other times I want to zoom everything. I think at night, where my eyes are more tired and when I have shut off the lighting in the room, I prefer bigger fonts.
I don't particularly care about increasing fonts ONLY. I've mainly done that on Firefox for Android years ago. The standard browser zoom (with CTRL++, CTRL+- or CTRL+WHEEL_UP, CTRL+WHEEL_DOWN) increases everything proportionally. The exceptions are newer websites that try to cram too much logic about what should be zoomed or hidden at a given level of zoom, but I'm not talking about 5 MB SPAs, but normal HTML sites.
I have read vast amounts of docs and I prefer HTML. So OK, I agree that some people want something unresponsive that looks like a printed page. But I think the issue is with how unpolished most EPUB readers are, not in the format itself.
For "underetministic" rendering, it's usually a PDF that had 2 columns, placed an image on the bottom of column 2 and referred to it from the top of column 1. If you automatically make an EPUB from that, the image would be far from where it's referred to. But nothing's stopping you from putting an image right after the paragraph that refers to it.
It's often a requirement for bare metal embedded development (too heavy in terms of memory), so it's basically unavoidable. Non-standard languages are very common for this kind of thing, just look at the linux-flavoured C.
Signal Priority only works well if the arrival time of the bus can be predicted some time before arrival at the signal (~30 seconds is a number I've heard a few times). As bus stopping times are highly unpredictable, a lower number of bus stops makes signal priority work much better (and far-side bus stops).
Furthermore signal priority and own lanes are almost always beaten by good circulation planning, reducing the number of traffic lights and cars on the route of the bus.
Certainly not with hydrogen directly. It might be involved in the production chain, but it's such a pain. If it's at all possible to electrify, that'll very likely win.
For flights, a combination of batteries for smaller, regional planes starting with "islands hoppers" now and SAF from either Biofuel or produced from Electricity (with Hydrogen as an intermediate step). Although I think that we might first see moves to reduce the 2x non CO2 Climate Impacts which can be much cheaper to tackle (such as Contrails).
For maritime applications, batteries when regularly near ports, probably hybrids with methanol for cross-ocean passage far away from coasts.
The Hazard 3 is basically a hobby project of Luke Wren, a Raspberry Pi Employee. He's contiuing to evolve it further, but I don't think it's ready for a full replacement of the Cortex-M yet, especially in regards to the Security Features.
The source code is all from Luke Wren and I don't think other cores use the source code directly, but improvements to test harnesses or general implementation patterns as well as better software support help other cores: https://github.com/Wren6991/Hazard3
For the SoCs I would expect to see an off-the-shelf Risc-V core (certainly no Hazard3 as the main CPU), but we'll see.
The Hazard3 in the Pico 2 are bigger, more capable cores than the Cortex-M0 in the first Pico, and therefore in general faster at the same clock for compiled code.
You're supposed to be able to just recompile most Pico projects to use them as long as there is no ARM assembly in it.
They are only inferior to the ARM Cortex-M33 cores in the Pico 2.
I know the "basically" is probably doing a bunch of heavy lifting, but dang, that's still awesome to think about. I didn't know hardware development was at the point where a hobby project CPU, apparently mostly developed by one guy, can realistically end up in a mass produced product like that.
I am curious to know which RISC-V design they'll go for in this SOC.
M. Wren getting real hard experience on RISC-V is going only to help RP to select and audit more seriously any RISC-V design which would make its way in their SOCs.
I just don't want to contribute to arm IP racketering (and we have mpeg and hdmi to take into account too with avX and eDP/DP).
My "Homeserver" with its database running on an old laptop has less downtime than AWS.
I expect most, if not 99%, of all businesses can cope with a hardware failure and the associated downtime while restoring to a different server, judging from the impact of the recent AWS outage and the collective shrug in response. With a proper raid setup, data loss should be quite rare, if more is required a primary + secondary setup with a manual failover isn't hard.
Or by generally exploding costs of megaprojects. Look at e.g. high-speed-rail in UK, France, Germany, ... . The first projects were the cheapest, after that it only got more and more expensive.