Evaluating A yields the address of the first element in the array. Evaluating the address of A also yields the address of the first element in the array.
&A == (int*)&A[0] &A == A (int*)&A[0] == A
All three of these expressions will evaluate to true
B = A; B = (int*) B=&A[0]
The above three statements are all equivalent because array references behave like pointers when they are evaluated as part of an expression.
Unlike pointers, the array reference itself is not assigned memory, only the array elements are assigned memory. The array reference is used as a handle to the first element in the array and all references are resolved at compile time. A pointer can be reseated (assigned a new value), an array cannot.
B = A; is valid
A = B; is not valid
looking at this another way
int A[10]; will consume 40 bytes of memory assuming a 4 byte integer
int* B = malloc(sizeof(int) * 10); will consume 44 bytes of memory assuming 4 byte integers and 4 byte addresses
I'm certain that it's different, but it is not fundamentally different. The person that you responded to did not claim that it is the same environment but rather one that has more or less the same toolset. All of them will still be built around a C-compiler, build tools, and a debugger.
I'd be incredibly surprised if the ruling was carte blanche as you describe. All that we have to go on is one press release and a news report, not the text of the ruling itself, so it's a bit premature to rush to judgement. Many of the stipulations that you suggest were most likely conditions imposed on Microsoft as a part of the ex parte TRO. Even if they weren't required to document some things they would be very wise to do so as it is sure to be brought up at the hearing. In any case, I find it unlikely that Microsoft would want to bite the hand that feeds.
I'm sure that you're absolutely correct about that. The vast majority of no-ip's customers are using the service legitimately, I'm certain of this. However, no-ip has certain legal responsibilities as a service provider and if they don't meet them their legitimate customers may end up getting caught in the crossfire.
For the record, I'm not taking a side as I have no idea what evidence Microsoft presented to get the ruling. I'm just pointing out the legal basis for what occurred.
property used to engage in criminal activity is subject to seizure and/or forfeiture. Domains have been seized in the past due to criminal activity but this has usually accompanied a criminal complaint by a law enforcement agency.
In this case, despite what the article may imply, Microsoft hasn't seized ownership of the domains. Rather, they used an ex parte temporary restraining order to seize control of the domains so that they may neutralize the source of the maliciousness. The ex-parte aspect is why no-ip wasn't notified. Microsoft managed to convince a judge to grant the order without informing the other party (most likely to prevent no-ip from notifying the malicious users). This will be followed up by a formal hearing, and full control of the domains will be restored to no-ip eventually.
If Microsoft abuses this, judges won't be so inclined to grant such requests in the future.
The core elements of PC firmware don't do anything particularly fancy, it's just software that tests components and configures the platform in a way that exposes a consistent interface and an interface itself is not patentable. Most of the heavy lifting is performed by the hardware (which is covered by other patents) and is accessed using documented methods (which is an interface, not patentable). It's unlikely that there would be sufficient novel material in the original IBM PC BIOS to warrant or defend a patent, and it would be rather simple to work around any tricks; as you mentioned, it was reimplemented from IBM's documentation and clean-room reverse engineering.
There are some patents for components that are not elements of the platform interface, such as securing access to, reprogramming, and validating the firmware code.
No, you said that they haven't yet demonstrated anything quantum about it, and I provided you with a link proving otherwise.
It may not be more useful, compact, or flexible than an existing well known and well optimized method of completing the same task, but neither were early electromechanical machines or some of the earliest digital computers.
In order to qualify it as a failed project or a scam you'd need to clearly demonstrate that it doesn't do what it claims to do, not that it doesn't do it as well as you expected. Give it a few years and a few more iterations, if it shows no meaningful improvement then that claim can be revisited.
Using quantum annealing to solve non-linear multivariate optimization problems is theoretically faster than using traditional turing computation. It definitely needs more development to overcome a normal workstation or supercomputer, but it will most likely happen eventually.
Researchers have been able to experimentally prove the existence of quantum entanglement in a quantum annealing processor which is supposedly a subset of the design that D-Wave employs
Some people are also retarded. Try redesigning a first person shooter for a touch screen. Every touch-screen FPS I have tried is beyond terrible, requiring tons of aim assist and alteration of game mechanics to suit the reduction in player control. Removing content or mechanics to suit an unsuitable control scheme is not "redesigning" anything, it's crippling it.
Not necessarily. Smartphones and tablets handle traditional control schemes very poorly. Try playing an FPS on a smartphone, or anything that requires a degree of precision and/or responsiveness. If a game can be designed/redesigned for a touch-screen interface, great. However, many genres simply play better using mechanical controls and the PSP excels at this.
It is indeed a manufactured issue but that doesn't mean that it's not an issue worth considering or addressing. Companies that operate solely through hiring "the person most qualified for the job" can fall victim to tunnel vision.
That's possible, and I wouldn't be surprised if some do, but it is my understanding that most cheats inject themselves into the program code at runtime rather than replace the program code entirely. It may be more appropriate to say that they are carefully crafted to work with the copyrighted binaries rather than ship with the copyrighted binaries themselves.
SMT on a dynamically scheduled architecture requires resolving and tagging data dependencies between instructions from two or more contexts as those instructions enter the reservation station, are dispatched to execution units, and eventually enter the reorder buffer. Speculative and cancelled instructions also need to be resolved from two or more contexts at once. That's not particularly easy to do, and the difficulty grows with the number of execution ports and accompanying execution units. Intel has been working at this for many, many years. Even when HT was not used in x86 (Core 2 era) it was being developed into the Itanium family of microprocessors.
If the ideality condition for efficiency is having all backend execution ports busy on every cycle CMT can theoretically reach parity with SMT by having a demanding thread running on each logical processor and without other factors such as cache latency becoming a bottleneck (assume ideality on these). However, outside of synthetic benchmarks this is incredibly hard to accomplish. As soon as one thread blocks (IO syscall for example) or enters a long-latency event (page fault for example) the operating system can either toss the thread on the waiting queue and context switch, or simply do nothing and issue stalls until the event is resolved. Excessive context switches cause overhead, and should be avoided, and stalls are inefficient by definition. If no context switch is performed, the CMT frontend must stall which means that the backend execution units will be idled. A SMT frontend must also stall, but the backend execution units may still be used unless the complementary thread also encounters a long-latency event.
Intels performance advantage most certainly does erode when highly-concurrent tasks are employed, but AMD's microprocessors require significantly more transistors and significantly more power to obtain the same level of performance.
Slashdot Mirror
Imagine the following:
int A[10];
int* B = 0;
Evaluating A yields the address of the first element in the array. Evaluating the address of A also yields the address of the first element in the array.
&A == (int*)&A[0]
&A == A
(int*)&A[0] == A
All three of these expressions will evaluate to true
B = A;
B = (int*)
B=&A[0]
The above three statements are all equivalent because array references behave like pointers when they are evaluated as part of an expression.
Unlike pointers, the array reference itself is not assigned memory, only the array elements are assigned memory. The array reference is used as a handle to the first element in the array and all references are resolved at compile time. A pointer can be reseated (assigned a new value), an array cannot.
B = A; is valid
A = B; is not valid
looking at this another way
int A[10]; will consume 40 bytes of memory assuming a 4 byte integer
int* B = malloc(sizeof(int) * 10); will consume 44 bytes of memory assuming 4 byte integers and 4 byte addresses
The DHS was created in large part to address the inability of other agencies to communicate and work together.
Is Deus Ex merely considered "solid work" now?
I'm certain that it's different, but it is not fundamentally different. The person that you responded to did not claim that it is the same environment but rather one that has more or less the same toolset. All of them will still be built around a C-compiler, build tools, and a debugger.
I think that you may be off by a few decades
Excellent find. Thank you
I'd be incredibly surprised if the ruling was carte blanche as you describe. All that we have to go on is one press release and a news report, not the text of the ruling itself, so it's a bit premature to rush to judgement. Many of the stipulations that you suggest were most likely conditions imposed on Microsoft as a part of the ex parte TRO. Even if they weren't required to document some things they would be very wise to do so as it is sure to be brought up at the hearing. In any case, I find it unlikely that Microsoft would want to bite the hand that feeds.
I'm sure that you're absolutely correct about that. The vast majority of no-ip's customers are using the service legitimately, I'm certain of this. However, no-ip has certain legal responsibilities as a service provider and if they don't meet them their legitimate customers may end up getting caught in the crossfire.
For the record, I'm not taking a side as I have no idea what evidence Microsoft presented to get the ruling. I'm just pointing out the legal basis for what occurred.
Second level domains are controlled through top level domains. Do you know nothing about DNS?
property used to engage in criminal activity is subject to seizure and/or forfeiture. Domains have been seized in the past due to criminal activity but this has usually accompanied a criminal complaint by a law enforcement agency.
In this case, despite what the article may imply, Microsoft hasn't seized ownership of the domains. Rather, they used an ex parte temporary restraining order to seize control of the domains so that they may neutralize the source of the maliciousness. The ex-parte aspect is why no-ip wasn't notified. Microsoft managed to convince a judge to grant the order without informing the other party (most likely to prevent no-ip from notifying the malicious users). This will be followed up by a formal hearing, and full control of the domains will be restored to no-ip eventually.
If Microsoft abuses this, judges won't be so inclined to grant such requests in the future.
The core elements of PC firmware don't do anything particularly fancy, it's just software that tests components and configures the platform in a way that exposes a consistent interface and an interface itself is not patentable. Most of the heavy lifting is performed by the hardware (which is covered by other patents) and is accessed using documented methods (which is an interface, not patentable). It's unlikely that there would be sufficient novel material in the original IBM PC BIOS to warrant or defend a patent, and it would be rather simple to work around any tricks; as you mentioned, it was reimplemented from IBM's documentation and clean-room reverse engineering.
There are some patents for components that are not elements of the platform interface, such as securing access to, reprogramming, and validating the firmware code.
That's the gist of what D-Wave's designers were complaining about.
Here's an interesting work published by IBM that looks at some particularly hard problems
https://www.ibm.com/developerw...
No, you said that they haven't yet demonstrated anything quantum about it, and I provided you with a link proving otherwise.
It may not be more useful, compact, or flexible than an existing well known and well optimized method of completing the same task, but neither were early electromechanical machines or some of the earliest digital computers.
In order to qualify it as a failed project or a scam you'd need to clearly demonstrate that it doesn't do what it claims to do, not that it doesn't do it as well as you expected. Give it a few years and a few more iterations, if it shows no meaningful improvement then that claim can be revisited.
Not necessarily.
Using quantum annealing to solve non-linear multivariate optimization problems is theoretically faster than using traditional turing computation. It definitely needs more development to overcome a normal workstation or supercomputer, but it will most likely happen eventually.
Researchers have been able to experimentally prove the existence of quantum entanglement in a quantum annealing processor which is supposedly a subset of the design that D-Wave employs
http://arxiv.org/pdf/1401.3500...
No, it's simply a case of pitting a very immature technology against one that's very mature.
Some people are also retarded. Try redesigning a first person shooter for a touch screen. Every touch-screen FPS I have tried is beyond terrible, requiring tons of aim assist and alteration of game mechanics to suit the reduction in player control. Removing content or mechanics to suit an unsuitable control scheme is not "redesigning" anything, it's crippling it.
Not necessarily. Smartphones and tablets handle traditional control schemes very poorly. Try playing an FPS on a smartphone, or anything that requires a degree of precision and/or responsiveness. If a game can be designed/redesigned for a touch-screen interface, great. However, many genres simply play better using mechanical controls and the PSP excels at this.
It is indeed a manufactured issue but that doesn't mean that it's not an issue worth considering or addressing. Companies that operate solely through hiring "the person most qualified for the job" can fall victim to tunnel vision.
Linus Torvalds vs Theo de Raadt would make for a pretty sweet rap battle
They'd be fine. The AGM-69 was decommissioned in the early 90s.
Lots of companies are rolling out Server 2012. Windows 8.1 workstations are following slowly but surely
That's possible, and I wouldn't be surprised if some do, but it is my understanding that most cheats inject themselves into the program code at runtime rather than replace the program code entirely. It may be more appropriate to say that they are carefully crafted to work with the copyrighted binaries rather than ship with the copyrighted binaries themselves.
SMT on a dynamically scheduled architecture requires resolving and tagging data dependencies between instructions from two or more contexts as those instructions enter the reservation station, are dispatched to execution units, and eventually enter the reorder buffer. Speculative and cancelled instructions also need to be resolved from two or more contexts at once. That's not particularly easy to do, and the difficulty grows with the number of execution ports and accompanying execution units. Intel has been working at this for many, many years. Even when HT was not used in x86 (Core 2 era) it was being developed into the Itanium family of microprocessors.
If the ideality condition for efficiency is having all backend execution ports busy on every cycle CMT can theoretically reach parity with SMT by having a demanding thread running on each logical processor and without other factors such as cache latency becoming a bottleneck (assume ideality on these). However, outside of synthetic benchmarks this is incredibly hard to accomplish. As soon as one thread blocks (IO syscall for example) or enters a long-latency event (page fault for example) the operating system can either toss the thread on the waiting queue and context switch, or simply do nothing and issue stalls until the event is resolved. Excessive context switches cause overhead, and should be avoided, and stalls are inefficient by definition. If no context switch is performed, the CMT frontend must stall which means that the backend execution units will be idled. A SMT frontend must also stall, but the backend execution units may still be used unless the complementary thread also encounters a long-latency event.
Intels performance advantage most certainly does erode when highly-concurrent tasks are employed, but AMD's microprocessors require significantly more transistors and significantly more power to obtain the same level of performance.
Egh, if they really want to deter robberies they should pack them with high explosives and shrapnel.