Slashdot Mirror

The robot used for this mission was developed by SRI International, a non-profit research firm; one of whose spinoffs is Intuitive Surgical. This two-armed robot was developed initially for open trauma surgery for the military, and was upgraded before the NEEMO 9 mission as a deployable system. Here's a link with some information (note that the pictures are rather old; the surgeon side of the system looks different now):
http://www.sri.com/esd/med_devel/telepresence.html

You can read more about the mission here and see a very cool picture of the robot suturing with fish in the background:
http://www.sri.com/news/releases/04-20-06.html

Not long after suturing was demonstrated at lunar latency; rock samples were picked up with the same manipulators, demonstrating the application flexibility of the robotic arms.
http://spaceflight.nasa.gov/gallery/images/behindt hescenes/training/html/jsc2006e13997.html

Yeah

a) Experiment demonstrates previously theorized quantum telecloning which is one way to get an approximation of transmitted bits (simply, u can get X more bits correct than just guessing).
b) The quantum No Cloning Theorem is still safe and not violated, no need to get hysterical or pissed off. This is because No Cloning Theorem only forbids exact copies.
c) Fidelity was 58%

Experiment makes, without a doubt, a valuable contribution although didn't overturn fundamental theory.
Imho, Quantum cryptography still viable due to privacy enhancement techniques. Read more on that here http://www.ai.sri.com/~goldwate/quantum.html

http://www.sri.com/about/timeline/mouse.html

streaming video of the '68 demonstration

http://sloan.stanford.edu/MouseSite/1968Demo.html

For a slightly longer list. http://www.csl.sri.com/users/neumann/illustrative. html

I think there is a plug in that should scratch just about any itch. Nice.

Indeed, the Python and Perl plugins are both very nice and from the look of it more featureful than the Ruby plugin at the moment (though I expect it's only a short matter of time before that evens out). I think its more a matter of what languages aren't currently covered? There are apparently plugins for Eiffel and Haskell and Ocaml and SPARK and Scheme (though I can't vouch for quality on any of those) and pretty much anything else you can imagine (given that those were random searches on my part).

Jedidiah.

What a surprise. http://www.ai.sri.com/search/

like for shakey the robot?

<o:LastSaved>2002-01-31T17:32:00Z</o:LastSaved>

I suppose this is another example of Microsoft getting credit for company's innovations [apple.com]?

I'm getting tired of just about every discussion about Microsoft being used as an opportunity by Apple fans to promote their favorite company. Keep that sort of stuff to the Apple groups, please. Whether or not Microsoft copied a feature from Lotus Improv has nothing to do with Apple.

Furthermore, it is stupid for Apple fans to point fingers when it comes to copying: without copying other companies' innovations, Apple wouldn't exist; they copied the very core of their platform from others (SRI, PARC, Alan Kay). Apple does have better taste than Microsoft in what they copy, but I hardly think they are more original.

Does anyone else get the impression that this kind of crap has been going on since day one?

Shakey was the size of small refrigerator, wheeled and (in retrospect) ugly as hell. I always thought it looked like it was going to topple over. But a robot that's smart enough to manipulate its environment (move a wooden ramp into position so it could roll up a step and continue on the task you asked it to do in the first place) - ground breaking.

You can find more about shakey here.

(Yes, I did have a sad, lonely childhood. How did you guess? :)

I did not.

My bad. Though you were the other guy, sorry.

This is not going to be a discussion about semantics, is it? If I can push the probability below mere guessing, many people would call it "secure". Not in a mathematical sense, of course.

See, but I am talking in a mathematical sense. QC is neat, but I too often hear: "Unlike conventional crypto, QC in unbreakable/provably secure/etc."

The reality is, there a trade off between probability of undetected intercept, probability of false alarm, and message size. If the message is say, normal english prose, I don't need to get 100% of it to figure out what you're saying. As I understand it, you counter this problem by using privacy amplification.

First of all, there is no "alarm" of any sort. Qubits are transmitted; on average, half of them will be wasted (because the receiver has to guess at which basis to read them in). It'll be a little bit more or less than half, but about half.

Which is my point. The odds that it is exactly half are tiny, so you are going to be willing to tolerate a range of values.
As long as I can get something of value without notcibly throwing off your average I'm all set.

Ya this is really an implementation issue. The algorithm works provided we have working hardware.

The "perfect implementation" may turn out to be fundamentally impossible.

Even if you can read half of our key without us knowing, it's not a huge deal

If I can read half your key it's a HUGE deal. That would mean that quantum crypto just plain sucks. Sure you can apply other security measures on top of quantum crypto to try and fix the problem, but I could apply a lot of those same measures to IP via avain carrier

All you've done is sidestep my argument.

Think about it this way:
You and I are gambling on a coin toss. I do all the tossing and picking so I have the ability to rig a round with my double-headed coin. You want to be able to catch me if I rig a round. You tell me that you will be keeping a running average of the results and if things get too skewed, you're quitting. You give me the specfic number of rounds you will be averaging and how far away from the mean it can get before you'll cry foul.
Using this information I can calculate the risk I'm taking by rigging any number of rounds. I can then choose to rig a number of rounds that leaves it likely that I can do my rigging, play the rest fair and still most likely fall withing you established limit.

That's my point about quantum crypto being reliant on statistics. You can accept only a single possible result for, you need to allow a range of results. This leads to a vulnerability: You want to detect eavsdropping, that's kinda the whole point of quantum crypto. You want your probability of false alarm to be low (significantly less than 50%), so you need to accept a wide range of likely results. This means that there's going to be some amount of listenting in I can do where it will still be less than 50% likely that your alarm goes off.
To me this appears to be a weak point in the concept.
There are ways to combat this, but it seems that with QC, you're going to be forced to assume that you're handing over a certain number of your bits to the enemy.
In order to ensure a good probability of detection for a "significant" amount of eavesdropping, you're you going be forced to assume that X number of bits are always being intercepted, since it will not be until X+1 bits are intercepted that you will hit your desired probability of detection.
This then requires the design of a protocol where X bits can be intercepted, but it is still to hard to guess the message, so you start employing privacy amplification. While I'm not all that familiar with privacy amplification, I expect there are fundamental limits to it's effectiveness, just the same as in the fields of compression and error correction.

But again, even if you read 50% of our key (or 90% or 95% or ....), we can make it arbitrarily secure by increasing the key length.

Same thing with carrier pigeons......which is why I'm getting the impression that QC is overrated.

The only way we're going to break up something like M$, or any a cash bloated behemoth (remember Unsafe at Any Speed ), is when something really B-A-D happens; like people dying as a direct result of using it; as if the /0 error had happened while the ship was under fire from terrorists...

Until then... Learn to cope with the beast.

Remember that the outer part of the first computer mouse (invented at my company back in 1964) was also made of wood.

When all of the requirements of a complete, fair, trustworthy, straightforward-to-use voting system are taken together, they become extremely complex systems; systems that include all of the people and operation plans, not just the box. Anyone who has followed Peter G. Neumann's Risks Forum for the last few decades, if they aren't hopelessly depressed by the sheer number, scope and seeming endlessness of mistakes out there, at least understands how easy it is to get systems like this wrong. And how much attention to detail, and not just programming detail, it takes to get it right. In this case, there are competitive pressures to do a quick but superficial job, political pressures to appear to be fixing the 2000 election problems, and potential criminal pressures to control the outcome (among other things). Unfortunately, as with many of the cases that make it into the risks forum, it appears that the affected population needs to experience an actual, live failure before they will believe or admit that a failure is possible. The only solution is continued vigilance and action.

Sadly, this is nothing new.

Every software developer needs to read Peter Neuman's book Computer-Related Risks , and keep up with the Risks digest (comp.risks).

Learning from other's mistakes is much less painful.

Ahh, good ol' Shakey. I don't know if he'll get in--the younger folk at CMU don't seem too familiar with Nilsson's work.

At IJCAI this year, I was on the WUSTL team competing in the Robot Challenge. In homage to Shakey, we had our robot, Lewis, play "Take Five" for background music, as this is the background music in the Shakey video*. CMU also sent a large contingent to participate in the Robot Challenge. Not a one of their students got the joke. Even after being told it was a reference to Shakey, I don't think anybody from CMU gave us anything other than blank looks. Some of the other people on the Grace team got it, but none of the CMU'ers. Well, at least not anybody getting their hands dirty--I believe Dani Goldberg got it.

But yes, Shakey is certainly deserving to be in the hall of fame. A lot of great achievements in robotics were realized in Shakey--he was fully autonomous, capable of rather complicated planning, and did navigation by visual landmarks. Of course, he had to think for 15 to 20 minutes between actions, hence "Take Five", but this was the late 60's. No fancy on-board computers, laser rangefinders, or probabilistic methods, but duplicating Shakey's performance from scratch is a signifigent piece of work even today.

* I believe this is the same video. My internet connection is too slow to verify, but I've never heard of another Shakey video

It's a sober and informed discussion of engineering safety (mostly but not entirely computer related) that's been going on for almost twenty years.

Try entering "shuttle" in the search form. I did just now and found the brief, grim announcement of the Challenger explosion.

If you prefer to curl up with a dead tree by the fire, read moderator Peter Neumann's Computer Related Risks. It is also available in Japanese translation.

Now, few of us are likely to ever risk our lives flying in space shuttles. Maybe some of us might write the code or design the machinery the astronauts will trust with their lives. But all of us depend on computers every day for our livelihood, and many of us depend on them for our lives more than you would feel comfortable with if you understand the implications of it.

Fly on an airplane lately? Anything a little more modern than a DC-3? Do you know what fly by wire means? Ever write code with a stack overflow or heap corruption? What do you suppose that means for the embedded systems that run today's commercial aircraft?

Does your car have antilock brakes?

Read RISKS. It will make you a better programmer. Because it will put the fear of God into you.

Great idea! That covers the control aspect admirably! I shall be sure and tell the great folks on RISKS Digest that all their fears and previous examples of control law systems going wrong are of no import.

OK, that was harsh. FBW works OK in the real world, I guess, after 30-odd years of development. I wonder about tuning it for a model Helo but never mind that

Rather more seriously, how do you propose to tackle the mechanical reliability issues? Model RC engines aren't up in the RB211-runs-for-years reliability range, and all that whirling mass and consequent vibration takes it's toll on the structure too. I think this would actually be the killer for any real world application involving long-duration (longer than 10 minutes or so) flight, high availability and high required reliability. But maybe I worry too much.

Multics security. Bell Labs answer: Unix. Who needs all that "extra" security junk in Multics. We don't need to protect /etc/passwd because we use DES crypt and users always choose strong passwords. We'll make the passwd file world readable so we can translate uid's to usernames. Multi-level security? Naw, its simpler just to make everything Superuser.

FORTRAN/COBOL array bounds checking. Bell Labs answer: C. Who wants the computer to check array lengths or pointers. Programmers know what they are doing, and don't need to be "constrained" by the programming language. Everyone knows programmers are better at arithmetic than computers. A programmer would never make an off-by-one error. The standard C run-time library. gets(char *buffer), strcpy(char *dest, char *src), -what were they thinking?

And some summation of various MULTICS history information:

"A Look Into The MULTICS Operating System"
Joe Martin December 1, 2002
Introduction
Multics (Multiplexed Information and Computing Service) is a timesharing operating system that was used in mainframe computers from 1970 to 2000. Multics has a historic role in operating system development. It was renowned for being highly reliable, configurable, upgradeable, and secure. Multics' unique virtual memory system was among the first to feature segmentation, paging, and dynamic linking.
History
The Multics operating system began in 1965 as a joint project by MIT, Bell Telephone Laboratories, and General Electric's computer products division. The majority of Multics development was done on-site at MIT. The chief source of funding for the project was provided by ARPA (Advanced Research Projects Agency) of the US Department of Defense. ARPA contributed $2 million per year for eight years for Multics development. Bell Labs and GE also contributed comparable resources.2
In 1965, two of the lead Multics developers, Fernando Corbató and Victor Vyssotsky, wrote a paper entitled "Introduction and Overview of the Multics System." In the paper there were nine major goals laid out for Multics:
Convenient remote terminal use.
Continuous operation analogous to power & telephone services.
A wide range of system configurations, changeable without system or user program reorganization.
A high reliability internal file system.
Support for selective information sharing.
Hierarchical structures of information for system administration and decentralization of user activities.
Support for a wide range of applications.
Support for multiple programming environments & human interfaces.
The ability to evolve the system with changes in technology and in user aspirations.
In 1969, Bell Labs withdrew from the development effort. In 1970 GE sold its computer-related business to Honeywell, which offered Multics as a commercial product and sold it throughout the 1970's and 1980's.
One thing that Multics is widely known for is being the parent OS of UNIX. Bell Labs engineers Ken Thompson and Dennis Ritchie worked on Multics until Bell Labs dropped out of the Multics development effort in 1969 functional by 1970. Whereas Multics could support several users, this new operating system could only support one user. Engineer Brian Kernighan jokingly referred to it as

So, if I'm Mr. Burns and I find these things crawling around on the land around my powerplant, what's stopping me from sending Smithers out to pick them up and throw them in the lake?

Heh. When my doctoral advisor was at Stanford, Shakey the Robot was there, and always had a crowd of graduate students following it around. My advisor got tired of this, and told the folks running Shakey: "If Shakey wanders into my office, it's not coming out."

The operators put foil tape in front of my advisor's office door, and a photosensor in the base of Shakey, to guard against this calamity.

Or so I've been told...

• Microsoft Terraserver.com is one of the big ones, selling images from lots of satellite sources. Originally a 1998 joint venture with MS, USGS and Compaq. Free lower-res stuff, subscription medium-res, high-res pictures for sale.
  
• SRI Digital Earth -
  Talk
  - DARPA project, some good stuff.
  
• LivingEarth.com and EarthImaging.com - more hi-res maps.
  
• Fourmilab.to Earth Viewer also does satellites, stars, etc. Slightly overworked due to Iraq conflict so using lower-resolution pictures.
  
• OpenGIS.org - Standards for geo-enabling web and other apps.
  

You don't tend to hear about fancy jet fighters crashing due to computer failure. However, it does happen - it's just kept out of the mainstream media in the united fascist states of america. Wouldn't want to have an educated, thinking populace, now, woud we?

Actually, more worrying is computer failure in air traffic control. That tends not to get reported either (wouldn't want to worry the sheeple) - but does happen with disturbing frequency too. :-(.

You could never share between a portals-based game (like Descent) with a BSP-tree based game like Quake, because they organize data in a fundamentally different manner.

You can. Both of those formats can be automatically compiled from a shared representation as simple polygons. The resultant map won't have the same manual optimization as if an artist had tweaked it by hand, though. For at least one of the engines, it will be slower than necessary. Quake and Descent are both 3 generations old, though, so a modern computer will chuckle at the extra work. (And the created Descent map may be quite ugly, as stretched-inverse-cubes are unlikely to gracefully represent the details of a Quake level)

The more substantive problem to sharing maps is the gameplay itself. Imagine what would happen if Mr. Quake was spawned in a Descent map: he'd run 10 meters, then fall into an inescapable depression- because the map was built for a flying hero. Likewise, a Descent spaceship might find a Quake map terminally boring ("I just fly up, over the castle, back down, and win!")

If the maps are intended for more compatible genres, then it might work a little better. At least assumptions like "player needs to walk across floor to the doorway" will hold true. But still, building a fun, professional-quality game map means tweaking to exactly challenge the player's ability to move, jump, and shoot.

Restricting the desired category of games to highly realistic ones makes the idea of sharing terrain much more worthwhile. In that case, as long as the terrain correctly duplicates the original location, then any inability of the game system to work well in it can be filed as a bug against the software.

In particular, I've noticed a trend in several FPS programs to include the Fort McKenna MOUT training grounds as a playable map, which becomes a common point of comparison.

Read the RISKS digest, as comp.risks or at http://catless.ncl.ac.uk/Risks. Everyone who works with computers should read this regularly, it is much less painful to learn from other people's mistakes.

PGN put a bunch of the classic items together in a book a few years ago, called Computer-Related Risks.

Another interesting paper was written by Peter G. Neumann, it can be found here.

In that case, RTS players owe their debt more directly to Danny Bobrow, Nils Nilsson and my dad Bertram Raphael, who invented the A* algorithm while working on Shakey the Robot at SRI. (And those three in turn owe debts to Dijkstra, Minsky and others. Isn't science grand?)

I'd really like to know why private business has so much sway over government in these sorts of things.

First, they mention owning the patent for all fields of use except satellite broadcast...does that mean that if I'm going to prepare a digital photo for satellite Internet trasmission, their patent doesn't cover it?

Second, they mention declaring that they have / own / control the patent, but they don't mention who developed the technology. Does anybody know if they just bought the patent from someone? Did they actually come up with the technology? Or did they sign a contract with a patent holder who has given them exclusive licensing rights for certain fields of use?

JPEG does appear to be patent-encumbered, by patents such as this one, but I can't find any references to Forgent or the patent number referenced in its press release.

Cool stuff, really.

Cool stuff, really.

The Communications of the ACM article, is available online, at <http://www.csl.sri.com/users/neumann/insideris ks.html#140> (Inside Risks 140, CACM 45, 2, February 2002).

This was discussed on RISKS some time back. They provide a link to a copy of the article.

Also, from draft-masinter-url-i18n-08:

6. Security Considerations

If IRI entry software normalizes the characters entered, but the resource names on the interpreting side are not normalized accordingly, and the interpreting software does not take this into account, there is a possibility of "spoofing". Similar possibilities turn up when interpreting software accepts URIs in various native encodings or allows accents and similar things to be ignored.

"Spoofing" means that somebody may add a resource name that looks the same or similar to the user while actually being different, or a resource name that contains the same characters, but in a different encoding. The added resource may pretend to be the real resource by looking very similar, but may contain all kinds of changes that may be difficult to spot but can cause all kinds of problems.

Conceptually, this is no different from the problems surrounding the use of case-insensitive web servers. For example, a popular web page with a mixed case name (http://big.site/PopularPage.html) might be "spoofed" by someone who obtains access to (http://big.site/popularpage.html).

However, the introduction of character normalization, of additional mappings for user convenience, and of mappings for various encodings may increase the number of spoofing possibilities. In some cases, in particular for Latin-based resource names, this is usually easy to detect because UTF-8-encoded names, when interpreted and viewed as legacy encodings, produce mostly garbage. In other cases, when concurrently used encodings have a similar structure, but there are no characters that have exactly the same encoding, detection is more difficult. A good example may be the concurrent use of Shift_JIS and EUC-JP on a Japanese server.

Administrators of large sites which allow independent users to create subareas may need to be careful that the aliasing rules do not create chances for spoofing.

See also Neumann - Inside Risks

Blatant karma whoring...

The risks forum is available as a moderated newsgroup, or you can subscribe to the e-mail version. See the Risks info page.

However, cutting to the chase, the IEEE and the authors it represents really have little to fear in reality. The IEEE isn't "2600" Magazine; it doesn't deal with controversial subject matter on a regular basis. They aren't in the computer security business and they are unlikely to accept any remotely controversial manuscript in the first place. They changed their rules for one simple reason: they think it will make people care about the injustices of the law.

Crispin
----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Available for purchase

I believe Englebart was working for SRI.

Anyone who has ever read Comp.risks will be familiar with this subject. I think this group is mandatory reading material for anyone involved in computer science.

Peter Neumann has written a lot of insightful comments on electronic elections. Check out the "Electronic Voting" part of his page, which can be found here.

Anyone who has ever read Comp.risks will be familiar with this subject. I think this group is mandatory reading material for anyone involved in computer science.

Peter Neumann has written a lot of insightful comments on electronic elections. Check out the "Electronic Voting" part of his page, which can be found here.

They invented pointers and mice.

They may have invented pointers, but Doug Engelbart invented the mouse in 1968 while working at Stanford Research Institute. Xerox PARC invented a lot of cool stuff--in fact, they invented most of the things we take for granted in computing, but they didn't invent all of them.

RCC stands for Radio Common Carrier. This service provided the customer, basically, a restricted area from within which he could make and take phone calls. In smaller towns and cities, the coverage was from usually from a single tower site with the repeater pushing 250 watts or more at either 15x.x MHz or 45x.x MHz.

IIRC, there were 13 channels or so available for the area. These were simplex (one way at a time) channels. You talk they listen and vice-versa.

MTS-Mobile Telephone Service (not to be confused with Message Telecommunications Service) was a refinement on RCC including duplex conversation.

IMTS-Improved MTS provided the ability to use trunked radio systems granting longer range and occasionally better quality plus full duplex conversations.

IMTS's limitations were what really pushed Cellular development. The 'Improved' in IMTS was more a state of mind that a reality.

Check out Chapter 4: The Cellular Telephone for a pretty good rundown of the regulatory and economic push for cellular.

It's odd that this just made it into the media, as this project (known as SUO SAS) has been around for the better part of 2 years now--not counting the previous phases of development, which go back several more years.

While the article got a lot of things right, it was also a good portion of hype. I worked on the networking software for this (which is built on top of the TAO CORBA ORB, btw), and while it is conceivable that it might scale up to 10,000 nodes, it is unlikely to do so in it's current form (well, as of a few months ago, anyway). In fact, we faced more or less the same scalability problems that any ad-hoc wireless network system faces, plus the added complexities of having to guarantee consistent tactical picture maintenance (how do you keep a consistent data 'picture' of an entire battlefied among 10,000 separated nodes, with no guarantees on connectivity, or even addressing between any two particular nodes? Now, how do you tackle message-based quality-of-service on top of this mess?). So, for those of you wondering, the problem tackled by this system is a lot bigger and more complicated that than faced by peer-to-peer filesharing systems (think superset of the gnutella problem), and the algorithms we were developing weren't perfect--or even good, necessarily. The problems facing ad-hoc networking are certainly as unsolved and difficult as they were before.

Another important note is that while we ultimately got our way and were able to use Linux for development (partly because we absolutely refused to work with a platform where we didn't have access to the network stack code), it was kind of an uphill battle with DARPA to do so. Linux still isn't qualified to be running on any type of deployed military system, and believe me, we heard about it constantly (I still shudder at the thought of trying to do our development in Windows...)

All that said, the concept of the project was/is pretty cool, but, as always, reality is less dramatic than its press release. If you want more info on the project and related research, here are some links:

Info on geo-routing algorithms (directly relevant to the SUO SAS problem)

A blurb on SUO SAS by SRI

The DARPA ATO web page describing SUO SAS

While I don't think either of them were really overtly trying to mentor me, I owe a lot of credit for what I know and what I can do to a couple of brilliant programmers that I've had the privilege to work with. Both of these fellows are very kind, pleasant people and went out of their way to help me. They also both go out of their way to write correct code, as opposed to, say, just screwing around with it until it sort of works.

I met Haim Zamir at Live Picture (now MGI Software) in 1997 where I really began my C++ effort in a serious way (I tried it in 1990 to write test tools at Apple but didn't really enjoy the experience). Have a look at Haim's Resume, particularly under "Skills" where he lists:

Well grounded in disciplines of software engineering for correctness, robustness, performance, and longevity

Another brilliant programmer is my friend Andrew Green. Andy spares no amount of effort to get his code just right - he devoted nine years to developing the ZooLib cross-platform application framework before releasing under the MIT License. (Not five years as I say on the page.)

If you think being correct, as opposed to merely working ok isn't important, imagine trying to get platform-independent reference counted smart pointers to work in a multithreaded application framework. Andy did.

For an archive of anecdotes of interesting, funny and sometimes tragic technology quality problems, please read:

• The Forum on Risks to the Public in Computers and Related Systems, with such anecdotes as:
  • The Sinking of the USS Gitarro (because of either poor training, poor UI, or both)
  • The scary MSWord residue feature - exchange Word documents during legal negotiations?
  • Also see the book Computer Related Risks by Risks moderator Peter Neumann

If you write software, another good investment (more important than your hardware investment), is buying and reading good books. As a software consultant I keep the canceled checks and receipts for my technical book purchases; in 1999 I deducted about $750 worth of technical books from my taxes and about $250 in 1998.

But there are a lot of bad software books out there; much as there was a gold rush due to the Internet, there was a smaller-scale gold rush for technical book authors over the last couple years. A really good source of straight-talking book reviews by people who have good reason to know what they're talking about is maintainted by the Association of C and C++ Users at:

• The ACCU Book Reviews Section

(Note to CowboyNeal - writing C-sharp with the pound sign set off the lameness filter, driving me damn near out of my skull. How about adding something to the preview to let us know which characters are lame, exactly?).

And good news for those of you across the pond (but bad news for me), it's a British organization and holds regular technical conferences. I believe they also send observers to the ISO standards bodies.

If you program in C++ you should read these two books by Scott Meyers and put them to practice in your code. Read each item one at a time and then go through your code from beginning to end to see how you can apply it:

• Effective C++ - ACCU Review - be sure to get the 2nd Edition
• More Effective C++ - ACCU Review

-Weffc++ (C++ only)

Warn about violations of various style guidelines from Scott Meyers' Effective C++ books. If you use this option, you should be aware that the standard library headers do not obey all of these guidelines; you can use `grep -v' to filter out those warnings.

C++ is not the problem language it's often said to be if you follow Meyers' advice, but if you prefer C you certainly can have problems there too - and note that the preferred language for Gnome is C (while KDE is an extended C++), for C programmers you should read:

• C Traps and Pitfalls - ACCU Review

• The Elements of Programming Style

Back to the topic of compiler warnings, remember reading about lint in Kernighan and Ritchey's The C Programming Language? When I started out in my first real programming job, doing Sun system administration and writing image processing software back in the late '80's, I learned to write "lint" targets in my Makefiles, and I'd type "make lint" after editing but before compiling to actual machine code. This made my code much easier to debug and quicker to develop.

Much of lint's function is now available in the warnings of GCC (but I don't think all of it), but there are some proprietary products that will do extremely rigorous statis analysis of your source code. I haven't yet used either (although I plan to) but the two I know about are:

• PC-Lint and FlexeLint
• CodeWizard - Linux Journal Review

• Insure

You can search by patent number here.

And speaking of web programming, many Slashdot readers write web applications (Linux being a "server OS" as they say). How many of you validate the HTML that's generated by the web applications you write?

Your HTML should work well in any browser and it should be well designed for easy usability. I don't mean attractive graphics. I mean it shouldn't suck. Two links on design:

• Useit
• Ask Tog

• By uploading static files from your browser - most convenient during hand composition
• By entering its URL in a form - best for dynamic pages and final tuning of static pages

Mike

Open-box software is not a panacea -- it does not solve all the problems. It still requires all of the discipline in development and operation that we would like to see in proprietary closed-box software. But it has enormous potential, and needs to be pursued as a serious contender.

In other words, open source software could be more reliable than closed source software, if it were produced in a disciplined way. Anyone who imagines that it is created in that way ought to spend a little more time at Freshmeat.

Tim

Go to Neumann's page above and search for "Robust" using the "Find in Page" function of your browser.

Neumann is the moderator of The Forum on Risks to the Public in Computers and Related Systems and the author of the book Computer Related Risks, so he should know whereof he speaks.

Please also read Open Source and These United States.

In the previous article, someone suggested the problem of how to compose a letter to congressional representatives to promote open source - perhaps simply printing out that paper and mailing it to them with a brief cover letter explaining how you've found a way the U.S. Government and Military can achieve substantial savings in its software purchases, along with gains in reliability, would be helpful.

Mike

Peter G Neumann, the moderator of the RISKS forum, has collected information and recommendations on electronic and Internet elections.
__

According to their site, they are a "nonprofit corporation." Go see for yourself, at the bottom.

SRI plans to gradually release selected EMERALD components to the public domain. One such component, eXpert-BSM, is currently available for download from SRI's Web site (see Resources). eXpert-BSM, a small, host-based sensor that acts as a security daemon, is "particularly good for detecting misuse on Solaris operating systems," Porras said. Since SRI is a nonprofit research institute, the components made available on its Web site are released without charge to the public domain. "If we don't make certain components available on the Internet, we will still make them available to [government organizations] and to the entire DoD research community," Porras remarked.

At Least someone with some brains and experience will be able to look at it and give it a thumbs up or thumbs down.

This may be a deeper answer than you are looking for, but I believe that government agencies have fallen far short in terms of a greater vision for sharing public data. In particular, government agencies need to jump on the XML bandwagon and begin to develop consistent data format for common types public information, which they should then provide via the web.

I do technical consulting work on public sector planning issues and there is an enormous amount of public data that should be provided through the web, but is not. For example, geographic data representing public infrastructure (roads, transit, etc.) and public records (property lines, housing) are not provided using any sort of consistent framework. Because this data is kept by many agencies across the country at different levels of government (local, state, federal), there is an enormous amount of duplication and waste within agencies themselves. Indeed, there are 1,000 different GIS formats and projections; even when the data is availible digitally, there is no server from which it can be read. The Census Beareau (which has a horrible website) does the best job of data sharing through its nationally availible TIGER GIS files, but no one has even begun to create a distributed framework for sharing and combining geographic data from multiple servers, using a consistent format.

In short, publishing basic HTML pages uses only a tiny fraction of the web's capabilites to improve governments. Is there is any organization that could benifit more from a good data-sharing framework? There is a DARPA-funded project - GeoVRML - at SRI that addresses some of these issues that sprang out of the fledgling digital earth initiative. Clearly, this will require federal initiative, but if you are a government webmaster, this is the type of vision that you should be promoting within your agency.