Congratulations to LinkedIn for reaching 300million members!

That’s quite an accomplishment.

There are now sites in that stratospheric level, but still, it is not an easy accomplishment.  Congraluations LinkedIn!



SGI T-shirt

A post on LinkedIn’s ex-SGIers group gotme looking for my SGI t-shirts.  One of my favorite pastime is to collect t-shirts, cups, etc. from the companies that I’ve worked for…. and I’ve worked for a lot of companies here in Silicon Valley.

I found my Jurassic T-shirt that I got when Jurassic Park, the movie, came out.  That was very big at the time, and I remember SGI rented the near by Shoreline movie theater and let the entire company watch it.  That was awesome!

Here is a picture of my T-shirts.  It’s a little bit worn out — what do you expect for a 20 years old t-shirt.  Also found another SGI t-shirt, this one is for Digital Studio  package.


Digital Studio T-shirt
Digital Studio
SGI Jurassic Park t-shirt
Jurassic Park

New Year online account clean ups

Every year I make resolutions and do my house cleaning.  One of the ritual I do is to review all my online accounts and update my settings, change passwords, etc.

1.  I update settings to increase my privacy as much as possible.  By default, for social media accounts such as Facebook, Twitter, LinkedIn, Google+ etc.  I set my sharing settings to only my circle, unless I specifically say otherwise.

2. I also change my privacy settings to not allow anyone to see more about me than I am comfortable with.

3. I turn on Two Factor Authentication if it is offer.  This mean that login to an online account requires both password and something extra, such as a code sent to my phone via SMS.  This has saved my bacons a few times when some rather big web sites (whose name shall not be mention) users database got hacked.

4. I also change my password if I’ve used that password for a while on that particular account.  Yes, I know about having to keep track of, remember, all these different passwords.  That’s why I strongly recommend a password locker.  There are apps that run on iOS, Android, Windows and OS X (across all of them too), that you can use keep your passwords in.

5. I use a password generator to generate my 8 to 12 chars password (8 is the minimum I recommend).


Nexus 7 (2012 Wifi) and Kitkat 4.4

I had a scare this weekend with thinking my Nexus7 got bricked by Kitkat update from Google.

Thursday night (11/21/13), my Nexus 7 let me know that it has d/l’ed Kitkat and ready to update.  I told it to go ahead since the last few times, updates from Google went fine without any problems.

After my Nexus 7 rebooted and updated, it then rebooted again and seem to be taking a long time at the boot up screen (bouncing color balls).  It was late, past 1am, so I left it sitting there on the dresser next to bed and forgot about it.  The next night, Friday, I saw it sitting on my dresser and remember about the upgrade, so checked it and found it is STILL at the bootup screen!!! WTF!

I pressed the power button to reboot.  Same thing…. Crap!  Tried it a number of time, no luck.  I was tired, so I left it there in the bootup screen.  This evening, I had time to look at it again and the damn thing is still at that screen.  It has been a while, so I had forgot how to boot into recovery mode, sigh.   Anyway, checking online found lots of complaints from people with similar problems.

This post on AndroidCentral was the one that solved my problem.  Just thought I shared it.

The following snippet is from AndroidCentral post, I am putting here in case the post goes away.


” I was in the same situation and ran into that issue as well. What I did was download the 4.3 factory image from here:

Make sure you get the correct one for your device. I have a 2013 wifi so I chose: Android 4.3 (JSS15R)

Inside that downloaded file, you’ll find It’s a couple of levels down. Unzip the files from there to your SDK folder (should be boot.img, recovery.img, system.img, userdata.img, and cache.img).

Boot your Nexus 7 to the bootloader (volume down + power) and connect to your PC with USB cable. Do NOT go into Recovery mode yet.

From the command prompt, make sure you can see your device: fastboot devices

Then, run the following commands:

fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot erase system
fastboot flash system system.img

At this point you have a clean install of 4.3 JSS15R.

Now go to Recovery mode and sideload the 4.4 OTA as you originally tried and it should work this time.

I followed these steps and was able to update to 4.4 without losing any data. YMMV”

Note: Once I was sure that I can boot 4.3 without losing my data, I actually updated to 4.4 using the above method.   The difference is that once in Recovery mode, I don’t do sideload, and I wipe dalvik cache, plus format /cache partition.

Dec 10, 2013

And now 4.4.2 update appeared on my Nexus7 and Nexus10.  Once again, I accepted the update on my Nexus7, let it boot into recovery and proceed to messed it up.  My fault this time.  I thought it would be as complicated as the previous update from 4.3 to 4.4.   I had to use fastboot procedure above to fix it.

For my Nexus10, I just had to accept the update to 4.4.2.  Boot into bootloader, flash CWM recovery, then boot into recovery and ‘adb sideload’ the new SuperSU.


Repurposing netbook into gateway, firewall, AP

The older netbooks, such as ASUS EEE 900 series, have gone down in price. I bought a refurbed EEEPC 900A w/1GB RAM, 4GB SSD and turned it into my gateway, firewall and local AP.  Upgraded memory to 2GB RAM, and added an external 8GB SD flash.

I loaded Fedora Core 17 Security Distro on it.  Now I have a nice, cheap gateway, firewall and AP (although only 802.11G speed).

I’ll add more to this as I have time…..

Unfortunately the netbook only have one wired 100M enet.  I need at least GigE interfaces.  I am currently looking at the

OEM Production 2550L2D-MxPC

which is an Atom D2550 based system with 2 Broadcom GigE, small, lower power and up to 8GB of RAM.  This should last me a long time as a router/gw/fw.

More to come….


File transfer speed over ssh

I’ve known that ssh encryption has an effect on the speed of file xfers. So doing thing such as rsync (which will use ssh) or even plain scp can be pretty darn slow, especially on large files and on system with old/slow CPU.

I also know about the recommendation to use different type of encryption when transferring files. Some people recommend blowfish, others arcfour. So I thought I’d do a little bit of testing in a controlled environment.

I have two recent vintage HP servers with the following specs.

HP ProLiant DL360p Gen8
Dual quad core Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (8 core, 16 threads total)
4 x 3TB, mdadm RAID10, formatted as XFS, mounted noatime,logbufs=8
Tigon ethernet NIC, connected as GigE, full duplex to HP ProCurve 2848 switch
(both servers connected to same switch)

The test file is:
3921247501 Mar 4 08:22 bigdata.tar.bz2 (3.8GB)

I am using OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
Kernel is 3.8.1-1.el6.elrepo.x86_64 #1 SMP Thu Feb 28 19:15:22 EST 2013 x86_64 x86_64 x86_64 GNU/Linux

I am going to copy this file from hp1 to hp2, using scp, rsync and ftp. With scp, I’ll try different encryption, no compression to see how the different encryption affect the transfers. For comparison purposes, I also timed using plain ole FTP transfer, which mean no encryption and very little system processing; and the timing proves that.  Also tested with plain rsync protocol (direct to rsyncd).

I run this 3 times. Without specifying encryption, ssh/scp will use the default, which depends on the version of OpenSSH (for this version, the default is aes128-ctr).  NOTE: the file is rm’ed each time at the dest before I do copy.

run Xfer type real user system
1 scp -o Compression=no 0m52.175s 0m12.709s 0m6.504s
2 scp -o Compression=no 0m47.872s 0m12.603s 0m6.806s
3 scp -o Compression=no 0m49.317s 0m12.748s 0m6.710s
1 scp -c arcfour -o Compression=no 0m49.536s 0m14.161s 0m6.903s
2 scp -c arcfour -o Compression=no 0m49.088s 0m14.045s 0m6.921s
3 scp -c arcfour -o Compression=no 0m50.698s 0m14.162s 0m6.728s
1 scp -c blowfish-cbc -o Compression=no 0m58.673s 0m44.295s 0m13.495s
2 scp -c blowfish-cbc -o Compression=no 0m56.399s 0m43.860s 0m9.036s
3 scp -c blowfish-cbc -o Compression=no 0m54.869s 0m43.949s 0m10.673s
1 scp -c aes128-cbc -o Compression=no 0m49.776s 0m14.641s 0m7.083s
2 scp -c aes128-cbc -o Compression=no 0m48.527s 0m15.154s 0m7.068s
3 scp -c aes128-cbc -o Compression=no 0m50.554s 0m15.334s 0m6.983s
1 ncftpput -m -u ftptest -p ‘XXXXXX’ hp2 /data/ /data/bigdata.tar.bz2 0m34.306s 0m0.141s 0m4.062s
2 ncftpput -m -u ftptest -p ‘XXXXXX’ hp2 /data/ /data/bigdata.tar.bz2 0m33.351s 0m0.160s 0m3.863s
3 ncftpput -m -u ftptest -p ‘XXXXXX’ hp2 /data/ /data/bigdata.tar.bz2 0m33.839s 0m0.154s 0m3.732s
1 rsync –stats -a /data/bigdata.tar.bz2 hp2::data/bigdata.tar.bz2.1 0m33.485s 0m10.221s 0m6.692s
2 rsync –stats -a /data/bigdata.tar.bz2 hp2::data/bigdata.tar.bz2.2 0m33.490s 0m10.234s 0m6.703s
3 rsync –stats -a /data/bigdata.tar.bz2 hp2::data/bigdata.tar.bz2.3 0m33.497s 0m10.163s 0m6.545s

In terms of speed, we have:

Average over 3 runs

RSYNC:         real=33.491  user=10.206  sys=6.6467
FTP:           real=33.832  user=0.1517  sys=3.8857
AES128-CBC:    real=49.619  user=15.043  sys=7.0447
ARCFOUR:       real=49.774  user=14.1226 sys=6.8507
AES128-CTR:    real=49.788  user=12.687  sys=6.6734
BLOWFISH-CBC:  real=56.647  user=44.0347 sys=11.068

So it look like in modern OpenSSH, using AES, it’s a wash which cipher/encryption method you want to use.

Note that rsync protocol itself is pretty darn efficient, slightly faster than FTP.

3/6/13 Update

AES in SSH.  I’ve tested again from an old Dell using Pentium 4 to the fast HP, with no AES support in hardware and the default AES128-CTR is much slower.  However, good news is that AES128-CBC is still faster than BLOWFISH, but slightly slower than ARCFOUR.  As for FTP and RSYNC, they are neck-and-neck in speed, no clear winner.

So my conclusion is that whether using AES with hardware support (in new Intel CPUs) or software, using the CBC (block mode) variant of AES is usually good enough.



iSCSI initiator (netbsd-iscsi-initiator) for OS X Mountain Lion (10.8.2)

I am playing around with iSCSI for my macbook pro. Looked around and the used to be free SNS globalSAN iSCSI is no longer free. ATO is too expensive to play with. Saw that macport has a netbsd-iscsi, so went that route.

$ sudo port install netbsd-iscsi-initiator
---> Computing dependencies for netbsd-iscsi-initiator
---> Dependencies to be installed: netbsd-iscsi-lib
---> Building netbsd-iscsi-lib
Error: for port netbsd-iscsi-lib returned: command execution failed
Error: Failed to install netbsd-iscsi-lib
Please see the log file for port netbsd-iscsi-lib for details:
Error: The following dependencies were not installed: netbsd-iscsi-lib
To report a bug, follow the instructions in the guide:
Error: Processing of port netbsd-iscsi-initiator failed

Poking in main.log show the error at compiling disk.c.

:info:build /bin/sh ../../libtool --tag=CC --mode=compile /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I../../include -I/opt/local/include -pipe -O2 -arch x86_64 -MT libiscsi_la-disk.lo -MD -MP -MF .deps/libiscsi_la-disk.Tpo -c -o libiscsi_la-disk.lo `test -f 'disk.c' || echo './'`disk.c
:info:build /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../include -I../../include -I/opt/local/include -pipe -O2 -arch x86_64 -MT libiscsi_la-disk.lo -MD -MP -MF .deps/libiscsi_la-disk.Tpo -c disk.c -fno-common -DPIC -o .libs/libiscsi_la-disk.o
:info:build disk.c:811:40: error: assignment to cast is illegal, lvalue casts are not supported
:info:build *((uint64_t *) ((void *)data + 8)) = (uint64_t) ISCSI_HTONLL(key);
:info:build ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
:info:build 1 error generated.
:info:build make: *** [libiscsi_la-disk.lo] Error 1

So I patched that line.

- *((uint64_t *) (void *)data + 8) = (uint64_t) ISCSI_HTONLL(key);
+ *((uint64_t *) ((void *)data + 8)) = (uint64_t) (ISCSI_HTONLL(key));

and now it builds. I just got to play with this to see if it works. More to report later.

%d bloggers like this: