HN Theater @HNTheaterMonth

Metajack mention power usage with parallelization briefly here[0], but doesn't provide the data.

[0] https://youtu.be/7q9vIMXSTzc?t=35m (2015)

⬐ taeric

To be clear, the reasoning is sound on this argument. I'm skeptical due to it never having delivered data, though. :(

I want it to be true. I expect that someone should be able to show this with data. I've never seen it done, though.

⬐ noch

You can collect much of this data for yourself on a GNU Linux system by using the cgroups feature of the Linux kernel which is more powerful than nice https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.t... .

Using the various CPU* options, you can turn on CPUAccounting, pin a given process and its children/threads to a range of CPUs, place CPUQuotas and so forth. There's a lot of power and granularity there.

I know, anecdotally, that devops/sysadmin folk use this to also audit and test energy consumption of processes over time. (Certain popular PID 1 programs have a run tool that allows you to easily, dynamically change and audit process resource usage.)

My typical use case, for instance, is auditing and managing various Emacs' processes lifetimes while running potentially racy elisp code.

⬐ taeric

I know the data can be gathered. Could go even more direct and measure power usage of the computer before and after the upgrade.

It would be nice if everyone pushing some of these would collect some data for their claims, though. Especially if any of them have better setups (read: more than the single machine I have).

I suspect you will hear a lot of numbers around the time of the 57 launch, and until then people will keep quiet as they try to make the numbers that get revealed as good as possible.

For old numbers, you can get some in some of my old presentations at conferences. I think the LCA 2015 one[1] has the most details in that regard.

[1] https://www.youtube.com/watch?v=7q9vIMXSTzc

After seeing a youtube demo[[1] of how the aggressive parallelisation that is done in Servo (safely possible by using Rust) speeds up this browser, i'm really excited for Servo! Also, i think this will give us a great base for all kinds of browser embedding what is not based on ancient webkit-gtk.

There is another nice presentation on Rust and Servo: https://www.youtube.com/watch?v=7q9vIMXSTzc

[1]: https://youtu.be/UGl9VVIOo3E?t=1019

⬐ krzat

I'm hoping for Servo-based alternative to Electron. If it could deliver some performance/memory improvements it would be good advertisement for the project, and also for Rust.

Not sure if that's realistic, Servo app ran on macOS takes about 200MB of RAM usage.

⬐ Eridrus

Servo isn't going to use any less CPU than other rendering engines, it will just be able to increase user-visible performance significantly by reducing latency by making better use of multiple cores.

⬐ rahkiin

And slack on my macOS takes 800 mb. And WhatsApp as well. And Discord.

⬐ themartorana

I keep hearing about Servo (and compiling it every now and again), but I really don't know - is Servo meant to eventually, maybe replace Gecko? Or is it/will it always be just a Rust playground?

It seems like it could seal Rust as a player if Servo became "A Thing" for real. What's the plan?

⬐ gulpahum

In the video (at 35:39), they show the future plans and the plan is to start using bits of Servo code in Gecko. So, they will replace small parts of C++ code with Rust. http://youtu.be/7q9vIMXSTzc?t=35m39s

One plan was to first replace easy parts, like image decoders (bmp/ico formats). https://github.com/servo/servo/wiki/Mozlandia-Rust-In-Gecko#...

It won't be a one big replacement, more like a gradual take over.

⬐ higherpurpose

I believe they've already said that it will replace Gecko on Android and in Firefox OS (this year). It's 2x faster than Gecko on a single core and 3x faster on four cores.

If it's really that good (and so much safer, as Firefox tends to be the browser with the most vulnerabilities) then it would be crazy for them not to build it into a full browser eventually. Microsoft is doing it, so they should do it as well.

Maybe with a new browser they can make Electrolysis be much more optimized as well. I think the main reason it takes them so long to get multi-process to work is because they have to optimize around Firefox's quirks, and I'm worried it still won't end up as safe or as quick as Chrome's multi-process system, which was built for Chrome from day one. In a new browser it might work much better.

⬐ lastontheboat

Not quite, and certainly not this year. We've said that we want to release an alpha version of something powered by Servo on Android this year; the Firefox OS work is just another good way to show viability of our ideas - it would be a huge feat of engineering to get it ready to ship on devices under the Firefox OS banner.

⬐ bobajeff

I'm sure they want to replace Gecko with Servo but they can't because it doesn't have xul/xpcom and it never will. There was a post a while back about a side project called Firefox.html which is to rewrite the interface in html5 instead of xul.

Anyways they shouldn't replace gecko but instead make a new browser with it's own branding like the Internet Explorer team is doing with Spartan. Because no matter what Mozilla does with Firefox it will never gain market share because they've lost momentum and don't have resources it takes to brute force users to their product like the big guys have.

⬐ stefanix

"never" and "lost" aren't words I would use with Mozilla. Their vision is solid with lots of innovation going on. They have major market share. They are light years ahead in terms of privacy and repeatedly beat all the other browsers in performance benchmarks.

Afaik, XUL is already replaced on the mobile Firefox version. Would not expect it in Rust at all.

⬐ bobajeff

Why, because of all of those buzz words? Name any company that doesn't have vision and innovation going on. Also, name any browser that doesn't repeatedly beat the others in benchmarks.

The facts are Firefox has not only lost momentum (as in stopped gaining market share) it's been losing market share.

⬐ wmf

It doesn't make sense to me that Mozilla would spend this much effort on a playground. I suspect they're managing expectations when they say it's not intended to replace Gecko.

⬐ TehCorwiz

He says in the video that since the bar to entry into the browser space means feature/speed parity (because if it isn't faster than what we're already doing what's the point) that it will eventually be a complete browser. What isn't covered is whether it will replace the gecko engine or if it will become a new browser entirely.

⬐ RubyPinch

>(because if it isn't faster than what we're already doing what's the point)

stability, security, etc

having no more page corruption issues would be nice

⬐ xKingfisher

As far as I know, there are no plans to replace Gecko, though they may pull in parts or ideas from Servo. Servo is still primarily a research project into parallelizing a web browser.

⬐ keeperofdakeys

It's too early, really. You don't take an experiment, and say "This will replace our main, stable product." You keep investing in it on the side until either, it's mature enough to make that decision, or it fails for some reason.

At the moment there is plenty of steam behind Servo, and it's growing all the time. So an optimistic outlook is that it will mature, and have a chance of becoming a full-fledged product. However problems might prick up, maybe Rust isn't quite as good for this as they think, maybe the experimental parallel architecture doesn't fully pan out. You can only make these kinds of observations when you've implemented most, if not all of the features required for the final product.

⬐ pjmlp

> 34 security vulnerabilities in WebAudio due to use-after-free and out-of-bounds errors

This is what happens to any language that builds on C's compatibility.

⬐ LinaLauneBaer

out-of-bound errors happen in other languages as well. use-after-free happens in almost every language that is not gc'ed.

⬐ pjmlp

> out-of-bound errors happen in other languages as well.

In sane languages an out-of-bounds error causes program termination, unless it was disabled on purpose (assuming it can be disabled). In C anything goes.

An out of bounds can cause the program to be injured, but not die, and eventually have some kind of inconsistent state.

> use-after-free happens in almost every language that is not gc'ed.

Yes, true if we are speaking about Modula-2 or Extended Pascal dialects. The most notable alternatives to C with manual memory management.

Everything else has at very least reference counting support.

⬐ LinaLauneBaer

Reference counting does not avoid using something after freeing it...

⬐ pjmlp

Then the reference counting is not properly implemented, otherwise reference count would be greater than zero.

⬐ LinaLauneBaer

    object = create_object() // RC 1
    object.release() // RC 0 => will be released
    // ...
    object.doSomething() // Used after object was released

?

⬐ maemre

I think parent means reference counting built into the language (like Python)

⬐ zokier

I was looking at Servo some time ago for more general Rust GUI framework but then the event-system was still incomplete, iirc you couldn't use Rust code directly as handler for DOM events. What is the situation today?

⬐ lastontheboat

No different. Once we're able to run browser.html [1], using it as a GUI for other things will be a more realistic proposition.

[1] https://github.com/mozilla/browser.html/

⬐ DecoPerson

I was at this presentation. Before the recording started, he said that the volatility of the Rust standard and its library really inhibited productivity.

He said something along the lines of: "By the time we update the codebase for a syntax update, there would be a library API change and vice versa."

I recommend checking out the rest of the LCA2015 talks; very informative if they apply to your area, IMHO. Dave Chinner's talk about how important "knowledge transfer between humans" was to kernel development and software engineering in general resonated strongly with me.

⬐ lambda

Well, Rust is now at 1.0.0 alpha, which means that the language has almost all of the planned breaking changes implemented (there are still a few corners where there are a few breaking changes planned, but in things that are minor enough to be unlikely to break much code).

The standard library is still in rapid iteration mode in the preparation for 1.0.0 beta, and thus large portions of it are marked unstable and so only available if you opt-in via a feature gate, but the plan is to stabilize that through the alpha and beta period and have a usable, stable standard library at 1.0.0, which is planned to come out within a few 6-week release cycles from now. And things which are not ready, or not really appropriate for a core standard library, are being moved out into separate Cargo crates that can iterate independently from the core language.

So yes, Rust has been iterating rapidly on the road to 1.0, which makes keeping up with the treadmill painful, but it's finally settling down; very soon you should be able to use it without constant breaking changes.

⬐ steveklabnik

> in things that are minor enough to be unlikely to break much code).

As much as I want this to be true, it's not. `io` is one of those libraries. That's going to break a lot of stuff, probably.

Beta is the 'your code will almost absolutely not break' release.

⬐ lambda

Sorry, tried to make that distinction by saying that the language has very few breaking changes left, and those that are left are expected to be minor, but the standard library is still in rapid iteration mode and is expected to break a lot.