Greylisting's especially helpful against the low-quality anklebiter spammers, who haven't bothered buying spamware that handles relatively simple command-response dialogs (hint - Sendmail originally ran on PDP-11s, and the SMTP dialogs are in the easy part, not the turing-complete rewrite-rules stuff.)
But there are other types of spammers it also kills off - one popular attack by the clever set is to hijack unused IP address space (typically by using ISPs that don't follow best practices on BGP filtering), blast away spamming for a few minutes, then drop the old address and switch to a new one, leaving the old address in various anti-spam blacklists and impossible to traceroute to. The fact that greylisting wants you to retransmit from the _same_ mail server IP address means that this attack won't work, and the only way for this kind of spam to work is to keep the stolen address space around for long enough to be traceable.
But as other people have said, greylisting also works because it makes the spammer call back later, after there's been time for the spammer's IP address to hit real-time blocklists. You can even implement this one yourself, without having to trust other RBL providers, by keeping some spam-bait email addresses around that never get legitimate email, either on the same domain you're protecting by the greylist or on a separate server (less effective, but less complex to implement safely.)
Greylisting is easy to implement, and doesn't get false positives (except for legitimate email from broken SMTP servers, which isn't very common.) It'll cut down on your system load by chasing away the zombie anklebiters, leaving you with mostly real email and better classes of spam.
It'll also cut down on "don't-bouncegram-me" complaints from people whose addresses are being forged by spammers, because it'll reject a lot of that mail before your bouncegram system gets to it.
You may also want to consider checking SPF before bouncegramming unknown senders - lots of people don't use it, and lots of spammers do, but it gives people who are having joe-job impersonation problems a way to keep you from adding to their trouble with your autoresponder, and those are one of the most common sets of SPF users.
I don't see the benefit from this vs. greylisting - either way, you're interrupting the SMTP transmission process before accepting the message, but with double-verify you're doing more CPU work and handling the message-body traffic the first time (when it might be spam)? Part of greylisting's appeal is that you don't need to do much work or accept much traffic on the first attempt, so you can reduce the load on your system and only have to filter spam from the semi-competent spammers.
There are some kinds of compliance you can detect from looking at a message or session, and some you can't. The kind of behaviour that greylisting deals with is "if you get a reject, try again soon", and the way you detect it is to reject them up front and then allow them in if they call back later. So mail senders that don't follow that part of the protocol get rejected automagically, and the great thing about it is that spammers are highly likely to be running non-RFC-compliant zombieware that won't come back. (Also, address-space-hijacker spammers normally don't use a chunk of stolen space long enough for your greylisting timeout, so you've also blocked them without extra work.)
Of course, you can always whitelist mail servers you deal with often, so their mail doesn't get stuck waiting for 5 or 30 or 60 minutes.
Instead of rejecting connections to the third MX record, you could teergrube them, so the spammer's machine ends up dogged out on tiny TCP windows talking to a mail server that's going very slowly and will eventually reject their message. If you want to get fancy, you could also have it feed blacklists, or at least adjust greylist timers, but just being passive-aggressive toward spammers is a good start.
The reason to put milk in first is that when you don't have good refrigeration and your milk isn't all that fresh, then it helps keep the milk from curdling, and apparently the Brits have views about what social classes consider this to be an issue and what that says about those social classes. On the other hand, one American variation on the theme that I've encountered in restaurants was having them put the milk into the already-not-boiling water before putting in the teabag:-(
If I'm in the mood for milk in my tea, I'd want some fairly strong Indian tea, maybe Assam or whatever else is around. But doing that with the more subtle Chinese teas - a Puerh or one of the oolongs - borders on criminal, and doing that with a Japanese green tea or a Chinese green-with-jasmine would be just weird.
Ok, so if it takes you 1 second to delete a spam, should we throw him in the slammer for 1 sec per spam he sent? With some spammers, that's 100 million spams, so ~1100 days or 3 years in jail just for annoying people.
But think about the number of people this spammer succeeded in ripping off - was it 100, or 1000, or 10000? Usually you'd spent less time in jail for stealing $1M from one person than $100 each from 10,000 people, or $1000 each from 1000 people, but at six months in jail per petty theft or 1 year per grand theft, he could easily be doing a lot of time.
Remember that this guy's a phishing thief, not just a pills-or-porn seller. How much time does he deserve for theft? If an average worker makes $50K/year, and the spammer makes $500K ripping off N victims, that's 100 person-years of honest labor he'd need to do just to pay them back for the value of their lost work time, not even counting the lost value by not having their money when they needed it. Should he only have to give back 1x what he stole, or pay more than that as compensation?
(Unless the Eschaton is trying to prevent any discoveries from creating closed time-like loops or other variants on time travel that might endanger its future existence,....) your assertion is bogus. Physicists would really like to have some applecarts get upset, especially if it's done in a way that generates cool new theories that require more physics professors to research, test, and teach about them. And cold fusion? Get real....
There may not be much else that's reasonably priced to spend theoretical physics dollars on, so paying professors to write non-experimentally-testable papers may be the way to go, but there seem to still be lots of physicists who want really really expensive test equipment, either really large accelerators/colliders/etc. or else really big orbiting astrophysics equipment.
Hey, I may not know, but my cats sure like string....
the problem is getting it unentangled again after they're done.
Of course, with cats, their position, velocity, and intentions aren't usually simultaneously predictable; even if you get out the electric can-opener, and can therefore predict what their position will be like in the near future, you still don't know which kitchen door they'll come in.
Openness isn't a free feature - but they could charge excessive prices for the developer kit to make up for it, and it'd still be better than having a closed system, without crippling the phone in other ways.
There are other features, like good voice recognition and text-to-speech, that can probably be done with the current hardware but require software development - I'm surprised they're not there, but if it wasn't ready in time for Macworld, it's an obvious thing to announce in June when the hardware's ready to ship. I'm more surprised that there aren't voice dictation features, since the hardware already supports voice compression (since the phone needs it) and there's plenty of RAM and a screen that would make UI easy to add - maybe the UI's too closely tied to other things that aren't ready yet?
The advertising clause really was obnoxious, as opposed to the "Keep my name in your code" parts and the "It's Not My *Fault*" parts, which were fairly reasonable even though RMS didn't really like them. I don't mind reading all the license stuff if I want to hack the code, but I'd rather not have to read it on some splash-screen or dialog box every time the program starts up, and I certainly don't want to have to read it on every piece of advertising literature about the product.
One thing I really like about "Keep my name in your code" and related kinds of license variants is it gives you some kind of crude mandatory source control - if you have to indicate that you've modified the code, that makes it easier to track and fix things, or at least if you don't put your name in the code, nobody should have to track you down and get permission for later license changes or whatever.
California has had bans for a couple of years on using laptops in the front seats of cars, as well as on having DVD players there. Basically the only display screens you can have visible to the driver are for controls and navigation equipment. So your GPS is fine, but running Google Maps on your laptop isn't.
The reason there's a question about whether the EVD readers can read the data formats for DVD disks is that the codecs aren't the only part of the system with either patents or copyrights or other intellectual property attached - if you remember the whole DVDCCA mess and DVD Jon et al. getting harassed for doing Linux DVD readers in the open, there's licensing there too. (I don't know if that part has royalties or just terms&conditions, or if it's available separately from licensing the codecs, or if the licensing part only applies to the audio section, or for that matter if you could do the mechanical and electrical parts without having to license the data formats; the whole thing was ugly enough I didn't keep track.)
But if the mechanicals and raw data formats can be done without too much licensing baggage, so EVDs can be sort of compatible, then I'd be surprised if the things aren't either chippable or downloadable, just as most Europeans I've talked to about DVD players say that stores selling DVD players over there pretty much always give you a nudge-nudge-wink-wink about asking them for the chip to defeat region coding. On the other hand, if they can't make compatible mechanicals and raw data formats, it may not end up being practical to have backward-compatibility-hacking in EVD players, and similarly, EVDs might not end up being readable on computer DVD players.
The point of the EVDs-in-Chinese question was mostly that even if they're not forward compatible so you can't read EVD disks on DVD players, there's enough Chinese market that they may get their economies of scale anyway.
Different groups who've translated the Bible into English have had different priorities and skill sets, written for different subsets of the English language, and done so at different times and therefore their dialects have different levels of readability today. (Sorry to pick on English here; I know a little about the Latin Vulgate, Luther's German translation and the Frency Douay translation, but basically nothing about post-1610 translations except into English:-)
Most modern translations are trying to strike some balance between readability, preservation of the nuances in the original languages, continuity with familiar readings from earlier well-known translations, introduction of better copies of original texts that weren't available to previous translators, better availability of other original-language material that helps us understand the way the language was used at the time the original documents were written, and of course there's the problem of dealing with poetry.
The King James translation was fairly conservative for its time (finished 1611), trying to retain much of the familiarity of the popular Geneva translation (which was politically awkward, because that had a lot of Puritan notes and commentary printed with it, and the King wanted stuff that was politically Anglican), and the Geneva translation retained a lot of continuity with Tyndale's and other translations, so even though the English language had been changing radically during the 1500s, and almost all of the "thee" and "thou" and "ye" and "hast" had gone out of popular usage by 1600, a lot of late-1400s grammar was in the translation. On the other hand, the KJV is still very accessible today, partly because it gradually became influential, partly because Shakespeare remains influential, and partly because the translators, while they were trying for broad readability, were a bunch of Southerners (that's London, Oxford, Cambridge, not Alabama:-), so you don't have the diversity of UK dialects such as Scots or Geordie or Cornwall English or Welsh-Border, so the last 400 years of linguistic evolution haven't hit it as hard as if he'd hired a bunch of his fellow Scots to translate it.
There are different kinds of backward compatible out there
Can you play existing DVDs on an EVD player? (No, they're not paying the royalties for the codec, and maybe other components.)
Can an EVD player read the data format for existing DVDs so you can send the data to a computer that has codecs? (Probably not, but maybe?)
Can you install new firmware, either by downloading or plugging in a chip, to add new data or codec functions in the future and stay forward-compatible? (If they're smart, yes, because somebody will leak the codecs and formats to make it DVD-backward-compatible:-)
Can you play EVD disks on a DVD player? (Presumably the player won't have the codecs, though some may have royalty-free codecs.)
Can you read EVD disks as data on a DVD player, so your computer can play EVDs using software codecs? (That's the second interesting question - it makes it possible to sell EVDs to a market where people don't have EVD players.)
If most of the EVDs are in Chinese, does it matter that the only players are in China or sold mailorder to overseas Chinese speakers? (Probably not.)
If the point of royalty-free formats is to make the players cheaper, will $20 external EVD players be cheap enough that anybody who wants to play EVDs will buy a player along with their first EVD disks?
Ok, so frickin' sharks are extinct, and you can't get frickin' sharks with frickin' lasers. But now that we've done that,...
Here in Silicon Valley, the place to go for lasers is HSC, Halted {Supply?Systems?} company in Sunnyvale. Their online catalog doesn't have much laser stuff, but the store generally has a lot of random high-powered laser parts as well as lots of other obsolete, surplus, and generally classic electronics and tools, and in general, if you're going to build a LaBoraTory for anything electrical or electronic, you've got to visit there.
Duh.. Wasn't even thinking about that one:-) Scales pretty well, and while it's easy to avoid (because people can use any DNS server they want), most people use their ISP's DNS server. That's more likely to be what they did. It avoids the IP overkill problem, and avoids the DNS round-robin problem, and if you're only trying to filter out some URLs on the targeted servers, you can do that at a proxy filter.
Sometimes there were crop failures, due to a wide range of competence problems with "scientific socialism", and the war obviously led to starvation as well as deaths from bombs and guns, but the main events of mass starvation during the Stalinist period were deliberate - groups of farmers that didn't cooperate with collectivism, or were rich enough that the Communists were jealous of them, got deprived of their animals and land, and either killed, sent to Siberia, or left to starve. Wikipedia article on kulaks.
UDP is a Layer 4 protocol for transmitting packets between (Layer 5,6,or 7) applications - it doesn't have any concept of connection, state, or acknowledgements, either in the packet headers or in the protocol for what to do with those packets. By contrast, TCP creates a connection between the two endpoints, using the 3-way-handshake mechanism, window size management, acknowledgements, retransmit mechanisms, etc., and the connection has state (SYN sent, SYN-ACK received, N bytes still waiting to go into a window, FIN received, etc.)
The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things
Do a simple one-packet response to a one-packet query - DNS usually works this way, and all the protocols like Echo and Daytime that got turned off due to packet-amplification attacks like smurfing work that way. The application doesn't maintain any state - it just answers your question and waits for the next one.
Send a stream of packets, unacknowledged, which you hope will mostly be delivered. Voice and videoconferencing applications work that way - it's better to have an occasional static or screen glitch than to slow the whole thing down waiting a few hundred milliseconds for lost packets to retransmit, watching everybody's mouth move out of sync like a bad Godzilla movie.
Provide a full-scale connection, emulating TCP badly at Layer 7. Applications that do this are usually designed for LANs, where they usually work, and they can get higher throughput with less CPU demand on the computer because the connections usually work and are have much lower latency and loss and higher bandwidth than the environments TCP was designed for.
Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.
Genuine one-shot unacked messages - telemetry apps are often like this, and sometimes logging apps are as well. If you lose the message "It's 43.123 degrees at 12:24:14", there'll be another one soon saying "It's 43.122 degrees at 12:24:15" that's probably just as useful as doing an ack and retransmit.
Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)
I've been wondering how they'd approach this technically, given that they've got a relatively small list of targets and they're talking about filtering 80% of the country's web traffic to block it. Unlike the US, it might be possible to do that in Canada without a huge expense, since a small number of ISPs handle most of the traffic, and most of it's concentrated through a few border crossings, and probably fewer than 20 million users. But it's still a really unbalanced scaling problem.
Bennett's article refers to the problem of blocking web sites by IP address or ISP, which is easy but creates large amounts of collateral damage. (One blocklist that anti-censorship people complained about in the past blocked all of terra.es, one of the world's largest hosting sites, and IP-block overkill is a well-known problem with anti-spammer blocklists.) Alternatively, you could put URL proxy filters on all web traffic at the ISP peering points, which is a large expense and does strongly invite blocking other kinds of traffic once you've done it, as the parent posting discusses. Proxying all web traffic is an approach some smaller ISPs took in the past, so they could use caching proxies and avoid the bandwidth costs of re-downloading common pages, but I doubt it's very common today, except perhaps at corporate and university firewalls.
There is an intermediate technical approach if they're clever - instead of running all web traffic through filters, or blocking all of the IPs that carry the banned material, route the IP addresses of the banned sites to a filtering server, and do the more detailed URL filtering there. This lets you avoid URL handling for most traffic that isn't banned, but still lets you do it for the IP addresses that the targets are in or near. The Internet currently carries about 200000 routes - this would require adding fewer than 1000 routes to ISPs' routers, which isn't a big impact, and lets you reduce costs by using much smaller servers for URL filtering. It also keeps the censorship service as a small specialized application rather than a massive infrastructure that's inviting more censorship.
Censorship is unfortunately a real problem in Canada. I was once at a conference in BC that got picketed by lefties because one of the speakers was a controversial right-wing newspaper publisher from Vancouver area. He was in fact obnoxious, but he was there to talk about censorship, which he knew pretty well because there were censorship laws and regulations that had been written specifically to censor him. On our way to the conference, Canadian customs officials wanted to examine all the literature we were bringing with us - not because of censorship, but because we'd made the mistake of saying we were going to a conference and therefore they suspected we might be thinking about selling something that they could tax. A more well-known example of Canadian censorship was that US feminists got Canada to pass censorship laws because pornography exploits women, and of course the first material that customs started confiscating was lesbian pornography produced by other US feminists... Apparently the US doesn't have a monopoly on prudishness in North America.
This isn't a problem of the American dollar devaluing (inflating) relative to some real standard. This is a problem of copper being increasingly more valuable relative to other commodities. Phone companies around the world are having problems with people cutting down their lines to steal the copper.
The US had a previous round of making it illegal to melt down coins - for a number of years in the late 1800s and early 1900s, the US was on a bimetallic standard, with both gold and silver exchangable at a fixed ratio, so depending on the relative market value of gold vs. silver, people could play games with the rates, and some years it made sense to take dollar banknotes to the Treasury and get coins in one of the metals, melt them down, and sell the metal as bullion, so it was made illegal. This was also tied up in politics of farmers' loans (e.g. if you had a debt in dollars, could you pay with the cheaper metal or did you have to pay with the more expensive metal), mining interests, etc.
It sounds like you think this device is being made for telcos to put into their network backbones to make them more secure, and you're saying that you'd rather have them upgrade either the network backbones or the access connections to your house? That's not what this is for.
This is a device that security-paranoid end users like banks or governments can buy, to put on the ends of building-to-building dark fiber service that they'd rent from the telcos. The reason a vendor like this would be working with telcos is to deal with service technology issues like fiber splices, and general service issues like finding out where dark fiber is available or can be constructed.
Remember that the users aren't just buying the hardware - they also need to get dedicated end-to-end fiber. In some cases, that can be cheap (e.g. you're just going down the street and you can rent conduit and run your own fiber), but if you're buying telco services and going any distance, you're usually going to be dropping a few tens of thousands of dollars a month. In some parts of George-Gilder-Land, it's cheaper than that, but not usually.
There are some economies of scale for the telcos if they start dealing with more dark fiber, which would be a fine thing, but the monthly costs are going to limit the user base more than the $100K hardware cost. The real tradeoff is between the service costs and the ability to distract auditors by pointing at the high-tech shiny thing.
Slashdot Mirror
But there are other types of spammers it also kills off - one popular attack by the clever set is to hijack unused IP address space (typically by using ISPs that don't follow best practices on BGP filtering), blast away spamming for a few minutes, then drop the old address and switch to a new one, leaving the old address in various anti-spam blacklists and impossible to traceroute to. The fact that greylisting wants you to retransmit from the _same_ mail server IP address means that this attack won't work, and the only way for this kind of spam to work is to keep the stolen address space around for long enough to be traceable.
But as other people have said, greylisting also works because it makes the spammer call back later, after there's been time for the spammer's IP address to hit real-time blocklists. You can even implement this one yourself, without having to trust other RBL providers, by keeping some spam-bait email addresses around that never get legitimate email, either on the same domain you're protecting by the greylist or on a separate server (less effective, but less complex to implement safely.)
It'll also cut down on "don't-bouncegram-me" complaints from people whose addresses are being forged by spammers, because it'll reject a lot of that mail before your bouncegram system gets to it.
You may also want to consider checking SPF before bouncegramming unknown senders - lots of people don't use it, and lots of spammers do, but it gives people who are having joe-job impersonation problems a way to keep you from adding to their trouble with your autoresponder, and those are one of the most common sets of SPF users.
I don't see the benefit from this vs. greylisting - either way, you're interrupting the SMTP transmission process before accepting the message, but with double-verify you're doing more CPU work and handling the message-body traffic the first time (when it might be spam)? Part of greylisting's appeal is that you don't need to do much work or accept much traffic on the first attempt, so you can reduce the load on your system and only have to filter spam from the semi-competent spammers.
Of course, you can always whitelist mail servers you deal with often, so their mail doesn't get stuck waiting for 5 or 30 or 60 minutes.
Instead of rejecting connections to the third MX record, you could teergrube them, so the spammer's machine ends up dogged out on tiny TCP windows talking to a mail server that's going very slowly and will eventually reject their message. If you want to get fancy, you could also have it feed blacklists, or at least adjust greylist timers, but just being passive-aggressive toward spammers is a good start.
On the other hand, one American variation on the theme that I've encountered in restaurants was having them put the milk into the already-not-boiling water before putting in the teabag
If I'm in the mood for milk in my tea, I'd want some fairly strong Indian tea, maybe Assam or whatever else is around. But doing that with the more subtle Chinese teas - a Puerh or one of the oolongs - borders on criminal, and doing that with a Japanese green tea or a Chinese green-with-jasmine would be just weird.
But think about the number of people this spammer succeeded in ripping off - was it 100, or 1000, or 10000? Usually you'd spent less time in jail for stealing $1M from one person than $100 each from 10,000 people, or $1000 each from 1000 people, but at six months in jail per petty theft or 1 year per grand theft, he could easily be doing a lot of time.
Remember that this guy's a phishing thief, not just a pills-or-porn seller. How much time does he deserve for theft? If an average worker makes $50K/year, and the spammer makes $500K ripping off N victims, that's 100 person-years of honest labor he'd need to do just to pay them back for the value of their lost work time, not even counting the lost value by not having their money when they needed it. Should he only have to give back 1x what he stole, or pay more than that as compensation?
(Unless the Eschaton is trying to prevent any discoveries from creating closed time-like loops or other variants on time travel that might endanger its future existence, ....) your assertion is bogus. Physicists would really like to have some applecarts get upset, especially if it's done in a way that generates cool new theories that require more physics professors to research, test, and teach about them. And cold fusion? Get real....
There may not be much else that's reasonably priced to spend theoretical physics dollars on, so paying professors to write non-experimentally-testable papers may be the way to go, but there seem to still be lots of physicists who want really really expensive test equipment, either really large accelerators/colliders/etc. or else really big orbiting astrophysics equipment.
Hey, I may not know, but my cats sure like string....
the problem is getting it unentangled again after they're done.
Of course, with cats, their position, velocity, and intentions aren't usually simultaneously predictable; even if you get out the electric can-opener, and can therefore predict what their position will be like in the near future, you still don't know which kitchen door they'll come in.
There are other features, like good voice recognition and text-to-speech, that can probably be done with the current hardware but require software development - I'm surprised they're not there, but if it wasn't ready in time for Macworld, it's an obvious thing to announce in June when the hardware's ready to ship. I'm more surprised that there aren't voice dictation features, since the hardware already supports voice compression (since the phone needs it) and there's plenty of RAM and a screen that would make UI easy to add - maybe the UI's too closely tied to other things that aren't ready yet?
The article says it'll support x86 versions of Windows as guests, but not the 64-bit versions.
One thing I really like about "Keep my name in your code" and related kinds of license variants is it gives you some kind of crude mandatory source control - if you have to indicate that you've modified the code, that makes it easier to track and fix things, or at least if you don't put your name in the code, nobody should have to track you down and get permission for later license changes or whatever.
California has had bans for a couple of years on using laptops in the front seats of cars, as well as on having DVD players there. Basically the only display screens you can have visible to the driver are for controls and navigation equipment. So your GPS is fine, but running Google Maps on your laptop isn't.
But if the mechanicals and raw data formats can be done without too much licensing baggage, so EVDs can be sort of compatible, then I'd be surprised if the things aren't either chippable or downloadable, just as most Europeans I've talked to about DVD players say that stores selling DVD players over there pretty much always give you a nudge-nudge-wink-wink about asking them for the chip to defeat region coding. On the other hand, if they can't make compatible mechanicals and raw data formats, it may not end up being practical to have backward-compatibility-hacking in EVD players, and similarly, EVDs might not end up being readable on computer DVD players.
The point of the EVDs-in-Chinese question was mostly that even if they're not forward compatible so you can't read EVD disks on DVD players, there's enough Chinese market that they may get their economies of scale anyway.
Most modern translations are trying to strike some balance between readability, preservation of the nuances in the original languages, continuity with familiar readings from earlier well-known translations, introduction of better copies of original texts that weren't available to previous translators, better availability of other original-language material that helps us understand the way the language was used at the time the original documents were written, and of course there's the problem of dealing with poetry.
The King James translation was fairly conservative for its time (finished 1611), trying to retain much of the familiarity of the popular Geneva translation (which was politically awkward, because that had a lot of Puritan notes and commentary printed with it, and the King wanted stuff that was politically Anglican), and the Geneva translation retained a lot of continuity with Tyndale's and other translations, so even though the English language had been changing radically during the 1500s, and almost all of the "thee" and "thou" and "ye" and "hast" had gone out of popular usage by 1600, a lot of late-1400s grammar was in the translation. On the other hand, the KJV is still very accessible today, partly because it gradually became influential, partly because Shakespeare remains influential, and partly because the translators, while they were trying for broad readability, were a bunch of Southerners (that's London, Oxford, Cambridge, not Alabama
Here in Silicon Valley, the place to go for lasers is HSC, Halted {Supply?Systems?} company in Sunnyvale. Their online catalog doesn't have much laser stuff, but the store generally has a lot of random high-powered laser parts as well as lots of other obsolete, surplus, and generally classic electronics and tools, and in general, if you're going to build a LaBoraTory for anything electrical or electronic, you've got to visit there.
Duh.. Wasn't even thinking about that one :-) Scales pretty well, and while it's easy to avoid (because people can use any DNS server they want), most people use their ISP's DNS server. That's more likely to be what they did. It avoids the IP overkill problem, and avoids the DNS round-robin problem, and if you're only trying to filter out some URLs on the targeted servers, you can do that at a proxy filter.
Sometimes there were crop failures, due to a wide range of competence problems with "scientific socialism", and the war obviously led to starvation as well as deaths from bombs and guns, but the main events of mass starvation during the Stalinist period were deliberate - groups of farmers that didn't cooperate with collectivism, or were rich enough that the Communists were jealous of them, got deprived of their animals and land, and either killed, sent to Siberia, or left to starve. Wikipedia article on kulaks.
The Applications may or may not create Layer 7 connections or maintain state. Most UDP applications do one of three things
Some applications that look like this are really hybrids - they've gone to a lot of work to make sure they work fine in a stateless UDP environment, where packets might get lost or duplicated, and remote partners might go on and off line, such as remote file-system apps where the Layer 7 acknowledgement that Block 12345 has been written to disk is what the application needed to know anyway. Being stateless lets the app not have to keep track of which remote sites are currently reachable, and lets a server scale to handle lots of sporadic accesses. And sometimes the client app maintains state even if the server doesn't - the client knows it has 242344 more bytes to send to the server, but the server responds to each packet idempotently when it comes in and doesn't worry about the past or future.
Firewalls used to be manually configured for some protocols - you'd allow a UDP connection from 1.1.1.1:1414 to 2.2.2.2:2828 - and also support protocols statelessly - you'd allow ping responses, or TCP SYN/ACKs, but didn't explicitly track which responses were really from which connections. This was usually good enough for TCP, but fairly crude for UDP, since the Layer 4 protocol doesn't tell you state. Stateful inspection techniques let the firewall keep track of each exchange between two sites - you'll accept ping responses from 2.2.2.2 to 1.1.1.1 because you know 1.1.1.1 just sent a ping to 2.2.2.2, and you'll accept TCP packets from 2.2.2.2:443 to 1.1.1.1:12345 because you know 1.1.1.1:12345 did a TCP SYN to that 2.2.2.2:443 and haven't seen a TCP FIN or timed out the connection. They're simulating state, even for protocols that don't have connections or state at Layer 4, because applications usually have one or a series of packet exchanges even if they don't have state at Layer 7 (or only have state at one end.)
Bennett's article refers to the problem of blocking web sites by IP address or ISP, which is easy but creates large amounts of collateral damage. (One blocklist that anti-censorship people complained about in the past blocked all of terra.es, one of the world's largest hosting sites, and IP-block overkill is a well-known problem with anti-spammer blocklists.) Alternatively, you could put URL proxy filters on all web traffic at the ISP peering points, which is a large expense and does strongly invite blocking other kinds of traffic once you've done it, as the parent posting discusses. Proxying all web traffic is an approach some smaller ISPs took in the past, so they could use caching proxies and avoid the bandwidth costs of re-downloading common pages, but I doubt it's very common today, except perhaps at corporate and university firewalls.
There is an intermediate technical approach if they're clever - instead of running all web traffic through filters, or blocking all of the IPs that carry the banned material, route the IP addresses of the banned sites to a filtering server, and do the more detailed URL filtering there. This lets you avoid URL handling for most traffic that isn't banned, but still lets you do it for the IP addresses that the targets are in or near. The Internet currently carries about 200000 routes - this would require adding fewer than 1000 routes to ISPs' routers, which isn't a big impact, and lets you reduce costs by using much smaller servers for URL filtering. It also keeps the censorship service as a small specialized application rather than a massive infrastructure that's inviting more censorship.
Censorship is unfortunately a real problem in Canada. I was once at a conference in BC that got picketed by lefties because one of the speakers was a controversial right-wing newspaper publisher from Vancouver area. He was in fact obnoxious, but he was there to talk about censorship, which he knew pretty well because there were censorship laws and regulations that had been written specifically to censor him. On our way to the conference, Canadian customs officials wanted to examine all the literature we were bringing with us - not because of censorship, but because we'd made the mistake of saying we were going to a conference and therefore they suspected we might be thinking about selling something that they could tax. A more well-known example of Canadian censorship was that US feminists got Canada to pass censorship laws because pornography exploits women, and of course the first material that customs started confiscating was lesbian pornography produced by other US feminists... Apparently the US doesn't have a monopoly on prudishness in North America.
Phone companies around the world are having problems with people cutting down their lines to steal the copper.
The US had a previous round of making it illegal to melt down coins - for a number of years in the late 1800s and early 1900s, the US was on a bimetallic standard, with both gold and silver exchangable at a fixed ratio, so depending on the relative market value of gold vs. silver, people could play games with the rates, and some years it made sense to take dollar banknotes to the Treasury and get coins in one of the metals, melt them down, and sell the metal as bullion, so it was made illegal. This was also tied up in politics of farmers' loans (e.g. if you had a debt in dollars, could you pay with the cheaper metal or did you have to pay with the more expensive metal), mining interests, etc.
This is a device that security-paranoid end users like banks or governments can buy, to put on the ends of building-to-building dark fiber service that they'd rent from the telcos. The reason a vendor like this would be working with telcos is to deal with service technology issues like fiber splices, and general service issues like finding out where dark fiber is available or can be constructed.
There are some economies of scale for the telcos if they start dealing with more dark fiber, which would be a fine thing, but the monthly costs are going to limit the user base more than the $100K hardware cost. The real tradeoff is between the service costs and the ability to distract auditors by pointing at the high-tech shiny thing.