For example, Huawei C8650 is an exception, running repack-bootimg.pl immediately after unpack-bootimg.pl result in a different boot.img — the scripts don’t take all possible arguments into consideration.

And after a little investigation, I found out a way to integrate a newly built kernel into your image, given that you already have Android built on your machine:

1. Use split_bootimg.pl to split an existing boot.img into boot.img-kernel and boot.img-ramdisk.gz.
2. Run in your shell:

   $ANDROID_SRC_DIR/out/host/linux-x86/bin/mkbootimg --kernel $NEW_KERNEL --ramdisk boot.img-ramdisk.gz --cmdline 'console=ttyDCC0 androidboot.hardware=huawei' --base 0x10200000 -o $NEW_IMG

echo 22 > /sys/devices/platform/msm_hsusb/gadget/fixusb

Now it shows up in ./adb devices!

After three days use of Huawei C8650, I realized why HP halted the development on webOS — Android is fast, easy-to-use, and most important of all, it’s more open than webOS.

One of the most important aspect of webOS was its UI. The introduction of card-based applications, innovative user interaction with the mobile phone, including gesture area and swipe-to-delete, are something to be missed after switching to Android. But those features, when in webOS, didn’t make that much sense since the system is slow enough to run only one application, not to mention two or three: what would application cards be of use then? Running multiple applications is reasonable when you already have adequate hardware to support it.

These couple days with an Android phone are really nice, despite that my roommates has criticized the low resolution of my device, which I at first rejected but eventually conceded the truth. Once having gotten rid of the default system which contains numerous carrier-provided (i.e. useless) applications and substituting with a capable system, I am able to exploit the capability of Android, and Google behind it.

The contact book has extensive support for Chinese, ordering and categorizing people’s names by pinyin automatically, and full names entered in Gmail can be split into given name and family name automatically: an easy example of Chinese language processing which has been studied thoroughly but no one ever used it publicly by default before.

And obviously, the dedicated Gmail client is way better than the E-mail client in webOS, which was already good enough.

The only real difficulty I have encountered, is that I am unable to connect to my device from my Gentoo laptop via adb. I am still not sure of the reason behind this, more strangely, it can be recognized under Window$ 7 in the same machine, and Gentoo could recognize my roommate’s Moto Defy. Should I be able to solve this (hopefully), I’ll post again here.

Anyway, here it is:
http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html

However, under webOS with the Linux kernel and some UNIX tools, this is realizable. Here’s an introduction on how to achieve this. (Tested with Palm Pixi Plus under Gentoo GNU/Linux. Should also be working with other phones and distributions.)

1. A preparation step: you need to have the access to the Linux shell on your phone, and have novaterm available on your computer, which is used to access the phone shell from your computer.
2. Enable enable USBnet on your phone, and connect it to your computer. Make sure you have the the usb0 interface properly shown upon the ifconfig command on both the computer and the phone. We assume the IP of the computer is 192.168.0.201, and the IP of the phone is 192.168.0.202.
3. Install squid on your computer. It will open up a port to redirect requests from your mobile phone. The default configuration should work. After installation completes, run /etc/init.d/squid start to start the daemon.
4. Then we redirect TCP requests from the phone to the computer by running this command in novaterm:
   

   iptables -t nat -A OUTPUT -p tcp -j DNAT --to-destination 192.168.0.201:3128

   Replace 192.168.0.201:3128 with the actual IP of the computer and the actual port squid is listening to.

5. Finally, we tell the route table to route the packages to the usb0 interface, so that the requests go properly to your computer instead of WIFI/mobile network. To complete this, we run:
   

   route add -net 0.0.0.0 netmask 128.0.0.0 dev usb0
   route add -net 128.0.0.0 netmask 128.0.0.0 dev usb0

And here we go! We should now be able to access the Internet from the phone via the computer network.

使用 Greasemonkey 安装脚本后在补退选页面即可看见相关选项, 填写验证码之后点击“Go!”可开始自动刷新, 如果有空位自动补上. 理论上可以同时对多个课程进行刷新, 并补选第一个有空位的课程, 但是实际操作中由于服务器方的原因, 可能只有一个能够正常运行.

安装 Election Cruncher

过了好多个月想起这件事, 发现已经有人遇到过这个问题, 不过给的 sed 脚本已经过时了.

这里是新的解决方法:

1. 在 Liferea 的 feed 属性中, 进入 Source 标签.
2. 启用 Use conversion filter, 并使用 sed -r 's|<div class="sysmsg">.*?</div>||g'

   作为 filter.

Hours later, I successfully made it a brick.

Hanvon N510 brickshot

I tried several methods on some Chinese forums, press rotate and then power, discharge the battery, and none worked.

I’ll have to go to Zhongguancun (中关村), and ask if they could repair it!

Indeed it is very fast when coming to HTML rendering and JS execution, but its non-uniform look with the system and the lack of extension support, makes it very frustrating for me to use it.

Unlike Firefox and other Mozilla platform based browsers, in which extensions can have full access to the browser itself and content document, Chrome extensions are divided into two parts:

• Background pages
• Content scripts

Each of them are restricted either to the browser chrome, or the content document. And they communicate through message passing. It can be illustrated as so (excuse me for my Inkscape skills):

Compared to Firefox, it is quite convenient to develop a light weight extension to Chrome: it’s just like using Greasemonkey with user scripts. However, the defects of the underlying JavaScript language, makes it very hard, if not impossible, to develop a large-scale extension.

The message passing between content scripts and background is surely asynchronous, while due to the implementation of underlying JavaScript language, it’s essentially impossible to block on an asynchronous call, as JavaScript is executed in one thread. You need to provide a callback. Combined with the native infectiousness of asynchronous calls, if you use it in a part of your code, it’s likely to spread over all your code.

Consider this situation: an extension’s preferences is stored in the localStorage provided by the browser. In order to access it’s very own preference, a content script need to make an asynchronous call to the background script. And…? You see here that we now need to arrange our code in favour of where the asynchronous calls appear, instead of their functionalities.

Yes, this is an issue for all JavaScript asynchronous calls, but in Chrome, the separation of content and browser, forces away all other work-arounds: the only thing you can pass as a message, must be a JSON object.

Furthermore, there are some other needless restrictions for content scripts: their XMLHttpRequests must obey the same origin policy. But, the background script are not restricted by this, and could therefore pass the result of XHR to content scripts by message passing mentioned above. So, what’s the use for restricting these content scripts? This completely makes no sense.

The tolerance of JavaScript has already introduced so much amateur, error-prone code, and the extension framework of Google Chrome even make well structured programs impossible to write.