> the medicine was worse than the cure.

This is a Trumpesque troll right?

The lockdown was definitely not worse than the disease. The "just get on with life" approach, let's call it "Sweden", kills and sickens a lot of people (not just old people), displaces other sick people from hospitals, and tanks the economy anyway because people are afraid to go out. In contrast, here in NZ after a short shock we have virtually no restrictions and no-one is afraid so normal life resumes.

If and when we have another case, we can reasonably hope for test+trace to contain the outbreak without having to lock down again. We shall see!

Because there is no C or C++ library even today that guarantees all memory safety bugs are prevented.

Chrome will soon remove FTP too. https://www.ghacks.net/2019/08...

In that book there's a character who's been transported many times --- and is haunted by the ghosts of his former selves.

Asimov was well-known to be a sexually-harrassing creep (see e.g. https://www.gizmodo.com.au/201...). This even made its way into his writing; his dirty-old-man wish-fulfillment stories (e.g. Janov and Bliss in Foundation's Edge, Hari and Dors in Prelude To Foundation) were just embarrassing.

He was also a pretty bad writer IMHO. I enjoyed reading his novels for the plot and ideas, but his characters and language are tissue-thin. There are many much better works by sci-fi writers who can actually write well.

Mozilla has taken essentially the same position. https://blog.mozilla.org/blog/...

ETP massively improves performance for everyone. Also, improving privacy benefits people even if they don't care about it.

40% of US users use an ad blocker extension on desktop, so browser extensions on mobile aren't just for nerds.

Mozilla have done lots of good things Chrome hasn't done. Did you miss the announcement about Enhanced Tracking Protection being turned on by default, blocking tons of trackers? Or browser extensions supported on Android? Or all the devtools features Chrome doesn't have?

Quite hard, actually.

One problem is that there are legitimate needs for autoplaying audio and video, e.g. games, so naive autoplay blocking breaks a lot of sites. Browser autoplay blocking implements complicated heuristics to try to distinguish these legitimate needs from unwanted autoplay. (People suggest, "oh, just ask me every time" but of course that creates an alert-spam problem like the one in the original post here.)

Another problem is that if you block autoplaying video elements, some sites will go to ridiculous lengths to get autoplaying "video" in front of users. For example, sites have been known to implement their own video codecs in JS. Even if JS is disabled, sites have been known to render "slideshow" video using pure CSS to shuffle through a set of images. Those hacks are of course much worse for users, in bandwidth and power, than just letting the site autoplay a proper video. That is why browser autoplay blocking focuses on blocking videos that have audio.

The exact quote is "has no plans to turn on our DoH feature by default in the United Kingdom and will not do so without further engagement with public and private stakeholders".

That is not a "guarantee they'll leave it disabled by default". It just means they won't do it "yet".

The main reason for the proliferation of processes is actually security. It turns out that JS can leverage Spectre hardware issues to snoop on whatever's running in the same process. Thus browsers need to move to a separate process per Web site.

You can write a memory allocator in Rust.
https://github.com/redox-os/ra...
However Rust code in the Linux kernel can use the existing allocator, and there is no pressing need to rewrite that AFAIK.

Rust doesn't need a stable ABI to be useful in the kernel. The kernel itself doesn't have a stable internal ABI.

Unlike most programming languages, but like C, the Rust standard library is optional. You can write Rust programs that don't use it, and people do.
https://rust-embedded.github.i...
For example people are writing bootloaders in Rust.
https://github.com/rust-osdev/...

The people actually working on writing Rust code for the kernel are implement Rust interfaces to the existing kernel libraries.

> C isn't more of a challenge than Rust is.

Writing C code that is completely free of memory safety bugs and other exploitable vulnerabilities is a huge challenge. It's about as hard as always writing code that is perfectly bug-free. Basically no-one can do it at scale.

Writing C code that works most of the time and has lots of vulnerabilities is indeed quite easy, and for a long time that was considered good enough. That needs to change.