Note: we do not currently use explosives in tank-to-tank anti-armor shells! They have much less penetrating power than shaped charges, particularly against composite armor.
At these velocities, it won't matter; the projectile will have more KE than the chemical energy of explosive would be, and it won't go through intact; most of that will be converted to heat.
At that velocity, no need to bother with HE. The antiarmor shell from an M1 is already just a depleted uranium (because it's dense) rod in a shell-sized casing.
Yeah, a hybrid-power plant M1 would seem a natural fit for this. We can have a railgun and be environmentally conscious!
One thing I still find odd though - why Intel of all people? Why not AMD?
Two reasons.
1) Noteboooks! The Pentium M is the one place where Intel may have the edge on AMD. Notebook sales are at 50% of all PC sales, and climbing; and this is the PowerPC's particular weak spot. If AMD doesn't mantain parity with Intel in the portable chip market, it's ok for AMD, but Apple is dead dead dead.
2) Safety. Apple thinks its OS and/or business model gives them the advantage over MSDell. They don't need a better chip; they need a guarentee that their chips will be *close*. AMD may be more likely to win, but Intel is less likely to completely botch a generation or two.
Also, after losing PS3 and XBox2 to IBM, I wonder if Intel cut Apple a super-special deal...
As I understand it... To be perfectly fair, at least some of the church-sponsored witch-hunting was a purposeful attempt to take that job away from local governments (who often used it for political purposes), and impose a more standardized and logical system. In many cases local governments coopted it anyway, and those were many of the worst, or at least broadest, abuses.
I'm as big a linux fanboy as the next guy (well, maybe not on slashdot), but have you looked at Solaris 10? The filesystem stuff is clever but may not fly in the real world. The new DTrace system monitoring tools, however, are a huge step ahead of anything else out there. Essentially it lets you hook any system call and run a secure script in kernel space when it triggers. (Not a very clear description, sorry, but it's the first OS enhancement I've seen in years to which my response wasn't 'Well, duh, about time.' but was 'uuuuh... ooh, that's clever.')
the US certainly supplied Saddam Hussein with weapons, I'd guess it is more probable that an M-16 would be shot at an American structure than an AK
Nonsense. Almost all of Hussein's weapons were Russian and French, with a small amount of Chinese and US equipment. Why do you think the US imported AK-47s from Poland to equip the new Iraqi army? Because that's what everyone in Iraq with military experience had trained with!
The thing about this I thought was interesting is that the research was sponsored by RSA Corp. Anybody want to bet that wouldn't have happened if TI had licenced a RSA algorythm?
I suppose it's a good thing that companies are competing in this way, rather than just slathering us all in layers of obfuscation and FUD.
a) fabrication is hard b) you still have the distance problem, you just got a one-time gain c) How are you going to remove the heat from the center of that sphere? You can reduce voltage, but that'll slow the signals down again...
No, making it bigger will make it slower. Current digital systems are mostly "clocked" (they don't have to be, but that gets much more complicated), which means that signals have to be able to get from one side of the system to the other within one clock cycle.
This is why your CPU runs at a faster speed than your L2 cache (which is bigger), which runs at a faster speed than your main memory (which is bigger), which runs at a faster speed than memory in the adjacent NUMA-node (which is bigger), which runs faster than the network (which is bigger),...
Note that I'm talking about latency/clock-rate here; you can get arbitrarily high bandwidth in a big system, but there are times when you have to have low latency and there's no substitute for smallness then; light just isn't that fast!
I wonder if it has to be low-quality. I'm sure it's possible to merge either multiple low-resolution captures zoomed on different regions of the screen, or just to average multiple low-resolution captures to get closer to a high-resolution image.
How hard would that be, really? And it only has to be done once, unless they can kill the P2P networks, also...
That sounds to me like more trouble than it's worth; just thinking about integrating that with LVM makes my head hurt. Would it really make a significant difference?
I think that was it, thanks! I tried googling, but got a bunch of instructions on how to make boot floppies.
Somebody mentioned it in a later comment, too. Anyhow, neat idea. It'd be better if you could manage it somehow without breaking LSB compliance... but I'd love to see a major distro go for this.
Unfortunately, I didn't save the link, but some clever lunatic rewrote his initscripts into makefiles (!) actually working out what depended on what and running all sorts of stuff in parallel - the kernal just launched "make boot" instead of initd. It made quite a bit of difference, IIRC.
No, no, no. I can see reasons to prototype protocols over UDP (cause it's mostly raw IP), but your reasons are all bad.
a) Modern TCP implementations (with window scaling) support a maximum window size of approximately 1 GB.
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well.
c) Yeah, until the firewall vendors start looking for this and the whole thing becomes a even more insanely unreliable hackjob than it already is. Why not just cut to the chase and implement RFC 3093?
d) I suppose, though this'll be pretty unreliable if/as egress filtering becomes more common.
TCP acks can be a lot less than 1/20th the traffic volume for a high-bandwidth connection (Nagle's algorythm?).
Point a webcam at your TV and record it that way. Problem solved!
(Seriously though, if you had multiple webcams aimed at different parts of the screen, and software to reintegrate the video streams... let's see them DRM that!)
Slashdot Mirror
Note: we do not currently use explosives in tank-to-tank anti-armor shells! They have much less penetrating power than shaped charges, particularly against composite armor.
At these velocities, it won't matter; the projectile will have more KE than the chemical energy of explosive would be, and it won't go through intact; most of that will be converted to heat.
US Tank shells
At that velocity, no need to bother with HE. The antiarmor shell from an M1 is already just a depleted uranium (because it's dense) rod in a shell-sized casing.
Yeah, a hybrid-power plant M1 would seem a natural fit for this. We can have a railgun and be environmentally conscious!
In Communist China, YOU register WEBSITES!
One thing I still find odd though - why Intel of all people? Why not AMD?
Two reasons.
1) Noteboooks! The Pentium M is the one place where Intel may have the edge on AMD. Notebook sales are at 50% of all PC sales, and climbing; and this is the PowerPC's particular weak spot. If AMD doesn't mantain parity with Intel in the portable chip market, it's ok for AMD, but Apple is dead dead dead.
2) Safety. Apple thinks its OS and/or business model gives them the advantage over MSDell. They don't need a better chip; they need a guarentee that their chips will be *close*. AMD may be more likely to win, but Intel is less likely to completely botch a generation or two.
Also, after losing PS3 and XBox2 to IBM, I wonder if Intel cut Apple a super-special deal...
Sure they can. They can disbelieve, declare you in comtempt of court, and throw you in jail indefinitely.
I wouldn't think so. You could, but Cell is a weird chip; not so much like a G6 as a G4 with 7 (!) super-VMX coprocessors.
With proper coding, performance for something like Photoshop might be fabulous, but I doubt it would be efficient for general-purpose computing.
Er, doesn't the rover have an arm? With a little rock-grinder on it, even?
I don't think it's *designed* to dig, or push off, but you might be able to do it...
As I understand it... To be perfectly fair, at least some of the church-sponsored witch-hunting was a purposeful attempt to take that job away from local governments (who often used it for political purposes), and impose a more standardized and logical system. In many cases local governments coopted it anyway, and those were many of the worst, or at least broadest, abuses.
I'm as big a linux fanboy as the next guy (well, maybe not on slashdot), but have you looked at Solaris 10? The filesystem stuff is clever but may not fly in the real world. The new DTrace system monitoring tools, however, are a huge step ahead of anything else out there. Essentially it lets you hook any system call and run a secure script in kernel space when it triggers. (Not a very clear description, sorry, but it's the first OS enhancement I've seen in years to which my response wasn't 'Well, duh, about time.' but was 'uuuuh... ooh, that's clever.')
iSync in 10.3 doesn't really support very many phones (and no new ones); any word on big changes/updates there?
the US certainly supplied Saddam Hussein with weapons, I'd guess it is more probable that an M-16 would be shot at an American structure than an AK
Nonsense. Almost all of Hussein's weapons were Russian and French, with a small amount of Chinese and US equipment. Why do you think the US imported AK-47s from Poland to equip the new Iraqi army? Because that's what everyone in Iraq with military experience had trained with!
Because it's the land that's expensive, not the structure. In my (suburban) town, a buildable lot, assuming you can find one, will run around $400k.
And the accountant closes the door and replies quietly, "What do you need it to be ?"
The thing about this I thought was interesting is that the research was sponsored by RSA Corp. Anybody want to bet that wouldn't have happened if TI had licenced a RSA algorythm?
I suppose it's a good thing that companies are competing in this way, rather than just slathering us all in layers of obfuscation and FUD.
I believe anything after the 22nd should have the '05 iLife, but am not 100% sure if it's based on order or ship or build date...
A good idea, and more layers will happen, but
a) fabrication is hard
b) you still have the distance problem, you just got a one-time gain
c) How are you going to remove the heat from the center of that sphere? You can reduce voltage, but that'll slow the signals down again...
No, making it bigger will make it slower. Current digital systems are mostly "clocked" (they don't have to be, but that gets much more complicated), which means that signals have to be able to get from one side of the system to the other within one clock cycle.
This is why your CPU runs at a faster speed than your L2 cache (which is bigger), which runs at a faster speed than your main memory (which is bigger), which runs at a faster speed than memory in the adjacent NUMA-node (which is bigger), which runs faster than the network (which is bigger),...
Note that I'm talking about latency/clock-rate here; you can get arbitrarily high bandwidth in a big system, but there are times when you have to have low latency and there's no substitute for smallness then; light just isn't that fast!
Theoretically, maybe; firing excess heat in the form of a laser is probably possible. In practice, this sort of laser doesn't get us any closer.
I wonder if it has to be low-quality. I'm sure it's possible to merge either multiple low-resolution captures zoomed on different regions of the screen, or just to average multiple low-resolution captures to get closer to a high-resolution image.
How hard would that be, really? And it only has to be done once, unless they can kill the P2P networks, also...
That sounds to me like more trouble than it's worth; just thinking about integrating that with LVM makes my head hurt. Would it really make a significant difference?
I think that was it, thanks! I tried googling, but got a bunch of instructions on how to make boot floppies.
Somebody mentioned it in a later comment, too. Anyhow, neat idea. It'd be better if you could manage it somehow without breaking LSB compliance... but I'd love to see a major distro go for this.
Unfortunately, I didn't save the link, but some clever lunatic rewrote his initscripts into makefiles (!) actually working out what depended on what and running all sorts of stuff in parallel - the kernal just launched "make boot" instead of initd. It made quite a bit of difference, IIRC.
No, no, no. I can see reasons to prototype protocols over UDP (cause it's mostly raw IP), but your reasons are all bad.
a) Modern TCP implementations (with window scaling) support a maximum window size of approximately 1 GB.
b) A big window, and the selective acknowledgement feature provided by many TCP stacks these days, makes this mostly moot as well.
c) Yeah, until the firewall vendors start looking for this and the whole thing becomes a even more insanely unreliable hackjob than it already is. Why not just cut to the chase and implement RFC 3093?
d) I suppose, though this'll be pretty unreliable if/as egress filtering becomes more common.
TCP acks can be a lot less than 1/20th the traffic volume for a high-bandwidth connection (Nagle's algorythm?).
Point a webcam at your TV and record it that way. Problem solved!
(Seriously though, if you had multiple webcams aimed at different parts of the screen, and software to reintegrate the video streams... let's see them DRM that!)
Heck, the most serious danger of either isn't fire; it's that the underground gasoline tanks will leak and contaminate local water supplies.