“Transparent proxying” means that clients on the LAN can’t bypass the proxy–all requests made through port 80 will be redirected to port 8080, which is the port DansGuardian listens on, which in turn references port 3128, which is the port Squid listens on.

In researching how to do this, I encountered constant warnings that I’d have to compile transparent proxying into the kernel, but apparently Red Hat 7.0 (at least if you do a pre-configured server installation as I did) already has it enabled, so all that was necessary were the Squid package (which was already installed) and DansGuardian (which can be downloaded as a Red Hat RPM).

SQUID

The Squid config file (/etc/squid/squid.conf) is among the most comprehensive I’ve seen, with comments that provide a lot of good general documentation for Squid itself. After reading up a bit on Squid optimization, I decided to leave the vast majority of the variables at their default settings.

Essentially the only changes I ended up making had to do with 1) making sure the clients on my LAN access to the proxy server after I setup a firewall rule to direct all HTTP requests through the proxy, and 2) enabling transparent proxying. To accomplish the access control part, the following lines had to be added to the access controls and http access sections of the file:

acl lan 192.168.1.0/24
http_access lan

A word about CIDR (Classless Internet Domain Routing) notation–the “24″ in the above line means that the first 24 bits (i.e., the first 3 numbers) are used to identify the network, while the remaining 8 bits (i.e., the last number) are used to identify hosts, which suits my private “Class C” network which allows hosts a range of 254 IPs from 192.168.1.1 to 192.168.1.254 (0 in the last position identifies the network, and 255 is the broadcast address, so they’re not available for hosts).

To achieve transparent proxying, the “httpd accelerator” needed to be enabled in Squid, with the following changes to squid.conf:

httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on

I’m not entirely clear why an http daemon (however “virtual”) is necessary to accomplish transparent proxying. At any rate, with these settings, I could no longer serve Web pages from Apache on the default HTTP port 80, so I changed that port in /etc/httpd/conf/httpd.conf to 81. While I’m not really using the Web server for anything, DansGuardian uses it to run a CGI script that displays dynamic “access denied” messages when a user attempts access to a blocked resource.

The following FAQ on “interception caching”–which I assume is the same as transparent proxying–was helpful, though I didn’t end up using the recommended ipchains settings for Linux 2.2: http://www.squid-cache.org/Doc/FAQ/FAQ-17.html

Finally, Squid was not set up to start on system startup in my runlevels to so I:

/sbin/chkconfig squid on

and then started it manually:

/etc/rc.d/init.d/squid start

DANSGUARDIAN

Installing an RPM of DansGuardian on a Red Hat system, DansGuardian works more or less right out of the box. The main problem is that it works a little too well–i.e., virtually all non-html or image file extensions, mime types, etc. are blocked. The program does not come with a list of blacklisted sites, but you can download one from the site, which I did. (While DansGuardian is GPL’d free software, you in fact have to pay for blacklist subscriptions–Dan provides a free download of your first file, though.)

For my needs, the necessary changes to /etc/dansguardian/dansguardian.conf were:

accessdeniedaddress = 'http://192.168.1.1:81/cgi-bin/dansguardian.pl'
weightedphrasemode = 0

The first change points DG to the CGI script that will . You need Apache running for this–you also have the option of using a simple non-dynamic HTML page with a generic “access denied” message if you don’t want to run Apache. As for the second change, using the “weighted phrases” feature of DG is simply too restrictive for my needs. Besides, I have a hunch that it may be the most resource-intensive feature of DG, and I have doubts about the ability of my 100MHz server to handle it without bringing Web surfing to a crawl.

To reduce the amount of restricted content (I’m only interested in filtering out hard-core porn sites), I edited the following files in /etc/dansguardian and commented out most of the settings to make them far less restrictive: bannedextensionlist, bannedmimetypelist, bannedregexpurllist (this file scans the URL for dirty words–I left it mostly intact but removed the word “sex,” because it would seem to block access to a lot of non-pornographic content (the “Sex” section on Salon.com, for example). “bannedsitelist” and “bannedurllist” contain include statements to refer to the blacklist files. After setting up the blacklist, I simply commented out all of the includes except those that point to the “porn” and “adult” subdirectories. Finally, in the “pics” file, I simply disabled this kind of filtering with the “enablePICS” variable.

Finally, as per the DG online documentation, I added a log rotation script as a weekly cron job (every Sunday at midnight): crontab -e, then add the line: 59 23 * * sun /etc/dansguardian/logrotation

To make sure that the firewall would redirect HTTP requests to be filtered by DansGuardian, I executed the following line, and added it to /etc/rc.local to be executed upon subsequent system startups:

/sbin/ipchains -A input -p tcp -d 0/0 80 -j REDIRECT 8080

With the RPM install of DG, it’s added automatically to the runlevels, so chkconfig is not necessary. Starting DG for the first time, though, I typed: /etc/rc.d/init.d/dansguardian start It took a while on my old server to process the huge blacklist file, but on subsequent startups, it uses a “processed” version of the blacklist, and starts up more quickly. Amazingly, there’s been no noticeable lag in Web browsing–at least on a LAN where only two users ever use it at the same time.

Two packages are required to fulfill the necessary functions: “bind” and “caching-nameserver.”

While the concept of DNS seems simple–mapping IP address to human-readable names organized in a hierarchical structure–evidently it’s an extremely complicated subject. The O’Reilly volume DNS and BIND weighs in at 622 pages, more than the same publisher’s book TCP/IP Network Administration which covers DNS as well as most other Internet protocols.

Rather than tackle such a huge subject out of simple curiosity, I decided to just have a crack at editing the appropriate configuration files and starting the service. With the help of both documents mentioned above, I seem to have DNS up and running without any trouble.

Once again, I relied on the following two documents for help:

1, http://www.jandg-cooper.com/home_network/index.html
2. http://www.tldp.org/HOWTO/mini/Home-Network-mini-HOWTO.html

I started with document #1, since #2 only provided instructions on using DNS to cache domain names, rather than provide DNS service to your LAN. So from document #1, I modeled my “/etc/named.conf” is modeled on document #1. I left out the “key,” “controls,” and “acl” sections, changed the “forwarders” lines to my own ISP’s DNS servers, and added the following line underneath it:

allow-query { 192.168.1/24; 127.0.0.1/32; };

As for the rest of named.conf, I simply substituted my own network information where appropriate.

I changed “/var/named/named.local”, created “/var/named/named.dorn” and “/var/named/named.dorn-rev” and substituted “jandg-cooper.com” with “dorn.com” wherever appropriate. (Although I don’t own the domain “dorn.com,” I can use it internally since I’m currently not providing access to any Internet services outside my LAN.)

Finally, I changed /etc/sysconfig/network-scripts/ifcfg-eth0 in accordance with document #1:

RESOLV_MODS=no
PEERDNS=no
LOGDNS=yes

As for what I took from document #2, my “/etc/dhcpd.conf” file included the line “option ip-forwarding off,” which I think had to be removed in order to use DNS locally when appropriate. Also, I commented out the “domain-name-servers” option which referred to my ISPs domain name servers, and replaced it with the address for my own DNS server: “option domain-name-servers 192.168.1.1;”

Finally, following the advice of #2, I edited the line in “/etc/rc.d/init.d/named” which invokes the named daemon so that it would be run by “nobody” rather than root: “daemon named -u nobody -g nobody”. “chkconfig named on” inserted named to start automatically on boot in the appropriate runlevel, and after a reboot (or an “/etc/rc.d/init.d/named start”), DNS was up and running. I can now “telnet vox” instead of “telnet 192.168.1.1″, etc.

Still it has long struck me as odd that my dad, for example, has processing power on his desktop that’s several orders of magnitude greater than what was needed to say, land our first man on the moon, when all he needs to do is access his mail and surf eBay looking for bargains to add to his vast collection of cigarette lighters.

So relatively cheap hardware is great. But it begs the question–what can you do with really cheap hardware? Particularly if you’re in charge of an office network, it has probably occurred to you that most of your computers really only need to fulfill the following functions: Word processing, spreadsheets, email, and Web browsing. This has been the case for several years already–innovations that make other functions necessary for a majority of users have simply not been forthcoming. With a diskless thin-client software project winning this year’s “Best Open Source Project” award at LinuxWorld San Francisco, it seems like an appropriate time to reconsider the benefits thin clients offer.

This case study that describes the genesis of the Linux Terminal Server Project ought to serve as a good starting point for anyone wondering how they might take advantage of the cost advantages Linux offers. Just a couple of years ago, it was probably the case that Linux on the desktop for user unacquainted with the OS was not “ready for prime time.” With new versions of Ximian’s Evolution groupware suite and the OpenOffice suite of office applications, for example, this is manifestly no longer the case.

• IP forwarding (routing)
• IP masquerading (for permitting all machines on the LAN to share the cable modem’s connection to the internet by letting them use the same IP address)
• DHCP (for assigning IPs to the machines on the LAN when they come onto the network)
• Samba (for file and printer sharing compatibility with whatever Windows machines there may be on the network)

These documents were indispensable:

#1: http://www.jandg-cooper.com/home_network/index.html
Describes in detail setting up a home network with a Linux server providing a broad range of internet services–all of ones listed above, plus mail, DNS, etc. It focusses on Linux kernel 2.4.x systems. (Red Hat 7.3+ for Red Hat users.)

#2: http://www.tldp.org/HOWTO/mini/Home-Network-mini-HOWTO.html
A shorter Linux Documentation Project document that describes setting up a basic home network on Red Hat 6, therefore focussing on Linux kernel 2.2.x systems. I decided to use Red Hat 7.0, which has a 2.2 kernel, so this document ended up being more useful for me. However, the other document explains more clearly and in greater detail what exactly is happening with each step you take.

HARDWARE NOTES

Evidentally it’s possible to pull all this off with a single NIC in your server, but the recommended configuration is to have 2 NICs–one for the cable modem and the other for the hub. Additionally, to avoid trouble, it’s advisable that the NICs be identical, rather two different models.

• Server: 100 MHz Pentium, 64 MB RAM, 2 D-Link DFE-530TX+ NICs
• 4-port Ethernet hub
• Workstation 1: HP Omnibook 4150 Notebook, Pentium II 366 MHz, 128 MB RAM. Linux/Win2000.
• Workstation 2: Pentium III 550 MHz, 384 MB RAM. Linux/Win2000.
• Workstation 3: Celeron 1GHz, 128 MB RAM. WinXP

I had originally wanted to upgrade the server with some cheap parts–particularly the processor–but according the manual I found on the manufacturer Web site, the FIC PA-2000 motherboard can’t handle a processor faster than a 133MHz Pentium. The few network services I currently have running seem to run flawlessly with this cheap old box, but I’d like to try to add DNS service plus the Squid proxy server and DansGuardian. I’ll be amazed if Linux can pull that off on this box without noticeable performance degradation, and will update this document accordingly.

INTERNET CONNECTION AND BASIC NETWORK CONFIGURATION

The first order of business is to make sure the server can connect to the Internet through the cable modem. These days almost all ISPs assign IPs via DHCP, so with the server functioning as a simple DHCP client, this shouldn’t be a problem. (You should have installed the the DHCP client daemon package (dhcpcd) upon installing the OS–if not you’ll have to do it yourself.) Linux will identify the two network cards by the device names “eth0″ and “eth1″. In my setup, eth0 represents the card that connects to the cable modem. Upon installing RedHat 7.0, my cards were automatically detected, and I had the option of making eth0 configure itself upon boot through DHCP. On RedHat systems, this setup can be handled post-install through the “linuxconf” utility. At this point, you should be able to “ping www.google.com” from your server and transmit and receive packets without a problem.

This is a good point to take care of the fundamental network configuration:

As I mentioned, the “linuxconf” utility can handle a lot of this if you’re running RedHat. But you can also edit the the necessary configuration files manually, as follows:

If you’re familiar with *nix systems, you know that most configuration files reside somewhere within the “/etc” directory. You’ll need a file called “ifcfg-ethX” in

/etc/sysconfig/network-scripts/

for each of your NICs. A partial listing of my file in

/etc/sysconfig/network-scripts/ifcfg-eth0

looks like this:

DEVICE="eth0"
BOOTPROTO="dhcp"
ONBOOT="yes"
IPADDR=""
NETMASK=""

while

/etc/sysconfig/network-scripts/ifcfg-eth1

looks like this:

DEVICE="eth1"
BROADCAST=192.168.1.255
IPADDR="192.168.1.1"
NETMASK="255.255.255.0"
NETWORK=192.168.1.0
ONBOOT="yes"
BOOTPROTO="none"

In the first listing, we see that eth0–that is, the NIC that connects to the cable modem–activates on boot, and will receive its network configuration information via DHCP–in this case, through your cable modem ISP’s DHCP server.

eth1 is the device that connects the rest of your network to the server. IP addresses that begin with “192.168.1″ are reserved for internal networking, and so you’ll want your server to have such an address. In my case, I’ve assigned it the first IP in that range–192.168.1.1–to the “IPADDR” variable here. The “BROADCAST” variable identifies the address that will transmit packets to all the machines on your LAN. (I’m actually not sure when or if this ever takes place on my LAN.) A “NETMASK” of 255.255.255.0 simply means that all IPs that look like 192.168.1.x will be part of the LAN. All other IPs will have to be reached via the router.

“/etc/sysconfig/network” is a file that controls some general networking variables. You’ll want to make sure that it has the following lines:

NETWORKING=yes
FORWARD_IPV4="yes"

According to document #2, you may also need to edit “/etc/sysctl.conf” and make sure it has the following lines:

net.ipv4.ip_forward = 1
net.ipv4.ip_always_defrag = 1 

If you’re editing your files manually rather than using linuxconf, you’ll want to restart your network so that the new config values are activated:

/etc/rc.d/init.d/network restart

As far as the server itself goes, everything should be in working order at this point, although I should point out that I had a problem in which I could not have both eth0 and eth1 activated and access the Internet with the cable modem at the same time. I wish I knew what I did to make this problem go away, but at some point in my screwing around, it started working!

DHCP SERVER

Your server will also run a DHCP server daemon (the package dhcp) to assign IP addresses to the machines on your LAN when their own DHCP client software queries the server for an IP to connect to the network. (Document #2 includes a series of instructions that I didn’t really follow, and somehow still got DHCP running.) Take a look at “/etc/dhcpd.conf”

The most important line here is the “range” variable, which will determine the number of machines that can be on your network at any one time. Mine says:

range 192.168.1.10 192.168.1.60;

which means 51 computers (obviously way more than you’ll ever need for a home network) can be simultaneously logged onto the LAN. We know that 192.168.1.1 is the server’s address about 192.168.1.2 through 9? Well, if you’re running DNS on your server, you can assign permanent IP addresses with hostnames to the machines on your LAN so that anyone on the network can simply use that name instead of IP address to refer to that box. Include an entry that looks like this for each of machine on your LAN:

#   --- This Linux box: the server
    host linuxserver {
        hardware ethernet 00:32:19:2C:A7:4F;
        fixed-address 192.168.1.1;
    }

Machines that don’t have such an entry (e.g., a friend’s laptop) will simply be assigned an IP via DHCP and can use the network just as easily.

Note that the same effect could be achieved by maintaining the “/etc/hosts” file on each machine on your network, but it’s obviously much easier to maintain this information from a central location.

Note also that the NIC hardware IDs required by these entries can be retrieved through the command “ifconfig” on Linux or “winipcfg” on Windows.

Restart your DHCP server with:

/etc/rc.d/init.d/dhcpd start

(NB: At some point, I had to create a blank “dhcp.leases” when the DHCP daemon complained that it couldn’t find one. Oddly, I can no longer find where Linux puts that file despite trying to “find” it.)

SECURITY AND “IP MASQUERADING”

To do packet handling and filtering, the 2.2 Linux kernel uses a program called “ipchains,” while the 2.4 kernel offers an enhanced version of that program used “iptables.” ipchains and iptables can be used to provide a secure firewall for your network, and for network address translation (NAT) or “IP masquerading,” which permits all the machines on your network to make use of a single Internet connection–in my case, the cable modem.

Because I’m running Red Hat 7.0, and therefore the 2.2 kernel, I used ipchains, and for now, I’m using it only for the purpose of masquerading, while I provide basic security to my network with the “/etc/hosts.deny” and “/etc/hosts.allow” files, as described in document #1 mentioned above. hosts.deny contains a single line–”ALL: ALL”–which denies all connections from incoming hosts, while the lines “ALL: 127.0.0.1″ followed by “ALL: 192.168.1.” in hosts.allow, modifies that rule to allow connections from the server itself (whose “loopback address” is 127.0.0.1) and from all devices on the LAN. I imagine I’ll have to make some changes to this setup when I get around to trying to serve content from a Web server/Zope application server from inside my LAN.

As for using ipchains to handle masquerading, I’ve included the following directly from document #1:

Configuring simple masquerading is very very easy once your internal and external networking is operational. Edit the /etc/rc.d/rc.local file and add the following lines to the bottom:

# 1) Flush the rule tables.
/sbin/ipchains -F input
/sbin/ipchains -F forward
/sbin/ipchains -F output
# 2) Set the MASQ timings and allow packets in for DHCP configuration.
/sbin/ipchains -M -S 7200 10 60
/sbin/ipchains -A input -j ACCEPT -i eth0 -s 0/0 68 -d 0/0 67 -p udp
# 3) Deny all forwarding packets except those from local network.
#    Masquerage those.
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ
# 4) Load forwarding modules for special services.
/sbin/modprobe ip_masq_ftp
/sbin/modprobe ip_masq_raudio

Run the rc.local script with the command /etc/rc.d/rc.local and you are ready to go! Sit down at one of your other computers and try some web surfing.

SAMBA

Samba is the only network service that I’m running that is not necessary for Internet connection sharing on your LAN. It’s necessary, though, if you want to share files and print services between Windows and Linux machines. I actually haven’t setup a printer through it yet, though.

You’ll need the following packages: samba-common, samba, and samba-client. Even if you installed these when you installed your OS, the two necessary daemons may not be set up to start on boot. Check to see if they’re running with: “ps -Al | grep mbd”. If you see smbd and nmbd running as processes, you’re all set. If not, start them with this command:

/etc/init.d/smb start

If your server’s LAN IP address is 192.168.1.1 You should be able to go to: “http://192.168.1.1:901/” to use the “SWAT” browser-based Samba configuration tool. If you have problems, you may need to add the following line to your /etc/xinetd.conf file as suggested by swat’s man page:

/usr/local/samba/bin/swat swat

Additionally, your “/etc/xinetd.d/swat” file may have Swat disabled by default. Make sure you have the line “disable = no” in this file.

This steps seemed to clear up any problems for me.

In Swat, under the “Globals” section, the following variables are the important ones:

• workgroup: Your Windows workgroup name
• netbios name: The name you want your server to show up as in Windows networking
• interfaces: should be eth0 or whichever interface services your LAN
• security: best option is USER — access will be controlled through username and password
• encrypt passwords: must be “Yes” to function with Windows users
• hosts allow: Value should be “192.168.1. 127.” to provide access only to users of your LAN

The rest of the variables should be OK with their default values.

You can create network shares pretty intuitively through the “Shares” section. A “homes” share is a special Samba share that provides users with accounts on the server access to their “home” directory.

Swat manipulates the “/etc/samba/smb.cnf” file, which, of course, can be edited manually.

USEFUL COMMANDS:

ifconfig

View network interface information (if invoked with no arguments).

/etc/rc.d/init.d/network restart
/etc/init.d/xinetd restart

Restart networking services.

/sbin/ifup eth0
/sbin/ifdown eth0

Start and stop a network interface, respectively. Sometimes this is necessary when network connectivity has been unexpectedly interrupted.

chkconfig dhcpd on

Adds dhcp startup script to the runlevel directories under /etc/rc.d so that DHCP starts on boot–obviously can be used with other services that you want started on boot.

chkconfig --list | grep SERVICE_NAME

See which if any run levels the service is set to start in.

tail -f /var/log/messages

Watch the messages on the server as the machines on your LAN connect to it via DHCP.

The other challenge involves our unwillingness to engage in projects that involve software patents. I’ve just reviewed some of the documents on the website of the League for Programming Freedom, and I’ve never been more convinced of the failure of software patents to achieve the goals for which patents were originally devised: encouraging innovation and fueling progress. In fact their principal effect currently seems to stifle invention with major patent holders intimidating developers who may have independently arrived at a given solution to a programming problem with the threat of litigation.

As Larry Lessig points out in an article written four years ago for the defunct Industry Standard, “On average it takes $1.2 million to challenge the validity of a patent, which means it is often cheaper simply to pay the royalties than to establish that the patent isn’t deserved.” Pursuing frivolous patents becomes a strategy for coercing potential competitors to licence your “innovation” rather than entangling themselves in expensive litigation.

If you’ve read some of my previous entries on this site, you will have noticed that I’m generally skeptical of many intellectual property claims. I am however, willing to concede that in a broad range of cases patents have helped achieve these goals. But I’m with the LPF in their efforts to abolish software patents. To summarize some of the main points in the League’s introduction to the issue.

To qualify for a patent, an invention must be judged not to be “obvious.” With the emergence of software patents subsequent to a 1981 Supreme Court decision which broadened the scope of what was patentable, programmers have discovered that computing techniques that were regarded as obvious by the programming community for many years have been patented, and that it is suddenly illegal to continue to incorporate these techniques. Before that case, it would have never occurred to a programmer to attempt to patent these techniques or algorithms. Part of the problem lies in the fact that examiners hired by the U.S. Patent Office are underpaid and frequently unqualified to judge what exceeds the this criteria of obviousness.

The Office continues to apply principles that are irrelevant to the field of software development. Because of the “tractable” nature of computer programming, hundreds of problems can be solved with dozens of “inventions” by a single programmer in a single day. The incentive patents provide is simply inapplicable here and, as I’ve mentioned, software patents have the opposite of the intended effect of encouraging innovation.

It may be useful to note that denying the legitimacy of software patents does not deny a software developer’s right to copyright and sell a program–it simply denies him the right to patent the programming methods used to create it. This issue is thus completely separate from the open-source vs. proprietary software debate.

For all the anomalous aspects of how my experience of Argentina began, it seems to me that this crisis threw into relief certain perennial characteristics of Argentine society. For example, it is said that Buenos Aires has four times the number of psychoanalysts per capita than that supposed capitol of neurosis, New York. While the number of people who can afford therapeutic treatment here is dwindling, one imagines that the stress caused by trying to make ends meet in the present context ensures that interest remains high. Tango itself–certainly the most globally recognizable of all Argentina’s cultural facets–is said to be an expression of Argentine melancholy. An important source of this melancholy is the sense of exile from the Old World that Argentines–the vast majority of them descendants of European immigrants–experienced upon their arrival to this distant austral outpost.

Argentina is still a society whose gaze is forever fixed northward. For some reason–perhaps for their unwillingness to identify with the indigenous populations that inhabit neighboring countries–Argentines have scorned the generous patrimony represented by the country’s richly varied geography. Two-thirds of the citizens of this sparsely populated republic–the eighth largest country in the world–live in the province of Buenos Aires. To the porteños–the inhabitants of the seaside capital–it’s as if moving to the interior would mean giving up hope on the possibility of boarding a ship for a brighter future. Now, a huge number of Argentines–particularly young, educated ones–really are leaving. In my experience in the university city of Córdoba, I met very few Argentines who weren’t actively searching for opportunities to emigrate (at least temporarily), and a fair number who succeeded in finding them, both in Europe and the United States, in spite of increasingly insurmountable visa restrictions.

None of this, of course, accounts for my love of this country. Whatever may be the character flaws engendered by the collective malaise I’ve suggested above, I could not imagine experiencing such astonishing genersosity and good will from any other people: not the Chileans, who are now achieving the same modernization that Argentina has long aspired to, not the famously sanguine and good-natured Brazilians, and certainly not the more indigenous Bolivians and Paraguayans, with their intrinsic (and probably justified) mistrust of outsiders. In light of this experience, I would feel sheepish about offering such a negative evaluation of the Argentine character if I didn’t have confidence that most thoughtful Argentines (and the proportion of Argentines who can be described in such a way is far larger than in my own country) would agree with it.

In any event, I didn’t achieve my goal of Spanish fluency. In November, I took a test at the University of Buenos Aires, where I was certified only as an “intermediate” Spanish speaker. To continue to make strides toward my goal of fluency, I have decided to spend at least the first half of 2003 in Mexico.

In some readily apparent aspects, these two Latin American countries could not be more different. Argentine national pride may seem formidable, but its negative character–an attitude that says “we Argentines are all in this ordeal together, so we may as well pull together”–seems to preclude its being a genuine expression of anything like patriotism. To current generations at least, definitive cultural expressions like tango seem to be promoted only for the benefit of tourists. And it’s difficult to attach any particular cultural significance to the otherwise pleasant tradition of the afternoon mate. For their identity, more than one Argentine has told me, “Argentines have always looked to Europe.” It would be difficult to imagine demonstrations of flag-waving enthusiasm such as those found in Puerto Rican, Cuban, and Mexican communities in the U.S. if Argentines were to arrive to American shores in such large numbers.

Mexicans of mixed descent–mestizos, who form the vast majority of Mexico’s population–are oftentimes no less eager to deny the indigneous portion of their heritage than Argentines are to deny that they share common cause with their largely indigenous South American neighbors. Still, perhaps because most Mexicans really do have indigenous blood coarsing through their veins, their relationship to the indigenous reality of Latin America is more ambiguous. I have in my pocket a ten-peso coin (worth a little less than one U.S. dollar). On what I suppose would be considered the “heads” side is a beautiful Aztec-inspired design while on the “tails” side I see the classic eagle-seizing-snake insignia familiar from the Mexican flag, a symbol that evokes Mexico’s status as a modern democratic republic. It is unlikely that even the small number of “pure” whites in Mexico to whom economic advantage disproportionately redounds (to say the least) would object to such a display of pride in their country’s mixed ethnic composition.

Perhaps, too, the relative illustriousness of Mexican history has something to do with their firm attachment to their territory, as opposed to the Argentines’ insistence on feeling themselves exiles. Upon entering the Palacio Municipal in front of Guadalajara’s lovely Plaza de Armas, the tourist is confronted with a literally breathtaking mural–painted by a famous muralist named José Clemente Orozco–which captures the essence of the contribution of Miguel Hidalgo, a priest who lead epically bloody campaigns during Mexico’s battle for independence, to the country’s formation. The Orozco mural in itself inspires me to learn more about Mexican history in a way that never happened in Argentina. Knowing that the country would be dramatically reshaped by its famous revolution in the early twentieth century is further incentive.

In spite of the economic reality that sends so many Mexicans north of the border, Mexico strikes me as a country far more secure in its own identity and proud of its own history and traditions than Argentina. But I’ve been here for just five days. Whether, after I spend more time here, I’ll feel justified in passing judgment on the essence of a nation of tens of millions–as I suppose I have with Argentina–remains to be seen.

Shiva’s rhetoric tends toward incendiary anti-capitalist boilerplate, and her arguments lose some of their force when she introduces unhelpful, screwball epithets like “species-centric” to castigate her enemies. But the force of her logic can’t be denied when she addresses the “Trips” (Trade Related Intellectual Property Rights) component of the 1994 World Trade Organization agreement that sought to apply rich-world intellectual property customs and laws across the board, forcing them on the developing world:

The poorer two thirds of humanity sustains itself through livelihoods based on biodiversity and indigenous knowledge. Today, this resource base of the poor is under threat as their plans and seeds are patented and claimed as inventions of Western scientists and Western corporations…. The TRIPs agreement … is not the result of democratic negotiations between the larger public and commercial interests or between industrialised countries and the Third World. It is the imposition of values and interests by Western transnational corporations on the diverse societies and cultures of the world.

Certainly talented minds in the developing world have come up with innovations that might provide lucrative patent material in the rich world. If it never occurred to them to try to protect their intellectual property because their profit instinct happens to be somewhat duller than ours, their ideas could easily end up being pirated by the rich world. Perhaps this happens as frequently in the world of scientific investigation and information technology as in the traditional realm of “indigenous knowledge” to which Shiva refers.

Shiva offers a chilling example of corporate overreaching to protect its intellectual property when she describes Monsanto’s practice of prohibiting farmers from saving seed, so that they have to buy every year from Monsanto. I’m unclear on exactly, how, but apparently patent law is employed to make this possible. It’s worth following up on with a bit more research.

Reading Shiva recalled a story I found in the Oct. 14, 2002 edition of the New York Times which deals with a report issued by the international Commission on Intellectual Property Rights, which recommends the loosening of the Trips restrictions:

The United States does stand to gain the most from stronger intellectual property protections, most of which must be in effect by 2005, under Trips. A World Bank study estimates that American companies would pocket an additional $19 billion a year in royalties, while developing nations like China, Mexico, Brazil and India — net importers of intellectual property — would pay more to the patent holders.

A plan that attempts to divert yet more money from already cash-strapped nations into the coffers of rich-world corporations obviously needs to be reconsidered. This NYT article is also useful for its clear summaries of the issues at stake:

Intellectual property rights are temporary grants of monopoly intended to give economic incentives for innovative activity. Why toil for months or years to develop a new drug or think up a clever software program, the thinking goes, unless there is the potential for a big payoff? The intended result is that consumers will pay somewhat higher prices for an individual drug or software program but will benefit from all the additional innovation in the economy.

That is the theory. Within the United States, there is criticism that the corporate frenzy to patent any technical advance, even business methods, undermines innovation by unnecessarily restricting the flow of ideas.

I also like the Times author’s pragmatic citation of economist Jeffrey Sachs:

The concern about Trips is that it is too much of a one-size-fits-all approach that works to the detriment of developing nations. “It would be fine if we lived in a world of all rich people,” said Jeffrey D. Sachs, a development economist at Columbia University. “The danger with Trips is that it will mostly hurt the developing countries’ access to ideas.”

and his equally pragmatic conclusion, even if I’m not in full agreement about the absolute worth of intellectual property rights:

In the end, the debate over intellectual property rights, like the controversy over I.M.F. policies in developing nations, may be more a dispute about speed than direction. Free trade, open financial markets and intellectual property rights are economic goals worth pursuing. But that is not to say that the preferred path is necessarily the straight line of ideological purity.