Although the interminable feeling the author had while waiting for Firefox 3.5 to start up mirrored my own feeling of waiting for him to get to the f'ing point, he's absolutely right: Firefox should just be using the system's secure random number generator on each platform. If you have a vulnerability in /dev/random or CryptGenRandom(), you have a massively more important finding than Firefox crypto.
This is exactly the reason, as a general rule of thumb, why I don't like end-user software packages that are designed to be cross-platform. While I find Firefox 3.5 on OS X to be way faster than Firefox 3.0, it still doesn't hold a candle to Safari. It may as well be written in Java. For something as fundamental as a web browser, which I'm using all day long, it can't take 30 seconds to open a new window, freeze up and start thrashing halfway through rendering a page, or crash twice a day. (All of which Firefox 3.0 did, and which made me decide to move to Safari.) On top of the performance, the fact that Firefox uses a fake skinned XUL look-alike interface on each platform is the straw that breaks the camel's back, at least for me.
Port the renderer cross-platform, and write separate native apps for each target platform. The amount of complication and cruft that must be in the codebase for making a massively complex software package like Firefox work cross-platform, and the amount of basic OS-level functionality that must have to be reimplemented from scratch because it isn't available on some particular target platform, is probably no small contributor to its performance woes.
It gets worse: sometimes they won't use platform libraries because it conflicts with the ideology they're trying to force on the web.
"Of course we won't use DirectShow / QT / GStreamer as an alternate backend for <video> -- that would make it actually useful in the real world, and our Theora evangelism comes first!"
As usual, there's no conspiracy. They're working on a GStreamer backend for Firefox but it wasn't finished in time for 3.5. It will probably go in next time around; the current version is a functional stopgap until then.
Yes, and "not giving a shit" gave us the fun we had with GIF89 (Will Compuserve shut down the web?!?), various incompatible video formats (Real, AVI, etc.), so this time around, giving a shit might save us from having to go thru all that again.
The LZW GIF patent trolling was from Unisys (It was a submarine patent for Compuserve), and it only affected encoders -- it didn't threaten the web in any way.
The video wars were because [Apple, MS, Real, Macromedia, Sun] were all trying to compete with each other using crap products that conflated [Branding, Plugin, Container Format, Codec] in a mash of uselessness.
Flash won not because it had the same codecs on all platforms, the plugin was customizable the same way on all platforms, and the end-user branding was all yours to theme.
The most interesting part of <video> is not codecs or containers, but the full + uniform control and customizability via its Javascript API. The only reason there is any problem at all is because Mozilla is refusing to expose access to QT / DirectShow / GStreamer.
This is true, but I wonder whether this would have been the case had more image formats been patent-encumbered. The web is a product of open standards and formats, and Firefox is attempting to apply that ideology to HTML5 video formats as well.
Gecko used to be used directly by a number of consumers for implementing native applications, but Camino on OS X is the only one left. All others are long-dead or switching to Webkit.
Mozilla threw all of their weight behind XULRunner years ago. It probably wasn't that bad of a decision, given how much of a headache it is to use Gecko directly.
I think you made a good point there about the drawbacks of cross-platform end-user apps. The problem is that the idea of developing a single code-base for all the different platforms are so damn compelling to both managers (from a business perspective) and also lots of engineers who've learned to accept code re-use as the holy grail of our craft.
Even doing the core rendering part cross-platform has a lot of technical issues as the platforms provide a lot of functionality that can be leveraged by the rendering engine (typesetting, drawing, animation etc...). Consequently, the more you want to integrate with the native facilities of the platforms, the more interfaces and glue components you need in order to hook the platform independent part up to the native facilities. This leads to a loads and loads of ceremonial code and interfaces that introduce additional layers of complexity.
Fun Fact: In Safari since version 3, the <input> elements aren't actually native widgets anymore, as NSButton et. al. couldn't support a bunch of the CSS attributes. They are now rigorous behavior-level reimplementations!
A widget that looks native but behaves differently is terrible! At least when it looks alien you don't expect it to behave natively.
You know, I remember the times when Firefox was called Firebird and Phoenix and I adored it for loading way much faster than IE. It's surprising how much FF changed since then.
The old Mozilla Suite had a start-up preloading tool as well if I remember correctly. Still, Google Chrome loads up way much faster than either IE or FF without preloading anything at all.
I think Chrome has something that preloads stuff. Starting it right after login takes a lot more time than if you start it a couple minutes later. I don't think it's all due to the heavy activity a Windows login takes.
Some background: on Unix, Firefox obtains seed entropy from /dev/urandom, while on Windows it calls RtlGenRandom() for some reason instead of CryptGenRandom(). This seeding material is then fed to the random number generator, a NIST SP800-90 Hash_DRBG.
However they do obtain additional (optional) entropy (if you're familiar with the NIST DRBG's, then I'm talking about the 'Additional Input' parameter) by reading system time while periodically reading a bunch of system dirs to advance time in a non-deterministic manner. And that's where this bug creeps up.
Apparently the 10,000 eyes of open source missed this huge mistake =( This is exactly the kind of thing I wouldn't except to see in open source software.
Well, catching it after a long beta and then three rounds of release candidates. Indeed, it was apparently caught by an end user, and not those 10K eyes of developers at all.
And that's the beauty of FLOSS. An end-user caught a problem that will, hopefully, be corrected in a couple days.
Were it a problem within IE (or Oracle applications - let's be fair as this is not a Microsoft-only problem) we would have to wait until a developer reads the report, the bug being assigned and the correction being put in a future bug-fix release.
In a way, a guy from Microsoft just made a huge point on how open-source is far superior to their own closed development cycle.
To summarize for those who have less spare time than I:
Some firefox developer had a Very Bad (tm) idea to seed a random number generator by scanning the Windows Temp folders, which is now causing a 30 secs to over a minute pause in start up for a lot of users (particularly those that use IE, which creates a LOT of temp files). Yikes.
At least the good news about the Bad Idea(tm) is that this should be a very small fix for 3.5.x.1 - as opposed to some competing browsers invested development that ignored/contradicted standards, requiring complete re-do's.
Wow - thanks for the summary. Certainly didn't need wads of text to say that.
Its one of those things "seemed like a good idea at the time, worked well, I feel clever" and then you move on. Then it bites you (or one of your users).
My best guess.. RNG_SystemRNG first tries to use a deprecated API (http://msdn.microsoft.com/en-us/library/aa387694(VS.85).aspx), then CryptoAPI, then this temp file entropy gathering approach. But if the deprecated API is _broken_, rather than absent from the DLL, then it will fall back to scanning temp files without ever trying CryptoAPI.
Maybe it's just me, but I consider this a (serious) security issue as well. The contents of temp files, which Firefox shouldn't even have access to, will now float around in the process memory of Firefox, even after the memory has been deallocated.
Firefox should never, ever, ever, open any file outside its own app directory, user preferences directory, or cache directory.
And a reasonably secure OS shouldn't even allow Firefox to open any of those files.
Not necessarily. If this is a typical seeding algorithm, at most there would be one block of data in memory, used for hashing. And one would also think they are smart enough to zero it out before deallocating it. It IS a security library, after all.
If the files are really that important shouldn't they have good permissions set? That is, if "Firefox shouldn't even have access to" them, shouldn't that be enforced by some OS level permissions?
And shouldn't any other programs one has around not be writing confidential information to temp files in the first place?
Seems like more of a dumb bug to me than a security problem.
One bug is a "fiasco"? How about the 15 years the web has been set back by supporting broken browsers like IE6? Oh, well at least it starts up quickly...
The real issue here is how hard it is to be a consumer of open source software on Windows. On Debian, if I wanted to fix this, I would just "apt-get source" the relevant package, make the change, and have Debian build me a new package with the fix. On Windows, this is apparently not possible, as there is no package management system to install the compiler and source code for you, and the apps check themselves to make sure that you don't modify them.
(I also like how the virus / spyware situation is so out of hand on Windows that you can't even recompile libraries without your own computer assuming you are hacking yourself. Nice.)
Way to completely miss the point-Windows is NOT stopping him from doing anything-Firefox is. The problem lies within the NSS (security stack) inside of Firefox. NSS is integral to Firefox but is not in the main source-it is a separate project. Firefox checks the binaries when it launches to verify that NSS is a Mozilla signed build. So to build Firefox to fix the problem, you must:
Download Firefox source and NSS source
Make the fix in the NSS source
Edit the Firefox source to remove the Mozilla signed binaries check
Build everything and hope it works
There are MANY perfectly true complaints about Windows and the Windows software development world-but this is problem is all Firefox.
This guy happens to be a damn good software engineer. He shouldn't have to recompile Firefox to use it. His choice in typography and blog design sucks ass though.
> This guy happens to be a damn good software engineer.
I'd have to agree with that point. I think he pretty much single-handedly wrote LLBLGen Pro, an ORM solution for C# or VB.NET. My company uses it and I personally think it's really quite nice.
Funny, my reaction to your statement is, why would anyone use Linux? (as a desktop operating system...)
I'm a pretty good programmer. If I had to change the source on a program to use it, I wouldn't. I have better things to do with my brain cycles, and that's all there is to it.
Well, you have to compile the whole thing, not just replace one library. If you are writing the software, you can remove the signature check, obviously.
Speed isn't everything. For the love of all web developers everywhere, pick any browser (Safari, Chrome, Opera, or Firefox) and dump IE. We would greatly appreciate it.
I just let it start up when I log-in. By the time Outlook and the anti-virus (and, presumably, all the malware that was not caught by either my anti-virus or my IT staff), Firefox will be there too.
In the meantime, I walked the floor, said "good morning" to my co-workers and got a nice warm cup of coffee from the espresso machine.
Could I use Linux, I would have to start working only a couple seconds after my computer was turned on. Think of it as a quality of life issue ;-)
Well yes, it's a bug but it's hardly a fiasco. Something like this should be caught in pre-release testing. Still, most users have their browsers running all the time anyway so a slow startup is not really that critical.
I've seen far more serious bugs being taken far more lightly.
I'd more alarmed by the fact that they've thrown something new into the mix security-wise than the effect on startup time.
If the system pseudo-random number generator has no problem, what's the use case for not using it? And if it does have a problem I'm sure they would have told someone :)
I just don't know why you add another moving part to the security system if you could avoid it, especially since it seems like a reasonably safe bet that people have had more eyes move over / experience with the alternative.
Yeah, it's a stupid bug. Most bugs are once you find them.
I also agree that this got into the security layer is probably the most worrisome part of the whole story. Maye this could build a case for mandatory code reviews for security related modifications.
I wish the Firefox developers would focus on bug fixing for the next big release. There are so many bugs that are not fixed for many years. For example alt-text on images not correctly shown or disable-output-encoding on XML/XSLT being ignored. Instead that add more and more features. The awesome bar already made me switch to Opera, I miss some extensions though so I do keep an eye if Firefox gets "better" for me.
Awesome, and they even exposed in the UI rather than burying it in about:config.
Their arrogance of baking into the browser what is essentially a bundled extension was ridiculously annoying. My favorite added misfeature: it blacklists URLs with the 'about' protocol handler.
I had been disabling / detuning it piecemeal with extensions + settings to make it less obnoxious. I've come to like most of the completion features most of the time, but the visual presentation and interactive behavior is just fucking awful.
At least it's not as bad as Epiphany: it sorts only in direct chronological order (oldest first!), and in true GNOME style is not customizable in any way. Why the fuck would you ever want that?
What is correctly shown? It shouldn’t be shown as a tooltip as that leads people to write alt text that’s specifically useful as a tooltip and useless to the real consumers of alt text: screen reader users and search engines.
It was something like no alt text being rendered when images are not displayed or found, I don't fully remember and could not find it in 5 minutes Bugzilla search hell. I did stumble on the still-open bug some days ago though, I think it was 8 years old now.
Resolved in 3.0, but was outstanding for many years. The bug comments are worth reading (some of them are from the XKCD and Dinosaur Comics guys, whose sites this bug impacted fairly heavily). It doesn't make their dev community look like a place I'd want to be.
And this is precisely why the most recent Firefox install I have is from the 2.x series. It used to be that Firefox (then Firebird) was the lean and mean cousin of bloated Netscape. Alas, age has taken it's toll and the amount of built in crud in Firefox that has nothing to do with downloading had display HTML documents is overwhelming...
Hmmm - looking back, I'm not sure why I'm on 3.0x. Were there new features? JSON backups - whoopee! Other than that, from a user's perspective, I'm not sure there is anything better. 2.x was fine by me too.
I quite like the awesome bar now (was that in 2.0?); some CSS3 support too. Bookmarking tagging, update checking are good as well. Improved SVG support I use occassionally for viewing.
Other than that I suppose faster javascript and optimisations through use of sqlite for history/bookmarks is good.
Probably a few other things if I thought about it.
Main features are in add-ons for me, firebug, yslow, noscript, adblock, seoquake,download toolbar, greasemonkey.
I keep a separate clean profile, without all the footer-bar ("clutter bar") icons for the wife to use whilst surfing
* Awesomebar. Some people hate it but I love it, and in Firefox 3.5 it's extremely easy to disable via the GUI.
* Bookmarks. I can easily bookmark any page by clicking on the star next to the address bar. Clicking it again allows me to edit it or remove it. I use this all the time.
* History with search.
* Spell check. I used to think it's useless but now I cannot live without it.
Because the number of users on Fx2.0 is low enough that we don’t support it any more. It won’t look broken for the most part, but there’s no guarentees as we don’t actively test in it.
Because the JavaScript engine in 3.0 is lightning fast compared to the 2.x engine and the 3.5 is ummm, faster than lightning. By a heck of a lot.
For me personally, the only reason I downgraded back to 3.0 from 3.5 is because Firebug 1.4 is bloody awful at the moment (in beta). Other than that, Firefox 3.5 is great.
Oh you rock, this is awesome. As soon as I opened the link for this news item I closed it immediately due to the complete lack of readability. Someone buy the man a book on typography, please!
A tool as brilliant as this, combined with an audience that reads tons of articles spread all over the internet every day, surely it deserves its own thread?
I can see myself using Readability to format most of the articles I read online now.
I think sometimes a duplicate is valid, after all I read through HN 2-3 times a day and I still managed to miss the thread for this the first time around.
And Ctrl-0 returns to default size. Before I knew this I was more resistant to temporarily adjusting font size because of the annoyance of then returning to default size.
I always just "(Dis)allow pages using their own fonts" + a readable minimum font size. That makes browsing much more comfortable for me and doesn't break too many sites (only very rigid table layouts, most of the time crappy online shops).
Before submitting my own comment re:the lack of line-height on this site I searched for "line-height" in the comments because I know Hacker News so damn well.
Forchrissakes people how does anyone think this is even approaching readable!? Someone needs a whack with the UI stick
Or just surf around with firebug installed. Then:
right-click the text area, choose "inspect element", then right-click the DIV its in, in Firebugs code area, then add this attribute:
style="line-height:1.5; font-family: Lucida Grande; width:50%; margin:0 auto"
(asp.net's ridiculous CSS is a bit trickier, but that CSS snippet usually gets most sites up to readability scratch)
Oh, and a poor man's arc90 readability thing can be found with the "zap annoyances" bookmarklets:
The "thread dump" feature should be an absolute requirement for any language runtime environment. Java has perfected this with the SIGQUIT signal. Thread dumps give you readable stacks of all threads with a simple user command (kill -3 on Linux/Unix, although a bit more difficult on Windows), without having to install symbol files, install additional software, run "scary" commands (for end users), etc.
This is a textbook example of taking a few thread dumps, a few minutes apart, immediately showing what is going on. IBM has one of these as their Performance or Hang "MustGather" script:
.NET thread dumps suck -- you have to use adplus to attach and they're not easy to read. Native programs (e.g. C/C++) work better with symbols and are just too scary for end users. DTrace on Solaris with Ruby/Python/PHP extensions is nice, but too cumbersome to install, and again too scary for end users.
I'm not aware of built-in thread dumps-by-signal in other non-Java languages (please note in a comment if there is), but this feature is so basic and needs to be baked in to every runtime environment and easy enough for end users to use.
Firefox, being a native program, is in a bad problem determination position here and the haphazard nature of the problem determination process in the forum and bug report shows that. I suggest Firefox create something like IBM's MustGather scripts (starting with a performance one such as IBM's hang MustGather -- http://www-01.ibm.com/support/docview.wss?uid=swg21115785 [click "Show Details" for the steps]). A hang MustGather should go through the process of installing symbol files, getting the thread stacks, submitting the information, etc. This will allow users to at least feel like they can do something valuable to help the developers fix the problem.
