According to accounts by people who haven't been told the events
* South Ossetia is a firecracker, but 50/50 South Ossetian/Georgian. * The South Ossetian militias attacked first. * Georgia's military is helping the US in Iraq - but their depleted military and reserves attacked back. * The South Ossetian's women and children had been moved to North Ossetia in Russia prior to the attack. * Oddly enough vast numbers of Russian troops just happened to be nearby to help out the South Ossetians. * Clearly the Georgians aren't angels either.
This is clearly a planned attack by Russia and the people that it has been giving free passports to (but who are not Russians otherwise). Right now it is looking like the West has swallowed the Russian view of events hook, line and sinker, when it appears that Russia has the most to gain from lying about all this.
I wonder if the bank even ever said "please can you check your statement in detail" before (as the summary says) just assuring him that it was all fine?
a) Europe: We have this awesome system (and variants thereof) that works, with strong incentives/harsh penalties for abuse by the billing companies.
b) Australia: We have this awesome system that works, ditto.
c) USA: We have this system that doesn't really work, that we don't trust, with no protection for us.
It's entirely an implementation issue, and I suggest that it's implemented to be best for business and the banks, with no consideration for the consumer that it's meant to be useful for.
Sounds like the bill paying service worked perfectly, and AT&T cocked up. If this automated bill paying service in the USA is like Direct Debit in the UK, then it absolutely cannot trigger collections agencies, it's just a bank transfer on a specific day triggered by the billing company.
But why the fuck was a collections agency onto you TWO DAYS afterwards? That's absolutely ridiculous.
If you checked your statements when they arrived, you could have seen the errors and put a stop to the debit before it occurred.
That is assuming that you actually do get statements (post or online) before the debit happens in the USA?
In your case what you probably want is an account that you put your expected amount of monthly bills in each month, and then pay all your bills from that one, instead of your primary account. If the company makes a mistake they are liable for any charges you may incur as a result of their mistake as well (or is that different in the USA as well?). Also do you have the option of putting a ceiling on the amount the debit is?
Automatic debiting is good for any bills that will incur a record in your credit history if you fail to pay them - basically credit cards, mortgage, etc. Luckily the mortgage amount is known in advance, and the credit card can be set to just pay the minimum required each month.
Direct Debit for bills - because you sometimes get a discount for paying by Direct Debit, and also because missing bill payments is a real hassle and I'm not organised enough to actually remember to pay things on time.
As for the credit card, I use it to pay for all orders online and of a reasonable amount in supermarkets. This gives me some protection, as opposed to using cash or a Debit Card.
I also check my bills every month to make sure that there is nothing out of the ordinary, and I look at my bank statements too (online, a couple of times a week). This is where you need to be diligent - the method you choose to pay is less important. You can revoke a Direct Debit at any time as well.
I agree that it makes sense for the intranet pages to be viewed in Compatibility Mode.
However showing a broken page icon next to standards-compliant web pages is another issue altogether. Clearly the broken page icon should apply to pages that aren't standards compliant!
With Windows Mobile and PalmOS devices, you can install IBM's J9 JVM (you can buy it for six dolla online) and then code in Java. I think the current version lets you code in Java 5. Couple that with SWT, and you have a nice environment in Java that's pretty frickin' cheap, but not an iPhone.
Failing Java+SWT on J9, I'd program for the iPhone (I'd do that before that, but I have no Intel based Mac:( )
In this case, the historical, and de-facto standard, wins. Base 2 capacities are all that matter for computer data stored in base two units of capacity, such as a block on a disc, computer memory, etc. You won't catch me using the inanely stupid SI unit names for this.
If this is the same disc as I've read about before, then at the outside of the disc the text is viewable with a 6x magnification, and it spirals in getting smaller all the time, and presumably referencing more and more advanced technologies all the time. This would stop a primitive society from learning about things way beyond them, until they had developed the necessary technology to read it.
Worries: if this disc is made with a certain societal bias, if some primitive society in the future finds it, they could develop their society in the same way that the disc writes about, rather than finding their own way.
Why not have more than one disc of material? Disc 1 (free with The Times on Sunday) could have the ancient stuff, Disc 2 (free with next week's Times) could have some myths, Disc 3... Disc 100. Also, what are they coating them with to last 2000 years without corroding?
Certainly the names of the guilty should be allowed to be publicised, as that is in the general public good.
Apart from that, initials and/or some general characteristics (e.g., accused's race, general location) could be used as well.
The purpose isn't to stop people knowing who has been accused, especially in the area they live it would be quite impossible. It is to restrict where this information ends up so that an innocent person won't have their life ruined after the case (and being found not guilty) or even just because they were brought in for questioning!
Names on radio or print media aren't so persistent, and people forget. But the internet, being simple to search, is a different matter.
An incident occurred that caused the metal frame to fail high up, and the building gracefully collapsed down on itself [rather than collapsing upwards into the sky, or like the death star!]
Other factors:
1) A building isn't a tree. Trees fall over because they don't have empty space to collapse into, the trunk is solid. If the WTC had been a 1000 foot high block of concrete, it wouldn't have collapsed in on itself.
2) Things fall in the direction of gravity when allowed to do so.
When you stop and think about it, it makes far less sense for the building to just collapse to the side than it does to collapse down if the incident happened high up. If half of the base of the WTC had been destroyed (bomb, etc) then the building could have falled to the side.
In addition, a controlled demolition to look like an accident probably would have tried to look random, rather than controlled! Stupid conspiracy theory.
You can write a bloody compiler (for C, BASIC, Java) in BASIC or FORTRAN, the only thing affecting the generated code at the end of the day is the algorithms (register allocation, loop unwrapping, etc) used within the compiler.
An everyday static compilation doesn't have runtime statistics available for it so it can never optimise as well as a compiler with runtime statistics available. Especially one with runtime statistics for the dataset you are running!
JIT compilation has these runtime statistics.
Therefore a JIT compilation can generate faster code than a static compilation. This has been shown to be the case (HP dynamo). Better static compilers will reduce the gap, but equally better JIT compilers will increase it again.
What can reduce performance for languages that are JITted these days is the language or runtime platform. Java has garbage collection, for example. Javascript has dynamic types.
Do I think that javascript will run as fast as C via the use of a JIT? No, I don't, but my reason for ruling it out wouldn't be "because C is faster" or "Javascript's running on C (even when JITted, somehow!) and thus can't be faster". It would be down to the language differences, and also the runtime differences.
I'm waiting for a Linux subnotebook system that uses one of NVIDIA's Tegra ARM-based SoCs. I think NVIDIA are a way off even shipping Tegra as product however, even at the low-end, never mind the theoretical quad-core Cortex A9 high-end.
I see it as providing a cheap, small, solution for the low-end market. A couple of CPU cores on one die mounted on an MCM with an RV730 level GPU on another die.
Why two dies? It's cheaper, as NVIDIA point out themselves having one larger die costs a lot more. I guess this is what they've learned with their massive GT200! Anyway, on 45nm in 2010 for AMD, this could be an ideal low-end laptop/notebook application processor.
And both NVIDIA and ATI's currently available hardware products support double precision floating point operations in hardware as well. For example ATI's FireStream 9250 based upon the RV770 does over 200 DP GFLOPS, which is twice that of the PowerXCell 8i.
Except they're available today. Larrabee is up to two GPU generations away.
[As an aside it does show that Sony's original idea of using Cell for graphics calculations wasn't bad, but just a few years early. Then again the original PS3 was going to have 4 Cell CPUs IIRC, giving well over 100x the FP power of the PS2]
I saw the benchmarks, was just wondering what methods they had used! I can certainly see how tokenising + address references would speed up over tokenising + named variables (with table lookup). Probably saved memory as well.
I guess it did come out in 1978, so 3MHz was probably what the Z80 achieved then. What's more surprising is the lack of speed enhancements with the Z80 afterwards, leading to 4MHz Z80s in 1984. Then again, the CPU market was a different thing back then.
No, JITs aren't interpreters. They're Just In Time Compilers.
They generate native code which then runs on the CPU directly.
I know that many people have pointed this out to you already, but compilation into native code is not interpretation.
Did you know that Apple use a JIT for PowerPC applications running on Intel? Even AmigaOS has a JIT, for 68k on PowerPC! That's native->native. Java bytecode can be viewed as a form of native code. But JIT can also run with interpreted languages like Ruby, Python, PHP, etc, directly converting into native code that runs at a good speed.
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.
So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?
Even though that is what a JIT is doing, taking a bytecode (or source code) and compiling it (at runtime, thus benefiting additionally from the runtime statistics) into native code. It's been proven that JIT compiling native code into native code on the same architecture can improve performance (HP Dynamo) - maybe the original compiler wasn't very good?
Ruby, FYI, is about 50x slower than C for the same algorithms. Your comment is true if you had left out that "or JIT, or whatever" statement.
2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.
2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.
Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.
Was this beyond simple BASIC tokenising of keywords, which pretty much every BASIC interpreter on an 8-bit micro did? Or did it compile the BASIC into another area of memory before running it (as you'd need the BASIC code for editing) - which surely must have been a bitch on memory in a 32KB computer. Or did the BASIC loader have different settings for loading-for-editing and loading-for-running?
If NVIDIA do anything it will be releasing an update of their Tegra application processor, or showing off the first generation of devices that will be using it.
As the original article even says, NVIDIA don't have a license for creating an x86 compatible CPU. Maybe they are making a non-backwards compatible x86-64 CPU instead! Ha! But why... VIA have been doing it for years and can't compete. Maybe this is NVIDIA showing off a chipset solution for VIA's Nano, that's more feasible.
Slashdot Mirror
* According to accounts by people who aren't telling the Russian view of events.
According to accounts by people who haven't been told the events
* South Ossetia is a firecracker, but 50/50 South Ossetian/Georgian.
* The South Ossetian militias attacked first.
* Georgia's military is helping the US in Iraq - but their depleted military and reserves attacked back.
* The South Ossetian's women and children had been moved to North Ossetia in Russia prior to the attack.
* Oddly enough vast numbers of Russian troops just happened to be nearby to help out the South Ossetians.
* Clearly the Georgians aren't angels either.
This is clearly a planned attack by Russia and the people that it has been giving free passports to (but who are not Russians otherwise). Right now it is looking like the West has swallowed the Russian view of events hook, line and sinker, when it appears that Russia has the most to gain from lying about all this.
I wonder if the bank even ever said "please can you check your statement in detail" before (as the summary says) just assuring him that it was all fine?
Looking through the discussion, it's all:
a) Europe: We have this awesome system (and variants thereof) that works, with strong incentives/harsh penalties for abuse by the billing companies.
b) Australia: We have this awesome system that works, ditto.
c) USA: We have this system that doesn't really work, that we don't trust, with no protection for us.
It's entirely an implementation issue, and I suggest that it's implemented to be best for business and the banks, with no consideration for the consumer that it's meant to be useful for.
Sounds like the bill paying service worked perfectly, and AT&T cocked up. If this automated bill paying service in the USA is like Direct Debit in the UK, then it absolutely cannot trigger collections agencies, it's just a bank transfer on a specific day triggered by the billing company.
But why the fuck was a collections agency onto you TWO DAYS afterwards? That's absolutely ridiculous.
If you checked your statements when they arrived, you could have seen the errors and put a stop to the debit before it occurred.
That is assuming that you actually do get statements (post or online) before the debit happens in the USA?
In your case what you probably want is an account that you put your expected amount of monthly bills in each month, and then pay all your bills from that one, instead of your primary account. If the company makes a mistake they are liable for any charges you may incur as a result of their mistake as well (or is that different in the USA as well?). Also do you have the option of putting a ceiling on the amount the debit is?
Automatic debiting is good for any bills that will incur a record in your credit history if you fail to pay them - basically credit cards, mortgage, etc. Luckily the mortgage amount is known in advance, and the credit card can be set to just pay the minimum required each month.
Direct Debit for bills - because you sometimes get a discount for paying by Direct Debit, and also because missing bill payments is a real hassle and I'm not organised enough to actually remember to pay things on time.
As for the credit card, I use it to pay for all orders online and of a reasonable amount in supermarkets. This gives me some protection, as opposed to using cash or a Debit Card.
I also check my bills every month to make sure that there is nothing out of the ordinary, and I look at my bank statements too (online, a couple of times a week). This is where you need to be diligent - the method you choose to pay is less important. You can revoke a Direct Debit at any time as well.
I agree that it makes sense for the intranet pages to be viewed in Compatibility Mode.
However showing a broken page icon next to standards-compliant web pages is another issue altogether. Clearly the broken page icon should apply to pages that aren't standards compliant!
Irish: Graaargh, Graaa... gRraaa, Gra
English: GUINNESS again, good Sir behind the bar.
http://www-01.ibm.com/software/wireless/weme/
Has a trial.
You used to be able to buy it for $6 at Handango, but they've redone their website to be totally unusable.
Java on PocketPC:
http://blog.vikdavid.com/2004/12/java_on_pocketp.html
With Windows Mobile and PalmOS devices, you can install IBM's J9 JVM (you can buy it for six dolla online) and then code in Java. I think the current version lets you code in Java 5. Couple that with SWT, and you have a nice environment in Java that's pretty frickin' cheap, but not an iPhone.
Failing Java+SWT on J9, I'd program for the iPhone (I'd do that before that, but I have no Intel based Mac :( )
I speak on behalf of many people when I say this:
Screw the SI units for data capacity.
1PB = 1024TB
1TB = 1024GB
1GB = 1024MB
1MB = 1024KB
1KB = 1024B
In this case, the historical, and de-facto standard, wins. Base 2 capacities are all that matter for computer data stored in base two units of capacity, such as a block on a disc, computer memory, etc. You won't catch me using the inanely stupid SI unit names for this.
If this is the same disc as I've read about before, then at the outside of the disc the text is viewable with a 6x magnification, and it spirals in getting smaller all the time, and presumably referencing more and more advanced technologies all the time. This would stop a primitive society from learning about things way beyond them, until they had developed the necessary technology to read it.
Worries: if this disc is made with a certain societal bias, if some primitive society in the future finds it, they could develop their society in the same way that the disc writes about, rather than finding their own way.
Why not have more than one disc of material? Disc 1 (free with The Times on Sunday) could have the ancient stuff, Disc 2 (free with next week's Times) could have some myths, Disc 3 ... Disc 100. Also, what are they coating them with to last 2000 years without corroding?
Certainly the names of the guilty should be allowed to be publicised, as that is in the general public good.
Apart from that, initials and/or some general characteristics (e.g., accused's race, general location) could be used as well.
The purpose isn't to stop people knowing who has been accused, especially in the area they live it would be quite impossible. It is to restrict where this information ends up so that an innocent person won't have their life ruined after the case (and being found not guilty) or even just because they were brought in for questioning!
Names on radio or print media aren't so persistent, and people forget. But the internet, being simple to search, is a different matter.
Sounds like excellent design to me.
An incident occurred that caused the metal frame to fail high up, and the building gracefully collapsed down on itself [rather than collapsing upwards into the sky, or like the death star!]
Other factors:
1) A building isn't a tree. Trees fall over because they don't have empty space to collapse into, the trunk is solid. If the WTC had been a 1000 foot high block of concrete, it wouldn't have collapsed in on itself.
2) Things fall in the direction of gravity when allowed to do so.
When you stop and think about it, it makes far less sense for the building to just collapse to the side than it does to collapse down if the incident happened high up. If half of the base of the WTC had been destroyed (bomb, etc) then the building could have falled to the side.
In addition, a controlled demolition to look like an accident probably would have tried to look random, rather than controlled! Stupid conspiracy theory.
You can write a bloody compiler (for C, BASIC, Java) in BASIC or FORTRAN, the only thing affecting the generated code at the end of the day is the algorithms (register allocation, loop unwrapping, etc) used within the compiler.
An everyday static compilation doesn't have runtime statistics available for it so it can never optimise as well as a compiler with runtime statistics available. Especially one with runtime statistics for the dataset you are running!
JIT compilation has these runtime statistics.
Therefore a JIT compilation can generate faster code than a static compilation. This has been shown to be the case (HP dynamo). Better static compilers will reduce the gap, but equally better JIT compilers will increase it again.
What can reduce performance for languages that are JITted these days is the language or runtime platform. Java has garbage collection, for example. Javascript has dynamic types.
Do I think that javascript will run as fast as C via the use of a JIT? No, I don't, but my reason for ruling it out wouldn't be "because C is faster" or "Javascript's running on C (even when JITted, somehow!) and thus can't be faster". It would be down to the language differences, and also the runtime differences.
I'm waiting for a Linux subnotebook system that uses one of NVIDIA's Tegra ARM-based SoCs. I think NVIDIA are a way off even shipping Tegra as product however, even at the low-end, never mind the theoretical quad-core Cortex A9 high-end.
I see it as providing a cheap, small, solution for the low-end market.
A couple of CPU cores on one die mounted on an MCM with an RV730 level GPU on another die.
Why two dies? It's cheaper, as NVIDIA point out themselves having one larger die costs a lot more. I guess this is what they've learned with their massive GT200! Anyway, on 45nm in 2010 for AMD, this could be an ideal low-end laptop/notebook application processor.
And both NVIDIA and ATI's currently available hardware products support double precision floating point operations in hardware as well. For example ATI's FireStream 9250 based upon the RV770 does over 200 DP GFLOPS, which is twice that of the PowerXCell 8i.
Except they're available today. Larrabee is up to two GPU generations away.
[As an aside it does show that Sony's original idea of using Cell for graphics calculations wasn't bad, but just a few years early. Then again the original PS3 was going to have 4 Cell CPUs IIRC, giving well over 100x the FP power of the PS2]
Cheers for the info.
I saw the benchmarks, was just wondering what methods they had used! I can certainly see how tokenising + address references would speed up over tokenising + named variables (with table lookup). Probably saved memory as well.
I guess it did come out in 1978, so 3MHz was probably what the Z80 achieved then. What's more surprising is the lack of speed enhancements with the Z80 afterwards, leading to 4MHz Z80s in 1984. Then again, the CPU market was a different thing back then.
No, JITs aren't interpreters. They're Just In Time Compilers.
They generate native code which then runs on the CPU directly.
I know that many people have pointed this out to you already, but compilation into native code is not interpretation.
Did you know that Apple use a JIT for PowerPC applications running on Intel? Even AmigaOS has a JIT, for 68k on PowerPC! That's native->native. Java bytecode can be viewed as a form of native code. But JIT can also run with interpreted languages like Ruby, Python, PHP, etc, directly converting into native code that runs at a good speed.
So stop saying "or JIT-compiled", it's wrong.
Clearly no matter how fast the interpreted language goes it can never be faster than C, as long as the interpreter (or JIT, or whatever) is written in C.
So if I wrote a C compiler in Ruby, the generated code could never run as fast as Ruby?
Even though that is what a JIT is doing, taking a bytecode (or source code) and compiling it (at runtime, thus benefiting additionally from the runtime statistics) into native code. It's been proven that JIT compiling native code into native code on the same architecture can improve performance (HP Dynamo) - maybe the original compiler wasn't very good?
Ruby, FYI, is about 50x slower than C for the same algorithms. Your comment is true if you had left out that "or JIT, or whatever" statement.
1) That's the Mono implementation of C#
2) Intel's C++ compiler is known to be one of the best but cannot handle all situations. GCC's takes 1.3 times longer. Java 'only' takes 1.96 times longer.
2a) Intel's C++ compiler got 3 errors in the benchmarks you linked to, thus it should have been disqualified. The Intel C got 1 error and a "no program", so again, disqualified. The first compiler to run all the tests was in fact the Gnu C++ compiler.
Ruby at 63x longer (or 30x slower than Java) should shut up all the Java haters who witter on about Ruby (or PHP at 12 slower than Java) for web development.
Was this beyond simple BASIC tokenising of keywords, which pretty much every BASIC interpreter on an 8-bit micro did? Or did it compile the BASIC into another area of memory before running it (as you'd need the BASIC code for editing) - which surely must have been a bitch on memory in a 32KB computer. Or did the BASIC loader have different settings for loading-for-editing and loading-for-running?
If NVIDIA do anything it will be releasing an update of their Tegra application processor, or showing off the first generation of devices that will be using it.
As the original article even says, NVIDIA don't have a license for creating an x86 compatible CPU. Maybe they are making a non-backwards compatible x86-64 CPU instead! Ha! But why ... VIA have been doing it for years and can't compete. Maybe this is NVIDIA showing off a chipset solution for VIA's Nano, that's more feasible.