I gave some late Christmas presents this year—packets of small, colored cable ties for use on luggage, in lieu of padlocks.
The Transportation Security Administration, it seems, is now advising airline passengers to leave their checked bags unlocked, so that locks will not have to be broken if TSA personnel decide to inspect them. The TSA assumes no liability for bags damaged in the process of breaking locks and apparently will assume no liability for the locks themselves or for any belongings that go missing, either. It does promise to seal inspected bags and notify the passenger. Clearly, however, this procedure subjects checked bags to unconstrained pilferage, if not by the TSA, then by airline employees. (No one in government seems to have thought this through, and I suspect we are expected to be grateful for the new rules.)
This brings us to the cable ties. The TSA actually recommends using these nylon devices to secure your luggage because doing so deters pilferage and yet allows easy access by inspectors as necessary. (Cables ties are difficult to break and cannot be reused, but they can be cut.) Luggage locks never really detered a determined thief, anyway. The problem with most cable ties, unfortunately, is that they are either white (most commonly) or black. What is to stop an airline employee (or bellhop, etc.) from buying a couple of packs of cable ties, cutting off passengers’ ties, stealing from the bags, and replacing the ties with identical ones? Colored ties are harder to find and are less likely to be messed with, at least for now. Neither my local hardware store nor electrical supply house had colored ties, but I found packages of assorted colors at Home Depot.
By the way, I think that opening people’s luggage while they are not present is a terrible idea. But so are most idea of this administration.
January 27, 2003
January 23, 2003
On Reaching Consensus
One of Terry Gross’s guests on Fresh Air today was antiwar demonstration organizer Mara Verheyden-Hilliard. The interview was tedious, with Gross suggesting that the coalition led by her guest, International ANSWER (Act Now to Stop War & End Racism), included what most Americans would consider the lunatic fringe, and Verheyden-Hilliard reacting indignantly (and at length) to the implication. I was not paying careful attention as she droned on, but, near the end of the interview, I turned suddenly toward my radio after Verheyden-Hilliard explained, “That’s what we have consensed on.”
I assume that what was meant was something like “That’s the consensus we reached,” or “That’s what we agreed to,” or simply “That was our consensus.” This last locution seems not to have a different meaning, and it has the advantages of being brief and of not turning heads in disbelief. One might argue, I suppose, that it emphasizes that which was agreed upon, rather than the agreement process, which was stressed in the original statement. Nonetheless, the need for Verheyden-Hilliard’s back-formation from “consensus” does not seem acute. Besides, “consensed” sounds too much like “condensed” or, perhaps, “incensed.”
I assume that what was meant was something like “That’s the consensus we reached,” or “That’s what we agreed to,” or simply “That was our consensus.” This last locution seems not to have a different meaning, and it has the advantages of being brief and of not turning heads in disbelief. One might argue, I suppose, that it emphasizes that which was agreed upon, rather than the agreement process, which was stressed in the original statement. Nonetheless, the need for Verheyden-Hilliard’s back-formation from “consensus” does not seem acute. Besides, “consensed” sounds too much like “condensed” or, perhaps, “incensed.”
January 9, 2003
A FrontPage Story
As you may have noticed from the home page of Lionel Deimel’s Farrago, I maintain the site with Microsoft’s FrontPage 2000. FrontPage is a Web design and authoring tool with many virtues, though it seems to have a mind of its own that makes certain sophisticated tasks harder than you think they should be, rather than easier. Nonetheless, FrontPage is a great tool for developing sites to be maintained by others who have limited Web-development skills or for developing sites that don’t have to live on the bleeding edge of Web technology.
FrontPage accomplishes some of its fancier tricks—generating tables of contents automatically, for example—by means of special software installed on the Web server, known as FrontPage server extensions. FrontPage server extensions are widely, though not universally, available on Web servers on a variety of platforms. The latest version of FrontPage is FrontPage 2002, and there are server extensions that correspond to this product, just as there were server extensions for previous one, FrontPage 2000. The 2002 server extensions also support FrontPage 2000.
I especially appreciate a program like FrontPage for the automatic changes it makes for the author, such as adding links to new pages on the site map page. Another nifty feature I have made use of on many sites is the ability to display the date a page was last edited without having to change the date manually. This feature was very nicely implemented. Frequently, one wants to put a standard footer on some or all of a site’s pages, and this is an attractive place also to display the last-edited date. In FrontPage, one can place independently defined borders on any edge of the page and have it appear, say, on all pages. If I want to change this border, I do so in one place, and that edit will be reflected on all the pages seen by the Web visitor. Moreover, if I put a date in a border—the bottom border, say—even though the “same” border is used on every page, the date shown can be made to display the date the page itself was last edited. I used this feature to show the edit date of most of the pages on my Web site.
Unfortunately, a few months ago, the feature stopped working properly. When I updated a page, the date in the bottom border did not change. It only changed if I changed the border itself, in which case, all the pages with the border would show the same updated timestamp. Actually, it took some time to realize what was happening, or, more properly, not happening. What seemed especially curious was the fact that the edit dates of my pages were being displayed properly on my site map page—FrontPage indeed knew when the pages had been changed.
I first noticed the problem in late September or early October. I was busy with a number of projects, however, and did not get around to serious troubleshooting for a while. By early December, however, I had tried everything I could think of to diagnose and fix the problem, so I called technical support at SBC WebHosting.com, which hosts my site. The ever-helpful SBC people had a number of suggestions, but no one seemed to have seen this problem before and, after a number of conversations, it was not clear whether we were closing in on a solution, or even a diagnosis, for that matter. In parallel, I had opened up a dialog with Microsoft support on the Web. Much of this dialog was carried on in written form, but, over a period of about a month—I took some troubleshooting time off for Christmas—I also had several telephone conversations with the Microsoft person working on my case. I also searched elsewhere—though not everywhere—for insight into the problem. I looked at on-line help, books on FrontPage, and the Microsoft Knowledge Base. What I discovered was that the feature I was using was not well documented, and failures of it seemed not to be documented at all.
By mid-December, all the technical support people were telling me that there seemed to be nothing wrong with my Web site or the FrontPage extensions on its Web server, and everything seemed to work fine for them. (I have reason to doubt this last assertion.) In fact, when I loaded my site onto the Web server on my computer, it worked fine. Evidence that perhaps I wasn’t crazy then came in the form of an e-mail message from a client experiencing the same problem with another site hosted by SBC. I called him immediately to tell him that he wasn’t crazy either and that I was working on the problem. Interestingly, the client had noticed the problem about the same time I did.
When I got back to work after Christmas, I started asking the SBC people what had changed on my server. I eventually learned that the FrontPage 2002 server extensions had replaced the 2000 server extensions sometime in August. This was suspicious. Microsoft suggested I sign up for a free Web site that supported FrontPage and put up a few pages to demonstrate that the date functionality was or was not correct. I did so, and I encountered the same problem I was having on the SBC server. At this point, SBC was suggesting that I should perhaps be on a Windows 2000, rather than a Unix server, and that perhaps FrontPage 2002 would fix the problem. My Microsoft contact, meanwhile, gave up and handed off the problem to the next higher level of technical support.
I ordered a trial copy of FrontPage 2002 and began looking into how much more expensive it would be to host my site on a Windows 2000 server. A couple of days later, I got a call from another Microsoft technician. We had a long and interesting conversation, but what he called to tell me was short and sweet—that the feature I was trying to make work had been quietly eliminated in the FrontPage 2002 extensions. The “date this page was last edited” option of the time and date component apparently used a lot of CPU time on Web servers when pages were uploaded, and Microsoft was urged by Web hosters to eliminate it. Microsoft complied and apparently hasn’t heard much about it from FrontPage users. I wasn’t happy to hear this, but I was happy to know that I had no more need to beat my head against the wall. I know when I’m beat. I have modified my site and will send a request to Microsoft to restore the deleted feature. I will not hold my breath.
Although I thought the feature I had lost was quite useful, it was obvious that it was poorly understood and little-used; Microsoft could certainly justify their eliminating it. On the other hand, the feature might have been more popular had it been better documented. I do miss the days when software was documented in reference manuals that told everything anyone could possibly want to know about a program, including its behavior in every conceivable circumstance. Alas, software now seems to change faster than it can be tested or documented. Instead of reading reference manuals, we read about bug fixes and workarounds.
FrontPage accomplishes some of its fancier tricks—generating tables of contents automatically, for example—by means of special software installed on the Web server, known as FrontPage server extensions. FrontPage server extensions are widely, though not universally, available on Web servers on a variety of platforms. The latest version of FrontPage is FrontPage 2002, and there are server extensions that correspond to this product, just as there were server extensions for previous one, FrontPage 2000. The 2002 server extensions also support FrontPage 2000.
I especially appreciate a program like FrontPage for the automatic changes it makes for the author, such as adding links to new pages on the site map page. Another nifty feature I have made use of on many sites is the ability to display the date a page was last edited without having to change the date manually. This feature was very nicely implemented. Frequently, one wants to put a standard footer on some or all of a site’s pages, and this is an attractive place also to display the last-edited date. In FrontPage, one can place independently defined borders on any edge of the page and have it appear, say, on all pages. If I want to change this border, I do so in one place, and that edit will be reflected on all the pages seen by the Web visitor. Moreover, if I put a date in a border—the bottom border, say—even though the “same” border is used on every page, the date shown can be made to display the date the page itself was last edited. I used this feature to show the edit date of most of the pages on my Web site.
Unfortunately, a few months ago, the feature stopped working properly. When I updated a page, the date in the bottom border did not change. It only changed if I changed the border itself, in which case, all the pages with the border would show the same updated timestamp. Actually, it took some time to realize what was happening, or, more properly, not happening. What seemed especially curious was the fact that the edit dates of my pages were being displayed properly on my site map page—FrontPage indeed knew when the pages had been changed.
I first noticed the problem in late September or early October. I was busy with a number of projects, however, and did not get around to serious troubleshooting for a while. By early December, however, I had tried everything I could think of to diagnose and fix the problem, so I called technical support at SBC WebHosting.com, which hosts my site. The ever-helpful SBC people had a number of suggestions, but no one seemed to have seen this problem before and, after a number of conversations, it was not clear whether we were closing in on a solution, or even a diagnosis, for that matter. In parallel, I had opened up a dialog with Microsoft support on the Web. Much of this dialog was carried on in written form, but, over a period of about a month—I took some troubleshooting time off for Christmas—I also had several telephone conversations with the Microsoft person working on my case. I also searched elsewhere—though not everywhere—for insight into the problem. I looked at on-line help, books on FrontPage, and the Microsoft Knowledge Base. What I discovered was that the feature I was using was not well documented, and failures of it seemed not to be documented at all.
By mid-December, all the technical support people were telling me that there seemed to be nothing wrong with my Web site or the FrontPage extensions on its Web server, and everything seemed to work fine for them. (I have reason to doubt this last assertion.) In fact, when I loaded my site onto the Web server on my computer, it worked fine. Evidence that perhaps I wasn’t crazy then came in the form of an e-mail message from a client experiencing the same problem with another site hosted by SBC. I called him immediately to tell him that he wasn’t crazy either and that I was working on the problem. Interestingly, the client had noticed the problem about the same time I did.
When I got back to work after Christmas, I started asking the SBC people what had changed on my server. I eventually learned that the FrontPage 2002 server extensions had replaced the 2000 server extensions sometime in August. This was suspicious. Microsoft suggested I sign up for a free Web site that supported FrontPage and put up a few pages to demonstrate that the date functionality was or was not correct. I did so, and I encountered the same problem I was having on the SBC server. At this point, SBC was suggesting that I should perhaps be on a Windows 2000, rather than a Unix server, and that perhaps FrontPage 2002 would fix the problem. My Microsoft contact, meanwhile, gave up and handed off the problem to the next higher level of technical support.
I ordered a trial copy of FrontPage 2002 and began looking into how much more expensive it would be to host my site on a Windows 2000 server. A couple of days later, I got a call from another Microsoft technician. We had a long and interesting conversation, but what he called to tell me was short and sweet—that the feature I was trying to make work had been quietly eliminated in the FrontPage 2002 extensions. The “date this page was last edited” option of the time and date component apparently used a lot of CPU time on Web servers when pages were uploaded, and Microsoft was urged by Web hosters to eliminate it. Microsoft complied and apparently hasn’t heard much about it from FrontPage users. I wasn’t happy to hear this, but I was happy to know that I had no more need to beat my head against the wall. I know when I’m beat. I have modified my site and will send a request to Microsoft to restore the deleted feature. I will not hold my breath.
Although I thought the feature I had lost was quite useful, it was obvious that it was poorly understood and little-used; Microsoft could certainly justify their eliminating it. On the other hand, the feature might have been more popular had it been better documented. I do miss the days when software was documented in reference manuals that told everything anyone could possibly want to know about a program, including its behavior in every conceivable circumstance. Alas, software now seems to change faster than it can be tested or documented. Instead of reading reference manuals, we read about bug fixes and workarounds.
January 6, 2003
Where Do They Come From?
I stopped at my local Wild Birds Unlimited store a few weeks ago and bought a thistle feeder to go with my wooden “house” feeder. This tube feeder is mainly intended for goldfinches, who love the small seeds. Curiously, goldfinches like to eat upside down, so many feeders made for them have perches above the seed holes, rather than below. I chose a wire mesh tube feeder, which supposedly accommodates both goldfinches and birds that feed in a more conventional posture.
When I got home, I installed the feeder and filled it with seed. I waited for weeks to see my first customer. Finally, in mid-December, I saw my first goldfinch, then another, and another. I still have not seen any birds other than goldfinches using the feeder, but I have seen as many as six of them at once jockeying for their share of birdseed. Where have these birds been? I had never knowingly seen a goldfinch before installing my new feeder. In an earlier, pre-scientific age, I might have concluded that thistle feeders create goldfinches through some process of spontaneous generation.
(Click here to see a picture of the new feeder.)
When I got home, I installed the feeder and filled it with seed. I waited for weeks to see my first customer. Finally, in mid-December, I saw my first goldfinch, then another, and another. I still have not seen any birds other than goldfinches using the feeder, but I have seen as many as six of them at once jockeying for their share of birdseed. Where have these birds been? I had never knowingly seen a goldfinch before installing my new feeder. In an earlier, pre-scientific age, I might have concluded that thistle feeders create goldfinches through some process of spontaneous generation.
(Click here to see a picture of the new feeder.)
January 5, 2003
Where Did the Other Calorie Go?
I heard an ad promoting sugar the other day, presumably the work of some sugar trade group, possibly The Sugar Association, Inc. (see below). In this spot, sugar was described as having only 15 calories per teaspoon. I found this very interesting because sugar used to be described as having 16 calories per teaspoon. (I knew I couldn’t be wrong about this because, during summer vacations in college, I worked for American Sugar Company and developed a stronger than average interest in facts about sugar.) I wonder what happened to the other calorie? Has sugar changed? Has the teaspoon gotten smaller?
A search of the Web was helpful, even though it didn’t really answer my question. The Sugar Association, Inc., Web site prominently displays a banner with the 15 calories per teaspoon claim, but most sources (e.g., Lawrence Hall of Science at U.C., Berkeley) give 16 as the proper number. Curiously, one source, Detroit Medical Center of Wayne State University, cites a calorie count of 35 calories per teaspoon!
Given The Sugar Association’s vested interest in making sugar into a health food, I suspect that 16 calories per teaspoon is the proper figure. I do wonder what the rationale is for 15 (or 35, for that matter). I’ll try to crack this mystery when I get the chance.
A search of the Web was helpful, even though it didn’t really answer my question. The Sugar Association, Inc., Web site prominently displays a banner with the 15 calories per teaspoon claim, but most sources (e.g., Lawrence Hall of Science at U.C., Berkeley) give 16 as the proper number. Curiously, one source, Detroit Medical Center of Wayne State University, cites a calorie count of 35 calories per teaspoon!
Given The Sugar Association’s vested interest in making sugar into a health food, I suspect that 16 calories per teaspoon is the proper figure. I do wonder what the rationale is for 15 (or 35, for that matter). I’ll try to crack this mystery when I get the chance.
Far Apart
This morning, and not for the first time, I heard an NPR reporter say of a negotiation something like “both sides are still far apart.” Such a statement invites the question whether this situation is more dire than one in which only one of the two parties is far apart. Generally, “distance,” whether physical or metaphorical, is a property of two points; if a is far from b, then b is far from a. It is difficult to see how it could be otherwise. For example, if one were to suggest a violation of symmetry in the relation because one party is willing to compromise more than the other, then this “violation” is really illusory—the two measurements are not really taken the same way, and, in reality, the parties are closer together and equally close together.
In a certain logical sense “both sides are still far apart” could be considered correct, since, as I said, a far from b implies b far from a. It is wrong, however, in the sense that “both” at least suggests that the relation could be asymmetric. The reporter should merely have said that “the sides are still far apart.”
In a certain logical sense “both sides are still far apart” could be considered correct, since, as I said, a far from b implies b far from a. It is wrong, however, in the sense that “both” at least suggests that the relation could be asymmetric. The reporter should merely have said that “the sides are still far apart.”
Subscribe to:
Posts (Atom)