Proprietary v open source software: more on removable features
Here's the third in a series of four short pieces by the IPKat's friend Keith Braithwaite (read the prologues to pieces one and two for the background) on the delicate balance between proprietary and open source models for the development and adoption of computer software.
More on Removable Features
Prologue
Last time we looked at the hidden downsides, for users, of spurning patented technology.
Now we return to the question of removing patented technology from existing products. This time we will look at a very low-level technology, buried deep inside the operating system, but which has a big impact on users’ experiences.
Despite its origins as a means of publishing scientific papers the web has become a rich visual medium. Almost every webpage has many graphical elements and graphics files tend to be large, particularly the high-resolution, rich colour images that we have become used to. Viewing this sort of content would be a much less satisfying experience without the application of two technologies from the proprietary world.
Zero-copy I/O
Many applications spend much of their time copying large chunks of data from one place in memory to another. For example, a web server delivering a page has to first retrieve the content from disk which involves copying it from a disk i/o buffer into the application’s memory space. The content is then copied into the buffer of a network socket to transmit it to the web browser. But doing that copies the content yet again to a network card buffer ready for serialisation on to the network itself.
An alternative is to copy the data into memory once and then pass around the system a “pointer” (or reference) to that data. The pointer is very small and requires much less effort to handle. Imagine the difference between sending a colleague a reference to a book in a note versus sending them the whole book. This is called (somewhat misleadingly) “Zero-Copy I/O”
The Apache 2 web server, for example, has a configuration option which means that when handling a request for a file requires no access to the data within a file – such as when delivering a file to a web browser as a download – Apache delivers the file contents without ever reading the file. But this is only possible if the operating system upon which Apache is running supports this feature.
The advantages can be significant. Sun Microsystems published a benchmark (showing measurements taken using ftp servers with a 1MB file) showing an improvement of 40% in the throughput and 20% less CPU utilization in servers that use Zero-Copy I/O. Removal of this functionality would make an impact on both users and operators of the server:
Data from IBM show how using a traditional approach instead of Zero-Copy I/O can almost triple the response time of an example application serving static files of various sizes . Such a slowdown could have a very serious impact on sales from a retail website – or drive away users to a faster competitor.
Even in your day-to-day work, you are probably benefiting from Zero-Copy I/O without being aware of it. Every time you request a large file – be it a photo, a software download, an audio track or a hospital x-ray – Zero-Copy I/O saves anything from seconds to minutes of your valuable time.
Zero-Copy I/O is becoming more widespread and the introduction of that technology into a range of products is being managed well. Let’s look at an older example of a key technology being mismanaged.
Image compression
Ever since the first NCSA Mosaic browser let webpages contain images, the Graphics Interchange Format (GIF) had been used as the standard encoding for simple pictures such as icons and page backgrounds. The authors of web servers and browsers thought little about this until 1994, when the owner of the intellectual property in the GIF standard, Compuserve, sought to collect royalties from companies incorporating that technology in their products. How could this have happened?
Computer manufacturer Sperry patented the Lempel-Ziv-Welch compression algorithm (LZW) in 1986. Unfortunately, LZW was published in a computer journal without reference to the fact that Sperry held a patent on it.
Not long after this Compuserve needed an efficient graphics representation for distributing images to their (pre-web) users and saw LZW as an ideal way to compress the graphics content of images. The resulting technology, GIF, was used widely by Compuserve users to share images. When the web arrived it seemed only natural to use GIF there, too. Sperry, merging with Burroughs to form Unisys, forgot that it owned the LZW patent until 1994. Unisys belatedly felt that it was obliged to assert its rights by demanding royalties from users of LZW – including the vendors of software that encoded or decoded GIF images, which included web server and browser makers.
Unisys quickly came to an agreement with Compuserve, letting it continue using LZW in the GIF format. Initially, both Compuserve and Unisys insisted that they only wanted to charge vendors of commercial software that employed the GIF algorithms. However, they soon had to retract this guideline because vendors started distributing the GIF support module as a “free add-on” to their commercial packages. Soon, only genuinely charitable organizations were able to avoid the payment of at least $0.10 per copy of any software that encoded GIFs.
Despite handing free licences to hundreds of non-profit organizations, schools, governments and so on, Unisys continued to generate only negative publicity. Anyone using a content management system or website authoring tool, or even an image editing application, was either deprived of the facility to use the web’s most popular image format and/or ran the risk of being found liable for infringing Unisys’s patent.
The worldwide patents on LZW expired in 2006. By then the GIF controversy had led directly to the formulation in 1995 of a new image encoding standard called Portable Network Graphics (PNG). However, PNG is still not fully established, largely due to the initial unwillingness of the leading browser vendors to invest in supporting it – even when it became an official standard of the WorldWide Web Consortium. Most webmasters continued to use GIFs, even though they were covered by patents, rather than lose readers.
Next article
My fourth and final article, which will wrap up the whole series with a summary, will look at the proposition that product designers don’t need to use proprietary technology because no real progress has been made in many areas for several decades. The conclusions may surprise you.
More on Removable Features
Prologue
Last time we looked at the hidden downsides, for users, of spurning patented technology.
Now we return to the question of removing patented technology from existing products. This time we will look at a very low-level technology, buried deep inside the operating system, but which has a big impact on users’ experiences.
Despite its origins as a means of publishing scientific papers the web has become a rich visual medium. Almost every webpage has many graphical elements and graphics files tend to be large, particularly the high-resolution, rich colour images that we have become used to. Viewing this sort of content would be a much less satisfying experience without the application of two technologies from the proprietary world.
Zero-copy I/O
Many applications spend much of their time copying large chunks of data from one place in memory to another. For example, a web server delivering a page has to first retrieve the content from disk which involves copying it from a disk i/o buffer into the application’s memory space. The content is then copied into the buffer of a network socket to transmit it to the web browser. But doing that copies the content yet again to a network card buffer ready for serialisation on to the network itself.
An alternative is to copy the data into memory once and then pass around the system a “pointer” (or reference) to that data. The pointer is very small and requires much less effort to handle. Imagine the difference between sending a colleague a reference to a book in a note versus sending them the whole book. This is called (somewhat misleadingly) “Zero-Copy I/O”
The Apache 2 web server, for example, has a configuration option which means that when handling a request for a file requires no access to the data within a file – such as when delivering a file to a web browser as a download – Apache delivers the file contents without ever reading the file. But this is only possible if the operating system upon which Apache is running supports this feature.
The advantages can be significant. Sun Microsystems published a benchmark (showing measurements taken using ftp servers with a 1MB file) showing an improvement of 40% in the throughput and 20% less CPU utilization in servers that use Zero-Copy I/O. Removal of this functionality would make an impact on both users and operators of the server:
• The end user will perceive poor performance while using the resources of the server;
• The server owner will have to expend more to support the same number of users.
“Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra 0.5 seconds in search page generation time caused traffic to drop by 20% . A broker could lose $4 million in revenues per millisecond if his electronic trading platform is 5 milliseconds behind the competition.”
Data from IBM show how using a traditional approach instead of Zero-Copy I/O can almost triple the response time of an example application serving static files of various sizes . Such a slowdown could have a very serious impact on sales from a retail website – or drive away users to a faster competitor.
Even in your day-to-day work, you are probably benefiting from Zero-Copy I/O without being aware of it. Every time you request a large file – be it a photo, a software download, an audio track or a hospital x-ray – Zero-Copy I/O saves anything from seconds to minutes of your valuable time.
Zero-Copy I/O is becoming more widespread and the introduction of that technology into a range of products is being managed well. Let’s look at an older example of a key technology being mismanaged.
Image compression
Ever since the first NCSA Mosaic browser let webpages contain images, the Graphics Interchange Format (GIF) had been used as the standard encoding for simple pictures such as icons and page backgrounds. The authors of web servers and browsers thought little about this until 1994, when the owner of the intellectual property in the GIF standard, Compuserve, sought to collect royalties from companies incorporating that technology in their products. How could this have happened?
Computer manufacturer Sperry patented the Lempel-Ziv-Welch compression algorithm (LZW) in 1986. Unfortunately, LZW was published in a computer journal without reference to the fact that Sperry held a patent on it.
Not long after this Compuserve needed an efficient graphics representation for distributing images to their (pre-web) users and saw LZW as an ideal way to compress the graphics content of images. The resulting technology, GIF, was used widely by Compuserve users to share images. When the web arrived it seemed only natural to use GIF there, too. Sperry, merging with Burroughs to form Unisys, forgot that it owned the LZW patent until 1994. Unisys belatedly felt that it was obliged to assert its rights by demanding royalties from users of LZW – including the vendors of software that encoded or decoded GIF images, which included web server and browser makers.
Unisys quickly came to an agreement with Compuserve, letting it continue using LZW in the GIF format. Initially, both Compuserve and Unisys insisted that they only wanted to charge vendors of commercial software that employed the GIF algorithms. However, they soon had to retract this guideline because vendors started distributing the GIF support module as a “free add-on” to their commercial packages. Soon, only genuinely charitable organizations were able to avoid the payment of at least $0.10 per copy of any software that encoded GIFs.
Despite handing free licences to hundreds of non-profit organizations, schools, governments and so on, Unisys continued to generate only negative publicity. Anyone using a content management system or website authoring tool, or even an image editing application, was either deprived of the facility to use the web’s most popular image format and/or ran the risk of being found liable for infringing Unisys’s patent.
The worldwide patents on LZW expired in 2006. By then the GIF controversy had led directly to the formulation in 1995 of a new image encoding standard called Portable Network Graphics (PNG). However, PNG is still not fully established, largely due to the initial unwillingness of the leading browser vendors to invest in supporting it – even when it became an official standard of the WorldWide Web Consortium. Most webmasters continued to use GIFs, even though they were covered by patents, rather than lose readers.
Next article
My fourth and final article, which will wrap up the whole series with a summary, will look at the proposition that product designers don’t need to use proprietary technology because no real progress has been made in many areas for several decades. The conclusions may surprise you.