A MILLION MONKEYS

A Blog about AI, UI and HI

April 2006

by Jeremy Chan

Bdale Garbee, Open Source & Linux CTO at Hewlett-Packard, presented a keynote speech entitled "Reaping the Benefits of the Community Development Model" at the LinuxWorld and NetworkWorld Conference & Expo in Toronto.

Garbee opened with anecdotes about his participation in the open-source community over the last 25 years. This includes a small piece of utility code he developed as a young boy, for which he was later invited to confer with his "peers" in the field, who at the time didn't realize his mother probably wouldn't let him attend a conference on his own to discuss his ideas at that age. He described the experience as one that heralded the community development model as something he was sure he would always participate in. Of note, Bdale has been a contributor to the Debian GNU/Linux project since 1995, and has some open source code running in a few satellites currently orbiting around the earth.

Bdale attempted to address the concerns of those currently reluctant to embrace the community development model. He listed their main concerns as follows:

• Concerned about accountability for support.
  
• Making all the pieces work together.
  
• Defining on open source strategy.
  
• Developing a criteria for software selection.
  
• Obtaining technical skills.
  

He then delineated what the state of open source adoption in the world today, honing in on Linux and many open source products are now commodities that just about everyone is running in some capacity or another. Though Windows is eating into the proprietary Unix market share, Linux is grabbing share at a faster rate--Linux uptake is faster than any other operating system available today, and currently sits at healthy 20 percent of all enterprise deployments. Slightly behind the operating system curve, but still quite healthy are open-source middleware like Apache, JBoss, etc. Finally, adoption of general-purpose open-source applications (such as OpenOffice) is still in its infancy. He expects the adoption trend to continue at each of these levels.

His contention was that the community development model, used on many of today's open-source projects (the most obvious of which is Linux), has come of age. Linux and open source are currently an indispensable part of HP's IT strategy, as evidenced by the litany of open-source software running in their environment, including Linux, Bind, OpenLDAP, and Apache. Thousands of HPs employees send all of their email using open-source email smtp and IMAP servers. Garbee cited open-source projects as key cost-saving element since the merger with Compaq.

And cost is only one of the obvious advantages of open source and the community development model. Some of the others:

• Try before you buy.
  
• No vendor lock in.
  
• Community engagement.
  
• Great performance.
  
• Security through openness.
  
• Choice of support models.
  
• Ability to participate/influence directions.
  

The ability to choose your support model is one often overlooked advantage--if you choose to develop the skills to support your own open source deployments, information on how to do so is freely available. If you choose instead to pay for that support, there are a bevy of community members available to help. Just how much support you need and are willing to pay for is up to you.

One other important characteristics of open source is the ability to fork the source code if you're not happy with the direction of the codebase. Most open source communities know that forking is painful, and therefore go to great lengths to resolve differences and live within the established licensing models for that software. In this way, communities self-regulate. It is important, however, that the ability to fork exist. The community may stagnate and perhaps drift into a centrally controlled model in which innovation may stagnate. Forking can be the release valve for just such a situation, and can restore the excitement and community model to the process. One example in which this occurred for the general benefit of the community was with XWindows system, some form of which is now used in just about every environment that doesn't originate in Redmond.

Jeremy Chan is a Principal Consultant at the Jonah Group and a Technical Architect with over 10 years of experience in object-oriented software engineering.

Posted by Jeremy Chan at 12:24 AM  Permalink |

by Jeremy Chan

At a mid-day security session at the LinuxWorld and NetworkWorld Conference & Expo in Toronto, Tony Howlett gave an overview of some of the open-source tools available for performing a network security audit to a small group of attendees, covering Network discovery and Mapping, TCP/IP service enumeration, network vulnerability, firewall and router auditing, and wireless security.

Howlett, who is founder and CTO of NSS and author of "Open Source Security Tools" (Prentice-Hall, 2004), simulated some of the tools he uses and steps he would take in performing a network security audit. Using a laptop running VMWare, he simulated an entire network of windows and linux machines, each running various pieces of software (databases, web servers, etc).

With a few clicks, Howlett demonstrated the use of ping sweeps, snmp-based probes, web spidering, mail hacking, and google-hacking, Port scanning, fingerprinting, and banner grabbing to discover all kinds of information about the various hosts and the services they were running, including the names of user accounts, services, shares, routing tables, MAC addresses.... the list goes on.

An audit (or attack) might proceed as follows, using freely-available tools:

• Ping sweep to detect hosts running within the network.

• Port scan using nMap to discover a web server running on port 80.

• Invoke wikto to spider the site and do some google hacking to see if there any files with potentially sensitive information being served anywhere on the site

• Use Hydra to crack passwords of any user account names discovered using nMap or wikto.

• Banner Grab using Nessus to determine that this is IIS5.0. Look up potential known IIS 5.0 exploits.

• Use Metasploit to exploit an IIS 5.0 buffer overflow vulnerability. Install command shell and assume administrative control of the entire machine using nothing but a web browser.

• Use AirSnort to discover MAC addresses, crack WEP-based networks.

• Use RATs (Router Auditing Tools) to convert your specific firewall configuration file into a list of likely vulnerabilities/candidates for exploitation.

• Employ any of a host of free packet sniffers (TCPdump, windump, ngrep, Ettercap) to wait for someone to type in plain-text credentials

• Rule the world.

Network security newbies like myself were surprised to find, among other things, that:

• Some firewalls deny TCP SYN packets, but allow ACK, FIN, and RST packets through, allowing for the discovery of active TCP services that are specifically shielded by firewall rules.

• Forgetting to replace the default SNMP community string on all hosts in the network is tantamount to completely giving away the store, because of all the information that can be gathered from a host using this protocol.

• The number of known security vulnerabilities is endless. If you're not up-to-date on all of your software patches, all of the effort you'd spent to harden your network is effectively lost
  
  

Familiarizing yourself with open-source tools like the ones listed above is a good first step in understanding network security. Using them to perform a mini-audit of your own network will likely give you a scare or two, but will help you to take the necessary steps to secure your network.

Jeremy Chan is a Principal Consultant at the Jonah Group and a Technical Architect with over 10 years of experience in object-oriented software engineering.

Posted by Jeremy Chan at 06:52 PM  Permalink |

by Jeremy Chan

The sheer abundance of web application frameworks out there is the tipoff that HTTP is a woefully inadequate protocol for building complex web applications.

Everyone is trying to find just the right mix of interoperating components, languages, and standards to make this somewhat more bearable. Seaside, developed by Avi Bryant and the Seaside community, is yet another web application framework (YAWAF?). It is squarely aimed at all web application developers, but will likely have the biggest impact with the population of object-toting Smalltalkers who still seem to be lurking about (Note: The author is one). Avi Bryant presented Seaside to a room of about 50 attendees at the Smalltalk Solutions Conference, held in conjunction with the LinuxWorld and NetworkWorld Conference & Expo in Toronto.

According to the website, "Seaside provides a layered set of abstractions over HTTP and HTML that let you build highly interactive web applications quickly, reusably and maintainably". Seaside's prime directive is that the framework should isolate developers from the tedium of link and state management, and baked-in control flow. Seaside also shuns the hand-coding of HTML and indeed any templating whatsoever, opting instead for a component-based approach in which objects know how to render themselves into HTML. Every piece of UI in Seaside is modelled by a "WAComponent". Each component has a "renderContentOn:" method, which allows it to render itself onto the canvas. In the listings below, the object named "html" can be thought of the "canvas"-like component (or page), to which messages are sent to render html content. For example:

   "links"
      html anchor
         callback:[self doSomething]
             text: 'Link text'
    "checkbox"
        html checkbox
          submitOnClick;
          value:someValue;
          callback:[:v | self setSomeValue: v]
    "styled text"
         html span class: aListItem cssClass with: 'some text';

The idea is that each page is composed by a tree of tiny renderers, each of which manages a bit of state and has a bit of rendering capability. Even for someone unfamiliar with the Smalltalk language, the code above is not too difficult to understand. Of note in the "link" example, the HREF attribute need not be invented and specified by the developer -- it is handily generated by the framework. A Smalltalk block is simply supplied to tell the app what to do when the link is clicked.

A questions arises, though, as to whether it is a good idea to generate all page elements with component renderers, or whether document markup is sufficient or even better in some cases. For example--a dynamic list of items, rendered on the server in Seaside might look like this:

   "unordered list"
       html undorderList:
          [list items do:
             [:ea | html listItem: 
                [self renderItem:ea on:html]]]

Is this easier to write/understand than something like:

	<ul>
	< % for(List item: items) {%>
		<li><% self.renderItem() %>
	<%}%>
	</ul>?

that you might see in a traditional web app page template?

I suppose it depends on how your brain works. To an object junkie, the internal consistency of syntax of the Seaside version is pure nirvana. To a page designer, it might be a bit of an unnecessary mental contortion. (aside: the Seaside version might afford the ability to later replace the renderers for non-broswer clients).

One rule of thumb is that we should aim to model declarative things in a declarative languages (XML, HTML) and procedural things in procedural languages (Java, Smalltalk, etc). The popularity of XML has given rise to its (mis)use in various context to model branching, looping, exception handling, and other procedural logic. Similarly, since at least parts of an HTML page are inherently declarative, it might be best to directly type in the declarations. This isn't more apparent than in the contortion required to add a space on your html page. In a Seaside app, you have to send the "space" message to the "html" object. Sigh.

The rule of thumb isn't hard and fast, though. Avi contends that app developers own the structure of the data on the page (even if that structure happens to be rendered on the page using HTML markup) and should be responsible for managing it. The list of items in the example above may indeed not even be rendered as a list once styles are applied--it could, for example, represent a menu of items - the generation and management of which is outside of the bounds of a page designer. The designer would, however, style the list to look like a menu. This separation of concerns is very clear within a Seaside application. I'd like to see an extra layer of abstraction, however, that provides components with methods like "menu" rather than "unorderedList" for cases like this, though.

The other problem with decomposing a user interface into small consituent rendering components is that debugging tends to be more difficult in some ways--it may not be very clear about how one discovers what pieces of an interface relate to the pieces of code that generates that interface if one didn't write that code in the first place. In traditional web-apps, one can simply look at the template to understand the structure of the page. To address this, the Seaside team quickly showed a web-based meta-browser tool that allowed the user to more easily view the tree of component renderers. Links from stack trace error pages, for example, take you directly to the line of code in the running environment, and allow you to make modifications in the running image.

Of course, there are upsides to the Seaside approach: the developer is largely freed from managing control flow state, form submission logic, and all those pesky URLs that make it difficult to change (and regression test!) a web app once it has been built. Seaside seems like it would allow rapid prototyping and reconfiguration of user interfaces by reconfiguring component renderers in novel ways without having to worry about state and link management headaches.

A interesting component of Seaside is its AJAX integration. Seaside has a set of Smalltalk packages and classes that provide a way to both control/invoke components of the scriptaculous javascript library, and which allow the developer to easily hook up handlers to scriptaculous AJAX requests. No knowledge of Javascript or AJAX constructs is required. Responses to AJAX requests are snippets of html generated by various Seaside rendering components.

Seaside is a bit on the bleeding edge for Smalltalk webapp development. The presenters were clear on the fact that code in the framework is very young, but it seemed to have a small, interested following even at this stage. Alignment with Smalltalk definitely provides some big wins, not the least of which is that there is no visible compilation step when code is altered, and that you never have to "deploy" code or restart the server to test your changes in the development environment, which is simply a Smalltalk image. The presenters almost seemed to take this for granted, but the beauty of the Smalltalk environment does that to you after a short time spent in it.

Jeremy Chan is a Principal Consultant at the Jonah Group and a Technical Architect with over 10 years of experience in object-oriented software engineering.

Posted by Jeremy Chan at 06:04 PM  Permalink |

In this month's Fortune magazine, Bill Gates is quoted as saying that he's finally on the verge of achieving a "digital workstyle." What he means by that, apparently, is two things:

1. He has an army of automated filters, vectors and human helpers whose job is to insure that he receives no more than about 100 emails per day.
2. He has a trio of big, interlinked screens on his desk, on which he runs email inbox, email compose, and a browser, side by side.

It seems churlish to note (but I'll note it, anyway) that Mac people have been able to do this sort of thing since about 1987 (Symbolics Workstation people even earlier, plus Symbolics ran LISP behind the paint application). That aside, what's significant about the insight into Gates' workstyle is that he's reiterating what "smart application" pioneers like Symbolics and Apple learned decades ago: that an awful lot of application complexity (and the need for a forced sort of 'cleverness' in application design) can be managed, ignored, or eliminated if you have enough room to move apps and documents around, view them simultaneously, interact with some of them peripherally (i.e., Gates keeps his inbox open so he can glance at it occasionally, not obsess over it), and assign transitory meaning to others by their physical position on the (virtualized) desktop. Microsoft is doing lots of research on this: their 'Touchlight' prototype, two-handed tabletop displays, etc., and the Flip 3D UI on Vista that (in lieu of infinite virtual desktop in the horizontal dimension, lets you inflect the "depth" of windows in a virtual 3D space — it's quite astonishing to see, and I'm eager to learn if it really enhances usability). In other respects, Vista is doing a lot of subtle things with UI that reclaim desktop real estate, including implementation of transparent overlay controls.

This is pretty cool stuff.

Posted by John Jainschigg at 11:09 AM  Permalink |