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!
Fedora 10
November 25, 2008
So, just a quick note to say Fedora 10 is out.
If you haven’t tried Fedora in a while, and you’re curious give the live image a try on a USB stick.
those dialogs
October 10, 2007
So there has been a lot of discussion recently about the key import dialog in PackageKit recently. We were talking about it on the bus on the way to work this morning, in fact. Here’s my thoughts (and some thoughts I didn’t come up with, but came from the bus discussion):
- Showing the fingerprint in the dialog is only useful if the fingerprint is somewhere else the user knows to look
- You obviously can’t put where to look in the key itself, because the key isn’t trusted until the fingerprint is verified
- Since you can’t put it in the key, discoverability is a hard problem. We pretty much have to hope that the key is in plain view on the website that offers the package / repo.
- “trust” is a bit of a stretch in any case, because often users will google around for software and install whatever they find. It’s really more “verify the software comes from the website that originally pointed to the package / repo file.”
- Only users who really understand the security implications of the dialog are going to verify that the key fingerprints match
- Given that most people who see the dialog aren’t going to verify that the key fingerprints match, the dialog isn’t useful for security (it only solves the identification problem for a small subset of users)
- One way to make the dialog more secure would be to treat the fingerprint like a CD key / activation number that the user has to enter instead of something that gets shown to the user. If entering the key was a required step for configuring a system to use a repository, then websites that offer repositories would have to include the fingerprint with the repo in plain view for the repo to be useful, and users couldn’t just click past the dialog without reading it.
- Some might argue that users are accustomed to entering these types of numbers already when installing software. There’s precedent anyway.
- Having to enter long strings of numbers sucks (just as much as having to read long strings of numbers sucks)
- Either way, there’s a very real aesthetic problem with this type of dialog, and it’s not clear there’s an easy way to fix that
- One thing that can help is have the distribution know about a select number of 3rd party repos/keys out of the box, so then the dialog can hide the key fingerprint entirely.
- Figuring out which keys to ship within a distribution is an interesting problem itself, but maybe it should have some parallels to the processes that the distribution uses for adding packages?
PulseAudio
August 24, 2007
So I was playing around with PulseAudio which will be the default in Fedora 8 and it’s definitely cool.
I played a movie in totem (actually the Truth Happens video) and the sound went out my speakers. I then plugged in a USB sound card with headphones hooked up into it and ran the pulse audio control capplet-thing. It has a page that says “Active Streams” on it or some such and on that page was a list that had Totem. I right clicked on the Totem item, and a context menu popped up that showed my laptop sound device, and the usb sound device. I picked the usb one and sound immediately and seamlessly changed to the headphones.
That was pretty neat and played around for a few minutes just switching it back and forth between devices, then I found out something really cool. The music was playing through the headphones, then I unplugged the usb sound card, and PulseAudio noticed the device went away and transparently switched the movie sound back to my laptop speakers!
I guess it does the right thing when you have multiple users logged in at once too. The active user always get a sound device and any audio getting played by inactive users goes to /dev/null.
Anyway, bottom line is, Lennart rocks.
Experimental LiveCD
August 18, 2007
So the desktop team here at Red Hat has decided we want a little more freedom in trying new ideas for Fedora. We can’t put radical changes into the main Fedora spin, because those types of changes often require make choices for the user that may alienate someone who currently uses Fedora.
Since Fedora 7, users of Fedora have had the ability to do custom spins pretty easily. Using that same infrastructure we (the desktop team) are going to do our own spin that tries various things, like disabling the root account, and not asking the user what partitioning scheme they want. Presumably, some of these ideas won’t work out, but it’s nice to have a play area where we can experiment and find the things the really work.
The key here is that we’re try to narrow the scope of the spin. It will specifically be ill-suited for a lot of users who happily use Fedora. Those users can keep using the mainline spin, though.
Aside from that we started a Desktop “Special Interest Group” (SIG) so that people outside of Red Hat can get more involved. We now hold weekly meetings on IRC.
Anyway, discussion about what should happen on the LiveCD happens on fedora-desktop-list
Login Records
June 29, 2007
So one of the the features I needed to implement for RHEL 5 was btmp logging for GDM. The btmp log is a record of failed log attempts that an admin can access by running the /usr/bin/lastb command. It’s similiar to the wtmp log which is a record of login and logouts by users, and also like the utmp log which is a record of users currently logged in.
GDM already had indirect support for those last two types of login records because when starting a session it would invoke the sessreg utility that ships with X. This utility would create an entry in the wtmp and utmp logs. This utility couldn’t create an entry in the btmp log, however, because it only gets invoked after a session is started, and the btmp log records failed login attempts–attempt that don’t lead to a session getting started.
The format of the 3 logs are nearly identical, so it made sense to do all the logging with in GDM. For RHEL 5, I pushed a patch that did wtmp and btmp logging, but neglected to do utmp logging. The reason for this was a bit of text in the utmp man page
xdm(8) should not create a utmp record, because there is no assigned terminal. Letting it create one will result in errors, such as ’finger: cannot stat /dev/machine.dom’. It should create wtmp entries, though, just like ftpd(8) does.
This turned out to be a mistake. People like to be able to see who is currently logged in by using the w command, which relies on utmp being up to date. I’ll be correcting that in a future RHEL 5 update.
Anyway, I submitted my patch upstream and Brian Cameron picked up the work and made it work in Solaris. This broke it in Linux, so he passed it back to me to fix for Linux.
There is still one issue left. utmp entries have a specific field per record called the ut_line field. For text logins you would put the name of the terminal device that is controlling the session. So if the user is logged in on vt 1, then the associated terminal device is /dev/tty1 and the ut_line field would be tty1.
For X logins, there is no controlling terminal, so there is some debate what should go in the ut_line field. Note, the warning I quoted above. Some utilities expect there to be a file in /dev with whatever value is given to ut_line. According to Brian, Solaris has traditionally dealt with this problem by creating fake files in /dev for each X login, just so programs like finger and w don’t freak out. These fake files are called “pseudo devices” and they’re sort of akin to pseudo-terminals, except they aren’t terminal devices.
Anyway, it’s not clear what we should do for ut_line. The whole idea of creating fake files just to satisfy some old unix utilities is sort of offensive, and it has SELinux implications as well. For RHEL 4, ut_line was not set to a valid file. It was simply the display number (:0 or whatever), so I’m thinking that’s probably the right way to go.
detached directories
June 18, 2007
So one thing I wanted for my Graphical Boot stuff was a standalone environment for it to work in. I wanted it to have its own /proc, device nodes, etc, because it gets run so early in the boot process that those things aren’t set up yet globally. If I make my program set them up globally, then other parts of the boot process get confused that things are set up already. What I really want is my own private directory that only my process can see and that goes away when my process exits.
This is something you can do with individual files pretty easily. Something like:
int fd;
char file[] ="/tmp/XXXXXX";
fd = mkstemp (file);
unlink (file);
It turns out you can do something similar with directories, too, although there are some caveats. If your program
- creates a temp directory
- mounts a ram filesystem in the directory
- opens the directory and stores the file descriptor somewhere
- lazily unmounts the ram filesystem
- remove the temp directory
Then the directory will no longer be visible from the filesystem, but will exist as long as the stored file descriptor is opened. The program can fchdir() to the directory using the saved file descriptor and work with it. Now some of the caveats are:
- the program needs to be root to mount the filesystem
- MNT_DETACH (the mount flag used to lazily unmount a filesystem) is unsupported api
- you can’t mount other filesystems in your detached directory
Overall, it’s kind of a neat concept, but those caveats make it fairly impractical to use.
Graphical Boot up!
June 9, 2007
So gnome blogs now has a nice wordpress setup thanks to Jeff Waugh, so I thought I’d take the opportunity to maybe start blogging. I don’t know if I’ll keep it going–all my past attempts have failed pretty miserably.
Anyway, at work right now I’m working on trying to lay some of the ground work toward getting a prettier boot sequence for Fedora. We have a wiki page that covers an overview-y superset of what I’m currently working on.
Specifically, my goals right now are to
- get a graphical splash screen up quickly
- have it do something interesting for the entire boot sequence
- not show any text during bootup
- have all the text we show during bootup now, available in a file after bootup
- have a way for users to turn off graphical boot up easily
A lot of this work is motivated by previous work by Kristian Høgsberg
What we currently have in Fedora is RHGB. It’s a small program that gets started as soon as /usr is available during bootup. The program starts an X server, throws up a progress bar that updates as boot progresses and has a detailed view that shows a terminal window with all the mesages in the middle of the screen.
RHGB has a number of disadvantages:
- boot up stalls (for as much as 10 seconds or more!) until the X server is started
- it’s X server is different than the X server GDM uses
- this causes flicker from all the VT switching and mode changes when going from text mode to X to rhgb to text mode to X to gdm
- this triggers X driver bugs that have issues starting multiple X servers simultaneously or in quick succession
- the details mode is ugly
- boot messages aren’t logged
What I’m working on now has a subtle (although still somewhat unpolished) animation that fades the fedora logo in and out against a dark blue background. Rather than having a traditional progress bar or spinner, I randomly add a new twinkling star somewhere on the screen whenever there is boot progress. It’s just a off the wall idea I’m using for test purposes right now. The framework for displaying the animation is intended to be somewhat flexible, so that the animation is simple to write and can be changed out easily (somewhat analogous to a screensaver, I guess).
Boot progress is reported using the same interface that RHGB takes advantage of now. The init scripts manually call rhgb-client –update whenever something interesting happens and rhgb-client –quit when its time for the splash screen to go away. It may make sense to do something different on this front in the future, not sure.
Boot messages are trapped by creating a pseudo-terminal early on and redirecting the console to the pseudo-terminal. This happens before anything else is run (even /bin/init!), in the very top of the initial ramdisk. Changing the initrd over to use the interface is as easy as changing the shebang line at the top of /init from
#!/bin/nash
to
#!/bin/plymouth /bin/nash
and installing the binary and support libraries in the ram disk image. /bin/plymouth sets up the psuedoterminal and passes off to /bin/nash transparently.
The messages sent to the pseudo-terminal are buffered until the filesystem is fully mounted and then the buffer is dumped to /var/log/bootmessages.log
For development purposes I’m using the standard vesa framebuffer implementation that’s sitting in the kernel, but we probably won’t ever ship anything that uses that. It’s just not a reliable enough solution and it doesn’t really play well with X (which is important if we want to get nice transitions between booting to sitting at the login screen). Right now there are efforts by Jesse Barnes and a few other people underway to get a a reliable drm modesetting interface set up for intel video hardware. It’s likely that we’ll punt shipping anything until that stuff lands upstream.
Anyway, you can follow my progress at a git repository I set up here:
http://people.freedesktop.org/~halfline/plymouth/