Today's e-voting technology has a lot of deep technical problems. On the surface these relate to PC style security issues - things like the ease with which systems using embedded Windows NT or an external Microsoft Access database can be made to show results other than those intended by the voters. These problems are real and well documented - do a google search on e-voting and you'll find lots of good reasons to be concerned.
I believe, however, that these issues, although important, mask much more fundamental problems with how the technology is deployed and the general failure of electoral management to reform itself through the effective use of technology. There are long term solutions but these are immaterial in terms of the present election because it's far too late to change.
Tomorrow's election will, therefore, feature the use of some e-voting technologies within the constraints of traditional electoral management and, in all likelihood, demonstrate some of that combination's weaknesses during this process. In my opinion, however, the total actual impact these security weaknesses have on the final vote counts is likely to be insignificant in the more important contests. What will be far more significant is the leverage these few real problems give conspiracy theorists to allege that much more consequential, but uncaught, frauds also took place. Fundamentally a small, but real, problem can become a national crisis if it lends itself to exploitation by people with agendas - and that's what I'm afraid will happen to e-voting on the day after tomorrow.
In that scenario Democractic losers across the country contest Republican electoral victories by asserting that security weaknesses in electronic voting were illegally exploited to their opponent's benefit and their loss. The resulting firestorm of media protest would then cast a shadow over legitimate electoral victories and discredit the electoral system because the security weaknesses allegedly exploited are real, even if the exploits are generally not.
Suppose, for example, that Mr. Bush wins by a narrow margin - a few percent in the overall popular vote with the issue even closer in one or two key states. In that situation the democrats seem unlikely to simply concede, preferring instead to launch hundreds of lawsuits at least some of which will ultimately be decided by judges balancing the unprejudiced, and genuinely expert, testimony of people like Dr. Rubin to the effect that exploitable weaknesses exist against the accused's assurances that no cheating took place. In this situation electoral management doesn't stand a chance: the traditional media will hold them guilty before the trials start and at least some judges, however well intentioned otherwise, will be forced to conclude that reasonable doubt exists as the legitimacy of the election results.
So what can be done? Absent a landslide Republican victory (or a kerry win) there's probably nothing you can usefully do except refuse to be caught up in the rush - just trust that the system will muddle through.
There may, however, be something the President can do - it's a classic hail Mary pass idea which may be really dumb, but which I'd like to toss out for comment.
Sir Arthur Conan-Doyle told a Sherlock Holmes story in which the big clue was that the dog failed to bark. In the same vein there's a missing "60 Minutes" special you need to think about in terms of that dog not barking.
In this case there seems to be reasonably good evidence that some captured North Vietnamese and VietCong papers naming John Kerry and earthed at the Vietnam War Archives held by Texas Tech University in Lubbock, are genuine. So far no third party has authenticated them, but they are said to show that both
Here's what Bruce Schneier had to say about this whole argument back in 1999:
"As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice."
Exactly right - so much so that I've asked my editor at linuxinsider (which will be offering a rebutal of my own soon) to contact him for permission to reprint his whole article on the subject. That may not happen, but you can look at it directly on his website: http://www.schneier.com/crypto-gram-9909.html and sae how an expert handles the somewhat loony argument against open source in high security environments.
As usual I found the./ comments fascinating and wanted to thank at least those whose ideas I'm going to think about.
I should mention, however, that the Linuxinsider column looks at only one aspect of these texts. As many people here pointed out the focus in business education isn't on the technology but on the uses which can be made of the technology. As a result OS and language details aren't that important; it's the overall ideas that count. However, I was using their treatment of Linux (in a Linux publication) to illustrate one aspect of the range of error in the textbooks.
The bottom line is simple, there are thousands of errors in these books - their treatment of Unix (including Linux) just exemplifies their tendency to substitute MS dogma for research. Check the
full draft (referenced in the column and on my
site as http://www.winface.com/acm_draft.html for
a taxonomy and more examples.
Re:I like this quote from one of the books
on
Why PHBs Fear Linux
·
· Score: 1
Including this quotation from one of the books reviewed in the column without more context was something of a mistake.
To understand what happened you need to understand that the linuxinsider column people are responding to looked at only one facet of these books but the draft article on my site (winface.com/acm_draft.html) takes a more general view - which includes recognizing that several authors get JAVA completely wrong.
The kind of experience you report is ludricrous but extremely common but has nothing to do with whether or not Unix is good, reliable, or effective and everything to do with the competence of the people running your system.
Apply Wintel or MVS or VM ideas to running Unix and you will reliably create a disaster - changing the way people think (which may mean changing the people) is the only cure.
Technical "how to" books get out dated very quickly; computer science books tend not to because they deal mainly with theory and research. Similarly behavior focused management books don't get out-dated because the technology changes but the behavior doesn't.
You bet! Take a look at the full draft on
my site (there's a link in the article). There
are thousands of errors of all kinds in these books
of which my personal fav rave is "mainframe and minicomputers have one cpu" (Turban et al).
Re:Article doesn't say much about how MS is descri
on
Why PHBs Fear Linux
·
· Score: 1
The books are almost entirely MS centric. Several of them have long sections amounting virtually to MS tutorials - and leave the student with the impression that MS ideas encoded in those applications are the only right ideas.
As I say in the longer draft on my site, the students the MS focus looks exhaustive, not illustrative - that's what makes this kind of thing so pernicious.
Good idea, and bang on with respect to the original title (Unix: a management guide) for my defen book - which O'Reillys was real interested in until they saw it didn't follow their format.
If you want to see the settlement clearly, think of Bill Gates bending over with his pants down.
Sun got just about everything it wanted, including $1.6 Billion in what amount to fines plus another $350 million in advance royalties on IP to be used by MS. That's $1,950 million - real money even for MS and just about one third of Sun's cash and short term securities before these payments are counted.
The cash, however, is less important than three pieces in the agreement: one giving Sun the right to license and access MS protocols at preset prices, one committing MS to inter-operability on identification and authentication, and the other preventing mutual lawsuits for ten years.
The importance of the licensing issue is in the access to information side of it. What this means is that open source products like SAMBA can continue to succeed regardless of MS's wishes in the matter.
The importance of the inter-operability issue lies in the fact that Sun is the driving force behind a range of open identity technologies - including the use of the SAML as a message carrier instead of an RPC vehicle. MS, of course, wants to do its own, very controlled and proprietary, thing with identity and authentication and this agreement will let them do it, but force them to maintain compatibility with the open standard right alongside their proprietary one -leaving the choice to customers and developers; all of whom can see exploding growth opportunities on the open side and little beyond the RIAA on the MS side.
The third key piece, the no mutual lawsuits clause, probably won't stand long but represents an initial layer of legal protection against use of the courts to legitimize cheating by either side - and, of course, we need to interpret this in terms of a history in whuch MS has just agreed to pay Sun 1.6 Billion to compensate for past cheating.
Earlier releases of Mozilla crash when following the link from the Linuxinsider front page to the actual story. I found this infuriating, but got nowhere talking to the developers.
It seems to have been related (note past tense, recent releases of firefox/Moz work fine) to a delayed response from one of the ad click counters. i.e. when I looked at the state of things at the time of the freeze, it usually showed a request for a data transfer from somebody like ad.doubleclick.com.
My best advice? update your release. According to the developers, there was nothing wrong with the earlier product, but that's been fixed....
As I point out in my Linuxworld.com article (the one the editors here have not slashdotted - I wonder if they don't like pro sco opinions?) the issue is whether or not IBM breached the terms of the contract under which they had access to the AT&T code. I believe they did and that SCO will have an easy time proving it - and in that context lets remember that 80 lines will more than suffice for this if, in fact, their provenance can be proven in court.
On the other hand my belief is that this issue has little or nothing to do with Linux on any platform other than the IBM P, I, and Z series machines using the PowerPC architecture and thus the SMP and memory management code constributed to the AT&T code base by engineers from companies like Sun, NCR, and Motorola. Today's SuSe or Red Hat CVS may include these materials, but since they're only called with respect to compilation for IBM's non intel hardware, I predict a zero real impact on Linux.
FUD, of course, is another matter and the more people focus on the negative consequences for Linux which would arise if a fundamentally mistaken interpretation of the whole mess were correct, the worse things will get for the Linux community. So lets not help that along by spreading mis-information and conjecture. The facts will sort themselves out reasonably soon - and if I'm right Linux will come out unscathed while, if I'm wrong, delaying the rush to judgement may still help clarify the real issues.
There's a lot of FUD being spread around this but, in reality, Microsoft is merely one of around 30,000 Unix source code licensees and is using the opportunity associated with the current SCOsource initiative on renewals to throw a little FUD at the Linux community.
The history here is interesting. When SCO first started, its target was the Tandy line of MC68000 add-in boards and similar computers while Paul Allen (developer of MS BASIC) was arguing with his marketing guy that they should port Unix to the Apple II.
When IBM asked for an OS demo from Microsoft, they specified a piece of hardware based on a chip, the i8088, that simply lacked the power to run Unix. It had, after all, been produced as a downgrade from the 8086 (which wasn't selling well against the MC68000) to enable compatibility with older 8bit devices and could barely handle CP/M.
To get a real OS as a later follow-on to PC-DOS, Microsoft licensed AT&T Unix source and did a partnership deal with SCO that resulted in Xenix for the 8086 before that plan got pushed aside by the astonishing commercial success of the PC.
SCO, however, was left paying Microsoft royalties on its contributions to the intel port - a situation that continued until SCO cleared the last Microsoft code out of OpenServer in the mid ninties.
That worm turned when SCO bought the USL properties from Novel and eventually discovered that they now held the source licenses for most of the material Microsoft had been licensing to them - and on which Microsoft has just renewed its license.
So, with apologies to the conspiracy theorists, the MS rebewal doesn't signal anything beyond normal business practices - with the bonus of being able to sow a little free fear and confusion among the Linux troops; itself, of course, another normal business practice for MS.
Mr. Kirkpatrick's article draws significant business conclusions - Dell will prosper, Sun will fail- from his analysis of the relative positions of the players today. I believe that most of what he cites as fact is wrong:
on little things such as the chips in playstations;
on historical issues such as the history of the Power4;
on industry structure such as seeing Dell as a manufacturor; and,
on interpretations such as his comments on the value of 64bit-edness;
but I'm not sure his conclusions are wrong.
More precisely, you can't draw his conclusions from either his "facts" or his arguments, but that doesn't invalidate the conclusions.
For one thing articles like this become self-fulling prophecies and their prevalence in
management oriented publications like Fortune help explain how Sun can be both a strong company
and very weak share.
He may well be right on the specific issue of Itanium's future. Technically it's a pretty good chip and the fact that it's late and under-powered won't be important in the long run -the PA-RISC, which became a significant success, was also late and under-powered.
So will the Itantic sink? In my opinion Mr. kirkpatrick's article missed most of the significant elements in today's market picture that will affect this.
For example, the right parallel could turn out to be Intel's original Pentium Pro. As Intel's first completely 32 bit chip it was, briefly, a world leader in performance but only on 32bit applications. Since most Microsoft software used the older 16bit instruction sets, its performance on the Pentium Pro was terrible. As a result AMD was able to seize significant market share with its K-586 and Intel was quickly forced to re-introduce 16bit compatiblity in the Pentium line.
Years later the Pentium Pro came back - as the xeon - and that could easily be Itanic's fate too, if management at companies like Sun and AMD get their act together and make it happen. (see my article for my comments on how this could be done).
Re:Best Ever Word of the Day
on
A Word a Day
·
· Score: 1
Nice comment, keep em coming - I appreciate them; really.
"Tide" is a nice word to play with too. If you consult the Oxford Concise you see that its first two meanings are:
time, season; and,
periodical rise
Notice that both meanings carry the implication (actually made clear in the examples in the unabridged dictionary) that times change, seasons end, a rising tide eventually becomes an ebbtide.
There's a third meaning too but it reflects sloppy thinking - kind of like a buffer overflow on code for an x86 CPU- and that's what ties the word back to your posting. Here's a list showing the number of unique web hits, during January, on the definition of "Defenestration" on the winface.com site originating at Microsoft Headquarters:
These counts reflect unique IPs - but since these are almost certainly DHCP assigned there's no direct way to know if 51 people used tide85.microsoft.com to hit the definition or whether one person rebooted 51 times and read the definition each time.
On the other hand, I'll bet that the real meaning of "tide" escaped the person who choose this name for the machines in those particular rackmounts.
I recently did an analysis of spam addressed to me (http://www.winface.com/spam/spam.html if you want to see my attempt to be lighthearted instead of outraged about this stuff). The nature and distribution of the stuff I get does not match that reported in the article - For example, I get three times more porno come-ons (38%) than the article suggests (12%).
Now it could be that I disproportionally attract certain kinds of spam but I think it more likely that the article shaded the facts to present a more positive picture.
I suspect that's true on the response rate stuff too because the article never answers the question about how the lady really makes any money at this. At a guess, the real long term response is much higher than she indicates - particularly on porno and related for products and "services" she didn't discuss with the interviewer.
I do not have definitive numbers to report but I have experimented with Solaris 2.7, Red hat 7.0, and OpenBSD 3.0 on two intel boxes: a 450Mhz Compaq P3 and a 2 x 550Mhz Compaq Xeon both with 17" screens and basic graphics boards.
At the time I was working for a client who had a bunch of gear sitting around and I volunteered to give a short course in understanding and deploying Unix so we installed and de-installed a number of times to get people to look beyond specific details to see the essential sameness of the processes and the resulting Unixes.
OpenBSD had fewer problems, and overall better performance than either of the others with big differences in installing the GUIs and using them. Solaris felt jerky, Red Hat was Ok, and OpenBSD felt like a Sparcstation on both machines.
The gap was, however, much smaller on the dual processor than on the uniprocessor with Solaris on simple things like "repeat 10 man -k csh" a good 30% slower than BSD or Linux on the uniprocessor but not noticeably different on the Xeon.
I didn't run serious tests and wish I had. If anyone out there has access to the gear and some time, perhaps you could run some of the standard linux mini-benchmarks (see http://www.tux.org/bench/ for samples) and report the results?
Slashdot Mirror
I believe, however, that these issues, although important, mask much more fundamental problems with how the technology is deployed and the general failure of electoral management to reform itself through the effective use of technology. There are long term solutions but these are immaterial in terms of the present election because it's far too late to change.
Tomorrow's election will, therefore, feature the use of some e-voting technologies within the constraints of traditional electoral management and, in all likelihood, demonstrate some of that combination's weaknesses during this process. In my opinion, however, the total actual impact these security weaknesses have on the final vote counts is likely to be insignificant in the more important contests. What will be far more significant is the leverage these few real problems give conspiracy theorists to allege that much more consequential, but uncaught, frauds also took place. Fundamentally a small, but real, problem can become a national crisis if it lends itself to exploitation by people with agendas - and that's what I'm afraid will happen to e-voting on the day after tomorrow.
In that scenario Democractic losers across the country contest Republican electoral victories by asserting that security weaknesses in electronic voting were illegally exploited to their opponent's benefit and their loss. The resulting firestorm of media protest would then cast a shadow over legitimate electoral victories and discredit the electoral system because the security weaknesses allegedly exploited are real, even if the exploits are generally not.
Suppose, for example, that Mr. Bush wins by a narrow margin - a few percent in the overall popular vote with the issue even closer in one or two key states. In that situation the democrats seem unlikely to simply concede, preferring instead to launch hundreds of lawsuits at least some of which will ultimately be decided by judges balancing the unprejudiced, and genuinely expert, testimony of people like Dr. Rubin to the effect that exploitable weaknesses exist against the accused's assurances that no cheating took place. In this situation electoral management doesn't stand a chance: the traditional media will hold them guilty before the trials start and at least some judges, however well intentioned otherwise, will be forced to conclude that reasonable doubt exists as the legitimacy of the election results.
So what can be done? Absent a landslide Republican victory (or a kerry win) there's probably nothing you can usefully do except refuse to be caught up in the rush - just trust that the system will muddle through.
There may, however, be something the President can do - it's a classic hail Mary pass idea which may be really dumb, but which I'd like to toss out for comment.
Sir Arthur Conan-Doyle told a Sherlock Holmes story in which the big clue was that the dog failed to bark. In the same vein there's a missing "60 Minutes" special you need to think about in terms of that dog not barking.
In this case there seems to be reasonably good evidence that some captured North Vietnamese and VietCong papers naming John Kerry and earthed at the Vietnam War Archives held by Texas Tech University in Lubbock, are genuine. So far no third party has authenticated them, but they are said to show that both
"As a cryptography and computer security expert, I have never understood the current fuss about the open source software movement. In the cryptography world, we consider open source necessary for good security; we have for decades. Public security is always more secure than proprietary security. It's true for cryptographic algorithms, security protocols, and security source code. For us, open source isn't just a business model; it's smart engineering practice."
Exactly right - so much so that I've asked my editor at linuxinsider (which will be offering a rebutal of my own soon) to contact him for permission to reprint his whole article on the subject. That may not happen, but you can look at it directly on his website: http://www.schneier.com/crypto-gram-9909.html and sae how an expert handles the somewhat loony argument against open source in high security environments.
I should mention, however, that the Linuxinsider column looks at only one aspect of these texts. As many people here pointed out the focus in business education isn't on the technology but on the uses which can be made of the technology. As a result OS and language details aren't that important; it's the overall ideas that count. However, I was using their treatment of Linux (in a Linux publication) to illustrate one aspect of the range of error in the textbooks.
The bottom line is simple, there are thousands of errors in these books - their treatment of Unix (including Linux) just exemplifies their tendency to substitute MS dogma for research. Check the full draft (referenced in the column and on my site as http://www.winface.com/acm_draft.html for a taxonomy and more examples.
To understand what happened you need to understand that the linuxinsider column people are responding to looked at only one facet of these books but the draft article on my site (winface.com/acm_draft.html) takes a more general view - which includes recognizing that several authors get JAVA completely wrong.
Apply Wintel or MVS or VM ideas to running Unix and you will reliably create a disaster - changing the way people think (which may mean changing the people) is the only cure.
Technical "how to" books get out dated very quickly; computer science books tend not to because they deal mainly with theory and research. Similarly behavior focused management books don't get out-dated because the technology changes but the behavior doesn't.
You bet! Take a look at the full draft on my site (there's a link in the article). There are thousands of errors of all kinds in these books of which my personal fav rave is "mainframe and minicomputers have one cpu" (Turban et al).
As I say in the longer draft on my site, the students the MS focus looks exhaustive, not illustrative - that's what makes this kind of thing so pernicious.
Good idea, and bang on with respect to the original title (Unix: a management guide) for my defen book - which O'Reillys was real interested in until they saw it didn't follow their format.
If you want to see the settlement clearly, think of Bill Gates bending over with his pants down.
Sun got just about everything it wanted, including $1.6 Billion in what amount to fines plus another $350 million in advance royalties on IP to be used by MS. That's $1,950 million - real money even for MS and just about one third of Sun's cash and short term securities before these payments are counted.
The cash, however, is less important than three pieces in the agreement: one giving Sun the right to license and access MS protocols at preset prices, one committing MS to inter-operability on identification and authentication, and the other preventing mutual lawsuits for ten years.
The importance of the licensing issue is in the access to information side of it. What this means is that open source products like SAMBA can continue to succeed regardless of MS's wishes in the matter.
The importance of the inter-operability issue lies in the fact that Sun is the driving force behind a range of open identity technologies - including the use of the SAML as a message carrier instead of an RPC vehicle. MS, of course, wants to do its own, very controlled and proprietary, thing with identity and authentication and this agreement will let them do it, but force them to maintain compatibility with the open standard right alongside their proprietary one -leaving the choice to customers and developers; all of whom can see exploding growth opportunities on the open side and little beyond the RIAA on the MS side.
The third key piece, the no mutual lawsuits clause, probably won't stand long but represents an initial layer of legal protection against use of the courts to legitimize cheating by either side - and, of course, we need to interpret this in terms of a history in whuch MS has just agreed to pay Sun 1.6 Billion to compensate for past cheating.
Earlier releases of Mozilla crash when following the link from the Linuxinsider front page to the actual story. I found this infuriating, but got nowhere talking to the developers.
It seems to have been related (note past tense, recent releases of firefox/Moz work fine) to a delayed response from one of the ad click counters. i.e. when I looked at the state of things at the time of the freeze, it usually showed a request for a data transfer from somebody like ad.doubleclick.com.
My best advice? update your release. According to the developers, there was nothing wrong with the earlier product, but that's been fixed....
As I point out in my Linuxworld.com article (the one the editors here have not slashdotted - I wonder if they don't like pro sco opinions?) the issue is whether or not IBM breached the terms of the contract under which they had access to the AT&T code. I believe they did and that SCO will have an easy time proving it - and in that context lets remember that 80 lines will more than suffice for this if, in fact, their provenance can be proven in court.
On the other hand my belief is that this issue has little or nothing to do with Linux on any platform other than the IBM P, I, and Z series machines using the PowerPC architecture and thus the SMP and memory management code constributed to the AT&T code base by engineers from companies like Sun, NCR, and Motorola. Today's SuSe or Red Hat CVS may include these materials, but since they're only called with respect to compilation for IBM's non intel hardware, I predict a zero real impact on Linux.
FUD, of course, is another matter and the more people focus on the negative consequences for Linux which would arise if a fundamentally mistaken interpretation of the whole mess were correct, the worse things will get for the Linux community. So lets not help that along by spreading mis-information and conjecture. The facts will sort themselves out reasonably soon - and if I'm right Linux will come out unscathed while, if I'm wrong, delaying the rush to judgement may still help clarify the real issues.
There's a lot of FUD being spread around this but, in reality, Microsoft is merely one of around 30,000 Unix source code licensees and is using the opportunity associated with the current SCOsource initiative on renewals to throw a little FUD at the Linux community.
The history here is interesting. When SCO first started, its target was the Tandy line of MC68000 add-in boards and similar computers while Paul Allen (developer of MS BASIC) was arguing with his marketing guy that they should port Unix to the Apple II.
When IBM asked for an OS demo from Microsoft, they specified a piece of hardware based on a chip, the i8088, that simply lacked the power to run Unix. It had, after all, been produced as a downgrade from the 8086 (which wasn't selling well against the MC68000) to enable compatibility with older 8bit devices and could barely handle CP/M.
To get a real OS as a later follow-on to PC-DOS, Microsoft licensed AT&T Unix source and did a partnership deal with SCO that resulted in Xenix for the 8086 before that plan got pushed aside by the astonishing commercial success of the PC.
SCO, however, was left paying Microsoft royalties on its contributions to the intel port - a situation that continued until SCO cleared the last Microsoft code out of OpenServer in the mid ninties.
That worm turned when SCO bought the USL properties from Novel and eventually discovered that they now held the source licenses for most of the material Microsoft had been licensing to them - and on which Microsoft has just renewed its license.
So, with apologies to the conspiracy theorists, the MS rebewal doesn't signal anything beyond normal business practices - with the bonus of being able to sow a little free fear and confusion among the Linux troops; itself, of course, another normal business practice for MS.
Mr. Kirkpatrick's article draws significant business conclusions - Dell will prosper, Sun will fail- from his analysis of the relative positions of the players today. I believe that most of what he cites as fact is wrong:
but I'm not sure his conclusions are wrong.
More precisely, you can't draw his conclusions from either his "facts" or his arguments, but that doesn't invalidate the conclusions.
For one thing articles like this become self-fulling prophecies and their prevalence in management oriented publications like Fortune help explain how Sun can be both a strong company and very weak share.
He may well be right on the specific issue of Itanium's future. Technically it's a pretty good chip and the fact that it's late and under-powered won't be important in the long run -the PA-RISC, which became a significant success, was also late and under-powered.
So will the Itantic sink? In my opinion Mr. kirkpatrick's article missed most of the significant elements in today's market picture that will affect this.
For example, the right parallel could turn out to be Intel's original Pentium Pro. As Intel's first completely 32 bit chip it was, briefly, a world leader in performance but only on 32bit applications. Since most Microsoft software used the older 16bit instruction sets, its performance on the Pentium Pro was terrible. As a result AMD was able to seize significant market share with its K-586 and Intel was quickly forced to re-introduce 16bit compatiblity in the Pentium line.
Years later the Pentium Pro came back - as the xeon - and that could easily be Itanic's fate too, if management at companies like Sun and AMD get their act together and make it happen. (see my article for my comments on how this could be done).
Nice comment, keep em coming - I appreciate them; really.
"Tide" is a nice word to play with too. If you consult the Oxford Concise you see that its first two meanings are:
Notice that both meanings carry the implication (actually made clear in the examples in the unabridged dictionary) that times change, seasons end, a rising tide eventually becomes an ebbtide.
There's a third meaning too but it reflects sloppy thinking - kind of like a buffer overflow on code for an x86 CPU- and that's what ties the word back to your posting. Here's a list showing the number of unique web hits, during January, on the definition of "Defenestration" on the winface.com site originating at Microsoft Headquarters:
These counts reflect unique IPs - but since these are almost certainly DHCP assigned there's no direct way to know if 51 people used tide85.microsoft.com to hit the definition or whether one person rebooted 51 times and read the definition each time.
On the other hand, I'll bet that the real meaning of "tide" escaped the person who choose this name for the machines in those particular rackmounts.
I recently did an analysis of spam addressed to me (http://www.winface.com/spam/spam.html if you want to see my attempt to be lighthearted instead of outraged about this stuff). The nature and distribution of the stuff I get does not match that reported in the article - For example, I get three times more porno come-ons (38%) than the article suggests (12%).
Now it could be that I disproportionally attract certain kinds of spam but I think it more likely that the article shaded the facts to present a more positive picture.
I suspect that's true on the response rate stuff too because the article never answers the question about how the lady really makes any money at this. At a guess, the real long term response is much higher than she indicates - particularly on porno and related for products and "services" she didn't discuss with the interviewer.
I do not have definitive numbers to report but I have experimented with Solaris 2.7, Red hat 7.0, and OpenBSD 3.0 on two intel boxes: a 450Mhz Compaq P3 and a 2 x 550Mhz Compaq Xeon both with 17" screens and basic graphics boards.
At the time I was working for a client who had a bunch of gear sitting around and I volunteered to give a short course in understanding and deploying Unix so we installed and de-installed a number of times to get people to look beyond specific details to see the essential sameness of the processes and the resulting Unixes.
OpenBSD had fewer problems, and overall better performance than either of the others with big differences in installing the GUIs and using them. Solaris felt jerky, Red Hat was Ok, and OpenBSD felt like a Sparcstation on both machines.
The gap was, however, much smaller on the dual processor than on the uniprocessor with Solaris on simple things like "repeat 10 man -k csh" a good 30% slower than BSD or Linux on the uniprocessor but not noticeably different on the Xeon.
I didn't run serious tests and wish I had. If anyone out there has access to the gear and some time, perhaps you could run some of the standard
linux mini-benchmarks (see http://www.tux.org/bench/ for samples) and report
the results?