What ever happened to conservation of matter? No resources are really "gobbled up". The resource that is really gobbled up is usable energy. Per the second law of thermodynamics everything we do turns a certain amount of usable energy into waste heat.
If we had an unlimited supply of high quality energy we could rearrange atoms and possiblly even subatomic particles to produce almost anything we wanted. We could easilly extract C02 from the air and turn it into fuel. We could easilly pump insane ammounts of seawater or trash through processing to get at trace ammounts of a valuable resource and so on. Fusion may be sufficient if we ever get it working well. I can't see any other technology on the horizon that will come close.
Until and unless that happens a lot of resources will be effectively limited to once through, especially if the end users of those resources can't or won't seperate them out of thier trash.
The i3's, i5's, and i7's are 32nm Do you have a source for that claim?
All the sources i've seen say the quad core i series chips are 45nm while the dual and six core i series chips are 32nm. Afaict the only 32nm "quad core" PC processors are some xeons that are based on a six or eight core design with some cores disabled.
AMD still handily beats Intel on performance per dollar.. the only metric I know of to compare performance numbers against. You keep saying this as if you think it's a victory for AMD. Selling equivalent products cheaper than the Intel is only a victory if AMD can actually make them cheaper than Intel. I see no evidence that this is the case.
tel has been running a smaller 32nm process/die size in order to beat AMD in performance Afaict all of intels desktop quad core chips are still on 45nm and are still beating the hell out of AMDs chips in indivdual core performance..
The AMD 6 core may be interesting for some niches but for desktop use performance in single threaded tasks is still very important.
Interestingly when intel stepped down the process size it didn't impact thier performance per core much it just let them cram an extra couple of cores in the same thermal envolope.
only a few of those 32nm chips designs have achieved price/performance parity while the rest are grossly below the curve.
So what?
Intel can charge a little more for equivalent chips because they have better band recognition. They can charge a shitload for thier best chips because those chips have no real competition (the only other way to get a PC with that kind of performance is to go dual socket and that can get expensive fast plus dual socket boxes tend to be noisy).
What matters for AMDs future is how much profit they (and globalfoundries) can make on each chip and whether that profit is sufficiant to fund continuing development and keep their performance in the same ballpark as intel. Having to sell their best processors at a third of the price intel sells their best processors for isn't exactly going to be good for the bottom line.
AMD is about to put its own 32nm process into production chips, so at the very least the very top end will not be Intel-only land anymore. IMO that really depends if AMD can push up single threaded performace (either by raising clockspeeds or by improving instructions per clock) as part of that transition or not. If not they will continue to lose badly on desktop tests.
And you can't tell with your hands (unless you are a master of negative braille, and the connectors are not particularly recessed) which way the connector goes, so you have to look at what you're doing my general technique with dins and mini dins is to rotate them while gently trying to insert them until they line up and go in.
Also a lot of mini din connectors have a large flat on them which makes getting them in the right way round easier.
The real question is will Intel put USB 3 in thier chipsets and if so when. Most PC processors are made by intel and current generation intel processors have to be paired with an intel chipset.
Afaict most chipsets have at least four SATA ports but most laptops only have two SATA devices so the only costs to replacing one of the USB ports with a USB+eSATA are a slightly more expensive connector and a few more tracks to route.
Contrast that to USB3 which currently needs a dedicated controller chip fed off a dedicated PCIe lane.
My understanding was the superspeed A plug was designed such that if you plugged it into a normal A socket the superspeed pins would not connect to anything and the low/full/high pins would connect as normal.
Laptops (especially the smaller ones) often have very limited locations that are suitable for placing ports so there is motivation to make the connectors flexible. Witness the USB2+eSATA ports that are now common on laptops, would companies have been so willing to add eSATA if it meant sacrificing a USB port to make space? I doubt it.
USB 1 and 2 worked on the principle of having the host adjust to the devices needs. This has worked out well since on a large fast chip (like a southbridge) it's not really going to make much difference to cost whether all the USB ports can run at high speed or only a subset of them.
USB3 is essentially two interfaces down the same port, the old USB interface is still there for slower devices and the new superspeed interface is there for faster stuff. Superspeed perhipherals will need to be able to fall back to high speed but I doubt the extra couple of pins to do that will add any significant cost to the chip designs.
SATA, meanwhile, has port multipliers available for it that behave in a manner similar to a USB hub. But with a few differences
1: Not all controllers support them 2: You can only have one in the path to a drive (so you couldn't for example have a multiplier in a standalone box feeding one in a multi drive enclosure 3: I've never seen one for sale in a seperate box, they all seem designed for mounting inside drive enclosures.
Another thing is that many machines are running thier SATA ports (and while on some motherboards there is a dedicated controller for the ESATA ports it's often just a spare port on the chipset SATA controller) in IDE mode to make setting up windows easier but afaict this disables any hotplugging and port multiplier support.
You're way way off-base here. The "integrated" audio chips and network "cards" you're talking about are still (and always were) discrete, they were just soldered onto the motherboard instead of stuck into a slot. Depends on the generation.
With audio Intel introduced a system called AC97 (later replaced by HDA which is similar in concept but supports higher data rates). There is still a dedicated chip (called the codec) to handle the final A/D and D/A conversion because analog stuff and high speed digital stuff don't mix well but any preproccessing and buffering of the data is either done by the southbridge or done in software.
A similar thing is happening with network though it only started recently and a lot of machines are still on the market that use PCIe or PCI network chips.
it seems unlikely that you'll ever have a high-TDP CPU and a high-TDP GPU (i.e. high-performance) sharing the same hunk of silicon. It doesn't make sense. Notice how the CPU vendors essentially ran out of ways to make CPU cores faster a while back so they started shoving more than one of them on a die. If they can get 6 cores on a die now without sacrificing much performance per core over thier quad cores then I really don't see why four decent CPU cores and a reasonable (not top of the line but good enough to play most games on moderate settings) should be a problem from a power POV.
The amount of stuff you can cram on a single chip is smaller than the amount of stuff you can cram on two chips, and chips that are twice as big are twice as likely to have catastrophic production flaws. That is true, however interconnecting chips at high speed is also expensive and if you use a relatively low speed interface like PCIe then you end up needing to have seperate memory for the CPU and GPU.
Putting more cores in desktops is getting fairly pointless because most desktop apps aren't all that paralell and trying to make individual cores perform better by making them more complex seems to be hitting dead ends too. This suggests that at least on the lower end chips there should be transistor count and heat budget spare to add integrated graphics.
The thing with lotteries is that the infrequent but large prizes give you a plausable reason for ending up with a large ammount of money coming out despite your inability to show a large ammount going in.
remember ps/2 mouse/keyboard ports? Well they didn't blow up, they just didn't tend to work due to the controller manufacturers being too lazy to make them work either way round (and yes it is possible to detect the difference, laptops did it for years).
RS-232 and PC printer ports used the same connectors but the PC ends had opposite genders so you'd have to go pretty out of your way to hook things up wrong with those.
So really unless you are using special stuff (e.g. external SCSI with it's myriad of conenctor some of which are shared with other stuff or data aquisition cards which tend to use whatever connector they can get enough pins out on) it's been pretty hard to make any really bad mixups with external PC connectors for a long time.
Internal PC connectors on the other hand often seem to be plain pin headers, usually withotu even any polarisation keys and often with the need to plug many small connectors onto. Still it's not as bad as it used to be where you had to plug in two power connectors of the same type next to each other and if you got them the wrong way round it almost certainly meant a fried motherboard.
AMD just came out with Six-Core processors for $200 [slashdot.org], how is that stagnant? Intel's only 6-core processor is still $1000 [google.com] And WHY are they selling 6-core processors so cheap? it's because their quad core processors can't keep up with intels so they are trying to make up for poor performance per core with higher core count.
Trouble is for desktop applications going from 4-core to 6-core is only of marginal benefit.
Itanium, anyone? Yes some time ago intel was screwing arround with itanium (which hardly anyone wanted because it ran x86 code so badly) and netburst (which was slower per clock than a P3) while AMD was pushing ahead with the hammer architecture.
However since core 2 and especially with nahelm (where intel moved to a point-point architecture from a shared FSB architecture) intel has gradually regained the lead starting with the single sockets and gradually moving up to larger platforms. AMD is resorting to throwing cores at the problem in a desperate effort to make up for thier poor performance per core but the trouble is that typical desktop workloads can't really load up four cores, let alone six.
The fundamental problem as I understand it is that operating systems (at least *nix and windows) use time formats that either can't represent leap seconds (because they count time intervals exluding leap seconds since some EPOCH) or could theoretically represent them but don't (see for example the documentation of "SYSTEMTIME" on windows that clearly states valid values for the seconds field as 0-59).
So applications end up seeing a leap second as a jump backwards in time as the fractions of a second tick roll over but the seconds don't advance. Jumps backwards in time have a number of problematic affects.
1: time differences calculated spanning the leap second are inaccurate. 2: short time differences arround can come out negative which can crash some software (ideally short time differences should be calculated from a seperate monotonic clock to avoid this but that can be difficult to do in practice since the monotonic clock on windows wraps annoyingly often and there doesn't seem to be a standard way to get a monotonic clock on *nix). 3: timestamps no longer correctly document the order in which things happened (this can be particularlly important for software like databases).
Time-keeping and even leap-seconds are covered as far back as the frickin' K&R*. A sibling mentioned the ancient (and for some odd reason still dreaded) calendar and timer exercises that a huge chunk of CompSci students have had to face. It's not like leap seconds are some sort of big and sudden surprise that just popped up in the last couple years (now their implementation schedule seems to be, but still...) The thing is before the days of global clock synchronisation systems becoming popular (which in turn had to wait for the internet to become popular) leap seconds weren't really a concern for OS designers. Local clock drift was far more significant as a source of error and in any case there wouldn't have been any way to distribute the leap second updates (descisions on leap seconds are not made very far in advance). Many systems out there today STILL don't have thier clocks synchronised well enough that leap seconds matter.
The two main operating system designs we use today (windows and *NIX) date back to this period and so thier time formats simply can't represent leap seconds correctly. NTP provides a warning of a leap second but there doesn't seem to be any mechanism for passing that data on to applications (or at least if there is it's poorly documented, i've certainly never seen any mention of such a thing when reading the documentation of the time fuctions on either windows or linux).
So as application programmers our real choices are either to ignore leap seconds and just make our programs tolerant of time jumps or to implement a complex system for handling leap seconds in spite of what the OS is doing.
I don't see it making life harder for most people - the only people it would be harder for is programmers involved in timekeeping, for whom understanding the leap second is a part of their job. The problem is even if we do understand the leap second afaict our operating systems don't.
Unix time simply cannot represent 23:59:60 . Windows has a couple of time formats. "SYSTEMTIME" could in thery represent 23:59:60 but the documentation on valid values specifically says that it isn't a valid value. Filetime has much the same problem as unix time.
Clocks should strive to give the most accurate measurement The most accurate measurement of what though? elapsed time or time of day?
The underlying issue is that we use "civil time" for both measuring elapsed time and measuring time of day but when high accuracy is required the two start to become incompatible. Further it's rather difficult to directly and accurately measure time of day.
UTC therefore represents a comprimise, it's based on "atom time" but adjusted to match earth time. Thw powers that be decided to do this by inserting or removing seconds but I don't see how adjusting the clock rate for a while is any worse a soloution.
A further problem is that many common time formats can't represent all valid UTC times. There is simply no way to represent a leap second in unix time.
The solution exists, it's TAI. You use TAI internally and convert to UTC (or your TZ) when displaying, similar to unix time. The big problem is that leap seconds aren't predictable so it's not possible to convert accurately between TAI and UTC for a time in the future nor is it possible for a system that isn't receiving updates to the conversion table to covert accurately for past/current time.
It follows that if a time is repeatedly converted between TAI and UTC by systems in different states of updating (as could easilly happen in a situation where a gradual migration from UTC to TAI is in progress) there could be some rather nasty error buildups. Much the same problem applies with DST but at least most developed countries tend to keep thier DST rules pretty consistent.
it will reduce it but consider for example the case of a user that puts everything they get from the internet into a downloads directory and doesn't bother renaming stuff on download unless there is a name conflict. Somehow the user is tricked into downloading the dll.
Sometime later they download a mp3, open it in itunes and get exploited.
After all, what were the end results of Sun v. Microsoft? The end result was that MS abandoned JAVA and developed it's own replacement. They even provided a tool for converting your JAVA code to run on.net.
EVEN if error correction works as you describe (and it doesn't, you are thinking network error corrections) then a crappy cable would REMAIN crappy ALL the time and therefor the corrections would also fail and you would never get any data ever. Depends just how crappy the cable is, it's perfectly possible for a cable to be just about good enough to pass signals intact most of the time but have the occasional bit fail due to either random noise or external interference (particularlly impulse interference). It's the same reason pictures break up sometimes on digital TV, mostly the channel is good enough to get the data through but occasionally there is a burst of intereference that makes the bit error rate too high for the error correction to handle.
I remember a while back someone I knew made an ethernet cable with wrong pairing. At 100 megabit small packets like pings would usually get through but large packets virtually never did because as the packets got bigger the chances of them being hit by a bit error also got bigger.
P.S. I agree that the articles claims are bunk, i'm just notpicking here.
Slashdot Mirror
What ever happened to conservation of matter? No resources are really "gobbled up".
The resource that is really gobbled up is usable energy. Per the second law of thermodynamics everything we do turns a certain amount of usable energy into waste heat.
If we had an unlimited supply of high quality energy we could rearrange atoms and possiblly even subatomic particles to produce almost anything we wanted. We could easilly extract C02 from the air and turn it into fuel. We could easilly pump insane ammounts of seawater or trash through processing to get at trace ammounts of a valuable resource and so on. Fusion may be sufficient if we ever get it working well. I can't see any other technology on the horizon that will come close.
Until and unless that happens a lot of resources will be effectively limited to once through, especially if the end users of those resources can't or won't seperate them out of thier trash.
The i3's, i5's, and i7's are 32nm
Do you have a source for that claim?
All the sources i've seen say the quad core i series chips are 45nm while the dual and six core i series chips are 32nm. Afaict the only 32nm "quad core" PC processors are some xeons that are based on a six or eight core design with some cores disabled.
AMD still handily beats Intel on performance per dollar.. the only metric I know of to compare performance numbers against.
You keep saying this as if you think it's a victory for AMD. Selling equivalent products cheaper than the Intel is only a victory if AMD can actually make them cheaper than Intel. I see no evidence that this is the case.
tel has been running a smaller 32nm process/die size in order to beat AMD in performance
Afaict all of intels desktop quad core chips are still on 45nm and are still beating the hell out of AMDs chips in indivdual core performance..
The AMD 6 core may be interesting for some niches but for desktop use performance in single threaded tasks is still very important.
Interestingly when intel stepped down the process size it didn't impact thier performance per core much it just let them cram an extra couple of cores in the same thermal envolope.
only a few of those 32nm chips designs have achieved price/performance parity while the rest are grossly below the curve.
So what?
Intel can charge a little more for equivalent chips because they have better band recognition. They can charge a shitload for thier best chips because those chips have no real competition (the only other way to get a PC with that kind of performance is to go dual socket and that can get expensive fast plus dual socket boxes tend to be noisy).
What matters for AMDs future is how much profit they (and globalfoundries) can make on each chip and whether that profit is sufficiant to fund continuing development and keep their performance in the same ballpark as intel. Having to sell their best processors at a third of the price intel sells their best processors for isn't exactly going to be good for the bottom line.
AMD is about to put its own 32nm process into production chips, so at the very least the very top end will not be Intel-only land anymore.
IMO that really depends if AMD can push up single threaded performace (either by raising clockspeeds or by improving instructions per clock) as part of that transition or not. If not they will continue to lose badly on desktop tests.
Do the CPUs actually work properly at those speeds though (where working properly is defined as passing something like the prime95 torture test)
Though IIRC they finally got arround to making the VCL unicode based in delphi 2010.
Afaict the propogation speed is determined by the relative permativity of the insulator.
http://en.wikipedia.org/wiki/Wave_propagation_speed#Calculating_velocity_factor
For a silicon dioxide insulator that would give a velocity of about half the speed of light.
I don't mean a flat on the mating part of the connector, I mean a flat on the plastic body.
http://media.digikey.com/photos/Assmann%20Photos/AK%20678-2.jpg
And you can't tell with your hands (unless you are a master of negative braille, and the connectors are not particularly recessed) which way the connector goes, so you have to look at what you're doing
my general technique with dins and mini dins is to rotate them while gently trying to insert them until they line up and go in.
Also a lot of mini din connectors have a large flat on them which makes getting them in the right way round easier.
The real question is will Intel put USB 3 in thier chipsets and if so when. Most PC processors are made by intel and current generation intel processors have to be paired with an intel chipset.
Afaict most chipsets have at least four SATA ports but most laptops only have two SATA devices so the only costs to replacing one of the USB ports with a USB+eSATA are a slightly more expensive connector and a few more tracks to route.
Contrast that to USB3 which currently needs a dedicated controller chip fed off a dedicated PCIe lane.
My understanding was the superspeed A plug was designed such that if you plugged it into a normal A socket the superspeed pins would not connect to anything and the low/full/high pins would connect as normal.
This isn't true of the B plug though.
Laptops (especially the smaller ones) often have very limited locations that are suitable for placing ports so there is motivation to make the connectors flexible. Witness the USB2+eSATA ports that are now common on laptops, would companies have been so willing to add eSATA if it meant sacrificing a USB port to make space? I doubt it.
USB 1 and 2 worked on the principle of having the host adjust to the devices needs. This has worked out well since on a large fast chip (like a southbridge) it's not really going to make much difference to cost whether all the USB ports can run at high speed or only a subset of them.
USB3 is essentially two interfaces down the same port, the old USB interface is still there for slower devices and the new superspeed interface is there for faster stuff. Superspeed perhipherals will need to be able to fall back to high speed but I doubt the extra couple of pins to do that will add any significant cost to the chip designs.
SATA, meanwhile, has port multipliers available for it that behave in a manner similar to a USB hub.
But with a few differences
1: Not all controllers support them
2: You can only have one in the path to a drive (so you couldn't for example have a multiplier in a standalone box feeding one in a multi drive enclosure
3: I've never seen one for sale in a seperate box, they all seem designed for mounting inside drive enclosures.
Another thing is that many machines are running thier SATA ports (and while on some motherboards there is a dedicated controller for the ESATA ports it's often just a spare port on the chipset SATA controller) in IDE mode to make setting up windows easier but afaict this disables any hotplugging and port multiplier support.
You're way way off-base here. The "integrated" audio chips and network "cards" you're talking about are still (and always were) discrete, they were just soldered onto the motherboard instead of stuck into a slot.
Depends on the generation.
With audio Intel introduced a system called AC97 (later replaced by HDA which is similar in concept but supports higher data rates). There is still a dedicated chip (called the codec) to handle the final A/D and D/A conversion because analog stuff and high speed digital stuff don't mix well but any preproccessing and buffering of the data is either done by the southbridge or done in software.
A similar thing is happening with network though it only started recently and a lot of machines are still on the market that use PCIe or PCI network chips.
it seems unlikely that you'll ever have a high-TDP CPU and a high-TDP GPU (i.e. high-performance) sharing the same hunk of silicon. It doesn't make sense.
Notice how the CPU vendors essentially ran out of ways to make CPU cores faster a while back so they started shoving more than one of them on a die. If they can get 6 cores on a die now without sacrificing much performance per core over thier quad cores then I really don't see why four decent CPU cores and a reasonable (not top of the line but good enough to play most games on moderate settings) should be a problem from a power POV.
The amount of stuff you can cram on a single chip is smaller than the amount of stuff you can cram on two chips, and chips that are twice as big are twice as likely to have catastrophic production flaws.
That is true, however interconnecting chips at high speed is also expensive and if you use a relatively low speed interface like PCIe then you end up needing to have seperate memory for the CPU and GPU.
Putting more cores in desktops is getting fairly pointless because most desktop apps aren't all that paralell and trying to make individual cores perform better by making them more complex seems to be hitting dead ends too. This suggests that at least on the lower end chips there should be transistor count and heat budget spare to add integrated graphics.
The thing with lotteries is that the infrequent but large prizes give you a plausable reason for ending up with a large ammount of money coming out despite your inability to show a large ammount going in.
remember ps/2 mouse/keyboard ports?
Well they didn't blow up, they just didn't tend to work due to the controller manufacturers being too lazy to make them work either way round (and yes it is possible to detect the difference, laptops did it for years).
RS-232 and PC printer ports used the same connectors but the PC ends had opposite genders so you'd have to go pretty out of your way to hook things up wrong with those.
So really unless you are using special stuff (e.g. external SCSI with it's myriad of conenctor some of which are shared with other stuff or data aquisition cards which tend to use whatever connector they can get enough pins out on) it's been pretty hard to make any really bad mixups with external PC connectors for a long time.
Internal PC connectors on the other hand often seem to be plain pin headers, usually withotu even any polarisation keys and often with the need to plug many small connectors onto. Still it's not as bad as it used to be where you had to plug in two power connectors of the same type next to each other and if you got them the wrong way round it almost certainly meant a fried motherboard.
AMD just came out with Six-Core processors for $200 [slashdot.org], how is that stagnant? Intel's only 6-core processor is still $1000 [google.com]
And WHY are they selling 6-core processors so cheap? it's because their quad core processors can't keep up with intels so they are trying to make up for poor performance per core with higher core count.
Trouble is for desktop applications going from 4-core to 6-core is only of marginal benefit.
Itanium, anyone?
Yes some time ago intel was screwing arround with itanium (which hardly anyone wanted because it ran x86 code so badly) and netburst (which was slower per clock than a P3) while AMD was pushing ahead with the hammer architecture.
However since core 2 and especially with nahelm (where intel moved to a point-point architecture from a shared FSB architecture) intel has gradually regained the lead starting with the single sockets and gradually moving up to larger platforms. AMD is resorting to throwing cores at the problem in a desperate effort to make up for thier poor performance per core but the trouble is that typical desktop workloads can't really load up four cores, let alone six.
The fundamental problem as I understand it is that operating systems (at least *nix and windows) use time formats that either can't represent leap seconds (because they count time intervals exluding leap seconds since some EPOCH) or could theoretically represent them but don't (see for example the documentation of "SYSTEMTIME" on windows that clearly states valid values for the seconds field as 0-59).
So applications end up seeing a leap second as a jump backwards in time as the fractions of a second tick roll over but the seconds don't advance. Jumps backwards in time have a number of problematic affects.
1: time differences calculated spanning the leap second are inaccurate.
2: short time differences arround can come out negative which can crash some software (ideally short time differences should be calculated from a seperate monotonic clock to avoid this but that can be difficult to do in practice since the monotonic clock on windows wraps annoyingly often and there doesn't seem to be a standard way to get a monotonic clock on *nix).
3: timestamps no longer correctly document the order in which things happened (this can be particularlly important for software like databases).
Time-keeping and even leap-seconds are covered as far back as the frickin' K&R*. A sibling mentioned the ancient (and for some odd reason still dreaded) calendar and timer exercises that a huge chunk of CompSci students have had to face. It's not like leap seconds are some sort of big and sudden surprise that just popped up in the last couple years (now their implementation schedule seems to be, but still...)
The thing is before the days of global clock synchronisation systems becoming popular (which in turn had to wait for the internet to become popular) leap seconds weren't really a concern for OS designers. Local clock drift was far more significant as a source of error and in any case there wouldn't have been any way to distribute the leap second updates (descisions on leap seconds are not made very far in advance). Many systems out there today STILL don't have thier clocks synchronised well enough that leap seconds matter.
The two main operating system designs we use today (windows and *NIX) date back to this period and so thier time formats simply can't represent leap seconds correctly. NTP provides a warning of a leap second but there doesn't seem to be any mechanism for passing that data on to applications (or at least if there is it's poorly documented, i've certainly never seen any mention of such a thing when reading the documentation of the time fuctions on either windows or linux).
So as application programmers our real choices are either to ignore leap seconds and just make our programs tolerant of time jumps or to implement a complex system for handling leap seconds in spite of what the OS is doing.
I don't see it making life harder for most people - the only people it would be harder for is programmers involved in timekeeping, for whom understanding the leap second is a part of their job.
The problem is even if we do understand the leap second afaict our operating systems don't.
Unix time simply cannot represent 23:59:60 . Windows has a couple of time formats. "SYSTEMTIME" could in thery represent 23:59:60 but the documentation on valid values specifically says that it isn't a valid value. Filetime has much the same problem as unix time.
Clocks should strive to give the most accurate measurement
The most accurate measurement of what though? elapsed time or time of day?
The underlying issue is that we use "civil time" for both measuring elapsed time and measuring time of day but when high accuracy is required the two start to become incompatible. Further it's rather difficult to directly and accurately measure time of day.
UTC therefore represents a comprimise, it's based on "atom time" but adjusted to match earth time. Thw powers that be decided to do this by inserting or removing seconds but I don't see how adjusting the clock rate for a while is any worse a soloution.
A further problem is that many common time formats can't represent all valid UTC times. There is simply no way to represent a leap second in unix time.
The solution exists, it's TAI. You use TAI internally and convert to UTC (or your TZ) when displaying, similar to unix time.
The big problem is that leap seconds aren't predictable so it's not possible to convert accurately between TAI and UTC for a time in the future nor is it possible for a system that isn't receiving updates to the conversion table to covert accurately for past/current time.
It follows that if a time is repeatedly converted between TAI and UTC by systems in different states of updating (as could easilly happen in a situation where a gradual migration from UTC to TAI is in progress) there could be some rather nasty error buildups. Much the same problem applies with DST but at least most developed countries tend to keep thier DST rules pretty consistent.
it will reduce it but consider for example the case of a user that puts everything they get from the internet into a downloads directory and doesn't bother renaming stuff on download unless there is a name conflict. Somehow the user is tricked into downloading the dll.
Sometime later they download a mp3, open it in itunes and get exploited.
After all, what were the end results of Sun v. Microsoft? .net.
The end result was that MS abandoned JAVA and developed it's own replacement. They even provided a tool for converting your JAVA code to run on
EVEN if error correction works as you describe (and it doesn't, you are thinking network error corrections) then a crappy cable would REMAIN crappy ALL the time and therefor the corrections would also fail and you would never get any data ever.
Depends just how crappy the cable is, it's perfectly possible for a cable to be just about good enough to pass signals intact most of the time but have the occasional bit fail due to either random noise or external interference (particularlly impulse interference). It's the same reason pictures break up sometimes on digital TV, mostly the channel is good enough to get the data through but occasionally there is a burst of intereference that makes the bit error rate too high for the error correction to handle.
I remember a while back someone I knew made an ethernet cable with wrong pairing. At 100 megabit small packets like pings would usually get through but large packets virtually never did because as the packets got bigger the chances of them being hit by a bit error also got bigger.
P.S. I agree that the articles claims are bunk, i'm just notpicking here.