You have to be going about 10km/h over before anyone would pull you over (from my experiences and communications with locals).

They have signs on QEW that say 50km/h over = license revoked and car towed. They don't play around.

For us Americans, that's about 30 miles per hour over the speed limit. It'd be like doing 85 in a 55, 100 in a 70, etc.

Is it? I kind of guessed. Due to the km/h being so small on my speedometer and not aligning properly, It appears to be about 64 on my mph.

That said, nobody's going to pull you over going 3km over the speed limit--so.

I am surprised this is a thing. I cross into Canada regularly at both Fort Erie and 87/A-15 and it's funny to watch.

In Ontario, the signs say 100km/h = 60mph. This isn't quite true but it's a good safe number if you want to prevent speeding.

In Quebec, their signs say 100km/h != 60mph.

It's much closer to about 64mph. Bust people end up speeding anyway.

Holy fuck a Linux/Unix guy I'd shake hands with. This is the correct answer, folks :P The minute you get into a "get off my lawn" approach to technology is the day you sign your career's death warrant.

You still have to license RHEL if you intend to have support. I suppose if you don't mind going at it your own...

You assume that people actually pay attention to these key mismatches and don't automatically click "yes" to them.

Would be worth a social experiment just to prove you idiots wrong ;)

I wish you'd post as a logged-in user, your comments are some of the only intelligent ones in this thread.

I have long said we need import tariffs/taxes on imported labor. We already do this for goods.

Starting with Microsoft Office 2007, the Office Open XML file formats have become the default[3] target file format of Microsoft Office.[4][5] Microsoft Office 2010 provides read support for ECMA-376, read/write support for ISO/IEC 29500 Transitional, and read support for ISO/IEC 29500 Strict.[6] Microsoft Office 2013 additionally supports both reading and writing of ISO/IEC 29500 Strict

http://en.wikipedia.org/wiki/Ooxml

Not to be confused with Open Office XML or Microsoft Office XML formats.

I didn't say Microsoft supported ALL standards, just that they support *some* standards.

What are you talking about?<br><br>http://en.wikipedia.org/wiki/Ooxml<br>http://blogs.msdn.com/b/dmahugh/archive/2010/04/06/office-s-support-for-iso-iec-29500-strict.aspx<br>http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnumber=61798<br><br>Microsoft supports an open document standard, standardized by the ISO, with Office and has for some time, though admittedly not "Strict" support until Office 2013.

Which, amusingly, could be ported over to Linux as well rather easily--given it's running within the user's context.

We use McAfee at work. With proper coaxing, it works pretty well and is unobtrusive--but it actually requires becoming familiar with the product and its features. It took a lot of trial and error.

One quick way you can help reduce A/V hit on a system is to remove zip file scanning during on-access scans and on-demand scans. Also, setting a file scan time limit can limit the amount of time the AV spends on one particular type of file.

Other antivirus solutions handle this a bit better, but McAfee is workable with the proper implementation.

AAAAAAND furthermore, in a purely technical sense IPv6 should be faster than IPv4 connectivity when it comes to routing.

Current IPv4 implementations actually do two state table tracking. Both the NAT table and the firewall's state table. In a dual stack, native configuration; only the firewall state table is required for IPv6 traffic alone; with no NAT table required. Or, in some cases, minimal NAT tables for specific devices when you wish to deploy IPv6 only and are supporting legacy devices that do not support it.

So, in theory, routing performance should be edged up a bit in IPv6 land. Also including the fact that hosts are now doing traffic fragmentation and the router's only involvement in fragmentation is sending an ICMP response (PACKET-TOO-BIG) rather than queuing and fragmenting traffic itself. Router performance should ultimately go up by quite a bit.

Ah, looks like100% of their broadband network is dual stack. Nice achievement for those folks.

"Dual stack takes more resources and complexity."

Yes, it does take labor and sometimes duplication of effort, but it doesn't REALLY negatively impact actual routing performance for most people with the exception of situations where routing for v4 is done in ASICs and v6 is done in the CPU, where v6's performance will ultimately be slower than the equivalent in v4 traffic.

However, this is so rare of a hardware configuration these days in most cases. Modern firewalls/routers/edge devices are doing everything in software with powerful enough CPUs to do both, where the performance would be no different than the equivalent increase in IPv4 traffic. Juniper SRX devices run in this configuration (with BSD running as the base OS), and my Ubiquiti device runs a dual core CPU as well.

If you have any questions, why not talk to Comcast? They've deployed IPv6 in a dual stack configuration across nearly their entire residential network (as the OP noted here). Clearly if there were performance problems that negatively impacted the cost of scalability, they wouldn't have made that move.