LWN.net Weekly Edition for October 9, 2014

On the sickness of our community

Lennart claims to be one of the favorite targets of the "assholes" in our community; there can be no doubt that this is true. For better or for worse, Lennart has become a sort of lightning rod for certain types of criticism — and worse. It is one thing to have one's code criticized; it's another to face death threats, abusive video postings, and more. Anybody who pays attention to what is happening in our communication channels cannot fail to see that Lennart is getting some special treatment.

There are those who will argue that Lennart has brought this experience upon himself, that his ways of dealing with the community have brought forth an ugly response. There is room to criticize how, say, the systemd project operates and how it interacts with the rest of the free software community. But there are limits to how far that criticism should legitimately go before it crosses the line. For the rest, the claim that Lennart has somehow caused the behavior we are seeing is a simple exercise in blaming the victim. Nobody should have to put up with that kind of attack, and we as a community should stand up against those attacks regardless of what we think of the person targeted.

It may be a fundamental mistake, though, to see those attacks as originating from inside our community. The people we develop code with are not the people who are creating that sort of grief. The net does not lack for vile idiots looking to make somebody's life miserable; they can be found far beyond the open-source community. Those are the people who are posting videos, making death threats, and assaulting our mailing lists with unpleasant sock-puppet posts. One should not confuse such people with our community! They hide in the dark corners of the net and invade our space to play their games, but they are not us.

For those wanting to understand just where this kind of harassment can go, an attentive reading of Kathy Sierra's experiences is a disturbing but informative experience.

What we need to do is to build our defenses against such people, rather than paint our whole community as being like them. Insisting on civil behavior within our community's boundaries is certainly a part of that, and a lot of progress has been made in that direction over the years. Yes, we can do better; hopefully the future will see more improvement. Unfortunately, there is little we can do about the larger mob of unpleasant people out there; in a world where free speech is protected, there will always be some unwelcome voices. We can disclaim them and, often, the best thing to do is to ignore them, but we can never suppress them entirely.

Another fundamental mistake, in your editor's view, is to blame this situation on Linus Torvalds. One should not underestimate the effect a leader can have on the tone of a development community — a visit to the OpenBSD lists is a good way to see that dynamic in action. By that measure, Linus should be judged (mostly) positively; the linux-kernel mailing list is far from the wild-west playpen that people would make it out to be. The volume on that list is approaching 1000 messages per day, yet one must look hard to find one that can be deemed abusive or intemperate. Yes, they exist — one will not gather thousands of people in one place without hearing some words occasionally — but the conversation is generally civil and technical. Linus's conversation included — with the occasional exception, granted.

There has been an interesting opportunity to watch the linux-kernel community in action recently, as a (presumably) well-meaning but incapable developer made repeated attempts to submit patches. These patches went to a large range of maintainers, and they were uniformly useless at best and, often, actively wrong. The person involved was wasting significant amounts of kernel developer time while contributing nothing of value.

A common response to such a person would be to flame them to a crisp in the hope that they simply go away. Some years ago, things would have probably gone just that way, but that is not what happened this time. Instead, the person involved was repeatedly told, in a polite manner, what was being done wrong and which steps to take to start learning how to do things right. This tutoring continued long past the point where it was clear that the message was not getting through. If a dozen (at a minimum) senior kernel developers can be nice (or at least civil) to such a person, things cannot be all bad.

Which, again, is not to say that things are perfect; there is a lot of room for improvement. But the kernel community is not the community that is harassing Lennart, and the people who are behaving that way are not taking their cue from Linus Torvalds. Those people have no need for a prominent leader who has a habit of going over the top with his email; they are going to set out to create grief anyway.

Your editor has been a part of the free software community for well over two decades at this point. The experience has not always been pleasant; it has included abuse, federal lawsuits, and, recently, threats by a prominent developer to circulate fabricated quotes in an attempt to destroy credibility. But overall, despite making a bad habit of being loudly wrong on the net, your editor has found this community to be a rich and welcoming place with a lot to offer. We should not let our glaring problems detract from what we have built over the years. Despite its many problems, our community is not a sick place.

Comments (346 posted)

Google's Physical Web

Google has unveiled the Physical Web, an "early-stage experimental project" designed to adapt the conventions of existing web applications to the world of "smart" objects: everyday devices with an embedded computer and an Internet connection, designed for day-to-day interaction. The central idea is that most of today's smart-object designs require users to interact through separate mobile apps, which makes for a higher barrier to entry and limits the interaction model. By using web concepts like URLs and hyperlinks, the thinking goes, connected objects from parking meters to home appliances will be easier to interact with and to develop for.

The smart objects targeted by the Physical Web appear to be restricted to Internet-connected devices that are designed for users to interact with directly. That category includes vending machines, advertising kiosks, public transportation stops, household appliances, and rental cars, to name a few examples mentioned in the documentation. It does not, however, encompass the entirety of the "Internet of Things" (IoT)—which is also concerned with connected devices.

IoT development projects, in contrast, are most often concerned with linking devices that will communicate with each other, sans human involvement on any regular basis. Temperature and humidity sensors in the rooms and hallways of an office building, for example, would wirelessly relay readings to the building's thermostat. Those devices tend to be discussed as elements that are configured once but rarely altered, and are not generally items that random users would interact with. Not so the Internet-enabled vending machine or ticket kiosk.

The problem with current smart-object products, as the Physical Web introduction page observes, is that currently every product requires installing a separate mobile app in order to be used. Phillips' Hue line of "smart lighting" lightbulbs requires the Hue app, the Nest thermostat requires the Nest app, Belkin's WeMo line of power switches requires the WeMo app, Kwikset's Kevo Bluetooth-connected door lock requires the Kevo app, and so on—and all of those examples are encountered before even leaving home; the problem grows when out in public. And, naturally, each object tends to have its own (often unpublished) API.

Discovery via Bluetooth

The Google team's proposed alternative to the hodgepodge of separate APIs that these products implement is to decide on a simple web-based API instead. Each smart object will have a unique URL, and any user that wishes to interact with the object must do so by first visiting the URL on their client device of choice. Obviously, for such initial contact to be possible, there must be some way for users to find the URL(s) of objects they encounter.

The project's approach to the discovery issue is to have every object broadcast its URL periodically so that nearby users can find it. The initial implementation broadcasts over Bluetooth 4.0 Low Energy (BLE), though the documentation notes that other wireless transport protocols may be usable as well. BLE already defines an "advertising packet" type that devices can use to announce their availability to anybody within range—typically encapsulating some vendor- or device-specific information inside. The Physical Web defines its own higher-level "URL broadcast" packet type, which smart objects would place in the payload of their BLE advertising packet.

A BLE advertising packet includes a two-byte Service UUID field, followed by up to 20 bytes of data. The Physical Web URL-broadcast packet would use the UUID 0xFED8 (which it defines as "URI Device"). Following this, the payload format includes one byte reserved for flags, one byte to report the device's transmit power, and up to 18 bytes for the object's actual URL.

So far, the project has not defined any flags. The transmit power is included so that client devices can weigh the observed power of each object they discover against the device's reported output power and make a rough estimate of which devices are closest and furthest away.

That leaves up to 18 bytes for the URL, which is a fairly confined field. In its documentation, the project says that it believes several techniques can be employed to shrink URLs so that they fit. First, URL-shortening services (e.g., tinyurl.com) can be used to create shorter addresses. Second, even on a short address, compression techniques like entropy coding can be used to make the result compact. For example, only the "important" parts need to be encoded (for example, leaving off http://www. and .com saves several bytes without sacrificing information). The documentation notes that similar space-saving techniques are already used when encoding URLs in QR codes, to great effect. That said, the documentation also posits that a Bluetooth Generic Attribute Profile (GATT) service for automatically shortening URLs could be developed.

Connecting to a web app

However the URL is encoded, though, the Physical Web also dictates that the page found at the broadcast URL must return some additional information: a title for the object, a description field, a favicon, and one or more additional URLs that client devices can use to interact with the object for real.

So, for example, the smart parking meter might broadcast a URL that decodes to http://www.example.com/prk?12345, with 12345 being the serial number of the particular meter. A user's smartphone would fetch the broadcast URL, getting back a long-form name and a secondary URL useful for authenticating, checking the remaining time on the meter, or making a payment.

In essence, though, after the initial discovery is complete, the entire session between the client device and the object turns into little more than standard web-application interaction. Most of the complexity from the client's (and, thus, the user's) perspective boils down to how best to manage the presentation of potentially dozens or hundreds of smart objects visible at any given moment.

To that end, the Physical Web proposes that client devices should maintain a running list of visible objects, but should not present notifications or alerts to the user for every new discovery. Whenever the user is interested in beginning a transaction, the presumption is that the object in question will be relatively close by, so sorting the list by approximate distance, by which devices that have been used in the past, and other simple metrics will make sense out of the chaos.

The documentation also suggests that remote web services could be employed to help the client prioritize which objects are likely of interest. The no-notifications policy is evidently a contrast with Apple's iBeacon framework, which is also designed to connect mobile devices to smart objects. It should come as no surprise, though, that Apple is interested in an app-driven interaction model, rather than a web-driven one.

There are also several security questions of interest with the Physical Web scheme. First, the broadcast-only nature of smart objects means that the objects will not be connecting to (and thus logging) every device that passes by. A user's smartphone can note objects without responding to any of the advertisement packets.

On the flip side, broadcasting advertisement packets also raises another specter: attackers cataloging all of the active devices in a given area—perhaps to mount some other form of attack if one of the identified devices has a known security hole. The project argues that devices that advertise shortened URLs already have one form of obfuscation working for them; further obfuscation could be employed on the secondary URL (that is, the one that the broadcast URL points the user toward) if the device makers so chooses. Furthermore, the web interface running at the secondary URL could enforce additional access restrictions, like requiring a login or pointing to an IP address (e.g., foo.local) that is only reachable when connected to the same LAN as the device.

What next?

At this stage, of course, it is not easy to put the ideas of the Physical Web project to the test. There is both an Android and an iOS app available for download (both of which are open source) that will monitor for broadcast URL advertisement packets and present them to the user, but there are no such smart objects in the wild making broadcasts to discover. Hardware hackers can evidently build their own using the RFduino, a diminutive microcontroller that runs on battery power and is Arduino-compatible. But it will likely be a long time before production devices hit the market to test the broadcast-and-web-API concept in its entirety.

In the long run, the greatest challenge to the Physical Web proposal may be the difficultly of persuading device makers to drop the one-app-per-device development model and move to web-applications. It may be cheaper and simpler for a company to write one web application than to write two or more apps, but device makers also seem to love the lock-in that a dedicated app provides. Google could take the initiative with some of its own smart-object products (such as the Nest line), but a decision like that is likely to be far removed from the current experimental state of the Physical Web.

Comments (9 posted)

NVIDIA sues Samsung and Qualcomm

Last month, NVIDIA announced two patent infringement actions against Samsung and Qualcomm. Both actions claim infringements of the same seven patents, which read on basic GPU functionality. This litigation could chill development in the graphics hardware world and certainly can't make those considering opening up their graphics device drivers particularly comfortable.

Negotiations with Samsung for a licensing agreement of NVIDIA's patents allegedly broke down after the Korean multinational company blamed its hardware suppliers (e.g. Qualcomm) for infringing. As NVIDIA wrote in its announcement, "Samsung repeatedly said that this was mostly their suppliers' problem". That led to NVIDIA pursuing legal action against both Samsung and Qualcomm. NVIDIA has complained [PDF] to the International Trade Commission (ITC) and has begun a lawsuit [PDF] in the US District Court for the District of Delaware.

Let's begin with the complaint at the ITC, which is a US administrative body that handles complaints about unfair competition in international trade as defined by law. One type of unfair competition is patent infringement. One remedy the ITC can award successful complainants is a ban on the importation of the infringing products. It does not have the authority to award damages (i.e. money). Indeed, on page 1 and 2 of NVIDIA's complaint, the company described its aims as:

Which processors and devices in particular? NVIDIA has a non-exhaustive list of Qualcomm products: "These processors include Qualcomm's Snapdragon processors using Adreno GPUs" (page 12). NVIDIA also alleges that "Samsung's Exynos processors," which "use Mali GPUs or PowerVR GPUs", found in several of its mobile devices, are infringing (page 3). The company also lists Samsung products, which "include, but are not limited to, mobile products such as mobile phones (including the Galaxy Note 4, Galaxy Note Edge, Galaxy S5, Galaxy Note 3, and Galaxy S4) and tablet computers (including the Galaxy Tab S, Galaxy Note Pro, and Galaxy Tab 2)".

In the lawsuit, NVIDIA makes the same allegations about the same products, but here seeks "injunctive relief and damages" (meaning a ban on the manufacture and sale of these products) and money from Samsung and Qualcomm.

Now let's look at the patents themselves:

6,198,488: "Transform, lighting and rasterization system embodied on a single semiconductor platform" (filed in 1999). This patent describes a graphics pipeline consisting of a coordinate-transformation module, a lighting module, and a rasterizer, all on the same chip and where multiple threads of execution can run simultaneously.

6,690,372: "System, method and article of manufacture for shadow mapping" (filed in 2000). This patent describes a basic approach to generating a shadow from a primitive: calculate shading once, and use the result of that first calculation to make another shading calculation. Different color values can be used in those calculations.

6,992,667: "Single semiconductor graphics platform system and method with skinning, swizzling and masking capabilities" (filed in 2003). This patent describes dedicated graphics hardware, containing the structure mentioned in the '488 patent, with an added skinning ability (for skeletal animation), an added swizzling ability (vector element rearranging), and/or an added masking ability (to conduct bitwise operations on graphics data).

6,697,063: "Rendering pipeline" (filed in 1997). This patent describes an algorithm for determining the visibility of a number of graphic elements by calculating their x, y, and z coordinates and comparing them.

7,015,913: "Method and apparatus for multithreaded processing of data in a programmable graphics processor" (filed in 2003). This patent describes ways to process graphics commands in an order different from what was received in order to reduce visual artifacts.

7,038,685: "Programmable graphics processor for multithreaded execution of programs" (filed in 2003). This patent describes ways to schedule multithreaded graphics processing.

7,209,140: "System, method and article of manufacture for a programmable vertex processing model with instruction set" (filed in 2000). This patent describes the function of a graphics processing unit (GPU) and the use of programs on it for transforming and lighting the graphics objects it handles.

For Samsung and Qualcomm to prevail (should a settlement not be reached), they would have to prove that the ideas described in the patents were not novel, were obvious to an average person having skill in the relevant art before the patents were filed, were not useful, or that the companies were not using the techniques claimed. The ideas described in the patents are indeed useful for generating graphics, so that defense would be difficult to employ. Samsung and Qualcomm's legal teams will have to defend based on the other three factors.

To win on lack of novelty, they would have to demonstrate that the ideas in the patents had been made public, or had been embodied in a product that was being sold to or used by the public more than a year before the filing date. To win on obviousness, they would need to show that given the prior art before the filing date, a graphics hardware professional with "average" skill in their profession would have found the patents to be an obvious next step in graphics hardware development. To win on the third factor, they would have to prove that they were not practicing the claimed inventions.

Although the Supreme Court's recent judgment in Alice has tightened up the patentability of computer-related ideas, this ruling will not likely pose a threat to NVIDIA's patents. Alice effectively prohibited "just-do-it-on-a-computer" patents, which take an abstract concept long-practiced without computers, like calculating financial risk, and adding a computer to merely accelerate or automate the practice. NVIDIA's patents, which relate to actual claimed improvements in computer hardware itself, are largely immune to an Alice-style challenge.

Those interested in timelines for these processes may not be surprised to hear that they may be drawn-out actions. The ITC decided on October 6 that it will investigate NVIDIA's complaints. This can take anywhere from months to years; we will find out by the end of November when the ITC estimates its investigation will finish. It can take longer if either or both parties decide to make various procedural motions. Those interested in keeping up with the ITC action can look to this web page to stay up-to-date. The worst outcome for Qualcomm and Samsung here is a US ban on importing and selling the devices that NVIDIA complained about.

The Delaware action may also be lengthy; one can expect time-consuming motions back and forth from both sides. Add to that the drafting and filing of briefs and memoranda, a pretrial conference, discovery, depositions, and oral arguments (not to mention any requests for deadline extensions), and we could be a year or more away from a trial (if it comes to that). The worst outcome for Qualcomm and Samsung here is a US ban on selling the devices NVIDIA complained about along with a hefty damages payment to NVIDIA.

This is shaping up to be yet another long battle in the mobile-device patent wars. Samsung has stated that it is unconcerned and will fight back (Qualcomm has not yet made a statement). ARM CEO Simon Segars also noted that the company may reach out to Qualcomm and Samsung to help them: "To the extent that we need to, we absolutely work with our partners when something like this happens".

It's true that this litigation is aimed at commercial distributors of graphics hardware using proprietary, closed-source drivers. However, one can imagine that graphics hardware developers ambivalent about opening up their device drivers may become even more reluctant. With NVIDIA publicly stating in its announcement how common it is for it to demand payment for licensing ("Our IP strategy is to earn an appropriate return on our investment by licensing our graphics cores and by licensing our patents. In each case, we start with a negotiation"), one could understand the reluctance of GPU manufacturers to disclose anything that could open them up to litigation. Nevertheless, trying to hide (as Qualcomm and Samsung have done with their closed-source drivers) has not proved to be a defense either.

Comments (8 posted)