Week of 6/14/99

Tomorrow is the due date for this quarter's Estimated Taxes, so I'd better get that done before I start anything else. Those of us who are self-employed write checks for taxes due rather than having them withheld. If you get a paycheck from your employer, the tax bite is pretty much invisible. You can certainly look at your check stub to see how much the government is stealing from you, and it does become obvious once a year when you do your income tax return, but you don't see that money in the first place, so it's less aggravating.

When you have to actually sit down and write a big check every quarter (in my case, two checks; one federal and one state) it becomes much more concrete. It also becomes much more obvious that Social Security taxes are twice what wage-earners think. In their case, their employers pay half, while those of us who are self-employed pay the full amount. Of course, it's all a shell-game, and wage-earners in fact pay twice what they think they're paying in Social Security taxes. It's just that employers write a check directly to the government instead of paying that money to the employee first.

The government aren't complete idiots, so they'll keep withholding in place. Most people don't know that withholding was a "temporary" measure instituted during World War II and intend to last only "for the duration of the emergency." Of course, "temporary" is government-speak for "permanent," and that's the way it's turned out.

And now I'd better get back to work to earn some money to feed the governments' voracious appetites. At least I get to keep some of it.

* * * * *

This from Richard Michael Todd [rmtodd@mailhost.ecn.ou.edu], referring to yesterday's notes:

Today on your notes page you wrote:

Here's an amazing true fact. Did you know that when you copy a CD to a CD-R, the result is *never* an exact copy of the source? I had been under the impression that the process of burning a CD-R was a straight digital copy operation like using diskcopy to copy a diskette. Not so. In fact, it more resembles an analog copy like photocopying a photocopy or duping a VCR tape, with all the generational degradation that implies. Each generation introduces additional errors.

Um, you're kidding, right? All a CD-R drive gets feed is the user-level data; the Reed/Solomon ECC codes and the 8/14 (IIRC) low-level channel codes get done by the drive. I seriously doubt CD-ROM drives even have a way of letting the user see the low-level coded datastream.

Well, that's what I thought. It seemed reasonable to me that when copying a data CD, the information would be supplied byte-wise from the source CD. I mean, that's what has to happen when you list a directory or run a program directly from a CD, right?

Apparently, that's not the case when copying CDs, however. See Andy McFadden's CD-R FAQ for more details. Unless I misunderstand this entirely, it appears that when doing a CD-R copy of a CD source, the CD source is supplying a raw bitstream rather than formatted and corrected data. If I'm understanding this wrong, please tell me.

* * * * *

This follow-up from Richard Michael Todd [rmtodd@mailhost.ecn.ou.edu]:

Well, it seems to be implying that there are two modes, raw and cooked, which on reading either bypasses or switches on the 3rd stage of Reed/Solomon ECC on reading, and similarly on writing. This is, on reflection, not overly surprising, since audio CDs use only the low/level 8/14 code and the first two stages of R/S ECC, whereas data CDs use a third stage of ECC for higher reliability -- you can tolerate an occasional dropout in your Van Halen CDs, but not in your OS installer.

I am surprised that anyone would think of coding a data-CD-copying program and not either have it used the cooked mode (making the CD/CD-R do the third stage ECC) or do the 3rd stage ECC in software. In any case, the first two stages of ECC should still give moderately low Bit Error Rates (dunno the exact values, but I'd suspect something in the neighborhood of 10^-6 to 10^-7). So even with the 3rd stage ECC off, you might get an occasional garbled sector, but most of the disk would be correct. What you said the other day implied to me that the disk you copied off a CD-R was totally unreadable, with contents bearing no resemblance to the original.

You obviously know so much more about this than I do that I probably don't even know what questions to ask you, let alone understand the answers. Basically, the situation is this: I have a CD-R that is a copy of an application program distribution CD. I can copy the files off that CD to a hard disk with no problem. I can install the application directly from the CD with no problem. When I try to do a disc-at-once copy using the Adaptec disk copy utility in "test and burn" mode, the program says that the disk was copied successfully. But I cannot read that disk in any CD-ROM drive. I don't think the problem lies with the CD-R drive or the media I've been using. This same source CD-R disk has failed to copy properly in two other CD-R drives, one an HP 7100 and the other an HP 8100. The only thing I can conclude is that there's something about the source CD-R disk that will not allow it to be copied successfully to another CD-R disk.

* * * * *

Another follow-up from Richard Michael Todd [rmtodd@mailhost.ecn.ou.edu]:

You obviously know so much more about this than I do that I probably don't even know what questions to ask you, let alone understand the answers.

Yes and no. I understand the basics of the theory behind the CD encoding scheme (being a grad student in EE/communication theory, I find things like error-correcting codes interesting). Alas, I don't actually have a CD/R to play with here, but am thinking of getting one, which is one reason why I've been interested to see how your experiences went. :-) I do know people around here who do have them, and I don't recall any of them ever saying there were problems in copying copies of data CDs. I'll ask around tomorrow.

Furthermore, I'm much more familiar with the Unix world than with the Windows realm, so I'm not entirely sure what to suggest to try. (I know what sort of things I'd try playing with if it were me this was happening to, but I don't know what the equivalent procedures would be for NT/95. Sorry.)

Basically, the situation is this: I have a CD-R that is a copy of an application program distribution CD. I can copy the files off that CD to a hard disk with no problem. I can install the application directly from the CD with no problem. When I try to do a disc-at-once copy using the Adaptec disk copy utility in "test and burn" mode, the program says that the disk was copied successfully. But I cannot read that disk in any CD-ROM drive.

By 'cannot read' you mean that the disk gives I/O errors, or that it reads the data okay but the data is corrupted (not recognizable as an ISO filesystem)? The first thing I'd try on Unix would be taking the suspect CD you just wrote and trying to just copy the whole CD from the CD-ROM drive to the disk (dd if=/dev/cd0 of=some-file-name bs=2k would be the command I'd use). Does your software have a way to let you make a disk image of the ISO filesystem from the CD-ROM onto your hard disk? If so, does that work with your recently-made CD-R? If so, that indicates that you wrote data successfully to the CD-R, but that for some reason the data written was not a valid ISO filesystem. (Hmm. Does Norton Utilities let you look at hex dumps of CD-ROMs sector-by-sector like you can with hard disks?)

By "cannot read" I mean that when I insert the disk in a CD-ROM drive, one of two things happen: (a) on one system, inserting the CD-R disk in the drive and attempting to log to that drive in Windows NT Explorer yields a CRC error and a refusal to display the contents of the disk; (b) on a couple other systems, the system doesn't even recognize that a disk is in the drive, returning a "Drive not Ready" error. This same behavior is exhibited on disks made in three different CD-R drives from that same source CD-R disk.

Thanks for your suggestions.

* * * * *

I'm replicating this discussion on CD-R stuff over to Current Topics so that it will be easier to find later.

Tuesday

Tuesday, June 15, 1999

[Current Topics Page]

Some excitement yesterday just before lunch time. I was sitting here in my office typing away when Barbara came in and told me not to let the dogs out unless I tethered them. Ordinarily, when I go downstairs to make lunch for my mother, I just let the dogs out the back door loose. They stick pretty close, chasing squirrels in our back yard and those of our adjoining neighbors, who've actually told us they appreciate rodent-free yards. I keep a pretty close eye on the dogs, checking every couple minutes. After five or ten minutes, I call them back in. They're friendly dogs, and no threat to anything except yard rodents.

When I asked Barbara what was going on, she said that a dog had bitten a girl down the street. The girl's grandfather shot at the dog, and three or four police cars were sitting in front of his house. We still don't know any details about how badly the girl was bitten, whether she was doing anything to the dog at the time, whether or not the grandfather wounded or killed the dog, and what's going to happen to him.

Police generally take a reasonable view of things like this. If the dog was truly attacking savagely, I'm sure he won't be charged for discharging a weapon within city limits. If, as I fear, the dog just nipped the girl and was not really a serious threat, that guy is going to be in a lot of trouble. Police rightly take a dim view of bullets flying around a residential neighborhood.

In my experience, dogs almost never attack a human unless they are rabid or the human provokes them. Reports of unprovoked attacks on children are usually bogus. It usually turns out that the child was intentionally aggravating the dog. In one case recently, a girl was attacked and mauled by a chained dog. As it turned out, she and other children had been stopping on their way home from school every day to throw rocks at the dog. One day, the dog had simply had enough. It lay in wait for its tormenters with some slack on its chain. The girl approached too closely and the dog mauled her badly. Although I'm sorry that the girl was injured, I must say that I'd have acquitted the dog. Humans aren't the only species entitled to defend themselves. They put the dog down, of course.

Twenty years ago, I worked for an industrial security company in Pittsburgh. We did stuff like protecting plants during strikes, sometimes exchanging gun fire with strikers. We used trained protection dogs and attack-on-command dogs heavily. I talked one time with one of the trainers. He said that protection dogs, which attack only when their master is threatened, were relatively easy to train because the training simply reinforced the dogs' natural instinct to come to the defense of a pack member.

Attack-on-command dogs, on the other hand, were very hard to train, because dogs instinctively avoid attacking people who are not threatening them or their pack. He told me that only a tiny percentage of the Doberman and German Shepherd puppies they saw were suitable for attack-on-command training. They simply refused to do it. Or they would do it sometimes, but not always, which was not acceptable for a trained attack dog.

We had many protection dogs, which were trained to attack if their handler was attacked, or if they spotted someone taking aggressive action like drawing a gun or a knife. But these dogs would not attack unless they judged there was reason to do so. Our most expensive dogs--$20,000 to $30,000 even then--were all certified Shutzhund III und Ferretenhund (protection dog III and tracking dog) with attack training. These dogs would reliably attack on command at any time, and regardless of who they were ordered to attack. But those were truly rare dogs.

Then there were guard dogs, which would attack anyone, including their handlers. These dogs were trained by intentionally mistreating them from the time they were puppies. They were randomly praised and punished until they were so confused they didn't know what was going on. What they learned was that no human was to be trusted, ever. They were essentially trained to be vicious and psychotic. Their purpose was to be left unattended in an area that needed to be guarded, where they would attack any intruder. None of us much liked this whole idea, and so we didn't have any guard dogs.

* * * * *

I've been working a bit with the Office 2000 applications. There are some nice new features, but Microsoft has, as usual and with the best of intentions, made the products worse in some respects than their predecessors. They continue their love affair with what, for lack of a better term, I'll call "things that move around instead of staying put like nature intended."

I first noticed this with Outlook 97. The first few times I moved messages to folders, I thought it was kind of neat that Microsoft automatically moved the most recently used folders to the top of the list. As it turns out, of course, that's a horrible idea. Such things are meant to be anchored. The human brain quickly learns where they always are and can move a message to them almost without thinking about it. With a folder list sorted by most-recently-used, you frequently have to search the list of folders to figure out where the one you want has moved to now. Not a good idea. I'm not sure what their designers were thinking.

It's gotten worse with Office 2000. Now we have menus that don't always show the same items. In theory (a poorly thought out one), this helps reduce user confusion by presenting only menu choices that the user is likely to want. In practice, of course, it's much harder to use such a variable menu scheme than it is to use fixed menus. At least this option can be toggled off, although it is set on by default. The Outlook folder list has no such choice.

* * * * *

It's off to the dentist for me. Ugh. I'll probably be wasted for the rest of the day.

Wednesday

Wednesday, June 16, 1999

[Current Topics Page]

Well, I survived the dentist yesterday, although I didn't get all that much done yesterday afternoon.

I've about given up on IE Favorites. Thanks to a tip from one of my readers last week, I was at least able to avoid the problem of clicking on a favorite bringing up the site in a different window than the active one. But I found this workaround too clumsy. It requires extra mouse clicks, and I have trouble getting used to it. I finally decided to bite the bullet and create my own links page. I've set this as my Start Page in IE, and I can always get to it just by clicking the Home icon. It's still very much incomplete, but adding new links is easy enough. I'll play around with this a bit, but I suspect I'll abandon IE's Favorites forever.

I'd better get back to work.

* * * * *

This from Shawn Wallbridge [swallbridge@home.com]:

I was reading at Jerry's site that Pair has told him that his site is too big. I am not sure how big his site is, but I am sure our web pages have more files and more MB's. These are hosted on an NT box running at our local ISP.

Currently we have 2 sites.

www.elections.mb.ca

This site has about 1700 files and about 50MB of data. This is our base site. We post all the financial data for every candidate. We have many small pages, but not many graphics. We are currently in the middle of a complete redesign of our site, which should be posted later this month.

www.boundaryredist.mb.ca

This site has about 600 files and about 120MB of data. This site has maps of the electoral divisions in our province and the changes that were made to them due to population shifts.

Our ISP is Pangea.ca a local company. I have talked to their 'NT' guy and they set up the NT server as a test and it seems to be working quite well. When uploading I have never had any troubles. I am sure the server we are on has minimal traffic. I don't think our site gets many hits (if any) but we are happy with the service we get from Pangea.

We are also building a section of the elections site to cover the upcoming election. We plan to have an ASP page that will allow you to search by address to see what electoral division you are in. This will be done using MS Visual InterDev.

So....FrontPage and NT work well for us and our site is (probably) bigger than Jerry's.

FYI

Shawn

Thanks. The key question, though, is are you running FP extensions? These are what seems to be causing the problem. I have no doubt that Jerry would have no problem at all using FrontPage on pair if the FP Extensions were not installed there. But he needs the extensions for the Search function.

The consensus among the people I've spoken with is that the FP Extensions become hinky with larger sites. I'm not exactly sure what "larger" means, except that overall site size in MB, number of files, and number of links may all have something to do with it. When I checked several days ago, Jerry's site was something over 25 MB, about 1,400 files, and about 3,200 links. My site, which has also started misbehaving a couple of weeks ago, is only about 11 MB, but has about 1,700 files and 6,500 links.

pair tech support is surprised that I am having problems with my site. They say that the problems usually start once a site exceeds 20 MB. But they concede that my problems have exactly the same symptoms from my point of view (although they're not seeing the server time-outs on their end with my site that they normally do when this problem manifests.)

Jerry seems convinced that the problem is that pair servers aren't fast enough, but I remain convinced that the problem is attempting to use FP Extensions on a site that's too big for them to function reliably.

* * * * *

This from Bo Leuf [bleuf@leuf.net]:

You wrote on the web...

"Then there were guard dogs, which would attack anyone, including their handlers. These dogs were trained by intentionally mistreating them from the time they were puppies. They were randomly praised and punished until they were so confused they didn't know what was going on. What they learned was that no human was to be trusted, ever. They were essentially trained to be vicious and psychotic."

Not unlike what happens to some people too, though one likes to imagine people at least have the potential to think their way out of this kind of conditioning.

...and perversely associated to this...

"With a folder list sorted by most-recently-used, you frequently have to search the list of folders to figure out where the one you want has moved to now. Not a good idea. I'm not sure what their designers were thinking."

That functionality sure feels like random praise and punishment. If you keep referring to most recently used, great, it's at the top. Anything else, and it's a whack on the fingers because the list is to all practical intents "random". Adaptive menus are even worse I find, because I quickly noted that these hide as yet unused options. Yuk -- the first time I encountered this, I wasn't even aware that it was active, and searched in vain for options I knew had to be there but couldn't find. I was very happy to find the setting to turn this off.

Strangely, I have heard people who say they *like* adaptive menus and most-recently-used lists, and couldn't imagine being without them. I've not figured out how they structure their mental map of how to find things, except to surmise that they are using the same strategy as hunt&peck typists who never learn the qwerty order -- i.e. they systematically scan until they find the item they want.

I hadn't made that connection, but it makes sense when I think about it. No wonder using Microsoft software sometimes makes me feel like biting someone...

Thursday

Thursday, June 17, 1999

[Current Topics Page]

I've set aside some time this weekend to get my network converted over to 100BaseT. For many years, I used and recommended 3Com networking cards, hubs, and other components, but I'm not as happy with them as I once was.

The market for simple networking equipment is interesting. Until recently, the stuff divided by price into two distinct classes. On the one hand was the "inexpensive name-brand" stuff from lower-tier companies like AddTron, LinkSys and NetGear. On the other was the more expensive name-brand stuff from upper-tier companies like 3Com, Intel, and HP. A small standalone hub might cost $125 from one of the lower-tier vendors and two or three times that from one of the upper tier. Same thing on NICs. A lower-tier NIC might be $25 or $30, whereas one from an upper-tier vendor might be $75 to $90. That kind of difference starts to add up.

But at least some of the upper-tier vendors have started to get more competitive, which leaves little reason to go with the lower-tier stuff. For example, comparing 8-port Fast Ethernet hubs, I notice that I can get a LinkSys model for about $125 or an Intel model for less than $20 more. Same thing on network cards. I can get a LinkSys or NetGear Fast Ethernet NIC for about $25, or get an Intel for $40. That's a no-brainer. I'll go with the Intel.

I should be getting an Intel InBusiness 8-port 10/100 Ethernet hub tomorrow, and I already have 10/100 NICs in most or all of my machines. Those are a mix of 3Com and LinkSys cards, but they should work fine with the Intel hub. I'll probably migrate to Intel 10/100 NICs as I build and upgrade the systems. I'll report later in more detail about what I find.

* * * * *

I've also been working quite a bit with my new Smart & Friendly CD-R drive. I'm convinced that Windows 98 is not a good environment for CD-R. I rebuilt the system where the CD-R drive resides, installing Windows NT in place of Win98. Although I still can't copy that problem CD, I've burned numerous other CDs with no problems at all. Last night, I duped an audio CD at 4X, expecting the resulting copy to be one of those Rice Krispies disks I keep reading about. But I played the copy in our home audio system, and could detect nary a snap, crackle, or pop.

* * * * *

This from Chuck Waggoner [waggoner@gis.net]:

I'm afraid IE's Favorites is not the only deficiency of the new IE5. I've now played around with Synchronizing for the last 2 weeks. Besides Synchronizing being a much harder word to type than the old Subscription, like all things Microsoft, more featuritis has crippled usability by making it far more complex, which will likely limit its implementation to only the most dedicated and savvy of users.

No one has come forward to answer my call for what is it in IE5 that replaces IE4's 'Manage Subscriptions'? The closest I have come is the '\Windows\Offline Web Pages' folder. It's similar, but lacks much of the information the IE4 Subscription Manager contained, such as: next update time; listing of the exact update schedule in plain English; and, most importantly, the red star on the item icons, telling you of a page that was updated, but which you have not yet read.

What makes IE5 Synchronizing pretty much useless, is its insistence that you must NOT be in the 'Work Offline' mode when it comes time for an automatically scheduled update. Now, the whole point of this was to enable the user to read pages offline without using connect time to browse, so I find myself almost always forgetting to put the darned thing back online after reading updates in offline mode. If offline, when update time rolls around, it will connect as if it's going to ask for the pages, but then promptly disconnects, showing a download failure dialog box. This was not a problem with IE4: pages updated whether you were online or offline.

And while the failure dialog box is more than IE4 showed when things went wrong, nonetheless it never gives a reason for failure--it's up to you to guess. Worse, when there is a failure, it very handily lists all the pages that were involved, but does not give you an option to switch from offline to online and try them all again. Instead, you've got to remember which pages failed and check them individually in the Tools/Synchronize dialog box of an IE5 window or over at the '\Windows\Offline Web Pages' folder, in order to give them all a go again manually.

I've found that if you make ANY change to the original URL Favorite (which you must save first, before Synchronizing is possible)--even something as innocuous as changing the name alias that the Favorite displays,--you lose the Synchronizing information for that URL, and must re-enter ALL Synchronizing parameters again from scratch. This was not the case with IE4; IE5 is obnoxious in this regard.

There are a few more options over IE4 on what to download--e.g. images, sound and video, ActiveX, follow HTML pages only--and this helps speed up downloading, but as is normal for MS, you can't set global defaults of what you want those to be, and I find myself having to go into that dialog box and make changes for every single page I'm interested in adding to the list. My preferences for most are the same--they just aren't the same as what Microsoft has thought they initially should be.

As with the IE4 implementation, occasionally some pages say they have been updated but really have not been; at other times, pages will say they have NOT been updated successfully and will show 0 bytes size, but all of the HTML text really HAS been successfully retrieved--in most cases that's all I need to call it success.

All-in-all, IE4 Subscribing was much more user-friendly, if somewhat less reliable at successfully downloading all items. IE5 Synchronizing is much harder to understand and learn--by a quantum amount--and will fail to download anything if you happen to be offline: a MAJOR flaw.

The conflict between Outlook and Synchronizing hanging up the modem on each other if they happen to want it at the same time, remains. And quite oddly, if I was set to 'offline' in IE4, whenever Outlook dialed in, it reset IE4 back to 'online'. I thought this was a nuisance at the time, but would welcome it now, as it would put me back online when I forget, so there would be fewer Synchronizing failures with IE5.

I can't think of anything more useful than the concept of this automatic download feature for later offline viewing. It has kept me on top of important information on several occasions and has significantly reduced my overall connect time. But this IE5 Synchronize implementation is not likely to attract any except those like me, who discovered it in IE4 and will make do with the horrible 'advancements' in IE5. It is VERY hard to make it work.

--Chuck Waggoner [waggoner@gis.net]

I wish you'd stop with the weasel-wording and tell us what you really think. I agree that IE's synchronize is a great idea that they've implemented pathetically. I gave up completely on scheduled updates, because I could never get them to work properly. I only use the subscription feature for one site now--The Register--and I invoke it manually each morning to download the new stuff from that site (which is pretty slow most of the time). I read my other "daily" sites while synchronize runs in the background. Other that that, I don't find it usable for anything.

* * * * *

This from Jan Swijsen [qjsw@oce.nl]:

In my experience, dogs almost never attack a human unless they are rabid or the human provokes them. Reports of unprovoked attacks on children are usually bogus. It usually turns out that the child was intentionally aggravating the dog.

We had a few dog attacks on children in Belgium recently. In most cases the child was a member of the family or at least a regular visitor. Often an external cause was pointed to, such as an overflying hot air balloon or a sudden thunderstorm. I am not a dog expert but I accept that such things could unsettle a dog. One of the main problems here, I think, is that almost all these accidents happened when the dog and the child were alone, without an adult present. Maybe an unsettled dog looks to some superior (pack leader?) for reassurance and probably a child may, in such conditions give, unwittingly, the wrong signal.

Anyway, in your discourse about dogs you mentioned 'well trained' a few times. I guess that could be the underlying problem here because few dogs are well trained. It is sad to see that a lot of people want a pet dog but are not willing to invest (mainly time) in training.

Svenson

I'm not a dog expert, either, although I've had Border Collies for more than 40 years now. I don't doubt that attacks happen, but they are very rare. Certainly rare enough that it always makes the newspapers, which is an indication in itself. As I said to Barbara yesterday, the number of children who have been attacked by dogs pales compared to the number of children whose lives have been saved by dogs. On balance, there's no question in my mind that dogs are children's friends.

As you say, many people do not understand dogs, even those who own dogs. A dog may use its teeth on a person in three circumstances:

First, it may nip someone as a warning to that person to stop doing something the dog doesn't like. A nip is standard dog behavior. One dog does the same to discipline another dog. Although it may (or may not) break the skin, the dog doesn't intend a nip to do damage. Also, dogs usually escalate to nipping only after a person has ignored growling, raised hackles, and similar threat displays. But such occurrences are often reported as attacks, even though no real damage was intended or done.

Second, a dog may snap at someone. A snap is completely involuntary on the dog's part, and is simply a reflex reaction to pain, fear, or surprise. Ask any vet about a dog snapping. A snap can do real damage, and all children should be taught to avoid surprising a dog or touching a dog that is obviously distressed. But, again, a snap is not voluntary, and one can't really blame the dog for a reflex action. Snaps are also often reported as attacks.

Third, a dog may actually attack. It is this circumstance--intentional, aggressive action intended to harm a person--that is very unusual.

You're right about training. Few people invest the time needed to properly train a dog. And few people take the time to teach their children how to interact with dogs. If they did, there would be many fewer confrontations between dogs and children.

* * * * *

This from Tom Syroid [tsyroid@home.com]:

Here's an interesting review of FP2000 for you. It mentions some things that even I didn't know existed.

Thanks.

Friday

Friday, June 18, 1999

[Current Topics Page]

UPS showed up yesterday morning with my new Intel InBusiness 8-Port 10/100 Fast Hub, a day earlier than expected. Of course, I had to drop what I was doing and install it. The hub itself is charcoal grey, and appears to be well designed and constructed. The first thing I always check on a new piece of equipment is the little things, on the theory that if they get the small stuff right, they're also likely to have gotten the major stuff right.

I found three minor features that tell me Intel got this one right: First, the hub has a power switch. Not a major issue, perhaps, but most small hubs, including those from major manufacturers, don't bother to include one. It costs a bit extra to include a power switch, but it's much easier to throw a switch when you need to work on the hub than it is to disconnect the power at the rear jack or fish around under a desk to find the power brick.

And that brings up the second nice feature. Most small hubs include a standard power brick. I hate those things. There's no way to plug one into a standard power strip without covering one or more additional receptacles. Also, I mount my power strips on the underside of my desk, with the receptacles facing down, so my choice is either to leave the brick dangling precariously or to use a Tie-Wrap to secure it. Intel did things right. The Intel power brick comes in two parts: a standard brick with the low-voltage cable hard-wired to it, and a separate, detachable standard PC power cord that fits a receptacle on one side of the brick.

The third feature is a CableKeeper ring that snaps into the rear of the hub and helps route and secure the rats' nest of cables that connect to the back of the hub. Most 8-port hubs resemble a giant squid, with little blinking green eyes and eight dangling tentacles. That CableKeeper ring does a lot to keep things neat.

Installation went smoothly. I shut down all my computers, moved the cables from the old 3Com 10BaseT hub to the new Intel 10/100BaseT hub, and applied power to the hub. I did notice that the old hub also had a 10Base2 coax cable attached to it, but I assumed that that was a holdover from the days when I ran a thinnet network. I powered up the new hub and turned on all the computers. The Intel hub automatically recognized all the computers as being connected at 100 Mbps, which it indicates with an orange LED. Devices connected at 10 Mbps display a green LED.

I was a bit puzzled when my resource server failed to map drives to the other machines on the network, but I assumed that that happened because the other machines weren't yet up and running. Once all the machines were running, I logged on to all of them, including kerby, my main workstation. I fired up Outlook, expecting it to go out and retrieve my mail. At that point, I went to the kitchen to get some Coke and do a couple of other things. When I returned five minutes or so later, I didn't have any mail, and the modem wasn't lit up. That was odd.

After thinking about it briefly, I finally realized that the problem was that my resource server--which runs the WinGate proxy that shares Internet access with the network--connects to the network using the 10Base2 coax cable. Duh. Fortunately, it was still connected to the old 3Com hub, and that hub still had power.

Well, that was easy enough to solve. The 3Com hub has a switch that toggles one of the ports between Normal and Uplink. All that switch really does is swap TX/RX on that port, which allows you to link to another hub with a standard Ethernet cable instead of a cross-over cable. Now all I needed was another standard Ethernet cable. I was sure there were a bunch of them somewhere in this office, but I had no idea where. So, I stole the cable from my testbed computer and used it to link the hubs. It worked perfectly. The resource server and the rest of the network saw each other fine, and WinGate worked again.

All told it took less time to get everything running than it probably took you to read this. The Intel InBusiness 8-Port 10/100 Fast Hub works, and it works well. If you're looking for a hub for your home or small business network, put this one on your short list. It won't disappoint you.

* * * * *

This from Michael Baker [solo32@mindspring.com]:

I've been enjoying your daynotes for a while now. Keep up the good work!

I have come across a problem with long filenames in NT 4.0. I'm attempting to encode a bunch of .wav files to .mp3. I'd like to do this with a batch file. However, I've noticed that the cd command doesn't seem to work with file names that have spaces in them. The help file states that cd does not treat spaces as delimiters. Well, this doesn't seem to be the case. I try this: cd tori amos. NT replies with "too many parameters - amos". I try: cd "tori amos". That returns "parameter format not correct - 'tori".

The dir command works fine. I haven't tried copy yet. This is rather irritating. It's bad enough that NT isn't case-sensitive. Btw, these files are in a NTFS partition.

Have you or any of your readers come across this??

Regards

---------------------

Michael Baker
solo32@mindspring.com

P.S I'm writing this while burning a CD. SCSI is great!

Thanks for the kind words. I have not encountered the problem you described. Just to verify it, I went to a command prompt, changed to c:\ and typed:

cd program files

Windows NT 4.0 Server changed me to the c:\program files directory properly. I don't know if you will find this useful, but many people aren't aware that you can use wildcards in directory names. For example, rather than typing the program files directory name in full, I could have typed:

cd pr*

and Windows NT would have changed me to the program files directory. Unfortunately, if more than one directory fits the mask, Windows NT simply changes you to the first directory that fits the mask rather than popping up a list. For example, I created the directories c:\aab and c:\aac. Typing

cd aa*

changed me to the c:\aab directory immediately. Still, wildcards may let you do what you need to do.

And I don't doubt that SCSI is better than IDE for burning CDs. I bought an IDE CD burner intentionally because I was likely to have more problems with it than with a SCSI burner. I know that sounds odd, but my job is to encounter problems and figure out how to avoid or work around them.

Saturday

Saturday, June 19, 1999

[Current Topics Page]

Pournelle's problems with FrontPage and pair Networks continue. I have problems, too, but not nearly as severe as his. Last night I got to thinking about what I could do to simplify my web somewhat. The first obvious thing was to get rid of some files that weren't being used. As it turned out, there were quite a few of them.

When I first started using FrontPage, I enabled Themes, which are canned color-coordinated templates for creating a web site around. Big mistake. In theory, themes allow a beginner to create an attractive, consistent site. In practice, I wouldn't wish them on my worst enemy. Ignoring the fact that they are not very attractive, the main problem with Themes is that they are graphically intensive and create huge numbers of graphics files. Each button on each page has its own graphic file. The upshot is that theme pages are pigs that take forever to download. I stopped using Themes soon after I began experimenting with them.

You'd think that removing the theme would also remove all the associated graphics. Not so. FrontPage expects you to either leave them in place or delete them manually. I actually did go in some months ago and delete hundreds of superfluous Theme files, but there were still scores of them in place. Until my site started timing out during publishing, there wasn't a whole lot of reason to get rid of those surplus files.

Last night, I went in and found all the Theme data files and deleted them. My web started with 856 files. By the time I finished deleting the Theme files, I was down to 642. That's 212 completely useless files gone, and that doesn't count the hundreds of files I deleted months ago.

I published last night with high hopes that the timeout problem would be fixed, but it still occurred. Oh, well. I've learned some things going through this mess:

Microsoft FrontPage Extensions are a joke. If you have any thought of creating a site that will eventually grow to anything larger than small, FP Extensions will eventually come back to bite you. The only thing they really do is support a handful of server-side functions, and the only one of those likely to be used is Search. But the FP Search function is not very powerful anyway, and you can accomplish the same thing or better by running a canned server-side search script, or simply by pointing your readers to a third-party search engine that has fully indexed your site.
Don't even think about using Themes. You can accomplish the same thing manually with very little more effort, and your site will be a lot cleaner for it. Anyway, Themes are ugly.

I'm seriously considering telling pair Networks to remove the FP Extensions from my site. That means the search engine will go away, but that may not be a big problem. I may use EzResult.com, a new search-engine that I stumbled across a month or so ago. EzResult doesn't have the most power search syntax, and they're still building their database (at about four million pages a day), but they do have one thing no one else has: instant updates. And by "instant", they mean instant.

Every other search engine I know of requires from days to weeks to get a new page indexed and listed in their database. EzResult requires literally seconds. That means I can hit the EzResult site, update this page, and have it instantly searchable. Try it yourself. Go to the site and search for the non-word furfurwathle.

EzResult also allows restricting searches to one domain. Using the search term d:ttgnet.com returns results only from this domain, for example. Between the ability to restrict searches to one domain and the instant updates, EzResult provides a pretty good alternative to the FrontPage Search function. It's also a lot faster.

* * * * *

This from Dan Bowman [dbowman@americanambulance.net]:

Bob, you seem to be the one for this one. I have not confirmed the attribution.

dan

The following was written by State Representative Mitchell Kaye from Cobb County, GA.:

"We, the sensible people of the United States, in an attempt to help everyone get along, restore some semblance of justice, avoid any more riots, keep our nation safe, promote positive behavior, and secure the blessings of debt-free liberty to ourselves and our great-great-great grandchildren, hereby try one more time to ordain and establish some common sense guidelines for the terminally whiny, guilt-ridden, delusional and other liberal, bed wetters. We hold these truths to be self-evident:

That a whole lot of people were confused by the Bill of Rights and are so dim that they require a Bill of No Rights.

ARTICLE I: You do not have the right to a new car, big screen TV, or any other form of wealth. More power to you if you can legally acquire them, but no one is guaranteeing anything.

ARTICLE II: You do not have the right to never be offended. This country is based on freedom, and that means freedom for everyone not just you! You may leave the room, turn the channel, express a different opinion, etc., but the world is full of idiots, and probably always will be.

ARTICLE III: You do not have the right to be free from harm. If you stick a screwdriver in your eye, learn to be more careful, do not expect the tool manufacturer to make you and all your relatives independently wealthy.

ARTICLE IV: You do not have the right to free food and housing. Americans are the most charitable people to be found, and will gladly help anyone in need, but we are quickly growing weary of subsidizing generation after generation of professional couch potatoes who achieve nothing more than the creation of another generation of professional couch potatoes.

ARTICLE V: You do not have the right to free health care. That would be nice, but from the looks of public housing, we're just not interested in health care.

ARTICLE VI: You do not have the right to physically harm other people. If you kidnap, rape, intentionally maim or kill someone, don't be surprised if the rest of us want to see you fry in the electric chair.

ARTICLE VII: You do not have the right to the possessions of others. If you rob, cheat or coerce away the goods or services of other citizens, don't be surprised if the rest of us get together and lock you away in a place where you still won't have the right to a big-screen color TV or a life of leisure.

ARTICLE VIII: You don't have the right to demand that our children risk their lives in foreign wars to soothe your aching conscience. We hate oppressive governments and won't lift a finger to stop you from going to fight if you'd like. However, we do not enjoy parenting the entire world and do not want to spend so much of our time battling each and every little tyrant with a military uniform and a funny hat.

ARTICLE IX: You don't have the right to a job. All of us sure want all of you to have one, and will gladly help you along in hard times, but we expect you to take advantage of the opportunities of education and vocational training laid before you to make yourself useful.

ARTICLE X: You do not have the right to happiness. Being an American means that you have the right to pursue happiness - which, by the way, is a lot easier if you are unencumbered by an overabundance of idiotic laws created by those of you who were confused by the Bill of Rights."

IF YOU AGREE, WE STRONGLY URGE YOU TO FORWARD THIS TO AS MANY PEOPLE AS YOU CAN. NO, YOU DON'T HAVE TO AND NOTHING TRAGIC WILL BEFALL YOU SHOULD YOU NOT FORWARD IT. WE JUST THINK IT IS ABOUT TIME COMMON SENSE IS ALLOWED TO FLOURISH; CALL IT THE AGE OF REASON REVISITED.

THANK YOU.

Well, if he isn't a libertarian, he ought to be...

* * * * *

This from Matt Beland [belandm@syspac.com]:

This is a kludged up mess I ran into a few years ago on Windows 95.

Default system directories - Program Files, My Documents, etc. - that are created by Windows during installation will work with the "cd" command. However, any directory created later, either manually or with third-party software, will not. To get into those directories, you must use the old DOS 8.3 file structure. To use the example Michael Baker used, the command to change to the "Tori Amos" directory is "cd toriam~1" rather than "cd tori amos."

Just for completeness, every so often I'll run into a system that does not handle the Program Files or other system directories properly either. The only answer I ever got from Microsoft Tech Support was that there was probably a registry error somewhere where a key had been deleted - which implies that it should be possible to add keys for those directories like "Tori Amos" so that the cd command will work.

Later,

Matt Beland
belandm@syspac.com

Hmm. It's not that way on my system, but the various directory utilities aren't consistent. Just to test it, I changed to c:\ and typed:

md old files

Windows NT Server 4 (SP3) created the directory c:\old (ignoring "files") but gave no error message. I then typed:

md "old files"

and it created the c:\old files directory properly. I then typed:

cd old files

and it changed to c:\old files properly. I then typed:

rd old files

and got an error message. Typing

rd "old files"

removed the directory properly.

* * * * *

This from Matt Beland [belandm@syspac.com]:

I've never tried it on NT (server or workstation). The description I gave I developed from using the original Windows 95 several years ago. Retrying it now on my Windows 98 system gives results like yours, except that it will not create a directory with the command "md old files", instead giving a "Too many parameters" error message. Rolling across the room to an old Windows 95B system does much the same, but I note a few problems. E.G., I created the directory "Old Files" and it works - but the directory "aa bb" does not. I no longer have an original Windows 95 system to retry the original test with.

-- begin pure, unfounded speculation --

If, as I surmised earlier, there is a registry key linking the old- and new-style directory names to the cd and md commands, and there is a separate key for each directory (which seems inefficient, but it wouldn't be the first time) perhaps there is a list of "common" directory names included in 95B, such as "common files", "old files", "downloaded files," and so on. This would be consistent with the "faster, not better" approach to problem solving that Microsoft indulged in with Windows 95. Since Windows 98 handled the "aa bb" directory fine, I can only assume they changed methods for 98. Assuming, of course, that the information on the registry keys I got from Microsoft in the first place was correct. (It has been a few years, and I don't recall there being any such thing as the Knowledgebase back then.)

-- end speculation --

Later,

Matt Beland
belandm@syspac.com

* * * * *

And then an exchange of letters began about what exactly is happening here. In a message to Michael Baker, Peter Thomas [peterjt@netcom.ca] says:

Michael

Regarding your eMail to Robert Thompson

It's a long shot but... Are you running CMD or COMMAND? I've found that do a START | RUN | COMMAND launches the "old" DOS interface while CMD launches the 32 bit shell.

Under the old interface CD PROGRAM FILES does say too many parameters...

Peter

Thanks. This is one of those things that I used to know but had forgotten. I guess Microsoft had to include the brain-dead command.com for applications that expected to find it. I use a command prompt fairly frequently, but always cmd.exe. I'd forgotten completely about command.com.

* * * * *

Michael Baker [solo32@mindspring.com] replies to Peter:

Peter,

Thanks! I thought I was losing it. Just before I received your message. I launched a command window via the start menu. CD worked fine with long filenames. Apparently, this runs the CMD command. I never knew that two different command interpreters existed in NT. After playing around a bit, I found that the window title for COMMAND is C:\WINNT\System32\command.com, and it calls itself Windows NT DOS.

Learn something new everyday.

---------------------

Michael Baker
solo32@mindspring.com

* * * * *

Michael Baker [solo32@mindspring.com] also says:

[...] In regards to the cd-writer, I know a number of people that use IDE units with very few problems. I had two main reasons for getting a SCSI writer. First, I already had a SCSI card and a SCSI cd-rom, zip, and scanner. Second, I read that SCSI drives are more reliable when multitasking than IDE. This is due to IDE's limitation of one active device per channel. I've had mine only a couple of weeks. So far it's been great. I hope yours works well for you. Er, maybe I should wish you ill so you will have lots of material to educate us with :).

Thanks again!

---------------------

Michael Baker
solo32@mindspring.com

Actually, I bought the ATAPI CD-R unit for just that reason. I've gotten enough feedback from readers to conclude at least tentatively that problems are much less common with SCSI burners. So, the question becomes: under what circumstances do problems occur with ATAPI burners, and what can be done to avoid them? I've already done quite a bit of work on that, and will do more. My preliminary conclusions are that ATAPI burners are generally reliable if configured and used properly, but one must understand a great deal more about all the interconnected factors to burn CDs reliably with an ATAPI burner than with a SCSI burner.

Sunday

Sunday, June 20, 1999

[Current Topics Page]

Yes, I know. EZResult doesn't find furfurwathle. I spoke too soon. Here's what happened.

In the process of setting up my new search page to point to EZResult, I found that EZResult hadn't parsed my site since late May. When you add a page manually, the update is instantaneous, but EZResult is like any other search engine in the sense that it visits a site only periodically to look for new pages. While I was there, I decided to go ahead and add the last couple of weeks of this page, and so I added http://www.ttgnet.com/daynotes/0614RTDN.html to their index manually. That was at about 9:15 a.m. local time.

I then wrote the piece about furfurwathle, planning to publish immediately to my web site and then go to EZResult to update that page to include the new stuff. What I found was that EZResult accepted the page, but didn't update the index. This may be because I hit them in the middle of housekeeping routines or something, or it may be because they limit any given page to being updated only once per day or whatever. The latter would make sense as a mechanism to prevent themselves from being spammed by people who update the same page frequently.

And, speaking of furfurwathle, why is Microsoft so convinced that one couldn't possibly want to cut or copy a word that it considers misspelled? I just now checked to see if furfurwathle had showed up yet on EZResult. Double clicking the word highlighted it, but right-clicking displays only the spell check menu. I had to manually Ctrl-C to copy the word. I hate Microsoft.

* * * * *

I've now installed the commercial upgrade version of FrontPage 2000 over the version of FP2000 I had installed on my hard disk. I just called up the publishing menu and it now allows me to choose Internet sites rather than just disk locations. We'll try publishing this and see what happens...

Well, it didn't work. Same old same old. I get prompted for my account name and password, I enter them, and it prompts me again for my account name and password. I hate Microsoft. I HATE MICROSOFT.

* * * * *

Barbara and I went over to the Tucker's last night for Steve's birthday. He just turned 44. An old guy now...

Suzy had been up in Pennsylvania visiting relatives, and stopped by the house for a couple hours on a flying visit before heading up to the church camp in the mountains for another week. She's a counselor this year. Steve's had the kids for the last week, but they'll be up in church camp all next week, so Steve's a free man for a while. He had Andrew last night, but Katie was at a birthday party. Barbara and I stopped over to deliver Steve's birthday present.

While we there, I told Steve we'd take him out for dinner, but to a really cheap place. So that's what we did. On the way, we stopped by Office Depot. I needed some CD-RW disks for my experiments. The only thing they had was a three-pack of Maxell's for $15. That's a rip. I've seen name-brand CD-RW media advertised on the net for $3 each or less. Still, I only need a few, and that's cheaper and quicker than sending off for them. I should have gotten them when I ordered the drive.

While we at Office Depot, Steve picked up a Star Wars game for Andrew. We got it installed after we got back to Steve's house. I must say it was pretty impressive, particularly running through Steve's PC speakers--a set of full size main speakers running through a standard home-audio receiver. I've often wondered why some people pay $250 or more for high-end PC speakers when they could call up Crutchfield and buy a $125 Sony receiver with 100 watts/channel and a $125 set of Yamaha 8" bookshelf speakers, that are video shielded, no less. There's certainly no comparison sound-wise.

* * * * *

Pournelle forwarded the following message to me. It's a very good explanation of the causes of the FrontPage timeout, and a warning to those who might consider using FrontPage extensions for a serious site. Note that all this applies to using the FrontPage Extensions. It's fine to use FrontPage as a client. The problems arise when you attempt to use it in a client-server environment. I will probably ask pair to remove the FrontPage extensions from my server and start using the Web Publishing Wizard instead. The only thing that loses me is the server-side functions, like Search, that I can do without anyway.

Hi, this is Kevin Martin at pair Networks. If you want to take this issue up further, please do so with me directly at sigma@pair.com.

The issues are as follows - if you want to discuss these in greater detail, I'll be more than happy to do so. I wouldn't want your column to be inaccurate!

1) the author.exe portion of the FrontPage extensions, which runs when you publish a Web, take an amount of real time and CPU time in direct proportion to the size and complexity of the Web itself

2) while those computations take place, author.exe makes no effort to send data to the client

3) Apache, which we did not write (hey, we didn't write FrontPage either), has a single Timeout configuration value that controls timeouts for all types of transmissions

4) after that length of time has passed, Apache is forced to assume that the author.exe process is hung or has otherwise failed, and it interrupts the connection

5) if Apache did not have this protection, or if the timeout is set excessively high, then a wide variety of other things can go wrong, including several denial-of-service effects on the Web service

6) if Apache were updated to include different Timeout settings for different situations (this is in their to-do file I believe), it would improve the situation, but it would still be impossible for Apache to distinguish between a looooong-running author.exe and a hung CGI; if CGIs aren't abandoned at *some* timeout value, they will "pile up" and consume all available resources, most likely the number of running httpd processes

7) the real solution would be for author.exe to send some sort of progress report to the FrontPage client, which would both keep the connection open easily and also allow the client to report progress to the end user

We cannot change the above points; they're all beyond our control. The ultimate consequence is that for this reason, and others which vary from case to case, FrontPage is not entirely ideal for managing large sites. The worst part is that author.exe takes a really long time, in proportion to site size. One customer had their publish time up to almost three hours; luckily they were on a dedicated server and were willing to accept the risks of the higher timeout setting. We can't do that on shared servers.

None of these conditions were set by us, or are controlled by us, or were preconceived in any way by us. If you have problems with these conditions, you are not alone. It's annoying to us as well. We're hoping that the FP2000 extensions, which we're currently testing, will improve the situation.

I don't understand the nature of your complaints about FrontPage as it relates to running a commercial site. Most of our customers are running commercial sites, and relatively few actually rely on FrontPage. We've mostly seen customers using it as a tool for quickly creating simple sites, or for managing content with lots of replicated structure. I wouldn't say that FrontPage directly relates to whether or not your content or intent is commercial, at all. I don't know if Microsoft would prefer that the buying public think differently, or not.

Also, nobody pays extra for FrontPage extensions on our service.

I am also sure you can find hosting services that run different Web servers (we feel Apache is the best choice for many reasons, and we're not alone), or that has upped their Timeout with regard for other consequences to other users, and that's fine. That's why there are other hosts; it's a free market. Our concern is providing the most stable, reliable service possible to all of our users. If a tool we didn't write has certain limitations, we look for a workaround, and if one cannot be found (we've tried), we try to help the customer understand the situation. Obviously, there are alternatives, even without dropping FrontPage. For example, larger sites are often managed in Sub Webs; I believe each Sub Web has its own author.exe instance associated with it, and thus the problem can be subdivided and made manageable again.

Again, if you want to discuss this further, please direct your response to me, and I'll ensure a quick reply.

Thanks,

Kevin Martin
sigma@pair.com

* * * * *

This from David Yerka [leshaworks@iname.com]:

I've been following your discussion on CDROM burners and thought I'd throw my pennies worth in. I picked up a CD-RW IDE drive a few weeks back and have had very good luck with it. Actually it surprised me as a couple of years ago I had much trouble with a SCSI unit in a clients office which was installed for doing permanent backups.

The drive is a Digital Research Technologies 2x6 with a 1meg buffer. (Actually its a BCE 62IE). I found it, of all places, in a Wholesale Club for approx. $145 and amazingly there was a $30 off coupon inside. I mean who can resist at that price. The club even had Sony CDR disks at 15 for $17!

I have it in a Win98 system (I guess we can say the "a" version now). Its a junk box put together that serves as a sort of do whatever system on my home network. Its got a couple of 2.5gig. Maxtor drives on the primary IDE, the CDRW as master on the secondary with a 32x CDROM drive as slave. 64 megs. of RAM and a 333 Cyrix cpu (actually speed 75x3.5=266).

I find I've been using it quite a bit as a quick dumping point for files. Using Direct CD and leaving a formatted CDRW disk in the drive I find I can store stuff on the drive quite easily and successfully. Files up to about 15meg. are store quite quickly considering the 2x write speed for CDRW. (my network is 10mips 10baseT). I haven't yet lost data and I've been moving about 50meg. or so a day down the line. Pulling stuff off the CDRW disk is basically the same as any 6x CD drive.

In playing around--moving the CDROM drive to the primary IDE and sticking the second hard drive onto the secondary IDE, etc.--I've found that moving data off the CDROM is the major factor in direct writes. Obviously Easy CD (3.5) wants to buffer the CDROM drive data to hard disk when on the secondary IDE with the CDRW but interestingly it also complains in the tests when the 32x CDROM is the slave on the Primary. Meanwhile, testing with CDRW as secondary master and a hard drive as secondary slave and the source tests out without problems. It seems a direct write (of 600meg.) from a hard disk on the same channel as this CDRW drive succeeds without extra buffering while a direct write from a CDROM drive on the other channel is problematical.

In practice I've found that buffering to the hard drive before writing while being slow almost totally guarantees a successful write. Interesting also is the fact that writing to a RW disk seems more successful than to a CDR disk on this drive. Guess maybe someone optimized the hardware with that bias.

I find that everything works best if I also ALWAYS test before writing. Yes, its slow, but what the heck I can always get some coffee, do the laundry, etc. 2x drives just aren't hotrods but for the price...

David M. Yerka

P.S. Oh, I guess I should mention I found your site by way of Jerry Pournelle's. In fact, I think you help me out a while back in an answer to a question I hit Dr. Pournelle with. If I didn't thank you then I do now...Thanks.

That's interesting, thanks. I'm surprised that you're able to do a direct write from a hard disk on the same ATA channel as the burner. I'm still experimenting under Windows NT with things like enabling DMA transfers on the channel that the hard disk is on. By default, Windows NT runs hard disks in PIO mode at only 8.3 MB/s. What I'm finding is that Windows NT NTFS is relatively inefficient at dealing with a bunch of small files and subdirectories. Churning away on a data set like that on one of my less capable systems, Adaptec's Easy CD Creator tells me that the hard disk throughput drops down into the 3 MB/s range, which worries me.

As far as the other matter, I don't remember what it might have been, but you're welcome.