I’m extremely happy to announce that Randy Barlow has joined the Fedora Engineering team, effective today. Randy was previously a member of Red Hat’s team working on technologies like Pulp. You can find his fingerprints in many upstream repositories as a frequent contributor. This is fortunate for our team, since Randy will be contributing both to our applications infrastructure and to our release team. His experience with Pulp may come in handy too, since it may play a part in making next-generation Fedora content available to the public. I hope the Fedora community will join me in welcoming Randy!
June 06, 2016
April 08, 2016
My day job, as you probably know, is at Red Hat, where I manage the Fedora Engineering team. Our team provides engineering and design services for the Fedora Project, a collaborative community project which is the upstream source for a number of influential products. Not the least of these is Red Hat Enterprise Linux, of course.
We now have a job opening for a senior engineer in the USA to be part of our team.
About the job
Collaborating with the rest of the team, the community at large, and your colleagues in Red Hat, you’ll:
- Build tools and web services that will in turn build a more modular next-generation Fedora
- Do full-stack development, with a hand in everything from working with designers, to architecting and writing code, to deploying in test/stage/production, to maintenance and enhancement
- Automate, automate, automate all the things
- Co-create and develop our next community engagement system, Fedora Hubs
- Stay tuned into exciting work going on throughout Red Hat related to platform and other technologies
- As with all Fedora Engineering jobs, communicate openly and continually with the whole community, and build community around everything you do using open source best practices
About the Fedora Engineering team
Our team uses a lot of Python (flask and sqlalchemy currently rank highly), and we’ll be expanding outward in the future where it makes sense. We create code upstream that is widely consumable beyond just Fedora, and we deploy our work on both Red Hat Enterprise Linux and Fedora.
We do that work openly: collaboration via git repositories, rapid and constant communication via IRC, frequent discussion through our mailing lists, and gathering and building community around our work. Simply put, we love open.
Who we’re looking for
The right candidate is a team player, positive and constructive, fully engaged and passionately committed to delivering results with their colleagues, wherever they might be. This is a senior position, so we’re looking for someone who’s a proactive, detail-oriented self-starter, and has the ability to lead from the side on a few projects. We want you to be really good at Python and being Pythonic, and hopefully have some similar high-level language experience like Ruby or Java where you can help us grow, too.
Not interested in working in a Red Hat office? No sweat. We’re a distributed team, and this job is perfect for an experienced remote candidate. Remote doesn’t mean aloof, though. You need to be somewhat of a people person to crush this job, because good open source means collaboration. We meet up at least once a year as a team for Flock, but we work together constantly online.
I would be remiss in not pointing out this position back-fills some mighty big shoes. That’s why I’ve outlined some ideas for who we’re looking for in this post. That being said, you’ll also be working for a manager who’s a super guy. Just check the sidebar of this blog for proof. In all seriousness though, we all care about our teammates’ success, so you’re never on your own when you need a hand.
Enough already, where do I apply?
April 05, 2016
I don’t get as much of a chance these days to do things like patches or other technical contribution. But I had some time free the other day and used it to stick my hands directly into a cool project, Pagure (pronounced roughly “pag-yOOR,” or listen here). You may have read about Pagure in this Fedora Magazine article a few months back.
It was tremendously easy to get Pagure, fix a bug, test the fix, and contribute it back (see my pull request here). I specifically looked for “easyfix” bugs, since I knew I didn’t have a lot of time to spend to help. So I decided to work on this issue, a button showing up when it shouldn’t.
First I forked the repo in Pagure. Then I cloned my new fork, and set it up as documented in the README. In the clone, I checked out a new branch using the issue number as a name, issue839.
To track down the fix, I ran the app locally and duplicated the error. I looked at the CSS style containers for the button and some of the surrounding elements. Using that information, I did a text search on the code to find the file that was generating the button. Then I simply applied some logic to find the fix for the problem, even though I wasn’t really familiar with the code involved.
Thankfully Pagure has a test suite, so I could also check that my fix didn’t break any of the tests. Then I committed and pushed my changes, and made a pull request using the button in Pagure’s web page.
I also learned something useful. Since I forked the repo to do my fix and make a pull request, if I force-pushed changes using git to my branch from which I made the pull request, the pull request was automatically updated with the changes! This is probably expected by people who do this all the time, but since I’m new at it, I was excited.
Bugs like this are something that just about anyone with a small amount of beginning programming skill could fix. Pagure even has other bugs like this waiting for people to handle. Maybe one of them is waiting for you!
February 03, 2016
I realized that some folks around the Fedora community may wonder why they don’t see me around as often this week and next week. I’m still alive and well, but I’m traveling in the Czech Republic. I’m currently in Brno for some Red Hat departmental meetings. Following that, I’ll be attending the Devconf.cz event. Then I’ll be back in the Brno office for a few days of other work and team meetings. I’ll be back in my home office on Monday, February 15th and around as usual at that point.
October 28, 2015
I feel like my recent blog posts have all been about openings. But it’s nice to be able to offer them. Each internship on our job site is linked in the bullets below, so you can apply for any for which you feel qualified.
- Software engineering internship – This internship focuses primarily on Python software development. You’ll take designs and build them into widgets for our Fedora Hubs project. You’ll collaborate with our applications team on back-end technology for the community. You’ll also work with our infrastructure team on production deployment. This internship also includes other related projects, not limited to just Hubs. The intern is preferably in Westford, MA for the summer. But that’s not strictly required for a well-qualified candidate with experience working in a global open source project. (In other words, if you can succeed at keeping touch daily with the team as a remotee, don’t let the location throw you.)
- User experience and design internship – This intern will work directly with our designers Máirín Duffy and Ryan Lerch on research and design for Fedora projects such as Hubs. You’ll do user research and work on improving interaction in our web apps and other associated projects. You’ll collaborate with the other interns, our whole development team, and the Fedora community at large. This job is in Westford, MA.
- Web development internship – This intern will work primarily (but not exclusively) on web apps at the front end. You’ll turn design into reality, and streamline existing applications to designer specs to build a more unified project. As with our other internships, you’ll be able to explore and work on other projects too. You’ll work with our design team, the community Websites team and our application developers to create and improve web tools our contributors will use for years. This job is preferably in Westford, MA for the summer. But we’ll consider remote for an exceptionally qualified candidate.
These jobs should end up being quite competitive. So I encourage you to get your application in as soon as you can!
Last year, we were fortunate to have superb interns who produced fantastic results. Meghan Richardson worked on many of the initial designs for Hubs in its early stages, interviewing potential users and then creating the workflows and feel for this new tool. Nate Yazdani worked on statscache, which compiles data from our messaging bus to make it available quickly to other apps, without constantly crushing our data store.
Red Hat is a fantastic company at which to intern, and we pride ourselves on an open and inclusive culture. These are not “fetch coffee” jobs — you’ll work on real problems alongside real experts.
We can’t wait to see what you can do!
October 16, 2015
Here’s a fantastic opportunity in open source for folks from underrepresented backgrounds. The Fedora Engineering team has an Outreachy internship available December 2015 to March 2016. Applications are being accepted at the Outreachy site. The deadline is 1900 UTC Monday, November 2, 2015.
Are you familiar with Outreachy? It’s a program designed to boost participation in open source by underrepresented groups. My employer, Red Hat, is sponsoring this internship. The Fedora Project, which my team at Red Hat supports, is proud to partner in offering it. This Fedora internship is an opportunity to work directly with our senior software engineers on a major project called Fedora Hubs.
Hubs is an initiative to bring better and more timely information to Fedora’s large community of participants and contributors. Several of our engineers will collaborate with you throughout the internship period on this project. We’ll use Hubs as a foundation for regular, daily mentoring of our Outreachy intern. You’ll use best of breed technologies like Python, Bootstrap, jinja templates, and more. Best of all, you’ll work alongside the team in real time.
You can read more about the internship and qualifications here on our wiki. The page also has general information about Fedora, such as our mission and how we work together.
But this internship isn’t just extending your skills, or working with awesome people. (Even though that’s a great incentive!) It’s also about bringing the open source way to thousands of people. This project lets contributors build sub-communities, or hubs, around their interests. “Standing on the shoulders of giants” is one of the greatest benefits of open source. The same goes for using open source to build communities. It’s a natural fit and a wonderful outcome for a successful internship.
Are you interested in diving deeper into Hubs, to see what this internship is about? Check out this recent blog post from our own Máirín Duffy on the purpose, design, and mockups of the Hubs project.
August 18, 2015
Getting started at Flock
Like everyone on the Fedora Engineering team, I was in Rochester for the Flock conference last week. After several flight delays on our direct flight from DCA to Rochester, Justin Forbes, Ricky Elrod, and I finally arrived a little after 9:00pm — about four hours late. Thankfully Josh Boyer came to pick us up at the airport.
Flock had a team of organizers within OSAS (and Josh also assisted throughout). As a former FUDCon organizer, though, I know the value of extra hands showing up to do work. Since old habits die hard, I showed up expecting to help out behind the scenes. That means I didn’t get to see a huge amount of content I was personally interested in. But in return hopefully everyone had a smoother Flock experience, especially speakers.
When I arrived, I reported to Tom Callaway, Ruth Suehle, and Josh. They got the conference rooms opened, and I helped set up the speaker workstations. We worked pretty late, well after midnight. Things were looking a little bleak at that point, with execrable network bandwidth, no projectors, no screens, and no audio for the ballroom.
Fears and worries abate
Nevertheless, the next morning Josh and I got up early and grabbed coffee at nearby Tedward’s. This place was a godsend, although their 7:00am opening time forced us to walk around a bit until we could get in.
We went down to do some additional setup. The organizers had worked with Remy DeCausemaker to get a bunch of loaner projectors from RIT so we’d be ready for the first sessions at 10:00am. (EDIT: According to Remy, Tim Duffy and Dan Schneiderman are the heroes of this particular day; see comments below.) So at least our speakers would be in OK shape. I helped Josh and Tom get everything ready in those rooms, while Ruth made sure registration and other logistics were under control. I missed Matthew Miller’s keynote, but I’d seen at least some of the material previously.
After lunchtime, things continued to drastically improve. The rental projectors showed up, along with small screens for each room and big speakers for the ballroom. The wireless internet improved quite a bit when a switch flip occurred due to our conference starting up. (It was dismal Tuesday night!) We had all the speakers trained on how to record their talks locally, to get around the constrained network bandwidth.
Suddenly things were looking up! Not surprisingly, the Fedora Engineering team dinner that night at The Old Toad was much more enjoyable. Since I wasn’t overly worried about the conference experience for the speakers and attendees any longer, it was easier to relax and enjoy the company of the team. I was so happy that we were able to get together in one place, since we really only get to do that once a year. (Incidentally, our friend Stephen Smoogen was absent from Flock due to family commitments — we missed you, Smooge!)<figure class="wp-caption alignleft" id="attachment_4622" style="width: 1024px"><figcaption class="wp-caption-text">Fedora contributors at Flock gather at Victoire for dinner</figcaption></figure>
I continued to monitor speaker rooms most of Wednesday and Thursday. I managed to make it to a couple sessions where I wasn’t sure there would be any senior Fedora leadership around. For example, I attended the Fedora Magazine session by Chris Roberts as well as most of the Fedora Hubs session by Máirín Duffy and Meghan Richardson.
I attended and loved Major Hayden‘s (of Rackspace fame) Thursday keynote on fighting impostor syndrome. It was one of the most practical that I’ve seen on this topic. I feel impostor syndrome is just a fancy way to refer to insecurity, a common trait for conscientious people. But that doesn’t make the strategies Major outlined any less useful or thoughtful. He gave a great talk — engaging and humorous without diluting the material. If you have a chance to invite him to a conference to speak, definitely do so!
I gave my own talk on Remote Ninjutsu on Thursday afternoon. The slides for the talk are here, although the video will be more useful for context. All the Flock 2015 videos are supposed to be available at some point in the next couple of weeks. Stay tuned for announcements about them.
The Thursday night social event at the Strong National Museum of Play was fantastic. It was a great way to blow off steam and enjoy the company of fellow Fedorans. I’m not sure how the organizers managed to find such a perfect venue!
Workshops and Flock wrap-up
On Friday I enjoyed the keynote by Jon Schull of eNable, the community that is flipping the script on prosthetics provision through 3D printing. It was a very moving look at how people are applying open source to make the world better for people in need.
Then the workshops beckoned. Now that I’d finished my Flock duties helping speakers and attendees, I was able to attend several sessions that were relevant to me personally, including the Fedora/CentOS rel-eng joint session, and my own on revamping the Flock software stack.
Once again, the Friday night social event at the George Eastman House was marvelous. It was a beautiful, grand mansion and the tour was quite interesting. I’d love to go back there sometime to see the exhibits I missed!<figure class="wp-caption alignleft" id="attachment_4625" style="width: 1024px"><figcaption class="wp-caption-text">The music parlor in the George Eastman House</figcaption></figure>
Flock conferences are always especially great for their hallway track. So many discussions can be had or progressed that way with high bandwidth. The challenge is always to move that discussion to a transparent context if it involves people not present, though. I’ve been seeing many trip reports from people’s blogs about Flock, and resulting list discussions, so I think that process is well underway.
Of course, that means Flock is a very engaging event. It takes a lot of attention and brainpower to shift focus for all those conversations! As a result, by Saturday afternoon I know I was fairly exhausted — in a good way, though. Several other people I know felt likewise, and commented on how well the conference had gone. In fact, I heard a number of comments that this was the best Flock, and even Fedora premier event, yet. The OSAS folks deserve special recognition for pulling off a fantastic conference.
Sunday started with a couple meetings, including with Matthew Miller and Jan Ku?ík, our new Fedora program manager. Then, after seeing a few other friends and colleagues off, I got to the airport. I relaxed in a lounge over beers with Kevin Fenzi, Jan Zeleny, and Stephen Tweedie, before we went to our respective flights. Then after a quick flight home, it was the usual “fun” making my way down I-95 from the airport to home. Monday morning was right around the corner…
Here’s to another great Flock, and to doing it again next year!<figure class="wp-caption alignleft" id="attachment_4627" style="width: 1024px"><figcaption class="wp-caption-text">Flock attendees wind down after the conference ends… with more hacking!</figcaption></figure>
July 21, 2015
The team I manage at Red Hat, the Fedora Engineering team, includes people who work on Fedora system administration, release tooling, application development, and design. We have a job opening for an engineer to work with our infrastructure applications team on some challenging, fun, and forward-looking problems:
- Building and enhancing our tools for producing and shipping cloud images for a variety of providers (experience definitely required!)
- Working with the Fedora Cloud SIG and other community members to resolve issues related to the Fedora Cloud edition and associated tools and processes
- Collaborating with the rest of the Fedora team to automate, automate, automate All the Cloud Things
- Working with the rest of the team on non-Cloud related projects too, such as Fedora Hubs
- Staying abreast of and aligned with work going on throughout Red Hat related to Fedora and cloud technology
- As with all Fedora Engineering jobs, communicating openly and continually with the whole community, and building community around everything you do using open source best practices
Our team uses a lot of Python. We create code upstream that is widely consumable beyond just Fedora, and we deploy our work on both Red Hat Enterprise Linux and Fedora. We do that work openly: collaboration via git repositories, rapid and constant communication via IRC, frequent discussion through our mailing lists, and taking opportunities to gather and build community around our work. Simply put, we love open.
Although the description says the job is in Westford MA, USA, in reality we’re a highly distributed team. While this job is originally conceived as an entry- or journeyman-level engineer in the Westford (or possibly Raleigh NC) Red Hat office, we’re also open to experienced remotees outside the USA. The right candidate is a team player, fully engaged and passionately committed to delivering results with their colleagues, wherever they might be.
Does this sound interesting to you? Go read the full description of the job, and then apply online.
June 24, 2015
As you might have seen, the Red Hat Summit is happening this week. As usual, I’m here volunteering on the staff, helping with training, the booth, manual labor, and whatever else I can do to assist our awesome event gurus. I love seeing and meeting customers and partners at this event, so I look forward to it every year.
Of course, it comes at a price. I’m not really around on IRC and slow to get to email compared to a normal work week. To make matters worse (or better, depending on your perspective), I’ll be on vacation for about a week and a half following the event. For that reason I put my outage on the vacation calendar on Fedocal.
Now, I don’t think this will unduly impact anything in Fedora. There’s little that depends on me personally since mainly I just try to help things happen for my teammates. But I wanted to make sure the community is aware and knows what to expect.
June 04, 2015
- Bad drivers at a lower layer (not PulseAudio’s problem)
- Bad hackery in the distro (ohai *buntu)
- People parroting years-old Internet “wisdom” (does that happen?)
But in a well-integrated system, PulseAudio is awesome. That’s definitely the case with Fedora Workstation. That includes Fedora 22, which is what I’m using now.
I’m attending a number of conference calls this week. Lots of them. The last two days have been eight hours of meetings. For example, today I’m at a Fedora Hubs workshop with fellow community members. I usually use my laptop to attend these conference calls. I use it with a USB headset attached. But having a headset on for that long is uncomfortable.
I also have a desktop computer in my office hooked to a big speaker set. So I use PulseAudio to route sound from my conference calls to those speakers. Now I don’t have to wear a headset to listen in.
I do this using the paprefs and pavucontrol utilities. I find these utilities very useful for more audio control. I can watch and move streams, all though an easy, comfortable GUI.<figure class="wp-caption alignnone" style="width: 800px"><figcaption class="wp-caption-text">My home office setup, courtesy of PulseAudio.</figcaption></figure>
Thanks for the memory, PulseAudio
But that’s not all!
I was in the conference call, but there were updates available on the desktop computer. I decided to see what happened when I rebooted to get the updates. (Since my laptop was on the call, it wasn’t a problem.) I restarted the desktop, and the sound automatically moved back to the laptop speakers! That was cool — I didn’t lose any of the conference.
But it got better. After updates finished and the system restarted, I logged in. The sound automatically went back to the desktop speaker system! I was really impressed.
PulseAudio can track where audio streams are going, and send them back to the original devices when restarted. I love this feature! I remember the early days of Linux audio. It seemed like every single operation was hit-or-miss. I’m glad I don’t have to mess around with the system at that level anymore. I can just concentrate on my tasks, and things Just Work(tm).
June 02, 2015
Are you (1) coming to Flock 2015; (2) located, or planning to be, in the Boston, MA or Westford, MA area; and (3) interested in taking a free, power and wifi-equipped bus if offered?
If so, then pre-register by 1900 UTC Friday, June 5, and make sure you indicate in your registration you are located in the Boston/Westford area. I’ll collect the final number of these signups on Friday afternoon US/Eastern time. We’ll use that number to determine whether or not it’s economical to book the bus.
The announcement about the bus will be made next week, so there will be plenty of time to make appropriate travel plans either way.
May 24, 2015
Fedora 22 is just around the corner and while upgrading my machine, I decided to completely ditch Gnome’s Evolution in favor of Mozilla Thunderbird. I had already switched a while back, but still had tons of mail in an old local Evolution account I wanted to migrate.
Unfortunately all HowTos I found on the web assume Evolution would store mail in the mbox format, while it switched to maildir in version 3.2.0. MozillaZine suggests to first convert maildir to mbox and then import the resulting files with the ImportExportTools extension. Why so cumbersome if there is the excellent Dovecot IMAP server that can read both maildir and mbox?
Migrating mail with Dovecot is straight forward. Quit Evolution and install dovecot:
yum install dovecot
Then set it to use Evolution’s local storage as mail location:
echo "mail_location = maildir:~/.local/share/evolution/mail/local/" \ >> /etc/dovecot/conf.d/10-mail.conf service dovecot start
Fire up Thunderbird, configure a new account for your user on localhost and copy over all mail from this account to the “Local folders”. There you go!
May 13, 2015
May 05, 2015
I was just voting on FLOCK talks and happened upon this talk proposal:
It’s no secret that many Fedora participants work for Red Hat. Or that Red Hat provides funding for the Fedora Infrastructure. There have been many conspiracy theories over the years centering on what, exactly, does Red Hat want out of Fedora in return. This talk, by the Red Hat VP who runs the RHEL engineering team, proposes to address that eternal question. What does Red Hat want? Join Denise Dumas to learn what Red Hat is working on next and how we would like to work with the Fedora community
In my time working for Red Hat on Fedora I often found that the Fedora Community was operating in a vacuum. We wanted to run a Linux Distribution that we had a stake in and a chance to modify to our needs. We also knew that Red Hat invested a considerable amount of money into Fedora to support our being able to do that. But what we were in the dark about was what Red Hat expected to get out of this partnership and what they wanted us to do to justify their continued investment. Although over time we did get our hands dirty maintaining more of the packages that made up the distribution, in a lot of ways we never graduated beyond mricon’s 2004 tongue-in-cheek posting about Red Hat’s relationship to its community (and its own internal divisions at the time).
In the last few years, Red Hat’s portfolio of products and future directions have greatly expanded. No longer just a producer of a Linux distribution, Red Hat is pursuing revenue sources in application middleware, both IaaS and PaaS pieces of the cloud, and containers. They also have engineers working on a multitude of open source solutions that enhance these basic products, adding flesh to the framework they set up. But where does the Fedora Community fit into this expanded roster of technologies? The Fedora Product has been very focused on “A Linux Distro” for a number of years but the Fedora Community is very broad and multi-talented. I’m hoping that Denise’s talk will provide an entrypoint for Fedora Contributors to start talking about what new directions they can take the Project in that would align with Red Hat’s needs. There’s a number of difficulties to work out (for instance, how does Fedora keep its identity while at the same time doing more work on these things that have traditionally been “Upstream Projects”) but we can’t even begin to solve those problems until we understand where our partner in this endeavour wants to go.
April 02, 2015
Fedora’s quality makes complacency easy. But in truth, we’re always under construction — or we should be. You could call that constant disruption by different names. Risk positive. Forward leaning. Embracing change. Since inception, Fedora was intended to avoid the status quo. So what’s next for shaking up said status?<figure class="wp-caption alignleft" id="attachment_4522" style="width: 1024px"><figcaption class="wp-caption-text">Courtesy of US Library of Congress.</figcaption></figure>
As you’re probably aware, starting with Fedora 21 our releases are a bit different. We now have different editions, each serving a specific type of consumer. The editions today are Workstation, Cloud, and Server. The editions differ in mostly minor ways, though, and we build them mainly the same way. That’s why these editions aren’t the end goal of change. Rather, they’re a step in changing what Fedora releases.
Matthew Miller, Stephen Gallagher, and others have been steadily laying out a vision for change in Fedora. Admittedly, that vision’s high level. It uses words like “Rings” to simplify and amplify concepts that are about change. These concepts are well attuned to higher level Fedora goals. While editions can effectively broaden Fedora’s appeal to different consumer audiences, we also want to attract more makers of things.
These days, the largest maker audience is beyond just those who care about building a platform. As Red Hat’s Paul Cormier said last year, “The application is king.” Makers of applications and things above the OS are always on our minds. So how does this relate to the Fedora release of the future?
For many years now, we’ve been building our release essentially the same way. We take a big bag of packages, like building blocks, and glue them together in a group that makes sense. We wrap that group in a shippable format (or several), sometimes with an installer, validate, and release it. Lately many Fedora folks are thinking about what that future release looks like, though. I would offer that the future release should be some combination of a strongly managed center, curated stacks, and an expanding nebula of containers.
Managed center? Does that mean the return of Fedora Core? No. Forget about Fedora Core. It’s dead, and it’s not coming back. Having the central part of the OS carefully managed in the community isn’t the same thing. Fortunately, there are emergent tools to do this. Among them, Project Atomic looks like one of the best bets in the space we care about. Atomic makes shipping an integrated, validated set of content easier. That content still comes from the packages we know well — kernel, glibc, bash, and others. But the rpm-ostree basis of Atomic can prevent slew in an installed system.
What do I mean by “slew”? Right now, the only Fedora release we know well is the one we put out at GA. After that, all bets are off. Any user potentially has a random subsets of updates on top. Saying “I’m using Fedora 22” is not very meaningful soon after release. That slew also makes validation, troubleshooting, diagnosis, and recovery unnecessarily hard. What if we manage this central content more carefully, using a model like rpm-ostree? We could validate a release more regularly, at least at a basic functional level.
There are other benefits as well. What if we constructed Rawhide using the rpm-ostree model? Imagine that an important core piece of the OS broke. We’d want to file that bug, track, fix, and update. Right now, hundreds of developers have to manually, sometimes painstakingly, fix their systems. This wastes large amounts of aggregate time. This problem is largely why many interested developers don’t run Rawhide as much as would be helpful. In the new model, if you’re invested in the problem, you can still work on it, of course. But the rest of the Rawhide users could, with a single command, back out to the previous tree and keep working. This keeps more interested (and interesting) people using Rawhide.
You could probably make a case for file system snapshots here. I think those are still useful for user data in this model. It’s not clear that snapshots would solve the slew problem above without imposing restrictions on them in some fashion. Would users be happy with that? Hard to say.
So what about these curated stacks? Well, to be honest it’s not yet clear what tech wins here. On one hand, enhancing rpm-ostree to allow layering might be a way forward. Currently rpm-ostree is somewhat monolithic in that you can’t really mix or match stacks readily… yet. My understanding is the Atomic guys are thinking about this problem already, though, and how to solve it. So I expect the code will catch up to (and maybe overtake) the concept before we know it.
Alex Larsson is also doing interesting work on what he calls “sandboxed apps.” Sandboxing in this model might not be too different from containers. The concepts seem quite similar. Throw into this mix the recent progress on overlayfs, which is now part of the mainline Linux kernel. What you have is ripe ground for a new method to build and release big swaths of a platform.
Again, we have building blocks of a solution for interesting problems, some long-standing. The problems of the central core above are shared at common application layers as well. But it’s useful to detach them at key dividing lines for obvious reasons. In some way, shape, or form, it seems inevitable that Fedora must take a swing at these problems, even if it’s on a per-edition basis.<figure class="wp-caption alignleft" id="attachment_4523" style="width: 1024px"><figcaption class="wp-caption-text">Courtesy of Glyn Lowe (CC-BY 2.0).</figcaption></figure>
This leaves the nebula of containers I mentioned. A year and a half ago, containers were all the rage. People were thinking about how they affected the technology landscape for infrastructure. Perhaps some people reading this were thinking about containers as a fad. Time and consumers and commercial customers have pretty much proved that wrong. Containers allow app developers and users to move swiftly (or not) independent of the OS. The technology is here to stay, because it mostly makes OS maintenance issues someone else’s problem. In this case, ours — Fedora’s.
For a long time we’ve relied on people working the application layer to radically change their methods if they’re interested in deploying on Fedora. But frankly, time has shown the world doesn’t care to do that. So our choice is to adapt or face irrelevance. Matthew Miller has spoken to this point several times, so I won’t belabor it. My only other point is that, however we build the future Fedora release, it should make King App comfortable.
For those people who might ask why we should take on this work, I’d start with a couple of thoughts. First, what’s in it for me as a contributor? Well, it depends first on whether you care about an edition that might use this model. I’m pretty involved in Workstation edition. For some time we’ve been interested in how to update Fedora for consumers at the OS and application level, rather than packages. And something like a core + containers model using Atomic directly solves that problem. The Cloud SIG already has an Atomic image designed primarily for container management. Their user base has different expectations from Workstation. But clearly there’s room for great collaboration here, and I expect for Server too.
Another reason this is interesting is app vendor involvement in Fedora. Containers abstract the distribution problems away from application vendors. We know Fedora is in a lot of embedded hardware and other projects in the Real World. That problem space fits well with our current platform construction model. As I said before, we don’t necessarily need to stop doing that. But at the same time, embracing the rise of the app container lets us more effectively reach the developer audience. This is not just about our Workstation edition but, more generally, people who build and make interesting things. This is also somewhat tied up with the implementation of Rings. That’s why I look forward to Matthew and Stephen driving more detail and progress on that front.
Finally, by solving this problem we can effectively influence the value of future RHEL, as well as CentOS and our other family members. That value is one reason Red Hat invests time and resources in our community. Making changes to grow that value is always a win-win for Fedora as well.
The hero’s journey
So, does all this mean we won’t have live or installation ISOs in the future? Not necessarily. They could still be useful. It would depend, as most things do, on what it takes to validate and maintain all those things in the long run. For example, I don’t see this idea necessarily affecting spins. Communities around those releases are accustomed to how they build their bits. But I think at least one (maybe more) of the official Fedora release editions will need to opt for this new model if we’re to make progress.
The entire set of changes needed isn’t yet clear, of course. One thing that is clear: release engineering process is, by definition, central. And there’s no doubt we’re looking at a healthy chunk of work. But I believe strongly enough in the possibilities that our team has an extra full-time person now to drive planning of those changes, consult with the Fedora release engineering team, and build a community around the tools needed. We are going to emphasize modularity, so the winning technology of tomorrow can plug in to releases down the road. The initial goal I’d like to set is to prototype a release of at least one Fedora edition for F23, and be part of F24 official release at GA.
That means it’s going to be an exciting year of construction ahead for Fedora. So please excuse our dust!<figure class="wp-caption alignleft" id="attachment_4525" style="width: 1024px"><figcaption class="wp-caption-text">Courtesy of Jakob Montrasio (CC-BY).</figcaption></figure>
March 30, 2015
Hey Fedorans, I’m trying to come up with an Ansible Talk Proposal for FLOCK in Rochester. What would you like to hear about?
* An intro to using ansible
* An intro to ansible-playbook
* Managing docker containers via ansible
* Using Ansible to do X ( help me choose a value for X😉
* How to write your own ansible module
* How does ansible transform a playbook task into a python script on the remote system
Let me know what you’re interested in
March 23, 2015
I’m excited to tell you about another* new addition to the Fedora Engineering team. In mid-April, Laura Abbott joins our kernel team. She comes to us most recently from Qualcomm. Her projects there included memory management and debugging support. She’s also a regular contributor to the Linux kernel upstream. Laura will work with Josh Boyer and Justin Forbes on projects relating to both the upstream and Fedora kernel. We’re happy to have Laura joining our team soon. Please help us extend her a warm welcome.
March 09, 2015
I’m proud and pleased to announce that Adam Miller is joining the Fedora Engineering team in mid-April, as our new release infrastructure guru. Adam is not new to our community — he’s been involved in Fedora for a number of years. He also has a long history of working on automation, release, and continuous integration in OpenShift, and I’m thrilled he’ll be bringing his experience and energy to our team. Among other things, Adam will be working on the next generation of release tools and deliverables in Fedora, in conjunction with the release engineering team and our community. I hope the Fedora community will join me in welcoming him.
February 20, 2015
Matthias Clasen recently posted some updates on the Fedora development list about new features in Fedora 22 Workstation. As you may know, we’re getting ready to issue an Alpha, so it’s a great time to try out these changes.
- Notifications have improved significantly in Fedora 22. The message tray no longer hides in the bottom, but is subsumed into the top bar. You can review them from the calendar popup. (Here are the original mockups.) Please try out the notifications with your favorite applications and report bugs if you find functional problems.
- The GNOME Shell theme has been refreshed.
- The login screen in Fedora 22 Workstation now runs over Wayland, but falls back to the standard Xorg server if something goes wrong. This is part of Fedora’s overall strategy of getting things running on Wayland early. Wayland as a session option was available in Fedora 21, but we are ultimately moving toward having it as the default in a future release. Note that the fallback calls Xorg in a slightly different way, so you may see bugs (and filing a bug report is welcome).
- The UI for installation of codecs, fonts, MIME types, and so on is now handled by GNOME Software. This change further enhances the sense of GNOME Software as a one-stop shop for installing things, which was a highly praised feature in Fedora 21.
- Nautilus has had multiple improvements, including more pleasant and logical context menus and controls (here are the designs).
Fedora 22 Alpha is scheduled to release on March 10. We hope you’ll give it a try, so you can test drive these new features. Those of you knowledgeable about Fedora 22 pre-releases can find early test candidate images for Alpha in the usual places. Please use Bugzilla to file helpful bug reports. If you need help filing a bug report, this wiki page may be useful.
January 26, 2015
Red Hat has an immediate opening for a full-time engineer to join the kernel team in Fedora Engineering. This job will work with Josh Boyer and Justin Forbes to maintain and improve the kernel in Fedora, and participate and contribute to upstream development and testing. This job interacts with the Fedora team and community, the RHEL kernel engineering groups, and the upstream kernel community.
Ideally we’re looking for someone with significant kernel experience. We want someone who can help manage our own kernel releases. But also we want to get patches and code upstream where it can benefit the entire community, for example to improve hardware support. Red Hat’s a challenging and exciting place to work, and the Fedora team is a great bunch of people to work with. A talented, motivated kernel hacker will find plenty of opportunity here for growth and collaboration.
Applications are being accepted now. You can find more information about the job, and apply online, via the posting here on our Red Hat Jobs site.
January 18, 2015
I’m here in Westford over the weekend with other members of the Fedora Design Team for their Fedora activity day. I traveled up to chilly Boston on Thursday midday, so I could assist by transporting people from the airport to our hotel in Westford.
On Friday, we convened in the Red Hat office in Westford. As is usual for my Westford visits, I pretty much spent the day running from place to place taking care of things unrelated to the Design team, but which needed to be done in my role as a manager. Fortunately most of the day was spent by the team figuring out policy and processes. I don’t feel like my input was needed there, or even appropriate since I’m not a frequent contributor to design tasks — as much as I love the team! So it all worked out for the best, I think.
Today, though, I was able to contribute. One of the major task areas was to do issue triage and fix up the team’s Trac instance. That was something I was (somewhat) qualified to do. I helped the team go through all the pending tickets, closing stale tickets (no response, unclear goals, redundant, etc.).
Then, using the categories developed by the team on Friday, I helped update the parameters on the Trac instance to match. I also set up a bunch of reports on Trac to match relevant agenda items for the reboot of the Design team meetings. This way, they can call up a set of reports to follow up on tickets methodically.
I even learned some good SQL-fu thanks to my buddy Langdon White. I finally got a start shedding my misunderstanding of joins, so I can do more complicated queries. One of the results was this report, which tells the team when an issue reporter is not responsive to questions, in line with the processes the team worked up on Friday.
People tried hard to make sure the FAD was remote accessible, so if you couldn’t be here, you could still monitor or participate. It was difficult to keep some of the facilities working. For instance, this afternoon I discovered that someone had bounced us from our own room on OpenTokRTC. That made it, well, rather difficult for us to broadcast there. I hope remote attendees will understand the difficulties and be confident we tried to make this a decent remote event.
Tonight I’ll probably think about some additional reports, and then do a little personal work. Tomorrow will be some more work sprints until I start chauffeuring people to the airport after lunch. I was happy to be part of the group and to help the participants have an effective FAD.
January 13, 2015
Each summer, Red Hat’s intern program brings in highly motivated and qualified students for a unique, enriching experience. Red Hat internships are demanding, challenging, and fun, just like our full-time jobs. They’re highly selective and (hopefully) highly rewarding for the participants. In the best cases, we find interns who are right for Red Hat, and we may look to hire them permanently after they leave school.
This year, the Fedora Engineering team has two summer intern positions open, and I wanted to make sure people in the community have seen them:
These internships expose students to Red Hat culture and give them opportunities to interact in person with other interns and Red Hat associates. For that reason, both internships are in the Westford, MA (USA) office. Being with other Red Hatters daily will help interns learn more about Red Hat as a company while they work on Fedora. (We may be flexible for a truly exceptional candidate.)
We’re still accepting applications, but we need to talk to specific candidates and make selections soon. So if one of these opportunities sounds like the perfect challenge, use the links above to get your application in before next week!
December 20, 2014
Normally I like to polish my code a bit before publishing but seeing as Fedora 21 is relatively new and a vacation is coming up which people might use as an opportunity to upgrade their home networks, I thought I’d throw this extremely *unpolished and kludgey* ansible playbook out there for others to experiment with:
When I recently looked at updating all of my systems to Fedora 21 I decided to try to be a little lighter on network bandwidth than I usually am (I’m on slow DSL and I have three kids all trying to stream video at the same time as I’m downloading packages). So I decided that I’d use a squid caching proxy to cache the packages that I was going to be installing since many of the packages would end up on all of my machines. I found a page on caching packages for use with mock and saw that there were a bunch of steps that I probably wouldn’t remember the next time I wanted to do this. So I opened up vim, translated the steps into an ansible playbook, and tried to run it.
First several times, it failed because there were unsolved dependencies in my packageset (packages I’d built locally with outdated dependencies, packages that were no longer available in Fedora 21, etc). Eventually I set the fedup steps to ignore errors so that the playbook would clean up all the configuration and I could fix the package dependency problems and then re-run the playbook immediately afterwards. I’ve now got it to the point where it will successfully run fedup in my environment and will cache many packages (something’s still using mirrors instead of the baseurl I specified sometimes but I haven’t tracked that down yet. Those packages are getting cached more than once).
Anyhow, feel free to take a look, modify it to suit your needs, and let me know of any “bugs” that you find
Things I’ll probably do to it for when I update to F22:
- Base my squid proxy setup on this: http://fedoraproject.org/wiki/Infrastructure/Mirroring/ProxyMirror instead of the mock document.
- Pull more of the hardcoded things into variables
- (?) Create a role for this (?)
Hey Fedora Planet, quick survey: I’ve been doing some blogging on general python programming and on learning to use Ansible. Are either of these topics that you’d be interested in showing up on planet? Right now the feed I’m sending to planet only includes Fedora-specific posts, linux-specific, or “free software political” but I could easily change the feed to include the ansible or python programming posts if either of those are interesting to people.
Leave me a comment or touch base with me on IRC: abadger1999 on freenode.
December 19, 2014
Like many people who celebrate holidays around this time of year, I’m taking some vacation time to spend with family and friends. This time helps me relax and recharge for the next year, which promises to be full of energy and new challenges. That’s especially important in a fast paced environment like working at Red Hat.
Quite a few of the Fedora Engineering team members, like me, are taking vacation time. They’ll be at varying levels of connection, so don’t be surprised if it takes longer to reach someone than usual. For example, I’ll be mostly away from the keyboard, visiting family or picking up some musical pursuits. I’ve encouraged our team to use the Fedora vacation calendar, so you know who might not be around. I’m starting my time off after today, and will return to duty Monday, January 5, 2015. (Wow, 2015 still sounds weird to me.)
I hope everyone in the Fedora community has a peaceful and joyous holiday season, and a happy and successful New Year!
December 10, 2014
This release has been a long time coming. It has been about a year since F20 release, and the pause we took as a community to embark upon the first steps of Fedora.next. I know many people have been anxious for the pause to be over. Finally the day has come and gone, and the release seems to be hitting on all cylinders!
I wanted to say thanks to the whole community that contributed to Fedora 21 release. It’s impossible to name everyone who helped, and if I leave someone out it might disappoint someone. So let me just say to everyone:
October 02, 2014
David Gay pointed me to an interesting project called Git by a Bus. Git by a Bus analyzes your git repository and attempts to quantify risk of having lots of code knowledge tied up in only a few people. Git by a Bus does its analysis by going through the repo history and making an estimate of what it calls unique knowledge.
This project blog page describes the analysis and metrics used. Perhaps this is a useful way to show how Fedora is doing as a project, across repositories like our web applications and infrastructure. It might show where we need to encourage further community development and participation so we avoid the “eaten by raptors” problem.
You might recall that “eaten by raptors” is Fedora shorthand for “hit by a bus” (violent idiom) or “going to work for another company” (not always applicable to Fedora, although certainly to Red Hat as a major contributor). We try to solve this problem by spreading project knowledge and documenting our processes. That way, if someone was eaten by velociraptors, the project can keep going without too much of a disturbance. This problem is common to any team or enterprise, not just open source. But I like to think our velociraptor spin is unique.
Here’s an example output I prepared for the MirrorManager project, which we use to provide content to Fedora mirrors worldwide. This is a potential example of high risk. One developer (the inimitable and awesome Matt Domsch) has unique knowledge of this project that is at risk if velociraptors manage to track and eat him. No doubt Matt would put up a good fight, but as you probably know they are clever girls.
Thankfully, there is a MirrorManager related Fedora Activity Day happening later this year. During that time the Fedora infrastructure, release engineering, and applications teams hope to accumulate and document more MM-related knowledge. At the same time they’ll be using this knowledge to architect, plan, and further develop the next revision of MirrorManager.
If you’re a principal in an FOSS project using git for your code, you might find Git by a Bus useful.
October 01, 2014
Today I received my brand new laptop, a Samsung ATIV 9+ (model 940X3G-K04), and of course my first exercise was to boot it on Fedora 21 Alpha. This model has the QHD+ 3200×1800 text display with a touchscreen, and a solid state 256 GB storage device.
First steps with Samsung ATIV 9+
I downloaded the manual on another system, which I read to discover I should hold down the F2 key at power-up to get into the BIOS setup.
I inserted a USB stick with Fedora 21 Alpha installed, before starting the laptop. By the way, I published a screencast on how to make that Live stick. Then I got into BIOS setup, and used the Boot options to enable booting from the USB stick.
I decide to make a full disk image of the pristine hard disk, compress it, and send it to backup just in case. I don’t feel like keeping 20 GB of the disk reserved for a Windows operating system I’m unlikely to use. So:
dd if=/dev/sda bs=1M | gzip -c | ssh email@example.com.X 'cat - > samsung-ativ-full-disk.img.gz'
I’m pretty sure this is going to tie up the laptop for longer than I’d like. On the plus side, it will give the CPU a bit of a burn-in as well. I ran through an installation after the disk copy was finished.
Booting after installation
The first hurdle was that the GRUB text screen is so small as to make it almost impossible to see for anyone over the age of 18. With the aid of a microscope I was able to find the right option to boot without testing.
Note #1: If the screen is also very dim, you can visit the BIOS setting to turn off the automatic screen dimming at boot time.
The actual boot from the Live USB stick was completely uneventful. Of course systemd was super-fast. In no time at all I was in the Live session.
Applications and interface
GNOME 3.14 did an excellent job detecting the HiDPI type display. The GNOME top bar and dock were sharp and readable. The display is gorgeous, quite comparable to a Retina-model MacBook Pro.
Some apps are still suffering a bit on HiDPI, though. LibreOffice and Firefox UI elements are far too small by default. Epiphany a.k.a. GNOME Web, on the other hand, works great. This is probably because GNOME Web responds to the overall GNOME display settings for HiDPI.
Note #2: To make the Firefox interface more HiDPI-friendly, visit the about:config URL page, and change the setting for layout.css.devPixelsPerPx to 2.
The Ctrl and Fn keys are reversed from my Lenovo x220 I’ve used for the last 3.5 years. Sigh, muscle memory. But the function keys mostly seem to work (other than the Windows specific ones).
Samsung ATIV 9+ touchpad issues
After hitting Fn+F5 to test the touchpad enable/disable function on the keyboard, I found the touchpad worked erratically. It sometimes didn’t work at all, even after a cold restart of the laptop. The pointer would disappear when the Terminal application or other text entries came to the foreground. The GNOME on-screen keyboard would emerge at these times, even if I didn’t need it and wasn’t touching the screen.
GNOME hacker and Fedora buddy Ray Strode, in his usual generous style, kindly entertained my questions and found some help for me. This seemed to do the trick:
sudo modprobe -r samsung_laptop gsettings set org.gnome.settings-daemon.plugins.peripherals.touchpad touchpad-enabled true
Ray opined that the routine that was catching the function key to disable touchpad was, for some reason, no longer catching it to re-enable. This might have something to do with the kernel module. I plan to investigate further next time I reboot the system.
This is where the enabling work in GNOME shines. A lot more systems these days have touch screens available. I love the fact that I can drag my apps around the screen with a finger as opposed to the touchpad. The standard auto-sizing targets at top, left and right all work well, so I can quickly maximize or half-size windows.
Unfortunately, the resizing handles on window sides and corners are difficult to grab accurately, which is frustrating. On HiDPI touchscreens, perhaps there’s a way to increase the size of these targets. Overall though, far more goodness than badness.
The keyboard backlight does not work if you install in EFI mode. Presumably, I should be able to reinstall the system after turning off Secure Boot in the BIOS, and then regain this capability. I’ll probably try that over the weekend so I don’t take more time away from productive work during the week.
The laptop itself seems to have sturdy build quality. It’s an attractive slate/charcoal color. The shell definitely shows oil from even clean, dry hands. The glossy touchscreen of course shows even more smudging. It would be nice if Samsung included a cleaning cloth.
I already love the touchscreen and find myself using it to quickly select the Activities overview, the GNOME settings at the upper right, and to swipe the notifications area into or out of view. The display is gorgeous and very bright even at half brightness.
One of the Samsung’s primary draws is its very slim profile. Besides the power adapter port and one USB 3.0 port on each side and the ubiquitous Kensington port, there is a mini-DisplayPort, a small port for the included gig-Ethernet dongle, a mini-HDMI port, and a TRRS-compatible 3.5mm headset port.
I wish the power adapter, whose jack is very slim and concerns me as potentially fragile, was something more like Apple’s “MagSafe” power connector. I’m sure that’s patented up and down to prevent anyone having such a feature. But for klutzes like me it’s definitely a huge help.
The 8GB of RAM seem well-suited, even generous, for a productivity user like myself who occasionally dabbles in virtual machine guests or other memory-intensive applications. It might be sub par for someone who has to run a lot of such apps often. But the ATIV 9+ seems weird to buy an ultralight laptop if that’s your use case, so I think 8GB is about right.
The 256GB solid state drive is incredibly fast. It’s my first SSD and I was shocked at the difference for doing not just the installation, but post-installation updates and software additions, as well as migrating my data over GbE from my older Lenovo x220 to the Samsung. It remains to be seen how the SSD stamina works out based on my routine style of use. However, I suspect if SSD is moving into the general marketplace it’s a good match for me since I’m usually more like a general productivity or creative content user.
I would say the ATIV 9+ is the best rival for the MacBook Air or Pro that I’ve seen.
September 26, 2014
CVE-2014-7169 is an additional security issue in the GNU bash shell that emerged after researchers discovered the fixes for CVE-2014-6271 did not completely solve the vulnerabilities they had identified. Fedora Magazine has a very useful story that tells you why these issues are important.
Since I already published a story on how to deal with CVE-2014-6271, I might as well do a quick followup here for my readers on how to deal with the additional vulnerability.
These instructions will allow you to quickly get packages from the Fedora Koji package build system to address both CVEs, without having to wait for them to propagate to Fedora’s worldwide mirror system.
Fedora 21 Alpha
Run these commands:
su -c "yum -y install koji" # provide root password... koji download-build --arch=$(uname -m) bash-4.3.25-2.fc21 su -c "yum localinstall bash-4.3.25-2.fc21.$(uname -m).rpm" # provide root password again...
Run these commands:
su -c "yum -y install koji" # provide root password... koji download-build --arch=$(uname -m) bash-4.2.48-2.fc20 su -c "yum localinstall bash-4.2.48-2.fc20.$(uname -m).rpm" # provide root password again...
Run these commands:
su -c "yum -y install koji" # provide root password... koji download-build --arch=$(uname -m) bash-4.2.48-2.fc19 su -c "yum localinstall bash-4.2.48-2.fc19.$(uname -m).rpm" # provide root password again...
Hope this helps!
September 23, 2014
I know there are a ton of posts about Fedora 21 Alpha hitting the Fedora Planet, and hopefully elsewhere on the web. But I couldn’t resist saying congratulations to the Fedora community on getting this release out.
We’ve had a long release cycle for Fedora 20 to accommodate a lot of thought and planning. How do we get three products out in place of one? How will we build them? What needs to change? How do we get the bits into place for releases? It’s a lot of work, and we’re not done yet. I suspect that we’ll see further change in the Fedora 22 cycle — although I’d also bet we won’t want to extend another cycle for it.
For my part as manager of the Fedora Engineering team, I am proud of the work all the folks on the team have done to support Fedora 21 Alpha. From changes to infrastructure, to work on new web applications to support multiple products, to notifying Fedora Project members of activity and contribution, to making things generally more beautiful, the team is tireless in their effort to serve the community. As always, my hat is off to them with awe and inspiration.
And of course it’s also off to you, the many, many members of the Fedora Project overall. From Ambassadors to Marketing to Docs to Translation to Websites to… whew. I ran out of breath there. But all of you folks rock!
If you want to pick a copy of any of the new Fedora products — Fedora Server, Fedora Cloud, or Fedora Workstation — just visit the prerelease download page featuring Fedora 21 Alpha, and take your pick.
August 25, 2014
One of the aspects of Fedora is holding public meetings on IRC. We use Meetbot (courtesy of Debian, thanks!) to help administer meetings. Common commands allow Meetbot to do all the hard work of recording proceedings. The automatic minutes make it possible for people who couldn’t attend to follow what happened in the meeting. These minutes are key for maintaining transparency and information flow around the project.
But the minutes still depend on the people who chair the meetings to use the command set to record important data.
- #startmeeting – Sets the overall group for the meeting
- #endmeeting - Cleans up when done, and gives you the URLs for the minutes
- #topic <Topic name> – Sets a topic heading for the next portion of the meeting
- #info – Record some information that’s useful for anyone reading the minutes
- #action <nick> <thing to do> – Clarifies who’s got the ball to complete something before the next meeting; it’s usually a good idea to set a due date*
- #agreed – Documents something the attendees agreed on, also important to make decisions transparent
- #idea – Helps give visibility to something no one is doing yet, but could be useful (also see #help in the MeetBot page)
- #chair <person>… - Add someone(s) to the list of people MeetBot will listen to for commands
* A good friend of mine pointed out that unless you set a due date for an action item, you’re not writing actions, you’re writing a wish list. It should not only be clear who’s got the ball, but when they’re expected to give it back.
Here’s an example of a meeting I ran recently where I used the MeetBot commands to record useful minutes. If you were to look at these minutes later you’d get a pretty good idea of what was covered. You’d also know who was supposed to do tasks before the next meeting. There are a couple action items without clear dates, which is sub-optimal. But overall the meeting minutes are pretty clear.
In some cases, I ended up repeating things people said, using the #info command at the front to tell MeetBot to record in the minutes. If you’re running a meeting you should be prepared to do this. I also like to add everyone in the meeting to the #chair list, to help increase information flow when needed. (It’s also not a bad idea to reduce the chance that a single chairperson will be knocked offline and unable to #endmeeting.)
Are you reading your minutes when done to see if they’re effective? If not, you should. Use what you find to make your meetings better and more transparent for the community. I thought about showing some recent examples of poor minutes usage, but I didn’t want to embarrass anyone.
If your minutes only serve to show a link or two, and an attendance roster, that’s pretty much useless for most community members. Sure, logs are useful, and good for transparency too. But it takes a long time to read logs and extract necessary points from the dialogue. That dialogue can also sometimes be confusing after the fact due to the way IRC works.
Use the facilities we have available to us in Fedora to provide more information and transparency on what you’re doing. The couple of extra minutes per meeting spent using MeetBot will save each reader many more in return!
August 15, 2014
For those who haven’t heard through Flock or the rumor mill, today is my last day at Red Hat and also the beginning of a hiatus from working on Fedora. Since I’ve been asked this many times in the past few weeks, this is because I’ve become a bit burnt out having worked on Fedora as both my day job and my hobby for the past seven years. It’s time for me to pull back, let fresh faces fill the roles I held, and do something else for a while to add some spice and variety. I may come back to Fedora or to Red Hat in the future but at the moment I’m only looking far enough ahead to see that I need to go forth and have some new experiences.
I do want to say thank you to all the wonderful people who have worked not just to make the Fedora distribution a solid piece of software but also filled Fedora with friendly faces and kind words. Truly, although I’m physically far removed from the rest of you, you are my neighbors, my community, and my friends. Even though I’m stepping away from working on Fedora, I hope to keep in touch with you via IRC for many many years.
I’d also like to announce that I woke up this morning to find that I’d been made the gatekeeper for a new Fedora Badge. As the badge submitter describes it:
I dream of a future where Toshio could fully express his techniques with the complicity and trust of many dance partners, responding to his moves and being pushed forward by him in the arts of dancing; exchanging, learning, growing as a vibrant community.
Taking away the specifics of dancing and myself, this is my hope for everyone who participates in Fedora: to be able to grow in sympathy with a larger community.
With that in mind, if we’ve danced together and you would like this badge, please contact me (abadger1999 on IRC, toshio.fedoraproject.org via email). I can’t remember everyone’s FAS usernames but I’m extremely happy to award you the badge if you remind me what of what it is
August 12, 2014
I recently returned home from Prague, where I attended the Flock conference. In it’s second year, the Flock conference is a gathering of free software developers, most of whom work in the Fedora community. Rather than give a blow-by-blow account of every talk I attended and every conversation I had (which would be exhausting), I’ll instead focus on the highlights of the conference.
Location, Venue, and Accommodations
I was very impressed with the location of the conference. The university was within a five minute walk of the hotel, and close to several convenient tram and metro stops. The classrooms were well furnished with power connections and comfortable seats, and the larger auditoriums were big enough to handle a big crowd. The hotel was very nice as well — the lobby was spacious, which made for lots of impromptu meetings and hanging out. Getting from the airport to the hotel was super-easy as well, as was the return trip. Also, the cafeteria where we had lunch was was exceptional — the food was delicious, and the location couldn’t have been more perfect.
There were several themes that resonated with me as I attended the conference. The first was around the changes to the Fedora release products (collectively referred to as Fedora.Next) in Fedora 21 and future releases. Whereas at last year’s Flock conference there was a lot of apprehension and negativity some of the proposed changes, this year I noticed a remarkably more upbeat attitude toward the changes. There was a lot of great discussion round how to get the technical work done that’s needed in order to make Fedora 21 (and 22, and so on) a success.
The next theme that resonated with me was documentation. Maybe it’s because I was giving a talk on documentation, but I felt there was a lot more interest and cohesion around doing a better job of documenting Fedora than I saw at last year’s conference. Both my talk (on Docbook and Publican) and Jaromir’s talk on Mallard were packed, and the two documentation workshops were very well attended as well. At one point during Friday’s workshops, I counted 22 people (besides myself) in the room working on Docs. We also had several new people dive right in and start working on writing documentation, so that was great to see as well.
The third theme that I focused on was ARM processors. The support in Fedora for ARM has grown tremendously over the past couple of years. Peter Robinson’s “ARM State of the Union” talk showed just how far support for ARM has come — both in 32-bit ARM as a primary architecture and with 64-bit ARM as a secondary arch. The ARM workshop on Saturday was great too — I was able to confirm that as of the 3.16 kernel, we now support the Plat’home OpenBlocks AX3 and Mirabox as two more Marvell Armada-based devices that will work great in Fedora 21. (They both require appending the .dtb to the kernel, but other than that, they seem to be working great.)
Last but not least, it was great to have a lot of hallway discussions with friends and colleagues. I had too many discussions to be able to remember them all, let alone discuss them here on my blog, but I thoroughly enjoyed catching up with many old friends and making some new ones as well. I always look forward to opportunities to rub shoulders with so many of the fantastic people that make the Fedora community great.
Thanks to Ruth and Spot and Josh and Miro and all the other folks who worked hard to organize the conference. Thanks to Red Hat for sponsoring my flight, and thanks to my employer, Bluehost, for sponsoring the conference and allowing me the opportunity to be in Prague for the conference. Also, thanks to each one of the presenters for making Flock 2014 a great conference.
August 10, 2014
- The constant stream of late nights was really getting to me. Didn’t arrive at the venue until about 9:15am. I skipped the first session and had some coffee, courtesy of Smooge.
- Caught up on email sent overnight from people in the USA, and did final preparation for my talk.
- I gave my session on the connection between RHEL and Fedora. I also discussed how well things went for RHEL 7 due to work in the Fedora community. I feel like it went very well. You can watch the complete video here.
- I had an excellent conversation with Alberto Ruiz, who manages Red Hat’s desktop applications team.
- Went with Alberto and Patrick Uiterwijk to lunch at the cafeteria. Got to know Patrick a little better, since he will soon be joining us on the Fedora Engineering team.
- Sat in the hall with Patrick and got a Taskwarrior server running on one of my boxes.
- Joined the session on revamping governance in Fedora, which was run by Toshio Kuratomi and Haïkel Guémar. This was hands down the best accomplishment of Flock. There will be a proposal for Board revamp coming from this session (finally!). I’m looking forward to the ensuing discussion and resulting improvements.
At this point I was finally exhausted. I headed back to the hotel early to do a little more reading and writing. I met up with some of the Anaconda team for a late dinner. Then I packed so I’d be ready in the morning to catch my flights back to the USA.
The Flock conference was excellent this year. It was nice getting back into the swing of community things. I enjoyed meeting up with everyone I saw. If I didn’t get a chance to see and talk with you personally, I’m still glad you were there. I hope you had a great time at Flock in Prague. Let’s do it again next year in the USA!
- Didn’t make it up quite so early today, due to not turning in until about 2:30am the previous night. I got to the school basically on time, but worked on email and day job stuff for a little while.
- Attended Matthew Miller’s joint session on Fedora.next.
- Got lunch late, ending up at a table with Stephen Tweedie and a few others. We talked about containers and strategy.
- Touched up my slides for Saturday, getting straight in my head how I wanted the presentation to go. Reveal.js is cool.
- Attended Richard Hughes’ session on building an application installer. GNOME Software is a huge step in usability, and it was enlightening seeing the huge amount of work that went into this tool. I wrote an article on Fedora Magazine covering this presentation.
- Attended Ralph Bean’s excellent workshop on making tools with fedmsg, the Fedora messaging bus built on Zeromq. We learned how to use just a few simple lines of Python to build a Twitter feed from Fedora Badges. Amazing!
- Attended the workshop on DevAssistant. I talked with the developers to learn about their future plans and to discuss desktop integration.
- Met up with Garrett LeSage, Chris Roberts, Matthew Miller, Haïkel Guémar, and others for a great dinner at an Italian pizzeria. It was delicious.
- Late hangout with friends kept me up yet again too late!
August 06, 2014
Here’s a summary of today’s activity where I participated or attended:
- Up at 5:45am so Matthew and I could meet up with Josh Boyer, Tom Callaway, Ruth Suehle, and Joe Brockmeier for breakfast. Then we arrived at the Flock venue early.
- Helped set up rooms with wifi information for attendees. Discovered the rooms feature electronically controlled windows. Once opened, these made the venue much more comfortable.
- Missed keynotes myself while ushing people around to them.
- Worked on my slides for Saturday’s talk, in the great Fedora tradition of iterating until the last minute.
- Sat in on Tim Flink‘s Taskotron talk, and took notes for a Fedora Magazine article.
- Went to a lunch meeting with Ludek Smid, Jaroslav Reznik, Joe Brockmeier, and Matthew Miller. We discussed some project management assistance for our Atomic/OStree work in Fedora. Very productive and we also had a good time.
- Sat in on Christian Schaller’s Fedora Workstation talk. It was very well attended, so I think the idea that the Linux desktop is dead might be a tad premature.
- Sat in on Marina Zhurakhinskaya’s talk on the Outreach Program for Women. I’m happy to say Fedora is an active player in this space. I look forward to our doing even more.
- Sat in on a talk on Waartaa by Ratnadeep Debnath and Sayan Chowdhury. This is an interesting take on a Web IRC client as a basis for other collaboration tools.
- Sat in on Chris Roberts’ and Marie ‘riecatnor’ Nordin’s talk on Fedora Badges and badge design. (If you’re looking for the resources shown in the talk, look here.)
- Headed back to the hotel to finish a Fedora Magazine article. Then I met up with friends to head over to our event at The Pub.
August 03, 2014
If you’ve been reading the Planet Fedora feed lately, you probably know that we’re coming up to time for Flock 2014, a major Fedora conference for Fedora users and contributors from North America and EMEA (Europe/Middle East/Africa). Along with most of the Fedora Engineering team, I’m headed to Prague, Czech Republic for the event.
First, we’ll spend a couple days in the Red Hat Czech office in Brno. We are meeting with a number of colleagues from the office, both to brief them on work we’re doing, and to hear about their current projects and plans. This should help us have a more productive Flock as well.
It’s possible team members may be a little harder to instantaneously reach on Monday and Tuesday while we crunch on these meetups in Brno. At Flock, obviously things will be busy as well. But seeing many community members in one place will probably be quite helpful in getting things done. We’ll do our best as always to stay on top of community requests and input throughout.
Flock 2014 should be an exciting and fascinating conference, and I’m very much looking forward to it. I’m hoping to use the conference to jumpstart my knowledge on Docker, OStree, and some of the other awesome technologies going on in Fedora. And of course I’ll be thrilled to see old and new friends from around the community.
I’m writing this from Schiphol Airport in Amsterdam, getting ready for my next leg of travel to Prague. I’ll be catching a bus to Brno there to meet up with the team. On Tuesday night we’ll get back to Prague. We have a team event that night — so we’ll see everyone bright and early on Wednesday morning at the conference!
July 30, 2014
I just bought a new Logitech M570 wireless trackball for use with my Fedora workstation. I favor a trackball over a moving mouse, because it’s easier on the joints, not to mention more practical on a crowded desk. My previous trackball device was a wired Logitech, and it developed a few problems recently. I’ve had it eight years, so I decided I got my money’s worth and could spring for a new one.
The Logitech M570 uses the Logitech Unifying Receiver USB wireless dongle, common to many Logitech devices. You can pair up to 6 of them to the current unifying device dongle that ships with the M570. Most Fedora users will want this device to be set with correct permissions for people who login on the console. It’s also helpful to be able to query or display battery status.
So here are the steps I recommend to install the Logitech M570 on Fedora. Do these steps before you plug in the receiver or turn on the trackball device. I’m using GNOME 3.12 on Fedora 20, so your mileage may vary:
- You may want to remove your existing pointing device first. Otherwise the new one may not work, at least until you do.
- Install solaar (upstream link), a monitoring and control gizmo for your Logitech Unifying Receiver and connected devices. Thank you to Eric Smith for packaging and maintaining this tool for Fedora!
- Plug in the receiver to an open USB slot. I recommend a rear slot since you likely won’t move this very often. (If you do, there’s a handy slot inside the trackball’s battery compartment where you can store the receiver without losing it!)
- Turn on the Logitech M570, and it should Just Work.
- You can launch solaar from the GNOME Shell, and a notification icon appears in the message tray. You can use this tool to see status and pair or unpair devices.
- (optional) If you want solaar to start every time you login, open the Terminal and enter these commands:
$ cd ~/.config/autostart$ ln -s /usr/share/applications/solaar.desktop .
June 10, 2014
Or: I Went to Read This Community Member’s Blog. What She Wrote about RHEL and Fedora Blew me Away!
Sorry about the clickbaitism. But seriously, after returning from Red Hat Enterprise Linux 7 release festivities this evening I planned to write a blog to the Fedora community about how RHEL and Fedora are intertwined. How Fedora is the cradle of platform innovation that Red Hat relies on to build RHEL and thus to serve as a foundation for many other products. How the community helps select and cultivate technology and prevent Red Hat from investing a ton of resources to make something no one wants.
Then I saw that Robyn Bergeron has already written everything to be said. Which illustrates several points:
- Properly empowered, motivated, and ambitious community is faster than individual effort.
- Robyn is awesome.
- There is no post about Fedora into which we can’t somehow reference His Meatiness.
Need I say more? No. Go read Robyn’s post if you haven’t already. [Mic drop]
June 09, 2014
I’m up in Westford at the Red Hat offices for some departmental events this week. It’s always fun traveling to the office and seeing coworkers and friends I normally only hear (or see online in text form). It does, however, eat mightily into my ability to be online in Fedora and interacting with friends, teammates, and contributors there. I’ll be up here through Thursday afternoon and then flying back home. So if you reach out to me but I’m a little slow to answer you in IRC or email, my apologies, and I’ll catch up as soon as I can!
May 20, 2014
I’m really happy, Robyn, that you’ve been such a big part of Fedora for these years. Whatever comes next, you have huge thanks from me and I know from many others in the Fedora community for your service and spirit. Thanks for including the community in everything you do, and I’m looking forward to working with you in your next role!
May 07, 2014
Have you seen Máirín Duffy’s post on the Fedora Design team’s next-generation design for the Fedora Project website? It’s a brilliant design based around the idea of a “sub hub.” These screens help customize the website to fit different sub-communities, initiatives, teams, or projects.
Máirín published this post with the design mockups a few weeks ago and they’re still open for feedback. I love the concept and the mockups, and the way it brings the site a little closer to the functionality people expect for interaction in other communities. The sub hub design offers a sites not just for promotion, but also for bringing people together for communication and information.
I’m sure the Design team will move forward at some point to bring these concepts into reality. But before they do, I know they’d appreciate hearing from community members. Even just offering feedback that “This is awesome!” is useful, so the designers know there is a solid mass of people who like the work. You can visit the site here to offer your constructive comments.
If you don’t, that’s OK too! Just be polite and specific in your comments. Rather than saying how to fix something, talk about why something doesn’t work for you. Designers are good at figuring out how to solve usability problems once they know more about the effects on the user. Those of us without a lot of design and usability experience often suggest solutions that seem like they’d work, but really might cause more problems for other users. So it’s best to concentrate on symptoms.
So if you haven’t checked out the post and offered some constructive feedback, please feel free. I’m really looking forward to seeing how things move forward with these designs and hope you’re excited about them too.
If you’re excited enough about the work to get involved and help, the Design team would love your contributions. There’s also more information about how to contribute here. There are several repositories set up where you can test existing ideas, change them with your own, and contribute changes back to the team using a pull request. Getting involved is easy, and the Design team is famous for their friendliness and willingness to help people get started contributing. So don’t be afraid to jump in!
March 28, 2014
I also love running the latest GNOME releases. So when GNOME 3.12 was released and available for Fedora 20, I followed these simple instructions, courtesy of Fedora Magazine and Ryan Lerch, to install it on my system.
I discovered a new feature in the GNOME Terminal is that keys Alt+1 through Alt+0 are mapped to allow you to quickly navigate to the first ten tabs in Terminal. This is super-useful, but because those keys also happen to map to the shortcuts in Irssi for switching to your first ten IRC windows, I couldn’t use them in Irssi. Since I use that function a lot more often, here’s how I fixed it:
- Open a GNOME Terminal, and from the quick menu in GNOME Shell’s top bar, choose Preferences.
- Under the Shortcuts tab, locate the Tabs list.
- For each shortcut from “Switch to Tab 1″ to “Switch to Tab 10,” click the shortcut to select it. Then click the entry under Shortcut Key. Hit the Backspace key to remove the existing shortcut.
Now you can use your Alt key combinations as before in Irssi. Have fun!
February 23, 2014
Here is a quick writeup of the protocol for the iKettle taken from my Google+ post earlier this month. This protocol allows you to write your own software to control your iKettle or get notifications from it, so you can integrate it into your desktop or existing home automation system.
The iKettle is advertised as the first wifi kettle, available in UK since February 2014. I bought mine on pre-order back in October 2013. When you first turn on the kettle it acts as a wifi hotspot and they supply an app for Android and iPhone that reconfigures the kettle to then connect to your local wifi hotspot instead. The app then communicates with the kettle on your local network enabling you to turn it on, set some temperature options, and get notification when it has boiled.
Once connected to your local network the device responds to ping requests and listens on two tcp ports, 23 and 2000. The wifi connectivity is enabled by a third party serial to wifi interface board and it responds similar to a HLK-WIFI-M03. Port 23 is used to configure the wifi board itself (to tell it what network to connect to and so on). Port 2000 is passed through to the processor in the iKettle to handle the main interface to the kettle.
Port 2000, main kettle interfaceThe iKettle wifi interface listens on tcp port 2000; all devices that connect to port 2000 share the same interface and therefore receive the same messages. The specification for the wifi serial board state that the device can only handle a few connections to this port at a time. The iKettle app also uses this port to do the initial discovery of the kettle on your network.
DiscoverySending the string "HELLOKETTLE\n" to port 2000 will return with "HELLOAPP\n". You can use this to check you are talking to a kettle (and if the kettle has moved addresses due to dhcp you could scan the entire local network looking for devices that respond in this way. You might receive other HELLOAPP commands at later points as other apps on the network connect to the kettle.
Initial StatusOnce connected you need to figure out if the kettle is currently doing anything as you will have missed any previous status messages. To do this you send the string "get sys status\n". The kettle will respond with the string "sys status key=\n" or "sys status key=X\n" where X is a single character. bitfields in character X tell you what buttons are currently active:
|Bit 6||Bit 5||Bit 4||Bit 3||Bit 2||Bit 1|
So, for example if you receive "sys status key=!" then buttons "100C" and "On" are currently active (and the kettle is therefore turned on and heating up to 100C).
Status messagesAs the state of the kettle changes, either by someone pushing the physical button on the unit, using an app, or sending the command directly you will get async status messages. Note that although the status messages start with "0x" they are not really hex. Here are all the messages you could see:
|sys status 0x100||100C selected|
|sys status 0x95||95C selected|
|sys status 0x80||80C selected|
|sys status 0x100||65C selected|
|sys status 0x11||Warm selected|
|sys status 0x10||Warm has ended|
|sys status 0x5||Turned on|
|sys status 0x0||Turned off|
|sys status 0x8005||Warm length is 5 minutes|
|sys status 0x8010||Warm length is 10 minutes|
|sys status 0x8020||Warm length is 20 minutes|
|sys status 0x3||Reached temperature|
|sys status 0x2||Problem (boiled dry?)|
|sys status 0x1||Kettle was removed (whilst on)|
You can receive multiple status messages given one action, for example if you turn the kettle on you should get a "sys status 0x5" and a "sys status 0x100" showing the "on" and "100C" buttons are selected. When the kettle boils and turns off you'd get a "sys status 0x3" to notify you it boiled, followed by a "sys status 0x0" to indicate all the buttons are now off.
Sending an actionTo send an action to the kettle you send one or more action messages corresponding to the physical keys on the unit. After sending an action you'll get status messages to confirm them.
|set sys output 0x80||Select 100C button|
|set sys output 0x2||Select 95C button|
|set sys output 0x4000||Select 80C button|
|set sys output 0x200||Select 65C button|
|set sys output 0x8||Select Warm button|
|set sys output 0x8005||Warm option is 5 mins|
|set sys output 0x8010||Warm option is 10 mins|
|set sys output 0x8020||Warm option is 20 mins|
|set sys output 0x4||Select On button|
|set sys output 0x0||Turn off|
Port 23, wifi interfaceThe user manual for this document is available online, so no need to repeat the document here. The iKettle uses the device with the default password of "000000" and disables the web interface.
If you're interested in looking at the web interface you can enable it by connecting to port 23 using telnet or nc, entering the password, then issuing the commands "AT+WEBS=1\n" then "AT+PMTF\n" then "AT+Z\n" and then you can open up a webserver on port 80 of the kettle and change or review the settings. I would not recommend you mess around with this interface, you could easily break the iKettle in a way that you can't easily fix. The interface gives you the option of uploading new firmware, but if you do this you could get into a state where the kettle processor can't correctly configure the interface and you're left with a broken kettle. Also the firmware is just for the wifi serial interface, not for the kettle control (the port 2000 stuff above), so there probably isn't much point.
Missing functionsThe kettle processor knows the temperature but it doesn't expose that in any status message. I did try brute forcing the port 2000 interface using combinations of words in the dictionary, but I found no hidden features (and the folks behind the kettle confirmed there is no temperature read out). This is a shame since you could combine the temperature reading with time and figure out how full the kettle is whilst it is heating up. Hopefully they'll address this in a future revision.
Security ImplicationsThe iKettle is designed to be contacted only through the local network - you don't want to be port forwarding to it through your firewall for example because the wifi serial interface is easily crashed by too many connections or bad packets. If you have access to a local network on which there is an iKettle you can certainly cause mischief by boiling the kettle, resetting it to factory settings, and probably even bricking it forever. However the cleverly designed segmentation between the kettle control and wifi interface means it's pretty unlikely you can do something more serious like overiding safety (i.e. keeping the kettle element on until something physically breaks).
February 08, 2014
DevConf.cz day 1, Friday.
Friday was the first day of sessions at DevConf.cz, the biggest and best Czech open source event by developers, for developers. The event was packed, with over 900 attendees even before the weekend started!
First up at 9:00 sharp was Tim Burke’s keynote about how Red Hat sees the IT market, specifically Linux and open source technologies. He covered how the various pieces of cloud, applications, storage, and platform fit together. It was pretty breakneck because there wasn’t a lot of time until the sessions started, but well observed and thoughtful. It’s clear the technologies built by people at this conference will set the pace for the future. The market has placed its bets on Linux and open source, and now it’s on us to deliver!
Langdon White followed with a story of startups. He covered how the tradeoffs between agility, stability, and maintenance can be mitigated by Software Collections. Software Collections allow IT groups to add stacks on their platform without affecting the deployment itself, while meeting more needs for developers and users.
Alex Larsson did a talk to a packed room (the biggest at the conference, no less!) on Docker, the open source container engine rapidly sweeping the community with its speed and flexibility. Fedora is rapidly developing a great grasp of Docker, and you can already install it on all supported Fedora releases. Obviously Red Hat has taken a huge interest in Docker too, so it’s no surprise the talk was SRO.
I went to Colin Walters’ session on OStree, a new way of distributing Linux operating systems. I found this session incredibly compelling, and I hope we look seriously at OStree in Fedora because of the problems it solves. There are clearly some issues that still need to be worked out, but Colin is up front about them, and he’s motivated and eager to collaborate with people to solve them. He’s truly one of the good guys of free software and I enjoyed this talk a lot.
I also attended Ondrej Hudlicky’s session on software usability, which was entertaining but also thought-provoking. A lot of what goes into making good software we either take for granted or completely miss. It’s so easy for software to suck when you don’t start by thinking about what the user is trying to do, and making that easy. Although the slides were quite dense, Ondrej did a great job explaining the concepts and why they were important.
I also attended sessions on DNF’s SAT solver, caught a bit on static analysis that went way over my head, and saw Richard Hughes’ session on GNOME Software. DevConf.cz is so packed with content, it’s impossible to see more than about half of what you’d like. There’s so much more content for Java folks, low-level network and hardware hackers, and kernel jockeys that it makes your head spin!
In the evening I went with a bunch of folks to get pizza at the hilariously named Pizzeria Al Capone down the street. The food was quite good, and the beer plentiful as we swapped stories and jokes. We had people from all over the globe at the table so it was a great night. Afterward we retired to the famous bowling bar in the basement of the Hotel Avanti. And of course, more beer and stories. I turned in rather late, around 1:00am, but in good shape for the next morning.
DevConf.cz day 2, Saturday.
Started out the day early again, with a 9:00am session on Cockpit. Cockpit is a new Linux server management user interface that beautifully fits the look and feel of modern desktops. It’s also has already grown a lot of capability including user and storage administration. This is a great way for us to break away from clunky and individually deprecating system-config-* tools. Instead we can move to a tool that’s more flexible, extensible, and network transparent for scalability.
Following was a talk by Russ Doty on security concerns in platform and application development. It was mainly general but made some good points about where threats usually come from (hint: not Igor the evil state-funded hacker).
Of course, no DevConf.cz event would be complete without a rapid-fire presentation from Lennart Poettering, and this year was no exception. Lennart covered kdbus, a new kernel implementation of IPC based on the excellent D-Bus. Kdbus is on its way into the kernel and will make Linux even slicker, starting with early boot and extending all the way to latest shutdown.
I also sat in on Ric Wheeler’s excellent presentation on Persistent Memory, which is next generation storage technology. Ric covered some of the challenges in supporting new types of storage in the Linux kernel, and the relative strengths and weaknesses of each.
Afterward, I went to lunch with Ralph Bean and Pierre-Yves Chibon from the Fedora Engineering team. With us were Patrick Uiterwijk and folks from Red Hat that work on infrastructure and tools for RHEL and JBoss engineers. We discussed some areas of potential collaboration, including a messaging bus for Red Hat Bugzilla. That could be an awesome new input for contributor data.
Then all the smart folks went off to find better broadband at the hotel to pore over some code together. Since I wouldn’t have been much help, I went back to the conference to catch Simo Sorce’s talk on Kerberos.
Following Simo, Dan Walsh talked about secure Linux containers. As always he was tremendously entertaining. Dan joked about how he’s been a big proponent of libvirt-sandbox for secure container support, but recently “got religion” about Docker. I hope this was taped because it was really informative. No wonder Dan’s consistently rated as a top speaker at the Red Hat Summit. (Note, you can still register for the event; I’ll be there in San Francisco too!)
Next Kyle McMartin talked about the pleasure and pitfalls of porting the Linux kernel to new architectures (hello, aarch64!). I admit a lot of this went over my head, but Kyle told some funny stories about stalking weird bugs in test suites exposed by porting. At least I think they were funny. Or rather, I think some people thought they were funny, since they were all laughing. I don’t understand kernel people, but they’re mostly lovable, and many of them have awesome beards.
Finally, I saw a talk on Arduino Yún. This model includes a small, embedded Linux computer that you can make do all sorts of cool things with the built-in sensors and other capabilities. The talk made me wish I had more spare time to spend on learning how to do hardware tinkering. Where’s my time machine?
I bowed out of the lightning talks (even though some of them looked awesome) so I could drop my bag at the hotel before the night party at Klub Fléda, a sort of warehouse-y bar/music club nearby the conference venue. With beer beckoning, it’s time to relax a bit with friends and colleagues!
Tomorrow there will be Fedora focused sessions, so I’m really looking forward to that. More later…
Today I released PulseCaster 0.1.10 with some under the hood improvements:
- Switch from GConf to GSettings, and include schema file
- Providing appdata for GNOME Software
- Provide hidden “audiorate” key for 44.1/48 kHz selection
- Complete GObject introspection switchover, eliminating excess dependencies and fixing bugs (RHBZ #1045717)
- Automatically provide .ogg filename extension in standard mode
- Additional translations
I’m planning some UI improvements for this little podcasting utility. I’m also hoping to do significant code refactoring for 0.2, tentatively scheduled for late spring/early summer. I’m also thinking about moving the central development repo to GitHub, since that’s where a lot of other Fedora incubated projects have migrated.
Of course, updated packages are coming shortly for Fedora 20.
PulseCaster lets you record interviews with simplicity. It pulls audio from two sources via PulseAudio, then mixes them into an Ogg Vorbis file for you. There’s also an expert mode that allows you to lossless audio in WAV format, and mix the audio yourself with post processing. For example, you could interview someone via a Voice-over-IP (VoIP) application, then include the interview in your podcast.
I used a little time between sessions (and during one session where I was completely in over my head) to push this out. It was nice to work on some free software of my own at a conference for developers! Hope you enjoy the new PulseCaster release.
February 07, 2014
I’ve been at Red Hat’s Czech office in beautiful Brno this week. That means lots of meetings, lots of email and conversations, and lots of good beer. But the best part is this weekend’s big event, the Developer Conference event.
This is one of the biggest open source events in the region, and it’s all organized and held by developers and engineers, for developers and engineers. There are hundreds of people here from across the globe, including plenty of folks from Red Hat but also upstream and downstream contributors from many other companies and volunteers as well.
There is so much good content happening at this conference, I’m not sure how I’ll get to see even half of what I’d like to. But as we like to say, it’s a good problem to have. Stay tuned to the DevConf.cz site for proceedings and links to recordings.
January 10, 2014
Just installed a new system and was having ssh connections timeout. Then I remembered talking about this same issue last year on IRC. The anecdote is amusing so I figured I would post the logs:
[Mon April 22 2013] * abadger1999 wishes he knew why his ssh connections to infra keep on hanging.
[Mon April 22 2013] <abadger1999> it’s a timeout of some sort… I just don’t know what.
[Mon April 22 2013] <skvidal> abadger1999: did you reinstall recently?
[Mon April 22 2013] <abadger1999> skvidal: nope
[Mon April 22 2013] <abadger1999> skvidal: would that help?
[Mon April 22 2013] * abadger1999 still on f17
[Mon April 22 2013] <skvidal> I have found I often need to set
[Mon April 22 2013] <skvidal> net.ipv4.tcp_keepalive_time = 300
[Mon April 22 2013] <skvidal> in /etc/sysctl.conf
[Mon April 22 2013] <skvidal> to not get timeouts
[Mon April 22 2013] <abadger1999> Thanks. I’ll try that .
[Wed April 24 2013] <abadger1999> skvidal: btw, your sysctl recipe seems to have fixd my ssh timeout issues. Thanks!
[Wed April 24 2013] <skvidal> abadger1999:
[Wed April 24 2013] <skvidal> abadger1999: last time it happened to me I had to google for the solution
[Wed April 24 2013] <skvidal> abadger1999: and I found a post from myself from 5yrs earlier
[Wed April 24 2013] <skvidal> abadger1999: _that_ is kinda freaky
[Wed April 24 2013] <pingou> isn’t that what blog are for?
[Wed April 24 2013] <dwa> nice
[Wed April 24 2013] <abadger1999> Cool
[Wed April 24 2013] <skvidal> “wow, this dude knew what was going on…. but he sure writes like he’s an ass”
[Wed April 24 2013] <skvidal> “oh….. wait”
Seth, you were more of a teddy bear than an ass.
December 26, 2013
Sorry to post this a day late for some Christmas celebrants. Hopefully you will have had such a wonderful holiday that you can forgive the tardy good wishes!
Wherever you are in the Fedora community, and whatever holiday you may or may not celebrate: I wish you a joyous season and the best and most successful possible 2014. May you have peace and help spread goodwill to all, whether through free and open source software or in other ways. Happy holidays!
December 17, 2013
So to Robyn and all contributors across the entire project — congratulations on a job well done. I can’t wait to see what you come up with next!
What are you waiting for? Christmas is here early, go get it!