
Servo Nightly Builds Available - dolftax
https://blog.servo.org/2016/06/30/servo-nightlies/
======
pilif
It's amazing to see actual effort taking place to build a new browser engine
from scratch.

I would say that since the late 90ies, there hasn't been a single new engine
being made. Everything we have now is a development based on KHTML, Gecko,
Presto or Trident.

By now, HTML and the standards surrounding it have become so big that starting
from a blank slate nowadays is next to impossible. The existing engines have
it much easier as they are allowed to grow with the spec, but a new engine has
to do everything from scratch.

This makes it even more impressive to see how far Servo is already (yes. I
know - there's probably some overlap with some existing Mozilla code, but
still).

Huge congrats to everyone involved. We need unafraid visionaries like you
people to actually move the web forward.

~~~
_pmf_
Edge is a new engine, too.

~~~
rat87
doesn't seem like it

[https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML](https://en.wikipedia.org/wiki/Microsoft_Edge#EdgeHTML)

> EdgeHTML is a proprietary layout engine developed for Edge. It is a fork of
> Trident that has removed all legacy code of older versions of Internet
> Explorer and rewritten the majority of its source code with web standards
> and interoperability with other modern browsers in mind.

~~~
ybx
Sounds like it's based on Trident to me

~~~
coldtea
Sounds like it's so rewritten compared to Trident, it's not even alike
anymore.

~~~
viscanti
The end result might look fairly different, but I'm not sure that 'forked-and-
refactored' is considered 'new' by very many people.

~~~
nickpsecurity
"rewritten the majority of its source code _with web standards and
interoperability with other modern browsers_ in mind"

I think coldtea is focusing on highlighted part. A rewrite like that might
change so many behavioral aspects, esp user- or developer-visible, that it can
be considered a new engine rather than mere clean-up of behaviorally-identical
old one. I certainly reuses some code and techniques but differences might be
major.

~~~
kbenson
At the same time, depending on how the rewrite was carried out, it may be
nothing like a completely new project. Rewriting function by function is
different than rewriting component by component, which is also different than
rewriting from scratch.

Rewriting function by function will give you largely the same program using
largely the same algorithms, but possibly with more or less bugs, or cleaned
up code.

Rewriting component by component will allow new ways those components are
implemented, but the interface between components will likely be the same.

Rewriting from scratch could yield anything (servo could be classified as a
way to rewrite gecko from scratch, I believe).

All of these could be said to have had the majority of their source code
rewritten, but I would only really consider the last one to be "new" without
knowing further details. Of course, the devil is in the details...

~~~
nickpsecurity
It's why I'm focusing on behavioral aspect: what does the software _do_? A
browser fork that behaves very differently from prior one to point you have to
change existing code to get same effect is essentially a new app at behavioral
level. However, it might have same name and lots of same code inside. At that
level, it's old code in an old app. We largely define our components by their
interfaces and behavior. So that's what I'm focusing on.

~~~
kbenson
Sure, but if it behaves significantly differently, then I think that precludes
it from being a function by function rewrite. At the same time, a component by
component rewrite _can_ be a complete rewrite (but it depends a bit more on
the details, I think). If the mainly user visible portions are rewritten, but
much of the utility code and other components are not, it may _appear_
behaviorally different, but but be largely the same code base. It's much
harder to know, looking in from the outside.

For a simplistic example, say someone provides a "rewrite" of grep. Maybe the
options are all different looking and sounding, so it may appear to be
significantly different. But if the core of the matching algorithm and it's
capabilities are largely unchanged, _is_ it a that much of a rewrite? To the
outside user it may superficially appear so, but to someone comparing the
source from before and after, there may be an entirely different opinion, and
even that may change if you come from a context of focusing on a particular
aspect.

As applied to Trident/Edge, we may have a case where the person speaking was
involved in a project to rewrite one major component of the browser, and so is
speaking in that context. Maybe that component is responsible for about 60% of
the code and functionality, but it still relies on a quite a bit of largely
unchanged additional libraries. It's very subjective as to whether you think
that qualifies as a rewrite of the project, and depends quite a bit on what
was not rewritten, and what you think of that code.

~~~
nickpsecurity
Re rewrite differences

Let's look at the grep example agsin. If it did same thing, but new interface,
then it would be same thing because behavior is otherwise the same. Now, lets
say you changed what pattern-matching itself produced where you no longer got
the same results from same text. Matched totally different patterns unless you
changed the text you are inputting to get same results again. And the
interface was different. Is that still grep?

If he's talking one component, maybe not anything new underneath. He said the
engine (rendering) would be more standards compliant and compatible with other
browsers. That's basically what Opera and Mozilla did many years ago while IE
didnt. If you blocked out the name, nobody using the browser would think they
were using same app when they saw rendering hit those aspects totally
distorting the presentation. Or had to redo their websites to display
correctly. I remember reading many complaints from web developers about making
stuff work with several, different engines whose rendering argued.

So, _if_ Edge engine is different enough to cause that, then it seems like a
different engine at behavioral level given same input leads to different
output that fails acceptance. Nobody would think it was same app unless the UI
told them.

I mean, I still think sameness or newness is an open issue. Do we judge it be
function and component as you added? Or interface and behavioral spec as I was
looking at? One might also look at data formats. I think it will best to
technically just compare in various ways to be accurate. Feature-driven
development field probably has some insight into this. However, users will
look at them as different, at least in a version since, if they can't do what
they were used for or break compatibility. The two Python versions are
possibly a good example.

~~~
kbenson
> Let's look at the grep example agsin. If it did same thing, but new
> interface, then it would be same thing because behavior is otherwise the
> same.

That sort of depends on how you define "behavior". More specifically, if it
matches something equivalent but different to regular expressions (even if
it's just a character transliteration to regular expression syntax), then does
the behavior change? Is _that_ still grep? Maybe, if grep decides the the "new
grep2 have an easier to learn matching language". It's not like we haven't
seen that before.

> I mean, I still think sameness or newness is an open issue.

Sure! The vast majority of cases it probably is an open issue, because
different people have different criteria. I was just pointing out that the
wording from MS doesn't necessarily imply a rewrite as many people might
define it, because we have very little context to go on in the statement, and
different people have different ideas about what _is_ the browser. The
rendering engine? The UI? The JS VM? All of them combined?

I can totally see someone responsible for the rendering engine saying "we
rewrote most of the source code" and the JS VM guys scratching their heads
wondering what the hell they are talking about, because they definitely didn't
rewrite most _their_ code, and they think their component is a significant
portion of the browser...

------
pcwalton
Happy to answer questions (when I wake up; getting this ready has been a lot
of work, needless to say) :)

It goes without saying, but as this is the very first nightly (not by any
means a full-fledged release), expect severe bugs, crashes, and missing
functionality. Many of your favorite sites will be broken. Don't expect to use
this as your everyday browser. We'd love feedback on what issues folks hit the
most, so we can prioritize—especially if you're a Web developer!

~~~
pekk
> expect severe bugs, crashes, and missing functionality.

I really don't mean this in a snarky way: wasn't this kind of thing supposed
to be obviated by the switch to Rust? It often seems that every other post
about Rust on HN says that if it compiles, it works.

~~~
IanCal
No language can fix missing functionality, that seems pretty clear.

Your compiler doesn't know what you're trying to do, so you can't prevent all
bugs.

That leaves crashes, and ... well it may also depend on what you mean by a
crash. The UI becomes unresponsive? Might have absolutely nothing to do with
memory issues or even code written in rust. Maybe your rust code is fine but
you're trying to open and write to the same file from two places which you
don't realise because the users file system is case insensitive but you've
only tested on a case sensitive one, etc.

It's also multi-threaded and while languages can significantly help improve
the safety of multi-threaded code, I don't think anything can stop you from
creating a deadlock or putting your system into an inconsistent state.

And finally, they may not even particularly expect those things, but putting
out early nightly builds to a wider audience and expecting nothing to go wrong
would be cavalier. A typical warning on many early releases is "don't blame me
if this destroys all your files".

~~~
alex_duf
>Maybe your rust code is fine but you're trying to open and write to the same
file from two places which you don't realise because the users file system is
case insensitive but you've only tested on a case sensitive one, etc

That sounds too precise to be just an example :) We've all been there!

~~~
IanCal
Haha, yes, this kind of thing has bitten me a few times. I remember getting
SVN really confused where the server thought files were different but my
machine thought they were the same (or similar). I think I had to make a whole
new repo.

It's now on my mental list for "but it works on my machine", checking
filenames and their cases.

------
reissbaker
It's definitely slower to actually load pages — I'm guessing that there are
still a lot of network optimizations that more mature codebases have accrued
that Servo hasn't yet — but _holy cow_ are pages buttery smooth once they do
load (and even while they're loading, which is unusual). Comparing Chrome and
Servo in terms of UI jank felt pretty shocking, in Servo's favor. Kudos, it
looks like Rust and WebRender have paid off.

Looking forward to seeing this evolve.

~~~
Manishearth
Yeah; we've mostly ignored the network stack.

So there's some extra copying in the IPC, and no speculative parsing, which
can slow things down, among other factors.

Can be fixed, but priorities :)

~~~
WasimBhai
I will absolutely love to contribute toward the network stack. Can you provide
me any pointers?

~~~
riskable
Using pointers in rust is discouraged!

~~~
kibwen
Do you have a reference for that claim? :)

~~~
Manishearth
_boxes kibwen_

------
Benjamin_Dobell
Looking forward to using Servo one day, keep up the good work.

First thing I noticed almost immediately after launching is that everything
breaks when dragging the window across monitors (that have different
densities) - OS X. I dragged from my Macbook's display to an external monitor
with a lower DPI and everything went huge and most of the UI got cut off.
Dragging back to the Macbook display does not resolve the issue and instead
introduces some weird redraw flickering with garbage data.

EDIT: Reported -
[https://github.com/servo/servo/issues/12009](https://github.com/servo/servo/issues/12009)

~~~
choosername
you misunderstand if you think servo is scheduled for production and put peer
pressure on the devs, but sure, firefox is great already, can only get better.
Speaking of which, how are the memory requirements of servo, in relative
terms, yet?

~~~
Benjamin_Dobell
I don't know what you think you inferred, but please reread my comment
carefully. I meant exactly what I wrote and nothing beyond that.

------
cmrx64
Comparing this to early Mozilla/Firefox's history, the point where nightlies
become available is really huge. Congrats to the servo team!

------
eatonphil
Just opened up the MacOS build. It is pretty impressive! But the autocomplete
is just awful. Typing in "[http://localhost:3000"](http://localhost:3000") at
normal speed produced "[http:///localhost:300000"](http:///localhost:300000").
Especially while it's in such a primitive developer-oriented state it would be
much more useful to disable that silly autocomplete.

Edit: Additionally, it doesn't yet support native keybindings like Command
left-right or Alt left-right.

~~~
publicfig
I doubt that there's going to be much effort into improving the HTML based
browser that they're using as a shell to the engine outside of making sure you
can go to a specific URL. Things like hotkeys and autocomplete are nice, but
not really necessary for developing on Servo. I could be wrong on that though

~~~
metajack
The browser.html team works on the frontend, so they are very much interested
in improving this. You're right that Servo devs themselves often use an even
more stripped down test harness that you supply URLs to on the commandline,
but that may change now that browser.html has gotten quite nice :)

------
hitlin37
"Servo is a modern, high-performance browser engine being developed for
application and embedded use."

Is embedded devices one of the goals around Servo? Do Servo have any embedded
specific design goals? I'm interested to know which parts in Servo targets to
embedded use. I can see that page says Android builds are coming soon. i guess
that explains it.

~~~
cmrx64
Embedded in the sense that you embed a browser in another application, I
think? Maybe IVE (in-vehicle entertainment).

~~~
mintplant
> Embedded in the sense that you embed a browser in another application

Yes, this is it.

~~~
hitlin37
ah....the description is ambiguous then. Embed a browser in another
application isn't very clear either. Is Servo like framework where devs can
build apps on top (something on electron line).

Or is it really about embedding browser inside your application. That one can
do today with QT framework where you can embed a browser inside your
application. But QT itself moved from Qt WebKit to Qt WebEngine. So, 'embed a
browser' in your application sounds old to me.

~~~
ZenoArrow
> "Embed a browser in another application isn't very clear either. Is Servo
> like framework where devs can build apps on top (something on electron
> line)."

"Embed a browser in another application" is perfectly clear. Servo is designed
so that it can be linked with other applications, and displayed within windows
that the host application controls.

WebKit is also embeddable in this way, but other browser engines are not as
mature in this area. There was talk of Servo using the same API that WebKit
uses for embedding, probably to help developers transition from WebKit to
Servo:

[https://github.com/servo/servo/wiki/Version-0.1#embedding](https://github.com/servo/servo/wiki/Version-0.1#embedding)

"The proposed plan is to use WebKit's API as a template or copy it
completely."

------
lewisl9029
Congrats on the release! Servo itself has been getting most of the attention
in this thread, and rightfully so, but I just wanted to mention that I really
love the progress the team has been making on the browser.html side as well!

It's great to finally see a browser UI built from the ground up on top of
_standard_ web technologies _and_ with first-class support for vertical tabs
to boot!

------
legulere
It's already more nice than what I expected.

Some really minor bugs that occurred while using it a bit (OS X 10.11):

\- Scrolling when already at the end of the page sometimes makes a relatively
big instant step (noticed this for instance on the hackernews startpage)

\- The tabs aren't cropped in tab view:
[http://imgur.com/Q1Bxibo](http://imgur.com/Q1Bxibo)

\- Tabs don't keep at which point you have scrolled when switching tabs

\- After opening the address bar and clicking on the website again there's a
short flicker.

~~~
Manishearth
Could you file issues for all of these (preferably with secreenshots)?

Thanks!

~~~
legulere
Reported all of them

------
johannh
Congrats! Please note that Servo is a work in progress that is still lacking
some modern browser security features, so enjoy responsibly.

See also
[https://github.com/servo/servo/labels/A-security](https://github.com/servo/servo/labels/A-security)

------
mjs
The OS X binary isn't signed, and the download URL is HTTP. Is there a version
available on a more secure distribution channel anywhere?

~~~
Manishearth
We're switching the download link over to HTTPS.

Is there a reason the OSX binary needs to be signed? We don't do anything
special.

Edit: HTTPS up: [https://servo-
builds.s3.amazonaws.com/index.html](https://servo-
builds.s3.amazonaws.com/index.html)

(This comment written in Servo :P )

~~~
threeseed
The last few releases of OSX don't allow you to launch unsigned binaries
without specifically disabling the check.

In the latest Sierra beta I've heard you can't disable the check without an
involved workaround.

It's just OSX users being lazy ;)

~~~
Manishearth
Huh. I've only recently started using OSX, and I've had codesign issues when
using self-compiled debuggers, but not when using things like servo.

Can it be signed by any old cert or does it need to be part of the trust
chain?

~~~
LnxPrgr3
Debuggers are special--the OS won't let unsigned binaries control other
processes, no matter how they came to exist on your system.

Outside of that, Gatekeeper applies to executables fetched from the Web, can
be disabled (harder on Sierra), and is easy enough to bypass--and you only
have to do it once per executable. If signed, the certificate does need to be
trusted to count--otherwise, it'd just be a fancy checksum.

~~~
Manishearth
Alright. This sounds like something we should be eventually doing. Not sure if
we should prioritize it right now. GPG-signing the binaries for extra
verifiability is another thing we could do in the meantime, though it doesn't
fix the OSX issue.

------
pimeys
Is there an article somewhere comparing how Servo and Chromium threaded
compositing differ? I guess there is some work on Chromium side to render
pages using multiple threads, but I couldn't find more information and how it
compares to Servo's mechanism.

~~~
reissbaker
The compositing is very different: Servo does almost everything on the GPU in
"retained mode" as opposed to "immediate mode," which is much faster and
similar to how modern game engines work. There's a good talk here explaining
it here: [https://air.mozilla.org/bay-area-rust-meetup-
february-2016/](https://air.mozilla.org/bay-area-rust-meetup-february-2016/)

------
dz0ny
Freezes with github issues
[http://i.imgur.com/bcSOoxc.png](http://i.imgur.com/bcSOoxc.png)

ERROR:js::rust: Error at [https://assets-
cdn.github.com/assets/frameworks-6fe6a7604ec4...](https://assets-
cdn.github.com/assets/frameworks-6fe6a7604ec4c2601272849e1b99a3a9aa12c79b3e25be0360f8d114768e7578.js:6:6359):
history is not defined

------
chenglou
Is the scrolling behavior on OS X custom implemented, just like on Firefox?
Imo it hits the uncanny valley unfortunately, especially for edge bounce back.
Otherwise, excited to try this out more.

~~~
metajack
I think the browser.html team will be very interested in this feedback. I sat
with them as they poured over Cocoa disassembly and source trying to replicate
the behavior as best they could. We definitely have some things to improve.
Because we are using our own rendering system to draw on the GPU, we can't use
Apple's implementation of this stuff which requires buying into Core
Graphics/Core Animation completely I believe.

Note that I don't think Firefox has overscroll at all, except maybe on mobile.

~~~
panic
It's worth looking at WebKit's implementation:
[https://github.com/WebKit/webkit/blob/master/Source/WebCore/...](https://github.com/WebKit/webkit/blob/master/Source/WebCore/platform/cocoa/ScrollController.mm)

------
pslam
I know it's not the point, but having this publicly available in such a usable
form - even with this bare minimum UI - is a huge milestone. A big barrier to
adoption I hear from many potential users is, "Are there any big users of Rust
yet? No? Why would we?" This answers that.

Half jokingly, all you need now is an emscripten target, so it can be run
inside a browser, and anyone can try it out without needing to install an app
:)

~~~
moosingin3space
> all you need now is an emscripten target

The thing I love about the programming community is that even though that's
clearly meant as a joke, someone'll make it happen, just to see if they can do
it :)

------
Svip
When I run it, I first see a webpage loading then it suddenly disappears and
the whole page becomes white. There is no UI, but when I hover over the white
nothing, it appears as if the webpage is still underneath as the cursor
behaves as it would if there were text and hyperlinks.

I am on Ubuntu 14.04, by the way.

Screenshot: [http://i.imgur.com/ixQj4sI.png](http://i.imgur.com/ixQj4sI.png)

------
daenney
It seems Servo doesn't respect my keyboard layout. I use Colemak on macOS but
when I go to type in google.com in the address bar I get t;;tuk.c;m.

~~~
pcwalton
This is pull request #11950.
[https://github.com/servo/servo/pull/11950](https://github.com/servo/servo/pull/11950)

~~~
daenney
Ah, awesome. Thanks for finding it!

------
blablabla123
How do you actually open the developer console? ;)

~~~
metajack
If you start servo with the devtools port on, you can use the Firefox tools to
get a remote console. This may or may not be working well at the moment. The
JS console.log stuff will get output to stdout or stderr when you run as well.

There are discussions underway about how to bring in other tools, and how to
get stuff like this into Servo or browser.html itself.

~~~
blablabla123
Thanks! I guess I can use this to get my project working on Servo... ;)

------
brson
Congratulations, servo team. This is an exciting milestone. Getting all these
eyes on servo is going to accelerate development even more.

------
melicerte
Now browsing HN with servo

------
sdeframond
Is some HiDPI mode already available on Linux?

~~~
metajack
I don't think we do autodetection yet aside from what Glutin already does
(which is very basic). But you can put Servo into a HiDPI mode manually with
the --device-pixel-ratio=2.0 argument, and you can supply whatever ratio you
like.

We do detect Retina on Mac and have system DPI awareness on Windows, so once
we figure out what to do on Linux we can probably add it pretty easily.

------
lisivka
Does not work on Fedora 23 due to mismatched libraries: servo requires openssl
1.0.0, while Fedora 23 has 1.0.2h.

~~~
watty
I like how a few comments up you're saying how harmful Windows is and implying
how easy it is to run Linux and Servo and here you are complaining about
mismatched libraries.

~~~
lisivka
It's looks like you are misunderstood me. Linux is great for development. It's
free. It's made by developers and for developers. It has lot of development
tools integrated into OS. You can tweak, modify, and debug just anything,
including kernel. It well documented and has full sources. If you want to help
Servo developers, Linux is great choice. If you want to USE Servo, then you
need to wait until developers will release version for your platform, because
it is not ready for end users. It is sad that I need to explain that on
_Hacker_ News site.

------
a_imho
not working at all ./runservo (as per instructions)

thread 'main' panicked at 'Failed to create window.: OsError("GL context
creation failed")', ../src/libcore/result.rs:785 note: Run with
`RUST_BACKTRACE=1` for a backtrace.

./servo welcome to servo, than it changes to a white window

Debian 8

~~~
kaiha
Most likely this is due to your system only supporting OpenGL version < 3.0. I
had the same problem. Replacing '-w' by '-c' in the 'runservo' script might
fix your startup problem.

~~~
ThePinion
This worked for me on Ubuntu 15.10 x64

------
56245623456
I started it and it worked, nice to see this progress!

Two things though: 1\. when I opened the tab sitebar clicking on a tab closed
it. 2\. I cannot reproduce this, but servo hung when i closed the window, it
stayed open, but did not rerender on resize. Using gentoo with Xorg, running
dwm as window manager.

~~~
igozalishvili
1\. That is intentional UX decision. 2\. That is known bug, that hopefully
will be fixed soon.
[https://github.com/servo/servo/issues/11937](https://github.com/servo/servo/issues/11937)

------
themihai
Nice UI, and it runs pretty fast! Is it possible to enable WebAssembly?
(running the MacOS binary)

~~~
pcwalton
Not at the moment. But watch this bug :)
[https://github.com/servo/servo/issues/9232](https://github.com/servo/servo/issues/9232)

------
ksec
While there are still lot of work to be done on servo. I wonder if other
browser engine be able to benefits from the research mozilla has done. Like
Webkit / Blink.

Or will this require some major rewrite?

~~~
Manishearth
Depends on the architecture. But if the monolithic Firefox is trying to use
servo components, I bet WebKit and Blink can too.

------
anirudhan
Congratulations on the release.

Running ./servo gives me this error.

"./servo: error while loading shared libraries: libEGL.so.1: cannot open
shared object file: No such file or directory"

I guess it should be an easy fix. But if there are instructions to copy/paste
that would really help. If someone has an answer, it would be great if you can
please post it here.

Edit 1: I think the problem is because I am trying to run it on ubuntu 14.04
server. Also I am using xming and putty x11 forwarding. I installed libegl
using 'sudo apt-get install libegl1-mesa-dev'. Now I am getting a new error.

Xlib: extension "XFree86-VidModeExtension" missing on display
"localhost:12.0". thread 'main' panicked at 'Failed to create window.:
NoAvailablePixelFormat', ../src/libcore/result.rs:785 note: Run with
`RUST_BACKTRACE=1` for a backtrace.

So I ran with RUST_BACKTRACE=1 and this is the stack trace.

Xlib: extension "XFree86-VidModeExtension" missing on display
"localhost:12.0".

thread 'main' panicked at 'Failed to create window.: NoAvailablePixelFormat',
../src/libcore/result.rs:785 stack backtrace:

    
    
       1:     0x55868358b56f - std::sys::backtrace::tracing::imp::write::h6528da8103c51ab9
    
       2:     0x55868359319b - std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::hbe741a5cc3c49508
    
       3:     0x558683592dff - std::panicking::default_hook::he0146e6a74621cb4
    
       4:     0x558683471857 - util::panicking::initiate_panic_hook::_$u7b$$u7b$closure$u7d$$u7d$::_$u7b$$u7b$closure$u7d$$u7d$::hc61828c8a9f6df01
    
       5:     0x558683578dcc - std::panicking::rust_panic_with_hook::h983af77c1a2e581b
    
       6:     0x5586835933e1 - std::panicking::begin_panic::he426e15a3766089a
    
       7:     0x55868357a63a - std::panicking::begin_panic_fmt::hdddb415186c241e7
    
       8:     0x55868359337e - rust_begin_unwind
    
       9:     0x5586835c997f - core::panicking::panic_fmt::hf4e16cb7f0d41a25
    
      10:     0x558681766ff0 - core::result::unwrap_failed::hd132ba2b7d75f379
    
      11:     0x558681765df4 - glutin_app::window::Window::new::h750be0f1f60f008a
    
      12:     0x558681764df0 - glutin_app::create_window::hae774cdda1762e66
    
      13:     0x55868170df45 - servo::main::h6924e5658370f6b5
    
      14:     0x558683592778 - std::panicking::try::call::h852b0d5f2eec25e4
    
      15:     0x55868359d5db - __rust_try
    
      16:     0x55868359d57e - __rust_maybe_catch_panic
    
      17:     0x55868359221e - std::rt::lang_start::hfe4efe1fc39e4a30
    
      18:     0x7fcc0d82eec4 - __libc_start_main
    
      19:     0x55868170cf09 - <unknown>
    
      20:                0x0 - <unknown>
    
    

Edit 2: I am not sure if this discussion belongs here. Let me know if I should
move this somewhere else.

~~~
Sylos
I get the same error, except that the library missing for me is
"libssl.so.1.0.0".

That is on Fedora 23, and what's really strange to me, is that I compiled
Servo about a week ago myself and that build works.

~~~
mwambua
I get the same libssl.so.1.0.0 missing lib on F23 as well. I've tried creating
a symlinked file... but it still doesn't work.

------
salzig
I really hope the UI keeps being that simple. I like it a lot.

------
a012
It doesn't display web page properly:
[https://i.imgur.com/VwBJqf7.png](https://i.imgur.com/VwBJqf7.png)

~~~
Manishearth
Could you explain what's wrong in that image?

~~~
a012
Texts were streched in Servo (right) compared to Firefox (left)

~~~
Manishearth
Ah, I see. I suspect that's just servo picking a different font on your
machine. It works for me.

We have some issues with choosing fonts IIRC.

------
senthilnayagam
looks good,

faced 2 issues,including one crash, have submitted tickets, already somebody
responded to github issues that was quick.

------
taf2
I really the tab interface. Is there a chrome extension that does that to
chrome?

------
dz0ny
Can we get rpi build, since you are advertising as browser for embedded use?
:)

~~~
Manishearth
"Embedding", not embedded. Embedding means that the engine can be used within
other applications, the way WebKit is often used for webviews.

I beleive Servo does work on a Pi, but probably not well.

~~~
pcwalton
In particular we haven't finished the GLES2 port of WebRender yet.

