Slashdot Mirror
Countries Ponder: GNU/Linux vs. Microsoft
koody writes: "IDG has an overview of how many countries are getting drawn into the debate over the relative merits of using open source software rather than Microsoft Corp.'s Windows applications. Seems like many countries would be slowly moving towards the open source community, while a few still pledge allegiance to Microsoft."
> Do they it 'cos they see the benefits of open source or are they just anti-USian ?
> Like the "evil NSA key windows backdoor" rubbish.
> I doubt they would ditch Windows if it was produced by a company of their own.
And what if it would be that way?
As an european country I would find it hard to rely internal security soly on an american company. What if there is a bug, country XYZ can't do anything about it until some guy in the USA fixes it. Now what if the software would be used for something important? And what if we just would have diplomatic problems because of a embargo of product X? (maybe about cars, fuel, meat, who know what...)
It should be the same reason why we europeans or any other country can't use the GPS for anything important. (like i.e. steering the trains with it)
Here the situation is quite obvious. GPS can be turned of with a switch in the USA. Yes GPS is useable as comfortable add-on but non USA countries can never rely on it. Thats why the EU is planning to do it's own positing system, not because it's better than GPS, but we will be able to rely on it.
Same goes for software, a non USA country can not safely use unexchangeable parts like microsoft products for anything important. It's always important to have at least two possible sources for a product, if not more. And windows fills this requirement not.
Okay for the non-geeks, why does OpenSource software fill this need? You still don't have more than one source, _but_ you get all the construction plans with the software, plus the right to actually use them. As a country in time of need you are able to fix possible problems yourself.
--
Karma 50, and all I got was this lousy T-Shirt.
That's not a fair generalization. The government can easily switch to another brand of pen, stapler, or jet without worrying interoperatibility with a existing supplies of paper or the existing air traffic control system. There aren't alot of security issues for a government office using a monoculture of Bic and Bostitch. The government is free to disassemble any pens, staplers, or jets they buy to search it for spying devices, attempt to repair problems, hire a third party to hire problems, or customize the products for their use. There isn't alot of risk of a license audit coming from Bic, Bostitch, or Lockheed.
This is a myth, and has been debunked so many times that further repetition can only be the result of intentional ignorance. I don't see how this Microsoftian FUD helps the open source cause.
Here is one of the better posts on the issue by screen name "adamba":
I worked at Microsoft for ten years, most of it on the core Windows NT/2000 (hereafter referred to as NT) networking code. [...]
I know a lot about the TCP/IP stack that is running on NT. Here is a short history of it (some of this may also be told in the book How the Web Was Won, but I haven't read it):
The original plan for NT was that a few members of the core NT team (which numbered about 15 developers) would write all the networking code. However, in 1990 a small team was started up in the LAN Manager group at Microsoft to do some of that NT networking work. Eventually that team moved over to be a part of NT (this coincided with the IBM-OS/2 "divorce", if anyone is interested).
Microsoft's networking software at the time ran over a network protocol called Netbeui, but it was decided that TCP/IP was gaining in importance, and should be included in NT. In addition, the user-mode API associated with Netbeui, which was called Netbios, was too Netbeui-specific and couldn't be adapted to allow user-mode access to TCP/IP. As a result, the decision was made:
1) To put a TCP/IP stack in NT
2) To adapt the sockets user-mode API for NT
#1 was solved by licensing code from a company called Spider Systems. However, Spider's TCP/IP stack was written to run within an environment called STREAMS, which was a wrapper that specified how the various parts of the stack would communicate with each other (TCP/IP is really several pieces of code -- two of which are TCP and IP -- layered on top of each other. Most network protocols are like that, which is why they are referred to as "stacks"). As a result, STREAMS also had to be ported to NT.
#2 involved the creation of the winsock API, which persists today.
It was recognized that using Spider's stack was a temporary measure, because nobody really wanted a stack that depended on STREAMS and its associated overhead. So, a short time after this, work was begun on a new version of TCP/IP, written entirely by Microsoft.
Along with Spider's stack came versions of various TCP/IP-related utility programs, such as ftp, rcp and rsh. Those were ported from BSD sockets to winsock (not a huge change) and bundled with NT.
Now, some of Spider's code (possibly all of it) was based on the TCP/IP stack in the BSD flavors of Unix. These are open source, but distributed under the BSD license, not the GPL that Linux is released under. Whereas the GPL states that any software derived from GPL'ed software must also be released under the GPL, the BSD license basically says, "here's the source, you can do whatever you want, just give credit to the original author."
Eventually the new, from scratch TCP/IP stack was done and shipped with NT 3.5 (the second version, despite the number) in late 1994. The same stack was also included with Windows 95.
However, it looks like some of those Unix utilities were never rewritten. If you look at the executables, you can still see the copyright notice from the regents of the University of California (BSD is short for Berkeley Software Distrubution, Berkeley being a branch of the University of California, for some reason referred to as "Berkeley" on the East Coast and "California" on the West Coast...and "Berkeley" is one of those words that starts to look real funny if you stare at it too long - but I digress).
Keep in mind there is no reason to rewrite that code. If your ftp client works fine (no comments from the peanut gallery!) then why change it? Microsoft has other fish to fry. And the software was licensed perfectly legally, since the inclusion of the copyright notice satisfied the BSD license.
I won't even swear on a stack of bibles that the "new" TCP/IP now shipping in NT/2000/XP and Windows 95/98/Me is completely free of the old code from Spider. Since I don't work there I don't have access to the source code. Certainly some parts of TCP (the checksum calculation comes to mind) are the same everywhere and once someone has written an optimized version, why rewrite it? And once again, this would be perfectly legitimate for Microsoft to do under the license.
But it is certainly misleading of the Wall Street Journal to say that BSD code is used "deep inside" the NT networking code, unless they mean the STREAMS wrapper itself, which I believe is still there in case someone wants to write a transport using it (I think there is an OSI TP4 STREAMS transport lurking somewhere out there, if anyone cares - but I just checked, nobody does). But the TCP/IP in NT certainly doesn't use STREAMS.
And implying that the TCP/IP stack uses BSD code is also false. As I said above there may be small vestiges of it in there, although I doubt it. Anyway the FreeBSD programmers who reported all this to the Wall Street Journal can't see the NT TCP/IP source either, so they can't have been referring to that.