The NDK is a GCC-based cross-compiler that lets you embed object code in a traditional Android app. It also works as a standalone cross-compiler, though it is not advertised as such. It is quite rough when used by itself, and agcc wraps the complexity in a little script. While agcc and agcc2.pl are written in Perl, agcc.bash is a Bash script. It also supports the latest revisions of the NDK, though r7 is slightly buggy.

With agcc.bash, building native Android software feels almost like working with GCC. As a quick example, let’s try the classic hello world:

AGCC_NDK=~/android-ndk-r6 ./agcc.bash hello.c -o hello

That wasn’t too exciting… but what happened there? I have the NDK installed at ~/android-ndk-r6 and I told agcc.bash where to look for it, using the AGCC_NDK environment variable. I then invoked agcc.bash as if it were GCC. Let’s see what agcc.bash did behind the scenes:

AGCC_NDK=~/android-ndk-r6 AGCC_ECHO=yes ./agcc.bash hello.c -o hello

=> ./agcc.bash hello.c -o hello
<= /home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gcc -o hello -I/home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/include -D__ARM_ARCH_5__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -DANDROID -DSK_RELEASE -DNDEBUG -UDEBUG -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -fno-exceptions -ffunction-sections -funwind-tables -fmessage-length=0 -march=armv5te -mtune=xscale -msoft-float -mthumb-interwork -fpic -fno-exceptions -ffunction-sections -funwind-tables -fmessage-length=0 hello.c -Bdynamic -Wl,-T,/home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/arm-linux-androideabi/lib/ldscripts/armelf_linux_eabi.x -Wl,-dynamic-linker,/system/bin/linker -Wl,–gc-sections -Wl,-z,nocopyreloc -Wl,–no-undefined -Wl,-rpath-link=/home/jyio/android-ndk-r6/platforms/android-8/arch-arm -L/home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib -nostdlib /home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib/crtend_android.o /home/jyio/android-ndk-r6/platforms/android-8/arch-arm/usr/lib/crtbegin_dynamic.o -lc /home/jyio/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/lib/gcc/arm-linux-androideabi/4.4.3/libgcc.a -lm -ldl

See how it transformed our innocent little command into a monster! This might be overkill for a hello world program, but it provides pretty good support for more complex software such as OpenSSL, cURL, and Python. It would be a good idea to add the NDK toolchain and agcc.bash to $PATH before trying to build a big program. In my case, the toolchain resides in ~/android-ndk-r6/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin. If you want to build some software that come with configure scripts, you might start with:

CC=agcc.bash ./configure

Do try this at home! Relevant links:

• Android NDK r6 (or, the latest version)
• agcc.bash
• hello.c

on the left, a stripped candle

So I scraped the wax off one of the candles and found some gray flakes (fairy dust!) surrounding the wick. The material could be seen through the thin layer of wax along the entire length of the candle. The sparkling effect suggests that the flakes are metallic. They should also have a low heat capacity and autoignition point, so that even after the flame appears to be extinguished, they are warm enough to continue burning and light the candle again. What are these metallic flakes? I burned a candle to find out.

burning the candle

The white sparks of light were reminiscent of burning magnesium. Magnesium burns at or above 473 °C (883 °F), which is more than sufficient to ignite the paraffin vapor streaming away from a recently-extinguished candle wick.

magnesium turnings on fire

Other metals could be added for a variety of spark colors.

Gone

The requested resource
/
is no longer available on this server and there is no forwarding address. Please remove all references to this resource.

His other websites, as well as social networking accounts, have also gone:

• Dive Into Python
• Dive Into Python 3
• Dive Into HTML5
• GitHub (though it seems that someone has re-created the account)
• Twitter
• Google+
• Reddit

His personal site is missing, too.

Whoa. How does someone just evaporate off the Internet like that? The search continues, but there may be a ray of hope…

Pilgrim has shared an incredible volume of information with Internet users everywhere. I hope he is alright.

Update:

ultimatebuster pointed me to firehose.diveintomark.org [ATOM], which contained recent Twitter activity; the site is now inaccessible, so the link points to my personal mirror copy.

Jason Scott called Pilgrim’s local police department, and Pilgrim was less than amused…

I called his police department to ask for a welfare check – someone had done it 4 minutes before me.

Mark Pilgrim is alive/annoyed we called the police. Please stand down and give the man privacy and space, and thanks everyone for caring.

The communication was specifically verified, it was him, and that’s that. That was the single hardest decision I’ve had to make this year.

… and that’s that!

As before, the VM is named mustard, my username is inportb, and this file is called /etc/init/mustard.conf…

description “mustard VM”
author “Jiang”

start on (local-filesystems and net-device-up IFACE=eth0)
stop on runlevel [016]

console output

respawn
respawn limit 5 10

pre-stop script
su inportb -c “VBoxManage controlvm mustard savestate”
end script

exec su inportb -c “VBoxHeadless –startvm mustard”

As soon as the local filesystems are ready and the network is up, Upstart would run VBoxHeadless and monitor the process. Should the process die unexpectedly (such as if someone hits the guest’s shutdown button by mistake), Upstart would bring it right back up. Furthermore, if some problem keeps terminating the process soon after starting, Upstart would stop trying after 5 bounces in 10 seconds. The “correct” way to start and stop the guest, respectively, would be through the host…

sudo start mustard
sudo stop mustard

Before we start, here’re the guest specifications that we’re looking for…

• VM name mustard
• RAM 1 GiB
• SATA controller with 20 GiB disk at mustard.vdi
• IDE controller with CD/DVD at installer.iso
• Bridged networking using host adapter eth0
• OS Windows 7

Create machine and disk…

VBoxManage createvm --name mustard --ostype Windows7 --register
VBoxManage modifyvm mustard --memory 1024 --acpi on --boot1 dvd --nic1 bridged --bridgeadapter1 eth0
VBoxManage createhd --filename mustard.vdi --size 20480

Create SATA controller and attach disk…

VBoxManage storagectl mustard --name “SATA Controller” --add sata --controller IntelAhci
VBoxManage storageattach mustard --storagectl “SATA Controller” --port 0 --device 0 --type hdd --medium mustard.vdi

Create IDE controller and add disc…

VBoxManage storagectl mustard --name “IDE Controller” --add ide --controller PIIX4
VBoxManage storageattach mustard --storagectl “IDE Controller” --port 0 --device 0 --type dvddrive --medium installer.iso

The proprietary version of VirtualBox exports a nifty RDP service that you can use to set up the machine. With VirtualBox 4+, the proprietary extensions come in a separate package. Note that the local and remote mouse cursors are not synchronized, so it may be somewhat difficult to operate. Starting the machine is simple…

VBoxHeadless --startvm mustard

After installation, I’d recommend setting up RDP from within Windows (or SSH in a UNIXy guest), because of the subpar VirtualBox RDP experience. If you want, change the boot order and remove the installer CD/DVD…

VBoxManage modifyvm mustard --boot1 disk
VBoxManage storageattach mustard --storagectl “IDE Controller” --port 0 --device 0 --medium emptydrive

… and that’s that! Since I’m using an Ubuntu host, my next post deals with how to start and suspend this VM during boot and shutdown.

How do you get this particular OS update on a second-generation Kindle? Well, let’s just say it’s not officially supported.

Look at the pretty pictures.

The Bloxes website features construction images as well, and the process is similar.

They’re not exactly inexpensive, and shipping takes a while. Instead of ordering bloxes, I decided to prototype my own on paper just for fun. This design might require some modification for use with cardboard (in particular, I’m sure you could figure out how the original design works and apply it to your project).

If you have the resources, go ahead and roll your own cardboard modules. As usual, it’s easier said than done…

Ubuntu 11.04 dropped yesterday, and I’ve taken the opportunity to install some other user interfaces marketed for touch-centric devices. The GTK-based virtual keyboard (onboard) is also inadequate.

Unity has just replaced GNOME on Ubuntu, and Canonical is putting all its support behind it as a mobile platform.

• It’s lightweight, and it starts up quickly.
• The dock/launcher on the left side supports the “grab&drag” gesture for scrolling.
• The full application menu can be accessed by a quick tap on the upper-left corner, and has large, finger-friendly buttons.
• The dock hides as soon as an application opens, and displays when the user pushes the mouse cursor against the left edge of the screen (or upper-left corner); this is somewhat awkward for touchscreen users.
• In fact, there are a number of hover-dependent events that are difficult or impossible to trigger using a touchscreen.

GNOME Shell was kicked out in favor of Unity, but it’s also supposed to be finger-friendly. I had to add a PPA, and the installation completely broke the theming across all GTK applications, but this was expected and understandable.

• It’s very accessible without a mouse, and nothing becomes unusable because of specific mouse requirements.
• The “grab&drag” gesture is well-supported, including for window management; windows could be dragged between virtual desktops.
• There’s also a long-press gesture for accessing context menus.
• Virtual desktops are added and removed dynamically; there is always an “empty” desktop on the bottom of the list, which creates a new desktop when a window is dropped on it.
• The dock on the left scales in size as icons are added and removed from it, so there may be problems with a long list.

Plasma Mobile is only a technology preview at this point. It doesn’t even come with an Xsession script, so I had to run plasma-mobile to start it. The interaction is very smartphone-like, with “grab&drag” supported everywhere (including widgets). However, “everywhere” is relative because Plasma Mobile does not have an application launcher at all.

Xfwm is my touch-agnostic baseline. I keep XFCE around on a separate partition so I could use Ubuntu+1 on my main partition and have recovery tools if/when it breaks. The touch screen works mostly like a mouse, in this case. Docks are all the rage these days, and XFCE is no exception; it auto-hides under the bottom of the screen, so it’s also somewhat difficult to reach.

In my opinion, a compelling touchscreen experience must provide, in no particular order:

• “grab&drag” and long-press gestures
• a virtual keyboard on par with those of Android and iOS, or a graffiti-like text input mechanism à la PalmOS
• multitouch, if possible
• differential treatment of screen and mouse inputs, so that the mouse doesn’t trigger gestures or virtual keyboards and can be used for precision manipulation

What do you think is important in a touch interface?

During the downtime, EveryDNS/DynDNS kept the DNS service going and Freenode chugged along as usual. The wiki was completely wiped, but I managed to scrape most of the text from caches everywhere; it will be returning shortly, and I’ll probably need some help moving the cached content to their rightful place.

Until next time