Prev: When writing html table to div, the data from table is unformatted
Next: multi file download with one click
From: Flash Gordon on 23 Feb 2010 19:22 John B. Matthews wrote: > In article <qij857xp3j.ln2(a)news.flash-gordon.me.uk>, > Flash Gordon <smap(a)spam.causeway.com> wrote: > > [...] >> 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! -- Flash Gordon
From: Richard Bos on 1 Mar 2010 16:14 MarkusSchaber <msr(a)soloplan.de> wrote: > On 10 Feb., 22:53, Andy Champ <no....(a)nospam.invalid> wrote: > > Can any locksmith or > > burglar alarm maker guarantee that a building will withstand all attacks > > for 12 months? =A0_That_ is the equivalent of withstanding all virus > > attacks for 12 months - and it's on a far simpler system. > > 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
From: Richard Bos on 1 Mar 2010 16:14 Lew <noone(a)lewscanon.com> wrote: > Richard Bos wrote: > > I've seen that - _my_ manager, in _my_ fix in _my_ program - in 1995. > > Three years later he thought that it would be a good idea for me to > > start paying attention to this Y2K thing he'd just heard about. > > > > And then there's the users. Don't get me started on the users. > > 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
From: Richard Bos on 1 Mar 2010 16:14 Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-02-13, Arved Sandstrom <dcest61(a)hotmail.com> wrote: > > In effect the commercial software is also crappy because we do not hold > > it to a higher standard. I believe that a well-thought-out system of > > software certifications and hence guarantees/warranties will lead to a > > saner market where the quality of a product is generally reflected in > > its cost. > > 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
From: Richard Bos on 1 Mar 2010 16:14
Lew <noone(a)lewscanon.com> wrote: > James Kanze wrote: > >> Neither Linux nor g++ were even usable, and emacs (by > > 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 |