Talks at linux.conf.au often cover a wider range of topics than those held
at many other Linux-related events, and LCA 2012 was no exception. The
final keynote at this conference was from Jacob Appelbaum, a lead developer
of the Tor project
no-holds-barred session took an uncompromising look at surveillance and
censorship and the people behind them. It was a strong call for action -
and for more free software -
from a courageous man who clearly lives by the words written on his
T-shirt: "be the trouble you want to see in the world."
We live, Jacob said, in a surveillance society. We don't really live in
independent states anymore; instead, we live in different surveillance
cones on a surveillance planet. Increasingly, the world resembles the Panopticon, a prison
designed in 1786. Anybody who thinks otherwise need only look at, for
example, the widespread warrantless wiretapping of US citizens with AT&T's
help under (at least) the Bush administration. We are, indeed, being
There are a number of coping strategies that we all adopt in the face of
this kind of surveillance, starting with the specious claim that "I have
nothing to hide." The fact that the attendees decided to put clothes on
before going to the conference that morning (a decision your editor, at least,
much appreciates) demonstrates otherwise. Or we say that yes, people are
watching, but bad things will never happen to us personally. Which is a
fine position until something does happen.
The problem with this kind of surveillance structure, according to Jacob,
is that "it attracts assholes." Once this machinery is put into place, it
will be put to bad uses regardless of its original intent. For example,
the "Echelon" spy network was put into place as part of the cold war, but
it was also alleged to be used to, for example, funnel information to
Boeing to be used to win aircraft orders.
Many (or most) countries allow for "lawful" interception of some
communications by governments without a warrant. Traffic data for phone
calls or text messaging, for example, falls under this umbrella. It's said
not to be "content" that requires a warrant to access, but it still tells a
story about a person and will be abused by governments. We need to make it
harder for governments to get at this data.
But it gets worse. The switches at the core of the phone system and the
Internet all have governmental backdoors built into them. Sometimes those
backdoors are more widely used than intended; Jacob recommended reading The
Athens Affair, an IEEE article about the use of surveillance backdoors
to spy on the Greek government (and many others). These backdoors are an
attractive target, to the point that the operators of these systems should
think hard about what their lives are worth; the man in charge of planning
the Greek Vodafone-Panafon network died suspiciously as the compromise of
that network was discovered.
Jacob played a video advertisement for the "FinFly" device, meant to be
installed in an Internet provider's equipment rack. The FinFly is a highly capable
man-in-the-middle attack device, able to pick out traffic associated with
specific targets, record it, and even install malware on the target's
systems. This device, sadly, is built on top of the Backtrack-Linux distribution.
Among its customers was the former government of Egypt, which used it
against pro-democracy activists there. Jacob does not want to live in a
world where governments can do things like that.
FinFly is just the beginning; there is a whole range of products designed to meet the needs
of the surveillance state. Quite a bit of information about this
particular area of commerce can be found in the Spyfiles release from
WikiLeaks. There is a lot of money to be made in surveillance equipment,
but the companies involved should be held culpable for the uses to which that
equipment is put.
Pervasive surveillance allows the government to put together a picture
about almost anybody. That picture is based on facts, but may still not be
true. But it is useful for the purposes of control, enforcement of power
structures, and harassment. Jacob knows that latter aspect well, having
been detained several times, threatened with jail, and subjected to
seizures of his electronic equipment.
Along with surveillance goes censorship - the determination by people in
power that there are things they do not want others to know. Practices
like Internet filtering are designed to promote ignorance and
retain power. It's done in lot of different ways. There is the famous
great firewall of China, which, he said, is more of a spider web catching
those who try to stray beyond the boundaries. In the US, censorship is
accomplished through "legal threats and illegal tactics." In Lebanon, the
national firewall uses a version of squid - a good thing, Jacob said, since
they haven't gotten around to patching it for a long time. In Syria,
off-the-shelf products are used. And so on.
Not all censorship is equal, and it is often easy to bypass. But
censorship, combined with surveillance, often leads to self-censorship.
The net was not built to make us fear our own state, but that is what is
happening. When a company like Google is frightened by a law like SOPA, we
should all be scared; Richard Stallman's The Right to
Read was not meant to be a manual.
History has shown us over and over again that people with power
will turn into thugs. The Stanford
prison experiment also demonstrated that quite clearly. With so much
experience in this area, why is it that we keep repeating the experiment?
The good news, according to Jacob, is that we have the power to change
things. And, in particular, we can challenge surveillance and censorship
with anonymity. The American revolution was fueled by anonymous pamphlets
that could be circulated without their authors ending up in prison. We
need the ability to distribute anonymous pamphlets in this century as well.
So what can we do? We need to reframe the issues so that freedom and
openness come first. We need to observe - and report on - surveillance
and censorship on the net. We should write more free software and get more
people to use it, and everybody writing software should be thinking about
their users' freedom and security. Free software needs to be free as in
freedom, though; "open source for business" is not the same thing.
He looks forward to the day when the
only binary blob running on his system is the government rootkit.
Tor is one piece of the puzzle, certainly, but there are others. Jacob
which allows encrypted text messaging between Android phones, as an
important piece of freedom-related technology. He also called out FreedomBox, the GNOME project, the Ada Initiative (what does freedom mean,
he asked, if half of our population is oppressed?), and the Electronic Frontier Foundation.
In the end, he said, it comes down to freedom for everybody - no
exceptions. But that is not how the surveillance state works. Securing
that freedom will require a dedication to open standards, open designs,
free software, free hardware, and decentralization. We can, he said, push
back the surveillance state and create for ourselves an accountable
government and freedom for all.
[Your editor would like to thank the LCA 2012 organizers for assisting with
his travel to the event.]
Comments (27 posted)
Your editor is still recovering from his journey home from Ballarat,
Australia, where the 2012 linux.conf.au was held. The richness of this
event can be seen in the numerous articles already published here; this
article will attempt to cover a variety of talks that, for various reasons,
did not turn into articles of their own.
Freedom is always a strong theme at LCA, and the 2012 version was no
exception. That emphasis tends to be especially strong in the keynote
talks, as should be clear from the reports on the keynotes by Bruce Perens and Jacob Appelbaum. Karen Sandler's keynote was
just as concerned with freedom and just as noteworthy; it would have
merited an article of its own had we not covered some of her topics from
another talk back in 2010. Karen retold
her chilling story of trying to get access to the source code for an
implanted device designed to protect her from abrupt heart failure. Not
only is that source not available to her; even the regulatory agency in the
US (the FDA) charged with approving the device normally does not review the
code. The presence of catastrophic bugs seems guaranteed.
In addition to simple worries about whether the device will work as
needed, there is another concern: these devices are increasingly given
wireless communications capabilities that allow them to be reconfigured and
controlled remotely. To the extent that the security associated with that
access can be verified, it seems to be notable mostly in its absence. In
other words, implanted medical devices would appear to be open to a variety
of denial of service attacks with extreme consequences. Given that some of
them are implanted into important people (she named Dick Cheney who, as a
result of his implanted device, no longer has a pulse), it only seems like
a matter of time until somebody exploits one of these vulnerabilities in a
high-profile way. Karen noted dryly that, given the type of people she
hangs around with, it would be unwise to expose herself to such attacks; she
went out of her way to get an older device with no wireless connectivity.
She pointed out that a lot of other safety-critical devices - automotive
control systems were mentioned in particular - have similar problems. The
solution to the problem is clear: we need more free software in
safety-critical applications so that we can all review the code and
convince ourselves that we can trust our lives to it. And that, she said,
is why she made the move to the GNOME Foundation. GNOME's work to make
free software usable and attractive in current and future systems is, she
said, an important part of getting free software adopted in places where we
need it to be.
Another theme at LCA has always been represented by the maker
contingent: whether it's Arduino, rockets, robots, or home automation, the
people who make their own toys always turn out in force at LCA. Notable
among a strong set of maker-oriented talks was "Rescuing Joe" by Andrew
"Tridge" Tridgell. The challenge here is to make an autonomous aircraft
that can search a defined area for a lost bushwalker ("hiker," in US
dialect), drop a water bottle nearby (without hitting him), then return
safely back to its landing point. This challenge has been run for a few
years, but nobody has yet fully achieved its goals; Tridge's team hopes to
be the first to succeed.
Getting there requires the design of a complex system involving autonomous
avionics, an independent failsafe mechanism that will crash the plane if it
leaves the search area, computer vision systems to locate the hiker,
mechanical systems to reliably drop the water bottle in the desired
location, and high-bandwidth digital communications back to the launch
base. The test systems currently run with a combination of Pandaboard and
Arduino-based systems, but the limitations of the Arduino are becoming
clear, so the avionics are likely to move to another Linux-based Pandaboard
in the near future.
This project requires the writing of a lot of software, most of which is
finding its way back upstream. The hardware requirements are also
significant; Tridge noted that the team received a sophisticated
phased-array antenna as a donation with a note reading "thanks for rsync."
All told, "challenge" appears to not even begin to describe the difficulty
of what this team has taken on. The whole talk, done in Tridge's classic
informative and entertaining style, is well worth watching.
Rusty Russell and Matt Evans recently took a look at V6 Unix, as
built for the PDP-11, and noted something obvious but interesting: it was a whole lot
smaller than the systems we are running now. The cat binary on
that system was all of 152 bytes - in an era when everything was statically
linked - while cat on Ubuntu 11.10 weighs in at 47,696 bytes - and
that is with dynamic linkage. We
have seen similar growth in grep (2,190 bytes to 151,056) and
ls (4,920 bytes to 105,776). So they asked: where is all this
growth coming from, and what did we get for it?
What followed was an interesting look into how Unix-like systems have
changed over the years; watching the video is well recommended. Their
first observation was that contemporary binaries could be reduced in size
by about 30% by using the GCC -Os option, which causes the
compiler to optimize for size. In other words, we are paying a 30% size
penalty in order to gain some speed; the actual speed benefit they measured
was about 9%. But there is a lot more to it than that.
A simple program consisting of a single "return 42;" line on
Ubuntu will, when build statically, weigh in at about 500,000 bytes. Rusty
and Matt determined that this program, which makes no direct C library
calls, was pulling in about 17% of glibc anyway. Even the simplest
program, anymore, must make provisions for dynamic loading,
atexit() handling, proper setuid behavior, and more. So the
program gets huge but, in this case, only about 2% of the pulled-in code
actually gets run. In general, they found, most of the code dragged in by
contemporary programs is simply wasted space. That waste can be reduced
considerably by linking against dietlibc instead of glibc, though.
How much does 64-bit capability cost? An amusing exercise in porting the
V6 code to the imaginary 64-bit "PDP-44" architecture increased its size by
about 50%; the size difference between 32-bit and 64-bit Ubuntu programs is
rather smaller, at about 9%. Use of "modern infrastructure" (that, for
example, forces malloc() to be used instead of sbrk() in
all programs) bloats things by about 120%. The large growth in features
(ls has 60 options) leads to a massive 440% increase in size; they
also measured a 20% time overhead caused by rarely-used features in
ls. It's worth noting that half of that time cost goes away when
running with LANG=C, leading to the conclusion that locales and
other flexibility built into contemporary systems has a large cost. In the
end, though, these appear to be costs that we are willing to pay.
David Rowe gave a fascinating talk on the development of Codec2, a
speech-oriented codec that is able to produce surprisingly good voice
quality at data rates as low as 1,400 bits/second. To understand the math
involved, one should watch the video. But even without following that
aspect of things, the talk is an interesting discussion of the open
development of a patent-free codec with interesting real-world applications
- sufficiently interesting that it risked being classified as a munition
and treated like cryptographic code.
In summary, LCA remains unique in its combination of strongly technical
talks, freedom-oriented and hands-on orientation, wide variety of topics
covered, and infectious Australian humor. There is a reason some of us
seem to end up there every year despite the painful air-travel experiences
required. Linux Australia has put together a structure that allows the
conference to be handed off to a new team in a new city every year,
bringing a fresh view while upholding the standards set in the previous
years. With regard to upholding the standards, the LCA 2012 lived up to
expectations in a seemingly effortless manner - it was a job well done
indeed. They have set a high bar for the 2013 team (Canberra,
January 28 to February 2) to live up to.
[ Conference videos can be found
format, and in
WebM. Your editor would like to thank the LCA 2012 organizers for
assisting with his travel to the event. ]
Comments (16 posted)
"World domination" is a less prevalent theme in Linux and open source
discussions these days than it was some time ago, but it still comes up
regularly in one field of study: robots. At the 2012 Southern California
Linux Expo (SCALE) in Los Angeles, Willow Garage's Tully Foote
described the Robot Operating System
(ROS) project, an open source stack for state-of-the-art robotics. ROS is
in use by industry and academic research projects, often on hardware that
runs in the hundreds-of-thousands of dollars range, but it is capable of
running on low end and homebrew robots, too.
Naturally, the ultimate homebrew device automation option is the open source Arduino, which was also on display at SCALE thanks to Akkana Peck and her flying robot shark....
ROS's universal robots
In his talk, Foote illustrated the need for a common, open source platform like ROS by describing his own background in robotics. As a graduate student, he often lamented the fact that interesting developments described in research papers were nearly impossible to re-implement at a different institution because there was no baseline framework on which to build the new bits. As a result, every research group ended up re-building the same infrastructure in a separate silo, slowing down the pace of useful research. The same productivity hit was evident in the DARPA Grand Challenge; Foote and his teammates saw that virtually every successful entrant ran Linux, but they shared no code. The difference between the teams that completed the challenge and those that failed was "a couple of percent" more efficiency in key algorithms, he said — a tiny amount of time compared to the hours spent constructing and debugging the predictable, underlying base layer.
ROS grew out of those concerns. The idea is to provide a reusable meta-framework that researchers can run on their own robot hardware, taking care of low-level services like hardware abstraction, device control (for sensors, actuators, motors, and other robo-building-blocks), and message-passing, and to offer reusable modules for common services like 2D and 3D object recognition and navigation. Developers can incorporate the libraries they need, then write their own code focused on the area of research interest.
Rather than simply design the system and post the code, however, the ROS
team has taken an active interest in cultivating an active community of
robotics researchers and code contributors. There is a thorough documentation site and a
StackOverflow-style question-and-answer site, plus a bug
tracker, IRC channel, and mailing lists. The code is licensed BSD-style,
in order to encourage adoption by commercial research groups in addition to academics.
The plan seems to be successfully attracting developers; the wiki lists more than 400 "stacks," which are installable ROS variants tuned for a specific task, hardware configuration, or research project. Many are marked as being maintained by institutions other than Willow Garage. Willow Garage itself is a "long-term incubator," as Foote described it. The team does its own robotics research as well as developing ROS, in the hopes of making a breakthrough someday that will warrant spinning off a startup company.
Architecture and marathons
Structurally, ROS is a collection of processes that communicate via the
ros_comm middleware layer.
This communication framework is abstracted at the network level, with C++,
Java, Python, and Lisp all equally supported for developing modules.
There are several message-passing paradigms supported, including
synchronous RPC-style services, asynchronous publish-subscribe, and simple
data acquisition. Under the hood, ROS is designed to run on Ubuntu (and
downloads for the current release, "Electric Emys," are packaged only
for Ubuntu), although experimental packages are available for other
distributions, as well as Mac OS X and Windows.
Robotics research is centered on compute-intensive subjects like
computer vision, object-detection, and decision making (rather than simply
programming repetitive tasks like car assembly), rarely manageable by a single CPU. Thus, ROS supports grid-like designs it calls "compute graphs" in which multiple slave compute nodes can talk to each other in peer-to-peer style, as well as report back to a master node. Foote described his team's DARPA Grand Challenge vehicles, which in different generations used everything from six rack-mount servers to a trunk full of Mac Minis. ROS can also run on remote compute nodes that communicate wirelessly to a robot — Foote mentioned that an Android application is in development that will allow users to run ROS on their phones to control small, Roomba-like robots.
A Roomba and an Android phone does not make for a cutting-edge proof of
concept, however, so Willow Garage set out to develop a state-of-the-art
research robot for working with ROS. The result is the PR2, a mobile
(wheeled) robot with stereo vision, two manipulator arms with five
pressure-sensing fingers on each, and an assortment of rangefinders and
other sensors for interacting with the world. The PR2 is powered by
sixteen i7 cores, and has a $400,000 price tag (although Foote said the company offers some level of discount for open source projects).
Foote played videos of several demonstration projects that Willow Garage
undertook, which are available at the bottom of the PR2 page. They included training the PR2 to "run" a 26.2 mile marathon (a problem that seemed to focus largely on teaching the PR2 to notice when it was running low on battery power, find an outlet, and plug itself in to recharge), play pool, and fetch and open bottled beer (determining the brand by visually scanning and interpreting the labels it finds in the fridge).
Nearly half a million bucks is a hefty bill by most standards, but Foote said there are around twenty PR2 units in the field — and that together they result in the publication of more than 100 research papers every year. The ROS community as a whole has expanded the number of software packages available from the initial 200 to more than 3000. Luckily, ROS runs on a range of other robot hardware, including several inexpensive options like the LEGO NXT and Willow Garage's new offering, the TurtleBot. TurtleBot is based on an iRobot Create, augmented with an ASUS netbook, a Microsoft Kinect, and various other sensors. TurtleBot kits are available for between $400 and $1400 (US), depending on how many of the off-the-shelf components are included.
The DIY approach
Foote's talk and PR2 videos wowed the crowd (which strained the capacity of the session room), but so did Akkana Peck's live demonstration of Arduino development in the "Fun With Linux and Devices" talk. Peck described herself as an circuit-building novice, emphasizing that Arduino was a simple way to get into the world of programming hardware devices and robots even for those inexperienced with IDEs and soldering irons.
Peck began with an overview of the Arduino itself, including digital and
analog I/O, programming via USB cable, and the various options for power
(USB-supplied, battery, and AC adapter). She then explained the Arduino
software environment and how to compile and upload code. "The first
project is always making the LED blink," she said, "which is a lot more exciting than it sounds when you finally get yours to blink."
From the blinking LED, she gradually increased the complexity of the projects, including how to interface with devices that draw more power than an Arduino can safely handle, how to read from sensors, and how to write Python code that interfaces with the Arduino's I/O pins — thus allowing the user to monitor and control devices. Along the way, these examples included several live demonstrations, including linking the blinking-LED signal into a series of desk lamps and Christmas tree lights, creating a functioning oscilloscope, and an echolocation rangefinder.
But those projects were only the lead-up to the main event, Sharkduino: controlling an "Air Swimmers" flying shark from a Linux box. Air Swimmers are helium-filled balloon toys with motorized tails and adjustable ballasts, and can be flown using an infrared remote controller. They are also inexpensive, which makes them a tempting target for an Arduino automation project. In addition, the infrared controller is more limited in functionality than a typical radio-controlled airplane or helicopter, making it ripe for hacking. Peck said she considered attaching a small Arduino directly to the shark, but ultimately chose to connect to it via the remote in the interest of making flying-shark-run-amok a less likely outcome.
The project involved dissecting the infrared remote, getting help from
the Arduino community on what sort of circuits to attach to the remote
control's switches, and writing a Python application to run on the desktop.
The end result allows the user to fly the shark by moving the mouse up,
down, left, or right. It may not shoot lasers yet (to Dr. Evil's certain dismay), but
"Bruce" (as the shark is evidently named) was still a hit with young and
old alike in the audience.
Along the way, Peck included tips on where to find Arduino components, how to ask for help from the Arduino community, and how the platform compares to BeagleBoard, RaspberryPi, and other rapid-prototyping products. All of the code demonstrated in the session (including the Sharkduino application) is available on Peck's personal web site, along with the session slides.
Penguin overlords not far behind
In some ways, ROS and Arduino could not be further apart. ROS is
developed (although not exclusively) on expensive specialty
hardware, while Arduino boards come as cheap as seven dollars (thanks to
the open hardware plans).
ROS is designed for complex, compute-intensive tasks, while Arduino is
designed to be as simple as possible. But in the more fundamental sense,
they serve the same goal: to provide a reliable, common platform on which
others can experiment and innovate. Neither could accomplish that as
effectively if they were proprietary, closed-source projects.
Willow Garage's TurtleBot promises to bring brainy robotics to the hobbyist market (while giving those hobbyists the same reliability and service that research institutions already enjoy), which should have an interesting effect on the ROS project and its community. And if the thought already occurred to you that a low-cost ROS robot outfitted with an Arduino-controlled sensor board sounds like an intriguing platform for exploration — why yes, there are several modules to do exactly that.
Comments (4 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: Security processes and the X.org flaw; New vulnerabilities in bugzilla, emacs, kernel, xkeyboard-config, ...
- Kernel: /proc/PID/mem; The zsmalloc allocator; XFS: the filesystem of the future?
- Distributions: SCALE: The road ahead for automotive Linux and open source; Ubuntu, Cinnamon, ...
- Development: Porting office suites to mobile platforms; GDB, Goptical, KDE, Suricata, ...
- Announcements: WebOS roadmap, lca videos, IPv6 launch, FOSDEM, ...