Slashdot Mirror


Happy 5th Birthday To Firefox

halfEvilTech writes "Five years ago today, Mozilla released Firefox 1.0. Ars celebrates the occasion by taking a trip back in time to revisit our classic coverage of the original release." For fun, we dug up the oldest Slashdot Firefox story, which was a Firebird story proclaiming yet another name change from Feb '04. At least this name change stuck.

4 of 252 comments (clear)

  1. Re:Original Firefox goals forgotten... by Neil+Hodges · · Score: 4, Informative

    GP is confused due to this sort of news. Parent is correct in that there will be no such interface.

  2. Re:Original Firefox goals forgotten... by RiotingPacifist · · Score: 4, Informative

    You can disable it entirely (the functionality not just the look) in FF3.5, so what exactly is your problem with me using it?

    --
    IranAir Flight 655 never forget!
  3. Re:Original Firefox goals forgotten... by BZ · · Score: 4, Informative

    Gecko's memory usage now is less than it was in the early 2000s in many cases. So this particular program is actually using less memory than it was in the early 2000s. Since just the shared libraries for it are bigger than 32MB (uncompressed, on some OSes, etc), it's hard to see how it could fit in 32MB of RAM...

    If your question is why there are these big shared libraries, the answer is that it's trying to do too much. The SVG1.1 spec is about 800 pages last I checked. And this is not because it goes into excruciating detail or anything. The CSS2.1 spec is about 300 pages (and while it's better on the detail, it's not perfect). You just end up with a huge gob of code to handle all those behaviors the huge specs require.

    How much memory do you think a web browser handling modern web standards should take up? How does that number stack up against existing web browsers?

    There's also the data set. People think nothing of sending hundreds of kilobytes of JS per page to the browser (last I checked, cnn.com has upwards of 500KB of JS just linked directly from the page; who knows whether they load more?). People think nothing of sending large amounts of graphics, etc.

    Which brings us to the last point: programs are bigger because they _can_ be. If you have to fit into 32MB of RAM, then you can't just decode a 3000px by 3000px image into memory (it's be 4 * 3000 * 3000 bytes, or 36MB). You do it piece by piece and forget the pieces after painting them, or something. You don't even cache decoded smaller images, since it's so easy for that to fill up memory. If you feel like you have more ram to work with, you might make the space/performance tradeoff of keeping the decoded image in memory instead of decoding on every paint...

  4. Re:A cake is in order by Nerdposeur · · Score: 4, Informative

    News for nerds. Stuff that matters (to nerds).