Category Archives: General

Everything else

Holiday Break 2017.

My work with the Fedora Engineering team has been a whirlwind this year. Of course, with lots going on in the releases and infrastructure, between modularity, continuous integration, Atomic, and more, there has been plenty for everyone to do. With both new and departing folks on our team there’s also been people-related change as well. I can easily see and feel the incredible effort going on in so many parts of Fedora these days.

I now contribute in a few areas, such as the Workstation working group. My own biggest personal contribution to the project this year, though (outside people management), has been to the Fedora Magazine. Ryan Lerch was responsible several years ago for resuscitating the Magazine into a vibrant, useful resource for our users worldwide, and I was happy to jump in and help when I found out about the great work he was doing. This year we were also fortunate to have Justin Flory serving for a while as editor in chief.

Now Ryan and I are happily keeping things chugging along, though. This year we set a goal for three million page views. And as of yesterday, we hit it! That’s not just an accomplishment for the Magazine folks, though. It means that Fedora news and information is reaching more and more people worldwide every month. In light of reaching this goal, it’s nice to sit back and take a breath to enjoy the scenery.

And that of course brings me to my annual reminder about what the holidays mean for Fedora team availability. Once again, I’m going to crib from an earlier post:

My good friend John Poelstra is fond of saying, “It’s OK to disappoint people, but it’s not OK to surprise them.” That wisdom is a big reason why I like to set expectations over the holidays.

Working at Red Hat is a fast paced and demanding job. Working full time in Fedora is itself demanding on top of that. These demands can make downtime at the holiday important for our team. At Red Hat, there’s a general company shutdown between Christmas and the New Year. This lets the whole organization relax and step away from the keyboard without guilt or fear.

Of course, vital functions are always staffed. Red Hat’s customers will always find us there to support them. Similarly, our Fedora infrastructure team will monitor over the holidays to ensure our services are working nominally, and jump in to fix them if not.

Some people like to spend time over the holidays hacking on projects. Others prefer to spend the time with family and friends. I’ve encouraged our team to use the Fedora vacation calendar to mark their expected “down time.” I encourage other community members to use the calendar, too, especially if they carry some expectations or regular responsibilities around the project.

I’m personally taking the next two weeks off around the holiday, mainly to take a break from work, but also to get buried in my creative pursuits as a musician, songwriter, and music engineer/producer. I hope each of you has a wonderful end of year season and that the holidays you enjoy are peaceful and bountiful.

Holiday break 2015.

The upcoming holiday break seems like a good time to break my silence on the blog. I haven’t had much time for writing of my own lately. I’ve been using most of that time writing and editing for the Fedora Magazine. That’s been quite rewarding, and our readership there keeps growing. But I want to use my own blog to draw the community’s attention to the holiday season. With the holidays come vacation time for me and the Fedora Engineering team.

Nothing says holiday quite like shiny things!

My good friend John Poelstra is fond of saying, “It’s OK to disappoint people, but it’s not OK to surprise them.” That wisdom is a big reason why I like to set expectations over the holidays.

Working at Red Hat is a fast paced and demanding job. Working full time in Fedora is itself demanding on top of that. These demands can make downtime at the holiday important for our team. At Red Hat, there’s a general company shutdown between Christmas and the New Year. This lets the whole organization relax and step away from the keyboard without guilt or fear. Of course, vital functions are always staffed. Red Hat’s customers will always find us there to support them. Similarly, our Fedora infrastructure team will monitor over the holidays to ensure our services are working nominally, and jump in to fix them if not.

Some people like to spend time over the holidays hacking on projects. Others prefer to spend the time with family and friends. I’ve encouraged our team to use the Fedora vacation calendar to mark their expected “down time.” I encourage other community members to use the calendar, too, especially if they carry some expectations or regular responsibilities around the project.

No matter how you decide to spend your holidays, I hope you have a peaceful and pleasant remainder of 2015, and a successful and prosperous 2016!

Image courtesy Jim Lukach – originally posted to Flickr as holidays…..

Writing to be read.

Here’s my point (TL;DR): Write to be read.*

Where do I get off?

As you read this, don’t forget: I’m speaking from experience as a bad writer of email! I’ve made every mistake I point out here, and most of them countless times over.

I have lots of room to improve as a writer. But in the same way, I’ve improved greatly over time. Years ago, my email messages tended to be long and flowery. They were filled with unnecessary qualifiers, adverbs, parentheticals, and asides. You name the writing sin, I committed it. It made my writing hard to read. That meant I often had to repeat myself in writing, on the phone, or face to face to make a point. Finally I realized this was due to my poor writing habits.

I learned that beautiful writing wasn’t necessarily wordy. Beautiful writing is successful writing. In open source and in business, successful means you get your point across. This is doubly true in an environment where everyone’s drowning in email. While there are certainly occasions that call for florid prose, the office or mailing lists usually don’t. I realized to truly affect colleagues, I needed to think more about writing to their expectations.

What makes for good email

If you work in open source, you probably use mailing lists. A mailing list efficiently shares information equally with many people at once. Your goal in writing to the mailing list is to inform and influence the list readers. Those people are your audience.

But your audience probably doesn’t have an infinite amount of time for email. At least, they don’t if they’re productive. I assume most people want to be productive, in open source or otherwise. They spend no more time on email than necessary. Instead, they spend their time on productive work — coding, creating, testing, doing.

This doesn’t mean email is wasted time. Ideally, email helps you stay informed, and be more productive. Those aren’t the only hallmarks of useful email, but they’re important for our purpose here — understanding our audience. The information you get from email should help you (1) reduce wasted effort, and (2) produce better work. If these things don’t happen, email stops being productive.

But here’s the rub: even an informative email may be unproductive! For example, if email causes you to waste more effort than the improvements it brings, it’s into unproductive territory. I find this often happens when email is hard to read. Here are some reasons why this might happen:

  • The information is too dense. If you’re making too many points at once, your writing becomes hard to follow. Sometimes this happens because you haven’t been careful with logic. Sometimes it happens because you haven’t organized your thoughts.
  • The information is in fragments. I see this happen on mailing lists when writers make points inline, instead of taking time to write a cohesive reply. After one or two replies, the discussion becomes much harder to follow.
  • The information is hard to find. When the language obscures your point, your email becomes unproductive. This can happen sometimes to writers not using their native language. But I find it happens just as often to native speakers, even mechanically “good” writers. That’s the case I concentrate on here.

Are we reading what you’re writing?

Have you ever spent a long time writing a big email, only to get little or no response? (No one loves the sound of crickets.) You probably started out with great intentions. You wanted to be informative and helpful. But you defeated your own purpose with sheer volume of information.

Perhaps you thought, I want to explain myself perfectly. That way, no one will misunderstand my point. But in doing so, you buried the real point in the explanation! Now you’ve made it harder for your busy audience to understand you. It’s arguable whether you even solved the problem you wanted to. After all, concise writing often makes your point more clearly.

In a way, you optimized for a corner case (as a developer might put it). And by doing so, you left your core audience behind. They’re the very people you hoped to inform or influence! Worse yet, over time that core audience becomes less engaged with you, your thoughts, and your writing.

Take me for example: like a lot of people, I’m busy. I’ll bet your core audience members are, too. If it takes me 15 minutes to read your lengthy email to pull two points from it, I may well give up before I succeed.The more time I spend to decipher an email, the more time I lose for more productive tasks. That 15 minutes is a lot of productive time to spend on one message!

But the problem grows worse over time. I usually have expectations about whether email will return the time I invest in reading it. Just like any investment, past returns don’t guarantee future ones. But they do tend to guide strategy. So I may start to set expectations about the value of your email. The more often I run into this problem, the more likely I’ll ignore or defer a future lengthy email you wrote.

Writing to be read

You might think, Why do I need people with limited time or attention to read my email? If you can’t take the time to read, then I don’t need your comments.

This kind of tunnel vision is where some people go wrong. The more you restrict your audience with artificial limits, the less effective you become at achieving your goal. You want to reach as many in your audience as possible, whether they have limited time or not.

Here’s another point: isn’t your time limited, too? Of course it is! We’re all roughly the same in this respect. No one wants their time used unproductively. In other words, most people in your audience probably have limited attention to give email. So your email should be as effective as possible.

This is why you should write to be read. Make your points as simply as possible. Build your points succinctly and concisely. And most importantly, mercilessly self-edit.Licensed CC-BY-SA 2.0 by Fredrik Rubensson -- URL: https://www.flickr.com/photos/froderik/9355090806/

Maybe you’re not used to self-editing. Perhaps you tend to spin a stream of consciousness into email. Or perhaps you couch your writing in qualifiers and asides. These bad habits probably limit your audience precisely as I describe above. A lot of smart people may avoid your email as a result. You’ve missed your chance to influence them, or spark new ideas.

In a follow-up post, I’ll show ways to predict whether your writing is likely to be read. I’ll show you how to find some common warning signs and fix your writing when they show up. Believe me, this is like any skill — a muscle you can build through exercise. I’ll show you exercises that help you get read more often and with more accuracy.

* TL;DR = too long; didn’t read.

** I believe it’s not ironic to have a TL;DR in a post about being TL;DR. If you want an explanation, you’ll read on. Hopefully I’ve written that explanation clearly enough you can follow my reasoning easily. If not, I’ve overestimated my right to this soapbox!

Fedora release infrastructure job opening.

The team I manage at Red Hat, the Fedora Engineering team, includes people who work on Fedora infrastructure, application development, and design. We have a job opening dedicated to architecting and building the next generation of release tools for Fedora.

With the rise of container technology such as Docker, and new platform tools like Project Atomic, we have a lot of opportunities to innovate in how we release Fedora. The three editions of Fedora (Workstation, Server, and Cloud) introduced in Fedora 21 give us better defined targets for what we build. But we also need tools that support building a variety of potentially new deliverables for those targets.

While we have a fantastic team of Fedora release engineers responsible for delivering the bits, they’re consistently strapped for resources to do heavy software development. Based on discussion with release engineers in both Fedora and RHEL, I believe this position will help us improve on two fronts:

  • Faster, more efficient, and more dynamic tools for creating a larger variety of compose deliverables
  • An environment that allows rapid iteration and continuous delivery/integration, and participation of a large community of contributors in more of a dev-ops fashion

A major portion of the value that Red Hat derives from Fedora — which allows Red Hat to invest in Fedora with jobs like this — is rapid integration of new technology in advance of RHEL. In the same way, Fedora has the opportunity to deliver advanced build and release tools for reuse by RHEL and hopefully CentOS as well. Therefore, the engineer in this job will play a critical role in making Fedora even more valuable.

This will be a challenging role! The incumbent will need to be not only a strong engineer with great architectural sense, but also a strong leader who can work with others in the community to unify around great tools and process. If you think you’re the perfect person for this job, apply through the Red Hat Jobs listing. If you have any problems, feel free to contact me via email.

En route to DevConf.cz 2015.

Like several other Red Hatters this week, I’m traveling to Brno in the Czech Republic to attend DevConf.cz 2015. DevConf is a fantastic open source conference that focuses on new technology upstream in dozens of important projects. It’s a great place to find out what’s coming next, and what’s already emerging in Fedora Rawhide.

DevConf always has great speakers, and this year is no exception. For instance, I’m looking forward to hearing what the systemd team plans to “break” next. People on the Fedora team including Dr. Pierre-Yves Chibon (pingou) and Patrick Uiterwijk (puiterwijk) are also featured on the Fedora day on Sunday. The CentOS team also has breakouts on Sunday, so it should be a great day for exchange across projects.

Before DevConf starts, I have some meetings happening in Red Hat’s Brno office. Also I hope to catch up with some friends and colleagues in the office, especially a few who are focused on Red Hat Enterprise Linux. Working in Fedora full time again means I don’t catch up with them as often in the course of a day.

I might be atypically absent from IRC while rushing around the office or at DevConf. If you need to reach me, email will probably work best. I might be delayed getting back to you but I’ll do my best to keep up while overseas. I’m writing this from the gate at Amsterdam’s Schiphol airport, doing my best to reset my body clock by drinking coffee and keeping my eyes open!

CVE-2014-6271 updates on Fedora.

IMPORTANT: Refer to this update for revised instructions.

What is CVE-2014-6271?

CVE-2014-6271 is a GNU bash vulnerability that permits specially-crafted environment variables to inject shell commands. This is a fairly serious issue. If you don’t want to wait out the hours until stable updates are issued to fix your Fedora system, here’s what you can do. (The Fedora Project may choose to issue some official guidance, this is just my own helpful hint.)

Fedora 21 Alpha

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.3.22-3.fc21
su -c "yum localinstall bash-4.3.22-3.fc21.$(uname -m).rpm"   # provide root password again...

Fedora 20

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.47-4.fc20
su -c "yum localinstall bash-4.2.47-4.fc20.$(uname -m).rpm"   # provide root password again...

Fedora 19

Run these commands:

su -c "yum -y install koji"   # provide root password...
koji download-build --arch=$(uname -m) bash-4.2.47-2.fc19
su -c "yum localinstall bash-4.2.47-2.fc19.$(uname -m).rpm"   # provide root password again...

Hope this helps!

Flock Day 2.

Here’s a summary of today’s activity at Flock 2014 where I participated or attended. I also have a blog entry reporting what I did on Day 1 of the conference.

  • Up at 7:00am (relatively late) to meet Fedorans for breakfast before going to the venue.
  • I attended Stephen Gallagher’s talk on Fedora Server. I also wrote this up for Fedora Magazine. You can read the article here.
  • I also attended Aditya Patawari’s talk on Ansible. I also wrote this up for Fedora Magazine. You can read the article here.
  • Then it was time for the Novena keynote on a fully open source laptop.
  • Sometimes even a great conference has to give way for your paid job. So I skipped lunch to work on some managerial duties. These things also have to get done, even at a Fedora conference, so the team can operate successfully.
  • I attended the Meet Your FESCo session. I even managed to get a question (and a “thank you” comment) into the proceedings. I did this mainly to prompt some comments from the FESCo members.
  • I had some side conversations with Radek Vokal and Denise Dumas. Like me, they’re part of Red Hat’s platform engineering organization (which makes RHEL).
  • I attended the Aditya Patawari’s talk on Docker. But mostly I realized I was running out of gas. Between the warm room and Aditya’s soothing voice, I had a hard time staying awake. So I decided to work on this blog to keep myself from dozing off.
  • I sat in on Stephen Gallagher’s talk on “Fedora.next.next.” This was his cute way of inspiring interest in the upcoming Fedora 22, to release in 2015.
  • After the talks ended, it was time to head back to the hotel to refresh. Then we met up and boarded a steamer for the big Flock Boat Party.

DevConf.cz event, day 2.

After I cleaned up and ate a light breakfast at the hotel, I strolled back to the university building for the second day of the 2013 DevConf.cz event. In case you didn’t see them, here are my reports on part 1 and part 2 of the first day.

One thing I didn’t point out yesterday: I only saw most of one track. There were actually three complete tracks going on, several workshop rooms, and a couple of hacking labs. This is a really big conference: I hear there are almost 550 people here from around the world! Here’s what I saw and did today:

  • Thomas Woerner presented his work on firewalld, the new dynamic firewall system. He talked not just about the problems firewalld solves but also some of the future capabilities. These include a rich language to adjust many pieces of the firewall in harmony when configuring. A lockdown mode is also planned that allows administrators to enforce policy and whitelist specific applications.Thomas Woerner discussing firewalld at DevConf.cz 2013
  • Thomas Graf presented on Open vSwitch, a multilayer, distributed switching system that supports full automation and extensibility for routing network traffic. Open vSwitch is a smart approach to a hard problem: getting packets somewhere when you have multiple routes available and may not know enough to decide which to take. I’m not a routing expert so I will probably need to go back and revisit the slides to
  • Lennart Poettering, Kay Sievers, and Harald Hoyer presented to an incredibly packed room (of course!) on “What Are We Breaking Today?”. Predictable network interface names were first on the roadmap. It sounds like this will succeed biosdevname (although it will not override it, i.e. people running biosdevname will not be affected). They also talked about gummiboot and the boot loader spec, which allows system owners to bypass the complex use of grub2 and instead drop simple configuration files into place to generate boot loader configuration. Another problem they try to solve: Newer systems when POSTing (UEFI, presumably) don’t initialize USB to save time, so systems with USB keyboards can’t choose from multiboot options. So they are trying to make it possible, even down to a user space component, to choose persistent or one-time multiboot options before rebooting. Next up was kernel D-Bus, which was a very fascinating and energetic discussion. It sounds like Kay and Lennart are working in the kernel community on both the coding side and the politics side to succeed. This is potentially a very powerful development. Finally, they talked about systemd in the user session, to give some of the same benefits to the session as have been given to the system boot. Think about it: we take about a second to boot the kernel, about a second to start the initrd, and then maybe 8-10 seconds or more to start a GNOME session! All this is leading toward an even bigger and vital topic: applications, app images, and app sandboxes. However, this is subject to design and not something Lennart & co. are looking at deeply on their own. As they said, Linux can be the world’s best and most-used general purpose OS, and the way to do this isn’t to slow down, because the other OS makers won’t.See that sacred cow over there? Let's kill it.
  • During the short break, I made a mad dash around the reception hall looking for anyone with hand lotion. Despite the wet weather, the heat in all the indoor locations has dried my hands to the point they’re starting to crack and bleed in places. (Yuck!) And of course I left my lotion at home, so it was comical trying to find someone with lotion. Thankfully the nice ladies at the reception desk, who barely spoke any English, eventually understood and helped me out!
  • Fittingly, after the break Bryn Reeves did a retroactive look back at “What Were We Breaking Then?”. The talk was a light and humorous reminder that change is difficult, and the fundamental conflict between needing to evolve and increase competition, and people’s natural resistance to change isn’t likely to disappear. for instance, remember going from libc-5.3 (“Blecch, Red Hat ships an ancient libc”) to glibc-2.0 (“Blecch, Red Hat ships a bleeding edge libc”)?
  • Dan Walsh then gave a talk on security for Linux containers. There are currently three different methods for this. The first is namespaces; Dan apparently created the first container method on RHEL back in RHEL 5, using pam_namespace. The second is the SELinux sandbox, which is available in RHEL 6. There is a third, new capability called systemd-nspawn that also allows you to containerize up to and including running a whole OS inside your host’s OS.
  • Lennart Poettering returned to explain the systemd journal and its capabilities. The journal provides features for structure, indexing, security, reliability, standards compliance, localization, and many others. Lennart spent time explaining use cases motivating each capability of the journal, and it was quite compelling. It was not without controversy, but it seemed like the entire audience was quite impressed with the demonstrations that Lennart gave for the journalctl utility.
  • I made a patch for an easily fixed problem Lennart encountered in his demo and attached it to this bug.
  • There was a talk on rsyslog message normalization and parsing. I admit I zoned out for part of this talk, but mainly because I was hot to work out the above patch! Also I realized I totally missed lunch, so I went to find sustenance, even in the form of a hot dog from the vendor downstairs.
  • I found out within 10 minutes after sending in my patch on the concerned bug, I had become a systemd contributor! 🙂
  • I hung around with NetworkManager guru Dan Williams for a bit and we talked about fun overseas with phones.
  • Open source super-guru Dan Allen did an amazing talk on Awestruct, a framework for HTML that lets you trivially create beautiful web sites out of content you can manage and deploy directly in git. This concept is very similar to what the Fedora Project is doing with templates for their site. Awestruct reduces the complexity by an order of magnitude, though, and eliminates the compile/build process.
  • I sat in another session of short talks. Marek Grác talked to us about his work in working with virtual guests, specifically shutting them down. The talk title, “How to Turn Off Your Computer,” was immediately attention grabbing!

The conference was really fantastic, with great content and a lot of good hallway conversations. Combining the conference with an office visit made it even higher value, so I hope I can attend next year.

After the conference day ends, I’m meeting up with a group of buddies to find Koishi, a sushi restaurant Will Foster told me about. It’s supposed to be very good, with a real Japanese chef who gets fish flown in from Slovenia. I think tonight will be low key, since we are back at the Red Hat Czech office in the morning!

(UPDATE: Said chef was apparently not working tonight at the restaurant, so we opted for the quite satisfactory Sushi Ya, and had a wonderful time. Vaclav Tunka was a marvelous guide to some great Czech wines and the suhi was quite good. The butter fish was exceptional and they had a markedly excellent spider roll.)

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!