I must have missed the weaponized uncontrolled faster-than-light explosion 60 years ago that proved the basic principles in an artificial device, and the whole thing being consistent with generally known physics.
Constructing a warp drive would require new basic science. Getting a fusion reactor working with an energy gain might require specific discoveries and a lot of hard engineering, but it's not inconceivable in any way. I also think the recent interview with the Alcator C-Mod guys here at/. made the point that the "failures" for at least the last 40 years have been the failures of funding agencies to provide the resources that the researches expected to be needed all along. ITER will be better know compared to if it had been built 20 years ago (new insights, better materials, better resources), but the basic design for what was needed to evaluate the next level of tokamaks concepts was there that long back.
No, it is Office alright. Maybe with some touches to the interface, and you can forget about getting anything relying on a 3rd party COM object to work, but it is Office recompiled. It will be closer to Office on x86 Windows than Office on Mac ever was. (Yeah, even in the disastrous times when Macintosh Office was all piped through some weird Win32 emulation...)
Windows on ARM is far closer to Windows 8 than Windows CE ever was to NT. CE was a clean-slate implementation, maybe borrowing some NT code. Windows on ARM seems to be more similar to something aking to XP Home or Media Center Edition, with the extra twist of another architecture and an arbitrary group policy decision (it's nothing more, really) not to allow third-party binaries in the traditional Windows GUI (e.g. only Metro apps). It is even so that Win32 API calls will be allowed for some Metro apps, including web browsers, even on ARM.
So, in the end, it is a marketing and feature set decision. Apple has been successful with the walled-garden approach, and that's what Windows RT will be marketed as, with the slight bonus of offering the "real" Microsoft Office.
In other words, at the very least, the dynamic languages will have to do a table lookup and then call the function, as opposed to just calling the function.
.Net and the JVM also do that.
Not true. In Java, methods are virtual by default, so there is some truth there. However, the JIT in the JVM will frequently be able to infer the true actual type and inline or at least do away with the vtable lookup. In.Net, the default is non-virtual methods, but even when methods are virtual, the same facts about type inference hold. In fact, these are reasons for why rather OOP-heavy designs might perform faster in.Net/Java than in C++ (unless you compile your C++ with profile-guided optimizations) - so many possible inferences and optimizations are only possible with the runtime binding information.
The same binary on the same platform (x86 in this case) will render the same results. That's part of the contract of the x86 ISA. However, unless you're using/fp:strict or equivalent in your compiler, just recompiling with ANY kind of changes can alter behavior.
Remember the early PIII era? What fun that was, until AMD got competitive again.
As far as I'm concerned Intel went straight from Pentium 2 to Core 2. Whatever that crap was in between, it sure wasn't the product of an industry leader.
Coppermine, the little L2 that could. First released just before the Athlon and staying competitive by rapidly racing from 500 MHz or so up to 1 GHz.
It's hard to say what is timing, what is product perfection, and what is good marketing. I remember being at a Nokia event in 2001 (basically "what are our future products as a recruiting event"). True, they talked about different concepts, including augmented reality and HUD solutions, that haven't taken off. But they certainly also talked about always-connected rich finger touch big-screen devices.
What was most striking at that event, however? I was the only one in the group I was in that thought the new devices seemed cool, and this was in a techy audience. Most phones only had circuit-switched data at this time, still going on basic WAP. Since then, we got cameras and MMS, HTML browsers, although limited. Most of these additions were also frowned upon by rather large groups, "why would I want a camera". And yet, they became commonplace. Only at that point did Apple release a smartphone which got a capacitive touch interface right. But even if capacitive touch had been available at a reasonable price point five years earlier, the market itself would not have been ready.
I can only guess that Nokia used focus groups more similar to my friends and concluded that a slow, gradual entry, focusing on niche devices, would be much easier on their R&D budget and result in higher sales. That held true for a number of years...
Considering that the data part of Thunderbolt is basically a different physical layer for PCIe, it should be very simple to handle. I guess, though, that it will be quite possible to do Really Stupid Stuff where the added latency compared to a motherboard PCIe board is enough to cause trouble. On the other hand, the latency is positively fantastic compared to what you can achieve with USB.
...And it had better be changing in magnitude, or else we wouldn't get Magnetic Resonance Imaging out of it!
...
The resonance isn't caused by changing magnitude in the main field (B0), which is the strong field here. By imposing a static, homogenous magnetic field, however, the nuclear spin states separate slightly in energy. If you send a RF pulse with the right frequency, you can observe resonance back, caused by the excitation between the states. Matter rich in 1H nuclei (like water) will show more resonance, detected in the receiver coils.
I think another scenario is more interesting: brand and location awareness. Make the driver pass by retailer X once, or once every n months. Not every trip. Immediate "click-through" equivalent will be low, but the driver might spontaneously go back to the same place to get the service offered at some other time. Getting one additional regular customer out of (let's say) 500 such occasional drive-bys can be worth it, even with the numbers you cite.
Kepler is observing the dimming of the light of the star (basically a part of the star disc is shadowed by the planet), when the planet transits directly in the line of sight between Kepler/Earth and the star. Hence, you can get a cross-section area, and by assuming the planet to be reasonably spherical (a fair assumption), you get the volume.
I think there is a dent even in the simulated one. Remember that these 2D visualizations are only representations of the 3D densities. Where you put your cutoff for surfaces, or in this case, where you put the steepest slope in your grayscale definition, can influence the perceived shape a lot more than what is actually the case.
You are assuming there are no holes in the protocol. How is the ID pairing truly done? Is it possible to do some kind of hardware reset over the wireless interface, either by design or by an implementation flaw? Is the ID sent in clear, or is there some proper handshake going on? If there is a cryptographic handshake, is it based on a single common certificate? (Reverse engineering one remote would then still be enough to spoof the ID of any other.)
If the secret of the ID itself is supposed to maintain security, how many requests can be sent in a certain timeframe. Can the pump be fooled to drain its battery receiving bogus wireless messages? There are so many possible attack venues. That does't mean this is necessarily a bad thing, but a high-level understanding of how the system is supposed to work hides so many possible ways to circumvent it.
And suddenly you have a whole different bag of problems. Even just sequencing genomes have frequently been done by putting huge parts of human DNA into yeast or other hosts as a method for amplification and storage. Are the yeast cells human? No. Is a mouse with a single human gene (maybe a disease allele) human? No, and your suggestion would seriously hamper research. Is a bacterium with a human or rather human-derived insulin gene human? No.
On the other hand, is there a problem if one would create e.g. the equivalent of a geep (a sheep-goat chimera, really two distinctive cell lines constituting different parts of the same body) from chimp and human lines? I would definitely think so. The tipping point is not too clear, and that's really the problem here. "Any creature with human DNA" is far too broad, so what criterion should we use.
And during those times when the sun is not hitting right on, a black surface will generally emit, you guessed it, more black-body radiation. (However, the real issue at hand then is the emission/(re)absorption properties in IR instead, but many black surfaces are black in IR and FIR as well, and the opposite holds for many white ones.) In short: staying black will not keep you warm, unless there is a lot of radiation around to absorb.
Quite a few modern chargers are active and adapt their power draw. Many are completely cool to the touch when nothing is connected. Generally, these chargers are also lighter, because they do not have the massive iron windlings of traditional transformers.
I now those "over here we do it like this" responses are tedious, but my Swedish bank authenticates with an external device generating a one-time code. Each "important" transaction is also signed by entering a number into the device and keying in the resulting code. The nice twist? The number you enter into the keypad are not random, they are instead the actual amount of money changing hands, or the destination account number. When you are keying in something, you should note if it's not right.
True, this decreases the cryptographical effectiveness - the confirmation code for amount X or account Y is the same each time (no clock in the device AFAIK), but as this is added after the first sign-in, I think it's a fair secondary precaution. Adding a reasonably well-adjusted clock would allow for some further security in actually signing the amount and the time for the transfer, with the same interface to the user.
What is also against is the current state of battery technology, i.e. we don't expect a stable fleet-wide solution to be based on current technology. Investing in standard form factors, designing drivetrains for their respective power delivery characteristics will just seem stupid.
It's a bit like where we would be if we had at this moment just discovered petroleum as a viable engine fuel, but for some reason what we actually have in production is tar. Tar has terrible viscosity and it doesn't make a very good fuel, so now the options are to create a full infrastructure creating future fuel lock-in, or handle this a special case while volumes are low and standardize on something sensible later on.
It might pay for itself in a few years of continuous use
I think you're missing a factor of two somewhere. Wouldn't you want the buffer to average out to half-full over the long run? What good is a constantly filled buffer?
The energy grid, at this point, has a lot of possible sources for sudden rises in demand (time-bound peaks, but also suddenly failing production facilities), but very few sudden rises in supply. From that perspective, it makes all sense to target full charge with the exception of the minutes when it's actually used.
Is there a reason ActiveX is being used in software that controls critical infrastructures? I don't want to jump to conclusions, but that seems almost as silly as a Security Consulting firm that doesn't test their own website for security holes.
Yeah. That way, you can build "rich" VB apps on top of the control developed by the vendor. What good is a control system if you can only control it through one single fixed-function Windows application?
But it would also be if someone sent some other semi-safe file (a Word document, for example), where the control was embedded. And, depending on security zone settings (scripting is disabled for local files by default in IE these days), a HTML file on some physical medium would suffice as well.
If you are indeed reading from something like an SSD, the data bandwidth shouldn't be a problem. The data pipe to any recent GPU is much wider than SATA, and quite favorable latency-wise as well. Of course, you are adding another layer of latency and transfers, but the situation is quite different from a case where you are offloading some computation whose data could otherwise stay in the CPU cache all the time.
I haven't even finished reading the article yet, but that was the first thing that struck me. Saying "Obviously if the rental car agency was negligent in the maintenance of one of its vehicles and that negligence led to the accident, they might be liable" implies quite clearly that they are a "legitimate potential defendant". The word "potential" is key: nobody's saying that they are guaranteed to be a defendant in the case, only that the may be in certain circumstances - the very same circumstances outlined in the post attempting to refute that line of argument.
Likewise, it could be construed or implied that the IP addresses were not in fact addresses of customers, but of the ISP itself, used for internal operations. Then the ISP is a legitimate potential defendant. Naturally, in most cases it would be easy to state the remote likelihood of a download or hosting actually being done by the ISP, but it is not obvious in all cases. Likewise, in most accident cases where a subpoena is considered, the actual likelihood of the rental agency being at fault is minimal. If they would actually be liable, it will probably be due to reasons of renting the car to someone obviously unsuitable rather than maintenance negligence.
The post is a terrible read, but the author seems to have some valid points nonetheless.
I don't know why, but my impression has been that the UI is actually more responsive in VS 2010 compared to 2008. My personal pet theory has been that GDI+ back-buffering can get slow on very high resolutions (2560 * 1600), while WPF would stack up better. That wouldn't conflict with your theory, though, just that there is some point where VS2010 will overtake 2008 when you have enough graphics power and enough pixels to blit.
Those using animal models also tend to have a, well, limited grasp of statistics. However, they still come out on top because: a) the statistical issues are still simpler when you can control for just about any factor except the ones you are really studying, and, b) since the experimental setups are more standardized, the few people that do grasp statistics have provided tools and rules of thumb that actually work well for the cases where they are used.
Slashdot Mirror
I must have missed the weaponized uncontrolled faster-than-light explosion 60 years ago that proved the basic principles in an artificial device, and the whole thing being consistent with generally known physics.
Constructing a warp drive would require new basic science. Getting a fusion reactor working with an energy gain might require specific discoveries and a lot of hard engineering, but it's not inconceivable in any way. I also think the recent interview with the Alcator C-Mod guys here at /. made the point that the "failures" for at least the last 40 years have been the failures of funding agencies to provide the resources that the researches expected to be needed all along. ITER will be better know compared to if it had been built 20 years ago (new insights, better materials, better resources), but the basic design for what was needed to evaluate the next level of tokamaks concepts was there that long back.
No, it is Office alright. Maybe with some touches to the interface, and you can forget about getting anything relying on a 3rd party COM object to work, but it is Office recompiled. It will be closer to Office on x86 Windows than Office on Mac ever was. (Yeah, even in the disastrous times when Macintosh Office was all piped through some weird Win32 emulation...)
Windows on ARM is far closer to Windows 8 than Windows CE ever was to NT. CE was a clean-slate implementation, maybe borrowing some NT code. Windows on ARM seems to be more similar to something aking to XP Home or Media Center Edition, with the extra twist of another architecture and an arbitrary group policy decision (it's nothing more, really) not to allow third-party binaries in the traditional Windows GUI (e.g. only Metro apps). It is even so that Win32 API calls will be allowed for some Metro apps, including web browsers, even on ARM.
So, in the end, it is a marketing and feature set decision. Apple has been successful with the walled-garden approach, and that's what Windows RT will be marketed as, with the slight bonus of offering the "real" Microsoft Office.
In other words, at the very least, the dynamic languages will have to do a table lookup and then call the function, as opposed to just calling the function.
.Net and the JVM also do that.
Not true. In Java, methods are virtual by default, so there is some truth there. However, the JIT in the JVM will frequently be able to infer the true actual type and inline or at least do away with the vtable lookup. In .Net, the default is non-virtual methods, but even when methods are virtual, the same facts about type inference hold. In fact, these are reasons for why rather OOP-heavy designs might perform faster in .Net/Java than in C++ (unless you compile your C++ with profile-guided optimizations) - so many possible inferences and optimizations are only possible with the runtime binding information.
The same binary on the same platform (x86 in this case) will render the same results. That's part of the contract of the x86 ISA. However, unless you're using /fp:strict or equivalent in your compiler, just recompiling with ANY kind of changes can alter behavior.
Remember the early PIII era? What fun that was, until AMD got competitive again.
As far as I'm concerned Intel went straight from Pentium 2 to Core 2. Whatever that crap was in between, it sure wasn't the product of an industry leader.
Coppermine, the little L2 that could. First released just before the Athlon and staying competitive by rapidly racing from 500 MHz or so up to 1 GHz.
It's hard to say what is timing, what is product perfection, and what is good marketing. I remember being at a Nokia event in 2001 (basically "what are our future products as a recruiting event"). True, they talked about different concepts, including augmented reality and HUD solutions, that haven't taken off. But they certainly also talked about always-connected rich finger touch big-screen devices.
What was most striking at that event, however? I was the only one in the group I was in that thought the new devices seemed cool, and this was in a techy audience. Most phones only had circuit-switched data at this time, still going on basic WAP. Since then, we got cameras and MMS, HTML browsers, although limited. Most of these additions were also frowned upon by rather large groups, "why would I want a camera". And yet, they became commonplace. Only at that point did Apple release a smartphone which got a capacitive touch interface right. But even if capacitive touch had been available at a reasonable price point five years earlier, the market itself would not have been ready.
I can only guess that Nokia used focus groups more similar to my friends and concluded that a slow, gradual entry, focusing on niche devices, would be much easier on their R&D budget and result in higher sales. That held true for a number of years...
Considering that the data part of Thunderbolt is basically a different physical layer for PCIe, it should be very simple to handle. I guess, though, that it will be quite possible to do Really Stupid Stuff where the added latency compared to a motherboard PCIe board is enough to cause trouble. On the other hand, the latency is positively fantastic compared to what you can achieve with USB.
...And it had better be changing in magnitude, or else we wouldn't get Magnetic Resonance Imaging out of it!
...
The resonance isn't caused by changing magnitude in the main field (B0), which is the strong field here. By imposing a static, homogenous magnetic field, however, the nuclear spin states separate slightly in energy. If you send a RF pulse with the right frequency, you can observe resonance back, caused by the excitation between the states. Matter rich in 1H nuclei (like water) will show more resonance, detected in the receiver coils.
I think another scenario is more interesting: brand and location awareness. Make the driver pass by retailer X once, or once every n months. Not every trip. Immediate "click-through" equivalent will be low, but the driver might spontaneously go back to the same place to get the service offered at some other time. Getting one additional regular customer out of (let's say) 500 such occasional drive-bys can be worth it, even with the numbers you cite.
Kepler is observing the dimming of the light of the star (basically a part of the star disc is shadowed by the planet), when the planet transits directly in the line of sight between Kepler/Earth and the star. Hence, you can get a cross-section area, and by assuming the planet to be reasonably spherical (a fair assumption), you get the volume.
I think there is a dent even in the simulated one. Remember that these 2D visualizations are only representations of the 3D densities. Where you put your cutoff for surfaces, or in this case, where you put the steepest slope in your grayscale definition, can influence the perceived shape a lot more than what is actually the case.
You are assuming there are no holes in the protocol. How is the ID pairing truly done? Is it possible to do some kind of hardware reset over the wireless interface, either by design or by an implementation flaw? Is the ID sent in clear, or is there some proper handshake going on? If there is a cryptographic handshake, is it based on a single common certificate? (Reverse engineering one remote would then still be enough to spoof the ID of any other.)
If the secret of the ID itself is supposed to maintain security, how many requests can be sent in a certain timeframe. Can the pump be fooled to drain its battery receiving bogus wireless messages? There are so many possible attack venues. That does't mean this is necessarily a bad thing, but a high-level understanding of how the system is supposed to work hides so many possible ways to circumvent it.
And suddenly you have a whole different bag of problems. Even just sequencing genomes have frequently been done by putting huge parts of human DNA into yeast or other hosts as a method for amplification and storage. Are the yeast cells human? No. Is a mouse with a single human gene (maybe a disease allele) human? No, and your suggestion would seriously hamper research. Is a bacterium with a human or rather human-derived insulin gene human? No.
On the other hand, is there a problem if one would create e.g. the equivalent of a geep (a sheep-goat chimera, really two distinctive cell lines constituting different parts of the same body) from chimp and human lines? I would definitely think so. The tipping point is not too clear, and that's really the problem here. "Any creature with human DNA" is far too broad, so what criterion should we use.
And during those times when the sun is not hitting right on, a black surface will generally emit, you guessed it, more black-body radiation. (However, the real issue at hand then is the emission/(re)absorption properties in IR instead, but many black surfaces are black in IR and FIR as well, and the opposite holds for many white ones.) In short: staying black will not keep you warm, unless there is a lot of radiation around to absorb.
Quite a few modern chargers are active and adapt their power draw. Many are completely cool to the touch when nothing is connected. Generally, these chargers are also lighter, because they do not have the massive iron windlings of traditional transformers.
True, this decreases the cryptographical effectiveness - the confirmation code for amount X or account Y is the same each time (no clock in the device AFAIK), but as this is added after the first sign-in, I think it's a fair secondary precaution. Adding a reasonably well-adjusted clock would allow for some further security in actually signing the amount and the time for the transfer, with the same interface to the user.
It's a bit like where we would be if we had at this moment just discovered petroleum as a viable engine fuel, but for some reason what we actually have in production is tar. Tar has terrible viscosity and it doesn't make a very good fuel, so now the options are to create a full infrastructure creating future fuel lock-in, or handle this a special case while volumes are low and standardize on something sensible later on.
It might pay for itself in a few years of continuous use
I think you're missing a factor of two somewhere. Wouldn't you want the buffer to average out to half-full over the long run? What good is a constantly filled buffer?
The energy grid, at this point, has a lot of possible sources for sudden rises in demand (time-bound peaks, but also suddenly failing production facilities), but very few sudden rises in supply. From that perspective, it makes all sense to target full charge with the exception of the minutes when it's actually used.
Is there a reason ActiveX is being used in software that controls critical infrastructures? I don't want to jump to conclusions, but that seems almost as silly as a Security Consulting firm that doesn't test their own website for security holes.
Yeah. That way, you can build "rich" VB apps on top of the control developed by the vendor. What good is a control system if you can only control it through one single fixed-function Windows application?
But it would also be if someone sent some other semi-safe file (a Word document, for example), where the control was embedded. And, depending on security zone settings (scripting is disabled for local files by default in IE these days), a HTML file on some physical medium would suffice as well.
If you are indeed reading from something like an SSD, the data bandwidth shouldn't be a problem. The data pipe to any recent GPU is much wider than SATA, and quite favorable latency-wise as well. Of course, you are adding another layer of latency and transfers, but the situation is quite different from a case where you are offloading some computation whose data could otherwise stay in the CPU cache all the time.
I haven't even finished reading the article yet, but that was the first thing that struck me. Saying "Obviously if the rental car agency was negligent in the maintenance of one of its vehicles and that negligence led to the accident, they might be liable" implies quite clearly that they are a "legitimate potential defendant". The word "potential" is key: nobody's saying that they are guaranteed to be a defendant in the case, only that the may be in certain circumstances - the very same circumstances outlined in the post attempting to refute that line of argument.
Likewise, it could be construed or implied that the IP addresses were not in fact addresses of customers, but of the ISP itself, used for internal operations. Then the ISP is a legitimate potential defendant. Naturally, in most cases it would be easy to state the remote likelihood of a download or hosting actually being done by the ISP, but it is not obvious in all cases. Likewise, in most accident cases where a subpoena is considered, the actual likelihood of the rental agency being at fault is minimal. If they would actually be liable, it will probably be due to reasons of renting the car to someone obviously unsuitable rather than maintenance negligence.
The post is a terrible read, but the author seems to have some valid points nonetheless.
I don't know why, but my impression has been that the UI is actually more responsive in VS 2010 compared to 2008. My personal pet theory has been that GDI+ back-buffering can get slow on very high resolutions (2560 * 1600), while WPF would stack up better. That wouldn't conflict with your theory, though, just that there is some point where VS2010 will overtake 2008 when you have enough graphics power and enough pixels to blit.
Those using animal models also tend to have a, well, limited grasp of statistics. However, they still come out on top because: a) the statistical issues are still simpler when you can control for just about any factor except the ones you are really studying, and, b) since the experimental setups are more standardized, the few people that do grasp statistics have provided tools and rules of thumb that actually work well for the cases where they are used.