This is not a limitation of the DVI port -- though it would be a limitation of DVI devices connected to it -- it is simply that most video cards do not waste silicon to allow features on a DVI port that DVI devices could not handle.

This does not change the fact that the underlying electrical specifications are identical between DVI and HDMI, nor does it change the fact that the protocol they are speaking is essentially the same. Only the features supported on that protocol are different.

HDMI == DVI + HDCP + audio
... though more recent versions of HDMI have increased the allowed signalling rates, for increased refresh rates and resolutions beyond 1080p.

Personally speaking, I hope that DVI is updated, and soon. As much of an improvement as DisplayPort is on a technical level, I'd prefer to keep DVI around for backward compatibility and interpolability with HDMI.

Me thinks you need to read some specifications before posting. Here's a couple primers:
http://en.wikipedia.org/wiki/Dvi
http://www.diffen.com/difference/DVI_vs_HDMI

HDMI and DVI are electrically identical and partially protocol compatible.

Physically differences:
*Their connectors are physically incompatible and require a converter plug.
*Also, DVI potentially supports a legacy VGA analogue signal on the connector. Few actual DVI cables carry this signal, but it is often available on the video card, which then needs a converter plug to plug into a VGA cable.

Protocol differences:
*HDMI includes support for DRM (HDCP) and audio. These are not supported by DVI devices, though they can be forwarded through a DVI connector to an HDMI device.
*HDMI has had several revisions, which allow for increased clocking and greater bitdepth. I would not expect these revisions to be supported by DVI devices. However, I've never had reason to look into this, so cannot comment further.

The converter (plug) between HDMI and DVI is known as a passive converter, because it has no active electronics inside. All it does is allow two separate types of plugs to connect. Differentiate this with a DVI/HDMI to DisplayPort covnerter, which is active, because HDMI/DVI and DisplayPort have completely different electrical specifications and protocols, even though they are both digital.

Until two months ago, I was a Runbox subscriber for over 10 years. So I can offer a pretty good review of the standard account.

Pros:

1. Respectable mailbox size (10 gigs), more available for extra $$
2. Large attachments (100 megs), though very few other mailservers will be able to handle more than a third of that
3. Respectable feature set (filters, aliases, etc etc)
4. 1 gig FTP account
5. small HTTP account, with CPanel
6. Decent prices

Cons:

1. From anywhere in the continental United States: Slow. Slow SMTP, Slow POP3.

Perhaps it's because of the transatlantic nature of the connection. Perhaps they just have a slow service. But it's only gotten slower over the years. Eventually it became enough to drive me away.

The last time I worked with Fedora (about 4 months ago), I had a technical issue with a version that was 2 releases prior. (For those who don't know, Fedora brings out a major release about every six months.)

Finding no help on Google or Fedora's website, I went to their IRC channel.

There were 150+ users logged in (though who knows how many were actively watching their screens). I politely explained the scenario and asked my question, only to be harassed by several of the forum members. Apparently they don't want to answer questions for anything beyond the previous release. These people actively sought out a sysop to have me kicked from the channel. Simply for asking a question for a version that was maybe a year out of date. The very worst linux zealot attitude, which I'd thought long gone these days, alive and well in the official Fedora channel.

If you don't update to the latest version -- regardless of what reason you may for not being willing/able to do so -- they do not want to hear from you, let alone actually assist you.

That experience was enough to convince me that I don't want anything to do Fedora. Because when there are issues, I don't want to be ostracised for asking for help.

Yet another reason that I'm glad that I do not live in California. Because apparently, somehow, every civilian has what amounts to very nearly full arrest powers in California. Yeah... That couldn't go terribly wrong or be abused.

Source: http://www.leginfo.ca.gov/

In the main, that works. However, it should be noted that support for CUPS-HTTP-ADMIN varies from distribution to distribution, and even from version to version.

What I find (seriously) annoying is that if CUPS-HTTP-ADMIN is enabled, it's always defaulted to localhost only. That may be fine for a desktop... but in case no one ever told the CUPS folks (and the folks creating server linux distros), sometimes linux is used on servers.

To that end, here is my own cheat-sheet on getting CUPS-HTTP-ADMIN on the LAN:

# add the following to cupsd.conf

# to the Listen section, attach port 631 to all NICs
Port 631

# place outside of any other sections, enable Web Interface
WebInterface Yes

# place outside of any other sections, disable HTTPS
DefaultEncryption Never

# to <Location />
Allow all

# to <Location /admin>
Allow all

# to <Location /admin/conf>
Allow all

Yes, it's in shorthand. No, it's not super-duper-secure. Because I have yet to see CUPS-HTTP-ADMIN be an actual attack vector. No, this is obviously not for a public facing linux box.

PS, don't forget to open up TCP 631 on whatever firewall is on your linux machine.

Once upon a time we used Clam for an email scanner on our inbound mailserver. It was totally insufficient -- it does not catch the majority of what's actually "in-the-wild", which is what you most need antivirus for. Nothing is bullet-proof, but Clam doesn't cut it. Not even for free.

Now, that was scanning our email. How does that differ from being used on a PC? Well, for one thing, Clam/ClamWin does not have a resident-memory / on-access scanning ability, so unlike our email scanner, there is no way to guarantee it would scan everything. Secondly, if it wasn't good enough to protect our email, you can be darn sure it won't be good enough to protect your email + everything else.

I'd truly like it if Clam / ClamWin was great. It just isn't. Sometimes you get what you pay for.

In what alternate reality is 30 megabit-per-second an acceptable speed for accessing terabytes of data? That's not even 4 MB/s of average transfer speed. That's not even fast enough to play a 1080p content, and a goodly amount of 720p content.

You want me to even consider a device like this? It needs to have USB 3.0 support, a gigabit link and be able to reliably push at least 500mbit in both directions (device dependant). If that raises the price, then the price needs to be raised - because under 4 MB/s is simply not an acceptable transfer speed. For crying out loud, hard drives have been faster than that for over 20 years.

According to Wikipedia, AMD is worth $4.5b. Possibly more. Perhaps Apple could convince their shareholders to take less. But we'll call it $4.5b for our purposes.

You think Apple wants to spend that much money to acquire a microprocessor company? A microprocessor company that doesn't even have its own fabrication plants? A microprocessor company that is noticeably lagging behind their main competitors: Intel and nVidia? Whatever your feelings towards AMD, you cannot refute that their market share has been on a decline the past few years, and that the Bulldozer lineup has not been able to resuscitate them.

About the only truly positive aspect for Apple would be that they would also get the ATI assets as well. But that's a double-edged sword. What if the ATI lineup slides? As things are, they can easily switch to nVidia GPU's. If they bought out AMD, they'd have little choice to be to stick with ATI gpu's no matter how good or bad things got.

And let's not forget, there are certainly some folks at Apple that were around for the joys of the G5 series -- another processor that was effectively a space-heater. They had problems with that, and took some flack for that. I imagine they'd like to avoid that unpleasant memory.

Personally, I would be shocked if Apple wanted to spend $4.5b, end a successful relationship with Intel, only to acquire a less efficient and often less powerful CPU lineup without acquiring a chip foundry as well. If there was the fabrication plant in there, then perhaps they could use it to make their own ARM chips for their phones/tablets. But they don't even get that.

Meant to say "The disk access patterns for most desktop users do NOT take enough advantage of this to make the increased cost worthwhile."

Someone hack an edit button onto this damn site already. Get with '90s, already.

There are two sides to traditional hard-disk performance: rotational-speed and areal-density. While both increase performance of the disk, they do so in different ways...

Rotational Speed, measured in RPMs, primarily affects random access/seek times -- allowing the disk heads to move to a new location more quickly. This is handy when there is heavy fragmentation (which should never be allowed to happen) or when the data files themselves have lots of non-consecutive data (like in databases). Higher rotational speed will increase transfer speeds... but not nearly so much as most folks think it will. The disk access patterns for most desktop users do take enough advantage of this to make the increased cost worthwhile.

Areal Density, measured in bits/m^2 or bits/in^2, primarily effects continuous transfer speed -- you get to read/write large files more quickly. This will help you more quickly transfer files on your network (though many/most disks can easily enough saturate gigabit ethernet, these days) or load large files into memory, such as the case for video games or other applications with large resource files. Areal density does not have much of an impact on random seek times, and so those numbers haven't seen much improvement over the years. Improving areal density is something drive manufacturers have a keen interest in, as it allows them to build disks with more storage capacity, thereby decreasing the number of platters necessary for a given amount of space, and therefore dropping prices.

Also, keep in mind that, to keep friction/heat/wear-and-tear down, 10k RPM drives tend to have fewer and smaller platters than 7,200 & 5,400 RPM drives; they are hamstringed for storage space. Consider that we now have 4 TB 7,200 RPM drives on the market, but the largest 10k RPM drive is only 1 TB. And the price is about the same.

Both sides of the coin effect performance, but in different ways. Given the amount of time that 10k RPM SATA drives have been on the market, I think it's safe to say that these will never catch on, and that their price will always remain high. 15k RPM desktop drives is nothing but a pipe dream.

SSDs, on the other hand, have ludicrous transfer speeds married to access times that make a 15k RPM drives look pathetic. Their only two caveats seem to be storage space (they still can't keep with traditional hard disks on that, but they're catching up) and reliability. Though flash memory is far from ideal, we can expect both density and reliability to increase over time, even as their transfer rates continue to compete with small RAID arrays.

SSDs already outpace 10k & 15k RPM hard disks in ever measurement of speed. Given time, they will likely catch up in storage capacity and bytes-per-dollar. And, by the looks of it, that point in time is rapidly approaching.

FreeBSD has long (like, 10+ years) had support for Blowfish password hashes. Blowfish was a close second in the AES contest, and is quite strong. Enabling it only requires editing /etc/login.conf and afterwards updating any pre-existing passwords.

You are incorrect, sir. 100mbit is rather more speed than is necessary for almost any thin client use. RDP, for instance, transmits basic window metrics (ie. "draw a window at x1,y1,x2,y2", etc etc), so is highly bandwidth efficient. In fact, with no fancy GUI effects, RDP can run quite comfortably on 10mbit, or even less. I know this for a fact because I work remotely using RDP quite often.

Is 100mbit enough to run a RDP session displaying 1080p60 video? No. But, then, that isn't what RDP is for, and this things display only runs at 1366x768.