Bill St. Clair noticed that Mac OS X Leopard's new “sandbox” facility uses Lisp syntax (supposedly it's actually TinyScheme).
/usr/share/sandbox/bsd.sb:
;; ;; common rules for various BSD daemons ;; Copyright (c) 2007 Apple Inc. All Rights reserved. ;; ;; WARNING: The sandbox rules in this file currently constitute ;; Apple System Private Interface and are subject to change at any time and ;; without notice. The contents of this file are also auto-generated and not ;; user editable; it may be overwritten at any time. ;; (version 1) (debug deny) (define (bsd.traverse-symlinks) (allow file-read-metadata)) (define (bsd.dylibs-and-frameworks) (allow file-read-data file-write-data (regex ; Allow files accessed by system dylibs and frameworks #"^/dev/null$" #"^(/private)?/var/run/syslog$" #"^/dev/u?random$" #"^/dev/dtracehelper$" #"/\.CFUserTextEncoding$" #"^(/private)?/etc/localtime$" #"^/usr/share/nls/" #"^/usr/share/zoneinfo/")) (allow file-read-data file-read-metadata (regex ; Allow reading system dylibs and frameworks #"^/usr/lib/.*\.dylib$" #"^/System/")) (allow ipc-posix-shm) ; Libnotify ) (bsd.traverse-symlinks) (bsd.dylibs-and-frameworks)
Update: My pal est of e7 fame has some code in TinyScheme (code he wrote in 1988) and so is now an official part of Mac OS X.
From the DARPA Grand Challenge discussion board:
A group of people from four Grand Challenge teams has formed a company to commercialize autonomous vehicle technology. We are adressing the civilian non-automotive market. Our vision statement is on www.cogneta.com. We are looking to team with others who can supply software and hardware solutions.
Civilian non-automotive... agriculture, maybe? Might be about time for that to happen. It's more plausible than the stuff on their site about single occupancy public-owned magic pollution-free vehicles.
Via Michael Hannemann.
IOL, 10/13/2007, “9 killed in army horror”:
It is believed the soldiers were killed when the gun jammed moments after the exercise began.
When the female officer went forward to help the gunner clear the blockage, another shell was accidentally fired, causing some of the unspent ammunition in nearly-full magazines to explode.
This, in turn, caused a “runaway”. There was nowhere to hide.
The rogue gun began firing wildly, spraying high-explosive shells at a rate of 550 a minute, swinging around through 360 degrees like a high-pressure hose.
The unknown officer tried to shut the gun down but she couldn't because the computer gremlin had taken over. Her fate was unknown at the time of going to press.
ITWeb, 10/16/2007, “Did software kill soldiers?”:
Mangope told The Star that it “is assumed that there was a mechanical problem, which led to the accident. The gun, which was fully loaded, did not fire as it normally should have," he said. “It appears as though the gun, which is computerised, jammed before there was some sort of explosion, and then it opened fire uncontrollably, killing and injuring the soldiers.”
Other reports have suggested a computer error might have been to blame. Defence pundit Helmoed-Römer Heitman told the Weekend Argus that if “the cause lay in computer error, the reason for the tragedy might never be found”.
Electronics engineer and defence company CEO Richard Young says he can't believe the incident was purely a mechanical fault. He says his company, C2I2, in the mid 1990s, was involved in two air defence artillery upgrade programmes, dubbed Projects Catchy and Dart.
During the shooting trials at Armscor's Alkantpan shooting range, “I personally saw a gun go out of control several times,” Young says. “They made a temporary rig consisting of two steel poles on each side of the weapon, with a rope in between to keep the weapon from swinging. The weapon eventually knocked the polls down.”
Young says he was also told at the time that the gun's original equipment manufacturer, Oerlikon, had warned that the GDF Mk V twin 35mm cannon system was not designed for fully automatic control. Yet the guns were automated. At the time, SA was still subject to an arms embargo and Oerlikon played no role in the upgrade.
“If I was an engineer on the Board of Inquiry, I would ask for all details about the software for the fire control system and gun drives,” Young says. “If it was not a mechanical or operating system error, you must find out which company developed the software and did the upgrade.”
Young says in the 1990s the defence force's acquisitions agency, Armscor, allocated project money on a year-by-year basis, meaning programmes were often rushed. “It would not surprise me if major shortcuts were taken in the qualification of the upgrades. A system like that should never fail to the dangerous mode [rather to the safe mode], except if it was a shoddy design or a shoddy modification.”
“I think there have been multiple failures here; in software and the absence of interlocking safeguards.” He asks if the guns were given arcs of fire and whether these were enforced with electromechanical end stops. “On a firing range you don't want guns to fire through 360 degrees.”
IOL, 10/17/2007, “Military accident: ‘stop speculation’”:
A one-eighth of a second burst of explosive shells from the barrel of the anti-aircraft gun killed nine soldiers and injured 15 others, MPs heard on Tuesday.
“As they continued firing, after the gun was fixed, it swung completely to the left, and one barrel fired off a burst of 15 to 20 shots in one-eighth of a second. The gun immediately to the left was hit.”
“This fatal burst then killed or injured members of all the guns to the left. The effect was therefore that all of those killed or injured were hit from the right and lost right hands, or right legs, or lost their lives.”
Gizmodo, 10/18/2007, “Robot Cannon Goes Berserk, Kills 9”:
A robot cannon began wildly firing on its own for some reason in South Africa last Friday, killing nine soldiers and wounding 14. The Oerlikon GDF-005 antiaircraft gun suddenly began uncontrollably firing as it swung back and forth, spraying hundreds of high-explosive 35mm cannon shells all over the place. The crazed robot's handlers are still trying to figure out what sort of software bug would cause such mayhem.
Swinging back and forth through 360 degrees, firing hundreds of shells until it ran out of ammo, with software to blame? Or 15-20 shots, to the left, for 0.125 seconds, due to a mechanical failure? I'm glad Gizmodo is on the case.
This incident brought out stories of other rumored berserk robot guns.
Danger Room, “Video: Robo-Weapon's Scary Twist”:
The tragedy in South Africa that killed nine soldiers isn't the first time a robotic weapon has spun out of control. Here's a video I obtained a few years back, showing a XM-151 Remote Weapons Station emptying its magazine of .50-caliber bullets -- and then turning towards the camera, looking for new targets to nail. I'm told -- but cannot confirm -- that this footage was shot during a demonstration for VIPs, and that several members of Congress would've been in serious jeopardy, had the weapon not run out of ammo.
My sources tell me that this incident occurred pretty much as described, except that the gun was loaded with blanks.
From the comments:
Rumor has it something similar happened with a SWORDS, and that's why F-M is coming out with a new armed robot platform.
There's an old story about the Sergeant York 40mm DIVAD system to the same effect. They'd programmed the radar to engage Soviet fighters on rocket passes -- a big metal target against a mostly blue sky. But then the Russians started demonstrating helicopter gunships. So they programmed it to pick spinning rotor blades out of ground clutter. Tested it on robot helicopters out in the desert. Worked like a charm.
So they take it out to another test range, one with reviewing stands, for a dog and pony show for the big wigs. And they fire it up, wait for the drone...and the turret swings around, through the reviewing stands, as the bigwigs duck and bail out. And it locks on the exhaust fan spinning on the side of the latrine.
I'm working on clearing the lemonodor queue.
In September a Northrop Grumman UAV comic book came to light [via boingboing]. It's terrible and weird—they should have hired Patrick Farley.
Bill Sweetman, in his Aviation Week blog, puts it into the historical context of the military aviation industry promoting their products with comic books, and points out that it's also totally inaccurate and unrealistic.
I just enjoy the anthropomorphized, taunting Global Hawk in the upper left.
Alice Hartley from Digitool:
MCL 5.2 will soon be released as on open source project. It is Unicode based. It is PPC only. Perhaps this release will enable some combination of financial and engingeering resources to provide an Intel implementation.
Not sure what that means for Digitool.
A preview of a work in progress from Zach.
Update: Zach linked to this in the comments:
Alexander Repenning on info-mcl:
So, the good news is that we can do amazing things in Lisp and they even run very efficiently. The bad news is that at a time when Apple is doing really well and producing some pretty exciting hardware we have reached a new low in terms of Lisp development. Regarding MCL / OpenMCL we are all a bit frustrated here. We do not want to have to pick between Intel & SLIME versus PPC & real IDE. What is keeping MCL and OpenMCL from reuniting into a really useful version of Lisp for the Mac? At a technical level, what went wrong with MCL's compiler that it cannot produce code working at least with Rosetta? How com the LispWorks stuff works with Rosetta, can produce PPC, Intel and even Universal Binaries working on ALL Intel Macs? From a business point of view, why can Hazem not let go of a company that does no longer appear to be viable?
Clozure's Andrew Shalit responds:
There is no current collaborative relationship between Clozure and Digitool, beyond Clozure's hosting the mailing list.
[...]
We don't have plans to reunite them.
As for the future of OpenMCL:
We've recently been able to put more resources into OpenMCL development. The command-line (non-GUI) version of OpenMCL now runs on Linux, Free BSD and OS X, supporting PPC and 64-bit Intel processors. We hope to have a 32-bit Intel port at some point, but we don't have anything to announce about that today.
Gary Byers has written an Objective-C interface that allows you to write Cocoa applications for the Mac in OpenMCL. This is not as simple as the MCL carbon interface was, but that's mostly a result of the fact that Cocoa is a much more complete object-oriented framework, and we are providing complete access to it: you can add Lisp methods to Objective C objects, you can subclass across the languages, etc. For those who want something simpler, we are working on an example library that provides a quick-and-easy gui programming interface along the lines of what MCL offered.
We have used the Cocoa tools to create a GUI-based IDE for OpenMCL on the Mac. The IDE is approaching beta quality and we intend to keep putting resources into it as much as we can. It's not the same as the MCL IDE, but we think Macintosh people will be happy with it. It's a real Macintosh app. This currently runs on PPC Macs, and it will run on 64-bit Intel Macs as soon as Leopard is released. (Leopard is required to run Cocoa as a 64-bit process.)
Andrew then says they could use more testers for the new IDE and explains how to try it out, though the situation with OpenMCL and OS X is a little confusing—I don't think there's an OpenMCL 1.1 that runs in the currently released version of OS X (10.4) on Intel hardware, so I don't think I can easily try the IDE.
Update: To be clear, OpenMCL 1.1 apparently runs fine on Intel Macs, but the Cocoa IDE does not.
Sean Ferguson's desperate cry:
If there is anybody left at MCL any more to read this, please tell us if MCL is dead or not! This is killing me!