Fedora Badges

August 10, 2013

So this is kind of interesting:


Fedora is rolling out a system where contributors get badges for doing various things (like doing package builds, or tagging keywords to software, or editing the wiki).

git tip of the day

August 2, 2012

So I just wanted to give a quick git tip, since I see people give them occasionally and I find those posts useful for me.

It’s often important to try find a commit where something was introduced originally. This is good for figuring out what commit to squash to fix up to, or for doing code archaeology to figure out context beside why a certain piece of code exists. I see a lot of people use git log –grep or git log -S. Those commands are nice and there is nothing wrong with them. I don’t usually like using them, though. I prefer:

git log -p

This will show you every commit message and patch in reverse chronological order paged through less. less has powerful search features built in. So you can for instance type:


to search for the last instance of when my_function was added in the code. If you hit "n" it will jump to the next to last instance, and so on. If you decide you want to seek backward over an entry you already went past you can do "?" and then "n" repeatedly. "/" to seek forward again.

Why do I like this better?

  • Because it’s interactive and more flexible. You can switch search terms mid-stream (tell me when bar() was called, but only before foo() was implemented in history)
  • Because it lets you see the surrounding commits. Seeing a commit in isolation is useful, but being able to see the commits that went in along side it is often invaluable for gleaning context into the motivation behind the commit.

Okay one more quickie: Another option that’s useful to throw before the "-p" in "git log -p" is "-U30". This amps up the amount of diff context surrounding the changes introduced in a patch, often making those changes imminently more clear. It’s no fun to see a patch that modifies the middle part of a function, and not being able to see what the function does.

So that’s my git tip.

Shell features

July 13, 2011

So Allan posted a pretty good summary of all the cool goings ons in shell land right now.

I thought I’d just follow up with a quick video showing two of the work-in-progress features, the login screen and the on screen keyboard.

As promised in my last post I’m going to do a follow up post with more details about where GDM is going in 3.2, but for now just the quick video: (click here)

So, when a user turns on their computer, boot ups, and then enters their username, password, etc, under the covers GDM is using a framework called PAM to do the heavy lifting of processing the login request. PAM is a fairly old, and established library that reads a “service” file to determine what plugins to load, and in what order to load them. The plugins determine what questions to ask the user, verifies the answers the user gives are acceptable, and things like that. As an example, one pam module is pam_unix which will get GDM to ask for a username and password that get checked against /etc/passwd and /etc/shadow (in a lot of cases anyway). Another example, is a module called pam_rps that makes the user play rock-paper-scissors instead of entering a password. Some PAM modules may not want text answers at all, though. For instance pam_fprintd just waits for the user to swipe their finger.

Traditionally, applications that use PAM only ever have one conversation running at a time. That one service file is loaded up and that service file’s stack of modules are run through in order as defined by the policy in the file. If a user wants fingerprint and password support, then they have to use a service file that mentions both pam_unix and pam_fprintd, and the modules have to provide some way to “fall through” to the next module. That means potentially giving up on waiting for fingerprint after 30 seconds and then jumping to pam_unix to ask for password, or something suboptimal along those lines.

Of course, ideally a user doesn’t want this serialized behavior. Instead, they want to either be able to type their password right away or swipe their finger right away and have the right thing happen.

One solution, that’s been slowly trickling in from a branch in git for quite a while, is to run multiple PAM conversations concurrently. I’ve deemed this ‘multi-stack’ or ‘split authentication’. So we can have the “password” stack of pam modules and the “fingerprint” stack both cheefully running along, independent of each other. If the user satisfies the requirements of one of the conversations (say by swiping their finger or entering their password), we cancel the other and proceed with login.

It’s a useful feature, and I finally decided to cut the remainly bulk of the work over to master yesterday in time for the 3.1.2 release. distros will have to enable it with –enable-split-authentication=yes passed to configure, and probably need to modify their pam configurations to accomodate.

I wouldn’t say it’s in perfect shape (in particular the greeter plugin interface is pretty unpleasant), but I wanted to land it now since it’s been lingering on the branch for so long. I’m sure there will be follow commits to deal with unexpected breakage as distros pick it up.

Next thing I’d like to do for 3.2 is get more GNOME 3 integrated greeter. I’ll try to do a follow up post about that soon.

Fedora 15

May 24, 2011

So Fedora 15 is out today with pretty good GNOME 3 support.

If you haven’t tried Fedora in a while and are feeling like trying something new and different, give it a try!

System Modal Dialogs

October 25, 2010

So in an effort to help make GNOME 3 turn out as good as possible, I’m helping figure out the story for system modal dialogs in the presence of the shell.

Firstly, I have to say that working with the shell is really rather refreshing. It’s very neat to start with a “naked” dialog and write some CSS and see it morph into the mockups. It’s a totally different development experience but it feels really natural. Also, doings things in javascript is interesting, too. Being able to test changes without recompiling, etc, is a nice change of pace, and javascript as a language has some nice constructs (like for (key in hashTable) { … }) that make some programming tasks look tidier than what I’m used to. GObject introspection makes it really easy to talk to various libraries, too. There’s some stylistic things I don’t like about javascript (like camelCase), and there’s occasionally some googling to figure out the “javascript way”, but overall it’s a very pleasant platform to develop for.

Anyway, I don’t really want to make this blog post about GNOME 3 as a development platform, but more about system modal dialogs. These dialogs are the things that should be dealt with “right away”. These are things that require the full attention of the user. As such, they should

  • should appear front and center on screen
  • should be clearly coming “from the OS” versus from an application
  • should “take the stage” until dismissed

The idea is these are things that really can’t wait, be side lined, etc. In general, only the os “core” should ever need to present a system modal dialog.

Most dialogs should not be system modal, since most dialogs come from applications. Also, system modal dialogs have a very high “cost” to the user since by their very nature, they’re modal. That is to say, they preempt the user from whatever auxiliary tasks the user was doing and prevents those tasks from being available again until after the dialog is dealt with. In this regard, system modal dialogs should never be unexpected. They should always be the direct consequence of something the user was doing. For many use cases the message tray is a better option than system modal dialogs.

One example where system modal dialogs are very relevant is password dialogs. We really need password dialogs to have a consistent look that matches the look for the shell. This is important so that we can “train” the user into learning what a password dialog should look like, so they think twice before inputting their password into a dialog that’s not provided by the OS. This paves the way for a trusted path future. Of course, it’s only a step in the right direction. Actually getting trusted path is a hard problem that’s going to have to get solved at some point in the future. WHen that feature is seriously looked at, the final solution may involve one or more of: secure attention keys, wayland, factory mode login screens, integration with the users cell phone, or other possibilities

Another example of a dialog that should be system modal is the logout dialog.

Now, I just want to give a few details about where I’m going on the implementation side of things. Since we know that system modal dialogs need to “look like” the shell, they probably need to run in the shell process. (there’s no plan to make GTK+ have a “Look like the shell” mode etc). On the other hand, these dialogs are very tightly bound to the service that wants it. For instance, gnome-session is the only thing that should ever be able to summon the logout dialog for the shell. Everything else should talk to gnome-session.

Given how closely bound a dialog is to the particular service needing the dialog, ideally, its implementation should be easily adaptable to changes the service needs as the services needs them. While the look and feel both need to align with the shell, the contents of the dialog need are details almost entirely specific to the service requesting the dialog. The interface between the dialog and the service should be private and without any sort of backward compatibility constraints, etc. This means it would be best if we could ship the implementation for the dialog with the service. But how do we ship the implementation with the service and run that implementation in the shell?

The shell already has a very powerful mechanism for extending itself. This extension system allows us to automatically load a custom javascript file and associated css stylesheet at startup. By leveraging this feature, gnome-session (for example) can ship its logout dialog right in its own source tree, change it whenever necessary without having to coordinate with the shell, and still achieve the “core os” look that’s important.

There are some unresolved details on how these “private” extensions should differ from the more public, user installable extensions the extension system was originally designed for (like should the extension interface be different, should the private extensions show up in the extension list in the UI, etc).

Now, even though we’ve decided the javascript should ship in the individual service source trees, there’s still the question of how the dialog and the service will communicate. Luckily, the javascript code has a great dbus binding called gjs-dbus that makes it pretty simple to export an interface on the session bus that each relevant service can talk to.

Another question is how much “heavy lifting” should be in the javascript code. I mean should the javascript dialogs just be dumb proxies of questions and answers between the user and service? Or alternatively, e.g., when the user clicks, shutdown should the javascript code implementing a shutdown dialog actually call out to ConsoleKit and initiate the shutdown in response to the user? I don’t think there’s any really right answer here. Certainly, given the support for gobject introspection and the convenient dbus bindings, a lot of low level things could be done straight from the dialog. There’s also something to be said for keeping the shell “lean” so there aren’t a lot of moving parts (with bugs) destabilizing something so fundamental to a functioning system. I think different services will have different amounts of “implementation” versus “presentation” in their extensions.

This blog post is already getting a bit long, so I’m going to cut it off here. I’ll do another post at some point with some results from the above considerations.


July 30, 2010

So Mo and I finally got engaged.

us together
(an oldish photo of us together)

Her ring

(Mo’s engagment ring!)

Plymouth ⟶ X transition

November 28, 2009

So one of the big polish bits in the boot process is the transition from plymouth to X. In Fedora, we worked to make it as seemless as possible when we first started on the Better Startup stuff a few releases ago.

If you haven’t seen it, when boot up finishes, plymouth settles down the boot splash to a transitionable animation frame, then the mouse pointer shows up, and GDM’s background cross fades in while the login window maps and expands to show frequently logged in users. In the best case, this transition all happens without any flicker, resolution changes, black intermediate screens, or console text showing up.

The way we accomplished this was:

  1. I gave “plymouth quit” a “–retain-splash” option which told plymouth to keep the boot splash’s contents on screen even after plymouth exits
  2. krh and ajax added a -nr option to the X server to make X not clear the screen to black (or a weave) at start up
  3. krh, airlied, and darktama (Ben Skeggs) added the driver backend support for -nr to intel, ati, and nouveau drivers respectiviely. Also, Bill Nottingham made -nr work with the fbdev X driver.
  4. ajax made the ugly big “X” mouse cursor not show up by default
  5. I made gdm stuff the screen contents to a pixmap referenced by the pseudo-standard _XROOTPMAP_ID root window property
  6. I also made gnome-settings-daemon cross fade from the _XROOTPMAP_ID pixmap when it loads its background. This step meant we also get a nice transition from gdm to the user’s session, because it also causes a crossfade to happen from gdm’s background to the user’s background during login.

Another big piece to the puzzle was kernel modesetting. This is what makes sure the right mode is set at boot up from the start. Jesse Barnes and krh did most of the work for that in the Intel driver (based on top of the memory manager work anholt, keithp, and other Intel crew did), while airlied did it for the ati driver, and darktama did it for nouveau.

This all works pretty well these days, but one big wrinkle in the whole process is the hand off from plymouth to gdm. Plymouth exits, leaving the system in KD_GRAPHICS mode and hopes that X starts and picks up the peices. This is not a very robust design, because if X doesn’t start, the system will be stuck in KD_GRAPHICS mode and the user won’t be able to switch VTs or really do anything at all, but reboot.

Furthermore, when plymouth exits, the kernel sets the scan out buffer to the frame buffer of the console. This is because the previous scan out buffer was owned by plymouth and goes away when plymouth exits. That means in order to keep things seemless we need to copy the last frame of the animation from plymouth’s framebuffer to the console frame buffer. This extra copy is unfortunate, because it means the kernel console has to be configured the same way as plymouth, but in multihead set ups it’s not. The kernel console “clones” the ttys across all heads, forcing every head to be the same resolution. But plymouth (and X) want every head to run in native resolution. This means in multihead setups we can’t do the copy because the pixel layouts aren’t the same, so we end up filling with black instead.

I’ve wanted to improve this situation for a while, but haven’t really been able to prioritize it above other various bits of work that need to be done. Since I’m on Thanksgiving break I can, in good conscience, ignore my priority list and just work on what I want, so I decided to work on this problem a bit :-)

I just merged the “no-fbcon” branch to plymouth master. It adds a new way to “deactivate” plymouth such that it’s still on screen and idly running, but X can start and take over anyway. This combined with some gdm changes to tell plymouth to go away in the appropriate way after X is started or fails to start means we solve the robustness issues and avoid the extra fbcon copy.

It actually only took a few hours to do. I probably should have made time for it before break.

Fedora 12

November 17, 2009

So Fedora 12 is finally out. Give it a try.

It shaped up to be a pretty good release I think.

So I’m at the Boston Summit this weekend. Mo showed off her portable usability lab. She posted about the lab before here. Jason Clinton posted a summary of the summit session here

The DVR hardware in the setup ouputs four avi files–one for each camera. The first file has the audio encoded in it. Having four files is cumbersome, though. It’s much better to see the camera focused on the users face at the same time as video focused on the users hands, and at the same time as the view that shows the users screen.

That’s where gstreamer comes in. It’s possible to write a pipeline that can take the 4 videos and compose them together into one 4-way split screen.

In Mo’s post she showed an earlier pipeline I came up with, but it was very slow and lacked audio.

I’ve been reading up on gstreamer, searching the internets for example pipelines, etc, and now have a better pipeline. Someone here at the summit asked for me to check it into git, so I did that today in the usability-lab module.