Plymouth Multi-head support

September 29, 2009

So it’s been a while since I’ve blogged.

This is just a short blog post to say that I landed multi-head support on plymouth master yesterday.  More details here:

http://lists.freedesktop.org/archives/plymouth/2009-September/000188.html

What this means is the boot splash redraws itself once per monitor,  in a way that looks good for the native resolution each monitor.  Previously, we’d draw right on the fb console, which is cloned across all monitors.  That made the splash have large black margins on some monitors, or look stretched.

One implication of this change is we now use libdrm directly when possible instead of going through the /dev/fb interface.

We still don’t do any accelerated rendering.  We don’t really need it, since plymouth splashes are normally designed to be very simple (Think “cell phone splash” not “3D video grame”).

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.

Linux is not about choice

January 9, 2008

So I came across a really interesting mailing list post by ajax today. He’s totally right and it’s refreshing to see…

an unexpected turn of events

December 21, 2007

So, I am totally surprised to see that Matthew Szulik is stepping down as Red Hat’s CEO.  I wonder what comes next…

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?

Congrats Dave

September 30, 2007

So I just wanted to publically say congratulations to my friend, Dave Malcolm (of Conglomerate, Evolution, and Dogtail fame), since he’s going to be marrying a great woman soon.

Congrats Dave!

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

subway entertainment

August 2, 2007

So there is a really cheap/yummy falafel place in Central Square I sometimes like to go to. Today I walked out of there with Falafel roll up and made my way down into the T to get home to Davis Square. The train went want stop to Harvard when a guy comes on and starts screaming:

guy: Attention everybody, attention everybody I’m about to dance
guy puts down boom box
guy: now I have three rules first. 1) If I do something you like, clap 2) If I do something you don’t like, clap 3) when I’m done, show your appreciation with donations or love. Hint: ladies, I’m single.
guy taps boom box to get it started
guy then does a series of back flips, double flips, hand springs and break dancing

It was pretty damn cool to see.

So one common programming idiom you’ll find a lot if you sniff around code in random projects is a helper function that reads or writes in a loop. Something almost, but not completely unlike…


bool write_it_harder (int fd, void *buf, size_t size_of_buf)
{
while (there are still bytes to write) {
the_number_of_bytes_written = write (fd, buf, the_number_of_bytes_left_to_write);
/* check for errors then figure out the_number_of_bytes_left_to_write */
}
return true;
}

THIS IS WRONG. It’s not a good idea to do in a gui program. It means that your app will

1) block until all the bytes are written (which could be a while, if the thing getting written to is slow)
2) will completely fall over on some devices

It’s really better (although harder to code) to treat read()/write() as one-shot operations. You do them once, get a result, and then should go back to poll() and wait for it to report that the fd you are working with is readable or writable again.

Another common one is:


again:
bytes_read = read (fd, buf, sizeof (buf));

if (bytes_read < 0 && errno == EAGAIN)
goto again;

Again, THIS IS WRONG.

1) you may get into a situation where read() will return EAGAIN over and over again in a tight, battery killing, cpu heating loop
2) there is no guarantee that you’ll get EAGAIN on successive calls anyway. pseudo-terminals for instance, will give you EAGAIN once, and then EIO for successive calls.

So, only every call read() or write() when poll() says its okay to call them, and realize that if poll() says its okay to call them, it’s only saying it’s okay to call them ONCE, and you need to ask poll() permission to call them again.

update
I’ve put a sample program up here to show what I mean.