He's probably referring to TKIP and thinking it is the only method available for WPA2.

TKIP has a few vulnerabilities (as detailed here and elsewhere) but as noted in the Wikipedia entry, none of them retrieved the key, and relied on short packets with mostly known content, and were not able to inject many packets (3-7), and the packets they could inject were fairly short (28 bytes, then 596 in a later attack).

None of that sounds at all like WEP's 56bit worthlessness.

While I prefer 1 and 10Gbit wired Ethernet, I have no problem with WPA2-Personal and even WPA is fine for low risk activities, although I have it disabled on all my access points.

(off topic, where in blazes did they hide the setting to change your signature? Damn Dice and their crappy playing around with /. *grumbles*)

Exactly!

Many times I have already read the article on another site and some to slashdot to read the comments.
They don't provide any news that I haven't heard anywhere else. I can't remember a time... ever I think.
There are precious few other sites on the net with comment sections worth reading, and it would be a damn shame to lose slashdot,but if they remove classic as a viewing option, I don't know that I will stick around, but I know for sure I will be around a lot less.

Arstechnica has already been getting a lot more of my time lately, mostly for it's much more timely stories and original content.

They like to think they are special I guess...

But the sentiment is the same, the BETA site stinks, and near unusable. Keep the classic interface as an option, or I imagine a good number of their viewers will find a new news source.

The signal isn't changing. HDMI merely doesn't transmit extra HDMI only stuff the DVI end wouldn't understand. HDMI's default pixel format is RGB, which is sent across the cable in exactly the same way as DVI. When transmitting RGB data, there is no difference between them. TMDS is the same for both.

Maybe it's like on the internet... everything talks IP, but says some people still run ancient email clients that only speak POP3, but the server supports POP3, IMAP, Exchange, etc. All of those formats are still running over IP, but when the POP3 client connects to the server, the server negotiates a POP3 connection and does its business.

HDMI uses the same signals to transmit extra stuff to HDMI devices, but that doesn't change the signal. The signal is what defines electrical compatibility. Since HDMI uses RGB as its native/default pixel format, sent across the dame D0/D1/D2 data links as DVI, in the same TMDS signal, there is no difference. When it discovers an HDMI device at the other end, it turns on some extra stuff, the existing stuff doesn't change.

RGB data between HDMI devices is exchanged exactly the same as between HDMI and DVI. Wikipedia says HDMI packetizes everything, including the video data, but that is not how it's defined in the actual standard, and I'll take the standard's word over Wikipedia.

I hope that clears things up a bit. And as to your question, the HDMI specification dictates that all HDMI devices power up assuming the other end is DVI until being told it is HDMI, and even then, it still has to negotiate which HDMI version it supports to turn on those additional features. It's stated there in Section C2 that I pasted above.

So really, since they are so similar, you could almost think of DVI as HDMI .5 or something, since it has no audio, no HDCP, no YCbCr colorspace. HDMI 1.3 added ethernet over HDMI, but that didn't change the signal any, just added a feature over the existing signal, and it has to be negotiated between the devices. What they do share, RGB video, is exactly the same, there is no "DVI RGB", just RGB without the extra HDMI stuff like audio, ethernet, etc.

The practice of powering up in the least capable mode is common all over electronics, and software. PCI devices come in 3.3v, 5v, and universal which supports both. Except for the voltage, it is electrically compatible with itself, but the slots are keyed to prevent damage. Ethernet is another example, all ethernet devices power up in 10Base-T mode and negotiate up to the highest level both sides mutually support. 10Base-T ethernet uses CSMA/CD on the wire, while 1000Base-T forbids it, but 1000Base-T devices still support it when talking to 10Base-T.

In the network world, one would say HDMI and DVI share the same PHY, just HDMI adds lots more commands over it.
DVI only knows about DVI, because the (original) spec is much older. HDMI came afterwards, and purposefully sharing the same PHY, mandated DVI compatibility. Any DVI devices that support extra HDMI features are doing so either according to a newer spec, or out of DVI's spec, but still using the same TMDS signal. That underlying signal never changes, during any negotiations, except to higher speeds in higher HDMI specs. The only thing that ever changes is what is transmitted over it.

As to what AMD has done... I really don't understand it. It can't really be a profit thing, since those adapters are usually included free with the card. But still, this is the first I've heard of any DVI devices doing audio out the DVI port. I haven't read the entire latest DVI standards, but I doubt it was added there, since the last update according to Wikipedia was in '01, and the working group's domain has a search parking page on it.

I found a copy of the HDMI spec someone posted at Purdue: https://engineering.purdue.edu/ece477/Webs/S12-Grp10/Datasheets/CEC_HDMI_Specification.pdf

Section 5.1.1 Link Architecture
"As shown in Figure 5-1, an HDMI link includes three TMDS Data channels and a single TMDS Clock channel. The TMDS Clock channel constantly runs at a rate proportional to the pixel rate of the transmitted video. During every cycle of the TMDS Clock channel, each of the three TMDS data channels transmits a 10-bit character. This 10-bit word is encoded using one of several different coding techniques.

The input stream to the Source’s encoding logic will contain video pixel, packet and control data. The packet data consists of audio and auxiliary data and associated error correction codes.
These data items are processed in a variety of ways and are presented to the TMDS encoder as either 2 bits of control data, 4 bits of packet data or 8 bits of video data per TMDS channel. The Source encodes one of these data types or encodes a Guard Band character on any given clockcycle."
The word packet is only used when describing packet and control data. Video data is transmitted as pixel data, with each color component going through a separate data link, remarkably like DVI...

Section 6.5 specifies how it draws pixels in RGB mode, which is the only mode HDMI and DVI share, and strangely enough they put the RGB pixels on the same data links as DVI does, in the same TMDS format.

Section 8.3.3 is titled "DVI/HDMI Device Discrimination" and specifies that any device that does not identify itself as an HDMI device in its EDID will be treated as a DVI device. Meaning it can't use all the extra features of HDMI.

Appendix C "Compatibility With DVI" :
C.1 Requirement for DVI Compatibility All HDMI Sources shall be compatible with DVI 1.0 compliant sink devices (i.e. “monitors” or “displays”) through the use of a passive cable converter. Likewise, all HDMI Sinks shall be compatible with DVI 1.0 compliant sources (i.e. “systems” or “hosts”) through the use of a similar cable converter.

When communicating with a DVI device, an HDMI device shall operate according to the DVI 1.0 specification, "[...continues]

C.2 HDMI Source Requirements
When communicating with a DVI sink device, an HDMI Source shall operate in a mode compatible with that device. This requires that the Source operate under the following limitations:
Video pixel encoding shall be RGB.
No Video Guard Bands shall be used.
No Data Islands shall be transmitted.

An HDMI Source may transmit Video Data Periods without Guard Bands only when communicating to a DVI sink device or during the process of determining if the sink device is HDMI capable. An HDMI Source, upon power-up, reset or detection of a new sink device, shall assume that the sink device operates under DVI 1.0 limitations. An HDMI Source shall determine if the sink device is an HDMI Sink by following the rule(s) described in Section 8.3.3. Upon detection of an HDMI Sink, the HDMI Source shall follow all of the HDMI Source-related requirements specified in this document.

All electrical and physical specifications in Section 4 shall be followed by the HDMI Source even when communicating with a DVI sink device.

C.3 HDMI Sink Requirements
When connected to a DVI source device, an HDMI Sink shall operate as a DVI 1.0 compliant sink with the exceptions outlined in Section C.1 above. A DVI source device will always be restricted in the following ways: Only RGB pixel encoding is used. There is no Guard Band on the Video Data Period. There are no Data Islands transmitted. An HDMI Sink, upon power-up, reset or detection of a new source device, shall assume that the source device is limited to the above behavior. Upon the detection of an indication that the source is HDMI-capable, the HDMI Sink shall follow all of the HDMI Sink-related requirements specified in this document.

All electrical and physical specifications in Section 4 of the HDMI Specification shall be followed by the HDMI Sink even when communicating with a DVI source device.

Section 4 details HDMI's TMDS implementation, which is substantially the same as DVI's, with this notice in section 4.2.5 titled "HDMI Sink TMDS Characteristics" :
"There may be a risk of source damage if the Sink asserts a very high or very low voltage, such as beyond the maximum ratings in the DVI 1.0 specification, on any TMDS line during power-on or other power transitions. "

I found a copy of the DVI 1.0 specification which specifies larger electrical tolerances than HDMI, hence HDMI's warning to adhere to HDMI's spec and not DVI's.

In other words, since HDMI is a superset of DVI, its saying unless the device identifies as an HDMI device, it will disable all/most of the features added by the HDMI spec. It clearly states, twice that the two specifications are electrically compatible. In the next two sections of the specification it shows the pinouts of the DVI-D to HDMI adapters, which merely route the data-links around. HDMI runs within DVI's voltage tolerances, they use the same TMDS, the same everything, except HDMI supports many more features than DVI. HDMI's extra features don't make it electrically incompatible, that isn't the definition of electrical incompatibility. Intel's Slot 1 and AMD's Slot A where mechanically/physically the same connector, but rotated 180 degrees because they were not electrically compatible.

In the end, yes, there are differences between the two specifications, but only with HDMI being a superset of DVI. Everything they share in common is done the same way. Semantics/definitions love to trip people up.
I suppose you are just confused as to the definition of electrical compatibility then.

You really don't like to be wrong, do you?
DVI-D and HDMI both use Transition-Minimized Differential Signalling as their electrical protocol. Past that, HDMI added HDCP to protect the [MP|RI]AA's "valuable" content. After the HDMI specification was published and became common on PCs, many/most PC graphics chips added HDCP capability to their DVI-D implementations, so that with a passive adapter that only changes which pins go where, everything works. As far as what is transmitted on those pins, it is the same.

From Wikipedia's article on HDMI "Because HDMI is electrically compatible with the CEA-861 signals used by digital visual interface (DVI), no signal conversion is necessary, nor is there a loss of video quality when a DVI-to-HDMI adapter is used." Citing the HDMI 1.3a specification at http://www.hdmi.org/manufacturer/specification.aspx (they make you sign up to download it, but it's free)

Changing the pins around does not make it electrically incompatible, that's what is called physical incompatibility, and that's what passive adapters do.

There really isn't any more proof to offer than the HDMI specification itself, unless you think that is wrong...

That was kind of why I was asking him what his role would be in the hypothetical collective...
He's probably the type that goes to potlucks without bringing food too heh

Wow. I suppose the rest of us are supposed to be glad you are a productive member of our commune? What is your role in the collective?

Paying other people to do work that we cannot or will not do ourselves is a tenant of a functional society. I don't know, or don't care to be a part of the society you picture yourself a member of.

And then foreclosing on her house?