Tomorrow our Wii is supposed to show up. According to a couple reviews so far, such as this one, Twilight Princess is the best Zelda ever (which of course means it's in the running for best game ever, period).
Often I do some kind of coding project over Thanksgiving vacation, but this year I guess not.
One of my D-Bus wishes is already squared away in the form of a viewer that comes with Qt, hopefully distributions will be shipping with this soon.
I went to a fantastic Dylan concert on Sunday night at Boston University. I've been to quite a few of his concerts over the last 15 years or so, and this was one of the best. If you haven't heard his new album, it's well worth it, even a lot of non-Dylan-fans have been appreciating it. There are a couple more shows left in this tour, one at Amherst and one in New York I think.
The audience was a lot more age-diverse than usual - maybe in part due to the Raconteurs opening and the BU location. There were a lot of parents with their kids, and plenty of college-age people. But the whole crowd stayed for Dylan and seemed into it, even the stuff off the new album. All the Raconteurs stayed too, watching from the side of the stage.
I wasn't looking forward to an arena show, but it turned out our tickets were on the third row (which wasn't apparent from the seating chart) and that Agganis Arena is not very big and has good sound.
A block of songs at the start of the set were nothing but harsh: Señor (Tales of Yankee Power), Honest With Me, Positively 4th Street, and Masters of War. Amy says Jack White was getting all into Masters of War and singing along. (Entire set list.)
I'm kind of sad I missed the previous night, in the same arena; the songs were mostly different and included several of my favorites. But this was a great performance.
Roozbeh, I have no objective way to know if you or Red Hat's lawyers have the correct interpretation of US law and Fedora's EULA language.
However, I'm tempted to take into account that 1) they are lawyers 2) they wrote the EULA in the first place 3) they talk to the FSF and OSI all the time 4) they are pretty much open source licensing experts due to working here and 5) there's no indication of bad faith; there aren't any payments (let alone $348 million in payments) or even any apparent benefits to Red Hat.
In short, why would Red Hat's lawyers be interested in making up a bogus answer for you? They are probably telling you (or Rahul and Jesse) their honest opinion about the law.
You and I might not like the law, but that's a separate issue.
As James posted long ago, the EULA specifically states that the GPL license of each individual component "wins," so I don't see how a GPL violation is possible. The EULA flat-out says that it's superceded by the GPL's requirements, as I read it. (I am not a lawyer.)
Finally, there is no change to the level playing field here, because there aren't any deals or payments or patent rents involved. Anyone has the same choice Red Hat does (or probably doesn't) have to offer a distribution with or without this clause. So if there is any benefit to Red Hat, anyone can copy the benefit, and if there's any detriment, anyone can remedy it and compete on that basis. And anyone can copy or remedy this feature of Fedora without paying anyone or asking anyone, and they can do it today. Maybe Ubuntu or someone already does, in fact, I have no idea.
I'm a moron for posting on this topic, but does this make any sense? Payments are being made but nobody admits there's any reason to make them? (Other than these 348 million reasons.)
Of course, Novell doesn't have to say there are patents. They just let Microsoft offer the customer "protection" "in case your house burns down" and then Novell steps in and says "check it out! We already paid your protection money for you!"
Or I guess their sales message could be: "Customers, for your benefit we have paid money to remove a nonexistent threat. That's $N less we'll be spending to provide value to you." Somehow I doubt it. For this deal to help Novell's sales, they have to (at minimum) leave Microsoft's bogus claims uncontested.
Let's see how one tries to weasel out of the spirit of the GPL:
Q1. How is this agreement compatible with Novell's obligations under Section 7 of the GPL?
Our agreement with Microsoft is focused on our customers, and does not include a patent license or covenant not to sue from Microsoft to Novell (or, for that matter, from Novell to Microsoft). Novell's customers receive a covenant not to sue directly from Microsoft. We have not agreed with Microsoft to any condition that would contradict the conditions of the GPL and we are in full compliance.
Novell's end user customers receive a covenant not to sue directly from Microsoft for their use of Novell products and services, but these activities are outside the scope of the GPL.
Even if the above is true (I am not a lawyer), it's a technicality and an unintended loophole. GPLv3 seems to have new improved text that might help, and I sure hope the FSF will be making it crystal-clear in the GPLv3 final draft.
That would force Novell to fork gcc, glibc, and so forth. Something they would deserve.
As an open source developer, on an emotional level, I feel Novell (the company) should now be treated like a company distributing GPL software without source, or for that matter a company distributing proprietary software without a license. Both are illegal and against the wishes of the software's creators.
I've written countless lines of GPL software and I am against it being distributed under Novell's "protection racket" terms. If the GPLv3 solves this problem I'd love to switch to it, "tivo clause" or not.
Just to be clear on one thing. I'm not against proprietary software on moral grounds. I use a fair bit of it for various reasons, though I'm also a huge open source fan and think open source's practical and social benefits are unquestionable.
If any company wants to write and sell proprietary software, then great for them - open source can compete on the merits. I would also work on proprietary software and be OK with it, though in practice I've never had a job doing so.
This is not a religious argument about open source, it's a matter of respect for a community that works together, and the wishes of creators. If I write something and put it under the GPL, then I want it under the GPL where all of us working on it can use it. I don't want it to be made proprietary, for someone else's benefit, due to some shady deal and legal technicality. Commercial yes (and encouraged), proprietary no.
In Novell's world, if I write something and GPL it, Novell will try to convince customers to buy support from Novell instead of from me (the original author) because of some nebulous, unspecified, almost-certainly-bullshit "IP issues" hinted at by Microsoft and legitimized by Novell for the price of $348 million.
In proper open source, Novell (or anyone) is welcome to take my code and convince customers to buy support from them because they are a big company and I'm just some guy on the Internet. But Novell (or anyone) is not welcome to proprietarize my code. If I wanted them to take my code proprietary I'd choose a BSD license and not the GPL. I want them to compete with me on a level playing field by offering a better value.
I suppose we can't blame Novell's executives. I imagine they needed the money, so asked Microsoft "what would it take for you to give us a few hundred million?" - and then did what Microsoft asked.
The rest of us should be asking why Microsoft asked for what they got. Here's my speculation: Microsoft is much more threatened by open source as a model than they are by the Linux kernel or Novell specifically, and they're very happy to throw a technical bone - especially one that involves Linux running virtualized on Windows - if in their mind it could help "proprietarize" open source software and spread doubt about it.
I'm sure many people will dismiss the above because I work at Red Hat. Fine. But I have to say, this post would be a lot more strongly-worded if I didn't work at Red Hat and didn't have to worry about that perception.
If it isn't obvious, this is a personal opinion and no more. I'm neither a lawyer nor do I have special knowledge.
I'm pretty sure none of the open source developers working at Novell were involved in this decision, and I don't envy them having to live with it. Hopefully there's some way the community can make the Novell execs regret their actions without harming the innocent bystanders.
I spent half the weekend rearranging Mugshot server code to make it easy to add new kinds of "block" (online happenings the site and client app will keep track of).
I'm becoming a huge fan of Java and Eclipse server-side development. I think it gets a bad rap because of certain suckages (EJB 2, JSF, old-style JSPs with inline code, old-style Java without generics or enums). But modern Java is EJB3/Hibernate, JSP expression language and tag files, Java 5, and so forth. At its best it's a very nice setup (though obviously I can come up with some gripes if pressed).
When we started out on Mugshot we made stupid mistakes since we were not Java programmers or even server-side programmers, and if there's one problem with all this Java stuff it's a lack of guidance on overall application structure and which technologies to use.
The more we've figured out what's going on the nicer the codebase gets. Now the problem is going back and fixing all the clueless code we wrote while learning. ;-)
Later this week I want to add a new block type (perhaps one whenever someone posts a new Flickr photoset), and write up a wiki page describing how to do it. This could be a short intro to hacking on the Mugshot server and also of course a guide to adding new block types.
BTW, Google Desktop was just updated to store more of its data and settings online (shared between your computers) instead of on a local disk. Obviously the way of the future and has been for a while now, and open source should be in a unique position to modify all the important apps to take advantage when a server side is available. Tom Tromey is thinking about it, and I'm also encouraged by AbiWord Collaboration.
In part I think there's a largish up-front effort to get some colocated servers and build some of the basics like a user account system. In fact I know there is because for Mugshot we spent a lot of time on this stuff. If it helps, anyone is welcome to modify Mugshot's code and use our colocated machines to work on providing services to the free desktop. If it doesn't help, that's cool too, but still I hope more people will think about hacking in this area.
My simple file sharing hack needs finishing up too (a quick fix is to add a block type for "new file shared," so people know when you post something).
John is threatening to roll the D-Bus low-level API 1.0 tarball in a couple of days. I just looked back in the ChangeLog:
2002-11-21 Havoc Pennington <hp@redhat.com> * Initial module creation
Coming right up on year 4. Now that's what I call a conservative release schedule! The last big API change I believe was:
2005-01-15 Havoc Pennington <hp@redhat.com>
* Land the new message args API and type system.
This patch is huge, but the public API change is not
really large. The set of D-BUS types has changed somewhat,
and the arg "getters" are more geared toward language bindings;
they don't make a copy, etc.
There are also some known issues. See these emails for details
on this huge patch:
lists.freedesktop.org/archives/dbus/2004-December/001836.html
lists.freedesktop.org/archives/dbus/2005-January/001922.html
Software sure does take forever, in this case double-forever. D-Bus has rarely been anyone's full-time job, and there were several stretches with essentially no work happening.
What's the significance of the D-Bus release? Well, the original D-Bus goal was a "system message bus", to support things like HAL. A secondary but hoped-for goal was to replace CORBA and DCOP with a simple desktop-independent IPC system. Both seem to be working out pretty well these days.
A lot of work remains though. Here are some of the major items:
Bindings, bindings, bindings. The low-level libdbus does not need to be growing many new features or much new code at all over the next couple years, but there's still all kinds of room to improve on the high-level bindings as most of them remain pretty immature.
The GLib bindings could be a lot easier to use. The original intent was to have no "IDL" xml file to mess with, but nobody has implemented the C parser (could be based on gtk-doc) or GLib introspection to avoid it. There's AFAIK no roadmap for what should be involved in getting these bindings to 1.0, and I'm sure the bindings could be improved many small ways.
Bindings are essential. The low-level API is both easy to misuse and kind of a pain in the ass.
Performance. I've noticed that people are profiling GTK-on-Cairo well after its release, and so far D-Bus is on the same track, despite some strong hints. Unlike the UI toolkit, I doubt D-Bus speed is very user-perceptible, though I do know D-Bus isn't especially peppy. Nontheless, I'm sure someone is going to benchmark it vs. other IPC systems and post shocking graphs, and to them I say, find the hotspots and send patches already.
Windows port. There's some work on the Windows port, and I'm not sure of the status in detail, but I think it could be done in a week or two of effort. Would like to see someone hammer this out for 1.2.
System activation. David Zeuthen's work to enable the systemwide bus to start daemons will likely land in a "1.2" sort of release, ideally within a few months.
Tutorial documentation. The low-level libdbus has almost excruciatingly thorough API documentation if I do say so myself, but nobody should really be using that API anyway and API docs are bad for getting started. "Getting started" documentation is needed for each high-level binding, with examples.
D-Bus Viewer. KDE had a neat tool for DCOP that let you browse all the running apps and introspect their methods. This is really useful, and a D-Bus equivalent is needed. There was a start on one in CVS at one point, but it hadn't gotten very far.
Integration into the GTK+/GNOME API. Lots of things in GNOME can be cleaned up and made simpler with D-Bus available. For example, the bat**** insane lifecycle-management/activation code in libgconf/gconfd-2 can be nuked. (please save us - it's so simple and things are so broken.)
For applications that want to be single instance and can just rely on D-Bus, there's no need to wait for a fancy "unique application" library - just try to own your app's D-Bus name on startup, and exit anytime you lose the name or fail to become its owner. Presto, single-instance. (This is what bus names were designed for, btw.)
Alternative transports and X forwarding. DBUS_SESSION_BUS_ADDRESS should be ssh-forwarded and tunneled, just like DISPLAY. Until this is done, remote applications won't really work right. And the sooner this is done, the sooner a new-enough version of ssh will get rolled out to distributions.
A somewhat hackier approach would be to implement a libdbus transport that worked over an X connection, probably using X properties to transfer messages.
Please, report API bugs. Especially in the bindings, but it's still possible to evolve libdbus via deprecation or extension as well. Several bad bugs were almost in libdbus 1.0 because people just assumed they were by design (diabolical design?) and worked around them instead of saying something or patching the library.
A final fun fact about libdbus 1.0:
$ nm -D dbus/.libs/libdbus-1.so | grep ' T ' | wc -l 200