SPAM: Score 3.3: Re: Instead of, why not...

Astrodog astrodog at
Mon Feb 14 16:14:56 PST 2005

> 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.
> 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).

%60-some percent of webservers run Apache. More than 2 million of
those run FreeBSD, (Almost as many as all of Linux combined) There's a
bit more to it than exposure.

> 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.

NIS/NIS+/LDAP, can all do this quite well. Combined with NFS... hot
damn, you have the same thing, except minus the whole
overhead/multiuser issue below

> 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.

Barring maybe VxWorks.

> 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 (,
> > 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.

If he is following ANSI C, and keeps his code modular, for the most
part, the OS its actually written on is irrelevent.

> > 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
> (, 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).

Yay for TrustedBSD.

> > 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.

Hrm. Every time I boot my system, it asks for a username, and
password. If I don't know the root password.... I could boot it single
user.... but even then, it STILL asks.

> --
> Anthony
> _______________________________________________
> freebsd-advocacy at mailing list
> To unsubscribe, send any mail to "freebsd-advocacy-unsubscribe at"

More information about the freebsd-advocacy mailing list