WebKit Gives Konqueror a Speed Boost (Past Firefox) 199
An anonymous reader writes "We always knew that WebKit is going to make Konqueror fast; but how much faster? Today we test that by putting Konqueror with KHTML through the SunSpider JavaScript Test and the then do the same with WebKit. To get an idea of how fast they are compared to other browsers, we also decided to put Firefox 4.0 Beta 2 through the tests."
I Guess ... (Score:5, Funny)
Re:I Guess ... (Score:5, Funny)
"...like an old lady krossing the street. Now it's more like the kar racing away after running over the old lady.
--
"If I'd asKed my kustomers what they wanted, they'd have said a faster horse." ~ Henry Ford"
^fixed...
How important are JavaScript times? (Score:5, Interesting)
How important are JavaScript times to the overall speed of rendering pages?
Is it like comparing 0-60 times for cars (a decent indication of performance, though not the best)? Or is a bit like measuring the time from 0-10 in first gear - a rather insiginificant proportion of the whole time taken to render a cross-section of typical web pages?
Do sites just concentrate of JavaScript performance so much because it's easier to measure?
Re:How important are JavaScript times? (Score:5, Insightful)
That is the wrong question. How important is Javascript speed for advanced web applications and HTML5 games?
Re:How important are JavaScript times? (Score:5, Funny)
How important is Javascript speed for advanced web applications and HTML5 games?
Cue the inevitable weenies who protest that the web is intended for documents, not applications, and applications should be written in native code, not JavaScript. In fact, queue them too because there seem to be so many of them.
Re: (Score:2)
Re:How important are JavaScript times? (Score:4, Funny)
Re: (Score:3, Interesting)
Who cares? The fact is that most of the web is documents, not applications. Javascript performance is largely irrelevant when rendering Wikipedia or Google. So why does anybody care about its speed?
Re:How important are JavaScript times? (Score:5, Insightful)
Javascript performance is largely irrelevant when rendering Wikipedia or Google.
MediaWiki sites such as Wikipedia don't use a lot of JavaScript, but Google does. Google Search's live suggestion was one of the first applications of the paradigm now called AJAX, and Gmail is an outright web app.
Re: (Score:2)
Using the web as a platform for applications is adding a completely pointless, slow-performing layer on top of native APIs that companies have spent decades creating.
You have to be administrator to install a native application. You don't to use a web application.
Break room PC (Score:2)
If you're running a system that you're not an administrator on (i.e., a corporate desktop), chances are the web application you run would be an enterprise app that requires a username/password too.
Break room PCs at work: the employee has permission to visit any safe-for-work web site but not to install software. Children's accounts on family PCs and guest accounts on public library PCs are under similar restrictions.
Re: (Score:2)
Re: (Score:2)
Native APIs are not native across different platforms, so the browser offers a standardised abstraction layer on top of that..
Performance hasn't been terribly important for years, and developers are already coding in high level languages which have multiple performance killing abstraction layers between the user and the hardware.
Even those native APIs you talk about have over those decades been getting slower and slower...
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2, Informative)
Re:How important are JavaScript times? (Score:5, Insightful)
Re: (Score:2)
Performance is going to be an important differentiator in browsers, for how well they are able to run web apps
Well, that knocks Firefox out of the running. Slow as a snail, memory hog... I gave up FF for Chrome / Safari (WebKit) many moons ago. Until they get a handle on memory management and the speed of their JS engine, I'll not return.
Re:How important are JavaScript times? (Score:5, Informative)
I know nothing about cars so I can't give you a car analogy, sorry. However, javascript performance isn't very important at all unless "the page" really is a full javascript application ala gmail. The reason for that is that you delay the javascript execution until after the whole page has rendered by hooking up your code with the body onload event. This avoid the page lockups you can encounter on badly coded pages where the browser can't render the page before the javascript has been run to completion.
Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.
Re:How important are JavaScript times? (Score:5, Funny)
I know nothing about cars so I can't give you a car analogy, sorry.
You must be new here...
Re: (Score:2, Troll)
Of course, the above is only true if all the javascript on the page follows best practices. That is seldom true if the page includes javascript from ad networks which has the bad habit of running document.write calls during the loading of the page. Since document.write can modify anything on the page, when such a function call is executed, the browser has to stop everything else until the javascript is run and then continue rendering. In that scenario, faster javascript execution would definitely lead to much faster page loads.
And that's exactly why I use NoScript and white list only those pages that need JavaScript working. IMO the damn advertisers are the worst ofenders for using jscript wrong and I figure they can eff off and die because I've got no interest in supporting their business model.
Re: (Score:2)
Re: (Score:3, Interesting)
I don't know about you, but the only time a page doesn't load instantly is when it has large content waiting for data to come down through my Internet "Service" "Provider" or chew on some Javascript. I've never seen HTML take long at all, unless it's a 200k+ behemoth.
the times (Score:2)
Careful gramps, your age is showing. The page your currently is 131k - a little short of what you call a behemoth. Maybe you'd call it a Hydra, or at least an ogre's big brother.
Re: (Score:2)
This post might be more informative if you specified the speed of your connection. If you happen to live next door to a university, and have access to their fiberoptic trunk - you'll seldom wait for anything. I mean, can you download movies in less than a week? Less than a day? Less than an hour?
I can download an ISO in 12 to 20 hours, if I don't mind listening to the wife and kids bitching about the lack of internet on their machines. Throttling my download so that I don't have to listen to their bitc
Re: (Score:2)
I pay $30/m for Comcast Cable. Burst speeds do reach up to 1mb/s on occasion - real throughput seems to live around 300k/s to 600k/s.
Connection speed shouldn't make too much of a difference unless you have something like dialup, slow DSL, or a poor vsat link. Even then, those would be content downloads hanging it up, not text. Hopefully.
Re: (Score:2)
JavaScript performance is important because everything else is already so fast you won't notice. A web browser first needs to parse the [X]HTML to construct a DOM. Any reasonably fast computer is bottlenecked on I/O doing this, even with quite a poor implementation. Then it has to build a layout tree. Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen
CSS table layout (Score:3, Insightful)
Even pdftex, which produces nicer output than most browsers and runs incredibly slowly can do about ten pages a second of text-and-image layout and a web browser only needs to finish laying out one screen full quickly - anything off the screen just needs to be finished before the user scrolls that far down the page.
Not always. The layout of an element further down the page can have effects higher up the page. Think of a multiple-screen-tall element using CSS display: table with inner elements using display: table-row and display: table-cell. This can be either a <div> element using a grid layout or an actual <table>; the effect is the same.
Re: How important are JavaScript times? zero? (Score:3, Insightful)
How important are JavaScript times to the overall speed of rendering pages?
Try (ab)using Konqueror/KHTML as your primary/only browser for a month and you will soon get frustrated by simple things like the What You See Is What You Get on your blog software not working.
I personally do not give a damn about JavaScript performance. It matters zero to me. JS runs "fast enough" in all browsers.
It does matter a whole lot to me that the JavaScript on sites runs as expected.
I do not care if a piece of JavaScript does not work slow or fast.
Re: (Score:2)
I dunno, but when I ditched firefox years ago Konqueror was the first browser I went to. The reason? Page rendering times.
For whatever reason when opening multiple tabs firefox would occasionally go into la-la land and tab after tab would just end up frozen in a loading state (tabs that had rendered worked, new fetches were frozen). It was as if some thread held a lock keeping anything from doing anything. Then all the sudden they'd all load in rapid order (maybe 1-2 mins later). Yes, I checked the var
So the real question is (Score:5, Interesting)
Is work continuing on KHTML, and -- if so -- why? I mean, KHTML surely has some stuff going for it (it was the basis for WebKit), but it seems like there's a really clear winner.
Re:So the real question is (Score:5, Informative)
The speed changes in webkit are being backported to KHTML.
As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison [pcworld.com] on you.
Re: (Score:3, Insightful)
The speed changes in webkit are being backported to KHTML.
Is that the actual plan? At one time, I thought the plan was an "unforking" [arstechnica.com].
As to why, its always good to have choices and an alternate source in case someone pulls a Larry Ellison [pcworld.com] on you.
Oracle is wielding patents. If Apple decided to do that, then it wont make any difference if these are two projects or one.
Re: (Score:2)
Konqueror was a faster and more HTML/CSS standards compliant browser than Firefox, at least until Firefox 3.0 came out. It doesn't have the enormous mountain of resources Mozilla, Google and Apple do so it's been left behind since then.
Re: (Score:2, Informative)
Re: (Score:3, Interesting)
KHTML may live on (!) as System HTML renderer, help renderer, whatever renderer and for people who chooses stability/robustness over "web 2.0" things like most insane javascript performance ever!
Not just that, Webkit stuff comes to KHTML too. They could be just a bit conservative since they have a OS (yea, minus drivers and kernel) which runs happily on 3 different architectures which has nothing to do with each other.
You wouldn't want Konqueror to crash while you move critical files around with it, you kno
Re: (Score:2, Informative)
Is work continuing on KHTML...?
It seems so. Check this [blogspot.com].
So yesterday. (Score:2, Funny)
Firefox 4 Beta 2 is so yesterday, today Firefox 4 Beta 3 is all the rage.
Re:So yesterday. (Score:4, Funny)
Firefox 4 Beta 2 is so yesterday, today Firefox 4 Beta 3 is all the rage.
True: 4b2 is outdated. 4b3 is much more recent. And who modded him as funny? This is informative.
So you get fast JavaScript, but NO JAVA (Score:4, Informative)
My personal opinion is that all other written-for-WebKit browsers are better choices compared to Konqueror+kpart for those who want a browser with WebKit rendering at this point.
Re: (Score:2)
Honestly, I don't know why they put so much effort into maintaining Konqueror instead of helping to get rekonq up to speed.
http://rekonq.sourceforge.net/ [sourceforge.net]
Re: (Score:2)
ReKonq is just a browser.
Konqueror is an extremely flexible browser, file manger and document reader. It can browser remote file systems over ftp or ssh (OK, lots of file managers can do that, but not all). You can spilt views arbitrarily - so a vertical split can emulate an old-fashioned FTP app, but you can split within those views as well.
Re: (Score:2)
Yes, but in KDE 4 Okular is now the default document reader and Dolphin is now the default file manager.
It wouldn't be unprecedented for them to replace the default web browser with a better browser.
Even Konquerer developers have admitted the interface is less than optimal because it tries to be all things to all people.
Comment removed (Score:4, Funny)
Java applets have uses (Score:3, Insightful)
Well, that joke will eventually hit +5 funny but, let me tell what happened today.
Was in market for a end user VPN account, you know they really depend on your IP to their IP speed/path. The largest and known/old VPN provider for such use has made all speed tests in Java. As I was testing something on OS X 10.4.11 Tiger (read as: OLD) and Apple stopped updating Tiger long time ago, along with security updates, I don't dare to enable "applets".
So until the gcc451 test was finished, I was prisoned on that par
Re: (Score:3, Informative)
A little patience, please.
If you check the entries on the page that you're linking to, you'll find this - https://bugs.webkit.org/show_bug.cgi?id=33044 [webkit.org]
On that page, there are already some patches that have been submitted, although not yet reviewed and developer resources have been allocated
to having a deeper look at the issue of getting Java applet support working.
Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit b
Progress not so fast (Score:2)
A little patience, please... Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.
A WebKit kpart is not new; there's been one for some time -- I made a package [launchpad.net] of it in October '09 because the one in the kubuntu repositories was out of date, so it must have been around for some time before that. Many things didn't work back then. For example it didn't integrate with KDE's password saving system. It looks like that's related to the fourth bullet on the list xiando posted -- so that _still_ may not be fixed.
Don't get me wrong, I'm glad to see that they're making progress. However, this has
Re: (Score:2)
I've long been disappointed with Konq not moving more quickly to Webkit but I think this is a tipping point for them.
Especially now since KDE 4 has matured.
Re: (Score:2)
> Getting Webkit in is a big first step; the rest will come, in time, and quickly, I'm sure. I would expect to see a fully functional Konq+Webkit by this year's end.
Webkit has been "in" since KDE 4.3 or 4.4. I have been submitting bug reports like crazy and things have become a lot better. Yet, in 4.4.5 the Webkit Kpart degraded so badly that I had to stop using it altogether to stop Konqui Segfaulting after mere seconds of use.
The people who think they like Webkit will find out what the seperate thread
Re: (Score:2)
What, nobody has written a Java VM is JavaScript yet?
LAKE APPLET (Score:2)
Snow Applet is also very good.
Results for Firefox3.6,Chromium,Opera Ubuntu (Score:2, Interesting)
Firefox-3.5.9-Linux: 2331.6ms
Opera-10.61-Linux: 868.2ms
Chromium-6.0.492.0-Linux: 865.6ms
I would have posted links to the results but apparently there were too many non-letter characters per line (even with the links inside href attribs).
Re: (Score:2, Informative)
- Firefox 3.6: 1063.0ms +/- 4.9%
- Firefox 4.0b4pre (today's build): 622.6ms +/- 12.0%
These are with the same engine, btw. Jaegermonkey is not in nightly builds yet.
It doesn't take much more to make you bound to DOM operations in normal webapps.
PS: sunspider 0.9.1 is also available
Really? (Score:2)
Re: (Score:2)
No, I think you have been misinformed. No one is still using Konqueror because no one ever used it in the first place. A lot of us linux users prefer Gnome to KDE, and even a ton of us who use KDE insist on something more "mainstream," like Firefox, Chrome or Opera, which are all better options, in my opinion. Konqueror's overall penetration of the web browser market is probably negligible, as its influenc
NASCAR (Score:3, Insightful)
this just in: (Score:2)
Re:What the frak is Konqueror? (Score:5, Informative)
It is the default browser in KDE, unless your distro changed it to Firefox. If you use Gnome, or OSX or Windows, you probably won't get to see it.
Re: (Score:2)
You mean KDE 4.5. will not be provided for these platforms? Wasn't there a porting project?
Re: (Score:3, Informative)
KDE 4.x already available on Windows, and probably on OS X as well (never tried). The first ports of Konqueror were pretty weak, but these days it works nicely enough. I wouldn't call it a must-have program on Windows, but if you like the KDE apps (ark, kate, and amorak are some others that I like) then you can get them from http://windows.kde.org/ [kde.org] (it includes a package manager for updating, which is really nice). It looks like the current version is KDE 4.4.0.
Re: (Score:2)
Hmm, I already knew about Konqueror, but thanks for your second sentence - I now finally see one advantage to using Windows!
Re: (Score:2, Insightful)
it is the predecessor of webkit. webkit was forked from konquerors html rendering engine.
Re:What the frak is Konqueror? (Score:5, Informative)
Everybody is all friendly again, but some have long memories
And some have very faulty memories:
Kong (KHTML) was ripped off by Apple,
KHTML was forked by Apple.
and they began the work on webkit as a closed source project
They worked on it internally, more-or-less secretly until the first version of Safari, when they released their code at the same time they shipped the binaries.
After some serious (legal) prodding,
After a number of KHTML developers bitched publicly.
Apple finally did the right thing and returned their changes to the community
Apple moved development into public svn rather than providing large (and difficult to merge) patch drops with each release. They also began soliciting external contributions from companies like Nokia, Adobe, and so on, as well as from the wider community.
Re: (Score:2)
And the rest of the story is that Webkit went on to become the fastest library on the planet, adopted into pretty much every toolkit and platform currently known to man [webkit.org] (scroll down to "webkit ports"), including Chrome and Android.
The whole thing started because the KDE guys didn't want to use Gecko in 1998
Re: (Score:2)
excellent response
Re: (Score:2)
Re:What the frak is Konqueror? (Score:5, Funny)
It's what spawned Webkit; which in turn is the most mature modern browser engine available on current Amigas, you know...
Re: (Score:2, Informative)
People think you're joking but here's what wikipedia says:
"There is also a project synchronized with WebKit (sponsored by Pleyo) called Origyn Web Browser, which provides a meta-port to an abstract platform with the aim of making porting to embedded or lightweight systems quicker and easier.[37] This port is used for embedded devices such as set-top boxes, PMP and it has been ported into AmigaOS 4.1 for PowerPC, AmigaOS 3.9 for Classic 68000 machines, AROS and MorphOS."
Re: (Score:2)
Well, it was mostly just @GP & his sig; apparently still a bit into Amiga, and haven't heard about the browser which, ultimately, some time ago gave that platform (or rather a group of them) a modern browsing experience?
Re: (Score:2)
I'll bet you haven't tried Midori browser either, then. twotoasts.de In my own informal testing (read, not disciplined in any manner, just diddling around) Midori was the FIRST browser to score 100 on the Acid3 test, and it's also the fastest GUI browser.
It's not my browser of choice, for two reasons - 1, it does break from time to time and 2, it lacks the customizations of Firefox. Also, Midori doesn't seem to be real happy on a system with any other Webkit engine installed.
Still - you should look at Mi
Re: (Score:2)
Wow! A single informative sentence.
Indeed that is the issue and we are happy that KDE 4.5 is out.
Re:Not a useful comparison (yet) (Score:4, Insightful)
JaegerMonkey is making steady progress in improving performance and in a couple of months or so will likely be on par with Nitro and V8.
You mean, in several months Mozilla will be approaching the level that Google is at now. It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.
Also, Opera is faster than Mozilla as well, I'd like to see it included on that chart to compare with the others. Maybe even IE9, if it doesn't skew the Y-scale too much.
Re: (Score:2)
Maybe even IE9, if it doesn't skew the Y-scale too much.
Last I checked, IE9 was faster than Firefox 4 beta by a substantial margin, and has in fact also passed Safari 5 (WebKit-based, of course). Chrome and Opera are still very slightly ahead, but not by much.
http://ie.microsoft.com/testdrive/benchmarks/SunSpider/Default.html [microsoft.com]
Re: (Score:2)
Comparing Mozilla resources to Chrome? Why not compare them to IE? Makes as much sense.
IE and Chrome are corporate browsers owned and developed by large corporations.
Konquerer, Firefox and Opera are not.
Re: (Score:2)
I'm beginning to think all this talk about which browser is faster,and by how much, is really kind of pointless. I'm not a gamer and don't use bleeding-edge hardware, though I retired my 386sx before ever venturing onto the internet, and since Firefox was first released, I've never thought it was too slow. Maybe some of the others are fa
Re: (Score:2)
At the bottom of the fine article is a link [digitizor.com] to a previous benchmark they ran between opera 10.6, chrome 5, chromium 6, and firefox 4 beta 1.
In the sun spider test, Chromium 6 is fastest, opera second, and firefox 4 last - but the difference is fairly narrow, apart from firefox which is heavily beaten.
In the V8 test, chromium 6 beats all, and chrome 5 edges out opera. Firefox 4 again is beaten heavily.
Yes, jaegermonkey will make a big difference to mozilla performance - but given the rate chrome 6 is better
Re: (Score:2)
It's become pretty clear that Google is able to develop Chrome much faster than Mozilla is able to develop Firefox.
And yet Chrome (or to be more precise, webkit) still doesn't support MathML. No wonder Chrome seems to develop faster if it's support for W3C standards is narrowed down. Plus, Chrome doesn't maintain it's very own rendering engine but uses one that's supported by at least one other major browser vendors.
Re: (Score:2)
But according to Wikipedia, it was first released in September 2008. It took until January *2010* for them to implement a freakin' extension system.
To be fair, the time between Phoenix 0.1 and Firefox 1.0, when the extension system was implemented, was 25 months, longer than the 16 months it took Google.
No, I think its more accurate to say Chrome has just had a lot further to go, and so their pace of development looks impressive when compared to an established project like Firefox.
The impressive part is that Chrome has managed already to beat Firefox in several areas, even though Firefox has a head start of 6 years and has been actively developed for all 8 of its years.
Re: (Score:3, Insightful)
The impressive part is that Chrome has managed already to beat Firefox in several areas
In a few areas, yes, and only because they could benefit from the many years of experience gathered in the development of web browsers. When Firefox first hit the scene, a JITing JS engine wasn't even a consideration, as top-notch JS performance simply wasn't that important. The same goes with things like tab and plugin isolation, etc.
I mean, don't get me wrong, Chrome is a very nice piece of work, and Google has the ad
Re: (Score:2)
In a few areas, yes, and only because they could benefit from the many years of experience gathered in the development of web browsers.
Well.. that's kind of like saying that the only reason they're ahead is because they have more and better programmers. In the top 5 browsers, Firefox's Javascript engine is fighting with IE for 4th place.
It's probably just the case that Mozilla has focused on things other than Javascript, where Google has a very real need for a browser that can handle large Javascript applications quickly. The two orgs just have different priorities, but I do think that Google is working very quickly, maybe even quicker t
Re: (Score:2)
Admittedly it's not even in beta yet, but I think you sorely misunderstand the improvements that IE9's JavaScript engine has made. It's more accurate to say that it's clawing with Safari for 3th place, and as of the most recent preview it's winning. Firefox has been left far, far behind. Opera and Chrome are still ahead, but it's down to less than 100ms difference between IE9 and Opera 10.6.
Re: (Score:2)
That may be true, I haven't looked at IE9 numbers in a while and I don't yet have a machine that can run it.
Re: (Score:2)
It's also worth considering that both Chrome (via WebKit) and Firefox have come from even older beginnings. Konqueror, and KHTML, is probably not as old as Netscape and Gecko, but neither modern browser (Firefox or Chrome) is using an engine that was created from scratch.
Re: (Score:3, Informative)
Chrome uses Webkit!
Apple Safari uses Webkit!
Nokia uses Webkit!
KDE Konqueror uses Webkit, in fact it was invented by them under the name KHTML.
So imagine that KDE's Konqueror will benefit from Webkit progress, now that they support webkit along KHTML
Re: (Score:2)
No. I mean in a couple of months Mozilla's JavaScript engine will likely match Google's. In several months Mozilla's engine may have surpassed Google's.
Are you assuming that Google is going to stop developing Chrome, that Mozilla is going to manage to reverse the trend and significantly outperform Google, or that we have reached the pinnacle of Javascript engines with V8 and no further development is possible?
Re: (Score:2)
V8 has gone about as far as it can go with its current approach. Google needs to start exploring alternative approaches to improve V8 further.
I agree, do you think they're not going to do that? I don't think they're going to let their Javascript engine of all things become stale. Mozilla has made impressive gains, but they started so much higher and still have a lot of work to do.
Re: (Score:2)
That's an interesting demonstration, but the topic under discussion is Javascript performance, not HTML5 rendering speed. Considering YouTube's usage of HTML5, I think it's likely that Google will begin investing more into the HTML5 development side of Chrome than they have in the past, and seek to gain the same type of performance increases that they have achieved with V8. I would, however, like to see a version of that test with each browser running individually in fullscreen or maximized. It may be th
Re: (Score:3, Funny)
You need to getting laid.
Re: (Score:2)
Why not use google's javascript engine. Isn't it the fastest? Open source too...
Actually, it looks like Opera is *still* faster than Chrome, even the nightly builds. Consider the data on this page (last updated a week or so ago). Yes, it's focused on IE9, but MS has no reason at all to try and make Opera look better than it is. http://ie.microsoft.com/testdrive/benchmarks/SunSpider/Default.html [microsoft.com]
Re: (Score:3, Insightful)
v8 only runs on ARM and x86.
That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?
Re: (Score:3, Funny)
v8 only runs on ARM and x86.
That's because the market has chosen to give a care only about these instruction sets. Can you name a computing product sold this month that 1. runs a web browser, 2. isn't marketed primarily as a video game console, and 3. uses something other than ARM or x86 as its primary CPU?
x86_64 :P
Re: (Score:2)
You jest, but this is a decent point; while the thought of a web-app that can use more than 4GB of RAM at once is frightening, it's not terribly unlikely that browsers will start moving to x64 in the next few years. IE is already available in both architectures, and I think Firefox is too. Konqueror definitely is. Not sure about Safari or Chrome, and I don't think Opera is. Nonetheless, 64-bit is the direction of the future.
Speaking of which, there are still Itaniums out there being sold and used. Admittedl
Re: (Score:2)
I think Firefox is too
This reply is posted with a x64 version of a nightly Firefox 4.0 (pre-b4) build.
Re: (Score:2)
TV set-top boxes are traditionally MIPS. Lots of them have web browsers in them these days (albeit limited, crappy ones).
Re: (Score:2)
Actually - Firefox's strength hasn't been speed for quite some time. It's that ADDONS and personalizations that make fans now. Back in the day, Firefox was blazing fast when compared to IE. But, even IE has evolved since then.
Re: (Score:2)
Would you consider breeding your ass with some nice quarterhorses? I'll split the profits I make when we start burning the barrels up at the rodeos!
Re: (Score:2)
OMG, yer so funny! Or you would be, if Firefox didn't have the biggest share of the browswer market aside from M$ IE, 23%-35%, depending on who you believe. That's quite a bit more than Chrome, Safari, Opera and Konqueror combined. And Firefox has increased its market share every calendar year since it came out, perhaps with the exception of this year. But yeah,no one uses it, lol
Re: (Score:2)
\
And Firefox market share since 2005:
/
(Note that the trends are correct, though not to scale.)
Re: (Score:3, Informative)
If beta 3 has been out for about a week?
It wasn't. Beta 3 was released on the 11th, the article was published on the 12th.