|
Week of 5 July 1999 Sunday, 11 July 1999 08:01 A (mostly) daily journal of the trials, tribulations, and random observations of Robert Bruce Thompson, a writer of computer books. |
|
|
Monday, 5 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] The Dell box is back in my office and is now my official Windows 98 working box. I fired up the HP 6200C scanner yesterday to do some test scans. Barbara just visited a person in Greensboro who is moving soon and needs to give up his Border Collie. She brought back pictures of the dog, so that was a ready-made opportunity to test the scanner. Here's a picture of Patch. I just stuck it in the scanner and pressed the scan button. What you see is what it did. No tweaks at all. * * * * * I've mentioned the OnStream tape drives before. I've been testing a DI30 (internal IDE 15/30 GB) model for several months. It now resides in the Dell system, and I've been working with it under Windows 98. This tape drive has very attractive features. It is inexpensive (around $250 street), large capacity (15 GB native / 30 GB compressed), fast (35 to 45 MB/min on real-world data), very quiet, and uses tapes that cost less than $30 each. The only thing that keeps me from endorsing this drive without qualification is that I've had repeated problems with the bundled OnStream Echo backup software. The initial release crashed repeatedly under Windows NT 4, and was not stable under Windows 98. I've since downloaded Echo 2.1.8, which was to have fixed the problems. The problems persist, although they are less frequent. This on several systems under both Windows NT 4 and Windows 98, and with the operating system freshly installed. Any instability in a backup application is unacceptable. If backing up with Echo was the only way to use this drive, I could not recommend it. That's not the case, though. OnStream makes available for download a Windows NT driver that allows you to use various third-party Windows NT backup applications with this drive. The OnStream drive also supports the bundled Windows 98 Microsoft Backup application, albeit indirectly. Although Windows 98 and Microsoft Backup do not recognize the DI30 as a tape drive, Echo includes a file system driver that creates a virtual disk to make the tape drive appear as just another disk volume in Explorer. That means you can use Microsoft Backup to backup files to the virtual volume that Echo creates. For example, I have Windows 98 Microsoft Backup configured to backup data to the file 990705.qic on drive T: (the OnStream virtual drive). I'm now backing up one local volume and three network volumes, which comprise 185,956 files totaling 10,498.786,422 bytes. Two hours into this backup, about 53,000 files totaling about 4 GB have been processed. I'm getting just under 1.5:1 compression, so this 15/30 GB tape will actually hold about 22 GB, more than enough to back up all data on my network. I've put this drive on my Recommended List, with the proviso that you not attempt to use it with the bundled Echo backup software, at least until they've gotten the bugs worked out. Used with Microsoft Backup or a third-party backup application, this is one heck of a drive. It's solidly constructed, and nothing else in its price range even comes close to the OnStream DI30 in capacity, speed, or media cost per megabyte stored. In this era of inexpensive 10 and 20 GB hard disks, the OnStream DI30 is a good solution for backing up a standalone PC. Given suitable backup software, it's also a good solution for backing up a small workgroup server. OnStream has created a winner with this drive. Now if only they can get the bundled software right. * * * * * This from Paul Robichaux [paul@robichaux.net] regarding an interview with a pyrotechnician in Salon:
Actually, no. I've never been around large scale stuff like this much. Which is pretty strange, given where I grew up. I lived four houses up the street from the Vitales, who owned a fireworks company. Also, Zambelli, who are now world-famous for their fireworks exhibitions, are based in New Castle, Pennsylvania. I remember them doing exhibitions during the football games in 1971, when I was a high-school senior. Every time the home team scored, up would go one of those mortar shells that detonated loudly. They used up quite a few of them. A typical score that year was New Castle 53, Visitors 0. That was the year, strange but true, that New Castle's high school football team ended up ranked #1 in the US and #3 in Pennsylvania. Position by position, the team that year outweighed the Packers, which was the heaviest team in pro football. The New Castle front four, for example, weighed 260, 285, 275, and 255. They grow big boys in Western Pennsylvania. Several ambulances always sat waiting just off the end zone, and they were needed frequently.
|
|
|
Tuesday, 6 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] Here's a tip to keep in mind when you're backing up. Always exclude temporary directories that have a bunch of small files in them, particularly when you're backing up the volume over the network. During my backup session yesterday, I learned just how badly backing up all these worthless little files can impact the time needed for the backup. As I mentioned, I backed up one local volume and three network volumes that contained a total of 186,956 files and more than 10 GB of data. On the local volume, the OnStream was maintaining a rate greater than 40 MB/min (2.4 GB/hour). At the end of the first hour, the drive had backed up about 2.5 GB. At that point, it hit a bunch of little files in a folder used to store working backups of my (admittedly huge) working data set. At that point, things slowed down considerably. After 2 hours, the drive had backed up only a total of 4 GB, for a rate of about 1.5 GB per hour. Then the real trouble started, because the backup started hitting the network volumes, including some with an incredible number of small files. Network volumes in general are slower to back up than are local volumes, and when a network volume includes a lot of small files, the time required begins to skyrocket. When the backup hit the IE5 Temporary Internet Files folder on my main workstation, kerby, I first thought the backup had died. That folder contains 17,828 files totaling about 153 MB. Backing up just that folder took the better part of an hour. After a total of seven hours elapsed, the backup had completed about 130,000 files totaling only 6 GB. That's an incremental 2 GB in five hours. This is not the fault of the tape drive or the backup software. The problem arises because there is a great deal of file system overhead and operating system overhead when working with large numbers of small files. The moral here is: Exclude temporary directories before you start your backup. And it got worse: At 7 hours, 22 minutes, 133,886 files, and 6,300,311,018 bytes into the backup, Microsoft Backup prompted me to "Insert another media". Geez. More than seven hours down the drain. I *know* these tapes hold 15 GB natively, because I've done large backups to them in the past using the Echo software. The compression indicator was showing 1.47:1, which is suspiciously close to 4 GB native, 3.99+ GB by my quick calculation. I don't know what limit Windows 98 puts on individual file size, but my first guess is that it's 4 GB. This is going to require some additional exploration. Yep, that appears to be the problem. Last night, I created another backup selection set that totaled about 3.5 GB on one local volume and two network volumes. I set it to backup, compress, and compare, and set the backup running. This morning when I came in, the backup and compare had completed normally. To test the backup, I located a folder on C: with five scratch files in it, deleted four of those files, and then fired up Microsoft Backup to do a restore. It scanned the tape for a couple of minutes to build a temporary catalog, and then presented me with the standard hierarchical view of the volumes and folders that had been backed up. I marked the files I'd deleted to be restored, told it not to overwrite files that already existed, and the started the restore. It took four minutes to locate the files on tape (they were quite a ways in), and then restored the four correct files, which were in fact correctly restored and readable. This works. * * * * * Standalone ftp clients don't get much attention any more. That's understandable because, although ftp itself is still heavily used for transferring files on the Internet, most people simply use the ftp functionality built into their web browsers. That's a reasonable solution for people who only transfer files occasionally, but those of us who frequently transfer files with ftp need a better solution--one with more options, more control, and particularly more speed. Back in the pre-web dark ages while Bush was still in office, I used WS_FTP, a decent graphical ftp client for its time, and one that is still competitive in its latest incarnation. Some years ago, I switched to CuteFTP, which improved on WS_FTP in nearly every respect, including features and speed. After experiencing various problems recently with CuteFTP--notably difficulties with firewalls and proxy servers--I've switched again, this time to FTP Voyager, a standalone ftp client from the WinGate folks that beat the current versions of WS_FTP and CuteFTP hands down.. Like WS_FTP and CuteFTP, FTP Voyager emulates the Windows Explorer interface, but it does a better job of providing an Explorer-like look and feel. It presents local and remote files and directories in separate panes, and allows you to use standard Explorer features such as context-sensitive right-click menus, full drag-and-drop support, sorting by clicking on column headers, and viewing properties for the selected file. Anyone familiar with the Windows 95/98 or Windows NT 4 interface will be able to use FTP Voyager intuitively. FTP Voyager also excels in transfer and management functions, providing good implementations of all those I expected and several that I didn't. One very nice feature is Folder Shortcuts, which allow you to create what amount to symbolic links within the folder structure. By creating a Folder Shortcut, you can avoid drilling down into a folder structure by simply logically mapping a folder several levels deep to appear as a root-level folder. The only problems I had with FTP Voyager related to its synchronization feature, which allows you to automatically reconcile files and subdirectories between the local and remote copies of an ftp site, and is touted as a means of automating web site maintenance. I don't think these problems were the fault of FTP Voyager, though. I used FTP Voyager to synchronize the local and remote copies of my web site in both directions. After synchronization completed, FTP Voyager indicated that the sites were fully synchronized. I changed three files on the local site, and then fired up FTP Voyager to attempt another synchronization. It promptly informed me that scores of files were out of sync between the two sites. Given the other problems that I'd been having with FrontPage, I concluded that the fault almost certainly lay with FrontPage rather than FTP Voyager. After using FTP Voyager 6.1.0.2 heavily for a couple of weeks, I've concluded that this $38 ftp client has about every feature anyone could want in an ftp client, including the ability to resume interrupted transfers. The product is downloadable for a free 30-day trial and can be registered as shareware if you decide to continue using it. FTP Voyager may be overkill if you just use ftp occasionally to download a driver or program update. But if you use ftp heavily, you'll want a solid dedicated ftp client. This is the best one I've seen. Recommended. * * * * * This from Steve Tucker [steve@wakeolda.com]:
Patch's owner is moving in a month or six weeks, and Barbara hopes that they'll have placed him by then. They already have someone in mind who lives in Atlanta. If that doesn't work out, I've already told Barbara to bring him home with her, hopefully on a temporary basis. As far as the scan, I was literally talking about a button on the scanner. You just push the big green button on the scanner. It fires up the scanning software on the Win98 box and does the pre-scan. You can then crop as you wish, do the real scan, and then do a Save-As to write the file to disk in whatever format and compression level you wish. It sounds as though we both go through similar processes.
|
|
|
Wednesday, 7 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] Here's an Office 2000 bug that just bit me. I work with a lot of documents in Word. I nearly always save a document manually before I exit Word. Once in a great while, I simply close Word and then save the document when prompted. That latter method doesn't work very well with Word 2000. The document saves properly, but Word 2000 locks to an "Application not responding" state rather than exiting properly. The first time this happened, I thought it was the old Word 97 "loop" problem. I expected to find CPU Utilization at 100%, with the zombie Word process sucking all the CPU ticks. That turned out not to be the case. Word 2000 was indeed a zombie process, but at 0% CPU utilization. Killing it seems to have no bad effect on the open documents, so I'm not worried unduly about it. At first I thought perhaps this happened because of something odd about the particular document. That turns out not to be the case. I've intentionally exited Word without first saving with several documents now, and it hangs on all of them. * * * * * Good advice from Pournelle about marital harmony. I sent him the following after I returned from our cookout Monday: [...] I just brought my mother back from my sister-in-law's house, where we had a holiday cookout. I'm in trouble with Barbara. She asked me if I wanted ice cream cake, and I told her thanks, but no. Two minutes later, she asked me again, and I again told her thanks but no. Two minutes later still, she asked me a third time, and I made the rookie mistake of telling her that I'd meant "no" the first two times I'd told her. Does one still make that kind of mistake after 40 years of marriage? I can't believe I did it after 16 years. I'll throw myself on her mercy and plead 100 degree temperatures and high humidity. To which he replied:
* * * * * This series of exchanges with Dave Howard [dave@the1vision.com]:
Yes, I would be very interested in continuing to work to resolve the problems I've had with Echo. I like the OnStream drives, and I would like to be able to recommend them without reservation. The Echo software would be a superb product if I could get it to work reliably. I understand that Echo is a new product, and I'm sure that the difficulties I'm having are simply the teething pains one expects with any new software. As things stand, my OnStream DI30 is installed for a long-term evaluation in a Dell XPS-M200s system running Windows 98. I'll be happy to report the errors I encounter, and to try any new versions of the software you may supply on that box. Once I can get Echo running reliably under Windows 98, I'll also be happy to move the drive to a Windows NT 4 system and see what we can accomplish there.
I'd like to try that beta. Actually, I'm less concerned with the many-small-files problem than I am with the fact that Echo crashes on me, although I guess the problems could be related.. I ran the original Echo release under Windows NT 4, where it crashed repeatedly. More than once, it actually locked up Windows NT 4 to a blue-screen that required a reboot, which is pretty tough to do. I tried the original release under Windows 98, and had better results there, but it still blue-screened frequently. At that point, I put the drive aside to await the update that OnStream told me was due to arrive before long. I downloaded that update (2.1.8) a couple of weeks or so back. I tried running it under Windows NT, and didn't experience any blue-screens with it, although the application itself frequently locked to the "Application not responding" state. At that point, I decided to try running Echo on a Windows 98 box, which is the environment most people will use. The first time I ran it (on a fresh Win98 install), the backup appeared to proceed normally. I had it set to do a backup and compare on a large data set, so I went to bed while the backup was still running. When I arrived in my office the next morning, Windows 98 was displaying a blue screen. I should have written down that information, but naturally I didn't. As far as I know, I'm not running any vcache fix, unless it was installed with the new version of Echo. I'm using a full version of the original Windows 98 distribution. Microsoft is supposed to be sending me a copy of Win98 Second Edition, but it hasn't arrived yet. I should say that I'm not a Win98 guy. I run Windows NT almost exclusively. I have Win98 around only for testing and to do screen shots for my books. So don't assume that I know much about Win9x.
Okay, thanks. I'm running on a Win98-only system now, so I think I'll wait for the beta version you mention. Also, I should have a copy of Win98 SE showing up in a few days, so it sounds as though everything should come together in the next week or so. * * * * * Right around dinner time yesterday, I installed the vcache.vxd fix Dave had sent me, and then downloaded and installed Echo v 2.1.11. I then initialized and retensioned a new OnStream ADR30 tape, labeled "Week 1", which seemed to take longer than it used to. The dialog mentions that initialization will take 10 to 20 minutes if the retension check box is marked, and I seem to recall the last version mentioning only 10 minutes. At any rate, the initialize/retension operation completed normally. I told Echo to back up all of drive C:, but no network drives. The vital stats for that operation are as follows (compare enabled, backup registry enabled, data compression disabled):
The backup operation initially indicated average backup speed in the 35 to 40 MB/min range, and continued at this level through about the first 1.8 GB. The backup then reached a couple of data directories that contain a very large number of files, some large ones, but many small ones. At that point, the backup rate began to slow down, ultimately arriving at the 28 MB/min overall average for the backup as a whole. The compare operation very quickly reached the 50 MB/min range and stayed there through about 1.8 GB, when it also slowed down, ultimately yielding a 39 MB/min average for the entire compare--still much faster than the 28 MB/min backup average. The single most notable fact, however, was that the backup and compare operations completed normally. It may be that Echo 2.1.11 has in fact fixed many of the problems I'd experienced with the original version and with 2.1.8. So far, it's looking good. * * * * * With the original version of Echo, I'd experienced extremely slow backup times when the compression option was turned on, so I decided to test this new version on the same data set, but this time with compression enabled. I clicked the Eject icon in Echo Express, and found that Echo required several minutes to update the tape directory before actually ejecting the tape. I then initialized and retensioned yet another tape, labeled it Week 2, and used the same backup set selection and options as I did for the last test, but this time turned compression on. Using compression is always a trade-off. Actually compressing the data requires some CPU ticks, but if a compressed data stream can be written to tape at the same raw data rate as an uncompressed stream, the net result is that more data is written to tape per unit time, increasing the overall throughput. A well-designed backup utility only uses CPU ticks for compression if those ticks would otherwise be unused, thereby achieving at least some compression without adversely impacting the backup operation. With such software, the raw data rate is similar regardless of CPU speed, but the amount of compression increases with faster CPUs, resulting in faster overall throughput. Some tape software offers a "maximum compression" option which compresses the data as much as possible regardless of the CPU utilization required. Using that option minimizes the amount of tape needed to store any given data set, but may require more time than using no compression at all. It appeared to me that the original version of Echo was always functioning in "maximum compression" mode, which greatly slowed backup times when compression was enabled. I did those original tests on various systems running anything from a Celeron/333 with 64 MB on the low-end to a Pentium III/550 with 256 MB on the high. This system has only a Pentium/200 and 64 MB, so the results should be worse, if anything. And, as it turns out, they are worse. Much worse. After letting the backup with compression run from 20:15 until 21:00, only about 0.5 GB had been written to tape, and the data rate was hovering at 12 MB/min. I killed the backup rather than beat the drive to death for no purpose. It appears that some more work remains on Echo if using compression is to be a realistic option. * * * * * I decided to test Echo 2.1.11 with a network backup. So, before I went to bed last night, I started a backup to a fresh tape with a backup selection set that included the local C: drive as well as a couple of network drives. I excluded the Temporary Internet Files directory and similar directories that included a ton of tiny files. When I got back to my desk this morning, the compare results were displayed on the monitor:
The backup started at 21:16 and completed at 00:52, for an elapsed time of 3:36, or 216 minutes, for a data rate of about 19.5 MB/min overall. The compare pass began at 12:56 and completed at 3:14, for an elapsed time of 2:18, or 138 minutes, for a data rate of about 30.6 MB/min, somewhat less than indicated. But the important thing is that it worked. Just to make sure, I again attempted to restore a couple of files, and they restored perfectly. The numbers for backup and compare speeds are both skewed by two factors: (1) as the file count indicates, even though I eliminated a lot of temporary directories from the backup set, I still had a ton of small files selected, and (2) a significant portion of the backup was across the network, which is always about half the speed of backing up files from a local volume, regardless of what tape drive or backup software you use. Working on a normal file set on a local volume, the OnStream drive and Echo software maintain a backup rate between 40 and 50 MB/min. Although I haven't verified this, I suspect they would have been faster still on a system more capable than this old Dell 200 MHz Pentium box. At this point, I conclude that the OnStream drive with Echo 2.1.11 is reliable, at least under Windows 98. I'm tentatively moving the OnStream DI30 and Echo 2.1.11 to my "Recommended without Qualification" list for Windows 98. I'll want more long-term working experience with it before it assumes a permanent place on that list, but for now I feel safe in recommending it. * * * * * This from ROBERT RUDZKI [graykatz@pe.net]. (As Robert pointed out in a follow-up message, the book he mentions here is Tunnel in the Sky)::
Actually, I may have said that the SEALs used the silenced S&W Model 10's, but the guy who first told me about it was SF detached to SOG. I subsequently saw an example of the silenced Model 10, although I never heard one fired. I wasn't aware of the 788's in .45 ACP. I have a 788 in 7.62 back in my gun closet. I bought it at the time because I needed an inexpensive bolt action in .308, but it has one of the quickest actions I've used. I do wish it had a fixed magazine instead of those chintzy removable box magazines, though. Thanks for the kind words about my web page. Actually, it's more a case of Pournelle's resembling mine than the converse. Or I guess I should say that I wish his more resembled mine. I've done a couple of pages for him as templates, notably one of his Special Reports home pages, but I've never been able to get him to dispense with the ugly icons and go to text menu bars. The reason most people think our pages look similar is that I use the same background image he does, and I'll admit that I stole that from him... I've never used FrontPage Express, and I've had my share of problems with FrontPage 98 and FrontPage 2000, but I still think they're the best tool for the job, at least for someone like me who doesn't create web pages for a living. As far as knives, I've always been of the opinion that Bowie knew what he was about when he chose to carry that Arkansas Toothpick. I used to have a very nice custom-made Bowie Knife, intended for carry rather than display, but I sold it twenty years ago or more. I used to wear a Bowen Belt Knife even with a suit and tie, but nowadays, the only knife I carry is a Victorinox Swiss Army Knife. I'll never be without a knife, though. Back in 1976, I was crewing for my girlfriend on a 14-foot Sunfish. She flipped the boat and stuck the mast in the bottom of the lake. I ended up tangled in the lines about five or eight feet below the surface. Fortunately, I'd inhaled deeply when I saw I was going under, and was able to hold my breath long enough to get free. You never know how long you can hold your breath until you really have to... Instead of coming down to help, she stayed on the surface and screamed. Fortunately, there was a power boat not far away, and those guys came to help. I got to the surface just as they showed up. They later told me that I'd been under for about two minutes. It seemed more like two hours. So I always carry a knife.
|
|
|
Thursday, 8 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] Hmm, it's been in the mid- to high-90's around here (say 36C) for the last several days, with humidity also very high. We somehow escaped thunderstorms, even though our dew points were as high as the upper 70's, until yesterday afternoon, when some big ones started rolling in. I've spoken before about how intelligent Border Collies are. I know that no one will believe this story, but I'll relate it anyway. When the thunder started up, our younger BC, Duncan, came to my office, looked at me, walked to the top of the stairs to the basement (where we always go during particularly severe weather, having once had our roof removed by a tornado), and looked over his shoulder at me. I ignored him, and he repeated the process a couple of times. I still ignored him, so he came over to me, put his front paw on my arm, and woofed. I was trying to finish a chapter, so I told him to leave me alone. He went under my desk (he spends a great deal of time napping there) and looked at my surge protector. Its sits between the UPS and the equipment and really functions more as just a multi-outlet strip than a protector. Duncan stood looking down at the surge protector for several seconds, and then reached over with his front paw and stepped on the illuminated orange switch, killing my equipment. I told him that if he felt that strongly about it, we'd go downstairs, so we did. As it happened, a major thunderstorm rolled through here a few minutes later, so the dog had a point. I know that no one who doesn't own a Border Collie will believe that this was an intentional act by Duncan. Anyone who does own one won't doubt for a moment that it was. These dogs are smart. Very smart. Any dog smart enough to go out on command and bring back one named sheep from a flock of 500 (a commonplace act for a Border Collie) is smart enough to figure out how to turn off a computer. I know you probably think I'm having you on about this, but I'm not. * * * * * I'm accumulating stuff to build a seriously fast system. Best of everything, SCSI-only, no expense spared. The goodie pile is starting to grow. FedEx showed up Tuesday afternoon with some Plextor drives. I now have a PlexWriter 8/2/20 CD-RW drive, an UltraPlex Wide CD-ROM drive, and an UltraPlex 40max CD-ROM drive. The first two are going to go into the take-no-prisoners system I'm building around a PC Power & Cooling Full Tower case, an Adaptec 2940U2W host adapter, Seagate U2W hard drives, a Pentium III/550 (maybe two), 256 MB of Crucial PC133 SDRAM, a Tecmar Travan NS20 SCSI tape drive and other best-of-breed components. Once I have all the stuff I need in hand, I'll be spending a long weekend getting everything built and configured. * * * * * I'm also opening up a new Current Topics page on scanners. I just bought an HP 6200C scanner last weekend. It has both USB and SCSI interfaces. Right now, it's connected via USB to odin, my Windows 98 box, but I plan to connect it via SCSI to the new box. I'll be looking for some help from those of you who are experienced scanner users. * * * * * Interesting article in this morning's paper. As is obvious to anyone who uses search engines, they're falling behind in indexing what's out there. According to the article, Northern Light is now the most comprehensive of the search engines (16% of the available pages indexed) with AltaVista and Snap not far behind. HotBot, which led with 34% when the study was last done in December, 1997, is down to only 11%. There were three other interesting statements. First, that it now takes more than six months for a new site to be listed. Second, that the likelihood of a site being listed depends on how many other sites link to it, which puts new sites at a disadvantage. Third, that there is an economic disincentive for search sites to continue to expand their coverage, because large databases are expensive to maintain and a larger database does not automatically mean increased advertising revenues. I did visit Snap.com, which I hadn't visited lately, and did some test searches. It indeed does appear to be a worthwhile search engine, so I've added it to my links page. I just got personalized spam yesterday from a guy who offered to submit my site to a bunch of search engines for a one-time fee of $34.95 or whatever. I'm already on all of the top dozen or so search engines, as well as a bunch of the others, so why should I care about his service? * * * * * After reading my page yesterday, Dave Howard [dave@the1vision.com] has this to say about my comments on Echo's compression algorithm:
Thanks. I'll look forward to trying the new version once it's released. For now, compression isn't a major issue for me--the 15 GB native capacity of the OnStream DI30 is larger than what I need anyway. But we're always adding larger hard disks around here, so I'll look forward to using a version of Echo that has fast compression. * * * * * This from [Alberto_Lopez@notes.toyota.com]:
Thanks for the kind words. Your question is an excellent one, and will become an important one for many more people as full time Internet connections become more common in homes. Actually, static versus dynamic IP addressing isn't the important issue. It's connection duration that really counts. Many cable modem users, for example, have dynamically assigned IP addresses but retain those addresses for months on end. For all intents and purposes, they might just as well have a static IP address. I was concerned enough about this question that I called my friend John Mikol, who has forgotten more about TCP/IP than I'll ever learn (I know that sounds strange coming from someone who's written a TCP/IP book for O'Reilly, but it's true nonetheless). John has a cable modem at home. He says he didn't used to worry much about security (although until recently he was able to call up network neighborhood on his home system and view resources on other people's computers throughout the cable company's network), but now he's scared stiff. The real answer is that there is no solution. If you set up your computers or network to be able to get to the Internet, the Internet can get to them. Period. Firewalls and similar measures offer a degree of protection, but anyone who knows what he is doing and cares to spend the time can get into your network. Period. Or, as Casanova once said, "if there's a hole in that chastity belt, I'll find it..." You could spend hundreds of thousands of dollars on equipment, hire black-belt TCP/IP security experts to staff your network full-time, and it still wouldn't make any difference. Someone who wants to get in can get in. Period. Realistically, there's only so much you can do, and your choice of operating system complicates matters further. Linux, for example, is more easily secured than Windows NT. Windows NT is inherently much more secure than Windows 98 will ever be. All of that said, there are a couple things you can do to protect yourself: First, as the Japanese say, the nail with the raised head gets hammered. That's very true here. If you're one of a huge group of ADSL users on that net, chances are you'll simply blend in with the crowd. If there's nothing out of the ordinary to make your network more attractive than anyone else's, chances are no one will spend the time and effort required to hack through even minimal precautions. The other thing, of course, is that implementing strong security serves as a red flag to a bull. If you're one of a million sites using WinGate or a NAT or Linux or something equally commonplace to secure your network, you won't attract much attention. The sites that get the attention are the ones that implicitly or explicitly wave that flag, shouting "We're so secure that no one could possibly break in. Nyah, nyah." Those are the sites that are going to get hammered big time. Second, implement some sort of minimal protection at the border between your network and the Internet. This can be a firewall (hardware or software); a proxy server (hardware or software like MS Proxy Server or WinGate); a Network Address Translator or NAT (again, hardware or software); or using permit/deny filtering by source address, TCP port number, etc. in your router (some ADSL "modems" have such functions. It's worth asking about...) My guess is that you ideally would like something that costs nothing, is perfectly secure, easy to set up and requires no maintenance. As you might guess, there's nothing like that. But the standard security offered by most products is more than sufficient to discourage all but the most persistent or talented crackers. Guard against the 99.9999% of the problem, and don't worry about the true superstars. They have better things to do than crack your network. In my own case, I'd choose WinGate, which I'm familiar with and which provides a reasonable security level with its default settings. Can someone break through that? Sure. But in my case they'd be expending an awful lot of effort for next to no return. Someone more familiar with Linux might do well to choose it. John tells me that there's a single diskette version of a Linux router than can run on an old 486 and provide pretty decent security. I won't bother trying to use it, but it might be worth looking into if you're very concerned. * * * * * This from A5d@aol.com:
You can sometimes pick up manuals for older cameras at photo swap meets or from some of the New York camera stores that handle used equipment. Herbert Keppler wrote a book, The Honeywell Pentax Way, that is long out of print, but you may be able to find a used copy. Check ABE, go to the search page and enter pentax in the title field. I found more than 70 books listed, including Kepler's and many others. The original Spotmatic used stop-down metering (averaging rather than spot metering, despite the name). The Spotmatic F was basically the same camera, but used full-aperture metering. That was nice, because the image in the viewfinder didn't get darker and darker as you stopped down to center the needle. As far as a zoom lens, your best bet would be the used departments of the New York camera stores (I call them that, although many aren't in New York. I actually mean the ones that advertise in Popular Photography. Does Modern Photography still even exist?). Another possibility would be auction sites. Pentax screw-mount lenses continued to be available new for many years after the last Pentax screw-mount camera was sold new, but I can't imagine that they'd still be available new. It's possible, though. It wouldn't surprise me to find that mainland China was still manufacturing cameras and lenses for the 49mm screw mount.
|
|
|
Friday, 9 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] More on the OnStream DI30 tape drive. I've been beating it to death, doing a full network backup every night. My data is now backed up better than it ever has been. Right now, I'm cycling through six tapes, more to beat on the drive than because I really need six full copies of my network data. I'm getting 40 to 45 MB/min on normal local files (less when I include directories with tons of tiny files) and about 22 MB/min across the network. That network slowdown is normal behavior, as I can attest from using other tape drives. As a usual practice, I do a full network backup to tape every Friday. Between times, I use a batch file that backs up changed data from the server to volumes on other boxes throughout the network. I think I may start using this drive with the "Thompson modified 6-tape rotation". That's basically four weekly tapes, Friday 1 through Friday 4, with two daily tapes, Daily A (Monday, Wednesday, Saturday) and Daily B (Tuesday, Thursday, Sunday). So the rotation goes something like this: Monday - Thursday: Daily A, Daily B, Daily A, Daily B That gives me the ability to recover a file that was deleted or corrupted as much as a month previously, and a full backup no older than one day. Worst case, if a tape breaks, I'd have a full backup two days old. At the end of month one (after backing up to Weekly 4), the Weekly 1 tape gets relabeled Daily A and Daily A becomes Weekly 1. At the end of month two, Weekly 2 becomes Daily B and vice versa. And so on, until each weekly tape has been a daily tape and vice versa, when the cycle starts again. That helps even out wear on the tapes. * * * * * This from Paul Robichaux [paul@robichaux.net]:
Well, much though I hate to disagree with a co-author, it *is* true, at least in the sense I meant it. You make a good point that simple unobtrusiveness provides no protection against scanners. But the point I was trying to make was not that one should depend on unobtrusiveness alone. Breaking into a reasonably well-secured system is non-trivial, although it can be done. If you use the default WinGate security settings, your site is reasonably well-secured against attacks. Not perfectly, but reasonably. If you're one of a million WinGate users that all have default security enabled, it's reasonably unlikely that anyone will select you in particular to attack from the group of a million other users. If, on the other hand, you run WinGate wide open, that in itself makes you obtrusive, at least to scanners. Before you become too complacent about your NAT setup making you invulnerable to anything but DOS attacks, let me just mention something that John told me last night. He's currently getting boinked by somebody who's hacking in to a specific machine behind his firewall. The source address of those packets (as viewed on a packet analyzer outside the firewall) is 192.168.X.X. Now, in theory, it's not possible to route packets with that network address across the public Internet. Packets with a private network number are supposed to be discarded, period. The border router at the source should discard them, as should the border router at the destination, and the routers at every intermediate hop. It's conceivable that one or even several of the routers involved is misconfigured and thereby allowing packets whose source address is a private network number to pass. But it's not conceivable that every intermediate router is so misconfigured, and it's certain that John's border router is not. And yet the packets continue. I agree that running a multi-homed Linux router provides security superior to anything you can realistically do with NT (and certainly with Win98). However, my take on what that reader said was that he was a Win98 guy, not a Linux guru. The most likely result of him (or me) attempting to configure a Linux firewall is that nothing will work. If we somehow got it to work, the likelihood is that it would work because we'd left the thing wide-open without realizing it. So I'll stand by my recommendation that readers do their best to remain unobtrusive and also do the best job they can with the proxy server, NAT, or router of their choice. * * * * * This from Frank A. Love [falove@home.com] regarding my query about whether Modern Photography still exists:
Thanks for the kind words. I'm not surprised that Modern went away. It was always a distant second to Popular in circulation. Popular is still around. I looked at it at the library last night. Still the same-old, same-old. I'm in much the same position you are. When I built my first darkroom, Kodachrome was still K-12 and Ektachrome was just moving from E-3 to E-4. Only real men processed color back then... My darkroom equipment is boxed up and hasn't been used in years. Every once in a great while, I'll pull out something like one of my Schneider Componon-S lenses just to admire it. Nowadays, photography is just a tool rather than a love affair. I have a Pentax K1000 with a 1:4 50mm SMC Pentax-M Macro lens and an AF-280T flash sitting on top of odin at the moment. I use it to shot photographs for my books. On color negative yet. I can remember the days when I spit on color negative and shot only large format b&w (120 when I was slumming), and 35mm Kodachrome.
|
|
|
Saturday, 10 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] Here's news. In the turnabout-is-fair-play department, the morning newspaper reports that a snake bit a poisonous man and died. I am not making this up. You can read about it here. Apparently, the man had recently undergone chemotherapy for cancer. The snake chomped him, and subsequently died. I hope that serves, as the French generals said when shooting their own rebellious troops during WWI, as un avertissement pour les autres. * * * * * This from Werth, Timothy [timothy.werth@eds.com]:
The answer, as usual, is "it depends." Briefly, I compared 10BaseT and 100BaseT by copying files directly from one machine to another. I had two test data sets. The first was a single 200+ MB file. The second was a group of more than 5,000 files in many subdirectories, totaling about the same 200+ MB. Relative to 100BaseT, 10BaseT required twice as long to copy the big file, and about 40% longer to copy the group of small files. But that greatly understates the value of 100BaseT, which wasn't even breaking a sweat during the copy. 10BaseT pulsed between 0% and 80% network utilization, but spent most of its time during the transfer at very high utilization. 100BaseT, on the other hand was barely flickering. The problem, and the reason that the large file copied so much faster than the small ones, is that the network speed isn't the bottleneck for a simple machine-to-machine copy. Instead, issues like operating system overhead and file system overhead control how fast data is being delivered to the network interface. But in a real network, where many machines are contending for network bandwidth, the bigger 100BaseT pipe pays off big time. On a heavily loaded network with many machines transferring data, 100BaseT will indeed be much faster than 10BaseT. Perhaps not ten times faster, but something on the very close order of ten times faster. My short take: if you're buying new network cards, always buy 100BaseT. If you're building a new network, buy 100BaseT cards and hubs. There's just not enough price difference to make it worth saving a few bucks by installing 10BaseT. If you have an existing small 10BaseT network, don't replace what you have, but buy 100BaseT components when you add equipment. Once your network gets to ten machines or more (depending on how much data they're transferring routinely), consider upgrading 10BaseT hubs to 100BaseT. The key is network utilization. So long as you're averaging 25% to 40% on 10BaseT, moving to 100BaseT will yield a noticeable but not huge real-world improvement. If you're much higher than that, 100BaseT starts to pay off. * * * * * This followup from Werth, Timothy [timothy.werth@eds.com]:
Sorry, I should have stated that explicitly. While backing up portions of network volumes that have a normal distribution of file sizes, I've seen some improvement while watching the instantaneous data rates shown by the backup software. Typically, what would have been running at perhaps 20 MB/min might run at 25 MB/min. But when the backup gets to the folders with bunches of small files, transfer rates drop back to what I was getting with 10BaseT. That makes sense, because watching the 10BaseT load indicators during such backups showed that even 10BaseT was barely breaking a sweat. * * * * * Another followup from Werth, Timothy [timothy.werth@eds.com]:
Yes, when I first read that Heinlein quote in The Notebooks of Lazarus Long back in 1973 or thereabouts, I thought Heinlein was just being clever. But the more I thought about it, the more I realized that he was serious (and right). I've tried to do that ever since, but I don't always succeed. * * * * * This from Chuck Waggoner [waggoner@gis.net]:
Sorry about the scanner link. I could have sworn I put it in, but I guess not. It's fixed now. As far as the divider line, that's what happens when one makes a "minor" change. I decided that the line was "prettier" than the asterisks and wouldn't increase download times significantly, and so I started using it. I work at 1024X768, so I never even thought about the screen width issue. It's also fixed now. One day, I will learn the "if it ain't broke, don't fix it" rule by heart. As far as backup rotations, you might want to consider how long you want to retrieve data for. The classic 10-tape Grandfather, Father, Son rotation uses daily, weekly, and monthly tapes and allows you to retrieve data from some months back. You can easily modify it to keep a dozen monthly tapes or more if you want to archive data for a year or more. I've never needed to revert that far, but I probably should consider something like that. On the other hand, I'm now doing a periodic archive to CD-R which really accomplishes the same thing, for my data if not for the other files. * * * * * This from Jim Robertson [address removed by request]:
No. You're correct that K-12 "couldn't" be processed in a home darkroom. But I did it anyway, and the same later for K-14. The problem is that Kodachrome is actually a black and white film with three separate emulsion layers (plus several additional layers for other purposes). Each emulsion layer is sensitive to a different color of light, red, blue, or green. With Ektachrome, each emulsion layer also has embedded color-couplers that react with by-products of development to create a dye that is the complementary color for that layer, cyan, yellow, and magenta, respectively. Unlike Ektachrome, Kodachrome doesn't have color-couplers embedded in the emulsion. All that means is you get to add them yourself during processing. The process is very complex. You develop the film three separate times, using a different developer each time. The developer itself contains the color-couplers for the layer you're developing. Those couplers combine with the waste products of development to create the necessary dyes. In between developing steps, you have to expose the separate emulsion layers with monochromatic light (that was actually my main difficulty) and perform numerous subsidiary washing. bleaching, and other steps. It wasn't really hard, other than finding the information and chemicals I needed and maintaining very close control of pH, but it was tedious. Developing a roll of film took me a day, and the quality wasn't all that great compared to commercially processed Kodachrome, but I did it for the experience. After I developed my first roll of Kodachrome, I sent Eastman-Kodak a nyah-nyah letter, enclosing some slides. They wrote back, politely but firmly telling me to stop kidding them. I then sent them back an uncut roll of Kodachrome that I'd developed as a negative rather than a positive. They offered me a job, but I explained that I was only 15. They then offered me a full scholarship at RIT if I'd come to work for them afterwards. I think I still have those letters around somewhere. I should probably have taken them up on their offer, but then my entire life would have been different. It's probably good that I did things as I did.
|
|
|
Sunday, 11 July 1999 [Last Week] [Monday] [Tuesday] [Wednesday] [Thursday] [Friday] [Saturday] [Sunday] [Next Week] What really disturbs me about software is not consistent bugs. I can deal with things that don't work the way they're supposed to, but malfunction the same way every time. What really disturbs me is stuff that works inconsistently. I've mentioned before things like the font size changing unpredictably in Internet Explorer. Pournelle has been going back and forth with Microsoft tech support about inconsistencies in how pastes to a FrontPage 2000 page work. Sometimes formatting carries over, but usually formatting is lost. I've been involved in that as well, mainly to confirm to Microsoft that what Pournelle is seeing isn't specific to his system or Windows 2000, because I'm seeing it also under NT4. Last night I saw yet another example. Actually, this has been going on for years. I run NT on nearly all my production systems, and I use the Blank Screen screen blanker. Usually it works, but sometimes it doesn't. There's no rhyme or reason for when it fails to blank the screen. The problem occurs on half a dozen systems and has been happening sporadically since I was running beta versions of NT4. Obviously, a failure to blank the screen is no great loss, but the fact that it happens is disturbing. * * * * * This from ROBERT RUDZKI [rasterho@pacbell.net]: (in case you're wondering about all the "xxxxxx" portions, I asked Robert to pull some stuff that was not Politically Correct because I don't have time to deal with flame mail.)
I've never owned a Leica, but I've used several of them, including one model from the 20's or 30's that had a winding knob rather than a winding lever. They are beautifully constructed and have superb lenses, but I could never justify paying what their equipment costs new. But it is wonderful stuff. As far as the GM suit, I concur. Just as in calculating a bullet's stopping power, what counts in such a collision is momentum (m*v) rather than energy (0.5*m*v^2), but your point is valid nonetheless. That a gasoline tank ruptures when a car is rear-ended by another vehicle traveling 70 mph is a matter of physics rather than faulty design. A point I have been making for years is that how punitive damages are awarded has in large part been responsible for the litigiousness of our society. By their nature, punitive damages are intended to punish the malefactor rather than benefit the victim. But in order to be effective against a huge company, those awards must be large. Because they are awarded directly to the victim, that victim and more importantly that victim's lawyer benefits from them. The solution is simple. Make punitive damages payable only to an established (and disinterested) national charity of the victim's choice (not his own church or local school, for example), and mandate that attorneys get no portion of punitive damages. Victims should receive only compensatory damages, and lawyers should be paid only on the basis of compensatory damages. To minimize frivolous lawsuits, it'd be better still to make it illegal for lawyers to work on contingency, period. Lawyers should be paid on a flat fee or hourly basis, not on a percentage of the eventual award.
|