Because of user-agent sniffing by Netflix.
Because of user-agent sniffing by Netflix.
Firefox has been ready for a while. The problem was Netflix sniffing the Linux user-agent and going down the Silverlight path. Now Netflix has fixed that.
One of the many things that's hard about building a browser is taking the blame for stuff like this.
"HPC leadership" by itself is pointless. China owning big computers doesn't put the USA at risk. It's what they do with them that matters, and whatever *that* is, you likely won't neutralize it just by building even bigger computers in the USA.
These HPC people are also glossing over the issue that for most important problems, parallelizing over commodity CPUs connected by commodity networks (i.e. the cloud) is far more cost-effective than the "big iron" shared-memory HPC systems, and via Google, Amazon and Microsoft, the USA completely rules that space.
If the USA needs to build really big shared-memory HPC systems to solve some specific problem connected to China, by all means propose that. General scare-mongering about "HPC leadership" is just an invitation to waste taxpayers' money.
Mozilla measured, and 1.2% of all Firefox Linux users are using ALSA with Firefox.
It sounds a lot like the 90s, except in the 90s it was just Microsoft who was the ostensible gatekeeper.
I am worried about the dominance of the Gang of Five, but a Gang of Five is a far, far better situation than a Gang of One.
Since that article you cited, Mozilla dropped their big Google deal and switched to Yahoo instead. Regardless of the merits of that, "bought by Google" is just wrong.
It's true that you don't come to New Zealand to maximise earnings. People tend to come here for other reasons, mainly lifestyle.
The weather in Wellington is terrible. Auckland's a lot better.
I once met an American neurologist who moved to NZ. She was earning less than half of what she'd been earning in the USA, but was much happier because the healthcare system here is better organised.
A small number of people have high-paying jobs in NZ that pay commensurately with what they'd get overseas. They tend to work remotely on something very specialized where they're practically irreplaceable.
It is expensive because of imports, but taxes are actually not high. Top income tax rate is 33%, and there's a 12.5% sales tax on almost all goods. (There are no states, therefore no state taxes.) That's significantly lower than the USA especially if you live in a high-tax state like California.
Your last sentence is probably true. Income inequality especially in healthcare isn't nearly as high is in the USA.
Your second sentence doesn't make sense to me unless your distant cousin is just ridiculously frugal. Lots of middle-class NZers eat out very frequently.
That's not true at all. Firefox extends the Chrome extensions API in various places as needed. For example, see the "New APIs" here: https://blog.mozilla.org/addon...
Another example: Firefox has implemented a "sidebar" Webextensions API, Chrome has not. https://bugs.chromium.org/p/ch... https://bugzilla.mozilla.org/s...
You are confused about the meaning of "guarantee" here. With Rust, if you don't write the keyword "unsafe" then code that triggers data races will not compile. With C++ and Swift, it will.
Safe Swift requires thread-safe ref-counting of heap-allocated objects. That is unacceptable.
Swift can't guarantee data-race freedom. Rust does. So Rust has data-parallelism libraries like rayon that you can use that keep you out of trouble.
On the flip side, Swift requires thread-safe refcounting for all dynamic memory management, which is horrible for systems programming.
Swift lacks many of Rust's key features. In particular, it doesn't ensure data-race-freedom like Rust does. You're also stuck with using reference counting for all dynamic memory management, and atomic ops for your refcounts at that. Traversing a read-only dynamic structure? Enjoy atomic addref/release all the way along.
No-one, apart from maybe Dan Bernstein, is good enough to reliably write bug-free code. The hubris that says "I am!" is the core reason why we have such enormous security problems.
> How many lines of code is in the Rust compiler & library. How much of that must be flawed? That'll get passed on to every program that uses it.
No, that's not how it works.
A bug in the compiler only matters if it was triggered during the build that produced your binary *and* the build succeeds *and* the results pass your test suite. Unless your code is quite unlike anyone else's code, you will hit this a lot less than bugs in your own code.
A bug in Rust's standard library can affect a lot of programs, but much of Rust's standard library is written in safe Rust so gets the same safety guarantees as regular Rust code. And of course the standard library gets a lot more testing and inspection than your own Rust program.
The bigger picture is that formal verification technology is advancing so that in time, we'll be able to verify that a build worked correctly (i.e. the generated code preserves the safety properties of the Rust code), and we'll be able to write proofs for most of the unsafe parts of the Rust standard library that they also preserve safety properties.
Are you saying that instead we should make people smarter? Or that we should write less software?
When all else fails, read the instructions.