Motivation of software professionals

[James Kanze]

I think it may be done occasionally. Certainly, if I had
contractual penalties for downtime, and my choices were
Windows or Linux, I'd run free software.

I'd use Windows XP before Linux, but frankly... I'd avoid
standard PC's completely: (modern) Solaris on a Sparc, or HP/UX
on HP's PA would be my choices. (Supposing I needed a real
general purpose system. Some of the embedded systems are
probably even more reliable.)

 

[James Kanze]

I've got mixed opinions on this. The real review takes place
off line. Explanation and discussion of possible solutions (I
know, a code walthru isn't supposed to consider solutions- a
daft idea if you ask me [1]) at a meeting.

Design meeetings can work.

It's always difficult to find the right balance, because people
do vary. What I think is certain is that you do need some time
isolated, to let your ideas jell, and you need some meetings, at
least at either end: brainstorming sessions before really
starting, and code reviews after the code has been written.
Between the two, different people probably have different needs.
A lot of people claim that they're most effective in pair
programming, for example, where as I (and some others I know)
would be much less effective if I couldn't do large parts of the
work more or less in isolation.

 

[Martin Gregorie]

I'd use Windows XP before Linux, but frankly... I'd avoid standard PC's
completely: (modern) Solaris on a Sparc, or HP/UX on HP's PA would be my
choices. (Supposing I needed a real general purpose system. Some of
the embedded systems are probably even more reliable.)

If uptime is the main criterion, your only options are fault tolerant
systems. Off the shelf that means Stratus or Tandem (now HP) Guardian
NonStop systems. This is the kit you find running telcos, inter-bank
networks, ATM networks, etc.

That apart, the most reliable system I've used is Microware's OS-9/68k, a
modular real-time OS. I've been running it almost every day since 1992
and have never found a bug in the system software despite applying Y2K
patches to it. I haven't replaced any hardware since 1993 either: not
even disks.

 

[Mike Schilling]

To be honest things were always simpler in the past.

Compare disks which ae formatted for a particular record size (requiring the
inter-record gap to be figured into the record/track calculation) with disks
that have fixed sector sizes, Which is simpler?

 

[Malcolm McLean]

Which is simpler, dealing with rush-hour traffic or a dire wolf trying to eat
your child?

And human interactions are not observably simpler nor more complex than any
time since the evolution of /homo sapiens/.

Actually early humans seem to have had slightly bigger brains than us.
Evolution is now making brains smaller rather than larger. Welfare
Queens are better adapted to their environment than blue-stockinged
ladies with philosophy degrees.

 

[Flash Gordon]

Quite possibly. Not every problem ending in 8 is a 2038 problem. If the
test rigs had 1900 as a base date (and yes, there's still plenty of
software around that thinks 1900 was a very good year), then the single
signed byte Richard Bos mentioned would be good for representing all
years from then until 2027 (assuming 8 bits to the byte). It would fail
in 2028, quite possibly giving the year as 1772 instead.

It was indeed 2028 when it fell over. I can't remember all of the exact
details, but it was the HP Pascal system, which was based on UCSD
(IIRC). I think the data structure was either defined as being 0..99 or
0..127, and it definitely hit a problem when it rolled over to 2028, but
I can't remember the exact details and don't have access to the systems
any more (I work for a different company).

I suspect it could have been the date encoded in to a 16 bit word as
7 bits - year
4 bits - month
5 bits - day

I did clearly document the date of failure when I was asked to look in
to Y2K, but of course that documentation will be lost before then! I
also documented that the simple work-around would be to set the date
wrong and just write on the printouts the correct date!

 

[John B. Matthews]

[...]

It was indeed 2028 when it fell over. I can't remember all of the
exact details, but it was the HP Pascal system, which was based on
UCSD (IIRC). I think the data structure was either defined as being
0..99 or 0..127, and it definitely hit a problem when it rolled over
to 2028, but I can't remember the exact details and don't have access
to the systems any more (I work for a different company).

I suspect it could have been the date encoded in to a 16 bit word as
7 bits - year
4 bits - month
5 bits - day

I did clearly document the date of failure when I was asked to look
in to Y2K, but of course that documentation will be lost before then!
I also documented that the simple work-around would be to set the
date wrong and just write on the printouts the correct date!

For reference, UCDSD Pascal I.5/II.0/III.0:

daterec = packed record
month: 0..12; { 0 IMPLIES DATE NOT MEANINGFUL }
day: 0..31; { DAY OF MONTH }
year: 0..100 { 100 IS TEMP DISK FLAG }
end { DATEREC } ;

<http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.shtml>

 

[Flash Gordon]

[...]

It was indeed 2028 when it fell over. I can't remember all of the
exact details, but it was the HP Pascal system, which was based on
UCSD (IIRC). I think the data structure was either defined as being
0..99 or 0..127, and it definitely hit a problem when it rolled over
to 2028, but I can't remember the exact details and don't have access
to the systems any more (I work for a different company).

I suspect it could have been the date encoded in to a 16 bit word as
7 bits - year
4 bits - month
5 bits - day

I did clearly document the date of failure when I was asked to look
in to Y2K, but of course that documentation will be lost before then!
I also documented that the simple work-around would be to set the
date wrong and just write on the printouts the correct date!

For reference, UCDSD Pascal I.5/II.0/III.0:

daterec = packed record
month: 0..12; { 0 IMPLIES DATE NOT MEANINGFUL }
day: 0..31; { DAY OF MONTH }
year: 0..100 { 100 IS TEMP DISK FLAG }
end { DATEREC } ;

<http://invent.ucsd.edu/technology/cases/1995-prior/SD1991-807.shtml>

Then I was probably right
Actually, that does sound familiar, apart from the comment about 100. I
know I did active testing, including setting the time to before
midnight, doing power cycles after 2000 (makes sure it did not change on
power up) etc. I think there might have been some display issues outside
the application which we did not care about.

So it just goes to show, we've still got the 2028 problem to deal with!
Perhaps I should brush up on my Pascal!

 

[Richard Bos]

Maybe not the locksmith itself, but there are insurance companies
which calculate how high the risk is, and they take that liability.

For locks, cars, even airplanes, insurance companies do that all the
time. But there are only a few cases where this is done for software.

Yeah... but on those policies, there are usually clauses like "if you
leave your windows wide open, the insurance on your door's locks is null
and void" or "You shall not run your car into a tree while under the
influence of alcohol, or you won't get a bent dime".
You try adding things like that to a computer policy and see how far you
get. "You shall keep your virus scanner up to date and not click on
dubious attachments, or we can't guarantee that the mess you make won't
interfere with our program's operation"? You'll never get away with it.
Better not guarantee anything - you _know_ there are people who will
always mess things up, and they'll be the first to complain.

Richard

 

[Richard Bos]

Yeah. Our jobs would be so much easier if we only didn't have customers!

Don't dis the customers, man. Having a derogatory attitude toward "users"
(there are only two industries that call their customers "users") is a major
arrogance. Shame on you.

Yah. I suppose you say the same thing to a doctor who complains that his
patients keep smoking?
No, I'm sure _your_ users are all peachy-clean, and _never_ set Outhouse
to automatically execute all attachments, ever. In the real world...

Richard

 

[Richard Bos]

That might seem "saner", but again, the market is massively improved by
free stuff at the baseline.

Look at it this way: Would science improve if you were guaranteed that
for-pay versions of the Periodic Table were "better" than free ones? No.
It turns out that it's much better for everyone to have basic information
be completely free.

That's not a valid comparison: the correctness of a Periodic Table can
be measured objectively. The "correctness" of Ganuck-C-plus-extensions
versus Microsoft-C-plus-extensions, OTOH, is a matter of holy wars.

Richard

 

[Richard Bos]

That's pure fantasy.

I used a couple of Linux distributions in the early nineties, and they worked
better than commercial UNIX variants.

You're mad. I used Solaris to run an Informix database system not ten
years ago, and I would not have run it on Linux for the world. The
business depended on that thing: no database, no newspaper. Linux was
simply Not An Option. That system's successor is run by someone else,
but apparently he (or rather, they) agree with me: it's Oracle, not
Informix, but still running on Sun systems.
The FTP server, meanwhile, ran on Linux. That was fine, for that
purpose. But don't come to me saying that it's better than the
commercial alternatives.

I used emacs and knew many who used vi back then. They were solid.

Yeah, but have you ever used an _editor_? No, a real one?

Richard

 

[Richard Bos]

I think it may be done occasionally. Certainly, if I had contractual
penalties for downtime, and my choices were Windows or Linux, I'd
run free software.

If I had _that_ choice, I'd not have signed the contract.

Richard

 

[Lew]

You're mad. I used Solaris to run an Informix database system not ten
years ago, and I would not have run it on Linux for the world. The
business depended on that thing: no database, no newspaper. Linux was
simply Not An Option. That system's successor is run by someone else,
but apparently he (or rather, they) agree with me: it's Oracle, not
Informix, but still running on Sun systems.
The FTP server, meanwhile, ran on Linux. That was fine, for that
purpose. But don't come to me saying that it's better than the
commercial alternatives.


Yeah, but have you ever used an _editor_? No, a real one?

Richard

 

[Lew]

Yeah, but have you ever used an _editor_? No, a real one?

Sure. emacs and vi. They're real, or are you suggesting I was hallucinating?
For that matter, MS Notepad is a real editor. I certainly would never
imagine such a one if I could help it. My chisel works real well on pebbles
for cuneiform editing, too.

<http://en.wikipedia.org/wiki/Editor_war>

Nice try.