Slashdot Mirror

Speciation is the genetic degeneration of a species to a point where certain members of the species are no longer able to reproduce with certain other members of the species.

No. It's not a "degeneration", and it's not about individual "certain members". It's about populations. If two groups can't interbreed, they're not the same species.

There's nothing at all to imply that this sort of microevolution would eventually accumulate to create a different kind of animal, which was my original point in the comment you quoted.

A new species is most definitely a "different kind of animal". And beyond that, if you'll read the link I gave you (Here's Google's cached version as it seems to be unreachable at the moment) you'll notice observed instances of very large changes: unicellular algae becoming colonial, bacteria undergoing large changes in morphology.

And earlier this year, a remarkable mutation was observed in E. Coli bacteria that left them able to metabolize citrate. Certainly that a "different kind" of bacteria.

For instance, if poodles became so inbred that they were no longer able to successfully reproduce with other breeds, would you say they had become a different species?

Yes. That is exactly the usual biological definition of a species.

Now, if they also somehow developed opposable thumbs, I'd say they were a different species

No, that wouldn't necessarily tell whether they were a different species. Some dogs have dewclaws, some don't, they're still the same species.

Liquid nitrogen (liquid density at the triple point is 0.707 g/mL) is the liquid produced industrially in large quantities by fractional distillation of liquid air

The cost of liquid nitrogen depends on the distance from related facilities and the price of energy; the actual cost tends to range between 0.10 and 0.50 USD/L.

both from wikipedia

The process of making liquid nitrogen consists of condensing atmospheric gases (principally nitrogen and oxygen), separating the liquefied gases, packaging and handling, and delivering the liquids. The most expensive part of this process is packaging and handling. This is reflected in the relative costs for "cylinder" and "bulk" gas prices. In the US, liquid nitrogen usually costs about $2/gallon when delivered in dewars and about $.50/gallon when delivered and pumped into a bulk storage tank. Prices tend to be higher the farther away from the condensing plant you are and outside the continental United States.

From Interesting Products

The namedroppers list has, in the last 10 years I've been monitoring it, been a source of misinformation and frequently mismanaged.

Kaminsky's bug is a rehash of an old bug that non-BIND nameservers were already strong against.

If your sole source of information about DNS comes from the likes of Randy Bush, you sir are an embarrassment to network administrators everywhere.

1. According to the IETF, DNSSEC was started in 1993. That's far longer than a decade.

2. A controlled, toplevel deployment of DNSSEC to .SE knocked out a number of .SE sites. Look at this for more details.

3. If you honestly think there aren't install costs with replacing DNS with something else, you're a fucking idiot and not worth my time..

Argument by vigorous assertion? Please. This is common knowledge. The BIND group says this isn't important, and DNSSEC is almost there.

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSSEC is currently deployed live in multiple countries, .gov and .arpa are now signed (but only for testing purposes at the moment). Yes, the number of DNSSEC hosts is only in the low 5 digits, but that's still way more then DNSCurve. 11 vendors have DNSSEC compatible DNS servers, which I believe is 11 more then DNSCurve. DNSCurve would have to be significantly better in order to garner support at this stage, and I'm not seeing it.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

This is a valid point. Only about 1/4 of recently tested home routers allowed DNSSEC traffic. It's also a problem that is trivial to solve in the long term. Once DNSSEC is deployed, routers will follow. Realistically however, all home routers will be DNSSEC capable before Windows can deal with the DNSSEC data. DNSSEC can still make policy decisions at the ISPs recursive resolver before that time however.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

Strange that the link you send doesn't mention DOS attacks at all.
DNSSEC requires 0 more compute power, but does increase network traffic. DNSSEC can be extended to use ECC instead of RSA to reduce the network overhead, with NO computational overhead.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

Oh? Read RFC 4034, then get back to me. Elliptic curve crypto already has a specified algorithm type, listed in appendix A.1. Unfortunately, the exact format hasnt been standardized yet. There are 245 more unassigned crypto specifications available for future use, I'd call that extensible.

DNSCurve does have some good ideas since it was designed to be easy to deploy, while DNSSEC deployment frankly sucks. DNSSEC is designed by committee,and it shows. On the other hand, it has many future-proof features like the ability to upgrade the crypto used in case RSA, DSA, ECC, or any other scheme falls like a house of cards, or simply need to be made longer in order to survive attacks.

If DNSCurve was proposed 5 years ago, it would have had a good chance of becoming the standard. Now, frankly, it's too late. Most of the major DNS servers support DNSSEC, .gov is currently signed and all US government sites must use DNSSEC by next year, the root servers and reverse .arpa domains have DNSSEC testbeds, Comcast has deployed their dnssec test servers. The political problems of who holds the root keys will be solved soon and DNSSEC will be live. Whether it takes off or not is a question for the market to decide.

Yes, but not more then DNSSEC, which is a published, widely implemented, and tested system.

I disagree. DNSSEC isn't widely implemented, and the widest test had numerous problems.

DNSCurve is 100% compatible with DNS. There's nothing a firewall could do that would be compatible with DNS that is incompatible with DNSCurve.

DNSSEC is not.

DNSCurve trades off more compute resources and the need to have the signing key on the public DNS server to get encrypted DNS, while DNSSEC has a lower server compute load and can store the signing keys off the server, but communicates in the clear.

DNSCurve protects against denial of service attacks. It requires far less compute-power than DNSSEC.

It's hard to make a case for the need to protect the DNS traffic from sniffing, the threat is modification, not sniffing.

Rubbish. Even an amateur cryptographer would tell you that the more you know about the message, the easier it is to break it. Confidentiality protections reduce the amount of knowledge, and thus protect against attacks that are yet unknown.

I would like to see elliptic curve crypto standardized and used in DNSSEC as it will significantly save on the traffic needed, but that is something that can be easily changed later. DNSSEC is very extensible and designed with the future in mind.

I don't think you know what you're talking about.

1. Have you looked at BIND's implementation of DNSSEC? It's thousands of lines of code alone.
2. See #1.
3. RFC4033: DNSSEC (deliberately) doesn't provide confidentiality; RFC 4033: DNSSEC does not protect against denial of service attacks.
4. The bind people claim that BIND9 was written by "a whole new set of people" but at least thirteen of the developers have been identified to work on both.
5. I'm leaving this one alone.
6. CA certificates were planned for an earlier incarnation of DNSSEC
7. I don't think this requires clarification, but this pdf indicates that the IETF started DNSSEC in 1993.

Do you actually check? Or do you just call people trolls who you don't agree with?