I see on your latest blog you’re using Firefox on your MacBook. I had to give up Firefox on the Mac after using it for years because it used so much CPU all the time! It was making the computer so hot I couldn’t use it on my lap. The fans ran all the time and that was so loud it annoyed me constantly.

I switched to Safari. I miss some of its features, especially “Re-open the last closed tab”, but at least now my computer doesn’t burn me and it’s quiet. And of course that means the battery lasts a lot longer too. It’s too bad that Firefox is so bad on the Mac, because I’d much rather use it than Safari.

One thing you can do if you really want to use Firefox is install the Flashblock add-on. Flash is the worst offender for CPU usage in the browser, it could be it’s the cause of most of the CPU usage. With Flashblock, embedded Flash requires a click to be loaded into a web page.

https://addons.mozilla.org/en-US/firefox/addon/433

Now that I use Safari I use ClickToFlash which does the same thing.

http://rentzsch.github.com/clicktoflash/

Another Firefox add-on I installed before giving up on Firefox was TooManyTabs. If you have a lot of tabs open in Firefox, it uses a lot of CPU and memory (on all platforms). TooManyTabs lets you keep the tabs visible but doesn’t keep the pages loaded.

https://addons.mozilla.org/en-US/firefox/addon/9429

Comparing a netbook to a notebook is an apples-to-oranges comparison (no pun intended). Netbooks have low-power components like Atom processors and weak integrated graphics. They’re designed to use much less power, and don’t run nearly as fast. You might not notice the performance difference if you’re just browsing and editing. Netbooks screens are smaller, not as bright, and thus don’t require as much power. So of course your netbook has better battery life.

Saying a MacBook has bad battery life because it doesn’t keep up with your netbook is just silly. It’s like complaining how much gas your SUV guzzled driving to LA compared to your Mini cooper. All I’m saying is if you want to drive your SUV and save some bucks, keep the speed down and don’t run the AC constantly.

I’m really amazed at how ornery you are!

Give it up Jim, no one cares what either of us thinks.

If your netbook is running Mac OS X, the difference in battery life would then likely being attributable to the difference in processors – a low-power Atom processor vs a Core 2 Duo. Of course, in that case you could still have even better battery life by running a native app.

GPL or otherwise.

That said it would be great if we had a universal binary.

Maybe you could try to be a little less personal about it. You know the app was released under the GPL in 2004, five years ago. If there’s no universal binary, it’s pretty unfair to blame me for it. But you’ve always like to blame me for all the ills of the world right?

In checking the 18 links that were on my weblog-roll in July of 1999, half of them are still going strong as of this month, and a few more have had posts within the last six months. A few more are moribund but there, and a few others gone into 404-land. Not bad, though.

Rogers always said that Fido is for lower revenue customers and Iphone should not be offered in the future with Fido.”

quotes taken from a telecommunications message board – http://www.howardforums.com/forumdisplay.php?f=431

Personally I’ve been with FIDO for 7 years, my avg monthly bill when I had the iPhone 3G was $110/month. CityFido (grandfathered plan) $45 + 100 Can/USA LD $5.00 (grandfathered) iPhone 3G data plan $30/6GB + iPhone $15 value pack = $101.95 before taxes.

You should also know that there are two new wireless companies opening up in Canada late August 2009/early 2010 that will be competing against the big 3 Rogers/Fido, Telus & Bell.

if you’ve already moved to Rogers, expect to pay more in the long run.

> What do you mean by “the JVM’s scaling limitations”?  The JVM
> has had more work put into scalability than any other general-
> purpose application platform in existence, and Scala is pretty
> much purpose-designed for message processing.

The fact the JVM has required more scalability work put into it than
any other general-purpose application platform in existence should
give you an idea of how unsuited its original design was for
scalability. Something designed with performance and scalability in
mind does not need so much effort.

And Scala is NOT purpose-designed for message processing. Don’t
believe the hype, the marketing. I have actually done research on
Scala’s messaging library. I implemented a concurrent system in
Erlang, Scala, Io and Rubinius and compared their implementations,
performance and scalability. Scala’s performance and scalability were
terrible. As far as its implementation goes, go ahead and read it for
yourself. You’ll see there’s nothing mindblowing there at all. It does
not even begin to compare to real messaging systems in terms of
robustness.

I don’t dislike Scala, as a language it has some neat stuff, but
people have just accepted the hype because they aren’t versed enough
in this stuff to form their own opinions, I mean, it looks really
great because it’s so damn complicated, it’s almost like Haskell it’s
so fancy. That doesn’t make everything about it (ie: their Actor
library) equally awesome.

> The comments on this post <http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html>
> include several from people who work on, or consulted for,
> Twitter, and satisfied me that they did a pretty thorough job
> of evaluating their options and in fact that Kestrel /Scala
> coming out on top was unexpected.

They also said: “Starling is quite possibly one of the slowest and
most poorly designed message queues in existence.” And yet it was
Twitter that created it.

> Given their intended path to incrementally rewrite the unreliable
> bits, the success they’ve seen with Kestrel, and improving
> Twitter reliability in the face of ever-growing load, I’m inclined
> to trust what they say.

When was the last time Twitter actually added a significant feature?
All they do is take away features because they can’t keep up with
growth. Look at all the sites that are using Twitter to enhance the
UI, tweetree.com for example. If Twitter had the capacity in their
servers they would add nice UI features like that. But every extra
piece of data they put on their pages complicates their
caching/performance/scaling situation even more, so the site and API
stagnate and regress.

Sorry I didn’t reply right away, believe it or not I rarely look at
this list because people almost never reply.

Jim

What do you mean by “the JVM’s scaling limitations”? The JVM has had more work put into scalability than any other general-purpose application platform in existence, and Scala is pretty much purpose-designed for message processing.

The comments on this post include several from people who work on, or consulted for, Twitter, and satisfied me that they did a pretty thorough job of evaluating their options and in fact that Kestrel /Scala coming out on top was unexpected.

Given their intended path to incrementally rewrite the unreliable bits, the success they’ve seen with Kestrel, and improving Twitter reliability in the face of ever-growing load, I’m inclined to trust what they say.