> Putting a bytecode interpreter into your browser is exactly what malware sites want you to do
There is already an execution engine in your browser --- JS. WebAssembly applications can do exactly the same set of things that JS can do, so there's no new problem.
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
As ActiveX showed, code signing is useless in practice unless you require all code to be signed by some trusted third party. But the whole point of the Web is to avoid having a single gatekeeper.
On the other hand, running untrusted code in a sandbox is a model that has worked for JS, and it will work for WebAssembly too.
Your argument, such as it is, rests on the assumption that the child in the womb does not have its own right to bodily self-determination. And it's exactly that assumption that pro-lifers disagree with.
Though it certainly is simpler to just assume that those you disagree with are innately evil.
> Now here's the thing, the people working at the organisation he was heading thought that was unacceptable behaviour. It's entirely their right, and in fact their duty[*] in some ways to say they won't work at an organisation headed by that guy. The organisation now has a choice: keep the head or keep many of its workers.
FWIW this is factually incorrect. Many people at Mozilla Corp (which Brendan was CEO of) didn't like his position on prop 8, but AFAIK none of them publicly called for his ouster. A handful of staff of the Mozilla Foundation (which Brendan was not part of) did and were in the news; they're probably who you're thinking of.
Nonsense. Use-after-free and double-free bugs are common sources of exploitable security issues, and "a decent string library and buffer library" doesn't help at all with those.
> If you're so goddam Christian, how about you fund Meals On Wheels for all those veterans you're so enamored of chest-thumping about?
Many Meals on Wheels projects are supported by Christian groups, e.g.: https://en.wikipedia.org/wiki/...: > Meals on Wheels [Calgary] was formed in response to a plea from the Hospital Chaplaincy Committee of the Calgary Presbytery of the United Church. http://www.catholiccharities.c... I personally volunteered for Meals on Wheels work as part of a Christian group.
> How about you fund some inner-city schools instead of starving their funding so you can promote corporate/religious/magnet schools in wealthy neighborhoods?
Christian groups tend to fund their own schools, but there are many that serve poor inner-city areas.
> How about walking some the walk you're so fond of talking the talk about?
Christians and Christian organizations pour enormous resources into charity work. Many of the biggest charities in the USA are Christian.
The blanket assumption that Christians or conservatives (as a whole) do not "walk the walk" is unsustainable.
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.
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.
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 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.
String and vector libraries can't protect you from use-after-free bugs. To prevent those, before Rust, you needed some kind of GC, which imposes performance tradeoffs (some combination of increased memory usage, throughput overhead, and pauses). (Swift's ARC is really a form of reference-counting-based GC.) Rust offers a new approach where you can have manual memory management but the compiler can verify you don't have use-after-free bugs.
For example, in Rust you can give away a reference to a field of an object *safely*: struct X { foo: Y } impl X {
fn foo(&self) -> &Y { &self.foo } } No way to do that safely in C++. Sure, you can give away a pointer or a reference to a field, but the compiler can't ensure you haven't introduced a use-after-free bug. Rust can.
Slashdot Mirror
> Putting a bytecode interpreter into your browser is exactly what malware sites want you to do
There is already an execution engine in your browser --- JS. WebAssembly applications can do exactly the same set of things that JS can do, so there's no new problem.
Furthermore, PNaCl was pretty much the same from this point of view, or actually worse because it added quite a lot more attack surface than WebAssembly does (both in Pepper and all the LLVM code).
As ActiveX showed, code signing is useless in practice unless you require all code to be signed by some trusted third party. But the whole point of the Web is to avoid having a single gatekeeper.
On the other hand, running untrusted code in a sandbox is a model that has worked for JS, and it will work for WebAssembly too.
Your argument, such as it is, rests on the assumption that the child in the womb does not have its own right to bodily self-determination. And it's exactly that assumption that pro-lifers disagree with.
Though it certainly is simpler to just assume that those you disagree with are innately evil.
The point is that none of the people he was actually working with said they wouldn't work with him.
> Now here's the thing, the people working at the organisation he was heading thought that was unacceptable behaviour. It's entirely their right, and in fact their duty[*] in some ways to say they won't work at an organisation headed by that guy. The organisation now has a choice: keep the head or keep many of its workers.
FWIW this is factually incorrect. Many people at Mozilla Corp (which Brendan was CEO of) didn't like his position on prop 8, but AFAIK none of them publicly called for his ouster. A handful of staff of the Mozilla Foundation (which Brendan was not part of) did and were in the news; they're probably who you're thinking of.
Using some wrapper library to force dynamic checks on all pointer accesses would mean giving up all the advantages of using C in the first place.
Nonsense. Use-after-free and double-free bugs are common sources of exploitable security issues, and "a decent string library and buffer library" doesn't help at all with those.
> If you're so goddam Christian, how about you fund Meals On Wheels for all those veterans you're so enamored of chest-thumping about?
Many Meals on Wheels projects are supported by Christian groups, e.g.:
https://en.wikipedia.org/wiki/...:
> Meals on Wheels [Calgary] was formed in response to a plea from the Hospital Chaplaincy Committee of the Calgary Presbytery of the United Church.
http://www.catholiccharities.c...
I personally volunteered for Meals on Wheels work as part of a Christian group.
> How about you fund some inner-city schools instead of starving their funding so you can promote corporate/religious/magnet schools in wealthy neighborhoods?
Christian groups tend to fund their own schools, but there are many that serve poor inner-city areas.
> How about walking some the walk you're so fond of talking the talk about?
Christians and Christian organizations pour enormous resources into charity work. Many of the biggest charities in the USA are Christian.
The blanket assumption that Christians or conservatives (as a whole) do not "walk the walk" is unsustainable.
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?
String and vector libraries can't protect you from use-after-free bugs. To prevent those, before Rust, you needed some kind of GC, which imposes performance tradeoffs (some combination of increased memory usage, throughput overhead, and pauses). (Swift's ARC is really a form of reference-counting-based GC.) Rust offers a new approach where you can have manual memory management but the compiler can verify you don't have use-after-free bugs.
Rust can do many things modern C++ can't do.
For example, in Rust you can give away a reference to a field of an object *safely*:
struct X { foo: Y }
impl X {
fn foo(&self) -> &Y { &self.foo }
}
No way to do that safely in C++. Sure, you can give away a pointer or a reference to a field, but the compiler can't ensure you haven't introduced a use-after-free bug. Rust can.