Live data from Hacker News

WebAssembly: Mozilla Won

robert.ocallahan.org

191–200 of 375 posts

Re: WebAssembly: Mozilla Won

#191

Earlier quoted context omitted.

I use FF, although Mozilla focuses on thousand of other things instead of making FF a great browser. As a developer I'm annoyed every time I enter "com.scala.List" in the address bar and FF does not use google to search but thinks this is an url. No, "List" is not a TLD and no that website does not exist.

As a developer I'm annoyed every time I enter "defined.in.hosts.file" in the address bar and Chrome does not believe this is a url but performs a search instead. Yes, I can define anything as a valid domain in hosts and yes that website exists on my computer.

That's weird. Any time I search for anything in chrome that doesn't contain a space, it asks me "Did you mean to go to http://x ?"

Re: WebAssembly: Mozilla Won

#192
post #78

Earlier quoted context omitted.

Even if thousands of developers from HN switch, that would hardly move the needle. Ordinary users just won't care about any of this. Servo, which I think is the most important software project in the world, is where it will start to change. That's when those of us who may not be directly contributing code into Servo need to come out and do our thing. I still fondly remember the NYT ad and the crop circle. We should d…

Given the original posters perspective, Servo is certainly te least concern to change the tides. For an end user it makes absolutely no difference if Mozilla reloaded will be written in C++, OCaml, Rust, wathever. Features, performance, security and speed of evolvement do count.

Servo's WebRender sub-project has amazing performance (GPU accelerated compositing and rendering), and is scheduled to be merged in Firefox as fast as possible.

Stylo (Servo's style subsystem) has already landed in Firefox behind a preference flag (not everything is wired at this point), and it also improves perf.

So, yes Servo is of paramount importance for Mozilla's future, because it does make a difference to end users.

Another advantage of Rust is that it allows devs to avoid a whole range of bugs making it easier for them to iterate and ship updates without introducing new tricky bugs (race conditions can be hard to debug).

While dynamic languages may be nice when you want to explore a problem space, the stronger/most static type system is a benefit for upgrading large, mature code bases...

Re: WebAssembly: Mozilla Won

#193
post #162

Earlier quoted context omitted.

> Even if thousands of developers from HN switch, that would hardly move the needle. Ordinary users just won't care about any of this. Thousands of developers from HN make websites . If they switch to Firefox, at the very least, the websites they make will support Firefox. This won't necessarily make Mozilla commercially viable, but if people are really that concerned about it, they can donate to the Mozilla Foundati…

that's purely a business decision.

It is a business decision, and the right decision is not to allow for monoculture to develop.

Re: WebAssembly: Mozilla Won

#194

Earlier quoted context omitted.

Some of these bugs could've been prevented with Rust: https://www.mozilla.org/en-US/security/advisories/mfsa2017-0...

Do you have any evidence that's why users are switching away? My general belief is that general-audience users don't care at all about bugs like those. Which is why we have so very many of them, and have for decades.

I don't, but a marketing campaign saying "using modern safe techniques" might get a little traction.

Re: WebAssembly: Mozilla Won

#195
post #136

Earlier quoted context omitted.

I don't have a good answer to your question, but for me it was actually performance. And this is particularly baffling, since Firefox seems to do extremely well in all benchmarks, often beating out Chrome. But, as a quick test, I closed Chrome, and it was up again instantly (say 500ms). I did the same with Firefox (after a generous warmup / caching session), and got 4 to 6 seconds each time. Clicking links and page l…

> Am I the only one that feels this way? Nope. I really want to like Firefox but its performance is just so much worse across the board than Chrome. Another example is video playback: Firefox, when viewing video, heats up my laptop to the point where the fans kick in at full blast. Chrome stays nice and cool on the same material. The difference in battery life is noticeable too. Sorry Firefox, you need to do better.

If it's making that much of a difference in heat, it's probably using a software renderer instead of passing the decoding to the GPU. Check (Menu)->Help->Troubleshooting Information and see if it says "Supports Hardware H264 Decoding: No;". If you can't fix it, I recommend using an extension that adds video URLs to your VLC playlist. VLC supports playing YouTube URLs natively.

Re: WebAssembly: Mozilla Won

#196

Earlier quoted context omitted.

Firefox's performance on Android is horrible though. I tried switching to it a few times but always have to switch back because of performance issue.

Agreed. It's the browser I'm using right now, but it's got some big problems. It's draining my battery and it interferes with chromecast.

I've been using Brave[1] on my Android phone for the past two months. It's been brilliant. A much better experience than Firefox, which was a bit slow and some pages loaded as a white screen.

I'd love to use Brave on my desktop too, but their lack of plugin/extension/add on support cripples it a little. There's a couple I just can't live without. Using Iridium[2] on the desktop instead.

[1] https://www.brave.com/

[2] https://iridiumbrowser.de/

Re: WebAssembly: Mozilla Won

#197
post #39

Earlier quoted context omitted.

This is not about unsafe WASM which should be rejected by verifier. This is about the raw machine output that the compiler generates from WASM. As with JIT for JS currently nothing verifies WASM compiler output. So a bug in the compiler may result in a WASM that passes the verifier to be translated into unsafe machine code.

Same thing applies to NaCl verifier. Bugs in verifier can cause problems. Verification or generation bugs are bug, not security weaknesses in the architecture. (I should not need to mention this but compiling is form of verification).

"Same thing applies to NaCl verifier. Bugs in verifier can cause problems. "

Not like with the other, though. You can statically verify NaCl stuff because it was designed for that to be easy. If WebAssembly doesn't do that, then it's a step down from NaCl at least on this risk. That it matters should be obvious given all the research by the kind of CompSci people that invented NaCl on eliminating that risk from the TCB. It's part of a larger concept where you make the things generating the risky code untrusted with the trusted checkers so simple they can be mathematically verified. Here's an example from a top group on NaCl:

http://www.cse.psu.edu/~gxt29/paper/rocksalt.pdf

I'm not worried about this too much as it will probably be some brilliant student's personal project in near future if it's not being researched already. A quick Google shows the Github has the full, C semantics with compiler (KCC) and a Javascript semantics at least has a prototype from 2015 of WebAssembly.

https://github.com/kframework/wasm-semantics

Re: WebAssembly: Mozilla Won

#198
post #81

Earlier quoted context omitted.

I doubt that would help. As the lead dev of VLC in a recent interview said, they’ve been offered huge amounts of money to include Google Chrome in their installer, and saying no was the hardest decision he’s ever made. As long as Google has fraudulent ads for Chrome "your browser is outdated, update now to Google Chrome" on their websites, as long as Google intentionally makes the experience worse for Firefox (see th…

Agreed with everything but your first sentence. MS was a much bigger impenetrable monopoly and the Web was won back. It can be done again. Having a great product and grassroots evangelism certainly help. (Not that I think Chrome is THE ENEMY. It's constantly evolving, multiplatform and open source. IE was none of that. But I agree Google's practices you described are despicable. Huge kudos to VLC for doing the right…

> MS was a much bigger impenetrable monopoly and the Web was won back. It can be done again.

The Web won because a) its introduction was a one-time technological change whose social impact was on the order of the printing press, and b) Microsoft had gotten fat and lazy on their monopoly revenues from Windows and Office.

We can't get cocky here. It is perfectly plausible that HTML will still render 500 years from now. And I'm dead certain that it will still dominate 20 years from now.

Growing up in a major technical revolution, it's easy for us to assume that the future will have a lot of technical revolutions that will keep knocking monopolists, rentiers, and authoritarians off their perches. And if that happens, great. But we should really be planning for the opposite case.

Re: WebAssembly: Mozilla Won

#199

Earlier quoted context omitted.

Some of these bugs could've been prevented with Rust: https://www.mozilla.org/en-US/security/advisories/mfsa2017-0...

Do you have any evidence that's why users are switching away? My general belief is that general-audience users don't care at all about bugs like those. Which is why we have so very many of them, and have for decades.

Rust's fearless concurrency[0] allows devs to write and refactor performant parallel code without the risk of introducing bugs, enabling them to ship upgrades faster.

It's the same benefit you get from strong, static types in a large project vs one with dynamic/weak types, but for another category of bugs. In large projects, it makes a difference.

---

0. Hopefully you'll forget the meme ;-)

Re: WebAssembly: Mozilla Won

#200
post #82

Earlier quoted context omitted.

"...the verifier for NaCl is likely to be an order magnitude smaller than a component in WebAssembly implementation..." Why is this so?

NaCL verifier is just a loop that essentially matches the instructions against a white list and checks their format and offsets. WebAssembly needs parser/linker/optimizer/assembler. Granted that the format is optimized for fast translation, but just the amount of code to support data structures in the implementation like maps, lists etc. must be big.

As in my other comment, something like that can be mathematically verified for correctness as well. That requires simplicity if one doesn't want to throw person-years of work at it w/ possibility of finding out it was impossible. My comment links to a formally-verified checker for NaCl as well.

https://news.ycombinator.com/item?id=14460649

Post reply on HN