Moving to Fedora 19 Alpha!

Usually I wait until later in the pre-release cycle — a few weeks before Beta on average — before I move to the pre-release of the next Fedora operating system. But for Fedora 19, I’m too excited to see GNOME 3.8 and all the other improvements, so I tried out the Fedora 19 Test Candidate 2 (TC2) during lunch yesterday. I burned it to a USB key and was happy with what I saw. I decided it was time to move over now and fit in with the cool kids.

Getting ready to install

Now, I could have just thrown caution to the wind and installed right away. But since I wanted to move over on my main workhorse laptop, a ThinkPad x220, I really needed to back up my user files first. I hadn’t done that in a month or two (I know, I know!) so this was a must. I figured, if I was going to have a little downtime for the backup, I might as well make it worthwhile and install the Fedora 19 Alpha TC2 while I was at it. Thankfully, this afternoon was free of meetings so it was a good time to be offline for a short while.

I keep my backups in several places, but the easiest one to get to right away, with the fastest write speed, is a portable USB 2.0/FireWire enclosure I keep around for my own backups. It has a 500 GB SATA drive inside and plenty of room for my data. I was already running the Fedora 19 Alpha TC2 using the Live USB. I attached the disk, and of course it was mounted up for my convenience. I used the Disks utility to unlock and mount my home volume from the encrypted hard disk, and used the rsync utility to freshen the backup.

Installing Fedora 19 Alpha TC2

I decided to do a network installation rather than just burning a Live image. There were a bunch of other packages I wanted, and I figured I might as well grab them all during installation; plus, I wanted to see how that process was working. I burned the F19 Alpha TC2 boot.iso to a USB key and booted up.

I was hoping to hold on to my current partitioning setup as part of the installation process. I have a /boot partition on /dev/sda1, and an LVM physical volume with a single volume group, subdivided into separate logical volumes. Some are encrypted, including my /home folder. Unfortunately this is where I ran into my first issue — the current F19 Alpha can’t handle custom partitioning in the installer interface. I don’t believe this is required in the release criteria for an Alpha, so it’s not a huge surprise.

Nor was it a huge impediment; fortunately, the installer GUI is not tied that closely to the OS version or package content anymore. That means I was able to boot off a Fedora 18 boot.iso (written to USB), and simply point to a Fedora 19 mirror as the software source. I used the existing (and working) Fedora 18 installer GUI to do my required custom partitioning, so I could retain my current partition setup. Then I was off to the races, while I worked on other things.

Initial thoughts

There are some cool interface changes during login. A finished desktop screen expands nicely from the center rather than having elements appear gradually in sequence. There is some work being done on an initial setup routine, kind of like an orientation for new users of GNOME 3. It’s still a bit rough, and there are bugs, but you can see where things are going: it’s definitely a useful feature.

I love the fact that the screensaver reports notifications gathered while the screen was off. This would be useful for things like chat where you might want to know whether someone was looking for you before you decide to log in. I’m thinking of quickly getting on the console to answer IRC pings, but I suppose, reading back, it might just as easily be used to avoid people. Heh. But again, neat improvement. Another nice notification improvement: the larger bar introduced in GNOME 3.6 also now confirms for you that you have no new notifications, a nice added visual cue.

The control center has a smorgasbord of upgrades, from a privacy control, to per-application notification settings, to easier to read layouts for numerous controls including NetworkManager. And the overview search now is easier to read as well. And of course, none of the changes sacrifice my ability to navigate around by keyboard instead of mouse, which I really like.

Are there bugs? Sure, although I haven’t hit any identifiable ones yet. I’ll keep playing with the pre-release over the weekend and file some bugs as I poke around into the corners. But so far, I really like what I see, and I think Fedora 19 is going to be a great release!

DevConf.cz event, day 1 part 2.

I’m sure you already saw my post on part 1 of day 1 of DevConf.cz, right? Well, not much time for lunch afterward — this conference is packed with content! It’s also packed with friends from around the world. Here’s a few of mine:

There are about 5 minutes between talks, and a quick 15 minute break in between morning and afternoon sessions. So after said break, I attended the following sessions:

• Ales Kozumplik spoke about DNF, a next generation package management library and utility for Fedora. There’s an explanatory Fedora wiki page here.
• Michael Schröder presented on the functions of package management in SuSE, including libsolv (which underlies DNF). This included explanations of many of the additional functions in libsolv that can be cherry-picked if appropriate for Fedora.
• Vratislav Podzimek gave a fantastic presentation on the reasons behind and for the Anaconda NewUI. He showed the many problems and maintainability issues with the Anaconda we’ve had for something like 7-8 years in Fedora. He also demonstrated how the new UI presents a simpler, faster way to install in Fedora and even allows you to quickly craft custom “addon” spokes.
• Following this, I attended the Anaconda NewUI discussion in one of the hacklabs. A partial list of discussions that happened there:
  • Confirmed that Anaconda redesign is meant to make it possible for people with little or no Linux experience to use the installer.
  • Someone said that this is perhaps exactly why some experienced people struggle with the new UI. While acknowledging that such users would have to become accustomed to the new UI, apart from two cases (LVM on mdraid and [UPDATE: reserving space in a VG -- see comments below]) at this time the new UI can do everything the old one did. Completing storage configuration is more streamlined for the middle of the bell curve cases, but still can be done for the outlying cases.
  • Quite a bit of discussion about addons and what the vision is for them in Fedora. Chris Lumens expressed this really well; his opinion is that they would only be used in Fedora for things that are really helpful for the Project but in which the Anaconda team has no expertise. In concept, any particular site that wants to use addons would only use one, or maybe two. Throwing lots of addons at a user would be confusing and unhelpful. Anaconda team doesn’t want to set policy about when to use addons, probably this would be a FESCo matter.
  • There are many difficulties with choosing default languages based on simple measurements. Inevitably you end up making the wrong choice for a substantial number of users and it becomes difficult for them to continue or complete their task.
  There was more, but these were some of the major topics I heard while bouncing around trying to publish things to various networks about the conference.
• I also attended the set of short talks for the core OS. Although they were labeled “lightning,” they were a little slower paced, but still good content. I’d like to see the next DevConf.cz include real lightning talks — perhaps 5 minutes, timed mercilessly, and following each other rapidly with a high energy and entertainment level. But the talks themselves were quite good, and included Tomas Mraz on password quality with libpwquality, and Hans de Goede on the current state and future of the Spice protocol and tools. Hans’ demonstrations were especially high in “wow factor,” and featured splitting a window across two diferent guests’ displays, and drag and drop of files from host to guest.

Following the short talks, it was almost time for the conference event. I went back to the hotel to drop off my bag, and several times I narrowly avoided death by sidewalk ice. Thankfully I was walking with Fabian Affolter who would have been able to call for help if I slipped and broke anything important! (I had met up with Fabian and fellow Fedora luminary Gerrold Kassube earlier in the day.)

I quickly headed back out into the cold and a few blocks later, met up with our hundreds of attendees at Klub Fléda. There was a huge variety of good food and, of course, the omnipresent Starobrno beer. There was also live music on stage, with a power trio doing their best to entertain the sedate geeks customarily grouped together 10 meters away from the stage.

I was able to hang out a bit with some of the hardcore hackers doing great work to solve hard problems in the Linux world, including Kay Sievers, Lennart Poettering, and Harald Hoyer. I haven’t seen Lennart and Harald in a number of years — since I was in Berlin for a LinuxTag event. After a few hours, I accompanied Dan “Strikemaker” Walsh back to the hotel where we had a quiet round or two before retiring. All in all, it was a fine day and I was looking forward to day 2.

Speaking of which, stay tuned for a report for the second day of DevConf.cz!

DevConf.cz event, day 1 part 1.

I’ve been at the Red Hat Czech Republic office in Brno this week for meetings and RHEL-related work. But I organized the visit around this weekend’s DevConf.cz event, a conference for free and open source software hackers in Europe. The organizers in the Brno office have done a fabulous job of putting this conference together. I arrived a little later than I wanted, just before the start of the first session. That was mostly because we were out far too late the night before, bowling and having Czech pilsner with friends in the hotel basement bar! Anyway, we joined a small queue where we picked up the agenda, a ticket to the Saturday night event, and a cute gift: Red Hat branded gloves. These would come in handy in the cold and snowy, but beautiful, Brno weather this weekend!

I headed to the first DevConf.cz talk of interest to me, on color management. This talk mainly covered the current state of color management in Linux. It didn’t give me a lot of new information, but it was well done. The speaker did mention some of Richard Hughes’ work on colord. He also mentioned the ColorHug device for calibrating screen displays to get correct color. I need to pick up one of these! He also covered the OpenICC group’s formation. I have to admit, I was still just waking up, and didn’t have as much attention to give here as the topic deserved. So I apologize for the lame recounting here.

Next I sat in Debarshi Ray’s talk on GNOME Online Accounts (GOA) for users and developers. Debarshi did a great job showing how GOA works in GNOME. He had some videos that show accessing online documents from a local desktop. In the developer section, he also explained some current problems with increasingly popular 2FA schemes, and with specific service integration through GOA. Despite significant issues with some underlying frameworks needed for better GOA support, there are smart people working to solve these issues in GNOME, which was good to hear. This will give the platform a better foothold on the seamless sharing users have learned to expect.

My energy started to flag at this point, so I grabbed a quick cup of caffeinated soda and ran back upstairs to see Tom ‘spot’ Callaway’s talk. His topic was improving the Fedora user experience through design-driven methodology. I saw a version of this talk at FUDCon in Lawrence, Kansas, where it generated excellent audience interaction. I was curious to see how it was received in Brno. I was happy to see a huge turnout for this talk here at DevConf.cz. UPDATE: Spot’s slides are here (ODP format).

Spot talked about focus on user experience as the first step in development process, as opposed to “let’s write code now, and make this pretty later.” This is not a path that many open source development projects take, but it’s one that tends to produce great results for recipients. Spot followed up with some intriguing examples:

• The new HyperKitty system that allows users and contributors to interact in ways they prefer. HyperKitty also can help raise the signal to noise ratio by allowing forum-like ratings of posts.
• A mockup of a Fedora Smorgasbord app-store like application to succeed PackageKit, and abstract away confusing details users don’t need when trying to install or update.
• A mocked up solution to reduce friction when filing bugs, and frustration when dealing with them.
• A Fedora Badges app to produce better user affinity in Fedora. Badges can also give some insight into what users are doing, from running specific applications to participating in community events.

I stayed in the same room to hear Leslie Hawthorn talk about negotiation theory in FOSS projects. (You can find an excellent summary of the topic in this post on Leslie’s blog.) A fundamental lesson I took away was often we prevent a great result because we care more about a conversation’s outcome than our goals. Leslie is an entertaining and engaging speaker and I really enjoyed this talk. Hopefully I’ll get to hang out with her a bit at DevConf.cz. I feel like we’ve crossed paths often before, but somehow miss each other through happenstance.

And since I just used the word “happenstance,” I think it’s time to end this post and get lunch. Stay tuned for part 2 of DevConf.cz day 1!

PulseCaster 0.1.9 is released!

Yup, 0.1.9 has finally made it out the door. Here’s the tarball and the git repo. There are also updated packages coming shortly in Fedora 17, 18, and Rawhide. If you want to help test those to get them out sooner, look here for the package for your Fedora release.

Plus, did you know there’s a Facebook page for PulseCaster? Visit it, like it, and feel the love.

PulseCaster 0.1.9: The gruesome details

I have no witty release name attached to any of the releases, so let’s call this “The One Where We Figured Out How to Give People an Expert Option and Translations, Too.” Some of the secret features you’ll find in this release:

• An expert option
• Translations

OK, I’m being a bit snarky here. Mainly I’m trying to play all nonchalant about how long it actually took me to get around to working on another release. Here’s a better listing of new stuff in 0.1.9:

• PulseCaster now uses GTK+ 3.0.
• PulseCaster also now uses PyGObject and GObject introspection for most stuff. The GStreamer bits are still a bit rough in the gir code. Specifically I found it difficult to get at messages on the bus. I’ll keep working on that, possibly for 0.2.
• There’s now an expert option that writes the recorded streams to two separate files in lossless FLAC format, so you can mix your own recording later. The default mode still writes a single Ogg Vorbis file, which suffices for most people. (The code here’s more than a bit hacky and needs to be cleaned up in 0.2.)
• Using the excellent Transifex service, translations are now part of PulseCaster! Many thanks to the wonderful volunteer translators around the world who contributed translations to the release, and to the Transifex folks for their great service.

Future work

Some of the features on the current roadmap:

• Clean up messy separate-stream code (see above)
• Provide a recording pause button
• Do some volume leveling and/or compression to help recordings sound better
• Provide more helpful information on disk space available/used

As always, you can find the PulseCaster site at http://pulsecaster.org — bugs and enhancement requests are welcome. Input from users helped to drive (eventually!) the work for this release, so a tip of the hat to them for participating!

Not why but why not.

When you’re working on any project that’s Fedora related, and you need to ask questions of a team, the default should be to communicate the question on a public forum. If the conversation isn’t open and transparent, there needs to be a good reason why not. “Default to open” is a pretty well-known mantra in FOSS so this shouldn’t be too surprising or controversial.

There are certainly times where private discussion is warranted. Dispute settling (not to mention disclosure) is often best done privately. If you have to relate personal or security sensitive details of some sort, putting them on a list for eternal archiving may not be appropriate. There are other good examples out there. But in all these cases, it’s important to minimize their impact on public communication. In other words, strive to filter those bits that are best kept private, and keep the rest in an open and transparent discussion.

Every communication of an idea, discussion of implementation details, and canvassing for opinions is a chance to involve others in what you’re doing. If you keep it private, you’re missing out on one of the chief benefits of the open source way — involving others and enabling them to help you as well as themselves. The question is never “Why does this discussion need to be open?” — it’s “Is there any good reason this discussion shouldn’t be open?” And if necessary, as a follow on, “How can I separate the private part of this discussion so it doesn’t keep the rest from being open?”

As the Fedora community continues to grow and spread, we need to continue to teach this aspect to new members — and those who are experienced must lead by example.

Congratulations on Fedora 17!

I wanted to extend a hearty congratulations to the whole Fedora community on another great release.

I’ve already been using the Beefy Miracle since before Beta, and I’m very impressed with its stability and ease of use. A special pat on the back to Robyn Bergeron for her first release as the Fedora Project Leader. I remember well that the FPL’s first release is always filled with stress and anxiety, even though the whole community always works hard to ensure a smooth release. Robyn, now that you have your first release in the rear view mirror,* you should definitely relish the moment. (OK, you had to give me just one hot dog joke.)

There are a huge number of features in this release — thank you to all the developers and maintainers both upstream and in the Fedora community who helped make them possible. Fedora is possible because of the great work done upstream in the free software community and I’m grateful every day for the awesome software that allows me to freely pursue work and play using Fedora. If you haven’t seen the bonanza of awesomeness in this release, you should definitely check out the feature list.

Nice work, everyone — enjoy Fedora 17 and then, I guess, it’ll be time to get cracking on Fedora 18!

• Remember, objects may be closer than they appear.

It ain’t always what it’s supposed to be.

Lately I’ve found that I really miss playing music regularly. When I first joined Red Hat in 2008, the plan was for me to move up to New England so I could join most of my coworkers in the Westford office. As a result, I gracefully exited the musical projects I was involved in at the time, so they wouldn’t be hampered by my sudden move. However, a plummeting housing market in the DC area and my mother’s struggles with her spinal problems put the kibosh on my move, and circumstances led to me basically just working from home. That has continued to work out pretty well for both me and Red Hat, so I don’t see it changing any time in the near future.

The unfortunate result, though, is that I haven’t been playing music regularly now for several years. And that gets me right where it hurts — in my work/life balance. Anyone who knows me knows I put a high value on that balance. I’ve been better at achieving it over the past couple of years. But the question I’ve asked myself lately is “to what end?”. Sure, I get to spend more time with my family, but it’s not like we are busy every second of every night or weekend. So the question is, am I doing the best with that non-work time that I could? And the answer to myself was no. I was missing the fun of being creative, and that’s what music does for me.

So I decided to challenge myself to get back into the music scene in the local area. I wouldn’t say that Fredericksburg, Virginia is a bustling music marketplace, but we do have our share of venues and bands. There are some limitations: most of what people are playing around here is bar music, i.e. classic rock, country, and/or blues (or hard metal, which is just not my bag, baby). That means I have to do away somewhat with my predisposition, which is singer/songwriter stuff in the folk/rock/pop genre. Because when you’re playing professionally, you are working in a marketplace, and rule number one is, the customer is always right. And if the customer wants to hear “Gimme Three Steps” for the eight thousandth frickin’ time, then I’m going to do my best to chew it up — dig?

Letting go of my personal feelings about tunes I like (or don’t), though, has been easier to solve than another issue: finding great people to play with. I’ve done auditions for a while now, and I’ve discovered — or maybe rediscovered, since I probably knew this long ago the last time I was auditioning — that auditions are a two-way street. When I show up for an audition with a group, they’re not just seeing whether I’m good for them, I’m determining whether they’re good for me. So far the second half of that equation has been missing. So I’m trying to branch out beyond just answering ads, and try to meet other musicians who maybe aren’t actively looking. It stands to reason that many great musicians in the area are already hooked up with a group, simply because they’re great and everyone knows it.

Fortunately I’ve found there are worthwhile open mic sessions in the area. I’ve never done these before — I found all my previous work through referrals and recommendations, working with a series of steadily excellent musicians. Not being a born extrovert, I also found that I had some trepidation about attending an open mic. What if I didn’t know the tunes? What if no one wanted me on stage? What if none of the other players was any good? Then I realized all these what-if’s were basically killing any positive outcome before it even had a chance. If I went, sure, there was a chance it might not end up having value. But if I didn’t, then there was a 100% chance it wouldn’t have any value. So it’s pretty simple — just go, already!

It’s turned out pretty well so far — I’ve found that there are some truly great musicians around this area. Sure, they may all be in good bands already, but they also tend to know each other, and the way I look at it, if they start to know who I am, they’ll be able to give me or someone else a heads-up for a situation that might be good for me. The open mic is just as much a networking opportunity as a musical one. So by embracing that opportunity my hope is to get more wired into the local scene, make some new friends, and maybe find a referral to play with some great musicians again. I think the key is not just to go, but to keep going. That’s reinvigorated me, so that I’m practicing more on my own again — and it’s helped me shake the rust and dust off.

So today, I’m going out again to an open mic that was fun last Sunday, after which I’m headed off to another audition. And while the other guys are certainly going to audition me, I’m also going to audition them. So don’t just wish me luck — wish them luck too!

Discoveries, no. 577.

This past week I discovered the following awesome things:

• Moving from a 10-year-old DOCSIS 2.0 modem to a DOCSIS 3.0 modem, assuming your cable ISP is remotely in tune with the times, will make your bandwidth better.
• Moving from a 7-year-old (?) Linksys WRT54GL a/b/g wireless router to a new Netgear WNR3500L b/g/n wireless router, assuming you have a laptop with wireless-N, is well worth the investment (and the Netgear is equally hackable with open firmware).
• If you had a stressful day, playing Rancor Rampage on Kinect Star Wars with your kids is a great way to take the edge off.

Autotitles in screen.

This comes in really handy in ~/.screenrc:

shelltitle '$ |bash'

Then add this in ~/.bashrc:

export PROMPT_COMMAND='[ "$TERM" == "screen" ] && echo -n -e "\033k\033\\"'

Restart screen in a fresh bash session and enjoy.

UPDATE: I stupidly screwed up the screenrc line because I did it from memory instead of copypasta. No cookie for me!

UPDATE #2: Aha, found that something in the innards of my blog software was removing an extra backslash that was needed in the export command above. Sorry for the mess.

Snake for great justice.

I took some time last night to make a couple additional fixes and changes to the irssi-libnotify project I posted about a few days ago.

Among other things, I changed the upstream VCS from Subversion to git, which ended up being pretty simple. I’m much happier keeping the code at Google when I know the entire history resides with me, too. That way, I can move the upstream elsewhere if it becomes necessary. Thankfully, git-svn makes it incredibly easy to migrate, and there’s a helpful wiki page to help with the migration.

I did find that the site docs left out an important part (to me) of the process, which is migrating the authorship information properly. This page was useful to find a quick recipe to use with the SVN log.

For some reason, though, I was still on a hacking (or more precisely, “flailing”) kick. I was happy to have made some fixes to my project, but I’m not a big fan of Perl, so I checked out the current state of irssi-python. This project, as you might expect, provides a Python scripting interface for irssi.

Unfortunately, the project hasn’t kept up with irssi, so it isn’t easy to build. I found a patch for 0.8.15, which applied cleanly and got most of the way there. However, I found for some reason that upstream irssi doesn’t install some of the development header files needed to build irssi-python. I created a patch and a new SRPM that will allow the project to build properly, and also put my work in a git repo with a README file that will help you build it if you’re interested.

Once you install the plugin, you can do the following to experiment so you can build your own scripts:

/load python /py exec import irssi

Have fun!