According to Comcast On Demand, "Elektra is an assassin always on a mission to kill, but when forced to decide between good and evil she finds herself fighting mystical and relentless ninja assassins."
D-BUS seems to be getting adopted by third parties more quickly than by the original intended audience. First Skype and now Maemo. Maemo looks like a really interesting project, I clearly need the Nokia thingy to run it on.
Pete, it's not just for ads. Even nonprofit or ad-free sites will have either whitespace or graphics; random article from a nonprofit organization, McSweeney, two fast examples. It's just more legible.
Anyhow, I really like the planet gnome design.
Dom, you're making a screen-real-estate-based usability/design argument. If I ever wrote down a Havoc's Guide to Software it would include "design arguments based on real estate are totally weak." In this specific case, text filled across a whole screen or page is hard to read. That's why newspapers have columns and most online magazines restrict width to much less than the whole browser. The standard word processor template I use has huge margins for the same reason.
Of course, Nickell has a more thorough design rationale and I'm lowering the level of the conversation ;-)
Slashdot comments are even dumber than usual when discussing coordinated security updates. I guess I'd expect that if they know nothing else, at least many Slashdot posters work in IT and understand security patches!
For those who don't know: in most cases, a not-yet-public security flaw has a public announcement date coordinated among all the major Linux distributions, BSDs, and the upstream project in question. That's because most users can't use tarballs or project-built binaries, they need packages from their vendor. By coordinating the announcement date, everyone can patch their systems at the same moment that the script kiddies can start to use the exploit. For an already-public flaw, of course, there's no value in a coordinated release date and everyone scrambles to ship the fix ASAP.
The lag between announce and patch can be large if the announce date isn't coordinated, because so many versions of so many operating systems need to be patched. Often the patch has to be backported to multiple versions of a package, which can be complicated. Then the fix has to be built (for something like Mozilla or OpenOffice.org, this is not fast), tested, documented, and pushed out for download.
If you're an open source project maintainer, you need to understand what to do when you learn of a security flaw. The simplest thing is to quietly notify any of the major Linux or BSD distributions and let them take it from there. For example here is how to report to Red Hat, here is how to report to Debian, here is FreeBSD.
Once you notify someone, wait to hear back. The upstream maintainer would normally announce the vulnerability and commit patches to CVS at the same coordinated time that vendors post packages. If you patch in CVS before anyone is ready with packages, your users are vulnerable during the gap (and generally unhappy about it). Worse, by committing a patch to CVS you're doing something that a black hat could notice, but most sysadmins will not notice.
Alex Graveley links to subtext, I think this thing looks awesome. A perfect place to experiment with it would be something like GNOME panel applets, Apple Dashboard, or Second Life objects. All these are limited programming domains where making programming easy would be high-value. I guess any sort of plugin/extension system might be a good place to experiment, but graphical ones seem more exciting. Seth points out that it's similar or at least complementary to some Smalltalk ideas.
Better judgment > /dev/null
Sorry to see this come up again, but I guess it will be a hot topic at GUADEC, so I may as well lay out the current status as I see it. (Summary: not much has changed...)
It won't show on Planet GNOME, so here is Mark Wielaard following up on Christian's post. Also earlier he posted a chart of Classpath development progress. More people should read Planet Classpath as I've hinted a couple times in the past.
Responding to Christian, he says "Java's mindshare in the wider GNOME community is close to non-existant today and there aren't really anything on the horizon that could plausibly alter that." This is potentially true. I said as much in my talk at the open source Java summit, where I was trying to clue in Sun (among other goals). At the same time, I think GNOME has it wrong (or at least is leaving those of us at Red Hat unable to contribute to GNOME), so I find the situation depressing.
Let's talk about technology first.
Graydon's analysis pretty much shows what a non-technical-issue this Java vs. C# thing is. And as Jeffrey Morgan says it would be nice to preserve choice for app developers.
The velocity of open source Java development, and sheer quantity of open source libraries and tools for Java seem to be discounted.
Just one thing I've been very impressed with is the Eclipse plugin system: this is in no way tied to Eclipse or SWT, and it is just a better way to think about extensibility than our historical fixation on "component systems." There's a very similar open standard called OSGi that I think is pretty neat, with at least two open source implementations (Oscar and Knopflerfish). I should do a separate blog post on why these are interesting sometime.
Screw its plugin system: when I used Eclipse itself to write Java for a few days, I was impressed with the increase in productivity. Most of the wins were because of the IDE, not because of the language. Like Emacs, Eclipse has awful usability engineering, but it has great features and functionality that save time once you discover them. If you've never used a serious IDE with a language like Java or C#, you should try it. The most important language features are the ones that enable a great IDE.
Another place to look at the size of the open source Java community is JPackage; the package list is down the side. And those are just the packages someone cared enough about to maintain in RPM format.
Or let's look at Apache's Java community, where Lucene was born - and then ported to C# to become the Beagle engine.
Obviously C# has lots of software out there as well, and it has more GTK+ software due to the focused effort to create same. I'm not trying to exhaustively belabor the Java vs. C# technical comparison but I am trying to point out that Java has a hell of a lot going for it including open source developer tools and libraries and huge momentum (largely open source) on the server side. Java 5 has some cute language features, too, and Tromey has shown how to make native code bindings easy.
Enough on technology. On the crux of the issue, what I wish GNOME would understand: Red Hat not shipping Mono is currently a can't rather than a won't. Making it worse, we are not able to spell out all the facts on why we can't. In fact, none of the Red Hat engineers (including myself) knows all the facts (and we couldn't share them in public if we did). We continue to try to get this issue resolved and there are serious efforts in progress, but, well, they have been in progress for quite a while. At some points it felt close to resolution, at the moment it doesn't really, at least not to me.
Please don't ask for more details here. I can't give them. You can take this as evidence that I'm lying, and that's fine, but I can't do anything about it.
I believe we have legitimate and non-evil reasons why we can't ship Mono. And I think open source Java looks plausible and a lot nicer than C; Java and Classpath will even run on Mono, and if C# becomes more viable later, experiments such as Graydon's or the Lucene port show that it isn't hard to do a Java to C# conversion. And guess what, we need open source Java in the desktop anyhow for OpenOffice.org and the browser plugin at minimum.
I don't know what people expect Red Hat GNOME developers to do. We can't roll over and say "OK, we'll start hacking in C#, even though we don't see a path to shipping any of the stuff we're hacking on" - does anyone seriously expect that?
If people don't believe us, then the right action is for GNOME to just require Mono and let Red Hat sort it out. Let's not blame a faceless company here for the sorting out. At the moment Red Hat's desktop strategy is largely set by me and other community members you know. I can tell you what I would advocate faced with Mono as a GNOME requirement: initially try to reimplement or live without the Mono bits, maybe using language-translation hacks to port stuff to Java; while finding a non-GNOME or forked-GNOME path to get out of this losing approach in the long term. It's ugly but true. We would probably stall as long as possible, hoping to find a way to ship Mono or that GNOME would change its mind, but that's all we could do. I can't think of a way we could justify hacking on software we can't ship.
If anyone has a better suggestion then let me know what it is.
Here's what I ask. Give the Java and Eclipse talks at GUADEC a chance. Try out some of the Java technologies I mentioned earlier in this post. Try Java 5. See if this is really such a clear-cut technical issue.
Eventually though GNOME should just decide what to do and proceed. If people think we are lying, or that something will happen to let us ship Mono, or simply think that Mono is more valuable than Red Hat's contributions, then so be it. These are decisions that have to be made. GNOME got stuck on the "Bonobo war" for a while, and the "Mono war" today, both at their heart ridiculous distractions from the real point, which is implementing a desktop environment.
Mikael, I would have said exactly the opposite. You can build all the platform you want and nobody is going to care. What they care about is apps. Good apps will drag along the worst platform imaginable. In fact, the major apps mostly have lame custom cross-platform toolkits as their platform, and nobody cares. GTK+ blows many of these toolkits out of the water but it does not matter.
My suggestion for giving GNOME a jolt would be to win with the apps. Make Evolution really fantastic, instead of limping-along-in-danger-of-being-Thunderbirded. Support great apps like Epiphany and Evince. Get GNOME Office in the game so it has a chance in hell. Invent great new kinds of app. Use a distinctive aspect of the GNOME platform (it's willing to diverge from Windows) to do interesting things in the apps and shared among apps. Undiplomatically: the last thing I'd do is start the my-platform-is-so-cool technowanking. It's all about what you can do for end users.
GNOME is a perfectly good desktop environment and I think is going along fine as such. But desktop environments aren't that exciting. Apps are exciting. Heck, read the metacity README. It's all about the virtues of boring.
Note, by "apps" I really mean "useful end-user functionality" and the desktop environment could include that functionality (effectively becoming a single integrated app). But our current structure tends to put everything useful in standalone apps.
I'm not crying "the sky is falling" here since I think good apps exist for Linux, they just aren't being built within GNOME. What I'm saying is that if we want GNOME to be where the excitement is, then it's about apps.
If you don't build the apps you can't really change anything interesting about the platform. You can only write a platform that can be a backend for XUL, VCL, SWT, WINE, etc. since the apps use those APIs.
The value of centering the excitement around GNOME would be to create a more integrated, exciting, innovative/nimble app suite. The downside of course is that it's so much more work than just using the cross-platform apps.
I have many more thoughts here, I guess, but it gets hard for me to talk without getting Slashdotted and causing confusion/misunderstanding among the vast majority of readers who lack context. I'm reluctant to post even this much... I'm sure I already have some choice quotable that everyone will misunderstand.