+This phrase always makes people think of software that is given away at no cost, has no owner, and thus no support or warranty of continuation. In reality the 'free' in free software means that the source code has been liberated and anybody may copy and compile it, but that does not exclude payment. As the Free Software Foundation (FSF, originators of the [ GNU] license) puts it: think free speech not free beer. Most people using [ Linux] for real applications are using commercial distributions which they have paid for and they expect (and get) the same level of quality and support as any other commercial product. As so much confusion has been caused by use of the term free, many developers now prefer to use the term 'Open Source'. 

+Linux is not cut down. It is fully fledged and continues to evolve with the latest developments in the software industry. Nor is it just for the PC. Stable, commercially used versions exist for [ x86] , [SPARC] , [ DEC] [ Alpha] , Power [ Macintosh] and Strong [ ARM] platforms. Beta versions exist, or are in various stages of development for [680x0] (old MAC, Amiga, Atari), PowerPC ([ IBM] /Motorola type platforms), MIPS, [ HP] , [ SGI] , APX100, The PalmPilot, Merced, and probably more! 

+They DID fragment, around 15 to 20 years ago, and for the last 10 years they have been converging. Using one unix-a-like system is very much like using another. There are fewer differences between the various unices than there are differences between e.g. windows 3.1 -> Windows95 -> Windows NT, moreover Unix systems broadly adhere to [ ANSI] and [ POSIX] standards that allow software to be source compatible across hardware platforms ranging from embedded micro controllers to super computers. The Open Software Foundation (OSF), of which all major OS vendors are members, takes standards further with their X/Open standard. This allows complete source code compatibility AND a common desktop environment across all platforms. The X/open standard was mostly formed by a conglomeration of existing standards and is now well established and functional (see below for Linux X/open issues). X/Open does not exclude the use of alternative standards on any particular system, but it does allow software developers to write a single  

+source code which will compile and run on all compliant platforms, while at the same time offering the use of a standard window manager so end users get the same interface regardless of which system they are using. True binary compatibility can only be offered on compatible hardware platforms, and even here progress is being made. On the [ x86] platform for example, Linux will run [ SCO] binaries, whilst [ FreeBSD] runs Linux binaries, and there is an umbrella group comprising most PC unix implementors which is aiming to achieve complete binary compatibility across their platforms. Other Linux portings are working on binary issues, for example the SUN Linux port will run most SunOS binaries and the [ DEC] [Alpha] Linux port supports Digital Unix binaries. 

+Difficult to answer this one as there is no credible evidence that this is happening. For the record we may point out that although the commercial Linux distributors differentiate their products, they are compatible and the various companies work together in friendly manner that is uncommon of the software world. They adhere to a common Filesystem Hierarchy Standard (that which determines the layout of the system), and they use kernels and libraries from the same series. The misconception that a standalone package has to be distributed in a different version for each Linux distribution is pure [ FUD] . 

+The short answer is that Linux does conform, but is not allowed to say so! Let us clarify that. X/Open essentially requires a [ POSIX] system with the OSF Motif GUI libraries and the CDE (Common Desktop Environment) window manager (see above, 'Unix is fragmenting' for more info on X/Open). The Motif libraries and the CDE are not open source and so cannot be included with a free distribution, but they are available. Several commercial Linux vendors and third party companies sell Motif/CDE packs for Linux with an OSF license (which is small, around $100-$200), which renders Linux compatible with X/Open (these 'packs' are not 'ports' but runtimes, compiled from original OSF source code). But there is no certification (yet). This does not bother most people as it is simple to verify that Linux with a Motif/CDE pack does compile unabridged OSF test suites, and that it does have an identical look and feel. Many developers who are targeting X/Open platforms use Linux as their development platform. The problem is  

+beurocractic, as the OSF structure and certification program was not designed to take account of open source systems. This is not to say OSF is hostile to Linux, they have ported Linux to their own microkernel (and this is used for running Linux on Power Mac and HP platforms). A recent uniforum conference demonstrated a unanimous desire on the part of X/Open members to find a way of getting X/Open (and hence UNIX) branding to the Linux OS, and it was resolved that a way through the red tape should be found. It is perhaps important to make another point clear, as we may have given the impression that Linux cannot run software developed for X/Open unless a motif license is purchased. In reality, motif software may be distributed in staticly linked form without any license requirements, and many common linux apps (such as Netscape and Acrobat) are freely distributed for Linux in this manner. Vendors of large motif packages generally assume that someone paying several thousand dollars for their package will not baulk at the thought of a $100 OSF license fee. 

+Since originally writing this, the [Samba] team (who make [ SMB] compatible network code freely available to [ UNIX] systems), have been unravelling the spaghetti of an NT primary domain controller, and are starting to offer support for this in their software. Many net administrators are overjoyed by this unlocking of the NT domain, but many others are indifferent as they have no desire to implement such methods irrespective of who is supplying them, as the protocol is still proprietary and bloated. Many administrators point to open solutions, particularly Kerberos, and note that NT5 uses Kerberos for domain authentication. It seems increasingly likely that the use of proprietary protocols in domain controllers is destined to die out. 

+This is a [ FUD] manglers dream phrase, as there is no direct means of refuting it (as system administrators are reluctant to admit break-ins, hard statistics of one OS Vs another are unavailable). Linux is, strictly speaking, a kernel, and an [ OS] kernel is inherently secure as it has no means on its own of communicating with the outside world. Break-ins occur via support programs which offer specific network services, and it is in these programs that weaknesses normally occur. That may sound like a pedantic comment but it is important as virtually all the network support code (ftp, web servers, email etc.) used in Linux is not Linux specific but generally available UNIX software, and in this sense Linux security may be considered no different to UNIX security in general. There is a caveat to this, Linux is available in many distributions including types that are aimed at home users and hackers which put ease of use and flexibility before vulnerability. As such they may be without shadow passwords, and may 

+The basic unit of time in Linux (and most Unix-like systems) is time_t. This format expresses the time as the number of seconds since midnight, 1 Jan, 1970. It has no concept of what is year 2000, it will pass as just another tick. time_t forms the basis of timekeeping within the kernel, date/time stamps on files, up-times, down-times etc., so as far as the kernel is concerned, no problem. Of course there is nothing that excludes an application from mis-interpreting the data, but that is true of any OS. Having said that, the libraries, both dynamic and static, that come as standard with linux (and thus used to compile virtually all Linux apps), are also Y2KOK, as are the alternative libraries people use for e.g. [ SMP] . Given that Linux has evolved recently, when developers have been Y2K aware, it is unlikely that even minor 'contributed' apps are not Y2K OK . Linux and Y2K is no different from any other major OS in this period in terms of compliance, nobody can warranty that no app is available for their system  

+that is not Y2KOK, but of course if you have managed to base your mission critical system on an obscure non-compliant utility, if you have the source you can at least warranty that you can fix it! Worth noting that in general Y2K problems are more relevant to electronic appliances than computers per-se. Many 'real-time-clocks' used in embedded devices have the year as 2 digits and the firmware uses this value directly, without taking account of possible rollovers. Unix uses time_t because it is part of a set of standard time calls in the [ C] language ([ C] and [Unix] were born and bred together), but use of C goes far wider than unix. C is used to write most of all major OS's, and is the predominant language in commercial software applications for all platforms. It is the most likely language to be used for runtime libraries of interpreted languages, it gets everywhere. Of course there is no obligation for programmers to use the standard time_t based functions, but generally speaking they do. So the real  

+'date-with-destiny' of the software world is not Y2K, but when time_t rolls over. As, by convention, time_t is a signed 32-bit value, this will happen in the year 2038. Of course, if programmers have stuck to the rules, then it will only require a system level re-definition of time_t and a re-compile to put things right. And of course with computers working towards 64 bit goals, it is quite likely that time_t gets defined as 64 bit on new systems anyway (as has already happened on the [ DEC] [ Alpha] version of Linux). A 64-bit time_t will roll-over sometime around the end of the universe.