Wednesday, July 27, 2011

Hidden Variables

Ever wonder what preprocessor symbols your GNU C and C++ compiler automatically includes in your program? I'm talking about symbols above and beyond those specified in the ANSI C and ISO C++ standards, like __FILE__, __LINE__, __func__, and __cplusplus. Having gotten bit by this once or twice, I've learned it pays to know these things. Try

gcc -dM -E - < /dev/null


g++ -dM -E - < /dev/null

which produce the same set of #define lines for me.

#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 2
#define __unix__ 1
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __GNUC_PATCHLEVEL__ 3
#define __DEC64_MAX_EXP__ 385
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __UINTMAX_TYPE__ long long unsigned int
#define __linux 1
#define __DEC32_EPSILON__ 1E-6DF
#define __unix 1
#define __LDBL_MAX_EXP__ 16384
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __DBL_DIG__ 15
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __DEC32_MAX__ 9.999999E96DF
#define __SIZEOF_LONG__ 4
#define __DECIMAL_DIG__ 21
#define __gnu_linux__ 1
#define __LDBL_HAS_QUIET_NAN__ 1
#define __GNUC__ 4
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 12
#define __BIGGEST_ALIGNMENT__ 16
#define __DBL_MAX__ 1.7976931348623157e+308
#define __DBL_HAS_INFINITY__ 1
#define __DEC32_MIN_EXP__ (-94)
#define __LDBL_HAS_DENORM__ 1
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __DEC32_MIN__ 1E-95DF
#define __DBL_MAX_EXP__ 1024
#define __DEC128_EPSILON__ 1E-33DL
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __SIZEOF_SIZE_T__ 4
#define __SIZEOF_WINT_T__ 4
#define __GXX_ABI_VERSION 1002
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MIN__ 2.2250738585072014e-308
#define __DECIMAL_BID_FORMAT__ 1
#define __DEC128_MIN__ 1E-6143DL
#define __DBL_HAS_DENORM__ 1
#define __NO_INLINE__ 1
#define __i386 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "4.4.3"
#define __DEC64_EPSILON__ 1E-15DD
#define __DEC128_MIN_EXP__ (-6142)
#define __i486__ 1
#define unix 1
#define __i386__ 1
#define __SIZE_TYPE__ unsigned int
#define __ELF__ 1
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __SIZEOF_PTRDIFF_T__ 4
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 2147483647L
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __CHAR16_TYPE__ short unsigned int
#define __DEC64_MANT_DIG__ 16
#define __DEC32_MAX_EXP__ 97
#define linux 1
#define __LDBL_MANT_DIG__ 64
#define __DBL_HAS_QUIET_NAN__ 1
#define __WCHAR_TYPE__ int
#define __SIZEOF_FLOAT__ 4
#define __DEC64_MIN_EXP__ (-382)
#define __FLT_DIG__ 6
#define __INT_MAX__ 2147483647
#define __i486 1
#define __FLT_MAX_EXP__ 128
#define __DBL_MANT_DIG__ 53
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __LDBL_MIN_EXP__ (-16381)
#define __SSP__ 1
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define __SIZEOF_WCHAR_T__ 4
#define __DEC_EVAL_METHOD__ 2
#define __INTMAX_MAX__ 9223372036854775807LL
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.40282347e+38F
#define __SIZEOF_DOUBLE__ 8
#define __FLT_MIN_10_EXP__ (-37)
#define __INTMAX_TYPE__ long long int
#define i386 1
#define __DEC128_MAX_EXP__ 6145
#define __GNUC_MINOR__ 4
#define __DEC32_MANT_DIG__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __STDC__ 1
#define __PTRDIFF_TYPE__ int
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-4931)
#define __SIZEOF_LONG_LONG__ 8
#define __LDBL_DIG__ 18
#define __GNUC_GNU_INLINE__ 1

Saturday, July 23, 2011

Value Subtract

Back in the mid 1990s I spent a few years as a manager at the National Center for Atmospheric Research, a national lab that was chock full of supercomputers and smart people. Apparently I wasn't one of the smart people. It wasn't the first time I'd made the career misstep to go into management. This is how I came to understand that I added no value to that organization while I was in that role.

I went off to the People's Republic of China for a month on a scientific exchange program sponsored by the U.S. National Science Foundation and it's PRC counterpart. This was a pretty major departure, pun intended. Nowadays I'd probably be able to keep up just carrying my Blackberry world phone and maybe my iPad. But way back then I was effectively cut off for a month pretty much from the entire English speaking and writing world.

Before I left, I programmed my desktop Solaris workstation to reply automatically to all of my incoming electronic mail, while filtering, categorizing, and filing it all away. At the time, I got maybe seventy email messages a day. That may seem like a low volume now, but remember this was BS, Before Spam, before the general public at large had access to electronic mail.

I had many adventures in China. I gave several talks. I kept a journal. I took photographs. It was like being on another planet. My journal could be read as a first contact story.

I returned to my office a month later, twelve pounds lighter and sporting a beard. I discovered that I had botched my email script. It had thrown all of the incoming email away. All of it. An entire month's worth of vitally important information consisting of status and problem reports, conference and request for proposal announcements, meeting summaries, vendor pleas, and cover their ass memos. All gone.

Here is what I learned in the days and weeks to come: it didn't matter. It never mattered. Ever. I never needed to know what was in any of those electronic communiques.

Perhaps you might have chosen to interpret this as a reflection on the low value of most of that email. Or on my ability to come back up to speed quickly. But I figured it meant I had actually very little to contribute to this organization, which for the most part ran just fine without me while I was gone for a twelfth of a year. If I wanted to make a difference, it was time for me to find something else to do with my life.

So I did. I quit that job just a few months later when an opportunity came along to join Bell Labs and return to being a technologist. I didn't fully appreciate at the time the impact, positive for the most part, this move would have on my career. And of course that job change would bring with it its own major life lessons.

But those are stories for another day.

Tuesday, July 19, 2011

Cyberspace Is The Next Battlefield

The U.S. Department of Defense just released an unclassified version of the document Department of Defense Strategy for Operating in Cyberspace. Yes, this is what I read for fun. It's only thirteen pages long. It's worth a look.

Department of Defense Strategy for Operating in Cyberspace

This very readable document outlines five strategic initiatives in how the DoD is going to deal with threats on the battlefield of cyberspace. But it's not really the initiatives I'm so concerned with. I like getting some insight into what this over half a trillion dollar agency is actually worried about and where they are likely to be spending their money. When it comes to technology, I feel about the DoD the way I do about high performance computing and the big cloud providers: whither they go, soon I shall be.

Here are some snippets from the document that caught my eye. Emphasis is mine.

Low barriers to entry for malicious cyber activity, including the widespread availability of hacking tools, mean that an individual or small group of determined cyber actors can potentially cause significant damage ... Small-scale technologies have an impact disproportionate to their size ... (p. 3)
The potential for small groups to have an asymmetric impact in cyberspace creates very real incentives for malicious activity. ... Whether the goal is monetary, access to intellectual property, or the disruption of critical DoD systems, the rapidly evolving thread landscape presents a complex and vital challenge for national and economic security. ... (p. 3)
... DoD is particularly concerned with three areas of potential adversarial activity: theft or exploitation of data; disruption or denial of access or service ...; and destructive action including corruption, manipulation, or direct activity ... (p. 3)
... computer-induced failure of power grids, transportation networks, or financial systems could cause massive physical damage and economic disruption. (p. 4)

When I've seen the term asymmetric warfare in the past, it has usually been used in the context of a high-technology opponent versus a low-technology opponent, or adversaries using traditional versus guerrilla strategies. But it applies here in an economic sense: it doesn't take a weapons program the scope of the Manhattan Project to bring economic ruin in the realm of cyberspace.

The Stuxnet worm completely changed the way I think about threats. Although it was surely an expensive program, requiring huge amounts of technical talent, the impact it had on Iran's nuclear program was surely disproportionately large compared to its cost. It is not hard to imagine either state or non-state actors bringing similar talent to bear on other critical technical infrastructure in the U.S. or elsewhere.

At a recent conference, I got chills thinking what malware inspired by Stuxnet could do if it infiltrated the firmware of tape drives used in a mass storage system. Don't laugh: most of the data in the world is still stored in tape. Son of Stuxnet could modify or remove data as it is being written to tape or as it is read back. This could render ground installations invisible in satellite photographs or accounts untraceable in financial records. A colleague of mine quipped that this kind of thing already happens by accident due to firmware bugs. The idea of it happening deliberately with specific intent is alarming.

... Every year, an amount of intellectual property larger than that contained in the Library of Congress is stolen from networks maintained by U.S. businesses, universities, and government departments and agencies. ... military strength ultimately depends on economic vitality ... (p. 4)
... Many U.S. technology firms outsource software and hardware factors of production, and in some cases their knowledge base, to firms overseas. Additionally, increases in the number of counterfeit products and components demand procedures to both reduce risk and increase quality. ... (p. 9)

Globalization is here to stay. That means it's now more important than ever to manage your supply chain and understand where your parts, both software and hardware, are really coming from.

... DoD's acquisition processes and regulations must match the technology development life cycle. With information technology, this means cycles of 12 to 36 months, not seven to eight years. ... DoD will be willing to sacrifice or defer some customization to achieve speedy internal improvements. ... (p. 11)

In Product Development as War Fighting I applied the principles espoused by the late John Boyd, the U.S. Air Force officer who revolutionized both air and ground combat, to software development. The kind of rapid iteration that this document discusses is just the kind of thing Boyd was talking about about when he referred to fast transients and his Observe, Orient, Decide Act (OODA) cycle in combat. Victory goes to the opponent who can make the correct decision and act upon it the most quickly. This applies to the choice of technology and its deployment as well.

If your organization is developing its own strategy to deal with information security, it is worth your time to read this document and see if they thought of something that you missed. For sure, they have a lot more eyes on the problem.

Saturday, July 16, 2011

Smaller Is Better

The desktop that I use for software development is an Apple Mac Mini. It's mostly an X window server for a couple of Linux systems that are my build and repository servers. Below you can see the tiny silver Mac Mini sitting on a shelf above the Cinema Display.

Contraption using Android FroYo, SSH, and Bash

Here are the servers in the basement, next to a spare LCD display, a honking big H-P full duplex color laser printer, and two two-drawer fire-rated filing cabinets. My backup strategy is as follows: I backup my two principle laptops, a MacBook Air and a ThinkPad X61t, to USB disk drives; I backup the two servers by doing disk-to-disk copies to removable disk drives; I do smaller incremental backups to media like CD and DVD ROMs and USB thumb drives; I also keep backups of individual projects on an off-site server.

Fire Safes

The backups are kept in one of the fire safe drawers. When I travel, any of the laptops that don't travel with me also go into the drawer. The ThinkPad actually fits in a file folder. The Air doesn't quite fit, but there is enough clearance for it to just sit length-wise on top of the file folders.

Fire Safe: Backups

On a recent trip I was just taking my Blackberry and my iPad. Both laptops went into the safe. I was regretting not having done a recent backup of my desktop system, when I realized I was thinking about this all wrong. The Mac Mini is small. Really small. File folder small.

Mac Mini

All of the connectors on the business end of the Mini disconnect easily.

Mac Mini Desktop: The Business End

This makes it trivial to shutdown my desktop, disconnect it from the network, display, and USB cables, and place the entire desktop system in a file folder in the fire safe, leaving the cables velcro-tied together and just dangling.

Mac Mini Desktop: Cables

Good luck doing that with a standard-sized white box PC cabinet.

Smaller is better.

Wednesday, July 06, 2011

We've all got time enough to cry.

David Finkleman and his colleagues have published an article, "The Future of Time: UTC and the Leap Second", in the July-August 2011 issue of American Scientist (Vol. 99, No. 4, pp. 312-319; also: here and here) on the proposal by the Radiocommunications Sector of the International Telecommunications Union (ITU-R) to cease adding leap seconds to Coordinated Universal Time (UTC) so that it would no longer be kept in sync with the earth's rotation. The ITU-R organization is proposing this because it's just too hard.

GPS time already forgoes the use of leap seconds, and as a result, just in the time that GPS time has existed, the wall clock time we know from the rotation of the Earth, slowing due to the drag caused by the lunar tides, has drifted fifteen seconds from the time GPS keeps through the use of its atomic clocks. Hardware and software that displays wall clock time, but which synchronizes to GPS time, has to keep track of those missing leap seconds and add them back in. If such a change were to be made, it would mean UTC would be completely abstracted away from the wall clock time we use on a day to day basis.

Is this a good thing, or a bad thing? I don't know. But it sure as heck is not a minor thing. I got into the study of time for two reasons: it turned out to be critical to many of the products I've worked on in the past two decades, and much of the software I've used gets it wrong. UTC diverging from the wall clock time we use to manage our systems will only make this harder.

I've added an update to my 2006 article on date and time keeping "Does anybody really know what time it is?".