In this section I'll discuss my philosophies regarding various technological issues and directions. In many of these cases, I've posted much more detailed positions and supporting arguments to various mailing lists I participate on, but at least here I can summarize my feelings on these topics.
You might well ask why I don't have more pretty graphics in my WEB pages.
The answer, quite simply, is because I hate having to sit all day waiting while huge graphics files are transmitted across the phone line, just to make a menu or a page of information (which I'm usually going to leave in a matter of seconds anyway) look "prettier". I don't dispute the utility of pictures and large files, so you'll sooner or later (if not already) be able to download pretty pictures and software through my Web pages too. But I don't think you should have to get these bulky things unless you darn well want them!
The Web is not WYSIWYG. HTML should not be treated as a desktop publishing medium or as a page layout language. Different users will have different screen color depths, different monitor resolutions, different window sizes, and more. There is no reason good enough to try to specify absolute fonts and point sizes, text colors, backgrounds and other bulky and useless nonsense which does nothing to improve the information content of a Web site. More often, this garbage makes it harder to read the site and drives visitors away.
As for cookies, that's another annoyance. I don't see any possible reasonable justification of some cookie that I get (just because some Web site showed me a stupid banner ad!) not expiring before the year 2029!!! I think users ought to simply (1) refuse to accept cookies, and (2) refuse to patronize Web sites which [ab]use them. It is ludicrous for some Webmaster to assume that I want his garbage lying around on my hard drive for more than thirty (!!) years!
A lot of this silly stuff really hurts Web sites that use it. Not only does it delay downloads and bog down the Web server (and the whole Internet) with useless bulk, but much of it also works like a brick wall that blocks lower-level exploration of a Web site by the search engine spiders. Thus, much of the abusing Web sites never get indexed by the search engines, and that makes it harder for users to find the Web site (more on this topic in a moment).
I very much dislike these stupid and bulky animated GIF files, graphical-text headers, mostly-useless graphical menus where text menus would work better, annoying cookies, navigation by dropdown selection boxes, and Java nonsense. You won't find any of that crap on my Web page.
This section is from a comment I posted to Andover News Network's Web site in November 1999.
I think it's amazing how so many Web site designers shoot themselves in the foot by designing overly complicated, browser-specific Web sites. The point of visiting a Web site (ESPECIALLY on a RETURN visit) is to get to the information that's available there. Anything which impedes or delays that is going to encourage the user to go somewhere else instead.
The other thing that I think is really comical is the use of DHTML, dropdown boxes, database search schemes, graphical menus, and the like. All of this nonsense builds a brick wall that search engine spiders cannot get past. For example, let's say you are online selling repair parts for a Sturmey Archer bicycle rear hub model 10-330ZA (among the ten thousand other items you carry). A user is very unlikely to find your Web site if one must enter "10-330ZA" at your own Web site's search engine in order to find the parts he wants. And certainly AltaVista's or Magellan's search engine spiders will never enter "10-330ZA" into that box so they can index the page of parts you sell for that particular bicycle hub.
If instead you build simple, fast, ordinary static Web pages with ordinary links to them (perhaps with the aid of an automated Web page generator), most of these Web search engines will gladly index (in detail) your entire Web site and every part number you stock. Customers (and potential customers) entering that part number into their Internet search engine of choice will get dropped right smacko into your Web page showing them immediately that YOU have *exactly* the related parts they're looking for.
Instead, most companies MIGHT indicate (maybe in a meta tag or something) that they sell bicycles and parts. Then when you get to the entry page you have to try to figure out the site-specific way on that individual site to see if they have what you're really looking for. (And you get to compete for the buyer's attention with all the other shops also hawking bicycles and parts...) I
I think you're going to eventually see more enlightened Web designers who realize that you don't HAVE to use an HTML/XML/whatever feature just because it exists (somewhere). Far better, I think, to use the *minimum* subset of HTML which will serve your LEGITIMATE BUSINESS purposes.
The goal is generally NOT to show off the (dubious) skills of an overly ambitious, show-off-mentality Webmaster.
On my own Web page, you'll find NO backgrounds, NO font colors, NO weird typefaces, NO singing/dancing animated GIFs, NO graphical menus. What you will find is a site where the graphics that ARE there are there for a reason. (And one of those is a small banner link to the "Best Viewed with ANY Browser" campaign, which I am proud to support!)
This section is from a comment I posted that got published to TalkBiz News in December 1999. I've made a few minor editorial changes from the version as published.
There's another all-too-common way that electronic businesses shoot themselves in the foot... and that's their seeming fascination with HTML-burdened E-mail.
It seems that a lot of businesses think it's somehow "cute" or "cool" to send people needlessly large E-mail laden with bulky and annoying HTML tags. Of course, this presumes that the recipients are using what amounts to a Web browser to read their E-mail.
While HTML is fine on Web pages (where it belongs) it does NOT belong in E-mail... which is supposed to be the UNIVERSAL, cross-platform mechanism on the net that allows **everybody** to communicate no matter what software and hardware platform they are running.
HTML tags typically increase the size of E-mail to 2.5x to 3.5x bigger than it ought to be. This reduces a typical 56K modem to effectively about 14.4K, and wastes disk space and other resources all along the E-mail distribution channel. It can cause the recipient's incoming mailbox to fill up several times faster than it otherwise would (especially if someone is away on holiday or business for a week or two) and thus make other urgent E-mail bounce or be refused.
HTML in E-mail is largely a power play on the part of a few companies who produce Web browsers, hoping to thus monopolize the market for E-mail software and put the non-Web-browser E-mail software companies out of the business. This is repugnant and offensive!
HTML tags in E-mail create difficulties for those who receive and read their E-mail by alternative mechanisms, including (this is not an exhaustive list):
It also creates problems when people unwittingly submit such HTML-burdened messages to mailing lists in digest form. Many E-mail programs don't deal well with a single E-mail which contains many attachments (and perhaps in different encoding methods) which are sprinkled throughout the file (rather than clustered at the end, as is traditional).
If someone really has to distribute information in HTML, then they ought to simply put it onto their Web site and then just E-mail folks a link to that Web site.
It doesn't help at all that Microsoft makes the sending of these obnoxious HTML-burdened attachments the default for at least some versions of Outlook and Outlook Express. :-((
Basically, HTML-burdened E-mail ought to be avoided altogether (and all outbound messages sent as 'plain text'). Otherwise, it ought to be sent ONLY after giving each recipient the option of whether they want HTML-burdened E-mail or the more efficient plain-text kind (and please, no negative-checkoff options. The plain text mode should still be the default).
Another issue, quite apart from whatever software the recipient uses to read HTML-burdened E-mail, is the fact that the extra bulk of such E-mail makes the recipient's E-mail Inbox fill up and overflow three or four times sooner than it would otherwise. I returned from a recent business trip (away just nine days) to find that my 10Mb E-mail Inbox as provided by my ISP was overflowing and my E-mail bouncing. This means cancelled subscriptions to newsletters and mailing lists, and lost potential new client inquiries. None of those are desirable.
There's also a privacy issue involved. HTML-burdened E-mail can contain viruses and malicious scripts, as well as "Web bugs" which try to "report home" to unscrupulous companies like DoubleClick and others which traffic in a person's private information that they haven't realized they gave out to others. There's an interesting article about the nasty implications of this issue in the NY Times.
In addition to the privacy issue, there's also the inappropriate issue of such "Web bugs" in that they try to connect to the Internet when you aren't otherwise (and don't particularly want to be) online. An example: being on an airplane at 30,000 feet and reading your E-mail on your portable computer. Obviously you're offline. You open an E-mail, and suddenly there's your machine trying (obviously unsuccessfully) to dial in to your ISP... just because your incoming E-mail contains a Web bug, a stupid banner ad, or some other HTML burden that directs it to go online to download something. (And if you're in Europe or some other foreign country where you get billed for local calls, that attempt to go online could easy cost you a connection to your ISP, just because the person who sent you that thoughtless HTML-burdened E-mail thought it would be cool to snoop on their [once-] customers.
Click here to read another letter I sent on this same topic, this one to Dr. Ralph F. Wilson, publisher of Web Marketing Today.
When you get HTML-burdened E-mail... COMPLAIN to the company that sent it to you, and make sure you let them know that you absolutely will not do businesses with companies that send offensive, bulky and obnoxious HTML-burdened E-mail to customers.
I've spent a lot of time attending CeBIT, the huge German computer trade show. An incredibly large show (over 700,000 attendees in 1995), one amazing thing is how FEW booths have anything truly innovative and interesting and new on display. The great majority of the booths are companies with "me too" products, rather than innovative and new things. In an industry where the advances of technology are coming so quickly, there are new market and product opportunities just laying all over the ground. It's truly curious that more companies don't lean down and pick up some of those, rather than trying to create artificial market differentiation (with increasing difficulty) and ending up building the same kinds of things as everybody else.
Even companies with a history of tremendous innovation and technological progress, such as Polaroid, often end up losing their innovative spirit (at Polaroid, this seemed to be with the departure of Dr. Land). And those companies that DO have interesting and innovative products often so drastically overprice them that their products either stay a profitable "niche" product, or fade away entirely, rather than achieving the growth and critical mass in the marketplace needed to guarantee them a long-term market presence.
In the "bad old days" of computing, every different manufacturer of computers made their own different kind of computer system, and the software made for one computer wouldn't run on another. The economic realities of LSI chips has put most of those proprietary-CPU computer companies out of the business, and today just about anybody can buy software far better than ever existed for the old-fashioned proprietary systems. And that nearly-universal software can be found shrink-wrapped on the shelves of neighborhood stores at ridiculously inexpensive prices.
Unfortunately, some of the companies that long for those old, high-margin proprietary-machine days are still trying to find an excuse to sell proprietary-hardware systems. And the whole "Network Computer" movement is based on that.
The premise supposedly is that Network Computers will somehow reduce the cost of user computers. In practice, however, Network Computers (at least those offering comparable service levels) are unlikely to cost significantly less to build than a full-fledged PC does. The monitor, keyboard, power supply, memory, sound circuits, hard drive, floppy, CD-ROM, mouse, display controller, and other equipment is virtually the same cost, regardless of what kind of CPU is going to be present.
Consider the following system, which local Micro Center stores are selling as of this writing (December 1997) for just $499.95:
(And the prices have come down and the capability gone up since then… Today (December 1999) you buy a full-fledged PC that's 2.5x faster, twice the main memory, four times the disk capacity, a CD-ROM drive more than three times faster, a 56K modem and a more capable display card, and even more bundled software, for another hundred dollars less).
Basically, the system contains everything most users will need other than a monitor and maybe a LAN card. Plus, it contains a quite substantial local computing capability. Why concentrate computing requirements onto a "compute server" somewhere else? That's simply a stupid concept, a throwback to the days of timesharing systems and "mainframe think".
The only real advantage of something like the Network Computer comes from having shared installations of major applications, rather than having to maintain separate installations locally configured on each user's machine. (In the old Novell days we used to be able to do this, but Windows software applications tend to complicate installations, as much as anything on purpose as a way of discouraging 'software sharing'). But if this software/applications problem is fixable for NCs, it's also fixable for PCs too.
I find it truly amazing that so much effort is being put (late in 1999) into "Terminal Servers" and turning these ultra-capable PCs into simple dumb (graphics notwithstanding) terminals. Now that computer power is getting so incredibly cheap, it's not surprising that some people seeing the opportunity will try to get people to pay forever to 'rent' it. But it's just as dumb for anyone to fall for the ruse. I believe that, much like the "Network Computer" concept of two years ago, this braindead attempt to return to the bad old days of timesharing and "mainframe think" will soon be recognized as for the most part the idiotic idea I think it is.
There is increasingly an awareness among people that it's possible to send voice across the Internet. While this is an interesting demonstration project, the fact is that the worldwide Internet backbone simply isn't designed to offer "demand bandwidth", guaranteed delivery, or even guaranteed availability at guaranteed delays.
Sending "Internet Phone" type calls for "free" across the Internet comes at a cost, and a lot of that cost involves unpredictable (and often unacceptable) quality levels.
While it may well be that packet voice is practical in particular cases (I tried to convince Datapoint to support packet "telephone" voice calls across ARCnet, back in the early 1980's as an alternative to their classic-centralized-switch "Infoswitch" product approach) I'm quite unconvinced that there is a serious long-term business opportunity to be had based on sending "free" telephone calls across the normal Internet. Part of the problem is that sending calls through TCP/IP via an Internet Service Provider uses more resources within the telephone network than a normal long distance call does. Therefore, after all the dust settles, it eventually is going to cost more than a regular long distance call does.
One can't argue, however, that the capability is going to force a substantial change in the way that long distance telephone calls (and particularly international ones) are tariffed and sold.
Every so once in a while, someone in the computer business comes out with a new programming language which is supposedly going to change the world (or at least transform the programming business). Everyone talks about it, the trade press has a field day, early adopters begin highly ambitious projects, and the bandwagon sets off moving, always to great fanfare.
The fact of the matter is that most of these bandwagons grind quickly to a halt, and in some cases carry their riders to commercial oblivion. Some of the previous fad programming languages (most of which have at very least not lived up to their hype) include:
One problem of course is that the early adopters (Corel, for example, who ported their whole Word Perfect suite to Java) are distracted from maintaining their core product line, which results in their falling behind in the industry. Like Novell who lost their focus during their disastrous fling with Unix, some companies are never likely to recover.
If one really wanted a generalized, compact/portable-object-code programming language, one could do that using Pascal and P-code. There's nothing all that revolutionary about Java.
The other issue is that languages like Java generally come with huge performance penalties (which of course are exacerbated by the current idiotic notion of trying to run the Java code at the central server rather than at the workstation, where computing power is cheaper).
Another fad that's being hyped by people who ought to know better is the idea of sending Internet traffic across cable TV connections into the home, supposedly allowing people to surf the Internet "thousands of times" faster than by traditional modems. These companies are promoting something that they simply cannot deliver, creating expectations that they will not be able to fulfill.
While the basic idea of digital transmission into the home at high speeds is just fine, the reality is that it's often not your modem which slows your Internet surfing down anyhow. If you watch the actual data transfer taking place, you'll probably see long periods of time where absolutely nothing is transiting your modem, and if you were on a cable-TV-based connection, you'd be waiting absolutely every bit as long. The truth is that delays when surfing the net come from many different areas, and the speed of the modem line connecting you to your ISP is only one of them. As in the classic metal chain (which is "only as strong as its weakest link"), your data transfer only goes as fast as the limit imposed by the smallest bottleneck enroute.
Even for transfers which in theory probably terminate on machines located at your own ISP (typically, E-mail and Usenet newsgroups), the likelihood of a user actually achieving real-world throughputs (and here we're talking about real world, not the first five users running on a lightly-loaded demonstration version) hugely better than they have today are small indeed. If nothing else, consider that most E-mail and Usenet servers are running on PCs... high-end PCs maybe, but PCs nonetheless. And those machines simply have limits to their aggregate throughput, which are already commonly achieved by existing customer loads at ISPs and other host sites. Increasing everyone's modem speeds by three orders of magnitude (without a corresponding decrease in the number of customers being served) will result in moving the bottleneck to the E-mail or Usenet server (or the distant Web server, for that matter). It is unlikely to change the actual throughput as seen by a given user by very much... certainly not by a factor of anything like a thousand.
It is ludicrous that Bob Metcalfe is deified by the industry as supposedly being the father of LANs. The LAN that Bob Metcalfe worked on was quite unlike the Ethernet which eventually became popular. Bob Metcalfe's LAN:
Datapoint's ARCnet, which was installed commercially in 1977 (well before Ethernet) avoided virtually all of these problems, and in fact the final version of Ethernet which eventually became popular looks a great deal more like ARCnet (thin coax or twisted pair cables, flexible interconnected-stars architecture based on active hubs, ability to add and remove nodes while the network is active, etc. etc.) than it does like the system Bob Metcalfe was involved with.
We have literally thousands of years of human history involved with distribution systems of an astonishing diversity, and virtually no such successful systems work using a bus distribution model (other than on the very smallest, most local of levels). Nearly all successful distribution schemes use a hub-and-spoke or "interconnected stars" model instead, because it's radically more versatile, flexible, and efficient.
(to be provided)
(to be provided)
Too often, "client/server" is a modern euphemism for what I call "mainframe think", the old-fashioned, obsolete idea of using lots of "terminals" around one big multiuser centralized machine that can do everything critical within itself. In a day where reasonably powerful CPUs cost the price of a good dinner, I think it's simply dumb to try to share them... I'm far more interested in finding ways for a single user to make profitable use of a bunch of them, than to decide how many users you can sandwich onto just one of them.
Besides, it's simply good practice nowadays to make scaleable systems where you can expand the overall system capacity by simply adding more low-cost modules. With a single centralized "server" machine, you reach the capacity of your centralized "server", and then you're just stuck. I really believe that in good measure, "client/server" is a desperate last-ditch attempt for IBM and the other big-machine people (finally realizing that the jig is up, LANs ARE replacing mainframes, as I predicted in 1977 that they would) to try to keep a place in the marketplace for their big old expensive monolithic dinosaurs.
To a certain extent, the whole Web thing is something of a throwback to "mainframe think" although with careful design at least the Web server is an appropriate place to employ a cluster of less expensive processors, rather than one big monolithic machine. But there is no mystery, anyhow, why the people trying to sell big, expensive, pricey iron are desperate to concentrate as much of the load as possible back onto centralized, server-style resources. Those machines (despite their being far less capable than the small army of distributed processors they hope to replace) carry far higher margins (and much greater profits) than the cheap, razor-slim-margin mass-market PCs do.
Briefly, I don't much like it. Mainly, for three good reasons. First, I hate proprietary, nonstandard, overpriced hardware. Second, I dislike the fact that their non-Intel architecture makes it difficult or impossible to run the huge array of good software that exists for the predominant PC platform, including things like good local area networking systems, both software and hardware (ARCnet for example). And third, as a programmer I hate a machine where I can't easily get it to do what I want it to do, and not just what some other programmer once thought I might want to do. I hate having to be forced to write EVERY program through a stupid, complicated GUI interface when the program in question is maybe only going to ever run once!!
I don't much care for this one, either. I can't imagine what possessed IBM to produce a CPU which completely flies in the face of the defacto industry standard Intel architecture (which in fact started from a Datapoint architecture, but that's another story). For years the ground was littered with the bodies of other wannabe mainframe companies, taught a very expensive lesson by IBM: you cannot blithely ignore the fact that the IBM 360/370 architecture and systems was a defacto industry standard. Companies had huge investments in hardware, software, and training based on that system and architecture.
One would THINK that after their disastrous effort to lock the [profitable, business] customer in via their Micro-Channel Architecture, (probably more than anything else responsible for IBM's loss of pre-eminence in the PC hardware marketplace), IBM would have learned their lesson. Apparently not.
Of course, the ONLY company truly making money hand-over-fist in the PC hardware business these days is Intel. IBM certainly has both the hardware design expertise and manufacturing and technology capability to go head-to-head with Intel for the PC CPU marketplace. If instead of making a noncompatible CPU (that almost nobody really wants), IBM had instead made a PowerPC that would execute Intel code in native mode (rather like NexGen did), or better yet as a plug-compatible replacement for the Intel 486 or Pentium or whatever, the chip would have doubtless been an instant competitor and huge success.
But for the time being, while everyone else is busy with Intel architecture and Windows and NT and ISA/VESA/PCI (and growing like mad), IBM is still trying to establish their own proprietary non-standard standards based on the PowerPC CPU, OS/2 operating system software (which fortunately they're finally realizing is a non-player), and they're still even trying to sell their ill-fated MicroChannel (and, predictably, continuing to "downsize"). Will IBM ever get their act back together? As of today, I'm certainly not willing to bet that they will.
I don't much like UNIX. In fact, it's fair to say I dislike it.
A good part of this is because I consider it an archaic, timesharing-oriented operating system, no longer appropriate in days like these when a powerful CPU can cost you less than a nice dinner. I really don't much think it makes sense to try to put a multiuser operating system on a shared CPU any more. Grosch's Law hasn't been true for a long time already.
I also don't really like it's old-school "omniscient" operating system design philosophy, where the operating system has to know the state of everything else all the time. When it used to control EVERYTHING this was more tolerable, but nowadays when most systems involve multiple CPUs, it's really impossible to know instantly that something else has just died. Designs like UNIX encourage the operating system to make sometimes-irrevocable decisions based on inherently unreliable information, and this is not a good way to design an operating system that needs to be reliable and dependable.
I also don't like the fact that at least most of the UNIX implementations (all that I've worked with, anyhow) use antiquated fixed-size-arrays for internal system tables, rather than the more sophisticated and flexible linked structures that any decent programmer has learned about before they get out of college.
It seems that Unix (and Linux) have a major role in today's Internet (in particular) but I think that's largely because of inertia from where a lot of the early Internet development was done. Given the enormous and well-coordinated resources being devoted to these areas by Microsoft, I don't see how the less-well-coordinated and less-comprehensive efforts of Linux and other open-source advocates can keep pace.
Use the BACK control on your Web browser, or click here to return to my main home page.
This page and all linked contents originating with me are Copyright (C) 1995-2000 by Gordon E. Peterson II, all rights reserved worldwide. Last revised November 22, 2000.