You only need to context switch on a fetch, store or branch if you mispredicted it. Otherwise branches are free, you prefetch loads and you write behind stores.
Meanwhile, IBM has machines with lots of sockets. Also, x86 gives you 6 cores per socket, and four sockets are cheap.
Wii is a great gaming system, and its graphics are not "very poor". This is pure nonsense, but I see where you come from.
The Wii's graphics are "very poor". Piss poor, really ridiculously bad for a system sold today. The Wii has trouble matching something like Shadow of the Colossus in graphics quality, and that's a PS2 title.
The Wii also a really fun console which I enjoy a lot. It's the only current-generation console in this home. The Wiimote and the balance board are brilliant inventions.
Sun is the only company I know of which usually manages to piss off both the Free Software movement and the Open Source movement at once by offering free and open source software. It is a highly unusual skill to have, and I am certainly not immune to its effects -- I think they're a crap company too, and I hope they die off sooner rather than later.
You don't need hardware multithreading when you have high enough single-thread performance, you can just context switch. IBM has industry-leading single-thread performance, and if you need lots of fast threads, you can just add more cores. In contrast, with the T2 you're stuck with just one socket. If you need to scale, you have to use multiple servers, or just port to POWER.
With such a dramatic overpricing, that's going to raise eyebrows with several government agencies.
Why do you believe that? If you need high performance, you can't use SPARC anyway, and if you don't need high performance, x86 is really really competitive.
It's the reason why a microwave oven is tuned to 2.4GHz, as that is the frequency at which water molecules, including those in your body, resonate.
Water doesn't have a sharp absorption peak, and 2.4GHz is in fact picked to NOT absorb too efficiently. At some frequencies water would absorb the radiation so well that only the outermost layer of food would be heated.
DNS would need a new address type instead of A. It would contain a list of IPv4 addresses. Something like 1.2.3.4:5.6.7.8:9.10.11.12. Old clients would only look up A, and so they wouldn't work.
It wouldn't be a big problem though. There are many many clients for every server, and people who need P2P would be eager to upgrade.
There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address.
Sure there is. The easiest backwards-compatible option would be to add an optional extra address field to the IP header. NAT gateways would then examine any incoming packets, and if they have that option set, they would pop off the first one and send the packet off to whichever address was named there. For packets without such options, they'd behave as they always did.
*poof* no more address shortage. An additional advantage is that NAT could no longer pretend to be a security tool.
IPv6 is a great leap forward in every way, but I still think there's a 50% chance that a proposal like the one I just made will win.
"Investing heavily in VoIP" means buying a couple of servers, a connection to the Internet, and finding a good Linux admin... At least if you're targeting private customers.
Getting blocked by the ISP's is a worry of course.
You can't do memory mapped I/O in standard C. You can't even do threads in standard C (well you can, but only if you don't try to share state between the threads, and then what is the point...)
Everyone does it anyway, and the compiler people mostly learned to not be too strict about this. One nasty exception is strict aliasing, which breaks a lot of real-world code.
Why can't we send a probe that will land on this asteroid and then piggy ride on it.
"Landing" would either actually be "crashing at a speed measured in km/s" or would require just as much fuel as going in the same orbit without the asteroid, and then what's the point...
The point is we don't know. If our survival depends on a strict range of natural conditions, then removing too much CO2 from the environment could spell disaster as well.
Removing CO2 from the environment isn't a concern. That won't happen for a long long time.
Core routers generally don't care much about connections, except for stuff like Lawful Interception. They look at each packet separately. You do get a bit of TCP unfairness by opening lots of connections, but it's reasonably easy for routers to counteract that.
You won't really see 50Mbps shared by anyone (except cable networks). More like 1000Mbps shared to hundreds or thousands of customers. You'd be surprised by how little bandwidth is actually used, except by students.
It might actually cost you less to just let the zombie spam away, and keep the customer is happy.
There's no might in there, it's definitely cheaper to let it spam away. Especially if you do a bit of "congestion management" so it doesn't eat too much bandwidth. If you're lucky the "congestion management will make the customer switch to a different ISP who might spend the time to educate them, in the process making the customer so angry that they switch back to you.
That's not a particularly ethical way to deal with zombies or customers, but for consumer connections cheap tends to beat ethical.
It's more like the worst of both worlds. ISP outgoing mail servers are notoriously overloaded, blacklisted and generally ill-maintained.
Also, at least around here, a lot of them do header logging and keep the data for a comparatively long time. You can argue that the ISP can get the same information just by analyzing packets, but actually a lot of email servers accept encrypted SMTP. The ISP can only log those emails by doing a man-in-the-middle, and they generally don't do that.
Slashdot Mirror
Yes, and from your email address, you really ought to know that. Or did they ditch their Unix labs?
Erase blocks are probably going to get larger. Try a typical Unix file system without tail packing on a 1MB block drive...
You only need to context switch on a fetch, store or branch if you mispredicted it. Otherwise branches are free, you prefetch loads and you write behind stores.
Meanwhile, IBM has machines with lots of sockets. Also, x86 gives you 6 cores per socket, and four sockets are cheap.
Wii is a great gaming system, and its graphics are not "very poor". This is pure nonsense, but I see where you come from.
The Wii's graphics are "very poor". Piss poor, really ridiculously bad for a system sold today. The Wii has trouble matching something like Shadow of the Colossus in graphics quality, and that's a PS2 title.
The Wii also a really fun console which I enjoy a lot. It's the only current-generation console in this home. The Wiimote and the balance board are brilliant inventions.
Sun is the only company I know of which usually manages to piss off both the Free Software movement and the Open Source movement at once by offering free and open source software. It is a highly unusual skill to have, and I am certainly not immune to its effects -- I think they're a crap company too, and I hope they die off sooner rather than later.
You don't need hardware multithreading when you have high enough single-thread performance, you can just context switch. IBM has industry-leading single-thread performance, and if you need lots of fast threads, you can just add more cores. In contrast, with the T2 you're stuck with just one socket. If you need to scale, you have to use multiple servers, or just port to POWER.
With such a dramatic overpricing, that's going to raise eyebrows with several government agencies.
Why do you believe that? If you need high performance, you can't use SPARC anyway, and if you don't need high performance, x86 is really really competitive.
It's the reason why a microwave oven is tuned to 2.4GHz, as that is the frequency at which water molecules, including those in your body, resonate.
Water doesn't have a sharp absorption peak, and 2.4GHz is in fact picked to NOT absorb too efficiently. At some frequencies water would absorb the radiation so well that only the outermost layer of food would be heated.
DNS would need a new address type instead of A. It would contain a list of IPv4 addresses. Something like 1.2.3.4:5.6.7.8:9.10.11.12. Old clients would only look up A, and so they wouldn't work.
It wouldn't be a big problem though. There are many many clients for every server, and people who need P2P would be eager to upgrade.
There's no way to extend the address space in a compatible manner, because there's no way for an old node to indicate a new node as a destination address.
Sure there is. The easiest backwards-compatible option would be to add an optional extra address field to the IP header. NAT gateways would then examine any incoming packets, and if they have that option set, they would pop off the first one and send the packet off to whichever address was named there. For packets without such options, they'd behave as they always did.
*poof* no more address shortage. An additional advantage is that NAT could no longer pretend to be a security tool.
IPv6 is a great leap forward in every way, but I still think there's a 50% chance that a proposal like the one I just made will win.
How can you outlaw file transfers? Heroes-S03E14.mkv packets are almost the same as Fedora-10-x86_64.iso packets. And so on and so forth.
Lack of enforceability rarely stops lawmakers.
"Investing heavily in VoIP" means buying a couple of servers, a connection to the Internet, and finding a good Linux admin... At least if you're targeting private customers.
Getting blocked by the ISP's is a worry of course.
volatile helps you when you have to share data across longjmp. That's the only thing the standard guarantees you can use it for.
You can't do memory mapped I/O in standard C. You can't even do threads in standard C (well you can, but only if you don't try to share state between the threads, and then what is the point...)
Everyone does it anyway, and the compiler people mostly learned to not be too strict about this. One nasty exception is strict aliasing, which breaks a lot of real-world code.
Why can't we send a probe that will land on this asteroid and then piggy ride on it.
"Landing" would either actually be "crashing at a speed measured in km/s" or would require just as much fuel as going in the same orbit without the asteroid, and then what's the point...
If the article is right, cadmium and telluride will become much sought-after as raw materials. You might get paid for the old panels.
The point is we don't know. If our survival depends on a strict range of natural conditions, then removing too much CO2 from the environment could spell disaster as well.
Removing CO2 from the environment isn't a concern. That won't happen for a long long time.
I don't think stone age people can clearcut forests....
Why not? The more common way would be burning the forest, but 6 billion people with stone axes could get rid of most forests rather quickly.
BGP is just a way to get routing tables in without having to type them by hand. It doesn't have anything to do with the actual forwarding.
Core routers generally don't care much about connections, except for stuff like Lawful Interception. They look at each packet separately. You do get a bit of TCP unfairness by opening lots of connections, but it's reasonably easy for routers to counteract that.
You won't really see 50Mbps shared by anyone (except cable networks). More like 1000Mbps shared to hundreds or thousands of customers. You'd be surprised by how little bandwidth is actually used, except by students.
The only real WTF was that the ship turned on their "tower" before it left port.
They made $28,067.31 by doing that (ok, probably -20% fees to AT&T). Not turning the "tower" on would have been a terrible decision.
Cruise ship cells are the best con ever.
Don't worry, modern deep inspection can do almost anything that a transparent proxy can do, and it's generally harder to detect.
It might actually cost you less to just let the zombie spam away, and keep the customer is happy.
There's no might in there, it's definitely cheaper to let it spam away. Especially if you do a bit of "congestion management" so it doesn't eat too much bandwidth. If you're lucky the "congestion management will make the customer switch to a different ISP who might spend the time to educate them, in the process making the customer so angry that they switch back to you.
That's not a particularly ethical way to deal with zombies or customers, but for consumer connections cheap tends to beat ethical.
It's more like the worst of both worlds. ISP outgoing mail servers are notoriously overloaded, blacklisted and generally ill-maintained.
Also, at least around here, a lot of them do header logging and keep the data for a comparatively long time. You can argue that the ISP can get the same information just by analyzing packets, but actually a lot of email servers accept encrypted SMTP. The ISP can only log those emails by doing a man-in-the-middle, and they generally don't do that.