NAT is not a security tool, has never been a security tool, and was never intended to ever be used as a security tool. It does no more good than a basic 'block all inbound' firewall, and only serves to limit and complicate every application you wish to use.
If I want to run multiple computers accessible over SSH or VNC, I have to run them on separate ports. If I want to run multiple web servers, I again have to run on different ports, or otherwise proxy them all through a single external server. SIP and other protocols that embed the address in the protocol are outright broken by NAT. Like XanC said, it is a necessary evil that should be dumped with extreme prejudice.
I realize I am by far an extreme case, but in a house of four, I run one server, two mythtv frontends, one networked tuner, one networked POTS ATA, one game console, three WiFi access points, one networked printer, one networked RAID card, three desktops, four laptops, three internet capable phones, and a handful of other old machines that I occasionally bring online for various uses. That's 21 devices which could be using their own IP. Throw in half a dozen applications I'm running on the server which each have their own IP as well, and I would nearly fill that/27.
Now sure, a number of those devices shouldn't have internet access, and I can run NAT like a normal person with a consumer router, but I would love to not have to. Meanwhile, VOIP services, networked consoles, NAS boxes, networked media players, and even networking in bluray players and TVs means the number of addresses used per-person is going to skyrocket in the next few years. This is exactly what IPv6 is supposed to allow.
In reality, gasoline is a more energetic fuel, offering almost 7% more energy by mass than diesel. Diesel is just about 18% denser. Your 1.39x value is completely wrong, with the actual value being closer to 1.1x.
The fuel combusts (ie. explodes!) just from compression. It doesn't even need an ignition source
Exactly, it combusts from compression. Typical diesels run ratios of 15:1 to 25:1. If you toss a match into a barrel of diesel, it will be extinguished.
A 40% decrease in bitrate is about what I'd expect going from a single-pass to a two-pass H.264 encoder, and it's entirely possible that a newer single-pass encoder can do the same sort of thing just by using a longer window now that RAM is a lot cheaper.
No, there is no difference in compressibility between a single pass and a two pass encoder. The two pass encoder simply allows you to set the quantizer so as to very accurately hit a target average bitrate.
Additional passes do nothing for video quality. All they let you do is accurately hit a desired average bitrate. In broadcasting, the only thing you really care about is the maximum bitrate.
For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate. You're giving up CPU cycles in decoding for lower video size
4.1 and 5.1 are levels, not profiles. Levels define the minimum throughput and frame memory required for a decoder. By running 5.1/unlimited, the only thing you get is the ability to crank up the number of reference frames for a quickly diminishing gain. Note that affects memory consumption directly, and CPU usage hardly at all.
x264 uses much more demanding settings. x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.
x264 allows YOU to use much more demanding settings. The defaults are actually fairly standard. Furthermore, nearly all of those settings affect encoding performance, making little difference in decoding speed besides possibly breaking hardware decoders. The two settings that make the most change in performance and compression are CABAC/CAVLC and slice count. CABAC offers 25-30% better compression for about 35% more CPU for decoding, but considering the Blu-Ray spec requires player to support CABAC, nearly all disks using h264 encoding will use CABAC. H264 offers parallel decoding through the concept of slices, areas of the video that are partitioned and encoded/decoded independently. Bluray videos generally have six or more of these. Using a single slice will noticeably improve compressibility, at the complete loss of parallelism. A 20mbps single-sliced h264 video with CABAC will strain even an i7 with Turbo Boost enabled, while it will handle that 40mbps Bluray encode at around half load.
The only other explanation is that properly encoded, 40mbps for 1080p24 is just beyond the visual acuity limits of the average human. The 20mbps video is closer to what you would expect out of an HDDVD, and back when that war was still going on, I recall one of the x264 devs (or maybe ffmpeg dev) claiming the additional bitrate afforded by Bluray went largely without gain, and the 30GB of HDDVD was plenty.
Aside from a few homebrew PS3 clusters, I don't know of any large scale Cell installations. The Roadrunner is a fairly standard (if very large) Opteron based cluster, with PowerXCell co-processors. The latest Cray XT5 is is a fairly standard (if very large) Opteron based cluster, with PowerXCell or FPGA co-processors.
The NSAs ASIC systems don't count, by definition, they are not general purpose. A modern 3GHz quad-core processor will manage an exhaustive DES search in about 600 years. Deep crack in 1998 could manage that feat in 9 days, but you wouldn't consider it comparable with a 25k chip cluster.
Similarly the @Home applications don't count because the interconnect bandwidth and latency is so abysmally low. It holds a huge amount of power (on the order of several PF), but it cannot be used for anything but relatively small Monte Carlo simulations.
Except that a 'supercomputers' and a 'cluster of commodity hardware' are effectively synonymous these days. They all use the same Power/Xeon/Opteron/Itanium chips, with several cores and a several GB of memory to a compute node. The only real difference left is the interconnect. Commercially built systems tend to have far beefier and more complex interconnects. Homebrew systems more often than not just use gigabit ethernet, with the larger ones rarely using anything better than a 'fat tree' with channel bonding or 10gbps ethernet.
Are some of the new file systems under development, such as btrfs, going to have distributed, networked operation as a basic feature? I recall hearing that ZFS has some ability along those lines.
Not exactly. ZFS has send/receive functions that let you copy a filesystem snapshot (full or incremental based off a previous snapshot) to another location. These functions just use stdin and stdout, relying on rsh/ssh/nc/whatever for network communication. It's designed more for remote backup purposes, rather than high availability.
That's great if you have a compliant device. I spent two hours trying to figure out why my mom's Nokia wasn't working with such a passphrase. I finally got tired of typing in such a long phrase and truncated it to 15 or so characters only to find it instantly working. Turns out while it lets you type in long phrases, it will silently fail to use them in a completely undocumented deficiency.
Because TiVo is closed source, and retains full control over the content on the device. They can guarantee that someone wont just recompile the code with a replacement function that dumps the data unencrypted to a user accessible hard disk.
They call it 'modulated thunder'. Thunder is just the noise produced by expanding gas heated by an electric discharge. The coils are actually being switched at several kHz, producing repeating 'thunder' at a frequency above the point where you stop hearing the individual claps, and instead hear a tone. It effectively is a low-mid range speaker.
You're looking at it wrong.
NASA's batch supercomputers have operated in this fashion for decades. One division gets a large supercomputer, and various projects get allotted CPU quotas. They can run as small or as large of tasks as they please on the first free nodes that open up, all billed to their quota. The fact that they put it on the internet for use with web servers does not make it anything new or amazing.
If you check out the fbo.gov link in the article, it says they are purchasing units of the CECHP01 SKU, which is a 160GB/65nm variant of the old style which still offered OtherOS support.
Slashdot Mirror
You're saying the guy talking about 'runon's has syphilis? That would explain why he's raving mad.
NAT is not a security tool, has never been a security tool, and was never intended to ever be used as a security tool. It does no more good than a basic 'block all inbound' firewall, and only serves to limit and complicate every application you wish to use.
If I want to run multiple computers accessible over SSH or VNC, I have to run them on separate ports. If I want to run multiple web servers, I again have to run on different ports, or otherwise proxy them all through a single external server. SIP and other protocols that embed the address in the protocol are outright broken by NAT. Like XanC said, it is a necessary evil that should be dumped with extreme prejudice.
I realize I am by far an extreme case, but in a house of four, I run one server, two mythtv frontends, one networked tuner, one networked POTS ATA, one game console, three WiFi access points, one networked printer, one networked RAID card, three desktops, four laptops, three internet capable phones, and a handful of other old machines that I occasionally bring online for various uses. That's 21 devices which could be using their own IP. Throw in half a dozen applications I'm running on the server which each have their own IP as well, and I would nearly fill that /27.
Now sure, a number of those devices shouldn't have internet access, and I can run NAT like a normal person with a consumer router, but I would love to not have to. Meanwhile, VOIP services, networked consoles, NAS boxes, networked media players, and even networking in bluray players and TVs means the number of addresses used per-person is going to skyrocket in the next few years. This is exactly what IPv6 is supposed to allow.
Anyone else notice the top of the hill is 1337?
There was a similar scene at the end of Debt of Honor (1994).
Just watch the ending to Predator.
In reality, gasoline is a more energetic fuel, offering almost 7% more energy by mass than diesel. Diesel is just about 18% denser. Your 1.39x value is completely wrong, with the actual value being closer to 1.1x.
The fuel combusts (ie. explodes!) just from compression. It doesn't even need an ignition source
Exactly, it combusts from compression. Typical diesels run ratios of 15:1 to 25:1. If you toss a match into a barrel of diesel, it will be extinguished.
A 40% decrease in bitrate is about what I'd expect going from a single-pass to a two-pass H.264 encoder, and it's entirely possible that a newer single-pass encoder can do the same sort of thing just by using a longer window now that RAM is a lot cheaper.
No, there is no difference in compressibility between a single pass and a two pass encoder. The two pass encoder simply allows you to set the quantizer so as to very accurately hit a target average bitrate.
Additional passes do nothing for video quality. All they let you do is accurately hit a desired average bitrate. In broadcasting, the only thing you really care about is the maximum bitrate.
For example, you can get higher quality with CPU-intensive settings using H.264 5.1 Profile than you can with H.264 4.1 (what Blu-Ray's/HD DVDs use), at the same bitrate. You're giving up CPU cycles in decoding for lower video size
4.1 and 5.1 are levels, not profiles. Levels define the minimum throughput and frame memory required for a decoder. By running 5.1/unlimited, the only thing you get is the ability to crank up the number of reference frames for a quickly diminishing gain. Note that affects memory consumption directly, and CPU usage hardly at all.
x264 uses much more demanding settings. x264 at 20 Mbit which high-quality settings is far more demanding than a 40 Mbit H.264 stream from a Blu-Ray.
x264 allows YOU to use much more demanding settings. The defaults are actually fairly standard. Furthermore, nearly all of those settings affect encoding performance, making little difference in decoding speed besides possibly breaking hardware decoders. The two settings that make the most change in performance and compression are CABAC/CAVLC and slice count. CABAC offers 25-30% better compression for about 35% more CPU for decoding, but considering the Blu-Ray spec requires player to support CABAC, nearly all disks using h264 encoding will use CABAC. H264 offers parallel decoding through the concept of slices, areas of the video that are partitioned and encoded/decoded independently. Bluray videos generally have six or more of these. Using a single slice will noticeably improve compressibility, at the complete loss of parallelism. A 20mbps single-sliced h264 video with CABAC will strain even an i7 with Turbo Boost enabled, while it will handle that 40mbps Bluray encode at around half load.
The only other explanation is that properly encoded, 40mbps for 1080p24 is just beyond the visual acuity limits of the average human. The 20mbps video is closer to what you would expect out of an HDDVD, and back when that war was still going on, I recall one of the x264 devs (or maybe ffmpeg dev) claiming the additional bitrate afforded by Bluray went largely without gain, and the 30GB of HDDVD was plenty.
Aside from a few homebrew PS3 clusters, I don't know of any large scale Cell installations. The Roadrunner is a fairly standard (if very large) Opteron based cluster, with PowerXCell co-processors. The latest Cray XT5 is is a fairly standard (if very large) Opteron based cluster, with PowerXCell or FPGA co-processors.
The NSAs ASIC systems don't count, by definition, they are not general purpose. A modern 3GHz quad-core processor will manage an exhaustive DES search in about 600 years. Deep crack in 1998 could manage that feat in 9 days, but you wouldn't consider it comparable with a 25k chip cluster.
Similarly the @Home applications don't count because the interconnect bandwidth and latency is so abysmally low. It holds a huge amount of power (on the order of several PF), but it cannot be used for anything but relatively small Monte Carlo simulations.
Except that a 'supercomputers' and a 'cluster of commodity hardware' are effectively synonymous these days. They all use the same Power/Xeon/Opteron/Itanium chips, with several cores and a several GB of memory to a compute node. The only real difference left is the interconnect. Commercially built systems tend to have far beefier and more complex interconnects. Homebrew systems more often than not just use gigabit ethernet, with the larger ones rarely using anything better than a 'fat tree' with channel bonding or 10gbps ethernet.
Are some of the new file systems under development, such as btrfs, going to have distributed, networked operation as a basic feature? I recall hearing that ZFS has some ability along those lines.
Not exactly. ZFS has send/receive functions that let you copy a filesystem snapshot (full or incremental based off a previous snapshot) to another location. These functions just use stdin and stdout, relying on rsh/ssh/nc/whatever for network communication. It's designed more for remote backup purposes, rather than high availability.
The cost of $34 is exactly a 50% markup of 400 of Amazon's 'medium high-cpu' instances for the quoted 20 minutes.
A medium 'high-cpu' linux instance at Amazon is $0.17/hr.
($0.17/hr) x (20min) x (400 instances) = $22.66666... +50% = exactly $34
That's great if you have a compliant device. I spent two hours trying to figure out why my mom's Nokia wasn't working with such a passphrase. I finally got tired of typing in such a long phrase and truncated it to 15 or so characters only to find it instantly working. Turns out while it lets you type in long phrases, it will silently fail to use them in a completely undocumented deficiency.
Or any form of network file system, for that matter.
On could claim it's already 19 major revisions past that point.
Because TiVo is closed source, and retains full control over the content on the device. They can guarantee that someone wont just recompile the code with a replacement function that dumps the data unencrypted to a user accessible hard disk.
They call it 'modulated thunder'. Thunder is just the noise produced by expanding gas heated by an electric discharge. The coils are actually being switched at several kHz, producing repeating 'thunder' at a frequency above the point where you stop hearing the individual claps, and instead hear a tone. It effectively is a low-mid range speaker.
You're looking at it wrong. NASA's batch supercomputers have operated in this fashion for decades. One division gets a large supercomputer, and various projects get allotted CPU quotas. They can run as small or as large of tasks as they please on the first free nodes that open up, all billed to their quota. The fact that they put it on the internet for use with web servers does not make it anything new or amazing.
Not everyone is perfectly ok with killing other people, even if they deserve it.
You say that from the relative safety of your desk, but that number drops off very quickly among those who are themselves in immediate mortal danger.
If you check out the fbo.gov link in the article, it says they are purchasing units of the CECHP01 SKU, which is a 160GB/65nm variant of the old style which still offered OtherOS support.
The phantom zone...