As most of you know Zeeshan has been hacking on creating a set of upnp tools for Linux similar to those Intel makes available for Windows users. I decided to give them a test run on Fedora to make sure there where no distro differences screwing up the build, but everything went smoothly apart from some pkconfig weirdness which I think is a Fedora bug. Anyway below is a screenshot of the upnp tools control point application viewing Coherence.
I think these set of tools will be of great use as things such as DLNA becomes more and more prevalent. People using the GMAE stack for instance will probably be very happy to have a native testing suite available. A big thanks to Zeeshan for the effort so far!
Update: I should have mentioned that the upnp library that the upnp control point application is using, gupnp, is done by Jorn Baayen at Opened Hand. So a big thanks also to Jorn for this.
Update 2: and for those who don’t know the Intel upnp tools and what they do take a look at this page.
I have known for some time that there was a work being done on improving the sound handling in GNOME, but I somehow missed out on it until today. Decided to test a USB headset and figured I would need to edit a GStreamer pipeline to get Banshee to output to this USB device. Then someone pointed out that there is GNOME sound properties now which I then used and noticed a ‘USB audio’ option having popped up. And it just worked.
So to the authors of gnome sound properties a big thank you from a happy user!
Read Miguel’s post about the patent suit between Sun and NetApp. I guess both parties are carefully avoiding stating something which is outright lies so instead they tiptoe around the issue a bit.
Here is my guess of how things went down:
Step 1: NetApps first approached StorageTek behind the cover of a third party intermediary seeking to purchase STK patents. This is what Jonathan mentions in his blog and nothing in the blog entry of the NetApp CEO contradicts this, it just omits it.
Step 2: Sun when being asked about the patent purchase turns around and says ‘sorry not for sale, but you can license.’ Sun having talked to the third party mentioned they make this offer directly to NetApp. So As the NetApp’s CEO says, Sun contacted them with a list of patent (the same list NetApp had asked to purchase) and said they where available for licensing.
Step 3: NetApp realize that their patent purchase request has backfired a bit and starts looking for a way out. Their first solution is to look through their own patent portfolio probably hoping to find something to cross license with Sun. (Or if they got stupid with greed, they tried to both get Sun to agree that they where not infringing on Sun’s patents and at the same time demand patent fee payment for their own).
Step 4: Licensing lawyers/people at Sun are faced with what is more than a ‘standard’ patent licensing agreement and for some reason tries to just drop it instead of dealing with it. (A scarily common event in many big companies).
Step 5: NetApp either due to worry about future legal action from Sun or due to greed decide that a request for a summary judgement about the validity of the Sun patents (which they originally wanted to buy) and a countersuit would be the best way forward.
Step 6: NetApp CEO presents his view in blog post in the hope to not get to much bad reactions from the open source/free software community.
Step 7: Sun CEO replies in his own blog.
All the above is just guesswork by me of course for what happened, but these set of events would not contradict either of the two versions of what happened.
My guess is that NetApp just got greedy in this process and starting behaving stupidly. Probably in the end they make the same fatal mistake that SCO did, they assumed the cost of a lawsuit is what you pay your lawyers. Instead the real cost of a lawsuit will often be the collateral damage it will inflict on your business. NetApp might end up experiencing the same thing that SCO did (although on a smaller scale), that suddenly their customer base wants to avoid doing business with them as they are seen as a patent troll and a enemy of open source software.
I picked up a copy of the International Herald Tribune today (which is sorta the internationally targeted version of The New Your Times). On the front page these was a small entry called ‘The End User: A revolt against MP3’ pointing to an article inside the paper. The article talks mostly about how increased bandwith and storage is causing a lot of people to look at lossless audio formats for the music collections. While the article mentions that both Apple and Microsoft have such formats available most of the article talks about FLAC and mentions some tools available for creating FLAC files.
The article made me think a bit as I have been pushing for a bundling of a surround sound tuned version of Vorbis with Dirac to create an open source ‘killer combo’. But reading this article, which also mentions that Dolby and DTS are offering lossless codecs for surround, I started thinking that maybe I was thinking of a response to yesterdays challengers, and what should be done is work on surround sound with FLAC and then create a killer bundle of Dirac and FLAC. I mean FLAC is already the leading lossless codec, and while the iPod only supporting ALAC might help make that format relevant, we might have a good chance to build upon the success of FLAC going forward by putting it to use in a wider array of usecases.
So I been pining in front of the mailbox everyday since middle of last week. The reason is that in order to progress on setting up here in the UK I need the utility bill as a proof of address. Specifically I am not able to get a bank account without it which in turn holds up a lot of other things.
Where to report a bug
Noticed suddenly that with the latest Fedora kernel update my network card stopped working properly. Booting into the previous kernel it still works fine. But having this problem I realized once again the pain of reporting bugs in some of the lower level modules. In this case I feel belongs clearly in the Red Hat bugzilla due to it being only Red Hat kernel patches which have changed between the two modules in question.
But I have filed a lot of bugs there over the years and Red Hat’s engineers are understandably not to keen in being bug report routers. On the other hand Red Hat, Novell, Ubuntu etc., is going to be the only entity known to a lot of linux users coming in now and expecting them to figure out and file bugs/send emails etc., to various upstream groups and projects is not very likely to happen. This could be either a blessing or a curse I guess. For someone being involved with GStreamer I guess the fact that only people cluefull/interested enough to figure out that there is such a thing as GStreamer on their system and also understanding it has a separate bugzilla will mean that even as the user population grows the project will not get swamped in ‘useless’ bugs, as the people filling bugs have already shown some technical understanding by figuring out where to file it. On the other hand one can also easily risk that important bugs never reach upstream and instead goes to the great bugzilla limbo that can be distro bugzilla’s.
There are a few things I have been hoping to see in the bug tracker space for a long time. The first is a way to mark a bug as depending on upstream bugfixes. I mean getting a patch into a driver or upstream library is often of little help unless that bugfix makes it into your distro’s package (unless you want to roll your own files, but then you run the risk of losing your fixes everytime you update the system unless your careful). Being able to have Red Hat bugzilla mark a bug in GNOME bugzilla as a prereq would be nice for instance.
The other is a good way to figure out where to file bug reports. I mean I know some bugzilla’s and other bug trackers out there, but there are shitloads of projects I have no clue on how handle bugs. And some of the projects that theorectically have a bugzilla, like some freedesktop projects, do not seem to use it, so filing a bug there is next to useless. Maybe it would be possible for the distro packagers, who hopefully have some contact with the upstream projects to add some kind of bug reporting info to their packages. But even that takes you so far as for example with the kernel I often get the feeling you need a specific developers name and home phone number if you want to report a bug :)