> - Upgrade to newer version always fails. I'm left with a broken OS at the end.
I'm pretty sure that this is an issue of having a more sophisticated package management.
OS X and Windows are basically huge software bundles that are dropped on a drive. They rarely change their internal structure gradually (Windows takes an odd middleground of basically keeping all patches around). It's a well understood process and easy to reason about: copy bunch of data A to location B, make sure it matches a checksum. Ship some parts in double in different versions, to support older versions. All the issues I ever had with that were with all the packages software I handbuilt on top of that.
OSes fully built on packaging software from ground up, e.g. apt, rely on the assumption that the package tree is always problem-free and that you can migrate any custom evolution of that tree to a new standard version. While this works formidably for smaller changes (I just want to add a package), where the potential breakage is contained to a rather limited set of packages, possibly close to the leafs of the tree, this gets problematic if you want to change a package on the top of the tree.
I think this gives a lot of power to the approach of immutable machines, combining both approaches: fine-grained dependency-tracking and resolution, while avoiding the evolutionary problems by always rebuilding the system from ground up on any change.
FWIW: I love a proper package management. But I don't believe in its infallibility.
> > Upgrade to newer version always fails. I'm left with a broken OS at the end.
> I'm pretty sure that this is an issue of having a more sophisticated package management.
I'm pretty sure that it's Ubuntu. My understanding is that Debian—from which Ubuntu is derived and which is also apt-based—is known for reliable upgrades.
Actually - it's the relative user-bases and the complexity of the user-cases.
An APT based system is capable of a system upgrade - but you have to help the system. The previous commenter is completely right that one of the underlying assumptions is that the package database is clean.
This applies to both Ubuntu and Debian.
The main challenges for Ubuntu is that there is a lot of ISV software out there which can break as it's not part of the distribution [0], end-users tend to run a variety of PPA's [1] and in general they don't realise the importance of the package database[2] and the classes of hardware that Ubuntu is used on means that driver upgrades can be complex. Actually, if you use Ubuntu's documented upgrade process it runs a variety of checks which standard apt doesn't.
I suppose that with fast Net connections and cheap disks upgrades aren't as needed as they used to be - but they're still one of the best bits of 'magic' I enjoy from the Ubuntu/Debian world.
[0] The counter-point being that end-users want that software e.g. Skype
[1] PPA's are great for end-users as they get to mix stable system software with the latest 'apps' but they cause problems for upgrades because you can't possibly test the variety of upgrade paths
[1] You can argue that they shouldn't have to - but that's a different matter.
I'm pretty sure that this is an issue of having a more sophisticated package management.
OS X and Windows are basically huge software bundles that are dropped on a drive. They rarely change their internal structure gradually (Windows takes an odd middleground of basically keeping all patches around). It's a well understood process and easy to reason about: copy bunch of data A to location B, make sure it matches a checksum. Ship some parts in double in different versions, to support older versions. All the issues I ever had with that were with all the packages software I handbuilt on top of that.
OSes fully built on packaging software from ground up, e.g. apt, rely on the assumption that the package tree is always problem-free and that you can migrate any custom evolution of that tree to a new standard version. While this works formidably for smaller changes (I just want to add a package), where the potential breakage is contained to a rather limited set of packages, possibly close to the leafs of the tree, this gets problematic if you want to change a package on the top of the tree.
I think this gives a lot of power to the approach of immutable machines, combining both approaches: fine-grained dependency-tracking and resolution, while avoiding the evolutionary problems by always rebuilding the system from ground up on any change.
FWIW: I love a proper package management. But I don't believe in its infallibility.