Making Linux and Android Get Along (It's Not as Hard as It Sounds)
The last, and slightly old-school way, to connect your Android device to your Linux box is via a direct USB connection. While this may evoke feelings of nostalgia for longtime gadget geeks who remember popping a Palm into a cradle and hitting the "HotSync" button, I find this to be the worst experience on newer devices, for reasons I'll explain below.
The Gingerbread (2.3.6 and below) Way
On Android devices prior to v.3.0, Google did the "right thing" to enable access to the device's filesystem. When plugged in via a USB cable, the device appears to be just another USB drive. You could move files to and fro, access documents directly on the device, and basically treat the phone or tablet just as you would any other thumbdrive (with maybe the exception of leaving it in your pocket to go through the wash).
Like SSHDroid above, once this USB storage was mounted, you could use any Linux tool at your disposal (Unison, Krusader, rsync) to make sure they were up to date. All was well, until Google tried to be too smart for its own good.
The Honeycomb (3.0 and above) Way
From Android v3.0 and up, plugging a device in via USB no longer shows up as USB storage (that is, the "easy way"). Rather, you're required to choose in the devices settings whether, on USB connection, you'd like the device to use the MTP protocol (that is, to appear to the other machine as a media player) or the PTP protocol (that is, to appear as a camera).
Now, I've read that there's a technical reason for Google's decision to do this, mainly that all applications and data now can reside on a single filesystem (as opposed to having to choose, for example, to install apps on the "phone" or on the "SD card", as I do on my OG Droid). All I would argue is that, for this user, those benefits do not outweigh the terrible experience of trying to use MTP on Linux (PTP actually works quite well, but only gives you access to the "DCIM" folder, so unless you want to store all your other stuff alongside the pictures taken by the built-in camera, this won't do).
I spent the better part of a weekend combing through posts on the XDA forums (http://forum.xda-developers.com"), which is a fantastic resource for all sorts of Android hacks, trying to find a nice, automated method of mounting the Prime's SD card. I found a couple resources (http://www.omgubuntu.co.uk/2011/12/how-to-connect-your-android-ice-cream-sandwich-phone-to-ubuntu-for-file-access and http://forum.xda-developers.com/showthread.php?t=1143044), but eventually settled on the script and instructions provided via this YouTube video: http://www.youtube.com/watch?v=3ehnoJn6CEk). After all that, I sat down, ready to see the Prime as just another drive in /media, just like the old days.
Well, not only is MTP access on Linux inconvenient to use, it's interminably slow. Once I got connected, I started copying my music collection to the Prime and left it plugged in overnight to do so. When I got up the next morning, it was approximately 5% completed. Before you start asking for transfer rates and whatnot, I don't have them, but I was able to transfer about half that same collection within a couple hours, and over SFTP (so with en/decryption overhead) no less. So I've pretty much sworn off direct connection for the Prime...there are so many other ways to shuffle files and data around, who needs it?
One of the great things about Android is that the ecosystem is free to come up with a variety of solutions to a problem and let users sort out which one best fits their needs. It could be that no one of the above alone will suit you—I myself use both SSHDroid and FolderSync on almost a daily basis. But all of the above apps are either free, or have free trial versions, so there's nothing stopping you from testing them out. Give it a try, and the robot and penguin will be getting along famously in no time!
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide