LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for March 31, 2011Android and HoneycombThere's been a lot of press—and hand-wringing—about Google's decision to withhold the source code for the latest Android 3.0 release. There have been claims that Google is (or will be) violating various licenses by doing so. While that claim is overblown, there are still reasons to be unhappy about the choice being made here, while recognizing that it is Google's choice to make. Business Week broke the story that, unlike previous releases, Android 3.0 ("Honeycomb")—targeted at tablet devices—would not be released for several months, possibly not until the next version ("Ice Cream") is completed. The article quoted Andy Rubin, Google's VP for engineering and head of the Android group, as saying that Honeycomb may not be suitable for phones:
We didn't want to think
about what it would take for the same software to run on phones. It would
have required a lot of additional resources and extended our schedule
beyond what we thought was reasonable. So we took a shortcut.
The concern seems to be that vendors might take Honeycomb, put it on phones (or other small-screen devices), and create "a really bad user experience". There has certainly been a number of vendors who took previous non-tablet-oriented releases and put them on tablets with varying degrees of success. Google appears to be worried that the Android brand is being tainted by low quality implementations. That may be true, but there are other ways that problem could be prevented. One obvious choice is the Android trademark, which Google could use to require devices to meet some minimum standards. Google already exercises some control via its Google-branded Android applications (like Market, Maps, and Gmail) that have to be licensed from the company. In order to do that, a device must fulfill the Android Compatibility Definition. But plenty of low-end phone and tablet makers were willing to forgo those applications, take the source code, and run with it—sometimes with less-than-stellar results. So, Google has found a different way to enforce its will on device makers that do not directly license code from the company: stop providing the source. Since one of the goals of the project was to "keep the GPL out of user space", that means that the Android user space is licensed under non-copyleft terms. But even if it were all covered by the GPL, Google, as the copyright holder, would not be obligated to release the code. Copyright holders are not beholden to the license they provide to others for using their code. As it is, most of the code is under the Apache Software License or similar terms, which means there is no requirement for anyone to provide source. The big exception, of course, is the Linux kernel, and one would expect that Google is GPL-savvy enough to not withhold that code. For the kernel, though, the interesting parts are not necessarily in Google's kernel tree, as it is the device makers that add support and drivers for their platforms. As we've seen, GPL compliance in Android tablets is rather spotty, at best, so that's where any license problems are likely to be found. Part of the uproar about Google's decision is based on the somewhat faulty belief that Android was ever a real open source project. There were high hopes early on that it might become one, and, up until now, Google kept throwing its code over the wall to—more or less—continue the open source spirit of the project. But, unlike real open source projects, there were only limited attempts to build a developer community around Android itself, instead, for the most part, there were just the periodic code drops. Much of the effort was aimed at cultivating application developers, which has worked out quite well. It's hard to say for sure, but one might guess that the openness of the Android code played a role in how quickly the platform was embraced by application developers. One could argue that Google needed to keep Android development in-house, so that it could keep up with the incredibly fast-paced smartphone market—and that may be true. One could certainly point to MeeGo as a counterexample of sorts, and one that has yet to really produce any tangible results in the form of products for sale. MeeGo clearly has a development community slowly growing around it, even though it is dominated by two (now one, really) companies. While MeeGo is much more upstream-oriented than Android, its governance has been largely top-down. So far, Google's model has been much more successful, but MeeGo is really only a year old at this point. Google has made a lot of noise about how "open" Android is, including things like Rubin's famous tweet in response to Steve Jobs: "The definition of open: 'mkdir android ; cd android ; repo init -u git://android.git.kernel.org/platform/manifest.git ; repo sync ; make'" For Honeycomb, at least for the next few months, that will no longer be true, which is enough to sour some folks on the Android platform as a whole. Google has evidently weighed the benefits that it gets from opening the Android code—bug fixes, enhancements, good public relations—and found that it was not enough to overcome its concerns. It is unfortunate that we won't be able to see what the CyanogenMod folks (and others in the "mod" community) might have done with Honeycomb, at least for a while yet. There are likely some low-cost tablet makers that could have done interesting things with it as well. While Google claims to be concerned about "user experience", it's pretty hard to read this move as anything other than a tightening of control over the platform. Hopefully, this is just a blip, and things will return to "normal" with "Ice Cream", but the damage may have already been done by then. Over the last few weeks, we have defended the behavior of several companies (Red Hat and Google) when they have been faced with accusations of license violations. In all of these cases, though, one does not have to like what the company is doing to recognize that it isn't a violation of any licenses. Once again, we would much rather see Google keep the Android project open—or make it even more open—but recognize that it is well within its rights not to do so. With any luck, other open source projects will show the way such that Google finds it in its interests to open up Android further. Time will tell ...
Here be dragons: PostGIS 2.0 adds 3D, raster image, and topology supportThe PostGIS geographic database system is nearing its 2.0 release, a major update that adds several significant new capabilities. PostGIS is an extension to the PostgreSQL database manager that implements GIS-specific data types and functions. Equally important, though, is the fact that a wide range of other open source geographic information system (GIS) projects can use PostGIS as a back-end data source, including GUI applications and servers. This 2.0 release is poised to be an important milestone not just for speed and stability reasons, but because it extends the database into three new areas: raster data, topology, and 3D. PostGIS adds support for geometric primitives (points, lines, polygons, as well as "collections" and other data structures of all three), plus reading, transforming, and writing a vast array of standard geospatial data formats. GIS applications often require special operators for calculating distances and areas, unions, intersections, and other set functions, along with specialized types of searches. PostGIS implements this functionality by adhering to the Open Geospatial Consortium's Simple Feature Access for SQL standard, although the project does not pay for the compliance testing necessary to advertise itself as an official implementation. PostGIS has been in active development since 2001, and built up a notable library of supporting GIS applications, including GRASS GIS, gvSIG, and MapServer; there are even commercial connectors available to tie proprietary GIS products into PostGIS databases. Still, in all this time, PostGIS has focused on what you might call traditional, vector-based, 2D geometry. One should not see this as a weakness; the majority of GIS applications are 2D and vector-based. Vector-based data encodes geographic features as shapes: points and polygons on a map projection, lines connecting features, and so on. RasterThere is, however, a lot of data available as raster imagery, too — aerial and satellite photographs, for example, which can be geocoded so that they can be properly aligned and transformed to fit onto a map. In recent years, the PostGIS community worked on raster support via an add-on package originally named WKT Raster, which was later renamed PostGIS Raster. With 2.0, its functionality will be fully integrated into the main application. Raster images are supported in special raster tables, which can be loaded from any format supported by the Geospatial Data Abstraction Library (GDAL), and exported to any GDAL-supported format. The list of supported formats is constantly growing, but at the moment the GDAL project lists more than 120. Naturally, loading and exporting is not the real work of supporting raster images in addition to vectors, so PostGIS 2.0 adds a slew of functions for analyzing and operating on the data inside the pixels. Rasters can be "extruded" into geometry (for example, turning regions of one color in the raster image into a polygon), averaged, and otherwise inspected. Rasters can be operated on with existing functions (such as calculating where they intersect with vector geometric shapes). It will also be possible to edit imported rasters in-place in the database, which opens the door to all sorts of transformations. The third dimensionThere is also no shortage of 3D data that could prove interesting to examine, if the data types to store it and the functions to transform it are available. PostGIS 2.0 adds extensive support for 3D, starting with two geometry types: polygonal surfaces and triangular irregular networks (TINs). Polygonal surfaces are just what you imagine them to be: three-dimensional surfaces defined by connected polygons. TINs define surfaces entirely with triangles, but the size of the triangles is flexible — somewhat like a multi-resolution mesh in a 3D modeling program. A TIN can use very few triangles to describe flatter areas of the map, and more to describe important features. In both cases, support for the new geometry consists not just of the basic data types, but the support operators to do recurring tasks like finding areas (and volumes) of regions in the new format. In addition to the new geometry types, the existing spatial indices have been made 3D-aware, and a library of 3D-functions added. This will allow GIS users to calculate distances in three dimensions, find 3D intersections of lines and shapes, and return 3D bounding-boxes or calculate complex things like 3D shortest-paths. The most straightforward application of 3D in GIS is to model landscape features in three dimensions, but there are more. Many other kinds of geo-coded data could be imported into a 3D PostGIS database for modeling and analysis. Consider calculating line-of-sight visibility between buildings, radio wave propagation, or flight vectors, for example. All involve familiar GIS operations, in 3D, even though they are not strictly "mapping"-related tasks. How best to output 3D data is a question that remains largely the domain of the front-end application (more on that a bit later...), but PostGIS 2.0 is adding support for direct output of 3D data to the XML-based X3D format. X3D is defined by the Web3D Consortium, which is working hard to get the format accepted into HTML5. Whether or not HTML5 ever allows the inclusion of in-line X3D scenes within page content, however, the format is likely to get supported in TopologyThe last major extension of PostGIS functionality in the 2.0 release is support for topology. In GIS terms, topology is not a reference to topographical maps. Rather, it means supporting data types and functions that implement mathematical graphs. In other words, instead of points, lines, and polygons, topology uses nodes, edges, and faces — potentially even directed and/or weighted edges. Transforming vector geometry into topology data makes what was a collection of shapes into a mathematical representation of the scene, including how nodes and regions are connected. The human eye can make those connections instantaneously, but the database requires explicit support for expressing them. Incorporating the topological version of a map layer in the database allows the application to perform path finding, routing, and flow analysis that cannot be done on raw geometry. The canonical example of this distinction is the Königsberg bridge problem: a human mathematician (say, Euler, to pick one at random...) can look at a drawing of the city and its seven famous bridges and work out its graph as nodes and edges implicitly. A PostGIS application cannot do the same with just the shapes of the river and landmasses. The data must be converted first. PostGIS 2.0 will be able to transform standard geometry into topological data, validate topology, and edit nodes and edges. Topology can also be converted to standard Geography Markup Language (GML) for output. This step represents the beginning of topology support in PostGIS. The future applications include network flow (such as traffic modeling), crisis management for disaster planning (such as minimum spanning trees and shortest paths for logistics), auto-map-coloring, "covering" problems, and considerably more. Those of us not in the GIS field may tend to think of GIS work at the national-mapping scale, for instance, but consider how valuable topology support would make PostGIS for network flow analysis, or for routing utilities within a building. Application support and additional enhancementsFeatures like topology and 3D are of limited value without support in the applications that use PostGIS. On that front, GRASS and gvSIG are the first to include topology, with others expected to follow. MapServer and QGIS, on the other hand, have raster layer support already. There may be more in the raster data support category that inherit their raster functionality from earlier support of the PostGIS Raster plug-in; the documentation is not always clear. For 3D data, the only application that appears to be readying support at present is gvSIG, which is scheduled to include it in the next release. This will reportedly be 3D viewing support only. Several of the open source GIS blogs are excited about the possibilities of 3D, though, including its potential for integration with virtual reality or augmented reality. That seems to be a few steps away, however, as does the possibility of combining topology and 3D data. The raster, 3D, and topology support slated for PostGIS 2.0 are not the database system's only new features. The blogs and mailing lists repeatedly mention the improvements to the TIGER geocoder, which imports data from the public domain map data gathered by the US Census Bureau, and broke when TIGER changed its format in 2010. There is also a new "reverse geocoder" function that takes a map point and returns nearby address data or street intersections, and a revamped GUI shape-file loader that for the first time can load several files at once. Finally, there are experimental builds for Windows for the very first time — in previous releases, Windows users had to compile PostGIS from scratch. The project has a complete list of new, enhanced, and deprecated functions in its online documentation. There may still be more enhancements to come; PostGIS reportedly has not yet declared its final feature freeze, and there are funded contractors working on some important areas, 3D included. The final release is officially expected in (northern hemisphere) "early spring," which of course is only a few days old at this point. In the meantime, the suitably daring can get test packages from the PostGIS site. With this many substantial new features, it may be worth taking an early look.
Supporting CentOSThere are rumors suggesting that the CentOS 5.6 release is imminent - though that is something we have heard before. This release will certainly be welcome to numerous CentOS users, but there can be no doubt that its tardiness - and, in particular, the absence of CentOS 5 security updates caused by its delay - has been a bit of a wakeup call for those users. If this much-used distribution is to remain viable into the future, some important changes will need to be made and those who depend on it will have to step up their support.There will be no shortage of CentOS users who would like to get their hands on the improvements and added hardware support to be found in the RHEL 5.6 and 6.0 releases. But the real problem is not delayed gratification; it is that there have been no CentOS 5 security updates since January 6, and only one since December 14, 2010. During this time, RHEL 5, on which CentOS 5 is based, has seen updates for dbus, exim, firefox (twice), gcc, hplip, java-openjdk, kernel (thrice), krb5, libtiff, libuser, mailman, openldap, pango, php, postgresql, python, samba, subversion (twice), tomcat5, vsftpd, and wireshark (twice). Since these updates are based on the 5.6 release, CentOS cannot easily pass them on to its users until they, too, have a 5.6 base. Since that base has been slow in coming, all those security updates have been blocked. Some of these vulnerabilities are more severe than others, but there can be no contesting the fact that every CentOS 5 system out there is currently running with a significant set of known holes. That is not the sort of solidity and support that CentOS users will have been hoping for. Many of those users will, by now, be wondering whether CentOS is the right distribution to base their systems on. The CentOS mailing list has been filled with users asking when updates would start flowing and why things have bogged down for so long. Some say that there are too many RHEL repackaging projects out there, and that CentOS should join forces with a distribution like Scientific Linux. Others blame the 6.0 release for distracting the project from its 5.x-based users - causing security updates for installed systems to languish in favor of a shiny new distribution that nobody is running yet. Still others complain that the project is insular, secretive, and hostile to new contributors. All of these claims may or may not be true, but they are not the subject of this article: there is another aspect to the problem that is unambiguous and clear. Many people benefit from the work of the CentOS project, but at the top of the list must be managed hosting providers. Those companies get, for free, a solid platform which they can install on thousands of servers and sell to their customers. A site called tophosts.com maintains a list of the top 25 hosting companies; a look at that list leads to some interesting conclusions. Of those 25 companies:
(As an aside, it is amazing how hard many of these companies make it to find out what it is that they are offering to sell. Hosting provider web sites seem to all be designed by the same person; they are twisty mazes of little JavaScript functions, all alike.) Represented on this list are the largest hosting providers in existence - though it must be said that the list is US-centric. Together, they account for many hundreds of thousands of systems, a significant percentage of which are running CentOS. That's a lot of business - a lot of revenue - which is being generated by CentOS-based systems. The failure of CentOS - or even a significant tarnishing of its reputation - would reduce the value of the services offered by these providers. Other free Linux distributions exist, and some are entirely suitable for stable deployment situations, but many customers want a distribution which is compatible with RHEL. So said providers have a significant stake in keeping the perceived value of CentOS high. Perhaps it is time that some of them put some resources into supporting that value. Said resources could certainly take the form of monetary donations to the project. But far better would be for these companies to hire somebody to work directly with CentOS and make it better. In return, they would reap all of the benefits that come with open source participation: they would have a better distribution to offer to their customers, they would get more influence over the direction of the project, their participation would enhance their reputation, and, crucially, they would improve their in-house expertise which could then be used to support their customers. All of the motivations for supporting free software development in other parts of the economy apply just as strongly to hosting providers. A look at the CentOS Sponsors Page shows that quite a few hosting companies - including a handful of the big ones from the list described above - are supporting the project. In many cases, it seems, that support takes the form of a donated server. CentOS certainly needs servers and bandwidth, but those, alone, will not keep the distribution strong. Even the strongest contributor gets a bargain from Linux - nobody puts in as much as they get out. But one suspects that the hosting industry is getting a better deal than many. Now would be a good time for the top beneficiaries of the CentOS project to roll up their sleeves and put some serious time into making it better.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||