TTG Home » Robert Home » Daynotes Journal Home » Journal for Week of 1 January 2001
|
Week of 1 January 2001 Latest
Update: Friday, 05 July 2002 09:16 |
|
Monday, 1 January 2001 [Last
Week] [Monday] [Tuesday] [Wednesday]
[Thursday] [Friday] [Saturday]
[Sunday] [Next Week] |
| Happy New Year. The start of another day, another week,
another month, another year, and (depending on how you look at it) another
decade, another century, and another millennium.
I ran web access reports for Pournelle's and my sites this morning. I almost made my secret goal. At the beginning of 2000, I decided I'd shoot for half a million page reads for the year on this site. At that time, that seemed wildly optimistic, since I was doing about 20,000 page reads a month. Things continued to build throughout the year, though, and we ended up with more than 70,000 page reads for the month of December. The total for the year came up 200 page reads short, at 499,800 page reads. Still not bad for what's really a personal site. It's going to take a while to publish this morning, because I updated the copyright notice at the bottom to include 2001. That means that every page in the web was updated, and every one of them will have to be published up to the server.
I really must do something about meepmeep, my Roadrunner box. It just locked up again as I was doing the DNS lookups for Pournelle's web access reports. Very aggravating, because it'd been running that job for half an hour or so and was probably near the end when the system hung. This happens periodically. Sometimes it's a week or two between crashes, and sometimes only an hour. Overall, it's probably crashing an average of once a week. This system was built around a cheap no-name Pacific Rim case and power supply (all that was handy at the time) and has had a continuing series of problems. At one point, the CD-ROM drive just disappeared. Physically it was still there, of course, but Windows NT Workstation 4.0 could no longer see it. That wouldn't have been a big deal, except that NT kept logging critical error messages to the event log, which gets old fast. So I simply disabled the secondary IDE interface, which solved that. Then the problems with sporadic hangs started. This is one hinky system, and I need to do something about it. I have a few options:
I've been doing a lot of thinking lately about what I want to do in 2001. I'll be doing the new edition of PC Hardware in a Nutshell, of course, and I may also do a new computer book of some sort and perhaps some articles for on-line publications. This is the year that I will (begin to) learn Linux. But Barbara and I are also going to be focusing on a special project that's all our own. More on that later as things unfold. Click here to read or post responses to this week's journal entries [Top] |
|
Tuesday, 2 January 2001 [Last
Week] [Monday] [Tuesday] [Wednesday]
[Thursday] [Friday] [Saturday]
[Sunday] [Next Week] |
| Slow day yesterday. Barbara spent most of the morning and
early afternoon alternating between tearing down and repacking the
Christmas decorations and watching the Parade of Roses. I spent that time
running web stats for the year, archiving old data, and doing other
administrative stuff, clearing the decks for the new year. In the
afternoon, we headed over to Barbara's sister's house, where we had Roast
Beast for dinner.
Duncan turned six yesterday, so he got more and bigger treats than the other guys all day long. Border Collies can definitely count (they need basic arithmetic for doing flock inventories and so on), but we don't think Duncan understood that it was his birthday. At six years old, Duncan is now officially middle-aged, in his forties in human terms. He's still remarkably fast--he can outrun Malcolm on the straightaway, although he loses ground in the turns--but he doesn't have the endurance he once did. Duncan loves to be outside and running at any opportunity, but after running for a while he's happy to lie down and rest, whereas Malcolm just wants to keep running.
FedEx just showed up with two Intel Celeron/800 processors. These are the new 100 MHz FSB models, and I'm looking forward to trying them. Intel has finally dispensed with the 66 MHz FSB, which was hurting the Celeron's performance against the Duron. In effect, the Celeron is now almost a Pentium III. The only difference I'm aware of is that the new Celerons have 128 KB of 4-way set associative L2 cache versus the 256 KB of 8-way set associative L2 cache of the Pentium III. That will translate to lower performance for the Celeron versus the Pentium III, of course, but the question is just how much. Probably not much. In absolute terms, the 100 MHz FSB Celerons will probably be a close match for similarly-clocked Durons. In practical terms that won't be the case, though. Both the Celeron and the Duron are intended for "value" systems, which is to say those using integrated motherboards. And integrated motherboards based on Intel chipsets have much higher performance than those integrated motherboards based on the VIA KM133 and SiS chipsets that are just starting to ship. The net result is that entry-level Celeron systems are going to be faster than entry-level Duron systems. That must have AMD gnashing their teeth. I love this competition between Intel and AMD. Who'd have thought only last fall that we'd now be able to buy a processor running at or near 1 GHz for well under $200? This competition benefits all of us. I'd like to get at least one of these Celeron/800 processors installed and running, but I'll have to wait. Intel shipped us bare processors, and I'm not sure what kind of heatsink/fan they need. I'd hate to guess wrong. I suspect I'll also need to apply BIOS updates to the motherboards that I install these processors in. All of them support Coppermine128-core Celerons at 66 MHz FSB and Pentium IIIs at 100/133 MHz, but a Celeron at 100 MHz is a different animal. The current BIOSs would probably either spot the processor as a Celeron and run it at 66 MHz or spot the 100 MHz FSB and run it as a Pentium III, assuming that the Pentium III L2 cache was present. Neither of those would be good. Click here to read or post responses to this week's journal entries [Top] |
|
Wednesday, 3 January 2001 [Last
Week] [Monday] [Tuesday]
[Wednesday] [Thursday] [Friday]
[Saturday] [Sunday] [Next
Week] |
| Back before we bought this house in 1987, we rented a house
from Barbara's minister, Nelson Weller. Nelson calls me every few years
with a computer problem, and the problem he had yesterday is worth
repeating as a warning. It's been very cold and dry around here. The other
day, Nelson intended to synch his Palm V. He got it out of his briefcase
and carried it back through the house to his desktop PC. When he slid the
Palm V into the cradle, a bright blue spark jumped from the Palm V to the
cradle, killing his desktop system. And I do mean killing it. He took it
to a reputable computer repair place. As it turns out, he's going to have
to replace the motherboard and processor. They're not sure about the
memory or the hard drive until they try them.
Static charges of more than 50,000 Volts can accumulate under dry conditions (although obviously at tiny amperages, or we'd have a plague of smoking corpses). Grounding that voltage to an unprotected serial port is a good way to introduce high voltage to components designed to work at 1.6V to 5V. So be very careful when connecting anything to a PCs ports or you may find yourself replacing your system.
More drain problems. The washer started overflowing again, so we called the plumber to check the backflow valve, assuming that we coincidentally had both problems--a clogged main drain and a clogged check valve. The plumber checked out the valve, and it's fine, so the problem is the main drain, again. We called the rooter guy, who came out again and augered out the drain. Again, he couldn't find a problem. He said the problem is likely with the line itself, which we installed only about six years ago. So we called the plumber who originally installed the line. He concurs, says that the problem is likely with the few feet of line he didn't replace because it was under the driveway, and suggests we call the city to see if they can do something. This is getting old fast. We've had several visits from plumbers and rooter guys, paid probably $300 for those visits, and are no better off than when we started. Oh, the joys of home ownership... Click here to read or post responses to this week's journal entries [Top] |
|
Thursday, 4 January 2001 [Last
Week] [Monday] [Tuesday]
[Wednesday] [Thursday] [Friday]
[Saturday] [Sunday] [Next
Week] |
|
Later post than usual this morning. We've been trying to get the problem with the main drain resolved. The city was out this morning and used a camera to establish that the problem is on our side of the stack. We could actually see the stoppage, despite the fact that the auger guy says the line is clear all the way out to the city stack. Now we need to get something done to fix it. More about this on the TTG Messageboard. Incidentally, I'm spending increasingly more of my time creating and responding to messages on the messageboards, so if you're looking for more there is the place to go. You might also check out Barbara's diary page.
We did it! Late yesterday morning, our SETI group appeared at #200 on the Top 100 Clubs list, with 37,913 units complete. We're within a couple hundred units of several other groups, so we should be climbing that list over the next couple of weeks. Congratulations to everyone. It's pretty amazing to me that we've accomplished so much in so little time. We've been doing this only since mid-August, whereas many of the groups that appear on the leaderboards have a year or more head start on us. This is particularly impressive because the "Clubs" list is the big leagues. If we'd been in any of the other groups, we'd have gained the top 100 (or even top 10) long ago. Way to go, everyone.
Barbara and I are working on a book (eventually, a series of books) that we intend to distribute electronically. These will be reference books, intended to be used on-the-fly by people who are sitting in front of a computer anyway, so putting the books in electronic form makes sense. The question is, which electronic form? I've looked at numerous e-book "solutions" but most of those have as their raison d'ętre preventing people from stealing the content. I've argued for years against any form of copy-protection that hinders the ability of honest people to use the product they paid for, which is to say any form of copy-protection whatsoever. So now as a content provider, it's put-up-or-shutup time for us. We'll be putting up. We will not lock, encrypt, or otherwise protect our content in any fashion that might hinder an honest user from using it in any reasonable manner. And we'll define "reasonable" as a typical user looks at things rather than as a typical content provider looks at things. For example, a single user who has both a desktop system and a notebook system should be able to install the product on both systems without paying for it twice. They're going to do it anyway--I would--so what's the point to turning them into criminals, if only technically? Obviously, we'll prohibit giving away or selling copies, posting the content on the Internet, and so on, but our license will prohibit nothing that we believe constitutes reasonable use. So with the necessity for encryption, copy-protection, serialization, and so on out of the way, we come to the question of how best to package the content. We considered using standard HTML, but there are some problems with that. Size, for one. Lack of a search facility for another. The huge number of individual files that would be needed for a third. HTML does have one thing going for it, though. Cross-platform compatibility. Whatever we decide on, we want it to be equally usable on a Windows PC and a Macintosh. Linux would be nice, but is not essential. We need a good search capability, and would like to have an automated TOC/Index generation system. The ability to copy/paste and print is highly desirable, and the ability to embed live links to Internet sites is essential. We'd like the content to be accessible with a standard browser, ideally without any requirement for loading a plug-in or dedicated client. A royalty-free run-time distribution system is essential. So, with all of that in mind, I started looking at the available options. We ruled out Adobe PDF stuff immediately on several grounds, including the fact that I despise PDFs. We ruled out stuff like the Microsoft Reader and similar e-book clients on many grounds as well. We looked at various HTML compilers, but none of them seemed compelling, and all seemed to lack one or more of our requirements. What we came up with, believe it or not, is the Microsoft HMTL Help authoring and viewing system. It compiles HTML and image files into a single .chm compiled help file, greatly reducing the size of the HTML in the process. It provides strong search capabilities and operates in the same way as the new standard Microsoft help files, which means that most users already know how to use it. The authoring system and the viewer are both free and royalty-free. The system is proprietary only in that it uses the Microsoft Internet Explorer engine, requiring IE 3.02 or higher to be installed (although not requiring IE be the default browser). That means chm files are accessible on Windows PCs and Macs, but not Linux systems. The lack of Linux compatibility is really not an issue, because I'd guess that literally not one in ten thousand of our prospective customers runs a Linux desktop system. The downside to the Microsoft HTML Help authoring system is that using it will require some significant investment in time to learn the product and prepare the raw content for use. It's not simply a matter of pointing the compiler at an existing web site and letting 'er rip. So before I start putting in time with that product, I wanted to ask if anyone had any experience with it and if there are better solutions I've overlooked. We'll have zillions of other questions as the project develops, including how best to market the product, how best to accept payments for it, and so on. We'll need lots of help and that help will have to be voluntary, at least at first. We're doing things on the proverbial shoestring. Getting one's own publishing company off the ground is no trivial task, even if one limits it to electronic publishing. We may even fail. But we're convinced that the best course for content creators is to take control of our own destiny rather than depending on traditional publishers. As the Chinese saying goes, the longest journey begins with a single step. So we're taking that step. To keep discussions organized (and available to refer back to later), we're opening a new forum over on the messageboard. If you have comments, please make them there. Click here to read or post responses to this week's journal entries [Top] |
|
Friday, 5 January 2001 [Last
Week] [Monday] [Tuesday]
[Wednesday] [Thursday]
[Friday] [Saturday] [Sunday]
[Next Week] |
| The drain auger guy is supposed to be coming out this
morning, and the guy from the city sewers department is supposed to meet
him here to watch what he does. We hope they'll get the drain clog
cleared. This is all very aggravating, and taking time I'd rather be using
for other things. Still, we can't have non-functioning drains, so this
takes priority. Until this gets resolved, I have all kinds of work backing
up to go along with my drains backing up. Thanks to everyone who's written
privately and on the messageboard to offer advice.
I did at least get a fair amount of outlining and structural organization done on our first e-book last night. For now anyway I'm working in FrontPage 2000, which isn't as bad as I feared it would be. I wouldn't want to write a 40 page chapter as a single HTML file, but the FP editor is quite usable for the shorter elements used in an e-book. By working in straight HTML, I'm keeping our options open for later. And now I'd better go respond to the email that's backing up in my inbox and get ready for the drain guys. Click here to read or post responses to this week's journal entries [Top] |
|
Saturday, 6 January 2001 [Last
Week] [Monday] [Tuesday]
[Wednesday] [Thursday] [Friday]
[Saturday] [Sunday] [Next
Week] |
| The drain auger guys came again yesterday, and they say the
problem is right out at the city cleanout stack, but on our side. I
figured that meant we'd get to pay to have the driveway ripped up and the
last portion of the main drain on our side replaced, so I called the
plumber who'd installed it in the first place and asked him what we needed
to do to get moving on it. When he called back, he said that replacing the
portion on our side might not fix the problem, because the problem was
right at the stack, which he's not allowed to touch. He suggested getting
back in touch with the city guy and telling him we wanted a "sewer
renewal", which would include replacing the cleanout stack and the
tail pipe, which is the 5 feet or so of pipe on our side of the stack that
the city installs. We may be able to talk the city guy into doing the
sewer renewal for free. Otherwise, it'd be a fixed fee of $450. But it's
clear that augering out the drain isn't going to solve the problem. So I
have to call the city guy first thing Monday morning and tell him what our
plumber said.
Boy, can I accumulate data. In addition to our main data subdirectory, I have an archive data subdirectory. The main data directory contains only active stuff, and totals just under a gigabyte. That's just our current working data. The archive data directory includes inactive stuff, plus some "semi-active" stuff like the raw web logs, distribution files I've downloaded over the Internet, and so on. And, boy, does that stuff add up. The archive directory used to be on a 50 GB hard drive on kiwi. After kiwi died, I connected that drive to another system long enough to pull the archive directory off to an active system. I always replicate all data files to hard drives on multiple systems, so I attempted to copy those archive data files to an archive directory on theodore, the main file server. The copy process blew up with insufficient disk space. Not surprising in retrospect, as theodore has "only" a 10 GB hard drive, of which only 5 GB or so was available after operating system and our main data directory was taken into account. When I checked the archive directory, I found that it had 14 GB of files! A lot of that could be dispensed with, particularly now that we're in a new year. For example, I download Pournelle's raw web logs every week. They are stored in compressed form as .gz files, and are typically anything from 500 KB to 1 MB for each daily file. That's no big deal--a year's worth would be only 300 MB give or take--but I uncompress them each week when I run reports and store the uncompressed files in another directory. So by year end, I had 366 uncompressed files for Pournelle's web logs, each of which was 10 MB, give or take. Those files totaled nearly 4 GB. Those files are of historical interest only now, so I used WinZIP to compress them using the maximum compression option. That 4 GB of uncompressed files turned into a single ZIP file that was about 150 MB. My own web logs showed similar shrinkage, albeit starting from a smaller base. All told, just archiving/compressing some of my old data got me down from 14 GB to about 9 GB. With that done, I decided to see if there were files I could get rid of. Being a packrat, I tend to accumulate files and keep them forever. Part of that was a result of living with dial-up until last summer. When you download a 5 MB file (or even a 1 MB file) via dial-up, you tend to keep it somewhere safe so that you don't have to download it again. The result was that I had multiple versions of a lot of things. I mean, not just the most recent version of Netscape Navigator I'd downloaded, but several older versions. And, realistically, what are the chances that I'll ever want Nav V2? Obviously, not very high. So I went through my install directory and deleted some of those antique installation files. Same thing in another directory I named distribution. That one has entire CDs copied into it, because it's often easier to install from a network volume than to find the original CD. Once again, I had lots of elderly programs. Chances are I'll never want to install FrontPage 98, say, or Office 97SBE. If so, I still have the original CDs somewhere. All told, I managed to chop down my 14 GB of archived data to something like 5 GB, and it would have been easy to chop it down more. But I have more disk space than time, so I decided to leave it at that. Once I had the archive directory pruned on thoth, my main system, I went over and deleted the entire archive directory that's mirrored on theodore, leaving more than 7 GB available on theodore's 10 GB drive. After clearing the Recycle Bin, I fired up vOPT and let 'er rip. It took quite a while to defrag and pack theodore's hard drive, but I didn't want to re-copy the archive data over there until I'd done so. So, as I write this, I'm in the process of copying the archive directory from thoth to theodore, which is going to take a while. Once that's done, I'll run a tape backup on theodore and once again feel that my data is reasonably safe.
And that, incidentally, reminds me of something I was going to comment on. Both Jerry Pournelle and J. H. Ricketson have commented recently about using mirrored hard drives as a substitute for tape backup. A mirror set is not a substitute for doing tape backups, not even close. A mirror set protects only against a single drive failure, but that's just one of the things that a tape backup protects against (and probably one of the least important). If you accidentally delete a file, a mirror set doesn't help at all. Same thing if a file is corrupted or if you're nailed by a virus. And if your computer is stolen or destroyed by a fire or other disaster, your mirror set helps you not at all. Don't get me wrong. A mirror set is a very good thing to have. But it's not a substitute for backing up. Neither Jerry nor J. H. depend solely on a mirror set, of course. Both of them do as I do, copying data directories from one machine to another on the network, and pulling off archive copies on optical media periodically. All of those steps are good ones, and ones I do myself. But a practical backup scheme for most people means using a tape drive. There's simply nothing else available that comes close to tape as a practical backup method. CD-R discs are fine, but they're small and even if you use a 12X writer, they're still much slower than tape. Magneto-Optical and DVD-RAM have the same problems in different proportions. A relatively inexpensive DDS-3 tape drive backs up 12/24 GB of data to a $10 tape at real-world speeds between 1 MB/s and 2 MB/s. There is no other technology that comes close to tape for speed, cost per GB stored, and reliability. Both Jerry and J. H. have complained about the reliability of tape, but in my experience reliability is a strong point of tape rather than a weak one. Hundreds of thousands of data centers and LANs world-wide are backed up to DDS tapes. If there were a problem with them, it'd be well-known by now. Nearly every problem with high-end tape drives that I'm aware of occurred either because tapes were overused or because the tape drive was not kept clean. Modern DDS tape drives have so much error correction built into them that the chances of losing data are vanishingly small unless the tape itself is damaged. Jerry comments that it's a pain in the butt to restore a failed hard drive because you have to re-install the tape software before you can do so. That's a good argument for using a mirror set in addition to a tape drive, but it's not a good reason for not using a tape drive. I was just reading a military document about setting up a secure firebase (yes, I have strange reading habits) and some similarities between doing that and keeping one's data secure struck me. When you design a firebase, you create a defense in depth, doing everything possible to keep the bad guys outside the wire. You don't say to yourself, "Let's see. Should I use machine guns or concertina wire or tanglefoot wire or landmines or claymores or flame fougasses or ..." You use all of them, plus anything else you can think of. If your data is important you should take the same approach to protecting it. It's not a question of "either-or". It's a question of how many "ands" you can afford. My data is important to me, so I use mirror sets and tape backup and replication to multiple network volumes and copies to CD-R and copies to DVD-RAM and backup to a remote Internet server and ... Not everyone can afford such massively multiple redundancy, and the truth is that not everyone needs it. But the more redundancy you introduce, the safer your data is, and that's what it's all about. Click here to read or post responses to this week's journal entries [Top] |
|
[Last
Week] [Monday] [Tuesday]
[Wednesday] [Thursday] [Friday]
[Saturday] [Sunday] [Next
Week] |
| While Barbara cleans house this morning, I get to do
laundry. Barbara had a smart idea yesterday. Ordinarily, we do wash loads
on the "Large" setting, which is very large indeed. I can easily
fit three or four pairs of jeans, the same number of sweat pants, several
sweat shirts, a half dozen t-shirts, and considerable other miscellaneous
stuff in a "large" load. When she bought this washer, she found
the largest washer available for home use. It also has a
"Medium" setting, which isn't that much smaller than Large, and
an "Extremely Small" setting, which fills the tub only a quarter
to a third full. I'd guess the relative amounts of water involved are 3,
2, and 1, with "1" being maybe 10 gallons (38 litres).
At any rate, Barbara decided yesterday to see if we could run an Extremely Small load without ending up with water on the basement floor. Lo and behold, it worked. Our drain isn't completely blocked, just slow running. When the washer ejects 30 gallons of water in about 15 seconds, that's enough to cause the main drain to fill up, leaving the used washer water with nowhere to go but overflowing the standpipe onto the basement floor. But when it ejects the water from an extremely small load, everything is fine. So I just took the whites down, intending to run them in two extremely small loads, with perhaps a half hour of recovery time for the drain before running the second load. I filled the washer, added soap, and put about half the whites in. When the washer started agitating, I noticed that the clothes looked pretty lonely in there. Much more water than clothes. So I kept adding clothes, a couple socks here, a pair of underpants there. And before long, I'd added the rest of the white load, and they were all still under water. I guess socks and undies don't take up much room, although there were also a couple pairs of sweatpants in there. So I won't have to do as many loads as I thought.
We're also going to install a DVD-ROM drive in Barbara's system today, so we can install the Britannica 2001 DVD. I don't have a SCSI DVD-ROM drive handy, so we're going to put an Hitachi GD-2500 ATAPI unit in Barbara's system as the sole IDE device. That's either a 4X or 6X unit. They made both with that model number, and I'm not sure which this one is. In terms of throughput, a 4X DVD-ROM is roughly equivalent to a 36X CD-ROM, so either should be adequate for Britannica. I thought I had a GD-5000 8X unit, but if I do it's lost in the stacks.
I've been saying that advertising is not a sustainable funding mechanism for web sites since before companies like doubleclick.net even existed. So it's a pleasure to have my judgment so strongly confirmed by the recent bloodbath that ad-supported web sites have experienced. Since October, many of those web sites have ceased operations, and many more will follow over the coming months. The problem, of course, is that web advertising simply doesn't work. Actually, I've made the point before that no type of advertising really works, but the problem with web-based ads is that they demonstrably don't work. When someone pays a lot of money to run an ad in a magazine or on television, it's impossible to determine what effect, if any, running that ad had on sales. A company that pays millions of dollars to run ads on ER or to buy double trucks in major magazines can delude themselves that they're getting value for the money they're spending. There's no direct correlation between money spent to run a particular ad and sales of the product being advertised. If sales goes up, the ad agency claims credit. If sales remain steady or fall, the advertising agency always claims that it's because not enough money was spent on ads or that the market is too competitive, or whatever. Anything but admit the sorry truth that ads of any sort are ineffective. But the story is different with web ads, because advertisers get immediate feedback that shows whether or not the ad was effective. And guess what? They aren't. Effective, that is. Ad agencies when faced with these hard numbers simply claim that the web is the "wrong venue" for advertising that product, or perhaps even admit that web advertising is ineffective. Anything but admit to the reality, which is that ads in general are ineffective, except perhaps as a mechanism for announcing new products. No one clicks on banner ads any more, and in their desperation advertisers increasingly are using even more obnoxious methods, most of which involve blinking, animation, and/or sound. I won't look at a screen full of that garbage, and obviously not many other people will, either. The result is a downward spiral. No one is willing to pay much for standard banner ads any more, and the loud flashy ads simply turn people off. So the result is that less money will be devoted to web advertising with each passing month. When web advertising was first getting started, there were actually more paid ad impressions available than there were places to run them. Any web site that was willing to run ads could do so and be paid for each ad. Now that web advertising has proven itself ineffective, there are fewer and fewer paid ads being chased by more and more sites. Ad server companies actually find themselves in the position of serving ads for which they will not be paid to sites which they have contracted with to run ads. The ad server companies still have to pay the sites that run the ads, mind you, but they themselves are not paid for those ads. That's obviously not sustainable. Something had to give and it has. Hence the collapse of web-based advertising. Right now, that collapse is hurting certain kinds of sites more than others. The high-bandwidth free gaming sites are closing right and left. For now anyway, sites like AnandTech and Tom's Hardware continue to generate ad revenue, albeit at probably half the impression rates they were formerly paid. I'm told that per impression rates are down in the $1/thousand range now and will drop still lower. That means that a page with one banner ad on it must draw 1,000 page reads to generate $1.00 in revenue. The obvious solution is to run multiple ads per page, but the problem with that is that there are a decreasing number of paid ads available, and rates per ad may be lower on pages with multiple ads than on those with only one ad. So what happens now? First, a lot of "free" sites won't be around much longer, simply because the decreasing pool of ad money will tend to concentrate in a relatively small percentage of the sites. The first ones to go will be the relatively small sites, those that had been generating less than $1,000 or so a month in ad revenue. They simply don't have the resources to provide sufficient high-quality content to keep drawing readers. You'll see a consolidation by an order of magnitude in any given type of site. In PC hardware sites, for example, the larger sites like AnandTech and Tom's Hardware will survive at the expense of scores of small PC hardware sites, which will close down in droves. Mid-range sites like Storage Review may hold on for a while, but ultimately they'll be forced out of business as well. We'll end up with perhaps four ad-supported PC hardware sites left standing. For a while, anyway. As ad revenues continue to drop, even those strong sites will come under increasing pressure. Ultimately, the only sustainable way to fund a web site is via direct payments by users. If people aren't willing to pay cash money to view your content, you're ultimately going to be out of business. And that's the way it should be. Click here to read or post responses to this week's journal entries [Top] |
