How much of my life’s been wasted dealing with problems caused by shared Web hosting hassles? I wish I could put a dollar value on it and collect it from the dozen or so companies that have promised me the world but delivered a minimally functional service that ultimately I cannot use. I’ll tell you about some of the hassles I’ve endured, but if you just want some quick advice, all I can say is this: Never use shared Web hosting for anything remotely important.
The most recent debacle happened yesterday, when the horrible shared hosting company that served up our JEM Electronic Media corporate site, our ad server, and our survey program, decided to spontaneously suspend our account due to resource over-usage. We have 250GB of transfer bandwidth to use every month, and we have never, on our best months, gone beyond 4GB of it. So imagine my surprise when I saw this warning message. I spent an hour and 15 minutes on hold before giving up on the support department and sending an email to ask that my account be cancelled. I found out later that the overusage had nothing to do with our shared account — someone else that had a shared account on the server was abusing it, but all of the customers on that server had to suffer for it.
Desperate to get our ads back online, I started an account with Verio, a Linux- and BSD-friendly hosting company I was familiar with from some interviews I did at SCALE 5x. It cost three times as much for the same level of hosting service, but promised better customer support and easier site management. I prepaid for a month, uploaded all of our site files, and configured our email accounts. Then I hit the wall — there was no way to upload our 14MB MySQL database. I had an SQL dump, which I usually upload from the command line, but Verio did not allow OpenSSH or remote MySQL access on my level of service. For that, I would have to pay another $10 per month, which brought the cost up to more than four times what I was paying at Omnis. Verio did have a tech support person on hand to talk to me immediately, but she said that the only way around the problem was to use a Web program to upload the SQL file, or upgrade the account. Verio provides phpMyAdmin, but that has a 2MB query limit — far short of the 14MB I needed. The tech told me that there were probably other programs I could use, but they were all for Windows. Having again spent way too much time messing with stupid limitations and technicalities, I asked to cancel my account. Unfortunately, Verio only has tech support people working on Labor Day — no customer support people — so I’d have to call back another day. It turns out I didn’t have to, because a very friendly man from Verio called me today to ask how he could help sell me some extra business services that I didn’t need. I wish I’d recorded the call, because the dramatic change from superficial friendliness to disgust and disinterest was comical when I told him I wanted to cancel my account.
These are only the latest nightmares from the land of shared hosting. I’ve been through it all with other shared hosts that Netcraft has consistently given top reliability ratings to. iPowerWeb had a “too good to be true” hosting plan, but our Web server went through between two and four hours of weekly downtime for reasons unrelated to the software we were running. HostNuke rudely told me that I could not run my own mail server because they didn’t want their customers spamming people. There are a bunch I don’t remember the names of, all of which were unreliable or offered “unmetered” bandwidth with hidden limitations. I went with one company that had an OpenBSD shared host, but the hardware was so weak that the traffic from one of my articles making it to the front page of OSNews brought it to its knees. I hosted on one shared server that seemed perfect, until one of the other people I shared the server with decided to send out spam, which resulted in our shared SMTP server being banned, and the hosting company refused to move me to another server to remedy the problem.
After the Verio disaster, I ended up moving our corporate site and database over to our main server where the rest of our sites are. I would prefer to have the ads and surveys on a separate server, but it’s just not going to work right now. Presently I’m waiting for the DNS cache to switch to our name servers. This means we’ve been without ads for more than a full day, all because of bad service from shared hosting. I had great experiences with a rented server from SevenL, and someday I hope we make enough money as a company to farm out all of our hosting to a customer-centric company like Rackspace, but for now, the only host I can both trust and afford is myself.
Recently a Linux kernel developer tried to relicense an OpenBSD network driver under the GPL, but was caught early in the process and the error was properly addressed with public rebuke. In an unrelated incident, the vice president of the FreeBSD Foundation reiterated in a statement in his August newsletter that open source software as originally and traditionally exemplified through BSD operating systems, and free software as presented by the Free Software Foundation, are not the same thing. Both OpenBSD Project and FreeBSD Foundation representatives separately addressed the same issue: dealing with reality. It’s not an issue for BSD people though — they’ve been dealing with reality for years. It’s really more of a problem for GPL supporters.
“GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope — the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time. But once the code is GPL’d, we cannot get it back,” said OpenBSD Project leader Theo de Raadt in response to the attempted unauthorized re-licensing of BSD driver code. Indeed, the notion that the BSD license allows people to “steal” code and use it in proprietary programs without any compensation or reverse-contribution has been frequently asserted in the perpetual GPL-versus-BSD arguments on the Internet. But when did the BSD license, or anyone who ever licensed code under it, lament that fact? Reality shows that commercial use of BSD-licensed code doesn’t bother anyone in the BSD community. That doesn’t mean there hasn’t been some reluctance to donate money to the BSD projects that commercial entities rely on, but that’s not a problem that software licenses are meant to address, it’s not specific to the BSD license, and GPL-licensed projects face the same challenge.
The argument that BSD code can be “stolen” and used commercially seems more like a self-fulfilling prophecy for GPL proponents, to whom this practice is the ultimate horror. It almost appears to be an element of sanctimonious antagonism, as though the GPL-relicensers are trying to teach the BSD people a lesson by attempting to exploit the freedom of the BSD license. This sounds familiar, doesn’t it? Your code is free to use? Hah! Well I’ll show you what a foolish thing that is!
Justin Gibbs of the FreeBSD Foundation wrote something truly brilliant about dealing with reality in August’s Foundation newsletter: “A GPL proponent might argue that a license for free software must be upgraded periodically since we cannot anticipate what new use models for free software might be developed that restrict freedom. The BSD license is as permissive as possible exactly because we cannot predict the future or to what beneficial purpose (commercial or otherwise) our software will be used.”
So on the one hand we have the FSF trying to change reality through restrictive software licenses; and on the other we have the BSD license, which deals with the mercurial nature of reality just as it is. One assumes that freedom needs to be defined in order to be valid, and protected through multiple convoluted restrictions; the other assumes that freedom finds its own personal definitions for all of us, and only requires that you not remove the author’s copyright notice or the license statement from the code. If there were a Taoist here, he might say that software licenses, like human beings, enter this world warm and soft, and leave it cold and hard.
I’ve always resisted the urge to blindly bash Microsoft — indeed it does make a few really nice products, and has had a positive impact on the computing world in some important ways. I also have to try to maintain a neutral stance on computer products that I intend to review, with the understanding that a product’s quality and a company’s behavior speak for themselves. Today I’m writing about something that all computer users need to be aware of, and Microsoft’s at the forefront of the effort that goes against user interests. Specifically I’m referring to Microsoft’s crusade to convince the International Standards Organization (ISO) to adopt its proprietary Office file format as a standard. If Microsoft wins this, we all lose.
No matter what your word processor situation is, you have at some point in your life experienced file format compatibility problems. Even if you only use Microsoft Office to create and read documents and you upgrade to each new version the minute it’s released, you’ll still run into problems sending Word or Excel files to other people who don’t have the latest version. More likely, you have an older version of Office that works well for you, but you can’t read files created with newer versions of Word, Excel, or PowerPoint. Maybe you’re one of the few and the proud who understands the superiority of WordPerfect or TextMaker, or you’re using the free OpenOffice.org or its commercial counterpart StarOffice. If you use one of these suites instead of Microsoft Office, then you already know the hassle involved with file format conversions.
If Microsoft wins the ISO standard war (and it’s trying really hard — it’s forcing or paying off its customers to flood ISO meetings with favorable votes), the file format problem has no hope of going away in the forseeable future, and in fact it will get worse as time goes on. Making Office Open XML (OOXML) the official ISO document format will encourage government agencies, corporations, and schools to standardize on it, which will more or less force them to buy MS Office 2007. The worst part, though, is that if these things come to pass, you too will be required to buy Office in order to exchange documents with these entities. In effect, the problem will be a lot more severe, because OOXML files created in one program could display differently in other programs.
The big problem with OOXML is that it is impossible to uniformly implement. Microsoft did not publish the entire standard — only the “required features” of the standard — so it’s not only possible, but according to history it is an absolute certainty that OOXML documents created by OpenOffice.org or WordPerfect will not work properly in Word, and vice-versa, because Microsoft will implement hidden portions of the standard. Secondly, much of the OOXML standard is left to application-specific rules and procedures. This means that similar features in different programs can write their OOXML files in different ways, essentially making them incompatible. Tactics like these are old hat for Microsoft; it is not the first time it has released specifications in the outward interest of compatibility with competing software, only to turn around and make its own products the only ones that work properly by taking advantage of hidden or undocumented and secretly required features. If you’re at all like me, right now you’re wondering how in the hell something this non-specific and nebulous can possibly be considered a “standard.” Standards are supposed to be static, thoroughly documented, and well-understood by everyone who needs to implement them. OOXML cannot be considered static, only part of it is documented, and it is impossible to understand it completely when parts of it are secret.
We already have an industry-accepted ISO standard document file format that is completely open and free to fully implement — OpenDocument. Microsoft’s effort to push OOXML through is nothing more than a ploy to force more people to buy Microsoft Office (and by extension, Windows Vista).
Last week Metaweb announced that its open information database, Freebase, had gone into public alpha, meaning you no longer need a registered account to access Freebase. Half the reason I know about this is because I wrote some documentation (it’s an O’Reilly Short Cut PDF, but you can download it for free) for Freebase developers a few weeks ago. It’s really quite an interesting service — kind of like Wikipedia, only in the form of a graph database.
Frankly, I don’t understand the concept of “public alpha” — I think the term “alpha” in software development belongs more to marketing and PR than it does to programming. If something is still in the alpha stage, it’s under active, volatile development, so it’s not ready to be used on a critical basis. In this case, the term does not properly apply to Freebase in its current state — it’s perfectly usable and you can start accessing, modifying, and building applications for it right now.
Freebase is an online, publicly accessible graph database (as opposed to a table-based relational database). Much of its data is Creative Commons content from other online information sources like MusicBrainz and Wikipedia, but Freebase’s users are slowly refining what’s there and adding more information as time goes on and the registered userbase expands. As of this writing, you still need to be registered with Freebase in order to modify or contribute. Registration is handled on an invitation-only basis; if you’d like a Freebase invite, email me at jem at thejemreport.com and I’ll send one out to you if I have any left.
For many years I’ve lamented two fundamental problems with software: that it doesn’t have features I really want, and that it doesn’t work the way it is supposed to. In other words I’m talking about a lack of appropriate features and a surfeit of bugs. As the era of open source software is slowly ushered in, and the era of proprietary software slowly wanes, I see the two different programming and licensing philosophies more dramatically exhibit these two fundamental problems, each to its own weakness. Neither of these philosophies is ever going to be enough to create truly great software. I wonder what the perfect licensing, distribution, and development model will be, assuming it has not been invented yet.
With open source software the traditional fundamental problem has been a lack of features. A program might almost do what you need it to, but not quite provide the same level of functionality that a proprietary alternative does. Likewise, in the height of the proprietary software era in the 1990s, a program might have all of the necessary features, but crash at inopportune times or only work under a certain set of conditions. Today those roles are totally reversed — most of my extensive experience with open source software on both desktop and server systems has elicited piles and piles of bugs and problems, nearly all of which are fixed for no cost in a reasonable amount of time. Likewise, proprietary software has increased in price and is delivering less interoperability with other software, less compatibility across different versions and platforms, and fewer features that in my professional opinion are necessary for the target userbase.
The traditional open source business model is to give the software away for free, but to charge for various services — installation support, paper manuals and pressed CD/DVD media, telephone technical support, bug fixes and other software updates on demand or as part of a subscription service, and custom software development. The “product” here is not the software (whatever it does), but the amount of responsibility and interactivity the company that distributes it provides. Seems like a great idea until you consider the fact that the company is never financially compelled to produce a technically perfect product — such an application would never need the associated services that the company charges for.
On the other hand, you have proprietary software that you pay a large one-time fee for. You might get a minimal amount of included support over a short period of time, and you might get major bug fixes for free through service packs and patches, but you won’t get the same level of service that you’ll get through an open source company. Certainly you can pay a lot more to get a little extra service, but it’s not the same. Proprietary software companies are built on the traditional “physical goods” philosophy that you make a great product and sell it as such. Windows is Microsoft’s best attempt at producing an operating system that it hopes you will be compelled to buy. But what about a company like Canonical or Red Hat? They are not financially compelled to produce a superior product — instead they aim for superior services.
Neither of these models is going to succeed in the long run. Once you’ve created the best product imaginable — as Adobe has done with the majority of its creative tools — it is very difficult to continue making money off of future upgrades. Macromedia Studio MX was the apex for Flash, Dreamweaver, FreeHand, and Fireworks, but there have been three upgrades since then. Each upgrade adds little things, but costs hundreds of dollars. Gone are the days when new versions brought huge, disruptive changes in proprietary desktop software. This model is not financially viable over the long-term, but as a user, at least I have the satisfaction of knowing that I’m buying someone’s best attempt at producing a great product. I rarely get that impression with open source software. I don’t think the ultimate design philosophy has been invented yet; I very much look forward to experiencing it, though.
While researching the details of the new Adobe Creative Suite 3, I discovered an Adobe employee’s long list of reasons why CS3 is not 64-bit. Some of them are valid, but when he regurgitated the tired old argument that compiling a program for a 64-bit environment does not make it faster, I had to wonder if he’s just making up excuses for code quality problems.
Compiling a program for a 64-bit environment dramatically increases its performance in any kind of filtering, sorting, encoding, or encryption operations. I’ve proven this in the past (more than once, actually). Almost every program in Adobe Creative Suite 3 does at least three of these four memory-intensive operations and would benefit in some way from being recompiled for 64-bit Windows Vista.
Another lame excuse the Adobe guy came up with was that 64-bit Windows Vista has poor driver support. What does that have to do with Creative Suite 3? And since when has poor operating system quality stopped Adobe from releasing software for that platform? Heck, Adobe itself isn’t afraid to release poor-quality software — I recall my first month with Dreamweaver MX 2004 being riddled with crashes and a few non-working features, and how many times has the Flash Player plug-in crashed your Web browser? Strange how Adobe is suddenly so concerned with operating system quality and driver support when the company has repeatedly chosen to ignore the desktop and workstation operating system with the broadest native hardware support — Linux.
One of the valid reasons the Adobe blogger lists for a lack of 64-bit support in Adobe products is the assertion that the company can’t afford the cost to test or distribute a separate 64-bit binary. The challenge introduced by supporting two operating system platforms that offer different bit-ness is also a valid and appropriate concern. But please, Adobe blogger, don’t tell us that there’s no performance advantage and that Vista 64-bit isn’t good enough for you. In the recent past, people like this were hawking similar absurdities about multi-CPU and multi-core desktop processors, but today it’s impossible to find a desktop OS that isn’t configured to take advantage of multiple CPU cores. As of this writing it is extremely difficult to buy or build a desktop computer that does not have a 64-bit instruction set ala AMD64 or EM64T. How much longer do we have to deal with poorly programmed “all the world is x86″ software?
The editor in chief of PC Magazine announced his departure last week, coupled with an editorial on his turnaround of opinion on Windows Vista. A longtime friend of his told me (and publicly wrote the same) that this is a significant change of opinion — that this editor had been in love with Windows since version 3.0, and it would take a lot to break that affection. I’ve been trying to find the brighter side of Vista since I first started testing it, but no matter how hard I try, I keep coming to the conclusion that Windows Vista just is not worth the money to buy, or the trouble to use.
I have to use Vista about once a week on average, almost always so that I can test some new desktop application. Lately it has been the new Adobe Creative Suite 3, so I’ve had more seat time with Vista lately than I’ve had since I wrote the Windows Vista review for Software in Review. Right now I’m working with the 64-bit edition to see if I can gain a better understanding of all of its problems in comparison to the trouble that Linux and BSD operating systems have in 64-bit mode. So far, my conclusion is that Vista has many more (and more visible) problems than any other 64-bit AMD64/EM64T operating system I have used recently. Vista is in the 64-bit stone age — it has driver problems that BSD and Linux OSes have not had since the first generation of the Athlon 64 and Opteron were new. I have a Diamond sound card in the Vista test system that does not work under any conditions because Diamond won’t write a Vista driver, and Microsoft doesn’t have a generic sound driver that will work with it in 64-bit mode. Linux does. FreeBSD does. Heck, I think OpenBSD does too.
Every time I use it, I keep thinking that I’m going to like Vista this time, even though it’s done nothing but frustrate me every other time I’ve used it. I think years of Linux and BSD customization has instilled in me the sentiment that if the software isn’t working as intended, that it is probably my fault somehow. I haven’t read the instructions, or I’m not changing the right options, or there is a problem in an area that I am not considering. This is how it was with DOS, and to a large extent Windows 95 and 98 (networking aside), but with Vista there is no longer enough room for user error to assume that you are the problem. Vista’s design is such that if there is a problem with the way the system is operating, you are not empowered to find out what is causing the trouble, nor are you able to fix it. Instead you’re trapped in a maze of automatic wizards with too few options, and nondescript warning messages that are unable to help you with anything.
My father’s opinion mirrors mine. He bought a new laptop computer with Vista preloaded on it, and liked “that new Vista” at first. After a few weeks of frustration and neverending network problems, he called and asked how he could get rid of it and put XP on the machine. He, too, would like to switch to Linux, but he needs some really expensive proprietary hardware control programs that only work on Windows and don’t operate correctly through a virtual machine. It really sucks when vendor lock-in extends well beyond the product a vendor sells.
The former PC Magazine editor’s solution was to switch back to Windows XP and think about switching permanently to Linux. Going back to XP is a temporary necessity, but switching to Linux is a long-term necessity for any technically able user who needs more that just “Web and email” in his desktop computing life (proprietary industrial hardware control and analysis software aside). Windows Vista really is that awful that switching to a dramatically different operating environment is a serious consideration.
There is a vast body of computer software that can no longer be used on modern computers and operating systems. Some of these programs are still great, even by today’s higher standards. As time goes on and companies forget about their old products, or are bought out by larger corporations that abandon unusable assets, we will reach a point at which the greatest desktop software ever made is no longer usable.
Though this topic has been on my mind for years, it came up again recently when I discovered that a program that I thought was great — Macromedia Freehand — is being killed off in favor of Adobe Illustrator. Freehand fans have known this since Adobe’s acquisition of Macromedia many months ago, and I was peripherally aware of this fact, but it didn’t really hit home until it was time to review the new round of Macromedia tools. I’ve got Illustrator CS3 here for review, but I haven’t gotten to use it yet and don’t yet know if it’s truly a replacement for Freehand. I suspect that it isn’t; Freehand was a vector drawing tool that focused on aiding Web page design. All of the programs in the Macromedia Studio suite were designed at their core to be about creating content for the Web. Illustrator, on the other hand, has always been focused on being a great vector graphics program with a slight bias toward print media. Both have their merits, and I would expect fans of each to say that their favorite is the superior program. Killing off Freehand won’t make people like Illustrator, though, especially if it does not have the same functionality. Removing Freehand diminishes the usefulness of both Flash and Dreamweaver, particularly for people who were used to using the whole Macromedia suite to design Web sites.
You can’t write an article about dead software without mentioning BeOS. I wasn’t into Be systems when the company was still alive, but ever since I saw the open source Haiku rewrite of BeOS for x86 machines, I’ve been convinced that this is a superior desktop operating system design. It is not a hodgepodge of various open source programs like Linux, nor is it a hodgepodge of various proprietary programs from a variety of different companies like a Windows environment generally is. Its modular design keeps BeOS from being a huge and unmanageable project like FreeBSD, and gives it security and stability that Apple OS X can’t ever hope to match. Be, Inc. was killed off by both Microsoft and Apple through separate means, and its software assets were sold to what was PalmSource, or what is now known as Access. Presumably Access still has the BeOS source code someplace, but won’t give it out to anyone — or even license it out to companies that want to sell updated versions. Rumor had it that Access was going to use the old BeOS code in a new mobile device operating system, but it appears as though those plans were cancelled in favor of a Linux-based solution. So what will become of BeOS? Access won’t answer any media inquiries about BeOS, so we may never know… except to honor it as another inhabitant of the proprietary software graveyard.
Near and dear to my heart are the old Sierra On-Line PC games. This was the company that defined and pioneered electronic role-playing adventure games. They had an idea for a MMORPG that predated World of Warcraft by several years, but never found a way to build the infrastructure to support it. Sierra also had the first graphical online gaming service called The Sierra Network, but though it was popular, it was not profitable. There were so many tragedies at the old Sierra On-Line that a technophile could not hear them all in one sitting without shedding a tear. The greatest among these misfortunes was that Sierra went public, was bought out (eventually) by Vivendi/Universal, and killed off the adventure game genre. All those old DOS games are lost to history, their adventures and stories confined to past-EOL floppy disks and abandoned 20MB hard drives.
It didn’t have to be this way — these companies could have released the source code for products that they never intend to use again, allowing the people who paid between $20 and $60 (in 1980s money) to continue to enjoy the products they purchased beyond their initial limitations. The proprietary software graveyard does not have to exist, but it does exist, and continues to grow because of the senseless selfishness and blindness of a few ignorant software corporations.
Now that The SCO Group’s Linux lawsuit has been gutted due to a ruling that says Novell owns the Unix copyrights, I bet the companies that paid protection money to SCO for proprietary Linux licenses and Unix rights (Sun Microsystems, EV1Servers) have that “I’ve been robbed” feeling right now.
The first and only name that comes to mind when considering the topic of buying SCO’s Linux licenses is EV1Servers. Here’s the official SCO press release on the matter. In short, EV1Servers bought Linux licenses for its Linux servers. The immediate reaction from EV1’s clients was disgust, and several of them cancelled their hosting agreements and moved to other service providers. The EV1Servers CEO, Robert Marsh, publicly regretted the deal soon after he finalized it, though it’s likely that he was more concerned with losing customers than with saying no to SCO’s baseless request for license fees.
If SCO did not own the Unix copyrights and there was no Unix code in Linux, then is EV1Servers entitled to a refund? Sadly, no, because the license agreement stated that refunds are no possible under any conditions — including the possibility that SCO doesn’t own any code in Linux. That wouldn’t necessarily stop EV1 from suing to get their money back, being that the deal was made under false pretenses, but somehow I doubt Robert Marsh will pursue it.
A few years ago I interviewed Scott McNealy, then-CEO of Sun Microsystems, at the Solaris 10 launch event in San Francisco. Though the article I wrote was long and covered many subjects, here’s a passage from it that is relevant to today’s discussion:
“What proprietary code had to be taken out of Solaris in preparation for open sourcing it?” McNealy responded by saying that the process of open sourcing Solaris actually started five years ago. “There were hundreds of encumbrances to open sourcing Solaris. Some of them we had to buy out, others we had to eliminate. We had to pay SCO more money so we could open the code — I couldn’t say anything about that at the time, but now I can tell you that we paid them that license fee to expand our rights to the code,” he said, referring to the February 2003 multimillion-dollar purchase of expanded Unix SVR4 license rights from the SCO Group.
If SCO did not own the Unix copyrights, then what did Sun pay for? Will Sun get its money back from SCO, and then pay it to Novell for the same rights? What will become of Solaris if it contains code that was licensed under the OpenSolaris CDDL when in fact it actually belongs to Novell?
The longer the SCO debacle continues, the more of a mess it becomes.
You should already know that electrostatic discharge (ESD), more commonly referred to as a static shock, will damage sensitive electronic components. The parts most sensitive to ESD are those that contain memory chips. In the computer industry, ESD is a major concern because nearly every part contains some kind of extremely ESD-sensitive component. The way computer parts are made, shipped, installed, and handled may change with the introduction of an interesting new anti-ESD technology announced this week.
The anti-ESD solution in question is called eESD, and was designed by Sanmina-SCI, a California-based PCB company that specializes in PCB manufacturing technology and services. Theoretically eESD could be integrated with just about any electronic component, and is already being implemented in cellular phones and one particular brand of DDR2 memory modules.
eESD’s tested limitation is 6000 volts, which is a fairly mild static shock. Those of you who live in cold climates know the pain of getting up off of a fabric couch, walking across a rug, and getting whacked by a painful shock from the television when you press the power button. The voltage of a shock big enough to hurt could easily reach twice the eESD tested limit, so this is not going to stop all damage from all kinds of shocks. As many electronics technicians already know, though, the shocks you need to worry about most are the little ones that you can barely feel.
Usual ESD precautions involve storing components and parts in Mylar bags or other static-safe or uniformly conductive packaging, wearing wrist or ankle straps that keep you grounded (so that you don’t carry a static charge), anti-static handling gloves, grounding mats, and metal blocks that you can touch to ground yourself on before touching components or circuit boards. The “poor man’s” solution is to simply touch something that is grounded, like a refrigerator, metal desk, or metal shelf, before you handle computer parts. These precautions will probably exist long into the future, even if eESD becomes ubiquitous. Still, it’s nice to have that extra degree of safety built in.
