And for most single-user uses, that's fine. I just kicked off a run of the LLVM test suite, since it was the first thing I could think of that would cause a lot of I/O. It was doing 1000 random reads and 500 random writes per second on my (two-year-old) laptop's SSD. It wasn't a great benchmark, because it was CPU limited, even with a quad-core i7, but that's largely the point of the SSD: the CPU is now the bottleneck, whereas with my old machine (spinning disk and Core 2 Duo), the same operation was I/O limited, even with a CPU less than half the speed.
Hmm, my drives send me emails when they start having problems. (And having gotten one of these emails a few years after setting up the drive initially, I was shocked to find it the email arrived in plenty of time. I pleasantly surprised to find the drive and all data still intact, and had time to swap a replacement into the raid).
There was a paper from Google about 18 months ago that showed that, while SMART errors do usually mean the disk will fail, lack of SMART errors does not mean that the disk is not about to fail. In a large number of cases, the drives failed with no warning.
The noise is also something of a red herring. I have a laptop whose drive started to make slightly worrying noises about 2 years ago, but which hasn't died (yet). I've also had several hard disks die with no warning at all. Sometimes, the failure correlates with hearing an odd noise first, but often it doesn't.
I've had three hard disks fail, none of them was in a state where any data was readable. My university computer lab at the time had about half of the drives fail within 18 months of purchase, all with the same failure mode. So I guess you were luckier. I've not had any SSDs fail yet, but I only have one and it's only about 2 years old, so there's still a lot of time...
FedEx is a company that I will avoid at all costs. I lost about half a day chasing them because they'd reported me to a debt collecting agency over an unpaid delivery. There were only two problems with this: paying for the delivery was not my liability (I hadn't signed anything) and they actually were paid by the people who were supposed to pay (who had a corporate account and a FedEx account number that deliveries could just be charged against). FedEx admitted this to me after the first time they wrote to me telling me that there was an unpaid debt, and issued me with a credit note for it. Unfortunately, they somehow managed to get the delivery entered into their accounting system twice and so they closed one as paid and then sent the other to a legal firm.
Controller failures are usually easy to fix. The controller on most disks is on a board on the outside that can be unscrewed and replaced. If you find another drive (often cheap, second hand) of the same make and model you can switch them across. I wouldn't recommend doing anything with the drive other than dumping the data when it's in this state, however...
That said, I completely agree. Stuff that is on a single drive is stuff that you don't care about.
You're the second post I've seen on this article conflating 10x the productivity with 10x the amount of code written. There's very little correlation between the two, which is why IBM learned that paying bonuses per line of code results in terrible code. The developers who are ten times as productive are the ones that spend the time understanding the requirements and then write code that does a good job of solving the problem at hand. They don't spend time writing hand-optimised versions of code that is not on the critical path, and they don't waste effort writing complex general solutions when their code is only going to need to handle one input. They do document their work and they do ensure that it's easy to refactor when the requirements change, because they've learned that the poor sap who will have to change it in a year's time is probably them.
With ThunderBolt, you have enough bandwidth for all of those things, although power is still another connector. That said, you should look for third-party docking stations. Even though specialised docking station connectors are now rare, it's fairly common for after-market designs to exist, which have a bar that lines up with all of the ports on the machine and allow you to just slot the machine in. I'd love to have a machine without even that, and just an inductive charger and near-field communication so I put it down on the desk and it starts working with everything else there, but that's a little way away.
Oh, and you probably have an unusually well-designed docking station. My experience with my father's old laptop was that it was more fiddly to get the docking right than to just plop the machine down on the desk and plug in a few cables. The ease of docking varies quite a lot between manufacturers.
Tarballs make me think of shitty sourceforge days.
Packages OTOH can be nice.
Tarballs are the input for most packaging systems. If you don't publish a tarball, then I have to create one before I even start packaging your code. So you get moved to the bottom of my list. And that's probably fine for a fast-moving project, where you don't want people running an old version and sending reports for bugs that are already fixed, but for a more mature project make sure you make life easier for packagers. That means:
Provide the tarballs
Provide a list of dependencies (don't make me run configure / CMake scripts, parse their output, and chase things down).
Ensure you specify minimum / maximum versions of dependencies for things you depend on, if they matter.
Ideally, provide a list of files you will install and where for each build configuration (I can generate this automatically if it's fixed, but it's harder if it's depends on the build configuration)
Provide a concise description of your project, both as a single-line summary and as a few paragraphs, for the descriptions in the packages.
If you provide all, or even most, of these then I can probably package your software in 5-10 minutes.
The tarball is not for casual users. The tarball is for packagers. Having a stable tarball (i.e. one with a published URL whose hash won't change between downloads) makes it much easier to create the package.
What's in it for them? The point of releasing open source code is not to gain users, it's to gain contributors. If you're someone for whom having to download a tarball and build it is too high a barrier to entry, then you're probably not someone who is likely to contribute patches either (and if you don't already have a dev environment set up, then you're almost certainly not going to contribute code). Given that they have limited time to spend on the project, does it make more sense to spend that time catering to you, or to people who will build from source?
Contrarily to what seems to be a popular belief on Slashdot, x86 and ARM aren't the real issue, it's the designs themselves which come from very different backgrounds
There's some truth in that, but a lot is intrinsic to the instruction set.
The first round of RISC vs CISC was won by RISC, because they used very simple instruction decoders, whereas CISC chips had 20-50% of their total die area taken up with the decoding logic. This meant that, for the same transistor budget, a RISC chip could spend a lot more of it on execution units.
Then, as dies became bigger, CISC started to gain because they could do things like divide in hardware, rather than as a microcoded loop, whereas RISC was still expanding the sequence in the compiler or assembler. RISC chips needed to modify their instruction sets to keep up. Those complex addressing modes in CISC chips started to be folded into single-cycle operations as part of the load pipeline, whereas the RISC equivalents were sequences of operations with lots of pipeline dependencies between them. Most of the surviving 'RISC' architectures (e.g. PowerPC) were quite CISCy by this point.
Then CPUs got faster than memory and so instruction cache pressure and so the variable-length instruction encoding became a benefit because instruction cache misses became very expensive and so having a smaller instruction cache with the same miss rate meant that you could have more execution units for the same transistor budget. The size of the cache became greater than the size of the decoder as time went on.
So why doesn't this apply to ARM? First, ARM has managed to keep their instruction set simple and orthogonal (so very cheap to decode), but also very expressive. All memory operations have a register, an immediate offset, and a shift, so you get quite complex addressing modes without needing a complex decoder. Thumb-2 is a variable-length instruction set, but a very simple one (instructions are all 16 or 32 bits, with a cheap way of distinguishing them) and one designed to make the instructions that compilers commonly emit shorter. It gives similar code density to x86, but with a much cheaper decoder.
Why does the decoder size still matter? Because the decoder is one of the only parts of the chip that has to be powered all of the time[1]. The name of the game today is trying to turn off as much of the CPU as possible. Power consumption per transistor has not been dropping nearly as fast as transistor densities have been increasing, so if you want to stay within your thermal envelope then you get more transistors to play with each generation, but you can power a smaller subset of them at any given time (this is called the Dark Silicon Problem by those in the industry).
Many of the tricks that Intel can do involve having a complex decoder and then a reordering and micro-op fusion sequence in their pipeline. These give a significant performance advantage at the high end, but also place a lower bound on their power consumption. Newer additions, like hardware transactional memory, come at a similar power cost: HTM requires a lot more logic in the cache controller, which means more always-on power consumption. It will probably give an overall performance/Watt advantage when the CPU is under full load in a large multicore setup, but in a single-socket system with moderate load you'll end up burning more power.
It's quite telling that the power consumption figures for Haswell, for a 1.5GHz single-core chip are in the same ballpark as a 1.5GHz quad-core Cortex A15 SoC (including 72-core nVidia GPU, under load).
[1] In tight loops, high-end Intel chips will power gate the decoder and just read from the micro-op cache, however the micro-op decoder is still powered and is about as complex as an ARM decoder.
DEC screwed the pooch on that one, no doubt; they priced it as a high-end workstation chip, and lower-priced commodity PC hardware running x86 ate their lunch.
I remember adverts for Windows NT PCs with Alpha chips, and they weren't that much more expensive than Intel. A Pentium Pro machine could easily set you back more and still be slower if you were running native code. That last bit was the killer: there was almost no native Alpha/NT software, not even Microsoft Office or Visual Basic. So you had to run the code in FX32! and then it was significantly slower than native code.
If DEC had really wanted this market, then they should have identified the top 1,000 CPU-intensive Windows applications and ensured that the first 5,000 machines off their production lines were shipped, for free, to the manufacturers, along with an offer of free support for porting software. If things like Photoshop had been ported, then things might have been quite different. Even a $1000 premium on hardware is nothing if it's making your artists spend 10% less time waiting is worth it. And once you've got a reasonable install base of people who are used to paying a lot for hardware and software, it becomes an attractive market for other software developers (at which point you release an Alpha simulator and cross-compile toolchain, which lets people test Alpha code on their x86 systems, albeit at maybe 10% of native speed).
Docking stations used to be very popular. They largely died out when people realised that they were paying $300 to be able to plug in one awkward connector instead of 3 (USB, video, power, possibly network). Back when they were popular, the keyboard was likely PS/2, the mouse was PS/2 or serial, the video was VGA, and you might have also plugged in a SCSI CD ROM or hard disk. Now, they still exist, but they're called monitors. A modern monitor comes with a USB hub (and if you buy an Apple one, either a FireWire or Thunderbolt hub). Your keyboard and mouse are connected to the display, so you just plug in power, a USB cable and a DVI/HDMI/DisplayPort cable and you get all of the benefits of the docking station - some people even have external hard disks and USB network interfaces dangled off the back of the monitor (just don't talk to them about performance). If your laptop and monitor both support Thunderbolt then that single cable is fast enough for display, keyboard, mouse, GigE, and eSATA.
I have an Asus TransformerPadSomethingWhateverTheSillyNameIs and it isn't too bulky as a laptop. The main advantages are that it has a really nice screen (1080p and useable outside on a sunny day) and a battery that lasts 10 hours without even trying to keep power consumption down, closer to 15 if I reduce screen brightness and so on. In terms of portability, with the keyboard attached it's twice as thick as the tablet, but the same other dimensions, so it's still easy to slip into pretty much anything that's big enough to carry a 10" tablet.
Android is great in the tablet mode, but it really starts to show that it was designed for phones when you start trying to do real work on it. Switching quickly between applications is cumbersome (e.g. if I'm writing something and want to refer to PDF documents or web pages for reference), far more so than on any other OS I've used (WebOS got this a bit better for tablets and I'm still bitter about HP mismanaging it into oblivion). I can see a market for Windows devices with this sort of form factor, and the whole Metro thing almost starts to make sense to me: when the screen's detached, the Android apps are all quite useable, but when it's attached to the keyboard and trackpad I'd like to have more traditional desktop apps available. That said, I've not used Windows on the desktop since Windows 2000 was state of the art and I've not used Metro except for briefly playing with devices owned by some friends at MSR, so it's entirely possible that I'd find both UIs completely frustrating...
Setting bit 11 of the second VM execution control register will cause RDRAND to cause VMExits when it is executed. This permits it to be trapped by a hypervisor. (Yes, I did have to look that up)
Don't trust a VM that traps RdRand. It is out to get you.
Not necessarily. A high-availability hypervisor will trap on this instruction to ensure that only one of the VMs actually gets a random number and the others all get the same value propagated to them. They will do the same with RDTSC, for the same reason.
If however they're defending the theory of AGW then there's clearly no conflict of interest is there?
Most of the 'fossil-fuel companies' are actually energy companies now, and will happily sell you solar panels, wind generators, and so on, and be the first in the queue for government subsidies on these things. There's a conflict of interest when they make claims in both directions, the difference is that in one case they are making the same claims as people with less of a conflict.
Oh. Would you care to point me to the hoards of level headed climate activists who say this about Hurricane Katrina or Sandy?
You're misunderstanding how science works and what the claims were. You make a prediction (e.g. pumping loads of extra energy into a chaotic system will cause more extreme weather) and you then look at the new data to see what it does to your hypothesis. Each data point will do one of three things:
Fit with your predictions, and therefore strengthen your hypothesis.
Not fit with your predictions, but within your predicted error margins, and so have no impact on your hypothesis.
Fit completely outside your predictions, disproving your hypothesis.
The scientists you are referring to are saying that they have more data points in the first category when these events happen. They don't conclusively prove their hypotheses (but then, that never happens in science), but they do lend it some extra weight.
If we assume that CO2 was the sole cause of warming in the last 130 years and nothing else was going on
No one is claiming this. There's a reason why these models take very large compute clusters to run: they have a huge number of variables and input data from a very large number of experimental inputs.
It depends on the complexity of the format. I have some WordStar 1.0 for DOS files, and I don't have a program that an open them, but if you look at the contents they're basically ASCII plus some escape characters, and I can make a reasonable guess about what the escape characters mean if I ever care enough to recover the data (since it's school work from when I was a small child, I don't care all that much). If you have set of fixed-size records in ASCII or EBCDIC, they're still easy to decode now even if they were written in the '70s (as long as you moved them onto newer media over the intervening time). If you have PCM data, the same applies: it's a trivial format, so as long as you have the raw bitstream it's easy for someone to reconstruct it. I used to have a Windows 3.11 application that was designed for audio editing, and it had a mode to open files that either had no header, or had a corrupted header, which let you select sample rate, bits per channel, endian, and a few other things, and it would open them: it may take an hour of futzing with settings to work out exactly which data layout you have, but it's a fairly trivial problem.
It's different for film, because getting video down to a manageable size requires some compression, which is much harder to reverse engineer. Fortunately, there are comparatively few common formats for video editing to choose from.
I use VirtualBox, although most of my colleagues use VMWare, so I get to compare them fairly regularly. They're not that far apart (not enough for me to bother getting VMWare, anyway), but there are a few places where VirtualBox lacks:
USB passthrough is flakey. Sometimes it works fine, sometimes it manages to put the host's USB stack into a state where it needs a reboot to fix (or possibly unloading and reloading the few dozen kexts that make up the Apple USB stack).
The DHCP service is annoying and directly forwards the DNS address rather than providing a proxy, so when you move between networks DNS stops working.
I don't run Windows in my VMs, but apparently if you do then VMWare has better support for integrating the apps with the host system.
VMWare is a lot better at memory management. It allocates memory using the normal userspace heap and so VMs can be swapped out when they're idle and it does some deduplication of memory. In contrast, VirtualBox just wires the entire VM's memory, so you end up with 2GB less available memory for everything else if you have a 2GB VM.
VirtualBox uses Qt, which is a way of writing applications that don't behave even vaguely like native ones. This is a minor nit, but a more significant one is that a bug in Qt means that a laptop with both integrated and discrete graphics will always stay using the discrete one if the VirtualBox control panel is running.
A related bug in the crappy Qt interface means that it will interrupt shutdown if the control interface is running (even if no VMs are).
For me, VirtualBox is Good Enough, but there's definite room for improvement and so I can understand why other people would pay for VMWare. I did pay for Parallels back when 2.0 came out, to run on my shiny new first-generation Core 2 MacBook Pro. It caused host kernel panics on a regular basis, which turned out to be due to their misreading of the Intel IPI documentation. They wanted me to pay for Parallels 3 to get the bug fix, so I will never give that company any money ever again.
Cortex A7 is not ARM's flagship performance chip, but it's pretty respectable. It's basically a tweaked Cortex A8, with the instruction decoder updated to be compatible with the A15 extensions and the layout optimised for better power consumption. It's still in-order, but it's dual-dispatch and gets similar performance to the A8 clock-for-clock in a much lower power envelope. My current phone has a single-core 1GHz Cortex A8, and it's starting to feel a little slow for a few things, but it's not exactly crawling.
The Krait is an A15, which does have a much higher IPC than the A7, but at the expense of power consumption. Four A7 cores, at the same clock speed, will draw slightly less power than one A15 core. For a tablet, I'd definitely be more interested in an A15 (or a big.LITTLE with both), but for a phone the A7 is probably a better choice.
Sure, whitespace is significant, but I've never had it break easily or be "brittle" as you say
The Jabber Python MSN transport shipped with an intent bug in an error path for several releases. The error path was never hit on the developer's test machine, but always hit for me because I didn't install one of the optional libraries. The error was caused by mixing tabs and spaces, and so looked correct in the editor, but Python happened to interpret a tab as a different number of spaces to the editor[1] and so it ended up doing something different.
This is what people mean when they call it fragile. You can introduce bugs as a result, but never see them unless you hit the code path in question (this, by the way, is a common source of exploitable bugs in all languages: code paths that are rarely hit that contain bugs, and Python makes them so easy to introduce). Meanwhile, in any language that either enforced the no-mixing-tabs-and-spaces rule with static checking[2], or which had a block delimiter character, these would be caught statically at parse time.
I can think of no other language where such a high proportion of code that I've run that has shipped as working releases has needed me to fix it before it will even start. As far as I can tell, all of the refugees from VB6 ended up writing shoddy Python code. Is it the language's fault? Well, it certainly doesn't help. I've been asking Python programmers for the last year what an else clause on a for loop meant. Last Friday, one gave the correct answer for the first time. Why do I know what it means? Because a person who wrote some (and shipped) some code using it apparently didn't...
[1] Ignoring Python's general hostility to using the character that means 'indent by one level' for indents, any language with significant whitespace that doesn't error when you have a line that has both tabs and spaces at the start of a line is broken.
[2] I believe that Python now has an option to check this. It should have been on by default since the first release.
I've been paid to work with the Python interpreter before. If Coverity only found one use-after free, then either the quality of the code has dramatically improved in the last three years, or Coverity is slipping...
Slashdot Mirror
And for most single-user uses, that's fine. I just kicked off a run of the LLVM test suite, since it was the first thing I could think of that would cause a lot of I/O. It was doing 1000 random reads and 500 random writes per second on my (two-year-old) laptop's SSD. It wasn't a great benchmark, because it was CPU limited, even with a quad-core i7, but that's largely the point of the SSD: the CPU is now the bottleneck, whereas with my old machine (spinning disk and Core 2 Duo), the same operation was I/O limited, even with a CPU less than half the speed.
Hmm, my drives send me emails when they start having problems. (And having gotten one of these emails a few years after setting up the drive initially, I was shocked to find it the email arrived in plenty of time. I pleasantly surprised to find the drive and all data still intact, and had time to swap a replacement into the raid).
There was a paper from Google about 18 months ago that showed that, while SMART errors do usually mean the disk will fail, lack of SMART errors does not mean that the disk is not about to fail. In a large number of cases, the drives failed with no warning.
The noise is also something of a red herring. I have a laptop whose drive started to make slightly worrying noises about 2 years ago, but which hasn't died (yet). I've also had several hard disks die with no warning at all. Sometimes, the failure correlates with hearing an odd noise first, but often it doesn't.
I've had three hard disks fail, none of them was in a state where any data was readable. My university computer lab at the time had about half of the drives fail within 18 months of purchase, all with the same failure mode. So I guess you were luckier. I've not had any SSDs fail yet, but I only have one and it's only about 2 years old, so there's still a lot of time...
FedEx is a company that I will avoid at all costs. I lost about half a day chasing them because they'd reported me to a debt collecting agency over an unpaid delivery. There were only two problems with this: paying for the delivery was not my liability (I hadn't signed anything) and they actually were paid by the people who were supposed to pay (who had a corporate account and a FedEx account number that deliveries could just be charged against). FedEx admitted this to me after the first time they wrote to me telling me that there was an unpaid debt, and issued me with a credit note for it. Unfortunately, they somehow managed to get the delivery entered into their accounting system twice and so they closed one as paid and then sent the other to a legal firm.
The R in RAID-0 does stand for redundant. As in 'the person who made the decision to use RAID-0 on our infrastructure has just been made...'
Controller failures are usually easy to fix. The controller on most disks is on a board on the outside that can be unscrewed and replaced. If you find another drive (often cheap, second hand) of the same make and model you can switch them across. I wouldn't recommend doing anything with the drive other than dumping the data when it's in this state, however...
That said, I completely agree. Stuff that is on a single drive is stuff that you don't care about.
You're the second post I've seen on this article conflating 10x the productivity with 10x the amount of code written. There's very little correlation between the two, which is why IBM learned that paying bonuses per line of code results in terrible code. The developers who are ten times as productive are the ones that spend the time understanding the requirements and then write code that does a good job of solving the problem at hand. They don't spend time writing hand-optimised versions of code that is not on the critical path, and they don't waste effort writing complex general solutions when their code is only going to need to handle one input. They do document their work and they do ensure that it's easy to refactor when the requirements change, because they've learned that the poor sap who will have to change it in a year's time is probably them.
With ThunderBolt, you have enough bandwidth for all of those things, although power is still another connector. That said, you should look for third-party docking stations. Even though specialised docking station connectors are now rare, it's fairly common for after-market designs to exist, which have a bar that lines up with all of the ports on the machine and allow you to just slot the machine in. I'd love to have a machine without even that, and just an inductive charger and near-field communication so I put it down on the desk and it starts working with everything else there, but that's a little way away.
Oh, and you probably have an unusually well-designed docking station. My experience with my father's old laptop was that it was more fiddly to get the docking right than to just plop the machine down on the desk and plug in a few cables. The ease of docking varies quite a lot between manufacturers.
Tarballs make me think of shitty sourceforge days. Packages OTOH can be nice.
Tarballs are the input for most packaging systems. If you don't publish a tarball, then I have to create one before I even start packaging your code. So you get moved to the bottom of my list. And that's probably fine for a fast-moving project, where you don't want people running an old version and sending reports for bugs that are already fixed, but for a more mature project make sure you make life easier for packagers. That means:
If you provide all, or even most, of these then I can probably package your software in 5-10 minutes.
The tarball is not for casual users. The tarball is for packagers. Having a stable tarball (i.e. one with a published URL whose hash won't change between downloads) makes it much easier to create the package.
What's in it for them? The point of releasing open source code is not to gain users, it's to gain contributors. If you're someone for whom having to download a tarball and build it is too high a barrier to entry, then you're probably not someone who is likely to contribute patches either (and if you don't already have a dev environment set up, then you're almost certainly not going to contribute code). Given that they have limited time to spend on the project, does it make more sense to spend that time catering to you, or to people who will build from source?
Contrarily to what seems to be a popular belief on Slashdot, x86 and ARM aren't the real issue, it's the designs themselves which come from very different backgrounds
There's some truth in that, but a lot is intrinsic to the instruction set.
The first round of RISC vs CISC was won by RISC, because they used very simple instruction decoders, whereas CISC chips had 20-50% of their total die area taken up with the decoding logic. This meant that, for the same transistor budget, a RISC chip could spend a lot more of it on execution units.
Then, as dies became bigger, CISC started to gain because they could do things like divide in hardware, rather than as a microcoded loop, whereas RISC was still expanding the sequence in the compiler or assembler. RISC chips needed to modify their instruction sets to keep up. Those complex addressing modes in CISC chips started to be folded into single-cycle operations as part of the load pipeline, whereas the RISC equivalents were sequences of operations with lots of pipeline dependencies between them. Most of the surviving 'RISC' architectures (e.g. PowerPC) were quite CISCy by this point.
Then CPUs got faster than memory and so instruction cache pressure and so the variable-length instruction encoding became a benefit because instruction cache misses became very expensive and so having a smaller instruction cache with the same miss rate meant that you could have more execution units for the same transistor budget. The size of the cache became greater than the size of the decoder as time went on.
So why doesn't this apply to ARM? First, ARM has managed to keep their instruction set simple and orthogonal (so very cheap to decode), but also very expressive. All memory operations have a register, an immediate offset, and a shift, so you get quite complex addressing modes without needing a complex decoder. Thumb-2 is a variable-length instruction set, but a very simple one (instructions are all 16 or 32 bits, with a cheap way of distinguishing them) and one designed to make the instructions that compilers commonly emit shorter. It gives similar code density to x86, but with a much cheaper decoder.
Why does the decoder size still matter? Because the decoder is one of the only parts of the chip that has to be powered all of the time[1]. The name of the game today is trying to turn off as much of the CPU as possible. Power consumption per transistor has not been dropping nearly as fast as transistor densities have been increasing, so if you want to stay within your thermal envelope then you get more transistors to play with each generation, but you can power a smaller subset of them at any given time (this is called the Dark Silicon Problem by those in the industry).
Many of the tricks that Intel can do involve having a complex decoder and then a reordering and micro-op fusion sequence in their pipeline. These give a significant performance advantage at the high end, but also place a lower bound on their power consumption. Newer additions, like hardware transactional memory, come at a similar power cost: HTM requires a lot more logic in the cache controller, which means more always-on power consumption. It will probably give an overall performance/Watt advantage when the CPU is under full load in a large multicore setup, but in a single-socket system with moderate load you'll end up burning more power.
It's quite telling that the power consumption figures for Haswell, for a 1.5GHz single-core chip are in the same ballpark as a 1.5GHz quad-core Cortex A15 SoC (including 72-core nVidia GPU, under load).
[1] In tight loops, high-end Intel chips will power gate the decoder and just read from the micro-op cache, however the micro-op decoder is still powered and is about as complex as an ARM decoder.
DEC screwed the pooch on that one, no doubt; they priced it as a high-end workstation chip, and lower-priced commodity PC hardware running x86 ate their lunch.
I remember adverts for Windows NT PCs with Alpha chips, and they weren't that much more expensive than Intel. A Pentium Pro machine could easily set you back more and still be slower if you were running native code. That last bit was the killer: there was almost no native Alpha/NT software, not even Microsoft Office or Visual Basic. So you had to run the code in FX32! and then it was significantly slower than native code.
If DEC had really wanted this market, then they should have identified the top 1,000 CPU-intensive Windows applications and ensured that the first 5,000 machines off their production lines were shipped, for free, to the manufacturers, along with an offer of free support for porting software. If things like Photoshop had been ported, then things might have been quite different. Even a $1000 premium on hardware is nothing if it's making your artists spend 10% less time waiting is worth it. And once you've got a reasonable install base of people who are used to paying a lot for hardware and software, it becomes an attractive market for other software developers (at which point you release an Alpha simulator and cross-compile toolchain, which lets people test Alpha code on their x86 systems, albeit at maybe 10% of native speed).
As I recall, Alpha lost the top supercomputer spot over 5 years after the last model was released.
Docking stations used to be very popular. They largely died out when people realised that they were paying $300 to be able to plug in one awkward connector instead of 3 (USB, video, power, possibly network). Back when they were popular, the keyboard was likely PS/2, the mouse was PS/2 or serial, the video was VGA, and you might have also plugged in a SCSI CD ROM or hard disk. Now, they still exist, but they're called monitors. A modern monitor comes with a USB hub (and if you buy an Apple one, either a FireWire or Thunderbolt hub). Your keyboard and mouse are connected to the display, so you just plug in power, a USB cable and a DVI/HDMI/DisplayPort cable and you get all of the benefits of the docking station - some people even have external hard disks and USB network interfaces dangled off the back of the monitor (just don't talk to them about performance). If your laptop and monitor both support Thunderbolt then that single cable is fast enough for display, keyboard, mouse, GigE, and eSATA.
I have an Asus TransformerPadSomethingWhateverTheSillyNameIs and it isn't too bulky as a laptop. The main advantages are that it has a really nice screen (1080p and useable outside on a sunny day) and a battery that lasts 10 hours without even trying to keep power consumption down, closer to 15 if I reduce screen brightness and so on. In terms of portability, with the keyboard attached it's twice as thick as the tablet, but the same other dimensions, so it's still easy to slip into pretty much anything that's big enough to carry a 10" tablet.
Android is great in the tablet mode, but it really starts to show that it was designed for phones when you start trying to do real work on it. Switching quickly between applications is cumbersome (e.g. if I'm writing something and want to refer to PDF documents or web pages for reference), far more so than on any other OS I've used (WebOS got this a bit better for tablets and I'm still bitter about HP mismanaging it into oblivion). I can see a market for Windows devices with this sort of form factor, and the whole Metro thing almost starts to make sense to me: when the screen's detached, the Android apps are all quite useable, but when it's attached to the keyboard and trackpad I'd like to have more traditional desktop apps available. That said, I've not used Windows on the desktop since Windows 2000 was state of the art and I've not used Metro except for briefly playing with devices owned by some friends at MSR, so it's entirely possible that I'd find both UIs completely frustrating...
Setting bit 11 of the second VM execution control register will cause RDRAND to cause VMExits when it is executed. This permits it to be trapped by a hypervisor. (Yes, I did have to look that up)
Don't trust a VM that traps RdRand. It is out to get you.
Not necessarily. A high-availability hypervisor will trap on this instruction to ensure that only one of the VMs actually gets a random number and the others all get the same value propagated to them. They will do the same with RDTSC, for the same reason.
If however they're defending the theory of AGW then there's clearly no conflict of interest is there?
Most of the 'fossil-fuel companies' are actually energy companies now, and will happily sell you solar panels, wind generators, and so on, and be the first in the queue for government subsidies on these things. There's a conflict of interest when they make claims in both directions, the difference is that in one case they are making the same claims as people with less of a conflict.
Oh. Would you care to point me to the hoards of level headed climate activists who say this about Hurricane Katrina or Sandy?
You're misunderstanding how science works and what the claims were. You make a prediction (e.g. pumping loads of extra energy into a chaotic system will cause more extreme weather) and you then look at the new data to see what it does to your hypothesis. Each data point will do one of three things:
The scientists you are referring to are saying that they have more data points in the first category when these events happen. They don't conclusively prove their hypotheses (but then, that never happens in science), but they do lend it some extra weight.
If we assume that CO2 was the sole cause of warming in the last 130 years and nothing else was going on
No one is claiming this. There's a reason why these models take very large compute clusters to run: they have a huge number of variables and input data from a very large number of experimental inputs.
It depends on the complexity of the format. I have some WordStar 1.0 for DOS files, and I don't have a program that an open them, but if you look at the contents they're basically ASCII plus some escape characters, and I can make a reasonable guess about what the escape characters mean if I ever care enough to recover the data (since it's school work from when I was a small child, I don't care all that much). If you have set of fixed-size records in ASCII or EBCDIC, they're still easy to decode now even if they were written in the '70s (as long as you moved them onto newer media over the intervening time). If you have PCM data, the same applies: it's a trivial format, so as long as you have the raw bitstream it's easy for someone to reconstruct it. I used to have a Windows 3.11 application that was designed for audio editing, and it had a mode to open files that either had no header, or had a corrupted header, which let you select sample rate, bits per channel, endian, and a few other things, and it would open them: it may take an hour of futzing with settings to work out exactly which data layout you have, but it's a fairly trivial problem.
It's different for film, because getting video down to a manageable size requires some compression, which is much harder to reverse engineer. Fortunately, there are comparatively few common formats for video editing to choose from.
For me, VirtualBox is Good Enough, but there's definite room for improvement and so I can understand why other people would pay for VMWare. I did pay for Parallels back when 2.0 came out, to run on my shiny new first-generation Core 2 MacBook Pro. It caused host kernel panics on a regular basis, which turned out to be due to their misreading of the Intel IPI documentation. They wanted me to pay for Parallels 3 to get the bug fix, so I will never give that company any money ever again.
Cortex A7 is not ARM's flagship performance chip, but it's pretty respectable. It's basically a tweaked Cortex A8, with the instruction decoder updated to be compatible with the A15 extensions and the layout optimised for better power consumption. It's still in-order, but it's dual-dispatch and gets similar performance to the A8 clock-for-clock in a much lower power envelope. My current phone has a single-core 1GHz Cortex A8, and it's starting to feel a little slow for a few things, but it's not exactly crawling.
The Krait is an A15, which does have a much higher IPC than the A7, but at the expense of power consumption. Four A7 cores, at the same clock speed, will draw slightly less power than one A15 core. For a tablet, I'd definitely be more interested in an A15 (or a big.LITTLE with both), but for a phone the A7 is probably a better choice.
Sure, whitespace is significant, but I've never had it break easily or be "brittle" as you say
The Jabber Python MSN transport shipped with an intent bug in an error path for several releases. The error path was never hit on the developer's test machine, but always hit for me because I didn't install one of the optional libraries. The error was caused by mixing tabs and spaces, and so looked correct in the editor, but Python happened to interpret a tab as a different number of spaces to the editor[1] and so it ended up doing something different.
This is what people mean when they call it fragile. You can introduce bugs as a result, but never see them unless you hit the code path in question (this, by the way, is a common source of exploitable bugs in all languages: code paths that are rarely hit that contain bugs, and Python makes them so easy to introduce). Meanwhile, in any language that either enforced the no-mixing-tabs-and-spaces rule with static checking[2], or which had a block delimiter character, these would be caught statically at parse time.
I can think of no other language where such a high proportion of code that I've run that has shipped as working releases has needed me to fix it before it will even start. As far as I can tell, all of the refugees from VB6 ended up writing shoddy Python code. Is it the language's fault? Well, it certainly doesn't help. I've been asking Python programmers for the last year what an else clause on a for loop meant. Last Friday, one gave the correct answer for the first time. Why do I know what it means? Because a person who wrote some (and shipped) some code using it apparently didn't...
[1] Ignoring Python's general hostility to using the character that means 'indent by one level' for indents, any language with significant whitespace that doesn't error when you have a line that has both tabs and spaces at the start of a line is broken.
[2] I believe that Python now has an option to check this. It should have been on by default since the first release.
I've been paid to work with the Python interpreter before. If Coverity only found one use-after free, then either the quality of the code has dramatically improved in the last three years, or Coverity is slipping...