danhor

> 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.

> 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.

> 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.

> 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.

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.

> 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.

> 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).

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.

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.

It's still the lingua-franca of ASIC/FPGA/Simulation, especially for scripting the tools.

I think it's slowly being replaced there by Python, but it's very slow.

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.