Difference between 32 bit and 64 bit processors

Computer technologies are constantly evolving and this evolution will continue to grow for many decades. This evolution is not only happening in software but also in hardware as both of them has to go hand in hand.

x86 is a very old technology that started with the 8086 family of processors. It has now evolved into the x86-32 version which is the most common version and its successor the x86-64 or more commonly known as x64. Its move towards a gradual shift to x64 has started quite early while there were still no major drawbacks seen in the pc market. This is because the first market to experience the problems related to x86 was those who run high-end servers.

Running a system that has 32bit architecture means that you are always limited to what 32bits can point to. A 32bit long pointer could only point to a maximum of 4.2billion addresses which is just about 4GB of memory. This means the processor can only allocate up to 4GB of memory to a certain program even if 16GB of memory is available. This limitation may not be a problem for a home setup but in a server environment, it presents a huge problem. That’s why x64 processors appeared very early for the consumers.

The x64 architecture still follows what x86 has but it improves on it by having 64bits in every address. This means that the memory capacity of the x64 architecture is the square of 4.2billion, which for now is an unimaginable amount of memory. That coupled with certain enhancements makes the x64 architecture a certainly great processor to replace its predecessor.

The advantage of x64 architecture is that it has backward compatibility with x86. So even if your operating system is 32 bit, users won't notice any difference in functionality. And once the 64 bit OS or software arrives you can just update it without upgrading hardware.

What is OpenID and how it works?

Many websites offer features that are only available to users who first log-in to the system. In a typical application, user identity is confirmed ("authenticated") upon entering the username and password for the account. This approach is straightforward and works, but there are drawbacks. Users are usually required to remember a username/password for every website they use, which can be problematic.

OpenID is an open standard that defines a way that web-based applications can authenticate users by delegating the responsibility of authentication to identity providers. With OpenID, users have a single identity that can be used on any OpenID-enabled application, and they only need to remember one password.
In this article, I describe the OpenID authentication system and show how a web application built with Ruby on Rails can use OpenID to authenticate its users.

How OpenID works?
OpenID relies on the HTTP protocol to exchange messages between users and "identity providers." Consider a user named Bob, whose identity provider is my OpenID (www.myopenid.com). Bob uses the Drupal content management system that happens to be an OpenID consumer. Here's the general workflow when Bob logs into his Drupal account through OpenID:

1. Arthur visits any OpenID-driven website.
2. Arthur enters his OpenID identity URI, "arthur-id.myopenid.com," in the login form and clicks a Submit button. That's his OpenID identity URI, which looks like a website address but identifies Bob and his identity provider.
3. Arthur's web browser is redirected to a web page served by myOpenID, where he is prompted for his password.
4. Arthur enters his OpenID password and clicks a Submit button.
5. myOpenID confirms Arthur's password, and his web browser is redirected to the website he opened with automated log-in.

Arthur entered his password only on the identity provider website, and never on the consumer website. The user's password is not shared with the consumer and only needs to be submitted once by users to the identity provider, preferably over a secure connection.

The following diagram best explains how OpenID works:

Benefits of using OpenID:

OpenID is an open standard that defines a way that web-based applications can authenticate users via a single identity. OpenID provides several benefits to users and developers. Users only need to remember one username (their identity URI) and password to access multiple applications. With a simple cookie and Remember Me checkbox, an OpenID identity provider can act as a convenient Single Sign-On (SSO) solution for someone who uses multiple OpenID consumers.

OpenID identity providers are responsible for the authentication of users It's nowadays common for web apps to offer OpenID support as an alternative to traditional authentication methods, but letting experts handle password security reduces the risk of accounts being compromised.

You will be glad to know that Google also provides OpenID. Use http://openid-provider.appspot.com to know your OpenID provided by Google.

Reference: Dr Dobb's