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.
WebAssembly: Mozilla Won
191–200 of 375 posts
Re: WebAssembly: Mozilla Won
#192Earlier 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.
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
#193Earlier 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.
Re: WebAssembly: Mozilla Won
#194Earlier 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.
Re: WebAssembly: Mozilla Won
#195Earlier 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.
Re: WebAssembly: Mozilla Won
#196Earlier 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'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.
Re: WebAssembly: Mozilla Won
#197Earlier 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).
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.
Re: WebAssembly: Mozilla Won
#198Earlier 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…
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
#199Earlier 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.
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
#200Earlier 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.