I thought most energy losses in chips were in the actual transistors rather than in the wires? Now, if they find a way to make this stuff switch very quickly between "superconducting" and "very good insulator"...
That's easy, just heat the junction, and voila! a new gated-thermal-resistor-super-conducting-transistor is born.
You mean, in addition to all the compression techniques and media formats?
That's why a lot of the posts recommend including redundant working players and media. That way, some tinkerers in the future will have a chance of cobbing together a working reader.
... wouldn't blocking people's access in advance considered an attack in and of itself? So the service should simply block itself off and be done with it.
When I used to work for a company that serves up millions of page views a day, we had to build our own servers to serve as proxy to the Ad traffics. That way, we only served up contents that are fully available on our server, and not subjecting our clients to the delays caused by the ads.
That's because most GUI applications are driven by events, and most applications are written to have just one event handler/dispatcher.
That doesn't mean that the application doesn't have a ton of threads or processes, utilizing processor resources. It's just easier and more efficient for a single dispatcher to communicate with a bunch of threads than it is to communicate with a bunch of processes. It also means that when one thread catches the hiccup, the whole application has to deal with the collateral damages.
Now, to make a GUI application multi-processes, you need to have a dedicated process to handle drawing and events. Add one or more processes to handle the tasks, and IPC to tie them together. In another word, you ends up reimplementing X:)
Add a deadline to that and you can see why you end up with just multi-threaded applications.
This is slightly different than simple polarization, see here: http://www.newscientist.com/article/mg18224515.000 -- full article requires log-in. Or here: http://www.physics.gla.ac.uk/Optics/play/photonOAM/
The point here is that a "pulse" can now encode more than just an "on/off" state. Instead, a pulse now encodes a "twistiness" level of states (can be 1, 2, 3, or up to 250 as in the NS article.) So, a 2GHz signal can now carries, let's say, 2x8 = 16 Gb/s.
The trouble, it seems, is to construct a receiver capable of correctly identifying the pulses.
I'm not sure C is up to the multithreading/ multiprocessor support that is going to be required as processors keep shifting from single core to multicore architectures...I know it can be done, but C is hard to program for a single core...Multicore support may take it over the edge.
Mind you, I don't think anything else is really set up for it either (Erlang?) but that's going to be the next big challenge. No language is going to be easier/harder to program for a single/multiple core/processor/threads. The language can only provide the facility for creating threads/processes, and the facility for those to communicate with one another.
As those facilities are high-level construct themselves, you should be able to implement them in any high-level language (for example, as an object or library.)
It still rests in the hands of the programmer to make use of those facilities, and to use threads and locks when appropriate.
Most of *our* server boxes don't have X on them, so it is a good distinction.
Just because there is a lot of effords in the kernel space, that doesn't mean that there isn't effords on the usability of Linux. Look at Ubuntu for example.
I thought most energy losses in chips were in the actual transistors rather than in the wires? Now, if they find a way to make this stuff switch very quickly between "superconducting" and "very good insulator"...
That's easy, just heat the junction, and voila! a new gated-thermal-resistor-super-conducting-transistor is born.
Just make sure they have a decent back-up solution :)
I personally would pick something like JournalSpace
You mean, in addition to all the compression techniques and media formats?
That's why a lot of the posts recommend including redundant working players and media. That way, some tinkerers in the future will have a chance of cobbing together a working reader.
... wouldn't blocking people's access in advance considered an attack in and of itself? So the service should simply block itself off and be done with it.
According to this article here, iPS cells can now be created from blood, does that mean that men are now obsolete?
When I used to work for a company that serves up millions of page views a day, we had to build our own servers to serve as proxy to the Ad traffics. That way, we only served up contents that are fully available on our server, and not subjecting our clients to the delays caused by the ads.
... if they use Pentiums, Schrodinger might finally know if the cat is alive or dead.
That's because most GUI applications are driven by events, and most applications are written to have just one event handler/dispatcher.
:)
That doesn't mean that the application doesn't have a ton of threads or processes, utilizing processor resources. It's just easier and more efficient for a single dispatcher to communicate with a bunch of threads than it is to communicate with a bunch of processes. It also means that when one thread catches the hiccup, the whole application has to deal with the collateral damages.
Now, to make a GUI application multi-processes, you need to have a dedicated process to handle drawing and events. Add one or more processes to handle the tasks, and IPC to tie them together. In another word, you ends up reimplementing X
Add a deadline to that and you can see why you end up with just multi-threaded applications.
/. is probably the wrong place to ask for such a deep and profound question.
This is slightly different than simple polarization, see here: http://www.newscientist.com/article/mg18224515.000 -- full article requires log-in. Or here: http://www.physics.gla.ac.uk/Optics/play/photonOAM/ The point here is that a "pulse" can now encode more than just an "on/off" state. Instead, a pulse now encodes a "twistiness" level of states (can be 1, 2, 3, or up to 250 as in the NS article.) So, a 2GHz signal can now carries, let's say, 2x8 = 16 Gb/s. The trouble, it seems, is to construct a receiver capable of correctly identifying the pulses.
Obviously they never met my ex-girlfriend...
Large, and with a long, thin snout, the Hispaniolan solenodon resembles an overgrown shrew
Oh the irony.
Most of *our* server boxes don't have X on them, so it is a good distinction.
Just because there is a lot of effords in the kernel space, that doesn't mean that there isn't effords on the usability of Linux. Look at Ubuntu for example.