Profile cover photo
Profile photo
Beau Steward
Beau's interests
View all
Beau's posts

Post has attachment

Goodbye internet. See you in a couple days.

So I bought an Asus Transformer Book T100TA (also called just T100). It's an Intel Atom BayTrail based tablet with keyboard dock. My intention was to install Android x86 on it and see what I could do with it. Unfortunately, some of the decisions Intel made in order to keep power consumption low and the hardware profile small to compete with ARM resulted in some consequences making it very difficult to do anything Linux based.

It comes with Windows 8.1 32 bit pre-installed. I can say that using Windows 8.1 on a tablet makes a lot more sense, but Microsoft kinda screwed things up by making a hybrid operating system environment (desktop and tablet/touch hybrid). The Windows market is very lacking in the software side of things compared to other tablet and phone markets so getting touch friendly apps is not so easy. Using plain desktop apps are definitely not touch friendly, especially at such a high resolution for such a small screen. And the funny thing is, the DPI on this tablet is derided as being too low! I might try to see if I can make some Windows DPI adjustments to make it a bit more touch friendly, but for the time being it's good that I have the keyboard dock.

The Windows touch keyboard is junk. I've gotten so use to Swiftkey that even the stock Android keyboard is not great. Apple and Microsoft could really learn something from the Android keyboard. Of all that I've used, though, the Microsoft one sucks the most.

The UEFI on this device is 32 bit and there is no legacy boot. This is where problems come in when trying to just boot an alternate operating system. Ubuntu is JUST NOW looking into supporting booting via 32 bit UEFI, and the only x86 based Android project looking at UEFI at all is Intel's Android-IA, which currently only supports 64 bit UEFI (though there's code in the source tree that is "experimental" for 32 bit UEFI boot).

Intel is banking on the BayTrail SOC to compete with ARM. As a result, their engineers are apparently working hard on the Linux support. The mainline kernel is showing new code from Intel to push for hardware support, but 3.12 has the beginnings of it, and we're not likely to see anything stable until 3.14. Android x86 and Android-IA are just hitting the 3.10 kernel so it's not likely to happen for some time.

For now, I'm attempting to adapt to Windows 8.1. Switching between tablet and desktop mode is very annoying and breaks UX so bad. I'm spending most of my time in the desktop environment but Microsoft made sure to make the touch environment unavoidable. There's suppose to be a service pack or something coming soon to make this a bit more bearable. However, I can pretty definitively say Windows 8 fits neither the tablet nor the desktop environment.

So what about the tablet itself? It's actually quite nice. The BayTrail SOC is the first to support out of order operations and is a quad core setup. The GPU is the same found in the third generation Core i series CPUs, though it's turned down a little to keep the TDP low. This is an Atom based system that supposedly can play some basic games, though I haven't really pushed it yet.

Asus did a pretty cool thing with the default install: The drive is encrypted out of the box using BitLocker. While this is likely to not keep government snoops out, it does mean Asus cares a little bit about user security. The built-in AES support in the CPU means there is negligible performance and power penalty.

I do have to knock Asus on something though. Their software spams info about 1TB of storage on their services, but you have to jump through a lot of hoops (ie: gain storage space through referals) to get it in 5GB chunks. You start at 5GB and work your way up. So much for registering your device and getting 1TB.

Overall, despite the setback of not being able to replace Windows 8.1, I'm happy with the device. It performs quite well (everything in Windows is smooth, almost buttery smooth) and so far does everything I could need in this platform. I can undock it from the keyboard dock and sit on the couch with it. It plays fullscreen video smoothly without needing specialized hardware like I've had to do with my past Atom based netbooks. It's also more compact that my past Atom based netbooks. For less than $400, it's an excellent device.

It's not going to replace my Core i7 laptop, but it fits in that space of usage I've been wanting in a portable computer quite nicely. I'll just have to be patient to get what I really want out of it.

My Mini's bootloader is unlocked! Let the hacking begin!

My phone now gives me a scary looking warning on boot about the potential damage I can cause by unlocking the bootloader.

So my phone has a locked bootloader using one of those fuse based bootloader locks. It uses a disassociated key and value (value is not derived from key) for the unlock code. This means it's nearly impossible to reasonably brute force the code.

Previous versions of the locking mechanism had exploits that could kill the lock permanently. The holes have been fixed and there are no known vulnerabilities for the versions used in current generation devices, including my Droid Mini.

A black market of sorts has popped up for unlock codes. It appears someone has access to the code database, or access to someone with that access, and they are now selling codes. I've seen prices ranging from $30-$45.

Basically, what has happened due to #VZW   and #motorola   shortsightedness is an attack vector for scams. Because they will not provide a trusted means of giving to their customers what they want, others have come up to profit on it, and, while I haven't seen it yet, others will come up offering these services and not delivering, exploiting the desperation of the people seeking this service.

The response from #VZW   and #motorola is likely going to be an attempt to shut down these sellers. As it becomes problematic to buy these codes, it will become easier and easier to scam people.

In short, #VZW and #motorola would rather see their customers take a risk at being scammed, possibly being scammed in ways other than by fraudulent financial gain (ie: cloning, tracking, etc), than to just do what everyone else knows is the right thing to do.

I know I made a mistake in buying a non-Nexus device. That will not happen again. Even if I end up having to carry a small tablet around.

Though, honestly, I'm getting more and more interested in a Firefox phone. I already have my own Firefox sync server, and I suspect this capability will extend to FirefoxOS. This would bring me to a major next step in removing my dependence on Google.

So I've been playing with doing things in parallel in Linux, without using GNU parallel. It's almost a pure bash implementation. It's sped up my MySQL backups by a substantial amount, combined with changing my compression.

So to do this in bash, you'll want a function to update your process counts for the jobs you are executing in parallel. I adapted a script a coworker gave me, which updates a global variable with the job count:

bgupdate() {
        bgcount=$(jobs -pr | wc -w)

With this done, the rest of the work is basically just using this function in a loop prior to executing your next job. I have a global variable that I can change as needed that contains the max number of parallel jobs. This is basically the meat of my dump:

for DB in $dbDatabase
        logmsg "Starting dump of tables in database $DB"
        for TABLE in $(mysql -u$dbUser -p$dbPassword -h$server --skip-column-names ${DB} -e "select table_name from information_schema.tables where table_schema='${DB}' order by data_length desc")
                while [[ ${bgcount} -ge ${jobsAtOnce} ]]
                        sleep 1
                logmsg "Starting dump of table ${DB}.${TABLE}"
                $cmdMysqlDump -u$dbUser -p$dbPassword -h$server --disable-keys --add-locks --skip-lock-tables $DB $TABLE | xz -$cmpLvl > ${dumpFile}/${DB}.${TABLE}.sql.xz &

While the number of background running jobs is greater than or equal to my configured maximum jobs, sleep for a second and check again. Once the number of jobs falls below the max, execute the next dump into a compressed archive. The ampersand at the end of the command is what launches the command in the background.

Once the last command in the queue executes, you have to bear in mind that these are being launched in the background so now you have to wait until there are zero background running jobs.

while [[ ${bgcount} -ne 0 ]] ; do
        sleep 1

With the change in compression and parallelizing my backup, my 5+ hour backup became a <1 hour backup, returning the slave server to the cluster after just 45 minutes. My larger database set that was taking 15+ hours to back up is now below 6 hours, with 1 table being responsible for that entire time, finishing all the rest in about 3 hours. Because it's all done in parallel, that means there's about 3 hours spent on one table. This is a huge improvement, and when the table is partitioned, it will be even faster.

I plan to do a similar trick to automated database restores.

This little trick is so obvious, I'm not sure why I'm just now coming across it. I'm using it quite a lot now as it's saving me time on many of my tasks.

I'm working on a variation of this for my MongoDB backups, now, because mongodump is even slower than mysqldump. mongorestore will be a challenge thanks to database level locks :/
Wait while more posts are being loaded