Not true. AOL may be big, but they don't own 90% of all the Internet customers out there. I don't have to go through them to get to more than 50% of the people on the Internet, unless I explicitly want to get to their particular customers.
Likewise, Time Warner may own a lot of content, but they don't own 90% of all content out there and I don't have to go through them in order to get content, unless I want their particular content.
These kinds of things cannot be said of Microsoft -- If I want to get to more than 50% of the people out there using computers, I *MUST* go through them one way or the other.
I don't recall where I saw it, but the point was made that Microsoft is a horizontal roadblock that pretty much everyone has to go through, whereas AOL/Time Warner is a vertical integration (or roadblock) that only affects people wanting to go a particular path.
Yes, Star Wars is his baby. Yes, he has special plans for releasing it in digital form. No, those plans don't have anything to do with DVD.
Anyone who has actually paid close attention to what he's doing with filming directly on digital media and what Lucasfilm has been doing in the area of increasing the quality of home video would have a good idea of where he's going.
Imagine if you had blue (or even UV) lasers that could cram nine or even sixteen times as much data onto each layer of a DVD, and a dozen or more layers per side, so that you could have an HDTV quality picture with THX quality sound on a DVD-size disc. And you could probably even have multiple camera angles for each and every scene.
I can't say that this is exactly what he has in mind, but he's exceptionally well plugged in to where digital media is going, and helping to drive a lot of the technology.
He's got extremely high standards, and if he's going to release an audio/videophile version of his movies, you can be damn sure that it's not going to be a crappy DVD.
As an example of the exposure differences they had to deal with, check out http://smaug2.whatisthematrix.com/dld/NUMBER_TWO.m ov and compare frames 49 & 51 (which are similiar) to frame 50 (which is rather darker than either of the other two).
This might be a QuickTime artifact, or it might be real. Either way, this sort of thing is probably the simplest of all the problems they had to compensate for.
Directories are nice, but I think IBM's Clever project demonstrates that intelligent searching can actually do quite a whole lot. Read the Scientific American article on the subject for more information.
Of course, there's also Google, which although perhaps not quite as intelligent as Clever, seems to be light-years ahead of everything else I've ever seen.
OpenBSD audits everything under/usr/src. Most of the auditing is fixing bugs, so that buffer overruns simply can't happen, stack smashing attacks are impossible, etc.... When a bug is found anywhere in the code, it is fixed -- even if there is not a known exploit, the bug is fixed anyway.
That's the biggest part of the default security that is inherent in OpenBSD -- Simply eliminating bugs.
There's another part -- where strong crypto is integrated by default into all those places where it can be of help, but as recent references on/. to papers written by Bruce Schneier demonstrate, crypto is actually a very small part of the overall security picture, albeit a critical part.
Fixing all the known bugs in the kernel and stuff under/usr/src has nothing to do with the integration of the crypto. These are things that should be done with all OSes, not just OpenBSD.
You could leave the strong crypto in packages that could be added appropriately (via the 'net), according to the location of the user -- RSA implemented with RSAREF in the US, but implemented with faster (and publicly available source, so it is likely to be more bug-free, and avoid embarassing things like buffer overflows in the RSAREF libraries) for overseas customers. But you might always get one package or the other by default, depending on where you are.
Of course, when it comes to packages and ports, you have to depend on the respective authors, but if they have the time and the necessary tools, it wouldn't hurt to have the same auditing procedures applied to them by the same auditing team, and then fixes offered back to the authors.
That way, everything in the OS would be more bug-free (and less susceptible to being exploited), and the system as a whole would tend to be more secure.
I didn't see any of the questions about Bastille Linux versus Debian, or if there are any plans to try to do a secure version of Debian, so that the Linux community can finally have something that might be approaching the inherent default security that is available with OpenBSD.
I have previously worked for Collective Technologies, a consulting company that has their own 1-800 and 1-900 number support lines that they offer to their customers. Red Hat has a partnership with CT wherein CT provides "premier support" for Red Hat worldwide.
You'll note that CT also has a partnership deal with Sendmail, Inc. During my time there, one of the serious pitches we made to Greg and Eric was that CT provide *all* the call center support for sendmail. As it turns out, although Sendmail, Inc has their own call center support team, they have actively pursued a partnership with CT in other areas, and even before that partnership was official, there was plenty of business they were sending our way because they simply couldn't handle it all.
I can tell you from personal experience that unless you're a professional support organization (such as a consulting company) and you can focus exclusively on providing technical support (including 1-800/1-900 support), you simply *cannot* provide that support at a sustainable cost that you can charge to your customers.
This is why more and more businesses are out-sourcing their entire support operations to dedicated support and consulting companies, such as CT.
The advantage that CT has is that they can provide far more than just standard 1-800/1-900 support, and if a customer has an in-depth problem the call center folks can pass the issue over to the appropriate regional sales representatives, and they can actually put a warm body on-site for that customer.
Companies like Red Hat and Microsoft can't do this. They instead rely on companies like CT to provide those additional consulting services. Even companies like Sendmail, Inc. have a hard time doing this, even though they've managed to snap up virtually every sendmail or SMTP-knowledgeable person whose name I've ever heard (and who could be stolen away from their current endeavours), and a lot of guys whose names are completely unknown to me.
Anyway, my point is that Red Hat can't possibly charge a fee that would be high enough to actually pay for all the potential sendmail support calls that they might get, and therefore it's in their best interest to pay big money to Sendmail, Inc. to become a preferred corporate customer, and get a lot more attention paid to their own agenda, in terms of bug-fixes, etc....
I disagree. While for the vast majority of people, there is no technical reason why sendmail should be preferred over other MTAs, there are cases where more obscure things need to be done and sendmail is simply the only functional choice.
I can do things with sendmail rewrite rules that are simply impossible (or at least *extremely* difficult) in other MTAs. This is why postfix is only 99% sendmail-compatible, since that last 1% is a killer.
Of course, sendmail *is* the best documented MTA in the world (it actually has two books written on the subject, Sendmail: Theory and Practice by Avolio and Vixie, and the definitive reference sendmail (now in it's second edition) by Bryan Costales with Eric Allman.
While perhaps not strictly a technical reason, available documentation (or the lack thereof) is a very strong motivating factor as to why many people choose to select particular products, SMTP MTAs included.
FreeBSD shoots for three to four releases per year, but the problem we typically have is that there are usually problems with the CD-ROM images as they were released (they won't boot on some machines, or don't recognize the Ethernet cards, or whatever), and the -RELEASE versions are almost always out-of-date within days after being created.
Instead, if you want an actual working version that fixes a couple of major problems in -RELEASE, you instead need to pick up the most recent -STABLE.
There are plans to try to fix this problem, so that -RELEASE is more useful out-of-the-jewel-box, but I suspect that there are still going to be a lot of people that buy (or otherwise get) the -RELEASE CD-ROMs, but never bother to even take off the shrink-wrap.
I guess it's a good way to support the project, but it doesn't seem to be a really good way to develop and distribute an OS. It seems to me that there should instead be three main branches:
-RELEASE, which gets made as rock-solid stable as possible, and although important bug-fixes get created (and patches released), no really new functionality gets added. Today, the best you can do in this arena is to run the previous major release down (e.g., -RELEASE is currently on 3.x, so you would instead run the latest 2.x version available), but this isn't a real fix for the problems.
-STABLE, which is -RELEASE plus some additional functionality, bug fixes, etc..., but no really huge architectural changes. This is pretty much -STABLE today.
-CURRENT, which is the absolute latest bleeding-edge version, and if you run it, you get what you deserve. There's absolutely no guarantees that the thing will ever even compile, much less run or even function according to design. If you want this, you damn well better track the freebsd-current and cvs-commit mailing lists religiously, cvsup RELENG_4 nightly, etc.... And don't forget wear your Nomex(tm) jammies if you ever want to post to any of the mailing lists. Again, this is pretty much -CURRENT today.
Are there any plans for such a three-pronged development track for Debian?
> SuSE is releasing tools to make their version of Linux more secure > (ie hardening scripts and other tools.)
I disagree that the application of scripts can take an OS that has not been audited and turn it into one that is "secure".
IMO, you need to go back and look at every single interface to every single routine, you need to go back and look at every single call of functions that are known to be typically mis-used (e.g., gets() instead of fgets()) and either replace them or ensure that they're used safely, and you have to start incorporating the security-minded thought process in all the code that gets committed from that point on (so that a routine that has been secured doesn't get broken by a later commit). You also need to follow all this up with a system of checks and balances, so that if you happen to miss something at one stage in the process, it's likely to get caught at another stage.
It is my understanding that this is basically what happend with OpenBSD, and is the reason why they have *never* had a security breach in a piece of the core OS (e.g., something from/usr/src) that had been audited. The FreeBSD folks have likewise recently fired up the freebsd-audit project, which I have started to monitor, and hope to perhaps some day be able to contribute something useful to.
That said, there is Bastille Linux, which I understand hopes to become the OpenBSD of the Linux world. But it's based on Red Hat. It would seem to me that it would be much more natural to base it on a much more solid distribution (such as Debian). As such, my personal opinion is that they're starting two strikes down, and with both arms and one leg tied behind their back.
So, to mirror and expand upon the above question, are there any plans to create a security/crypto-oriented distribution based on Debian, or perhaps efforts to modify the Debian development methodology so that not only does all the core code get audited, but the audit process gets built into the development and commit process?
I had a senior-level research project that I did on the subject of comparing a variety of language parsing systems. It was supposed to be a straight comparison of augmented transition node networks (ATNs) as compared to something else (I can't remember what).
However, my conclusion was that each method (and there are more than two) had both its strengths and weaknesses, and no one of them was "better" than any other in general.
I then went on to propose that the best solution would be to have a "blackboard" system, whereby you allow each parsing methodology to do what it does best and you don't try to twist each of them to handle everything, and they each contribute their own part to the mapping and parsing of the input.
The result being that you can have multiple feedback loops, and the total output should be better than the sum of individual outputs of the various subsystems.
It wasn't exactly the paper that had originally been envisioned, and my adviser only gave me a "B" for it. I wish I had a copy of it online, so that I could provide an URL to it. Hopefully, I've still got a floppy disk around somewhere that I could pull up that has a copy of it. If I ever manage to get a copy and put it up, I'll let you folks know.
Anyway, it seems to me that the sort of systems that Systrans and GPLtrans have created would be ideal applications of this methodology -- take what they have now (strict sentence/phrase/word substitution, or whatever), and combine that with a system that could tag and direct the substitution based on contextual clues.
Implemented properly, you should be able to continue to extend and improve this sort of a system pretty much indefinitely.
I definitely agree about Card and Gibson, so I'm curious to know what you think are really good books to start with for Gaiman and Williams -- books that highlight their style, as well as being particularly engaging?
As a person who speaks only English, but resides in a country where the official languages are French, Flemish (Dutch by any other name), and German, I can tell you from personal experience that it is *much* easier to understand someone speaking another language than it is to try to make yourself understood in another language.
In my experience, this is universal.
Therefore, it makes a lot of sense having two separate converters (one that attempts the richest possible understanding of the language to be converted from, so that the maximum amount of semantics can be preserved in the conversion to the Universal language), and a simpler one that just converts from the Universal language into the "canonical" form of the local language.
In the computer world, we understand that "write" operations are typically much more expensive than "read" operations, and depending on our application mix, we may optimize one at the expense of the other.
It makes just as much sense to do this with regard to processing of natural languages as it does with other computer programs.
No, don't send e-mail to congress. Nothing gets ignored more than e-mail.
See my comments above on this same topic, but basically you should send a real physical letter. In fact, if you're *really* serious, name the congress critter on the outside of the envelope and send it Registered Mail.
This is the same service that the US gov't uses to send material classified up to SECRET (they use certified mail for material that is only CONFIDENTIAL), and the US Postal Service regulations and laws stipulate that *only* the named individual may receive the letter.
Violation of USPS regulations and laws regarding things like this is a *very* serious matter. You're talking jail time on the minimum conviction.
This is also a really good trick to pull on some corporate CEO if you're pissed off at the service that they provide and you want to complain -- they end up having to get pulled out of whatever meeting they're in, so that they can sign for the letter in person.
And it wouldn't hurt to send a carbon copy to the Better Business Bureau via certified mail (there's no need to piss them off;-).
No, don't send a telegram -- they get ignored. Don't send a fax -- they also get ignored. Don't call on the telephone -- you'll get the run around and no one will pay attention to you. Don't send e-mail, either -- *nothing* is more ignored than e-mail.
No, take the time to write a real physical letter. That's the only thing that gets the remotest level of attention from congresscritters.
If you're willing to spent $0.34 (or 17BEF, if you're a US citizen living and working in Belgium), then they figure you're probably actually serious about whatever it is you're writing about.
Having something fucked up by incompetence is no better than having it fucked up by someone who knows what they're doing but has contrary opinions as to what the program should be allowed to do.
> Well, it could be, but D-H is broken. (See > Schnier's _Applied_Cryptography_ for details.)
True enough, which is why we have Elgamal.;-)
And why weren't you there to celebrate the expiration of the Diffie-Hellman patents with the rest of the DC Cypherpunks, and other luminaries such as Whitfield Diffie himself and Peter G. Neumann?;-);-)
However, this is just key exchange. We also need a signature standard. Since the keys are being signed off-line, even if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.
Zone transfers aren't secured in this respect. Data within a zone is cryptographically signed, so that you can be sure that it really is valid, and someone hasn't been able to spoof you, etc....
This way you can also be sure that when you ask for "fred.yourzone.org" and the answer is that the next valid label is "george.yourzone.org" that not only does "fred.yourzone.org" not exist, but that there are no other labels that exist between that and "george.yourzone.org", so "frederic.yourzone.org" doesn't exist (and you don't need to ask about it), nor does "fredbert.yourzone.org" (and you don't need to ask about it either), etc....
The zone transfers are secured in the same way they always have been -- by the authoritative nameservers restricting what IP addresses it will respond successfully to AXFR (or IXFR) queries.
Slashdot Mirror
Not true. AOL may be big, but they don't own 90% of all the Internet customers out there. I don't have to go through them to get to more than 50% of the people on the Internet, unless I explicitly want to get to their particular customers.
Likewise, Time Warner may own a lot of content, but they don't own 90% of all content out there and I don't have to go through them in order to get content, unless I want their particular content.
These kinds of things cannot be said of Microsoft -- If I want to get to more than 50% of the people out there using computers, I *MUST* go through them one way or the other.
I don't recall where I saw it, but the point was made that Microsoft is a horizontal roadblock that pretty much everyone has to go through, whereas AOL/Time Warner is a vertical integration (or roadblock) that only affects people wanting to go a particular path.
Yes, Star Wars is his baby. Yes, he has special plans for releasing it in digital form. No, those plans don't have anything to do with DVD.
Anyone who has actually paid close attention to what he's doing with filming directly on digital media and what Lucasfilm has been doing in the area of increasing the quality of home video would have a good idea of where he's going.
Imagine if you had blue (or even UV) lasers that could cram nine or even sixteen times as much data onto each layer of a DVD, and a dozen or more layers per side, so that you could have an HDTV quality picture with THX quality sound on a DVD-size disc. And you could probably even have multiple camera angles for each and every scene.
I can't say that this is exactly what he has in mind, but he's exceptionally well plugged in to where digital media is going, and helping to drive a lot of the technology.
He's got extremely high standards, and if he's going to release an audio/videophile version of his movies, you can be damn sure that it's not going to be a crappy DVD.
As an example of the exposure differences they had to deal with, check out http://smaug2.whatisthematrix.com/dld/NUMBER_TWO.m ov and compare frames 49 & 51 (which are similiar) to frame 50 (which is rather darker than either of the other two).
This might be a QuickTime artifact, or it might be real. Either way, this sort of thing is probably the simplest of all the problems they had to compensate for.
Directories are nice, but I think IBM's Clever project demonstrates that intelligent searching can actually do quite a whole lot. Read the Scientific American article on the subject for more information.
Of course, there's also Google, which although perhaps not quite as intelligent as Clever, seems to be light-years ahead of everything else I've ever seen.
They've been around for a while. Ron Guilmette created wpoison a while back. There's even a Wired story about it.
;-)
Unfortunately, wpoison appears to have since disappeared, although Ron never mentioned this to me.
Interestingly, I found out all this information doing a simple Google search on "wpoison".
OpenBSD audits everything under /usr/src. Most of the auditing is fixing bugs, so that buffer overruns simply can't happen, stack smashing attacks are impossible, etc.... When a bug is found anywhere in the code, it is fixed -- even if there is not a known exploit, the bug is fixed anyway.
/. to papers written by Bruce Schneier demonstrate, crypto is actually a very small part of the overall security picture, albeit a critical part.
/usr/src has nothing to do with the integration of the crypto. These are things that should be done with all OSes, not just OpenBSD.
That's the biggest part of the default security that is inherent in OpenBSD -- Simply eliminating bugs.
There's another part -- where strong crypto is integrated by default into all those places where it can be of help, but as recent references on
Fixing all the known bugs in the kernel and stuff under
You could leave the strong crypto in packages that could be added appropriately (via the 'net), according to the location of the user -- RSA implemented with RSAREF in the US, but implemented with faster (and publicly available source, so it is likely to be more bug-free, and avoid embarassing things like buffer overflows in the RSAREF libraries) for overseas customers. But you might always get one package or the other by default, depending on where you are.
Of course, when it comes to packages and ports, you have to depend on the respective authors, but if they have the time and the necessary tools, it wouldn't hurt to have the same auditing procedures applied to them by the same auditing team, and then fixes offered back to the authors.
That way, everything in the OS would be more bug-free (and less susceptible to being exploited), and the system as a whole would tend to be more secure.
I didn't see any of the questions about Bastille Linux versus Debian, or if there are any plans to try to do a secure version of Debian, so that the Linux community can finally have something that might be approaching the inherent default security that is available with OpenBSD.
What about it, guys?
I have previously worked for Collective Technologies, a consulting company that has their own 1-800 and 1-900 number support lines that they offer to their customers. Red Hat has a partnership with CT wherein CT provides "premier support" for Red Hat worldwide.
You'll note that CT also has a partnership deal with Sendmail, Inc. During my time there, one of the serious pitches we made to Greg and Eric was that CT provide *all* the call center support for sendmail. As it turns out, although Sendmail, Inc has their own call center support team, they have actively pursued a partnership with CT in other areas, and even before that partnership was official, there was plenty of business they were sending our way because they simply couldn't handle it all.
I can tell you from personal experience that unless you're a professional support organization (such as a consulting company) and you can focus exclusively on providing technical support (including 1-800/1-900 support), you simply *cannot* provide that support at a sustainable cost that you can charge to your customers.
This is why more and more businesses are out-sourcing their entire support operations to dedicated support and consulting companies, such as CT.
The advantage that CT has is that they can provide far more than just standard 1-800/1-900 support, and if a customer has an in-depth problem the call center folks can pass the issue over to the appropriate regional sales representatives, and they can actually put a warm body on-site for that customer.
Companies like Red Hat and Microsoft can't do this. They instead rely on companies like CT to provide those additional consulting services. Even companies like Sendmail, Inc. have a hard time doing this, even though they've managed to snap up virtually every sendmail or SMTP-knowledgeable person whose name I've ever heard (and who could be stolen away from their current endeavours), and a lot of guys whose names are completely unknown to me.
Anyway, my point is that Red Hat can't possibly charge a fee that would be high enough to actually pay for all the potential sendmail support calls that they might get, and therefore it's in their best interest to pay big money to Sendmail, Inc. to become a preferred corporate customer, and get a lot more attention paid to their own agenda, in terms of bug-fixes, etc....
I disagree. While for the vast majority of people, there is no technical reason why sendmail should be preferred over other MTAs, there are cases where more obscure things need to be done and sendmail is simply the only functional choice.
I can do things with sendmail rewrite rules that are simply impossible (or at least *extremely* difficult) in other MTAs. This is why postfix is only 99% sendmail-compatible, since that last 1% is a killer.
Of course, sendmail *is* the best documented MTA in the world (it actually has two books written on the subject, Sendmail: Theory and Practice by Avolio and Vixie, and the definitive reference sendmail (now in it's second edition) by Bryan Costales with Eric Allman.
Then there's the increased available online documentation, both the FAQ, and my own Sendmail Performance Tuning for Large Systems paper that I wrote and presented at SANE'98.
While perhaps not strictly a technical reason, available documentation (or the lack thereof) is a very strong motivating factor as to why many people choose to select particular products, SMTP MTAs included.
It's interesting that you mention this problem.
FreeBSD shoots for three to four releases per year, but the problem we typically have is that there are usually problems with the CD-ROM images as they were released (they won't boot on some machines, or don't recognize the Ethernet cards, or whatever), and the -RELEASE versions are almost always out-of-date within days after being created.
Instead, if you want an actual working version that fixes a couple of major problems in -RELEASE, you instead need to pick up the most recent -STABLE.
There are plans to try to fix this problem, so that -RELEASE is more useful out-of-the-jewel-box, but I suspect that there are still going to be a lot of people that buy (or otherwise get) the -RELEASE CD-ROMs, but never bother to even take off the shrink-wrap.
I guess it's a good way to support the project, but it doesn't seem to be a really good way to develop and distribute an OS. It seems to me that there should instead be three main branches:
-RELEASE, which gets made as rock-solid stable as possible, and although important bug-fixes get created (and patches released), no really new functionality gets added. Today, the best you can do in this arena is to run the previous major release down (e.g., -RELEASE is currently on 3.x, so you would instead run the latest 2.x version available), but this isn't a real fix for the problems.
-STABLE, which is -RELEASE plus some additional functionality, bug fixes, etc..., but no really huge architectural changes. This is pretty much -STABLE today.
-CURRENT, which is the absolute latest bleeding-edge version, and if you run it, you get what you deserve. There's absolutely no guarantees that the thing will ever even compile, much less run or even function according to design. If you want this, you damn well better track the freebsd-current and cvs-commit mailing lists religiously, cvsup RELENG_4 nightly, etc.... And don't forget wear your Nomex(tm) jammies if you ever want to post to any of the mailing lists. Again, this is pretty much -CURRENT today.
Are there any plans for such a three-pronged development track for Debian?
> SuSE is releasing tools to make their version of Linux more secure
/usr/src) that had been audited. The FreeBSD folks have likewise recently fired up the freebsd-audit project, which I have started to monitor, and hope to perhaps some day be able to contribute something useful to.
> (ie hardening scripts and other tools.)
I disagree that the application of scripts can take an OS that has not been audited and turn it into one that is "secure".
IMO, you need to go back and look at every single interface to every single routine, you need to go back and look at every single call of functions that are known to be typically mis-used (e.g., gets() instead of fgets()) and either replace them or ensure that they're used safely, and you have to start incorporating the security-minded thought process in all the code that gets committed from that point on (so that a routine that has been secured doesn't get broken by a later commit). You also need to follow all this up with a system of checks and balances, so that if you happen to miss something at one stage in the process, it's likely to get caught at another stage.
It is my understanding that this is basically what happend with OpenBSD, and is the reason why they have *never* had a security breach in a piece of the core OS (e.g., something from
That said, there is Bastille Linux, which I understand hopes to become the OpenBSD of the Linux world. But it's based on Red Hat. It would seem to me that it would be much more natural to base it on a much more solid distribution (such as Debian). As such, my personal opinion is that they're starting two strikes down, and with both arms and one leg tied behind their back.
So, to mirror and expand upon the above question, are there any plans to create a security/crypto-oriented distribution based on Debian, or perhaps efforts to modify the Debian development methodology so that not only does all the core code get audited, but the audit process gets built into the development and commit process?
I had a senior-level research project that I did on the subject of comparing a variety of language parsing systems. It was supposed to be a straight comparison of augmented transition node networks (ATNs) as compared to something else (I can't remember what).
However, my conclusion was that each method (and there are more than two) had both its strengths and weaknesses, and no one of them was "better" than any other in general.
I then went on to propose that the best solution would be to have a "blackboard" system, whereby you allow each parsing methodology to do what it does best and you don't try to twist each of them to handle everything, and they each contribute their own part to the mapping and parsing of the input.
The result being that you can have multiple feedback loops, and the total output should be better than the sum of individual outputs of the various subsystems.
It wasn't exactly the paper that had originally been envisioned, and my adviser only gave me a "B" for it. I wish I had a copy of it online, so that I could provide an URL to it. Hopefully, I've still got a floppy disk around somewhere that I could pull up that has a copy of it. If I ever manage to get a copy and put it up, I'll let you folks know.
Anyway, it seems to me that the sort of systems that Systrans and GPLtrans have created would be ideal applications of this methodology -- take what they have now (strict sentence/phrase/word substitution, or whatever), and combine that with a system that could tag and direct the substitution based on contextual clues.
Implemented properly, you should be able to continue to extend and improve this sort of a system pretty much indefinitely.
I definitely agree about Card and Gibson, so I'm curious to know what you think are really good books to start with for Gaiman and Williams -- books that highlight their style, as well as being particularly engaging?
As a person who speaks only English, but resides in a country where the official languages are French, Flemish (Dutch by any other name), and German, I can tell you from personal experience that it is *much* easier to understand someone speaking another language than it is to try to make yourself understood in another language.
In my experience, this is universal.
Therefore, it makes a lot of sense having two separate converters (one that attempts the richest possible understanding of the language to be converted from, so that the maximum amount of semantics can be preserved in the conversion to the Universal language), and a simpler one that just converts from the Universal language into the "canonical" form of the local language.
In the computer world, we understand that "write" operations are typically much more expensive than "read" operations, and depending on our application mix, we may optimize one at the expense of the other.
It makes just as much sense to do this with regard to processing of natural languages as it does with other computer programs.
See my other comments above. In short, don't send e-mail, send a real physical letter.
In fact, if you're really serious, send it via certified or registered mail. That will most certainly get their attention.
No, don't send e-mail to congress. Nothing gets ignored more than e-mail.
;-).
See my comments above on this same topic, but basically you should send a real physical letter. In fact, if you're *really* serious, name the congress critter on the outside of the envelope and send it Registered Mail.
This is the same service that the US gov't uses to send material classified up to SECRET (they use certified mail for material that is only CONFIDENTIAL), and the US Postal Service regulations and laws stipulate that *only* the named individual may receive the letter.
Violation of USPS regulations and laws regarding things like this is a *very* serious matter. You're talking jail time on the minimum conviction.
This is also a really good trick to pull on some corporate CEO if you're pissed off at the service that they provide and you want to complain -- they end up having to get pulled out of whatever meeting they're in, so that they can sign for the letter in person.
And it wouldn't hurt to send a carbon copy to the Better Business Bureau via certified mail (there's no need to piss them off
No, don't send a telegram -- they get ignored. Don't send a fax -- they also get ignored. Don't call on the telephone -- you'll get the run around and no one will pay attention to you. Don't send e-mail, either -- *nothing* is more ignored than e-mail.
No, take the time to write a real physical letter. That's the only thing that gets the remotest level of attention from congresscritters.
If you're willing to spent $0.34 (or 17BEF, if you're a US citizen living and working in Belgium), then they figure you're probably actually serious about whatever it is you're writing about.
Having something fucked up by incompetence is no better than having it fucked up by someone who knows what they're doing but has contrary opinions as to what the program should be allowed to do.
The result is still a fucked up program.
> Well, it could be, but D-H is broken. (See
;-)
;-) ;-)
> Schnier's _Applied_Cryptography_ for details.)
True enough, which is why we have Elgamal.
And why weren't you there to celebrate the expiration of the Diffie-Hellman patents with the rest of the DC Cypherpunks, and other luminaries such as Whitfield Diffie himself and Peter G. Neumann?
However, this is just key exchange. We also need a signature standard. Since the keys are being signed off-line, even if DSA is considerably slower than RSA, it shouldn't be that big of a deal -- they only need be signed once.
Zone transfers aren't secured in this respect. Data within a zone is cryptographically signed, so that you can be sure that it really is valid, and someone hasn't been able to spoof you, etc....
o nfig/trusted-keys.phtml to learn more about DNSSEC and how it works.
This way you can also be sure that when you ask for "fred.yourzone.org" and the answer is that the next valid label is "george.yourzone.org" that not only does "fred.yourzone.org" not exist, but that there are no other labels that exist between that and "george.yourzone.org", so "frederic.yourzone.org" doesn't exist (and you don't need to ask about it), nor does "fredbert.yourzone.org" (and you don't need to ask about it either), etc....
The zone transfers are secured in the same way they always have been -- by the authoritative nameservers restricting what IP addresses it will respond successfully to AXFR (or IXFR) queries.
Follow the links from http://www.isc.org/view.cgi?/products/BIND/docs/c