Feb 202012

How would you decide which tablet to buy? In particular, I wanted to determine which screen size would suit my needs. I wanted to be able to view rmls.com listings and read the occasional technical paper. I did some initial web-research, then visited my local Best Buy to get my hands on a variety of tablets.

My test? Google for “Paul McKenney Parallel Programming”, click on the LWN link and download the 358-page PDF. Then open it and test legibility in portrait and landscape mode.

I opted for the 10.1″ Samsung Galaxy Tab. I think the 8.9″ would have worked every bit as well and I preferred the slightly smaller size (with the same 1280×800 screen resolution). Unfortunately, they didn’t have it in stock at any of the Oregon locations and it didn’t come with the $50 gift card, eliminating the 10% savings.

I’ve only dabbled with the device so far and allowed a small gaggle of children to verify that the critical Angry Birds and Fruit Ninja “benchmarks” run beautifully. I will update once I’ve had some time with it.

I had hoped that the Lenovo X1 was a fluke and not a precursor of things to come when it comes to screen resolution in the Lenovo product line. Unfortunately, it seems Lenovo is continuing to release high-end notebooks with commodity screen resolutions. Their flagship mobile Thinkpad x220 as well as the new Ideapad u300s both sport 1366×768 resolution displays. Their competition, the 13″ Mac Book Air and the Asus Zenbook UX31 both come with higher resolution displays and much trimmer designs. I have loved my Thinkpads over the years, but unless Lenovo offers better displays in the very near future, my next machine will likely come from another manufacturer.

Today concludes my eleventh day in Prague attending three conferences and enjoying a few quick days of vacation with my wife.

Carsten Emde of OSADL was kind enough to invite me to speak on the Yocto Project at the Realtime Linux Workshop. I thoroughly enjoy hearing from members of industry, academia, and the Linux development community all at the same conference. I received a lot of positive feedback regarding the Yocto Project and collected my fair share of “todos”. Spending time with the leading Linux kernel developers is always inspirational for me, I invariably return with renewed commitment to improving my technical skills. After so many of these events, I consider these people my friends, and I so enjoy the trips that they feel more like a social event than a professional one. That, in my opinion, is how it should be.

Mary Lou joined me here in Prague while Grandma and Grandpa Mickelson braved our two children so she could get away for the needed break. She joined us on an OSADL sponsored walking tour of Prague covering the caste, lesser town, old town, and new town. We enjoyed the sights, the food was great, and some quiet time alone in a place where we had no responsibilities was wonderful. Her visit was long enough that she got to relax and enjoy her vacation, as well as look forward to getting home to our kids, our home, and our life.

Following our break, the Linux Foundation events began. The Embedded Linux Conference Europe (ELCE) and LinuxCon were held in parallel here at the Clarion Congress Hotel Prague. I spent a good deal of time at the Yocto Project booth, talking with attendees and catching up with team members. People were still trying to figure out how to spell Yocto a year ago when the project was announced. Now that the message has gotten out, there was a surge of interest – largely from people tired of maintaining their own frankenstein OS and looking for a solution. Others came by to be mesmerized by the Yocto Project 1.1 contributions visualization video rendered with the excellent gource project.

I attended excellent talks from Jonathan Corbet of LWN fame, Mathieu Desnoyers (EfficiOS), Grant Likely (Secret Lab), Stephen Rostedt (Red Hat), Frank Rowand (Sony), and Koen Kooi (beagleboard). The hallway track was also excellent. I met with developers and friends whom I only see online, including someone I had never met in person and hadn’t heard from in nearly 10 years when we hacked on some opensource projects together.

I wrapped it up with my presentation on tuning Yocto Project built images for tiny systems. Despite an imposing stack of 48 slides, I delivered the talk in the allotted time with room for questions without sending my audience into a speed-talk-stupor. I received some valuable feedback and made some useful contacts.

I am now exhausted mentally and physically. While I’m rather dreading the travel home, I’m very excited to be home with my family again.

gnome-3 The Linux desktop took great strides as GNOME and KDE migrated through versions 1 and 2 (and even 3 in the case of KDE). They literally caught up with the competition starting from the likes of fvwm2 and windowmaker in an incredibly short period of time.

Since then though, things have been sluggish at best. GNOME put a lot of work into the nuts and bolts which is a good thing, but didn’t do much to improve the user experience. KDE continued to blaze ahead with new technologies like Plasma and their white-screen-of-death… errr, maybe that wasn’t a feature. So GNOME 2 grew stale, while KDE became shiny and unusable.

While this was going on the GNOME Shell sprang into existence with lots of radical paradigm shifts in the desktop usage model. Not to be outdone, well not without trying anyway, Mark Shuttleworth began pushing Unity onto unsuspecting faithful Ubuntu users. Both of these have been met with significant resistance. While GNOME’s new desktop appears to have lovers and haters, Unity had haters and… well… sheep, but no lovers.

So no that Fedora 15 is out and ships with GNOME3 by default, I figured it’s time I gave it a fair shake as I did unity some time back. I grabbed the x86_64 Fedora 15 live installer and stuck it on a USB key using unetbootin.

So, first things first. Before evaluating GNOME3 I had to make some modifications so that I could do something other than complain about the defaults:
gnome-3-tweak

  1. Edit /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml and replace all title_vertical_pad values with “0″ (from the absolutely nucking futs default of 13).
  2. Alt-tab between “different windows” is broken by Gnome3′s window grouping. To switch back and forth between two windows of the same application (say two consoles for instance) use alt+~ instead of alt-tab. There are extensions to restore the by-window behavior, but this is simple enough and provides some added functionality.
  3. Install gnome-tweak-tool to be able to setup some decent fonts and font sizes, or alternatively just use the gnome-shell profile editor to select a console font manually. The rest of the fonts seem relatively sane.

This is just what I did to be able to tolerate the live-image from Fedora.

The Good:
gnome-3-windows

  • The death of the folders and files on the Desktop. I hate them – and yet I am simply not diciplined enough not to put them there. In this one case, I appreciate the system forcing better behavior on me :-)
  • Better use of the Desktop. I like the full screen menu, especially with groups and a search function. It’s easy, intuitive, and attractive. Having the panel and the workspace switcher all integrated into that view works well for my workflow.

The Bad:

  • Constant Accessibility icon. If I don’t need this now, I probably am not going to need it tomorrow (crossing my fingers).
  • The panel calendar opens evolution, and only evolution. Evolution sucks (and so does Coke, Casio algebraic calculators, the Chrome browser, and Emacs), we need a calendar service that other applications can provide. Having the address book, mail, and calendar all assumed to be evolution is annoying.
  • The current window icon in the panel… wtf is that all about? It serves no useful purpose that I can determine.
  • The categories list in the Activities->Applications view is very small in relation to the application icons, detracting from the very easy course mouse control required to select applications when you have to revert to careful precise control to select a category.

All the said, Gnome 3 is hands-down a much better integrated and implemented desktop environment than unity. Someone needs to take the developers rose colored shades away, and then I think we’ll have a nice Desktop solution.

lenovo_x1_i1 Lenovo unveiled their much-touted ThinkPad X1. It’s thin, it’s fast, it’s tough, it’s got a lot going for it… but the 13.3″ display comes in only one resolution: 1366×768. Really? 1280×800 was bad enough on the X201 and X220. Even at 800 vertical pixels I’ve run across the occasional dialog box with unreachable OK and Cancel buttons. Are you sure you want to format your root partition? It’s like russian roulette while guessing which of the off screen buttons – presumably [OK] and [Cancel] is selected by default! 768 is just silly.

I understand that most users probably don’t use 6 point font. They probably don’t care if they can only read three Facebook wall posts before having to scroll down. But isn’t there still a market for people that want a high-end screen with their high-end laptop? I’d pay another $100 for 1440×900, and I’m confident nearly every other software developer would as well. I find it a bit amusing that one of the images on the Lenovo web site shows a 3D modeling program on the X1 – not likely people, not with that resolution.

So how about it Lenovo, can we get an optional high resolution screen (as are made available on so many other ThinkPads, past and present) for software developers and other not-blind people?

Jun 012011

After slowly tweaking my bash prompt over several years I’ve finally arrived at something that I feel is simple, functional, and elegant. I’ve addressed my four primary annoyances with working in a terminal:

  1. Finding commands in the terminal scrollback is difficult.
  2. Long working directories cause awkward wrapping.
  3. I find myself using “git branch” and “git status” far too often.
  4. With so many terminals open, it can be difficult to distinguish between them.

I didn’t want fourteen colors, a clock, the date, and my ascii art gravatar in my prompt, so I’ve tried to keep it simple. To address #1 above, I’ve made my prompt green. This makes finding it in the noisy scrollback much easier. This uses escape pres, which are admittedly a bit nasty, but they get the job done:

\[\e[32;1m\]$PROMPT\[\e[0m\]

For #2, I used to show only the leaf of the path, but for *some* projects even this became problematic with pathnames like:

linux-yocto-2.6.37+git1+79669230fd82a3e7e254cf8b596a2388a4333e62_1+e53debfc6896bb89174ebb74154ed9b3bc72b59c-r18

So I took a page out of Joshua Lock‘s book and just ensure my prompt ends with “\n$ ” so my commands start on a new line and in the same column every time.

PROMPT="\u@\h:\w\n\$ "

For #3, also inspired by Mr. Lock, I did some digging and found a ridiculous number of heavy handed implementations, included some running ruby scripts to determine the current git branch. Ruby? Really? Turns out any modern distribution provides the very handy __git_ps1 bash autocompletion feature, so simply adding:

\$(__git_ps1 ' [%s]')

to my PS1 gets me the current branch in square brackets. To show the current state of the repository, including modified files, staged files, and things like being in the middle of a bisection, I export GIT_PS1_SHOWDIRTYSTATE=1 and add bash.showDirtyState=true to my ~/.gitconfig. This adds a * for modified, + for staged (*+ for both), and things like “|BISECTING” when in the middle of a git bisect command. Very handy!

Finally, for #4, I’ve found that setting the working dir in the titlebar of the terminal does a fair job at distinguishing between them. I don’t use many terminal applications (mutt, mc, etc) so the directory is usually adequate. I set a variable and then include that in PS1:

TITLEBAR="\[\e]2;\w\a\]"

In summary, the setup of my prompt in .bashrc is as follows:

if [ $TERM != "linux" ]; then
    TITLEBAR="\[\e]2;\w\a\]"
fi
GIT_PS1_SHOWDIRTYSTATE=1
PROMPT="\u@\h:\w\$(__git_ps1 ' [%s]')\n\$ "
PS1="$TITLEBAR\[\e[32;1m\]$PROMPT\[\e[0m\]"

This results in a prompt that looks something like this:

dvhart@doubt:~ [master]
$ touch test

dvhart@doubt:~ [master]
$ git add test

dvhart@doubt:~ [master +]
$ echo " " >> ~/.bashrc

dvhart@doubt:~ [master *+]
$ git reset --hard HEAD
HEAD is now at 8def692 bitbake TEMPLATECONF

dvhart@doubt:~ [master]
$ git bisect start HEAD HEAD~2
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[e82b229ca456cb77f1da310f7a6f966a4d5e2c95] use __git_ps1 in bash prompt

dvhart@doubt:~ [(e82b229...)|BISECTING]
$ git checkout master
Previous HEAD position was e82b229... use __git_ps1 in bash prompt
Switched to branch 'master'

dvhart@doubt:~ [master]
$

Update (7-Jun-2011): If you happen to use git to track your home directory config files, such as .bashrc and ~/bin you likely want to avoid using __git_ps1 in your prompt as it will show up pretty much all the time, and lose its effectiveness while working in your actual development project repositories. To address this, I’ve updated my prompt to only display __git_ps1 when the git top-level directory is not $HOME:

# Print the __git_ps1 string unless the git directory is $HOME.
function git_ps1() {
    GD="$(git rev-parse --show-toplevel 2>/dev/null)"
    if [ "$GD" != "$HOME" ]; then
        __git_ps1 ' [%s]'
    fi
}

if [ $TERM != "linux" ]; then
    TITLEBAR="\[\e]2;\w\a\]"
fi
GIT_PS1_SHOWDIRTYSTATE=1
PROMPT="\u@\h:\w\$(git_ps1)\n\$ "
PS1="$TITLEBAR\[\e[32;1m\]$PROMPT\[\e[0m\]"

As many of you are aware, I have been thoroughly enjoying working at Intel since September 2010. It provides me numerous opportunities to learn new things and advance my existing skills. It is also a very high performance culture with numerous incredible people to model. Coming to Intel as Kernel developer has its challenges. As a kernel guy, people expect you know the low level architecture – but compared to 10+ year Intel veterans (kernel or not) I find I have some catch up to do! Besides just Intel architecture, there are countless other things I want to learn and skills I want to develop.

  • Improve my git fu
  • Follow LKML,oe-core,poky
  • Contribute to PREEMPT_RT Linux
  • Master perf and lttng, in addition to ftrace
  • Internalize the nitty gritty details of the hardware boot process
  • Learn to use Eclipse (mostly so I can understand how others work)
  • Sort out GUI application architecture abstraction (for braindump)
  • Master the programming problems in texts like Hacker’s Delight
  • Read all the Linux kernel books ever written… or maybe just the ones on my shelves currently
  • And that’s just the mostly professional stuff…

I find I can make it partway into a small subset of these, but before I can truly master any of them, I’m pulled away onto some other high priority thing which brings an entire new set of things I need learn more about. I need to be able to assimilate information faster! My eyes and my brain just don’t seem to have the required bandwidth.

What are some ways you have found to master new skills and make deep technical information your own while keeping up with a dynamic work environment?

May 272011

I was debugging a problem in a codebase I’m none too familiar with this evening and decided it was high time I learned how to generate a callgraph in python. A very brief Google search landed me here http://stefaanlippens.net/python_inspect, and a commenter had exactly what I needed:

+                import inspect
+                bb.plain(" << ".join([i[3] for i in inspect.stack()[1:-4]]))

Which generates a very simple call graph:

parse << parse_file << worker << run << _bootstrap << __init__ << start << __init__ << Pool << start << __init__ << updateCache << runAsyncCommand << runCommands << idle_commands << waitEvent << main

Awesome module, thanks for the blog, and thanks for the comment!

May 222011

wordpress-logo A month back or so I started tinkering with converting my drupal blog to wordpress. While I liked the idea owning my data, the required maintenance for drupal was more than I wanted to manage. WordPress offers a much more polished administrative interface and is trivial to upgrade, customize with modules, and much more flexible in terms of theming.

To convert my blog entries, I tweaked the script listed here. Since I was using Vernon Mauery‘s Acidfree Drupal module for photo albums, I had my work cut out for me to complete the transition from Drupal to WordPress. I brushed up on my MySQL and wrote some python to convert the acidfree references in the blogs to NextGen Gallery references. The result is what you see here.

While I was planning on hosting this blog on my personal NAS, I decided in the end that I don’t want the NAS to be the primary source of any information: blogs, music, photos, or otherwise. The NAS is a backup, and the only way for it to be a proper backup is if everything on it resides elsewhere. I also didn’t care to have to manage the security issues of exposing my NAS to the intertubes.

As part of the exercise I really wanted to come up with that perfect title and sub-title, that catchy five-words-or-less phrase that succinctly and completely described me and everything I might ever decide to burden my readers with. Thanks to Joshua Lock and Vernon Mauery for listening to me obsess over it. In the end I opted to keep it simple, and make it easy for you to tell whose blog it is in your feed reader (which is how you should be reading all but this post!) So here it is, dvhart.com in wordpress form. If you followed my blog previously, please update your RSS feeds.

elc-rt-roadmap With the soon to be legendary “roadmap” Thomas Gleixner presented at the 2011 Embedded Linux Conference for the PREEMPT_RT patch series, people are likely wondering what that means for projects like The Yocto Project which make the PREEMPT_RT patch series available as part of a larger integration project.

It is our goal to maintain the linux-yocto recipes and git repositories as closely aligned with the mainline kernel as possible. This primary goal sets the schedule for which kernel version will be used as the basis for the next major release. 0.9 released with 2.6.34, 1.0 with 2.6.37, and 2.6.39 or 40 are likely to follow. These won’t necessarily align with the supported PREEMPT_RT kernel versions.

We have a few options. First, we could port PREEMPT_RT to whatever the next kernel version turns out to be. Second, we could release a separate kernel tree just for RT. Third, we could just not include PREEMPT_RT when the versions do not align. There is precedent for the first option, and indeed this exactly how we provide a 2.6.34 PREEMPT_RT tree with 0.9 and 1.0. We took the third option for 1.0 and the 2.6.37 tree, preferring to stick with the 2.6.34 version for RT kernels rather than do yet another forward port to 2.6.37, duplicating much of Thomas’ work toward a 2.6.38 PREEMPT_RT. This is time consuming, error prone, and doesn’t contribute to the overall quality of the PREEMPT_RT patch series as it is somewhat apart from that which Thomas releases. The second option, a separate kernel tree, is contrary to another key goal of The Yocto Project, which is to reduce duplication of effort. A separate kernel tree would require duplication of the meta branch, and all the bug fixes, security fixes, and feature sets would have to be applied to each tree.

Going forward, our approach to PREEMPT_RT will be as follows. We will strive to align with the official PREEMPT_RT releases. When that is not possible, we will favor skipping RT support in a kernel version or two just as Thomas does with PREEMPT_RT. In very rare occasions, such as with the 2.6.34 kernel, we may opt to forward port PREEMPT_RT to align with the current linux-yocto recipe’s base kernel version.