why not OS X?

[Konstantin Riabitsev]

--=-BSPzKw/A4S7XacXTjsom
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2002-06-04 at 16:49, Nick (Spunky Cadaver) wrote:
> >Right
> >now someone has to be present there to click buttons to actually update
> >the box. Multiply it times 250, and you will understand why we don't
> >support it in the department.
>=20
> well TECHNICALY you could do it with Timbuktu...but that would=20
> involve spending more money, so bad idea, I think VNC is coming along=20
> well with OS X though...Also how do pure Darwin users update?

No-no-no, remote tools don't cut it either. What I need is a system
where I can "push" an update onto the update server and all my
workstations will "suck" it down nightly and automatically install it.
This is what we are doing with yup (yes, we actually use yup with Red
Hat, although it's currently getting a major face-lift).

> Im pretty sure you could have just downloaded SSH yourself and=20
> compiled it....to fix the hole...may be wrong though.

Yes, yes I could have. However, that would require me to invent a way to
package it so it blends into the existing distribution, then upload it
to all workstations and install it, hoping that when Apple _does_
release a fixed version, it will not conflict with my installation.

Moreover -- ok, OpenSSH is an open-source product. What about holes in
Netinfo or somesuch? Some closed-source proprietary Apple tool that has
a hole in it -- what am I supposed to do about upgrading it in case a
hole is discovered? I have no choice but to wait when Apple gracefully
releases the update, which takes weeks or months. Back to the reason why
we are not using Microsoft, in fact.

> >Anyway. OS X would be something I'd buy my mom to use at home, but
> >that's its niche right now. Maybe things will improve... but where it
> >stands right now, we will be happily running x86 Linux in our department
> >and get by with 2 sysadmins per 250 boxes for years to come.

Oh, yeah, something else I've forgotten -- a kickstart-like system.
Currently we have several installation classes -- several workstation
classes, a beowulf node, and one kickstart config per each server we are
using. In case one of our workstations goes down, say a hdd is dead, all
we have to do is grab a replacement hard drive, put it into the
workstation, reboot it, and select "linux install" in the PXE menu.
Total admin time spent on the problem -- about 10 minutes. 15 minutes
later (3 minutes if the installation is done for a beowulf node over
GigE), the system is back up and running -- no supervision required. It
will even restore the configuration during %post.

Now, imagine an OS X workstation dying. Oh, the horror. I would have to
go there, install Mac OS X 10.1, configure it, run software updater,
install the packages... total admin time about 3-4 hours. Notice the
difference? As far as I know there are currently no imaging tools to
create a "ghost"-like image and burn it directly onto the Mac OS X box
directly from a CD. In fact, I'm not certain that's possible since from
what I know, OS X sets the system ID during the installation time to
prevent piracy (correct me if I'm wrong, someone). Even if it is
possible and such tools exist, we would have to have about 10 different
CD's for each of our installation classes, plus we would still have to
run the software updater after the installation is complete.

No, deploying OS X in a department/company is completely brainless. You
will end up paying about twice, or even three times as much for about
the same amount of compute power, you will require 2-3 times as many
administrators, not to mention all the software you will have to buy to
be even remotely productive.

No, I don't see OS X anywhere besides a home.

--=20
 0>  Konstantin ("Icon") Riabitsev
/ )  Duke University Physics Sysadmin
 ~   www.phy.duke.edu/~icon/pubkey.asc

--=-BSPzKw/A4S7XacXTjsom
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEABECAAYFAjz9MHAACgkQlVxa81EWb4gRWwCfX3N6C+xE9hO0LcRtFnjs8JGQ
l/wAn3/ME9CLsB2NgwS6XtGVNZv3A0rN
=kwQD
-----END PGP SIGNATURE-----

--=-BSPzKw/A4S7XacXTjsom--