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

[Anthony Atkielski]

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