Debian Kit Part 2: External MicroSD config on Asus TF101

Some days ago I had managed to successfully and unfortunately soft-brick my Asus Eee Pad Transformer TF101 due to incorrectly using a Nvflash utility for SBKv1 devices on my SBKv2 device. Long story short: The fiasco led to the specially-made partitioning on my tablet's internal storage to be overwritten by garbage, taking the bootloader with it.

Thankfully it's not really that hard to completely flash the tablet back to normalcy thanks to Nvidia's nvflash utility and the tablet's APX mode. I managed to put the tablet back to Asus's stock ROM. Regaining root logins and privileges was trivial and now I managed to put in my previous daily driver ROM, Android Revolution HD, back into my Transformer.

To make my tablet two times as useful as it was at that moment, I've decided to reinstall Debian Kit. It is unfortunate that I had forgotten to back up the loopback image stored in my tablet's internal SD storage, so I had to reconfigure everything from scratch again. With that, however, I had the opportunity to do something different: I planned to put Debian on my tablet's external SD card, which is inserted on the right side of the tablet itself, not the one on the keyboard dock.

It is important to note, however, that most external SD cards are significantly slower than internal SD storages put inside most phones and tablets. The external SD card I used is a cheap class-2 16GB that I bought from CD-R king (of all places), so needless to say, my Debian install is going to be slow as fuck. Installing a package from the repositories for example, takes quite a long time, with most of the time wasted on unpacking, setting up, and installing the packages.

I partitioned the external microSD using gParted on my Thinkpad, with 12GB partitioned as ext3 (this is what Debian will use) and the rest of the remaining space as a FAT32 partition, because I don't think I'll be needing an entire ~16GB worth of space for an OS residing within another OS, especially when most of my work is done on the command line. It's formatted as FAT32 because apparently that and NTFS are the most convenient file systems that Android natively automatically mounts on its own. Following the instructions of a Debian Kit installation, instead of the usual opt to install the loopback image on a rather small 2GB file in the internal storage, I did the following with mk-debian:

# mk-debian -i /dev/block/mmcblk1p1 -d precise -t ext3

Where /dev/block/mmcblk1p1 corresponds to the 12GB ext3 partition that I had created earlier on my external microSD. Note that I did not use /dev/block/mmcblk1 because that corresponds to the entire block device, rather than one of its partitions.

So Debian Kit did its thing and installed a minimal install of Debian that for some reason follows the apt repositories of Ubuntu 12.04 Precise, so I can't really tell if it's Debian or Ubuntu, though I'll just settle on calling it Debian for now. Anyway, I digress. After Debian had finished its usual setting-up, I began to set up my installation according to my specifications. I followed most of the stuff on the Debian Kit manual regarding andromize, created a normal user for myself, adding sudo privileges for the said user, fixed the timezone being set in UTC by default, and reimporting my dot-config files from my Thinkpad. So far, so good.

Once I let the tablet go to sleep, however, either when it automatically does after a time period of inactivity or when I close the lid with the dock connected, the block partition "disappears". That is to say, when I get back to my Debian install through the terminal, and do a command such as ls, the command is strangely not found by the system. The same thing happened to cd. I then concluded that I the block disappeared and now I'm just running off the system from memory.

I figured that it was something wrong with my ROM of some sort. I noticed that whenever external volumes (SDcards, USB drives) are inactive and the tablet goes into sleep, Android automatically unmounts them, then remounts them back again when I wake the device. I did a little research on this annoying behaviour and found out that it's a "feature" made by Asus. I then hypothesized that Asus was extremely bright to unmount the entire device rather than just the partitions that it can read (which is to say, when the ROM decides to unmount the FAT32 partition /dev/block/mmcblk1p2, it takes the ext3 partition /dev/block/mmcblk1p1 along with it as well). Since Android Revolution HD branched itself out from the stock ROMs of Asus, the behavior persisted on my custom ROM.

I figured that the ROM only does this on filesystems that it naturally (in a sense that I can see and use them on the native Android interface) detects and supports, like FAT32. So I repartitioned my external SD card again, only this time I made the ext3 partition take up the entire storage space on the device. After that I made Debian Kit install itself on the newer, larger partition.

That is currently my setup as of now and thankfully /dev/block/mmcblk1 stops disappearing whenever my TF101 goes into sleep mode. However, I noticed that after a long uptime /dev/block/mmcblk1 eventually disappears again. I do not know at the moment if it happens during activity or inactivity, but very recently I left my Debian user account logged in overnight and when I tried to use it again the following morning it appears that my partition had disappeared once again. It's solvable with a reboot, but rebooting is tedious and takes some time.

I will look further into this problem and check for any solutions. Hopefully it's something related to my ROM and not any of my hardware. If that's the case, I'll just take a look at some sweet Android 4.1.2 Jellybean ROMs, and try them on my tablet.

Cytus: The "touchier" touch-based rhythm game

During the recent weeks I have been occasionally engrossed in playing Cytus, a rhythm game for the iOS and Android mobile platforms. Most people would probably take a look at the game and just pass it for another one of those catchy touch-based rhythm games that only become popular for a few moments then slowly and painfully die out into inexistence.

Cytus is especially unique due to it being completely designed for capacitative multi-touch screens. I have also played other touch-based rhythm games like osu! (more specifically its Android port, osu!droid) in the past, but osu! appears to be designed specifically for graphics tablets. Additionally, due to its user base consisting of mouse-trotting players, a good handful of songs available for osu! made by the players are optimized in favor of mouse players more than those who play with graphics tablets, or in my case, fingers.

Cytus is also relatively easy to pick up and learn. The gameplay is easy and intuitive. A black bar continually bounces up and down from the top to the bottom of the screen, with each direction of movement corresponding to a measure (though sometimes I think a complete round trip from top to bottom corresponds to a measure, I'll have to take time to study this). A black glow on the sides of the screen repeatedly pulses after every two 1/4 beats. Colored circles (that are colored by group depending on which trip the black line is going to and fro) pop up on the screen, and the player has to hit these circles alongside the music's rhythm. Then there are the sliders, which are a couple of smaller circles connected in a chain. The player has to slide their finger through the slider, hitting all of the smaller circles in the process. Then there's the freezes (or holds), where the player has to keep their finger on a large circle with a bar running underneath, and wait until the black line has finished traversing the entirety of the freeze bar. Because Cytus is specifically written for multi-touch screens, "jumps", where the player has to simultaneously press two or more circles at one time, can be easily implemented.

As of the time of writing, Cytus comes with 26 songs (2 are cleverly hidden, and one of the songs requires the player to like Cytus on Facebook or follow Rayark's Cytus Twitter account), most of them unique and highly enjoyable. A song in Cytus is about a bit longer than an average DDR song (most Cytus songs do not reach two minutes in length). Rayark (the development team of the game) announced that the current roster of songs in the game are currently incomplete, and there are at least a hundred more songs that are about to come out in the future. They created an interesting release plan---every hundred thousandth registered player of the game awards everybody with ten more songs, possibly an entire new chapter; with all the songs presumably unlocked for everybody by the time Cytus gets a million official players.

Notice my use of the word "official" in the last paragraph. Cytus is available for both the iOS and Android mobile platforms, though it is not free (as in both freedom and beer). iOS users are expected to shell out approximately two dollars to get to play the game. Android users can initially pay the game for free, but as they play on the second and third chapters, they must wait out a 30-second and 45-second "cooldown" period (respectively) before the song plays. F2P Android players also have song restarting disabled by default.

F2P players are not included in the release "census", for obvious reasons. Additionally, those who acquired the game illegitimately through black repositories for jailbroken iOS devices and leaked .apk's for Android devices are also (hopefully) not counted for the census.

I bought the game off Google Play (with the same price as the iOS version) because I've decided that taking a mandatory 30/45 second break between each song isn't fun.

I have a couple of gripes with Cytus, especially with the Android port, since that's where I play most of the time anyway. Firstly, the game rendering performance is awfully poor on my Asus Eee Pad Transformer TF101. I suspect that the primary reason for the lag is due to Nvidia implementing poorly-written Tegra drivers, where by doing so, they can effectively force game developers to optimize their games for the Tegra devices, rather than for every mobile GPU out there. The game runs smoothly on my HTC Desire HD, though there are some freezes here and there (but that's probably because of activities and apps fighting for CPU time in the background). There are also timing issues present within the Android port of the game, where a rather perfectly timed tap is registered with an annoying delay, turning some of my "Perfect" notes into measly "Good"s. So I can also hypothesize that some blame is to be put on the game developers themselves as well, probably because from my experience most games ported from iOS into Android are almost always badly implemented.

To solve the performance issue on my phone, I resorted to overclocking the CPU up to 1.2-1.4GHz, choosing the Performance CPU scaling governor, and/or closing every background activity and app that I can close. For my Transformer, however, overclocking the CPU doesn't seem to have any effect, nor does closing a couple of background applications. The only viable solutions I can think of are (1) just living with the game with bad lag and timing issues (I did get a couple of Million Masters with the tablet though), (2) Just play the game on my smoother phone (though thumb players will probably be a separate category for "competitions"), or (3) steal an iPad off an unfortunately picked friend who plays the game.

I also do hope that the game will offer its players the ability to import their own songs and use them in the game, though the iOS roots of the game will most likely prevent that from doing so, if the developers decide to make the iOS and Android versions of the game completely similar to each other in respect to features. It's the same thing that keeps "osu! for iOS" an unstable hack job for jailbroken iOS devices.

Doing some work on a novel

Some friends and acquaintances of mine have noticed me writing and working on some sort of manuscript. It's neither surprise nor a secret, I am writing a book. More specifically, I'm writing a work of fiction. I've been writing a lot of prose fiction ever since I wasn't even in high school, though some of those works were lost either accidentally or intentionally by me.

I have had a lot of ideas for writing a fiction novel during the last five years or so, but none of them ever even made past the simple 10,000 word count checkpoint. The reasons are probably because I can't find the time to work, and that I can't seem to string together a coherent plot that doesn't entirely sound like I hastily pulled it out of my ass.

I am not going to put in any specific details on this novel that I'm working on, nor am I going to hand out a plot summary of it. Those things will come once the first self-edits of every chapter and scene in my novel are done and I'll have to go find and coerce an unlucky person to edit my work again. But here's a hint for the persistent: It's set in (sort of) present day September 2012 in the Philippines, and it has something to do with international politics. It's a work of fiction that branches itself out from real-world events of that time. A lot of the places I used in my novel are also very much real. The genre is mostly thriller with bits of mystery thrown in here and there.

To prevent myself from slacking off and procrastinating by just deciding to play Sid Meier's Civilization V or Payday: The Heist all day, I've set a short term and two long term goals for my writing. The short term goal is, write at least 750 words a day. Does that sound too easy for a goal? Not really, especially when you're trying to make the plot as realistic, plausible and detailed as something you can find in a Robert Ludlum novel. I have noted a few days where I was not able to meet my short-term goal, or even wrote a single word on the pending chapter.

The long term goals are 45,000 words and 80,000 words for the entire novel. 45,000 words is 5,000 words short of the word count requirement for the National Novel Writing Month (NaNoWriMo), though I have some recollections of their word count requirement being only 45,000 or even 40,000. The second goal, 80,000, is the average word count of a lot of popular fiction novels. The 80,000-100,000 word count range is also comically referred to as the "zone where the publishers and agents actually take your manuscript seriously".

I'm writing my work in vim, typesetting it with LaTeX, and outputting it in a PDF using pdflatex, because who needs "word processors" anyway? I also wrote a small Python script that calculates the word count of each individual chapter and the entire manuscript itself, and calculates how much (in percentage) I have done to reach my long-term goals. There is a margin of error in its calculation of word count, however, since wc also counts my LaTeX comments and commands as words.

Hopefully by the next week or two I'll be able to finish the entire first draft of the manuscript. I'll begin editing by then, and at the start of November, I'll begin work on another novel to participate in this year's NaNoWriMo.