So Mo and I finally got engaged.

My router is a pretty underpowered machine. It has 512MB of RAM, and its ‘disk’ is a 2GB flash card on a CF to ATA adaptor (read as: really slow). But given its job is just routing packets 99% of the time, neither of these deficiencies are an issue.

Asides from one problem. Every time I did a yum update that pulled in an selinux policy update, it would consistently exhaust all the ram in the machine. I filed a bug on this, and as usual, Dan Walsh dropped some selinux knowledge that I had no idea about.

You can customize the bzip block size and “small” flag via
/etc/selinux/semanage.conf. After applying you can add entries like these to
your /etc/selinux/semanage.conf to trade off memory vs disk space (block size)
and to trade off memory vs runtime (small):

bzip-blocksize=4
bzip-small=true

You can also disable bzip compression altogether for your module store
via:
bzip-blocksize=0

Since I put that first tweak in place, it’s survived several policy updates without a hiccup.

SELinux on low memory systems. is a post from: codemonkey.org.uk

No related posts.

The Augen Android tablet being sold in Kmart stores at the moment is (shockingly) running a 2.6.29 kernel and Android 2.1 on top of that. It's also (shockingly) currently impossible to get hold of the source code for the kernel - Augen (whose corporate address is a small unit in Florida) say that the software comes installed on the units by the OEM and they don't have any access to the source either. This isn't an excuse, of course, and they say that they hope to have it on their website within the next few days - but even so, it seems that the Android device GPL violation trend is still on course. It'll be interesting to see what the long-term outcome of this kind of violation is, especially with these devices increasingly being sold by mainstream stores.

Six years ago, we did the first large scale Ogg Theora stream from the 2004 GUADEC conference.

It was a dime on its side to get things ready for this year. I purposely removed myself from the organization, because for various reasons I’m not going to GUADEC this year, but I was hoping the rest of the company would do their part to get this working, and I just provided the necessary prodding along the way. I’ve been told one of the organisers in charge of this got ill at some point and communication went a bit south during that period, so I had some complaints from our support guys that they had to do last-minute rushing.

But the streams are live today, and a few developers here are giddily running around looking at the stream, the image, working on some typical bugs you get when you’re doing stuff like this for the first time (the artifacts on keyframes the encoder seems to have remind me a lot of the Theora bugs we had to squash back in the day, and obviously they are worse on still images, like, say, an empty conference room…)

Go check out the stream and make sure you have a WebM-enabled browser, like the Firefox 4.0 beta or latest Opera.

Congratulations to our intrepid hackers like Zaheer and Andoni for their hard work a few weeks ago on WebM, and I’ve been told Marc-André actually went to Holland just to deliver the encoders :)

Things I hate today include:

• Symbian on my Nokia N97 — for spontaneously rebooting as soon as I got off the ferry.
• Google Maps — for not caching the map tiles I'd carefully downloaded while I was on the free ferry wireless, showing my route to the hotel.
• Mobile phone networks — for the insane amount of money it will have cost me to re-download the same map tiles again, as I was driving.

It's almost as if it's a conspiracy — especially between the latter two.

I really need to get myself an N900 and start using maemo-mapper again. Every time I try to use non-free software, it hurts.

I don't normally consider myself an angry person. I don't go around kicking puppies or punching holes in walls, but over the last day or so, I've been considering whether or not I default to anger.

Over the last week, I've been in Portland, OR for OSCON. I hadn't been to this particular show in years, primarily because it felt very very corporate on my last visit. It had a "we payed big money for this sponsorship so we're going to get to aggressively push our non-FOSS software (and culture) to you in confusingly worded sessions and keynotes" vibe. Is it snarky for me to say that? Snark is kind of an angry way of making a point, I suppose. Okay, lets try again.

It concerns me when a conference that has "Open Source" in its name in any way encourages non-FOSS software and ideals, from its sponsors or otherwise. It would be more appropriate to say that it annoys me. So, I stopped going to OSCON a few years back.

I'd heard from others that OSCON had gotten better about things, so I penciled it in for my 2010 conference attendance and got budget allocation to go. Now that it is all said and done, I think things have noticeably improved, but I felt it could still use some work. First, here were some things that I liked about OSCON:

* Good timing, on breaks, meals, snacks, events, and plenty of time to make it from one session to another (as long as no one ran too long)
* Track on new/emerging languages seemed just right for OSCON, even if it wasn't something of interest to me
* Most companies/groups on expo floor had some FOSS to talk about
* Google's generosity in giving out several hundred Nexus One phones. They're not 100% FOSS, but they're more FOSS than my old iPhone.

Things I didn't like:

* "Sponsor" sessions that were simply advertisements for non-FOSS. Does OSCON really need to do this anymore?
* Whoever gave away vuvuzuelas (spellcheck proposes "Venezuelans"). Sounds like fun, until someone walks by your booth blowing one for the 100th time. With the World Cup, I imagine you really don't need to hear anything to enjoy the game, but at a conference, being able to hear my answer to your question is rather useful.
* Defensive keynotes. Specifically, where the keynote presentation is on the defensive from the beginning. I'm looking at you, Microsoft and Eucalyptus. The fact that you need to defend your non-FOSS model and tactics outright should be telling for you, but was just embarrassing to watch.

Overall, I enjoyed OSCON, but to be honest, I came into this conference with a secret hope. I knew that Google would have a huge presence here, and I was hoping that I'd get the chance to talk about chromium (or at least, hear someone talk about it).

As many of you might know from reading this (infrequently updated) blog, I spend a fair amount of time working with the chromium source code, gently (and occasionally not as gently) massaging the source so that it builds into RPM packages for Fedora targets, while at the same time, stripping out as much of the bundled/forked third party FOSS libraries as I can. I know my work is appreciated by users and by my counterparts in other distributions who are also doing the same tasks. But I've never really felt that most of the people working on Chromium cared whether I did it or not. In fact, with the notable exception of Evan Martin, I felt that they actually were generally unhappy that I do this work.

I should clarify that statement somewhat. In the course of my work, I've needed to patch the chromium source code pretty aggressively. To date, none of my patches have been merged (or in most cases, even commented on), even though most of them have been submitted as bug reports. This is demoralizing, because it implies that they don't take the time to care about my work. However, I've tried very hard to never assume malice when other factors such as being overworked could be equally viable.

I've got pretty strong feelings about how Chromium (and v8) development is being done. I think that the design and implementation decisions that they've made have made it difficult for any real community of contributors to form around it, and in the case of v8, functionally impossible for third party FOSS projects to leverage. I've raised these feelings with the Google Chromium team in the past, and they generally don't care. (Again, Evan is a notable exception.)

I know that it is much harder to communicate online than it is in person, the nuances of inflection and tone translate poorly in bits and fonts, so I was hoping that someone from the Chromium (or v8) team would be at OSCON to talk about their roadmap, their development approach. I had hoped for this for two reasons: 1) To better understand what motivates them to act the way they do and 2) To have the opportunity to explain why their approach is so frustrating from a FOSS and a distribution packager perspective

Sadly, there were no "Chromium" or "V8" sessions on the OSCON schedule, but there were two "generic" Google sessions, so I attended both of those. The first was more of a general "Google" town hall, and the speaker (Chris DiBona) said early on that questions about Google's FOSS initiatives should be held until his later session, so I waited for that session. During the first session, it was noted that a healthy majority of attendees in the room worked for Google, which gave me hope that there were some Chromium/V8 folks present.

I attended the second session, and waited for the topic of Chromium to come up during Mr. DiBona's slides, but it was not mentioned at all. No other questioners during the Q&A session brought it up, so I raised my hand.

To be fair, I don't remember exactly what I asked, verbatim. I knew Mr. DiBona wasn't part of the Chromium team, but I was also aware that he seemed confidently (and even cheerfully) aware of Google's FOSS initiatives, so I asked a broad question that went something like this:

"Google's approach to Chromium and V8 has been really frustrating and difficult from a distribution perspective, do you know if there are any plans to improve that?"

Chris DiBona responded with a defensive ferocity and anger that caught me significantly off-guard. He accused me of being angry, then admitted he was unaware of any such concerns, then suggested it would be better handled offline, all in an extremely condescending and aggressive tone.

I left the session disappointed. I wasn't expecting him (or anyone) to say "We're so sorry! We'll change everything right now!", but I certainly wasn't expecting to be bitten and yelled at. Am I truly angry? I thought about this for the next two days. Had I said something to merit that anger, or was he simply deflecting anger back at me. I didn't feel angry, at least, not until he answered with such an aggressive tone and demeanor.

In retrospect, almost every single question asked in those two sessions was less of a question and more of a glowing fanboy praise, in the form of a question. "When will Google Foo version 2 be released?" or "Will Google Bar integrate with Google Baz?". My question summed up to "When will Google Qux stop behaving badly?". Was there a way I could have phrased that to get a better response? Would it have helped if I had been more specific (even if that would have taken 15 minutes to do properly)? Or was it simply that I was highlighting a negative that caused such backlash?

All that I knew for sure was this: In one single response, Chris DiBona made me not want to work on Chromium anymore.

After the talk, several Google employees approached me to talk about Chromium and V8, they didn't work on that effort, but they knew the people who did. I apologize for not mentioning them by name, because, well, I'm terrible with names, but we talked about my concerns, both idealogical and technical. I explained why Chromium and V8 weren't part of any Linux distribution, the work I had done to compare performance in a static vs shared configuration, why bundling and forking as an instinctual default behavior was harmful, and they explained why they suspected that the Chromium and V8 projects were handled in the way that they were. They were patient, but engaged with me, which was good, because I was admittedly pretty worked up by that point.

But I couldn't stop thinking about being angry. I know how it made me feel when Chris lashed out at me during his session, and it stacked on top of what I had already been feeling about my Chromium efforts. It made me feel unwanted, unappreciated, and unwelcome. Even though my instinct was to blame his anger for this, was I really the angry one?

Angry people are poisonous people. Sometimes, they can calm down and become productive people, but almost no one is useful and productive when they're angry. This is why snark isn't useful or productive. It's why no one wins a shouting match, ever. When it comes to FOSS, which is largely a meritocracy, when you're angry, you're not able to earn respect or credibility.

I hope that people appreciate the work that I do on Free Software and Open Source. I hope that I am respected amongst my fellow users and contributors in the community at large. I hope that I'm not angry. I'd rather be passionate than angry.

I'm not sure if I'm going to keep working on Chromium or not. I'm not sure if I was truly angry in that session at OSCON. But I do know that I'm going to make a conscious effort to identify, within myself, the difference between passion and anger, and leave any anger that I find behind. I'm not saying that it is never wrong to be angry, just that it isn't productive to be angry in FOSS, and I'd much rather be a productive contributor than an angry agitator.

I know it won't be too long before I'm giving a presentation at some FOSS or Linux event and someone asks me an angry question, but I hope I will be able to reply calmly, and channel that anger into something productive. I encourage all of you to think about being angry and how that affects your involvement with FOSS and its communities.

sgx535 drivers in today's Meego kernel tree: 3 (GMA600, CE4100, N900)
sgx535 drivers submitted upstream: 1 (Tungsten GMA500 driver, submitted March 2009, rejected due to significant chunks of functionality there purely to support closed userspace)

To be fair, the rest of the Moorestown support code seems to be shaping up fairly nicely. But the lack of a coherent story about what graphics support is going to look like isn't hugely reassuring.

Update:

The Meego kernel tree isn't really a fair comparison here - I should be talking about the Intel MID tree. That's only got the GMA600 and CE4100 drivers at the moment, and I'm told that there's consolidation work going on there.

For the last couple of years I’ve been responsible for our wonderful Evangelism group at Mozilla. We’ve been responsible for a combination of developer relations, standards work and outbound developer-focused communications. If you’ve followed our work on hacks and devmo, especially around the release of 3.5 and 3.6 then you’ve familiar with the pretty amazing work of this team.

But over the last few months I’ve been focused on one aspect of that job more than others – helping to drive the web-facing side of our platform. A big part of that work has been listening to web developers who are building on top of the web and understanding what they need. (This is a big part of the role of the Evangelism group inside of Mozilla.) I’ve also been working closely with Mozilla’s engineering team to help determine what’s important and what’s not. I think that I’ve discovered – and others inside of the project have discovered as well – that having someone doing that full time with a specific focus on the web platform full time is really important. (In the past that role was spread across various parts of the project.)

To that end I’m moving on from leading the Evangelism team and moving to help manage the web-facing side of Firefox full time. It’s easiest to think of this as a product manager for the web.

This is going to be an interesting job, to be sure. It’s entirely built of soft skills: listening closely to web developers, both frontend and backend. Working with the Mozilla community to communicate and understand where the web needs to go next. Working with partners to build great partnerships and products. Working with our user and developer engagement groups on the best way to talk about the web. Maintaining a roadmap for Gecko. And, last but certainly not least, working every day with the people on the ground doing the great work that make Gecko the best platform to advance the web.

I expect that I’ll keep posting on hacks and on this weblog. But expect to see different kinds of questions from me from now on. I expect that I’ll be spending a good bit of my time on what the web will look like 2-5 years from now and what we can do at Mozilla to make that happen. That’s going to require looking for the best ideas that people have and working to make them a reality through the Mozilla project.

The web is a platform that’s still ripe for improvement and change. So I’m looking forward to your feedback and your help.

I've had the Sprint Palm Pre for ~13 months now.  It had some initial problems with build quality of the first batch, but after the warranty replacement I have had no problems for the past year.  Early during June I upgraded to the HTC Evo 4G.  The Evo is a very sweet phone in many respects.  It is very clearly one of the best phones on the market now along with Droid Incredible, Droid X or Samsung Galaxy S.  But I had three key problems:

• The Evo is too huge.  With the 4.3in screen it crosses the line of acceptable upper bound size for a phone.
• On-Screen keyboard.  It is simply clumsy and slow to use compared to a real physical keyboard.
• The Android UI is less streamlined in design compared to WebOS.  Various tasks on my Palm Pre that would take mere seconds would take 5X as long on the Evo.  I found myself missing the sweeping gestures of the WebOS interface.  I do not need to press upon precise locations on the screen to go "Back".  Multitasking between apps on WebOS is very smooth with the card sweeping gestures.

Having used the HTC Evo 4G for a month, it became clear to me that Palm put a serious amount of good design into the usability of WebOS.  There is a lot to like about the WebOS platform.  Hackers have seen how friendly Palm has been toward developers.  FOSS developers have commented about how Palm used various Open Source components like upstart and pulseaudio a well integrated fashion.  If WebOS had launched a year earlier and with fewer initial hardware glitches, it might now be a serious contender to Android.  But various indicators now show that Palm simply lacks the momentum of customers against the likes of RIM, Apple or Android.  Palm is heavily investing in their app ecosystem, without which they have no chance.  It remains to be seen if HP's continued investment will keep the platform alive.

I returned the HTC Evo 4G under Sprint's excellent no questions asked 30 day trial policy.  The Evo is a very good phone, but I'm simply more productive with the streamlined interface of WebOS.  I think the ideal phone would be a larger Pre, with horizontal instead of vertical slide-out keyboard and modern 1GHz processor.  Unfortunately it seems no such device is in the plans.  HP seems to be working on a WebOS tablet.  I might consider the Samsung Epic 4G.  The slide-out horizontal keyboard might make it usable enough for me to tolerate the UI negatives of Android.

I’m preparing for my GUADEC keynote and have a request for material that would be useful. Specifically, does anyone have a good group picture from the first GUADEC? This is the best I’ve found so far, but I seem to recall there were better. Please comment or email me (luis at this domain) if you’ve got one. Thanks.

Are you getting excited?  GNOME’s flagship conference, GUADEC, is taking off in a little over a week in Den Haag, The Netherlands.  I’ve got my bags packed and a draft of my talk written.

With one more concert tonight in New York City, I set off tomorrow evening for a much needed vacation in Macon, France where I will be learning classic French cooking at Robert Ash’s cooking school.  The first lesson happens on my birthday, when I will be turning a nice and ripe 33.  Fresh fare such as bar à la crème de fenouil avec ses pommes dauphinoises, confit de canard, and profiteroles au chocolat, among others are set to be learned.  I’ve been playing with the idea of having a fund raising dinner with all the proceeds going to the GNOME Foundation during this year’s Boston Summit.  Perhaps after the course I will feel confident enough to trade donations for my cooking.

Afterwards there are a couple of days of layover in Amsterdam between when the course ends and GUADEC begins.  At GUADEC I am going to be devoting most of my time to whipping PyGObject into glorious introspection shape.   Please join us at the BOFs to learn more, help us hack or get help porting your apps to utilize the power of introspection.  There will be a BOF on general GObject Introspection on Monday the 26th between 14:00-16:00 and on PyGObject(PyGI) on Thursday the 29th between 14:00-18:00.  Otherwise you can find myself or any of the other introspection and GNOME python hackers any time during GUADEC.  If you are a newbie developer looking for something to hack on to get your name out there while learning some core GNOME technologies,  there are some really easy bits to sort of take control of and run with.  There is a lot of detail work such as fixing annotations or doing simple overrides that would take little effort to get up to speed with but make a huge impact on the final quality of the introspected bindings.  Heck, find me over a glass of beer at one of the after parties and I will wax poetic on the thing needed to be done to finish the last mile of our Python plans.

After GUADEC, Colin Walters and I will be travelling to Berlin, both to save airfare by flying out on a weekday and to decompress after a week of non-stop hacking.   I’m looking forward to seeing many old friends and making new ones.  Let’s make GUADEC rock and continue to push GNOME to continue to excel at excellence.  With this year’s focus on GNOME 3 and the underlying technologies that support it there will be a lot of exciting things to see and hack on.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

The Call for Papers for the Linux Plumbers Conference (LPC) in November in Cambridge, Massachusetts is ending soon, on July 19th 2010 (That's the upcoming monday!). It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the only conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that both parties understand better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level infrastructure and APIs.

The two previous LPCs were hugely successful (as reported on LWN on various occasions), and this time we hope to repeat that.

Like the previous years, I will be running the Audio conference track of LPC, this time together with Mark Brown. Audio infrastructure on Linux has been steadily improving the last years all over the place, but there's still a lot to do. Join us at the LPC to discuss the next steps and help improving Linux audio further! If you are doing audio infrastructure work on Linux, make sure to attend and submit a paper!

Sign up soon! Send in your paper quickly! Only three days left to the end of the CFP!

(I am also planning to do a presentation there about systemd, together with Kay. Make sure to attend if you are interested in that topic.)

See you in Boston!

Vincent, which specific options do you need that aren’t supported yet?  If there are commonly used options that aren’t supported, then we should definitely figure out how to add them, but add them smartly.  The large problem is that openvpn’s dev team is absolutely spineless and apparently adds every option anyone ever requests without thinking about how they fit into the larger picture.  The larger picture is already huge:

That coupled with the fact that openvpn apparently has no capability to negotiate options with the peer means you have to specify the config exactly as the admin has set it on the server.  This is a great recipe for Just Doesn’t Work.  People have suggested that we add a GtkEntry or GtkTreeView that you can set to whatever you want, but given that openvpn gets run as root, we still need to validate those options.  So why not figure out how to add them in a clear, consistent manner that’s marginally understandable to users?

All that said, there’s a number of options that we do need to add more support for, like HTTP proxy, DHCP over TAP interfaces, etc.  Simply adding every single option is a great recipe incomprehensible interaction, so we need to get reports from users about what options are actually used in the wild.  Please let us know!

I've just been working on Evolution's reply code, and have added a couple more of those annoying "nag pop-ups", including this one which I expect a lot of people will appreciate when they don't get the resulting mail:

It's currently set to trigger if you hit 'Reply to All' on a message with more than 15 recipients; unless it's a mailing list message. And of course you can see that it's trivial to turn it off if you never want to see it again.

I've also taken a moment to write down and post some thoughts on the 'Reply to All' vs. 'Reply to List' debate for mailing list messages.

Things I did to myself before the bar:

• Did only a fraction of the practice I should have.
• Felt underprepared and terrified, just like you feel now.

Things that happened to me during the bar:

• Day before the exam, while studying poolside at the hotel: got a sunburn.
• First day of exam: stung by a bee.
• Last day of exam: computer crash, requiring me to handwrite the last section of the exam. Haven’t hand-written for three hours straight since college.

And I still passed. Even got invited to be a grader.

So: moral of the story: don’t panic; you’re not as underprepared, and it isn’t as hard, as you think it is. You rock. You’ll pass.

Why WEXT Sucks Episode #52,334

The world only needs a few jackasses and I’d like to think I’m not one of them.  So instead of being a jackass and making fun of people who bought the wrong hardware, tonight I’m going to throw a bone to everyone who mistakenly bought a Broadcom WiFi card thinking that Broadcom cares about open-source and that any bugs you had with their binary driver would be fixed in a timely manner.

In a great example of how WEXT is underspecified, the frequency returned from SIOCGIWFREQ has been interpreted to mean one of two things depending on the driver you have.  Some drivers report the associated channel, while others report the tuned channel.  Of course during a scan the card tunes to a bunch of different channels.  So when you hit up SIOCGIWFREQ you have no idea what the card is going to report.

Some configurations use the same BSSID/SSID combination on different bands.  Thus we need to know what the associated frequency is so we can match up the exact AP the card’s talking to with an entry in the scan list.  Otherwise the scan list doesn’t represent any sort of reality, and that’s not a good thing.  If the card reports the tuned frequency when it’s background scanning or finding a better roaming candidate then the match will fail.

Tossing the Bone

What’s the only thing more common than a dual-band single BSSID/SSID network configuration?  If you guessed “drivers which make talking to that network hard” then you win a big wet donkey kiss from an ugly goddamn donkey.  So in complete violation of my Fix the Stupid Drivers Instead of Hacking Around Them policy I’ve checked a fix into NetworkManager that handles this situation better.  If you ever saw:

NetworkManager[666]: <info> (wlan0): roamed from BSSID 11:22:33:44:66 (cakehole) to (none) ((none))

then I just fixed 15% of your problem.  You’re welcome.  The other 85% is your proprietary driver.  The real fix for this is to use the much more capable nl80211/cfg80211 kernel interfaces instead of WEXT.  That still doesn’t help all you proprietary driver users out there, because Broadcom pretty much ignores upstream kernel wireless advances.  So next time spend another $5 and make your life easier by getting an Intel or Atheros card instead.

I will be at Farmingdale College tonight giving a talk to LILUG.  It is a draft of my “The Future is JavaScript” talk I will be presenting at GUADEC in a little over two weeks.  I will also be talking about what it has been like working for an Open Source company for the last five years, along with how to get started working within the community.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

Yay Brazil!. They're making it illegal to use DRM to prevent "fair dealing" with copyrighted works, or access to works which are in the public domain. It's also legal to "crack" DRM if you're only doing it for the purpose of "fair dealing".

So, for example, it would be legal for me to crack the DRM on the eBooks I buy, which is necessary just so that I can read them. Currently I have to break the law just to be able to buy and use eBooks.

UK citizens, go here and add your vote; it's very simple to register if you haven't already done so.

I'm running a power management track at the Linux Plumbers Conference again this November. Unlike most conferences which focus on presenting completed work, Plumbers is an opportunity to focus on unsolved problems and throw around as many half-baked solutions as you want in order to try to find one that seems to stick. The suspend/resume problem in Linux is mostly solved[1], which means that it's time for us to focus on runtime power management and quality of service.

This has been an especially interesting year in the field. We've landed the infrastructure for generic runtime power management, glued that into PCI and started implementing that at the driver level. pm_qos is being reworked to improve performance and scalability as we start seeing more drivers that need to express their own constraints. And, of course, we had the wakelock/suspend blockers conversation that didn't end in a terribly satisfactory manner, although Rafael is now working on an implementation that presents equivalent functionality with a different userspace API. Runtime full-system suspend isn't solved yet either - the current cpuidle-based solution doesn't work well on multicore systems. And maybe we could be more aggressive still by looking at reclocking more system components on the fly even if the existing interfaces don't allow that. Do we have all the hooks we need to identify which system resources are being used? Are we doing the best we can in terms of avoiding trading off performance for power savings?

So if you'd like to talk about any of these things, or if there's any other problems that you don't think have been solved yet, head on over to the call for submissions and help make sure that we can make Linux the most power-efficient OS possible.

[1] Yes, some machines are broken, but those tend to be individual weird bugs which we're gradually tracking down rather than fundamental issues in our core code, so they're not really in the scope of Plumbers

I’m double checking now but as of this afternoon I was told we have two rooms in the Stata Center and one in Walker, November 6th-8th. I’ll post details and final confirmation as soon as I get them. Thanks goes to Walter Bender and Felice Gardner for all the leg work.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

A few months ago I sat down with Philipp Schmidt and Arun and helped to map out what the open web skill set would look like, mapped as a cloud. This was the first draft, and I thought that it came out pretty well. Lots of stuff left off and lots of stuff under-speced and some stuff over-speced, but a good start. This is all part of Mozilla’s Drumbeat Open Web Assessment and Accreditation work. (The paper itself was 3 feet by 2 feet – quite large, so click through to the larger image for a better view.)

I’m obsessed with music. I can’t imagine a day without it. Regardless of what I’m doing, there’s pretty much always something playing in the background. From time to time I move my work setup from one room to another, just to shake things up, and break some habits. Recently I did this, and it involved using a different machine to usual as my desktop.
After setting up, I noticed that something just didn’t sound right with my music. All the high end frequencies sounded harsh and mashed together. The low end wasn’t anything amazing either. I tried some different speakers. It sounded even worse. At this point I thought I was going crazy, and tried some headphones (my tried and tested Sennheiser HD-280′s — What I like about these is that I’ve used them long enough that I know what to expect from them, so I know when something isn’t sounding right). Again, it sounded lifeless and dull, and high frequencies were almost painful.

What the hell was going on ? I started wondering if I could blame it on software. Maybe there was something in the driver that I could tweak. Maybe Pulseaudio was doing something wrong. I spent an afternoon looking for things to configure, going as far as disabling power management features in the hope that was the cause. In the end, I gave up. I just decided that the “High Definition Audio Controller” built into the ICH7 chipset, or some other components in the audio signal path on the motherboard was crap.

A few months ago, Chris Lee visited, and brought with him a NuForce Icon uDAC. (He also brought a pair of $1500 headphones for which he took much ridicule for being an audiophile). I got the chance to try out his setup at the time, and I admit it did sound great (even with my cheapo $99 headphones).

Remembering all this, I decided to pick up a udac, and give it a shot. As suspected, it worked perfectly. Complete plug and play experience, with no complications, and the crystal clear audio that I wanted. I can hear bass frequencies again. High frequencies are reproduced in a manner that doesn’t sound like tinnitus.

It’s weird. I used to think that the days of add-in sound cards were over with the advent of onboard motherboard sound. For as long as there exist motherboard implementations that sound this bad, I’m thankful that you can still pick up inexpensive quality solutions.

nuforce udac is a post from: codemonkey.org.uk

Related posts:

1. Linux Music Workflow: Switching from Mac OS X to Ubuntu with Kim Cascone Create Digital Music has an interesting post up today by...

So to follow on from my posting stating my position wrt kernel drivers for closed source userspace drivers, lets take a look at the embedded GPU industry and Linux kernel relationship.

What does the embedded industry get from Linux?

They get a kernel which is royalty free, with 1000s of man-years of development experience and resources. Before Linux these vendors either sourced an OS on a royalty basis from some closed-shop, or rolled their own in-house one.

Now people might say "but the embedded GPU industry has to support Windows as well", but take one look at NVIDIA Tegra One and you can see the embedded windows marketplace is less than important, NVIDIA Tegra Two is all about the Linux, whereas they were pretty much only talking to MS on Tegra one.

So Linux is a great boon for this industry, and means they can produce higher quality products for a lower cost (or lower quality products at a lower cost in some cases). So really there are probably two games in town for these embedded vendors, selling into Apple or selling into Linux centric developments, like Android, Meego, Linaro.

So what are they actually hiding in userspace?

The main thing they seem to be hiding is shader compilers and their GPU assembler code, things that convert from GLES into the assembler code for their GPUs. This stuff isn't rocket science but it probably is where most of their speed up and tricks are hidden.

So why do they think it valuable?

I think all 3D IP vendors dream of becoming Imagination Technologies, they need to learn there is already one Imagination Technologies and the only way to easily disrupt their revenue stream and sell into other SOCs is to be disruptive, not just follow the herd. They also probably had to spend a lot of money writing a decent GPU compiler from scratch, whereas most embedded firmware is a lot more trivial, so they probably think they need to directly recoup the costs from this development instead of giving it away. The thing is they are hw vendors, the sw is a sunk cost, opening it would actually make future maintenance easier. HW companies never do well at SW and they would be best to just open it and try and involve some community development around it.

Is the value of this IP more valuable than what the receive from Linux?

This is the crux of my issue with these vendors, they are receiving the Linux kernel for free, but don't want to contribute anything back. They know they can't sell into any where else except Linux driven products, but they insist on keeping their development methodologies from the days of Windows and their own in-house OSes. Those days are gone, but they cling to the idea that for some reason they can produce a better GPU stack on their own than they could in collaboration with other, despite the fact that the kernel that forms the basis for their sales was developed in this fashion. They also all use gcc as the compiler for their CPUs again proving the insanity.

Isn't it up to them what they do?

Totally, but its also up to the Linux community to push back against them. The thing is they'd never have opened any code if it wasn't for the GPL making them at least open the kernel portions, they don't care about freedom or GPL, they care about their bottom line, and doing the least amount of work to remain legal and make money. Now they are getting all this wonderful software for free, Linux phone sales are driving their bottom line, but they still don't want to play the game by the rules of the kernel. They want to have their cake and eat it too. (the cake is a lie). Hence they spend their time creating their own solutions in private, releasing what they have to comply with legalese but never actually allowing people the freedom to use their devices.

So shouldn't we give a little?

The thing is two major vendors have been pushing Imagination Technologies for years to open something, these guys are aiming to sell thousands->millions of devices, we have gotten the ugliest kernel shim in the world in 4 years of trying. All the other vendors are only willing to give that little. I don't personally think any of them want to open this stuff and will hide behind IP excuses for ever.

What will make them change their minds?

a) money and lots of it. If google or olpc can demand open driver commitments (in contracts, not handwaving agreements) then I suspect these vendors will quickly realise the value of their IP is dwarved by the value of sales. This probably means a major chance for one of the vendors to control a lot of the space in the Linux world.

b) disruptive vendor, one vendor realises before the others that opening their IP will lead to more sales than keeping it closed and also lead to the chance of more people optimising their technology and leveraging other work in the industry.

So are you saying they should drop all their in-house developed solutions?

No I'm saying that the driver for their hardware is a single entity, and if the whole entity isn't open, then none of it is truly open. So if they don't want to release an open userspace, then they don't get to merge their open kernel bits to support the closed userspace. We have to keep the maintenance burden on them, so it keeps costing them money to track newer kernels, and they don't get community support from other vendors who have committed to doing things right.

So why should they re-write drivers?

This happens in Linux the whole time, with nearly every new technology. Wireless, RAID, SATA for example, all have had vendors trying to push complete stacks of their own writing, you'll notice over time the drivers that are actually written to the current stacks work best, an the crazy vendors drivers are often horror shows.

What would be nice to happen?

It would be great if there was a hero with time/funding and involvement in the ARM GPU community to take over being maintainer of these solutions, from kernel all the way to userspace. Vendor driver writers could ask this person for advice, and they could have some sort of working group where they develop a stack based around current Linux technologies, like GEM/TTM/DRI2/Mesa/Gallium3D. If you take a look at the mesa stack lately, there has been a lot of work on making it work as an EGL/GLES stack as well as a classic GL stack. Then vendors would supply open drivers compliant with this stack, and just sell lots of chips.

What would be most likely negative solution?

We get what we have now, they maintain the 5-6 GPU stacks in their own world, and never talk to each other, and it costs them more and more money going forward to maintain. Some hero reverse engineers one or two of the GPU architecture, maybe some hero writes a open driver stack from docs under NDA or with open docs.

I may update this post as I have more thoughts ;-)

[I posted this to lkml earlier - discussion should happen there not in comments here, but its nice to have somewhere easy to point people at].

Now this is just my opinion as maintainer of the drm, and doesn't
reflect anyone or any official policy, I've also no idea if Linus
agrees or not.

We are going to start to see a number of companies in the embedded
space submitting 3D drivers for mobile devices to the kernel. I'd like
to clarify my position once so they don't all come asking the same
questions.

If you aren't going to create an open userspace driver (either MIT or
LGPL) then don't waste time submitting a kernel driver to me.

My reasons are as follows, the thing is you can probably excuse some
of these on a point by point basis, but you need to justify why closed
userspace on all points.

a) licensing, Alan Cox pointed this out before, if you wrote a GPL
kernel driver, then wrote a closed userspace on top, you open up a
while world of derived work issues. Can the userspace operate on a
non-GPL kernel without major modifications etc. This is a can of worms
I'd rather not enter into, and there are a few workarounds.

b) verifying the sanity of the userspace API.
1. Security: GPUs can do a lot of damage if left at home alone, since
mostly you are submitting command streams unverified into the GPU and
won't tell us what they mean, there is little way we can work out if
the GPU is going to over-write my passwd file to get 5 fps more in
quake. Now newer GPUs have at least started having MMUs, but again
we've no idea if that is the only way they work without docs or a lot
of trust.

2. General API suitability and versioning. How do we check that API is
sane wrt to userspace, if we can't verify the userspace. What happens
if the API has lots of 32/64 compat issues or things like that, and
when we fix them the binary userspace breaks? How do we know, how do
we test etc. What happens if a security issue forces us to break the
userspace API? how do we fix the userspace driver and test to confirm?

c) supplying docs in lieu of an open userspace
If you were to fully document the GPU so we could verify the
security/api aspects it leaves us in the position of writing our own
driver. Now writing that driver on top of the current kernel driver
would probably limit any innovation, and most people would want to
write a new kernel driver from scratch. Now we end up with two drivers
fighting, how do we pick which one to load at boot? can we ever do a
generic distro kernel for that device (assuming ARM ever solves that
issue).

I've also noticed a trend to just reinvent the whole wheel instead of
writing a drm/kms driver and having that as the API, again maintainer
nightmares are made of this.

d) you are placing the maintenance burden in the wrong place

So you've upstreamed the kernel bits, kept the good userspace bits to
yourselfs, are stroking them on your lap like some sort of Dr Evil,
now why should the upstream kernel maintainers take the burden when
you won't actually give them the stuff to really make their hardware
work? This goes for nvidia type situations as well, the whole point is
to place the maintainer burden at the feet of the people causing the
problems in an effort to make them change. Allowing even an hour of
that burden to be transferred upstream, means more profit for them,
but nothing in return for us.

I’ve been following the recent news story about the russian spy ring that was busted in the US. In particular, I found this blog has some fascinating info on how they were allegedly operating. The bit about a truck pulling up with an ad-hoc wireless network for the spy to connect to intrigued me. It seems like an obvious thing to do reading about it, but it made me realize, I don’t think I’ve ever actually used ad-hoc networking (for spy related activities or otherwise).

Russian spies. Ad-hoc networks. is a post from: codemonkey.org.uk

No related posts.

A hilarious article at LWN reminded me about the value of not being a sore loser. I was very fortunate to receive my own lesson very early on (in 1.3 or early 2.0 days IIRC), when DaveM rejected my console code in favor of Geert's. I liked that console because it was capable of rendering effectively the characters of width other than 8 pixels. It may have been a sizeable corpus of work for me, but it was back when Linux was a bubbling soup of fun, and not important enough for me go on blowiating at conferences in front of the gullible. So we closed the book and went on hacking something even better (ok, in my case it was floppy.c, but you know what I mean).

P.S. For the love of god, read Rusty Russel's Mortal Kombat Model of Software Development (link).

Some Third-Party Thoughts

A friend summarized Bilski this way: “Shorter #Bilski: Federal Circuit, your rule was too straightforward and didn’t add enough uncertainty to an already volatile field.”

I don’t think that was actually the court’s intent, but certainly that will be the short-term outcome. Long-term the court and the PTO will have to find new rules. Patently-o has some thoughts on how that process might play out, and the PTO has issued the following guidance to patent examiners on the topic. The PTO memo, while preliminary, is a great simple summary of the ruling, and contains the following critical passage:

If a claimed method does not meet the machine-or-transformation test, the examiner should reject the claim under section 101 unless there is a clear indication that the method is not directed to an abstract idea.

In other words, the PTO has reverted to the pre-business-methods ‘machine-or-transformation’ test as a default, with the burden of proof shifted to the patent filer to show a ‘clear indication’ that their non-machine/non-transformation is not an ‘abstract idea.’ It will be interesting to see in coming months what the PTO accepts as a ‘clear indication’; I would expect that this won’t be a high bar to clear, but it will probably cut out some of the most egregious applications.

For an optimistic take on the whole thing, check out Rob Tiller’s piece at opensource.com.

Comments on the Concurrences

Yesterday’s train ride focused on the majority opinion. However, as I noted then, the voting patterns here are complex; complex enough that there is some important law to be found in the two concurrences. The patently-o post I linked above makes a particularly astute observation in this regard. So today’s train ride I’ll try to read and share some thoughts on the concurrences, particularly the ‘swing’ concurrence from Breyer and Scalia.

The first thing to note is that the Breyer/Scalia concurrence opens with a strong support of Stevens’ opinion that business method patents are not patentable, but that this part is… only signed by Breyer. So it does not tell us much. The rest of it focuses on four (really three) points which Breyer and Scalia feel the entire court agrees on. If you read only one part of the opinion, read this part- it is short, sweet, and to the point, and because at least five (possibly nine) members of the court agree here, it will likely be the jumping off point for the next round of patentability litigation. These points are:

1. There are many things which are unpatentable. This seems uncontroversial (the court was quite explicit about it in 1989′s Bonito Boats case), but after the Federal Circuit’s expansion of patentability through the 80s and 90s, it was perhaps not as clear as it should have been. This concurrence makes it very clear (once again) that there is a line, even as it simultaneously announces that no one knows where the line is. It could also be interpreted as a subtle hint to the Federal Circuit that they should set to finding that line. (Gottschalk v. Benson, which held that algorithms are unpatentable, is cited approvingly here; as I mentioned yesterday, Gottschalk and Flook may have been given some second wind by Bilski; possibly the best thing that anti-software patent crusaders can salvage from this.)
2. Transformation of a thing to a different state is a “very good clue” (point two), but not the only clue (point three), as to whether or not non-machine things are patentable. The Federal Circuit’s Bilski ruling had essentially declared this ‘machine or transformation’ test to be the only test, which was what made business methods unpatentable under that ruling. Again, Flook is cited approvingly (when saying that it is a strong test) but unfortunately Gottschalk is cited to show that it is not the only test- which is exactly the loophole that State Street (the case that allowed business methods) drove through.
3. The ‘useful, concrete, and tangible result’ test that the Federal Circuit put forth in State Street- i.e., the case that allowed business patents- is not a good test, sometimes producing patents that range from ‘the somewhat ridiculous to the truly absurd.’ In other words, something can be ‘useful, concrete, and tangible’ but still not be patentable. This last point was highlighted by Patently-O yesterday as being fairly important.

If you’d told anti-software patent/anti-business-method patent folks on Sunday that the court’s Monday ruling would have five justices (or maybe nine) justices agreeing that the ‘useful, concrete, tangible result’ rule was bogus, they’d have been pleased. Of course, they’d have expected the court to enunciate a new, replacement rule- which has not happened. It is that gap which has caused so much consternation, not just for patent critics but also for patent supporters.

It will be up to the Federal Circuit to try and find a new rule, somewhere between ‘machine or transformation’ and ‘useful, concrete, tangible’- and this almost certainly means that we’ll be back at the Supreme Court arguing similar issues within a few years, asking the court to ratify- or reject- the next Federal Circuit attempt.

In trying to figure out what Scalia actually agreed to, I’ve now read sections II.B.2 and II.C.2 (which Scalia did not sign on to) a couple of times. They are, like much of the decision, a little rambly; long on vague assertions about the current state of things (lots of talk about the ‘Information Age’) and not very strong on details or particular policy conclusions. If I had to guess (and I should stress that this is just a guess) Scalia is really reacting to the mechanisms used to reach these vague conclusions, which tend to be very divorced from the actual statutory text that the main body of the decision relies on. So probably not worth reading much into that.

The Stevens concurrence… that will have to wait for another train ride. Suffice to say for now that it is a thorough researching of a difficult question. It is certainly not perfect, but is the kind of dedicated textual and historical reading that many members of the court pay lip service to but do not consistently practice.

Dear intarweb,

I’ve been searching all over for data on what these fancy Dell R815 servers (which can house 4 12-core Opteron CPU’s for a total of 48 cores in 2U) draw in terms of power.

This handy capacity planner from Dell doesn’t have this machine listed yet.

Anyone out there know where I can find this info, or have one of these babies actually running ?

Working in a Security Response Team (SRT) is a pretty demanding job, but if you think it's one of the worst jobs in science then you're probably working for the wrong SRT.

The Red Hat SRT is looking for another member to investigate, triage, and respond to security vulnerabilities in Red Hat Enterprise Linux but also across other products and services. You'll join our diverse and enthusiastic team currently spread across eight different countries.

Sound interesting? See the full job description: Security Response Team Software Engineer. If you are interested please use the online application process.

Although the location is specified as the Czech Republic there is actually no specific restriction on the location of this position, and if you're right for the role you could be located at your nearest local world-wide Red Hat office, or possibly even remote.

It turns out that it's actually really, really easy to set up an l2tp tunnel. You just need to install xl2tpd, configure some address ranges and then add an authentication entry to chap-secrets. It's just that the entire known universe appears to be more interested in using ipsec as well, and that looks worse than setting up Kerberos and I've already done that enough in my life thanks. I don't care about my connection being encrypted (I've got encrypted protocols for that), so this seems to be an entirely reasonable solution.

Searching for information on setting up an L2TP VPN takes me here, where I get to choose between OpenSWAN, KAME and some OpenBSD port. Searching for information on setting up a PPTP VPN takes me here, where I'm told exactly what I need to do.

Given choices, I chose the one that reduced my choices. THERE IS A LESSON HERE.

(Sadly, I'm now going to have to deal with L2TP anyway because something in the intermediate network is dropping GRE)

I found this article interesting. The power management slides could be retitled “what Linux has done in the last three years”. So windows 7 didn’t ship with a dynamic timer tick ? Surprising. Linux isn’t perfect when it comes to power management, but we’re a lot better than we were, and it’s interesting to see Windows now planning on using some of the same innovations.

The ‘fast startup’ slides are interesting too. The ‘logoff & hibernate’ is the only real ‘new’ feature there afaics. It’s interesting to see terms used that have become passe in Linux like ‘cache prefetching’ and ‘parallel startup’.

interesting windows 8 leaked info. is a post from: codemonkey.org.uk

No related posts.

I forgot to mention another central problem in my blog story about file locking on Linux:

Different machines have access to different features of the same file system. Here's an example: let's say you have two machines in your home LAN. You want them to share their $HOME directory, so that you (or your family) can use either machine and have access to all your (or their) data. So you export /home on one machine via NFS and mount it from the other machine.

So far so good. But what happens to file locking now? Programs on the first machine see a fully-featured ext3 or ext4 file system, where all kinds of locking works (even though the API might suck as mentioned in the earlier blog story). But what about the other machine? If you set up lockd properly then POSIX locking will work on both. If you didn't one machine can use POSIX locking properly, the other cannot. And it gets even worse: as mentioned recent NFS implementations on Linux transparently convert client-side BSD locking into POSIX locking on the server side. Now, if the same application uses BSD locking on both the client and the server side from two instances they will end up with two orthogonal locks and although both sides think they have properly acquired a lock (and they actually did) they will overwrite each other's data, because those two locks are independent. (And one wonders why the NFS developers implemented this brokenness nonetheless...).

This basically means that locking cannot be used unless it is verified that everyone accessing a file system can make use of the same file system feature set. If you use file locking on a file system you should do so only if you are sufficiently sure that nobody using a broken or weird NFS implementation might want to access and lock those files as well. And practically that is impossible. Even if fpathconf() was improved so that it could inform the caller whether it can successfully apply a file lock to a file, this would still not give any hint if the same is true for everybody else accessing the file. But that is essential when speaking of advisory (i.e. cooperative) file locking.

And no, this isn't easy to fix. So again, the recommendation: forget about file locking on Linux, it's nothing more than a useless toy.

Also read Jeremy Allison's (Samba) take on POSIX file locking. It's an interesting read.

Some very preliminary thoughts on Bilski, written in the course of one train-ride to work. This does not represent the viewpoint of my employer and should not be taken as legal advice; merely observations on one ruling.

• In the lower court (Federal Circuit) ruling on this case, the Federal Circuit was very aggressive in trying to limit business method patents by applying an old rule very, very broadly. The Supreme Court here reached the same conclusion about the specific patent at issue (holding it not patentable) but chastised the Federal Circuit for their aggressiveness in going from step 1 (invalidate this particular patent) to step 2 (invalidate all business method patents). At the highest level, this is not good for opponents of software patents- this is the most change-averse patent opinion the Supreme Court has issued in recent years, and it will leave the Federal Circuit very reluctant to broadly attack entire classes of patents in the near future. But the court did not completely bar such attempts, and it also strengthened some older anti-software-patent rulings, so it is not a complete loss for opponents of business method and software patents.
• This was a very splintered decision- while every judge agreed in the outcome, no part of the opinion got more than five votes, and many parts got only four. This probably explains why it took so long, and why Stevens was not (as widely anticipated) the author of the majority opinion- one or more judges probably were swinging between the two opinions until very late in the process. The addition of the probably pro-business Judge Kagan to replace the (effectively) pro-technology Judge Stevens could make future cases along these lines more conservative. And the court itself basically admits in their first section that this is hard; saying of the Federal Circuit’s ruling in the case that “Students of patent law would be well advised to study these scholarly opinions.”
• The court punts on the most difficult questions, quite explicitly: “This [Information] Age puts the possibility of innovation in the hands of more people and raises new difficulties for the patent law. With ever more people trying to innovate and thus seeking patent protections for their inventions, the patent law faces a great challenge in striking the balance between protecting inventors and not granting monopolies over procedures that others would discover by independent, creative application of general principles. Nothing in this opinion should be read to take a position on where that balance ought to be struck.” [emphasis mine.] Unfortunately, this buys into the rhetoric that all inventors are patenters, but otherwise makes it explicit that the court is staying out of the deeper policy question to the greatest extent it can.
• Core of the decision is to set up a very conflicting set of tests: business methods can in some circumstances be ‘processes’, which are patentable, but they may also be abstract ideas, which are not patentable. (The lower court had said that business methods are never processes and therefore a court did not need to ask ‘is this an idea?’ before ruling that it was unpatentable.) So future seekers of business method patents (and presumably software patents as well) will have to thread the needle, showing that they are a process (probably not difficult after this ruling) but also that they are not an abstract idea (may be hard, not clear yet.)
• Needless to say, this kind of gap is the kind of thing that sophisticated lawyers love to drive trucks through, and which will continue to create lots of uncertainty for small innovators for whom even the threat of a patent suit is enough to stop innovation.
• When deciding that the patent is an idea, and hence unpatentable, the court has kind things to say about Benson and Flook, two older case which spoke against patenting algorithms but which were then sort of ignored. This may signal to lower courts that they should take these cases more seriously when looking at software and business method patents, which would be a good thing for anyone who is seriously interested in the quality of software patents and not the worst possible outcome for those who believe that all software patents should be banned- these could become potent weapons against some of the most outrageous patents on algorithms.
• At the same time, the court also speaks well of Diehr, another older case. This case has generally been interpreted to stand for the idea that a combination of software with hardware (originally, use of software to control a rubber curing machine) is patentable, but the court here seems to read it more broadly, arguing that Diehr should be interpreted to mean that algorithms combined with any new processes (whether mechanical or otherwise) might still be patentable.
• The court specifically tells the Federal Circuit that the method of restriction it had been using is barred or weakened (not great for those who dislike software patents) but also specifically says that the Court can and should explore new methods of limitation as long as they are consistent with the text of the patent act; seemingly implicitly stating that the pre-Bilski situation (where business method patents ran rampant) was untenable. This suggests to me that we’ll see a period of several years of experimentation in the Federal Circuit, where the Federal Circuit attempts to find new ways to limit business method patents on something other than a case-by-case ‘I know it is an idea when I see it’ rule of thumb.
• The court specifically says that they did not want to create uncertainty for software patents, citing the pro-software-patent amicus briefs, but then goes ahead to create such uncertainty by allowing the Federal Circuit to find new, narrower tests. However, these two sections of the majority holding got only four votes; Scalia did not join this part of the otherwise majority opinion- presumably because it seems to give the Federal Circuit very wide interpretive powers.
• The Stevens opinion, at a glance (remember, brief train ride) would have been much more amenable to the anti-software-patent crowd, but I imagine that it is exactly this quality that made it the minority opinion.

I’m afraid that at the end of this brief train ride, my only firm conclusion can be that the real winners here are patent lawyers- this decision creates no new certainties, only uncertainties, which will encourage patenters to spend more money patenting things, and the rest of us to waste time and energy worrying about the problem- time and energy that should have been spent on innovating. But this is a long, multi-layered ruling, and will require a lot of time for the full implications to be truly understood, so take this one-train-ride blog post with a large grain of salt :) Hopefully more writing tonight/tomorrow.

hey kids it’s a puppet show place coin in slot to make it go

It's amazing how far Linux has come without providing for proper file locking that works and is usable from userspace. A little overview why file locking is still in a very sad state:

To begin with, there's a plethora of APIs, and all of them are awful:

• POSIX File locking as available with fcntl(F_SET_LK): the POSIX locking API is the most portable one and in theory works across NFS. It can do byte-range locking. So much on the good side. On the bad side there's a lot more however: locks are bound to processes, not file descriptors. That means that this logic cannot be used in threaded environments unless combined with a process-local mutex. This is hard to get right, especially in libraries that do not know the environment they are run in, i.e. whether they are used in threaded environments or not. The worst part however is that POSIX locks are automatically released if a process calls close() on any (!) of its open file descriptors for that file. That means that when one part of a program locks a file and another by coincidence accesses it too for a short time, the first part's lock will be broken and it won't be notified about that. Modern software tends to load big frameworks (such as Gtk+ or Qt) into memory as well as arbitrary modules via mechanisms such as NSS, PAM, gvfs, GTK_MODULES, Apache modules, GStreamer modules where one module seldom can control what another module in the same process does or accesses. The effect of this is that POSIX locks are unusable in any non-trivial program where it cannot be ensured that a file that is locked is never accessed by any other part of the process at the same time. Example: a user managing daemon wants to write /etc/passwd and locks the file for that. At the same time in another thread (or from a stack frame further down) something calls getpwuid() which internally accesses /etc/passwd and causes the lock to be released, the first thread (or stack frame) not knowing that. Furthermore should two threads use the locking fcntl()s on the same file they will interfere with each other's locks and reset the locking ranges and flags of each other. On top of that locking cannot be used on any file that is publicly accessible (i.e. has the R bit set for groups/others, i.e. more access bits on than 0600), because that would otherwise effectively give arbitrary users a way to indefinitely block execution of any process (regardless of the UID it is running under) that wants to access and lock the file. This is generally not an acceptable security risk. Finally, while POSIX file locks are supposedly NFS-safe they not always really are as there are still many NFS implementations around where locking is not properly implemented, and NFS tends to be used in heterogenous networks. The biggest problem about this is that there is no way to properly detect whether file locking works on a specific NFS mount (or any mount) or not.
• The other API for POSIX file locks: lockf() is another API for the same mechanism and suffers by the same problems. One wonders why there are two APIs for the same messed up interface.
• BSD locking based on flock(). The semantics of this kind of locking are much nicer than for POSIX locking: locks are bound to file descriptors, not processes. This kind of locking can hence be used safely between threads and can even be inherited across fork() and exec(). Locks are only automatically broken on the close() call for the one file descriptor they were created with (or the last duplicate of it). On the other hand this kind of locking does not offer byte-range locking and suffers by the same security problems as POSIX locking, and works on even less cases on NFS than POSIX locking (i.e. on BSD and Linux < 2.6.12 they were NOPs returning success). And since BSD locking is not as portable as POSIX locking this is sometimes an unsafe choice. Some OSes even find it funny to make flock() and fcntl(F_SET_LK) control the same locks. Linux treats them independently -- except for the cases where it doesn't: on Linux NFS they are transparently converted to POSIX locks, too now. What a chaos!
• Mandatory locking is available too. It's based on the POSIX locking API but not portable in itself. It's dangerous business and should generally be avoided in cleanly written software.
• Traditional lock file based file locking. This is how things where done traditionally, based around known atomicity guarantees of certain basic file system operations. It's a cumbersome thing, and requires polling of the file system to get notifications when a lock is released. Also, On Linux NFS < 2.6.5 it doesn't work properly, since O_EXCL isn't atomic there. And of course the client cannot really know what the server is running, so again this brokeness is not detectable.

The Disappointing Summary

File locking on Linux is just broken. The broken semantics of POSIX locking show that the designers of this API apparently never have tried to actually use it in real software. It smells a lot like an interface that kernel people thought makes sense but in reality doesn't when you try to use it from userspace.

Here's a list of places where you shouldn't use file locking due to the problems shown above: If you want to lock a file in $HOME, forget about it as $HOME might be NFS and locks generally are not reliable there. The same applies to every other file system that might be shared across the network. If the file you want to lock is accessible to more than your own user (i.e. an access mode > 0700), forget about locking, it would allow others to block your application indefinitely. If your program is non-trivial or threaded or uses a framework such as Gtk+ or Qt or any of the module-based APIs such as NSS, PAM, ... forget about about POSIX locking. If you care about portability, don't use file locking.

Or to turn this around, the only case where it is kind of safe to use file locking is in trivial applications where portability is not key and by using BSD locking on a file system where you can rely that it is local and on files inaccessible to others. Of course, that doesn't leave much, except for private files in /tmp for trivial user applications.

Or in one sentence: in its current state Linux file locking is unusable.

And that is a shame.

Update: Check out the follow-up story on this topic.

When programming software that cooperates with software running on behalf of other users, other sessions or other computers it is often necessary to work with unique identifiers. These can be bound to various hardware and software objects as well as lifetimes. Often, when people look for such an ID to use they pick the wrong one because semantics and lifetime or the IDs are not clear. Here's a little incomprehensive list of IDs accessible on Linux and how you should or should not use them.

Hardware IDs

1. /sys/class/dmi/id/product_uuid: The main board product UUID, as set by the board manufacturer and encoded in the BIOS DMI information. It may be used to identify a mainboard and only the mainboard. It changes when the user replaces the main board. Also, often enough BIOS manufacturers write bogus serials into it. In addition, it is x86-specific. Access for unprivileged users is forbidden. Hence it is of little general use.
2. CPUID/EAX=3 CPU serial number: A CPU UUID, as set by the CPU manufacturer and encoded on the CPU chip. It may be used to identify a CPU and only a CPU. It changes when the user replaces the CPU. Also, most modern CPUs don't implement this feature anymore, and older computers tend to disable this option by default, controllable via a BIOS Setup option. In addition, it is x86-specific. Hence this too is of little general use.
3. /sys/class/net/*/address: One or more network MAC addresses, as set by the network adapter manufacturer and encoded on some network card EEPROM. It changes when the user replaces the network card. Since network cards are optional and there may be more than one the availability if this ID is not guaranteed and you might have more than one to choose from. On virtual machines the MAC addresses tend to be random. This too is hence of little general use.
4. /sys/bus/usb/devices/*/serial: Serial numbers of various USB devices, as encoded in the USB device EEPROM. Most devices don't have a serial number set, and if they have it is often bogus. If the user replaces his USB hardware or plugs it into another machine these IDs may change or appear in other machines. This hence too is of little use.

There are various other hardware IDs available, many of which you may discover via the ID_SERIAL udev property of various devices, such hard disks and similar. They all have in common that they are bound to specific (replacable) hardware, not universally available, often filled with bogus data and random in virtualized environments. Or in other words: don't use them, don't rely on them for identification, unless you really know what you are doing and in general they do not guarantee what you might hope they guarantee.

Software IDs

1. /proc/sys/kernel/random/boot_id: A random ID that is regenerated on each boot. As such it can be used to identify the local machine's current boot. It's universally available on any recent Linux kernel. It's a good and safe choice if you need to identify a specific boot on a specific booted kernel.
2. gethostname(), /proc/sys/kernel/hostname: A non-random ID configured by the administrator to identify a machine in the network. Often this is not set at all or is set to some default value such as localhost and not even unique in the local network. In addition it might change during runtime, for example because it changes based on updated DHCP information. As such it is almost entirely useless for anything but presentation to the user. It has very weak semantics and relies on correct configuration by the administrator. Don't use this to identify machines in a distributed environment. It won't work unless centrally administered, which makes it useless in a globalized, mobile world. It has no place in automatically generated filenames that shall be bound to specific hosts. Just don't use it, please. It's really not what many people think it is. gethostname() is standardized in POSIX and hence portable to other Unixes.
3. IP Addresses returned by SIOCGIFCONF or the respective Netlink APIs: These tend to be dynamically assigned and often enough only valid on local networks or even only the local links (i.e. 192.168.x.x style addresses, or even 169.254.x.x/IPv4LL). Unfortunately they hence have little use outside of networking.
4. gethostid(): Returns a supposedly unique 32-bit identifier for the current machine. The semantics of this is not clear. On most machines this simply returns a value based on a local IPv4 address. On others it is administrator controlled via the /etc/hostid file. Since the semantics of this ID are not clear and most often is just a value based on the IP address it is almost always the wrong choice to use. On top of that 32bit are not particularly a lot. On the other hand this is standardized in POSIX and hence portable to other Unixes. It's probably best to ignore this value and if people don't want to ignore it they should probably symlink /etc/hostid to /var/lib/dbus/machine-id or something similar.
5. /var/lib/dbus/machine-id: An ID identifying a specific Linux/Unix installation. It does not change if hardware is replaced. It is not unreliable in virtualized environments. This value has clear semantics and is considered part of the D-Bus API. It is supposedly globally unique and portable to all systems that have D-Bus. On Linux, it is universally available, given that almost all non-embedded and even a fair share of the embedded machines ship D-Bus now. This is the recommended way to identify a machine, possibly with a fallback to the host name to cover systems that still lack D-Bus. If your application links against libdbus, you may access this ID with dbus_get_local_machine_id(), if not you can read it directly from the file system.
6. /proc/self/sessionid: An ID identifying a specific Linux login session. This ID is maintained by the kernel and part of the auditing logic. It is uniquely assigned to each login session during a specific system boot, shared by each process of a session, even across su/sudo and cannot be changed by userspace. Unfortunately some distributions have so far failed to set things up properly for this to work (Hey, you, Ubuntu!), and this ID is always (uint32_t) -1 for them. But there's hope they get this fixed eventually. Nonetheless it is a good choice for a unique session identifier on the local machine and for the current boot. To make this ID globally unique it is best combined with /proc/sys/kernel/random/boot_id.
7. getuid(): An ID identifying a specific Unix/Linux user. This ID is usually automatically assigned when a user is created. It is not unique across machines and may be reassigned to a different user if the original user was deleted. As such it should be used only locally and with the limited validity in time in mind. To make this ID globally unique it is not sufficient to combine it with /var/lib/dbus/machine-id, because the same ID might be used for a different user that is created later with the same UID. Nonetheless this combination is often good enough. It is available on all POSIX systems.
8. ID_FS_UUID: an ID that identifies a specific file system in the udev tree. It is not always clear how these serials are generated but this tends to be available on almost all modern disk file systems. It is not available for NFS mounts or virtual file systems. Nonetheless this is often a good way to identify a file system, and in the case of the root directory even an installation. However due to the weakly defined generation semantics the D-Bus machine ID is generally preferrable.

Generating IDs

Linux offers a kernel interface to generate UUIDs on demand, by reading from /proc/sys/kernel/random/uuid. This is a very simple interface to generate UUIDs. That said, the logic behind UUIDs is unnecessarily complex and often it is a better choice to simply read 16 bytes or so from /dev/urandom.

Summary

And the gist of it all: Use /var/lib/dbus/machine-id! Use /proc/self/sessionid! Use /proc/sys/kernel/random/boot_id! Use getuid()! Use /dev/urandom! And forget about the rest, in particular the host name, or the hardware IDs such as DMI. And keep in mind that you may combine the aforementioned IDs in various ways to get different semantics and validity constraints.

A while back, I took over maintainership of gwibber in Fedora. At the time, gwibber depended on desktopcouch (aka couchdb), but that implementation, well, sucks. couchdb depends on erlang (which causes the dependency chain to get HUGE) and it performs poorly and it eats up a ton of disk.

All in all, a bad idea. This version crashes a lot, and bugzilla is slowly filling with abrt reports about how gwibber either crashes immediately on startup or at some point shortly afterwards.

However, the gwibber upstream decided to make a branch of the code that doesn't use desktopcouch! This branch uses sqlite, and crashes a lot less. Unfortunately, some key functionality doesn't work in this branch, specifically, notifications (as in, pynotify). I've spent most of the day trying to get it working again, and what I have accomplished is this:

When notifications are enabled in preferences (note: you have to restart the app to see the changes), the notification bubbles for new items popup, but they never quite make it to the client display. If you disable notifications, everything works fine.

So, interwebs, I plead for your help. Can you make this work properly, so I can push a gwibber update and make many (okay, some) people happy?

Source RPM is here: http://spot.fedorapeople.org/gwibber-2.30.0.1-10.fc14.src.rpm

I'm sure I'm making some stupid little mistake here, my python skills are poor at best.

See also.

The GNOME Foundation released their conference speaker guidelines today. This is an important step not just in helping speakers know what's acceptable, but also in helping audience members understand in advance what the community is likely to find objectionable and ensure that they can feel comfortable in raising concerns.

Of course, guidelines mean little without enforcement. My original draft of these suggested that event runners be able to stop presentations if they felt they were gratuitously in breach of the guidelines. Opinions on this were fairly strongly split, with several people concerned that this effectively allowed individuals to immediately shut down presentations with little oversight. That's a genuine concern, but it does seem to assume bad faith on the part of conference organisers in a way we've rarely (never?) seen. On the other hand, conferences in our field have endured presentations that have contained offensive material from start to finish. If an offended individual is in a minority then it's not easy for them to potentially challenge the audience by vocally expressing their unhappiness, and even standing up and leaving may be a difficult and obvious act.

But I don't set the behavioural standards of the community, and attempting to enforce standards that people don't agree with isn't going to fly. Some people are likely to feel that even the level of enforcement suggested is an unwelcome intrusion into free discussion of some topics, so I think this is a good compromise that is a great signal for our unwillingness to accept inappropriate presentations. With luck we'll see other communities enact similar guidelines and we can come to a broad consensus that covers the majority of our conferences.

I've had the opportunity to look into the Joojoo tablet recently. It's an interesting device in various ways, ranging from the screen being connected upside down and everything having to be rotated before display, to the ACPI implementation that's so generic it has no support for actually attaching most embedded controller interrupts to ACPI devices and so relies on a hacked kernel that exposes individual interrupts as ACPI events that are parsed in userspace, to the ChangeOrientation binary that's responsible for switching between landscape and portrait modes containing gems like ps aux | grep fgplayer | grep -v grep and containing references to org.freedesktop.PandaSystem, a somewhat gratuitous namespace grab. Hardware-wise it seems to be little more than battery, generic nvidia reference design board and touchscreen with an accelerometer and LED glued to the chipset's GPIO lines. The entire impression is one of an ambitious project not backed up by the level of technical expertise required to get things done properly. Frankly, I think Michael Arrington came out of this rather better than he could have done - behind the reasonably attractive UI, the entire device is pretty much held together by string and a following wind.

Of course, releasing shoddily put together technology isn't generally illegal and from that point of view Fusion Garage aren't any worse than a number of products I've had the misfortune to actually spend money on. But they're distributing Linux (stock Ubuntu with some additional packages and a modified kernel) without any source or an offer to provide source. I emailed them last week and got the following reply:

Dear Sir,

we are still actively making changes to the joojoo software. We will make
the source release available once we feel we are ready to do so and also
having the resources to get this sorted out and organized for publication.
We seek your kind understanding on our position and appreciate your
patience on this. Thank you.

Best Regards
joojoo Support Team

Strong work, Fusion Garage. Hardware and software may not be your strong points, but you're managing copyright infringement with the best of them.

The benefits of Meego's "Upstream first" policy are amply demonstrated by the Meego kernel tree now carrying two separate PowerVR drivers with significant quantities of duplicate code, neither of which is upstream.

Wait. What?

For work, I’m re-reviewing servers and systems with the simple-but-not-easy goal of lowering the basic monthly cost per core. The world of racks, servers, CPU’s and cores is a more complicated place than it was a few years ago, since in a few U’s you can put anything from a bunch of small cheap servers up to monster boards with four CPU sockets and 12 core CPU’s for a total of 48 CPU’s in a 2U space. And a look at a Blade system still makes me drool, although I’m still not sure in what case a Blade really makes sense.

In any case, I tried to do a little comparison (which is hard, because you end up comparing apples and oranges) using Dell’s online configurator.

On the one hand, filling racks with Poweredge R810, 4 x 8 core 1.86 GHz, Intel XeonL7555 machines, gets the price down 26 euro per core per month. Doing the same with Opterons, which surely aren’t as powerful as the Intel ones, I can get a Poweredge R815, 48 cores quad Opteron 2.2 GHz, 6174, for 48 cores total, at 9.53 euro per core per month.

And then I thought a Blade would be an even better deal, but it turns out that it isn’t really. The cost per core, with similar CPU’s, really did come out pretty much the same as the R810 based solution. Probably not that surprising in the end since if you fill a machine with cores, the CPU cost will start dominating. But somehow I thought that Blades would end up being cheaper for maximum core power.

Maybe I’m approaching this the wrong way ? If the main concern is cost per core in a datacenter, how would you go about selecting systems ?

I was hoping to have a confirmation by now on the dates of the summit but we are a bit delayed in securing the rooms. I apologize as I know people need to know the dates in order to plan other events. What I can tell you is we are trying to secure room at the newly built MIT Media Lab which is one of the reasons for the delay. The preference right now is for the November dates with the October dates being requested as a fall back. The decision for that was based on the few people who contacted me with strong reasons why November would be better. This included better timing to go over results for the GNOME 3 marketing campaign and more people being in the Boston area at that time due to the Linux Plumbers Conference. Hopefully I will have more information by next week. It isn’t always easy to get big institutions to move quickly, especially since the rooms are provided gratis, but we have good people on the ground helping us out with this. Thanks for your patience.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

callcatcher results for DEV300_m83 records a pleasingly large drop of -220 unused methods as sd reduces by 198 unused methods, while uui and framework drop to 0.

Prepared some patches to make OOo gtk3 ready, though probably best to hold off integrating into say 3.4 until the new build stuff is in place because for vanilla-land we’ll probably want to support building both gtk2 and gtk3 vclplugs side by side which is a bit hacky in the current gtk3 workspace

Do you want to work on some software that will be used by every Fedora packager?

Do you like hacking in python?

Do you have a thing for git?

Well have I got a project for you!!!

The Dist Git Project is back in action and steaming ahead to try and finish before we branch for Fedora 14. Currently I'm working on fedpkg the software to replace our Make system. I could use some help. If you'd like to help, find me on IRC (Oxf13 on freenode) or email. I don't really like livejournal comments so try to use a different way of finding me.

Happy Hacking!

A bunch of good things happened to me recently, in quick succession. Today was particularly satisfying, so a quick list lest I forget that I am born lucky.

• I spent the past weekend in Amsterdam, Groningen, Midwolda, and Amsterdam, for Sofie and Mariette’s wedding. A great time was had by all, and groups of friends mixed into one for a weekend of celebration. Life can be beautiful sometimes.
• The first night in Amsterdam I went to a milonga all by myself for the first time and finally got round to asking complete strangers to dance. Win.
• The last day in Amsterdam I spent with Africa and Alex, and among other things we had a great Kobe steak that really is worth the extra price – it melts like butter in your mouth.
• Last night out of the blue one of my uncles called because he had heard ‘the news’ and wanted to check in on me and see how I was doing. I’m guessing he was surprised I was doing pretty much fine considering, but it was a good feeling to know someone out there in my family cares enough to call. It made the distance that much shorter for a little while.
• Also last night, I familiarized myself with one of work’s projects that needed a patch which I’d been asking to be made since Thursday because of a customer problem (which ran like a red thread, sadly, throughout the wedding weekend). I spent five hours trying to get a first unit test written and running into that project (there were none before), then ten minutes patching the code and writing the code to show that my patch works. Today, that patch got deployed and attacked with six different use cases, and it all held up. This is on code I’ve never seen before, so win.
• Today, I exchanged a work favour for a home favour with Fernando, and he immediately agreed to come home with me and help me set up the big IKEA closet. On the way we stopped at Angel’s to pick up these double bench chairs I’ve been dreaming about getting ever since he showed them to me:

  We took them home on our heads, and I cleaned them. They need some more cleaning, but I love them already. I got these specifically because someone old and wise recently pointed out to me that Barcelona has individual benches, and she was sad and angry at that little fact. So these twin seat benches are a raised fist against Barcelona’s soltero benches.

• And, as usual, Angel didn’t let us go without at least a full glass of wine, and a bag with a huge chunk of tortillas and some freshly cooked gambas. Thank God for people with a passion for what they do.
• After helping me put the closet together (we made it half way through, this particular IKEA set needs a power drill and a saw to put together!), Fernando took me to the Diseny Hub Barcelona because a good friend of him works there. Turns out they have a MakerBot there, he’s printing parts for a RepRap, and he’s willing to print my parts. So after being sidelined in my attempts to get one in Belgium, it turns out I will now be able to make one just ten minutes from my current living place!

  Also, the place seems awesome, has real industrial 3D printers and etchers and 3D scanners, offers workshops, and it looks like people can actually come in and use things. I have a feeling I’m going to be dropping by there…

It’s a big enough list of things to be cheerful about in a really short time, and I’ve left out some less practical more private things, so summer is looking good so far…

On popular request, here are my (terse) slides from LinuxTag on systemd.

The WIndows 7 installer runs using vesa, in the wrong resolution and aspect ration, and does sub-pixel anti-aliasing anyway?

Thanks to Carlos Garnacho’s recent work with the evdev driver and Gtk+ along with Peter Hutterer’s work on getting  the multitouch situation sorted out inside of X, not to mention everybody else who has contributed to the effort, I was able to get Multitouch working on my Fedora 13 powered Lenovo T410s.

All the following instructions relate to those who have N-Trig multitouch devices. Mileage may vary with other devices. To start playing around with multitouch in Fedora today you will need

• my evdev multitouch RPM packages built from Carlos’ branch
  • Warning: this package obsolete xorg-x11-drv-evdev so you will no longer get updates from the Fedora repo
  • Note: I’ll provide a yum repo for my packages once Koji is up and running again, for now if you don’t have an X86_64 machine you will need to rebuild the source rpm.
• If you have a N-Trig device you will also need to get the kernel Kyle built which has a fixed N-Trig driver (hopefully this will show up in an update soon).
• You will also need Carlos’ xorg.conf snippet. This is again for the
  N-Trig driver but should be easily modifiable for other devices
• To play with multitouch you will need the latest Gtk+ from the xi2-playground branch

I recommend building Gtk in a jhbuild environment or at least don’t install it since it is the unstable 3.0 branch. Once the multitouch stuff has been backported to 2-20 branch I will start providing packages. I take no responsibility for the breakage of anyone’s machine due to replacing such a major system package. Thankfully, if you run inside of jhbuild you can play around all you want without fear of breaking your system. Another option might be to run inside an virtual machine but I am not sure if multitouch events will propagate correctly yet.

If you want to play with some demos you will find them inside the tests/multitouch directory of Gtk. Have fun and ping me with any issues you have. It might be nice if we got this working for Fedora 14. The pieces are certainly falling into place.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

So obviously, blog-wise I fell off the face of the earth for close to two months.

The immediate reason is some personal stuff happening to me that I needed to bounce back from (well, ok, I lied – it’s not stuff, it’s just one tiny little thing.)

As a result I haven’t done much hacking at all, beside a few fruitful morituri hack sessions.

As a consequence, I don’t have much useful to report, but I am going to slowly get back to some hacking. My Lego Mindstorms are already with me here in Barcelona so I am going to get started on that CD ripping robot Any Day Now.

I’ll get more specific about what non-hacking stuff I’ve been up to recently after the fallout of the personal stuff, but for now I’ll just mention I’ve been hugely enjoying getting back to playing basketball over the last year. A while ago Farid taught me a nice layup trick, and yesterday I had Pepe film it:

I haven’t pulled that one off correctly during a game though!

Oh wait, I lied. Yesterday I got a proof of achievement of something hacker-related: my Spanish diploma in Twisted!

I need to buy me a wall to hang that on, it’s just too cool! And the back lists all skills achieved, in Spanish. Check this out:

“El manejo de errores robusto con diferidos”. I’m sure that official had a field day translating deferred into Spanish.

Life! I’m back to eating you, one bite at a time. Make sure you’re ready for me.

It is extremely satisfying when you can see your work turn directly into a working product. I just played with last night’s test version of firefox, and as per roc’s blog post, it indeed contains the video support whose licensing I (and others here) were working on last week. In an ideal world, lawyers should play a very small role in product development, and in this case we were probably involved more than anyone wanted us to be. But that wasn’t to be, so I am proud I helped get it done, and done right, and that all firefox users will benefit from it in the future.

CO2 is not a pollutant – it is plant food. It’s what makes plants grow.

All I can think of is this:

The saddest thing is a laptop firmware that provides a valid embedded controller operation region but which then proceeds to read and write embedded controller registers by banging on ioports itself rather than listening to the operating system.

I’ll be heading to GUADEC this year thanks to the generous support the GNOME Foundation Travel Committee but that won’t be my first stop in my mega marathon travelling month of July.

• I will first be travelling to NY around the 8th for the God Street Wine reunion concerts and will be making a pit stop at the Long Island Linux Users Group to give a dry run of my GUADEC talk entitled “The Future is JavaScript” which will continue with my theme from last year of continuing to meld the GNOME Desktop with the web platform (this year focusing on what JavaScript brings to the table)
• I fly out of JFK Airport on the 17th for Lyon France where I am taking the week long Robert Ash cooking course at Rue du Lac in Macon, Burgundy
• The class ends on the 23rd and my Hotel is booked for the 25th in The Hague so I am not quite sure if I will stay in Lyon or start my way up.  I know I have some GNOME friends living between Lyon and The Hague so I am offering to cook dinner for anyone who will let me crash at their place for a couple of days before GUADEC.
• And then there is the main event – GUADEC.  My talk is on Wednesday the 28th at noon.  It shouldn’t be missed.
• To relax a bit more, save money on airfare and because I love Germany, I am heading to Berlin for a couple of days before flying back to the US

If anyone is going to be in any of the areas I will be in and wants to hang out.  Let me know and I’ll see if I can make time.

[read this post in: ar de es fr it ja ko pt ru zh-CN ]

The upcoming week I'll do two talks at LinuxTag 2010 at the Berlin Fair Grounds. One of them was only added to the schedule today, about systemd. Systemd has never been presented in a public talk before, so make sure to attend this historic moment... ;-). Read about what has been written about systemd so far, so that you can ask the sharpest questions during my presentation.

My second talk might be about stuff a little less reported in the press, but still very interesting, about Surround Sound in Gnome.

See you at LinuxTag!