Slashdot Mirror

eldavojohn writes "Earlier this month, a United States piracy list fingered China, Russia, and Canada as the first, second and third worst governments (respectively) for enforcing copyright policy in the world. China's Foreign Ministry has rejected these claims as 'groundless' just before meeting with Secretary of State Hillary Clinton and Treasury Secretary Timothy Geithner on Monday and Tuesday in Beijing to address copyright policy. The official Chinese statement read, 'The involved US Congress members should respect the fact and stop making groundless accusations against China.' The plan nevertheless remains to use the visit to pressure China into overhauling its failed attempts to curb piracy, since software piracy in China appears to be a social norm, with the Chinese government possibly even leading by example."

eldavojohn writes "Earlier this month, a United States piracy list fingered China, Russia, and Canada as the first, second and third worst governments (respectively) for enforcing copyright policy in the world. China's Foreign Ministry has rejected these claims as 'groundless' just before meeting with Secretary of State Hillary Clinton and Treasury Secretary Timothy Geithner on Monday and Tuesday in Beijing to address copyright policy. The official Chinese statement read, 'The involved US Congress members should respect the fact and stop making groundless accusations against China.' The plan nevertheless remains to use the visit to pressure China into overhauling its failed attempts to curb piracy, since software piracy in China appears to be a social norm, with the Chinese government possibly even leading by example."

eldavojohn writes "People in mainland Louisiana are seeing the beginnings of the oil's full effects on wildlife in the area. Sticky, rust-colored oil covers the reeds like a latex paint, indicating that the efforts to lay miles of floating booms to keep it away from the fragile marshes are useless. They are experiencing what the Plaquemines (mouth of Mississippi River) saw last week, and it now appears that their defenses were inadequate. Only time will tell how much worse it can get as BP still scrambles for a solution. NPR also ran a story critical of Obama's 'scientific approach' that he promised to use in office and how well it's being applied and holding up during this crisis."

suraj.sun sends in a followup to a story we've been following about the Texas Board of Education's efforts to put a more political spin on some of their state's textbooks. From the Dallas Morning News: "In a landmark move that will shape the future education of millions of Texas schoolchildren, the State Board of Education on Friday approved new curriculum standards for US history and other social studies courses that reflect a more conservative tone than in the past. Split along party lines, the board delivered a pair of 9-5 votes to adopt the new standards, which will dictate what is taught in all Texas schools and provide the basis for future textbooks and student achievement tests over the next decade. Texas standards often wind up being taught in other states because national publishers typically tailor their materials to Texas, one of the biggest textbook purchasers in the country. Approval came after the GOP-dominated board approved a new curriculum standard that would encourage high school students to question the legal doctrine of church-state separation — a sore point for social conservative groups who disagree with court decisions that have affirmed the doctrine, including the ban on school-sponsored prayer."

Socguy writes "With the announcement earlier this week that a team of researchers has created the first artificial life, The Economist has been pondering the implications of what this brave new frontier means when the power to build living organisms filters through to anyone with a laptop. Traditional methods of restricting and regulating dangerous technology have more or less worked so far, but The Economist thinks that this time may be different. They are calling for an open system where the 'good guys' can see and counter any dangerous organisms that are released, accidentally or otherwise."

1sockchuck writes "Iceland's supply of renewable power has gained a high-profile international data center customer. Web browser developer Opera Software was announced today as the first customer of the Thor Data Center, which will house Opera's servers in data center containers that can use fresh air cooling, rather than chillers (a strategy also used by Google). The Thor Data Center is located in Hafnarfjorour, to the west of Iceland's ash-spewing volcano. Iceland's data center operators insist their location represents no operational risk from volcanic activity."

1sockchuck writes "Iceland's supply of renewable power has gained a high-profile international data center customer. Web browser developer Opera Software was announced today as the first customer of the Thor Data Center, which will house Opera's servers in data center containers that can use fresh air cooling, rather than chillers (a strategy also used by Google). The Thor Data Center is located in Hafnarfjorour, to the west of Iceland's ash-spewing volcano. Iceland's data center operators insist their location represents no operational risk from volcanic activity."

An anonymous reader writes "After evolving over 15 years to get to 1.0, a mere 2 years later and Wine 1.2 is just about here. There have been many many improvements and plenty of new features added. Listing just a few (doing no justice to the complete change set): many new toolbar icons; support for alpha blending in image lists; much more complete shader assembler; support for Arabic font shaping and joining, and a number of fixes for video rendering; font anti-aliasing configuration through fontconfig; and improved handling of desktop link files. Win64 support is the milestone that marks this release. Please test your favorite applications for problems and regressions and let the Wine team know so fixes can be made before the final release. Find the release candidate here."

FleaPlus writes "As part of its new plans, NASA has outlined the initial series of large-scale 'flagship' technology demonstration (FTD) missions for developing and testing technologies needed for sustainable beyond-Earth exploration, complementing the smaller-scale ETDD missions outlined previously. The first four FTD missions (costing $400M-$1B each, about the cost of the recent Ares I-X suborbital rocket launch) are scheduled to launch between 2014 and 2016, demonstrating advanced in-space propulsion (next-generation ion propulsion and solar arrays), in-space propellant transfer and storage, a lightweight/inflatable mission module at the ISS (which will also test closed-loop life support), and an inflatable aeroshell for aerocapture at Mars. A multi-purpose robotic rendezvous and docking vehicle will also be developed to support these missions."

eldavojohn writes "So far every attempted fix has resulted in failure to contain the Gulf of Mexico oil spill with the exception of the riser insertion method that appears to be little more than a mile-long tube sucking up oil. After attempting many options to allow the continued collection of crude oil, BP is finally considering a 'top kill' option that will kill the well. A vessel at the surface will use 30,000 horsepower pumps to slam kill mud and clay into the well's bent riser, allowing them to cap the well off with two relief wells (which won't be ready for several months). If that fails, the vessel will move on to a 'junk shot' that involves spewing larger debris like shredded rubber and golf balls into the lines to gum up the flow and stop it. Government officials acknowledge that while this may provide a solution, it may also worsen the situation if the resulting pressure causes the lines to blow or fail at other points. While this is likely one of the worst environmental disasters to hit the gulf, BP's debacle has caused Shell to pre-build cofferdams into seven wells that it is currently drilling in the gulf. These would drop into place in the event of such a catastrophic failure of a riser under the well."

eldavojohn writes "So far every attempted fix has resulted in failure to contain the Gulf of Mexico oil spill with the exception of the riser insertion method that appears to be little more than a mile-long tube sucking up oil. After attempting many options to allow the continued collection of crude oil, BP is finally considering a 'top kill' option that will kill the well. A vessel at the surface will use 30,000 horsepower pumps to slam kill mud and clay into the well's bent riser, allowing them to cap the well off with two relief wells (which won't be ready for several months). If that fails, the vessel will move on to a 'junk shot' that involves spewing larger debris like shredded rubber and golf balls into the lines to gum up the flow and stop it. Government officials acknowledge that while this may provide a solution, it may also worsen the situation if the resulting pressure causes the lines to blow or fail at other points. While this is likely one of the worst environmental disasters to hit the gulf, BP's debacle has caused Shell to pre-build cofferdams into seven wells that it is currently drilling in the gulf. These would drop into place in the event of such a catastrophic failure of a riser under the well."

Anders writes "People for the Ethical Treatment of Animals, the largest animal rights organization in the world, endorse a new FLOSS license. From the article: 'The Harm-Less Permissive License (HPL) is a permissive, non copyleft, software license. It is based on the FreeBSD license but with one additional restriction; the "harm-less" clause. It prevents software, licensed under the HPL, to be used for harming humans or animals.'" I guess this leaves the bunny-fueled power plant in Stockholm out in the cold.

An anonymous reader writes "Well, that didn't take long. Larry Horn, CEO of MPEG-LA, the consortium that controls the AVC/H.264 video standard, says the group is looking at creating a patent pool license for VP8 and WebM, Google's new open source, royalty-free HTML5 video format... So much for a Web video standard unencumbered by patent issues." We talked about VP8/WebM a couple of days ago when Google open sourced it. Reader Stoobalou points out another late-night email from Steve Jobs, who was asked to comment on VP8 vs. H.264. Jobs laconically sent a pointer to the technical analysis we linked before, where the poster says "VP8 copies way too much from H.264 for anyone sane to be comfortable with it, no matter whose word is behind the claim of being patent-free."

overThruster writes "Security giant Symantec is taking another step toward global domination of the information security market with the purchase of VeriSign's authentication business. Back in April it purchased PGP Corporation and GuardianEdge. VeriSign is the best known Certificate Authority; they are virtually synonymous with certificates for SSL and PKI. It seems like this could dilute the trust value of their brand rather than enhance it. It is not clear yet what effects this will have on VeriSign customers but the cynic in me says it can't be good. In terms of putting all your eggs in one basket, this will sure make Symantec a juicy target for hackers (as if they weren't already). Imagine you could hack one company and control a large chunk of endpoint security software and the bulk of the Internet's public key infrastructure."

Dr. Eggman writes "Physorg.com brings us news of a synthetic genome, produced by the J. Craig Venter Institute, being used in an existing bacterial cell for the first time. Using a combination of biological hosts, the technique produces short strings of DNA by machine which are then inserted into yeast to be stitched together via DNA-repair enzymes. The medium sequences are passed into E. coli and back into yeast. After three rounds, a genome of three million base pairs was produced." (More below.) "Specifically, the genome of M. mycoides was synthesized from scratch. This synthetic genome was then inserted into the cells of a bacteria known as Mycoplasm capricolum. The result is a cell, driven by a synthetic genome, producing not the proteins of Mycoplasm capricolum, but of M. mycoides. The institute has far-reaching plans for its synthetic life program, including designing algae that can capture carbon dioxide, make new hydrocarbons for refineries, make new chemicals or food ingredients, and speed up vaccine production." The BBC has coverage of the hybrid cell as well.

kokoko1 submits this snippet from The Telegraph, which reports that Facebook isn't alone — now YouTube, too, is being censored in Pakistan. "The blocking of YouTube comes a day after a Pakistani court blocked Facebook amid a growing row over a competition on the social networking website to design cartoons of the Prophet Muhammad." Update: 05/20 18:58 GMT by T : According to an anonymous reader, Wikipedia and Flickr are out, too.
Update: 05/21 12:11 GMT by KD : And now add Twitter to the blocked list. This post claims that more than 1,000 sites are being blocked in Pakistan.

FlorianMueller writes "Long gone are the times when Europe was that bastion of resistance against software patents and patents on such things as file systems were ruled invalid. In a decision published today, the Federal Court of Justice of Germany upheld a patent on the automatic generation of structured documents (such as XML/HTML) in a client-server setting. The ruling lays out general principles that go beyond the patent at stake: they tear down all barriers to software patentability in the largest EU member state, even though a European patent treaty has been adopted that was intended to exclude software from the scope of patentable subject matter. EU patent examiners recently warned against a drift toward software patents. Software patent critics in Europe fear this will spark more litigation on their continent and increasingly call for defensive measures."

FlorianMueller writes "Long gone are the times when Europe was that bastion of resistance against software patents and patents on such things as file systems were ruled invalid. In a decision published today, the Federal Court of Justice of Germany upheld a patent on the automatic generation of structured documents (such as XML/HTML) in a client-server setting. The ruling lays out general principles that go beyond the patent at stake: they tear down all barriers to software patentability in the largest EU member state, even though a European patent treaty has been adopted that was intended to exclude software from the scope of patentable subject matter. EU patent examiners recently warned against a drift toward software patents. Software patent critics in Europe fear this will spark more litigation on their continent and increasingly call for defensive measures."

FlorianMueller writes "Long gone are the times when Europe was that bastion of resistance against software patents and patents on such things as file systems were ruled invalid. In a decision published today, the Federal Court of Justice of Germany upheld a patent on the automatic generation of structured documents (such as XML/HTML) in a client-server setting. The ruling lays out general principles that go beyond the patent at stake: they tear down all barriers to software patentability in the largest EU member state, even though a European patent treaty has been adopted that was intended to exclude software from the scope of patentable subject matter. EU patent examiners recently warned against a drift toward software patents. Software patent critics in Europe fear this will spark more litigation on their continent and increasingly call for defensive measures."

eldavojohn writes "In a disturbing case for average consumers, nine DRAM chip manufacturers have been fined more than $400 million for price fixing. The named companies are Samsung, Hynix, Infineon, NEC, Hitachi, Mitsubishi, Toshiba, Elpida, and Nanya. A tenth company, Micron, avoided fines by reporting the other nine to the authorities. Since all companies cooperated with the probe, they received a 10% reduction in fines, so it could have been worse. The US DoJ has had its own history with chip makers and LCD makers in price fixing scandals."

eldavojohn writes "In a disturbing case for average consumers, nine DRAM chip manufacturers have been fined more than $400 million for price fixing. The named companies are Samsung, Hynix, Infineon, NEC, Hitachi, Mitsubishi, Toshiba, Elpida, and Nanya. A tenth company, Micron, avoided fines by reporting the other nine to the authorities. Since all companies cooperated with the probe, they received a 10% reduction in fines, so it could have been worse. The US DoJ has had its own history with chip makers and LCD makers in price fixing scandals."

asgard4 writes "Coming up with sound, elegant, and easy to implement designs is not a trivial matter, as Fred Brooks, author of the classic book The Mythical Man-Month, acknowledges in his latest book The Design of Design. In many disciplines — especially in software development — the design process and how to produce good designs is relatively poorly understood. Teaching the design process to students is even more difficult. In the form of opinionated essays, Brooks attempts to summarize what we know about the design process, how it has changed over time, and how we can produce better and more elegant designs. Brooks has decades of experience designing large systems and is well known for his involvement in the design of IBM's OS/360. Even though Brooks is a computer scientist, the book applies equally well to many other disciplines outside of software development that have a formal design process, such as architecture. A lot of his examples come from other engineering disciplines and architecture. But of course he presents the obligatory OS/360 case study as well." Read on for the rest of Martin's review. The Design of Design: Essays from a Computer Scientist author Frederic P. Brooks, Jr. pages 432 publisher Pearson Education rating 8/10 reviewer Martin Ecker ISBN 0201362988 summary Inspiring new book by Fred Brooks The book is divided into six parts, the first three of which I consider the most relevant and most interesting. In part one, Brooks starts out with a discussion of models for the design process. In particular, he presents his take on how the traditional Rational Model (or the Waterfall Model — its offspring that is better known to computer scientists) is not sufficient to achieve greatness in design because it has a too simplistic and idealistic view of the design process. Brooks then proceeds to discuss better, more iterative models for designing, for example, Boehm's Spiral Model used in software development, which much of the newer so-called agile methodologies are based on. He argues that it is important to have a clear, concise model that can be accompanied by an easy to understand graphical representation, such as a diagram, in order to be able to teach the design process to novice designers.

Part two of the book is about collaboration and team design. On large projects there will usually be multiple designers who are forced to work together to produce a single, coherent design. The major stumbling block in team design is achieving conceptual integrity. Brooks suggests that the most important way of achieving this is by empowering a single software architect who has a high-level overview and can make the final call on different, competing design alternatives. I totally agree with this from my own experience of working on large projects where multiple people held design responsibilities. In this part of the book, the author also has a timely chapter on telecollaboration and on the impact of modern technologies, such as videoconferencing via the internet, on team design.

Part three, titled Design Principles, contains various essays on budgeting, constraints, and user involvement in the design process. There is also some interesting material on what Brooks calls exemplars in design, i.e. the reuse of previous designs as a whole or in part in creating new designs. My favorite chapter in this section of the book is the one on good style. I find that a good design doesn't just need to be coherent and functional, it also needs to be elegant. Brooks's definition of design style is quite good in my opinion: "Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different". Well put.

Part four of the book, in which the author outlines his dream software system for designing houses, is the by far weakest part of the book for me. The presented "design" of the dream system is simply a list of high-level features without going into any detail, which is pretty pointless in my opinion. Part five gets more interesting again with two essays on great designers and how to foster an environment at a company to make designers great. In particular, I like the idea of having designers "eat their own dog food", i.e. forcing them to use the end products of their designs out in the wild (maybe in form of a sabbatical at one of the system's customers). The book concludes with seven chapters on various case studies. While these are certainly interesting, they don't contain any additional essential thoughts on the design process that weren't already presented in the previous parts of the book.

The Design of Design is an excellent book from one of the pioneers in computer science. Brooks's writing style is as elegant and enjoyable as ever. While he dates himself in some of his examples, the overarching ideas of the book are timeless and important. Not many books have been written about the design of the design process itself and this book is a valuable addition. It is mostly aimed at designers and people who have spent some time reflecting on the design process itself. The casual reader and people who are more concerned with implementing designs rather than creating the designs themselves might find it somewhat intangible. However, even designers in disciplines other than computer science or software development can gain a lot from the insights in this book.

You can purchase The Design of Design: Essays from a Computer Scientist from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

asgard4 writes "Coming up with sound, elegant, and easy to implement designs is not a trivial matter, as Fred Brooks, author of the classic book The Mythical Man-Month, acknowledges in his latest book The Design of Design. In many disciplines — especially in software development — the design process and how to produce good designs is relatively poorly understood. Teaching the design process to students is even more difficult. In the form of opinionated essays, Brooks attempts to summarize what we know about the design process, how it has changed over time, and how we can produce better and more elegant designs. Brooks has decades of experience designing large systems and is well known for his involvement in the design of IBM's OS/360. Even though Brooks is a computer scientist, the book applies equally well to many other disciplines outside of software development that have a formal design process, such as architecture. A lot of his examples come from other engineering disciplines and architecture. But of course he presents the obligatory OS/360 case study as well." Read on for the rest of Martin's review. The Design of Design: Essays from a Computer Scientist author Frederic P. Brooks, Jr. pages 432 publisher Pearson Education rating 8/10 reviewer Martin Ecker ISBN 0201362988 summary Inspiring new book by Fred Brooks The book is divided into six parts, the first three of which I consider the most relevant and most interesting. In part one, Brooks starts out with a discussion of models for the design process. In particular, he presents his take on how the traditional Rational Model (or the Waterfall Model — its offspring that is better known to computer scientists) is not sufficient to achieve greatness in design because it has a too simplistic and idealistic view of the design process. Brooks then proceeds to discuss better, more iterative models for designing, for example, Boehm's Spiral Model used in software development, which much of the newer so-called agile methodologies are based on. He argues that it is important to have a clear, concise model that can be accompanied by an easy to understand graphical representation, such as a diagram, in order to be able to teach the design process to novice designers.

Part two of the book is about collaboration and team design. On large projects there will usually be multiple designers who are forced to work together to produce a single, coherent design. The major stumbling block in team design is achieving conceptual integrity. Brooks suggests that the most important way of achieving this is by empowering a single software architect who has a high-level overview and can make the final call on different, competing design alternatives. I totally agree with this from my own experience of working on large projects where multiple people held design responsibilities. In this part of the book, the author also has a timely chapter on telecollaboration and on the impact of modern technologies, such as videoconferencing via the internet, on team design.

Part three, titled Design Principles, contains various essays on budgeting, constraints, and user involvement in the design process. There is also some interesting material on what Brooks calls exemplars in design, i.e. the reuse of previous designs as a whole or in part in creating new designs. My favorite chapter in this section of the book is the one on good style. I find that a good design doesn't just need to be coherent and functional, it also needs to be elegant. Brooks's definition of design style is quite good in my opinion: "Style is a set of different repeated microdecisions, each made the same way whenever it arises, even though the context may be different". Well put.

Part four of the book, in which the author outlines his dream software system for designing houses, is the by far weakest part of the book for me. The presented "design" of the dream system is simply a list of high-level features without going into any detail, which is pretty pointless in my opinion. Part five gets more interesting again with two essays on great designers and how to foster an environment at a company to make designers great. In particular, I like the idea of having designers "eat their own dog food", i.e. forcing them to use the end products of their designs out in the wild (maybe in form of a sabbatical at one of the system's customers). The book concludes with seven chapters on various case studies. While these are certainly interesting, they don't contain any additional essential thoughts on the design process that weren't already presented in the previous parts of the book.

The Design of Design is an excellent book from one of the pioneers in computer science. Brooks's writing style is as elegant and enjoyable as ever. While he dates himself in some of his examples, the overarching ideas of the book are timeless and important. Not many books have been written about the design of the design process itself and this book is a valuable addition. It is mostly aimed at designers and people who have spent some time reflecting on the design process itself. The casual reader and people who are more concerned with implementing designs rather than creating the designs themselves might find it somewhat intangible. However, even designers in disciplines other than computer science or software development can gain a lot from the insights in this book.

You can purchase The Design of Design: Essays from a Computer Scientist from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

DukeTech writes "This week marks the end of an era for one of the earliest pieces of Internet history, which got its start at Duke University more than 30 years ago. On May 20, Duke will shut down its Usenet server, which provides access to a worldwide electronic discussion network of newsgroups started in 1979 by two Duke graduate students, Tom Truscott and Jim Ellis." Rantastic and other readers wrote about the shutdown of the British Usenet indexer Newzbin today; the site sank under the weight of a lawsuit and outstanding debt. Combine these stories with the recent news of Microsoft shuttering its newsgroups, along with other recent stories, and the picture does not look bright for Usenet.

DukeTech writes "This week marks the end of an era for one of the earliest pieces of Internet history, which got its start at Duke University more than 30 years ago. On May 20, Duke will shut down its Usenet server, which provides access to a worldwide electronic discussion network of newsgroups started in 1979 by two Duke graduate students, Tom Truscott and Jim Ellis." Rantastic and other readers wrote about the shutdown of the British Usenet indexer Newzbin today; the site sank under the weight of a lawsuit and outstanding debt. Combine these stories with the recent news of Microsoft shuttering its newsgroups, along with other recent stories, and the picture does not look bright for Usenet.

DukeTech writes "This week marks the end of an era for one of the earliest pieces of Internet history, which got its start at Duke University more than 30 years ago. On May 20, Duke will shut down its Usenet server, which provides access to a worldwide electronic discussion network of newsgroups started in 1979 by two Duke graduate students, Tom Truscott and Jim Ellis." Rantastic and other readers wrote about the shutdown of the British Usenet indexer Newzbin today; the site sank under the weight of a lawsuit and outstanding debt. Combine these stories with the recent news of Microsoft shuttering its newsgroups, along with other recent stories, and the picture does not look bright for Usenet.

DukeTech writes "This week marks the end of an era for one of the earliest pieces of Internet history, which got its start at Duke University more than 30 years ago. On May 20, Duke will shut down its Usenet server, which provides access to a worldwide electronic discussion network of newsgroups started in 1979 by two Duke graduate students, Tom Truscott and Jim Ellis." Rantastic and other readers wrote about the shutdown of the British Usenet indexer Newzbin today; the site sank under the weight of a lawsuit and outstanding debt. Combine these stories with the recent news of Microsoft shuttering its newsgroups, along with other recent stories, and the picture does not look bright for Usenet.

astroengine writes "Earlier this month, engineers suspended Voyager 2's science measurements because of an unexpected problem in its communications stream. A glitch in the flight data system, which formats information for radioing to Earth, was believed to be the problem. Now NASA has found the cause of the issue: it was a single memory bit that had erroneously flipped from a 0 to a 1. The cause of the error is yet to be understood, but NASA plans to reset Voyager's memory tomorrow, clearing the error."

Roberto123 writes "Network World offers some insights into the way China infiltrates US organizations, physically and via computer, to steal information. Security expert Ira Winkler says there are far more serious threats out there than the 'laughable' uproar over China's hack of Google."

itwbennett writes "In a letter to US Representative Ed Markey, FTC Chairman Jon Leibowitz said that the FTC has begun contacting copy machine makers, resellers, and office supply stores to inform them about privacy concerns over the images that can be stored on the machines' hard drives and trying to 'determine whether they are warning their customers about these risks ... and whether manufacturers and resellers are providing options for secure copying.'"

FlorianMueller writes "Can a patent troll ever be fair? Yes. The primary concern over the upcoming Defensive Patent License — a GPL-like non-aggression pact for patents — is that it might be too defensive to have the desired impact. But actually the DPL could grow very big if one or more 'Fair Trolls' are brought to life and enforce patents against companies that don't support the DPL. The 'Fair Trolls' would commit to the DPL's terms, so they would have to leave other DPL backers alone. In exchange for this, the community would gladly feed them with patentable ideas (financial rewards for contributors included). Over time, staying outside the DPL alliance would become a costly choice for companies whose products might infringe patents. The bigger the DPL pool gets, the more valuable it becomes to its members. The more aggressive the Fair Trolls are, the better for the cause."

eldavojohn writes "Germany has ordered Google to give up hard disk drives used to store German data collected during their Street View operations in that country. This follows Google's admission last week (after prodding from the Germans) that it had collected the data from unsecured wireless area networks from around the entire world as its roving cars collected the photo archive for Street View. Google says they've offered to just destroy the data, in cooperation with national regulators, but the German government wants to know what they've collected. They do not think that destroying the drives suffices for compliance with the laws. Officials went so far as to say of the situation, 'It is not acceptable that a company operating in the EU does not respect EU rules.' Germany has certainly been keeping their eye on the search giant." The Ars coverage notes that the US FTC may be looking more closely at Google's collection as well.

eldavojohn writes "Germany has ordered Google to give up hard disk drives used to store German data collected during their Street View operations in that country. This follows Google's admission last week (after prodding from the Germans) that it had collected the data from unsecured wireless area networks from around the entire world as its roving cars collected the photo archive for Street View. Google says they've offered to just destroy the data, in cooperation with national regulators, but the German government wants to know what they've collected. They do not think that destroying the drives suffices for compliance with the laws. Officials went so far as to say of the situation, 'It is not acceptable that a company operating in the EU does not respect EU rules.' Germany has certainly been keeping their eye on the search giant." The Ars coverage notes that the US FTC may be looking more closely at Google's collection as well.

Pickens writes "eWeek reports that Microsoft has announced it will pay $200 million to settle a patent-infringement suit against it by VirnetX, which alleged that the software giant infringed on its patents related to communications, virtualization and collaboration technology. This payment represents a substantial markup from the $105.7 million that a Texas jury awarded in March when it found that Microsoft had infringed on two US patents held by VirnetX. Microsoft will license VirnetX technology for its own products. 'We believe that this successful resolution of our litigation with Microsoft will allow us to focus on the upcoming pilot system that will showcase VirnetX's automatic Virtual Private Network technology,' says Kendall Larsen, VirnetX Holding Corp.'s CEO. East Texas courts have a reputation as a good place to pursue intellectual property suits against larger corporations. While many of these cases seem to be settled out of court — or dismissed as totally frivolous — recent lawsuits such as those leveled by i4i and VirnetX are notable for at least extending to the Big Judgment phase."

Pickens writes "eWeek reports that Microsoft has announced it will pay $200 million to settle a patent-infringement suit against it by VirnetX, which alleged that the software giant infringed on its patents related to communications, virtualization and collaboration technology. This payment represents a substantial markup from the $105.7 million that a Texas jury awarded in March when it found that Microsoft had infringed on two US patents held by VirnetX. Microsoft will license VirnetX technology for its own products. 'We believe that this successful resolution of our litigation with Microsoft will allow us to focus on the upcoming pilot system that will showcase VirnetX's automatic Virtual Private Network technology,' says Kendall Larsen, VirnetX Holding Corp.'s CEO. East Texas courts have a reputation as a good place to pursue intellectual property suits against larger corporations. While many of these cases seem to be settled out of court — or dismissed as totally frivolous — recent lawsuits such as those leveled by i4i and VirnetX are notable for at least extending to the Big Judgment phase."

Halo1 writes "Demonstrating it's not just about Flash, Apple has officially rejected for the first time another alternative iPhone development environment following its controversial iPhone SDK Agreement changes. Even though RunRev proposed to retool its HyperCard-style development environment to directly expose all of the iPhone OS's APIs, Steve Jobs still rejected its proposal. The strength of RunRev's business case, with a large-scale iPad deployment project in education hinging on the availability of its tool, does not bode well for projects that have less commercial clout. Salient point: at last February's shareholders' meeting, Jobs went on the record saying that something like HyperCard on the iPad would be great, 'but someone would have to create it.'"

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Programming Clojure by Stuart Halloway was very near to the perfect book for me. It covers many things common to many Lisp languages while highlighting in moderate detail the things that make Clojure unique and worthy of some attention. The book spends a large amount of time dealing with the intricacies of interfacing fluidly with Java (down to a package rewrite inside a large project). This fits me perfectly as a Java programmer, and I now feel ready to experiment with peppering functional language capabilities into an object oriented language. The book also strives to show how to simplify multithreading through functional programming, which is good because I find multithreading in Java a serious headache that few are good at. Programming Clojure, released in May 2009, is currently the only book out there devoted to Clojure, and the introduction is written by the language's creator, Rich Hickey, who says, 'What is so thrilling about Stuart's book is the extent to which he "gets" Clojure.' The book earns its place on the Pragmatic Bookshelf by guiding the user through rewriting a part of Ant into a new build tool called Lancet — adding to the project what you just learned about Clojure at the end of each chapter." Keep reading for the rest of eldavojohn's review. Programming Clojure author Stuart Halloway pages 304 publisher The Pragmatic Bookshelf rating 8/10 reviewer eldavojohn ISBN 978-1-934356-33-3 summary A firm definition of Clojure via examples coupled with the beginnings of actually programming Clojure. First, a lot of you are probably wondering what Clojure is and asking me why you should care at all about it. Well, Clojure is a functional programming (FP) language that runs on top of the extremely pervasive Java Virtual Machine and in doing so seems to offer a simpler way of multithreaded programming. It belongs to the family of languages that are Lisps and as a result this book covers a lot of remedial material that is common to other Lisp languages. If you're a serious lisp programmer, you'll be able to skip some of this book (the intro will guide you). Clojure has rarely been mentioned on Slashdot with the resulting comments revealing largely confusion or considering it a buzzword. It's going to be hard to write this review about the book instead of the language being that 99% of what I know about Clojure comes from this book. If you work through this book linearly, you must also use the command line read-eval-print loop (REPL) that, similar to Ruby's IRB, allows you to get hands on with Clojure and Halloway's examples.

Both Hickey and Halloway are very active in Clojure development. In fact, Halloway has a video out on types and protocols, new developments in Clojure 1.2 since the book went to print. Halloway does a good job at providing examples, keeping the book pragmatic and showing you the "wrong" way before incrementally showing you how to correctly accomplish various goals in Clojure. But he loses two points on this review for two reasons. One is that he over evangelizes about Clojure. It would lend a lot more credibility to everything else he says if he would just relent and abstain a bit from painting Clojure as the best language for any task. This ties into my second point which is the fact that books on programming languages are supposed to give the reader two very valuable things: knowledge of when to use the language and knowledge of when not to use the language. Programming Clojure is lacking in the latter--this is not a unique problem as most books about a language really sell their language. All too often in my professional career I see a solution and think, "Wow, that really was not the right tool for the job." (I'm looking at you, Java) Clojure definitely has its strengths and weaknesses despite very little evidence of the latter in this book although I was directed to a QCon presentation where the author speaks more about where Clojure excels in real life.

That said, the book is a great fit for the object oriented Java developer who does not also code a lisp-like language regularly. I say that because Chapter Two deals with reviewing all of the facets of Clojure--most of which are found in other Lisp languages which might be seen as remedial to a proficient Lisp developer. However, before you skip it entirely, there are important notes that Halloway injects into these chapters ranging from how not to do things in Clojure to the minute differences and implications they hold. Chapter Five dives into the fundamentals and features of functional programming in Clojure. This chapter was especially useful to me as I'm not used to languages featuring things like lazy sequences, caching of results or tail-call optimization. Working through the examples in Chapter Five really opened my eyes to some of the more powerful aspects of FP. Like how an infinite sequence can easily be handled by Clojure and its laziness allows you to only pay for what you need from that sequence. While definitions of infinite sequences are also possible in Haskell or Python, Clojure brings this capability to the JVM (not that anything is preventing a more verbose Java library from handling such structures).

Chapter Three focuses a lot on Clojure's interaction with Java and does a great job of showing you how to rewrite part of your Java project into Clojure and run it on the JVM. This includes calling Java from Clojure, creating and compiling Clojure into java classes, handling Java exceptions in Clojure and ends with the beginning work in Lancet (the build tool the book strives to create using what we learn in each chapter). It also contains a bit on optimizing your performance when working with Java in Clojure. This theme continues through the book as Halloway knows that one of Clojure's main selling points is that it can be so much faster than Java if you're willing to put in the extra work and planning to utilize pure functional programming.

In Java, everything is an object. In Scheme, everything is a list. Well in Clojure, the main staple is sequences which brings us to Chapter Four: Unifying Data with Sequences. While this chapter succeeds in teaching how to load data into sequences, how to consume data from sequences and how to force evaluation of lazy sequences, it felt like one of the weakest chapters in the book. This is all necessary in learning Clojure but Halloway skimps on examples and could stand to add some more examples on what is and isn't seq-able, seq-ing on various things and performing functions on various things.

Multicore chips are all the rage these days. And right now it seems that developers are by and large content with coding single threaded applications. But that may change in the future when the user expects more than a few cores in usage. In the introduction, Halloway argues a few reasons why we all should use Clojure and one of those reasons happens to be the somewhat sound logic that we will all have cores coming out of our ears in the near future. That means that as a developer you have the option to spawn more threads which means coordination of threads which means you will be forced to do the dirty dance of concurrency. Chapter Six is entirely devoted to this and, honestly, I reread a lot of this chapter as there are several update mechanisms and models that you can use to manage concurrency in Clojure. Unsurprisingly there is no silver bullet for concurrency even in Clojure. This book has but a handful of figures and their formatting leaves much to be desired but the two in this chapter are necessary references for deciding if you should use refs and software transactional memory, atoms, agents, vars or classic Java locks. This is a potent chapter that ends with a snake game implementation in Clojure demonstrating some basic concurrency. While Clojure protects you from some classically complex issues and may make concurrency vastly more succinct, it still requires a lot of thought and planning. Halloway provides good direction but clearly hands on experience is a necessity in this realm.

Chapter Seven focuses entirely on macros and is somewhat disheartening in that it presents an extremely powerful feature of Clojure that is also very complex. Halloway gives two rules and an exception for Macro Club. The first rule is: "Don't Write Macros." The second rule is: "Write Macros if That Is the Only Way to Encapsulate a Pattern." The exception is you can also write macros if it makes calling your code easier. Halloway does a good job of explaining the basics of macros in Clojure and breaks them down via a taxonomy into categories and examples of macros in Clojure. Macros are a necessity when you're trying to augment Clojure by adding features to it or if you are creating a Domain-Specific Language (DSL). Macros in Clojure do seem easier than macros in most other Lisp languages. At the end of Chapter Seven, you create a basic DSL for Lancet which was helpful even though I was left feeling helpless in the face of macros. Despite the complexity of macros in Chapter Seven, Eight's multimethods are similar to Java polymorphism and was much easier to wrap my head around than macros. Multimethods are used very infrequently (seven times in the five thousand lines that compose the Clojure core).

Chapter Nine is unfortunately less than twenty pages and deals with "Clojure in the Wild." You would think that a book in the series of Pragmatic Programmer would have more pragmatism than the features of a language with Lancet but let's face it--Clojure is a relatively young language. Nine covers automated tests, data access and web development. The automated testing is a short section on Clojure's test-is packaging. The database stuff appears to be little more than wrappers around the already mature JDBC. The web development consists of an intro to Compojure which is similar to web.py and Sinatra. Compojure shows a lot of promise in reducing the amount of code one needs to write a basic web application. It lacks the feature set and support that Rails has with rapidly building CRUD applications but holds a lot of potential to be flushed out into something similarly powerful. Halloway says his introductions to these projects should "whet your appetite for the exciting world of Clojure development" but I think a more accurate description is that these brief brushes with functional projects leaves the reader ravenously blinded by hunger for more.

Some final thoughts on the book: I caught only two very minor typos in the book. It's all English and code. There were no pictures or illustrations in this book except for one on page 96 in which a tiny drawing appears named Joe who asks a question about vectors. Oddly enough, I didn't find Joe on any of the other three hundred pages. It was very easy to work through this book from cover to cover and the example code was very instrumental in my understanding of Clojure. As a Java monkey, rereading sections seemed a requirement although the book is concise enough for me to enjoy in my free time over one week. Halloway cites mostly websites and utilizes tinyurl to reference blogs like Steve Yegge's blog and frequently he references Wikipedia. Only three of his many citations are other printed books (although one of them is Gödel, Escher, Bach: An Eternal Golden Braid). Halloway's greatest strength is the engaging examples (like the Hofstadter Sequence) that he picks and provides to the user and I hope that future editions of the book build on this as well as expand on the growing base of Clojure projects out there. His github is rife with both instructive and pragmatic examples that could stand to be included in a future book.

Some final thoughts on the language: Clojure holds a lot of potential that is yet to be realized. I cannot say yet whether the succinct syntax offers a good balance between quick coding and readability. To the uninitiated, the code can look like a jumble of symbols. Yes, we escape the verbosity of Java and the kingdom of nouns but is what Clojure offers (a neighboring kingdom of verbs) better? While Clojure is concise, it requires a lot of keywords which required a lot of usage look up when starting. Clojure code is potent and powerful. A mere five thousand lines of Clojure code create your engine--the core of the language. I assume this brevity is due to ingenious reuse that Clojure can offer but I would hate to be the person to maintain that code if I was not the author. What's better is that this code is quickly conjured at the REPL if you wish to read it yourself or augment a feature. A sage coworker who has seen much more than I in this business of software development recommended Clojure to me. He was right that it is a very interesting and innovative language but in my opinion it has a long way to go before it becomes the next Ruby or Java. Clojure needs an equivalent to Ruby on Rails and it's fighting an uphill battle against all the developers like myself that left college with so much object oriented coding and so little functional programming (although Scheme is my alma mater's weed out course). If you find yourself stagnating and are thirsty for some continuing education in the form of a stimulating challenge, I recommend Clojure (and this book on Clojure). Hopefully Clojure's full potential is realized by the community and it finds its deserved place in many developer's tool sets as the right tool for some jobs.

You can find Programming Clojure in three DRM-free formats and hard copy from the publisher's site. For a sample of the author's writing and to get a feel for how he injects Clojure code into it, check out his blogs on his company's website.

You can purchase Programming Clojure from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

eldavojohn writes "Yesterday the Texas textbook controversy was reported internationally but the news today heats up the debate as California, a state on the other side of the political spectrum, introduces legislation that would block these textbook changes inside California. Democrat Senator Leland Yee (you may know him as a senator often tackling ESRB ratings on video games) introduced SB1451, which would require California's school board to review books for any of Texas' changes and block the material if any such are found. The bill's text alleges that said changes would be 'a sharp departure from widely accepted historical teachings' and 'a threat to the apolitical nature of public school governance and academic content standards in California.'"

eldavojohn writes "Yesterday the Texas textbook controversy was reported internationally but the news today heats up the debate as California, a state on the other side of the political spectrum, introduces legislation that would block these textbook changes inside California. Democrat Senator Leland Yee (you may know him as a senator often tackling ESRB ratings on video games) introduced SB1451, which would require California's school board to review books for any of Texas' changes and block the material if any such are found. The bill's text alleges that said changes would be 'a sharp departure from widely accepted historical teachings' and 'a threat to the apolitical nature of public school governance and academic content standards in California.'"

diegocg writes "Linux 2.6.34 has been released. This version adds two new filesystem, the distributed filesystem Ceph and LogFS, a filesystem for flash devices. Other features are a driver for almost-native KVM network performance, the VMware balloon driver, the 'kprobes jump' optimization for dynamic probes, new perf features (the 'perf lock' tool, cross-platform analysis support), several Btrfs improvements, RCU lockdep, Generalized TTL Security Mechanism (RFC 5082) and private VLAN proxy arp (RFC 3069) support, asynchronous suspend/resume, several new drivers and many other small improvements. See the full changelog here."

Contridictory stories are circulating after Fox News's pursuing of Wikimedia Foundation for hosting pornography reportedly resulted in Jimmy Wales personally removing some pornographic material from its servers, then giving up his special editing privileges under pressure. Fox News reported that Wikimedia is "in chaos"; this report was picked up by VentureBeat and others. Wales denies that there is any chaos (any more than usual, that is) at Wikimedia. The Fox News report apparently relied on a single unnamed source, and Wales said, "They don't even bother to contact me before publishing nonsense." The background: on April 27 Fox News published an exclusive report about porn on Wikimedia servers, then followed up by contacting organizations that had donated to Wikimedia to ask them what they thought about it. In the aftermath, Wales took a position in support of purging porn from Wikimedia Commons. This all started when estranged Wikipedia co-founder Larry Sanger contacted the FBI with an allegation of child porn on Wikipedia.

Contridictory stories are circulating after Fox News's pursuing of Wikimedia Foundation for hosting pornography reportedly resulted in Jimmy Wales personally removing some pornographic material from its servers, then giving up his special editing privileges under pressure. Fox News reported that Wikimedia is "in chaos"; this report was picked up by VentureBeat and others. Wales denies that there is any chaos (any more than usual, that is) at Wikimedia. The Fox News report apparently relied on a single unnamed source, and Wales said, "They don't even bother to contact me before publishing nonsense." The background: on April 27 Fox News published an exclusive report about porn on Wikimedia servers, then followed up by contacting organizations that had donated to Wikimedia to ask them what they thought about it. In the aftermath, Wales took a position in support of purging porn from Wikimedia Commons. This all started when estranged Wikipedia co-founder Larry Sanger contacted the FBI with an allegation of child porn on Wikipedia.

suraj.sun picked up a Guardian (UK) piece on the Texas school board and their quest to remake US education in a pro-American, Christian, free enterprise mode. We've been keeping an eye on this story for some time, as it will have an impact far beyond Texas. From the Guardian: "The board is to vote on a sweeping purge of alleged liberal bias in Texas school textbooks in favor of what Dunbar says really matters: a belief in America as a nation chosen by God as a beacon to the world, and free enterprise as the cornerstone of liberty and democracy. ... Those corrections have prompted a blizzard of accusations of rewriting history and indoctrinating children by promoting right-wing views on religion, economics, and guns while diminishing the science of evolution, the civil rights movement, and the horrors of slavery. ... Several changes include sidelining Thomas Jefferson, who favored separation of church and state, while introducing a new focus on the 'significant contributions' of pro-slavery Confederate leaders during the Civil War. ... Study of Sir Isaac Newton is dropped in favor of examining scientific advances through military technology."

flynny51 writes "Dr. Dylan Evans of the School of Medicine, University College, Cork, Ireland, has had a two-year period of intensive monitoring and counseling imposed upon him and as a result his application for tenure is likely to be denied. His offense — sharing an article from a peer-reviewed journal on fellatio in fruit bats."

l_i_g_h_s_p_e_e_d writes "The trailer for Sintel is ready. (We discussed the beginnings of this project in 2007.) Sintel is a Blender Open Movie project created using only FLOSS software. 'For the entire creation pipeline in the studio, we will only use free/open source software. We have less than two months now to finish this completely. ... Imagine the tension that's building up here to get everything perfect. For today, we'll celebrate a big step forward.' Download here."

An anonymous reader writes "The US has sent a team of nuclear physicists to help BP plug the 'catastrophic' flow of oil into the Gulf of Mexico from its leaking Deepwater Horizon well, as the Obama administration becomes frustrated with the oil giant's inability to control the situation. The five-man team — which includes a man who helped develop the first hydrogen bomb in the 1950s — is the brainchild of Steven Chu, President Obama's Energy Secretary." Let's hope this doesn't mean they actually try the nuclear option. In other offshore drilling news, reader mygoditsfullofdoom informs us that a Venezuelan gas rig has sunk in the Caribbean (with no loss of life). This one is being laid at the feet of Venezuela's state oil company PDVSA, which hasn't exactly been regarded as uber-competent "after President Hugo Chavez fired half the company's managers and senior engineers following a 2002 strike."

As promised when the Humble Indie Bundle hit $1 million in donations the other day, indie developer Frictional Games has released Penumbra: Overture's source code. "The code for Penumbra: Overture is a continuation of the one used for the tech demo + some addition for the not so long lived Robo Hatch project. It also contains some code from Unbirth, giving it quite some history." The release also includes the HPL1 engine. "This is engine that has powered all of the Penumbra games and it even includes the stuff used to create the 2D platformer Energetic. The engine code was started in December 2004 and was actively developed until early 2008." The repositories are available at github.