By Stuart J. Johnston
May 7, 2008
Microsoft finally released Windows XP Service Pack 3 (SP3) to the general public, earlier this week, after a minor glitch or two the week before. It is an update that many XP users have been waiting impatiently for, for months.
Despite the fact that it's now available, however, the company still has a caveat for some users. If you have Internet Explorer 7 or 8 already installed, you may want to uninstall it before installing SP3. Then, if you wish, you can reinstall IE afterwards.
Why? As the 1990s buzz phrase goes: it's complicated.
At least that's the message in a posting made on Microsoft's (NASDAQ: MSFT) IE team blog this week.
It revolves around the fact that SP SP2 shipped with IE6. However, XP SP3 ships with a slightly different version of IE6. It also concerns the order in which the service pack and IE7 or IE8 are installed.
"If you choose to install XP SP3, Internet Explorer 7 will remain on your system after the install is complete. Your preferences will be retained. However, you will no longer be able to uninstall IE7," Jane Maliouta, deployment program manager for IE8, said in her blog post. The same goes for IE8, which is currently in beta test.
That's because the uninstallation process saves the wrong set of IE6 files on your hard disk, which would cause big problems later – so you're locked out of simply reverting to IE6.
The best way to handle the problem, Maliouta said, is to first, uninstall IE7, install XP SP3, and then reinstall IE7.
For the more adventurous who may have installed the beta test release of IE8, the warning counts double. Microsoft has set its download sites to not offer SP3 to users who already have IE8 installed – for good reason. If you install SP3 on top of IE8, as with IE7, you will no longer be able to uninstall the beta software.
"Since people are more likely to uninstall beta software, we strongly recommend uninstalling IE8 Beta 1 prior to upgrading to Windows XP SP3 to eliminate any deployment issues and install IE8 Beta 1 after XPSP3 is on your machine," Maliouta added.
Two analysts said they don't view the situation as a significant problem, but one said that it makes the update process more complex than it should be..
"I suppose there could be some applications that are affected, but I don't see it having any impact on most users," Michael Cherry, lead analyst for operating systems at researcher Directions on Microsoft, told InternetNews.com.
Roger Kay, president of analysis firm Endpoint Technologies, was of a similar mind.
"It sounds like a glitch [Microsoft] needs to fix, but it doesn't sound like a big deal," he said. "Still, a user shouldn't have to go through a lot of work to get it fixed," Kay added.
The company had planned to release XP SP3 last week, but that fell through after Microsoft found a clash between the service pack and Microsoft's Dynamics Retail Management System (RMS).
Microsoft announced on Monday it had put a filter in place so that XP SP3 is not offered to users with RMS installed. Then it released the service pack as planned. The company is working to come up with a solution for RMS users.
Friday, May 9, 2008
Thursday, May 8, 2008
What can you do with a second Ethernet port?
By: Nathan Willis
Purchase a new PC or motherboard soon, and the chances are good that it will come with two built-in network interfaces -- either two Ethernet jacks or one Ethernet and one Wi-Fi. Tossing in a second adapter is an inexpensive way for the manufacturer to add another bullet point to the product description -- but what exactly are you supposed to do with it? If you are running Linux, you have several alternatives.
Plugging another Ethernet cable into the second jack and hoping for the best will accomplish nothing; you have to configure Linux's networking subsystem to recognize both adapters, and you must tell the OS how to use them to send and receive traffic. You can do the latter step in several different ways, which is where all the fun comes in.
The big distinction between your options lies in the effect each has on the other devices on your network (computers, routers, and other appliances) -- intelligently routing network traffic between them, linking them together transparently, and so on. In some cases, the simplest end result is not the easiest to set up, so it pays to read through all of the alternatives before you decide which to tackle.
Bonding
From your network's perspective, the simplest option is channel bonding or "port trunking" -- combining both of the computer's interfaces into a single interface that looks like nothing out of the ordinary to your applications.
A combined logical interface can provide load balancing and fault tolerance. The OS can alternate which interface it uses to send traffic, or it can gracefully fail over between them in the event of a problem. You can even use it to balance your traffic between multiple wide area network (WAN) connections, such as DSL and cable, or dialup and your next door neighbor's unsecured Wi-Fi.
To bond two Ethernet interfaces, you must have the bonding module compiled for your kernel (which on a modern distro is almost a certainty), and the ifenslave package (which is a standard utility, although you might need to install it from from your distro's RPM or APT repository).
On a typical two-port motherboard, the Ethernet adapters are named eth0 and eth1, so we will use that for our example commands. With ifenslave installed, take both Ethernet adapters offline by running sudo ifdown eth0 and sudo ifdown eth1. Load the bonding module into the Linux kernel with modprobe. There are two important options to pass to the module: mode and miimon. Mode establishes the type of bond (round-robin, failover, and so on), and miimon establishes how often (in milliseconds) the links will be checked for failure. sudo modprobe bonding mode=0 miimon=100 will set up a round-robin configuration in which network packets alternate between the Ethernet adapters as they are sent out. The miimon value of 100 is a standard place to begin; you can adjust if it you really want to tweak your network.
To create an actual bond (which for convenience we'll call bond0), run sudo ifconfig bond0 192.168.1.100 up to assign an IP address to the bond, then run ifenslave bond0 eth0 followed by ifenslave bond0 eth1 to tie the physical Ethernet interfaces into it.
Round-robin mode is good for general purpose load balancing between the adapters, and if one of them fails, the link will stay active via the other. The other six mode options provide features for different setups. Mode 1, active backup, uses just one adapter until it fails, then switches to the other. Mode 2, balance XOR, tries to balance traffic by splitting up outgoing packets between the adapters, using the same one for each specific destination when possible. Mode 3, broadcast, sends out all traffic on every interface. Mode 4, dynamic link aggregation, uses a complex algorithm to aggregate adapters by speed and other settings. Mode 5, adaptive transmit load balancing, redistributes outgoing traffic on the fly based on current conditions. Mode 6, adaptive load balancing, does the same thing, but attempts to redistribute incoming traffic as well by sending out ARP updates.
The latter, complex modes are probably unnecessary for home use. If you have a lot of network traffic you are looking to manage, consult the bonding driver documentation. For most folks, bonding's fault tolerance and failover is a bigger gain than any increased link speed. For example, bonding two WAN links gives you load balancing and fault tolerance between them, but it does not double your upstream throughput, since each connection (such as a Web page HTTP request) has to take one or the other route.
Bridging
The bonding solution is unique in that both network adapters act like a single adapter for the use of the same machine. The other solutions use the two adapters in a manner that provides a new or different service to the rest of your network.
Bridging, for example, links the two network adapters so that Ethernet frames flow freely between them, just as if they were connected on a simple hub. All of the traffic heard on one interface is passed through to the other.
You can set up a bridge so that the computer itself does not participate in the network at all, essentially transforming the computer into an overpriced Ethernet repeater. But more likely you will want to access the Internet as well as bridge traffic between the ports. That isn't complicated, either.
Bridging requires the bridge-utils package, a standard component of every modern Linux distribution that provides the command-line utility brctl.
To create a bridge between your network adapters, begin by taking both adapters offline with the ifdown command. In our example eth0/eth1 setup, run sudo ifdown eth0 and sudo ifdown eth1 from the command line.
Next, create the bridge with sudo brctl addbr bridge0. The addbr command creates a new "virtual" network adapter named bridge0. You then connect your real network adapters to the bridge with addif: sudo brctl addif bridge0 eth0 adds the first adapter, and sudo brctl addif bridge0 eth1 adds the second.
Once configured, you activate the bridge0 virtual adapter just as you would a normal, physical Ethernet card. You can assign it a static IP address with a command like sudo ifconfig bridge0 192.168.1.100 netmask 255.255.255.0, or tell it to retrieve its configuration via DHCP with sudo dhclient bridge0.
You can then attach as many computers, hub, switches, and other devices as you want through the machine's Ethernet port, and they will all be able to see and communicate with each other. On the downside, if you have a lot of traffic, your computer will spend some extra energy passing all of those Ethernet frames back and forth across the two adapters.
Firewalling and gateway-ing
As long as you have excess traffic zipping through your computer, the OS might as well look at it and do something useful, such as filter it based on destination address, or cache repeatedly requested Web pages. And indeed, you can place your dual-port computer between your upstream cable or DSL connection and the rest of your local network, to serve as a simple Internet-connection-sharing gateway, or as a firewall that exerts control over the packets passing between the network interfaces.
First, you will need to bring both network adapters up and assign each a different IP address -- and, importantly, IP addresses that are on different subnets. For example, sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0 and sudo ifconfig eth1 192.168.2.100 netmask 255.255.255.0. Note that eth0's address is within the 192.168.1.x range, while eth1's is within 192.168.2.x. Maintain this separation when you add other devices to your network and you will keep things running smoothly.
Forwarding the packets between the Internet on one adapter and your LAN on the other is the purview of iptables, a tool for configuring the Linux kernel's IP filtering subsystem. The command sudo iptables -A FORWARD --in-interface eth1 --out-interface eth0 --source 192.168.2.0/255.255.255.0 -m state --state NEW -j ACCEPT allows computers on the LAN interface eth1 to start new connections, and forwards them to the outside world via the eth0 interface. Following that with sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT keeps subsequent packets from those connections flowing smoothly as well.
Next, sudo iptables -A POSTROUTING -t nat -j MASQUERADE activates Network Address Translation (NAT), secretly rewriting the IP addresses of traffic from the LAN so that when it goes out to the Internet, it appears to originate from the Linux box performing the routing. This is a necessary evil for most home Internet connections, both because it allows you to use the private 192.168.x.x IP address block, and because many ISPs frown upon traffic coming from multiple computers.
Finally, run sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward to activate the kernel's packet forwarding.
This setup will pass traffic from your LAN to your Internet connection, but it does not configure the network settings on the LAN computers themselves. Each of them needs an IP address, gateway and network information, and some working DNS server addresses. If your dual-adapter Linux box is serving as a NAT gateway, you could easily have it provide that information to the clients as well, using DHCP. Your distro probably comes with the dhcpd package. Configuring dhcpd is beyond the scope of the subject here, but check your distro's documentation for Internet connection sharing and you will likely find the instructions you need.
Once you are comfortable using iptables to set up basic NAT and packet forwarding, you can dig a little deeper and learn how to use your box as a first-rate firewall by writing rules that filter traffic based on source and destination address, port, and protocol.
Isolating
Finally, you can always configure your secondary network adapter to work in complete isolation from the rest of your LAN.
Sure, there is little gain to such a setup for general-purpose computers, but it is a popular choice for certain Ethernet-connected devices that only need to send data to one destination. Homebrew digital video recorder builders use the technique to connect the HDHomerun HDTV receiver directly to a MythTV back end, thereby isolating the bandwidth-hogging MPEG streams from the LAN. The same traffic separation idea might also come in handy for other single-purpose devices, such as a dedicated network-attached storage (NAS) box, a networked security camera, or your Ethernet-connected houseplant.
For most devices, isolating your second adapter entails setting up the computer to act as a DHCP server as in the gateway example above, but without worrying about NAT rules routing between the secondary client and the rest of the network.
Caveat emptoring
So which technique is right for you? My advice is to think about what network trouble you most need to prepare for. If your dual-adapter box is a server with heavy traffic to handle, or you need to balance your traffic across two WAN connections, bonding is for you. On the other hand, if you just bought an HDHomeRun to add to your MythTV back end, think about attaching it directly to the spare interface.
Bridging and gatewaying are most similar, in that they use the dual-adapter box to connect multiple other devices into a single network. If that is what you need to do, consider that bridging works at the Ethernet link level, well below IP and TCP in the protocol stack. At the Ethernet level, the only sort of traffic shaping you can do is that based on the hardware MAC address of the computer. You have significantly more control when you run a full-fledged NAT gateway.
But whichever option you choose, remember that messing around with your network configuration can get you disconnected in a hurry if you make a mistake. For that reason, all of the above examples use commands that change the "live" system, but don't alter the configuration files Linux reads in at startup. If you make a mistake, a reboot should bring you back to a known working state.
If you decide you want to make your changes permanent, your best bet is to consult your distro's documentation. Distros vary slightly in where and how they store network configuration scripts (Red Hat uses /etc/sysconfig/network-scripts/, for example, while Ubuntu uses /etc/network/).
One you start digging into the details, you'll find even more possibilities for utilizing that second network adapter under Linux. But you should now be armed with a general idea of how to make both adapters talk to your network at the same time -- and you can do your part to eliminate network adapter wastefulness.
Purchase a new PC or motherboard soon, and the chances are good that it will come with two built-in network interfaces -- either two Ethernet jacks or one Ethernet and one Wi-Fi. Tossing in a second adapter is an inexpensive way for the manufacturer to add another bullet point to the product description -- but what exactly are you supposed to do with it? If you are running Linux, you have several alternatives.
Plugging another Ethernet cable into the second jack and hoping for the best will accomplish nothing; you have to configure Linux's networking subsystem to recognize both adapters, and you must tell the OS how to use them to send and receive traffic. You can do the latter step in several different ways, which is where all the fun comes in.
The big distinction between your options lies in the effect each has on the other devices on your network (computers, routers, and other appliances) -- intelligently routing network traffic between them, linking them together transparently, and so on. In some cases, the simplest end result is not the easiest to set up, so it pays to read through all of the alternatives before you decide which to tackle.
Bonding
From your network's perspective, the simplest option is channel bonding or "port trunking" -- combining both of the computer's interfaces into a single interface that looks like nothing out of the ordinary to your applications.
A combined logical interface can provide load balancing and fault tolerance. The OS can alternate which interface it uses to send traffic, or it can gracefully fail over between them in the event of a problem. You can even use it to balance your traffic between multiple wide area network (WAN) connections, such as DSL and cable, or dialup and your next door neighbor's unsecured Wi-Fi.
To bond two Ethernet interfaces, you must have the bonding module compiled for your kernel (which on a modern distro is almost a certainty), and the ifenslave package (which is a standard utility, although you might need to install it from from your distro's RPM or APT repository).
On a typical two-port motherboard, the Ethernet adapters are named eth0 and eth1, so we will use that for our example commands. With ifenslave installed, take both Ethernet adapters offline by running sudo ifdown eth0 and sudo ifdown eth1. Load the bonding module into the Linux kernel with modprobe. There are two important options to pass to the module: mode and miimon. Mode establishes the type of bond (round-robin, failover, and so on), and miimon establishes how often (in milliseconds) the links will be checked for failure. sudo modprobe bonding mode=0 miimon=100 will set up a round-robin configuration in which network packets alternate between the Ethernet adapters as they are sent out. The miimon value of 100 is a standard place to begin; you can adjust if it you really want to tweak your network.
To create an actual bond (which for convenience we'll call bond0), run sudo ifconfig bond0 192.168.1.100 up to assign an IP address to the bond, then run ifenslave bond0 eth0 followed by ifenslave bond0 eth1 to tie the physical Ethernet interfaces into it.
Round-robin mode is good for general purpose load balancing between the adapters, and if one of them fails, the link will stay active via the other. The other six mode options provide features for different setups. Mode 1, active backup, uses just one adapter until it fails, then switches to the other. Mode 2, balance XOR, tries to balance traffic by splitting up outgoing packets between the adapters, using the same one for each specific destination when possible. Mode 3, broadcast, sends out all traffic on every interface. Mode 4, dynamic link aggregation, uses a complex algorithm to aggregate adapters by speed and other settings. Mode 5, adaptive transmit load balancing, redistributes outgoing traffic on the fly based on current conditions. Mode 6, adaptive load balancing, does the same thing, but attempts to redistribute incoming traffic as well by sending out ARP updates.
The latter, complex modes are probably unnecessary for home use. If you have a lot of network traffic you are looking to manage, consult the bonding driver documentation. For most folks, bonding's fault tolerance and failover is a bigger gain than any increased link speed. For example, bonding two WAN links gives you load balancing and fault tolerance between them, but it does not double your upstream throughput, since each connection (such as a Web page HTTP request) has to take one or the other route.
Bridging
The bonding solution is unique in that both network adapters act like a single adapter for the use of the same machine. The other solutions use the two adapters in a manner that provides a new or different service to the rest of your network.
Bridging, for example, links the two network adapters so that Ethernet frames flow freely between them, just as if they were connected on a simple hub. All of the traffic heard on one interface is passed through to the other.
You can set up a bridge so that the computer itself does not participate in the network at all, essentially transforming the computer into an overpriced Ethernet repeater. But more likely you will want to access the Internet as well as bridge traffic between the ports. That isn't complicated, either.
Bridging requires the bridge-utils package, a standard component of every modern Linux distribution that provides the command-line utility brctl.
To create a bridge between your network adapters, begin by taking both adapters offline with the ifdown command. In our example eth0/eth1 setup, run sudo ifdown eth0 and sudo ifdown eth1 from the command line.
Next, create the bridge with sudo brctl addbr bridge0. The addbr command creates a new "virtual" network adapter named bridge0. You then connect your real network adapters to the bridge with addif: sudo brctl addif bridge0 eth0 adds the first adapter, and sudo brctl addif bridge0 eth1 adds the second.
Once configured, you activate the bridge0 virtual adapter just as you would a normal, physical Ethernet card. You can assign it a static IP address with a command like sudo ifconfig bridge0 192.168.1.100 netmask 255.255.255.0, or tell it to retrieve its configuration via DHCP with sudo dhclient bridge0.
You can then attach as many computers, hub, switches, and other devices as you want through the machine's Ethernet port, and they will all be able to see and communicate with each other. On the downside, if you have a lot of traffic, your computer will spend some extra energy passing all of those Ethernet frames back and forth across the two adapters.
Firewalling and gateway-ing
As long as you have excess traffic zipping through your computer, the OS might as well look at it and do something useful, such as filter it based on destination address, or cache repeatedly requested Web pages. And indeed, you can place your dual-port computer between your upstream cable or DSL connection and the rest of your local network, to serve as a simple Internet-connection-sharing gateway, or as a firewall that exerts control over the packets passing between the network interfaces.
First, you will need to bring both network adapters up and assign each a different IP address -- and, importantly, IP addresses that are on different subnets. For example, sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0 and sudo ifconfig eth1 192.168.2.100 netmask 255.255.255.0. Note that eth0's address is within the 192.168.1.x range, while eth1's is within 192.168.2.x. Maintain this separation when you add other devices to your network and you will keep things running smoothly.
Forwarding the packets between the Internet on one adapter and your LAN on the other is the purview of iptables, a tool for configuring the Linux kernel's IP filtering subsystem. The command sudo iptables -A FORWARD --in-interface eth1 --out-interface eth0 --source 192.168.2.0/255.255.255.0 -m state --state NEW -j ACCEPT allows computers on the LAN interface eth1 to start new connections, and forwards them to the outside world via the eth0 interface. Following that with sudo iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT keeps subsequent packets from those connections flowing smoothly as well.
Next, sudo iptables -A POSTROUTING -t nat -j MASQUERADE activates Network Address Translation (NAT), secretly rewriting the IP addresses of traffic from the LAN so that when it goes out to the Internet, it appears to originate from the Linux box performing the routing. This is a necessary evil for most home Internet connections, both because it allows you to use the private 192.168.x.x IP address block, and because many ISPs frown upon traffic coming from multiple computers.
Finally, run sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward to activate the kernel's packet forwarding.
This setup will pass traffic from your LAN to your Internet connection, but it does not configure the network settings on the LAN computers themselves. Each of them needs an IP address, gateway and network information, and some working DNS server addresses. If your dual-adapter Linux box is serving as a NAT gateway, you could easily have it provide that information to the clients as well, using DHCP. Your distro probably comes with the dhcpd package. Configuring dhcpd is beyond the scope of the subject here, but check your distro's documentation for Internet connection sharing and you will likely find the instructions you need.
Once you are comfortable using iptables to set up basic NAT and packet forwarding, you can dig a little deeper and learn how to use your box as a first-rate firewall by writing rules that filter traffic based on source and destination address, port, and protocol.
Isolating
Finally, you can always configure your secondary network adapter to work in complete isolation from the rest of your LAN.
Sure, there is little gain to such a setup for general-purpose computers, but it is a popular choice for certain Ethernet-connected devices that only need to send data to one destination. Homebrew digital video recorder builders use the technique to connect the HDHomerun HDTV receiver directly to a MythTV back end, thereby isolating the bandwidth-hogging MPEG streams from the LAN. The same traffic separation idea might also come in handy for other single-purpose devices, such as a dedicated network-attached storage (NAS) box, a networked security camera, or your Ethernet-connected houseplant.
For most devices, isolating your second adapter entails setting up the computer to act as a DHCP server as in the gateway example above, but without worrying about NAT rules routing between the secondary client and the rest of the network.
Caveat emptoring
So which technique is right for you? My advice is to think about what network trouble you most need to prepare for. If your dual-adapter box is a server with heavy traffic to handle, or you need to balance your traffic across two WAN connections, bonding is for you. On the other hand, if you just bought an HDHomeRun to add to your MythTV back end, think about attaching it directly to the spare interface.
Bridging and gatewaying are most similar, in that they use the dual-adapter box to connect multiple other devices into a single network. If that is what you need to do, consider that bridging works at the Ethernet link level, well below IP and TCP in the protocol stack. At the Ethernet level, the only sort of traffic shaping you can do is that based on the hardware MAC address of the computer. You have significantly more control when you run a full-fledged NAT gateway.
But whichever option you choose, remember that messing around with your network configuration can get you disconnected in a hurry if you make a mistake. For that reason, all of the above examples use commands that change the "live" system, but don't alter the configuration files Linux reads in at startup. If you make a mistake, a reboot should bring you back to a known working state.
If you decide you want to make your changes permanent, your best bet is to consult your distro's documentation. Distros vary slightly in where and how they store network configuration scripts (Red Hat uses /etc/sysconfig/network-scripts/, for example, while Ubuntu uses /etc/network/).
One you start digging into the details, you'll find even more possibilities for utilizing that second network adapter under Linux. But you should now be armed with a general idea of how to make both adapters talk to your network at the same time -- and you can do your part to eliminate network adapter wastefulness.
OfflineIMAP makes messages and attachments available locally
May 06, 2008 (9:00:00 AM) - 2 days, 5 hours ago
By: Ben Martin
OfflineIMAP allows you to read your email while you are not connected to the Internet. This is great when you are traveling and really need an attachment from a message but cannot connect to the Internet.
You can use OfflineIMAP to sync all your email during the night so that it is all instantly available when you wake up. This is a security trade-off -- you gain speed and availability for your email at the expense of having to properly protect the local copy of all the email that is created on your laptop.
OfflineIMAP is designed to contact your IMAP servers and create a local copy of your email in maildir format. You then point your mail client at the local maildir tree and use your mail client as normal. OfflineIMAP can then sync any changes, such as which messages you have read and deleted, back to the server. OfflineIMAP performs a bidirectional sync, so new messages from the server are downloaded to your local maildir while any changes you have made locally are sent to the IMAP server.
If your email client does not support maildir format, you can use OfflineIMAP to sync email between two IMAP servers and ultimately accomplish the same thing. This scenario is a little more complex, as you need to install an IMAP server on your laptop, tell your email client to connect to the IMAP server on localhost, then use OfflineIMAP to keep the IMAP server on your laptop in sync with your main IMAP server. An alternative is to use OfflineIMAP to sync to a maildir repository as normal and tell your local IMAP server to use that maildir as its email source. This thread contains information on setting up courier-imap locally to serve up your mail.
OfflineIMAP packages are available for openSUSE, Ubuntu Gutsy, and from the Fedora 7 and 8 repositories. If no packages exist for your distribution, the documentation provides good information on installation from source. I used OfflineIMAP 5.99.2 from the Fedora 8 repository. Version 5.99.2 does not support the Gmail account type. Version offlineimap-5.99.7 from the Fedora rawhide repository does support Gmail but has another bug relating to directory creation which causes synchronization to fail. For these reasons I would recommend using the IMAP account type and manually configuring it for Gmail until package repositories contain later versions of OfflineIMAP.
The primary configuration file for OfflineIMAP is $HOME/.offlineimaprc, and you can find a commented template configuration file online. The configuration file defines one or more accounts. For each account you must set the local and remote repository. A repository is configured in its own section and contains the type for storing email locally, or IMAP to connect to a mail server. When connecting to an IMAP server you can specify the hostname, username, and password, and whether OfflineIMAP should use SSL to connect to the IMAP server.
Configuration and setup is shown below. First I create the configuration file using the sample that comes with the offlineimap package. The accounts directive is set to contain a single Gmail account. This account has both a local and remote repository so that OfflineIMAP knows where to store email locally and what server to contact. The local repository is a maildir in my home directory. The remote repository uses the type IMAP instead of Gmail because of the version issues discussed above. I have selected an appropriate email address as the remoteuser so spambots will make themselves known. The nametrans directive lets you change the name of folders in the local repository. In this case I call re.sub twice to first change occurrences of INBOX, [Gmail], or [Google Mail] into root. One directory will be missed by this initial mapping, which is then accounted for by moving the Sent folder inside the root folder. This translation is useful because Evolution expects your inbox to be directly in the root folder of your IMAP account. If you change where the local copy of INBOX is stored, Evolution can more naturally interact with the local mail repository. You can also set up more elaborate folder name translations depending on your needs.
$ cp /.../offlineimap.conf ~/.offlineimaprc $ vi ~/.offlineimaprc accounts = my-gmail [Account my-gmail] localrepository = GMailLocalMaildirRepository remoterepository = GMailServerRepository [Repository GMailLocalMaildirRepository] type = Maildir localfolders = ~/.offlineimap-maildir-my-gmail sep = . restoreatime = no [Repository GMailServerRepository] type = IMAP remoteuser = i-am-a-spam-bot-log-me@gmail.com remotehost = imap.gmail.com ssl = yes remotepassfile = ~/.offlineimap-pass-my-gmail realdelete = no nametrans = lambda foldername: re.sub('^Sent$', 'root/Sent', re.sub('^(\[G.*ail\]|INBOX)', 'root', foldername)) ... $ mkdir -p ~/.offlineimap-maildir-my-gmail
With this configuration in place, just run offlineimap. It will check its metadata and notice that you haven't performed any previous sync and download everything from your IMAP server.
You should then have a complete copy of your email in maildir format on your local machine. See the client notes for information on configuring your email client to directly use the email from this maildir. When you want to send your changes back to the main IMAP server and check for new email, just run offlineimap again. Alternatively, you can use the autorefresh directive in ~/.offlineimaprc to tell offlineimap to continue to sync your accounts every n minutes.
Normally, you should run OfflineIMAP without any command-line options to bidirectionally synchronize your configured email accounts, but OfflineIMAP accepts some options that might be handy for casual use. The -a option accepts a comma-separated list of accounts that you wish to synchronize. This can be great if you are expecting a message but have some accounts defined that are slower to sync than others. The -u option lets you choose one of many interfaces to OfflineIMAP. The default is the Curses.Blinkenlights interface, which you might find to be too distracting. TTY.TTYUI displays a simpler and less distracting progress report. You can also change the interface that will be used by default by altering the ui directive in ~/.offlineimaprc. The -c option allows you to specify an alternate location to ~/.offlineimaprc for the configuration file.
Having the contents of your IMAP account available offline means you don't have to seek out an Internet connection just to get an attachment or wonder if a particular message has been cached locally by your email client. If you are working with moderate-sized attachments, the ability to schedule your laptop to grab your email an hour before you wake up can save precious time when you are traveling.
By: Ben Martin
OfflineIMAP allows you to read your email while you are not connected to the Internet. This is great when you are traveling and really need an attachment from a message but cannot connect to the Internet.
You can use OfflineIMAP to sync all your email during the night so that it is all instantly available when you wake up. This is a security trade-off -- you gain speed and availability for your email at the expense of having to properly protect the local copy of all the email that is created on your laptop.
OfflineIMAP is designed to contact your IMAP servers and create a local copy of your email in maildir format. You then point your mail client at the local maildir tree and use your mail client as normal. OfflineIMAP can then sync any changes, such as which messages you have read and deleted, back to the server. OfflineIMAP performs a bidirectional sync, so new messages from the server are downloaded to your local maildir while any changes you have made locally are sent to the IMAP server.
If your email client does not support maildir format, you can use OfflineIMAP to sync email between two IMAP servers and ultimately accomplish the same thing. This scenario is a little more complex, as you need to install an IMAP server on your laptop, tell your email client to connect to the IMAP server on localhost, then use OfflineIMAP to keep the IMAP server on your laptop in sync with your main IMAP server. An alternative is to use OfflineIMAP to sync to a maildir repository as normal and tell your local IMAP server to use that maildir as its email source. This thread contains information on setting up courier-imap locally to serve up your mail.
OfflineIMAP packages are available for openSUSE, Ubuntu Gutsy, and from the Fedora 7 and 8 repositories. If no packages exist for your distribution, the documentation provides good information on installation from source. I used OfflineIMAP 5.99.2 from the Fedora 8 repository. Version 5.99.2 does not support the Gmail account type. Version offlineimap-5.99.7 from the Fedora rawhide repository does support Gmail but has another bug relating to directory creation which causes synchronization to fail. For these reasons I would recommend using the IMAP account type and manually configuring it for Gmail until package repositories contain later versions of OfflineIMAP.
The primary configuration file for OfflineIMAP is $HOME/.offlineimaprc, and you can find a commented template configuration file online. The configuration file defines one or more accounts. For each account you must set the local and remote repository. A repository is configured in its own section and contains the type for storing email locally, or IMAP to connect to a mail server. When connecting to an IMAP server you can specify the hostname, username, and password, and whether OfflineIMAP should use SSL to connect to the IMAP server.
Configuration and setup is shown below. First I create the configuration file using the sample that comes with the offlineimap package. The accounts directive is set to contain a single Gmail account. This account has both a local and remote repository so that OfflineIMAP knows where to store email locally and what server to contact. The local repository is a maildir in my home directory. The remote repository uses the type IMAP instead of Gmail because of the version issues discussed above. I have selected an appropriate email address as the remoteuser so spambots will make themselves known. The nametrans directive lets you change the name of folders in the local repository. In this case I call re.sub twice to first change occurrences of INBOX, [Gmail], or [Google Mail] into root. One directory will be missed by this initial mapping, which is then accounted for by moving the Sent folder inside the root folder. This translation is useful because Evolution expects your inbox to be directly in the root folder of your IMAP account. If you change where the local copy of INBOX is stored, Evolution can more naturally interact with the local mail repository. You can also set up more elaborate folder name translations depending on your needs.
$ cp /.../offlineimap.conf ~/.offlineimaprc $ vi ~/.offlineimaprc accounts = my-gmail [Account my-gmail] localrepository = GMailLocalMaildirRepository remoterepository = GMailServerRepository [Repository GMailLocalMaildirRepository] type = Maildir localfolders = ~/.offlineimap-maildir-my-gmail sep = . restoreatime = no [Repository GMailServerRepository] type = IMAP remoteuser = i-am-a-spam-bot-log-me@gmail.com remotehost = imap.gmail.com ssl = yes remotepassfile = ~/.offlineimap-pass-my-gmail realdelete = no nametrans = lambda foldername: re.sub('^Sent$', 'root/Sent', re.sub('^(\[G.*ail\]|INBOX)', 'root', foldername)) ... $ mkdir -p ~/.offlineimap-maildir-my-gmail
With this configuration in place, just run offlineimap. It will check its metadata and notice that you haven't performed any previous sync and download everything from your IMAP server.
You should then have a complete copy of your email in maildir format on your local machine. See the client notes for information on configuring your email client to directly use the email from this maildir. When you want to send your changes back to the main IMAP server and check for new email, just run offlineimap again. Alternatively, you can use the autorefresh directive in ~/.offlineimaprc to tell offlineimap to continue to sync your accounts every n minutes.
Normally, you should run OfflineIMAP without any command-line options to bidirectionally synchronize your configured email accounts, but OfflineIMAP accepts some options that might be handy for casual use. The -a option accepts a comma-separated list of accounts that you wish to synchronize. This can be great if you are expecting a message but have some accounts defined that are slower to sync than others. The -u option lets you choose one of many interfaces to OfflineIMAP. The default is the Curses.Blinkenlights interface, which you might find to be too distracting. TTY.TTYUI displays a simpler and less distracting progress report. You can also change the interface that will be used by default by altering the ui directive in ~/.offlineimaprc. The -c option allows you to specify an alternate location to ~/.offlineimaprc for the configuration file.
Having the contents of your IMAP account available offline means you don't have to seek out an Internet connection just to get an attachment or wonder if a particular message has been cached locally by your email client. If you are working with moderate-sized attachments, the ability to schedule your laptop to grab your email an hour before you wake up can save precious time when you are traveling.
As the SCO rolls
By: Steven J. Vaughan-Nichols
Reality, as good writers know, is sometimes stranger than fiction. SCO's recent performance in the U.S. District Court in Utah is a perfect example. With years to prepare, SCO executives made some remarkable statements in their attempt to show that SCO, not Novell, owns Unix's copyright.
While this case is not about SCO's claims that IBM and other companies placed Unix IP (intellectual property) into Linux, Novell's attorneys decided that they would address this issue as well. One presumes that, since this may be their one and only chance to attack SCO's Linux claims in a courtroom -- what with SCO facing bankruptcy -- they decided to address this FUD once and for all.
Before getting to that, though, Novell hammered on Christopher Sontag, one time head of SCOSource, the division of SCO devoted to selling Unix's IP. Sontag, while dodging around what code SCO was actually selling -- UnixWare code or the whole Unix tree leading to UnixWare -- was finally cornered into admitting that SCO had received $16,680,000 from Microsoft and $9,143,450.63 from Sun and did not report these deals or income to Novell as it was required to do under the terms of the Novell/SCO APA (Asset Purchase Agreement).
On the second day of the hearing, April 30th, Sontag admitted that he did not "know if there's any code that is unique to UnixWare that is in Linux." He also admitted that he did not know of any analysis that showed there was any "legacy SVRX [Unix] software' in UnixWare." For someone who was in charge of SCO's Unix IP, who arranged to license it to Sun and Microsoft, and whose company was suing IBM for using Unix code in Linux, Sontag seemed remarkably ill-informed about exactly what it was that he was selling.
Sontag was followed on the witness stand by SCO CEO Darl McBride. With McBride on the stand, as can be seen in the trial's transcript, things became somewhat surreal. McBride, only minutes after Sontag said he didn't know if there was Unix or UnixWare code in Linux, said, "We have evidence System V is in Linux." McBride's most memorable moment came though when he claimed, after years of never being able to demonstrate any direct copying of Unix material into Linux that "Linux is a copy of UNIX, there is no difference [between them]."
In regards to SCO's May 2003 letter to companies that were using Linux and "Therefore, legal liability that may arise from the Linux development process may also rest with the end user," McBride claimed that "I don't see anything in here that says you have to take a license from us."
From there, McBride went on to say that simply because SCO had stated in this letter that "We intend to aggressively protect and enforce our rights" and added that the company had already sued IBM, that SCO didn't mean to imply that "we're going to go out and sue everybody else." At the time, most observers agreed that SCO certainly sounded like they were threatening to sue Linux end-users.
McBride then managed to entangle himself in how SCO accounted for the revenue it had received from Microsoft and Sun. The implication, which McBride vigorously denied, was that SCO had misled the stock-buying public in SEC documents in 2003 and 2004.
In what may prove to be a problem for Sun in the future, McBride also said that while SCO felt Sun had the right to open-source Unix in OpenSolaris, its most recent Sun contract was really about Sun "looking for ways to take their Solaris operating system and make it more compliant with the Intel chip set, which is what SCO has a deep history of doing."
Greg Jones, Novell's VP of Technology Law, was then sworn in. Jones testified that SCO's 2003 agreement with Sun "allows Sun, then, to release Solaris as open source under an open source licensing model, which they have done in a project called OpenSolaris. So it poses a direct competitive challenge to Linux and, certainly, to Novell, given that Linux is an important part of Novell's business. We are a Linux distributor."
Jones went on to say that if Novell had been aware of SCO making this deal with Sun, it would not have allowed it because, "It simply would not have been in Novell's commercial interests. In the fall of 2002, Novell had acquired Ximian, a Linux desktop company. We were exploring ways to get into the Linux market so enabling a competitor to Linux simply would not have been in Novell's interests. In the manner in which they entered this agreement, when they did it, they kept all the money. I assume that would have been their proposal but, fundamentally, it simply would have been contrary to Novell's business interests to enable something like this."
On the third day of the case SCO stuck to its guns, but added little more to their arguments.
On the case's final day, Novell simply stated that, when all was said and done, the APA made it clear that Novell, and not SCO, had the rights to Unix's IP. Therefore, SCO had no right to make these deals, and certainly no rights whatsoever to keep the funds from such deal.
In Novell's closing arguments, Novell also hit again on the SCO/Sun deal. Novell pointed out that "There's no question they (SCO) allowed Sun to open-source Solaris," and that while SCO executives would have you believe that giving Sun the right to open-source Solaris had no market value, SCO's engineers believed that open-sourcing Solaris had great value.
So, as the case moves on, SCO still seems unable to make any headway on its claims that the APA gave it the right to sell Unix's IP. Novell attorney's also made a point of demonstrating that SCO still has only naked claims, without any evidence, that there's any Unix code inside Linux. The Judge is expected to rule on the case in the near future.
Finally, Sun may yet have to contend with Novell's IP interests in OpenSolaris. Novell clearly doesn't believe Sun had the rights to open-source the System V code within OpenSolaris under its CDDL (Common Development and Distribution License).
Reality, as good writers know, is sometimes stranger than fiction. SCO's recent performance in the U.S. District Court in Utah is a perfect example. With years to prepare, SCO executives made some remarkable statements in their attempt to show that SCO, not Novell, owns Unix's copyright.
While this case is not about SCO's claims that IBM and other companies placed Unix IP (intellectual property) into Linux, Novell's attorneys decided that they would address this issue as well. One presumes that, since this may be their one and only chance to attack SCO's Linux claims in a courtroom -- what with SCO facing bankruptcy -- they decided to address this FUD once and for all.
Before getting to that, though, Novell hammered on Christopher Sontag, one time head of SCOSource, the division of SCO devoted to selling Unix's IP. Sontag, while dodging around what code SCO was actually selling -- UnixWare code or the whole Unix tree leading to UnixWare -- was finally cornered into admitting that SCO had received $16,680,000 from Microsoft and $9,143,450.63 from Sun and did not report these deals or income to Novell as it was required to do under the terms of the Novell/SCO APA (Asset Purchase Agreement).
On the second day of the hearing, April 30th, Sontag admitted that he did not "know if there's any code that is unique to UnixWare that is in Linux." He also admitted that he did not know of any analysis that showed there was any "legacy SVRX [Unix] software' in UnixWare." For someone who was in charge of SCO's Unix IP, who arranged to license it to Sun and Microsoft, and whose company was suing IBM for using Unix code in Linux, Sontag seemed remarkably ill-informed about exactly what it was that he was selling.
Sontag was followed on the witness stand by SCO CEO Darl McBride. With McBride on the stand, as can be seen in the trial's transcript, things became somewhat surreal. McBride, only minutes after Sontag said he didn't know if there was Unix or UnixWare code in Linux, said, "We have evidence System V is in Linux." McBride's most memorable moment came though when he claimed, after years of never being able to demonstrate any direct copying of Unix material into Linux that "Linux is a copy of UNIX, there is no difference [between them]."
In regards to SCO's May 2003 letter to companies that were using Linux and "Therefore, legal liability that may arise from the Linux development process may also rest with the end user," McBride claimed that "I don't see anything in here that says you have to take a license from us."
From there, McBride went on to say that simply because SCO had stated in this letter that "We intend to aggressively protect and enforce our rights" and added that the company had already sued IBM, that SCO didn't mean to imply that "we're going to go out and sue everybody else." At the time, most observers agreed that SCO certainly sounded like they were threatening to sue Linux end-users.
McBride then managed to entangle himself in how SCO accounted for the revenue it had received from Microsoft and Sun. The implication, which McBride vigorously denied, was that SCO had misled the stock-buying public in SEC documents in 2003 and 2004.
In what may prove to be a problem for Sun in the future, McBride also said that while SCO felt Sun had the right to open-source Unix in OpenSolaris, its most recent Sun contract was really about Sun "looking for ways to take their Solaris operating system and make it more compliant with the Intel chip set, which is what SCO has a deep history of doing."
Greg Jones, Novell's VP of Technology Law, was then sworn in. Jones testified that SCO's 2003 agreement with Sun "allows Sun, then, to release Solaris as open source under an open source licensing model, which they have done in a project called OpenSolaris. So it poses a direct competitive challenge to Linux and, certainly, to Novell, given that Linux is an important part of Novell's business. We are a Linux distributor."
Jones went on to say that if Novell had been aware of SCO making this deal with Sun, it would not have allowed it because, "It simply would not have been in Novell's commercial interests. In the fall of 2002, Novell had acquired Ximian, a Linux desktop company. We were exploring ways to get into the Linux market so enabling a competitor to Linux simply would not have been in Novell's interests. In the manner in which they entered this agreement, when they did it, they kept all the money. I assume that would have been their proposal but, fundamentally, it simply would have been contrary to Novell's business interests to enable something like this."
On the third day of the case SCO stuck to its guns, but added little more to their arguments.
On the case's final day, Novell simply stated that, when all was said and done, the APA made it clear that Novell, and not SCO, had the rights to Unix's IP. Therefore, SCO had no right to make these deals, and certainly no rights whatsoever to keep the funds from such deal.
In Novell's closing arguments, Novell also hit again on the SCO/Sun deal. Novell pointed out that "There's no question they (SCO) allowed Sun to open-source Solaris," and that while SCO executives would have you believe that giving Sun the right to open-source Solaris had no market value, SCO's engineers believed that open-sourcing Solaris had great value.
So, as the case moves on, SCO still seems unable to make any headway on its claims that the APA gave it the right to sell Unix's IP. Novell attorney's also made a point of demonstrating that SCO still has only naked claims, without any evidence, that there's any Unix code inside Linux. The Judge is expected to rule on the case in the near future.
Finally, Sun may yet have to contend with Novell's IP interests in OpenSolaris. Novell clearly doesn't believe Sun had the rights to open-source the System V code within OpenSolaris under its CDDL (Common Development and Distribution License).
Monday, April 28, 2008
Apple in rumored talks to license vibration feedback for iPhone
By Aidan Malley
Published: 02:45 PM EST
Apple has reportedly begun talks with Immersion to integrate haptic feedback into future touchscreen devices, addressing a complaint leveled against the iPhone by fans of physical buttons and keyboards.
An Apple worker has allegedly leaked to Palluxo that Immersion executives met twice with their Apple peers this week to discuss integrating Immersion's vibration response technology into the cellphone.
The meetings are said to parallel a more publicized deepening of relations between the two companies through indirect means: Immersion this week hired Clent Richardson, a former Worldwide Solutions Marketing VP at Apple between 1997 and 2001.
What exactly would be implemented is unclear. However, Immersion's most recent efforts have focused on using haptics to simulate physical button presses in an increasing number of touchscreen phones, including Sprint's soon-to-be iPhone rival, the Samsung Instinct.
The technique most frequently involves sending short, concentrated pulses through all or specific locations of a phone as the user taps buttons in software. In effect, haptics not only restore some of the feel absent in touchscreens, but also give users a way of confirming that the phone has recognized a command through more than just visual output.
A frequently-cited complaint regarding the iPhone is its lack of tactile feedback for converts from BlackBerries and other smartphones, many of whom expect the relative certainty of physical responses while navigating the interface or typing.
Neither Apple nor Immersion has commented on the rumored discussions, which are still early and so aren't expected to result in a finished product for some time.
Published: 02:45 PM EST
Apple has reportedly begun talks with Immersion to integrate haptic feedback into future touchscreen devices, addressing a complaint leveled against the iPhone by fans of physical buttons and keyboards.
An Apple worker has allegedly leaked to Palluxo that Immersion executives met twice with their Apple peers this week to discuss integrating Immersion's vibration response technology into the cellphone.
The meetings are said to parallel a more publicized deepening of relations between the two companies through indirect means: Immersion this week hired Clent Richardson, a former Worldwide Solutions Marketing VP at Apple between 1997 and 2001.
What exactly would be implemented is unclear. However, Immersion's most recent efforts have focused on using haptics to simulate physical button presses in an increasing number of touchscreen phones, including Sprint's soon-to-be iPhone rival, the Samsung Instinct.
The technique most frequently involves sending short, concentrated pulses through all or specific locations of a phone as the user taps buttons in software. In effect, haptics not only restore some of the feel absent in touchscreens, but also give users a way of confirming that the phone has recognized a command through more than just visual output.
A frequently-cited complaint regarding the iPhone is its lack of tactile feedback for converts from BlackBerries and other smartphones, many of whom expect the relative certainty of physical responses while navigating the interface or typing.
Neither Apple nor Immersion has commented on the rumored discussions, which are still early and so aren't expected to result in a finished product for some time.
Remote control function said hidden in iPhone beta firmware
By Aidan Malley
Published: 02:20 PM EST
Code in Apple's latest iPhone 2.0 beta firmware allegedly contains references to a utility that will let an iPhone or iPod touch play media from nearby iTunes sources
Pointing only to an unnamed person as the source for its leak, TUAW claims that multiple string entries in the cellphone's beta code refer to selecting from different media categories and include mentions of dialog boxes that let users choose their particular source.
The information suggests that the additions are the groundwork for an Apple TV-like feature, purportedly named iControl, that would let users play any iTunes content over a local network with features similarly to the dedicated media hub already on store shelves.
It's unclear as to whether the feature is strictly intended for streaming local content to the iPhone itself or can actively steer other devices, imitating a more advanced home theater remote such as Logitech's Harmony.
However, the listings as they appear would indicate a direct connection to a 2.5-year-old patent filing submitted by Apple in late 2005.
In the filing, the iPhone maker says it has invented a method that would let a portable media player view the contents of a local media server, such as a computer, and send instructions telling the media server to change tracks while it outputs content to a separate media receiver, whether physically attached to the computer (such as speakers) or remote (such as an Airport Express-like connection).
The aim is to let users steer media playback in a networked media system with existing hardware rather than dedicated controllers, Apple engineers state in the earlier patent.
Regardless of its actual purpose of iControl, there are no clues as to when, if at all, the software will be released for the company's handheld devices.
Published: 02:20 PM EST
Code in Apple's latest iPhone 2.0 beta firmware allegedly contains references to a utility that will let an iPhone or iPod touch play media from nearby iTunes sources
Pointing only to an unnamed person as the source for its leak, TUAW claims that multiple string entries in the cellphone's beta code refer to selecting from different media categories and include mentions of dialog boxes that let users choose their particular source.
The information suggests that the additions are the groundwork for an Apple TV-like feature, purportedly named iControl, that would let users play any iTunes content over a local network with features similarly to the dedicated media hub already on store shelves.
It's unclear as to whether the feature is strictly intended for streaming local content to the iPhone itself or can actively steer other devices, imitating a more advanced home theater remote such as Logitech's Harmony.
However, the listings as they appear would indicate a direct connection to a 2.5-year-old patent filing submitted by Apple in late 2005.
In the filing, the iPhone maker says it has invented a method that would let a portable media player view the contents of a local media server, such as a computer, and send instructions telling the media server to change tracks while it outputs content to a separate media receiver, whether physically attached to the computer (such as speakers) or remote (such as an Airport Express-like connection).
The aim is to let users steer media playback in a networked media system with existing hardware rather than dedicated controllers, Apple engineers state in the earlier patent.
Regardless of its actual purpose of iControl, there are no clues as to when, if at all, the software will be released for the company's handheld devices.
Europe's not finished with Microsoft
Microsoft's troubles in Europe are far from over, as Neelie Kroes, The EU competition commissioner, has warned. We review the past and future options for Microsoft and the European Commission.
Posted Richard Hillesley at 2:34PM, 24th April 2008
The 80s were the dog-eat-dog days of business. Top of the pile was Microsoft, the biggest and baddest of them all, led by Bill Gates, who invented the computer, the universe and everything.
Gates looked a bit like the nerd on the cover of Mad Magazine, made it to the cover of Time magazine, and was rich and successful beyond anybody's wildest dreams.
The view of Gates and Microsoft from inside the computer industry was more circumspect. PC software looked amateurish and nobody took it too seriously until the cultures began to collide in the business world during the middle of the decade. The affordable desktop computer, which sprang out of an unholy alliance between IBM, Intel and Microsoft, changed the face of computing in the home and in the work place, and for the most part was beneficial to the user, if only because it was cheap and accessible.
Microsoft always took more credit for this revolution than it probably deserved, but had a way of coming out on top, which owed everything to its early dominance of the operating system market for the IBM PC and its clones. From this dominance grew its prominence on the desktop, and the gradual eclipse of its competitors. The question that was always being asked of Microsoft was how much did the company owe its success to the quality of its software, and how much to the ruthlessness of its marketing?
From the beginning Microsoft had a special relationship with the original equipment manufacturers (OEMS), and made this relationship tell. Each innovation on the desktop, each new tool and the company that made it, either fell by the wayside or was assimilated into the Microsoft hive.
In the hive
Compaq had its arm twisted to stop it bundling Apple's Quicktime on the desktop. Internet Explorer, and later, the Windows Media Player, were bundled into the operating system, and given away free, sucking revenues and market share from Netscape, Real Networks and Apple. The squashing of Netscape and the subsequent death of the browser market led to Microsoft's conviction for monopolistic behaviour before the US antitrust courts.
Microsoft added platform-dependent "features" to Java to render Java's multi-platform features redundant, and when that ended up in court, developed the .NET platform, a very successful and popular alternative that reproduced many of the major features of Java with the notable exception of its multi-platform capabilities.
Kerberos, the encryption standard developed by MIT, was extended by Microsoft with the apparent objective of inhibiting interoperability in the workgroup server space and, in the words of Jeremy Allison of Samba: "these changes were treated as trade secrets, patented if possible, and only released under restrictive non-disclosure agreements, if released at all."
During the US anti-trust trials, Steven McGeady, a vice president of Intel, testified against Microsoft, Intel's most important trading partner, asserting that Microsoft intended to "embrace, extend and extinguish" competition by substituting open standards with proprietary protocols, and claimed that Intel had been warned to cease development of its Native Signal Processing audio and video technology, which promised to vastly improve user experience of the desktop - or else Microsoft would bypass Intel and develop Windows exclusively for AMD and National Semiconductor chips. "It was clear to us that if this chip did not run Windows it would be useless in the marketplace," McGeady testified. "The threat was both credible and terrifying."
Microsoft has always had an ambivalent relationship with the concept of interoperability and with the standards that make interoperability possible, tending to view the protocols and data formats it uses as "de facto" standards and "trade secrets" which it is free to "extend" with no obligation to share. This may not always be deliberate behaviour. Where there is a monopoly standards become incidental, an option rather an obligation. This tendency has been at the root of Microsoft's problems in the US and European courts. Microsoft is not being penalised for success, but for shutting the door on competition, and resisting any requests to modify its behaviour.
Into Europe
Microsoft's troubles in Europe began as early as 1993, when Novell complained that "onerous licensing conditions" imposed on OEMs by Microsoft was pushing NetWare out of the workgroup market.
In this market Novell had been the innovator, but Microsoft had muscled a napping, but still relevant, Novell out of the picture. Thus began a long history of litigation which culminated in the 17 September 2007 decision of the European Court of First Instance, which upheld the European Commission's decision to fine Microsoft and uphold the principle of interoperability.
The September judgement came at the end of a ten year case initiated by Real Networks, supported by Sun Microsystems, Novell and others, all arguing that innovative products were being pushed out of the market on the back of Microsoft's monopoly. Over the years each of these litigants withdrew from the case after doing deals with Microsoft worth billions of dollars, leaving the Free Software Foundation Europe (FSFE), the Samba Team, and their allies to fight the case to the finish.
As Jeremy Allison of the Samba Team told Groklaw: "the copyright in Samba is spread across many, many individuals, all of whom contributed under the GNU GPL 'v2 or later', now 'v3 or later' licenses. You can't buy that. There's nothing to sell. There's no point of agreement for which to say 'here are the rights to Samba, we'll go away'. We're in the, some would say unique, some would say unenviable position, of not being able to sell out. We can't be bought."
Much has been made of the Commission's insistence that Microsoft offer a version of Windows without Windows Media Player bundled, and the record fines imposed upon Microsoft. Improbably, some press coverage suggested that the European decision was a blow against innovation and competition. But the fines mean little more than a few pence on the price of Windows to a company as rich as Microsoft. The fines are a penance for Microsoft's prevarications and refusal to comply with the European courts.
The most important part of the judgement was the Commission's insistence that Microsoft be forced to publish the protocols used by Windows clients and servers under "reasonable" and "non-discriminatory" terms.
For this decision to have any meaning it was incumbent upon Microsoft to publish the protocols in their entirety, and to reflect the actual behaviour of Microsoft servers and clients in the real world - without evasion, inconsistencies, broken standards, obfuscations, fees or hidden patents - to comply with the commonly understood meaning of open standards and protocols as they have been implemented by other participants in the computing industry.
Microsoft has complied, with reservations, releasing protocols and data formats free for "non-commercial" use, (which immediately discriminates against competition), and making promises of future interoperability with its products. Unfortunately the promises have come with limitations, and the limitations target free and open source software.
As Thomas Vinje of ECIS, noted: "For years now, Microsoft has either failed to implement or has actively corrupted a range of truly open standards adopted and implemented by the rest of the industry. Unless and until that behaviour stops, today's words mean nothing."
Bursting the bubble
It is worth noting that once Netscape was trounced and Microsoft assumed the monopoly position in the browser market there was a five year gap of no innovation or competition between the release of IE6 and IE7. The subsequent release of IE7 was almost certainly prompted by the rapid rise of the open source browser, Firefox, and was notable for its failure to comply with W3C standards. Domminance of a market by a proprietary monopoly does not encourage innovation.
Throughout the European Commission's proceedings Microsoft claimed that the protocols were proprietary to Microsoft, and talked of protocols that were enclosed in a "blue bubble". Georg Greve, president of the FSFE explained: "The blue bubble was a theory that Microsoft invented in order to justify that it had kept parts of the protocol secret. They said that there's a difference between the internal protocols and the external protocols, if you want to describe them like that. They said that certain protocols that are so secret that they are in this blue bubble, because they had visualized this with a blue bubble, that this could never be shared without actually sharing source code, without sharing how the program exactly works. These protocols were so special that somehow, magically, you had to have the same source code to actually make that work. That was the blue bubble theory. So they said things like, 'HTML is outside the blue bubble, but the things you want us to disclose, that is inside the blue bubble.'"
In the wake of the decision, the US Assistant Attorney General for Antitrust, Thomas Barnett, made the highly contentious claim that the outcome, "rather than helping consumers, may have the unfortunate consequence of harming consumers by chilling innovation and discouraging competition," which drew a clear response from the EU competition commissioner, Neelie Kroes, that it was "totally unacceptable that a representative of the US administration criticised an independent court of law outside its jurisdiction."
In contrast, the American Antitrust Institute noted "the oddity of Barnett's statement" as both Europe and the US had found that Microsoft was "a monopolist which had acted to harm competition, and both insisted on interoperability in framing a remedy," and noted that "the EC has appropriately targeted strategies that would have the effect of deterring investment in innovations that might lead to a reduction of the monopolist's power and new benefits for consumers."
Talk is cheap
As the kerfuffle surrounding MS-OOXML demonstrates, the publication of protocols and data formats is not enough. To become truly universal, proprietary interest must be relinquished, and interoperability frameworks opened up to discussion, contribution and maintenance by third-parties through a neutral party (usually a standards body), and this is something that the European commissioners are beginning to understand.
As the MS-OOMXl kerfuffle has also demonstrated, such processes are highly political, and like the political process, can be influenced and misled.
But for the moment, Microsoft's tribulations in Europe are far from over. The Commission is investigating a complaint from Opera Software demanding that Internet Explorer comply with W3C standards, and one from the industry body, ECIS (European Committee for Interoperable Systems), in which Microsoft is alleged to have "illegally refused to disclose interoperability information across a broad range of products, including information related to its Office suite, a number of its server products, and also in relation to the so called .NET Framework.
The Commission's examination will therefore focus on all these areas, including the question whether Microsoft's new file format Office Open XML, as implemented in Office, is sufficiently interoperable with competitors' products."
In a press conference to announce Microsoft's latest fine, the EU competition commissioner, Neelie Kroes, emphasised that "a press release does not necessarily equal a change in a business practice. And if change is needed... then the change will need to be in the market, not in the rhetoric."
She also said: "There are lessons that I hope Microsoft and any other company contemplating similar illegal action, will learn.
. Talk, as you know, is cheap; flouting the rules is expensive.
. We don't want talk and promises, we want compliance.
. If you flout the rules you will be caught, and it will cost you dear."
Proprietary protocols are anathema to network computing and a deliberate hindrance to innovation and competition in computing environments. Few of the players, or users, maintain the illusion that a Microsoft-only world is either desirable or attractive - and the accusations of ballot stuffing, bribery, and undue political influence that surrounded the acceptance of OOXML as a standard by the ISO has only served to emphasise this reality.
Posted Richard Hillesley at 2:34PM, 24th April 2008
The 80s were the dog-eat-dog days of business. Top of the pile was Microsoft, the biggest and baddest of them all, led by Bill Gates, who invented the computer, the universe and everything.
Gates looked a bit like the nerd on the cover of Mad Magazine, made it to the cover of Time magazine, and was rich and successful beyond anybody's wildest dreams.
The view of Gates and Microsoft from inside the computer industry was more circumspect. PC software looked amateurish and nobody took it too seriously until the cultures began to collide in the business world during the middle of the decade. The affordable desktop computer, which sprang out of an unholy alliance between IBM, Intel and Microsoft, changed the face of computing in the home and in the work place, and for the most part was beneficial to the user, if only because it was cheap and accessible.
Microsoft always took more credit for this revolution than it probably deserved, but had a way of coming out on top, which owed everything to its early dominance of the operating system market for the IBM PC and its clones. From this dominance grew its prominence on the desktop, and the gradual eclipse of its competitors. The question that was always being asked of Microsoft was how much did the company owe its success to the quality of its software, and how much to the ruthlessness of its marketing?
From the beginning Microsoft had a special relationship with the original equipment manufacturers (OEMS), and made this relationship tell. Each innovation on the desktop, each new tool and the company that made it, either fell by the wayside or was assimilated into the Microsoft hive.
In the hive
Compaq had its arm twisted to stop it bundling Apple's Quicktime on the desktop. Internet Explorer, and later, the Windows Media Player, were bundled into the operating system, and given away free, sucking revenues and market share from Netscape, Real Networks and Apple. The squashing of Netscape and the subsequent death of the browser market led to Microsoft's conviction for monopolistic behaviour before the US antitrust courts.
Microsoft added platform-dependent "features" to Java to render Java's multi-platform features redundant, and when that ended up in court, developed the .NET platform, a very successful and popular alternative that reproduced many of the major features of Java with the notable exception of its multi-platform capabilities.
Kerberos, the encryption standard developed by MIT, was extended by Microsoft with the apparent objective of inhibiting interoperability in the workgroup server space and, in the words of Jeremy Allison of Samba: "these changes were treated as trade secrets, patented if possible, and only released under restrictive non-disclosure agreements, if released at all."
During the US anti-trust trials, Steven McGeady, a vice president of Intel, testified against Microsoft, Intel's most important trading partner, asserting that Microsoft intended to "embrace, extend and extinguish" competition by substituting open standards with proprietary protocols, and claimed that Intel had been warned to cease development of its Native Signal Processing audio and video technology, which promised to vastly improve user experience of the desktop - or else Microsoft would bypass Intel and develop Windows exclusively for AMD and National Semiconductor chips. "It was clear to us that if this chip did not run Windows it would be useless in the marketplace," McGeady testified. "The threat was both credible and terrifying."
Microsoft has always had an ambivalent relationship with the concept of interoperability and with the standards that make interoperability possible, tending to view the protocols and data formats it uses as "de facto" standards and "trade secrets" which it is free to "extend" with no obligation to share. This may not always be deliberate behaviour. Where there is a monopoly standards become incidental, an option rather an obligation. This tendency has been at the root of Microsoft's problems in the US and European courts. Microsoft is not being penalised for success, but for shutting the door on competition, and resisting any requests to modify its behaviour.
Into Europe
Microsoft's troubles in Europe began as early as 1993, when Novell complained that "onerous licensing conditions" imposed on OEMs by Microsoft was pushing NetWare out of the workgroup market.
In this market Novell had been the innovator, but Microsoft had muscled a napping, but still relevant, Novell out of the picture. Thus began a long history of litigation which culminated in the 17 September 2007 decision of the European Court of First Instance, which upheld the European Commission's decision to fine Microsoft and uphold the principle of interoperability.
The September judgement came at the end of a ten year case initiated by Real Networks, supported by Sun Microsystems, Novell and others, all arguing that innovative products were being pushed out of the market on the back of Microsoft's monopoly. Over the years each of these litigants withdrew from the case after doing deals with Microsoft worth billions of dollars, leaving the Free Software Foundation Europe (FSFE), the Samba Team, and their allies to fight the case to the finish.
As Jeremy Allison of the Samba Team told Groklaw: "the copyright in Samba is spread across many, many individuals, all of whom contributed under the GNU GPL 'v2 or later', now 'v3 or later' licenses. You can't buy that. There's nothing to sell. There's no point of agreement for which to say 'here are the rights to Samba, we'll go away'. We're in the, some would say unique, some would say unenviable position, of not being able to sell out. We can't be bought."
Much has been made of the Commission's insistence that Microsoft offer a version of Windows without Windows Media Player bundled, and the record fines imposed upon Microsoft. Improbably, some press coverage suggested that the European decision was a blow against innovation and competition. But the fines mean little more than a few pence on the price of Windows to a company as rich as Microsoft. The fines are a penance for Microsoft's prevarications and refusal to comply with the European courts.
The most important part of the judgement was the Commission's insistence that Microsoft be forced to publish the protocols used by Windows clients and servers under "reasonable" and "non-discriminatory" terms.
For this decision to have any meaning it was incumbent upon Microsoft to publish the protocols in their entirety, and to reflect the actual behaviour of Microsoft servers and clients in the real world - without evasion, inconsistencies, broken standards, obfuscations, fees or hidden patents - to comply with the commonly understood meaning of open standards and protocols as they have been implemented by other participants in the computing industry.
Microsoft has complied, with reservations, releasing protocols and data formats free for "non-commercial" use, (which immediately discriminates against competition), and making promises of future interoperability with its products. Unfortunately the promises have come with limitations, and the limitations target free and open source software.
As Thomas Vinje of ECIS, noted: "For years now, Microsoft has either failed to implement or has actively corrupted a range of truly open standards adopted and implemented by the rest of the industry. Unless and until that behaviour stops, today's words mean nothing."
Bursting the bubble
It is worth noting that once Netscape was trounced and Microsoft assumed the monopoly position in the browser market there was a five year gap of no innovation or competition between the release of IE6 and IE7. The subsequent release of IE7 was almost certainly prompted by the rapid rise of the open source browser, Firefox, and was notable for its failure to comply with W3C standards. Domminance of a market by a proprietary monopoly does not encourage innovation.
Throughout the European Commission's proceedings Microsoft claimed that the protocols were proprietary to Microsoft, and talked of protocols that were enclosed in a "blue bubble". Georg Greve, president of the FSFE explained: "The blue bubble was a theory that Microsoft invented in order to justify that it had kept parts of the protocol secret. They said that there's a difference between the internal protocols and the external protocols, if you want to describe them like that. They said that certain protocols that are so secret that they are in this blue bubble, because they had visualized this with a blue bubble, that this could never be shared without actually sharing source code, without sharing how the program exactly works. These protocols were so special that somehow, magically, you had to have the same source code to actually make that work. That was the blue bubble theory. So they said things like, 'HTML is outside the blue bubble, but the things you want us to disclose, that is inside the blue bubble.'"
In the wake of the decision, the US Assistant Attorney General for Antitrust, Thomas Barnett, made the highly contentious claim that the outcome, "rather than helping consumers, may have the unfortunate consequence of harming consumers by chilling innovation and discouraging competition," which drew a clear response from the EU competition commissioner, Neelie Kroes, that it was "totally unacceptable that a representative of the US administration criticised an independent court of law outside its jurisdiction."
In contrast, the American Antitrust Institute noted "the oddity of Barnett's statement" as both Europe and the US had found that Microsoft was "a monopolist which had acted to harm competition, and both insisted on interoperability in framing a remedy," and noted that "the EC has appropriately targeted strategies that would have the effect of deterring investment in innovations that might lead to a reduction of the monopolist's power and new benefits for consumers."
Talk is cheap
As the kerfuffle surrounding MS-OOXML demonstrates, the publication of protocols and data formats is not enough. To become truly universal, proprietary interest must be relinquished, and interoperability frameworks opened up to discussion, contribution and maintenance by third-parties through a neutral party (usually a standards body), and this is something that the European commissioners are beginning to understand.
As the MS-OOMXl kerfuffle has also demonstrated, such processes are highly political, and like the political process, can be influenced and misled.
But for the moment, Microsoft's tribulations in Europe are far from over. The Commission is investigating a complaint from Opera Software demanding that Internet Explorer comply with W3C standards, and one from the industry body, ECIS (European Committee for Interoperable Systems), in which Microsoft is alleged to have "illegally refused to disclose interoperability information across a broad range of products, including information related to its Office suite, a number of its server products, and also in relation to the so called .NET Framework.
The Commission's examination will therefore focus on all these areas, including the question whether Microsoft's new file format Office Open XML, as implemented in Office, is sufficiently interoperable with competitors' products."
In a press conference to announce Microsoft's latest fine, the EU competition commissioner, Neelie Kroes, emphasised that "a press release does not necessarily equal a change in a business practice. And if change is needed... then the change will need to be in the market, not in the rhetoric."
She also said: "There are lessons that I hope Microsoft and any other company contemplating similar illegal action, will learn.
. Talk, as you know, is cheap; flouting the rules is expensive.
. We don't want talk and promises, we want compliance.
. If you flout the rules you will be caught, and it will cost you dear."
Proprietary protocols are anathema to network computing and a deliberate hindrance to innovation and competition in computing environments. Few of the players, or users, maintain the illusion that a Microsoft-only world is either desirable or attractive - and the accusations of ballot stuffing, bribery, and undue political influence that surrounded the acceptance of OOXML as a standard by the ISO has only served to emphasise this reality.
Subscribe to:
Posts (Atom)