Even if this technique is much worse (I can certainly believe it is) the price might allow uses that would never be practical with MRI even with the best financial support. For example, ultrasound might be viable for use in GPs or small medical facilities which could never dream of justifying an MRI machine.

Scenario 1: 20% of staff tested failed. Individual targeting is pointless because the issue is systemic. This has happened in aviation, it’s common for accident investigators to conclude that the entire company culture (or even the entire industry) has failed to handle a problem. They don’t waste time in cases like this pointing at individuals.

Scenario 2: you test very regularly and nobody fails the tests. Except Bob, he fails the tests. In this scenario, your threat analysis document will recommend retraining, firing, or restricting Bob specifically.

Scenario 2 almost never happens because nobody has data that good. If your sampling frequency or ability to conduct tests are limited, no specific sample is enough to cover the entire problem. If you focus on a punishing (or just re-educating) the 20% who failed then your next test will fail for (potentially) 20% of the 80% who weren’t retrained, and thus didn’t learn anything.

TLDR: you need to choose the approach based on the situation, but we collectively tend to treat security poorly enough that we’re almost never in the fortunate situation where scenario 2 fits.

Flags don’t exist for the period where they’re gaining recognition. Compromising the significance of the iconography for the temporary gain of not being misidentified during the period it isn’t recognisable would just mean if it gains recognition it will forever be less than it could be.

In other words, with flags you need to play to win, not to survive. Better that the attempt have a higher risk of failure with a great flag than a lower risk with a mediocre flag.

The pale blue dot is an excellent way to represent a global outlook and “we’re all in it together”, not sure I can think of a better pedigree for this concept. I’d perhaps have been tempted to make it a smaller blue dot, but flags do need to be recognised at a distance, so it can’t be too much smaller.

Of course there’s a lot of other uses of fossil fuels than just electricity, so we’re still using more each year and probably will for a while yet, but it’s still a major milestone and a change in how the world works that can be celebrated, especially given so many things are switching towards electricity as a basis at the same time.

We are fixing the problem too slowly, but the ball is rolling faster and faster now, signs a promising that we will eventually fix it, now the question is how much damage will be done before we get there rather than whether we’ll get there.

https://ember-energy.org/latest-insights/global-electricity-...

I fully admit that personal experience has biased me strongly in favour of c-sections, but only when the stats support them, which they often do.

The real question is whether detransitioning or other negative outcomes are greater than the number of suicides prevented by allowing early transitioning, and that’s a rather more complicated hurdle to jump.

Of course we’ll need a way to resolve fluctuations both rapid and slower. Rapid fluctuations are handled by pumped hydro and increasingly by batteries.

The slow fluctuations (day/night all the way to summer/winter and good/bad weather patterns) are much trickier, I think it’s still unclear how well handle them, but it will certainly be partly handled by having an excess of renewables, though we’ll likely need some other solutions too, nuclear is probably one of them.

In the extreme case, as road coverage approaches 100%, the city stops containing buildings so the traffic will drop towards zero, so there’s actually a balance point somewhere, but roads are quite inefficient for high density cities, so probably the balance point would be less about fulfilling traffic demand and more about reducing the demand by demolishing most of the city.

Rust doesn’t have the kind of high performance garbage collection you’d want for this, so starting with unsafe makes perfect sense to me. Hopefully they keep the unsafe layer small to minimise mistakes, but it seems reasonable to me.

Here’s some ideas: 1. A data side channel 2. Use it to send originator for each message, have unique note on other end per sender so they don’t need to check visually, but also show on their display so corrupted or suspicious sender can be verified, in desperate circumstances (rather than the current case of “that cannot be done at all”). 3. Digital audio, allowing actual high quality audio, which we know does improve comprehension, which should not be optional in this context. 4. Take some lessons from modern coms systems on how to handle overlapping coms, plus the extra bandwidth from digital, so overlapping coms is handled gracefully (I realise the realtime nature prevents being too clever, but perhaps blocking all but the first to speak and playing a tone if you’re being blocked), perhaps with some sensible overrides like atc and anyone declaring an emergency getting priority. Currently overlap obliterates both messages and it’s possible for senders to not even know their message was lost. This has contributed to accidents, whilst basic direct radio transmissions cannot avoid this, smart algorithms with some networking could definitely reduce the failure cases to very rare and extreme scenarios 5. Let atc interact with flight planners on aircraft, show the aircraft’s actual locally programmed flight plan to atc, with clear icons if it differs from the filed plan atc has, and perhaps as an emergency only measure, allow atc to submit a flight plan to the aircraft (not replacing the active plan of course, just as a suggestion/support for struggling pilots, “since you have not understood my instructions 3 times, please review the submitted plan on your flight computer, note how it differs from what you programmed”) 6. Aircraft usually know where they are, and which atc they’re meant to be communicating with, have the data channels talk even when the audio channel is not set correctly. If incompetent pilots forget to switch channel, you can force an alarm instead of launching a fighter jet, or just have a button for “connect to correct atc” and a red light when you’re not on the correct one.

That’s just the ideas I’ve come up with just now. 4. Is probably quite hard to get right, and 5 could add load, so should be done carefully. But hard to believe the current system is technically optimal, or even vaguely close to optimal.

Admittedly, I know the real reason is that having 1 working system for everyone is better than a theoretically great system that is barely implemented and a complicated mess of handoffs between the 2. But with care they can absolutely improve things, but feels like things are moving a few decades slower than they should be.

> whether by phishing or exploiting the fact the passwords are weak or have been reused

1. Phishing is harder when you only ever enter your password into 1 place, and that one place is designed to be secure and consistent.

2. Much easier to have exactly 1 strong password than unique strong passwords for every website.

Is it better than a vault full of random passwords? Probably not, beyond pressuring the user into using the more secure method

Being forced to maintain compatibility for all previously written apis (and quite a large array of private details or undocumented features that applications ended up depending on) means windows is quite restricted in how it can develop.

As a random example, any developers who have written significant cross platform software will be able to attest that the file system on windows is painfully slow compared to other platforms (MS actually had to add a virtual file system to git at one point after they transitioned to it because they have a massive repo that would struggle on any OS, but choked especially badly on Windows). The main cause (at least according to one windows dev blog post I remember reading) is that windows added apis to make it easy to react to filesystem changes. That’s an obviously useful feature, but in retrospect was a major error, so much depends on the filesystem that giving anything the ability to delay fs interaction really hurts everything. But now lots of software is built on that feature, so they’re stuck with it.

On the other hand, I believe the Linux kernel has very strict compatibility requirements, they just don’t extend to the rest of the OS, so it’s not like there’s a strict rule on how it’s all handled.

Linux has the obvious advantage that almost all the software will have source code available, meaning the cost of recompiling most of your apps for each update with adjusted apis is much smaller.

And for old software that you need, there’s always VMs.

Same problem as ai safety, but the actual problem is now the corporate greed of humans behind the ai rather than an actual agi trying to manipulate you.

Caching and lower level calls are generic solutions that work everywhere, but are also generally the last and worst way to optimise (thus why they need such careful analysis since they so often have the opposite effect).

Better is to optimise the algorithms, where actual profiling is a lesser factor. Not a zero factor of course, as a rule of thumb it’s probably still wise to test your improvements, but if you manage to delete an n^2 loop then you really don’t need a profiler to tell you that you’ve made things better.

Nowadays the price arguments are… complex. But for the first time people actually care enough about the environment that nuclear is no longer competing poorly with coal (except for in Germany).

The exact maths on comparing pricing is complicated, given that energy storage costs vary so much depending on the inputs (try looking up storage costs for a 100% solar/wind grid during a once in a decade lull, it’d make nuclear look great, but obviously for a slightly mixed grid and more typical conditions, storage might be reasonably priced vs nuclear).

Anyway, I’m mildly disinterested in nuclear now that it’s only a side show to renewables, but I think it’s far from being a slam dunk either way. If some country or politian is more interested in nuclear, fair play to them, I say go for it. We’re not in a comfortable position right now so any movement away from fossils is a win regardless of where we end up (within reason of course)

No doubt the debate will only be resolved once and for all once fusion turns up and actually makes fission genuinely irrelevant (even then, fission might be cheaper for quite a while).

Rather the opposite for their customers.

I’m sure there’s a few cases where this would excessively hurt a company’s prospects (perhaps where a company has an innovative software product with a thin hardware component), but in the majority of cases losing access to the software of a hardware product as an asset is a relatively small loss, and the benefit to consumers is pretty huge. I’d support the trade off.