f20 - difference between i386 and x86_64 distros

[Jerry Feldman]

On 01/20/2014 10:13 AM, Chris Adams wrote:
> Once upon a time, Robert Moskowitz <rgm at htt-consult.com> said:
>> On 01/20/2014 06:47 AM, Frank Murphy wrote:
>>> On Mon, 20 Jan 2014 06:45:54 -0800
>>> Robert Moskowitz <rgm at htt-consult.com> wrote:
>>>
>>>>> The day will come when all OS providers,
>>>>> will give cutoff for 32bit hardware\code
>>>> Well that is a given by 2026....
>>>>
>>>> :)
>>>>
>>>>
>>> Amazing what a guess will get ya,
>>> jail or laurels. :)
>> The death, so to speak, for the 32 bit time field.  Yes, it is
>> handle rather well now in software in preparation for that day, but
>> there is still plenty of bad stuff that will make all the planning
>> for y2k look like play stuff.
> Oh, was that what was supposed to be?  That's not until 2038 (for 32 bit
> signed int and epoch = 1970-01-01 00:00:00).
>
> I really doubt that it will be that big of a deal.  Most databases use
> actual date fields, not time_t (since time_t already doesn't cover many
> interesting dates).  Not all OSes use the same epoch either, so this is
> mostly a Unix problem, and most current Unix systems already handle a
> larger time_t (if somebody is still trying to make SunOS 4 or SCO run in
> 2038, time_t will be the least of their problems).
>
I was burned once by the 32-bit time. It was actually a bug in the Unix
standards tests. At the time I was working as a software engineer in the
develpment environment group for Digital Unix on the Alpha which was a
true 64-bit chip. The problem was that we had to use 32-bit time because
the standard mandated it. While 2038 (actually June sometime) is when
the 32-bit time integer goes negative, it is very common in financial
applications to project 50 or more years into the future. In my case, I
had updated the utmp libraries (and utxtmp). When I walked in one day
release management was banging on my cube because the standards tests
broke and it was in the utmp library, Well, there was nothing wrong with
utmp. Thanks to a bit of research and help of a colleage in the
standards group we focused on a bug in the standard test where the time
went negative. The author of the standard suite agreed and we were able
to get a waiver and also a fix to the standards suite. I currently work
on software that does financial simulations well into the future, and we
have our own time library because some of the products were 32-bit not
so long ago.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 530 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140125/40d7fda4/attachment-0001.sig>