20 Sep
2011
20 Sep
'11
1:11 p.m.
Yeah, that's true. What you can buy today is gigantic compared to what was available
not so long ago but now everything is digitized so stuff we used to keep on paper and
video tape or 8 tracks and film negatives is now on the hard drive. There's never
enough room any more and there probably won't ever be again.
------Original Message------
From: Chuck Guzis
Sender: cctalk-bounces at classiccmp.org
To: General Discussion: On-Topic and Off-Topic Posts
ReplyTo: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: New rsync mirroring at trailing-edge.com
Sent: 20 Sep 2011 16:45
On 20 Sep 2011 at 16:20, Vintage Coder wrote:
You guys and your extravagances!
I couldn't mirror it on one of my Sun boxes, the biggest drive I have
is 73G...
Well, I suppose it depends on your usage. To me, an 80G drive is
huge; I can't generate relevant content fast enough. To someone who
stores movies on their hard drive, it's unbelievably small. My
friend who's a photographer keeps buying TB drives to hold his work.
--Chuck
20 Sep
20 Sep
2:01 p.m.
Yeah, that's true. What you can buy today is gigantic compared to what
was available not so long ago but now everything is digitized so stuff
we used to keep on paper and video tape or 8 tracks and film negatives
is now on the hard drive. There's never enough room any more and there
I guess that's how I manage to only need a tiny (by modern standards)
hard drive. Manuals and books are on paper, photographs are silver images
and audio recordings, well not 8-tracks, please... 1/4" recording tape.
probably won't ever be again.
I think it's a well-known fact that you never have enough disk space (or,
indeed, physical space for uour machines, test gear, tools, etc).
Joking aside, biutsavers is a tremendous resource from both the
historical and practical standpoint. It is much appreicated here. Long
may it continue!
-tony
3:47 p.m.
New subject: RANT: Never enough room (was: New rsync mirroring at
Yeah, that's true. What you can buy today is
gigantic compared to what
was available not so long ago but now everything is digitized so stuff
we used to keep on paper and video tape or 8 tracks and film negatives
is now on the hard drive. There's never enough room any more and there
probably won't ever be again.
Boyle's Law states that a gas will expand to fit the available space.
Data, software, and commercial software products do, also.
Moore's Law (which is an observation, not a law) holds that speed
and capacity will double every 18 months.
That isn't enough when content (and size of MICROS~1 products) doubles
every 17 months.
MICROS~1 seems to use Moore's Law as a design tool - always design
everything to require twice the speed and capacity of current technology.
If speed and storage efficiency of the product isn't adequate, throw
hardware at it.
Seriously though, part of the problem is that MICROS~1 seems to believe
(or at least used to) in treating programmers well. Programmers always
use current state of the art, rather than using machines representative of
what the customers have. If a programmer fills the drive, they give them
a bigger one. If a programmer gripes about speed, they provide a faster
machine. Therefore, without necessarily any such INTENT, they are in a
world of unlimited resource, produce products that expect better resources
that what the customers have, and push the industry towards following
Moore's Law.
If a progammer has a flaky machine, it gets replaced immediately. Should
that really always be done, even for those writing exception handlers? An
unfortunate consequence is that those writing code to handle errors have
no experience with them, and SIMULATED errors do NOT behave like the real
thing. If MICROS~1 were to trade computers with us, the next round of
software would be more efficient (faster and using space more
effectively), and significantly less buggy, since they would have to put
up with slow performance, running out of disk and memory space, and would
experience the bugs of the real world.
As an example of OS bugs directly related to MICROS~1 programmers not
having adequate real world bug experience, SMARTDRV became MANDATORY
starting with Windoze 3.10 Beta. When it would hit a sector read/write
error, it would have already told the installer that that part of the task
had been successfully completed! Therefore, it could not "Ignore" and
continue. It could not "Abort" or "Fail" that part of the task,
because
it had "alredy been completed". Therefore, the ONLY option for the
critical error handler was "RETRY". Even in cases where that could not
possibly succeed. Normal SOP would previously have been to IGNORE, record
the filename, complete the installation and then go back and manually
repair/replace THAT file. But THAT is not an option. The ONLY way out of
the RETRY loop is to reboot. BUT, since SMARTDRV wrote the DIRectory
sectors AFTER all else was done (and had not been done at the time of the
REBOOT), there is no trace of the aborted installation.
On Windoze 3.10 beta installation, I hit a sector error that Spinrite,
etc. could not find. When I reported the problem, MS "beta Support"
declared it to be a "Hardware Problem - NOT OUR PROBLEM". I attempted to
point out that:
1) It IS the responsibility of the OS to properly handle hardware problems.
2) SMARTDRV installation should be OPTIONAL, or at least OVER-RIDABLE,
such as a command line switch for SETUP to specify not installing or
activating it.
3) SMARTDRV's write caching will eventually cause significant data loss.
Because of the "background" unpublicized nature of it, OTHER PROGRAMS
will get blamed for the loss.
I was not invited to any further beta testings.
MS-DOS 6.00 added SMARTDRV and disk compression.
Most word processor and spreadsheet users were in the habit of saving
their file, and turning off the machine as soon as the DOS prompt
re-appeared. Of couse, with write-caching, the file had not yet been
written when the flow of computrons ceased.
Soon, the press was flooded with stories of "Microsoft disk compression
causing data loss!"
Infoworld, for example, ran dozens of such stories. They ran a test suite
that did a bunch of office macros, then did a cold boot, in a loop. Of
course, the SMARTDRV write cacheing was wiped by the reboots, and data was
lost.
Bill Gates called the editor of Infoworld and told them that their test
procedure was flawed. What else was he going to say? that there WAS a
known intolerable problem, but that it was a DIFFERENT part of the OS
that was for real at fault? BIG TIME.
Infoworld reported that phone call as "harrassment" and
"intimidation".
Eventually, to maintain public image, MICROS~1 had to fix "the disk
compression bugs". The repair, which was released as a FREE "STEPUP"
upgrade from 6.00 to 6.20 (6.10 was in use by IBM), consisted of:
FIX DISK COMPRESSION BUGS:
1) Disable SMARTDRV write-cacheing
2) IF write-cacheing were deliberately re-enabled
a) delay re-display of DOS prompt until buffers had been written
b) disable the rearrangement of writes, so that what writes were done
would be in chronological order
(The differences between 6.20, 6.21, and 6.22 were unrelated, and due to
having the disk compression (6.20), losing the IP court case with STACer
(6.21 without compression), and re-releasing with a different compression
program (6.22))
--
Grumpy Ol' Fred cisin at xenosoft.com
3:50 p.m.
New subject: RANT: Never enough room (was: New rsync mirroring at
In summary: Grumpy Ol' Fred
4:13 p.m.
New subject: RANT: Never enough room (was: New rsync mirroring at
On Tue, 20 Sep 2011, Glen Slick wrote:
In summary: Grumpy Ol' Fred
I concede that my attitude can be a "bit" cynical.
But do you contest the points that I attempted to make?
--
Grumpy Ol' Fred cisin at xenosoft.com
21 Sep
21 Sep
10:42 a.m.
New subject: RANT: Never enough room
At 03:13 PM 9/20/2011, Fred Cisin wrote:
I concede that my attitude can be a "bit"
cynical.
But do you contest the points that I attempted to make?
Of course not. And there are many more points to be made about error
checking. Personally, for the era you speak of, I blame Charles Petzold
for writing code examples that didn't error-check, then putting them in a book.
At 05:41 PM 9/20/2011, Ian King wrote:
We did test, and test and test and test. We had
databases filled with bug reports, thousands upon thousands of them for any given product.
It's not that the test process doesn't exist or that it's not effective.
It's the priority given to quality vs. ship dates and new feature sets. -- Ian
I'm glad you mentioned that. I don't have any doubt that the software
industry has better tools, more experience, and more expertise for software
testing than ever before. Whether companies choose to use it, and how they
interpret the results and assess the risk of shipping - that's another story.
Software delivery over the Internet has certainly changed the landscape, too,
making it very easy to patch your program every few days once it is in
the field (cough Adobe Acrobat cough).
The days of putting disks in boxes are long gone.
As for the connection between consuming disk space and software testing,
I'm routinely appalled at the way programs leave megs and megs of temp
files, past install patches, etc. all over users' drives without regard.
Or why an HP printer driver or a .NET upgrade takes 20 minutes to install.
Cynically, I think it's all working well towards Windows eventually
having the more Unix-like separation of user data and program files.
The lesson will be re-learned.
- John
1:54 p.m.
New subject: RANT: Never enough room
At 05:41 PM 9/20/2011, Ian King wrote:
>We did test, and test and test and test. We had databases filled with
>bug reports, thousands upon thousands of them for any given product.
>It's not that the test process doesn't exist or that it's not
>effective. It's the priority given to quality vs. ship dates and new
>feature sets. -- Ian
We actually do appreciate the attempts. But, think about: how could it
have been POSSIBLE to reach shipping without SMARTDRV NEVER having hit a
disk write error? (When that happened, it locked up the machine in an
inescapable loop!) Was EVERY bit of the testing done on perfect machines?
Or was the error, when found, handled the way that Win3.10 Beta support
handled my report - "Somebody Else's Problem!"
My comment about sticking the programmers on flaky slow machines was
partially exaggerated. But, at least some of the testing needs to be done
that way.
>I concede that my attitude can be a
"bit" cynical.
>But do you contest the points that I attempted to make?
On Wed, 21 Sep 2011, John Foust wrote:
Of course not. And there are many more points to be
made about error
checking. Personally, for the era you speak of, I blame Charles Petzold
for writing code examples that didn't error-check, then putting them in
a book.
There's a fine line that needs to be walked. The complete beginner needs
to be given a chance to start off with success at something trivial - I
used to start every programming course with having them write a program to
put their own name on the screen ("Hello, world" was NOT acceptable, as
then one person did the homework for a dozen students). Another teacher
who did such in the classrooom and didn't assign anything until they were
"ready" to input three numbers and output a calculated value ("Carbon 14
dating"!!) could never understand why the students who nodded attentively
in class couldn't do the first assignment.
BUT, as soon as they do ANY input, it is time to teach error and validity
checking. (and to NOT trust scanf() with unformatted input!). And then,
whenever there is anything that could POSSIBLY have a problem (such as
disk I/O), teach planning for all possible problems.
The days of putting disks in boxes are long gone.
I miss the days of Zip-lock bag with a disk and a few sheets of stapled
paper.
As for the connection between consuming disk space and
software testing,
I'm routinely appalled at the way programs leave megs and megs of temp
files, past install patches, etc. all over users' drives without regard.
Very bad housekeeping habits!
Or why an HP printer driver or a .NET upgrade takes 20
minutes to install.
Horrible disregard for efficiency
Cynically, I think it's all working well towards
Windows eventually
having the more Unix-like separation of user data and program files.
The lesson will be re-learned.
Why must every trivial program alter OS?
--
Grumpy Ol' Fred cisin at xenosoft.com
2:10 p.m.
New subject: RANT: Never enough room
At 12:54 PM 9/21/2011, Fred Cisin wrote:
There's a fine line that needs to be walked. The
complete beginner needs
to be given a chance to start off with success at something trivial
Windows programmers using Petzold's book weren't Comp Sci 101 students.
They were existing programmers who wanted to learn Windows. I'd argue
that showing proper error handling for a Windows function is just
as important as demonstrating how to call the function. So much of his
crap code was copied-and-pasted into place.
Why does it still feel like apps under Windows XP are running out of stack?
Twenty years later, their failure modes still feel like Windows apps
aren't checking return values on calls that might fail when allocating
special RAM.
- John
2:48 p.m.
New subject: RANT: Never enough room
>There's a fine line that needs to be walked.
The complete beginner needs
>to be given a chance to start off with success at something trivial
On Wed, 21 Sep 2011, John Foust wrote:
Windows programmers using Petzold's book
weren't Comp Sci 101 students.
They were existing programmers who wanted to learn Windows. I'd argue
For a while, Petzold seemed to be the ONLY way to learn Windoze
programming.
that showing proper error handling for a Windows
function is just
as important as demonstrating how to call the function.
Absolutely!
The RETURN is half of the function call.
And, I've had students contest their grade when they wrote code that put
out the correct result and CRASHED.
So much of his crap code was copied-and-pasted into
place.
Why does it still feel like apps under Windows XP are running out of stack?
Twenty years later, their failure modes still feel like Windows apps
aren't checking return values on calls that might fail when allocating
special RAM.
Too many people never seem to learn that a program that works is NOT
"correct" unless it would also work with bad inputs or other conditions.
"Your program worked! That's a very good START. Now, what happens if the
user types in 0 for the input value? What happens if the user types in
"NO" instead of a number? What happens if the user puts a space in the
middle of the name that they are supposed to type in?"
3:06 p.m.
New subject: RANT: Never enough room
On 9/21/11 1:48 PM, Fred Cisin wrote:
Too many people never seem to learn that a program
that works is NOT
"correct" unless it would also work with bad inputs or other conditions.
"Your program worked! That's a very good START. Now, what happens if the
user types in 0 for the input value? What happens if the user types in
"NO" instead of a number? What happens if the user puts a space in the
middle of the name that they are supposed to type in?"
Several years ago I wrote a very simple interactive shell script[1]
that set up a class environment from a CD, on a fresh Linux install.
The OS version was fixed and the installation was automated, so no
variables there. The operators expected to run the script had a minimum
level of Linux skills. They also had access to a central help desk.
The initial script, which accepted input where needed and resulted in
a complete, correct setup, was about 75 lines. The delivered script was
over 800 lines, about half comments and half error-checking. It was
about the most heinous work of art I ever delivered.
Doc
[1] bash was not the most efficient way to do it, but it was the most
universally accessible. The client wanted something internally
documented and easily maintained and expanded.
3:11 p.m.
New subject: RANT: Never enough room
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Fred Cisin
Sent: Wednesday, September 21, 2011 11:48 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: RANT: Never enough room
[snip]
Too many people never seem to learn that a program that works is NOT
"correct" unless it would also work with bad inputs or other conditions.
"Your program worked! That's a very good START. Now, what happens if the
user types in 0 for the input value? What happens if the user types in
"NO" instead of a number? What happens if the user puts a space in the
middle of the name that they are supposed to type in?"
Many, many years ago, back before I'd learned anything like QA or test methodology, I
was writing an application (command line!) that required freeform user input. After
I'd thought of everything I could think of, I asked the office manager to help me out.
I didn't tell her anything about the program (although she knew the general idea of
it) and asked her to just type any sort of thing that popped into her head. When she
couldn't crash the app or corrupt the database, I figured I was done. :-) -- Ian
3:29 p.m.
New subject: RANT: Never enough room
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Ian King
Sent: Wednesday, September 21, 2011 12:12 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: RANT: Never enough room
[snip]
Too many people never seem to learn that a program that works is NOT
"correct" unless it would also work with bad inputs or other conditions.
"Your program worked! That's a very good START. Now, what happens if
the
user types in 0 for the input value? What
happens if the user types in
"NO" instead of a number? What happens if the user puts a space in the
middle of the name that they are supposed to type in?"
Many, many years ago, back before I'd learned anything like QA or test
methodology, I was writing an application (command line!) that required
freeform user input. After I'd thought of everything I could think of, I asked
the office manager to help me out. I didn't tell her anything about the
program (although she knew the general idea of it) and asked her to just
type any sort of thing that popped into her head. When she couldn't crash
the app or corrupt the database, I figured I was done. :-) -- Ian
7:06 p.m.
New subject: RANT: Never enough room
From: Ian King
Sent: Wednesday, September 21, 2011 12:29 PM
One of my personal all-time favourites.
7:33 p.m.
New subject: RANT: Never enough room
When I first learned of SQL injection exploits, my first thought was, "Is this a
joke?" It seems so painfully obvious - which, of course is how most of these things
look in retrospect.
Hindsight is an exact science. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of
Rich Alderson [RichA at vulcan.com]
Sent: Wednesday, September 21, 2011 4:06 PM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: RE: RANT: Never enough room
From: Ian King
Sent: Wednesday, September 21, 2011 12:29 PM
One of my personal all-time favourites.
9:20 p.m.
New subject: RANT: Never enough room
On 22/09/2011, at 7:33 AM, Ian King wrote:
When I first learned of SQL injection exploits, my
first thought was, "Is this a joke?" It seems so painfully obvious - which, of
course is how most of these things look in retrospect.
Hindsight is an exact science. -- Ian
You're right, it is obvious, but not just in retrospect. It's obvious in any
situation you need to produce a delimited string, your first question should be, what if
my string contains a delimiter? And then, can I escape the delimiter or just filter it
out? Can I avoid escaping/filtering (blacklist) and only allow a subset of characters in
the first place (whitelist)?
The fact that we've had so many privacy breaches, intrusions, data loss, defacements,
credit card fraud, etc. due to this blindingly simple issue is downright pathetic. These
"programmers" should be held liable for negligence.
Oh, and hi list. I'm new here. :)
Scott.
22 Sep
22 Sep
9:16 a.m.
New subject: RANT: Never enough room
On Wed, 21 Sep 2011, Rich Alderson wrote:
...and Pick and other MV dbs are totally immune to crap like that. :)
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.simpits.org/geneb - The Me-109F/X Project
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Political correctness is a doctrine, fostered by a delusional, illogical
minority, and rabidly promoted by an unscrupulous mainstream media, which
holds forth the proposition that it is entirely possible to pick up a turd
by the clean end.
From: Ian
King
Sent: Wednesday, September 21, 2011 12:29 PM
One of my personal all-time favourites. 
21 Sep
21 Sep
2:37 p.m.
New subject: RANT: Never enough room
BUT, as soon as they do ANY input, it is time to teach
error and validity
checking. (and to NOT trust scanf() with unformatted input!). And then,
whenever there is anything that could POSSIBLY have a problem (such as
disk I/O), teach planning for all possible problems.
I returned an Open University assignment with some validity checking that was
not in the question and got down marked!
wtf.....
Dave Caroline
20 Sep
20 Sep
5:06 p.m.
New subject: RANT: Never enough room
On 9/20/11 12:47 PM, Fred Cisin wrote:
Seriously though, part of the problem is that MICROS~1
seems to believe
(or at least used to) in treating programmers well.
MSFT programmers do what the Program Managers tell them to, right or wrong.
Every programmer I know that has worked for them have a universal hatred of
them.
So, don't blame the programmers.
6:16 p.m.
New subject: RANT: Never enough room
On 9/20/2011 2:06 PM, Al Kossow wrote:
On 9/20/11 12:47 PM, Fred Cisin wrote:
I would submit that the programmers should not
be seeing flaky hardware
upon which to do their development. The process should be to develop
requirements, design, implement and test.
The process at MS clearly had not found out how to test, and if the
product was not handling the problem, then they failed totally up front
in developing requirements.
Since they rushed out a hack to rip of Stac-er or whatever it was,
clearly almost one of the above methodology was followed, as you pointed
out with illustrations.
However it does no good to have a workstation in front of a programmer
which doesn't work. The way to handle the problem is to give the
problem of anticipating failures to someone who can develop test cases,
which the product can be thrown at by the testers. Otherwise, how do
you know if you have tested it again. One should be able to trace all
the functions of the program back through to a use case which has been
thought out, including ones which should be covering failing cases.
You'd be way further down the line with that product than either what is
there, or one developed by a programmer on flaky hardware, or unknown
failure cases.
the Beta program should not necessarily include someone with the
problems you had w/o being sure they are doing the use case testing that
makes sense, and in any case they should never ignore a concise report
of a problem.
jim
Seriously though, part of the problem is that
MICROS~1 seems to believe
(or at least used to) in treating programmers well.
MSFT programmers do what the Program Managers tell them to, right or
wrong.
Every programmer I know that has worked for them have a universal
hatred of
them.
So, don't blame the programmers.
6:41 p.m.
New subject: RANT: Never enough room
We did test, and test and test and test. We had databases filled with bug reports,
thousands upon thousands of them for any given product. It's not that the test
process doesn't exist or that it's not effective. It's the priority given to
quality vs. ship dates and new feature sets. -- Ian
________________________________________
From: cctalk-bounces at classiccmp.org [cctalk-bounces at classiccmp.org] On Behalf Of Jim
Stephens [jws at jwsss.com]
Sent: Tuesday, September 20, 2011 3:16 PM
To: On-Topic and Off-Topic Posts
Subject: Re: RANT: Never enough room
On 9/20/2011 2:06 PM, Al Kossow wrote:
On 9/20/11 12:47 PM, Fred Cisin wrote:
I would submit that the programmers should not
be seeing flaky hardware
upon which to do their development. The process should be to develop
requirements, design, implement and test.
The process at MS clearly had not found out how to test, and if the
product was not handling the problem, then they failed totally up front
in developing requirements.
Since they rushed out a hack to rip of Stac-er or whatever it was,
clearly almost one of the above methodology was followed, as you pointed
out with illustrations.
However it does no good to have a workstation in front of a programmer
which doesn't work. The way to handle the problem is to give the
problem of anticipating failures to someone who can develop test cases,
which the product can be thrown at by the testers. Otherwise, how do
you know if you have tested it again. One should be able to trace all
the functions of the program back through to a use case which has been
thought out, including ones which should be covering failing cases.
You'd be way further down the line with that product than either what is
there, or one developed by a programmer on flaky hardware, or unknown
failure cases.
the Beta program should not necessarily include someone with the
problems you had w/o being sure they are doing the use case testing that
makes sense, and in any case they should never ignore a concise report
of a problem.
jim
Seriously though, part of the problem is that
MICROS~1 seems to believe
(or at least used to) in treating programmers well.
MSFT programmers do what the Program Managers tell them to, right or
wrong.
Every programmer I know that has worked for them have a universal
hatred of
them.
So, don't blame the programmers.
7:50 p.m.
New subject: RANT: Never enough room
On 9/20/2011 3:41 PM, Ian King wrote:
It's not that the test process doesn't
exist or that it's not effective. It's the priority given to quality vs. ship
dates and new feature sets. -- Ian
We have the same problem now, throw out
functions that don't work to get
product shipped. The bugs like Fred saw should have a way to be
identified somehow and get the problem fixed or not shipped. It isn't
an easy problem to deal with.
It's always scary when well tested bits are pulled for "better"
solutions at the last minute too.
Jim
8:21 p.m.
New subject: RANT: Never enough room
Fred Cisin wrote:
Yeah,
that's true. What you can buy today is gigantic compared to what
was available not so long ago but now everything is digitized so stuff
we used to keep on paper and video tape or 8 tracks and film negatives
is now on the hard drive. There's never enough room any more and there
probably won't ever be again.
Boyle's Law states that a gas will expand to fit the available space.
Data, software, and commercial software products do, also.
Moore's Law (which is an observation, not a law) holds that speed
and capacity will double every 18 months.
That isn't enough when content (and size of MICROS~1 products) doubles
every 17 months.
MICROS~1 seems to use Moore's Law as a design tool - always design
everything to require twice the speed and capacity of current technology.
If speed and storage efficiency of the product isn't adequate, throw
hardware at it.
Seriously though, part of the problem is that MICROS~1 seems to believe
(or at least used to) in treating programmers well. Programmers always
use current state of the art, rather than using machines representative of
what the customers have. If a programmer fills the drive, they give them
a bigger one. If a programmer gripes about speed, they provide a faster
machine. Therefore, without necessarily any such INTENT, they are in a
world of unlimited resource, produce products that expect better resources
that what the customers have, and push the industry towards following
Moore's Law.
If a progammer has a flaky machine, it gets replaced immediately. Should
that really always be done, even for those writing exception handlers? An
unfortunate consequence is that those writing code to handle errors have
no experience with them, and SIMULATED errors do NOT behave like the real
thing. If MICROS~1 were to trade computers with us, the next round of
software would be more efficient (faster and using space more
effectively), and significantly less buggy, since they would have to put
up with slow performance, running out of disk and memory space, and would
experience the bugs of the real world.
As an example of OS bugs directly related to MICROS~1 programmers not
having adequate real world bug experience, SMARTDRV became MANDATORY
starting with Windoze 3.10 Beta. When it would hit a sector read/write
error, it would have already told the installer that that part of the task
had been successfully completed! Therefore, it could not "Ignore" and
continue. It could not "Abort" or "Fail" that part of the task,
because
it had "alredy been completed". Therefore, the ONLY option for the
critical error handler was "RETRY". Even in cases where that could not
possibly succeed. Normal SOP would previously have been to IGNORE, record
the filename, complete the installation and then go back and manually
repair/replace THAT file. But THAT is not an option. The ONLY way out of
the RETRY loop is to reboot. BUT, since SMARTDRV wrote the DIRectory
sectors AFTER all else was done (and had not been done at the time of the
REBOOT), there is no trace of the aborted installation.
On Windoze 3.10 beta installation, I hit a sector error that Spinrite,
etc. could not find. When I reported the problem, MS "beta Support"
declared it to be a "Hardware Problem - NOT OUR PROBLEM". I attempted to
point out that:
1) It IS the responsibility of the OS to properly handle hardware problems.
2) SMARTDRV installation should be OPTIONAL, or at least OVER-RIDABLE,
such as a command line switch for SETUP to specify not installing or
activating it.
3) SMARTDRV's write caching will eventually cause significant data loss.
Because of the "background" unpublicized nature of it, OTHER PROGRAMS
will get blamed for the loss.
I was not invited to any further beta testings.
MS-DOS 6.00 added SMARTDRV and disk compression.
Most word processor and spreadsheet users were in the habit of saving
their file, and turning off the machine as soon as the DOS prompt
re-appeared. Of couse, with write-caching, the file had not yet been
written when the flow of computrons ceased.
Soon, the press was flooded with stories of "Microsoft disk compression
causing data loss!"
Infoworld, for example, ran dozens of such stories. They ran a test suite
that did a bunch of office macros, then did a cold boot, in a loop. Of
course, the SMARTDRV write cacheing was wiped by the reboots, and data was
lost.
Bill Gates called the editor of Infoworld and told them that their test
procedure was flawed. What else was he going to say? that there WAS a
known intolerable problem, but that it was a DIFFERENT part of the OS
that was for real at fault? BIG TIME.
Infoworld reported that phone call as "harrassment" and
"intimidation".
Eventually, to maintain public image, MICROS~1 had to fix "the disk
compression bugs". The repair, which was released as a FREE "STEPUP"
upgrade from 6.00 to 6.20 (6.10 was in use by IBM), consisted of:
FIX DISK COMPRESSION BUGS:
1) Disable SMARTDRV write-cacheing
2) IF write-cacheing were deliberately re-enabled
a) delay re-display of DOS prompt until buffers had been written
b) disable the rearrangement of writes, so that what writes were done
would be in chronological order
(The differences between 6.20, 6.21, and 6.22 were unrelated, and due to
having the disk compression (6.20), losing the IP court case with STACer
(6.21 without compression), and re-releasing with a different compression
program (6.22))
--
Grumpy Ol' Fred cisin at xenosoft.com
from initializing itself. The support group was
totally useless and the
solution was trivial - when the higher priority job first
started, it only
needed to suspend operations long enough to allow MU-BASIC to
initialize itself and begin normal operation. Then RT-11 gave the
higher priority job all the time it needed to execute (about 10% of the
CPU time) and everything was OK.
On another occasion, a bug was found in SRCCOM.SAV (two tests
were done in the wrong order) resulting in the extra memory that was
available not being used. DEC was totally uninterested and I don't
think that the error was ever corrected.
I admit that by 1991, most of the development on RT-11 probably
stopped short of adding Y2K support for RT-11 even though the
Y2K bugs had been fixed in a number of places without the user
being aware since only 2 digit years were displayed. An obvious
example was V05.06 of MACRO.SAV which had no changes
when V05.07 of RT-11 was released in 1998 with the rest of
the Y2K bugs fixed.
I agree that at least DEC was experiencing great turmoil by 1990
and that must have been a great problem for continued development -
let alone that PDP-11 hardware had essentially been frozen and VMS
was probably considered the only important product at that point -
at least until Compaq bought DEC - which in turn was bought by HP.
It is not completely clear to me why Ken Olsen could be so brilliant
up until 1980, but failed to see and make the necessary changes to
DEC thereafter. So MICROS~1 is not the only company with
bad management. With all of the seven dwarves gone and IBM
a very different company, it would seem that software development
has been unable to achieve the same sort of advances seen by
hardware.
I strongly agree with your point about error handling. I suspect that
most of the code I write uses about half of the instructions to handle
error conditions - which occur less than 1% of the time and some of
which never occur, but just in case. I find that when error conditions
are handled correctly, the program rarely gets into difficulty. And
it is much easier and takes much less time to handle the errors correctly
when the program is being written than to integrate the error handling
code into the program after everything else has been completed.
Jerome Fine
9:34 p.m.
New subject: RANT: Never enough room
On 20/09/11 3:47 PM, Fred Cisin wrote:
This is very true and may be the only realistic way of turning back the
tide of bloat, poor design and poor architecture. Programmers should be
on SLOW machines! Otherwise what we get is a kind of software-enforced
hardware obsolescence, which is just wrong.
(The problem isn't limited to Microsoft, though. The rant might have
reasonably focused on them in the 1990s, but are they even relevant any
more?)
--Toby
Yeah,
that's true. What you can buy today is gigantic compared to what
was available not so long ago but now everything is digitized so stuff
we used to keep on paper and video tape or 8 tracks and film negatives
is now on the hard drive. There's never enough room any more and there
probably won't ever be again.
Boyle's Law states that a gas will expand to fit the available space.
Data, software, and commercial software products do, also.
Moore's Law (which is an observation, not a law) holds that speed
and capacity will double every 18 months.
That isn't enough when content (and size of MICROS~1 products) doubles
every 17 months. ...
Seriously though, part of the problem is that MICROS~1 seems to believe
(or at least used to) in treating programmers well. Programmers always
use current state of the art, rather than using machines representative of
what the customers have. ...
If MICROS~1 were to trade computers with us, the next round of
software would be more efficient (faster and using space more
effectively), and significantly less buggy, since they would have to put
up with slow performance, running out of disk and memory space, and would
experience the bugs of the real world.
--
Grumpy Ol' Fred cisin at xenosoft.com
9:56 p.m.
New subject: RANT: Never enough room
----- Original Message -----
From: "Toby Thain" <toby at telegraphics.com.au>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Tuesday, September 20, 2011 9:34 PM
Subject: Re: RANT: Never enough room
This is very true and may be the only realistic way of turning back the
tide of bloat, poor design and poor architecture. Programmers should be
on SLOW machines! Otherwise what we get is a kind of software-enforced
hardware obsolescence, which is just wrong.
(The problem isn't limited to Microsoft, though. The rant might have
reasonably focused on them in the 1990s, but are they even relevant any
more?)
--Toby
The problem is people blindly upgrading their computer/OS/Software for no
real reason. I don't understand why you need to have the latest version of
most mature apps when very few people need or will use those new features.
Older apps and OS fly on new hardware, why upgrade?
Programmers target the machines that they expect to be the norm when their
software is released.
10:52 p.m.
New subject: RANT: Never enough room
On 20/09/11 9:56 PM, TeoZ wrote:
----- Original Message ----- From: "Toby Thain" <toby at
telegraphics.com.au>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Tuesday, September 20, 2011 9:34 PM
Subject: Re: RANT: Never enough room
Yes, that's a problem too.
This is very true and may be the only realistic way of turning back the
tide of bloat, poor design and poor architecture. Programmers should be
on SLOW machines! Otherwise what we get is a kind of software-enforced
hardware obsolescence, which is just wrong.
(The problem isn't limited to Microsoft, though. The rant might have
reasonably focused on them in the 1990s, but are they even relevant any
more?)
--Toby
The problem is people blindly upgrading their computer/OS/Software for
no real reason. I don't understand why you need to have the
latest
version of most mature apps when very few people need or will use those
new features. Older apps and OS fly on new hardware, why upgrade?
Programmers target the machines that they expect to be the norm when
their software is released.
They wouldn't, if they didn't have them on their desks. A bit of tough
love may be needed.
Look at the payoff: For all the fools blowing money on new hardware they
don't need, get a FASTER system because the software is so much more
efficient (having been tested on slow hardware); and those with older
hardware will continue to be able to use it effectively.
Can't see any downside here. And pointless consumption has to end, anyway.
--Toby
11:06 p.m.
New subject: RANT: Never enough room
----- Original Message -----
From: "Toby Thain" <toby at telegraphics.com.au>
To: <cctalk at classiccmp.org>
Sent: Tuesday, September 20, 2011 10:52 PM
Subject: Re: RANT: Never enough room
Can't see any downside here. And pointless
consumption has to end, anyway.
--Toby
Pointless consumption will have to get worse. We are a society where all
companies live and die by revenue increases every year yet western
birthrates are shrinking along with wages. Less people with less money yet
still needing more consumption to get keep the economy floating along.
Anyway I expect computer companies will start recycling old system with new
case colors to sell to people every three years when our Chinese credit card
gets maxed out.
10:05 p.m.
New subject: RANT: Never enough room
You know, in the current IEEE Computer, there was a study about the
impact of software bloat. For the life of me, I can't figure out
what the conclusions and recommendations were.
The article was too bloated.
--Chuck
21 Sep
21 Sep
10:36 a.m.
New subject: RANT: Never enough room
On 2011-09-20 13:47, Fred Cisin wrote:
If a progammer has a flaky machine, it gets replaced
immediately. Should
that really always be done, even for those writing exception handlers? An
unfortunate consequence is that those writing code to handle errors have
no experience with them, and SIMULATED errors do NOT behave like the real
thing.
Thanks Fred, that is a good one. I'm trying to make some disk analyzer
tools, so I'm collecting defective/broken hard drive to figure out, how
they behave. Don't care to much about working ones ;-)
4729
days inactive
4731
days old
27 comments
18 participants
participants (18)
-
aek＠bitsavers.org -
ard＠p850ug1.demon.co.uk -
cclist＠sydex.com -
cisin＠xenosoft.com -
dave.thearchivist＠gmail.com -
doc＠vaxen.net -
emu＠e-bbes.com -
geneb＠deltasoft.com -
glen.slick＠gmail.com -
IanK＠vulcan.com -
jfoust＠threedee.com -
jhfinedp3k＠compsys.to -
jws＠jwsss.com -
RichA＠vulcan.com -
scott＠kevill.com -
teoz＠neo.rr.com -
toby＠telegraphics.com.au -
vintagecoder＠aol.com