I've been running the Vanilladroid firmware for my HTC Eris for a few weeks now. Beside the phone spontaneously rebooting itself every few hours, its run great, and with built in wifi tethering.
Tonight it proved potentially fatal for one young man. While walking home it appeared like I interupted a mugging near HacDC. The victim was being kicked by a man who ran away as I got closer. He was laying sprawled out on the concrete, face right on the sidewalk and shirt ripped off. I pulled out my phone, hit the icon for Dialer One (which comes with Vanilladroid), dialed 911, dial key, and... nothing. Dial key again, nothing. Checked, it says 911 in the number box, but the app isn't dialing it. I closed the app and tried again, notta. I can't believe it would refuse to dial 911 so I hard reset the phone and try again, still the dialer just sits there as I press the dial key.
I finally had to go on the web, look up the number for Dc Police, and have them transfer me to 911.
I take partial blame for not looking into this app and switching it out sooner. Hopefully Google removes it before someone dies while trying to call for help.
Thursday, May 27, 2010
Friday, May 21, 2010
praise for Gnome's GIO
We've been (finally) getting Concordance's C code refactored into a standalone XMPP server called GNation.
Concordance used a good deal of GLib code already, but we've gone a bit further in using the GIO library for managing sockets and connections. In doing so, we were able to reduce roughly 160 lines of code for opening and monitoring listening sockets into 12 and I suspect further reductions as we continue. All of the IPv4 vs IPv6 support was cleanly abstracted, adding a socket listener to the MainLoop was done automatically, and the GIO documentation was of the same high quality we've come to expect from GLib.
Major thanks to the hard work that has gone into this!
Concordance used a good deal of GLib code already, but we've gone a bit further in using the GIO library for managing sockets and connections. In doing so, we were able to reduce roughly 160 lines of code for opening and monitoring listening sockets into 12 and I suspect further reductions as we continue. All of the IPv4 vs IPv6 support was cleanly abstracted, adding a socket listener to the MainLoop was done automatically, and the GIO documentation was of the same high quality we've come to expect from GLib.
Major thanks to the hard work that has gone into this!
Wednesday, May 19, 2010
How free is Google's VP8 (WebM)?
Thank you Google for using your wealth to purchase On2 corporation and release VP8 to the world. However, there appears to be one glaring flaw in the patent license you offer which makes it incompatible with free software licensing: it appears to only cover the VP8 bitstream itself, not improvements to it made by the community.
When On2 previously released VP3.2 to the Xiph foundation and the world, the patent license explicitly included derivatives (improvements) to VP3.2 including Ogg Theora. This was a critical step in transitioning the proprietary VP3.2 codec to the open codec Theora is today.
On2's "VP" codecs included little extensibility, why should they as On2's revenue stream depended on releasing (and offering a new license for) a new improved codec version every year or two. You cannot use their VP5 codec to decode VP6, you need to get a VP6 codec for that. In contrast, Vorbis is ten years old now and is still being improved on.
The large body of work undertaken primarily by Tim and Ralph at Xiph before Theora 1.0 could be released was extending the bitstream in a losslessly upgradable manner from VP3.2 to include the fields necessary to continually improve Theora over the next decade and beyond. You can see this by playing a VP3.2 video next to a Theora 1.1 video, and even more so in the Theora 1.2-beta9 comparisons, and they've barely scratched the surface still.
For comparison, On2 corporation's patent license for VP3.2 can be found in the Theora license file vs Google's VP8 bitstream license. As I'm not a lawyer, I would love to hear SFLC's evaluation of this in their next Oggcast.
When On2 previously released VP3.2 to the Xiph foundation and the world, the patent license explicitly included derivatives (improvements) to VP3.2 including Ogg Theora. This was a critical step in transitioning the proprietary VP3.2 codec to the open codec Theora is today.
On2's "VP" codecs included little extensibility, why should they as On2's revenue stream depended on releasing (and offering a new license for) a new improved codec version every year or two. You cannot use their VP5 codec to decode VP6, you need to get a VP6 codec for that. In contrast, Vorbis is ten years old now and is still being improved on.
The large body of work undertaken primarily by Tim and Ralph at Xiph before Theora 1.0 could be released was extending the bitstream in a losslessly upgradable manner from VP3.2 to include the fields necessary to continually improve Theora over the next decade and beyond. You can see this by playing a VP3.2 video next to a Theora 1.1 video, and even more so in the Theora 1.2-beta9 comparisons, and they've barely scratched the surface still.
For comparison, On2 corporation's patent license for VP3.2 can be found in the Theora license file vs Google's VP8 bitstream license. As I'm not a lawyer, I would love to hear SFLC's evaluation of this in their next Oggcast.
Tuesday, May 18, 2010
stability, always a few versions behind
Several of our projects use waf and Vala, which I normally have nothing but good things to say about, but this is an exception. At the moment, we're stuck working with outdated versions of both.
Tonight I tried upgrading from Waf 1.5.10 to 1.5.16 and was unable to get any of our packages to build with it. As it turns out, it doesn't seem to like glib (maybe the "-" or number in the package name?) and fails to record its cflags and libs to pass to gcc during building. If 1.5.10 didn't have a few annoying bugs of its own or if we could patch and "compile" 1.5.10 we'd be fine, but even this version we had to use the "binary" (compressed Python script) from their website as we couldn't get a Python 3 version to build from source.
Despite all this, it is very nice to have a small, clean build system that both supports Genie and runs on Python 3. The small workarounds we've had to do are worth the savings in headache and frustration autotools/scons/etc would cause us.
With Vala, apparently nobody did even a casual check to ensure the Genie parser was still working properly before releasing valac 0.8.0 (now up to 0.8.1), and a basic example from the language's frontpage (command line argument parsing) compiles but fails to link. For now, we're all forced to stick with valac 0.7.10 until the problem is solved or someone suggests a workaround. Its unfortunate a few of our devs run Ubuntu 10.04 which doesn't offer valac 0.7.x as a package.
Good news is I'm almost finished debugging
Tonight I tried upgrading from Waf 1.5.10 to 1.5.16 and was unable to get any of our packages to build with it. As it turns out, it doesn't seem to like glib (maybe the "-" or number in the package name?) and fails to record its cflags and libs to pass to gcc during building. If 1.5.10 didn't have a few annoying bugs of its own or if we could patch and "compile" 1.5.10 we'd be fine, but even this version we had to use the "binary" (compressed Python script) from their website as we couldn't get a Python 3 version to build from source.
Despite all this, it is very nice to have a small, clean build system that both supports Genie and runs on Python 3. The small workarounds we've had to do are worth the savings in headache and frustration autotools/scons/etc would cause us.
With Vala, apparently nobody did even a casual check to ensure the Genie parser was still working properly before releasing valac 0.8.0 (now up to 0.8.1), and a basic example from the language's frontpage (command line argument parsing) compiles but fails to link. For now, we're all forced to stick with valac 0.7.10 until the problem is solved or someone suggests a workaround. Its unfortunate a few of our devs run Ubuntu 10.04 which doesn't offer valac 0.7.x as a package.
Good news is I'm almost finished debugging
expat.vapi (Expat bindings for Vala/Genie) and David is sprinting ahead with xml config file parsing with it. By this weekend we could have XMPP routing with the new server being branched off from Concordance-XMPP.
Saturday, May 15, 2010
dusting off pyogg2
I've started work on updating an old CMS I worked on between 2002-2005 that includes a non-linear Ogg editor and Icecast stream queue management. Part of this is updating the CMS to Python 3, including pyogg2 which it uses.
Since I no longer have working ssh keys for committing to svn.xiph.org, I copied the pyogg2 repository to hg.concordance-xmpp.org and resumed the work I left off in 2005. Pyogg2 was in fairly stable shape but lacked documentation, utilities for working with common codecs, and only had a few examples to learn it with. I'm already given its build system a major cleanup (now just "setup.py build" like any other Python package) and almost finished the Python 3 PyModule code.
I have a lot more work to do on this; the CMS needs to be updated for modern web standards (HTML/5), the homebrew MySQL ORM with SQLAlchemy, and changing from the old CGI Apache configuration setup to CherryPy.
Since I no longer have working ssh keys for committing to svn.xiph.org, I copied the pyogg2 repository to hg.concordance-xmpp.org and resumed the work I left off in 2005. Pyogg2 was in fairly stable shape but lacked documentation, utilities for working with common codecs, and only had a few examples to learn it with. I'm already given its build system a major cleanup (now just "setup.py build" like any other Python package) and almost finished the Python 3 PyModule code.
I have a lot more work to do on this; the CMS needs to be updated for modern web standards (HTML/5), the homebrew MySQL ORM with SQLAlchemy, and changing from the old CGI Apache configuration setup to CherryPy.
Wednesday, May 12, 2010
Leaving the Ubuntu project
In response to the recent news that Canonical has stated peddling MPEG-4 patent licenses to Ubuntu OEMs, I am resigning as member of the Ubuntu project.
I have been uncomfortable by Canonical misusing the Ubuntu trademark with their proprietary Ubuntu One service, which they have recently added a proprietary music store to for MP3-only downloads fully integrated with Ubuntu's version of Rhythmbox, and bundling an ever-increasing amount of proprietary drivers with Ubuntu.
I still find the Ubuntu community an outstanding model for how the free software community should organize. Strong grassroots presence through the local community teams, democratically organized leadership, and most importantly the Ubuntu Code of Conduct are models other projects should look to emulate.
I'm certain that if put to a vote, the Ubuntu community would release the Ubuntu One server code as AGPLv3 and discontinue business practices in contrast with free software values conducted in its name, but the only way we can vote against Canonical is with our feet.
As I serve in a leadership position in a local community team, I'll be upholding my agreement with the Ubuntu Code of Conduct by gracefully stepping down after finding another team member to take my place and migrating any remaining accounts off my @ubuntu.com email address.
I have been uncomfortable by Canonical misusing the Ubuntu trademark with their proprietary Ubuntu One service, which they have recently added a proprietary music store to for MP3-only downloads fully integrated with Ubuntu's version of Rhythmbox, and bundling an ever-increasing amount of proprietary drivers with Ubuntu.
I still find the Ubuntu community an outstanding model for how the free software community should organize. Strong grassroots presence through the local community teams, democratically organized leadership, and most importantly the Ubuntu Code of Conduct are models other projects should look to emulate.
I'm certain that if put to a vote, the Ubuntu community would release the Ubuntu One server code as AGPLv3 and discontinue business practices in contrast with free software values conducted in its name, but the only way we can vote against Canonical is with our feet.
As I serve in a leadership position in a local community team, I'll be upholding my agreement with the Ubuntu Code of Conduct by gracefully stepping down after finding another team member to take my place and migrating any remaining accounts off my @ubuntu.com email address.
server migration complete
I have finished migrating all the websites I host from maat (at ServerBeach) to nut (at Hurricane Electric). Tonight I finished wiping all the passwords, ssl certs, and other private data from the old server before its shut down tomorrow.
Maat was an Athlon XP 2200+ server with 1gig ram, 80gig HD, 10meg up/down, 2TB/month transfer, and 1 IPv4 address. Nut is a Atom 330 (1.6ghz 64-bit dual core) with 2gig ram, 500gig HD, 100meg up/down, unlimited bandwidth, 6 usable IPv4 addresses and a /64 IPv6 subnet - and costs less.
I shed a tear working through maat's filesystem checking for any remaining files to be copied and finding the original Gentoo stage3 tarball used to install it:
My experience so far with Hurricane Electric is that their remote admin tools are limited to "remote hands" (call a technician 24/7 to reboot a server, type in commands, etc), where ServerBeach offered a really nice web portal for rebooting, accessing a rescue image, etc without having to call anyone. Of course, those tools haven't been working correctly since December. The technicians at Hurricane Electric have demonstrated a far higher level of expertise than anyone I've spoken to at ServerBeach.
Unlimited 100meg bandwidth, IPv6, and 10x bandwidth (HTML/5 Ogg audio/video hosting) is the real seller. In retrospect, I'm really glad ServerBeach had the FUBAR downtime in December prompting me to look for alternatives, this is a much better deal.
Maat was an Athlon XP 2200+ server with 1gig ram, 80gig HD, 10meg up/down, 2TB/month transfer, and 1 IPv4 address. Nut is a Atom 330 (1.6ghz 64-bit dual core) with 2gig ram, 500gig HD, 100meg up/down, unlimited bandwidth, 6 usable IPv4 addresses and a /64 IPv6 subnet - and costs less.
I shed a tear working through maat's filesystem checking for any remaining files to be copied and finding the original Gentoo stage3 tarball used to install it:
/stage3-i686-2007.0.tar. Tomorrow ServerBeach will likely disconnect maat and retire it as after 3 years the server is out of maintainability.My experience so far with Hurricane Electric is that their remote admin tools are limited to "remote hands" (call a technician 24/7 to reboot a server, type in commands, etc), where ServerBeach offered a really nice web portal for rebooting, accessing a rescue image, etc without having to call anyone. Of course, those tools haven't been working correctly since December. The technicians at Hurricane Electric have demonstrated a far higher level of expertise than anyone I've spoken to at ServerBeach.
Unlimited 100meg bandwidth, IPv6, and 10x bandwidth (HTML/5 Ogg audio/video hosting) is the real seller. In retrospect, I'm really glad ServerBeach had the FUBAR downtime in December prompting me to look for alternatives, this is a much better deal.
Saturday, February 20, 2010
working on gtypes
We've been moving forward on the PySoy rewrite using Genie in faith that a Python 3 binding for GObject would come about.
At PyCon this weekend I've brainstormed with Kirk McDonald, author of PyD which serves a similar role to use D types/objects in Python, and several other authors of FFIs for Python. A rough strategy is coming together to solve this in a dynamic manner.
The first part of the solution is libvala; using a small part of its functionality to parse .vapi and .gir files for existing GObject libraries such as GTK and Cairo as well as any library written in Vala or Genie. This gets us the C API for the library in all it's object oriented goodness, and with that we can dynamically generate bindings using Python's ctypes.
The second part is a GObject type in Python which supports subclassing in Python. Kirk detailed how this is done in PyD; each generated GObject type gets a subtype with all of its virtual methods all running Python methods which call the superclass's C method by default. When a Python subclass of a GObject class is made this GObject subclass is used allowing Python to override any of its methods and pass objects of the subclass back to GObject where they'll perform as expected. Not simple or easy, but its a strategy.
The end result is dynamic Python 3 bindings for GTK as well as PySoy and all the other tools we work on.
I'm organizing a sprint for this at PyCon. If anyone has ideas on this please comment, or if you'd like to help (whether at PyCon 2010 or not) get in touch with me.
At PyCon this weekend I've brainstormed with Kirk McDonald, author of PyD which serves a similar role to use D types/objects in Python, and several other authors of FFIs for Python. A rough strategy is coming together to solve this in a dynamic manner.
The first part of the solution is libvala; using a small part of its functionality to parse .vapi and .gir files for existing GObject libraries such as GTK and Cairo as well as any library written in Vala or Genie. This gets us the C API for the library in all it's object oriented goodness, and with that we can dynamically generate bindings using Python's ctypes.
The second part is a GObject type in Python which supports subclassing in Python. Kirk detailed how this is done in PyD; each generated GObject type gets a subtype with all of its virtual methods all running Python methods which call the superclass's C method by default. When a Python subclass of a GObject class is made this GObject subclass is used allowing Python to override any of its methods and pass objects of the subclass back to GObject where they'll perform as expected. Not simple or easy, but its a strategy.
The end result is dynamic Python 3 bindings for GTK as well as PySoy and all the other tools we work on.
I'm organizing a sprint for this at PyCon. If anyone has ideas on this please comment, or if you'd like to help (whether at PyCon 2010 or not) get in touch with me.
Wednesday, January 13, 2010
Epson Artisan 810 on Linux (Ubuntu)
We purchased a new printer for the house last night to replace the windows-only Dell printer that ran out of ink (and would cost almost as much as a new printer for replacements).
First, some advice: plan ahead, order online, don't buy from Staples. We paid $170 for this when Epson is offering them direct for $130 with free shipping. If we were not in need of immediate replacement we could have saved $40 and waited a week. Further, the rep at the store lied when he told us the printer was going to the back to get a unit "fresh off the truck", it was a unit another customer had returned with ink spilled and dried on the inside and some of the packaging torn open. Buyer beware. Otherwise, they seemed to clean it up and repackaged it well. I have half a mind to order the printer online and return this one within 14 days for refund to save the $40.
The printer itself is fairly impressive. Two paper trays (letter/legal plus photo/cardstock) and a built-in CD printing tray that slides out when you select CD printing, scanner with auto-document feeder, and built in 10/100 and wifi so we don't need to depend on any computer in the house to properly "share" the printer. All I had to do is select our access point on the front controls and give it a static IP on our router.
Ubuntu 9.10 detects the printer over the network in seconds and I was printing the Ubuntu test page in under a minute, so more than half the systems in the house were easy. Windows setup was not hard, but time consuming as loads of bundled software installed from the CD. The only complaint I have is the color seems a little off; printing the same image in both Linux and Windows shows a fairly radical difference in quality. The prints from Linux are still much better than printing from Windows to our older printer.
Next I tried to use the scanner function. Using GIMP to launch SANE (Scanner Access Now Easy), the printer was automatically detected and let me select either the flatbed or auto-document feeder. Both options work fine until I start the scan, at which point the Epson Artisan 810 locks up and needs to be rebooted.
There is a scan function from the front panel, not supporting anywhere near the scanner's full resolution and storing in JPEG format with obvious artifacts around text/etc, but at least we don't need to use a Windows system for basic scans until SANE is fixed. Since I have a stand-alone Epson scanner that works beautifully this isn't a huge issue for me, though it would be great to be able to use the auto-document feeder from Linux and be able to put this older scanner into storage.
First, some advice: plan ahead, order online, don't buy from Staples. We paid $170 for this when Epson is offering them direct for $130 with free shipping. If we were not in need of immediate replacement we could have saved $40 and waited a week. Further, the rep at the store lied when he told us the printer was going to the back to get a unit "fresh off the truck", it was a unit another customer had returned with ink spilled and dried on the inside and some of the packaging torn open. Buyer beware. Otherwise, they seemed to clean it up and repackaged it well. I have half a mind to order the printer online and return this one within 14 days for refund to save the $40.
The printer itself is fairly impressive. Two paper trays (letter/legal plus photo/cardstock) and a built-in CD printing tray that slides out when you select CD printing, scanner with auto-document feeder, and built in 10/100 and wifi so we don't need to depend on any computer in the house to properly "share" the printer. All I had to do is select our access point on the front controls and give it a static IP on our router.
Ubuntu 9.10 detects the printer over the network in seconds and I was printing the Ubuntu test page in under a minute, so more than half the systems in the house were easy. Windows setup was not hard, but time consuming as loads of bundled software installed from the CD. The only complaint I have is the color seems a little off; printing the same image in both Linux and Windows shows a fairly radical difference in quality. The prints from Linux are still much better than printing from Windows to our older printer.
Next I tried to use the scanner function. Using GIMP to launch SANE (Scanner Access Now Easy), the printer was automatically detected and let me select either the flatbed or auto-document feeder. Both options work fine until I start the scan, at which point the Epson Artisan 810 locks up and needs to be rebooted.
There is a scan function from the front panel, not supporting anywhere near the scanner's full resolution and storing in JPEG format with obvious artifacts around text/etc, but at least we don't need to use a Windows system for basic scans until SANE is fixed. Since I have a stand-alone Epson scanner that works beautifully this isn't a huge issue for me, though it would be great to be able to use the auto-document feeder from Linux and be able to put this older scanner into storage.
Sunday, January 10, 2010
soy.windows.Window rendering, GLEW headache
I'm seeing "red" now with our Windows, in more ways than one. The rendering code for soy.windows.Windows is to the point that, by changing the glClear color, we're seeing red in the window rather than black. This is a big step forward given that porting to use GDK is a big part of the libsoy migration.
On the other side of "red" is anger over GLEW. I really wish I knew of a decent, mature alternative to GLEW. The project is so immature that, though one of the maintainers is a Debian developer, they do not provide the pkgconfig file for it. Without this file, which provides Waf with the location of the library and it's headers, we would have to write a search script to verify that it's installed and find it's location. None of the major distros I looked at provide the pkgconfig on their own.
It's also at least partially redundant with the functionality of gtkglext which I believe should be able to replace GLEW entirely.
On the other side of "red" is anger over GLEW. I really wish I knew of a decent, mature alternative to GLEW. The project is so immature that, though one of the maintainers is a Debian developer, they do not provide the pkgconfig file for it. Without this file, which provides Waf with the location of the library and it's headers, we would have to write a search script to verify that it's installed and find it's location. None of the major distros I looked at provide the pkgconfig on their own.
It's also at least partially redundant with the functionality of gtkglext which I believe should be able to replace GLEW entirely.
Subscribe to:
Posts (Atom)