[MUD-Dev] Preference for host OS
Brian Hook
bwh at wksoftware.com
Mon Sep 10 22:26:26 CEST 2001
Thanks for all the replies. I'm going to do a single response to a
bunch of paraphrased comments to keep traffic down:
Re: Windows
Yes, it's not very cost-effective or portable. It's pretty much
dropped to the lowest rung on the ladder.
Re: BSD vs. Linux
This really seems to come down to "BSD is more stable and Linux is
more popular". Given that, I think I'd lean towards BSD since the
philosophy of that community tends to emphasize robustness and
stability. My problem with Linux is that there are so many
distributions that it's difficult to really say "Linux", and
people have very strong opinions on the various distos and their
implementations. For someone that doesn't have years of
experience comparing these, it's tough to really get good data
that isn't tainted with some kind of religious subjectivity.
Hence my original question -- I figure with enough data I can
start to get some gestalt understanding of the issue.
Re: Solaris/x86
From all my friends, the generalization is: "It sucks, but that
was a long time ago, and it may not suck now". Followed by
several people saying that it definitely doesn't suck now.
However I don't know anyone that used it back in the "Bad days"
(ca. 1995) and still uses it today and can thus comment on the
differences/improvements.
Re: Write portably
I'm definitely aware of this. My code right now is happily
portable between 32 and 64-bit architectures; Windows and Unix/OS
X; little vs. big-endian; Win32 threading vs. pthreads; and my 3D
client code runs on OpenGL and DirectX (and should port to MacOS
and OS X very easily). The issue isn't one of development, but
deployment.
In general, my development platform and deployment platform should
be fairly uncoupled. Sure, there might be some system specific
stuff that could bog, but I'm confident that by sticking with the
standard subset of features (BSD sockets + pthreads) that I should
be fairly safe. And the server itself is not going to be a GUI
app (administration will likely be through an SSH connection
possibly with output piped on the administrator's side to a GUI
app running on OS X).
Re: Use what your admins/programmers are comfortable with
In general, this is sound advice, but any admins hired are going
to have to be flexible. The business case is going to have to win
out over the personal preference of individual administrators,
since it's doubtful they'll even have a consensus. I don't like
hiring people with religious preferences on anything (coders,
artists, designers or admins). There's nothing more aggravating
than having one guy using Emacs, another using vi, and another
using MSDEV Studio and no one can settle on tab size or "tabs
vs. spaces". And, of course, the one guy that hates Language X
and refuses to use it and thus writes his own "conversion" API
between his personal coding sandbox and the rest of the code base.
I also don't want to use a non-ideal solution simply because it's
the comfortable T-shirt that no one wants to throw away, and
that's the trap you can fall into when you use the "let's use what
we've used before" approach. Obsolescence through complacency.
I'm far more comfortable dealing with Win2K as a server, but I'm
not going to let that force me into using it (as close to a slam
dunk "loser" as you'll get in server arguments). Not to mention
the hideous cost, which weighs on you as a startup.
Re: OS X
For those that don't know, OS X is basically the open source
Darwin kernel with a nice GUI on top. I like Aqua and OS X quite
a bit, and it does ship with development tools (at least the
retail box does). These include ProjectBuilder, InterfaceBuilder,
gcc, gdb, etc. VERY nice development tools, if not the best in
the world (if you include AppKit, CoreFoundation, and Cocoa). OS
X lets you open a tcsh terminal if you'd like, and has the
standard BSD tools you'd expect on any good Unix. It's my primary
"Unixish" development platform. Ideally I can develop on it and
then just recompile and go on my cheap x86 Unix clone of choice
when it's time to deploy.
Thanks,
Brian
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev
More information about the mud-dev-archive
mailing list