> The FAA has one of my favorite examples of thoughtful rulemaking. They haven't banned flying with a baby on your lap, because the extra cost would mean many parents would drive instead. Since driving is far less safe than flying, a ban would lead to more deaths. I'd love to see more of this "all things considered" thinking around bans.
In terms of CO2e, a familiy of 2 + a kid driving a car instead of flying results in quite a bit of less emissions. Depending on the assumed mortality per tonne CO2e, driving might lead to a lot less deaths.
This is of course quite unreliable data, but one example of just to say how "all things considered" is very hard and almost always still comes down to a judgement call.
Yes. This. We all - and especially parents - spend all day every day evaluating risks. The FAA does not need to decide for me the level of risk between holding a baby in my arms vs having it in a sling during take off and landing. That's very silly.
For real. For something like car seats, arguably the regulation was what we needed to get them adopted. This though, seems as necessary as government regulators deciding if I can babywear my child when walking down the street. The relative risks and benefits are impossible to fully compare with this issue, and the impact on other people is nil whether it's baby in lap or baby in carrier.
> WhatsApp is similar by the way. Unless you enable E2E backups, they end up in iCloud/Google Drive backups and are only encrypted at rest
One of the few good things about WhatsApp is that Meta can very credibly claim that they can't access the backups (as they're not stored by Meta). Meta holds the encryption key & Google/Apple hold the backups, so at least you now have deal with two entities to get the data.
I don't think without forcing more customers to loose data (e.g. by requiring them keeping an encryption pin/key) it's possible to perform backups in a (much) better way.
> I don't think without forcing more customers to loose data (e.g. by requiring them keeping an encryption pin/key) it's possible to perform backups in a (much) better way.
I have full confidence that the industry would be quick to innovate if they were forced to, but that's not in their interest nor the government's interest.
Here's a simple one: Build an open standards-based system where users choose their backup provider and let them decide whether they prefer to have full control over the encryption keys or whether they want them to be managed by a third party. Educate them so that they can at least try to make an informed decision. Warn them about the risks and jurisdictions of built-in providers.
If someone wants to continue using their device as-is? Cool, 2 taps and they're done.
Do they want to store all of their app backups on their NAS? Make it as easy as switching your default browser.
> Here's a simple one: Build an open standards-based system where users choose their backup provider and let them decide whether they prefer to have full control over the encryption keys or whether they want them to be managed by a third party. Educate them so that they can at least try to make an informed decision. Warn them about the risks and jurisdictions of built-in providers.
WhatsApp performs (on Android) backups inside a normal directory. You can just backup it via e.g. Syncthing, which I've done in the past.
It doesn't get much more standards based. Strongly pushing users to deviate from the standard flow IMHO risks them quickly choosing poorer options (e.g. a free, dubious, online hoster). At least with the current setup, the "easy option" is quite safe in terms of not loosing data and very low risk that anyone apart from you and governments with lawful access ever accesses the data.
I see, I wasn't familiar with the way WhatsApp does this. I was talking more broadly about iOS/Android app data backups in general.
> At least with the current setup, the "easy option" is quite safe in terms of not loosing data and very low risk that anyone apart from you and governments with lawful access ever accesses the data.
The backups would still be encrypted and you could even have Apple/Google hold onto the key (if you wanted to), but if the data was stored elsewhere then neither party could access it unilaterally.
I'd argue that should/could be relevant, but isn't in reality. Do two global data processors more happy to work with governments/law enforcement exist?
> 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.
In terms of CO2e, a familiy of 2 + a kid driving a car instead of flying results in quite a bit of less emissions. Depending on the assumed mortality per tonne CO2e, driving might lead to a lot less deaths.
This is of course quite unreliable data, but one example of just to say how "all things considered" is very hard and almost always still comes down to a judgement call.