Slashdot Mirror
Linux: Fighting the FUD of Forking
sebFlyte writes "Fighting the MS FUD machine is a full time job for some open source developers, especially now Microsoft have thrown in the issue of the possibility of Linux forking (as Unix did)... it would also seem that Gates has moved on from telling people to 'get the facts' and creating FUD around patents and IP to criticising the open source communty's ability to create interoperable software."
I've ignored Red Hat and SuSE for about 5 years now, focusing mainly on Debian, Slackware, Gentoo, etc.
Now that I've used a Red Hat system again, I was completely dazzled by how drastically different the experiences are. I expect the GUI to be more polished, naturally, but so many underlying things are different as well. All in all, they're things I can learn, and binary and source compatibility are still there, but it's the trend that's disturbing.
All of the traditional UNIX vendors forked in order to raise the barrier of exit for people who wanted to switch platforms. Sun's platform is still alive today because Solaris is such a unique beast that you have administrators trained solely in the art of this platform. All the UNIX part does is allow for some kind of source compatibility. Maybe.
Cisco took TCP/IP, which was practically invented (and perfected?) on a BSD box and threw it away to build a new proprietary OS to run specifically on their routers.
It's hard to find a major distribution shipping the vanilla kernel these days. When does, for example, SuSE decide that binary compatibility with other distros is keeping them from "enhancing" the user experience? Can they resist?
I'd like to be wrong about all of this.
I don't quite see the problem here.
I am not afraid of forks, if they are executed well.
Look at some examples we've had in the past:
gcc fork - when the gcc development started to slow down, a new group forked it and the primary thing it did was to speed up development.
emacs fork - emacs had had a notice for ages saying that "X11 support was coming RSN", but nothing happened for quite a while. The Lucid-Emacs (later became XEmacs) happened and within a very short amount of time there was quite a hustle and bustle of activity between the two - Yes, there are some interoperability issues here in that both designed their respective GUI concepts a bit differently. But both evolved at a much quicker pace then if we only had one. (Especially good in this case, was that the lucid/xemacs team decided that sticking to old packages like the age old c-mode wasn't a good thing and that there were better alternatives to be used, and they didn't shy away from using them - much to the advantage of the entire community.
If there should be a linux fork, I am not really afraid of it, since those who will fork it, will know that they will also NEED interoperability (an issue that emacs/xemacs didn't really have in that sense, as the files you edit with them ARE interoperable -- and I don't think a linux fork that will make the formats of binaries / shared libs different, will find much acceptance, unless they also manage to continue supporting the old formats as well (pretty much like you can still use a.out binaries, if you still have the kernel support for it compiled in).
I don't think we should just have a kernel-fork just for the sake of it - but if there are good reasons for a fork, I am not afraid of it - in fact, I'd rather welcome it.
Benedikt