However, it is also common to combine this with the checksum() function to reduce it to a 32 bit integer. This makes collisions much more likely, even in relatively small databases. For example, the GUIDs 28258F69-6536-4198-BE37-94960ABF054F and 49B60D4B-DC4A-4E18-825E-B4C99713D011 both checksum to 0xC3AD13D3. With a table of about 100,000 rows collisions will start to occur more frequently by the birthday paradox.

def P(x, n):
  return 1 - ((x-1)/x)**(n * (n-1)/2)
 
>>> P(2**32,77500)
0.503022489601693
 
>>> P(2**32,200000)
0.9905011979711653
 
>>> P(2**52,100000000)
0.6705145268350288

Using this maths, we can see that using a 32 bit random number, the probability of getting at least one collision is 50% at around 77,500 rows and 99% at 200,000 rows. We can also see that if we increase this to a 52 bit number, 100 million rows gives a 67% chance of getting at least one collision, so 64 bit should be plenty.

A compromise of both is to simply truncate the GUID at 64 bits and optionally convert to a bigint.

SELECT CONVERT(BIGINT, CONVERT(BINARY(8), newid()))

If you leave it as binary and don’t need to convert to an integer type, this does not have to be 8 bytes. For example, you could have a 5 or a 10 byte code.

None of these are perfect but the probability of a collision decreases with more bits. If 128 bit is too long for you (e.g. to display to users) but 32 bit generates too many collisions, try a compromise such as 64 bit.

If you are consistent enough, you may even be able to store the original GUID and just display the truncated form, which could allow you to change the length displayed later without changing the probability of collisions. This is more flexible but may lead to confusion among users and consistency is required (differing lengths could lead to bugs).

Put the green and red like/dislike bar on the thumbnail of the video so you can see if a video is going to be any good before you visit it and to reduce mindless spam from misleading video names and thumbnails.

Possibly the best improvement to YouTube usability since the advent of the play button.

1. Time slows down as you approach the speed of light. Velocity is a derivation of time (speed = distance / time). This can make it difficult to measure, and the time dilation needs to be accounted for.
2. When measuring things close to the speed of light, the equipment itself has the same limitations. It takes time for a signal to get from one part of the equipment to another.
3. The Earth itself is moving in the solar system, the solar system is moving in the galaxy, and the galaxy is moving in the universe. The speed of light is an absolute limit, but the measurement of something moving between two points on Earth is a relative measurement. If something was fixed in an absolute position, it would be moving very quickly relative to the Earth.
4. The speed of light limitation applies to objects with mass. The mass of neutrinos is believed to be non-zero, but is not yet completely known, and objects with energy essentially have more mass, so the mass of it changes as it accelerates. It’s hard to do maths when you don’t have all of the starting variables.

I bought a Lycom PE115 6Gbps SATA III adapter, and put it in a PCIe 2.0 port, but when I benchmarked the drive with CrystalDiskMark, on an idle Windows 7 x64 machine (Dual Xeon E5620, 8GiB ECC-R 1333MHz) the results were very disappointing.

Not only was there no improvement over the port on the motherboard, the dedicated 6Gbps SATA III card was actually significantly slower than the 3 Gbps SATA II port (roughly 64% of the speed).

I tried without and then with the drivers for the card installed, and it made no real difference.

Fill 0

The blue bar is on the motherboard’s SATA 3Gbps.
The red bar is on the PE115′s SATA 6Gbps
The yellow bar is the PE115 with drivers manually installed.
The green bar is back on the motherboard, to confirm it.

The results show that the PE115 consistently performs significantly worse than the motherboard in both fill 0×00 (above) and fill random (below) operations.

Fill Random

All of this was done in CrystalDiskMark 3.0.1 x64.

There’s nothing new in Windows 8 that warrants replacing Windows 7 so soon but there’s enough changed on the surface to piss people off. People don’t like having changes forced upon them (see also: Facebook). The only people that will be getting Windows 8 will be people who got it pre-installed and had no choice, and I don’t see any businesses upgrading to Windows 8 whatsoever.

Decompiler
Converts object code to a higher level language, such as C.

Disassembler
Converts object code to assembly.

Stupid
Charging thousands of dollars for software whose target audience primarily use it to crack software rather than paying for it.

The “SQL” pronunciation is actually defined in the original 1986 specification for SQL and confirmed by common DBMS such as MySQL.

Most of the answers seem to revolve around running Visual Studio as a normal user rather than an administrator, but I was already doing that.

Eventually, a reply to this bug provided an answer.

When I checked the key, I saw

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\DDECache\VisualStudio.10.0\system]
"ProcessName"="devenv.exe"
"WindowName"="Visual Studio Application Management Window"
"WindowClassName"="VisualStudioAppManagement"

Deleting the “system” key then opening a file again worked and replaced the key with working values

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\DDECache\VisualStudio.10.0\system]
"ProcessName"="devenv.exe"
"WindowName"="DDEHandler"
"WindowClassName"="DDEHandler"

When it has the correct values (refresh to make sure that it does) remove “set” permissions from your own user so that it can’t replace them with the bad values, to make the change permanent.

In particular, it is common for people to set a “cd /d path” in their AutoRun key in the registry but this breaks the power toy and Windows 7′s built in hold shift and right click on a directory to open a command prompt there. This can be worked around by adding a /d to the shell extension in the registry.

What doesn’t seem to be mentioned anywhere though is that this AutoRun key also gets run when you double click on a batch file. That means a batch file which assumes its own current directory (a reasonable assumption – more reasonable than using absolute paths) may not be able to find files in the same directory as it.

What I really wanted to do was move my home directory to my D: drive but the command prompt was still opening on the C:

Most people also seem to only change the default directory of their command prompt to match a non-default home directory.

The first mistake I made was to type “cmd” into the start menu and right click on it to pin it there. This calls it “Windows Command Processor” and starts in C:\Windows\System32 (because that’s where cmd.exe lives). Instead, go through the start menu programs list and find “Command Prompt” under “Accessories” and pin that. It will correctly default to your home directory, because the “start in” is set to %HOMEDRIVE%%HOMEPATH%. Note that you could just change this shortcut’s arguments (cmd /k cd “PATH”) or start in but it will only change it for that one shortcut.

Anyway, once you are using “Command Prompt”, set your home directory. I’m using Windows 7 Pro, so I can go to Computer Management and just set the directory for my user in the GUI under “Users and Groups”. This is no longer available in home versions of Windows (they shouldn’t have removed it) but you may still be able to set your home directory by using the command

net user USERNAME /homedir:PATH

where “USERNAME” is your user name and “PATH” is the directory you want to set. You can check this with the command net user.

When I type “cmd” into the run dialogue, it still opens on C: but at least batch files work now. Further suggestions are welcome.