Live data from Hacker News

Servo Nightly Builds Available

blog.servo.org

201–210 of 246 posts

Re: Servo Nightly Builds Available

#201

Earlier quoted context omitted.

Why not to try Linux? It's free. It's made by developers and for developers. Try Fedora Linux.

> It's made by system developers and for people comfortable with debugging low level issues like kernel panics caused by faulty drivers. Fixed that for you :P PS. It is considered bad etiquette to ignore the issues of a Windows user and simply "recommend Linux" in a tech community like this, especially when a Windows build has already been promised. You don't know the reasons why someone is using Windows (ex. because…

I sorry to inform you, but Windows is considered harmful, so this is good etiquette now, also known as "word of mouth". You can download and run Linux in fraction of time you will need to argue that this is bad for a user.

Download Linux. Download Servo. Run Linux. Run Servo. Profit.

Re: Servo Nightly Builds Available

#202

Earlier quoted context omitted.

Well, we still do lots of reverse-engineering, because the specs are often wrong :)

It's a rule of thumb in most software I found studying high-assurance. Inevitably, some academic or commercial team wants to robustly implement some standard (esp a protocol). They notice it's specified in a combo of English and implementation code. They start doing formal specifications of English spec. Every time , IIRC, they find various inconsistencies and such that already did or could lead to real-world problem…

Implementing SIP a couple of times, part of it is the other implementations just flat-out misread. Even when there's a formal syntax specified, they simply ignore it. For instance, SIP specifies a "lr" (loose route) parameter. The syntax is just that: lr. But many implementations get it wrong and require a value, like lr=1, or lr=true.

Even things as simple as line endings are implemented wrong (in HTTP too), and that can cause security consequences as proxies end up reading headers differently than the user agents. I've seen this live on the public Internet.

SIP and the IETF to some extent encourages this with Postel's Law, telling implementors they should guess what the intention of the message is. We need less of VB's On Error Resume Next and more panic-abort type functionality. Look at this insane document: https://tools.ietf.org/html/rfc4475 "SIP Torture Tests". The authors gleefully come up with ridiculous yet legal permutations of messages that are allowed under their arcane rules. The fact this exists should send the opposite message: simplify your damn protocol. And this is only at the parsing level!

I know people say that HTML could never have had strictness because it'd have been too hard, but I don't buy that. One common issue was getting nesting wrong, like or leaving unclosed tags. By removing the (silly, honestly) name out of the ending tag and just using , a whole class of errors is removed. Add in a browser that just fails to render and explains exactly why, and people would quickly not publish pages that are broken.

Re: Servo Nightly Builds Available

#203

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.

1. That is intentional UX decision. 2. That is known bug, that hopefully will be fixed soon. https://github.com/servo/servo/issues/11937

Re: Servo Nightly Builds Available

#204

Earlier quoted context omitted.

It's a rule of thumb in most software I found studying high-assurance. Inevitably, some academic or commercial team wants to robustly implement some standard (esp a protocol). They notice it's specified in a combo of English and implementation code. They start doing formal specifications of English spec. Every time , IIRC, they find various inconsistencies and such that already did or could lead to real-world problem…

So most of the spec bugs I've come across don't have to do with English vagaries; they have to do with the reverse-engineering not being perfect. Converting the nebulous concept of expected behavior into procedural text is hard, and there are bugs. So yeah, "implementation deviations" is usually the issue, but not really English ambiguity, at least with web specs. I put my pedant hat on when looking at proposed chang…

There have certainly been spec bugs that could be found from a formal specification, some of which are security related (most of the TLS bugs found by miTLS have been protocol bugs simply found as a result of encoding much of the semantics formally).

That said, while I certainly have a fondness for formal specifications, I also always end up feeling like they have a lot of downsides. They're often very verbose and hard to skim, and they're also another language that anyone implementing the specification has to learn prior to implementing it (or they can just wing it, but then your formal specification is worth nothing!).

Re: Servo Nightly Builds Available

#205

Earlier quoted context omitted.

It's a rule of thumb in most software I found studying high-assurance. Inevitably, some academic or commercial team wants to robustly implement some standard (esp a protocol). They notice it's specified in a combo of English and implementation code. They start doing formal specifications of English spec. Every time , IIRC, they find various inconsistencies and such that already did or could lead to real-world problem…

Implementing SIP a couple of times, part of it is the other implementations just flat-out misread. Even when there's a formal syntax specified, they simply ignore it. For instance, SIP specifies a "lr" (loose route) parameter. The syntax is just that: lr. But many implementations get it wrong and require a value, like lr=1, or lr=true. Even things as simple as line endings are implemented wrong (in HTTP too), and tha…

> SIP and the IETF to some extent encourages this with Postel's Law, telling implementors they should guess what the intention of the message is. We need less of VB's On Error Resume Next and more panic-abort type functionality.

I don't think it's as clear-cut as that. I think the main thing is error handling must be defined: it doesn't matter whether it's panic-abort or whether it's defined how to deal with any stream of bytes. Don't let implementers choose what they should do.

Re: Servo Nightly Builds Available

#206

Earlier quoted context omitted.

> It's made by system developers and for people comfortable with debugging low level issues like kernel panics caused by faulty drivers. Fixed that for you :P PS. It is considered bad etiquette to ignore the issues of a Windows user and simply "recommend Linux" in a tech community like this, especially when a Windows build has already been promised. You don't know the reasons why someone is using Windows (ex. because…

I sorry to inform you, but Windows is considered harmful, so this is good etiquette now, also known as "word of mouth". You can download and run Linux in fraction of time you will need to argue that this is bad for a user. Download Linux. Download Servo. Run Linux. Run Servo. Profit.

Yeah I wish Linux desktop was that great. I run Xubuntu for dev work (Rust actually). Even really trivial things, like making the edges of the windows easy to grab to resize -- they get totally wrong: the target area is 1px or so. (Yes I know, Alt+Right click is an option, and I should really just use XMonad.) I go search for this issue. Sure enough, many years ago people were talking about this issue, and it's just one excuse after another. Never resolved; maybe it's a theme issue (with all in-box themes), maybe it should be solved somewhere else. Whatever. End result, out of box, it's difficult to resize a bloody window. I think that sums it up pretty well.

I've less and less love for MS (though Visual Studio...), but even with having to install crappy hacks to fix Win8, it's _still_ a smoother end-user experience than Linux desktop.

With Win10's Linux layer, assuming there's an accelerated X server for Windows, I can't think I'll keep even a VM around much. (If I can turn off Win10's spyware.)

Re: Servo Nightly Builds Available

#207
post #74
post #2

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 w…

> 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.

if feature_thats_not_implemented_yet:

  explicitly_crash

Re: Servo Nightly Builds Available

#208

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

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.

Re: Servo Nightly Builds Available

#209
post #2

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 w…

Awesome work!

I noticed that the Servo Nightly build is already about as big as Chrome or Firefox. As it's not yet a complete browser, I expected it to have a lighter executable. Do you know what lead to this? Is it a matter of build artifacts or optimization? Is Servo going to grow even larger while achieving feature-parity with other engines?

It looks like Servo could be a great alternative for Chromium Content -- one of the things that keeps me from (ab)using Electron/NW/CEF is the massive initial overhead, and a WebRender-based UI with lower admittance price would change the whole scenario.

Re: Servo Nightly Builds Available

#210
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?

Post reply on HN