Date: Tue, 15 Feb 2005 00:47:27 +0100 From: Anthony Atkielski <atkielski.anthony@wanadoo.fr> To: freebsd-advocacy@freebsd.org Subject: Re: SPAM: Score 3.3: Re: Instead of freebsd.com, why not... Message-ID: <515551513.20050215004727@wanadoo.fr> In-Reply-To: <d9175cad050214084136d3b12c@mail.gmail.com> References: <9C4E897FB284BF4DBC9C0DC42FB34617641AE6@mvaexch01.acuson.com> <d9175cad05021205463a6c12fb@mail.gmail.com> <d9175cad050214084136d3b12c@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Kjeldergaard writes: > 1) Cost (in $$$): FreeBSD is free. Most of its third-party software, > also free. This is a big advantage to the many businesses that have > difficulty affording hundreds and often thousands of dollars per > machine in software. This I will grant unconditionally. Windows costs a fortune, and for companies of any size, it can cost as much or more to put Windows on the machine than it does for the hardware itself. There are a lot of companies pirating Windows, though. In some countries (the U.S. for example) this is only a minority of customers, in other countries it is essentially everyone. Often this takes the form of fudging on the number of licenses purchased vs. the number of seats actually installed. If a company can use pirated copies of Windows with impunity, the cost advantage of a truly free OS disappears. > 2) Security: FreeBSD has rather a notable track record for security. > I know of no examples in which an email client or web browser has been > able to execute arbitrary code, sometimes even outside of its > permissions level. Windows (possibly due in part to exposure) has a > deplorable track record. Patches come out often to fix known security > holes, but sometimes weeks or months after the hole has been found and > reported publicly. This is mostly due to exposure, as you note. There's nothing inherently more or less secure about Windows (at least in recent versions based on NT). Much of the exposure is the result of changes made by Microsoft to please the desktop market. If FreeBSD or other operating systems were to replace Windows, they'd develop the same exposure, because desktop users want features more than security (also true for corporate users in many cases, sadly). > 3) Stability: FreeBSD is possibly the most stable OS currently in > existence. For some people's desktops that does not matter. However, > there are mission-critical desktops in existence and sometimes > crashing is not allowed. Such as? ATMs come to mind, but not much else. A mission-critical desktop also implies a mission-critical human being behind it, which is quite rare (maybe a mission controller for a spacecraft, or something). > 4) Flexibility (especially mutliuser): This one is probably the most > important. When dealing with desktops, the ability to make it act > appropriately for the intended users is integral to its success or > failure as a desktop OS. Unfortunately, this favors Windows, not other operating systems. Corporate IT groups can force specific Windows environments on a network of thousands of machines much more easily than they can with any other operating system. They can force things to run on every machine when it is booted. They can prevent users from logging in as local administrators, and they can prevent the machine from giving users a chance to gain administrative access before or during the boot process. None of this is possible with FreeBSD or with any other OS, as far as I know. These features were market-driven. Many large customers _require_ these features today. The features you describe are merely cosmetic. What large organizations want is the ability to control what's on the desktop to a far greater degree. Windows actually allows this, or at least it does better at it than any other general-purpose desktop OS. > 5) Ease of development: A place where non-windows becomes > substantially more prevalent in the desktop market is the desks of > Software Engineers. It depends on which environments they are programming for. Typically software engineers run the OS that will run the software they write. In any case, they are such a tiny minority of the desktop population that they can be ignored. > Those of us that program for a living often choose Unix (or Unix-like) > because it has a powerful terminal, good (and free/OSS) versioning > software available, good (and in gcc's case free and OSS) compilers, > excellent editors (free, OSS), excellent documentation systems (man is > free and OSS, for instance), and wonderful debuggers (gdb...free, > OSS). It also is capable of running the same software that we are > running on our Unix servers so that we can work on applications that > work with them in an environment that simulates the server. It is also > remarkably stable during development. This makes debugging > substantially simpler. Unfortunately, this assumes that the engineer is writing software for UNIX. If he is writing for Windows (as most engineers are), he must run Windows. > Windows, however, is often not the environment on the server ... Most engineers are writing for the desktop. > 6) mutliusericity: (Yes, I know that's not a real word...) In > general, Windows does not handle multiple simultaneous users. This is > something that Unix was built around and thus is strong with. Very true. The NT code base does support multiple users, but the notion of a GUI is so entrenched in Windows that this support is practically invisible. UNIX, of course, was built as a timesharing system, and it handles multiple users effortlessly. Indeed, the average PC today could service thousands of simultaneous users under FreeBSD, if they used UNIX in the classic way (from a terminal or terminal emulator). It's a pity that this aspect of UNIX is so rarely used, although I've seen a few examples. A good example of UNIX used in a classic way is the Internet Chess Club (http://www.chessclub.com), which runs FreeBSD and supports thousands of simultaneous users via terminal interfaces (the client programs used by members of the club to play online chess are essentially dressed-up telnet clients). It would be extremely difficult to even get this to run under Windows, much less obtain any kind of performance. > The need to do this on a desktop is somewhat rare ... More than somewhat, particularly in small businesses and at home. Desktops by nature are single-user systems. Only one person uses the system at a time. Multiuser support isn't needed. UNIX handles this well, but the desktop scarcely uses it. Windows handles it poorly, but desktop users seldom need it. Serially multiple users aren't the same thing, and current versions of Windows handle that pretty well, anyway (although not nearly with the security of UNIX). True multiuser operation does exist on the desktop, but it's limited and invisible. For example, on corporate desktops, some services on a local machine may run under administrator accounts, whereas the current desktop user will be logged in under a normal user account. This prevents the local user from changing things on his own machine, which is exactly what corporate IT groups prefer. Of course, this can be done even more effectively with UNIX, but unfortunately it's not enough of a factor to influence desktop market penetration. > Windows has a major fault with multiple users and appropriate storage > of settings. Agreed. You can sign on as different users in Windows XP, but there's tremendous overlap between users; it's convenient but not very secure. This isn't the fault of the OS per se, but of the way applications (and some system programs) are written for the OS, without multiuser awareness. > Many applications (including M$ apps proper) do not > separately store settings in a user-by-user basis and instead toss > them into the centralised registry as a system setting. Yes. It's possible to use ACLs in the registry, but nobody does it (and it's a bit dangerous because it's easy to get very confused). > This is both a security nightmare and a frustration to the various > users. This situation simply doesn't come up in fBSD. If a user stores > a setting, it is stored (generally) in their home directory safe from > affecting other users. Yes. Of course, the user can simply choose to run as root when he boots the system, and then he can blast everything that corporate IT has set up. That can be prevented with Windows to a large extent. -- Anthony
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?515551513.20050215004727>