Which CPU is actually fastest heavily depends on what you will be using it for. Your list of "regular geek activities" does not narrow it down enough. Also, many applications contain optimizations that target a particular CPU family or architecture.............. All CPU performance charts: http://www.tomshardware.co.uk/charts/processors,6.html [tomshardware.co.uk] I just picked a few of those at random and they were all topped by the "Intel Core i7-965 Extreme Edition (Bloomfield 4c) * 3.2 GHz, DDR3-1066, 1 MB L2, 8 MB L3"
Seems if raw performance is what you desire the i7 9xx stuff (with triple channel ddr3) is basically the top of the pile regardless of application category.
IPv6 remains the only viable answer if we want to keep growing the Internet. Having most machines on dual stack is pretty much a prerequisite to intoducing v6 only hosts nad yet as of right now only a handful of hosts are dual stack. Further most home routers dont' support IPv6 either. To think that this will get sorted in the next couple of years is frankly ludicrous.
The only viable answer now is to move end lusers behind NAT so thier IPs can be freed up for servers (and yes that will almost certainly mean price increases for those of us home users who want to retain a public IP).
Why didn't they just get someone to develop something and slap a name on it? They did slap the duke nukem name on third party stuff a couple of times, duke nukem time to kill and duke nuem manhatten project spring to mind.
It always appeared to me that the big problem with dnf was they really wanted it to be a ground breaking game but others kept overtaking them and so they kept rearchitecting the game over and over again.
Yeah, there won't ever be a good consumer HD video camera as long as they have to be portable Why would a digital camcorder need to be much bigger than a digitial stills camera of similar image quality?
Yes there are a lot of ipv6 addresses, however looking at the total size of a 128 bit address space is very misleading as ipv6 addresses are designed to be allocated in a more heirachical manner and designed to support stateless autoconfiguration for clients. Originally end sites were meant to be allocated a/48 though ripe now seems to be pushing for smaller allocations to smaller end sites.
Plus only 2::/3 is assigned to the ipv6 internet with other address space being reserved for other purposes.
Those figures would give us 2^45 end sites, this should be enough that we don't run out of addresses any time soon but it's a lot less than the ammount people assume from just looking at the number of bits in the IP.
why can't all little-visited domains be on virtual hosts and share their IP address with many others? Many can but as of right now if you want to use ssl/tls you pretty much need your own IP.
with ssl/tls the server does not have the http request at the time the connection is negotiated and certificates checked so it can't use the name from it to decide what certificate to present.
You can in principle have multiple domains on one certificate but it makes the certificate management far more of an administrative PITA (essentially the host would have to apply for a certificate on behalf of all the domains they host on an ip and get a new one every time a domain needed to be moved between machines)
There is a ssl/tls extention which tells the server which domain is being requested during the ssl handshake so it can send out different certificates for different domains. Unfortunately the built in ssl support in xp doesn't support it (both IE and chrome use the windows built in ssl support, firefox doesn't).
It's not meant to. Browser performance is not measured in 'average' CPU usage, but 'latency'. And in my experiance the biggest performance issue with firefox isn't really all that related to the CPU and the second biggest is only tangetically related to it.
The biggest problems are
1: firefox is a ram-hog, combine that with an OS that likes to swap out ram that hasn't been in use for a while to increase disk cache size or so (both windows and linux like to do this) and if you leave you browser unused for a while or run other ram hungry applications it will be extremely slow when you come back as it drags back in hundreds of megabytes from swap.
2: firefox is single threaded so if one window has some slow javascript running on a time (/. i'm looking at you) it can slow the whole browser down. Likewise if something is being swapped in (see above) ALL the browser windows grind to a halt.
Not as precious as it used to be but if you are still stuck on 32-bit desktop windows (for whatever reason) then you are limited to 4GB of address space (which generally translates somewhere between 2.5GB and 3.75GB of usable ram depending on what other hardware you have taking address space). Even if you are using a 64-bit OS your motherboard often puts fairly low limits on how much ram you can actually use.
And what is worse is that when something causes the browser to be swapped out and then you touch a window that hasn't been touched in a while it has to swap all that memory back in before the browser will respond again.
Re:I can certainly vouch for this.
on
Y2.01K
·
· Score: 1
there are plenty of ways to do it that are just as simple I'm not sure there are
Consider you have a system that stored it's data in old fasioned flat files with say a 2 digit BCD year, I see four possible fixes each with it's issues
1: move to a psuedo-bcd format that can represent numbers up to 150, existing data all remains valid and the system is good for 50 years BUT you will have to write your own arithmetic/conversion functions for psuedo-BSD and hunt down everywhere BCD arithmetic or conversion is used in the code and change it. 2: implement a system that redefines the date field such that numbers below a certain threshold are considered to be in 20xx, the problem then becomes chosing that threshold, too large and you risk breaking historical data, too small and you get breakage again after a relatively short period. 3: implement the above but with a sliding window based on the current date, at first this seems like a good idea but it could cause a lot of confusion when say 90 year old (if your window is 90 years in the past and 10 years in the future) data starts being interpreted as being in the future. Possibly this could be worse than a system that breaks for new data depending on how long it takes to realise that data is being misinterpreted 4: change the file format and either convert all existing data or implement a file format version detection system
4 is the only proper long term fix but depending on details of how the data is stored is likely to be very intrusive.
Afaict it's quite common for ATMs to refuse to return cards if they think something is wrong with them or think they are stolen.
I could easilly see it taking three or four people before they realised it was a more general problem.
And maybe some of these people had the problem at different ATMs (afaict most places have more ATM locations then bank branches) and/or different times (I dnunno if banks in germany open at the weekend or not, I'm pretty sure most of them don't here in the UK).
All in all for 12 people to be at a bank branch with the problem would not really require stupidity on the customers part.
or even, as of Jan 01 2010, the next Yes there will be minor date related problems all the time as some obscure date format reaches it's limit or some programmer made a stupid assumption but I expect 2038 to be the next major one.
Then we have a few major date formats expiring close together, 2100 (yes people still use 2 digit years), then unsigned 32 bit unix (used in some linux filesystems and also likely to be used in many systems as a quick fix for the 2038 bug) in 2106 and dos in 2107 (used in zipfiles and the fat filesystem among other places) most of us probablly won't live to see those problems though (and some of them may well be eliminated by the systems that use them falling out of use).
other than using english/american conventions. That is what it should do, file formats should NOT be localisation dependent. If they want to create a new format that follows some other languages conventions that's fine but they shouldn't call it csv.
How many hardware RTCs actually use unix time anyway? the last one I dealt with stored years (2 digit!), months, days, hours minuites and seconds (I think there may have been another field too for smaller time units, not sure offhand).
Besides hardware RTCs usually wrap in a sane way so you can postpone the bug or reduce it to a bug that only happens if the system is left turned off for insane lengths of time fairly easilly.
The difficult bit with the 2038 bug is dealing with things like file formats, network protocols, library binary interfaces etc.
Copy and paste that in and your done You shouldn't just copy and paste code in willy nilly anyway! that is what leads to cases like the recent "GPL code in MS software" incident.
What you should do is learn the facilities of the libraries available to you (most importantly your languages standard library) and make use of them. If they libraries you have available don't offer what you need then you need to weigh up the advantages of copying in code you didn't write (and may therefore have difficulty maintaining) vs adding a dependency vs reinventing the wheel.
Sadly as you say schools don't really teach this and even if they do people often end up picking up a new language very quickly without really ever learning it properly..
Depending on how important the development is and just how much the "large sums" are it's either similar to the reverse engineering case or a case of stupid penny pinching.
This means all that needs to be done for date calculations is a recompile. ROFLMAO
IF the programmers have been good and actually used time_t rather than just int* AND either they haven't used it across interfaces that need to remain binary compatible AND they haven't stored it in any files then it may be possible to fix it with some clever hacks in the standard library and headers followed by a recompile with a special flag to indicate that 64 bit versions of the time functions and a 64-bit time_t should be used.
Back in the real world I expect a lot of code will need cleaning up to deal with the above issues and some libraries will either need thier major version buping (indicating a backwards compatibilty break) or to introduce a dual version system as mentioned above for the standard libraries. Anywhere the numbers are conversted to/from a byte sequence (the disk files you mentioned but also things like network protocols) will also need attention (and for shared disk files it may be nessacery to do a staged upgrade first adding support for reading the new format and then enabling writing in the new format).
And then there is the issue that to get the OS level fixes you may need to upgrade the major version of your OS and/or move to the 64-bit version of your OS (64-bit linux already has the y2K38 issue fixed) with the huge potential can of worms that opens (particually if the version of the OS that you are running is out of support at the time the 2038 bug becomes a big deal)
And then there is the fact that some source code will simply be completely lost.
In some cases the only reasonable fix may be forklift upgrades.
In summary I don't expect it to be much worse than Y2K but I don't expect it to be much better either.
* changing int to 64-bit would be almost certain to do more harm than good.
Most of the programmers who will be working this bug haven't been born yet On what do you base this assertion?
Lets assume that a programmers career runs from about 21 to 65 , that work on the 2038 bug runs from 2033 to 2038 and that people at any stage in thier carrer are equally likely to be working on the bug (personally I suspect it will mostly be older programmers).
that would put the programemrs working on the bug as being born between 1968 and 2017 (there may be some off by one errors in this aritmetic, they shouldn't affect the point significantly). In other words most of them have already been born.
I suspect when the 2038 bug rolls around many of us slashdotters will be the old guys who can still program in C!
Using innocent and unsuspecting members of the public to do it though seems like a pretty fucked up thing to be doing and I hope whoevers idea this was gets punished appropriately.
If you are a goverment want to do a test of airport security systems then fine but use someone who has agreed to do it, agree it with the governments of target countries first and give that person ID so that they can prove that they are doing an official test.
On the other hand, my cousin ended up with almost no games on "white" Macbook. They told him "Black" one needed to play games. Guess what the White has? Intel GPU. Black, Nvidia. Either you are misremembering the story or the person who advised your cousin was wrong. The black macbook always had intel graphics as did thier contempory white models.
Maybe you were thinking of the brief period when the aluminium unibody macbook had nvidia graphics while the white macbook still had intel graphics.
Things don't seem much better on this side of the pond (personal experiance of UK and info picked up from friends in continental europe), most ISPs still don't offer ipv6 and those who do generally offer it through tunnels and don't make it obvious. Further most home routers don't support ipv6 either.
IMO things are already too late for IPV6 to be widely deployed before IPV4 addresses run-out*. When that happens I predict the next move will be for ISPs to claw back addresses from home users and bottom end hosting customers to allocate to more lucrative uses.
ISPs who have always had their low end customers natted and those who only do higher end stuff are likely to be SOL. Maybe they will become the ones who will drive ipv6 forward.
*That is normal allocations are no longer available from the rirs. Arin have chosen to keep some addresses back for special uses and other rirs may do the same and of course reallocations of addresses will happen either officiall or unofficially.
I think the bigger archives (university archives of PHD thesis, archives of major journals, NASAs archives etc) will be ok unless there is a huge paradigm shift or a major societial collapse. If pdf starts to lose favour as the format for distributing electronic documents I would expect these large archives to just convert thier documents en-masse to the new format.
Lots of other less important stuff will be lost of course but that has always happened.
Slashdot Mirror
Which CPU is actually fastest heavily depends on what you will be using it for. Your list of "regular geek activities" does not narrow it down enough. Also, many applications contain optimizations that target a particular CPU family or architecture. .............
All CPU performance charts: http://www.tomshardware.co.uk/charts/processors,6.html [tomshardware.co.uk]
I just picked a few of those at random and they were all topped by the "Intel Core i7-965 Extreme Edition (Bloomfield 4c) * 3.2 GHz, DDR3-1066, 1 MB L2, 8 MB L3"
Seems if raw performance is what you desire the i7 9xx stuff (with triple channel ddr3) is basically the top of the pile regardless of application category.
IPv6 remains the only viable answer if we want to keep growing the Internet.
Having most machines on dual stack is pretty much a prerequisite to intoducing v6 only hosts nad yet as of right now only a handful of hosts are dual stack. Further most home routers dont' support IPv6 either. To think that this will get sorted in the next couple of years is frankly ludicrous.
The only viable answer now is to move end lusers behind NAT so thier IPs can be freed up for servers (and yes that will almost certainly mean price increases for those of us home users who want to retain a public IP).
Why didn't they just get someone to develop something and slap a name on it?
They did slap the duke nukem name on third party stuff a couple of times, duke nukem time to kill and duke nuem manhatten project spring to mind.
It always appeared to me that the big problem with dnf was they really wanted it to be a ground breaking game but others kept overtaking them and so they kept rearchitecting the game over and over again.
Yeah, there won't ever be a good consumer HD video camera as long as they have to be portable
Why would a digital camcorder need to be much bigger than a digitial stills camera of similar image quality?
Just make your house into a faraday cage ;)
Yes there are a lot of ipv6 addresses, however looking at the total size of a 128 bit address space is very misleading as ipv6 addresses are designed to be allocated in a more heirachical manner and designed to support stateless autoconfiguration for clients. Originally end sites were meant to be allocated a /48 though ripe now seems to be pushing for smaller allocations to smaller end sites.
Plus only 2::/3 is assigned to the ipv6 internet with other address space being reserved for other purposes.
Those figures would give us 2^45 end sites, this should be enough that we don't run out of addresses any time soon but it's a lot less than the ammount people assume from just looking at the number of bits in the IP.
why can't all little-visited domains be on virtual hosts and share their IP address with many others?
Many can but as of right now if you want to use ssl/tls you pretty much need your own IP.
with ssl/tls the server does not have the http request at the time the connection is negotiated and certificates checked so it can't use the name from it to decide what certificate to present.
You can in principle have multiple domains on one certificate but it makes the certificate management far more of an administrative PITA (essentially the host would have to apply for a certificate on behalf of all the domains they host on an ip and get a new one every time a domain needed to be moved between machines)
There is a ssl/tls extention which tells the server which domain is being requested during the ssl handshake so it can send out different certificates for different domains. Unfortunately the built in ssl support in xp doesn't support it (both IE and chrome use the windows built in ssl support, firefox doesn't).
It's not meant to. Browser performance is not measured in 'average' CPU usage, but 'latency'.
And in my experiance the biggest performance issue with firefox isn't really all that related to the CPU and the second biggest is only tangetically related to it.
The biggest problems are
1: firefox is a ram-hog, combine that with an OS that likes to swap out ram that hasn't been in use for a while to increase disk cache size or so (both windows and linux like to do this) and if you leave you browser unused for a while or run other ram hungry applications it will be extremely slow when you come back as it drags back in hundreds of megabytes from swap.
2: firefox is single threaded so if one window has some slow javascript running on a time (/. i'm looking at you) it can slow the whole browser down. Likewise if something is being swapped in (see above) ALL the browser windows grind to a halt.
Not as precious as it used to be but if you are still stuck on 32-bit desktop windows (for whatever reason) then you are limited to 4GB of address space (which generally translates somewhere between 2.5GB and 3.75GB of usable ram depending on what other hardware you have taking address space). Even if you are using a 64-bit OS your motherboard often puts fairly low limits on how much ram you can actually use.
And what is worse is that when something causes the browser to be swapped out and then you touch a window that hasn't been touched in a while it has to swap all that memory back in before the browser will respond again.
there are plenty of ways to do it that are just as simple
I'm not sure there are
Consider you have a system that stored it's data in old fasioned flat files with say a 2 digit BCD year, I see four possible fixes each with it's issues
1: move to a psuedo-bcd format that can represent numbers up to 150, existing data all remains valid and the system is good for 50 years BUT you will have to write your own arithmetic/conversion functions for psuedo-BSD and hunt down everywhere BCD arithmetic or conversion is used in the code and change it.
2: implement a system that redefines the date field such that numbers below a certain threshold are considered to be in 20xx, the problem then becomes chosing that threshold, too large and you risk breaking historical data, too small and you get breakage again after a relatively short period.
3: implement the above but with a sliding window based on the current date, at first this seems like a good idea but it could cause a lot of confusion when say 90 year old (if your window is 90 years in the past and 10 years in the future) data starts being interpreted as being in the future. Possibly this could be worse than a system that breaks for new data depending on how long it takes to realise that data is being misinterpreted
4: change the file format and either convert all existing data or implement a file format version detection system
4 is the only proper long term fix but depending on details of how the data is stored is likely to be very intrusive.
any other soloutions you can think of?
At least you'd be in good company
Afaict it's quite common for ATMs to refuse to return cards if they think something is wrong with them or think they are stolen.
I could easilly see it taking three or four people before they realised it was a more general problem.
And maybe some of these people had the problem at different ATMs (afaict most places have more ATM locations then bank branches) and/or different times (I dnunno if banks in germany open at the weekend or not, I'm pretty sure most of them don't here in the UK).
All in all for 12 people to be at a bank branch with the problem would not really require stupidity on the customers part.
or even, as of Jan 01 2010, the next
Yes there will be minor date related problems all the time as some obscure date format reaches it's limit or some programmer made a stupid assumption but I expect 2038 to be the next major one.
Then we have a few major date formats expiring close together, 2100 (yes people still use 2 digit years), then unsigned 32 bit unix (used in some linux filesystems and also likely to be used in many systems as a quick fix for the 2038 bug) in 2106 and dos in 2107 (used in zipfiles and the fat filesystem among other places) most of us probablly won't live to see those problems though (and some of them may well be eliminated by the systems that use them falling out of use).
other than using english/american conventions.
That is what it should do, file formats should NOT be localisation dependent. If they want to create a new format that follows some other languages conventions that's fine but they shouldn't call it csv.
How many hardware RTCs actually use unix time anyway? the last one I dealt with stored years (2 digit!), months, days, hours minuites and seconds (I think there may have been another field too for smaller time units, not sure offhand).
Besides hardware RTCs usually wrap in a sane way so you can postpone the bug or reduce it to a bug that only happens if the system is left turned off for insane lengths of time fairly easilly.
The difficult bit with the 2038 bug is dealing with things like file formats, network protocols, library binary interfaces etc.
Copy and paste that in and your done
You shouldn't just copy and paste code in willy nilly anyway! that is what leads to cases like the recent "GPL code in MS software" incident.
What you should do is learn the facilities of the libraries available to you (most importantly your languages standard library) and make use of them. If they libraries you have available don't offer what you need then you need to weigh up the advantages of copying in code you didn't write (and may therefore have difficulty maintaining) vs adding a dependency vs reinventing the wheel.
Sadly as you say schools don't really teach this and even if they do people often end up picking up a new language very quickly without really ever learning it properly..
Depending on how important the development is and just how much the "large sums" are it's either similar to the reverse engineering case or a case of stupid penny pinching.
This means all that needs to be done for date calculations is a recompile.
ROFLMAO
IF the programmers have been good and actually used time_t rather than just int* AND either they haven't used it across interfaces that need to remain binary compatible AND they haven't stored it in any files then it may be possible to fix it with some clever hacks in the standard library and headers followed by a recompile with a special flag to indicate that 64 bit versions of the time functions and a 64-bit time_t should be used.
Back in the real world I expect a lot of code will need cleaning up to deal with the above issues and some libraries will either need thier major version buping (indicating a backwards compatibilty break) or to introduce a dual version system as mentioned above for the standard libraries. Anywhere the numbers are conversted to/from a byte sequence (the disk files you mentioned but also things like network protocols) will also need attention (and for shared disk files it may be nessacery to do a staged upgrade first adding support for reading the new format and then enabling writing in the new format).
And then there is the issue that to get the OS level fixes you may need to upgrade the major version of your OS and/or move to the 64-bit version of your OS (64-bit linux already has the y2K38 issue fixed) with the huge potential can of worms that opens (particually if the version of the OS that you are running is out of support at the time the 2038 bug becomes a big deal)
And then there is the fact that some source code will simply be completely lost.
In some cases the only reasonable fix may be forklift upgrades.
In summary I don't expect it to be much worse than Y2K but I don't expect it to be much better either.
* changing int to 64-bit would be almost certain to do more harm than good.
Most of the programmers who will be working this bug haven't been born yet
On what do you base this assertion?
Lets assume that a programmers career runs from about 21 to 65 , that work on the 2038 bug runs from 2033 to 2038 and that people at any stage in thier carrer are equally likely to be working on the bug (personally I suspect it will mostly be older programmers).
that would put the programemrs working on the bug as being born between 1968 and 2017 (there may be some off by one errors in this aritmetic, they shouldn't affect the point significantly). In other words most of them have already been born.
I suspect when the 2038 bug rolls around many of us slashdotters will be the old guys who can still program in C!
Using innocent and unsuspecting members of the public to do it though seems like a pretty fucked up thing to be doing and I hope whoevers idea this was gets punished appropriately.
If you are a goverment want to do a test of airport security systems then fine but use someone who has agreed to do it, agree it with the governments of target countries first and give that person ID so that they can prove that they are doing an official test.
On the other hand, my cousin ended up with almost no games on "white" Macbook. They told him "Black" one needed to play games. Guess what the White has? Intel GPU. Black, Nvidia.
Either you are misremembering the story or the person who advised your cousin was wrong. The black macbook always had intel graphics as did thier contempory white models.
Maybe you were thinking of the brief period when the aluminium unibody macbook had nvidia graphics while the white macbook still had intel graphics.
Things don't seem much better on this side of the pond (personal experiance of UK and info picked up from friends in continental europe), most ISPs still don't offer ipv6 and those who do generally offer it through tunnels and don't make it obvious. Further most home routers don't support ipv6 either.
IMO things are already too late for IPV6 to be widely deployed before IPV4 addresses run-out*. When that happens I predict the next move will be for ISPs to claw back addresses from home users and bottom end hosting customers to allocate to more lucrative uses.
ISPs who have always had their low end customers natted and those who only do higher end stuff are likely to be SOL. Maybe they will become the ones who will drive ipv6 forward.
*That is normal allocations are no longer available from the rirs. Arin have chosen to keep some addresses back for special uses and other rirs may do the same and of course reallocations of addresses will happen either officiall or unofficially.
I think the bigger archives (university archives of PHD thesis, archives of major journals, NASAs archives etc) will be ok unless there is a huge paradigm shift or a major societial collapse. If pdf starts to lose favour as the format for distributing electronic documents I would expect these large archives to just convert thier documents en-masse to the new format.
Lots of other less important stuff will be lost of course but that has always happened.
I believe that dell do at least with their business machines.
so they built 200m of unoccupied structure just to show off?!