A better way hairy, is to use the Windows 7 disk to install a NEW copy first, and when it asks for the key, select "Trial". Once the install is complete, then run it again, and it will detect the trial version and allow you to upgrade it. The "second" install/upgrade is very quick.
I don't know about fingerprints at 6 meters away, but if they come up with a miniature portable through the clothes scanner (ALA TSA) that can scan people from 6 meters away, I'll be happy to take it through a chain of 24-hour fitness centers to beta test it for them.
Just to point out your errors: Your own link shows the deskstar having a 85MB/s minimum sustained write speed, and if you were to design a system that a minimum speed was required, you could quite easilyuse 2 drives, with one writing from inner track to outer, and the other from outer track to inner in a RAID-0, and as your graph shows, it would sustain 400MB/s between the two. You could also leave the inner tracks unused. Or use a faster drive that spins at 15k RPM. You still aren't near the speed you would need to write uncompressed images, but at least the numbers are realistic.
The obvious choice, use a SSD. My personal SSD (OCZ Revo 3 x2) can sustain 1.4GB write speeds without breaking a sweat. Save the images using standard jpg compression, and it should be extremely easy to do.
Let's see. I don't think either stuxnet or flame are scaring the hell out of the Iranian civilian population? There isn't a large count of civilian casualties?
Sorry, here's the top 10 with version numbers: 1. Internet Explorer 9.0 23.11% 2. Internet Explorer 8.0 22.04% 3. Internet Explorer 7.0 7.70% 4. Safari 7534.48.3 6.24% 5. Firefox 12.0 3.69% 6. Android Browser 533.1 3.49% 7. Firefox 11.0 3.01% 8. Chrome 19.0.1084.52 1.94% 9. Firefox 10.0.2 1.48% 10. Chrome 18.0.1025.168 1.43%
Although, I find version numbers fairly irrelevant for Firefox, Chrome, Safari as their version numbers change so quickly that they under represent themselves.
I'll make this a sample size of 2 then. With 590,703 unique visitors: 53.45% used IE 14.84% used Safari 13.57% used Firefox 12.54% used Chrome 4.04% used Android 0.45% used Opera
These were taken from a site with absolutely no technical background, and should have no bias towards any particular demographic. Whether stats counter is more correct or not globally or not, NetApp's numbers more closely resemble traffic we see, and therefore a more accurate source for us.
hich would mean rewriting the entire view layer from using Win32 controls to using WinRT controls.
No,.NET apps use.NET controls not Win32 controls, which is quite independent from the underlying OS or architecture. On the Win32/64 platform, the.NET controls may indeed use Win32 controls, but the.NET app doesn't need to know or care about that. So long as the.NET control is implemented the same on both platforms, any.NET app that uses it will be portable with no code changes required.
You mean like the OS calls to open a window and draw things to it?
.NET has their own calls to do that. It is extremely rare that you would ever need to (or should) be making Win32 calls to do such things.
Well except that everything he wrote, and the technical abbreviations he used were absolutely correct. But there is a large majority of slashdot readers that aren't familiar with Microsoft technologies and get easily confused when the same abbreviation is used for multiple things. CIL is indeed correct, as would MS-IL, or IL when referring to the byte code that.NET applications get compiled to.
For the sites that I've worked on, it's mostly the social media plugin crap that slows then down, with facebook being one of the worst offenders. As such, I take great pains to load the social media stuff only after the entire page has been rendered, which helps responsiveness greatly. Multiple css files = negligible. Multiple javascript frameworks = negligible.
Why would you be comparing ARM to x86? If you are going to be pulling an ancient version of the instruction set for intel from 1978, then let's do an apples to apples comparision and compare that to the 1978 version of ARM. The 1978 intel chip (8086) had AX, BX, CD, DX, SI, DI, BP, and SP registers (I would count IP and not including the segment registers CS,DS,ES,SS, or the flag register, or floating point operators). You are right, there really only were 4 general (AX,BX,CX,DX) with some operations limited to using BX,SI,SI,BP like string operations, CX for counting/loop operations. ARM had 0.
Or we could compare the 32-bit version of Intel chips that have been around since 1985, extend those out to 32-bits and make them all general registers, add 2 more segment registers, add 8 multimedia registers (MMX0-MM7), add 8 SIMD registers (XMM0-XMM7), and a few more status registers (CR0-CR4,TR3-TR4,DR0-DR3,D6,D7,TR,GDTR, LDTR, IDTR). Still ARM had 0 (Unless you want to count acorn, which came out a few months later, and an actual working computer 2 years after that).
In 1987 Intel added register renaming making the total general purpose registers 128, while only being able to see 16. While you can't directly address these 128 general purpose registers, they work behind the scenes to effectively give you a much larger register size than what you see. All the benefit of more registers but without having to specifically use them.
Or we could compare what we had in 2004. Intel allowed to specify an additional 8 more registers R8-R15 (Still 128 in the background). ARM has 13-14ish.
That's totally believable since the energy required for those things is (relatively) very small especially compared to the total system power, while you have to increase the memory bandwidth on ARM because of the larger fixed sized instruction set and higher number of instructions to achieve the same performance. So the higher CPU power usage is offset by not requiring a faster (and more power hungry) bus, a higher frequency execution unit, memory controller and memory.
Yeah, right. 37 of which you can only ever use at most 16. Of which, 5 are taken up already, and personally I wouldn't call the flags register a general purpose register, nor the stack pointer, etc, but apparently they do, lol. Also, look down at the nice graph right below your quote, you will also notice that during Fast Interrupt Routines, you have only 5 registers free to use (R8-R12), and during user mode, you only have 13 (R0-R12) free for your use, and during an IRQ you have 0 free? lol.
So you have R0-R7 which are what most would consider general purpose, R8-R12 are special and only available in certain operating modes, and R13,14,15 aren't what most would consider general purpose.
x86-64 has 16 (64-bit) general purpose registers, but ARM has 8 (32-bit) general purpose registers, and a few specialized ones, some of which are only available in certain operating modes. PowerPC and SPARC both have 32 64-bit registers but can only do register-register type operations (load/store) which quickly forces the registers to be cycled, while x86-64 can do register-memory type operands which is much more efficient.
And yes, Intel does do a lot of microcode, pipelining, and micro-ops. The great part is that because of it, the instruction set appears CISC externally, but internally through micro-ops, it gets 95% of the benefit that you would see through RISC. Today's x86 chips are more a CISC/RISC hybrid than they are of a pure CISC design. And of course a 200MHz SPARC was worse in performance than the Pentium 2's of the day, and isn't really in the same performance league as today's 4GHz x86-64 processors.
A better way hairy, is to use the Windows 7 disk to install a NEW copy first, and when it asks for the key, select "Trial". Once the install is complete, then run it again, and it will detect the trial version and allow you to upgrade it. The "second" install/upgrade is very quick.
Here's the family pack for $110 --
http://www.bhphotovideo.com/c/product/645759-REG/Microsoft_GFC_00236_Windows_7_Home_Premium.html
http://www.bhphotovideo.com/c/product/645759-REG/Microsoft_GFC_00236_Windows_7_Home_Premium.html
I don't know about fingerprints at 6 meters away, but if they come up with a miniature portable through the clothes scanner (ALA TSA) that can scan people from 6 meters away, I'll be happy to take it through a chain of 24-hour fitness centers to beta test it for them.
Just to point out your errors: Your own link shows the deskstar having a 85MB/s minimum sustained write speed, and if you were to design a system that a minimum speed was required, you could quite easilyuse 2 drives, with one writing from inner track to outer, and the other from outer track to inner in a RAID-0, and as your graph shows, it would sustain 400MB/s between the two. You could also leave the inner tracks unused. Or use a faster drive that spins at 15k RPM. You still aren't near the speed you would need to write uncompressed images, but at least the numbers are realistic.
The obvious choice, use a SSD. My personal SSD (OCZ Revo 3 x2) can sustain 1.4GB write speeds without breaking a sweat. Save the images using standard jpg compression, and it should be extremely easy to do.
What makes you think that your bank account PIN can't be guessed? Please post it.
Let's see. I don't think either stuxnet or flame are scaring the hell out of the Iranian civilian population? There isn't a large count of civilian casualties?
What part do you think is the same?
Nah, I was around long before Wayne Bell. By the time he hit the scene, I was already out.
Sorry, here's the top 10 with version numbers:
1. Internet Explorer 9.0 23.11%
2. Internet Explorer 8.0 22.04%
3. Internet Explorer 7.0 7.70%
4. Safari 7534.48.3 6.24%
5. Firefox 12.0 3.69%
6. Android Browser 533.1 3.49%
7. Firefox 11.0 3.01%
8. Chrome 19.0.1084.52 1.94%
9. Firefox 10.0.2 1.48%
10. Chrome 18.0.1025.168 1.43%
Although, I find version numbers fairly irrelevant for Firefox, Chrome, Safari as their version numbers change so quickly that they under represent themselves.
I'll make this a sample size of 2 then. With 590,703 unique visitors:
53.45% used IE
14.84% used Safari
13.57% used Firefox
12.54% used Chrome
4.04% used Android
0.45% used Opera
These were taken from a site with absolutely no technical background, and should have no bias towards any particular demographic. Whether stats counter is more correct or not globally or not, NetApp's numbers more closely resemble traffic we see, and therefore a more accurate source for us.
Sure you can. You just can't do it with an interval of 1.
I fought on the epic frontlines of the Amiga versus Atari BBS flamewars before most of you were an ache in your daddys' groins.
Most perhaps, but not all. Some of us here on slashdot actually wrote the BBS software that the flamewars went on.
Exactly. Do you have any idea how many World of Warcraft bots I could be running on one of those farming me gold?
How well does that demonstration work in Internet Explorer?
Works fine for me in IE 9+.
Once this UEFI Secure Boot thing ramps up over the coming years, it will no longer be possible to wipe a computer for another operating system
Read the UEFI spec. This isn't true. http://www.redhat.com/about/news/archive/2012/6/uefi-secure-boot
Just write your app in .NET like millions of applications currently are, and you don't need to do anything.
hich would mean rewriting the entire view layer from using Win32 controls to using WinRT controls.
No, .NET apps use .NET controls not Win32 controls, which is quite independent from the underlying OS or architecture. On the Win32/64 platform, the .NET controls may indeed use Win32 controls, but the .NET app doesn't need to know or care about that. So long as the .NET control is implemented the same on both platforms, any .NET app that uses it will be portable with no code changes required.
You mean like the OS calls to open a window and draw things to it?
.NET has their own calls to do that. It is extremely rare that you would ever need to (or should) be making Win32 calls to do such things.
Well except that everything he wrote, and the technical abbreviations he used were absolutely correct. But there is a large majority of slashdot readers that aren't familiar with Microsoft technologies and get easily confused when the same abbreviation is used for multiple things. CIL is indeed correct, as would MS-IL, or IL when referring to the byte code that .NET applications get compiled to.
There is nothing stopping you from doing that david. We do that and it works quite well for the off-site content.
For the sites that I've worked on, it's mostly the social media plugin crap that slows then down, with facebook being one of the worst offenders. As such, I take great pains to load the social media stuff only after the entire page has been rendered, which helps responsiveness greatly. Multiple css files = negligible. Multiple javascript frameworks = negligible.
Why would you be comparing ARM to x86? If you are going to be pulling an ancient version of the instruction set for intel from 1978, then let's do an apples to apples comparision and compare that to the 1978 version of ARM. The 1978 intel chip (8086) had AX, BX, CD, DX, SI, DI, BP, and SP registers (I would count IP and not including the segment registers CS,DS,ES,SS, or the flag register, or floating point operators). You are right, there really only were 4 general (AX,BX,CX,DX) with some operations limited to using BX,SI,SI,BP like string operations, CX for counting/loop operations. ARM had 0.
Or we could compare the 32-bit version of Intel chips that have been around since 1985, extend those out to 32-bits and make them all general registers, add 2 more segment registers, add 8 multimedia registers (MMX0-MM7), add 8 SIMD registers (XMM0-XMM7), and a few more status registers (CR0-CR4,TR3-TR4,DR0-DR3,D6,D7,TR,GDTR, LDTR, IDTR). Still ARM had 0 (Unless you want to count acorn, which came out a few months later, and an actual working computer 2 years after that).
In 1987 Intel added register renaming making the total general purpose registers 128, while only being able to see 16. While you can't directly address these 128 general purpose registers, they work behind the scenes to effectively give you a much larger register size than what you see. All the benefit of more registers but without having to specifically use them.
Or we could compare what we had in 2004. Intel allowed to specify an additional 8 more registers R8-R15 (Still 128 in the background). ARM has 13-14ish.
during user mode, you only have 13 (R0-R12) free for your use
That's totally believable since the energy required for those things is (relatively) very small especially compared to the total system power, while you have to increase the memory bandwidth on ARM because of the larger fixed sized instruction set and higher number of instructions to achieve the same performance. So the higher CPU power usage is offset by not requiring a faster (and more power hungry) bus, a higher frequency execution unit, memory controller and memory.
But we'll have to wait and see.
Yeah, right. 37 of which you can only ever use at most 16. Of which, 5 are taken up already, and personally I wouldn't call the flags register a general purpose register, nor the stack pointer, etc, but apparently they do, lol. Also, look down at the nice graph right below your quote, you will also notice that during Fast Interrupt Routines, you have only 5 registers free to use (R8-R12), and during user mode, you only have 13 (R0-R12) free for your use, and during an IRQ you have 0 free? lol.
So you have R0-R7 which are what most would consider general purpose, R8-R12 are special and only available in certain operating modes, and R13,14,15 aren't what most would consider general purpose.
x86-64 has 16 (64-bit) general purpose registers, but ARM has 8 (32-bit) general purpose registers, and a few specialized ones, some of which are only available in certain operating modes. PowerPC and SPARC both have 32 64-bit registers but can only do register-register type operations (load/store) which quickly forces the registers to be cycled, while x86-64 can do register-memory type operands which is much more efficient.
And yes, Intel does do a lot of microcode, pipelining, and micro-ops. The great part is that because of it, the instruction set appears CISC externally, but internally through micro-ops, it gets 95% of the benefit that you would see through RISC. Today's x86 chips are more a CISC/RISC hybrid than they are of a pure CISC design. And of course a 200MHz SPARC was worse in performance than the Pentium 2's of the day, and isn't really in the same performance league as today's 4GHz x86-64 processors.