Linux-Advocacy Digest #361, Volume #30 Wed, 22 Nov 00 03:13:03 EST
Contents:
Re: Of course, there is a down side... (Mike Byrns)
Re: OT: Could someone explain C++ phobia in Linux? ("Erik Funkenbusch")
Re: Linux 2.4 mired in delays as Compaq warns of lack of momentum ("Les Mikesell")
Re: OT: Could someone explain C++ phobia in Linux? ("Erik Funkenbusch")
Re: OT: Could someone explain C++ phobia in Linux? ("Erik Funkenbusch")
Re: OT: Could someone explain C++ phobia in Linux? ("Erik Funkenbusch")
new site ([EMAIL PROTECTED])
Re: The Sixth Sense ("Christopher Smith")
Re: Uptime -- where is NT? (sfcybear)
Re: Uptime -- where is NT? (sfcybear)
Re: Uptime -- where is NT? (sfcybear)
Re: Uptime -- where is NT? (sfcybear)
Re: Of course, there is a down side... ("Les Mikesell")
Re: Another happy Linux user ("Frank Van Damme")
Re: Uptime -- where is NT? ("Aaron R. Kulkis")
----------------------------------------------------------------------------
From: Mike Byrns <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Of course, there is a down side...
Date: Wed, 22 Nov 2000 06:10:47 GMT
mark wrote:
> In article <[EMAIL PROTECTED]>, Mike Byrns wrote:
> >Frog wrote:
> >
> >> On Fri, 17 Nov 2000 02:25:37 GMT , [EMAIL PROTECTED] wrote
> >> >On Thu, 16 Nov 2000 19:35:43 -0500, Gary Hallock
> >>
> >> >>I rarely have dependency problems. And its a lot better than DLL hell.
> >> >>rpm will
> >> >>tell you whats missing. You can install multiple rpms at once and all
> >> >>dependencies
> >> >
> >> >Sure it will with some arcane description of a file or package that is
> >> >nowhere near to the name of the actual package (that includes the file
> >> >you need), so unless you happen to know what these things actually
> >> >are, you will never find them.
> >>
> >> Yes, MSVCRT.DLL is so much more descriptive and unambiguous.
> >
> >That's a filename. There is a description as well. All properly written
> >32-bit Windows DLLs have additional information like the File Version,
> >Description, Publisher, Language, Original Filename (useful if it gets renamed
> >:-), the Product Name it's part of and that Product's Version. This info
> >alone can be used to easily ID almost any PE executable.
> >
> >> And of
> >> course, products from Microsoft *always* keep the most current DLL, so you
> >> *never* have software that relies on entry points that don't exist any
> >> more.
> >
> >This has been hashed about so many times that it's really lost any semblance
> >of humor. Properly written application installers do not replace newer
> >versions of shared components with older versions. So far I've not seen
> >anyone produce a relevant Microsoft application that blindly installs older
> >shared components. That's typically the realm of your AOLs and Netscape's and
> >such. That's OK though. They can keep on performing the equivalent of system
> >sabotage and Windows will replace their mess right along behind them.
> >
> >
>
> I might have misunderstood this thread, but I thought the suggestion was
> that the newer DLL no longer supported a given call, thus breaking some
> existing package.
>
> Isn't this what's become known as 'DLL Hell', considered to be a major
> issue with windows?
>
> Mark
The newer libs support the old calls even if they have to map them. The problem is
that 3rd-party installers have historically replaced NEWER DLLs to suit their own
needs thus breaking apps that depend on the NEW calls.
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Wed, 22 Nov 2000 00:16:39 -0600
"Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > Since C++ includes the majority of the C language, writing code that
> > compiles under a c++ compiler *IS* c++, even if it also might be C.
There
> > are some subtle difference between the same program compiled under C and
C++
> > though.
> >
> OK, So why should I call it C++ if it is only C?
It's not only C. It's also C++. For instance, this code:
For instance, many of the same code constructs are identical between C, C++,
and Java. Does that mean Java code isn't Java code simply because it has
the same syntax?
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.nt.advocacy
Subject: Re: Linux 2.4 mired in delays as Compaq warns of lack of momentum
Date: Wed, 22 Nov 2000 06:17:50 GMT
"Chad Mulligan" <[EMAIL PROTECTED]> wrote in message
news:IKIS5.1542$[EMAIL PROTECTED]...
>
> > > Linux, ext2fs... the limit is built-in because the designers weren't
> > > smart enough to do what several other OSes have successfully been
> > > able to do.
> >
> > You mean Microsoft? The company that only sold systems
> > with 32 Meg DRIVE limits back when Linus came up with
> > the 2Gig file limit design?
>
> What year was that? I was using a DOS 3.2 that exceeded that limit in
1986.
It must have been an OEM version, probably Compaq's. Other
companies added the ability to have multiple partitions before
the stock MS version had them. I've forgotten the sordid details
of which long overdue feature was added to DOS in which decade.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Wed, 22 Nov 2000 00:22:09 -0600
"Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> I'm the one with the 8 figure contract. I only do this in case I can
> pass on something useful to someone else.
Ahh, which explains all your free time to spend posting on the net.
> >Do you save the temp files generated by the compiler
> > in the Temp directory as well? That's what these are. Hell, the temp
files
> > are even more relavant than the ones listed in the knowledge base
article
> > because the temp files are actually generated code, while the the
> > autogenerated files are things to do with Intellisense and the class
> > browser.
> >
> What can I say. The customer only permitted VC++ under those conditions.
> Besides, I can't do any trouble shooting/ modifications if the class
> browser isn't working. At least it becomes difficult..
No more difficult than doing it under Unix, using vi or emacs.
> > In other words, they have nothing to do with either the code generated,
or
> > the source code in any way. They're to do with the IDE as temp files.
> The project won't build without them. If a version 3.0 is released, then
> it is required to build a new version 3.0 with exactly the same code,
> i.e. diff returns no differences!
Completely false. The files you mention have *NOTHING* to do with the
compile process. Nothing. They have nothing to do with building. In fact,
executing a command line build without opening the IDE will see that these
files don't get created.
Why not try what you claim before saying it matter of factly. I tell you
what, you're doing your client a serious disservice, and you clearly don't
know what you're talking about.
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Wed, 22 Nov 2000 00:24:59 -0600
"Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > SourceSafe has nothing to do with CVS, nor was it designed by Microsoft.
> > They bought it from a company called OneTree about 5 years ago.
SourceSafe
> > also has a command line, but then you wouldn't know that because you're
such
> > an "expert".
> Used SourceSafe several times. Underneath it is CVS. It should be as
> good as CVS if you get by the GUI and crippled command line.
No, it doesn't. CVS and SourceSafe have nothing in common other than they
are both version control software. SourceSafe does *NOT* use CVS. Hell,
SourceSafe existed before CVS was a real program (CVS started as a bunch of
scripts wrapped around RCS).
All you're doing is proving how little you know, and how eager you are to
stick your foot in your mouth.
------------------------------
From: "Erik Funkenbusch" <[EMAIL PROTECTED]>
Subject: Re: OT: Could someone explain C++ phobia in Linux?
Date: Wed, 22 Nov 2000 00:27:18 -0600
"Russ Lyttle" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> > Where do you get that? printf is very much part of C++, if you think
> > otherwise, you are very very confused.
>
> Not really. Until recently you had to include <stdio.h>. Now it is
> <cstdio.h>. Why do you think the new name has the "c" prefix? It
> indicates that you are doing C style programming, not C++. This is,
> IMHO, a bad feature of C++. The mixing of C style with C++ style is nice
> for bringing up old C programmers, but it makes for bad code on real
> projects.
Oh gee. More of that patented Russ Lyttle knowledge. Hint: It's not
<cstdio.h>, it's <cstdio> (no .h).
If you had even a passing knowledge of your job, you'd konw that, but you
don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: new site
Date: Wed, 22 Nov 2000 06:22:18 GMT
Sid Bite´s Underground Portal [SBUP]
Is a gateway to the underground www. Trough SBUP you can find: serials,
keygens, cracks, hacking, phreaking, virii, trainers, warez, exploits,
porn and more!
Http://www.sidbites.com
Http://sbup.da.ru
Http://welcome.to/sidbites
Http://sbup.cjb.net
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Christopher Smith" <[EMAIL PROTECTED]>
Crossposted-To:
alt.destroy.microsoft,comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: The Sixth Sense
Date: Wed, 22 Nov 2000 16:35:28 +1000
"T. Max Devlin" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> Said Christopher Smith in alt.destroy.microsoft;
> [...]
> >A shortcut is, to all intents and purposes, a symlink to a shell object.
>
> A more grossly inaccurate, yet broad sweeping, statement of the issue I
> doubt we will ever be privileged to view.
Yet, as usual, a statement you either cannot or will not refute.
------------------------------
From: sfcybear <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Wed, 22 Nov 2000 06:27:05 GMT
In article <ZvsS5.406$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> sfcybear writes:
>
> >>> That still leaves the FACT that NT uptime clocks are only acurate
> >>> for 49.7 days while Unix clocks are 10 times more acurate than
that.
> >>> remaining accurate for 497 days.
>
> >> You're confusing range with accuracy. Both clocks could be equally
> >> accurate. Range usually comes at the expense of precision. That
is,
> >> the same number of bits can provide a greater range if the
precision
> >> is reduced.
>
> > So? Does it change anything?
>
> Yes. It changes your claim that it's a "fact" than UNIX clocks are
> 10 times more accurate than that.
It does not change the fack that NT only reflects the correct uptime for
only 49 days Thus it is only accurate for a period of 49 days. Linux
Unix is correct 497 days. Thus Linux is accurate for 497 days. Since we
are mesuring time, the amount of time that the clock is accurate IS what
is most important. Your silly little word games does NOTHING to chang
the fact that the NT uptime clock is Useless.
>
> > NT uptime clock croaks at 49 days
>
> Irrelevant, given that the issue I was addressing was the one of
> the alleged "10 times more accurate".
>
For TIME mesurements, the linux clock will give accurate time for ten
times the time period of NT. There you happy? For all your BS, the NT
clock is still worthless.
> > even with your word games.
>
> What alleged word games?
The discution was about the NT clock which is still worthless, still
only works for 49 days vs the 497 days of a Unix clock. Nothing you have
said changes the fundemental facts, just the terms used, so yes word
games.
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: sfcybear <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Wed, 22 Nov 2000 06:36:22 GMT
In article <JpGS5.604$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Aaron R. Kulkis writes:
>
> >> sfcybear writes:
>
> >>>>> That still leaves the FACT that NT uptime clocks are only
acurate
> >>>>> for 49.7 days while Unix clocks are 10 times more acurate than
that.
> >>>>> remaining accurate for 497 days.
>
> >>>> You're confusing range with accuracy. Both clocks could be
equally
> >>>> accurate. Range usually comes at the expense of precision. That
is,
> >>>> the same number of bits can provide a greater range if the
precision
> >>>> is reduced.
>
> >>> So? Does it change anything?
>
> >> Yes. It changes your claim that it's a "fact" than UNIX clocks are
> >> 10 times more accurate than that.
>
> >>> NT uptime clock croaks at 49 days
>
> >> Irrelevant, given that the issue I was addressing was the one of
> >> the alleged "10 times more accurate".
>
> > What benifit is derived by gaining uptime precision to fractions
> > of a second, at the cost of the upper limit being 49 days rather
> > than 497 days?
>
> Irrelevant, given that the issue I was addressing was the one of
> the alleged "10 times more accurate".
Irrelevant, given that the disscution was really about the usefulness
for the NT clock, arguing over the semantics is a wast of time. I was in
error I should have said
Linux and Unix report an accurate uptime value for 10 times the length
of time that NT does. This makes the Linux and Unix clocks much more
usefull for keeping track of uptimes. In terms of usefulness the
accuracy over a 49 day time frame is vertualy worthless when compared to
being accurate uptime reporting over the time span of 497 days like unix
and Linux. All your game playing changes nothing of substance.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: sfcybear <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Wed, 22 Nov 2000 06:48:22 GMT
With you anal attitude toward language, I'll bet your a dud at parties.
Still nothing has changed. the NT uptime clock is virtualy worthless.
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: sfcybear <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Wed, 22 Nov 2000 06:45:14 GMT
In article <XnGS5.603$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> Giuliano Colla writes:
>
> >>>>>> sfcybear writes:
>
> >>>>>>> That still leaves the FACT that NT uptime clocks are only
acurate for
> >>>>>>> 49.7 days while Unix clocks are 10 times more acurate than
that.
> >>>>>>> remaining accurate for 497 days.
>
> >>>>>> You're confusing range with accuracy. Both clocks could be
equally
> >>>>>> accurate. Range usually comes at the expense of precision.
That is,
> >>>>>> the same number of bits can provide a greater range if the
precision
> >>>>>> is reduced.
>
> >>>>> Maybe the terms he used aren't exact.
>
> >>>> You're not sure?
>
> >>> It depends wether you're speaking of clock accuracy (which is a
hardware
> >>> issue, not OS related, and therefore off topic), or of uptime
estimate
> >>> accuracy.
>
> >> Which do think fits into the context of the discussion, and how
does
> >> your "depends" matter?
>
> > Clock accuracy of course has nothing to do with the context
> > of the discussion, but uptime estimate accuracy has to do.
> > That's what he was speaking of.
>
> That's what I'm speaking of.
>
> > If you're out of range you've lost all accuracy.
>
> Which can happen to both. So, how does that make one "10 time more
> accurate"?
>
> >>> Whenever uptime estimate is completely wrong you may well say that
> >>> accuracy of the measured value is not so good, even if clock
accuracy
> >>> comes from a caesium primary. In that case with Unix you have an
> >>> accurate measurements for a time 10 times longer than with NT.
>
> >> That's range, not accuracy.
>
> > The out of range error may be the reason to loose any
> > measurement accuracy. A reading of 2 instead of 51.7 is a
> > 2500% error. How do you define accuracy? Something like the
> > difference between actual and measured value, divided by
> > actual value, or something different?
>
> You're talking about relative accuracy, which can differ from
> absolute accuracy. However, I'm simply interested in finding out
> how one can be "10 times more accurate".
OK Then let's chage it to: The accuracy range for reporting Uptimes is
10 times longer with Unix than with NT. Of course, the 49 day uptime
period may well be all that is needed with NT. It is quite obvious that
even 497 days is NOT a good enough range for Linux.
Nothing of any substance is really changed by you objections to the
wording. The NT uptime clock is still vertualy worthless.
>
> >>>>> But if someone comes to your home to measure the floor in order
to
> >>>>> deliver you the wall to wall carpet,
>
> >>>> That's a matter of fitting some material into a space. Rather
different
> >>>> from an uptime measurement, which is open-ended.
>
> >>> That's an abstract notion.
>
> >> Not at all.
>
> Note: no response.
>
> >>> Any value may be open ended.
>
> >> Incorrect; consider the amount of carpeting example.
>
> > What will be the upper limit? The average room or the
> > Versailles castle ballroom? Or carpeting the fifth avenue to
> > give it a Christmas look? You see, it's not so obvious, even
> > if you're just selling carpets.
>
> On the contrary, it is quite obvious, given that the surface
> area of the Earth is a very good upper limit.
>
> > However what do you suggest for uptime? 64 bits with 1
> > second resolution gives a range of 50 billion years (roughly
> > the Universe age). Following what you say it's not
> > appropriate because it's not open-ended!
>
> I'm not trying to suggest what anyone should use for uptime. I'm
> simply trying to find out how one can be "10 times more accurate".
>
> >>> Writing a program you must decide what will be your upper limit,
and
> >>> reserve space accordingly. If your decision is wrong, then you've
made
> >>> a silly mistake.
>
> >> No program writing is involved in computing the amount of carpeting
> >> needed.
>
> > Off topic, but have you ever heard about architecture
> > programs, used to design interiors?
>
> Non sequitur, as you just admitted.
>
> >>>>> and does it with a micrometric gauge, providing .1 mil accuracy,
but
> >>>>> spanning only 3 inches, you'd call him an idiot, wouldn't you?
>
> >>>> He isn't the one who chose the poor analogy.
>
> >>> Maybe you don't grasp it,
>
> >> Maybe I did grasp it.
>
> Note: no response.
>
> >>> but if you select a word size and a time resolution, you set your
> >>> upper limit.
>
> >> If you had bothered to read what I wrote, you would realize that I
> >> already grasped it:
> >>
> >> DT] Range usually comes at the expense of precision. That is, the
same
> >> DT] number of bits can provide a greater range if the precision is
reduced.
> >>
> >> Note that the correct word is now precision, not accuracy.
>
> Note: no response.
>
> >>> If the choice is poor you end up exactly like that. Using
milliseconds
> >>> to measure uptime isn't much smarter than using a gauge to measure
a
> >>> floor.
>
> >> If uptime is the only thing being measured with that choice, then
you
> >> would have a point. You don't suppose they're using that same
value
> >> for something else, do you?
>
> > If they use something not appropriate for uptime, then
> > they're making the same mistake of the gauge. The man
> > measuring the floor could have a gauge in his pocket for
> > other purposes, but it's not appropriate for measuring the
> > floor.
>
> Tape measures can be used to measure carpeting needs as well as the
> size of curtains. Imagine that, another purpose.
>
> > Do you believe that a second counter, with an appropriate
> > resolution would have been such a task to endanger system
> > performance? Or a few instructions to handle overflow of the
> > millisecond counter would have been dangerous?
>
> What limited imagination you have. Are the only other uses you can
> imagine ones that endager system performance?
>
> > Unix had a 10 ms counter, and they judged that a range of
> > over one year and a half was enough, so they didn't bother.
> > MS roughly 30 years later had a 1 ms counter and didn't
> > bother either. Judging apparently that a range of one month
> > and a half was enough.
>
> How does that make one "10 times more accurate"? You're still
> avoiding the issue that I originally addressed.
>
> >>> If you think differently I'll address elsewhere whenever in need
> >>> a) to measure my floor, b) to measure uptime.
>
> >> Be sure to write a program to handle (a), with appropriate upper
limits.
>
> > Whenever in need I'll do it. But you may be sure that
> > existing interior design programs are using appropriate
> > upper limits: the feature is visible, competition is present
> > and if they made it as crappy as MS, they wouldn't survive
> > for long time.
>
> How does that make one "10 times more accurate"?
>
>
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Les Mikesell" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.ms-windows.advocacy,comp.os.ms-windows.nt.advocacy
Subject: Re: Of course, there is a down side...
Date: Wed, 22 Nov 2000 07:06:16 GMT
"Mike Byrns" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> >
> > Isn't this what's become known as 'DLL Hell', considered to be a major
> > issue with windows?
> >
> > Mark
>
> The newer libs support the old calls even if they have to map them. The
problem is
> that 3rd-party installers have historically replaced NEWER DLLs to suit
their own
> needs thus breaking apps that depend on the NEW calls.
And the historical reason that 3rd party apps had to overwrite these
DLLS would be?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: "Frank Van Damme" <[EMAIL PROTECTED]>
Subject: Re: Another happy Linux user
Date: Wed, 22 Nov 2000 08:21:52 +0100
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> The truth can sometimes be painful Frank.
>
> BTW why didn't any of you Penguinista's complain when Jaques"le-foot"
> the bare foot pirate (a linonut par excellance) kept posting Windows
> user troubles for me to fix. Which I did.
>
> claire
The only thing I want to say is: we aren't getting any further this way.
All this 'discussions' would have had a point if we just renamed this ng
to comp.os.linux+windows.hardware or something. Just collecting
individual OS horror stories doesn't make a point. We all know that
computers are a little more complex than, say, a hair drier or a lawn
mower. One can allmost impossibly predict what a given combination of
hardware and software will be. Why I switched to Linux is (well
switched, I still dual boot, but I'm passing 90% of my time in Linux):
1/ My windows always crashed, though I know people whose Windows rarely
crashes
2/ There were frequently bugs in Windows software, especially msoffice
3/ I wanted to try something new, and the Linux approach of OSS
interested me. I also heard people saying Linux was more stable,
reliable, etc. etc. then Windows.
So I gave it try ans I'm pretty happy with it. If you're happy with
Windows, ok for me. You draw our attention to cases of Linux hardware
trouble? Annoying and useless. We draw your attention blabla Windows
hardware trouble? Ditto.
------------------------------
From: "Aaron R. Kulkis" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.os2.advocacy,alt.destroy.microsoft
Subject: Re: Uptime -- where is NT?
Date: Wed, 22 Nov 2000 02:19:23 -0500
The Ghost In The Machine wrote:
>
> In comp.os.linux.advocacy, Erik Funkenbusch
> <[EMAIL PROTECTED]>
> wrote
> on Tue, 21 Nov 2000 04:07:00 -0600
> <ENrS5.9449$[EMAIL PROTECTED]>:
> >"sfcybear" <[EMAIL PROTECTED]> wrote in message
> >news:8vcn0b$gr4$[EMAIL PROTECTED]...
> >> Hardly Identical. NT is acurate for 49 days, Linux/Unix is accurate TEN
> >> TIMES LONGER! 497 days! This is better design. When looking at the TIME
> >> that Unix was designed, memory was VERY expensive (the reason that 2
> >> bits were used for the year giving us Y2K), Programers did not program
> >> with large variables and computers were much less reliable, 497 days was
> >> a VERY reasonable number and shows a well thought out choice! When NT
> >> was being designed memory prices were far lower and it was not uncommon
> >> for computers to be up MUCH longer than 49 days. 49 day was a very poor
> >> choice, and is an example the LACK of thought in programing that drove
> >> me away from MS
> >
> >You are completly clueless Matt.
> >
> >No Unix system that I know of suffered from Y2k in the way you mention.
> >Unix has never used two digits for years (digits, not bits as you claim) in
> >any way except for textual printout (on screen or printer or text file).
> >All date and time variables are stored internally in a "seconds from" some
> >day (usually Jan 1, 1970, IIRC). The only Y2k issues Unix had were when
> >dates were stored in textual form, or when they were printed or read, not
> >when they were stored in binary form.
>
> Pedant point: the tm structure (man localtime) has a tm_year structure,
> which prior to 2000 was basically the last two digits of the year.
> However, the documentation is very clear: tm_year = year - 1900,
> which means its value is now 100. At worst, this will result in
> the year '19100' being reported by programs that aren't clued in. :-)
>
> The *real* fun will begin just after the start of the year 2038... :-)
Provided you are using the the following equation:
#define TM_YEAR_BASE 1900
year = tm_year + TM_YEAR_BASE;
Then all you need to do is recompile.
> hopefully by then we'll all be using 64-bit time_t values.
> Or maybe we'll all be smart and use the VMS quadword (long long) value,
> which, IIRC, started at Nov 17, 1858 midnight UTC, incremented every
> microsecond, and won't have a problem with time for about
> 290,979 years... :-)
>
> By that time we'll probably have figured out how to create a new
> universe by simply thinking about it, or something. :-)
>
> --
> [EMAIL PROTECTED] -- insert random misquote here
--
Aaron R. Kulkis
Unix Systems Engineer
ICQ # 3056642
H: "Having found not one single carbon monoxide leak on the entire
premises, it is my belief, and Willard concurs, that the reason
you folks feel listless and disoriented is simply because
you are lazy, stupid people"
I: Loren Petrich's 2-week stubborn refusal to respond to the
challenge to describe even one philosophical difference
between himself and the communists demonstrates that, in fact,
Loren Petrich is a COMMUNIST ***hole
J: Other knee_jerk reactionaries: billh, david casey, redc1c4,
The retarded sisters: Raunchy (rauni) and Anencephielle (Enielle),
also known as old hags who've hit the wall....
A: The wise man is mocked by fools.
B: Jet Silverman plays the fool and spews out nonsense as a
method of sidetracking discussions which are headed in a
direction that she doesn't like.
C: Jet Silverman claims to have killfiled me.
D: Jet Silverman now follows me from newgroup to newsgroup
...despite (C) above.
E: Jet is not worthy of the time to compose a response until
her behavior improves.
F: Unit_4's "Kook hunt" reminds me of "Jimmy Baker's" harangues against
adultery while concurrently committing adultery with Tammy Hahn.
G: Knackos...you're a retard.
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.advocacy) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Advocacy Digest
******************************
