用来阅读Bloglines的脚本

~/.torsmo/bloglines.sh

#!/bin/bash
#run this in crontab
#remember 'chmod go-r bloglines.sh'
#jan.h.xie@gmail.com

USER="YOUR_ACCT@gmail.com"
PASSWORD="YOUR_PASS"
XMLFILE="http://rpc.bloglines.com/listsubs"
LOCALXML="/home/jan/.torsmo/bloglines.xml"

wget --http-user=$USER --http-pass=$PASSWORD -O $LOCALXML $XMLFILE
＃shit ZJU network
until [ -s $LOCALXMLFILE ]
do
   wget --http-user=$USER --http-pass=$PASSWORD -O $LOCALXML $XMLFILE
done

~/.torsmo/bloglines.pl

#!/usr/bin/perl
## bloglines.pl: used to extract info from bloglines.xml

use XML::Simple;
use Data:umper;

$#ARGV+1 == 1 or die("Usage: [perl] bloglines.pl [time|name|news]\n");

my $xmlfile = "/home/XXX/.torsmo/bloglines.xml";
my $xml = XMLin($xmlfile);
my $totalfeeds = 14;

#for debug
#print Dumper($xml);

if($ARGV[0] eq "time") {
   print $xml->{head}->{dateCreated}."\n";
}
elsif($ARGV[0] eq "name") {
   print $xml->{head}->{ownerName}."\n";
}
elsif($ARGV[0] eq "news") {
   for($feed = 0; $feed < $totalfeeds; $feed++) {
       my $title = $xml->{body}->{outline}->{outline}->[$feed]->{title};
       my $unread =
$xml->{body}->{outline}->{outline}->[$feed]->{BloglinesUnread};

       if($unread > 0) {
           #truncate title
           if(length($title) >= 24) {
               my $temp = substr($title, 0, 24);
               $title = $temp."...";
           }

           #table output
           $title = $title." "x(36-length($title));

           print " ".$title.$unread." unread\n";
       }
   }
}
else {
   die ("Wrong argument. try one of {time, name, news}.\n");
}

这里同样用到了XML:Simple. Dataumper是用来做debug的，如果要自己写一些用到
XML:Simple的脚本的话这是个很好的辅助工具，如果只是用我的脚本的话不需要装这个
lib, 把use Dataumper那一行注释掉就可以了

Eugenia Loli-Queru同志在Gnome的支持论坛发了一帖，请求开发者们举行一次投票来看看Gnome用户们有哪些需求，然后选择的实现其中的某些需求。可是让他郁闷的是他得到了一封不近人情的回复:

"regarding market research, we care about it only when happens from our marketing department and to our customers"

的确是让人恼火。这种完全背离开源本质的回答让人失望之极。如果开源软件的开发者们以这种态度面对用户，开源的优势将会荡然无存。

To make it clear: I am not against Open Source Software, in fact, I am for it. But I am increasingly frustrated with Open Source software written by hobbyists; hobbyists who write a specific application or library because they need a specific function out of their applications, for their own needs and only their own needs. Here's what happened:  
A few days ago I was in the middle of a cyclone in the desktop-devel-list gnome mailing list asking the gnome devs to include the Gnome users in the process of evolving Gnome (because currently feature requests are getting very much ignored on their bugzilla). I just wanted the Gnome users to be asked (whatever the way, not just by using a poll) what are their most needed features and having the Gnome devs implement the ones that makes sense to implement. This way, more users would be happier about the apparently "closed" nature of Gnome's development.

I got the answer I expected from the Novell/Sun/Red-Hat people: "regarding market research, we care about it only when happens from our marketing department and to our customers". They don't care about the "generic" Gnome user. That's ok. Understandable. These guys have a business to run.

However, I was not happy from the answer I got from the Gnome developers who don't work for a Gnome-related corporation:

"A feature will be implemented if and only if there is a developer who wants to implement it" (it was later mentioned in the discussion that this is if the developer actually has such a need himself for the feature).

I do not like or agree with the above statement, because I see software as simple tools. Only good tools can ultimately succeed. And I want Open Source to succeed.

Tools are meant to do what people need to do (integrating them after careful consideration without bloating the platform, of course). If the Gnome devs completely cut off their users in such a way, I see no reason why anyone would would still want to run Gnome. Their voice would never be heard because the corporate developers don't care about their kind, and the hobbyist developers don't care anyway. And that's the reason why many Gnome users left the platform over the past 2 years: closed development cycle. There is a real community problem here, and the thing is, the gnome devs pretty much agree that there is one but they don't seem to care to do something about it. For example, the No1 Gnome feature request, a menu editor that actually works properly, is still not realized after so many years. And the decision for the spatial Nautilus that created an uproar to the Gnome user community (users had to wait 6 months to get a checkbox on the preference panel to get back to the Classic View instead of having to go dirty with GConf) was pretty much taken single handedly by Red Hat.

Sure, not every developer is like that. There are many other OSS developers who actively ask for feedback. On GnomeFiles.org I see third party GTK+ developers asking for feedback almost everyday, and as a user, this really makes me feel good about their applications. But that's not the norm and definitely not the norm with Gnome. Open source devs generally only code whatever they personally need, and that's a huge difference from a commercial application where the "customer" is being asked repeatedly what features he/she needs in the application.

You may argue that in the second case you pay real money to get such support, but in my book, engineering is engineering. In our article yesterday about "The Ten Worst Engineering Pitfalls" by Keith F. Kelly, on the No2 spot you will find this: "2. Basing the design on your own motives rather than on users' needs." So, no matter if something is developed for OSS or for commercial reasons, the principle of engineering remains the same, because in both cases, the software is released out there to be consumed by [innocent] people. So in both cases, there is some responsibility on what the user would expect out of a given application and in the case of Gnome, there are a few millions of users that developers should take into account. If these developers really don't want user feedback, they should close down their bugzilla, stop offering their software freely (only use it for their own needs), stop sending press releases out and stop asking for donations on their front page. It's as simple as that.

If the "plain user" entity in the OSS world is such a taboo why the hell would I want to use OSS software? Just because the code is open? I don't personally have any real use for the source code (and most normal users don't either). I don't do C anymore (in the case of Gnome) and I can't possibly pay 0-200 per hour to a consultant to add features for me. All that "the source code is open, send me patches" it's all looney-baloney for the vast majority of users. However, I wouldn't mind at all paying about per year to a big project like Gnome, but get assured that users aren't cut off from its development process (the current donation scheme does not take care of this).

Red Hat's Havoc Pennington & Novell's Jimmac suggest that users write an analysis and test cases of a feature request the user wants to see implemented, because this way you might get the developer motivated to actually implement it. The problem I see with this is two fold:
a. Not many people have a clue how to write a test case or use Gimp/Photoshop to create a mockup to illustrate their point. They can only quickly describe what they need, and that's that.
b. Normal users don't use bugzilla. Only power users & developers do. Besides, no one likes spending time to register.
It's the project itself that needs to do the right moves to reach its audience and take a pick on their problems, not the other way around. For example, Apple has a very simple feedback page on their web site that doesn't require registering (as opposed to bugzilla which is very technical and requires extra thinking) where "normal" users can send, well, feedback. Apple developers use Apple's bug reporting page on their developer's sub-site, but plain users just have a form with few straight-forward fields to write down their gripes. Problem is, OSS developers don't like anything that's not filed on their bugzilla ("if it's not filed, it doesn't exist" they say), but point of the matter is, the user should be the center of attention and incovenience-free, not the developer.

What I like to see, is some market research. Approach all kinds of users, put their gripes in line, make a note of their features they really need and evaluate them. Then, create a project plan and distribute the tasks that need to be done to your developers and make sure they deliver what they must deliver. People will say "that's not how OSS works", but as a user, I don't really care how OSS works. I care about using software that's been properly developed taking users into account rather than purely developers' needs. Be careful: I am not asking the OSS developers to implement every little thing that's asked out there, I am asking them to simply take users into account and get an idea of what the whole of their userbase needs. Extracting useful information from the mass will be difficult, but it is achievable if the right resources & infrastructure are into place.

I personally find it "deteriorating" for any user to use Open Source software made from such 'lone' developers and not by a company which specifically asks for feature requests or does market research. It would be like the user does not respect him/herself by using a tool that does not do all it could do or all things the user needs it to do (please note: that's in the cases where the application indeed does not do everything the user needs -- other OSS software are really rich already, e.g. emacs, apache, postgresql etc).

To me, software is a tool, nothing more. I am as practical as it goes when it comes to computers. I don't idolize them and I don't have a political ideology about software or hardware (and in fact, I personally take pity to anyone who does -- there's more important things in this world than to be political over bits and bytes).

If something is open source, that's cool, it's a meta-feature that the closed source apps don't have, and I welcome it and I embrace it. But when it comes to software written by hobbyists who don't want to implement anything apart from what they personally need, and systematically ignore their users (apart for their crashing bug reports, which is the only thing that they seem to need them for), I refuse to use that software, because I respect myself and my choices. I prefer to shed down the right money for the right commercial software (open or closed), than to use half-baked, half-implemented OSS software made by deaf developers.

While this might not be a huge problem for small time applications, it is a big problem when a project that's used by millions has the same attitude towards its users. It's disappointing, to say the least.

IBM正在进行一项研究用于恢复系统崩溃的PC机。研究成果可以让PC机通过任何个人数字设备启动，并运用新开发软件的各种系统工具来恢复一个崩溃的系统。这项研究最令人惊奇的地方是它能够把任何个人数字设备，包括iPod, usb stick甚至手机改造成一张功能强大的启动盘。这将会给硬件发烧友提供莫大的方便。这项技术是基于linux平台的。

March 04, 2005
"Blue Screen of Death" Rescues With Personal Devices
Now that the cat's out of the bag, I can point people to something cool we did in our group at IBM Research. What I am referring to was demonstrated at IBM PartnerWorld 2005 a couple of days ago in Las Vegas, calling it a "personal jumper cable" to counter the "Blue Screen of Death" on PCs.

In a pinch, the Linux-based technology "transforms" a personal device, such as an MP3 player, a USB pen, or even a cell phone, into a powerful "Rescue and Recovery" device that can be used for things such as:

Booting a PC "from" the personal device
Accessing data from the PC's unbootable drive
Accessing specific backups located on the personal device
Providing an emergency productivity environment (e-mail, Lotus Notes, web, ...), even if the PC's drive is completely dead
Rebuilding the PC's drive
More ...
An iPod mini was used in the PartnerWorld demonstration.

I think it's cool because we are packaging all this functionality into personal devices that people won't find a chore to carry around, and in many cases, already carry around. Moreover, the original purpose of the personal device is unaltered. For example, if it's an MP3 player, it will remain so.

I've seen the software been described as "IBM One-touch Rescue & Recovery On Linux" in the press.

Some relevant links [updated]:

TechWorld Coverage

Breaking News @ CRN | IBM Software Performs BSOD Rescues

Webcast Containing the Demo (the demo is approximately 25 minutes into the webcast)

Posted by amit at 12:24 AM

下面是我用来看天气预报的脚本, 改自Gentoo Forums [http://forums.gentoo.org] 上的
同名脚本 ;p

~/.torsmo/forecast.sh

#!/bin/bash
# forecast.sh
# Run this in your /etc/crontab

# FIND YOUR LOCID
# ---------------
# First go to: http://xoap.weather.com/search/search?where=XXXXX
# The "XXXXX" can be anything you are searching for, such as zip code, city,
state, or country.
# After loading that web page up you should have a search returned with a "loc
id".
# The "loc id" will be used for your # weather.

DAYS="4"
LOCID="CHXX0044"
PARTNERID="1003666583"
LICENSEKEY="4128909340a9b2fc"
XMLFEED="http://xoap.weather.com/weather/local/"

XMLFILE="$XMLFEED$LOCID?dayf=$DAYS&prod=xoap&par=$PARTNERID&key=$LICENSEKEY&ut=C
"
LOCALXMLFILE="/home/XXX/.torsmo/forecast.xml"

wget -N $XMLFILE -O $LOCALXMLFILE
#I add this loop since the net condition isn't very well in ZJU
until [ -s $LOCALXMLFILE ]
do
   wget -N $XMLFILE -O $LOCALXMLFILE
done

~/.forecast.pl:

#!/usr/bin/perl
## forecast.pl

use XML::Simple;

my $xmlfile = "/home/XXX/.torsmo/forecast.xml";
my $xml = XMLin($xmlfile);

my $numArgs = $#ARGV+1;
my $arg = $ARGV[0];

if ($numArgs == 1) {
   if ($arg eq "updated") {
       print $xml->{dayf}->{lsup} . "\n";
   }
   else {
       print $xml->{loc}->{$arg} . "\n";
   }
   exit;
}
elsif ($numArgs == 2) {
   my $day = $ARGV[0];
   my $info = $ARGV[1];
   if ($info eq "condday") {
       print $xml->{dayf}->{day}->[$day]->{part}->[0]->{t} . "\n";
   }
   elsif ($info eq "condnight") {
       print $xml->{dayf}->{day}->[$day]->{part}->[1]->{t} . "\n";
   }
   else {
       print $xml->{dayf}->{day}->[$day]->{$info} . "\n";
   }
   else {
       print $xml->{dayf}->{day}->[$day]->{$info} . "\n";
   }
}

XML:Simple是一个简单的XML Parser, Gentoo上有ebuild, 其它发行版的用户可以上CPAN
上找到.

torsmo是一个类似于gdesklets的软件。在我的桌面上右边那个用来显示gmail/bloglines/weather的工具就是 torsmo. 我将会贴出一系列文章来说明torsmo的配置方法。简单的配置我就不说了，.torsmorc里面有很好的注释. 我想要说的是如何定制适合自己的个性化的torsmo.

torsmo的灵活性非常强，通过和定制脚本的配合可以做成许多事情。这里我贴出自己用的
几个脚本。我把这些脚本都放在~/.torsmo里面，而.torsmorc是~/.torsmo/torsmorc的一
个软链接。

首先是检查Gmail的新邮件信息的脚本，如果有新邮件，还可以显示出邮件标题。

~/.torsmo/gmail.pl: 通过Gmail的API得到邮箱状态信息

#!/usr/bin/perl
## gmail.pl

#find this two lib on CPAN
use Mail::Webmail::Gmail;
use GMail::Checker;

my greatest_ = "YOUR_ADDR"; # your Gmail username
my $password = "YOUR_PASS"; # your Gmail password
my $gmailfile = "/home/XXX/.torsmo/gmail.txt";
my $newmessages = 0;
my @subjects = ();

my $gwrapper = new GMail::Checker();
$gwrapper->login(greatest , $password);

my ($totalmessages, $usedspace) = $gwrapper->get_msg_nb_size();
$gwrapper->close();

my $gmail = Mail::Webmail::Gmail->new(username => greatest , password =>
$password, encrypt_session => 1);
my ($usage, $capacity, $usagep) = $gmail->size_usage();
my $messages = $gmail->get_messages(label => $Mail::Webmail::Gmail::FOLDERS{
'INBOX' });

foreach ( @{ $messages } ) {
   if ( $_->{ 'new' } ) {
       $newmessages += 1;
       my $subject = $_->{ 'subject' };
       $subject =~ s/<(.*?)>//gi; # remove tags
       push(@subjects, $subject);
   }
}

open(FD, "> " . $gmailfile) or die("Could not open file.\n");
print FD "totalmessages=" . $totalmessages . "\n";
print FD "newmessages=" . $newmessages . "\n";
print FD "status=Using " . $usage . " (" . $usagep . ") of " . $capacity . "\n";
for($i=0; $i<=$#subjects; $i++) {
   print FD $subjects[$i] . "\n";
}
close(FD);

~/.torsmo/gmail_extract.pl: 提取信息的脚本，为torsmo所调用

#!/usr/bin/perl
# gmail_extract.pl

my $numArgs = $#ARGV+1;

if($numArgs != 1) {
   die ("Usage error: gmail_extract.pl [info]\n");
   exit;
}
else {
   my $file = "/home/XXX/.torsmo/gmail.txt";
   my $arg = $ARGV[0];
   open (HANDLE, $file) or die ("Could not open file.");
   @LINES = ;

   if ($arg eq "newsubjects") {
       $line = $LINES[1];
       my ($foo, $newmessages) = split(/=/, $line);
       if($newmessages > 0) {
           for($i=3; $i<=$#LINES && $i < 12; $i++) {
               my $num = $i-2;
               my $sub = $LINES[$i];

               # truncate long subjects so it will not
               # autoexpand the tormso window
               if(length($sub) >= 40) {
                   my $temp = substr($sub, 0, 40);
                   $sub = $temp . "...\n";
               }
               print " " . $num . ". " . $sub;
           }
           if($#LINES > 11) {
               print " Check mailbox to see more ...";
           }
       }
   }

   # how many total message do I have?
   if($arg eq "totalmessages") {
       $line = $LINES[0];
       my ($foo, $total) = split(/=/, $line);
       $total =~ s/[\r\n]//g; # remove \n
       print "There are " . $total . " messages\n";
  }

   # how many new messages do I have?
   if($arg eq "newmessages") {
       $line = $LINES[1];
       my ($foo, $new) = split(/=/, $line);
       $new =~ s/[\r\n]//g; # remove \n
       if($new == 0) { print "There are no new messages\n"; }
       elsif($new == 1) { print "There is one new message\n"; }
       else { print "There are " . $new . " new messages\n"; }
   }

   # usage status
   if($arg eq "status") {
       $line = $LINES[2];
       my ($foo, $retval) = split(/=/, $line);

   # usage status
   if($arg eq "status") {
       $line = $LINES[2];
       my ($foo, $retval) = split(/=/, $line);
       print $retval;
   }

   close (HANDLE);
}

On Compaq Presario 2804sc:
P4m 1.6GHz - 756 DDR - ATI Raedon 7500 Mobility 64M - 5400rpm 40G Hard Disk - 14'' LCD - Intel Pro/100 VE

XFCE4 + root-tail + torsmo:

在一场激烈的口水仗之后，Mozilla Foundation终于发表了最后决定：Mozilla Suite 1.7将是这个系列的最后一个版本，以后的升级也都只会是这个版本的一些小变动。声明中提到:

1. 1.7.x将会是最后系列，Mozilla Foundation将会为那些有兴趣参与1.7.x发布的开发者提供基础设施以便于他们进行工作。
2. Mozilla Foundation将为那些愿意继续开发Seamonkey(Mozilla Suite的开发代号)的志愿者提供必要的基础设施(包括CVS, bugzilla, 开发工具等等)

Mozilla Suite是Firefox和Thunderbird的母亲。随着这两个孩子的一天天壮大，母亲也已经老了...

Mozilla Application Suite - Transition Plan
March 10, 2005

In 2003 we announced our intention to shift development focus from the integrated Mozilla Application Suite (commonly referred to as "Seamonkey") to a new generation of applications -- the Mozilla Firefox browser and the Mozilla Thunderbird mail and news client. That shift in focus occurred almost immediately, as the Mozilla Foundation was formed and we hired the lead developers for Mozilla Firefox and Mozilla Thunderbird. At that time we also stated our intention to maintain a long-lived, stable 1.7.x version of Seamonkey. We noted that a number of commercial distributors ship Seamonkey and will need the means to maintain it for their customers. There is also a user and developer base that is fond of Seamonkey and would like to maintain it. We have continued with this maintenance plan as well, with a 1.7.6 release scheduled for the next few weeks.

In the last few months we have also been releasing a series of 1.8 alpha and beta releases. The goal of these releases has been to test the changes to the back-end aspects of our codebase. Most users are familiar only with the "front-end" of our code -- the actual end user applications that provide browsing and mail functionality. But underneath this layer of code is a deep, complex layer of infrastructure that makes things work behind the scenes. There's no reason for end users to be aware of this foundation, just as most of us aren't aware of the details of the foundation of the skyscrapers we visit. But it is critical, and continued development and testing of this layer is vital to keeping our applications healthy.

The ongoing alpha and beta releases of Seamonkey 1.8 have suggested that the Mozilla Foundation itself will be creating a 1.8 final release. This is not our plan. The 1.8 releases have been for testing our backend. We intend that the 1.7.x line of releases will be the last long-lived, maintained versions released by the Mozilla Foundation. There is no doubt that the series of 1.8 alpha and beta releases have caused some confusion about whether there would be a 1.8 product released by the Mozilla Foundation. In addition, a set of people have done a non-trivial amount of work on 1.8 features, thinking this would be part of an official Mozilla Foundation release. This has been a error on our part. These contributors have reason to be unhappy with us. We can only apologize, at the same time recognizing that apologies only go so far and can't fix the error.

Our plan for the Seamonkey suite is as follows:

The 1.7.x line will be the last set of Seamonkey products released and maintained by the Mozilla Foundation. The Mozilla Foundation will provide infrastructure for those interested in working on the 1.7.x releases, which we expect will include a number of vendors who provide these products to their customers. We've committed to support the 1.7 branch some time ago. If we ship 1.8 we'll need to support that as well, and we just can't manage supporting that many versions as well as Firefox and Thunderbird releases.


The Mozilla Foundation will provide infrastructure support (CVS access, bugzilla, development tools, etc) for community members who wish to continue to develop Seamonkey. This community group may wish to do formal releases of Seamonkey, much as the Sunbird and Minimo developers do. We support this. We probably won't use the same naming conventions, as we need to be clear that this is not a Mozilla Foundation product release.


Boris Zbarsky has posted an open letter to the Mozilla Foundation signed by a set of interested parties, laying out a community transition plan. We support this plan and will work with interested parties to figure out strategy. There will undoubtedly be some implementation details to be worked out (e.g., can we actually use Seamonkey as a formal trademark, how do we work the tinderbox machines, etc.).
The dedication to the product, the initiative of the developers and the proposal of the transition plan as a solution are all hallmarks of the Mozilla community. We support this effort completely.

当网络的速度快到能在瞬间完成一部DVD电影的下载的时候，你还会去买DVD吗？阿尔卡特的发言人的回答是不。有人说这种说法太可笑了，如果DVD要消失，那也是在书籍消失以后。但是更多的人指出这个比喻太过糟糕。人们不会淘汰书籍是因为喜欢享受纸的质感，不喜欢面对荧光屏。而对于DVD来说并没有这种区别，无论是观看买来的DVD或者是网络上播放的电影，面对的都是令人厌倦的荧光屏。想想看你的cd机，在mp3越来越流行的今天，她还有用武之地吗？你最近又买了多少cd呢？我自己已经很久没有买cd了...

DVD facing an early grave
Video downloading will kill off the 'passive' format, claims Alcatel chief
The DVD format will be nothing more than a flash in the pan, according to the chief executive of Alcatel.

Speaking at the opening of the Alcatel Forum in Paris, Serge Tchuruk told delegates that cheap and widely available broadband services will sound the death knell for the popular storage medium.

Recent network price drops are just the start of a longer term trend that would see video downloading kill off the DVD, he claimed.

"The DVD will be short lived," said Tchuruk. "This kind of video was a passive exercise. Today things need to be much more interactive."

He added that, while the price of broadband had halved in the past two years, capacity has increased fivefold. This is going to drive a wave of data services, both mobile and fixed, through what Tchuruk described as "user-centric broadband".

As a result telecoms companies will have to shift from being voice dominated to concentrating on services to generate revenue. Tchuruk added that voice still accounts for more than 70 per cent of telecoms revenues.

However, it is in the mobile services that Tchuruk sees most promise. Delegates were told that mobile voice and data services had a two or three times price premium compared to fixed services.

Steven J. Vaughan-Nichols发表了一篇激烈的文章来指出firefox当前所面临的困难。firefox无疑是一款成功的浏览器，也是开源世界的骄傲。但是在无限风光的背后又隐藏了什么呢？ 最让我感到吃惊的是它的核心开发者之一Mike Conner说到:

In nearly three years, we haven't built up a community of hackers around Firefox, for a myriad of reasons, and now I think we're in trouble. Of the six people who can actually review in Firefox, four are AWOL, and one doesn't do a lot of reviews. And I'm on the verge of just walking away indefinitely, since it feels like I'm the only person who cares enough to make it an issue.

缺乏社区动力是开源软件最不愿看到的事情，没有充足的社区支持代表着后劲的缺乏。现有的社区支持也大多围绕着插件开发这一块，而对于Firefox本身的代码却鲜有人问津。Google支援的六名工程师也许从一定程度上可以缓解这种情况，但是从Firefox的源码量来看远远不够。Firefox需要资金，需要更多的盈利手段。


Firefox Is Heading Towards Trouble  
By Steven J. Vaughan-Nichols
March 8, 2005

Opinion: I think Firefox is the best browser on the planet, but it's not going to stay that way long unless the team behind it gets their act together sooner rather than later.







I love Firefox.

It is, without a doubt, my favorite browser ever, and I've used almost every one that ever rendered a Web page. No matter what the operating system—Windows, Linux, heck, even NetBSD—one of the first things I do now with any of my boxes is to install Firefox on it.

I'm not alone. There have been over 25 million downloads of Firefox since version 1.0 hit the streets in fall of 2004. It has come out of nowhere to shrink Internet Explorer's share of the Web-browser space for the first time in years.

Firefox is also gaining software support. In addition to smaller open-source add-on programs, mainstream helper applications like Yahoo Toolbar and Google Desktop Search are now coming to Firefox.

Last, but never least, Firefox is more secure than Internet Explorer.

So, what's not to like?

Well, several things if you must know.

First, I said Firefox is more secure. That doesn't mean it's perfectly secure. You still must practice safe Web surfing to avoid phishing attacks and the like, and make sure to keep the browser patched up to avoid known security problems like the IDN (International Domain Name) bug.

Unfortunately, Firefox hasn't done a great job of making it easy to get its patches.

Click here to read about Mozilla's recent security upgrade, Firefox 1.0.1.

While Firefox does have an auto-update feature, the rollout of its first security patch, Firefox 1.0.1, was delayed for several days because of server overload problems.

Then, when it was rolled out, it was done slowly—20,000 downloads an hour—so as not to overwhelm the servers.

This is not good. In February, according to WebSideStory, Firefox was up to 5.69 percent of the Web browser market. Mozilla's avowed goal for Firefox is to get it up to 10 percent of the market this year. If Firefox does hit those kind of numbers, its back-end infrastructure must be built up or there's no way it can mount a serious threat to IE.

Quality assurance back at the servers also needs improvement. When the Mozilla Foundation first started pushing the automatic updates to Windows users out on Feb. 28, what actually ended up happening was that the Windows update was served up to Mac and Linux users!

Boy, did that do them a lot of good!

Besides, this 'update' isn't really an update. It's a complete new installation of Firefox 1.0.1. Can you say annoying?

To further confuse Windows users, the default installation of this 'patch' leaves you with entries for both the now-gone older version and the new one in Windows' Add or Remove Programs control panel.

It's a known bug that's been around since June of 2004 and it's still not been fixed. I am not amused.


It's not just Windows users who are facing a rocky upgrade route: Firefox 1.0.1 wasn't available for Linux and Mac users at all until several days later.

You would hope that as Firefox popularity grows by leaps and bounds, these kind of problems would be fixed. I wish I could be so optimistic.

Mike Connor, a core Firefox developer, writes in his blog, "In nearly three years, we haven't built up a community of hackers around Firefox, for a myriad of reasons, and now I think we're in trouble. Of the six people who can actually review in Firefox, four are AWOL, and one doesn't do a lot of reviews. And I'm on the verge of just walking away indefinitely, since it feels like I'm the only person who cares enough to make it an issue."

If Firefox's reviewing developers, the key people of any open-source project, have burned out on the project, Firefox is in a lot of trouble.

Forget about trying to get new and better versions out. They're not going to be able to keep up on security fixes and bugs. For example, it used to be that if you ran Firefox you never saw annoying pop-up ad windows.

That was then. This is now.

Today, instead of pop-ups, there are sites that feed you pop-unders: advertising windows that deploy under your current Web browser window, which you then see when you close your window.

It's annoying, it needs to be fixed, and if Connor is correct, I don't see that happening anytime soon. A Firefox extension, Adblock, can make the pop-under problem more manageable, but you must set it up manually for it to work.

Forget about Microsoft coming out with IE 7 to challenge Firefox. If Firefox rots from the inside out—the way so many other programs, like the original Netscape browser, did—then it's not going anywhere much beyond where it is now.

How will Microsoft's Internet Explorer 7.0 release challenge Mozilla's Firefox? Click here to read more.

Here's the long and short of it. If the Mozilla Foundation and Firefox friends like Google don't start spending money—right now—to hire more programmers, more project managers and more servers, it won't matter how many ads in the New York Times Firefox supporters take out, Firefox will have already reached its high tide of popularity and we can only wait for the ebb to begin.

eWEEK.com Senior Editor Steven J. Vaughan-Nichols has been working and writing about technology and business since the late '80s and thinks he may just have learned something about them along the way.

APR是一项很有意思的技术... 首先它是开源的，其次它在某种程度上是可以和ACE相提并论的。它的主要目的是让程序员可以轻松的写出可移植的代码而不用纠缠于无止境的#ifdef/#endif. 把介绍放在全文中作文档，以后也许会用到。

Apache的衍生物也是不同反响，真是漂亮。

Feature Story  
Written by Ryan Bloom     
Tuesday, 01 February 2005  
Apache 1.3 was ported to a variety of platforms, including many that weren't POSIX based, such as Windows, OS/2, and BeOS. On those platforms, Apache 1.3 often relied on #ifdef blocks to acheive portability, effectively forking the source into mainline code and platform-specific code, making the code harder to read, debug, and maintain.
When development started on Apache 2.0, the developers knew that they needed a better solution. Initially, two existing solutions were considered. One was the Adaptive Communication Environment (ACE), and the other was the Netscape Portability Runtime (NSPR). However, both were rejected.
ACE was implausible because Apache requires that all code be written strictly in C, and ACE is a combination of C and C++. And while NSPR looked like a good fit, it's license was incompatible with Apache's. (The licensing issues were eventually resolved, but by that time, APR was already in development.)
Nonetheless, writing APR from scratch has worked well for the Apache community — and others. (See the sidebar, "Who's Using the Apache Runtime?" for more details.) It's a portability layer specifically written with servers in mind.
Let's see how to write applications with APR. And to appreciate APR's power, let's start with code that looks portable, but's not. As you'll see, there are devils in the details.
Almost Portable

Some code is inherently portable, because it uses very well documented APIs
that are implemented everywhere. For example, the code...
char *var = getenv("SHELL");
... compiles and runs on all platforms, but there are subtleties that may make it behave differently. For instance, is the SHELL variable name case sensitive? On Unix it is, but on Windows, it isn't. Also, on Windows, applications can be compiled in either UNICODE or ANSI modes. If your application is compiled for UNICODE, then the environment table is UNICODE — but this code always tries to read the environment variables as ANSI strings. These details can be absolutely infuriating for any developer.
In APR, this same concept can be written as:
char *var;apr_status_t rv;rv = apr_env_get(&var, "SHELL", p);
In this case, the code isn't much more complex than the original, and it resolves the issues of the original code. Because APR always uses native functions under the covers, APR is able to determine if it should be reading as UNICODE or ANSI and react accordingly.
Listing One shows a very simple program that demonstrates getting a single environment variable.
LISTING ONE: Reading an environment variable with the Apache Portable Runtime

1 #include "apr.h" 2 #include "apr_env.h" 3 4 int main(int argc, char* argv[]) { 5   apr_pool_t* p; 6   char *env_var; 7 8   apr_initialize(); 9   atexit(apr_terminate());10   apr_pool_create(&p, NULL);11   apr_env_get(&env_var, argv[1], p);12   printf("%s\n", env_var);13   apr_pool_destroy(p);14 }
The first thing the program does is initialize APR. Every APR-based application should do this as soon as the program starts. (While APR may work without initialization on some platforms, on others it won't. It's best to always add the call.)
Next — and another mandatory step — the program calls atexit() to configure APR to call apr_terminate() when the program exits. This ensures that any mutexes and other, limited operating system resources are released.
The rest of the code does the work. Line 10 creates the first pool created (more on pools momentarily), lines 11-12 get the requested environment variable and print it to the console. Line 13 destroys the pool and exits.
If the code is in file abc.c, compile it on Linux using:
$ gcc abc.c `./apr/apr-1-config --includes` \  `./apr/apr-1-config --libs`  \  apr/.libs/libapr-1.a -o echoenv
apr-1-config is a configuration script that provides the proper arguments for compiling APR programs. In this case, the includes directories and the libraries that must be linked to satisfy APR's requirements. You can run the application with ./echoenv SHELL.
Not Portable

Code that looks portable but isn't is frustrating, to be sure. But a far more complex problem is code that's obviously non-portable. It's hard enough for experienced multi-platform developers to remember which function is for which platform — what do you do when porting a complex application to a platform you have no experience with?
For example, loading shared libraries is different on many platforms. What function do you call to load a library on Windows, Linux, HP/UX, and MacOS X? Many people know how to do it properly on one or two of those, but very few people know all four.
Even if you do — on Windows, you use LoadLibraryEx(), Linux uses dlopen(), HP/UX uses shl_load(), and MacOS X uses NSLinkModule() — each of those functions have different arguments and different error codes.
In sharp contract, loading a library in APR is as simple as:
apr_dso_handle_t *h = NULL;apr_status_t status;status = apr_dso_load(&h, "testdso.so", p);
The type apr_dso_handle_t is a handle to the shared library. With a handle, you can load a specific symbol from the library.[ Ed.: What is the argument, p?]
For a complete list of the types of actions that APR makes portable, see the
API documentation on the APR web site.
Managing Memory

In all of the examples above, APR allocated the memory for the APR variables, because for most APR types, only APR can allocate the memory. Because of how most APR types are defined, only APR has the correct size of the APR type, and therefore only APR can allocate the memory correctly.
So how do you allocate memory for your variables? Use pools.
Typical C memory management requires that the code that requests memory also free that memory. If you forget to free any of your allocated memory, your application leaks, which, for a long-running application like a server, can get bad enough to bring the computer to a crawl. Pools address this problem by having all memory allocation happen from shared pools of pre-allocated memory. This allows all of the allocated memory to be freed at one time, without needing to worry about memory leaks.
You can also create a hierarchy of pools, so that each pool has a parent. If you destroy a pool with a parent pool, then the memory from the sub-pool is returned to the parent instead of being freed. If you clear or destroy a parent pool, the child pools are automatically cleared or destroyed, respectively. Finally, you can register functions to run when a pool is cleared. This is useful if you have a resource that must be closed properly, because you can drop the handle to the resource, and when the pool is cleared, the resource will be closed. APR itself uses this feature to ensure that mutexes are released before a program ends.
Pools also enhance performance. One of the worst things you can do in C is allocate and free memory repeatedly. Often, the worst part of your application is malloc() and free(), which you don't control. By moving to pools, you remove a lot of the overhead of malloc() and free(), because calls to those functions are centralized. In fact, in a well-architected, pool-based application, there are never any calls to free() until the program is about to end. Written to use pools, programs come to a steady state, where it neither allocates nor frees memory while performing its work.
To be fair, working with pools is complex, and they don't map well to all applications. Any application that is small and doesn't do the same operation multiple times isn't a good match for pools.
Pools are APR's biggest advantage and biggest weakness. For people who like pools and have been using them in their applications, APR is the perfect portability library. However, for people who want to write very object-oriented code, pools can often get in the way. Also, it is very difficult to combine pool-based and non-pool-based code. The APR developers realize that pools aren't for everybody, and are working on finding ways to abstract memory allocation so that the current pools implementation can use a non-pools based allocator.
See the sidebar "Swimming in Pools" to help determine if your application is well-suited for pools.
Implementing cat using APR

cat is one of the simplest commands found on Unix machines: it reads one or more files or standard input, and prints everything read to standard output. However, paired with a variety of other Unix commands, cat can become a very powerful tool. So, it's surprising that there isn't a reasonable facsimile of cat for Windows (except for cygwin, but it removes you from the Windows environment instead of implementing the tools in a native environment).
Let's implement a simple, portable version of cat using APR. Listing Two shows the most important function ((a complete version of cat is left as an exercise.)
Listing Two: The guts of a portable version of cat

1 void printOutput(apr_file_t *in, apr_file_t *out, int numberNonBlank,  2                 int numberAll, int showEnd, int showTab, int showNonprint,  3                 int squeezeBlank)  4 { 5   char str[HUGE_STRING_LEN]; 6   int linenum = 0; 7   int lastBlank = FALSE; 8 9   while (apr_file_gets(str, HUGE_STRING_LEN, in) != APR_EOF) {10     apr_size_t bytes;11     int emptyLine = FALSE;1213     emptyLine = !strcmp(str, APR_EOL_STR);14     if (apr_file_eof(in)) {15       break;16     }17        18     if (squeezeBlank && emptyLine) {19       if (lastBlank) {20         continue;21       }22       else {23         lastBlank = TRUE;24       }25     }26     if (!emptyLine) {27       lastBlank = FALSE;28     }2930     if (numberAll || (!emptyLine && numberNonBlank)) {31       linenum++;32       apr_file_printf(out, "%d: ", linenum);33     }3435     if (showTab) {36       replaceTab(str);37     }38     if (showNonprint) {39       replaceNonprint(str);40     }4142     bytes = strlen(str);43     if (!strcmp(str + bytes - strlen(APR_EOL_STR), APR_EOL_STR)) {44       str[bytes - strlen(APR_EOL_STR)] = '#CONTENT#';45     }46     apr_file_printf(out, "%s%s" APR_EOL_STR, str, (showEnd) ? "$" : "");47   }48 }
The function printOutput() loops through a file reading one line at a time, making some changes to the string that was just read, and printing the result. No sub-pools are created, because nothing in the loop actually allocates new memory.
Looking at Listing Two, it should be obvious that using APR doesn't change the code that you'd normally write to implement cat, with one exception on line 43. Notice the APR_EOL_STR macro. It expands to the correct end-of-line character sequence for the current platform. On Windows, this is CR/LF, while on Unix, it's LF. This can be a very important difference when porting applications that deal with text files between platforms, and again APR provides the tools for handling this problem.
Listing Three shows the function that determines how to handle printing non-printable characters.
Listing Three: Character checking in APR

1 void replaceNonprint(char *str) 2 { 3   int len = strlen(str); 4   char old[HUGE_STRING_LEN]; 5   int i; 6   int offset; 7 8   memcpy(old, str, len); 9   for (i = 0, offset = 0; i < len; i++, offset++) {10     if (old == '\t') {11       continue;12     }13     if (!apr_isascii(old) && !apr_isprint(old)) {14       str[offset++] = 'M';15       str[offset++] = '-';16       str[offset++] = toascii(old);17     }18     if (apr_iscntrl(old)) {19       str[offset++] = '^';20       str[offset++] = (old == '7') ? '?' : old | 0100;21     }22   }23 }
replaceNonprint() is only called if the user wants to see non-printable characters. In this case, lines 13 and 18 are the most interesting, because they show how to determine if the current character is printable or not, and if it is an ACSII character or a control character. These methods are usually implemented as macros on most platforms, but on some of the more esoteric platforms, they don't exist at all, so APR had to re-implement them.
Who's Using the Apache Runtime?
Since APR 1.0 was released in October 2004, it's received a lot of attention. However, projects have been using APR with great success since its early days.
Obviously, the most visible APR-based project is Apache 2.0. Apache 2.0 relies on APR for all of its portability concerns. This has allowed the Apache developers to combine their source into a single codebase, avoiding the issues associated with lots of platform-specific #ifdef s.
While solving some problems, code unification highlighted another: portability isn't as simple as replacing platform-specific networking and file system functions with "generic", portable replacements. Fundamentally, different platforms run servers in often unique ways.
For example, Unix lends itself to having a lot of server processes with one or a small number of threads per process. Windows, on the other hand, lends itself to at most two processes with a much larger number of threads per process. To solve this problem, Apache 2.0 needed to abstract out the process launching aspect of the application.
Another project that's had great success with APR is Subversion (http://subversion.tigris.org/). Subversion leverages APR to provide a current versioning system on every major (and some minor) platforms. The Subversion version control system is interesting, because it has both client and server components, both which use APR for portability. The Subversion server can either be run as a module to Apache 2.0 or as a stand-alone server. The client is a simple command-line application. (APR doesn't contain any GUI components.)
A slightly different project that takes advantage of APR is APR-util. APR-util is developed by the same engineers who write APR itself. For more details about APR-util, see the sidebar "APR-util: What Is It?"
Portability is a complex problem to solve, and it shouldn't be tackled lightly. While APR goes a long way to solving portability problems, no tool can remove all of the complexity, and APR should be considered just one part of your solution.
APR-util: What Is It?
Although the Apache Portable Runtime provides everything you need to write portable C code, it doesn't handle a number tasks that are nonetheless valuable to have available on many platforms — tasks such as MD4 and MD5 encoding, and string matching with simple glob characters like * and ?.
For tasks like those, the APR team created the APR-util library, a set of useful routines that are guaranteed to work on all platforms. For instance, if you've always wanted a wrapper for accessing any type of database with the same API (much like Perl' s DBI layer), APR-util has the DBM system.
APR-util can also be used for manipulating URIs, generic pooling mechanisms through the resource list API, and UUID handling.
Each individual system in APR-util is completely separate, which can be very confusing. The only thing that holds these systems together in a single library is that all of its features are small, useful, and inherently portable. Although most people don't know about APR-util, it is a very powerful library and should be considered when you need anything it offers.
Swimming in Pools
Pools work best for long-running applications that repeat the same operations over and over again. However, pools can be used for any type of application, if it is designed properly.
To write an application for use with memory pools, think of your application as a set of nested operations. Each operation should get one pool with as many sub-pools as necessary.
For example, the first operation is the application itself; the second operation could be configuration; and a third could be running a command or processing a request. Everything nests within the first pool, the one that was created when the program started. When the program ends, simply discard the first pool. This will, in turn, destroy every other pool in the program, ensuring that all memory is freed.
Code, Code Everywhere

Hopefully, this quick trip through the Apache Portable Runtime has shown you how easy it can be to write portable C code without sacrificing readability or maintainability. APR is a project that has taken a long time to come to fruition, but the final 1.0 release is a strong foundation for portable code.
Thanks to the Apache Portable Runtime team, writing portable code so much easier than it used to be. APR has eased cross-platform development for everybody.
Ryan Bloom is one of the founding members of the Apache Portable Runtime project, and continues as an occaisional committer today. He is the author of the Apache Server 2.0: The Complete Reference. Ryan can be reached at rbb@apache.orgThis email address is being protected from spam bots, you need Javascript enabled to view it. Thanks to David Barrett for reviewing early drafts of this article.

由一位在软件工程方面有近十年经验的专家根据自己的经验总结出以下10个常见问题:

1. 解决方案比要解决的问题还要复杂

2. 基于自己的需求而不是用户的需求来设计

3. 疏于优雅的处理所有可能的出错情况

4. 不去保护用户的隐私

5. 期待用户会去(或者应该去)阅读所有文档

6. 期待用户掌握了(或者应该掌握)技术知识/术语

7. 期待用户会(或者应该会)在使用某些功能先进行配置

8. 总是试图去猜测用户的意图(而不是通过交流来了解)

9. 不知道什么时候对软件进行重构(要么是无效的重构，要么是在需要重构的时候没有去做)

10.  没有尽可能的提高软件的可维护性和代码的可理解性

The Ten Worst Engineering Pitfalls
 Posted by special contributor Keith F. Kelly on 2005-03-09 02:19:16 UTC
I've been a professional software engineer for close to ten years. Based on my experience, I recently attempted to enumerate the ten worst engineering "traps" most developers seem (for whatever reason) prone to fall into. Here's the list I came up with. It should be noted that wherever two of these come into conflict, the item close to the top of the list wins.   
The Ten Worst Engineering Pitfalls

1. The solution is more problematic than the problem it was created to solve.

2. Basing the design on your own motives rather than on users' needs.

3. Neglecting to handle all possible failure cases gracefully.

4. Failing to protect users' privacy.

5. Expecting that users will (or should have to) read anything.

6. Expecting that users will (or should have to) possess technical knowledge or jargon.

7. Expecting that users will (or should have to) configure something before using it.

8. Challenging or attempting to guess the user's intent.

9. Not knowing when to re-architect (either doing it pointlessly, or avoiding it when needed).

10. Failing to make the implementation as maintainable and understandable as possible.

日本公平贸易委员会(JFTC)正在通过法律手段让Intel而为其所作的不公正商业行为退款。据调查Intel曾迫使日本的五大PC制造厂商(占市场份额的77%)都完全或者是大部分采用Intel CPU并尽量缩减其他品牌CPU的采购份额。文章的最后提到欧洲也正在采取行动调查Intel的商业行为是否有不当之处。

AMD的声势越来越浩大了，在以前这是不可想象的... 看来AMD64的推出不仅占领了市场份额，也占领了人心。
期待中国的举措。