Profile cover photo
Profile photo
Beau Steward
Communities and Collections
View all

Post has attachment
Add a comment...

Goodbye internet. See you in a couple days.
Add a comment...

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.
Add a comment...

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.
Add a comment...

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.
Add a comment...

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 :/
Add a comment...

So I found out why the battery stats API was blocked in Android 4.4.

A google engineer, in deciding it'd be better to not support and expand standardization of reporting hardware usage, decided to block access to internal hardware monitoring. He says that it was not intended to be used by third party applications. He actually said that these apps will break sooner or later so they would prefer to break them sooner.

Their solution was to basically break an entire class of application for Android rather than make access to that information standardized or provide better handling of supported monitoring and metrics on the hardware.

Google, you are doing something bad here. I now have a problem that I cannot troubleshoot because of this. Because you bent to the will of Verizon and allowed locking of these devices (remember, Google owns Motorola Mobility and built the Droid lineup), and you broke this access, I can't fix my phone.

I'm now over 80% wakelocks. I can't find what's causing it. I've done everything short of wiping my phone and starting over. I really want to avoid this.
Add a comment...

Can't find what is causing my excessive battery drain on my phone. Might demand it to be replaced with a phone still on Android 4.2.2.
Add a comment...

So Verizon and Motorola finally released Android 4.4 for my Droid Mini. After a couple of days of usage, I wish they had not.

AVRCP remained broken. Some aspects of A2DP improved, but there were working pieces in 4.2.2 that are not broken.

Behavior of some events changed, which impact the functionality of some apps in a negative way. I'm having to use workaround for some things, and others I just have to tolerate.

Ever since upgrading, something keeps wakelocking my phone. I thought maybe it was the new Fitbit functionality, but that is disabled for now. I've been slowly going through various apps to try to track it down. Why going through apps rather than use something like wakelock detector? Because Google thought apps shouldn't have access to battery stats anymore, so without root, wakelock detector can no longer see who's doing what. I can see that wakelocks are around 60-70% and I can see something is constantly wakelocking the phone. It's causing excessive battery drain. What was really good battery life on 4.2.2 is now only slightly better than my old GNex.

So I can't root my phone anymore. I can't troubleshoot it. And I can't get the performance I had previously. Also, I can't roll it back.

When I got the GNex and found how awesome it was to have absolute control over it, I promised myself I'd stick to Nexus devices. The problem with this, though, is Google is following the trend of making phones larger and larger. I love the size of my Droid Mini. However, I now have to choose if I want a large device which I have control over, or a more sane sized device that is locked down.

This is so fucking obnoxious. I know Verizon played a major role in making sure the Droid lineup was locked down. It's one of the many reasons why, in March, I'll be separating from Verizon. Additionally, I think I'll just have to live with the fact that when it comes time to upgrade my phone again I'll have to buy a small tablet in the name of avoiding the bullshit control games.
Add a comment...

Post has attachment
For those wondering how I cropped my G+ cover image so that it doesn't take up the entire screen.
Add a comment...
Wait while more posts are being loaded