Mozilla Servo alpha will be released in June
groups.google.com
groups.google.com
Web compatibility is a long road, and it's crucial for us to be able to know what missing functionality is most important and the places where we need to focus on performance the most. The purpose of the package is to help us find and prioritize bugs and missing features. We want to know which sites are the most broken (and, even more importantly, which missing features are breaking those sites). From the Web developer side, we also want early feedback on use cases that may be slow today, so that the browser engine can eventually become a great experience for everyone.
(Of course, this will change over time, just that I don't expect it to be 100% secure by June)
I already see lots of broken pages because of NoScript, I often use bookmarklets to strip the page of excessive (mis)use of design... so as long as you can show me the text I will be fine, thank you. ;) Not the typical user though, I know.
On the other hand I am thrilled about security and privacy possibilities this brings to the table! So I can't wait to try it out. Keep up the good work!
export OPENSSL_INCLUDE_DIR=$(brew --prefix openssl)/include
export DEP_OPENSSL_INCLUDE=$(brew --prefix openssl)/include
./mach build
Have you ever tried Google+? In my experience this is one of the most demanding pages out there and it is almost unusable in Firefox for me. The only reasonable way for me to use it is to switch to Chrome. (Linux, cheap Intel Celeron with 2.6 GHz)
Also, just tried loading the site on a much faster internet connection and everything worked, although text entry was slightly laggy on a new note. Still couldn't figure out how to get a count of my notes though.
There has been talk in PhantomJS on making multiple engines available. It's the 11th most commented issue[1], out of 1k+ issues.
Sometimes a broadly used browser-engine is important, but other things servo could be useful.
One issue with PhantomJS (on webkit) is that it crashes quite frequently and use a lot of memory[2], areas where Servo may do better.
[1] https://github.com/ariya/phantomjs/issues/10209
[2] https://github.com/ariya/phantomjs/issues?utf8=%E2%9C%93&q=i...
Well, we obviously all gonna use it that way though :-)
Sorry. The metaphor kinda broke down there. Point is, congratulations. Rust+Servo is one of the most absurdly ambitious projects I've seen in the last twenty years, to make a new browser engine and a new systems-level language. The level of success achieved even to this point is astonishing. I know the road is still long, but I wish you the best in finishing this journey!
If it's a known bug we'll just close it. If you want, see if you can find dupes on the issue tracker before filing, but don't spend too much time doing that.
I was wondering, is it still true (or ever was true)?
Additionally, the rust / servo community is very good, so you can usually get help pretty quickly on IRC.
[1]: https://github.com/servo/servo/issues?q=is%3Aopen+is%3Aissue...
See https://starters.servo.org/
This is still true. We're pretty good at creating easy issues, though there's also a steady flow of newcomers so often they get snapped up quickly. A lot of the low hanging fruit is gone, but with careful planning it's easy to create more.
Servo project aims to achieve better parallelism,
security, modularity, and performance.
Despite the way some news articles might write about it, Mozilla does not intend this to be a new browser for regular people - It's an extension of their new language, and R&D.
Over time, Firefox may incorporate components written in Rust, potentially including parts from Servo, but AFAIK there is no timeline for that.
I'd suggest there's another set of aims that comes out of the work to make Servo easier to embed than Gecko, but the time isn't right to make the most of that yet.
I disagree. While I'm not sure what the internal planning is, we are doing a bunch of things to move towards having a shippable Servo browser. If Servo was more of an experiment with no possibility of shipping there would be a whole host of features that we wouldn't even bother implementing it.
Servo's existence is also not to serve as a use case for Rust. If anything, it's the other way around, Mozilla was interested in Rust development because of Servo. However, over time Rust has gained a life of its own which is pretty awesome. (Yes, Servo does serve as a pretty good canary for Rust, but it's not the raison d'etre)
As far as Servo's future is concerned, there are a bunch of non-mutually-exclusive steps that can be taken going forward:
- Start moving components into Gecko (already being done) and write new ones (already being done): https://wiki.mozilla.org/Oxidation . Gecko can use Servo's URL parser, and wrote its own MP4 metadata parser. There's active work going on replacing Gecko's style/CSS system, and discussions about webrender. I've also seen some interest in dropping Rust into Spidermonkey.
- Expose a webview-like library (not being done yet, but there's interest)
- Release servo as its own browser, perhaps using browser.html (this is being coordinated at browser.html)
- Replace Gecko on Firefox for Android (this is not too hard, since the browser UI is simpler. Not being done yet)
- Replace Gecko in Firefox for Desktop (this is pretty hard -- there's no clear delineation between "Gecko" and "Firefox" and the UI uses things like XUL which I'd rather keep out of Servo). This is not being done yet.
They are but they're Servo's goals "for reals".
Parallelism: All current browsers are written to do layout in a single thread and the specs were written assuming this. When Servo started, whether you could write a parallel layout algorithm for the web was an open question. Servo has a multithreaded layout system that's faster than Firefox per-thread.
Security: The Rust programming language is memory safe. This prevents a large class of security vulnerabilities from happening. The number I saw was ~50% of the critical security vulnerabilities reported in Firefox in 2014 wouldn't be possible in Rust. It's also architected from the ground up to be multi-process sandboxed. I think there are other layers of defense but those are the two I know about.
Modularity: The pieces of Servo are in seperate repositories and the repos (crates) are actually used by the Rust community. Similarly, Servo pulls in crates from the broader community. This combined with the desire to port bits and pieces to Gecko makes the browser a lot more modular than you might expect. It's also designed for embedding and (I think) matches the CEF api so it should be usable wherever webkit/blink are but I haven't been keeping up with things there.
Performance: Parallel layout with a GPU-based scene graph [1] should result in a browser that's several times faster than anything currently available. The Servo team has been hesitant to really push benchmarks given the incomplete support but everything published is really promising.
If something like this is implemented, providing frequently used resources via a plugin, privacy aware CDN or even a custom CDN similar to https://addons.mozilla.org/en-US/firefox/addon/decentraleyes... would be possible.
We occasionally have discussions on whether or not to switch to Bugzilla. Github has some limitations when it comes to organizing things; however it's more newbie-friendly so there's a tradeoff.