"Operating system vendors face this problem once or twice a decade: They need to migrate their user base from their old operating system to their very different new one, or they need to switch from one CPU architecture to another one, and they want to enable users to run old applications unmodified, and help developers port their applications to the new OS. Let us look at how this has been done in the last 3 decades, looking at DOS/Windows, Macintosh, Amiga and Palm."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2008-08-25
*nix systems are more straightforward to migrate/upgrade between versions, because few if any changes are ever made on a 'unix' level i.e. the bare iron. the /etc directory was there in 1987, 89, 99, 2009 and I'll wager it will be there in 2019.
The linux kernel being distinct from libc distinct the gnu userland etc., and so system wide changes just can't happen, they just aren't practicable.
Nobody controls the whole OS from boot -> shutdown like, say, the MacOS or NT teams would. Even the BSD teams don't have direct control over more than the core utilities. This is not a bad thing IMO!
One side-effect is that us *nix users will probably never need to go through the sorts of migrations mentioned in the article, something that you can testify. A unix system will be a unix system, forever and ever :-)
This is good in terms of upgrades, continuity and predicability. I for one won't enjoy upgrading one night to find /etc merged into some binary registry :-)
But this also means that there will never be a quantum leap moment like 98 to XP for the linux community. No big changes, rearchitecting linux to be a BeOS or even a Plan 9.
Nothing against pulseaudio, dbus etc. as daemons, but they do not sit in /dev as *nix intuition suggests. There is nothing specifically unix about them, they would feel just as home as an NT service.
Unionfs on netbsd has always frozen for me, and /proc is useful to help create unportable scripts^W^W job security ;-)
Member since:
2007-09-22
Your kidding right ?
Like Windows doesn't have that problem ? Some people have said: 50% of the code of Windows and it's associated parts are compatibility layers and old code that will is very hard to take out.
Just take any 'modern' Windows, all files in the Windows-directory are still in 8.3 format and a progra~1 directory still exists.
I've never seen any Unix with such a file-system specific backwardscompatibility problem.
I actually think Unix-like operating systems are doing a lot better in that regard. A lot of current Unix-like (software) is open source and this means a lot of the upstream applications in distributions like Debian get a patch from their downstreams to support newer libraries/API's, I actually think a lot less is left behind. People often discuss the duplication in the Open Source world, but patches from Ubuntu end up in Suse, patches from Suse end up in RedHat, patches from Fedora end up in Debian, etc.
And what is wrong with running deamons for specific tasks like dbus or pulseaudio ? It's better when it's seperate, because it can easiliy be replaced. Just an example, who still runs Sendmail, other then a few large users ? OK, some people who care for a certain type of license in their base-installation (OpenBSD for example, but they are busy replacing it with their own opensmtpd). Why is that ? Because it's just pipes, files, sysctl's and text. Any part can easily be replaced.
Could you please explain what you mean with distinct from the unix philosophy, maybe I just misunderstood. :-)
Maybe you were thinking of Plan 9 or something like that ? Many of it's ideas have already found a place in current Unix-like operating systems. OK, maybe unionfs isn't such a great implementation. But /proc is their in Linux.