Engineering code quality in Firefox • Hacker News Board

Re: Engineering code quality in Firefox

#131

Post by juskrey » Wed, Apr 22, 2020, 3:54 PM UTC

exdsq wrote: post #130

juskrey wrote: post #115

Earlier quoted context omitted.

This is especially laughable, since I have seen how that works on practice: take something everyone already does, write 1000 of PhDs on that, add to academic history book, now wikipedia and voila. If any of IT projects came from academia to the market, it's only because certain people were picked up by businesses that were onto something already.

I don't mean this in a derogatory way but from your bio it sounds like you work in full-stack web development - maybe with some data processing. Sure, this stuff doesn't really come from academia. But there are other bits of tech where academia does play a large part and your viewpoint is just not correct. One example that contradicts your second paragraph away is I spent several years at a consultancy that helped ac…

Coincidentally, before current full stack freelancing stuff, I've spent around two years in augmented reality, often having to dig through tons of published research, only to realize pretentious lab methods do not work outside. We ended up adopting some methods from hacky teens on DIY forums, but never that..

Re: Engineering code quality in Firefox

#132

Post by pcwalton » Wed, Apr 22, 2020, 4:37 PM UTC

gsnedders wrote: post #119

why_only_15 wrote: post #97

Earlier quoted context omitted.

as of the last time i recall the window server had some special treatment for safari to try to optimize various things -- is that true?

I'm unaware of any special treatment (but that doesn't mean there is none!), beyond Apple caring about battery life in general on their OS and I would strongly expect that the browser forms part typical-use testing of the OS and as such influences what parts get targeted for performance work. Certainly Apple's WebKit port uses Core Animation heavily, which is definitely heavily tied to the compositor in the window se…

Safari definitely uses private APIs (or at least did at one point) to manipulate out-of-process layers more directly than the public CA API lets you do.

Re: Engineering code quality in Firefox

#133

Post by ohazi » Wed, Apr 22, 2020, 5:12 PM UTC

swiley wrote: post #118

thayne wrote: post #66

Earlier quoted context omitted.

> Trying to compile Firefox was already a challenge. That, and each compile took an hour. At first glance, this sounds terrible. But when compared to software projects of comparable size, Firefox is hardly unique. Compare to compiling Chromium for example, or even the Linux kernel.

Those are all very different levels of difficulty IMO: Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies. Firefox is pretty painful but it's doable with a decent amount of care and bandwidth. Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are al…

The first time I had a reason to build Chromium was ten years ago. I was using a 32-bit machine with 4 GB of RAM, and that's where the story ends.

Re: Engineering code quality in Firefox

#134

Post by gsnedders » Wed, Apr 22, 2020, 7:45 PM UTC

pcwalton wrote: post #132

gsnedders wrote: post #119

Earlier quoted context omitted.

I'm unaware of any special treatment (but that doesn't mean there is none!), beyond Apple caring about battery life in general on their OS and I would strongly expect that the browser forms part typical-use testing of the OS and as such influences what parts get targeted for performance work. Certainly Apple's WebKit port uses Core Animation heavily, which is definitely heavily tied to the compositor in the window se…

Safari definitely uses private APIs (or at least did at one point) to manipulate out-of-process layers more directly than the public CA API lets you do.

Ah, yeah, it does seem to still do that. For some reason I thought that those APIs had been made public, but alas no.

Re: Engineering code quality in Firefox

#135

Post by freeboson » Thu, Apr 23, 2020, 1:18 AM UTC

alephnan wrote: post #23

We had an "open-ended" project in an undergraduate Computer Security course to discover a 0-day in Firefox. The professor (a researcher, not lecturer, by trade) didn't really have a curriculum, and said this artifact accounted for 70-80% of our grade. Trying to compile Firefox was already a challenge. That, and each compile took an hour. IIRC, Firefox is built on some esoteric architecture / design pattern that's def…

The syllabus where a grade is broken down by percentages is (at US institutions) considered to be like a contract. If the course originally had it at "70-80%", then it cannot be changed mid-semester without being acceptable to you. It's fairly incredible for this to happen (at a US institution).

Re: Engineering code quality in Firefox

#136

Post by freeboson » Thu, Apr 23, 2020, 1:24 AM UTC

swiley wrote: post #118

thayne wrote: post #66

Earlier quoted context omitted.

> Trying to compile Firefox was already a challenge. That, and each compile took an hour. At first glance, this sounds terrible. But when compared to software projects of comparable size, Firefox is hardly unique. Compare to compiling Chromium for example, or even the Linux kernel.

Those are all very different levels of difficulty IMO: Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies. Firefox is pretty painful but it's doable with a decent amount of care and bandwidth. Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are al…

Do you have to build chromium with blaze? Or does it use e.g. cmake or something?

Re: Engineering code quality in Firefox

#137

Post by webmobdev » Thu, Apr 23, 2020, 2:50 AM UTC

sgift wrote: post #112

webmobdev wrote: post #103

Earlier quoted context omitted.

> About DRM: Mozilla fought against it, and caved when it became clear they could not win. While I do believe there was genuine opposition to this move within the community, I think the real decision makers had already made up their minds and just made a show of "discussing" it. I feel they did it under pressure, and perhaps were even induced with promises of more revenue, from Google. And where was the question of r…

> While I do believe there was genuine opposition to this move within the community, I think the real decision makers had already made up their minds and just made a show of "discussing" it. I feel they did it under pressure, and perhaps were even induced with promises of more revenue, from Google. The problem with beliefs is that there is no option to disprove them. Mozilla said they fought against it, the people wh…

> And what incentive would companies have had to do that? Firefox simply doesn't have the market share to force anyone to develop for them.

- Firefox has enough of a marketshare that nobody ignores them. - If Google wouldn't, someone else would have. - The content providers (Netflix, Prime, Hulu etc.) would have forced them to do so.

I don't buy these arguments. And the fact that Mozilla makes it opt-in by default shows that the Mozilla board is now more concerned about revenue from Google and squeezing it as much money from their product than actually improving it. I wish the Firefox developers had more voice.

Re: Engineering code quality in Firefox

#138

Post by jbroman » Thu, Apr 23, 2020, 2:54 AM UTC

freeboson wrote: post #136

swiley wrote: post #118

Earlier quoted context omitted.

Those are all very different levels of difficulty IMO: Linux is almost trivially easy, only slightly harder than the usual configure && make and has very few dependencies. Firefox is pretty painful but it's doable with a decent amount of care and bandwidth. Chromium is a fairly typical google project where the recommended first step to building it is to become a google employee but some alternative workarounds are al…

Do you have to build chromium with blaze? Or does it use e.g. cmake or something?

It's uses gn, a build system developed for Chromium. That said, on an Ubuntu system the steps to build Chromium are fairly well-documented and straightforward, as long as you have an appropriately beefy system (unfortunately it's a long wait and a fair amount of RAM is required, and Googlers tend to use a distributed build system).

https://chromium.googlesource.com/chromium/src/+/master/docs...

Re: Engineering code quality in Firefox

#139

Post by webmobdev » Thu, Apr 23, 2020, 3:30 AM UTC

gsnedders wrote: post #117

webmobdev wrote: post #33

Earlier quoted context omitted.

> Presto wouldn't be so memory efficient on today's web; I disagree. (I continued to use the last version of Opera Presto for a few year even after it was abandoned, and it continued to outperform other browsers on both platforms - Windows and macOS, though the macOS version was a bit more buggy). Let's not forget that Presto already supported a lot of HTML5 features(1) before it was abandoned. (Even today, it works…

> I disagree. (I continued to use the last version of Opera Presto for a few year even after it was abandoned, and it continued to outperform other browsers on both platforms - Windows and macOS, though the macOS version was a bit more buggy). Loading my profile on Twitter leads Presto to use more memory than Firefox. (Though really that's a terrible benchmark, probably want to disable in-memory caching.) > Let's not…

> Loading my profile on Twitter leads Presto to use more memory than Firefox. (Though really that's a terrible benchmark, probably want to disable in-memory caching.)

That's not surprising as current Firefox has indeed made improvements. Your argument is disingenuous if you aren't comparing Opera presto with the equivalent version of Firefox of the same period. Firefox than couldn't even manage 10-20 tabs, without high RAM consumption, whereas Opera Presto could easily handle around 100+.

> Morale only really collapsed after the move to WebKit, nor had there been lay offs for several years prior.

I didn't claim the layoffs started years before they were sold. Opera was a solid company for some time. But many employees were laid off prior to Opera being sold to their current owners, mostly the marketing and support staffs and some developers. Morale was indeed low in the company. And rumours were already swirling around in Opera forums and popular Opera fan blogs that Presto would be dumped. (And it was dumped ultimately for Blink, a fork of webkit, created in partnership with Google).

Your point about some memory issues with engines, compared to the previous versions, are correct. Despite those issues, Opera Presto was still better than Gecko during the same period.

My point is to compare Apple to Apple - highlighting the weak point of a browser engine, whose development has since been abandoned, by comparing it to Gecko's current modern avatar doesn't make sense, when my argument is that Presto was a better engineered product than other browser engines of its times. Ofcourse I agree that Firefox has come a long way and is far better now. (That's why I shifted to it after Opera died).

> The graph of module dependencies was ... so in many ways it really wasn't modular.

Perhaps so. It is still easier to understand than Firefox's mish-mash of a codebase, because it is smaller and better coded.

Re: Engineering code quality in Firefox

#140

Post by webmobdev » Thu, Apr 23, 2020, 3:52 AM UTC

acdha wrote: post #126

webmobdev wrote: post #71

Earlier quoted context omitted.

> ... only that there’s been more than a decade of massive improvements which is not reflected in your comments ... Oh ok. I see the confusion - I was speaking specifically about Opera (Presto engine) versions. Not the current Opera Chromium clone. And the point I was trying to make is that it was a much, much better product than its competitors. And if it had survived, with the original team still working on it, it…

I was also talking about Presto. It was good at the time in some areas but that’s like the guys who say their classic car is unmatched ignoring that everything on the lot is safer, lower maintenance, and less polluting. People switched because Presto wasn’t perfect (I had plenty of big reports) and it was falling behind with each release as Mozilla and Google really hit their strides.

> I was also talking about Presto. It was good at the time in some areas but that’s like the guys who say their classic car is unmatched ...

I was talking about Presto in comparison with browser engines of its period. As for people switching to others because "Presto wasn't perfect" - obviously, even an Opera fan like me did too, because the project was abandoned and started showing its age! My point was that it was a much better engineered project than its competitor of the same period and if its development had continued with the same philosophy, it would still be one.

When I say Opera Presto was better, I do mean better than Gecko, Trident, Webkit of that period, not better than the current modern versions of these browser engine.