> > ...the breaker point ignition always meant that the engine > > spent a considerable amount of its life with late timing due to breaker > > points wearing down...
> Hmmm - Being that the spark occurs when the points *open*, worn breaker > points would make the timing advanced (reduced dwell, but advanced > timing). Unless you're going to say that the wear block wears down > faster than the points burn back - which I don't think is generally the > case.
I see what your saying, but it doesn't work that way.
Try checking the timing on an engine with well used set of points. Or just observe the gap of a worn set of points - is the gap wider or narrower? And yes I suppose wear to the rubbing block accounts for most of it - transfer of metal plays a role too. -jim
"hls" <h...@nospam.nix> writes: > "Steve" <n...@spam.thanks> wrote in message
>> It amazes me that anyone today doesn't realize what a massive effort >> went into fixing all the possible Y2K problems before they >> happened. I guess thats gratitude for you.... :-(
> I think you are right in a sense. There is no gratitude. Did we not > see the > millenium coming for the entire history of modern computing???
For a programmer in the 1960s, trying to save space (which cost lots of both money and time) in a program *today* was important. The idea that the same code might really still be in use in 2000 -- when the programmer would be long retired -- was remote enough not to worry about. I haven't seen any real figures on percentage of new code needing fixes, but I expect somewhere around 1980 it probably started to decline, and aroung 1990 to decline sharply. Any programmer who wrote anything after about 1995 that needed to be fixed should be taken out back and shot. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
> I AM a software engineer who worked on that stuff since 1968 and worked on > several of these alleged Y2K problems. Every one was total crap. > Absolutely nothing would have happened.
You had an astonishingly unusual experience, at variance both with all the statistics and every other software engineer I've talked to who was involved. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
On 2009-11-07, Bill Putney <b...@kinez.net> wrote:
> IOW - the Mayans had only gotten that far in extending their calendar > when their own civilization collapsed and they stopped adding to the > calendar - but when "modern" man looks at that in retrospect, his > interpretation of that observation is that the Mayans stopped updating > the calendars at the point because they "knew" things were going to end > at that point - i.e., there was no more work needed on the calendar, > their work was finished.
Actually it's not where they just randomly stopped. It's the end of a cycle. The calendar is driven by astronomy with short and long cycles. It is a greater knowledge than conventional thought believed possible. These larger cycles were not unique to Maya but appear in many cultures. Anyway, the end of world as many people put it isn't so much the end of the world, but at worst the end of the world as we know it. The old cycle will end and the new cycle will begin. This may be about as eventful as new years' eve.
What people fear is that solar system is entering into a 'bad neigborhood' as it moves through the galaxy and that with it perhaps some event which we will have no power over will occur. We shall see :)
Some others think it will just be some sort of spirital change in society, again sparked by whatever 'neighborhood' the solor system is moving through.
The funny thing is, the sun is behaving rather odd already. Whatever is coming it's based on the movement of this planet through the universe and there ain't anything to do but ride it out :)
> Practically any critical system could have been put back in operation by > having the date set to something like 1-1-1970. The data to be fixed > could easily be identified by the date and fixed later once patches were > done.
Like banking systems, where the rules to apply depend on the date? Set back to 1970, and refigure retirement year maybe?
Both from picking 1970, and from mentioning the Y38K problem, it sounds like you're a Unix guy (as am I, by the way, which is why I'm quoting statistics rather than regaling you with war stories) -- very few of the serious problems were in the sort of scientific and server enviroments where Unix is commonly used. It was in legacy databases. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
On 2009-11-07, Bill Putney <b...@kinez.net> wrote:
> Brent wrote:
>> ...Practically any critical system could have been put back in operation by >> having the date set to something like 1-1-1970. The data to be fixed >> could easily be identified by the date and fixed later once patches were >> done...
> I have no opinion or knowledge on if it was real or not, but it would > seem obvious to me that if it was real, your statement would be wrong > about, say, the banking industry. Can you imagine the world calamity if > interest calculations were all screwed up - even for a day? Stock > market...?
Well I was speaking of life and death systems such as air traffic control and the like. Systems that really don't need to know what year it is. Banks would have had an entire holiday to come up with some sort of patch for business on the 2nd. I really didn't think the world as we knew it would have ended. Although, I wish I had stocked up gold and silver then... look at the price today! :)
>> Practically any critical system could have been put back in operation by >> having the date set to something like 1-1-1970. The data to be fixed >> could easily be identified by the date and fixed later once patches were >> done.
> Like banking systems, where the rules to apply depend on the date? Set > back to 1970, and refigure retirement year maybe?
I guess I just don't consider that a critical system that couldn't be fixed later. I'm talking about planes crashing into each other, traffic lights going green for all directions at the same time, etc... things that could get people killed, not a day or two without working ATMs.
>> Now the real event comes in 2038 ;) time() returns 2147483647 >> ( http://en.wikipedia.org/wiki/Year_2038_problem ) > Both from picking 1970, and from mentioning the Y38K problem, it sounds > like you're a Unix guy (as am I, by the way, which is why I'm quoting > statistics rather than regaling you with war stories) -- very few of the > serious problems were in the sort of scientific and server enviroments > where Unix is commonly used. It was in legacy databases.
I know. unix had little problem with Y2K. Although I needed to patch up my NeXT boxes. I think the patch was mostly to be able to set the correct date and stuff like that. I don't think anything major would have stopped working.
Brent <tetraethylleadREMOVET...@yahoo.com> writes: > On 2009-11-07, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote: >> Brent <tetraethylleadREMOVET...@yahoo.com> writes:
>>> Practically any critical system could have been put back in operation by >>> having the date set to something like 1-1-1970. The data to be fixed >>> could easily be identified by the date and fixed later once patches were >>> done.
>> Like banking systems, where the rules to apply depend on the date? Set >> back to 1970, and refigure retirement year maybe?
> I guess I just don't consider that a critical system that couldn't be > fixed later. I'm talking about planes crashing into each other, traffic > lights going green for all directions at the same time, etc... things > that could get people killed, not a day or two without working ATMs.
Different industry, different priorities. Almost none of the Y2K problem was in control systems, embedded systems, or the like (a mailling list I'm on was considering creating "Certified Y2K compliant" stickers to put on our pre-electronic engine management cars. We were also considering "Warning: this automobile has not been tested for Y2K compliance" stickers to put on cars on used-car lots, but I digress). It was almost all in the financial, insurance, and government-regulatory etc areas.
But even given that, I'm not quite sure why you think waiting until your bank was suddenly in regulatory non-compliance on 1/1/2000 and starting to fix it then would have been better than spending a couple of years getting it fixed so the customers (and more importantly, the regulators) didn't notice -- the fixes had to happen in any event, the only issue was when and how panicked.
As for your ATM example: if you'd been the manager in charge of the software for those machines for your bank and they'd quit working on 1/1/2000, you'd have been looking for work by some time early that morning. And firing you would have been the vice-president you report to's last official act (with probably several layers of severed heads in between) as well. The only things more important than keeping uptime for customers are backup and regulatory compliance (and in banking, regulatory compliance includes backups).
>> Both from picking 1970, and from mentioning the Y38K problem, it sounds >> like you're a Unix guy (as am I, by the way, which is why I'm quoting >> statistics rather than regaling you with war stories) -- very few of the >> serious problems were in the sort of scientific and server enviroments >> where Unix is commonly used. It was in legacy databases.
> I know. unix had little problem with Y2K. Although I needed to patch up > my NeXT boxes. I think the patch was mostly to be able to set the > correct date and stuff like that. I don't think anything major would > have stopped working.
Nor on my machines. But (1) my machines don't have anything major on them by the standards I'm describing, and (2) everything had been fixed in advance -- which is the point. -- As we enjoy great advantages from the inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. (Benjamin Franklin)
>>> ...the breaker point ignition always meant that the engine >>> spent a considerable amount of its life with late timing due to breaker >>> points wearing down... >> Hmmm - Being that the spark occurs when the points *open*, worn breaker >> points would make the timing advanced (reduced dwell, but advanced >> timing). Unless you're going to say that the wear block wears down >> faster than the points burn back - which I don't think is generally the >> case.
> I see what your saying, but it doesn't work that way.
> Try checking the timing on an engine with well used set of points.
Hah! If you can show me where to find one. Except, I do own a 1942 Gravely that has points in the magneto - never used a timing light on it - always followed the book on statically timing it.
> Or > just observe the gap of a worn set of points - is the gap wider or > narrower? And yes I suppose wear to the rubbing block accounts for most > of it - transfer of metal plays a role too. > -jim
Of course, as you no doubt know, when you get metal transfer, you get peaks and valleys on the points and then feeler gages (or a 3x5 card) don't tell you anything with any accuracy.
>> That's my buttal. Do you have a rebuttal?
>> -- >> Bill Putney >> (To reply by e-mail, replace the last letter of the alphabet in my >> address with the letter 'x')
-- Bill Putney (To reply by e-mail, replace the last letter of the alphabet in my address with the letter 'x')
>For a programmer in the 1960s, trying to save space (which cost lots of >both money and time) in a program *today* was important. The idea that >the same code might really still be in use in 2000 -- when the >programmer would be long retired -- was remote enough not to worry >about. I haven't seen any real figures on percentage of new code >needing fixes, but I expect somewhere around 1980 it probably started to >decline, and aroung 1990 to decline sharply. Any programmer who wrote >anything after about 1995 that needed to be fixed should be taken out >back and shot.
The problem was the many data files that still contained a 2 digit year. All those files had to be converted. And any program reading them had to changed and compiled or assembled to accommodate the new file format. Even if the program did nothing with the date. Yes, there were - and probably still are - assembler programs running in major apps. I was called recently about taking an assembler job. If you think about how much of business data contains a start date - birthday, policy, account, etc, etc, etc, and the old data files with 2 digit years, it's pretty easy to see the scope of the problem. Those data files had to plugged with 19 before the calendar flipped to 20, and of course everything had to be tested up the yazoo first. Most stuff was addressed well before crunch time, but there was plenty to do in the last 2 years when push came to shove. DB2 - the major mainframe database - was designed with 8 digit dates, so presented no problem. It was all the old tape and disk files and the programs that touched them that posed the problem.
> >>> ...the breaker point ignition always meant that the engine > >>> spent a considerable amount of its life with late timing due to breaker > >>> points wearing down... > >> Hmmm - Being that the spark occurs when the points *open*, worn breaker > >> points would make the timing advanced (reduced dwell, but advanced > >> timing). Unless you're going to say that the wear block wears down > >> faster than the points burn back - which I don't think is generally the > >> case.
> > I see what your saying, but it doesn't work that way.
> > Try checking the timing on an engine with well used set of points.
> Hah! If you can show me where to find one. Except, I do own a 1942 > Gravely that has points in the magneto - never used a timing light on it > - always followed the book on statically timing it.
Yeah I haven't put a timing light on a small engine much either and I'm not sure if points and magneto behave the same as points and coil as far as wear patterns.
> > Or > > just observe the gap of a worn set of points - is the gap wider or > > narrower? And yes I suppose wear to the rubbing block accounts for most > > of it - transfer of metal plays a role too. > > -jim
> Of course, as you no doubt know, when you get metal transfer, you get > peaks and valleys on the points and then feeler gages (or a 3x5 card) > don't tell you anything with any accuracy.
Well i did say observe not use a feeler gauge. Also i expect to some extent the metal transfer also produces some porosity which takes up more space than the original metal and may account for some of the closing of the gap.
In article <sqc7f5hseslvplve2d031cd4uvv5o8i...@4ax.com>, Ashton Crusher <d...@moore.net> wrote:
>What was found was that if you ran leaded fuel for a few thousand >miles it built up a coating that could provide protection for a long >time after that even if you burned unleaded. But if you took a new 66 >engine that had never been run and started it off on unleaded it would >burn the valves relatively quickly.
That was my impression, though I admit I haven't researched the issue thoroughly. -- The problem with socialism is there's always someone with less ability and more need.
>Having worked with software engineers who previously spent a fair chunk >of their career fixing Y2K problems before Y2K, I not only believe it I >KNOW it.
>Anyone that thinks Y2K wouldn't have been a problem if corrective >measures hadn't been put in place is, frankly, clueless. It wasn't a >problem because a huge effort was committed to fixing it in time.
Yep. The fact that those in the business knew it was coming long before the public caught on didn't hurt either. Now the "general wisdom" is that Y2K was a "boy who cried wolf" scenario, when actually the wolf DID arrive, only to find wolf-proof brick walls and cranky called-out-of-retirement COBOL programmers with shotguns :-) (they're mostly safely back in retirement now, in a better position for the Y2K money...) -- The problem with socialism is there's always someone with less ability and more need.
In article <7ljsa9F39lln...@mid.individual.net>, Bill Putney <b...@kinez.net> wrote:
>incandescents), someone will release the latest shocking "scientific" >studies to start a HUGE environmental panic over the mercury being >"released into the environment" from those bulbs (manufacturing, >breakage, discarding into landfills, yadda, yadda, yadda), and some >marvelous saviour will be waiting in the wings to "fix" the problem with >a solution that he just happens to have ready, and charge us huge bucks >in the process.
And said fix will be a bulb which relies on the incandescence of an electrically heated metal filament immersed in an inert gas sealed in a glass envelope. Sure, it uses a little more energy, but it's SAFER, and more ENVIRONMENTALLY FRIENDLY don't you know :-)
Unfortunately GE gave up their research into high-efficiency incandescents. I think Phillips is still working on theirs, though, both the quartz-capsule HIRs inside a standard bulb envelope and exotic filament treaatments. -- The problem with socialism is there's always someone with less ability and more need.
In article <1b639njeft....@snowball.wb.pfeifferfamily.net>, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
>Both from picking 1970, and from mentioning the Y38K problem, it sounds >like you're a Unix guy (as am I, by the way, which is why I'm quoting >statistics rather than regaling you with war stories) -- very few of the >serious problems were in the sort of scientific and server enviroments >where Unix is commonly used. It was in legacy databases.
Unix systems got bit, just not as much. I ran into one... a version control system which would corrupt the database if it was ever run after Y2K. Repairing that (proprietary and undocumented) database to the point where we could get the code out of it was not fun. I wish I remembered the name of the VCS so I could denigrate it properly, but the company is long since out of business anyway. -- The problem with socialism is there's always someone with less ability and more need.
> I thought the Mayan prediction was sometime in 2012 - could be wrong.
> -- > Bill Putney
I think your date of 2012 is correct for the Maya predictions. There was another prediction recently which claimed a disaster event for 11-11-09. On that date I will watch "Law and Order", most likely, and go to bed.
>Both from picking 1970, and from mentioning the Y38K problem, it sounds >like you're a Unix guy (as am I, by the way, which is why I'm quoting >statistics rather than regaling you with war stories) -- very few of the >serious problems were in the sort of scientific and server enviroments >where Unix is commonly used. It was in legacy databases.
I did some cleanup work for some people who had a realtime factory automation system written in COBOL running on a VMS machine. Don't ask how it got that way.
Updating VMS to V5.5 fixed all of the OS-related Y2K issues, none of which really mattered anyway since none of the code used the system date. The code, however, accepted a human-entered Julian date in the form of two digits for the year, then three digits for the number of days since Jan 1. It treated the Julian date number as an integer and the only acceptance testing it did on the date was that it couldn't be lower than 85000. Which of course was a problem when the date turned to 00001.
Nobody had any of the source code for this mess, so I patched the binary so it compared it with 0 instead of 85000. Problem solved. Actual coding time about 10 minutes, time to figure out what the code actually did (a combination of the operators really having no clue how the system worked and a lack of documentation) about two weeks.
If I'd had the source code, it wouldn't have been a big deal to fix it so it calculated the actual Julian date from the system date, but I really didn't want to work with this stuff any more than necessary. --scott
-- "C'est un Nagra. C'est suisse, et tres, tres precis."
Matthew Russotto wrote: > ...I think Phillips is still working on theirs, though, > both the quartz-capsule HIRs inside a standard bulb envelope and > exotic filament treaatments.
I have HIR's in one of my Concordes. Apparently they haven't caught on yet. I think they even quit making the hi beam (9006) bulb in it. But I do have a spare on the shelf (actually was planning on putting that in my second Concorde, but haven't gotten aroundtuit since the headlight assembly has to be modified slightly to accept angle-based bulbs).
-- Bill Putney (To reply by e-mail, replace the last letter of the alphabet in my address with the letter 'x')
Matthew Russotto wrote: > In article <hd29eh$7c...@news.eternal-september.org>, > Brent <tetraethylleadREMOVET...@yahoo.com> wrote: >> Now the real event comes in 2038 ;) time() returns 2147483647 >> ( http://en.wikipedia.org/wiki/Year_2038_problem )
> Not going to be a big problem. The time_t type is 64-bits on any > modern Unix system. Even Windows uses 64 bits.
> I make no promises for Y10k.
Hah! Yeah - that one's really got me worried. Something tells me there will be bigger things to be worried about by then - or maybe all problems will be over by then.
-- Bill Putney (To reply by e-mail, replace the last letter of the alphabet in my address with the letter 'x')
> In article <sqc7f5hseslvplve2d031cd4uvv5o8i...@4ax.com>, > Ashton Crusher <d...@moore.net> wrote:
> >What was found was that if you ran leaded fuel for a few thousand > >miles it built up a coating that could provide protection for a long > >time after that even if you burned unleaded. But if you took a new 66 > >engine that had never been run and started it off on unleaded it would > >burn the valves relatively quickly.
> That was my impression, though I admit I haven't researched the issue > thoroughly.
Well that whole theory that a tankful of leaded fuel protected the valves forever was crafted in hindsight, after it became clear that old engines were not burning valves with unleaded gasoline as had been predicted. If you do research you might look at the studies done by those who build engines designed to run on LPG. What those studies demonstrated is that soot makes some difference in wear on valves. Hardened valves were used in LPG engines long before they were used in gasoline engines because LPG engines eat valves more than gasoline engines. The reason LP gas engines erode valves faster is because they burn so cleanly. The valves erode because of the clean metal on metal contact. Tests have shown that you can counter the valve wear problem in LPG engines by just burning a tiny amount of oil along with the LPG. The soot produced protects the valves. It should be obvious that 1960's gasoline engines did not have this problem of burning fuel too cleanly.
If you do your research you will note that the tests that showed the benefit of lead were all done under very extreme conditions where engines were run at extremely high rpm high load conditions. It has never been demonstrated that lead makes a noticeable difference in valve wear under normal driving conditions.
Where TEL did make a clear difference was in oil refinery economics. It allowed the oil companies to produce and sell the mix of products that maximized profits. In simple terms, it was a way to increase demand plus lower production cost.
Another big difference that has resulted from removing lead from gasoline is engines last longer without lead, oil change intervals can be made longer and spark plugs last considerably longer. Those changes have been documented in side by side comparisons of the same engines on the 2 types of fuel. Those differences are directly related to removing lead from the fuel and not changes in engine design or changes in materials used.
>> I thought the Mayan prediction was sometime in 2012 - could be wrong.
>> -- >> Bill Putney
> I think your date of 2012 is correct for the Maya predictions. There was > another > prediction recently which claimed a disaster event for 11-11-09. On that > date I > will watch "Law and Order", most likely, and go to bed.
> I think your date of 2012 is correct for the Maya predictions. There was > another > prediction recently which claimed a disaster event for 11-11-09. On that > date I > will watch "Law and Order", most likely, and go to bed.
The major disaster that will happen on 11-11-09 is that almost everyone will forget the anniversary of the armistice. People need to remember what happens when countries get embroiled in badly-thought-out wars. That's what the day is all about... --scott -- "C'est un Nagra. C'est suisse, et tres, tres precis."
>> I AM a software engineer who worked on that stuff since 1968 and worked on >> several of these alleged Y2K problems. Every one was total crap. >> Absolutely nothing would have happened.
> Well - hey then - it's a darn good thing we had others besides you > working on it!! (just kidding - I have no idea if the potential > problems were real or not)
My personal feeling, based on observation, is that the world was and is at much greater risk due to unspec'd, untested & unverified software being hacked out in third world countries than anything we could ever conceive related to two digit date years. All that Y2K hype sure did keep a bunch of SW people employed for a year or so though.
E. Meyer <epmeye...@gmail.com> wrote: >My personal feeling, based on observation, is that the world was and is at >much greater risk due to unspec'd, untested & unverified software being >hacked out in third world countries than anything we could ever conceive >related to two digit date years. All that Y2K hype sure did keep a bunch of >SW people employed for a year or so though.
What the Y2K hype did was cause a lot of people to go back and go through some of their old code and do documentation and maintenance work that was years if not decades overdue.
People who get badly-designed and badly-tested code from the lowest bidder are indeed a problem. But people who think they don't need to do spend money to properly document what they have, and don't think they need to spend money to keep what they have up to date, they're just as much of one. --scott
-- "C'est un Nagra. C'est suisse, et tres, tres precis."
|
