The effort, dubbed RE<C (shorthand for "renewable energy less than coal"), calls for Google to invest in companies developing clean-energy technologies and for Google itself to next year invest tens of millions in research and development in renewable energy.

Technologies created by Google will likely be used by Google, whose data centers are voracious consumers of electricity. The company envisions either selling electricity from renewable sources or licensing technology on terms that would promote broad adoption, according to company founders Larry Page and Sergey Brin.

Its overarching goal is to produce 1 gigawatt of electricity from renewable sources--enough to power the city of San Francisco--faster than the current pace of green-technology development.

"The main crux of this is that we believe that you can do it cheaper than coal...and we want to make it happen now," said Page, Google's president of products. "Most people who are doing this now are trying to do it less expensive than people before, but they are not trying for that goal which will have a significant effect on the world."

Investments in other companies will be funded by Google's philanthropic arm, Google.org, which has about $2 billion worth of Google stock available to it.

In particular, Google will be investing in solar-thermal technology, wind power, and geothermal systems. Its target is to fall below the price of coal power generation, which can be as low as 2.5 cents per kilowatt-hour, said Bill Weihl, Google's green-energy czar.

Google said it's already working with eSolar, a solar-thermal company building systems for utilities to generate electricity from heat. It has invested in Makani Power, which is pursuing electricity generation by harnessing wind at high altitudes.

As part of the effort, Google will be hiring experts in the energy field. It expects to hire 20 to 30 people into its clean-energy division in the next year. More substantial investments will come as energy projects come online, Weihl said.

Although an ambitious plan, Google's impact on the clean-tech market segment in the near term is likely to be more psychological than financial, said Paul Clegg, a senior equity analyst who follows clean tech at Jefferies.

"Tens of millions of dollars is not a small number, obviously, but you're spreading that over things that a lot of other companies are attacking on an individual basis with more money going at it," Clegg said. "I think they'd have to invest a lot more money to get the next Manhattan Project going."

However, Google's initiative is significant in that it could indicate how corporations will start addressing their energy needs and climate change going forward, he said.

A strategic move
The push to mitigate the effects of climate change through clean energy falls squarely into Google.org's missions to improve human health and alleviate poverty, said Larry Brilliant, the executive director of Google.org.

Its foray into the energy business is part of Google's corporate charter to expand into new business areas that are "strategic," according to Brin.

As a large consumer, Google can benefit from cheaper sources of electricity and technologies it successfully develops could generate revenue, he said. In addition, those technologies could potentially bring cheaper sources of electricity to areas of the world that don't have it.

"For economic development to be possible in these areas and for new industries to be spurred along, we want to develop cheap alternatives that are widely available," Brin said. "This isn't just about solving a problem. It also creates a gigantic opportunity."

Thus far, you've seen a couple of HLA programs that will actually compile and run. However, all the statements appearing in programs to this point have been either data declarations or calls to HLA Standard Library routines. There hasn't been any real assembly language. Before we can progress any further and learn some real assembly language, a detour is necessary; for unless you understand the basic structure of the Intel 80x86 CPU family, the machine instructions will make little sense.

The Intel CPU family is generally classified as a Von Neumann Architecture Machine. Von Neumann computer systems contain three main building blocks: the central processing unit (CPU), memory, and input/output devices (I/O). These three components are connected together using the system bus (consisting of the address, data, and control busses). The block diagram in Figure 1-4 shows this relationship.

Figure 1-4: Von Neumann Computer System Block Diagram.

The CPU communicates with memory and I/O devices by placing a numeric value on the address bus to select one of the memory locations or I/O device port locations, each of which has a unique binary numeric address. Then the CPU, I/O, and memory device pass data between themselves by placing the data on the data bus. The control bus contains signals that determine the direction of the data transfer (to/from memory, and to/from an I/O device).

Within the CPU the registers is the most prominent feature. The 80x86 CPU registers can be broken down into four categories: general purpose registers, special-purpose application accessible registers, segment registers, and specialpurpose kernel mode registers. This text will not consider the last two sets of registers. The segment registers are not used much in modern 32-bit operating systems (e.g., Windows, BeOS, and Linux); because this text is geared around programs written for 32-bit operating systems, there is little need to discuss the segment registers. The special-purpose kernel mode registers are intended for writing operating systems, debuggers, and other system level tools. Such software construction is well beyond the scope of this text, so once again there is little need to discuss the special purpose kernel mode registers.

The 80x86 (Intel family) CPUs provide several general purpose registers for application use. These include eight 32-bit registers that have the following:

EAX, EBX, ECX, EDX, ESI, EDI, EBP, and ESP

The "E" prefix on each name stands for extended. This prefix differentiates the 32-bit registers from the eight 16-bit registers that have the following names:

AX, BX, CX, DX, SI, DI, BP, and SP

Finally, the 80x86 CPUs provide eight 8-bit registers that have the following names:

AL, AH, BL, BH, CL, CH, DL, and DH

Unfortunately, these are not all separate registers. That is, the 80x86 does not provide 24 independent registers. Instead, the 80x86 overlays the 32-bit registers with the 16-bit registers, and it overlays the 16-bit registers with the 8-bit registers. Figure 1-5 on the next page shows this relationship.

Figure 1-5: 80x86 (Intel CPU) General Purpose Registers.

The most important thing to note about the general purpose registers is that they are not independent. Modifying one register may modify as many as three other registers. For example, modification of the EAX register may very well modify the AL, AH, and AX registers. This fact cannot be overemphasized here. A very common mistake in programs written by beginning assembly language programmers is register value corruption because the programmer did not fully understand the ramifications of Figure 1-5.

The EFLAGS register is a 32-bit register that encapsulates several single-bit boolean (true/false) values. Most of the bits in the EFLAGS register are either reserved for kernel mode (operating system) functions or are of little interest to the application programmer. Eight of these bits (or flags) are of interest to application programmers writing assembly language programs. These are the overflow, direction, interrupt disable^[4], sign, zero, auxiliary carry, parity, and carry flags. Figure 1-6 shows the layout of the flags within the lower 16 bits of the EFLAGS register.

Figure 1-6: Layout of the Flags Register (Lower 16 Bits of EFLAGS).

Of the eight flags that are usable by application programmers, four flags in particular are extremely valuable: the overflow, carry, sign, and zero flags. Collectively, we will call these four flags the condition codes.^[5] The state of these flags lets you test the result of previous computations. For example, after comparing two values, the condition code flags will tell you if one value is less than, equal to, or greater than a second value.

One important fact that comes as a surprise to those just learning assembly language is that almost all calculations on the 80x86 CPU involve a register. For example, to add two variables together, storing the sum into a third variable, you must load one of the variables into a register, add the second operand to the value in the register, and then store the register away in the destination variable. Registers are a middleman in nearly every calculation. Therefore, registers are very important in 80x86 assembly language programs.

Another thing you should be aware of is that although some registers are referred to as "general purpose" you should not infer that you can use any register for any purpose. The SP/ESP register pair for example, has a very special purpose that effectively prevents you from using it for any other purpose (it's the stack pointer). Likewise, the BP/EBP register has a special purpose that limits its usefulness as a general purpose register. All the 80x86 registers have their own special purposes that limit their use in certain contexts. For the time being, you should simply avoid the use of the ESP and EBP registers for generic calculations; also keep in mind that the remaining registers are not completely interchangeable in your programs.

1.7.1 The Memory Subsystem

A typical 80x86 processor running a modern 32-bit OS can access a maximum of 2³² different memory locations, or just over four billion bytes. A few years ago, four gigabytes of memory would have seemed like infinity; modern machines, however, are pushing this limit. Nevertheless, because the 80x86 architecture supports a maximum four-gigabyte address space when using a 32-bit operating system like Windows or Linux, the following discussion will assume the fourgigabyte limit.

Of course, the first question you should ask is, "What exactly is a memory location?" The 80x86 supports byte addressable memory. Therefore, the basic memory unit is a byte, which is sufficient to hold a single character or a (very) small integer value (we'll talk more about that in the next chapter).

Think of memory as a linear array of bytes. The address of the first byte is zero, and the address of the last byte is 2³²-1. For a Pentium processor, the following pseudo-Pascal array declaration is a good approximation of memory:

Memory: array [0..4294967295] of byte;

C/C++ and Java users might prefer the following syntax:

byte Memory[4294967296];

To execute the equivalent of the Pascal statement "Memory [125] := 0;" the CPU places the value zero on the data bus, the address 125 on the address bus, and asserts the write line (this generally involves setting that line to zero), as shown in Figure 1-7.

Figure 1-7: Memory Write Operation.

To execute the equivalent of "CPU := Memory [125];" the CPU places the address 125 on the address bus, asserts the read line (because the CPU is reading data from memory), and then reads the resulting data from the data bus (see Figure 1-8).

Figure 1-8: Memory Read Operation.

This discussion applies only when accessing a single byte in memory. So what happens when the processor accesses a word or a double word? Because memory consists of an array of bytes, how can we possibly deal with values larger than a single byte? Easy, to store larger values the 80x86 uses a sequence of consecutive memory locations. Figure 1-9 shows how the 80x86 stores bytes, words (two bytes), and double words (four bytes) in memory. The memory address of each of these objects is the address of the first byte of each object (i.e., the lowest address).

Figure 1-9: Byte, Word, and Double Word Storage in Memory.

Modern 80x86 processors don't actually connect directly to memory. Instead, there is a special memory buffer on the CPU known as the cache (pronounced "cash") that acts as a high-speed intermediary between the CPU and main memory. Although the cache handles the details automatically for you, one fact you should know is that accessing data objects in memory is sometimes more efficient if the address of the object is an even multiple of the object's size. Therefore, it's a good idea to align four-byte objects (double words) on addresses that are an even multiple of four. Likewise, it's most efficient to align two-byte objects on even addresses. You can efficiently access single-byte objects at any address. You'll see how to set the alignment of memory objects in a later chapter.

Before leaving this discussion of memory objects, it's important to understand the correspondence between memory and HLA variables. One of the nice things about using an assembler/compiler like HLA is that you don't have to worry about numeric memory addresses. All you need to do is declare a variable in HLA and HLA takes care of associating that variable with some unique set of memory addresses. For example, if you have the following declaration section:

static
     i8    :int8;
     i16   :int16;
     i32   :int32;

HLA will find some unused eight-bit byte in memory and associate it with the i8 variable; it will find a pair of consecutive unused bytes and associate i16 with them; finally, HLA will find four consecutive unused bytes and associate the value of i32 with those four bytes (32 bits). You'll always refer to these variables by their names, you generally don't have to concern yourself with their numeric address. Still, you should be aware that HLA is doing this for you behind your back.

 

Red Hat Linux comes with a variety of resource monitoring tools. While there are more than those listed here, these tools are representative in terms of functionality. The tools are:

• free

• top (and GNOME System Monitor, a more graphically oriented version of top)

• vmstat

• The Sysstat suite of resource monitoring tools

Let us look at each one in more detail.

1. free

The free command displays system memory utilization. Here is an example of its output:

total used free shared buffers cached Mem: 255508 240268 15240 0 7592 86188 -/+ buffers/cache: 146488 109020 Swap: 530136 26268 503868

The Mem: row displays physical memory utilization, while the Swap: row displays the utilization of the system swap space, and the -/+ buffers/cache: row displays the amount of physical memory currently devoted to system buffers.

Since free by default only displays memory utilization information once, it is only useful for very short-term monitoring, or quickly determining if a memory-related problem is currently in progress. Although free has the ability to repetitively display memory utilization figures via its -s option, the output scrolls, making it difficult to easily see changes in memory utilization.

Tip

A better solution than using free -s would be to run free using the watch command. For example, to display memory utilization every two seconds (the default display interval), use this command: watch free The watch command issues the free command every two seconds, after first clearing the screen. This makes it much easier to see how memory utilization changes over time, as it is not necessary to scan continually scrolling output. You can control the delay between updates by using the -n option, and can cause any changes between updates to be highlighted by using the -d option, as in the following command: watch -n 1 -d free For more information, refer to the watch man page. The watch command runs until interrupted with [Ctrl]-[C]. The watch command is something to keep in mind; it can come in handy in many situations.

2. top

While free displays only memory-related information, the top command does a little bit of everything. CPU utilization, process statistics, memory utilization — top does it all. In addition, unlike the free command, top's default behavior is to run continuously; there is no need to use the watch command. Here is a sample display:

11:13am up 1 day, 31 min, 5 users, load average: 0.00, 0.05, 0.07 89 processes: 85 sleeping, 3 running, 1 zombie, 0 stopped CPU states: 0.5% user, 0.7% system, 0.0% nice, 98.6% idle Mem: 255508K av, 241204K used, 14304K free, 0K shrd, 16604K buff Swap: 530136K av, 56964K used, 473172K free 64724K cached PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 8532 ed 16 0 1156 1156 912 R 0.5 0.4 0:11 top 1520 ed 15 0 4084 3524 2752 S 0.3 1.3 0:00 gnome-terminal 1481 ed 15 0 3716 3280 2736 R 0.1 1.2 0:01 gnome-terminal 1560 ed 15 0 11216 10M 4256 S 0.1 4.2 0:18 emacs 1 root 15 0 472 432 416 S 0.0 0.1 0:04 init 2 root 15 0 0 0 0 SW 0.0 0.0 0:00 keventd 3 root 15 0 0 0 0 SW 0.0 0.0 0:00 kapmd 4 root 34 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 5 root 15 0 0 0 0 SW 0.0 0.0 0:00 kswapd 6 root 25 0 0 0 0 SW 0.0 0.0 0:00 bdflush 7 root 15 0 0 0 0 SW 0.0 0.0 0:00 kupdated 8 root 25 0 0 0 0 SW 0.0 0.0 0:00 mdrecoveryd 12 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald 91 root 16 0 0 0 0 SW 0.0 0.0 0:00 khubd 185 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald 186 root 15 0 0 0 0 SW 0.0 0.0 0:00 kjournald 576 root 15 0 712 632 612 S 0.0 0.2 0:00 dhcpcd

The display is divided into two sections. The top section contains information related to overall system status — uptime, load average, process counts, CPU status, and utilization statistics for both memory and swap space. The lower section displays process-level statistics, the exact nature of which can be controlled while top is running.

	Warning
	Although top looks like a simple display-only program, this is not the case. top uses single character commands to perform various operations; if you are logged in as root, it is possible to change the priority and even kill any process on your system. Therefore, until you have reviewed top's help screen (type [?] to display it), it is safest to only type [q] (which exits top).

2.1. The GNOME System Monitor — A Graphical top

If you are more comfortable with graphical user interfaces, the GNOME System Monitor may be more to your liking. Like top, the GNOME System Monitor displays information related to overall system status, process counts, memory and swap utilization, and process-level statistics.

However, the GNOME System Monitor goes a step further by also including graphical representations of CPU, memory, and swap utilization, along with a tabular disk space utilization listing. Here is an example of the GNOME System Monitor's Process Listing display:

Figure 2-1. The GNOME System Monitor Process Listing Display

Additional information can be displayed for a specific process by first clicking on the desired process and then clicking on the More Info button.

To view the CPU, memory, and disk usage statistics, click on the System Monitor tab.

3. vmstat

For a more concise view of system performance, try vmstat. Using this resource monitor, it is possible to get an overview of process, memory, swap, I/O, system, and CPU activity in one line of numbers:

procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 524684 155252 338068 0 0 1 6 111 114 10 3 87

The process-related fields are:

• r — The number of runnable processes waiting for access to the CPU

• b — The number of processes in an uninterruptible sleep state

• w — The number of processes swapped out, but runnable

The memory-related fields are:

• swpd — The amount of virtual memory used

• free — The amount of free memory

• buff — The amount of memory used for buffers

• cache — The amount of memory used as page cache

The swap-related fields are:

• si — The amount of memory swapped in from disk

• so — The amount of memory swapped out to disk

The I/O-related fields are:

• bi — Blocks sent to a block device

• bo— Blocks received from a block device

The system-related fields are:

• in — The number of interrupts per second

• cs — The number of context switches per second

The CPU-related fields are:

• us — The percentage of the time the CPU ran user-level code

• sy — The percentage of the time the CPU ran system-level code

• id — The percentage of the time the CPU was idle

When vmstat is run without any options, only one line is displayed. This line contains averages, calculated from the time the system was last booted.

However, most system administrators do not rely on the data in this line, as the time over which it was collected varies. Instead, most administrators take advantage of vmstat's ability to repetitively display resource utilization data at set intervals. For example, the command vmstat 1 displays one new line of utilization data every second, while the command vmstat 1 10 displays one new line per second, but only for the next ten seconds.

In the hands of an experienced administrator, vmstat can be used to quickly determine resource utilization and performance issues. But to gain more insight into those issues, a different kind of tool is required — a tool capable of more in-depth data collection and analysis.

4. The Sysstat Suite of Resource Monitoring Tools

While the previous tools may be helpful for gaining more insight into system performance over very short time frames, they are of little use beyond providing a snapshot of system resource utilization. In addition, there are aspects of system performance that cannot be easily monitored using such simplistic tools.

Therefore, a more sophisticated tool is necessary. Sysstat is such a tool.

Sysstat contains the following tools related to collecting I/O and CPU statistics:

iostat

Displays an overview of CPU utilization, along with I/O statistics for one or more disk drives.

mpstat

Displays more in-depth CPU statistics.

Sysstat also contains tools that collect system resource utilization data and create daily reports based on that data. These tools are:

sadc

Known as the system activity data collector, sadc collects system resource utilization information and writes it to a file.

sar

Producing reports from the files created by sadc, sar reports can be generated interactively or written to a file for more intensive analysis.

The following sections explore each of these tools in more detail.

4.1. The iostat command

The iostat command at its most basic provides an overview of CPU and disk I/O statistics:

Linux 2.4.18-18.8.0 (pigdog.example.com) 12/11/2002 avg-cpu: %user %nice %sys %idle 6.11 2.56 2.15 89.18 Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn dev3-0 1.68 15.69 22.42 31175836 44543290

Below the first line (which displays the system's kernel version and hostname, along with the current date), iostat displays an overview of the system's average CPU utilization since the last reboot. The CPU utilization report includes the following percentages:

• Percentage of time spent in user mode (running applications, etc.)

• Percentage of time spent in user mode (for processes that have altered their scheduling priority using nice(2))

• Percentage of time spent in kernel mode

• Percentage of time spent idle

Below the CPU utilization report is the device utilization report. This report contains one line for each active disk device on the system and includes the following information:

• The device specification, displayed as dev<major-number>-sequence-number, where <major-number> is the device's major number[1], and <sequence-number> is a sequence number starting at zero.

• The number of transfers (or I/O operations) per second.

• The number of 512-byte blocks read per second.

• The number of 512-byte blocks written per second.

• The total number of 512-byte blocks read.

• The total number of 512-byte block written.

This is just a sample of the information that can be obtained using iostat. For more information, see the iostat(1) man page.

4.2. The mpstat command

The mpstat command at first appears no different from the CPU utilization report produced by iostat:

Linux 2.4.18-14smp (pigdog.example.com) 12/11/2002 07:09:26 PM CPU %user %nice %system %idle intr/s 07:09:26 PM all 6.40 5.84 3.29 84.47 542.47

With the exception of an additional column showing the interrupts per second being handled by the CPU, there is no real difference. However, the situation changes if mpstat's -P ALL option is used:

Linux 2.4.18-14smp (pigdog.example.com) 12/11/2002 07:13:03 PM CPU %user %nice %system %idle intr/s 07:13:03 PM all 6.40 5.84 3.29 84.47 542.47 07:13:03 PM 0 6.36 5.80 3.29 84.54 542.47 07:13:03 PM 1 6.43 5.87 3.29 84.40 542.47

On multiprocessor systems, mpstat allows the utilization for each CPU to be viewed individually, making it possible to determine how effectively each CPU is being used.

4.3. The sadc command

As stated earlier, the sadc command collects system utilization data and writes it to a file for later analysis. By default, the data is written to files in the /var/log/sa/ directory. The files are named sa<dd>, where <dd> is the current day's two-digit date.

sadc is normally run by the sa1 script. This script is periodically invoked by cron via the file sysstat, which is located in /etc/crond.d. The sa1 script invokes sadc for a single one-second measuring interval. By default, cron runs sa1 every 10 minutes, adding the data collected during each interval to the current /var/log/sa/sa<dd> file.

4.4. The sar command

The sar command produces system utilization reports based on the data collected by sadc. As configured in Red Hat Linux, sar is automatically run to process the files automatically collected by sadc. The report files are written to /var/log/sa/ and are named sar<dd>, where <dd> is the two-digit representations of the previous day's two-digit date.

sar is normally run by the sa2 script. This script is periodically invoked by cron via the file sysstat, which is located in /etc/crond.d. By default, cron runs sa2 once a day at 23:53, allowing it to produce a report for the entire day's data.

4.4.1. Reading sar Reports

The format of a sar report produced by the default Red Hat Linux configuration consists of multiple sections, with each section containing a specific type of data, ordered by the time of day that the data was collected. Since sadc is configured to perform a one-second measurement interval every ten minutes, the default sar reports contain data in ten-minute increments, from 00:00 to 23:50[2].

Each section of the report starts with a heading that illustrates the data contained in the section. The heading is repeated at regular intervals throughout the section, making it easier to interpret the data while paging through the report. Each section ends with a line containing the average of the data reported in that section.

Here is a sample section sar report, with the data from 00:30 through 23:40 removed to save space:

00:00:01 CPU %user %nice %system %idle 00:10:00 all 6.39 1.96 0.66 90.98 00:20:01 all 1.61 3.16 1.09 94.14 … 23:50:01 all 44.07 0.02 0.77 55.14 Average: all 5.80 4.99 2.87 86.34

In this section, CPU utilization information is displayed. This is very similar to the data displayed by iostat.

Other sections may have more than one line's worth of data per time, as shown by this section generated from CPU utilization data collected on a dual-processor system:

00:00:01 CPU %user %nice %system %idle 00:10:00 0 4.19 1.75 0.70 93.37 00:10:00 1 8.59 2.18 0.63 88.60 00:20:01 0 1.87 3.21 1.14 93.78 00:20:01 1 1.35 3.12 1.04 94.49 … 23:50:01 0 42.84 0.03 0.80 56.33 23:50:01 1 45.29 0.01 0.74 53.95 Average: 0 6.00 5.01 2.74 86.25 Average: 1 5.61 4.97 2.99 86.43

There are a total of seventeen different sections present in reports generated by the default Red Hat Linux sar configuration; many are discussing in upcoming chapters. For more information about the data contained in each section, see the sar(1) man page.

Notes

brw-rw----    1 root     disk       3,   0 Aug 30 19:31 /dev/hda
                  

• Natural Threats: Floods, earthquakes, tornadoes, landslides, avalanches, electrical storms, and other such events.
  
• Human Threats Events that are either enabled by or caused by human beings, such as unintentional acts (inadvertent data entry) or deliberate actions (network based attacks, malicious software upload, unauthorized access to confidential information).
  
• Environmental Threats: Long-term power failure, pollution, chemicals, liquid leakage.
  

• Threat: The potential for a threat-source to exercise (accidentally trigger or intentionally exploit) a specific vulnerability.
  
• Threat-source: Either (1) intent and method targeted at the intentional exploitation of a vulnerability or (2) a situation and method that may accidentally trigger a vulnerability.
  
• Threat Analysis: The examination of threat-sources against system vulnerabilities to determine the threats for a particular system in a particular operational environment.
  
• Vulnerability: A flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system's security policy.
  

• Risk: The combination of the probability of an event and its consequence. (ISO Guide 73)
  
• Risk management: The process of determining an acceptable level of risk, assessing the current level of risk, taking steps to reduce risk to the acceptable level, and maintaining that level of risk.
  
• Threat: A potential cause of an unwanted impact to a system or organization. (ISO 13335-1)
  
• Vulnerability: Any weakness, administrative process, or act or physical exposure that makes an information asset susceptible to exploit by a threat.
  

1. An expression of an intention to inflict pain, injury, evil, or punishment.
   
2. An indication of impending danger or harm.
   
3. One that is regarded as a possible danger; a menace.
   

1. Susceptible to physical or emotional injury.
   
2. Susceptible to attack: “We are vulnerable both by water and land, without either fleet or army” (Alexander Hamilton).
   
3. Open to censure or criticism; assailable.
   
4. Liable to succumb, as to persuasion or temptation.
   

1. The possibility of suffering harm or loss; danger.
   

Android’s threat to the iPhone

The first phone to use Google’s Android operating system will be available on October 22.

If Google plays its cards right, its unveiling of the first Android-powered phone on Tuesday will prove to be more than a distraction from iPhone-mania – it will be the moment the search giant capitalizes on Apple’s control issues.

First, the lowdown on Google’s (GOOG) Android mobile operating system. The first phone to use it, the $179 G1 from HTC, will be available around October 22 and will use T-Mobile’s wireless network. Data plans will start at $25 per month, and cost $35 per month for unlimited access. (Voice plan is separate.) It comes with nifty programs like Gmail, YouTube, contacts, calendar, IM, and Google Maps with Street View, which shows pictures of locations on a map.

Think of Android as an attempt to do for phones what Windows does for the PC, or OS X does for the Mac. But unlike Microsoft (MSFT) and Apple (AAPL), Google isn’t looking to make money off of phone software or hardware; instead, it’s giving Android away for free to any phonemaker and wireless carrier who will bake it into a handset. Why? If people use their phones to get online, the more they’ll do Google searches, click Google ads, and in the process, make Google money.

That clears up why Google needs Android. But do the rest of us? After all, there’s no shortage of smartphones out there already; if you don’t want RIM’s (RIMM) BlackBerry, you can get Apple’s iPhone, Nokia’s (NOK) N95; or a Windows Mobile phone from Palm (PALM), Motorola (MOT) or Samsung.

Google’s answer for why we need another: to save us from folks like Apple and Microsoft. “No one party will control this platform,” Rich Miner, Google’s group manager for mobile, said at the Mobilize conference in Silicon Valley last week. In theory, such a hands-off approach makes it easier for bright entrepreneurs to set up shop and make money without answering to one powerful company. Jason Bremner, senior director of Qualcomm’s (QCOM) cellular products group, vouches for that. “It helps innovation,” he said. “And it drives costs down.”

It’s a timely argument, because Apple has been a bit heavy-handed with its popular gadget lately. We already knew about the iPhone’s basic restrictions: AT&T (T) is the exclusive U.S. carrier, Apple is the only company allowed to make iPhones, and Apple itself decides which programs you can legitimately download and install through its App Store. But in recent weeks, Apple’s inner control freak has grown especially active.

It began in August, when Apple’s App Store police rejected programs including “I Am Rich,” which was little more than a very expensive picture for $999; NetShare, which turned the iPhone into a modem; and Murderdrome, a violent digital comic book.

But a real backlash began a few days ago, when Apple nixed Podcaster, a program that lets people directly download shows without going through Apple’s iTunes. The app didn’t seem to violate any of Apple’s published rules – so why was it tossed?

Creator Alex Sokirynsky, a 27-year-old web developer who writes software in his spare time, blogged his rejection letter: “Since Podcaster assists in the distribution of podcasts,” Apple wrote, “it duplicates the functionality of the Podcast section of iTunes.” The implicit message: Don’t try to improve on our way of doing things. The move even angered some Apple fans. Longtime Mac developer Paul Kafasis blogged that Apple had “gone too far;” online publishing pioneer Dave Winer called it a dealbreaker for developers. (Apple did not respond to a request for comment.)

Actually, Apple has always had control issues. When CEO Steve Jobs returned to save the company a decade ago, one of his first acts was to cancel agreements that allowed other companies to make Macs. Executives almost decided not to release a Windows-compatible version of the iPod partly because it would mean dealing with Brand X operating system.

And of course there are those strained relationships with Hollywood studios, because Apple insists on dictating the pricing for most songs and videos in the iTunes store. To be fair, Apple’s meticulous streak has its benefits, of course – if the company wasn’t so particular, do you think it could build iTunes into the top-selling U.S. music retailer, invent the iPod, and win all those design awards? Yeah, probably not.

But in this case, there’s reason to believe Apple’s hands-on approach could eventually lose out to Google’s more open model. Assuming Google can build and maintain a reliable operating system on its first try (and that’s a big assumption), it’s reasonable to expect major players like Motorola, Samsung and Sony Ericsson to build phones around the free software. And since the wireless carriers are hungry for Internet-friendly phones to compete with AT&T’s lock on the iPhone, Android phones could prove popular. It’s conceivable that in a year, Google-backed phones could be available from all four major U.S. carriers next to Apple’s one, with a wide-open distribution model next to Apple’s curated App Store.

Still, even in Google’s dream scenario, Android won’t gain ground overnight. The first model out the gate is from HTC (hardly a household name), running on T-Mobile’s second-tier network. Adding to the uncertainty around the launch, a number of software developers are taking a wait-and-see stance toward Google’s debut effort.

Andrew Stein, director of mobile business development for Popcap Games, said that while the maker of titles like Bejeweled and Zuma jumped at the chance to be first on the iPod and iPhone, it’s not so excited about Android. “Apple’s been doing operating systems for a very long time, but this is really Google’s first,” Stein said. “I don’t think the first couple of devices are going to be multimillion-unit phones.”

But Google’s got at least one developer eager to take a chance. Sokirynsky, whose rejected iPhone app became a cause for bloggers, said he’s now turned his attention to building a version of Podcaster for Android. “I only developed Podcaster for the iPhone because that was the phone I used and the app I wanted,” he said. “I plan to keep developing for other platforms that are more open.”