Most viruses don't go looking around for PLC software. They tend to either be done for fame or for money, and these days it seems to be mostly money. I can't think of another virus comparable to Stuxnet.
I know most are anycast. I still think DoD should give up their slot to someone else, especially since they have 2. There is no reason why any organisation should have two slots; the only reason for that is historical.
It would probably be reasonably easy to get someone else to run the H server cluster. The DNS protocol itself limits the number to 13, quite by accident, and there was no grand design when it was decided who was getting them.
If the US army can't run their server properly, they should offer the slot to someone else.
I'm willing to bet that when mainstream 64-core general-purpose CPUs arrive, they will be NUMA and be partitioned in groups with shared cache. I will be surprised if all the cores have a shared cache other than possibly a large slow write-through level-4 cache. It would be very tricky to make an efficient modern cache with deferred writeback and access by 64 cores, and the gains over e.g. 4 smaller caches would be modest. The memory bandwidth requirements of a 64-core chip also make it very tempting to implement separate memory controllers for groups of cores instead of needing an extremely fast shared memory controller.
So all in all, I think a very fast desktop tomorrow will look like a shrunk version of a modern NUMA server, at least when it comes to what the operating system can see.
In your idealized society, you think he should be paid based on... how many hours he worked? Your hybrid economic system removes both the altruistic motive of communism and the reward motive of capitalism.
In a free market, prices of goods are close to the marginal cost of producing those goods, in this case close to the cost of the hours he worked. If prices are higher than that, competition brings them down, if they are lower, manufacturers go out of business.
Of course a free market is not a very attractive proposition for most businesses, so a lot of their effort goes into preventing it from existing. Apple is particularly good at it.
Well there is the slight problem of actually getting to the beam.
Get into the tunnel which is quite cold to keep the magnets superconducting.
Somehow avoid the synchrotron radiation.
Make sure nothing you bring is made of metal. Hope that high magnetic fields are relatively harmless.
Drill into the pipe which "contains" hard vacuum.Make sure nothing falls into the pipe or the beam will start hitting that and start showering you in bremsstrahlung and possibly exotic particles.
Put your hand into hard vacuum, preferably without otherwise breaking the vacuum.
I think MythBusters are going to pass on this one.
The codec isn't the main problem with DAB (although it would certainly have been nicer if they had picked a decent one from the start). The main problems are the atrocious spectrum efficiency and high cost/large spectrum allocation for a MUX. DAB is useless for local radio, and for anything else DVB-T is a better standard (and DVB-T2 even better, of course).
Internet radio is going to win the war anyway; DAB and DRM+ both lost their chance to get into cars and therefore they don't have a chance. DVB-T could still get limited penetration simply because it would be approximately free to add radio channels to the existing network. Internet radio will soon be in every cell phone, and cell phones can get the signal through to the car audio system either with FM or with Bluetooth; modern cars support both.
Around here, FM radio seems to be either in the car, in the house, or built into a cell phone. A cell phone should have enough juice to handle DRM+; they seem to be doing fine with internet radio at least and that must be way more power hungry. I wouldn't imagine that DRM+ was significantly less power hungry than DAB.
DRM+ is a vastly better standard than DAB. DAB should have never existed. If you want to replace traditional FM local stations, DRM+ is an excellent choice -- better coverage and higher quality with less power and using less spectrum. If you want to cover a huge area with a MUX, DVB-T2 is what you want and it can transmit a large amount of channels in one MUX. DRM+ is one channel per MUX, but that isn't a large problem since there is room for many MUXes in just a small amount of spectrum.
This is something which has been researched in computer science for a long time. See e.g. Amoeba distributed OS (which assumes completely different architectures and disjoint memory).
You could do a good first attempt with Linux and a userspace manager process which changes CPU-affinity based on program requirements and load. This only works because the differences are so simple in this case, but I bet hardware designers will try to keep it reasonably simple.
The difference is that this one seems to be able to run all three cores as SMP with a single kernel being able to run on all of them. Traditionally the cores either run completely different systems, or the kernel runs on one along with general system tasks, whereas the other is dedicated to DSP-like work.
How do you handle applications that don't play nice and keep using large quantities of CPU time after you've told them to go into sleep mode?
You're the bloody OS! You don't have to give the applications any CPU time at all, if you feel it's time better spent playing tic-tac-toe with imaginary opponents.
It's tricky to switch from the fast to the slow CPU and back at precisely the right point, but all you lose by getting the timing wrong is slightly worse performance or slightly worse battery life. Not the end of the world.
The CPU requirements are fine, but the graphics requirements are difficult to match with a laptop. My last non-laptop non-server was a BeBox, I'm not going back to having to sit at a table.
My current laptop doesn't handle Civilization IV very well, even... I'd buy the game if it had a 2D option, something I'd love for Civilization IV as well.
It isn't the overpopulated countries which are responsible for CO2 emissions, in general. The places with high birthrates generally have very low CO2 emissions, with the notable exception of Saudi Arabia.
I don't know the system in Norway, but in Denmark all businesses (and public employers) contribute to a joint fund paying for maternity expenses. You can't get out of paying for maternity just because you employ people who won't have any more children.
If I was in Norway with a business that small, I simply wouldn't hire women because it would be murder to pay someone for a year and get no work from them,
You can probably move it to paternity instead, so employing men won't protect you.
PayPal runs the card. They are responsible for verifying the CCV, the address, the card holder. If the card is stolen, the seller can never know.
Again, I'm not saying that it's right, but real banks do exactly the same thing.
If the buyer demands a chargeback or the transaction is found to be fraudulent, they do a chargeback and add an extra fee to the transaction (paid by the merchant). The bank ONLY loses money if the merchant goes bankrupt. In all other cases, either the buyer or the merchant ends up with the loss.
Paypal offers the merchant pretty much the same deal, possibly even slightly sweeter because there is a chance they'll side with the merchant and they don't AFAIK add a chargeback fee on top of the loss.
The buyer on the other hand has a dramatically higher risk with Paypal than with a normal credit/debit card transaction.
Turns out it was with a stolen credit card. So they reversed the payment leaving me with a -$600 balance.
I'm not saying that it's right, but the real banks do exactly the same thing. As a merchant, all the risk is yours. The agreements you have to sign with banks (or other credit card transaction handlers) are truly horrendous, but you can't take your business elsewhere, because they're all pretty much the same.
Slashdot Mirror
Most viruses don't go looking around for PLC software. They tend to either be done for fame or for money, and these days it seems to be mostly money. I can't think of another virus comparable to Stuxnet.
I know most are anycast. I still think DoD should give up their slot to someone else, especially since they have 2. There is no reason why any organisation should have two slots; the only reason for that is historical.
It would probably be reasonably easy to get someone else to run the H server cluster. The DNS protocol itself limits the number to 13, quite by accident, and there was no grand design when it was decided who was getting them.
If the US army can't run their server properly, they should offer the slot to someone else.
I'm willing to bet that when mainstream 64-core general-purpose CPUs arrive, they will be NUMA and be partitioned in groups with shared cache. I will be surprised if all the cores have a shared cache other than possibly a large slow write-through level-4 cache. It would be very tricky to make an efficient modern cache with deferred writeback and access by 64 cores, and the gains over e.g. 4 smaller caches would be modest. The memory bandwidth requirements of a 64-core chip also make it very tempting to implement separate memory controllers for groups of cores instead of needing an extremely fast shared memory controller.
So all in all, I think a very fast desktop tomorrow will look like a shrunk version of a modern NUMA server, at least when it comes to what the operating system can see.
In your idealized society, you think he should be paid based on... how many hours he worked? Your hybrid economic system removes both the altruistic motive of communism and the reward motive of capitalism.
In a free market, prices of goods are close to the marginal cost of producing those goods, in this case close to the cost of the hours he worked. If prices are higher than that, competition brings them down, if they are lower, manufacturers go out of business.
Of course a free market is not a very attractive proposition for most businesses, so a lot of their effort goes into preventing it from existing. Apple is particularly good at it.
Well there is the slight problem of actually getting to the beam.
I think MythBusters are going to pass on this one.
The codec isn't the main problem with DAB (although it would certainly have been nicer if they had picked a decent one from the start). The main problems are the atrocious spectrum efficiency and high cost/large spectrum allocation for a MUX. DAB is useless for local radio, and for anything else DVB-T is a better standard (and DVB-T2 even better, of course).
Internet radio is going to win the war anyway; DAB and DRM+ both lost their chance to get into cars and therefore they don't have a chance. DVB-T could still get limited penetration simply because it would be approximately free to add radio channels to the existing network. Internet radio will soon be in every cell phone, and cell phones can get the signal through to the car audio system either with FM or with Bluetooth; modern cars support both.
Around here, FM radio seems to be either in the car, in the house, or built into a cell phone. A cell phone should have enough juice to handle DRM+; they seem to be doing fine with internet radio at least and that must be way more power hungry. I wouldn't imagine that DRM+ was significantly less power hungry than DAB.
DRM+ is a vastly better standard than DAB. DAB should have never existed. If you want to replace traditional FM local stations, DRM+ is an excellent choice -- better coverage and higher quality with less power and using less spectrum. If you want to cover a huge area with a MUX, DVB-T2 is what you want and it can transmit a large amount of channels in one MUX. DRM+ is one channel per MUX, but that isn't a large problem since there is room for many MUXes in just a small amount of spectrum.
This is something which has been researched in computer science for a long time. See e.g. Amoeba distributed OS (which assumes completely different architectures and disjoint memory).
You could do a good first attempt with Linux and a userspace manager process which changes CPU-affinity based on program requirements and load. This only works because the differences are so simple in this case, but I bet hardware designers will try to keep it reasonably simple.
Is their mips-per-milliwatt rating so bad they actually need the 3rd core for decent idling?
The mips-per-milliwatt is not the problem. The problem is the leakage current when in a sleep state higher than completely off.
The difference is that this one seems to be able to run all three cores as SMP with a single kernel being able to run on all of them. Traditionally the cores either run completely different systems, or the kernel runs on one along with general system tasks, whereas the other is dedicated to DSP-like work.
How do you handle applications that don't play nice and keep using large quantities of CPU time after you've told them to go into sleep mode?
You're the bloody OS! You don't have to give the applications any CPU time at all, if you feel it's time better spent playing tic-tac-toe with imaginary opponents.
It's tricky to switch from the fast to the slow CPU and back at precisely the right point, but all you lose by getting the timing wrong is slightly worse performance or slightly worse battery life. Not the end of the world.
The CPU requirements are fine, but the graphics requirements are difficult to match with a laptop. My last non-laptop non-server was a BeBox, I'm not going back to having to sit at a table.
My current laptop doesn't handle Civilization IV very well, even... I'd buy the game if it had a 2D option, something I'd love for Civilization IV as well.
is there any GOOD reason why they simply didn't repair the blowout preventer, hook up a new dipstick, set up a new rig, and keep on a-pumpin'?
It was way too damaged. They tried to attach pipes several times, with fairly limited success.
But, on the upside, I bet they'll damn sure be properly maintaining those blowout preventers from now on.
If past accidents are anything to go by, then no, they won't be properly maintaining anything.
The oil industry seems to be somehow insulated from the normal process of learning from failure.
Why don't you go for the compressed stream rather than trying to live-encode 720p content?
It isn't the overpopulated countries which are responsible for CO2 emissions, in general. The places with high birthrates generally have very low CO2 emissions, with the notable exception of Saudi Arabia.
If you take money from the rich and give it to the poor, that is fundamentally wrong.
You can't make a statement like that and expect it to be universally agreed with. You'd be in the far minority around here with that opinion.
I think you can achieve that with:
<META NAME="ROBOTS" CONTENT="NOARCHIVE">
I don't know the system in Norway, but in Denmark all businesses (and public employers) contribute to a joint fund paying for maternity expenses. You can't get out of paying for maternity just because you employ people who won't have any more children.
If I was in Norway with a business that small, I simply wouldn't hire women because it would be murder to pay someone for a year and get no work from them,
You can probably move it to paternity instead, so employing men won't protect you.
PayPal runs the card. They are responsible for verifying the CCV, the address, the card holder. If the card is stolen, the seller can never know.
Again, I'm not saying that it's right, but real banks do exactly the same thing.
If the buyer demands a chargeback or the transaction is found to be fraudulent, they do a chargeback and add an extra fee to the transaction (paid by the merchant). The bank ONLY loses money if the merchant goes bankrupt. In all other cases, either the buyer or the merchant ends up with the loss.
Paypal offers the merchant pretty much the same deal, possibly even slightly sweeter because there is a chance they'll side with the merchant and they don't AFAIK add a chargeback fee on top of the loss.
The buyer on the other hand has a dramatically higher risk with Paypal than with a normal credit/debit card transaction.
Turns out it was with a stolen credit card. So they reversed the payment leaving me with a -$600 balance.
I'm not saying that it's right, but the real banks do exactly the same thing. As a merchant, all the risk is yours. The agreements you have to sign with banks (or other credit card transaction handlers) are truly horrendous, but you can't take your business elsewhere, because they're all pretty much the same.
TeX is somewhat difficult as a render target. In the general case it degenerates to embedding PS or PDF images...