OpenGear Networks
Friday, 22 July 2011
The Unix revolution — thank you, Uncle Sam? By Matthew Lasar
Ars Technica has a nice read[1] on the history of Unix and some inside insights into how it developed and evolved. Here's a brief snippet from the article:
This November, the Unix community has another notable anniversary to celebrate: the 40th birthday of the first edition[2] of Ken Thompson and Dennis Ritchie's Unix Programmers Manual[3], released in November 1971. Producing the document was no easy task, because at that point the Unix operating system grew by the week; budding aficionados added new commands and features to the system on a regular basis.
"The rate of change of the system is so great that a dismayingly large number of early sections [of the text] had to be modified while the rest were being written," Thompson and Ritchie noted in their introduction. "The unbounded effort required to stay up-to-date is best indicated by the fact that several of the programs described were written specifically to aid in preparation of this manual!"
That's why Unix timelines are fun to read—they give a sense of how quickly the system collaboratively evolved. But some of them either skip[4] or mention without explanation[5] a government decision that, in retrospect, paved the way not only for Unix, but perhaps for the open source movement as well: the 1956 Consent Decree between the United States Department of Justice and AT&T.
Read on for the full article at arstechnica.com[1].
URL[1]: http://arstechnica.com/tech-policy/news/2011/07/should-we-thank-for-feds-for-the-success-of-unix.ars
URL[2]: http://www.cs.bell-labs.com/who/dmr/1stEdman.html
URL[3]: http://cm.bell-labs.com/cm/cs/who/dmr/manintro.pdf
URL[4]: http://www.unix.org/what_is_unix/history_timeline.html
URL[5]: http://www.computerworld.com/s/article/9133628/Timeline_40_years_of_Unix
Debian has a nice write up on all things patents. It's a good overview of the patent system especially as applied to software in general and FOSS (like Debian) in particular. Definitely worth reading.
Here's a blurb from the page[1]:
Community Distribution Patent Policy FAQ
Introduction
For whom is this document intended?
This document presents information about patents and patent liability useful for developers working on community distributions of Free and Open Source Software (FOSS). By community distributions, we mean collections of free software packages maintained and distributed by organizations composed of volunteers, where neither the organization nor the volunteers seek to make a profit from the activity. Such community-based distributions may sell as well as give away their work product, possibly on CDs or USB storage media or by paid-for downloads as well as by gratis distribution.
This document has been prepared by lawyers at the Software Freedom Law Center (SFLC) at the request of the Debian project, and may be helpful to similar community FOSS distributions. Its statements about legal matters are accurate as of the date of composition regarding US law, and may be applicable to other legal systems. But this document does not constitute legal advice. It has not been based on analysis of any particular factual situation, and any lawyer providing an opinion on the questions presented below would need to ascertain the particular facts and circumstances that might vary this information in a particular setting. You should not rely upon this document to make decisions affecting your project’s legal rights or responsibilities in a real-life situation without consulting SFLC or other lawyers.
URL[1]: http://www.debian.org/reports/patent-faq
Tuesday, 12 July 2011How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History
Wired[1,2] has a really nice long write up on Stuxnet and how it was deciphered. It's a long and detailed article and makes for quite nice reading.
Bruce Schneier has also commented on it[3] as has Slashdot[4]. Sans also has coverage in their newsletter[5] along with some useful links[6,7].
Here's a blurb from the Wired article:
It was January 2010, and investigators with the International Atomic Energy Agency had just completed an inspection at the uranium enrichment plant outside Natanz in central Iran, when they realized that something was off within the cascade rooms where thousands of centrifuges were enriching uranium. Natanz technicians in white lab coats, gloves and blue booties were scurrying in and out of the “clean” cascade rooms, hauling out unwieldy centrifuges one by one, each sheathed in shiny silver cylindrical casings.
Any time workers at the plant decommissioned damaged or otherwise unusable centrifuges, they were required to line them up for IAEA inspection to verify that no radioactive material was being smuggled out in the devices before they were removed. The technicians had been doing so now for more than a month.
“We were not immune to the fact that there was a bigger geopolitical picture going on. We were definitely thinking … do I really want my name to be put on this?” – Eric Chien
Normally Iran replaced up to 10 percent of its centrifuges a year, due to material defects and other issues. With about 8,700 centrifuges installed at Natanz at the time, it would have been normal to decommission about 800 over the course of the year.
But when the IAEA later reviewed footage from surveillance cameras installed outside the cascade rooms to monitor Iran’s enrichment program, they were stunned as they counted the numbers. The workers had been replacing the units at an incredible rate — later estimates would indicate between 1,000 and 2,000 centrifuges were swapped out over a few months.
The question was, why?
To find the answers, read on... [1].
URL[1]: http://www.wired.com/threatlevel/2011/07/how-digital-detectives-deciphered-stuxnet/all/1
URL[2]: http://www.wired.com/threatlevel/2011/07/stuxnet-timeline/
URL[3]: http://www.schneier.com/blog/archives/2011/07/history_of_stux.html
URL[4]: http://news.slashdot.org/story/11/07/11/1958249/How-Investigators-Deciphered-Stuxnet
URL[5]: http://www.sans.org/newsletters/newsbites/newsbites.php?vol=13&issue=55#sID300
URL[6]: Long Link [www.win32virusremoval.com]
URL[7]: Long Link [www.telegraph.co.uk]
Microsoft’s Android Shakedown - Timothy Lee - Disruptive Economics - Forbes
Forbes has a take[1] on the Patent system - nothing new here except that it's probably a lot more eye catching than the usual rants on Slashdot, considering the audience Forbes enjoys.
There's also this[2] from Ars Technica, a book review that is related to the same issue but a "Timothy B Lee" who could probably be the same person.
Will anything come of it? Keep hoping... Meanwhile here are a few snippets from [1]:
This story sheds light on the recent string of stories about Microsoft demanding royalty payments from various companies that produce smart phones built on Google‘s Android operating system. Intuitively, this doesn’t make much sense. Most people would say that Google has been more innovative than Microsoft in recent years—especially in the mobile phone market—so why is Microsoft the one collecting royalties?
The reason is that Microsoft has more patents than Google. A lot more. The patent office has awarded Google about 700 patents in its 13-year lifetime. Microsoft has received 700 patents in the last four months. Microsoft’s total portfolio is around 18,000 patents, and most of those were granted within the last decade.
Even if you think Microsoft is more innovative than Google, the engineers in Redmond obviously haven’t been 25 times as innovative as those in Mountain View. So why the huge discrepancy?
Getting software patents takes a lot of work, but it’s not primarily engineering effort. The complexity of software and low standards for patent eligibility mean that software engineers produce potentially patentable ideas all the time. But most engineers don’t think of these relatively trivial ideas as “inventions” worthy of a patent.
Creating such a bureaucracy has a high opportunity cost for small, rapidly growing companies. Most obviously, it requires spending scarce capital on patent lawyers. But it also means pulling engineers away from doing useful work to help lawyers translate their “inventions” into legal jargon. And that, in turn requires a shift in corporate culture. Startups are innovative precisely because they avoid getting bogged down in paperwork. Convincing engineers to pay more attention to patent applications necessarily means that they spend less time doing useful work, and that can be fatal to a young startup.
The opportunity costs to getting patents is much lower for mature software companies like Microsoft or IBM. They tend to have more money and engineers than they know what to do with. And their software development processes are already slow and bureaucratic. So it’s much easier to add a “fill out patent applications” step to the official software development process, and the negative effect on engineers’ productivity is much smaller.
URL[1]: http://blogs.forbes.com/timothylee/2011/07/07/microsofts-android-shakedown/
URL[2]: http://arstechnica.com/old/content/2008/07/book-review-7-08.ars
CWE - 2011 CWE/SANS Top 25 Most Dangerous Software Errors
A nice detailed list on the top security issues related primarily to software most of which can and should be addressed during development. With some good security practices and education, most developers and processes should be able to handle these kinds of issues as part of their development cycle.
Here's a brief excerpt from the site[1]:
The 2011 CWE/SANS Top 25 Most Dangerous Software Errors is a list of the most widespread and critical errors that can lead to serious vulnerabilities in software. They are often easy to find, and easy to exploit. They are dangerous because they will frequently allow attackers to completely take over the software, steal data, or prevent the software from working at all.
The Top 25 list is a tool for education and awareness to help programmers to prevent the kinds of vulnerabilities that plague the software industry, by identifying and avoiding all-too-common mistakes that occur before software is even shipped.
URL[1]: http://cwe.mitre.org/top25/index.html