A nice article in the New York Times on software patents. I hadn't seen the comparison to pharmaceutical companies before: software companies are getting one patent per $500,000 in R&D; costs, while pharmaceutical companies are getting one patent per several hundred million in R&D; costs. Seems like a good illustration of the problem that would make sense even to a nontechnical audience.
I did some dbus optimization a while back, but it got lost when we rewrote all the marshaling code to support fully recursive types. Unfortunately, the code now has a distributed bloat problem where the performance issue comes from too many "layers" - to speed this up I think we need someone to come in with an ugly stick and do more hard-coding and special-casing and general de-genericization/de-abstraction.
Usually this kind of speed-over-sanity is one big Bad Idea in desktop programming (though the kernel and libc are full of it) but maybe dbus is an exception if we want it to stack up well vs. other binary-protocol IPC systems. Then again, if we look at the desktop as a whole dbus is unlikely to be a bottleneck so "who cares" could be the right answer. We just have to ignore whining from anyone running dbus vs. other-IPC-thingy benchmarks.
On the plus side, the dbus TODO for 1.0 is looking awfully short.
Charlie and the Chocolate Factory: enjoyed much more than expected, keeps the spirit of Dahl books. Christopher Lee scenes were awesome.
The Island: not recommended. Good cast, potentially the original script was good, but the whole thing got the Michael Bay treatment. Not sure how they got most of the cast to do it (Scarlett claims to have signed up before learning of the Michael Bay aspect).
Harry Potter 6: very harsh cliffhanger. You might want to wait for 7 to come out, then read the last two together.
Tour de France: not as exciting as some years, but always good.
I predict that Stealth will be the worst blockbuster of the summer, based on the trailers. Looks on par with The Core.
Thought I'd pile on and help announce an experimental new project... even though I've had nothing to do with designing or building it. ☠ has been in GNOME CVS for a while now, but few have seen it in action.
Besides testing the Unicode support of every program that tries to display its name, the ☠ project is an experiment in combining chat with building a persistent document, plus random cool features such as a web-based shared whiteboard. FAQ links to Manifesto. (Those with broken Unicode or a need to use verbal communication can call the project Yarrr, btw.)
For the nerds in the audience, ☠ combines Java, PHP/MediaWiki, and AJAX in order to offend as many developers as possible in a single go.
Red Hat people involved in building this include Jonathan Blandford, Bryan Clark, Diana Fong, Marco Gritti, Alex Larsson, David Malcolm, Seth Nickell, and Colin Walters. (Hopefully I didn't miss someone.)
Polish, usability engineering, bug-freeness, and all that good stuff are still to come; as I understand it the current version is intended to discover any interesting interaction properties that improve on existing stuff such as chat, wiki, or email. No point dotting the i's until we know which aspects are worthwhile.
The shiny new ☠ server is a special MediaWiki instance that supports a <yarrr></yarrr> tag. This tag inserts a ☠ discussion into the page. We seem to have a wiki-free edition as well, if you only want to see the discussion aspect or marvel at the wrongness of the JavaScript hacks. Also, an example meeting conducted by the marketing team.
Part of the idea here is that it could eventually be a desktop feature or application; but as the FAQ says, priority one was to iteratively figure out what the software should be like. An in-flux desktop application would require everyone to keep downloading and installing the same latest version. So we started with the web.
If you think this looks exciting, join the mailing list, or grab the code.
My plan was to stay just a couple of nights in Ottawa for desktopcon, skipping the kernel stuff later in the week. But my flight was just canceled and they didn't have anything until tomorrow, which would mean missing almost the whole thing, since I was already leaving a bit early. So I just asked for a refund.
At the moment I'm stuck in Manchester airport until I can get a ride home.
Federico, the gconf issues there are fairly well-known; I posted a mail a while back with some analysis but Google isn't finding it again.
The big win is not complicated optimizations, it's just to avoid loading and parsing a ton of documentation translations that will never be used. If you do that then gconfd can continue to be horribly inefficient but still be far faster since there's far less data. Cutting down the amount of data is the order-of-magnitude win.
One approach is an mmap cache like the icon cache.
In the long term, a better approach is to just avoid having the schemas installed and loaded in the way they are now, as described here and also here.
Anyway, it just lacks someone doing the work.
I was expecting a summer blockbuster action movie, but War of the Worlds was pretty much a horror film in the tradition of Alien.
Software has a state where bugfixing is just as likely to make it worse as it is to make it better. Metacity is kind of in this stage; most (but not all) of the open bugs really are not very important, relative to other aspects of the desktop that people could work on. And a more interesting observation, it's not clear that fixing the last 1% ever gets you to 100%. Why is this?
In short, there are some serious diminishing returns on bugfixing after a certain point.
I think one of the important things software developers only learn through experience (you can't learn it from books) is how to tell the difference between a bug that should be fixed and a bug that should be left alone.
Most open source developers just leave these "would be nice to fix someday, I guess" bugs open in the bugtracker forever rather than argue with the bug reporter, even though an experienced maintainer knows they aren't going to get fixed and aren't worth fixing.
I'm not trying to trivialize the worthwhile bugs, and there certainly are a few left in metacity (which we would love help with).
Also, I think major changes to something like metacity remain interesting, for example adding a compositing manager. Or a full rewrite of some kind, if it had some good goals. Directed major changes remain valuable even when random bugfix churn is a negative.
The "it will never be finished, ever" aspect of software can be very depressing. Sometimes I think the videogames industry would be cool for this reason, especially writing console games. Because you ship the game, it's burned to the CD, and that's it. The code is set in stone. Much more like other creative endeavors such as painting or carpentry. None of this "updates" and "next version" nonsense.
Aha! yum-utils to the rescue, now I can do all sorts of silly things. Thanks Seth.
Of course, gtk2 downgrade didn't fix Evolution. Which random thing to try downgrading next... maybe I should just debug the thing ;-)
Is there any way to convince yum to downgrade a package? Especially relevant since evolution is all busted in rawhide. To downgrade Evolution I did an rpm -e followed by a yum install of a specific Evolution version, but that didn't help and so I'm guessing I need to downgrade gtk2; rpm -e gtk2 is kind of a bad idea though, so I need the equivalent of "rpm -U --oldpackage" only with yum. Yes, I am too lazy to go download stuff manually and then use rpm rather than yum. If yum could just download a package without installing it, that would be almost as good as a --oldpackage sort of option. "yum download gtk2-2.6.7-4" would do it. Of course, maybe the problem isn't gtk2 either, who knows.
Stephan Binner mentions the KDE for Red Hat project and complains about the current official Fedora Project packages. I would like to see the KDE for Red Hat project be in charge of the official packages to be honest. I think it's been discussed before and I don't really know what the status is or conclusions were, but my personal .02 is that there's no reason in principle why KDE can't directly control the Fedora packaging. The only requirements would be to follow the same maintenance guidelines as other Fedora packages in terms of spec files, build, testing, etc. and I guess not break any global stuff (such as upgrades or shared files). We have moved away from Bluecurve in the Fedora Project due to a general "closer to upstream" guideline (though we aren't religious about that guideline if we can get a nicer system by bending it a bit, and as always we do a certain amount of backporting fixes rather than wholesale upgrade during freezes).
I think there is a complexity here which is that right now externally-owned packages have to be hosted via the Extras infrastructure rather than the inside-Red-Hat Core infrastructure, but the roadmap is for Extras and Core to use the same infrastructure eventually, and both infrastructures work fine.
I'm not unilaterally committing to anything, other Fedora people and Red Hat people would have to weigh in, but this is my view.
