It sounds like they are trying to create a "Streisand effect". Publicise these interesting cases where a link is taken down so that the information is not hidden, but actually spread further.
My colleague is currently designing a C65 in an FPGA, currently running at 28.9x the speed of a C64 but with lots of features still unimplemented. But even designing the hardware at that level, it will be difficult to be completely bug compatible. Particularly since he's driving 1920x1200 video over HDMI.
Anonymising the data just requires replacing each key with something unrecognisable. The GP's suggestion passes the smell test, though I would suggest randomising the list instead of assigning id values sequentially.
Lots of phoronix blog posts have made it to the front page of slashdot and talked about this exact issue. It's only recently that the open source drivers have been gaining momentum and becoming usable for gaming on most GPU's. But they've been fine for desktop work for ages.
Oh, and point 1.5 should have been; Source control!.
When you get something working, commit it. It's like the scientific method, if you can't reproduce something it doesn't exist. Source control gives you confidence to experiment, knowing that you can easily undo everything without losing something that you know works.
Other people have suggested how to learn the basics of a language, so I'll ignore that problem.
Designing and writing good code is an art form. There are many anti-patterns you may fall into that could doom your project that a more experienced developer can help you avoid.
A couple hours a week spent explaining your design before you start writing code, or helping to track down why your code doesn't work as expected, or reviewing the code you believe is finished, will save you days of wasted effort.
Structure your code so that you can write automated tests to cover *everything*. It will seem like a pain to start with. But once your project picks up speed, it will be invaluable to ensure you never break something that you know already works. Tracking down bugs in old code is painful.
If you do this right, you will get into the habit of writing the tests first, or along side the code you are writing. You will find that you rarely run the code as a user would, because that just wastes time. And when you do finally run the code as a user, it just works.
Since this is in the CPU die, it can't add to the I/O throughput of the CPU, unless the code you're running isn't fast enough to saturate the memory bus. Even if your code is saturating I/O you might want to use an FPGA to reduce power consumption.
Any way you set it up, your going to need OS support to reconfigure the FPGA. Perhaps a well defined section in the ELF format, with some kind of locking semantics to prevent more than one process from using it. That would depend on how many FPGA resources / CPU cores you have....
Anyone who is going to spend the money to buy and use these CPU's, will have to solve this problem. For the short term, this is likely to only be used in high end clustered server farms, for workloads where you wouldn't want to swap jobs very often anyway.
IMHO hardware design tools have had far less investment than compiler tools, and we're overdue to invest more effort in improving them.
Since the FPGA is in the CPU, I assume there are either CPU instructions to pipe data in and out of the FPGA. Or the FPGA may have direct access to the memory controller / cache. Either way you need a good way to synchronise between them.
So consider a solution that takes LLVM bitcode and runtime profiling data. Pick out some number of hot code blocks in an optimisation pass, translate the data flow into VHDL (or write something better....) build that, calculate the final circuit timing, replace the code block with new LLVM intrinsics to hand over control, then in the back end emit the new CPU instructions.
Obviously you'll also need to modify the operating system to manage the configuration of the FPGA, and ensure that you don't blow up the chip by running the wrong code at the wrong time.
But I think there is plenty of scope to implement something like this. There just hasn't been a need to build the tools before now.
Bingo. Imagine an LLVM based optimisation pass that uses profiling data to take a hot code block and translate it to run on the FPGA. Anywhere in your implementation where the CPU core is the bottleneck, rather than memory access. And since it's in the CPU, you could shift from running x86 instructions to raw hardware without the complexity and latency increase of piping data to a GPU or other external device.
HDMI was showing it's age the moment it was designed. All of the design and planning behind HD TV's was short sighted, as if they never planned to replace it.
It doesn't work that way. To snatch someone's coins you have to break their private key and produce a transaction signed by it.
You could refuse to include some transactions, or you could spend your own coins twice on two different forks of the block chain. I don't think there are any other ways to game the system.
To break up the key, you could just use Reed Solomon error correction. N bits of key + M extra bits for error correction. Then you break it into numbered pieces. Any combination of pieces that provide N bits can be used for recovery. If you assemble more bits, you can even correct some amount of bit rot.
There's a strong correlation between share price changes and margin loan acceleration. Most of the "growth" of the share market comes from people borrowing money to speculate, not because those companies are producing more value themselves. Of course, what goes up must come down.
You don't need to delay the actual trade. Just delay reporting the order and trade data to even the playing field. That would prevent most uses of HFT.
Once your passive black road has been covered by white snow, you've lost. The sun's energy will bounce off the snow, you have to wait until the ambient temperature rises enough to melt the snow. If you can use some stored energy to melt the snow, you can start absorbing more energy on your black surface to recharge. You may eventually lose the war and run out of stored energy, but you might be able to delay the inevitable.
I'm thinking of Network Coding Meets TCP. Though that doesn't give a great background. I've experimented with my own implementation, but had to shelve it due to lack of time. I'll try to quickly summarise the core idea;
You have packets [p1,.. pn] in your stream's transmission window.
Randomly pick coefficients [x1,..., xn] and calculate a new packet = x1*p1 + x2*p2 + ,.... (in a galois number field, so '+' is an XOR and '*' is a pre-computed lookup table). Sending the coefficients in the packet header.
The receiver collects the packets, and attempts to combine pairs of packets to reduce the complexity of the coefficients. Basically like solving simultaneous equations. That sounds complicated, but the algorithm isn't too hard;
- Keep the current set of packets, sorted by their coefficients. When you receive an incoming packet, you attempt to subtract each of your existing packets which have a smaller coefficient set (again, galois field math). If you're left with nothing, this packet didn't give you any new information, so throw it away.
- Attempt to subtract this new packet from each of the existing packets in your set. Insert your new packet into the list.
When you have a packet with a most significant coefficient of 1. You know you will be able to decode that packet eventually. And you know that you can eliminate that coefficient from any other incoming packet. So you can send an acknowledgement to the sender and they can advance their transmit window. Once you have eliminated all other coefficients you can deliver the packet to the application. Keep each packet in memory until the sender has advanced their window and stopped sending it.
Each incoming packet may eliminate a coefficient from the packets in your list, while at the same time introducing a new one. If you don't send extra redundant packets you may never be able to decode anything. Consider the worst case where every packet is the XOR of two neighbouring packets in the stream, you can't decode anything until you receive a single packet by itself. Sending more redundant packets will reduce the latency to decode the stream while adding to the number of useless packets received.
Slashdot Mirror
Because they *were* 14 billion light years away, and are now probably 46...
"Nobody really buys hammers anymore. ... Everyone is using a general-purpose tool-building factory factory factory".
http://discuss.joelonsoftware.com/default.asp?joel.3.219431.12&
It sounds like they are trying to create a "Streisand effect". Publicise these interesting cases where a link is taken down so that the information is not hidden, but actually spread further.
So new chips could waste die space to include a holographic company logo?
My colleague is currently designing a C65 in an FPGA, currently running at 28.9x the speed of a C64 but with lots of features still unimplemented. But even designing the hardware at that level, it will be difficult to be completely bug compatible. Particularly since he's driving 1920x1200 video over HDMI.
Anonymising the data just requires replacing each key with something unrecognisable. The GP's suggestion passes the smell test, though I would suggest randomising the list instead of assigning id values sequentially.
Lots of phoronix blog posts have made it to the front page of slashdot and talked about this exact issue. It's only recently that the open source drivers have been gaining momentum and becoming usable for gaming on most GPU's. But they've been fine for desktop work for ages.
Oh, and point 1.5 should have been; Source control!.
When you get something working, commit it. It's like the scientific method, if you can't reproduce something it doesn't exist. Source control gives you confidence to experiment, knowing that you can easily undo everything without losing something that you know works.
Other people have suggested how to learn the basics of a language, so I'll ignore that problem.
Designing and writing good code is an art form. There are many anti-patterns you may fall into that could doom your project that a more experienced developer can help you avoid.
A couple hours a week spent explaining your design before you start writing code, or helping to track down why your code doesn't work as expected, or reviewing the code you believe is finished, will save you days of wasted effort.
Structure your code so that you can write automated tests to cover *everything*. It will seem like a pain to start with. But once your project picks up speed, it will be invaluable to ensure you never break something that you know already works. Tracking down bugs in old code is painful.
If you do this right, you will get into the habit of writing the tests first, or along side the code you are writing. You will find that you rarely run the code as a user would, because that just wastes time. And when you do finally run the code as a user, it just works.
Since this is in the CPU die, it can't add to the I/O throughput of the CPU, unless the code you're running isn't fast enough to saturate the memory bus. Even if your code is saturating I/O you might want to use an FPGA to reduce power consumption.
Any way you set it up, your going to need OS support to reconfigure the FPGA. Perhaps a well defined section in the ELF format, with some kind of locking semantics to prevent more than one process from using it. That would depend on how many FPGA resources / CPU cores you have....
Anyone who is going to spend the money to buy and use these CPU's, will have to solve this problem. For the short term, this is likely to only be used in high end clustered server farms, for workloads where you wouldn't want to swap jobs very often anyway.
IMHO hardware design tools have had far less investment than compiler tools, and we're overdue to invest more effort in improving them.
Since the FPGA is in the CPU, I assume there are either CPU instructions to pipe data in and out of the FPGA. Or the FPGA may have direct access to the memory controller / cache. Either way you need a good way to synchronise between them.
So consider a solution that takes LLVM bitcode and runtime profiling data. Pick out some number of hot code blocks in an optimisation pass, translate the data flow into VHDL (or write something better....) build that, calculate the final circuit timing, replace the code block with new LLVM intrinsics to hand over control, then in the back end emit the new CPU instructions.
Obviously you'll also need to modify the operating system to manage the configuration of the FPGA, and ensure that you don't blow up the chip by running the wrong code at the wrong time.
But I think there is plenty of scope to implement something like this. There just hasn't been a need to build the tools before now.
Bingo. Imagine an LLVM based optimisation pass that uses profiling data to take a hot code block and translate it to run on the FPGA. Anywhere in your implementation where the CPU core is the bottleneck, rather than memory access. And since it's in the CPU, you could shift from running x86 instructions to raw hardware without the complexity and latency increase of piping data to a GPU or other external device.
HDMI was showing it's age the moment it was designed. All of the design and planning behind HD TV's was short sighted, as if they never planned to replace it.
How do you know he wasn't listing them chronologically? "1 Intel, 2 Samsung[, 1 don't recall] and 1 Critical. "
It doesn't work that way. To snatch someone's coins you have to break their private key and produce a transaction signed by it.
You could refuse to include some transactions, or you could spend your own coins twice on two different forks of the block chain. I don't think there are any other ways to game the system.
So build an obstacle course between the special "obese people only" parking spaces and the front door...
I'd rather the surgeon was calmed by the appearance of the operating theater. I don't see how deliberately making it ugly would improve the situation.
To break up the key, you could just use Reed Solomon error correction. N bits of key + M extra bits for error correction. Then you break it into numbered pieces. Any combination of pieces that provide N bits can be used for recovery. If you assemble more bits, you can even correct some amount of bit rot.
There's a strong correlation between share price changes and margin loan acceleration. Most of the "growth" of the share market comes from people borrowing money to speculate, not because those companies are producing more value themselves. Of course, what goes up must come down.
You don't need to delay the actual trade. Just delay reporting the order and trade data to even the playing field. That would prevent most uses of HFT.
So standardise on a blue-tooth interface to provide just the sensor data to a phone. The sensors shouldn't go out of date.
Lower unemployment? Great idea. Except we can't do it.
We've been living on credit for so long, we're dependant on it. If our rate of borrowing slows down, people lose their jobs.
So if we want to lower unemployment we need to borrow more money? Great, except everyone's basically swamped with debt already.
Once your passive black road has been covered by white snow, you've lost. The sun's energy will bounce off the snow, you have to wait until the ambient temperature rises enough to melt the snow. If you can use some stored energy to melt the snow, you can start absorbing more energy on your black surface to recharge. You may eventually lose the war and run out of stored energy, but you might be able to delay the inevitable.
I'm thinking of Network Coding Meets TCP. Though that doesn't give a great background. I've experimented with my own implementation, but had to shelve it due to lack of time. I'll try to quickly summarise the core idea;
You have packets [p1, .. pn] in your stream's transmission window.
Randomly pick coefficients [x1, ..., xn] and calculate a new packet = x1*p1 + x2*p2 + , .... (in a galois number field, so '+' is an XOR and '*' is a pre-computed lookup table). Sending the coefficients in the packet header.
The receiver collects the packets, and attempts to combine pairs of packets to reduce the complexity of the coefficients. Basically like solving simultaneous equations. That sounds complicated, but the algorithm isn't too hard;
- Keep the current set of packets, sorted by their coefficients. When you receive an incoming packet, you attempt to subtract each of your existing packets which have a smaller coefficient set (again, galois field math). If you're left with nothing, this packet didn't give you any new information, so throw it away.
- Attempt to subtract this new packet from each of the existing packets in your set. Insert your new packet into the list.
When you have a packet with a most significant coefficient of 1. You know you will be able to decode that packet eventually. And you know that you can eliminate that coefficient from any other incoming packet. So you can send an acknowledgement to the sender and they can advance their transmit window. Once you have eliminated all other coefficients you can deliver the packet to the application. Keep each packet in memory until the sender has advanced their window and stopped sending it.
Each incoming packet may eliminate a coefficient from the packets in your list, while at the same time introducing a new one. If you don't send extra redundant packets you may never be able to decode anything. Consider the worst case where every packet is the XOR of two neighbouring packets in the stream, you can't decode anything until you receive a single packet by itself. Sending more redundant packets will reduce the latency to decode the stream while adding to the number of useless packets received.