Getting a tourist visa to Myanmar in Chiang Mai is quick and straightforward. There is a conveniently located consulate with very friendly staff, and no appointment is required. Here’s what you’ll need:
A photocopy of your passport photo page
Two passport photos
800 THB cash (or 1600 THB for rush service – I’m not sure how fast this is)
Address in Myanmar
Your previous employment information
If you really want to print your own form and fill it out ahead of time, you can find one on their embassy’s website. You can get these forms and fill them out at the Chiang Mai consulate, and they even provide pens and glue-sticks to attach a photo to your application. After submitting your documents, they will review them (~10 minutes), ask you to make any necessary changes, and then you will pay the 800 THB application fee (cash only). The consulate will then give you a receipt and let you know when to return for your passport.
Normal service time is two days (e.g. drop off Tuesday, pick up Thursday).
Visa application hours are 09:00-12:00 Monday – Friday. Pick up hours are 15:30-16:30 (normally two days later).
Although there is a sign at the entrance to the embassy saying something about needing bus/air tickets and a hotel booking, this is not requested when submitting the application.
Despite Google Maps indicating that the consulate is closed, it’s really open (since July 2015).
It is less expensive to obtain a visa ahead of time rather than getting a visa on arrival (800 THB ≈ $22.75 vs. $50 for eVisa on Arrival)
“I believe everyone here is a moonshot thinker, in your hearts[…] I believe that most of us are not in a context where we can be as open minded, as honest, as dispassionate when appropriate, as authentic as we want to be, as our natural selves would be. And I think you need to ask your context for that opportunity. And if it’s really not going to give it to you, be humble, try a few times, and if it doesn’t work, go find a new context. You all deserve to be able to let the best part of yourselves out.”
I picked up an Acer C720 Chromebook a few days ago to see what all the rage was about. After all, I spend most of my time in the browser already, where I create, read, update, and delete things. Do I really need all the excess of a full-fledged operating system? Can I get by with a $199 laptop that is cheap enough and light enough that I can take it traveling everywhere? I won’t go into details on the hardware – there are plenty of reviews already – but I did want to lay down some thoughts on the experience. I used Code Jam as a litmus test for Chromebooks as a simple development machine, and this is how it turned out:
This thing is fast. When I hear “Celeron”, I think machines made by Compaq or eMachines sitting next to CRTs that are dog-slow and will probably break in 3 months. This Celeron, however, is Haswell microarchitecture, and with minimal requirements of Chrome OS, makes the machine feel fast. It also helps that Chromebooks come with flash storage. This means excellent boot times (far faster than any Mac/Windows machine), and general snappiness.
This thing is light. It only has an 11″ screen, but compared to my unibody Macbook Pro 15″, it’s a much better travel companion. And the battery really does last all day (it’s rated for 8.5 hours, and that’s pretty much what I get).
The screen sucks. The TN panel has terrible viewing angles. The HP Chromebook 11 is the only budget Chromebook with an IPS display right now, but its processor is roughly half as fast.
Some things are really hard that are trivial on the conventional OS’s:
Try remapping the caps lock key to control on an external keyboard. In Chrome OS, you can easily do that with the internal keyboard, but not for external keyboards. It took me about two hours of reading through bug reports to find a hack.
Unzipping files – Chrome OS has built-in functionality that mounts zip files as ejectable drives – but it doesn’t work with all zip formats. For example, Code Jam solutions. The workaround for this was downloading and unzipping on my server and using a remote text editor to read the file.
Transferring files to/from remote servers – you can’t use TeamViewer (there’s no app), you can’t use SFTP (there’s an app but it costs money). In Code Jam, my workaround for the input/output files was copy and paste. Less than ideal.
Some issues are unique to the architecture of Chrome OS:
Flaky internet makes Chrome OS suck – you’re in some purgatory between good internet and no internet at all, which means that many apps are spinning around trying to connect rather than going into their (reduced functionality) offline modes.
The NaCl SSH client is sometimes insufficient. For example, Koding requires an SSH proxy server, and Chrome OS can’t do that. The workaround is to use Koding’s web terminal interface.
And some issues are just because Chrome OS is younger and not as polished:
I had frequent bluetooth disconnects for my headset and mouse. For my headset, the only solution was often to reboot (resetting the bluetooth power didn’t help).
While you can set “natural scrolling” for the trackpad, you can’t for an external mouse.
Scrolling with a bluetooth mouse was often quite jumpy scrolling pages at a time, even at the lowest sensitivity settings.
But it does work. My Code Jam “stack” consisted of a Koding VM and a Zed text editor client on Chrome set up to work with remote files on the VM. Pretty simple, and it worked pretty well (aside from the occasional Zed save hiccups that didn’t push the last character I typed).
Ultimately, this Chromebook is not something that I’d want as a development replacement machine. Chrome OS is just a wee bit too limiting. I sorely miss some of the niceties I have on Mac OS X – TotalTerminal, Alfred, Transmit, and Adium to name a few. Maybe in a few months we’ll see Haswell+ Chromebooks with an IPS display, and I’ll have a nice travel companion (assuming where I travel to has good internet).
There are instructions for compiling rippled on Ubuntu, but they’re not entirely clear. Sometimes you just want a script to do everything for you. Here’s something I cobbled together for Ubuntu 12.04 (you may want to modify the tag for whatever the current release of rippled is):
Seagate has developed a new 2.5″ laptop drive with a 2 TB capacity. Previous 2 TB laptop drives had a thickness of 15 mm, making them unsuitable for placement in most laptops. In contrast, the new Seagate/Samsung Spinpoint M9T ST2000LM003 (HN-M201RAD/AVN) has a thickness of only 9.5mm. However, this drive is not yet being sold through normal consumer sales channels. However, these drives are being sold as part of the Seagate Backup Plus line, inside a nice little USB 3.0 enclosure. These Backup Plus drives are also much cheaper (about 50% less) than the drives on eBay (step 3: profit?). Note, however, that you get no warranty (Seagate warranty validation: “The product you identified was sold as a system component”). The only tricky part is actually getting the drive out of the enclosure, especially if you’re trying not to damage the case.
The top of the case is made of stamped metal, and is held on by a combination of double sided tape and small clips.
Because there is more tape near the USB plug, it is easiest to begin prying the case off from the other end. Start by jamming something thin under the edge of the top of the case (see photo below). To avoid damage, you’ll probably want to use a nylon spudger (while screwdrivers work fine they will probably cause some cosmetic damage to the case). You can slide the spudger around the edge of the case, releasing the two clips at the end.
I ended up jamming the spudger further into the top of the case (on top of the hard drive) and prying gently, which also released two of the side clips (but being careful not to deform to the top too much).
After that, you just have to work the spudger around releasing the rest of the clips, and the top will come off. The drive itself is held into the bottom part of the case by two plastic pegs that protrude slightly from the case into the screw holes of the drive on the side away from the USB plug. They can be easily released with a little gentle prying.
bandwidthd is a great tool to graph traffic on your network interfaces, especially when you’re acting as an ISP for the better part of the city. Unfortunately, bandwidthd on Ubuntu Precise Pangolin (12.04) stopped getting updated at 2.0.1+cvs20090917-4.1. This package contains a pretty serious bug that causes bandwidthd to lose all data every 6 hours or so. Fortunately, there’s a more recent package (2.0.1+cvs20090917-5) with the fix committed, but it’s only available for Ubuntu 12.10+. (NB: 2.0.1+cvs20090917-7 has a dependency on a higher version of Apache than 12.04 has, so we’re ignoring it.) Solution: backport! (Here’s a dpkg that you can just dpkg -i if you don’t want to do it yourself.)
It’s actually not very difficult to do a backport, but it’s not trivial the find the correct instructions.
Grab all sources from LaunchPad: .orig.tar.gz, .debian.tar.gz, .dsc
dpkg-source -x *.dsc
dpkg-buildpackage -rfakeroot -uc -b
dpkg -i bandwidthd_2.0.1+cvs20090917-5_amd64.deb
You will probably also need to install build dependencies, but just apt-get whatever you need.
This could potentially all be automated with backportpackage, but I haven’t investigated yet.
Here’s an abbreviated tutorial for getting Kali Linux (1.0ish) running on a Cubieboard. (In case you’re wondering, Kali is the successor to BackTrack.) I use Berryboot as the bootloader, which allows us to multiboot and use compressed file systems (>50% compression, saving ~2 GB for a full install of Kali), and also makes it easy to swap around and play with different operating systems.
What you’ll need: a USB flash drive (~4 GB), Debian/Ubuntu Linux (e.g. Kali on VMware works great).
Begin by installing Berryboot onto a microSD card. The easiest way is to empty the microSD slot, boot into the built-in Android system on the Cubieboard NAND, download the Berryboot APK, and follow the instructions.
Install some tools on your Linux box:
apt-get -y install squashfs-tools kpartx
Now we need to build a squashfs image of the rootfs that Berryboot can boot form. We’ll do this the easy way: by modifying the Kali Raspberry Pi image. Download the image onto your Linux box (you do have a Linux box, don’t you?):
kpartx -av kali-linux-1.0-armel-raspberrypi.img
mount /dev/mapper/loop0p2 /mnt
Modify the mount point:
sed -i 's/^\/dev\/mmcblk/#\0/g' /mnt/etc/fstab
We need to configure the kernel modules that will be loaded. Note that Berryboot ships its own kernel modules, so we don’t need the actual blobs themselves. Create or overwrite these files (these are borrowed from the Cubieboard hwpack):
# /etc/modules: kernel modules to load at boot time.
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
#For SATA Support
#Display and GPU
# Workaround for dropping connections because power save
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0
Now we need to package up the rootfs we customized into a squashfs image:
Now we need to get the image onto the microSD card so that Berryboot can use it. Copy your new image (kali-on-cubie.img) to a USB flash drive.
Boot your Cubieboard with Berryboot (i.e. the microSD card inserted). Click “Edit Menu”. Click (and hold) “Add OS”, and you’ll get a dropdown menu; select “Install from USB stick”, and choose the kali-on-cubie.img we just created.
Instead of using the prebuilt ARM image for Raspberry Pi, we’ll build the rootfs “from scratch” (kind of). This lets us use the armhf architecture, which Google tells me is better than armel (Cubieboard has a more modern processor that supports the faster armhf instructions, whereas Raspberry Pi only supports armel). Also, we can customize the image, leaving out packages which we might not need in a memory/storage constrained environment.
After building the rootfs, we resume at step 6 above, of course substituting the actual path of our new rootfs for /mnt (which is the path of the rootfs that would have been mounted from the prebuilt image).
apt-get install debootstrap qemu-user-static
# define which packages you want here. If you want everything, add "kali-linux-full". See also this kali.list.chroot for ideas.
export packages="xfce4 kali-menu wpasupplicant kali-defaults initramfs-tools uboot-mkimage nmap openssh-server"
mkdir -p arm-stuff
mkdir -p kernel
mkdir -p rootfs
debootstrap --foreign --arch $architecture kali kali-$architecture http://archive.kali.org/kali
cp /usr/bin/qemu-arm-static kali-$architecture/usr/bin/
LANG=C chroot kali-$architecture /debootstrap/debootstrap --second-stage
cat << EOF > kali-$architecture/etc/apt/sources.list
deb http://http.kali.org/kali kali main contrib non-free
deb http://security.kali.org/kali-security kali/updates main contrib non-free
echo "kali" > kali-$architecture/etc/hostname
cat << EOF > kali-$architecture/etc/network/interfaces
iface lo inet loopback
iface eth0 inet dhcp
cat << EOF > kali-$architecture/etc/resolv.conf
export MALLOC_CHECK_=0 # workaround for LP: #520465
mount -t proc proc kali-$architecture/proc
mount -o bind /dev/ kali-$architecture/dev/
mount -o bind /dev/pts kali-$architecture/dev/pts
cat << EOF > kali-$architecture/debconf.set
console-common console-data/keymap/policy select Select keymap from full list
console-common console-data/keymap/full select en-latin1-nodeadkeys
cat << EOF > kali-$architecture/third-stage
dpkg-divert --add --local --divert /usr/sbin/invoke-rc.d.chroot --rename /usr/sbin/invoke-rc.d
cp /bin/true /usr/sbin/invoke-rc.d
apt-get install locales-all
rm -f /debconf.set
apt-get -y install git-core binutils ca-certificates initramfs-tools uboot-mkimage
apt-get -y install locales console-common less nano git
echo "root:toor" | chpasswd
sed -i -e 's/KERNEL\!=\"eth\*|/KERNEL\!=\"/' /lib/udev/rules.d/75-persistent-net-generator.rules
rm -f /etc/udev/rules.d/70-persistent-net.rules
apt-get --yes --force-yes install $packages
rm -f /usr/sbin/invoke-rc.d
dpkg-divert --remove --rename /usr/sbin/invoke-rc.d
rm -f /third-stage
chmod +x kali-$architecture/third-stage
LANG=C chroot kali-$architecture /third-stage
cat << EOF > kali-$architecture/cleanup
rm -rf /root/.bash_history
rm -f cleanup
chmod +x kali-$architecture/cleanup
LANG=C chroot kali-$architecture /cleanup
I was recently looking for a pair of Bluetooth headphones to isolate myself from the world without a cord tethering me to my laptop. I ended up settling on LG’s HBS-700 headphones due to spectacular reviews on Amazon. The cost of selecting the HBS-700, rather than its newer cousin, the HBS-730, was missing out on the apt-X codec, which is reportedly much better than the standard SBC codec that most Bluetooth devices use. But the HBS-730 noted terrible range and poor reliability, which really doesn’t work for me when I’m shipping these headphones 12 timezones away from the retailer. So I chose the HBS-700.
Despite the occasional typo in the user manual (yes, I do read user manuals for fun), first impressions of the device were pretty good. The device is light, well-built, and comes with a charge. The only problem I noticed was that sound quality was substantially lower than my cheapo Acoustic Research ARE-09s. Turns out that there is an easy fix for this; disconnect the headset, open Terminal and run this:
defaults write com.apple.BluetoothAudioAgent "Apple Bitpool Min (editable)" 53
For the HBS-700, 53 is the highest bitpool supported. By default my headset had previously negotiated a much lower bitpool, which corresponds a much lower bitrate. Interestingly, setting the minimum bitpool to 51 actually resulted in worse performance, because of the mismatch of sampling rates between the encoded audio I was listening to (at 48 kHz) and the SBC encoding (at 44.1 kHz). You can examine the negotiated bitrate using this command:
defaults read com.apple.BluetoothAudioAgent
According to the A2DP specs you can get a rough idea of how bitpools correspond to bitrates using the following table:
Table 4.7: Recommended sets of SBC parameters in the SRC device
Ever wondered why internet in the UAE sucks? I have a theory…
Etisalat runs a Great Firewall of UAE for HTTP traffic, and is overloaded and/or buggy.
Commonly accessed files are sometimes cached by the Great Firewall, and can be delivered/inspected/passed through quickly. However, less common files need to be fetched by the Great Firewall before being delivered to the end user. Because the Great Firewall is overloaded or buggy, it can sometimes inspect and deliver the first bytes of a file quickly before slowing to a crawl. For example, this could manifest as downloading a file at 300 KBps for a few seconds before dropping down to 50 KBps for the remainder of the file, or producing a sawtooth-like bandwidth graph. If it’s a large file, it could end up taking hours. Sometimes the Great Firewall is unable to do any caching due to cache settings on the web server, in which case it has to inspect the file each time it is downloaded (you will see this with the results from speedtest.net).
Encrypted data cannot be inspected and seems to be ignored by the Great Firewall. This suggests a few ways around the firewall: the most commonly used one is to VPN out. Another way is to use HTTPS. This is particularly useful with Google Maps, for example (http://maps.google.com/ vs. https://maps.google.com/). You can also see a pronounced difference when using Speedtest over an encrypted connection or not (https://dustin.li/tmp/st/ vs. http://dustin.li/tmp/st/ – this is my server in North Virginia). In my own testing, direct encrypted (e.g. HTTPS) connections outperform VPN encrypted connections, which in turn outperform unencrypted HTTP connections. We’re talking almost an order of magnitude – 4.83 Mbps HTTPS vs. 0.64 Mbps HTTP.
Etisalat’s DNS service occasionally slows to a crawl, which introduces non-bandwidth related latency. I have sometimes worked around this when I am at home by switching to Google’s DNS servers or my personal DNS server.