Impressions of My New Motorola Moto X (not really a review)

Sadly late last week my much loved Nexus 4 phone died. After much testing, it turned out to be a failure of the flash memory on which the system lives, and so the device is fairly well dead.

I’m pretty well determined to keep as close to the stock Android experience as possible. LG is pretty good at that, and they manufactured the Nexus 4, and it was a great price. However, it concerns me when an manufacturer sells me a product that dies less than six months past its warranty. So I am skeptical of LG right now.

That left me considering the Google devices and the Motorola devices. The Nexus 5 looks wonderful, and the price is excellent. I’ve heard many good things about it. And looking through the Motorola lineup, the Moto X stood out as the best option, even above their new “budget” models.

Between the Nexus 5 and the Moto X I was hard-pressed to decide. The Nexus 5 certainly had much better system specifications on paper, but the Moto X was incredibly well-engineered, and creatively so as well.

In the end, the creativity and engineering of the Moto X won out for me, even above the base system specifications. This decision was the more premium, price-wise as well, though not by a wide margin, considering a free bumper case was being included and Google charged a ridiculous price for shipping last time.

When all was said and done, I ended up with a new phone from Motorola, the Moto X, 32 GB of flash memory, a bumper case, an NFC clip that acts as an unlock, and a real walnut wood case, for $475, including tax.

Most satisfactory, except for the fact that I have to buy it at all, because my Google/LG Nexus 4 failed, and I was forced to. I think the main reason I chose the Moto X was because Motorola is the manufacturer, and every Motorola device I have ever owned has worked flawlessly, never dying, and survived everything I dished out to it. In my mind, Motorola has a reputation of reliability and durability, as well as engineering — and they are a company that takes pride in making a solid product as well. But I have to admit, having a real wood case was also a nice selling point.

Anyway, I ordered it, custom made, with walnut, gold metallic highlighting, orange bumpers, my name engraved on it (I never resell), and all sorts of little custom details about the software innards. It arrived before a week was out, and they were excellent about keeping me informed of the billing, build and shipping progress along the way. A completely satisfactory experience.

The Experience

This Moto X, first of all, is much more fluid than my Nexus 4. And the screen, even though it is less resolution, looks better. And best of all, this is the first of the smartphones I’ve owned that actually felt very natural and comfortable to hold in the hand.

Of course, being a Google Android device, it synced itself up all quick and nicely with my contacts once I connected my Google account. And the phone was great at pointing out things you should consider activating or doing as your started to break the phone in, customizing it even further toward your tastes.

I really was surprised at how fast and smooth this phone was. I was imagining that, despite what others had said, I would run into the occasional performance stutter, especially when all the apps were installing themselves as I was trying to do other things. But it didn’t. I don’t know what these Motorola engineers did, but they did something very, very right.

For a while now, I’ve slowly been getting myself used to dictating messages to my Android devices rather than typing them out. Always there is the occasional annoying glitch in its interpretation than you must awkwardly return to manually fix. Happily, one of the first things I noticed was that this Moto X was noticeably superior at voice recognition than my Nexus 4 was, and my Nexus 4 was damn good!

I think I remember reading somewhere that Motorola engineers added a small CPU whose sole purpose was to perform voice recognition. I suppose I should verify this before even mentioning it, but I’ll leave that for you to do, if you doubt my memory as much as I do. If they did, it certainly shows.

I remember thinking, when I first heard of it, how unsettling it would be to have a device that was going to be listening to you at all times. Particularly in an age when so many “true Americans” with “American values” have such a fetish for voyeurism and disdain for any privacy. But my Moto X is sitting right next to me, on the right. I know it hears my clicking keyboards, and maybe a fart. And of course, all the lies I tell myself when nobody is around. But it’s not looming there, like I imagined it might, with its own disturbing gravity of ears. Though perhaps it should. I don’t know.

But what I do know is that I love being able to yell out to it from across the room and have it answer or do something for me. Before, I thought, what a silly feature really. I can just hit the microphone button on the search bar and get the same thing. But there is something very different about it just being there, knowing you can just tell it something, at any time, or ask it something, as if it were actually something… in the room with you.

I think it’s impossible to describe. Just like how it feels in the hand. And just like how things move within the screens. And how it knows when you’re in the car driving, and will read out messages to you if you like, instead. These guys as Motorola thought of a lot of things, and they really did an amazing job bringing those things together into an actual working device.

I suppose it all boils down to, I like this phone. I like the Moto X so much that I’m even a little happy that my LG Nexus 4 died, just so that we could be together now. And I don’t have even the slightest hint of regret that I might be missing something, having chose the Moto X over the Nexus 5. In fact, I’m happy that I did.

Oh, I should also mention the camera. I like taking pictures. From what I was reading earlier, neither then Nexus 5 or the Moto X supposedly have the greatest camera. But I do like this camera better than the one I had on my Nexus 4. It takes beautiful pictures, to me. And the camera app is very fast. In another very clever design decision, Motorola engineers thought to make the camera start when you flick your wrist. I thought, how silly, really. But the thing is, it’s very useful! And it happens fast!

The thing I don’t like about the camera is that it seems very easy to blur the pictures. I think it must not have any image stabilization, or maybe I just haven’t found it to enable yet. So you have to be aware of your hand and body motion as you snap. This is a little bothersome, being so sensitive. Then again, for years with cameras, I had to worry about the same thing – always using the trick of holding your breath when you shoot to keep the lens from any distorting motions.

I would still say that is a minus of the camera. And really, that’s the only minus I’ve found – amongst so many pluses! The most peculiar and delightful thing about this phone is the pluses you never even thought would be there. The biggest being; the Moto X is just so damn comfortable to be around!

This device really is a truly wonderful dollop of engineering and design baked into a sweet package. It is understated, elegant, and intelligent, at all levels, and at any angle. I honestly don’t think I could be happier with a phone. I could just eat it!

My new Moto X with a walnut back! Picture was taken with my no-good Nexus 7 front-facing camera though, with lots of unsightly reflection from the plant's artificial sun.
My new Moto X with a walnut back! Picture was taken with my no-good Nexus 7 front-facing camera though, with lots of unsightly reflection from the plant’s artificial sun.

Creating a Samba 4 Domain Member File Server

Just finished writing up a piece on how to integrate a Samba 4 file server into an existing Active Directory Domain.

The odd thing is creating a Samba 4 server that doesn’t want to be authoritative, but is, instead, subject to another server for auth and permissions.

Not a lot out there I found for just a simple file server. All kinds of stuff for integrating a Linux system to use AD/DC for centralized auth — like user logins to Linux boxes — but not much on just being a file server, that doesn’t need all that extra rigmarole.

Hopefully it will help someone out… 😉


Wicked, New Orientations

The Truth of Vertical vs. Horizontal Key Layout
The Truth of Vertical vs. Horizontal Key Layout

Few things in life are definitively good or evil in their entirety. This is one of them.

I have no idea what these keys in the center of keyboards are named. What I do know is that recently some manner of vertical orientation was spawned, and it is an abomination.

Be very careful when you buy keyboards now or you may find yourself wildly scrolling back and forth uncontrollably in your applications, or typing over large swaths of text instead of inserting. Even jumping to locations you never intended!

This new vertical orientation is a most vile, confusing and even dangerous development. Be wary!

LVM Basics – A Quick Intro and Overview by Example

This article is published at Linux Tools of the Trade.

Storage technologies and methods can be a confusing subject when you’re first starting out, and depending on which route you choose, and how you organize them, these storage methods can continue to be confusing even when you know lots – unless you plan and organize well, at the beginning.

Take the time to think about what you want to have before losing yourself in the details of any given technology. And keep this in mind as you create.

Following is very generalized overview of some practical LVM use, presented in simple, no-frills terms. LVM tends to scare people away, seeming complex at first. And it can be, but it doesn’t have to be. This is the easy way, to get you started with LVM if you’re interested. You can make it harder (and perhaps better) later.

What is LVM? Why use it?

GNU/Linux gives you many options. LVM, the Logical Volume Manager is one of them. LVM lets you combine disks and partitions and even arrays of disks together into single filesystems.

LVM is very flexible. None of your storage media or arrays need to match up – you can combine a high performance PCI-e RAID10 array with an external USB 3.0 4TB hard drive if you like. Not always the best idea performance-wise, but often performance isn’t the most important thing.

LVM performs very well, too. Is your RAID0 SATA array running out of space? Add 2 more drives in another RAID0 and combine their capacities together. Or just throw in one new drive. It’s a messy way to do it, but you can. And it would still be fast.

Or perhaps you’re more sober, and want to create a SAN for your network, starting off with a 4-disk RAID10 with smaller drives. But you’re worried the space might fill up, and you can’t have the files span multiple filesystems. If you use LVM, you can just put in a second array at a later date, and expand your logical volume seamlessly.

 LVM Details

From a designer and administrator standpoint, you can think of LVM as having 3 main components:

  1. Physical volumes (devices or arrays).
  2. Physical volumes you bundle into made-up groups.
  3. Logical disks created and carved out of those groups you made.

This is where your planning comes into play (or not if you’re bad).

I’ve gotten into the habit of always using LVM to create the volumes which I will then format into filesystems. This gives me the flexibility to add more capacity, or take some away, at any point in the future.

The Debian distribution has long supported creating and installing itself into LVM volumes. Most of the major distributions now seem to support this as well.

So, using LVM, it’s a simple matter to take your 6TB RAID array and make a nice little root drive of 10GB for Debian, and a 5TB home directory, that you could then share with another 10GB partition you might make later for, say, Fedora.

Of course, you could partition your RAID array with extended partitions to achieve much of the same result, but you would not have nearly the flexibility later.

The Nitty Gritty

Working with LVM requires that you have the LVM tools. In Debian you can get these installed for you automatically if you choose to install onto an LVM volume, or you can get them later with

apt-get install lvm2

Instead of “normal” devices for hard drive volumes,  you’ll get logical devices that are create by the device mapper. In Debian, at least, they live under /dev/mapper and you also get a prettier version of the device names you create under /dev/<volume_group> — and you get to choose the <volume_group>

Creating Physical Volumes

The first thing you need to do is decide which devices you’d like to take over as LVM-controlled beasties. You can also specify individual partitions of disks if you like. The point being, you don’t have to even partition a disk first – you can specify the whole device if you like. Or partition it if you prefer. People will always argue over what’s best, and there is no clear winner. Which means, do what you like!

Let’s say you have 2 SATA3 drives, /dev/sdb and /dev/sdc. And you want to use them for LVM. The first thing to do is claim those physical volumes for LVM:

pvcreate /dev/sdb /dev/sdc

And lets suppose later you decide you also want to use your RAID 1 drive (/dev/md0) for LVM as well. You can designate any physical volume to be used with LVM, at any time.

pvcreate /dev/md0

Oh, I also have a USB 3.0 drive I might want to do something with:

pvcreate /dev/usb_drive_0

Do be careful though – consider any data on these destroyed.

Creating Volume Groups

Once you have some physical volumes in your system designated for LVM use, you can start grouping them up together. Creating volume groups doesn’t give you anything you can format into a filesystem, it just groups together whichever physical volumes you want to use into a named group that you can reference them by as one.

Think of it as the first abstraction layer — which of these physical devices do I want to group together and use as a big pool of space, from which I can make my littler hard drives.

You might want to consider how fast the drives perform when grouping. For example, you probably don’t want to group your super fast RAID array in with your USB drive. But maybe you’re fine grouping your RAID array in with your other SATA drives.

Yes, yes indeed, we’re fine with grouping our RAID in with our SATA drives. It will be fast. And the USB will be slow. How about we name these groups to reflect the fast and slowness of each. Maybe I can use the slow for backups?

vgcreate fast /dev/md0 /dev/sdb /dev/sc

That’s it. Easy to create a volume group. Just pick a name, like “fast” as we did here, and then list the volumes you want to use in it — ones that you created with pvcreate. And if you’re wondering, yes you can skip the pvcreate part above — but don’t — until you’re very sure that all this structure stuff is going to stick in your head.

Now, even though we only have one device in our USB drives, we may later add more nonetheless. So why not put it into an LVM group now – then later if we need to expand our backup area with more space, we can add a second USB drive, and just add it to this same group for instant gratification.

We’ll call this one slow:

vgcreate slow /dev/usb_drive_0

So we now have two spaces we can work with – the “fast” space, and the “slow” space. These are the volume groups. And we no longer have to care about which devices make them up. Well, until something goes wrong.

I suppose it’s worth noting that LVM provides no redundancy or backups, by default, although there are some great mechanisms built into it for doing so later, in some… interesting ways. So it’s really best to make sure your physical volumes have the level of redundancy and protection you want, before making those physical volumes into logical ones. I almost never make an LVM volume out of anything but a RAID array, unless I just don’t care that much about losing data, because I’m so awesome about backups (mm hmm).

Creating Logical Volumes

Now you can create logical volumes in your volume groups, and these logical volumes you can format just like hard drive partitions.

When you create your groups, LVM will allocate all the space possible on those devices, and make it available to you to create your logical volumes in. If you ever want to see how much space you have:

vgdisplay fast

You’ll get to see how much space you have, and also how much space has already been allocated to logical volumes.

Now, lets say I want to have a 100GB “disk” for my database files. Fast disk access is important for database work, so we’ll put that on the “fast” volume group:

lvcreate -n database -L100G fast

This will create a logical device of 100GB size called /dev/fast/database (at least in Debian). A more pedantic device name is also created called /dev/mapper/fast-database but I prefer using the first naming convention.

You can then use this newly-created device just like you would any hard drive. You can partition it if you like, or you can just create a filesystem on it:

mkfs.ext4 /dev/fast/database

Now, if you decide you just must partition these, they can be a little tricky to mount. Using a tool called partx you can extract that partition table out into devices you can work with, but we won’t go into that just now, here.

But if you skip the partitioning bit, these logical volumes mount just like normal filesystems, except really, they can be coming off of any number of drives in your volume group.

mount -t ext4 /dev/fast/database /var/mydatabase

Easy as pie! (when you don’t have to make the crust)

The same holds true for your slow USB drive:

lvcreate -n backups -L 2T slow
mkfs.ext4 /dev/slow/backups
mount -t ext4 /dev/slow/backups /mnt/backups

Here we created a “drive” of 2TB called “backups”, formatted it, and mounted it at /mnt/backups. This would be our USB drive.

Adding More Drive Space to an LVM Logical Volume

Now that we’re demystified, and have been using our system just fine for weeks, we ended up filling up our /dev/slow/backups with backups. Let’s say our USB drive was 3TB. We only allocated 2TB to our logical volume for backups, so really we have 1TB left free in the “slow” volume group. We could see this with

vgdisplay slow

So, if we wanted, we could just increase the size of our logical volume /dev/slow/backups to eat up that extra 1TB that exists in that volume group, and so give us the full capacity of that USB drive:

lvextend -L+1T /dev/slow/backups

Here we give a relative size in the -L parameter, saying we want to add 1TB to the already-allocated size of 2TB, making a total of 3TB. Of course, this doesn’t make the filesystem bigger, just the “disk” the filesystem is on. But ext4 is easy to resize:

resize2fs /dev/slow/backups

By not specifying a specific size, resize2fs will just make the filesystem as large as it can on that “drive”. And you don’t have to take the disk offline either — this is an online resize, and I’ve never had it fail. But of course you should do it offline. But I never will.

You can also shrink filesystems and volumes, but I’m not going to go into any of that here because shrinking filesystems is unnatural.

But suppose even 3TB is not enough for your backups. Well, it’s easy to add a new device to a volume group, and make it available for logical volume to eat up in its gluttony.

You buy another USB drive! So now we need to add it to the “slow” volume group. You got a good deal on 4TB drive this time. So you have your original 3TB one, and now a 4TB one you’re going to use to expand your storage. Assuming it’s assigned /dev/usb_drive_1

First, create the physical volume, as usual:

pvcreate /dev/usb_drive_1

Then add it to your “slow” volume group:

vgextend slow /dev/usb_drive_1

After you do that, if you look with

vgdisplay slow

You’ll see that you now have a whopping 7TB volume group called “slow”.

Then you just do the same as above to extend your logical volume, or “drive”, for your backups:

lvextend -L+3T /dev/slow/backups
resize2fs /dev/slow/backups

Et voila! You now have a 6TB backup “drive”, because you didn’t use the full 4TB off the new one. You left 1TB free in the “slow” volume group, because you’re not always a complete hog, and you may like to use that 1TB for some other volume in the future, like:

lvcreate -n pron -L1T slow
mkfs.ext4 /dev/slow/pron
mount -t ext4 /mnt/relax /dev/slow/pron

Because, well, if not a hog, then perhaps a pig. Oink.  And that uses the last of the drives.


You can, of course, remove devices from LVM groups as well. You just need to make sure you have enough space in the volume group to do so. For example, if you have 2 USB drives, one 3TB and one 4TB, making a total of 7TB — if you’re using up 6TB in logical volumes, you won’t be able to take away either of those USB drives, unless you can shrink down your logical volumes first (after shrinking your filesystem first, unless you like agony).

The point being, LVM is quite flexible.

One of my other favorite features is the ability to take a live snapshot. This is great for backing up whole disk images of a live-running system. You create an LVM “snapshot”, and then you can dump that image anywhere you like, and the filesystem will be in a consistent state, even with the system running. It’s wonderful for virtual machine images especially.

But I’m not going into that either here, just  yet.

Hopefully this might have helped you a little. I remember when I was first looking at LVM it was a confusing mish-mash of all these different options, and nothing spelled it out simply. Hopefully, this has managed to do so, if you’re looking to get started with it, for play or production.

And as always, check out the man pages. There are lots of other places out there too with more detailed and specific use cases and feature examples.

Honestly, using LVM has changed everything for me. It’s certainly worth looking at. Best to you!