The Fedora Project will soon put out its 21st release. I’ve been running the pre-release bits for a while now, here are a few observations:
Last Saturday a few of us gathered to work on Fedora Security. This FAD (Fedora Activity Day) was the second in recent times held in Pune, after the testing FAD held in August.
The goal of the FAD was to get introduced to the newly-formed Fedora Security Team, pick up a few bug reports that were tagged as security-relevant bug reports, and triage them. Fixing the bugs wasn’t part of the agenda, as actually pushing package updates needs one to be a provenpackager or the maintainer of the package.
I participated in the Fedora Activity Day at the RH office in Pune yesterday. There was a decent turnout, 20+ people, and it was fun to test the in-progress version of the upcoming F21 release along with other folks.
I’ve been using the Fedora 18 pre-release for a couple of months now, and am generally happy with how it works. I filed quite a few bugs, some got resolved, some not. Here’s a list of things that don’t work as they used to in the past, with workarounds so they may help others:
If you have enabled git information in the shell prompt (like branch name, working tree status, etc.) , an upgrade to F18 breaks this functionality. What’s worse, __git_ps1 (a shell function) isn’t found, and a yum plugin goes looking for a matching package name to install, making running any command on the shell *very* slow.
The GNOME default of ‘hibernate’ or suspend-to-disk on very low battery power isn’t optimal for many laptops — hibernate is known to be broken on several hardware setups, it frequently results in file system corruption, and just causes pain. That, combined with the weird behaviour of the GNOME power manager to put the system in hibernate, even when the battery isn’t low, annoyed me enough to go hunting for a way to change the default.
The GUI doesn’t expose a ‘sleep’ setting; it just offers hibernate and shutdown, so here’s a tip to just put the system to sleep state (suspend to RAM), which is a much well-behaved default for me.
Updating a Fedora 16 guest to a Fedora 17 guest via preupgrade gave me the ‘Oh no, something has gone wrong!’ screen at the GDM login screen. It’s quite frustrating to see that screen because you can’t switch to a virtual terminal for troubleshooting, or even reboot or shutdown.
To send the key sequence Ctrl+Alt+F2 to the guest to switch to a virtual terminal, use the qemu monitor by pressing
and use sendkey to send the key sequence:
(qemu) sendkey ctrl-alt-f2
Then go back to the guest window by issuing
After logging in as root, I poked in the gdm log files in /var/log/gdm/ and saw the fprint daemon was causing some errors. Removing the fprintd package fixed this, but this is just a workaround, not a solution:
yum remove fprintd
My article on FUDCon Pune 2011 appeared on opensource.com last week:
Apparently my initial submission was about 3x longer than the average article on opensource.com. I’ve covered events running up to the conference on this blog, and with the osdc article, I’ve covered the conf as well. There still might be a few things left which I’ll post about here in the coming days.
My second talk at FUDCon Pune was on Virtualization (slides) on day 2. While I had registered the talk well in advance, I wasn’t quite sure what really to talk about: should I talk about the basics of virtualization? Should I talk about what’s latest (coming up in Fedora 16)? Should I talk about how KVM works in detail? My first talk on git had gone well, and as expected for this FUDCon, majority of the participants were students. Expecting a similar student-heavy audience for the 2nd talk as well, I decided on discussing the basics of the Linux Virt Stack. Kashyap had a session lined up after me on libvirt, so I thought I could give an overview of virt-manager, libvirt, QEMU and Linux (KVM).
And since my registered talk title was ‘Latest in Linux Virtualization’, I did leave a few slides on upcoming enhancements in Fedora 16 (mostly concentrating on the QEMU side of things) at the end of the slide deck, to cover those things if I had time left.
As with the previous git talk, I didn’t get around to making the slides and deciding on the flow of the talk till the night before the day of the talk, and that left me with much less sleep than normal. The video for the talk is available online; I haven’t seen it myself, but if you do, you’ll find I was almost sleep-talking through the session.
To make it interactive as well as keep me awake, I asked the audience to stop me and ask questions any time during the talk. What was funny about that was the talk was also being live streamed, and the audio signal for the live streaming was carried via one mic and the audio stream for the audience as well as the recorded talk was on a different mic. So even though the audience questions were taken on the audience mic, I had to repeat the questions for the people who were catching the talk live.
I got some feedback later from a few people — I missed to introduce myself, and I should have put some performance graphs in the slides, as almost all users would be interested in KVM performance vs other hypervisors. Both good points. The performance slides I hadn’t thought about earlier, I’ll try to incorporate some such graphs in future presentations. Interestingly, I hadn’t also thought of introducing myself. Previously, I was used to someone else introducing me and then me picking up from there. At the FUDCon, we (the organisers) missed on getting speaker bios, and didn’t have volunteers introduce each speaker before their sessions. So no matter which way I look at it, I take the blame as speaker and organiser for not having done this.
There was some time before my session to start and there were a few people in the auditorium (the room where the talk was to be held), so Kashyap thought of playing some Fedora / FOSS / Red Hat videos. (People generally like the Truth Happens video, and that one was played as well.) These, and many more are available on the Red Hat Videos channel on YouTube. There was also some time between my session and Kashyap’s (to allow for people to move around, take a break, etc.), so we played the F16 release video that Jared gave us.
Overall, I think the talk went quite well (though I may have just dreamed that). I tried to stay awake for Kashyap’s session on libvirt to answer any questions directed my way; I know I did answer a couple of them, so I must have managed to stay up.
I had targeted the session for beginners; however I had some help from Shakthi, who conducted a session on git during the 2nd FAD and from Ramky who spoke on version control systems in the talk before mine. So I could skip a few basic things and get right on to the demo.
I didnt really get the luxury to prepare well in advance; I had in my mind what I would do in general, but the got the slides and the flow ready just the night prior to the talk. Organising FUDCon wasn’t too taxing, but there are a few last-minute things that have to be done, well, at the last minute. And the presentation, etc., had to wait.
I have earlier seen students just attend sessions but not really follow up on what they were being taught. So I thought I’d make this an interactive session, inviting people from the audience to participate in the session by someone coming up on the stage and writing a .c program, someone else coming up and creating a git repo, then someone else modifying the code, doing another commit, and so on.
While I thought about this, I recalled Rusty’s session at foss.in a few years back where he did such a thing successfully. Now emulating that feat would be really difficult. People who have attended Rusty’s talks would know what I mean. He puts in hours and days for such talks. I’m sure he’d have thought about how to pull it off even if the person to come up on stage wouldn’t know how to type.
There were about 50 – 60 people attending the talk. So what I did, instead, was to ask the attendees about who knew how to write C programs, and who knew how to type fast. I called up one such attendee and asked him to write a simple ‘Hello, World!’ program.
I then called up someone else (Aditya) to commit the first version. Thankfully, the original C file did not have any punctuation in the ‘Hello, World!’ string, so the idea for the 2nd commit was ready. Once Aditya initialised the git repo and did the first commit, I modified the program output to add the comma and exclamation point and make that the 2nd commit in the git repo. I then moved on to create a new C program that prints out ‘Goodbye, World’ (we had dedicated the conference to Dennis Ritchie). This was done in a new branch called ‘goodbye’. Next was to create another branch, called ‘fudcon’, and write another C program to show ‘Hello, FUDCon’. Then a few lessons on merging, switching branches, viewing commits and logs from other branches followed. The slides have the list of commands that were shown.
The last step was to clone this repo into another local one, commit a few things there, do a push into the original repo, make some other pulls here and there, and the session participants were ready with hands-on git lessons that they could use.
I had quite a few questions during and after the session, and I even heard of people trying out the examples after the talk. So I’d call the talk/demo a success.