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…
That makes no sense as a class design - are there so many zero days in firefox that are so easy to find that you can expect undergrads to casually find enough that you can base 70% of the class grade on it?
Engineering code quality in Firefox
41–50 of 155 posts
Re: Engineering code quality in Firefox
#42> Our next major challenge: We are dealing with 21 million lines of code. I think I just fail to understand the true complexity of a browser, but how is Firefox 21 million lines of code? How can a browser be 21 million lines of code? That just seems so large for what a browser does.
Re: Engineering code quality in Firefox
#43Earlier quoted context omitted.
Any change to the grading scheme of a class should be Max(old grade, new grade). One of my profs once offered a re-test opportunity such that you would have had an incentive to do worse on the exam for certain original scores. Drove me up the wall.
I also think that just keeping the new grade is a valid retake scheme. Although it's less forgiving for the students, it encourages them to make absolutely certain that they know the content for the retake. Anything with a square root curve where you have to pinpoint your retake score perfectly to maximize the final grade is unfair and encourages the wrong thing.
Re: Engineering code quality in Firefox
#44Earlier quoted context omitted.
the f does Firefox ... same URL when opened in safari It would be interesting to compare the safari budget/manpower. Even given that, I would imagine safari only has to support one-ish OS, and probably has help from the OS group.
The WebKit team is smaller than the corresponding team at Mozilla, even if you look at the subset of of identical roles across both organizations (and e.g. ignore those working on the Firefox network stack). That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS lib…
Re: Engineering code quality in Firefox
#45Earlier quoted context omitted.
Opera felt small and fast because it did less and ran websites doing less. If you look at an old site in a modern browser, it's much faster; if you even could run a modern site in an old browser, you'd see just how many optimizations you're taking for granted — not to mention things like high-quality text rendering which fully supports Unicode and complex scripts.
> Opera felt small and fast because it did less and ran websites doing less. Let us assume that is true (even though it isn't) - what's Firefox and other browsers excuse for running slower than Opera on these same sites, during the same period? Opera presto supported a lot of the features of HTML5(1). So it didn't necessarily "do less" than the others. And second, if you really want to compare Opera presto with other…
Re: Engineering code quality in Firefox
#46We 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…
Re: Engineering code quality in Firefox
#47Earlier quoted context omitted.
Presto wouldn't be so memory efficient on today's web; web applications typically ran into plenty of places where memory consumption was worse in Presto versus WebKit, for example. (A simple example here is that each DOM Node was larger in Presto than any other browser, if I'm not forgetting.) But ultimately a lot of this comes down to different considerations: when the majority of your revenue comes from companies w…
> 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…
Just about all of the major browsers earned their reputation for being blazing fast, tiny, and using little memory. And those attributes are well-deserved at their launches. Then real-world pressures kick in -- it turns out that although people love small and fast, that doesn't do them much good without support for X (or being able to handle condition Y), and there are many, many values of X (and Y). Small and fast plus X would still be nearly as small and fast, but small and fast plus all X is decidedly not. Meanwhile, the other engines are evolving too, and everyone more or less converges on roughly the same performance characteristics. We [I work for Mozilla] end up mainly competing on different metrics, assuming we all keep up with "good enough" speed and size.
> It says a lot about Firefox that despite being older than both Chromium / Blink and Webkit, the latter are more popular in many open source and commercial applications because of the ease of use in coding and integrating it in their applications.
Indeed it does. Firefox abandoned embeddability long ago, and only recently decided to try again with GeckoView. And yes, it was a deliberate decision, but not for the profit motivations you're suggesting. It was based on maintainability and developer velocity, when we realized we were not going to out-compete Google with engineer headcount. We had to simplify and reduce our nonessential complexity overhead.
> Mozilla also made some developers sign non-disclosure agreements
Why throw so much shade? I'm not sure exactly what you're referring to, but Mozilla does indeed sign NDAs for stuff that people will only make available under NDA, and there is some insider knowledge that can only be released under NDA or not at all. That was far more common with FirefoxOS, because let's just say that the mobile industry isn't quite as open as desktop. (Massive understatement!) But generally speaking, we have very little to gain from keeping any technical or architectural stuff private, and quite a bit to lose. We're still a community-based project, and get very substantial contributions from non-employees, admittedly much less than in that past as a percentage (for a long time, we hired up many of the better contributors, which cut both ways.) The vast majority of our discussions happen in open forums (Matrix instead of IRC now, but still mailing lists + newsgroups + various other things). The only private technical stuff I ever deal with is security-related, and even there we're very good about opening up bugs after they've shipped.
Re: Engineering code quality in Firefox
#48Earlier 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…
> The source code of Opera Presto is out there on the net I don't suppose it's been open-sourced, has it? It would be great to have an alternative browser engine out there, instead of just three (or two and a half, depending on how you count Blink and Webkit).
No, it was leaked illegally. Opera filed a lot of DMCA complaints with many online Git repository services to get the code removed from them. But you can still find it if you Google hard. I also recall reading that some Russian developers were working on the leaked code and had also released a "newer" version with some patches (Opera presto was really popular in Russia) but I couldn't find it.
There is another little known open source browser project independent of Gecko, webkit and Blink currently being developed but I just can't remember its name, even though I tried compiling it on my system ... damn ... I'll post an update when its name comes to mind.
Re: Engineering code quality in Firefox
#49Re: Engineering code quality in Firefox
#50Earlier quoted context omitted.
the f does Firefox ... same URL when opened in safari It would be interesting to compare the safari budget/manpower. Even given that, I would imagine safari only has to support one-ish OS, and probably has help from the OS group.
The WebKit team is smaller than the corresponding team at Mozilla, even if you look at the subset of of identical roles across both organizations (and e.g. ignore those working on the Firefox network stack). That said, it's worthwhile remembering that WebKit does very much maintain all the abstractions to be cross-platform (and Apple do still maintain a Windows port), even if it does try and leverage plenty of OS lib…