I think there are four things you need. - commit to quality (has to be top to bottom) - use systematic process (seems like you get this) - check everything (at every stage) - improve continuously (own your process and your meta process) i wrote more about this at http://www.multicians.org/thvv/nasty.html
Chris Tavares wrote the original Cookie Monster program in 1970. Story is at http://www.multicians.org/cookie.html -- sounds like you used a descendant of the original. Source is available online. The program did not wander randomly: you had to start it while logged in, and it would then sleep and pop up messages later. People used to prank their co-workers when they found a terminal unattended.
This article was written by me, Tom Van Vleck. "monsterhead78" has just copied the text from http://www.multicians.org/thvv/7094.html. T he original page has some pictures and useful links.
"The UNIX Time-Sharing System," by Dennis Ritchie & Ken Thompson, is one of the best-written papers ever. The elegance of thought and economy of description set a standard we should all aspire to. http://cm.bell-labs.com/cm/cs/who/dmr/cacm.ht ml
I list several more classics on my "Software Engineering Reading List" page at http://www.multicians.org/thvv/swe-readings.ht ml
I have interviewed many PhDs, and hired some.
I have never hired for a job where the PhD was
a job requirement: this might be so for a
professor job, but not for research and development.
A PhD shows that the candidate can finish something
difficult, despite institutional BS. This is often
a talent that transfers to jobs in big companies.
Many PhD degrees also require some originality and creativity, which can come in handy in some jobs.
There are other ways to prove this to an interviewer.
The PhD is not a guarantee of important attributes
that may be needed in many jobs, such as the
ability to cooperate with and respect others.
The value of particular academic subjects and
courses to a job is also something that an
interviewer has to discover on a case by case
basis. I hired a person with a PhD in Physics
who was awesome at debugging, and he credited
this to his training in design of experiments.
Specific courses in Computer Science theory
are not checklist items for most jobs: I have
worked with folks who could not move beyond
regurgitating what they had learned in class to
actually thinking about the current problem,
and that trait might be more common among people
who have taken a lot of classes.. or not.
I wouldn't rank getting a PhD as the best way
to command a high salary in computing careers.
The best way to do that is to be outstandingly
good at a rare and highly prized specialty, and
to be able to communicate well. I know a guy who
was a chip designer, one of the best in the world
at some of the hottest companies. He made top
dollar when he was working, and then spent
some time unemployed, and then learned new
skills, including managing.
Although your comments seem authoritative and knowledgeable, your facts are fuzzy and wrong. Unix was derived from Multics, but Multics at the point was dead. AT&T had abandoned the project altogether.
You can't learn lessons from the past if you get your facts wrong.
Multics did not die when Bell labs pulled out
early in its development. It continued to grow,
became a commercial product, sold hundreds of
millions of dollars of hardware (back when that was a lot of money), and was finally killed by
the French in 1986. Systems remained in use until
October 2000.
Multics is not owned by any company in Canada. It is owned by Bull, a French company, which acquired it from Honeywell, a thermostat company, which bought GE's computer department in 1970.
The small Canadian company currently known as CGI Group was contracted by Bull to provide maintenance service to the remaining Multics sites after Bull canceled OS development about 1987. Since there are no more Multics sites running, I suspect that CGI group has no current rights to Multics.
Understand, also, that in the late 60s and early 70s, systems copied ideas from each other more freely than now, because it was generally viewed that "you couldn't patent software."
More information about Multics is at
http://www.multicians.org/
I have used Quicken for a dozen years.
Originally it was a wonderful product,
easy to use, helpful, and simple.
Over time it has
bloated with a sink full of dubious features
had worse and worse support
come out with almost yearly cosmetic releases
abandoned Mac support
I have been planning to go to OS X and I am glad
to hear that I won't have to buy another Quicken.
Before I buy, there are two issues I will
need answers to. One was already mentioned:
database robustness. Quicken went through some
rough times with corruption
before they came up with repair procedures
that were effective and safe.
The other is check printing. If you can print
on 3-up checks, great.. but how do you print
other than three at a time? This is a horrible
mess, depends on all kinds of obscure stuff
that changes with every combination of OS and
printer. Quicken's method of aligning
and printing checks on dot matrix printers was
one of the things that helped it succeed early.
But debugging this stuff on hundreds of printer
models will be tedious and costly. I suggest that
you create a user discussion board where people
can share their experience on this sub-topic.
online discussion systems on mainframes
on
Blizzard Births BBS
·
· Score: 3, Interesting
BBS-like functions were provided by various mainframe timesharing systems well before 1978.
Multics had an online threaded discussion system called "continuum" (later renamed "forum") which I used while housebound during the Massachusetts blizzard of 78. The Multics machine wouldn't fit in my apartment though: I had a TermiNet 300 dialed up to MIT's Honeywell 6180.
Multics continuum was first written in the mid 70s in order to bid on a RFP for the Executive Office of the President of the United States (we lost the bid, IBM got it). At the time we were told that the capability desired was similar to a discussion system on the Dartmouth timesharing system.
The PLATO system at University of Illinois had a threaded discussion system in the 70s, as did a similar system, forget its name, at Stanford.
Sun and Oracle should merge
on
The Faded Sun
·
· Score: 2, Interesting
Every place I worked that bought Sun servers then had to go out and buy Oracle licenses, and deal with finger pointing if the OS and the DBMS didn't cooperate. The companies could combine, save money on marketing, sell a more complete business offering.
Segue (http://www.segue.com/) makes a set of commercial tools that support extensive script-driven testing of web applications. SilkTest is the testing tool.
At my previous startup, we bought and used these tools and developed extensive test libraries for our product.
There are also companies that will test your product for usability on many different platforms. Look at http://www.otivo.com/ for one such.
Stu Madnick is a professor in the Sloan School
of Management, not in the CS department.
This department has other professors who have
testified and consulted for Microsoft, such as
Dick Schmalensee, see
this Microsoft propaganda.
(In the sixties at MIT, the Project MAC folks
mostly thought that the school of management
people were not in the forefront of the field.
Undergraduates who were flunking out of EE would
change majors to Management and coast through.
I am sure things have changed since then but
in those days, mis-identifying Madnick as a
CS professor would get an immediate reaction.)
I've worked in several teams that
worked hard and played hard together.
Tom DeMarco speaks of "jelled" teams
and if a team is to come together in that
way I think you socialize too.
I worked on the Multics operating system for
16 years, and the annual Multics picnic was
one of many social events that I look back on
with pleasure: see
http://www.multicians.org/picnics.html
Other places I've worked didn't have that
kind of social interaction. People went home
after work and didn't socialize unless they
had some previous association. It was less fun.
Noel Morris and I wrote the MAIL command
for MIT's CTSS system on the 7094 in 1965.
Yes, in those days we used 6-bit BCD for
messages, so they were all upper case. MAIL
was used by several thousand registered
users of the two MIT systems. This program
was the ancestor of the Multics and Unix mail
commands. See
http://www.multicians.org/thvv/mail-history.html
for more on the history of mail and instant
messaging.
TRAM is an interesting idea.
Without taking anything away from it,
let me mention some work done in the 70s.
Multics had the same problem after crashes: it
took a long time to bring the system back up because the "salvager" had to check every
"VTOC entry." (fsck/inode in Unix terms)
We re-wrote the file system to do the necessary
checking on each use of the directory and VTOC
data, and eliminated the salvage during boot.
Everything still got checked, but only as needed.
Boot times went from hours to minutes, and the
system was much more solid and reliable.
"Yet readers of the articles proclaiming a shortage would be perplexed
if they also knew that Microsoft only hires 2% of its applicants for
software positions, and that this rate is typical in the
industry. Software employers, large or small, across the nation,
concede that they receive huge numbers of resumes but reject most of
them without even an interview. One does not have to be a ``techie''
to see the contradiction here. If employers were that desperate, they
would certainly not be hiring just a minuscule fraction of their job
applicants."
There is no contradiction here. I have been hiring programmers for
many years. 50 resumes to one hire is actually less discriminating
than many places I know of. A professor, who flunks incompetent
students, knows that there are job applicants who are inappropriate
for a given job opening. If someone accused Professor Matloff of
discrimination because he gave F's to people who didn't pass his
tests, even though they were old, or brilliant guitar players, or real
good at video games, I'd defend him.
I've screened a whole lot of programmers' resumes, interviewed a lot
of people, and hired a bunch. Nearly half my hires were foreign born
and educated; none had an H-1B. Many of my hires had college
degrees, and I didn't hold that against them, but high grades in
school, or prestige of the institution, didn't convince me to hire
anyone. I don't happen to have hired any UC Davis graduates, but two
of the best hires I ever made came from CSU Chico; they came to work
on day one, sat right down, and went to work learning our proprietary
language, operating system, and tools, with no fuss.
The companies I've worked at used highly paid experts to screen out
inappropriate resumes, so I didn't see the real junk. I still
examined ten to twenty resumes for every one that I chose for
telephone screening. About half of these were worth interviewing.
About half of the people interviewed got an offer. This is a lot of
work to go to for each hire, but it's a lot less costly than hiring
somebody that doesn't work out.
One time I was asked to "work the booth" at a Silicon Valley job fair.
That was when I saw the real losers, unfiltered. I stood behind a
table and talked briefly to each candidate in a long line. There were
all kinds of nice people. They deserved to have good jobs. But most
were light years from being able to work in a software company. One
example: a high school shop teacher. Really pleasant person. Anybody
who can do that job is organized, mature, and able to tolerate BS.
He'd taken a course in BASIC at a community college and wanted to
become a programmer. Cool, good idea. But I could meet my deadlines
with less cost and risk by hiring somebody else. I told him he needed
more courses and more experience.
On the other hand, I am quite sour on hiring H-1B workers. The
lengthy and expensive process of applying for one, and the rule that
you can't pay somebody until he has a visa, means that once you decide
to hire one of these workers, you have to wait six months. Forget it;
in the high tech environment, that's half the life of a company. The
H-1B workers can't go to another company without starting over with a
new application, and if their current employer finds out they're
looking, and terminates them, they have to leave the USA. This
happened to a company I worked for, and an important position
went unfilled for six months, and the worker ended up back at the
country of origin.
I have never seen any practice of paying workers less based on their
visa status. But companies, when hiring, make the lowest offer they
can that will get the worker, and it's quite possible that people who
need an H-1B will accept lower offers.
The assertion that H-1B workers' resumes lie about their credentials,
while American programmers' resumes do not, doesn't match my
observations. Lots of resumes are inflated, foreign and domestic.
When an interviewer discovers that someone claims to know more than he
actually does, in an area relevant to the job, that's an instant
turnoff. The few cases of blatant resume fraud I've encountered were
all Americans.
Professor Matloff writes, "any competent veteran programmer can become
productive in a new programming language in a couple of weeks on the
job." I wish it were that easy, but I don't think this is true,
especially for his example of a C programmer beginning to use Java.
Writing "C-in-Java" programs that aren't object oriented and use Java
poorly isn't really "productive." Object orientation isn't something
you pick up on the job in a couple of weeks.
The high-tech companies I know about expect new hires to learn on the
job. They want to choose people who'll succeed at this, and lots of
people can't. There is a 10 to 1 range in programming ability, that's
an old result, and there's another range of 10 to 1 in "performance
attributes" like being able to work in teams, make and keep
commitments, communicate clearly and openly, and learn new skills.
I've interviewed at companies where I was a perfect fit for the job,
and they said so, except that I was already making more than their
CEO. "Too bad for you," I said. (Hmm, come to think of it, all those
companies failed.) So I agree with Prof. Matloff that companies can
be short-sighted in their understanding of their best interest. I've
also met experienced programmers who feel that they deserve a
high-paying job with short hours and low pressure, and who think they
are being discriminated against when others will work harder for less
money.
$600 is not out of line for a "big changer." Especially if the radio could be controlled a little better. Car radio features I want:
a command that says "no talking." Distinguish music from speech via autocorrelation and change the channel when the announcer starts talking.
shucks, we could have a command that says "find classical music" or "find hard rock." ("prikazyvat radio, find beatles, please.")
commercials would respond to this by going to singing jingles. How about a command that says, "if you hear this, change the station"? ("prikazyvat radio, yuck." Obviously a macro.)
a command that finds a traffic report, or replays the last one it heard.
a command to hush for 30 seconds, e.g. my favorite station is playing a commercial I really hate. I do this manually now, but sometimes forget to turn it back up.
I have requested temporary relief from my hit quota. Best.com was pretty quick last time I was slashdotted, hope it's quick this time. They put in tiered pricing a few years back when people put up porn sites on Best's servers: rather than censor, they charge for bandwidth. I've been well served at the lowest tier.
When I saw the IBM System/38 announcement, I said to myself "a Multician worked on this." The nice thing about it was that it had a built-in database as its file-system abstraction. Many of the design choices in S/38 seemed to address problems we'd encountered in using Multics. Turned out I was right: one of the Multics designers had done a lot of consulting at IBM on FS, the "future system" IBM scrapped in 1975, and some of the FS features made it into S/38, the ancestor of AS/400.
I have been told by IBM colleagues that deep inside AIX, there's a virtual-memory file-mapping OS also derived from FS.
Does "Multics live on" here? No. The single-level store idea was used by several OS designs, and implemented in various ways. A better way to say it is that this feature "lives on."
The system features described were not the result of a committee, or of professors: they were done by one engineer, supported by the tools and process described in other papers at the website, in order to meet commercial requirements.
The "percentage" feature was required by university customers who funded their multi-million dollar machines by combining funds from multiple departments. The departments wanted to be sure they got what they paid for: "darn CS students are using more than their share of the machine."
The realtime scheduler was invented to win benchmarks, and it did. A relatively underpowered CPU was able to run specified workloads more efficiently that its competition, because of the tuning control available.
Both of these problems have gone away, now that each of us has more power on our desktops than the multi-million-dollar machines that a whole university used to have to share.
I am a fan of Unix and Mach. They solve different problems than the one Multics was solving, and do so in a different economic and technical world.
Slashdot Mirror
I think there are four things you need.
- commit to quality (has to be top to bottom)
- use systematic process (seems like you get this)
- check everything (at every stage)
- improve continuously (own your process and your meta process)
i wrote more about this at http://www.multicians.org/thvv/nasty.html
Chris Tavares wrote the original Cookie Monster program in 1970. Story is at http://www.multicians.org/cookie.html -- sounds like you used a descendant of the original. Source is available online. The program did not wander randomly: you had to start it while logged in, and it would then sleep and pop up messages later. People used to prank their co-workers when they found a terminal unattended.
This article was written by me, Tom Van Vleck.
T he original page has some pictures and useful
"monsterhead78" has just copied the text from
http://www.multicians.org/thvv/7094.html.
links.
"The UNIX Time-Sharing System," by Dennis Ritchie & Ken Thompson, is one of the best-written papers ever. The elegance of thought and economy of description set a standard we should all aspire to.t ml
t ml
http://cm.bell-labs.com/cm/cs/who/dmr/cacm.h
I list several more classics on my "Software Engineering Reading List" page at
http://www.multicians.org/thvv/swe-readings.h
A PhD shows that the candidate can finish something difficult, despite institutional BS. This is often a talent that transfers to jobs in big companies. Many PhD degrees also require some originality and creativity, which can come in handy in some jobs. There are other ways to prove this to an interviewer.
The PhD is not a guarantee of important attributes that may be needed in many jobs, such as the ability to cooperate with and respect others. The value of particular academic subjects and courses to a job is also something that an interviewer has to discover on a case by case basis. I hired a person with a PhD in Physics who was awesome at debugging, and he credited this to his training in design of experiments. Specific courses in Computer Science theory are not checklist items for most jobs: I have worked with folks who could not move beyond regurgitating what they had learned in class to actually thinking about the current problem, and that trait might be more common among people who have taken a lot of classes.. or not.
I wouldn't rank getting a PhD as the best way to command a high salary in computing careers. The best way to do that is to be outstandingly good at a rare and highly prized specialty, and to be able to communicate well. I know a guy who was a chip designer, one of the best in the world at some of the hottest companies. He made top dollar when he was working, and then spent some time unemployed, and then learned new skills, including managing.
You can't learn lessons from the past if you get your facts wrong.
Multics did not die when Bell labs pulled out early in its development. It continued to grow, became a commercial product, sold hundreds of millions of dollars of hardware (back when that was a lot of money), and was finally killed by the French in 1986. Systems remained in use until October 2000.
see http://www.multicians.org/myths.html for more on this and other incorrect ideas about Multics.
Multics is not owned by any company in Canada.
It is owned by Bull, a French company, which
acquired it from Honeywell, a thermostat company,
which bought GE's computer department in 1970.
The small Canadian company currently known as
CGI Group was contracted by Bull to provide
maintenance service to the remaining Multics
sites after Bull canceled OS development about
1987. Since there are no more Multics sites
running, I suspect that CGI group has no current
rights to Multics.
Understand, also, that in the late 60s and early
70s, systems copied ideas from each other more
freely than now, because it was generally viewed
that "you couldn't patent software."
More information about Multics is at
http://www.multicians.org/
- bloated with a sink full of dubious features
- had worse and worse support
- come out with almost yearly cosmetic releases
- abandoned Mac support
I have been planning to go to OS X and I am glad to hear that I won't have to buy another Quicken.Before I buy, there are two issues I will need answers to. One was already mentioned: database robustness. Quicken went through some rough times with corruption before they came up with repair procedures that were effective and safe.
The other is check printing. If you can print on 3-up checks, great.. but how do you print other than three at a time? This is a horrible mess, depends on all kinds of obscure stuff that changes with every combination of OS and printer. Quicken's method of aligning and printing checks on dot matrix printers was one of the things that helped it succeed early. But debugging this stuff on hundreds of printer models will be tedious and costly. I suggest that you create a user discussion board where people can share their experience on this sub-topic.
BBS-like functions were provided by
various mainframe timesharing systems well before
1978.
Multics had an online threaded discussion system
called "continuum" (later renamed "forum") which
I used while housebound during the Massachusetts
blizzard of 78. The Multics machine wouldn't
fit in my apartment though: I had a TermiNet 300
dialed up to MIT's Honeywell 6180.
Multics continuum was first written in the mid 70s
in order to bid on a RFP for the Executive Office
of the President of the United States
(we lost the bid, IBM got it).
At the time we were told that the capability
desired was similar to a discussion system on
the Dartmouth timesharing system.
The PLATO system at University of Illinois
had a threaded discussion system in the 70s,
as did a similar system, forget its name, at
Stanford.
Every place I worked that bought Sun servers then
had to go out and buy Oracle licenses, and deal with
finger pointing if the OS and the DBMS didn't
cooperate. The companies could combine, save
money on marketing, sell a more complete business
offering.
Problem is, who would run it? Larry or Scott?
of commercial tools that support extensive
script-driven testing of web applications.
SilkTest is the testing tool.
At my previous startup, we bought and used
these tools and developed extensive test
libraries for our product.
There are also companies that will test your
product for usability on many different platforms.
Look at http://www.otivo.com/ for one such.
(In the sixties at MIT, the Project MAC folks mostly thought that the school of management people were not in the forefront of the field. Undergraduates who were flunking out of EE would change majors to Management and coast through. I am sure things have changed since then but in those days, mis-identifying Madnick as a CS professor would get an immediate reaction.)
I've worked in several teams that
worked hard and played hard together.
Tom DeMarco speaks of "jelled" teams
and if a team is to come together in that
way I think you socialize too.
I worked on the Multics operating system for
16 years, and the annual Multics picnic was
one of many social events that I look back on
with pleasure: see
http://www.multicians.org/picnics.html
Other places I've worked didn't have that
kind of social interaction. People went home
after work and didn't socialize unless they
had some previous association. It was less fun.
When I wrote it in 1965 we called it MAIL.
This "e" business always sounded silly to me.
Multics had the same problem after crashes: it took a long time to bring the system back up because the "salvager" had to check every "VTOC entry." (fsck/inode in Unix terms)
We re-wrote the file system to do the necessary checking on each use of the directory and VTOC data, and eliminated the salvage during boot. Everything still got checked, but only as needed. Boot times went from hours to minutes, and the system was much more solid and reliable.
See http://www.multicians.org/thvv/marking.html
There is no contradiction here. I have been hiring programmers for many years. 50 resumes to one hire is actually less discriminating than many places I know of. A professor, who flunks incompetent students, knows that there are job applicants who are inappropriate for a given job opening. If someone accused Professor Matloff of discrimination because he gave F's to people who didn't pass his tests, even though they were old, or brilliant guitar players, or real good at video games, I'd defend him.
I've screened a whole lot of programmers' resumes, interviewed a lot of people, and hired a bunch. Nearly half my hires were foreign born and educated; none had an H-1B. Many of my hires had college degrees, and I didn't hold that against them, but high grades in school, or prestige of the institution, didn't convince me to hire anyone. I don't happen to have hired any UC Davis graduates, but two of the best hires I ever made came from CSU Chico; they came to work on day one, sat right down, and went to work learning our proprietary language, operating system, and tools, with no fuss.
The companies I've worked at used highly paid experts to screen out inappropriate resumes, so I didn't see the real junk. I still examined ten to twenty resumes for every one that I chose for telephone screening. About half of these were worth interviewing. About half of the people interviewed got an offer. This is a lot of work to go to for each hire, but it's a lot less costly than hiring somebody that doesn't work out.
One time I was asked to "work the booth" at a Silicon Valley job fair. That was when I saw the real losers, unfiltered. I stood behind a table and talked briefly to each candidate in a long line. There were all kinds of nice people. They deserved to have good jobs. But most were light years from being able to work in a software company. One example: a high school shop teacher. Really pleasant person. Anybody who can do that job is organized, mature, and able to tolerate BS. He'd taken a course in BASIC at a community college and wanted to become a programmer. Cool, good idea. But I could meet my deadlines with less cost and risk by hiring somebody else. I told him he needed more courses and more experience.
On the other hand, I am quite sour on hiring H-1B workers. The lengthy and expensive process of applying for one, and the rule that you can't pay somebody until he has a visa, means that once you decide to hire one of these workers, you have to wait six months. Forget it; in the high tech environment, that's half the life of a company. The H-1B workers can't go to another company without starting over with a new application, and if their current employer finds out they're looking, and terminates them, they have to leave the USA. This happened to a company I worked for, and an important position went unfilled for six months, and the worker ended up back at the country of origin.
I have never seen any practice of paying workers less based on their visa status. But companies, when hiring, make the lowest offer they can that will get the worker, and it's quite possible that people who need an H-1B will accept lower offers.
The assertion that H-1B workers' resumes lie about their credentials, while American programmers' resumes do not, doesn't match my observations. Lots of resumes are inflated, foreign and domestic. When an interviewer discovers that someone claims to know more than he actually does, in an area relevant to the job, that's an instant turnoff. The few cases of blatant resume fraud I've encountered were all Americans.
Professor Matloff writes, "any competent veteran programmer can become productive in a new programming language in a couple of weeks on the job." I wish it were that easy, but I don't think this is true, especially for his example of a C programmer beginning to use Java. Writing "C-in-Java" programs that aren't object oriented and use Java poorly isn't really "productive." Object orientation isn't something you pick up on the job in a couple of weeks.
The high-tech companies I know about expect new hires to learn on the job. They want to choose people who'll succeed at this, and lots of people can't. There is a 10 to 1 range in programming ability, that's an old result, and there's another range of 10 to 1 in "performance attributes" like being able to work in teams, make and keep commitments, communicate clearly and openly, and learn new skills.
I've interviewed at companies where I was a perfect fit for the job, and they said so, except that I was already making more than their CEO. "Too bad for you," I said. (Hmm, come to think of it, all those companies failed.) So I agree with Prof. Matloff that companies can be short-sighted in their understanding of their best interest. I've also met experienced programmers who feel that they deserve a high-paying job with short hours and low pressure, and who think they are being discriminated against when others will work harder for less money.
I have requested temporary relief from my hit quota. Best.com was pretty quick last time I was slashdotted, hope it's quick this time. They put in tiered pricing a few years back when people put up porn sites on Best's servers: rather than censor, they charge for bandwidth. I've been well served at the lowest tier.
I have been told by IBM colleagues that deep inside AIX, there's a virtual-memory file-mapping OS also derived from FS.
Does "Multics live on" here? No. The single-level store idea was used by several OS designs, and implemented in various ways. A better way to say it is that this feature "lives on."
The "percentage" feature was required by university customers who funded their multi-million dollar machines by combining funds from multiple departments. The departments wanted to be sure they got what they paid for: "darn CS students are using more than their share of the machine."
The realtime scheduler was invented to win benchmarks, and it did. A relatively underpowered CPU was able to run specified workloads more efficiently that its competition, because of the tuning control available.
Both of these problems have gone away, now that each of us has more power on our desktops than the multi-million-dollar machines that a whole university used to have to share.
I am a fan of Unix and Mach. They solve different problems than the one Multics was solving, and do so in a different economic and technical world.
Sorry. I have asked the ISP for temporary relief from its bandwidth limitation policy. They "strive to read all email within 24 hours." -- tom