Yet the system’s name didn’t spring from nowhere. It’s inspired by a notion that’s even less tangible than a bunch of ones and zeroes; it describes, Obama said, the extent of Mandela’s compassion.
There is a word in South Africa — Ubuntu, a word that captures Mandela’s greatest gift: His recognition that we are all bound together in ways that are invisible to the eye; that there is a oneness to humanity; that we achieve ourselves by sharing ourselves with others, and caring for those around us. … He not only embodied Ubuntu, he taught millions to find that truth within themselves.
Some people have recently asked me about switching from an iPad to a Nexus 7. Did I have to give anything up? Am I still happy with the choice?
My conclusion: Nexus 7 is the better choice for geeks over an iPad. Of course, I think it’s a good choice for non-geeks too. :)
I like my Nexus 7 a lot. In most ways, it seems comparable to an iPad Mini (I had an iPad 2). There are some gotchas, especially if you’ve already invested in the iOS ecosystem. In my case, I felt the difference in price ($429 for a 32GB iPad Mini vs $249 for a 32GB Nexus 7) and features I wanted made up for that. Having used both, I would definitely still choose the Nexus 7 over an iPad. Whether it makes sense for you will depend on your use case. I’ve also read that Android devices are quickly becoming the better choice for anyone under 35 or so. I don’t know if that’s true, but my argument fits in with that pattern.
The Nexus 7 isn’t perfect. Most of the reviews (e.g., CNET’s) are pretty spot on, but these are some observations I’ve had that you might not hear elsewhere. They’re coming from a geek’s perspective with about 2 months worth of Android usage. I’ve been using iOS since 2008.
You can run software you’ll never see on the iPad (e.g. AdBlock for Android, an SSH/SFTP server so you can transfer any files you want over WiFi, etc.) Rooting isn’t required for these.
Real Chrome and Firefox browsers, as opposed to skins over Safari like you’ll find on iOS. This is important to me as a web developer, since Android browsers are supporting more and more advanced HTML5 features because of the competition that this opens up. No OS updates are necessary to get the new web browser features, either.
You can download any files to the device, which is really nice. I’ve lost track of how many times I wanted to add an MP3 from a website to my iOS music library, which is trivial in Android.
Related to that, I already have several Micro USB cables (as you might), so I’m happy that I don’t have to buy new, expensive cables just to use future devices. (That’s a part of why I’m considering switching completely to Android.)
It’s clearer to me that I can do something useful with this device when it’s 5 years old. The bootloader is completely open, so I could even run Ubuntu in the future if I wanted.
Installing and updating applications is nicer. Applications can be remotely installed with the click of an “install” button in your laptop’s browser, and they can be set to automatically update in the background if you want. On iOS, I go a long time between app updates, mostly because it’s a manual process.
Humble Bundle for Android meant that I had already purchased Android games when I purchased their Windows/OS X/Linux counterparts.
I still have “smart cover”-like functionality (closing the cover makes the device sleep) with the Poetic Slimline case. Note: not all cases support this.
I can play Vorbis audio, along with MP3s and AAC I purchased from the iTunes Store. That opens up music in my library that I could never play on iOS.
Given the choice between the mostly-closed iOS ecosystem and the Linux-based Android OS, using a Nexus 7 potentially helps the overall open source ecosystem.
It easily fits in my front jacket pocket which makes it really nice to use on a bus. (Even the iPad Mini would be too big.)
Gesture typing and widgets are much more useful than I thought they would be.
Fewer apps are specifically made for tablets right now. This isn’t often a problem, but you can tell some 3rd party apps were built with a smartphone screen in mind. More developers start by developing for the iPad first and then Android tablets. However, the marketplace may be starting to shift, due to popular Android tablets.
Sometimes, I’m surprised that things are slow. On occasion, I see the launcher slow down and restart. It might be a misbehaving widget; I’m not sure. But it has been noticeable, and I don’t remember it happening as often on the iPad.
If you already have an iOS device (like I do), you might have to find equivalents or repurchase some software. This hasn’t been a big issue, as most apps that I actually use are available on Android.
The Nexus 7 doesn’t have USB Mass Storage (UMS) like older Android devices, which means file transfer over USB is more difficult. It can use the MTP and PTP protocols, which aren’t as widely supported. This wasn’t something I knew going in, which makes a difference on Ubuntu (although Ubuntu 13.04 is supposed fix MTP support). Transferring music after mounting the Nexus with SFTP works fine, though it doesn’t integrate well with Rhythmbox.
If you download more than a handful of files, you’ll have to get a third party file browser or use SFTP to manage them easily. Also, files transferred with SFTP aren’t always picked up in media apps, so you may need to rescan on occasion.
There doesn’t seem to be hardware decoding of WebM video, which basically means that MPEG4 (.mp4, .m4v, etc.) is the only realistic choice for HD video. I would have expected this situation to be better in the Google-produced Nexus 7.
The Google Play Music app is generally pretty good, but it’s not as nice as the Music app in iOS. However, since there’s an open ecosystem, there are great third party apps like doubleTwist (my current preference) or Winamp (nice, but not a good option for tablets yet).
I hope this list helps out another geek who’s considering making the switch, especially if you’re the kind of person who cares about the types of things I noted. Like I said, I’ve been happy with my choice so far.
There were lots of good questions (which I wish I had written down), including how to use it with iTunes, how to use it as a replacement for logrotate, how I was using Vagrant for testing, how to automate more than set of rules, etc.
Takeaway: Debugging rsyslog and logrotate is easier when using Vagrant and logrotate‘s debug switch (-d).
I’ve been getting my hands greasy with more involvement in Ubuntu server maintenance lately, so I thought I’d share some of my experiences with debugging rsyslog and logrotate.
We’re using an EC2 instance running Ubuntu 12.04 (Precise Pangolin) to receive syslog packets from Heroku and elsewhere. They’re received with rsyslog, and we’re using logrotate to rotate and compress the log files. We’re being a little lazy right now and just letting everything go into /var/log/syslog. So far, that’s been a good choice as the machine only handles log aggregation. Most of the setup is similar to what Heroku recommends.
My first bump in the road was that which Ubuntu 12.04 doesn’t give rsyslog port 514 (the standard syslog port), unlike Ubuntu 10.04. This is because 514 requires root privileges. As a result, the port has to be above 1024, so I chose 1514 to make it easier to remember and know its purpose. It’s not completely clear why Ubuntu changed rsyslog to run under its own user (I would guess security reasons), but there is a bug report which helped me figure this out.
Following that I ran into an issue with getting logrotate to rotate the log files in the way we wanted. We decided that storing 30 days worth of logs, marking the rotation with the date, and compressing older logs would be best for our needs. It sounded easy enough to configure after looking at man logrotate and /etc/logrotate.conf. But it didn’t work! No matter what I tried, only 7 days of logs were retained, although compressing and adding a date extension worked fine.
It turned out to be a simple problem, but it’s more important to know how to debug these problems, I think. Below is what I did.
You probably don’t want to debug configuration problems directly on your production instance, or even on a staging instance. To develop the changes locally, I found that the easiest solution was to use Vagrant. They provide a precise64 box which was perfect for my needs:
From there, you can test logrotate with the -d switch. Point it to your configuration file and then see what it says it will do:
logrotate -d /etc/logrotate.conf
The problem behavior was clearly visible in the output; /var/log/syslog was only being kept for 7 days. Changes to /etc/logrotate.conf did not make a difference for the rotation count (but I could change to doing dateext). Around that time, started poking around in /etc/logrotate.d/, where I found /etc/logrotate.d/rsyslog.
This is the original configuration for /var/log/syslog:
After that point, it was simple to try my changes and retest using logrotate as above:
# NOTE: `dateext` means you can rotate at **most** once a day. Be cafeful setting it globally.
reload rsyslog >/dev/null 2>&1 || true
The debug output then showed it would retain the logs for 30 days. Great! It was then a simple matter of installing the same configuration in production.
While the result is important, I think the bigger takeaway is a process I can use in the future. With Vagrant and logrotate -d /path/to/conf in hand, future configuration changes are easier to develop, test, and deploy.