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.
Does wider adoption benefit the developers of OSS, or would they be better spending their time working on the software than fighting FUD?
(I mean this as a serious question, not trolling)
500GB of disk, 5TB of transfer, $5.95/mo
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
Funny how someone who talks a lot about the software 'ecosystem' wants customers to invest in this one dinosaur - instead of being amazed at the natural process of species differentiation and survival of the fittest.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
I think this is brillant, couldn't have come from a more knowledgable person at a better time. Especially given that in the past day or two a nice little article got published up on Groklaw about the SMB / CIFS protocol and what legnths they have to go to, to reverse engineer / pull it apart on the wire. It's essentially a slightly intelligent brute force method.
0 10415933
Take a look. I couldn't have made the timing for this article any better if I tried.
http://www.groklaw.net/article.php?story=20050205
I second Tridge's motion that when Microsoft really wants to come to the party on interoperability, let me know. I want to be there.
Personally, I think the major reason why they are going through what they are doing for interoperability now, it's all because of market pressure with the rise of open source, and the open standards which it follows. See what's happening with all the governments demanding open standards for documents etc?
*sigh* when will they learn?
Curiosity was framed; ignorance killed the cat. -- Author unknown
Nobody said that EVERYTHING is going to break on Longhorn.
But enough of it is going to break to make switching a pain in the butt, you can be sure about that. But not so much is going to break that NOBODY is going to switch.
The stupid large corporations are screwed anyway, because they have vendor lock-in due to their unwillingness to train anybody to use another OS, so they'll buy Longhorn regardless of the expense and conversion problems.
Small businesses, OTOH, have somewhat more flexibility to switch to another OS or keep using the old one. This varies by business since some businesses don't want to train or convert either.
It took three years for most people to upgrade from Windows 2000 and 98 to XP because there wasn't enough reason to do so (from 2000 anyway). Microsoft doesn't want to repeat that mistake. ALso they want to differentiate from Linux more strongly. So this time the OS will be VERY different - which will break things.
Microsoft doesn't care because they have forced the corporations into a licensing scheme that pretty much forces corps to upgrade every three years or lose money on the deal (even though they've already lost money since Longhorn is late - a major corp complaint.)
However, if the hardware upgrade requirements are as reported, Microsoft could find itself in deep crap. Which is probably why they dumped WinFS (which, BTW, is a feature they've been promising for about the last ten years - and haven't delivered on yet). I expect to see Avalon reduced in functionality over the next year as well - with the result that Longhorn will end up being just a different version of XP with some new eye-candy - and Microsoft will be back where it started with no one bothering to upgrade.
The bottom line: Windows is now so bloated and so screwed up that even Microsoft can't change it effectively.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Well, kinda... But if you want it to work properly, well sell you a new version of your (otherwise perfectly working) software for a mere $500 a copy.
Microsoft thrives on non-interoperability. You remembe the debacle of word'97? It couldn't save properly in word5 format. Once you bought one copy of word '97 you had to upgrade every copy of word in your company or deal with unusable copies of various documents interrupting the work flow all over the place.
(yeah.. they fixed that problem a year later but by that time, most companies had paid Microsoft the billions of dollars in upgrade fees, which was the entire intention.
(it might have been word '95 that did this, but you get my point)
In any case, Longhorn is going to be different enough from current windows that it's probably going to be just about as nasty (and expensive) to 'upgrade' to the arbitrary restrictions of Longhorn as it will be to upgrade to Linux and Open Software.
Free Software: Like love, it grows best when given away.