The Year 2038 Problem
Generic Usenet Account
[http://groups.google.com/googlegroups/archive_announce_20.html], the
first discussion of the Y2K problem on the Usenet was on January 18
1985 [http://groups.google.com/groups?threadm=820%40reed.UUCP]. That
is a good 15 years before the problem manifested. Even then, it
turned out, we were scrambling for cover when the D-day was
approaching.
Although the Y2K scare turned out to be vastly overblown, we do have a
massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
After that, the time on the Unix systems will read as Fri Dec 13
14:45:52 1901.
IMHO, if we want to avoid the last minute panic that we witnessed
towards the end of the last millennium (while pursuing the Y2K
problem), we should begin the process of debating the viable solutions
to this problem NOW. It will take a long time for the consensus to be
built, and to come up with a solution that most (if not all) people
find acceptable. We also need considerable time to test out all
possible solutions in the real world, to decide if the solutions
really work as expected. We may also need to develop a suite of
recovery strategies should the problem manifest in some system on that
fateful Monday morning. All this takes time. So, as the late Todd
Beamer would have said: Let's roll.
Bhat
Bob Day
"Generic Usenet Account" <use...@sta.samsung.com> wrote in message
news:90e5135.04052...@posting.google.com...
< snip >
> Although the Y2K scare turned out to be vastly overblown,
Idiot!! It wasn't "vastly overblown" at all. The fact is,
we did a damn good job fixing it.
-- Bob Day
"Dario (drinking coffee in the office…)"
In 2038 all OS (Unix included) will have 64 bits
to hold a Date value and with 64 bits the rollover
will happen 292 billion years after 1/1/1970.
- Dario
Dan Pop
>Although the Y2K scare turned out to be vastly overblown, we do have a
>massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
>18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
> After that, the time on the Unix systems will read as Fri Dec 13
>14:45:52 1901.
Nope, this won't happen. By then, time_t will be a 64-bit type, as it
already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
lx64:~/tmp 13> cat test.c
#include <time.h>
#include <stdio.h>
#include <limits.h>
int main()
{
printf("%d\n", (int)sizeof(time_t) * CHAR_BIT);
return 0;
}
lx64:~/tmp 14> gcc test.c
lx64:~/tmp 15> ./a.out
64
So, what's the next massive problem we have to worry about, now that we
have just solved this one?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Marco van de Voort
>>Although the Y2K scare turned out to be vastly overblown, we do have a
>>massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
>>18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
>> After that, the time on the Unix systems will read as Fri Dec 13
>>14:45:52 1901.
>
> Nope, this won't happen. By then, time_t will be a 64-bit type, as it
> already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
FreeBSD/AMD64 too, I just happen to see last week.
Guillaume
> to hold a Date value and with 64 bits the rollover
> will happen 292 billion years after 1/1/1970.
Which is why we probably won't ever need any more than
64 bits to hold dates.
Our galaxy will probably have collapsed by then, and
maybe along with the whole universe.
corrlens
"Guillaume" <grsN...@NO-SPAMmail.com> wrote in message
news:40b630cd$0$315$7a62...@news.club-internet.fr...
Hoping we haven't contacted any kind of higher intelligence Humans from
other planet and they want us to modify our date to theirs.
Otto Wyss
> Nope, this won't happen. By then, time_t will be a 64-bit type, as it
> already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
>
The time_t might have 64-bit but are you sure that every occurence where
the time is copied or used is as well?
O. Wyss
--
See a huge pile of work at " http://wyodesktop.sourceforge.net/"
q...@q.com
There is time to resolve this issue
in a calm, cool and collected manner.
Certainly 64 bit processors and/or long long
data type will go a long way to resolving the issue.
But there will NOT be any need to import
thousands of H1b visas to fix this problem.
Y2K was definitely blown way out of proportion!
This was done by high priced consulting companies
trying to justify their worth.
Peter Ammon
> Dan Pop <Dan...@cern.ch> wrote:
>
>
>>Nope, this won't happen. By then, time_t will be a 64-bit type, as it
>>already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
>>
>
> The time_t might have 64-bit but are you sure that every occurence where
> the time is copied or used is as well?
>
> O. Wyss
34 years ago was 1970; how many programs from that era are running on
modern hardware without having been recompiled?
Stephen Sprunk
news:90e5135.04052...@posting.google.com...
> massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
> 18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
> After that, the time on the Unix systems will read as Fri Dec 13
> 14:45:52 1901.
You mean systems which use a signed 32-bit int for time_t. Modern systems
use a 64-bit int for time_t, so the problem is moot (unless you're running
code in 2038 that hasn't been recompiled since the early 1990s).
> IMHO, if we want to avoid the last minute panic that we witnessed
> towards the end of the last millennium (while pursuing the Y2K
> problem), we should begin the process of debating the viable solutions
> to this problem NOW. It will take a long time for the consensus to be
> built, and to come up with a solution that most (if not all) people
> find acceptable.
There already is a solution, consensus for it, and implementations of it.
The sky is NOT falling.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Stephen Sprunk
news:1gegpbt.ot7t0q1p5gqogN%otto...@orpatec.ch...
> Dan Pop <Dan...@cern.ch> wrote:
>
> > Nope, this won't happen. By then, time_t will be a 64-bit type, as it
> > already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
> >
> The time_t might have 64-bit but are you sure that every occurence where
> the time is copied or used is as well?
If someone copies a time_t into a variable of any other type, they may be
invoking undefined behavior, which means it's not the Standard's problem,
it's the coder's.
time_t exists for a reason, just like size_t. Use them.
Thomas Matthews
[sarcasm on]
I believe that we should all go out and hunt down these old
Unix boxes and fix them. After all, this is way more important
than getting Windows to stop that Blue Screen of Death during
shutdown, holes in the security systems of servers and reduction
of spam.
After all, there are at least 33 more years to develop a
good panic. It will probably take that long to find these machines
that are in charge of all the critical activities in the world.
See, smart people don't use machines that say programs have executed
illegal instructions (when it is the operating systems's fault).
Nope, stopping those Cell Phone spammers isn't as important because
these cell phones are not controlling critical systems (and I know
because I've either worked on them or seen them all).
So how will I panic, hmm, I don't know, but I've got a while to
figure it out. I think I will use my computer that requires
rebooting once a day, using appllications that can't communicate
with the operating system, even though they are made by the same
company. Yep, I search those web sites that will download spyware
onto my machine so they can see how I am panicking.
Yep, I've just added another item to my worry list. Someday,
I'll actually review it. :-)
[End of sarcasm]
--
Thomas Matthews
C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
Gordon Burditt
>massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
>18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
> After that, the time on the Unix systems will read as Fri Dec 13
>14:45:52 1901.
That depends on whether the system considers a time_t to be signed or
unsigned. Some UNIX systems consider the time range of a traditional
32-bit time_t to be 1970 thru something like 2106, not 1901 thru 2038.
There is also no prohibition of using a larger integer for a time_t.
This isn't an ANSI C problem. It may be a POSIX problem, although
I'm not sure whether POSIX says anything about time_t's having to
have exactly 32 bits. (Some systems already use 64 bits, I believe,
and those processors will become more popular as it gets closer to
2038, if they're not obsoleted by the 4096-bit processors.)
Now, this creates problems if you're storing time_t's on disk as, for
example, file timestamps, but it doesn't rule out converting the filesystem
including 0-extending or sign-extending the time_t to more bits.
My personal preference would be for a 256-bit number of picoseconds since
the creation of the universe. It gives better precision than 1 second.
It won't run out during the life of this universe. The only trouble is,
we don't know accurately when that was.
Gordon L. Burditt
T.M. Sommers
>
> So, what's the next massive problem we have to worry about, now that we
> have just solved this one?
The Y10K problem, when all those 4-digit years everyone is so
proud of become obsolete. If it took several years to fix just
40 years worth of software for the Y2K problem, just think how
long it will take to fix 8000 years worth of software for the
Y10K problem. We had better get started right away. There is no
time to lose.
Guillaume
> other planet and they want us to modify our date to theirs.
Hehe, that might happen indeed.
Who knows, maybe they'll want to store dates with a femtosecond
resolution. We wouldn't get very far with 64 bits, then...
rossum
Burditt) wrote:
>>[snip]
>
>My personal preference would be for a 256-bit number of picoseconds since
>the creation of the universe. It gives better precision than 1 second.
>It won't run out during the life of this universe. The only trouble is,
>we don't know accurately when that was.
>
>
> Gordon L. Burditt
< mode = nitpick >
Not quite accurate. We know precisely when the universe started; at
time = 0. The problem is that we don't know what the time is now.
< mode = whatever_passes_for_normal >
rossum
--
The Ultimate Truth is that there is no Ultimate Truth
Roger Willcocks
news:c95mfi$6...@library2.airnews.net...
> My personal preference would be for a 256-bit number of picoseconds since
> the creation of the universe. It gives better precision than 1 second.
> It won't run out during the life of this universe. The only trouble is,
> we don't know accurately when that was.
Given we want to represent times in the past as well as the future, it would
be reasonable to fix 'now' (give or take) as midpoint in the range, so why
not arbitrarily pick
00:00:00.000 on the morning of January First 0001 as
1-followed-by-255-zeroes (256-bit unsigned value).
--
Roger
Stephen Sprunk
> the creation of the universe. It gives better precision than 1 second.
> It won't run out during the life of this universe. The only trouble is,
> we don't know accurately when that was.
You assume a "when" exists; relativity says that's impossible.
Relativity aside, there's nothing preventing time_t from being a
floating-point number whose zero is at a particular epoch. Epsilon of the
chosen type determines the precision of your clock.
SM Ryan
# to hold a Date value and with 64 bits the rollover
# will happen 292 billion years after 1/1/1970.
By 2000, OSes could afford four digit years. The problem wasn't new
software that included enough space. The problem was old files, old
databases, and old software (some without source code). If you can
guarentee that changing time_t to 64 bits will automatically convert
32 bit values in existing files, databases, and object code, then
you're right, no problem.
If the conversion is not automatic, then it's Y2K all over again.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
What kind of convenience store do you run here?
corrlens
"Guillaume" <grsN...@NO-SPAMmail.com> wrote in message
LOL ... And then if we ever colonized the moon and mars and then we have
real-time databases with planet earth , what's time and date is at the
moon/mars compared to the earth :-) ..... I'll be dust by that time
Mario Charest
>
> My personal preference would be for a 256-bit number of picoseconds since
> the creation of the universe. It gives better precision than 1 second.
> It won't run out during the life of this universe. The only trouble is,
> we don't know accurately when that was.
Wouldn't work, time isn't a constant. Doesn't show when your talking about
seconds, but with picoseconds that will need to be taken into account.
Number of picosecondes since creation of the universe isn't the same on top
of mount Everest then at sea level. I wonder how NTP is going to deal with
that LOL.
>
>
> Gordon L. Burditt
Jeff Schwab
I hereby nominate Bell Labs as the relative center of time, hence forth
referred to as the Origin. The time at which any event occurs is not
the local time, but the perceived time at the Origin "when" the event
occurred, even if the event was not "then" directly observable from the
Origin.
q...@q.com
Thomas Matthews wrote:
No, No, No. These old Unix boxes should be replaced with the latest,
state-of-the-art hardware.
In 2038 these boxes will be as slow as 4.77Mhz x86 processors
from 1980's.
q...@q.com
No H1b visas were required!!!
AngleWyrm
news:c957pb$5mq$2...@sunnews.cern.ch...
> In <90e5135.04052...@posting.google.com> use...@sta.samsung.com
(Generic Usenet Account) writes:
>
>
> Nope, this won't happen. By then, time_t will be a 64-bit type, as it
> already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
> So, what's the next massive problem we have to worry about, now that we
> have just solved this one?
The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
current rate of 80 million/day, it will be completely gone within the lifespans
of some of the folks walking the earth today.
My solution is that I plan to be dead around 2040 or so.
AngleWyrm
> No need to go into 'panic mode'.
> There is time to resolve this issue
> in a calm, cool and collected manner.
> Certainly 64 bit processors and/or long long
> data type will go a long way to resolving the issue.
> But there will NOT be any need to import
> thousands of H1b visas to fix this problem.
> Y2K was definitely blown way out of proportion!
> This was done by high priced consulting companies
> trying to justify their worth.
Yes, no need to panic. What we need here a small team of specialists, gathered
together in a committee. Over the course of their lives, with the benefit of
government funding, I'm sure this top-notch group of problem solvers will come
forth with a resolution to our problem.
q...@q.com
http://tycho.usno.navy.mil/history.html
http://tycho.usno.navy.mil/master.html
http://tycho.usno.navy.mil/clocks.html
CBFalconer
>
>> Although the Y2K scare turned out to be vastly overblown, we do
>> have a massive problem ahead of us ------ the Year 2038 problem.
>> On Mon Jan 18 21:14:07 2038, the Unix seconds-since-epoch count
>> will "roll-over". After that, the time on the Unix systems will
>> read as Fri Dec 13 14:45:52 1901.
>
> That depends on whether the system considers a time_t to be
> signed or unsigned. Some UNIX systems consider the time range
> of a traditional 32-bit time_t to be 1970 thru something like
> 2106, not 1901 thru 2038.
The obvious cure is to switch to the CP/M standard date format,
which is a 16 bit unsigned value expressing the count of days
since 1977-12-31. 0 is 'unknown'. This postpones the problem
until about 2157 or so.
Quite a good troll, he didn't need to prod it further.
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Jeff Schwab
> Jeff Schwab wrote:
>
>> Mario Charest wrote:
>>
>>>> My personal preference would be for a 256-bit number of picoseconds
>>>> since
>>>> the creation of the universe. It gives better precision than 1 second.
>>>> It won't run out during the life of this universe. The only trouble
>>>> is,
>>>> we don't know accurately when that was.
>>>
>>>
>>>
>>>
>>> Wouldn't work, time isn't a constant. Doesn't show when your talking
>>> about
>>> seconds, but with picoseconds that will need to be taken into account.
>>> Number of picosecondes since creation of the universe isn't the same
>>> on top
>>> of mount Everest then at sea level. I wonder how NTP is going to
>>> deal with
>>> that LOL.
>>>
>>>
>>>>
>>>> Gordon L. Burditt
>>>
>>>
>>
>>
>>
>> I hereby nominate Bell Labs as the relative center of time, hence
>> forth referred to as the Origin. The time at which any event occurs
>> is not the local time, but the perceived time at the Origin "when" the
>> event occurred, even if the event was not "then" directly observable
>> from the Origin.
>
>
q...@q.com top-posted:
> Center of time is the United States Naval Observatory.
> http://tycho.usno.navy.mil/history.html
> http://tycho.usno.navy.mil/master.html
> http://tycho.usno.navy.mil/clocks.html
There are plenty of existing "centers of time," and I might also mention
Greenwich. I'm suggesting a center not to be used as an actual point of
physical measurement, but as a conceptual reference point for use in
software.
Corey Murtagh
<snip>
> The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
> current rate of 80 million/day, it will be completely gone within the lifespans
> of some of the folks walking the earth today.
Last time I heard a prediction on that (which wasn't all that recent,
admittedly), trend analysis on usage vs known (or suspected) supplies
put the run-out point around 2025.
So yeah, I think a /lot/ of folks here will see the end.
> My solution is that I plan to be dead around 2040 or so.
15 years after the oil runs out and we're all paying US$20/gallon for
vehicle grade alcohol :>
--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur!"
myren, lord
>> In 2038 all OS (Unix included) will have 64 bits
> Which is why we probably won't ever need any more than
> 64 bits to hold dates.
> Our galaxy will probably have collapsed by then, and
> maybe along with the whole universe.
God forbid I'm not running at least 256 bits by then. ;)
Myren
Keith Thompson
> "Gordon Burditt" <gordon...@burditt.org> wrote in message
> news:c95mfi$6...@library2.airnews.net...
> > My personal preference would be for a 256-bit number of picoseconds since
> > the creation of the universe. It gives better precision than 1 second.
> > It won't run out during the life of this universe. The only trouble is,
> > we don't know accurately when that was.
>
> You assume a "when" exists; relativity says that's impossible.
>
> Relativity aside, there's nothing preventing time_t from being a
> floating-point number whose zero is at a particular epoch. Epsilon of the
> chosen type determines the precision of your clock.
With a floating-point type, the precision of your clock is also
determined by how far you are from the epoch. I'd rather have a
consistent precision over the entire representable range than be able
to measure picoseconds close to the epoch, but have the precision drop
by a factor of two every now and then.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
SM Ryan
# those still using proprietry software ;->
I'm still using 68K programs intended for Mac System 5 or 6 on a MacOSX
powerpc chip.
--
SM Ryan http://www.rawbw.com/~wyrmwif/
A bunch of savages in this town.
Mabden
news:46pcb0tco7vnc54f8...@4ax.com...
> On 27 May 2004 21:27:14 GMT, gordon...@burditt.org (Gordon
> Burditt) wrote:
>
> >>[snip]
> >
> >My personal preference would be for a 256-bit number of picoseconds since
> >the creation of the universe. It gives better precision than 1 second.
> >It won't run out during the life of this universe. The only trouble is,
> >we don't know accurately when that was.
> >
> >
> > Gordon L. Burditt
> < mode = nitpick >
> Not quite accurate. We know precisely when the universe started; at
> time = 0.
But only for relatively small values of zero.
> The problem is that we don't know what the time is now.
> < mode = whatever_passes_for_normal >
Thursday, about tea time. Always.
--
Mabden
Mabden
news:k-GdnRbmXKu...@comcast.com...
>
> I hereby nominate Bell Labs as the relative center of time, hence forth
> referred to as the Origin.
I already pay them for "overages" on my cell phone. Please, don't ask me to
pay them on my LIFE, as well.
--
Mabden
Mabden
news:10857222...@radsrv1.tranzpeer.net...
> AngleWyrm wrote:
>
> <snip>
> > The entire planet's 3 thrillion barrels of oil is about 25% gone, and at
the
> > current rate of 80 million/day, it will be completely gone within the
lifespans
> > of some of the folks walking the earth today.
>
> Last time I heard a prediction on that (which wasn't all that recent,
> admittedly), trend analysis on usage vs known (or suspected) supplies
> put the run-out point around 2025.
>
> So yeah, I think a /lot/ of folks here will see the end.
>
> > My solution is that I plan to be dead around 2040 or so.
>
> 15 years after the oil runs out and we're all paying US$20/gallon for
> vehicle grade alcohol :>
>
Yeah, there's always methane and grain alcohol - too expensive now, but
cheap when the oil runs out and costs $200 a barrel.
Those people will be livid with us, you know! They are going to have a space
station and off world places to go to. They'll really need rocket fuel and
have great ways of turning crude oil into fantastic new fuels with great
efficiency. They'll have cars running on corn (like we could now). But they
won't have the prime crude oil! They'll be boiling shale to eke out tiny
amounts of oil!
They'll look back and curse us for using all the primo stuff on CARS and
PLANES!!! It'll be, like, "You IDIOTS! You could have just burned Vodka and
gotten around on Earth! We need the good stuff NOW!!!!"
HeHe The future sucks!
--
Mabden
Richard Bos
> Although the Y2K scare turned out to be vastly overblown, we do have a
> massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
> 18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
> After that, the time on the Unix systems will read as Fri Dec 13
> 14:45:52 1901.
I see a two-step solution, doing one thing and refraining from doing
another. Step one: start using 64-bit time_t's. Step two: stop storing
time_t's directly on disk, use standardised (ISO) formats.
Times and dates presented to your user need not change at all, since
presenting a user with an undecoded time_t is cruel and unusual
punishment anyway; therefore, there are none of the socio-behavioural
problems that surrounded the Y2K problem.
Richard
Richard Bos
> AngleWyrm wrote:
>
> > The entire planet's 3 thrillion barrels of oil is about 25% gone, and at the
> > current rate of 80 million/day, it will be completely gone within the lifespans
> > of some of the folks walking the earth today.
>
> Last time I heard a prediction on that (which wasn't all that recent,
> admittedly), trend analysis on usage vs known (or suspected) supplies
> put the run-out point around 2025.
The two previous times I heard predictions on that, the dates were 1980
and 2000. So I'm not scared. I see much better reasons for finding
alternative sources of energy; Shell, Exxon, and the oil-guzzling USA
getting a bit nervous don't matter much to me.
> > My solution is that I plan to be dead around 2040 or so.
>
> 15 years after the oil runs out and we're all paying US$20/gallon for
> vehicle grade alcohol :>
I won't. I'll never be paying US$20 or US$ anything for anything.
Richard
Gerry Quinn
xxx...@yyyyyyy.com says...
> "Generic Usenet Account" <use...@sta.samsung.com> wrote in message
> news:90e5135.04052...@posting.google.com...
> < snip >
> > Although the Y2K scare turned out to be vastly overblown,
>
> Idiot!! It wasn't "vastly overblown" at all. The fact is,
> we did a damn good job fixing it.
In countries where little or no effort was put into preventing it, no
significant problems occurred either.
"Only the vigilance of our firefighters has prevented this 2000-year old
forest from burning to the ground dozens of times over the last decade!"
- Gerry Quinn
Mabden
news:nZotc.24498$rb....@nwrdny03.gnilink.net...
>
> "Generic Usenet Account" <use...@sta.samsung.com> wrote in message
> news:90e5135.04052...@posting.google.com...
> < snip >
> > Although the Y2K scare turned out to be vastly overblown,
> < snip >
>
> Idiot!! It wasn't "vastly overblown" at all. The fact is,
> we did a damn good job fixing it.
Indeed, the problem was worked on for over a year and a half at my
workplace. I personally spent many a Saturday and late night for a full
year, with no extra money - ah, salary. Our system had a 2000 and a 20XX
problem (I forget the exact year - maybe the 2038 Unix year) and we spent
many man-hours fixing the problems so that all the sales people would get
their commissions on time, and not have them sent to their grandfathers!
--
Mabden
Robert W. McAdams
> Dan Pop wrote:
> >
> > So, what's the next massive problem we have to worry about, now that we
> > have just solved this one?
>
> proud of become obsolete. If it took several years to fix just
> 40 years worth of software for the Y2K problem, just think how
> long it will take to fix 8000 years worth of software for the
> Y10K problem. We had better get started right away. There is no
> time to lose.
Actually, the next big date problem is the Y2100 problem (at least for
those who aren't still concerned about Y2K, which is still 44 years
away). Many programs still assume that any year that's evenly
divisible by 4 is a leap year.
Bob McAdams
Fambright
Richard Bos
> Actually, the next big date problem is the Y2100 problem (at least for
> those who aren't still concerned about Y2K, which is still 44 years
> away). Many programs still assume that any year that's evenly
> divisible by 4 is a leap year.
That's a small date problem, easily corrected. All it takes is an
amendment of a tiny expression to a still not complicated expression.
No changes to any interface are needed, so this is very straightforward
to put into effect.
Richard
q...@q.com
t only approches zero.
rossum wrote:
> On 27 May 2004 21:27:14 GMT, gordon...@burditt.org (Gordon
> Burditt) wrote:
>
>
>>>[snip]
>>>
>>My personal preference would be for a 256-bit number of picoseconds since
>>the creation of the universe. It gives better precision than 1 second.
>>It won't run out during the life of this universe. The only trouble is,
>>we don't know accurately when that was.
>>
>>
>> Gordon L. Burditt
>>
> < mode = nitpick >
> Not quite accurate. We know precisely when the universe started; at
> time = 0. The problem is that we don't know what the time is now.
> < mode = whatever_passes_for_normal >
>
> rossum
>
> --
>
> The Ultimate Truth is that there is no Ultimate Truth
>
q...@q.com
year it must be divisible by 400.
Bob Day
news:MPG.1b20ff0fc...@news.indigo.ie...
Pull your head out of the sand for a moment, and take
a look at: http://www.grantjeffrey.com/article/y2kretro.htm
-- Bob Day
Dan Pop
>My personal preference would be for a 256-bit number of picoseconds since
>the creation of the universe. It gives better precision than 1 second.
>It won't run out during the life of this universe. The only trouble is,
>we don't know accurately when that was.
Does it matter?
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>Otto Wyss wrote:
>> Dan Pop <Dan...@cern.ch> wrote:
>>>Nope, this won't happen. By then, time_t will be a 64-bit type, as it
>>>already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
>>
>> The time_t might have 64-bit but are you sure that every occurence where
>> the time is copied or used is as well?
>
>By 2038 opensourced software will be abundant and everyone will laugh at
>those still using proprietry software ;->
Guess what? Even proprietary software is maintained.
Dan Pop
Yeah, but that would be a 64-bit x 4 vector processor ;-)
Dan Pop
>In article <nZotc.24498$rb....@nwrdny03.gnilink.net>,
>xxx...@yyyyyyy.com says...
>> "Generic Usenet Account" <use...@sta.samsung.com> wrote in message
>> news:90e5135.04052...@posting.google.com...
>> < snip >
>> > Although the Y2K scare turned out to be vastly overblown,
>> < snip >
>>
>> Idiot!! It wasn't "vastly overblown" at all. The fact is,
>> we did a damn good job fixing it.
>
>In countries where little or no effort was put into preventing it, no
>significant problems occurred either.
A country generating no significant software products has nothing to fix.
It's as simple as that.
Stephen Sprunk
news:10857222...@radsrv1.tranzpeer.net...
> AngleWyrm wrote:
>
> 15 years after the oil runs out and we're all paying US$20/gallon for
> vehicle grade alcohol :>
I assume that $20 is after inflation, which means it'll be on par (in
constant dollars) with what we pay for petrol or ethanol today. Hardly a
problem, though I'd expect us all to be running on hydrogen by then; ethanol
is a transition fuel.
S
--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin
Leor Zolman
wrote:
>My personal preference would be for a 256-bit number of picoseconds since
>the creation of the universe. It gives better precision than 1 second.
>It won't run out during the life of this universe. The only trouble is,
>we don't know accurately when that was.
That's ok, we probably know it to at least the same relative accuracy as
January 1, 1970 "accurately" mirrors the beginning of the Unix era.
-leor
>
>
> Gordon L. Burditt
--
Leor Zolman --- BD Software --- www.bdsoft.com
On-Site Training in C/C++, Java, Perl and Unix
C++ users: download BD Software's free STL Error Message Decryptor at:
www.bdsoft.com/tools/stlfilt.html
Gerry Quinn
xxx...@yyyyyyy.com says...
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
> > > > Although the Y2K scare turned out to be vastly overblown,
> > > < snip >
> > >
> > > Idiot!! It wasn't "vastly overblown" at all. The fact is,
> > > we did a damn good job fixing it.
> >
> > In countries where little or no effort was put into preventing it, no
> > significant problems occurred either.
>
> Pull your head out of the sand for a moment, and take
> a look at: http://www.grantjeffrey.com/article/y2kretro.htm
LOL! That article was written a mere ten days into the year 2000 by tha
author of "The Millenial Meltdown", and already he was running for
cover. He should have waited a few days, some of his his followers
might not have been down from the hills in time to read it.
He had no significant examples of serious failures to report, so he
started pushing that good old line "If it wasn't serious why did we
spend so much?". Nearly all the article is just "Everybody else said it
was serious too".
He asks:
"Those who naively suggest that Y2K was all hype should ask themselves
why banks (who are not generally known to throw their money away) would
spend literally hundreds of millions of dollars and hundreds of
thousands of man hours to fix the problem..."
You know, banks *aren't* known for throwing their money away - they've
got plenty of yours and mine for that! Barings, for example, or AIB.
There was a Feb 29 bug in 2000 that wasn't hyped at all, and little
enough went wrong that day either.
Truth is the Millenium Bug Disaster was a '60s science fiction scenario,
based on the assumption that all the operations that keep the industrial
world turning are done by technicians blindly obeying the orders on
punched cards that some big old computer spits out. The real world is
considerably more fault tolerant.
- Gerry Quinn
CBFalconer
> "Corey Murtagh" <em...@slingshot.no.uce> wrote in message
>
>>
>> 15 years after the oil runs out and we're all paying
>> US$20/gallon for vehicle grade alcohol :>
>
> I assume that $20 is after inflation, which means it'll be on par
> (in constant dollars) with what we pay for petrol or ethanol
> today. Hardly a problem, though I'd expect us all to be running
> on hydrogen by then; ethanol is a transition fuel.
And where does the power to extract that hydrogen come from? In
case you hadn't noticed it does not tend to occur in free form in
nature. However, it can serve as an intermediary between real
renewable sources and portable machinery.
Otto Wyss
> "Otto Wyss" <otto...@orpatec.ch> wrote in message
> news:1gegpbt.ot7t0q1p5gqogN%otto...@orpatec.ch...
> > The time_t might have 64-bit but are you sure that every occurence where
> > the time is copied or used is as well?
>
> If someone copies a time_t into a variable of any other type, they may be
> invoking undefined behavior, which means it's not the Standard's problem,
> it's the coder's.
>
> time_t exists for a reason, just like size_t. Use them.
>
I don't hope time_t isn't as often converted to int as size_t is. Well I
guess it won't be that big problem, I just wanted to point out that you
never should assume what other coders think.
O. Wyss
--
See a huge pile of work at " http://wyodesktop.sourceforge.net/"
Otto Wyss
> Otto Wyss wrote:
> > The time_t might have 64-bit but are you sure that every occurence where
> > the time is copied or used is as well?
>
> By 2038 opensourced software will be abundant and everyone will laugh at
> those still using proprietry software ;->
Whow perfect! I'll see that my OpenSource projects are finished be then.
jpd
> "Corey Murtagh" <em...@slingshot.no.uce> wrote in message
> news:10857222...@radsrv1.tranzpeer.net...
>> AngleWyrm wrote:
>> > My solution is that I plan to be dead around 2040 or so.
Hm I might not make that. Fun prospect!
>> 15 years after the oil runs out and we're all paying US$20/gallon for
>> vehicle grade alcohol :>
>
> I assume that $20 is after inflation, which means it'll be on par (in
> constant dollars) with what we pay for petrol or ethanol today. Hardly a
> problem, though I'd expect us all to be running on hydrogen by then; ethanol
> is a transition fuel.
The fun thing of course is that alcohols are about the simplest things
to make, and dead cheap too. The only thing that make them so darn
expensive is the various governements wanting a piece of the action, in
the interest of letting people have less fun for their dollar.
Fact is, oil is not as cheap as it seems, as it has rather high cleanup
costs associated with it. Same with nuclear fuels, but oil doesn't have
quite such spectacular faillure modes. Altough I have to admit that
fuel/air bombs are kinda neat. And oily birds make for nice television
and cause traffic jams with people driving to a different, clean beach.
Same with our silicon based computing stuffs. They and the facilities
needed to produce them are not very environment friendly, and the
pittance some of us now have to pay as advance clean-up costs will not
be enough to fix the problems the obsoleted debris will create later on.
Anyway. Whatever we do, we'll pay for it sooner or later. If sufficiently
late we'll just be cursed by our ancestors. Which would you prefer?
--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
Stephen Sprunk
> Stephen Sprunk <ste...@sprunk.org> wrote:
>
> > "Otto Wyss" <otto...@orpatec.ch> wrote in message
> > news:1gegpbt.ot7t0q1p5gqogN%otto...@orpatec.ch...
> > > The time_t might have 64-bit but are you sure that every occurence
where
> > > the time is copied or used is as well?
> >
> > If someone copies a time_t into a variable of any other type, they may
be
> > invoking undefined behavior, which means it's not the Standard's
problem,
> > it's the coder's.
> >
> > time_t exists for a reason, just like size_t. Use them.
> >
> I don't hope time_t isn't as often converted to int as size_t is. Well I
> guess it won't be that big problem, I just wanted to point out that you
> never should assume what other coders think.
Neither time_t nor size_t is ever converted to int in code I write or
maintain; I can't speak to what others do...
With the growing adoption of 64-bit desktops we already see bugs where
people improperly convert size_t to int, at least on platforms where int
isn't also 64-bit (i.e. AMD64). We'll find out how many people don't use
time_t correctly in 2038 :)
Stephen Sprunk
news:40B751E8...@yahoo.com...
> Stephen Sprunk wrote:
> > I assume that $20 is after inflation, which means it'll be on par
> > (in constant dollars) with what we pay for petrol or ethanol
> > today. Hardly a problem, though I'd expect us all to be running
> > on hydrogen by then; ethanol is a transition fuel.
>
> And where does the power to extract that hydrogen come from? In
> case you hadn't noticed it does not tend to occur in free form in
> nature. However, it can serve as an intermediary between real
> renewable sources and portable machinery.
Hydrogen isn't the original source; however, it is a clean, portable way to
store and transport energy generated by some other means. Depending on the
original source, the entire system may or may not be clean, and there's
varying values of "clean" as well.
Ethanol is mainly interesting because it has almost the same energy density
as petrol, has about the same price, runs in the same engines without
modification (though the fuel system needs anti-corrosion protection), uses
the same transport and fueling infrastructure, and can be produced nearly
anywhere in the world. While ethanol is far cleaner than petrol, it's
nowhere near as clean as hydrogen even if you consider waste generated in
producing the latter.
q...@q.com
either to the resellers (filling stations)
or regionally (to terminals).
Gasoline is distributed to terminals via pipelines.
MTBE is also distributed via pipelines. But MTBE
pollutes ground water.
Ethanol is shipped via trucks, no pipelines.
Any thoughts on hydrogen distribution?
Thomas G. Marshall
> In article <nZotc.24498$rb....@nwrdny03.gnilink.net>,
> xxx...@yyyyyyy.com says...
>> "Generic Usenet Account" <use...@sta.samsung.com> wrote in message
>> news:90e5135.04052...@posting.google.com...
>> < snip >
>>> Although the Y2K scare turned out to be vastly overblown,
>> < snip >
>>
>> Idiot!! It wasn't "vastly overblown" at all. The fact is,
>> we did a damn good job fixing it.
>
> In countries where little or no effort was put into preventing it, no
> significant problems occurred either.
Like whom? It seems to me that every software installation of major
worth, regardless of the country, was checked and fixed and rechecked,
etc.
I still think that the y2k thing is real----I'm worried. Is it over
yet?
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupy
ournose.
Thomas G. Marshall
> "Dan Pop" <Dan...@cern.ch> wrote in message
> news:c957pb$5mq$2...@sunnews.cern.ch...
>> In <90e5135.04052...@posting.google.com>
>> use...@sta.samsung.com
> (Generic Usenet Account) writes:
>>
>>
>> Nope, this won't happen. By then, time_t will be a 64-bit type, as
>> it already is on some 64-bit platforms (e.g. all 64-bit Linux ports):
>
>> So, what's the next massive problem we have to worry about, now that
>> we
>> have just solved this one?
>
> The entire planet's 3 thrillion barrels of oil is about 25% gone, and
> at the current rate of 80 million/day, it will be completely gone
> within the lifespans of some of the folks walking the earth today.
>
> My solution is that I plan to be dead around 2040 or so.
When I was in middle school, mid to late 70's, they told us with
completely /authoritative tones/ that if the world were entirely hollow
and filled with oil that it would be used up before the year 2020.
eeeeeeeeee-Yuh.
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupy
ournose.
Thomas G. Marshall
> Stephen Sprunk wrote:
>> "Corey Murtagh" <em...@slingshot.no.uce> wrote in message
>>
> ... snip ...
>>>
>>> 15 years after the oil runs out and we're all paying
>>> US$20/gallon for vehicle grade alcohol :>
>>
>> I assume that $20 is after inflation, which means it'll be on par
>> (in constant dollars) with what we pay for petrol or ethanol
>> today. Hardly a problem, though I'd expect us all to be running
>> on hydrogen by then; ethanol is a transition fuel.
>
> And where does the power to extract that hydrogen come from?
Nuclear power plants.
> In
> case you hadn't noticed it does not tend to occur in free form in
> nature. However, it can serve as an intermediary between real
> renewable sources and portable machinery.
>
> --
> fix (vb.): 1. to paper over, obscure, hide from public view; 2.
> to work around, in a way that produces unintended consequences
> that are worse than the original problem. Usage: "Windows ME
> fixes many of the shortcomings of Windows 98 SE". - Hutchison
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupy
ournose.
Thomas G. Marshall
I'm thinking they're gonna hate us for one thing for another. If not
for environmental reasons then perhaps social. Heck, we might as well
give'm something to cry about. Let's go melt them polar caps good.
Er......wait a while....
>
>
> --
> j p d (at) d s b (dot) t u d e l f t (dot) n l .
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupy
ournose.
Thomas G. Marshall
> "Gordon Burditt" <gordon...@burditt.org> wrote in message
> news:c95mfi$6...@library2.airnews.net...
>
>> My personal preference would be for a 256-bit number of picoseconds
>> since the creation of the universe. It gives better precision than
>> 1 second. It won't run out during the life of this universe. The
>> only trouble is, we don't know accurately when that was.
>
> Given we want to represent times in the past as well as the future,
> it would be reasonable to fix 'now' (give or take) as midpoint in the
> range, so why not arbitrarily pick
>
> 00:00:00.000 on the morning of January First 0001 as
> 1-followed-by-255-zeroes (256-bit unsigned value).
Without doing the math....Does that leave it possible to have years
/before/ the begining of time?
--
Everythinginlifeisrealative.Apingpongballseemssmalluntilsomeoneramsitupy
ournose.
Stephen Sprunk
>
> Stephen Sprunk wrote:
> > Ethanol is mainly interesting because it has almost the same energy
density
> > as petrol, has about the same price, runs in the same engines without
> > modification (though the fuel system needs anti-corrosion protection),
uses
> > the same transport and fueling infrastructure, and can be produced
nearly
> > anywhere in the world. While ethanol is far cleaner than petrol, it's
> > nowhere near as clean as hydrogen even if you consider waste generated
in
> > producing the latter.
>
> either to the resellers (filling stations)
> or regionally (to terminals).
> Gasoline is distributed to terminals via pipelines.
> MTBE is also distributed via pipelines. But MTBE
> pollutes ground water.
> Ethanol is shipped via trucks, no pipelines.
>
> Any thoughts on hydrogen distribution?
Once oil is refined into gasoline (aka petrol), it is shipped to filling
stations nearly exclusively via rail and truck tankers, at least in the US.
Hydrogen would be distributed the same way. Natural Gas is the only fuel
commonly transported via pipeline to consumers, and that makes it attractive
in the near term, but CNG and LNG aren't long-term solutions for clean
energy.
Transporting large masses of H2 isn't nearly as safe as petrol, for obvious
reasons, but this is mostly offset because hydrogen can be produced anywhere
electricity is available, removing the need to ship it long distances around
the world or even around a state/province. In theory, every filling station
could produce their own, removing transport from the picture entirely, but I
doubt that's cost-effective.
CBFalconer
> CBFalconer <cbfal...@yahoo.com> coughed up the following:
>> Stephen Sprunk wrote:
>>> "Corey Murtagh" <em...@slingshot.no.uce> wrote in message
>>>
>> ... snip ...
>>>>
>>>> 15 years after the oil runs out and we're all paying
>>>> US$20/gallon for vehicle grade alcohol :>
>>>
>>> I assume that $20 is after inflation, which means it'll be on par
>>> (in constant dollars) with what we pay for petrol or ethanol
>>> today. Hardly a problem, though I'd expect us all to be running
>>> on hydrogen by then; ethanol is a transition fuel.
>>
>> And where does the power to extract that hydrogen come from?
>
> Nuclear power plants.
Now you are really trying to pull my chain. Better known as a
silly way to boil water. If you could propose a way of nullifying
the waste products, that would be one thing. Hiding them under
the rug for future generations does not count. Take a look at the
chart of the nuclides, and the products of uranium fission,
sometime.
Mabden
news:2239adb8ffb0f421...@news.teranews.com...
> Transporting large masses of H2 isn't nearly as safe as petrol, for
obvious
> reasons
I'm sorry, but what are the reason Hydrogen is less safe than petrol or
natural gas?
--
Mabden
q...@q.com
Stephen Sprunk wrote:
> <q...@q.com> wrote in message news:40B80714...@q.com...
>
>>Stephen Sprunk wrote:
>>
>>>Ethanol is mainly interesting because it has almost the same energy
>>>
> density
>
>>>as petrol, has about the same price, runs in the same engines without
>>>modification (though the fuel system needs anti-corrosion protection),
>>>
> uses
>
>>>the same transport and fueling infrastructure, and can be produced
>>>
> nearly
>
>>>anywhere in the world. While ethanol is far cleaner than petrol, it's
>>>nowhere near as clean as hydrogen even if you consider waste generated
>>>
> in
>
>>>producing the latter.
>>>
>>I am not sure hyow hydrogen would be ditributed,
>>either to the resellers (filling stations)
>>or regionally (to terminals).
>>Gasoline is distributed to terminals via pipelines.
>>MTBE is also distributed via pipelines. But MTBE
>>pollutes ground water.
>>Ethanol is shipped via trucks, no pipelines.
>>
>>Any thoughts on hydrogen distribution?
>>
>
> Once oil is refined into gasoline (aka petrol), it is shipped to filling
> stations nearly exclusively via rail and truck tankers, at least in the US.
Gasoline, one of the main products refined from crude oil, accounts for
just about 16 percent of the energy consumed in the United States. The
primary use for gasoline is in automobiles and light trucks. Gasoline
also fuels boats, recreational vehicles, and various farm and other
equipment. While gasoline is produced year-round, extra volumes are made
in time for the summer driving season. Gasoline is delivered from oil
refineries mainly through pipelines to a massive distribution chain
serving 168,000 retail gasoline stations throughout the United States.1
There are three main grades of gasoline: regular, mid-grade, and
premium. Each grade has a different octane level. Price levels vary by
grade, but the price differential between grades is generally constant.
The cost to produce and deliver gasoline to consumers includes the cost
of crude oil to refiners, refinery processing costs, marketing and
distribution costs, and finally the retail station costs and taxes. The
prices paid by consumers at the pump reflect these costs, as well as the
profits (and sometimes losses) of refiners, marketers, distributors, and
retail station owners.
In 2002, the price of crude oil averaged $24.09 per barrel, and crude
oil accounted for about 43% of the cost of a gallon of regular grade
gasoline (Figure 1). In comparison, the average price for crude oil in
2001 was $22.95 per barrel, and it composed 38% of the cost of a gallon
of regular gasoline. The share of the retail price of regular grade
gasoline that crude oil costs represent varies somewhat over time and
among regions.
Federal, State, and local taxes are a large component of the retail
price of gasoline. Taxes (not including county and local taxes) account
for approximately 31 percent of the cost of a gallon of gasoline. Within
this national average, Federal excise taxes are 18.4 cents per gallon
and State excise taxes average about 20 cents per gallon.2Also, eleven
States levy additional State sales and other taxes, some of which are
applied to the Federal and State excise taxes. Additional local county
and city taxes can have a significant impact on the price of gasoline.
Refining costs and profits comprise about 13% of the retail price of
gasoline. This component varies from region to region due to the
different formulations required in different parts of the country.
Distribution, marketing and retail dealer costs and profits combined
make up 13% of the cost of a gallon of gasoline. From the refinery, most
gasoline is shipped first by pipeline to terminals near consuming areas,
then loaded into trucks for delivery to individual stations. Some retail
outlets are owned and operated by refiners, while others are independent
businesses that purchase gasoline for resale to the public. The price on
the pump reflects both the retailer's purchase cost for the product and
the other costs of operating the service station. It also reflects local
market conditions and factors, such as the desirability of the location
and the marketing strategy of the owner.
Gerry Quinn
> >
> > Nuclear power plants.
>
> Now you are really trying to pull my chain. Better known as a
> silly way to boil water. If you could propose a way of nullifying
> the waste products, that would be one thing. Hiding them under
> the rug for future generations does not count. Take a look at the
> chart of the nuclides, and the products of uranium fission,
> sometime.
Then do an assay of the amount of natural radionucleides that are hidden
'under the rug'. I've heard there's stuff called uranium with a half-
life of 4000 million years, just hidden in rocks in unmarked locations
all over the planet. If you have a granite fireplace, there's even some
in your house, oozing radioactive radon gas into the air you breathe.
- Gerry Quinn
Gerry Quinn
tgm2tothe...@replacetextwithnumber.hotmail.com says...
> > sufficiently late we'll just be cursed by our ancestors. Which would
> > you prefer?
>
>
> I'm thinking they're gonna hate us for one thing for another. If not
> for environmental reasons then perhaps social. Heck, we might as well
> give'm something to cry about. Let's go melt them polar caps good.
"Those bastards in the twenty-first century could have prevented the ice
age, but they insisted on reducing CO2 emissions..."
- Gerry Quinn
Jens.T...@physik.fu-berlin.de
Well, if I am not completely mistaken, there's quite a bit of a
difference in the _concentration_ the stuff has been hidden 'under
the rug' by nature (plus stuff like plutonium doesn't seem to be very
common there) and the one the waste products are going to be stashed
away in. Or did they come upt with a way to distribute that stuff
evenly over a volume of a small mountain range and nobody told me?
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.T...@physik.fu-berlin.de
\__________________________ http://www.toerring.de
jpd
>
> I'm sorry, but what are the reason Hydrogen is less safe than petrol or
> natural gas?
Apart from the nasty tendency of those awfully small molecules to
slip through almost everything else (the main effort in creating
storage solutions for it is in storing it in a form where it's bound to
something else), it's mostly fear factor I guess.
It's a pity, really. It has such a simple cycle and in itself is about
as `clean' as you could wish for. It's just that handling it is hard.
Roger Willcocks
"Thomas G. Marshall" <tgm2tothe...@replacetextwithnumber.hotmail.com>
wrote in message news:UIUtc.3050$hB2....@nwrdny03.gnilink.net...
I reckon so... 2^255 / (10^12 * 86400 * 365) = 1.8x10^57 years
or about 10^47 times the age of the universe.
To put it another way, the universe is apparently somewhere between 2^98 and
2^99 picoseconds old (10 - 20 thousand million years.)
--
Roger
Gerry Quinn
berlin.de says...
>
> > Then do an assay of the amount of natural radionucleides that are hidden
> > 'under the rug'. I've heard there's stuff called uranium with a half-
> > life of 4000 million years, just hidden in rocks in unmarked locations
> > all over the planet. If you have a granite fireplace, there's even some
> > in your house, oozing radioactive radon gas into the air you breathe.
>
> Well, if I am not completely mistaken, there's quite a bit of a
> difference in the _concentration_ the stuff has been hidden 'under
> the rug' by nature (plus stuff like plutonium doesn't seem to be very
> common there) and the one the waste products are going to be stashed
> away in. Or did they come upt with a way to distribute that stuff
> evenly over a volume of a small mountain range and nobody told me?
The irony is that that (dispersion) is precisely the sort of thing that
people object to! The result is that radioactive waste is held in
concentrated form and everyone is afraid of it. If it were diluted, the
environmentalists would protest that where there were once a thousand
tons of nuclear waste, there are now a million.
Note how frequently you see a casually implied estimate of the threat
from nuclear materials in terms of the mass of material multiplied by
the halflife.
And people complain about quite insignificant amounts of radionucleides
in seawater.
- Gerry Quinn
Baxter
-------------------------------------------------------------------------
Free software - Baxter Codeworks www.baxcode.com
-------------------------------------------------------------------------
"Stephen Sprunk" <ste...@sprunk.org> wrote in message
news:2239adb8ffb0f421...@news.teranews.com...
>
> Once oil is refined into gasoline (aka petrol), it is shipped to filling
> stations nearly exclusively via rail and truck tankers, at least in the
US.
Nope. There's been more than one explosion of gasoline pipelines.
---------
RENTON, Wash. (AP) - The operator of a 400-mile fuel pipeline system that
was shut down after an explosion plans to complete necessary repairs and
restart the line late Tuesday.
The repair and restart plan has been approved by coordinators for both the
U.S. Environmental Protection Agency and the state Ecology Department,
Olympic Pipe Line Co. spokesman Michael Abendhoff said Monday night.
The pipeline moves 12 million gallons of gasoline, diesel and jet fuel every
day. The explosion and subsequent fire disrupted fuel deliveries throughout
the system.
http://islandpacket.com/24hour/nation/story/1392234p-8654812c.html
Seattle - July 28, 1999 -The families of two 10-year-old boys killed in a
gasoline pipeline explosion last month filed suit Wednesday, seeking
punitive damages and to ban the pipeline operator from continuing to do
business in the State of Washington.
http://www.voiceoftheinjured.com/a-wd-pipe.html
Pipeline Accident Report: Rupture of Piney Point Oil Pipeline and Release
of Fuel Oil Near Chalk Point, Maryland
Pipeline Rupture and Release of Fuel Oil in the Reedy River at Fork Shoals,
South Carolina June 26, 1996
Williams Pipeline Company, Gasoline Explosion and Fire, Roseville,
Minnesota, April 16, 1981.
http://www.ntsb.gov/publictn/P_Acc.htm
Dik T. Winter
> On 2004-05-29, Mabden <mab...@sbcglobal.net> wrote:
> > I'm sorry, but what are the reason Hydrogen is less safe than petrol or
> > natural gas?
>
> Apart from the nasty tendency of those awfully small molecules to
> slip through almost everything else (the main effort in creating
> storage solutions for it is in storing it in a form where it's bound to
> something else), it's mostly fear factor I guess.
Yup. In one recent news report on a fire in a hydrogen tank somewhere in
the Netherlands, the conclusion was that there was no safety hazard as no
toxic chemical stuff did emerge.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Peter J. Acklam
> I'm sorry, but what are the reason Hydrogen is less safe than
> petrol or natural gas?
I'm sorry, but what has this got to do in *any* of these
newsgroups.
Peter
--
Peter J. Acklam - pjac...@online.no - http://home.online.no/~pjacklam
CBFalconer
> Jens.T...@physik.fu-berlin.de says...
>>
>>> Then do an assay of the amount of natural radionucleides that are hidden
>>> 'under the rug'. I've heard there's stuff called uranium with a half-
>>> life of 4000 million years, just hidden in rocks in unmarked locations
>>> all over the planet. If you have a granite fireplace, there's even some
>>> in your house, oozing radioactive radon gas into the air you breathe.
>>
>> Well, if I am not completely mistaken, there's quite a bit of a
>> difference in the _concentration_ the stuff has been hidden 'under
>> the rug' by nature (plus stuff like plutonium doesn't seem to be very
>> common there) and the one the waste products are going to be stashed
>> away in. Or did they come upt with a way to distribute that stuff
>> evenly over a volume of a small mountain range and nobody told me?
>
> The irony is that that (dispersion) is precisely the sort of thing that
> people object to! The result is that radioactive waste is held in
> concentrated form and everyone is afraid of it. If it were diluted, the
> environmentalists would protest that where there were once a thousand
> tons of nuclear waste, there are now a million.
Chernobyl did an admirable job of dispersing radioactive waste
over a fairly wide area. Places such as Love Canal demonstrate
the efficacy of burying and forgetting wastes in general. 20 or
30 years after the banning of leaded gasoline, many highways
border vegetation show the benefits of lead dispersion.
I think we must belong to the genus Homo Non Sapiens.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Thomas G. Marshall
I no longer worry about OT posts in ng's. I've discovered that often a
subject is raised because of the /audience/ known to exist in the ng,
not its particular subject.
That is supposedly against the charter of the big 8. So be it.
--
While using is ok, actually /writing/ free software is a disingenuous
activity. You can afford to write software for free only because of
someone else somewhere actually paying for it. Just say no.
Thomas G. Marshall
> In article <3DUtc.3026$hB2....@nwrdny03.gnilink.net>,
In my life, the spirit of your point here has been echoed by me in a
very many circumstances and subject matters.
q...@q.com
at Chernobyl. Also, Chernobyl did NOT have a containment
building.
Helsinki (AFP) May 24, 2002
Finland's parliament on Friday approved construction of a fifth nuclear
reactor, the first such plant to be authorized in Western Europe or
North America since the Chernobyl disaster in 1986.
August Derleth
> "Stephen Sprunk" <ste...@sprunk.org> writes:
>> "Gordon Burditt" <gordon...@burditt.org> wrote in message
>> news:c95mfi$6...@library2.airnews.net...
>> > My personal preference would be for a 256-bit number of picoseconds since
>> > the creation of the universe. It gives better precision than 1 second.
>> > It won't run out during the life of this universe. The only trouble is,
>> > we don't know accurately when that was.
>>
>> You assume a "when" exists; relativity says that's impossible.
>>
>> Relativity aside, there's nothing preventing time_t from being a
>> floating-point number whose zero is at a particular epoch. Epsilon of the
>> chosen type determines the precision of your clock.
>
> With a floating-point type, the precision of your clock is also
> determined by how far you are from the epoch. I'd rather have a
> consistent precision over the entire representable range than be able
> to measure picoseconds close to the epoch, but have the precision drop
> by a factor of two every now and then.
Of course, more advanced beings would presumably have learned to cope with
that phenomenon, and have learned to focus on the more important concepts
in the Universe, such as universal mortality and alienation.
Singing:
"Does anybody really know what time it is?
Does anybody really care?
If so, I can't imagine why.
We've all got time enough to die."
-- Chicago
Sorry. ;-)
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
August Derleth
> "Generic Usenet Account" <use...@sta.samsung.com> wrote in message
> news:90e5135.04052...@posting.google.com...
>> Although the Y2K scare turned out to be vastly overblown, we do have a
>> massive problem ahead of us ------ the Year 2038 problem. On Mon Jan
>> 18 21:14:07 2038, the Unix seconds-since-epoch count will "roll-over".
>> After that, the time on the Unix systems will read as Fri Dec 13
>> 14:45:52 1901.
>
> You mean systems which use a signed 32-bit int for time_t. Modern systems
> use a 64-bit int for time_t, so the problem is moot (unless you're running
> code in 2038 that hasn't been recompiled since the early 1990s).
Which, in the real world, is very possible. The IA-64 architecture and the
Sparc-64 architecture both have explicit provisions to run 32-bit machine
code compiled for earlier iterations of the family tree. I think all
commercially viable 64-bit architectures will need very similar provisions.
Plus, in a world where PDP-8s are still used in mission-critical
applications by big organizations (BART), 32-bit systems will be around
long after 2038.
>
>> IMHO, if we want to avoid the last minute panic that we witnessed
>> towards the end of the last millennium (while pursuing the Y2K
>> problem), we should begin the process of debating the viable solutions
>> to this problem NOW. It will take a long time for the consensus to be
>> built, and to come up with a solution that most (if not all) people
>> find acceptable.
>
> There already is a solution, consensus for it, and implementations of it.
> The sky is NOT falling.
We knew, in a very real way, how to fix Y2K back in the 1980s. Hell, we
knew in the 1970s, but we thought it would be too expensive to do things
right.
IOW, the panic will set in, and it will be averted in 2037 or thereabouts
by the same method Y2K was averted in 1999.
Mark McIntyre
Think "Hindenberg"
If you pour a gallon of petrol on the floor, you can tap dance in it. If
you pour a gallon of natural gas on the floor, it dribbles out through the
drains in gaseous state. Trust me, I've done both. Heck I've even done it
with a gallon of iso-propanol (they're all handy coolants. The trick with
the last was to open the lab windows before I fell over dead drunk, and
then died of asphyxiation).
If you pour a gallon of H on the floor, you can kiss your ass goodbye as it
passes your head on its way to kingdom come. There /is/ a reason that the
LH test rig at RAL was about a mile from the rest of the lab, behind 20ft
thick earth banks, and inside a concrete bunker with one disposable wall.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Mark McIntyre
<Dik.W...@cwi.nl> wrote:
>In article <10858372...@ente.ipberlin.com> jpd <read_t...@do.not.spam.it> writes:
> > On 2004-05-29, Mabden <mab...@sbcglobal.net> wrote:
> > > I'm sorry, but what are the reason Hydrogen is less safe than petrol or
> > > natural gas?
> >
> > Apart from the nasty tendency of those awfully small molecules to
> > slip through almost everything else (the main effort in creating
> > storage solutions for it is in storing it in a form where it's bound to
> > something else), it's mostly fear factor I guess.
>
>Yup. In one recent news report on a fire in a hydrogen tank somewhere in
>the Netherlands, the conclusion was that there was no safety hazard as no
>toxic chemical stuff did emerge.
Tank fires are fairly safe, as its the vapour that burns and in tanks, not
much can escape. Also tanks for storing Hydrogen tend to be filled with an
inert material to retard any heat.
Mind you I heard a great (but probably apocryphal) story about someone at
RAL who accidentally ignited the a coolant bath of the stuff, and was
running around with the top ablaze, searching for a suitable place to chuck
it before the heat convected in and boiled the rest. At that point, there
would have been one heck of an explosion.
Mabden
wrote in message news:335uc.4031$hB2...@nwrdny03.gnilink.net...
> Peter J. Acklam <pjac...@online.no> coughed up the following:
>
> > "Mabden" <mab...@sbcglobal.net> wrote:
> >
> >> I'm sorry, but what are the reason Hydrogen is less safe than
> >> petrol or natural gas?
> >
> > I'm sorry, but what has this got to do in *any* of these
> > newsgroups.
> >
> > Peter
>
>
> subject is raised because of the /audience/ known to exist in the ng,
> not its particular subject.
>
> That is supposedly against the charter of the big 8. So be it.
>
Perhaps you both missed the "[OT]" tag. What that means is that the post you
are about to read, or ignore - your choice, is Off Topic for this newsgroup.
It's a courtesy to explain to you that you would be wasting you time if you
thought this thread was related to the newsgroup. When you see [OT], you are
guaranteed to have a subject that does not relate to the proper purpose of
the newsgroup. Therefore, if you only want to read topics that ARE targeted
to your newsgroup, please, in the future, ignore posts with [OT] in the
subject, as you may find them to be not what you would expect in the
newsgroup.
--
Mabden
Mabden
news:t23ib01j0b4mtsfhf...@4ax.com...
> On Sat, 29 May 2004 09:48:24 GMT, in comp.lang.c , "Mabden"
> <mab...@sbcglobal.net> wrote:
>
> >"Stephen Sprunk" <ste...@sprunk.org> wrote in message
> >news:2239adb8ffb0f421...@news.teranews.com...
> >
> >> Transporting large masses of H2 isn't nearly as safe as petrol, for
> >obvious
> >> reasons
> >
> >I'm sorry, but what are the reason Hydrogen is less safe than petrol or
> >natural gas?
>
> Think "Hindenberg"
The Hindenberg didn't burn because of the hydrogen. You can't see hydrogen
burn (perhaps a little bluish glow).
The Hindenburg burned the cloth coating which was treated with the same
stuff we now use in rocket fuel. It went up because of static discharge that
was supposed to be mitigated by using wire to attach the cloth panels (to
ground it), but because they used rope instead the charge was allowed to
build until a flammable condition occured. It was a case of compounded
errors.
Learn a little history (and chemistry) before posting urban legends.
--
Mabden
Thomas G. Marshall
Have you lost your mind? I was agreeing with that very premise, and in
fact was pointing out a reason for it: People often like to discuss
things because of the ng's audience, not because of the ng's subject
topic. It's how most folks view it these days I think.
And, no by the way, I've seen purists attack even posts that were
labeled as "OT" under the argument that OT doesn't excuse a post
deliberately in the wrong ng. I certainly don't feel that way.
You seemed to have missed what I was saying entirely.
--
Forgetthesong,I'lljustoptforthefrontallobotomy...
Mabden
wrote in message news:aJbuc.5450$hB2....@nwrdny03.gnilink.net...
[snip vile attacks]
> And, no by the way, I've seen purists attack even posts that were
> labeled as "OT" under the argument that OT doesn't excuse a post
> deliberately in the wrong ng.
OK, Topic Nazi! I get your point, you want the "purity" of the newsgroup to
supersede the rights of posters who go off on tangents! Don't kill the
messenger, but people will sometimes have "side conversations" that are not
particularly "on- topic". That is just life, and the way people are.
Are you going to change the world, Net-Cop?! NO, I don't think so!
Is it *YOUR* job to police this newsgroup? NO!
Do I need this bad attitude after a hard day? No!
So keep your stupid opinions and attitude to yourself, Dick (Tracy)!
--
Mabden
Thomas G. Marshall
Yep, and then in 2039 the 20-20 hindsighters will say: "Y2038 was blown
way way out of proportion, nothing went wrong!!!!!"
>
>
> --
> yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
> To email me, rot13 and convert spelled-out numbers to numeric form.
> "Makes hackers smile" makes hackers smile.
--
Forgetthesong,I'lljustoptforthefrontallobotomy...
Thomas G. Marshall
> "Thomas G. Marshall"
> <tgm2tothe...@replacetextwithnumber.hotmail.com> wrote in
> message news:aJbuc.5450$hB2....@nwrdny03.gnilink.net...
>
> [snip vile attacks]
>
>> And, no by the way, I've seen purists attack even posts that were
>> labeled as "OT" under the argument that OT doesn't excuse a post
>> deliberately in the wrong ng.
>
> OK, Topic Nazi! I get your point,
You conveniently snipped away the sentence
I certainly don't feel that way.
that came right after that. Now WHY IS THAT? Could it be that you LIKE
misrepresenting the truth? That's called lying, and you should know
better.
> you want the "purity" of the
> newsgroup to supersede the rights of posters who go off on tangents!
> Don't kill the messenger, but people will sometimes have "side
> conversations" that are not particularly "on- topic". That is just
> life, and the way people are.
AND I AGREED WITH THAT. I even elaborated on why. I have no issue now,
nor ever, with people going off on a tangent in ANY newsgroup.
You Do realize that you're looking like a bigger and bigger idiot, don't
you? You must be pretty embarrassed by now.
>
> Are you going to change the world, Net-Cop?! NO, I don't think so!
>
> Is it *YOUR* job to police this newsgroup? NO!
>
> Do I need this bad attitude after a hard day? No!
>
> So keep your stupid opinions and attitude to yourself, Dick (Tracy)!
IT'S NOT MY OPINION. I SAID THAT I DIDN'T FEEL THAT WAY.
But YOU like to quote only CERTAIN sentences of what someone says.
Go ahead fool, show me where I was "a topic nazi". I was completely the
opposite!!!!!!!!
--
Forgetthesong,I'lljustoptforthefrontallobotomy...
Mabden
wrote in message news:J%buc.5515$hB...@nwrdny03.gnilink.net...
> IT'S NOT MY OPINION. I SAID THAT I DIDN'T FEEL THAT WAY.
Yeah, I know, I was just fucking with you. hehehe. Sorry.
--
Mabden
Thomas G. Marshall
> "Thomas G. Marshall"
Not a bad technique: get caught making a huge mistake and then say you
did it on purpose.
On purpose or not, you /might/ care for what others here think of you.
You and I weren't arguing in a void...
Mark McIntyre
<mab...@sbcglobal.net> wrote:
>"Mark McIntyre" <markmc...@spamcop.net> wrote in message
>news:t23ib01j0b4mtsfhf...@4ax.com...
>> On Sat, 29 May 2004 09:48:24 GMT, in comp.lang.c , "Mabden"
>> <mab...@sbcglobal.net> wrote:
>>
>> >"Stephen Sprunk" <ste...@sprunk.org> wrote in message
>> >news:2239adb8ffb0f421...@news.teranews.com...
>> >
>> >> Transporting large masses of H2 isn't nearly as safe as petrol, for
>> >obvious
>> >> reasons
>> >
>> >I'm sorry, but what are the reason Hydrogen is less safe than petrol or
>> >natural gas?
>>
>> Think "Hindenberg"
>
>The Hindenberg didn't burn because of the hydrogen. You can't see hydrogen
>burn (perhaps a little bluish glow).
>
>The Hindenburg burned the cloth coating which was treated with the same
>stuff we now use in rocket fuel.
Yesh, I saw that BBC docudrama too. I believe its still case not proven.
And you really think that the presence of a zillion moles of h2 didn't
assist somewhat?
Enough in this OT thread already...
jpd
> On Sun, 30 May 2004 01:13:17 GMT, in comp.lang.c , "Mabden"
><mab...@sbcglobal.net> wrote:
>>
>>The Hindenburg burned the cloth coating which was treated with the same
>>stuff we now use in rocket fuel.
>
> Yesh, I saw that BBC docudrama too. I believe its still case not proven.
> And you really think that the presence of a zillion moles of h2 didn't
> assist somewhat?
Think about it a bit. There's lots of hydrogen that is _not_ mixed with
air, so it can't burn until it encounters oxygen somewhere. (If it'd
been pre-mixed 2:1 with oxygen it would've gone BOOM instantly, but it
didn't. Igniting soap-bubbles filled with that mixture is a class-room
display experiment around here, BTW.)
You can pretty much emulate what happens when you fill a plastic bag
with, say, natural gas and hold a flame to it. The plastic burns first,
then the gas, which slowly forms a nice ball of fire as it gets out of
the bag (or the bag burns away).
Eyewitness reports gleaned from the 'net tell us that it was first
the outer hull, and only after a while the hydrogen burn was visible.
Thinking about it a bit more, I'd say that the actual cause of the fire
(sabotage or ropes instead of wire) is less important. The outer coating
_was_ too flammable, regardless of also being too ignitable.
Which is pretty clear from the after-incident technical investigation.
> Enough in this OT thread already...
Don't ask, then. :-)
CBFalconer
"q...@q.com" wrote:
> CBFalconer wrote:
>> Gerry Quinn wrote:
>>> Jens.T...@physik.fu-berlin.de says...
>>>
>>>>> Then do an assay of the amount of natural radionucleides that
>>>>> are hidden 'under the rug'. I've heard there's stuff called
>>>>> in rocks in unmarked locations all over the planet. If you
>>>>> have a granite fireplace, there's even some in your house,
>>>>> oozing radioactive radon gas into the air you breathe.
>>>>>
>>>> Well, if I am not completely mistaken, there's quite a bit of
>>>> a difference in the _concentration_ the stuff has been hidden
>>>> 'under the rug' by nature (plus stuff like plutonium doesn't
>>>> seem to be very common there) and the one the waste products
>>>> way to distribute that stuff evenly over a volume of a small
>>>> mountain range and nobody told me?
>>>
>>> The irony is that that (dispersion) is precisely the sort of
>>> thing that people object to! The result is that radioactive
>>> waste is held in concentrated form and everyone is afraid of
>>> it. If it were diluted, the environmentalists would protest
>>> that where there were once a thousand tons of nuclear waste,
>>> there are now a million.
>>
>> Chernobyl did an admirable job of dispersing radioactive waste
>> over a fairly wide area. Places such as Love Canal demonstrate
>> the efficacy of burying and forgetting wastes in general. 20 or
>> 30 years after the banning of leaded gasoline, many highways
>> border vegetation show the benefits of lead dispersion.
>>
>> I think we must belong to the genus Homo Non Sapiens.
>
> at Chernobyl. Also, Chernobyl did NOT have a containment
> building.
I didn't say it did. The point was that dispersal is no answer to
fission products, which depend on physics, not reactor
containment, moderators, etc.
>
> Helsinki (AFP) May 24, 2002
> Finland's parliament on Friday approved construction of a
> fifth nuclear reactor, the first such plant to be authorized
> in Western Europe or North America since the Chernobyl
> disaster in 1986.
My condolences to the Finns.
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Gerry Quinn
markmc...@spamcop.net says...
> >I'm sorry, but what are the reason Hydrogen is less safe than petrol or
> >natural gas?
>
> Think "Hindenberg"
>
> If you pour a gallon of petrol on the floor, you can tap dance in it. If
> you pour a gallon of natural gas on the floor, it dribbles out through the
> drains in gaseous state. Trust me, I've done both. Heck I've even done it
> with a gallon of iso-propanol (they're all handy coolants. The trick with
> the last was to open the lab windows before I fell over dead drunk, and
> then died of asphyxiation).
>
> If you pour a gallon of H on the floor, you can kiss your ass goodbye as it
> passes your head on its way to kingdom come. There /is/ a reason that the
> LH test rig at RAL was about a mile from the rest of the lab, behind 20ft
> thick earth banks, and inside a concrete bunker with one disposable wall.
Does liquid hydrogen ignite spontaneously in air? I wouldn't have
thought so. While I'm sure it evaporates faster than liquid nitrogen,
the cooling effect of a couple of inches of boiling hydrogen would
hardly be sufficient to stop you walking out. Not if you have shoes on
anyway! Of course there might be an alarming amount of fog...
The Hindenberg, in any case, was full of gaseous hydrogen, probably
safer than liquid, but anyway different. AFAIK, more than half of the
passengers survived, largely because a hydrogen fireball produces a
relatively small proportion of radiant heat.
- Gerry Quinn
q...@q.com
CBFalconer wrote:
Reprocessing "spent" fuel rods will eliminate that problem.
Anyway the real future in nuclear technology is fusion.
Jens.T...@physik.fu-berlin.de
> In article <2hrgvfF...@uni-berlin.de>, Jens.T...@physik.fu-
> berlin.de says...
>>
>> > Then do an assay of the amount of natural radionucleides that are hidden
>> > 'under the rug'. I've heard there's stuff called uranium with a half-
>> > life of 4000 million years, just hidden in rocks in unmarked locations
>> > all over the planet. If you have a granite fireplace, there's even some
>> > in your house, oozing radioactive radon gas into the air you breathe.
>>
>> Well, if I am not completely mistaken, there's quite a bit of a
>> difference in the _concentration_ the stuff has been hidden 'under
>> the rug' by nature (plus stuff like plutonium doesn't seem to be very
>> common there) and the one the waste products are going to be stashed
>> away in. Or did they come upt with a way to distribute that stuff
>> evenly over a volume of a small mountain range and nobody told me?
> The irony is that that (dispersion) is precisely the sort of thing that
> people object to! The result is that radioactive waste is held in
> concentrated form and everyone is afraid of it. If it were diluted, the
> environmentalists would protest that where there were once a thousand
> tons of nuclear waste, there are now a million.
Problem is that you can't properly dilute it down to a level similar
to the concentration in nature. Even if you could bring all the stiff
into a soluble form and a make a very fine powder out of it and then
drop it in the sea it would still take a long long time until it's
dispersed down to an acceptable level. While mixing comes free, thanks
to the second law of thermodynamics, it takes quite some time. But if
you have to speed it up you need lots of extra energy. If that would
be different please explain why e.g. in the Irish sea due to the
Sellafield/Windscale plant (or whatever they call the thing nowadays)
the concentrations are still that high.
> Note how frequently you see a casually implied estimate of the threat
> from nuclear materials in terms of the mass of material multiplied by
> the halflife.
> And people complain about quite insignificant amounts of radionucleides
> in seawater.
What's "insignificant" is depends a lot on whom you ask. And it meant
something quite different in the fifties compared to what it means
now, even to the stout supporters of the use of nuclear power. It's
simply that nobody knows what levels are "insignificant" since no-one
really understands all the mechanisms by which added amounts of radio-
active materials can influence living organisms. Some people (and not
from the crackpot fringe) even claim that small amounts are healthy -
having such a range of opinions shows quite nicely that nobody really
knows).
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.T...@physik.fu-berlin.de
\__________________________ http://www.toerring.de