Linux Hits the Road
An anonymous reader writes "Vicroads does regular surveys of the roads in Victoria, Australia, to determine where they need to be patched or otherwise repaired. It used to be done in a vehicle travelling at 20 kph: slow, tedious, and hazardous to the traffic around it. Now, thanks to Linux, it's being done at speeds of 80 to 100 kph. The Melbourne Age has the details. Short version: the cost has fallen from $1.2 million Australian to $850,000. Not bad..."
(I wrote FireWire camera support for QNX, and looked at the Linux code to see how to do some things. It didn't help much.)
(Windows support for FireWire is painful in a different way. It's incredibly complex, and has far too much kernel code, to allow for DRM. And the Video for Windows retrofit for FireWire is flakey.)
See here for details.
Q.
Insert Signature Here
The state to the left of Victoria is called South Australia. That is the border being referred to there.
Well, the project manager Viner thought that the project would be based on Windows but after talking to Dr. Tim Ferguson, Viner let Ferguson base it on Linux. Viner was so impressed with the way that Linux preformed the video capture and monitoring that "The experience has made Viner a firm Linux convert. 'The office is moving over to Linux and we are looking at getting some form of network-attached storage for our clients,' he said."
And Ferguson said it best at the end of the article: "Development using open source software means the developer is totally in charge. You can do what you like, and customise things to your own needs. There are downsides, like the problems I faced with the firewire drivers. But then you'll generally find that you are not alone in this; there will be others to contribute little bits of knowledge until the jigsaw is complete."
So to say that Linux is "incidental" is a little bit of an understatment.
The CSIRO's RoadCrack system is designed to find cracks in the pavement as small as 1mm wide, at 'highway speeds' of up to 105Km/h (65Mph).
The link doesn't say when this one was built, but it won awards in 1999, and was 'upgraded' in 2001.
I find your ideas intriguing and I wish to subscribe to your newsletter.
Or you can just leave those parameters as NULL, in which case (e.g. SECURITY_ATTRIBUTES) the call inherits the setting from the current process, just like it says in the MSDN. You do read the MSDN, right?
DirectX would be your first stop.
And your last stop, because RIGHT THERE IN THE DX8.1 SDK is code to do what you want:
It took me about half a day to take this code and write a video capture app which we could hook into our FPGA dev board to demonstrate our product.
Yes, the Windows APIs are bigger and scarier than the equivalent UNIX APIs (where equivalents exist). The wealth of examples and development communities more than makes up for this, IMO.
Jon.
...you do have the choice to use either the CRT's open() function or Windows' OpenFile/CreateFile API calls; You don't have to use the more complicated one if you don't want the extra features. Most of the nastier parameters to CreateFile, such as that infrequently-used SECURITY_ATTRIBUTES structure, can be passed NULL to get default behaviour, so you don't have to set up the ACL on the file by hand if you don't want to.
I'm afraid it's the old rule coming into play here; Some complicated tasks require complicated APIs. On the other hand, MS could have stuck with *nix's user/group/everybody permissions and never required a CreateFile API. I'm sure the merits of ACLs are a bone of contention in some places.