In <000201bf57ef$c9f24000$021d85d1@youwant.to> David Schwartz (davids@webmaster.com) wrote:
>> On 5 Jan 00, at 15:37, Bill Wendling wrote:
>> I realize that CPUs are speeding up at an amazing rate, but being
>> in the semiconductor industry, I know that the technology is
>> reaching a minimun size because we are approaching atomic
>> dimensions. Since speed is not only about power, but how far you
>> have to go, an essential factor in increasing speed is to decrease
>> the distance you have to go. Then add the fact that most
>> motherboards are essentialy a bunch of RF transmission lines, I
>> honestly don't see hardware speeding up much more. At 1 Ghz,
>> we are talking about waveguides, not wires.
> How many times do we need to hear this, see it proven wrong, and then hear
> it again. I remember when quantum affects were supposed to make it
> impossible to produce chips with features below .35 microns. I remember
> seeing a 'proof' that no modem running over normal telephone lines could
> exceed about 12,000 bps.
And it was not THAT far from true. My 4 years old Courier V.Everything is still
fastest modem for normal telephone line (it was upgraded to 56Kbit, of course,
but it was done with program change, not with any physical changes in it).
> I don't know how these problems will be solved or they would already be
> solved. But they will be.
They will not be. Of course we'll see some more speedup (may be even 10GHz
but I doubt even it) but not that much. Not much enough to make usage of
64 Itanium deriviation affordable for toaster at least :-)
>> The argument that we won't have to deal with it in xx years sure
>> sounds like the same one that got us into Y2K in the first place.
>> They say oh, but this is different because.....I don't know that I buy
>> into that. It seems to me it is more an issue that 'we have too
>> many other problems, and maybe that one will go away before we
>> have to deal with it'.
> No, it is being recognized and dealt with. We already have the tools to
> make our application source code Y2.038K compliant and should be using them.
> That then leaves the task of fixing the operating systems and system
> libraries. Those tasks are also proceeding on a very reasonable schedule.
It fact what should be changed is NOT kernel but glibc. 99.9% of programs do
not call kernel directly. Even if fix for Y2.038K will be added to kernel in
Y2.035K it'll be problem but not such a big problem if all programs will be
ready... So it's more like glibc's problem then kernel problem right now.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jan 07 2000 - 21:00:05 EST