November 20, 2009


Máirín Duffy
Want to learn design skills? Want to help Fedora? Fedora Interaction Design Hackfest, Tuesday 24 Nov

Hopefully my post title has captured your attention. :) I would like to let you know about a project starting up right now that is a great opportunity for you to:

  1. Learn about how interaction design is done.
  2. Pick up some interaction design and user research skills.
  3. Get involved in an open design project.
  4. Help make Fedora better!

So the Fedora Board has started an initiative to create Fedora user profiles and personas to help inform decisions about Fedora policy and design in the future.

Okay Mo, so first of all, what is a persona?

From Wikipedia:

Personas are fictional characters created to represent the different user types within a targeted demographic that might use a site or product. Personas are useful in considering the goals, desires, and limitations of the users in order to help to guide decisions about a product, such as features, interactions, and visual design. Personas are most often used as part of a user-centered design process for designing software and are also considered a part of interaction design (IxD), have been used in industrial design and more recently for online marketing purposes.

A lot of discussion about personas is available on Cooper’s blog and is a good read for getting up to speed on what they are and how they work.

Okay, uh, so how are personas going to help us make Fedora policy and design decisions?

Well, for example, you may recall the great panda panda-monium from early www.fedoraproject.org redesign mockups, in which about half of folks giving feedback loved the panda (“Please kill to keep that damn Panda, mairin. The thing is too cute and seems to look like a great little mascot.”), and the other half felt the panda was an insult to Fedora users (“In general i like the layouts…. for 6 year old kids. If this is the best you can come up with you might as well base it on this: http://ostiaunlobby.files.wordpress.com/2008/07/teletubbies-group2.jpg”)

WHY DONT YOU LOVE ME???

Of course, everyone is entitled to their own opinion of the pandas. Those opinons may or may not have any bearing on how our target users might receive them, though. If we have a set of Fedora personas defined, we can talk about how each of the personas, designed to be representative of our target audience would feel about pandas. Discussing whether or not the Fedora panda is a good choice for our *target audience* or not will help us make decisions based on the target audience we’ve agreed upon for Fedora rather than base it on knee-jerk / personal / anecdotal reactions that merely represent the personal opinons of the folks who happened to be around at the time to give their feedback.

There’s more discussion of potential benefits of personas to Fedora in a post I made yesterday to the ‘User Profiles’ thread on fedora-advisory-board list, so please check it out for more info and please feel free to dive into the discussion with any questions / commentary / feedback you have.

Well Mo, this sounds good. But where do we get personas from?

We’ll build them. Well, I think there’s a lot of different methods to going about constructing personas, but to be good they need to be backed by user research data. User research data can take many forms.

The approach I’d like to propose for Fedora persona development is based on the user research process advocated for in Observing the User Experience: A Practitioner’s Guide to User Research by Mike Kuniavsky. A high-level / action-oriented summary of the approach is as follows:

  1. Define the product and product goals. Done.
  2. Decide on an audience to target with the product that will help meet the product goals. Done.
  3. Conduct interviews of product stakeholders in order to determine high-level research questions to consider exploring with members of the target audience. Proposal for doing this.
  4. Draw up a list of specific research questions to answer to start conducting user research on the intended target audience. These are specific rather than high-level questions. For example:
    • “Does the target audience care about software freedom or not?” could be a Fedora Board stakeholder high-level research question.
    • Specific questions that could be explored during research, “Does that target audience know what free software is?” “Does the target audience already use free software? If so, which software?”
  5. Prioritize the specific research questions, pick a cut-off point for how many to explore, and determine research methods for each.
  6. Draw up a research schedule and assign specific research tasks to volunteers.
  7. Do the research! And check in with volunteers to make sure they’ve not run into any issues and help them resolve them.
  8. Hold a data analysis session. Cluster the data from the research into 3-8 groupings from which to build the personas on.
  9. Brainstorm and document the personas!

So…. How can I help?

SO GLAD YOU ASKED!!!! :) I am blocking out Tuesday, November 24th to be an interaction design hackfest. I want to run it from 3 pm – 6 pm EDT (8 PM – 11 PM UTC) on #fedora-design on irc.freenode.net. I’d like us to start working on work item #3, conducting interviews of product stakeholders, in order to get moving on the persona-building process. Depending on how far we get we may be able to dip into #4 and #5.

What concrete actions will helping involve?

  • Interviewing Fedora stakeholders via email or IRC in order to answer the stakeholder interview questions.
  • Documenting the Fedora stakeholder interviews by organizing the interview results on a Fedora wiki page.
  • Reviewing the interview answers and brainstorming potential research questions.
  • Per research question, brainstorming ways we can gather data to help answer the question. (Could we answer that question by running a questionnaire on Planet Fedora? Could we answer it by running some usability tests at FUDcon Toronto next month? Could we answer it by looking at fedoraproject.org website logs?)

You do not have to be an artist to help with design! So show up next Tuesday and find out how you can help. :)

  • Date: Tuesday 24 November 2009
  • Time: 3-6 PM EDT; 8-11 PM UTC
  • Place: #fedora-design on irc.freenode.net
  • Host: mizmo (me!)
  • Agenda: Fedora User Research Plan

p.s. for the panda-haters, how about this mascot:
MEET YOUR NEW GOD

Posted in Uncategorized
November 20, 2009 08:18 PM

Matthew Garrett
Why SHMConfig is off by default
Bastien mentioned the Chromium OS xorg.conf file, which includes an irritating wart - namely, Option "SHMConfig" "on". This tells the Synaptics touchpad driver to export its configuration data to a shared memory region which is accessible to any user on the system. The reason for this is that in the past, there was no good way for configuration information to be passed to input drivers through the X server at runtime. This got fixed with the advent of X input properties, and synaptics can now be configured sensibly over the X protocol.

But why was it off by default? Because, as I said, the configuration data is exported to a shared memory region which is accessible to any user on the system. And while it contains a bunch of information that's not terribly interesting (an attacker being able to disable my touchpad or turn on two finger emulation may be a DoS of sorts, but...), it also contains some values that are used to scale the input coordinates. Which means that anyone with access to the SHM region can effectively take control of your mouse. The current position is exported too, so they can also track all of your mouse input.

Now, this isn't stunningly bad. The attacker can only do this while you're touching the pad. You'll see everything that happens as a result. There's no way to fake keyboard input. They need to be running code as another user on the system - if they're running as the logged in user then they can already do all of this. And for a device as single-user as Google seem to be looking at, it's obviously not a concern at all.

But there's still plenty of places on the web suggesting that you enable SHMConfig, and various distributions that ship with it turned on (Ubuntu on the Dell mini used to, but got turned off after I contacted them about it). It's absolutely fine to do this as long as you're aware of the security implications of it, but otherwise please use X input properties instead.
November 20, 2009 04:56 PM

Bastien Nocera
Sticky tape
Google might know how to write a web browser, but writing an OS certainly isn't their forte.

You might have seen Matthew's mention of the acpid hacks, some of the other sources are just as funny to read.

November 20, 2009 12:03 PM

Richard Hughes
The Fedora 12 Installing Saga

And so, long story short, we decided to revert the change for F12.

Part of being an open source maintainer (and also my job at Red Hat) is to ignore trolls, but some of the messages I was getting yesterday were just personal attacks and abuse. That’s not cricket at all.

November 20, 2009 10:01 AM

Chris Blizzard
the next firefox business model

If you want to use our plugin APIs you have to sign an agreement that says anytime a user crashes because of your software, you pay us a nickel.  We wouldn’t have funding problems for a while, but boy would Adobe’s shareholders be pissed.

November 20, 2009 05:02 AM

November 19, 2009


Dan Williams
Few Surprised at New Evidence of Staging Driver Suckage

wdyt_photo3.articleThomas Johnson (High School Janitor)

“Oh yeah, I’ve seen that code.  It’s worse than what I clean up in the bathrooms after Prom or Homecoming.  The kids get high and drunk and party too hard and puke all over the place.  I deal with enough vomit from 7:30 to 6; I wouldn’t touch the staging drivers with a mop twice as long as the one I have at work.”

Just Say No

Thomas just found out that none of the “staging” wifi drivers will work with hidden access points because they don’t set the IW_SCAN_CAPA_ESSID capability bit.  Furthermore, the most popular “staging” drivers (for the Ralink hardware used in many netbooks) don’t even have specific SSID scanning capability at all.

Why do you care?  Hidden APs don’t broadcast their network ID, which misinformed people think is more secure (hint: it’s not).  Before a driver can associate to the network, it needs to discover available APs and capabilities, which requires a probe-request, which exposes the network ID to everyone anyway.  But that requires driver support which none of the staging drivers have.

I fixed this issue upstream two years ago by adding IW_SCAN_CAPA_ESSID to Wireless Extensions.  Of course the staging WiFi drivers that many distros enable never got fixed because the vendor it came from didn’t bother to work with the community in the first place.  And people wonder why they don’t work.

Broadly speaking, staging WiFi drivers come in two flavors: (a) old dried gum from under the cafeteria table (drivers with a future), and (b) fresh vomit from the hung-over kid in your math class (those without a future).

The drivers with a future (winbond, rtl81xx) are or will based on the kernel-standard mac80211 wireless stack, which implements the 802.11 WiFi specification in the kernel.  Since they use the standard mac80211 stack, they get all these nice features like probe-scanning and the correct capability bits for free.  All you have to do is work on supporting the hardware itself.

The drivers without a future (rt2860, rt2870, rt3070, rt3090, wlan-ng, vt665x) are based on forks of the ancient ieee80211 stack that Intel’s ipw2×00 drivers forked from the hostap driver.  Each of these drivers includes their own copy of the core ieee80211 stack forked at different times and with different hacks.  When a bug shows up, that means 4x the work, and 4x the chance for the fix to slip through the cracks.  Which is why these drivers have no future.  They are a maintenance nightmare.  Besides, they have crap like this:

pAdapter->StaCfg.bScanReqIsFromWebUI = TRUE;

It just blows my mind why people think staging wifi drivers are a great idea.  There’s a reason staging drivers set the TAINT_CRAP flag in your kernel; because that’s what they literally are.

So what’s the right thing to do?

There’s one huge reason why dead-end staging drivers are a bad idea: there aren’t enough developers.  So do you spend that effort  on maintaining unmaintainable shit code?  Or do you spend it on fixing the code that has a future?  Most of the time you can’t do both.

If you choose to maintain the staging drivers, then things become worse over time since the staging code is simply less tested and less maintainable.   So you continue to drop hacks and fixes onto an ever-growing steaming pile of manure.  Nobody cares much about the driver (because it doesn’t use the standard kernel interfaces and thus doesn’t have a future), so your staging driver never benefits from all the great feature work and bug fixing that the mac80211 and wireless developers are doing.

But if you choose to help fix the upstream drivers that do use mac80211 (like rt2×00), and thus have a future, maybe for a few months some users won’t have great wireless.  But they didn’t before either.  But then 6 months later, all the users get great wireless with features like power saving, background scanning, WiFi Direct, Bluetooth 3, access-point mode, etc.  Those things will never be done to the staging drivers, because those drivers are a dead-end maintenance nightmare, because their code is awful, and because they don’t use the standard kernel wireless stack.

I know I’d invest the effort where it helps users the most, even if it means a few more months of subpar driver support while the official upstream drivers get fixed and the staging drivers go untouched.  That’s how things actually get better when you can’t fix everything at once.

November 19, 2009 11:30 PM

Matthew Garrett
Sigh.
If only eeepc-laptop sent standard keycodes, or something.

Oh, wait.

Writing a Linux distribution is hard. There's a huge range of interconnected dependencies. It takes a long time to learn how everything fits together, and fixing things properly rather than adding device-specific hacks often requires rewriting a lot of code. I'm sure Google will figure it out in time[1], and I'm also sure that the majority of their work is going into their UI rather than the underlying infrastructure. But even so, don't expect that you'll be able install Chromium OS on a random piece of hardware and have it work as well as, say, Fedora in the near future.

[1] Based on that script, I'd say they're about equal to Xandros at the moment
November 19, 2009 08:32 PM

Bastien Nocera
Fedora 12, and beyond
Fedora 12

Fedora 12 got released yesterday, with plenty of nice new features.

My hand in that was the running bluetoothd on-demand, work on gnome-volume-control and its profile switching (meaning dead-easy 5.1 support), enhancements in the GNOME Bluetooth UI (which you probably already saw if you use Fedora 11), the PAN support in NetworkManager.

The stuff I really like is:
- the Bluetooth PAN support, so I can install the non-free wireless drivers on my laptop (which lacks Ethernet)
- the new notification theme
- the awesome work on KMS, and performance enhancements, which means I now use a GL compositing manager on all my machines
- the out-of-the-box mounting of my iPod Touch, though music syncing is still some way away.

You might want to read Matthias' interview for the Fedora 12 release.

Fedora 13

More recently work has started on Fedora 13.

nautilus-sendto got its own plugin API now, so you can extend it whilst keeping the code closer to your application or library. Empathy in GNOME 2.30 will take advantage of that. Pascal Terjan worked on the Pidgin plugin to make it use the Pidgin D-Bus interface, which means we don't need a Pidgin plugin to talk to nautilus-sendto anymore. Both changes are in Fedora 12 and Fedora 13.

Totem finally got some of my time, and a number of bug fixes have gone into the GNOME 2.28 and unstable branches. In master, we now have a nice OSD, disk-buffering of streams, reverse frame-stepping, and RTSP/HTTP authentication. Much thanks to the GStreamer guys, and Wim in particular, for making those last 3 items possible in Totem.

There's a few more items I'm still working on that'll sure please the crowds :)
November 19, 2009 01:52 PM

Behdad Esfahbod
Pango vs HarfBuzz
Since the rewritten HarfBuzz is shaping up fast and getting lots of Buzz these days, I get asked the same question again and again: "Will HarfBuzz replace Pango?" This post tries to answer that.


Short answer: No, not at all! Pango is here to stay. It will change, but only get better.


Long answer:

Pango provides two levels of API: A low-level and a high-level.

Low level API: What I can the "three pillars of pango":
  • pango_itemize(): Breaks text into runs that each have the same font, Unicode script, language, direction, and other characteristics.
  • pango_shape(): Shapes a single run of text, given the font, script, language, direction, and other properties. Shaping means converting Unicode text to positioned glyphs.
  • pango_break(): Does line breaking and other text segmentation (cursor positions, cluster boundaries, word boundaries, and sentence boundaries).

High-level API: Pango's high-level API consists of the PangoLayout object, aka "here's a piece of text render it in this box I don't care what you do."

Of these, HarfBuzz only does shaping. That is, hb_shape() is functionally equivalent to pango_shape().


API implications: Here is how moving to HarfBuzz affects the Pango API:
  • Everything in pango-ot.h will be deprecated and be a thin wrapper around hb-ot.h. This is already done in the harfbuzz-ng-external branch of Pango.
  • There will be new API in Pango, perhaps in pango-hb.h to help extracting various HarfBuzz structures from their Pango equivalents.
  • pango_shape() will be a thin wrapper around hb_shape() (read below).

Pango Modules: pango_shape() calls into Pango shaper modules to get the actual shaping done. There are two kinds Pango shaper modules depending on what they do (the API is the same, so Pango doesn't differentiate between the two classes):
  • Bridge modules: The basic-win32.c, basic-atsui.c modules call into another, platform native, shaping system to get the work done. The external (not integrated in Pango yet) modules basic-graphite.c and basic-m17n.c also do the same for the SIL Graphite and m17n shaping libraries.
  • On Linux, since there currently is no native shaping engine, Pango has multiple shaping modules, one per script, to do the actual shaping (arabic-fc, syriac-fc, indic-fc, thai-fc, ..., and basic-fc for all the non-complex scripts).
Now, as HarfBuzz becomes the shaping engine on Linux, all those script-specific modules will be removed and basic-fc will simply call into hb_shape(). That's indeed what the basic-fc.c in the harfbuzz-ng-external does.

Later on, when we add support for native win32, CoreText, Graphite, and m17n to HarfBuzz, all those other modules will also be replaced by HarfBuzz-calling equivalents.

Which one to use: Pango or HarfBuzz? Depends.

PangoLayout is designed to be the 'render this text in this box I don't care how' kind of API. That's a perfect fit for GUI toolkits like GTK+, but not suitable for lots of other uses, for example:
  • Web browsers
  • Word processors
  • Designer tools
  • Font design tools
  • Terminal emulators
  • Batch document processors
  • TeX engines
while in many of those cases PangoLayout can be made to work (with much pain, mind you), Pango still provides the lower level API and lots of other bits and pieces to get something going. What it doesn't give full control on however is font selection, which happens to be a deal-breaker for many of those usecases (browsers following CSS rules, etc).

So, each of those kinds of applications need to assess the pros and cons of using Pango vs using HarBuzz and providing all the other bits themselves. For example, HarfBuzz doesn't provide:
  • An itemizer
  • A Unicode Bidirection Algorithm implementation
  • A Unicode Line Breaking implementation
  • Glyph rasterization
  • Glyph metrics information
  • etc
There's also a hybrid use possible: to borrow those pieces from Pango on platforms that it's feasable, but drive HarfBuzz directly. It all depends. When in doubt, ask! We have a mailing list.

That said, Firefox will use HarfBuzz as soon as it's ready (there are patches circulating around). Google is using old HarfBuzz for their Webkit and will port to the new one. I'm also attending the Webkit-GTK hackfest in December to port that to the new HarfBuzz. We'll work towards sharing the HarfBuzz-dealing code among Webkit backends.

This is already a long post. Let me finish now. Hope I made it a tiny bit more clear.
November 19, 2009 04:07 AM

November 18, 2009


Máirín Duffy
New Fedora Spins site with Fedora 12

With the release of Fedora 12 we’ve given the spins.fedoraproject.org a bit of a facelift. :) (What did it look like before? Pre-facelift spins.fedoraproject.org.)

I wanted to tell the tale of this redesign to show how we did it, together as a community, and also to give kudos to the many folks who pitched in and made it happen.

I’m sure I’m forgetting some items and deserved kudos (let me know and I’ll update this post) but I have to leave for my bus now so that’s all for now. I hope this gives you some insight into a community design & implementation process. :)

And check out spins.fedoraproject.org and let us know what you think! We’re of course always open to improvements – this is an open design process. :) Also note there is more work to be done – let me know if you’ve any interest in helping out :)

Posted in Uncategorized
November 18, 2009 11:00 PM

Andre Klapper
maemo.org Bugzilla: Minor tweaks
Statistics

Incoming reports in the last weeks

As I’m quite busy with the normal “Triaging and Syncing” business already (as seen above, a first increase of bug reports happened right after Maemo Summit in week 41, but I expect way busier times ahead) Karsten concentrates on technical stuff. It’s good to have him back as now stuff gets done that unfortunately was on the backburner.
First pay-offs (small, but definitely worth to mention, not only for the sake of transparency) that were done because I could “outsource” this to Karsten:

Screenshot

Entering a new report

Having users/customers reporting a bug in order to improve a product is great (always keep in mind that they do not need to spend the time on that). However the freetext input makes this sometimes complicated: A “Steps to reproduce: Connect to foo.” is vague when there are several ways offered by the <abbrev title="User Interface">UI</abbrev> to connect to foo and only one of these ways triggers the bug. Also, some testers (me, for example) love to simply follow braindead exact instructions without the need to think a lot. ;-)
Hence Bugzilla now asks reporters to use an ordered list to provide exact steps. Yes, it is helpful.
Also, when it comes to reproducibility of issues an answer like “Sometimes, but not too often” is always a bit vague and does not tell how often the reporter had tried (once? five times?). Now we ask for numbers like “maybe 3 out of 10 times”.

Screenshot

New “Moved to Brainstorm” answer

Closing valid enhancement requests as INVALID just because they are better suited for maemo.org Brainstorm always sounded a bit rude. We now have a MOVED resolution plus a nice one-click-button-and-done implemented.

And third, we have a link to the Bugsquad on the maemo.org Bugzilla frontpage now.

More news to come.

November 18, 2009 08:24 PM

Máirín Duffy
Unpackaged Open Font of the Week: Chunk

Chunk is a fun slab serif decorative font that is useful for headlines and other creative treaments. The font was created by Meredith Mandel – check out Meredith’s Chunk type specimen poster for an idea of the type of treatments this font can shine in.

So, you want to package Chunk?

Fantastic! You rock! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

Our fonts packaging policy, which the above refers to, is documented here:

And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

Last week’s font

Last week’s font was Comic Serif Pro by Hannes von Döhren. Nobody has picked up the font package request yet! Would you like to?

Posted in Unpackaged Font of the Week
November 18, 2009 01:50 PM

Caolán McNamara
DEV300_m65

With DEV300_m65 unused methods reduces to 886 as hwpfilter drops out of the list.

idling
Some other work ongoing on removing permanent timers which are constantly triggering when we should otherwise be idle. 3.2 will have the clipboard polling removed which makes the bare frame idle without wakeups, while patches for making math idle have been applied for 3.3. The spell checking loop in impress and draw never ends at the moment, patch available to fix that, as well as fix the graphic and ole cache manager loops to not run if unnecessary. I’ve no fixes for the more complicated writer and calc idle loops yet however.

strict aliasing
Good bit of progress on making OOo strict aliasing safe as well.

cppcheck
Played around with cppcheck as well, mostly discovered missing checks in various workbench tools and build-time tools, but a few good catches on stl iterators in main-line code, and very good on new[]/new vs delete/delete[]. A few false STL positives as well, but upstream is responsive to bug reports, so next version will give a better set.

November 18, 2009 08:45 AM

Jesse Keating
Another 6^H 5 months, another Fedora release
Fedora 12 released today, go get it. This is the 8th Fedora release I've had the pleasure of being paid to work on in a release engineering role. It has been a long and hard trip, but with lots of rewards along the way. Our community is stronger than ever, with more volunteer (both outside and inside Red Hat) people taking up leadership roles or driving features through or just helping out where help is needed.

12 is cool. 12 was really hard to get out too. 12 had a shorter development period than previous releases, because we lost a month due to an infrastructure incident during the Fedora 10 cycle. We decided to give Fedora 11 a full 6 months as we had a lot of really cool features lining up for it and we were going to do a shorter 12 cycle to polish things up. Turns out we had people doing lots of polish, but other people doing lots of features too, even in a compressed timeline. I'm deeply impressed with the amount of work that can get done, often in spite of the challenges faced by a Fedora developer/maintainer. I can't wait to see what kind of productivity we see as some of these challenges are addressed in the Fedora 13 cycle. Some big changes are coming, tune in to the upcoming FUDCon where there will be multiple talks and hack sessions regarding these challenges our developers, maintainers, testers, and users face.

A few interesting data points for Fedora 12:
- First release in a looong time (ever since I've been doing it perhaps?) that we didn't have to slip the final release date once we got past Beta.
- First release probably ever where the x86_64 DVD is seeing more torrent downloads than the i386 DVD
- Smoothest release day EVER. Seriously. The infrastructure folks really have this down and there were 0 issues.

One more thing that seriously impresses me about Fedora 12 is the launch of our spins site. This is a fabulous new site to really help showcase the different looks that Fedora as a project can offer, finally bringing to fruition something we had been talking about for many releases/years now. There is more website (re)design coming, and I am very excited about it.

Go on, give Fedora 12 a try. A Live image gives you folks with commitment issues something to try without risk, and the install DVD/CDs (and network install iso) gives you fine tuners the ability to hand select the software you get from our vast repository. I promise you we'll do the best we can to ensure a fun, safe, and free ride.
November 18, 2009 04:35 AM

November 17, 2009


Máirín Duffy
IT’S HERE!!!!!!

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Posted in Uncategorized
November 17, 2009 04:01 PM

Ray Strode
Fedora 12

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

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

November 17, 2009 03:43 PM

November 15, 2009


Behdad Esfahbod
On Unexpected Hanging Paradox and applications in law enforcement
[Note: this post has nothing to do with the ongoing executions in Iran.]

Unexpected hanging paradox is a well-known alleged logical paradox about a prisoner's response to an unusual death sentence. To quote Wikipedia, here is the statement of the paradox:
A judge tells a condemned prisoner that he will be hanged at noon on one weekday in the following week but that the execution will be a surprise to the prisoner. He will not know the day of the hanging until the executioner knocks on his cell door at noon that day. Having reflected on his sentence, the prisoner draws the conclusion that he will escape from the hanging. His reasoning is in several parts. He begins by concluding that the "surprise hanging" can't be on a Friday, as if he hasn't been hanged by Thursday, there is only one day left - and so it won't be a surprise if he's hanged on a Friday. Since the judge's sentence stipulated that the hanging would be a surprise to him, he concludes it cannot occur on Friday. He then reasons that the surprise hanging cannot be on Thursday either, because Friday has already been eliminated and if he hasn't been hanged by Wednesday night, the hanging must occur on Thursday, making a Thursday hanging not a surprise either. By similar reasoning he concludes that the hanging can also not occur on Wednesday, Tuesday or Monday. Joyfully he retires to his cell confident that the hanging will not occur at all. The next week, the executioner knocks on the prisoner's door at noon on Wednesday — which, despite all the above, will still be an utter surprise to him. Everything the judge said has come true.

This has intrigued me again and again and I could never come to peace with it. While researching this recently I came across this paper which is a non-exhaustive survey of various tries to model the paradox. Great read.

Today I came across a blog post by Ed Felten called Targeted Copyright Enforcement: Deterring Many Users with a Few Lawsuits. While I find it very disturbing that a scientist like Ed Felten may be helping RIAA better screw people by their copyvio lawsuits, the puzzle and the solution provided are well worth a read. Not irrelevant to the Hanging Paradox, though in this case the reasoning may actually work.
November 15, 2009 10:16 PM

November 14, 2009


William Jon McCann
Mockturtlesuppe

Things have been rolling along in GNOME Shell land.  We’ve been experimenting and evolving the design as we go.

If you were reading this and this carefully you may have noticed links to a design document for the Shell.  I’ve just put out a long overdue update for that document.

Please read the GNOME Shell Design PDF and let us know what you think.  Higher resolution versions of some of the figures used in the document may be found here.  We’ll be adding these to the wiki soon.

Once you’ve read the document please grab the Inkscape SVG mockups and try to make them better.  I’m sure that you can.  My drawing skills are not exactly legendary.

Looking forward to hearing your thoughts and seeing your modifications.

As usual find us on IRC #gnome-shell on GimpNet or http://mail.gnome.org/mailman/listinfo/gnome-shell-list .

Make sure to try it out too.  It is really easy to use from jhbuild.  See http://live.gnome.org/GnomeShell#building

November 14, 2009 09:23 PM

Máirín Duffy
Gimp 2.7.0 x86_64 packages for Fedora 12

The lure of layer groups drove me to build F12 RPMs for Gimp 2.7.0 last night. However, I was not to get that new sparkly pink pony for my stable, as layer groups are not in 2.7.0. That being said, there’s still some interesting tweaks (one I noticed was brush filtering, another was a very nice cleanup of the save dialogs) so you may want to give these a shot to check up on Gimp’s progress.

Use ‘em at your own risk of course. I am no expert packager and in my desperate fervor for acquiring pink sparkle ponies, I resorted to some dirty tricks to make these build :)

http://duffy.fedorapeople.org/packages/f12/gimp-2.7.0/

THREE MORE DAYS!

Posted in Uncategorized
November 14, 2009 07:48 PM

November 13, 2009


Máirín Duffy
Fedora 12 One-Page Release Notes PDF

We’ve [1] been working on a set of one-page release notes for Fedora 12, and now that those are set I took some time today to put them into a single PDF file. However, there are 3 pages…! So, for your event, you might like to print out two sets of release notes: Page 1 + Page 2 for desktop users, and Page 1 + Page 3 for system administrators and developers. Then allow folks to pick up either or both depending on their interest. Or, you can simply print out all three as one packet. Whatever you like. :)

[1] According to Fedora’s wiki history, the following people contributed to the page: Paul Frields, Máirín Duffy, Mel Chua, Nicu Buculei, Steven Moix, Sakis Asamaras, Charley Wang. In addition to those folks, David Aquilina provided a photo, and Caius Chance volunteered to model for another photo. Eric Sparks and the Fedora Documentation team came up with the concept. Thanks everyone!

ZOMG I CAN’T STAND IT FOUR MORE DAYS!

Posted in Uncategorized
November 13, 2009 11:56 PM

Máirín Duffy
Friday fun with tablets!

Fedora 12 rocks on tablets, so Nicu, Kushal, and María decided to start a Friday fun tablet meme – draw a kindergarten style house. :)

Of course I couldn’t resist, so here is my house!

FOUR MORE DAYS!

Posted in Uncategorized
November 13, 2009 05:48 PM

Matthew Garrett
Legacy PC design misery
I've spent chunks of the last couple of days fighting a problem that's existed for about 25 years. The 8086 was a 16-bit processor with a 20-bit address space, limiting the maximum physical address that could be accessed to 1MB. However, quirks of the segmented memory system meant that addresses greater than 1MB could be constructed - these would wrap around to the bottom of memory. Because loading the segment registers was a time consuming operation, some programmers used this behaviour as a performance optimisation.

The 80286 introduced 24 bit address space. Unfortunately, this meant that the addresses that previously wrapped to the bottom of memory now pointed at real addresses - not ideal if you were expecting the old behaviour. IBM fixed this by tying the 21st address line (A20 - they're zero indexed) through an and gate, with the default behaviour being to keep it tied at 0 and thus maintaining the old wraparound behaviour. Applications that wanted to access the full address space needed to enable the A20 logic gate. IBM didn't want to add any extra hardware to their system if they could avoid it, so tied the other side of the and gate to a spare pin on the keyboard controller. By writing a couple of bytes to the keyboard controller, your PC-AT stopped pretending to be an XT and gave you access to all of the insanely expensive RAM it had stuffed in it. Hurray!

PCs have been emulating this behaviour since the AT was first cloned. Of course, this being the PC industry, many have got it wrong. There's a set of approaches for controlling the A20 gate that may work, varying in terms of performance and desirability. Most hardware will give the desired result (ie, I have no desire to run DOS executables from 1982, make my A20 work damnit) using any of the various methods of A20 enabling. Some hardware doesn't. The most common method used in bootloaders (where we still have access to system BIOS services) is to call int 15h with an ax of 0x2401, which asks the BIOS to enable A20 for us. This isn't implemented on all hardware, but we should get a failure back that lets us go and bang on the keyboard controller in an attempt to get it to pay attention[1].

Enter the Kohjinsha SC3.

I picked this up second hand in Japan. It's a ridiculously cute little tablet, only slightly larger than hardware that's comfortably in the MID range. It booted a Fedora liveCD perfectly, though having GMA500 graphics meant that what appeared wasn't terribly attractive. Installation proceeded happily enough, followed by a reboot and... nothing. Grub loaded the kernel and initrd, jumped to the kernel and everything hung.

So, for the past couple of days, I was stepping through the kernel setup code, trying to work out where and why it was hanging. I'd got it narrowed down to the region where the kernel tried to free the memory used by the initramfs, but the failure hopped around depending on my kernel build. Something was clearly very wrong. The strangest thing about this was that if I booted the liveCD boot menu and selected "Boot from local drive", everything worked perfectly. isolinux was clearly doing something that grub wasn't, but there's rather a lot of code to step through there.

Things became a lot easier once I found that the OpenSuse version of grub worked. Their grub has a rather smaller set of patches than ours, and only a few looked even plausibly relevant. It only took ten minutes or so to figure out that it was one that altered the A20 code. Things became much clearer then.

The main functional difference between the Suse A20 implementation and the upstream one[2] is that the Suse one explicitly tests whether the A20 enabling worked by putting values at two different addresses that would be the same if A20 is disabled. By comparing them, we know whether A20 is working properly or not. If not it can then fall back to other mechanisms. The Fedora code trusted the BIOS's claim that the int 15 call had worked. The Kohjinsha's BIOS lied, A20 remained disabled, grub copied the kernel and initramfs to chunks of address space that contained lies rather than RAM and everything fell over horribly.

Thankfully, not a difficult fix once the problem was identified. But seriously, people. How hard can it be not to screw this up?

(For an excrutiatingly detailed analysis of how hard it can be not to screw this up, see here)

[1] the Intel Macs don't implement the int 15 approach, but return a failure. They also don't have a legacy keyboard controller, so attempting to hit that resulted in grub falling over. The magic IO port approach works. Another example of how the Intel Macs aren't really PCs...

[2] grub2 implements the more paranoid check
November 13, 2009 02:32 PM

Chris "Monty" Montgomery
While Denton and George are Sleeping #9

Commencing final assembly!

November 13, 2009 02:31 AM

Lennart Poettering
On OOM

Building on what Havoc wrote two years ago about the fallacies of OOM safety (Out Of Memory) in user code I'd like to point you to this little mail I just posted to jack-devel which tries to give you the bigger picture. Should be interesting for non-audio folks, too.

Say NO to OOM safety!

November 13, 2009 01:25 AM

November 12, 2009


Máirín Duffy
Getting Ready for F12: Media Sleeves and Labels

Fedora 12 is not out yet, no. However, thanks in a big part to Luya being on the ball and getting started on the media artwork, and with his help, we have put together a full set of Fedora 12 media artwork. So now you can have a head start at getting your media all prepared and ready to burn next Tuesday! :)

All the media artwork has been created for the following Fedoras:

  • Fedora Desktop Live Media, 32-bit and 64-bit
  • Fedora KDE Live Media, 32-bit and 64-bit
  • Fedora Install DVD, 32-bit and 64-bit

We’ve got sleeves:

We’ve got labels:

I also put together a set of LightScribe labels. We could actually really use your help with these – I don’t have a LightScribe burner so I don’t have a way to test the design. If you’re planning to LightScribe burn F12 anyway and have the equipment to do so, would you mind giving one of the designs a try and letting us know if the label design works okay?

We also have made all of the templates used to create these designs available, so if you want to make a custom label (maybe you’ve a favorite spin you’d like to burn?) you’re free to do so. Wait a minute, you don’t own expensive Adobe software? Gee, you are silly – you don’t need that stuff! All these designs were made in Fedora! :) Check it out:

FIVE MORE DAYS!!!

Posted in Uncategorized
November 12, 2009 07:16 PM

Dave Airlie
what a difference having hardware makes....
So I (and other radeon developers) debug a lot of radeon problems, both locally and with people over irc/bugzilla, and I often am quite slow to deal with bugs that I can reproduce locally, its usually a last resort to do remote debugging and its unfortunate for people who have hw bugs that we can't reproduce locally.

So what prompted this post?
https://bugzilla.redhat.com/show_bug.cgi?id=527874
KMS:RV515:X1400 Thinkpad T60 resume fails

So first up, my local Thinkpad T60p with an rv530 always resumed fine, my local T42 with 7500 mostly works okay as well, so
there goes my local reproduction.

So Peng works for Red Hat in Beijing and the week before kernel summit I sat down on irc for most of two days with him running various tests. We tracked it down in that 2 days to the fact that his video RAM wasn't getting setup properly on resume. The NMI on resume let me track down that when the gpu accessed the ring, it generated an error on the PCI bus, this led to checking the contents of the PCIE gart table (with a detour through kernel vmap page handling). The PCIE gart table is in VRAM, and upon checking it on resume noticed when we copied it back into VRAM it was getting mangled. So we could deduce VRAM was broken.

I handed off to Jerome and he got traces of the BIOS posting using VBE and using ATOM (which we use in the kernel), Jerome ruled out different parts of the engines and we got reports of it working for some people when powered down for a long time or other randomness, and we were going back and forth with ideas on what might be going wrong, and had started thinking we should power off various parts of the hw before suspend, and the problem was due to inconsistent hw state on resume.

Peng happened to visit Brisbane for a Red Hat meeting this week and brought the T60, and this morning I swapped my laptop for his. First of all I tried to play by plugging in a VGA monitor, this produced another bug where the LVDS would die when starting KMS, so I fixed that quickly first. So the VGA screen was also corrupted, and VRAM wasn't enabled at all. Next I tested vbetool posting worked, also suspend/resume to corrupt, unload radeon, vbetool post and load radeon worked. Then I started testing with Jerome's userspace atom init tool, doing a s/r, unload radeon, atom post, load radeon also worked fine. This is where it started to make no sense, since Jeromes tool was doing the exact same thing as the kernel parser. I started by blaming the atom delay code in the kernel but that proved a dead end after an hour or two. Next thing I enabled the kernel atom debugging and all of a sudden it resumed fine. So it was a timing issue somewhere in atom parser running the init code.

So enabling debugging put enough of a delay between operations that something that wasn't working before now succeeds. I started bisecting the debug messages, I removed half the debugging at a time until after about 3 hrs I got it down to one printk happening between two atombios commands. The surrounding code was reading and writing one of the memory controller setup registers on the GPU, so it pointed to some register write not getting fully into the hw before we read it back and write it again later. I changed the atom code to do a read back before writing regs for certain operations and viola all resumed fine.

So this took the best part of 8 hours, I reckon if I'd been doing the same over irc with Peng it would have taken at least a month of back and forth on irc to figure it out. Having the hardware locally even for a day made it possible to track it down and figure it out so much quicker and efficently. So the bad news for anyone with bugs we can't reproduce locally is that we generally will fix any bugs we can locally first just from a efficiency point of view, since we can fix them so much quicker and faster.
November 12, 2009 10:00 AM

November 11, 2009


Bastien Nocera
A little OSD
Totem in master now has purdy OSD when you press a key, or a key on your remote control, and you're in fullscreen. Note that this requires compositing.

Screenshot streaming the Avatar HD trailer
November 11, 2009 04:58 PM

Peter Hutterer
evtest-capture and replaying events
Many of you are probably familiar with evtest, a small debugging utility written by Vojtek Pavlik to check what input device data is leaving the kernel. I use it a lot and one of the standard requests I make in bugreports is run evtest against the device file. The information it prints tells us the capabilities a device has and the events being sent when a certain action is performed.

I've used this information to add uinput device to my uinput test devices collection to debug various server and/or driver failures.
That worked for some cases but suffered from a major caveat: it was incredibly hard to reproduce issues that resulted from complex interactions. For months, I've been meaning to fix this and last weekend I finally had time to sit down and hack something up. That work is now in the evtest repository.

It works quite simple:
The user runs evtest-capture against the device and performs the action that reproduces the bug. evtest-capture saves the event stream into an xml file, this xml file can then be converted into a standalone uinput-based C program that resembles both the device and the interaction. I can re-create and run that program on my test box and reproduce and hopefully debug the issue.

The full set of steps is (as root where necessary):


$> evtest-capture /dev/input/event0 pointer-crashes.xml
$> xsltproc evtest-create-device.xsl pointer-crashes.xml > pointer-crash-device.c
$> gcc -o pointer-crash-device pointer-crash-device.c
$> ./pointer-crash-device
#verify the issue happens with this test device.


Like so many things, it's not perfect but it will hopefully help us reproduce a lot more bugs and thus make it simpler to find and address these bugs.
November 11, 2009 12:00 AM

November 10, 2009


Máirín Duffy
Unpackaged Font of the Week: Comic Serif Pro

Comic Serif Pro is another fun font – it’s a slab serif font useful for headlines and other creative treaments – including comic books. :)

I actually found out about the font from my ever-awesome fellow FOSS artist pal Ryan Lerch, who showed me a comic mockup he’d made using it. I contacted the creator, Hannes von Döhren, who very graciously not only agreed to relicense the font under Creative Commons Attribution 3.0 license, he also similarly licensed the rest of his impressive set of free fonts under CC-BY-3.0. (If you enjoy them, please consider giving Hannes a PayPal contribution on his site or consider purchasing from his collection of beautiful non-free fonts to show your appreciation.)

So, you want to package HVD Comic Serif Pro?

Holy cow! You’re awesome! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

Our fonts packaging policy, which the above refers to, is documented here:

And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

Last week’s font

Last week’s font was Sniglet by Haley Fiege. Nobody has picked up the font package request yet! Would you like to?

Unpackaged Font of the Week Posts

Enjoy these font postings? You can view them on all the Unpackaged Font of the Week tag, and you may also subscribe to them via RSS.

Posted in Unpackaged Font of the Week
November 10, 2009 08:42 PM

Richard Hughes
GNOME Color Manager mailing list

GNOME Color Manager now a mailing list – It’s for discussion about colour management in GNOME, and that sort of thing.

November 10, 2009 06:40 PM

Matthew Garrett
The ACPI Embedded Controller
Of course, the event model I described before is far too simple to be worthy of a place in the ACPI spec. At the most basic level, there's more possible events than there are GPEs to attach them to, so there's a need for some further complexity. This manifests itself in the form of the ACPI embedded controller (EC).

The EC is typically a small microprocessor sitting on your motherboard, often implemented in the same hardware as the keyboard controller. It shares a lot in common with the keyboard controller - on PCs it'll usually appear in system io space, with one register for writing a command or reading a status, and a second register for passing data back and forth[1]. There's 256 registers available, so a typical interaction might be to write the READ command (0x80) to the command register, write the EC register address to the data register and then read back from the data register to get the EC register contents.

The embedded controller will often be responsible for tracking information about the hardware, such as the temperature. Attempting to read the temperature through ACPI will execute an ACPI method - in the case of the temperature being monitored by the embedded controller, this method will attempt to read from an EC register. The EC driver then performs the read and returns the result, which gets converted into decidegrees kelvin and passed back to whatever made the temperature query.

But, as mentioned above, the EC also generates events. These may be in response to a user initiated event like a hotkey press, or may be triggered by some change in hardware state like a thermal trip point being passed. The embedded controller will then raise a GPE.

Unlike normal GPEs, the EC GPE is not handled by looking for a _Lxx or _Exx method. Instead, the ACPI tables provide information about the GPE that the EC is using. This may be in the form of a _GPE definition in the EC object in the main ACPI tables, or alternatively may be provided in an ECDT (Embedded Controller Descriptor Table), an optional table that provides all the EC information. In either case, the OS knows which GPE will be triggered by the EC. It then installs a handler that will be called whenever the EC raises that GPE.

Things get a touch confusing at this point. The first thing this handler does is read the command byte, which functions as a status byte on reads. It then checks whether the SCI_EVT bit is set. This informs the system that the GPE was in response to a hardware event, and so the EC handler writes a query command to the EC command register and then reads back a value between 0 and 255 from the data register. This is then mapped to a _Qxx method, with xx representing the number of the EC event read from the data register. Like the _Lxx and _Exx methods, the _Qxx method is then executed.

The problem with all of this is that the EC isn't that fast. When a byte is written to it, it's necessary to read back the status byte and check whether the IBF bit is set. This is set when the OS writes a byte to the data register, and cleared once the EC has processed it. The straightforward way to deal with this is to poll the status byte until the bit is cleared, and then write the next byte, but polling is slow and wastes CPU time. The EC can instead be set to interrupt mode, where it'll fire a GPE when the IBF bit clears.

The EC has one additional function. The ACPI spec allows for an i2c bus to be implemented through the EC, with EC registers mapping to i2c registers. The observant among you will realise that this means that there's an indexed access protocol being implemented on top of indexed access hardware, which is more layers of indirection than seem sane. For additional humour, this is usually only used to add support for ACPI smart batteries. ACPI batteries are generally abstracted behind a set of ACPI methods that provide information. Smart batteries instead speak i2c directly to the OS[2] for no real benefit. Linux handles these devices fine, and while the chances are you probably don't have one, the chances are also that if you do you haven't noticed.

The final quirk of ACPI events is that there's yet another means of delivering events. The term "fixed feature" is used to describe an ACPI device that isn't described in the ACPI tables. A power button may be implemented as a fixed feature device rather than a normal ("control method") device. This is indicated by a flag in the fixed feature block. Hitting a fixed feature power button will generate an ACPI interrupt, but no GPE. Instead the OS has to read the fixed feature block and note that the power button flag is set there. It then notifies userspace appropriately. Sleep buttons can also be implemented this way, but other devices will be in the normal ACPI tables and will generate either GPEs or EC events.

[1] On my laptop, these are ports 0x62 and 0x66 - compare to the keyboard controller's use of ports 0x60 and 0x64

[2] As directly as indirection via the EC can be...
November 10, 2009 02:58 PM

Andre Klapper
GNOME 3.0: September 2010!

GNOME logo

After collecting some feedback, the GNOME Release Team has finally decided on the release date for GNOME 3.0: It will be September 2010.
To take a look again at the GNOME 3 plan that was released in April 2009: Click here.

New module decisions for GNOME 2.30 were also made of course.

November 10, 2009 11:16 AM

Matthew Garrett
ACPI general purpose events
ACPI is a confusing place. It's often thought of as a suspend/resume thing, though if you're unlucky you've learned that it's also involved in boot-time configuration because it's screwed up your interrupts again. But ACPI's also heavily involved in the runtime management of the system, and it's necessary for there to be a mechanism for the hardware to alert the OS of events.

ACPI handles this case by providing a set of general purpose events (GPEs). The implementation of these is fairly straightforward - an ACPI table points at a defined system resource (typically an area of system io space, though in principle it could be something like mmio instead), and when the hardware fires an ACPI interrupt the kernel looks at this region to see which GPEs are flagged. Then things get more interesting.

The majority of GPEs are implemented in the ACPI tables via methods with names like _Lxx or _Exx. The xx is the number of the GPE in hex, while the leading _L or _E indicates whether the GPE is level- or edge-triggered. If an ACPI interrupt is fired and GPE 0x1D is flagged as being the source of the interrupt, the ACPI interpreter will then look for an _L1D or _E1D method. Upon finding one, it'll execute it. What this method does is entirely up to the firmware - on most HP laptops, GPE 0x1D is hooked up to the lid switch[1] and so executing it will send a notification to the OS that the lid switch has changed state. The OS will then evaluate the state of the lid switch (generally by making another ACPI query) and send the event up to userspace.

How does the lid end up triggering GPE 0x1D? Things get pretty hardware specific at this point. Intel motherboard chipsets have a set of general purpose io (GPIO) lines that can, for the most part[2], be used by the system vendor for anything they want. For a lid switch, one of these lines is hooked to the switch and the BIOS configures the GPIO as an input. Pressing the switch will cause the GPIO line to become active. The GPIO lines are mapped to GPEs in a 1:1 manner, though with an offset of 16 - ie, GPIO 0xd will map to GPE 0x1d. If GPIO 0xd becomes active, GPE 0x1d will be flagged and an ACPI interrupt sent. The ACPI code will then do something to quash the interrupts, such as inverting the polarity of the GPIO[3], as well as send the notification to the OS.

Why are the GPIOs offset by 16 relative to the GPEs? The lower 16 GPEs (again, talking about Intel hardware) have pre-defined purposes[4]. These range from things like "Critically low battery" to "PCIe hotplug event" down to "This device triggered a wakeup". And the latter is what I'm most interested in here.

Various pieces of modern hardware can be placed into power saving states when not in use. The problem with this is that the user experience of having to turn on hardware before you can use it is not a good one, so in order to make this the default behaviour we need the hardware to tell us that something happened that requires us to wake the hardware up.

There's something of a chicken and egg problem here, but thankfully most of the relevant modern hardware has out of band mechanisms to tell us about things going on. The PCI spec defines something called Power Management Events (PME), which are driven by an additional current that's supplied to the hardware even when it's otherwise turned off. On plug-in PCI Express cards, firing a PME generates an interrupt on the root bridge and a native driver can interpret that, but for legacy PCI devices and integrated chipset devices the notification has to come via ACPI.

The example I've been working on is USB. It's a good choice for various reasons - firstly, there's already support for detecting when the USB controller is idle. Secondly, modern USB host controllers have support for generating PMEs on device insertion, removal or (and this is important) remote wakeup. In other words, as long as the USB bus is idle we can power down the entire USB controller. If the OS tries to access a USB device, we'll power it back up. If the user unplugs or plugs a device, we'll power it back up. If a previously idle device suddenly responds to some external input, we'll power it back up. And it's all nicely invisible to the user.

How does this work? The controller retains a small amount of power even when nominally pwoered down. This is used to keep the detection circuitry alive. When it receives a wakeup event, it asserts the PME line. The chipset detects this and fires a GPE. The OS runs this GPE and receives a device notification on the ACPI representation of the USB controller, telling us to power it back up. We do so and process whatever woke us - if the bus then goes idle again, we can power down once more.

The astonishing thing is that this all works. The only problem we have is that it relies on the machine vendor to have provided the ACPI methods that are associated with the GPEs. If they haven't, we can't enable this functionality - even though the hardware is capable of generating the GPEs, we have no method to execute to let us know which device has to be woken up. The GPE is never answered, we never acknowledge the PME and the hardware keeps on screaming for attention without getting any. And, more to the point, it never gets powered up and your mouse doesn't work.

There's a pretty gross hack to deal with this. In general, we know what the GPE to device mappings are - they're pretty static across Intel chipsets, and while AMD ones can be programmed differently by the BIOS we can read that information back and set up a mapping ourselves. This trick also comes in handy when some vendors (like, say, Dell) manage to implement one of the GPE events wrongly. Everything looks like it should work, but the method never sends a notification because it's buggy. In that case we can unregister the existing method and implement our own instead.

This code isn't upstream yet, but patches have been posted to the linux-acpi mailing list and with luck it'll be there in the 2.6.33 timeframe. My tests suggest about 0.2W saving per machine, which isn't going to save all that many polar bears but seems worth it anyway.

[1] _L1D = lid. Sigh.

[2] There's a few that are reserved for specific purposes

[3] So where before it had to be high to be active, it now has to be low to be active - this means that it'll now trigger on the switch being opened rather than closed, so you'll get another event when you open the lid again.

[4] You can find a list in the documentation for the appropriate ICH chip - the relevant section is "GPE0_STS" under the LPC interface chapter.

November 10, 2009 03:08 AM

November 09, 2009


Matthew Garrett
Looking to the past
It’s an oft-voiced suggestion that rather than looking at the bad things that happen in our communities, we should focus on the good things. There’s a number of highly successful geek women already – should we not be concentrating on encouraging more of them, rather than scaring people away with tales of thoughtlessness, discrimination and outright abuse?

Let’s draw an analogy. One day, a $20 charge appears on your credit card. You didn’t make it. You report it to your credit card company, who assure you that they take fraud seriously and then do nothing. A few days later, another $20 charge. Your credit card company tells you that such events are rare, unrepresentative of the general credit card experience and continue to do nothing. A week afterwards, another charge. This time your credit card company describes how they’re planning on implementing a brand new anti-fraud system, but that this is unrelated to any events that may currently be occuring and will give no details as to when it’s going to be rolled out. And proceed to ignore any further reports you make about fraudulant transactions.

Would you stay with this company? Or would you take your business somewhere else?

The problem with the “Let’s look to the future rather than spending too much time getting stuck in the present” argument is that it assures people that things will get better without providing a roadmap for getting there. It does nothing to validate their concerns or make them feel wanted within a community. It assumes either that people will stick with a community that doesn’t respond to their complaints, or that it’s possible to construct a community that’s welcome to an assortment of genders, ethnicities and lifestyles without any of those people being represented in the first place.

Ignoring people’s concerns is an excellent way to drive them away from your community. Doing so because of a potential future that’s probably conditional on you having those people in your community is short sighted and self defeating. Ignoring the present doesn’t benefit the future. It benefits the status quo.

(Originally posted here)
November 09, 2009 08:56 PM

November 08, 2009


Máirín Duffy
Fedora 12 rocks on tablets


(That’s Fedora 12 Beta’s Inkscape on my Thinkpad x61 with a built-in Wacom digitizer in the photo. Photo credit David Aquilina, CC-BY-3.0)

Got a tablet, or want to get one, but not sure it’s going to work out in Linux? Here’s how my Thinkpad x61’s built-in Wacom tablet works in Fedora 12 Beta:

  • Tablet pressure sensitivity out-of-the-box, no xorg.conf needed! (Well okay, so that’s been the case for a couple Fedora releases now ;-) )
  • Cellwriter provides handwriting recognition text input (no more having to flip the tablet back to keyboard mode just for one stupid little thing.)
  • Xournal is great for taking notes & signing documents. No more print, sign, and re-scan; I can just sign emailed digital documents on screen and email them right back.
  • Gimp brush dynamics effects rock – they’re the secret to achieve quite a few of the effects in the Fedora 12 wallpaper designs.
  • The new Inkscape in Fedora 12 has a cool new feature that allows you to create your own brushes and save them or choose from a collection of preset brushes.


Fedora is truly committed to software freedom. Enjoy great features like this without the guilt. Try Fedora 12 RC3 today. Or wait until Fedora 12 final comes out:

Posted in Uncategorized
November 08, 2009 08:22 AM

November 06, 2009


Máirín Duffy
Get to know a Fedora Ambassador or User

We’ve got a meme!

Name: Máirín “Mo” Duffy
IRC nickname: mizmo
IRC channels: #fedora-design, #fedora-art, #fedora-admin, #fedora-mktg, #fedora-devel on freenode; #fedora-desktop on GIMPnet
Location: Boston, Massachusetts USA

Mo

Posted in Uncategorized
November 06, 2009 10:20 PM

Chris "Monty" Montgomery
While Denton and George are Sleeping #8

We're out of beta and releasing on time...

November 06, 2009 04:12 PM

Caolán McNamara
my first sub hour build

So, i7 920 + 10k SATA, full vanilla OOo DEV300_m64, no ccache, no nodep, no NOHIDS, straight build from a stock “./configure” (i.e. includes building seamonkey from source and binfilter) through and including packaging with (date && VERBOSE=FALSE build –all –dlv_switch -link -P8 — -P8 -s && date) > /tmp/build.log 2>&1 took 58 minutes.

November 06, 2009 12:32 PM

Lennart Poettering
Public Service Announcement

Folks! Since quite some time now the kernel exports the DMI machine information below /sys/class/dmi/id/. You may stop now parsing the output of dmidecode thus depending on external tools and privileged code.

For example, to read your BIOS vendor string all you need to do is this:

$ read bv < /sys/class/dmi/id/bios_vendor
$ echo $bv

Which is of course much simpler, and cleaner, and safer than anything involving dmidecode.

Thank you for your time!

November 06, 2009 10:14 AM

November 05, 2009


Paolo Borelli
JavaScript in gnome

Being away from home, bored and yet too tired to do something productive, I skimmed through the gnome-shell proposal mail thread on d-d-l and spotted the inevitable debate on the choice of javascript as a scripting language for the shell.

Personally I am not a big fan of js, quite the contrary, but lately I had to use it extensively (though not in gnome related context) and at the end of the day it is a language as any other. I am not saying it would be the one I would have chosen, but once you use it a bit and get to know its idiosyncrasies, you get what you need done and move on with life. After all any programming language sucks, each one in its own special way and some more than others, but they all suck.

Reading in the aforementioned thread the reasons why js was picked I would have been totally satisfied with valid answers like:

  • “It’s my project I and pick whatever language I please”
  • “Some of the more talented and experienced gnome hackers chose it. Trust them”
  • “It is not C++ or perl, so do not complain”

Beside given that javascript

  • has good free implementations
  • is widely used (not only in general, but at this point also by various big gnome projects)

I do not have any major problems with it. After all we have clean and consistent code bases written using GObject C conventions, I do not see why we should not be able to tame js as well.

That said, some of the rationales provided for choosing it in the above mentioned d-d-l thread really really trouble me.

js has no platform libraries, so we can use our own

What kind of reason is that? First of all when you embed another scripting language you are not forced in any way to use its standard libarary as well. Second, having a good standard library (or a large set of third party libraries) is a good thing: I thought we were focusing on implementing good applications instead of reimplementing and maintaining a “gwhatever” library for every problem in the world.

using js will attract web developers

That is plainly naive. First of all I have never hacked on something because it was written in a language, at most I have learned a language because something I wanted to hack on was written in it. Second learning the syntax of a language is nothing compared to learning library API, tools, workflows etc and even if I have not used js in gnome yet, I am pretty sure they differ a lot from what web developers are used to. Last but not least, I’d prefer to attract a single good developer than a hundred people not willing to invest an afternoon in learning a language/api/tool.

November 05, 2009 10:33 PM

Bastien Nocera
Get Moblin, get GNOME
If you were to install the new Moblin 2.1 somewhere, you'd be getting a gnome-bluetooth powered Bluetooth panel.

All the code lives upstream in the gnome-bluetooth module on master.
November 05, 2009 10:10 PM

Chris "Monty" Montgomery
While Denton and George are Sleeping #7

The first few wooden shells, hot off the press as it were.

November 05, 2009 08:13 PM

Richard Hughes
GNOME Color Manager and initial scanner support

Late last night, after a few hours of intense refactoring (to allow udev based devices, as well as xrandr based devices) we got the initial scanner support working:

Scanner support

Scanner support

This lets us support printers and digital cameras pretty easily too. At the moment we just need to figure out how to make gnome-scan make a scan for us and save it in tiff format, and then we can get the calibration working for all types of scanners. Of course, you need a precision printed reference image, but you can get these pretty cheaply from Wolf Faust.

Then, we need to work with the gnome-scan guys to agree an interface so that gnome-scan knows what profile to use for each device. Either a library or DBus interface (with calls in either direction) are being considered, although I think the session-activated dbus interface is probably going to win. There’s still quite a bit of integration work to make CUPS ICC profile aware, but that’s on the list after scanners are working. After all, you need a calibrated scanner to calibrate the printer. Help is always welcome, so please checkout the code and help find bugs.

November 05, 2009 09:29 AM

November 04, 2009


Bastien Nocera
No more stuttering
Today, as some of you guessed from my teaser yesterday, I finished implementing on-disk buffering in Totem, using playbin2's new features.

Using Totem in master with this gstreamer patch, Totem will start playing back videos as soon as enough buffering has been done on disk.

Note that this will only work for QuickTime and FLV streams, but that means that the YouTube Totem plugin and streaming trailers from Apple's website just got better, and should allow us to implement stream saving very soon.
November 04, 2009 08:04 PM

Behdad Esfahbod
litl by litl
Finally litl's product is out: it's a webbook. The easel mode looks quite interesting, and reading their website, it looks like the kind of gadget/netbook/appliance I'd be more than happy to have around (in a theoretical family setting, not /me as lone hacker).

But at the starting price of $700, I'm not sure who they are targeting. Sounds like Apple customers... And that does not include the remote or the HDMI cable. And the twinpack offers exactly $0 dollars discount over buying two units separately. I found these very cheap of them. Otherwise it all looks very promising.

While at gadgets, anyone knows whether n900 will have a developer program?
November 04, 2009 07:26 PM

Behdad Esfahbod
HarfBuzz HackFest
Here is a quick update re HarfBuzz:

During May and August I finished rewriting the OpenType Layout engine to use mmap()ed font files. This is in Pango 1.26.x already. Pango and fontconfig also received a lot more optimization love. That deserves a long and separate blogpost. The net result is that the text stack's memory usage is considerably lower now. All this goodness will be in the upcoming Fedora 12.

In October, I attended the 33rd Internationalization and Unicode Conference in San Jose to present the free software text stack (useless slides) as well as present and promote HarfBuzz (useless slides). That was a very fruitful event and I received lots of interest from many major industry players. With the liberal license that we are releasing HarfBuzz under, we expect broad adoption, which is exactly what we are looking for.

This week, Jonathan Kew and myself are having a small HarfBuzz HackFest here in Mozilla's Toronto office. Here's what we have got done so far:
  • Jonathan has a version of Firefox using harfbuzz-ng (the codename for the rewrite) that has advanced layout features controlable through CSS. Very very cool stuff. He updated it to the latest harfbuzz-ng code.
  • I ripped harfbuzz-ng out of the Pango tree and into a standalone module. Finally! Took a couple hours of git surgery plus ten minutes to put together an autotools build system. Git clone URL is this. The harfbuzz-ng-external branch in Pango uses that as an external module. The plan is to reach a stable 1.0 release of harfbuzz-ng before next stable GNOME and most probably, Pango will require harfbuzz unconditionally (that is, on all platforms). Note that harfbuzz is NOT tied to FreeType, so you can use it with any rasterizer you have around.
  • We fixed all portability issues Jonathan had faced when compiling harfbuzz-ng with MSVC.
  • Jonathan is working on the shaper side, while I'm working on the API and pulling it all together.
  • I added glue code for using harfbuzz-ng with glib, ICU, and FreeType.
  • Lots of API and design review.
At the rate this is developing, by the end of the week we should have basic shaper (Latin, Cyrillic, CJK, ...) and Arabic+Syriac working perfectly and tackling Indic family. We're closer to 1.0 than you may think!
November 04, 2009 07:20 PM

Máirín Duffy
Unpackaged Open Font of the Week: Sniglet

Sniglet is a fun rounded, sans-serif font useful for headlines and other creative treaments. The font was created by Haley Fiege, and it supports a full Latin character set including accent marks (Haley notes both Icelandic and French are supported.) (P.S. Haley’s got some other great fonts for sale on dafont.com that you might want to give a try if you like Sniglet!)

So, you want to package Sniglet?

Super! You’re totally kickin’! You’ll want to follow the first steps here next to the ‘if you intend to do some packaging’ header:

Our fonts packaging policy, which the above refers to, is documented here:

And if you have any questions throughout the process, don’t hesitate to ask on the Fedora Fonts SIG mailing list:

Last week’s font

Last week’s font was Bola by Pablo Caro. Edward (AKA tk009) has again stepped up as he did for Tiza and has already packaged it and submitted a font package review request for Bola. (Fedora wiki font request page.) Both the Tiza font package review request and the Bola font package review request are waiting on someone to review them, so if you’ve got the time and inclination, please help out!

Thanks again to Edward for helping Fedora expand our inclusion of all the awesome openly-licensed fonts out there!

(P.S. I had a bit of a WordPress malfunction (I am so accustomed to implicit apply but apparently in schedule changes WordPress requires an explicit apply action) so there was a 15 minute window today during which you may have gotten a little sneak preview of another font I may post about it the future. ;-) )

Posted in Unpackaged Font of the Week
November 04, 2009 01:50 PM

Máirín Duffy
Planet can be annoying.

WordPress posted a draft a week early by accident. Planet will not forget unless I keep that post but erase the content.

So here I am replacing that post with random content to get the posted-too-early post off Planet. :)

Posted in Unpackaged Font of the Week
November 04, 2009 11:50 AM

November 03, 2009


Bastien Nocera
Notice anything?
Answers on a postcard (or in the comments).

November 03, 2009 06:49 PM

November 02, 2009


Chris Blizzard
bringing theora to youtube (the hard way)

I switch back and forth between Linux and Windows 7 pretty regularly these days.  But I have has this problem with Linux. I can’t run Firefox 3.6 nightlies (which are nicer than the 3.5 release) and Weave and Flash all at the same time. I can run Firefox 3.5 and I can have Flash, but Weave doesn’t work. Or I can run 3.6 with Weave but then Flash crashes the browser. It turns out that for me Weave is way more important than Flash but I still miss being able to watch the occasional Youtube video.

If you’ve ever run Linux for any period of time, you’ve had this kind of experience.

Anyway, I decided to try and make it so that I could easily play Youtube videos without having to use Flash. (Flash – in many ways – is the weak link in the chain.  In this case it’s because I can’t fix/hack it, although I’m happy to not have it because my browser is a lot more reliable.)

Theora + Youtube = Love

Theora + Youtube = Love

I wrote a greasemonkey script called Theoratube that connects to the Firefogg extension. It’s based very heavily on the really great Youtube without Flash Auto user script that lets you embed videos as a plug-in. But in my case I decided to use native Theora and HTML5 video because it’s more reliable, has controls and doesn’t require any additional software to start working.

How does it work?  It pulls down the video, uses Firefogg to transcode it, and then stuffs it back into the browser via a private URL.  It’s slow because it has to pull + encode the entire video, but it works surprisingly well for something that is as hacky as it is.

The worst part is the delay in between loading it and the first time you can play the video.  It needs a few changes to make it more usable:

1. It needs to download the video, start transcoding it and stream it into the browser as soon as possible.  This shouldn’t really be a problem and will probably be a pretty good experience.  Youtube bursts its traffic to start and then throttles it way back and at least on my machine the encoder can keep up pretty easily to transcode live.  This means taking it out of greasemonkey and putting into a proper extension to get everything inline properly.

2. The current Firefogg stuff works pretty well but it isn’t really designed for this use case.  For example, once you start a download of a file there’s no way to cancel it.  Same with encoding.  Also it needs an event feedback system instead of polling, which is what the greasemonkey script has to do right now.  But if you’re moving it to an extension above anyway this is probably pretty easy to do – just download in the extension directly and then include Firefogg for the encoding part.

3. Firefogg can only encode directly on a file instead of being part of a stream.  Not sure if ffmpeg2theora can handle this across platforms or not – I suspect so, but it’s something that needs to be fixed.

4. It really needs a big online cache to store data once you’ve downloaded it and encoded it to a free format.  Think of it as collaborate transcoding in the cloud.  Download, transcode, re-upload so that others can benefit as well.  You’ve already got the Youtube ID and the format it came from – that would make it pretty easy to key off of and do a quick lookup before trying to re-download the video and re-encode it.*

5. It needs to match particular quality formats to bitrates for the encoder.  Right now it just encodes everything at top quality since it’s just local and it’s the least loss you can buy.

6. The copyright issues here are…interesting.  There’s some content on Youtube for which the uploader actually has the copyright on that particular work.  (I mean, we’re talking about Youtube.  Your source for 15 remixes of Drunkest Guy Ever.)  And this is mostly about accessibility, not downloading.  So we’ll see if anyone gets upset.

7. It doesn’t handle youtube embedded videos on the web.  This will be a little trickier, but certainly not impossible.  Just need some more greasemonkey to help there.  Probably have to transform the object embeds into something else.

8. Seeking might be a little challenging, but not impossible.  There’s a parameter to the get_video call that lets you specify where to start pulling the video.  Probably offset in the number of seconds.  But needs some investigation/work.

So this is certainly 0.1 software.  But it raises an interesting tactic in making content more accessible in open formats – even without the participation of the original party.  Sometimes the work around isn’t what you expected.  (Note: I would like this for t61 as well.)

* No fooling, I wonder if Google would be willing to host such an archive?  People are willing to transcode to work around their lack of support for open formats – maybe they could at least provide a valid archive for them to work together?  Or maybe the Internet Archive?

November 02, 2009 02:00 PM