Live data from Hacker News

Servo Nightly Builds Available

blog.servo.org

181–190 of 246 posts

Re: Servo Nightly Builds Available

#181

Earlier quoted context omitted.

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

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

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

Re: Servo Nightly Builds Available

#182
post #84

Earlier quoted context omitted.

In pure Rust that never uses "unsafe", maybe. (Though even then, you only get memory safety; it's still possible to e.g. go into an infinite loop and use all CPU and/or memory).

Does anyone know if Servo has any unsafe Rust code?

Yes, quite a bit of it: https://github.com/servo/servo/search?l=rust&q=unsafe

Re: Servo Nightly Builds Available

#183

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.

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

It's worth looking at WebKit's implementation: https://github.com/WebKit/webkit/blob/master/Source/WebCore/...

Re: Servo Nightly Builds Available

#184
post #84

Earlier quoted context omitted.

In pure Rust that never uses "unsafe", maybe. (Though even then, you only get memory safety; it's still possible to e.g. go into an infinite loop and use all CPU and/or memory).

Does anyone know if Servo has any unsafe Rust code?

If it uses any external libraries (for example, for image handling) then I believe it does by definition, since the API wrapper you end up writing ends up being a small shim that wraps the actual library call in unsafe (because object code is unsafe, as the term in used in Rust).

Re: Servo Nightly Builds Available

#185
post #129

Earlier quoted context omitted.

It's also still possible to panic.

Panic's implementation uses unsafe code, IIRC. But stuff like stack overflow can happen even without explicit unsafe code, I think.

Rust intercepts most stack overflows and aborts the program when they occur. There are some more difficult cases where legit stack overflows are still possible, the resolution to which is blocked on LLVM support on most platforms (notably, Windows is the best here).

Re: Servo Nightly Builds Available

#186

Earlier quoted context omitted.

I feel like mobile (Android, really) needs a fast, secure and extensible browser, I hope that Servo can help Firefox achieve those first two goals so that it could be my browser of choice

Servo is trying to be fast on mobile; there even has been some research work into the power efficiency of servo on mobile. Admittedly, android-specific efforts have slowed down in the past few months, but I believe it is still a goal :)

Given the fate of FirefoxOS and iOS' restrictions on browsers, is there any other mobile platform where Servo could actually be used?

Re: Servo Nightly Builds Available

#189

Earlier quoted context omitted.

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

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…

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.

Re: Servo Nightly Builds Available

#190

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…

Interesting. Thanks for the perspective.
Post reply on HN