The unified process presupposes that predictions can be made with minimal effort but these can be wrong, so it is necessary to be able to adapt to change. This (reasonable prediction is possible) is one of the main differences compared to agile methods. So the unified process appears to have a more common approach (compared to other disciplines, like civil engineering for example) to software development.
However, it is an error to think the Unified Process as a linear building process as it is fully meant to be iterative and incremental. Failing to recognise this leads to misusing the Unified Process as a waterfall approach which is known to be very risky.
The unified process is composed of 12 disciplines and 6 phases (this is the extended version of the original unified process which we use). These disciplines are mostly the standard ones found in other processes. The same is true for the phases. This means that the static structure of this process is quite similar to others.
The big difference (and advantage) is in the dynamic aspect. Indeed, the unified process is fully iterative and incremental (and in fact the details of the static structure reflect this). This means that the design activity for example is done many times during the development in order to be able to adapt to the potential changes in the requirements (based on the user's feedback).
The unified process has the interesting potential to be stretched in both directions, either towards Agile approaches, either towards waterfall approaches. This makes it the most suitable software development process for most cases.