Re: Linux vs FreeBSD vs SCO

• Previous message: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
• Next in thread: Tony Lawrence: "Re: Linux vs FreeBSD vs SCO"
• Reply: Tony Lawrence: "Re: Linux vs FreeBSD vs SCO"
• Reply: Joe Dunning: "Re: Linux vs FreeBSD vs SCO"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 26 May 2005 19:21:06 -0400
To: Jeff Hyman <scolist@cactus.com>

At Thu, May 26, 2005 at 13:25 , our malformed and occasionally
flatulent friend Jeff Hyman spewed forth this fount of brain juice:

> -------------- clipped -------------
> | If you want to go back to your "Golden Unix Years" [ or more likely
> | the Xenix years ] I'd suggest the FreeBSD 4.11. It will run on
> | current hardware. You didn't say what hardware you are going to be
> | running on but some of the older SW doesn't like the new hardware.
> |
> | I'm getting older and older - and there seems to be no way to
> | preventing that is acceptable - and I took over the tech side of
> | two different ISPs when I was older than you are now.
> |
> | My first BSD experience was a 2.6, and it was like going back to
> | Xenix 1.x on my old Radio Shack 16 - where I got hooked on Unix in
> | 1983. All of a sudden I was 'home again' and you're not supposed
> | to be able to do that [see a comment in a reply to a post by Tony].
> |
> | And speaking from the vantage point of a few year older than you,
> | one thing that keeps me from getting older [mentally] is learning
> | new things. And JPR and Bob Stockler - both on this list - are
> | older than I. And even my son says "you are interesting to be
> | around". What greater compliment could I get?
> |
> | --
> | Bill Vermillion - bv @ wjv . com

> Bill,

> I changed the Subject header to avoid thread drift.

> If you had a choice between FreeBSD or Linux or SCO, which would pick?
> and why? I'm also curious how FreeBSD stands in the current *nix wars
> compared to the rest. I do value your input as well as anyone else here
> that has had a taste of SCO|Linux|FreeBSD. I'm just curious.

My last two SCO accounts de-commissioned their machine earlier this
year. One move to a custom application with a web interface using
MySql on Linux from Novel. That custom ap cost more than most
of the databases out there, but the client worked a deal with the
developer, and gets commissions on all further sales. Highly
specialized and nothing available did exactly what they needed.

The other moved to an NT platform - as their software vendor for
their pharmacy finally got it converted from SCO to NT. That was
being promised for 3 years. I wound up upgrading that machine to
OSR5 for Y2K as the transition from SCO to NT was originally
targeted for that time frame.

The problems >>I<< have with Linux is it is not consistent.
And it changes. They don't seem to have the concept of legacy
systems, so that if they change something they expect you to
upgrades. When - at one time - the ps -af deprecated the '-'
and would bail out when it encountered that in a script I was told
"change the scripts". The don't understand that some system have
scripts that have worked for years the old way, and sometimes
those scripts are called only rarely so breakage may occur later
and you might not know why.

This happened in the past and I've not done a lot with Linux
recently - except for two sites I keep running. All my servers
are FreeBSD. My mail server is getting upgraded this week as
the volumes of mail it's woefully under-powered. I just checked
in and it's been up and running for 459 days, and that's when I
upgraded the OS on February 21, 2004. Exceptionally stable.
I've also had SCO machines stay up that long but got really strange
in displaying things on one that was up for at least 2 years.

Another think I disliked was their 'better' way of firing off init
scripts. Instead of the text oriented inted.con with one line for
things they instituted the xinetd.conf file and xinetd.d diretory.

Each file in xinetd.c has about 8 lines inside { and } with
all it's options.

disable = no, or disable = yes certainly is more complex
than just commenting out, or adding a line in /etc/inetd.d

In the SGI system V there was an etc file that had one line for
each service with the enable or disable, but it wasn't as overly
wordy - or MSish - as the Linux thing.

Of course this structure made it easy to parse things with their
graphical front end.

But and make this a

 _ _ _ _
| |__ (_) __ _ | |__ _ _| |_
| '_ \| |/ _` | | '_ \| | | | __|
| |_) | | (_| | | |_) | |_| | |_
|_.__/|_|\__, | |_.__/ \__,_|\__|
         |___/

They way it was implanted [maybe it's changed] goes against all
things I ever learned about robustness in servers - and I only putz
around with servers.

One day I got a call from XXX [running your SW so you can see who
they might be] that nothing was working. Mail was down, telnet was
down [and they had a great many users telneting in to use pine for
mail] the web server was down. I inherited that when the other
system admin [really excellent Unix person from the days of
the old Gould Fire-breathers if anyone remembers them] went on to
other things. But they have a lot of email users remotely who had
always used telnet and that was not going to change.

I was able to ping, then I performed a secure shell login and found
the system was running but nothing >>NOTHING<< that was in xinetd
was running.

I restarted xinetd, and things started running and immediately
stopped. It did the same thing. Reading the docs I found out how
to start the logging and started it up that way.

I looked at the logs and 18 services started, and then it found a
configuration error in the ftpd startup. What caused that error I
never found out. BUT - when it found that error, it bailed out and
took everything else with it.

IOW on failure in xinetd stopped everything else. That's more
like an MS machine than a Unix.

I don't use Linux that much but these few things made me dislike
it. [I think you can tell I'm prejudiced. I got a Radio Shack 16
in 1983 and moved by BBS to that in 1984 and made it a Usenet node

Then there is the rpm upgrade path. That also seems so MSish, as
often you install an upgrade, and you find it needs something else,
so you install that. And often you get library errors - just like
MS gets those DLL things.

In FreeBSD I almost always - with about 3 exceptions - build
everything on the machine. I got to /usr/ports/<category><pgm>
and type 'make'. These exceptions in case you are interested
are things such as installing cvsup, which I do from a pre-built
package, from packages otherwise it has to compile Ruby, and some
other programs, that are used only for the compile, and that can
take a long time.

It goes to the net, gets the needed source code, sucks them in,
compiles them, checks for all needed dependencies, compiles them,
and then with make install it checks if there are other
dependencies and brings them in and installs them. Some of the
Linux dists are starting to adopt thins.

With this method you almost never worry about outdated libraries,
because we are compling on a running system. And often you get
new libraries in addition to old ones.

And for things such as shells, and at least through all the 4.x
series of FreeBSD EVERYTHING in /sbin is compiled statically, so
that each program can run all by itself and not depend upon any
libraries at all. And I really dislike 'bash' that is the stock
dist in Linux. And when I got into one of those I have to unlearn
my ksh leanings, or install ksh there. That's personal preference.

The newest BSDs have gone dynamic, but you do have an option to
make those core files static. To me this is the only way as worst
case you can move a file into a broken system if needed.

In short the FreeBSD has evolved from the real BSD which came
from the old Unix systems. And there is no concept of a different
kernel and user-land. When you build a system you build a kernel
and all associated files so there is nothing to get out of sync.

FreeBSD appears to be designed, and so much of Linux appears to
have just happened.

There is also a saying in the BSD group that goes something like
this. "Linux is for MS haters. FreeBSD is for Unix lovers".

That seems to have a degree of truth in it.

I see many converts from Linux in the FreeBSD group. But it's not
as desk-top oriented as Linux. And in many Linux installs you
don't do anything but put in a disk or two, and use up about 2GB
to put everything onto the system. OTHO I've put a running
FreeBSD on a 800MB drive and had 400MB for user stuff.

It's solid and runs and runs and runs. I've never had a server
crash, and when it's upgrade time it's the only time they get
rebooted.

I may have been lucky, but when installing a new OS on a remote
server, it's off line two times for only about 5 minutes maximum,
each time.

I run cvsup out of cron nightly to update the sources [ and for
the servers I only get the release patches for security holes ]
and when it's time to install a new one, I just go into
/usr/src. And I run 'make buildworld' under nohup and logout, and
come back later to examine the output. If that works I do the
same on 'make buildkernel KERNCONF=<nameforthatmachine>, and I
check later to see if it's ok.

The if all goes well about 1AM or so, I just perform
'make installkernel KERNCONF=<nameforthatmachine>, which takes
about 30 seconds.

The I do a remote reboot, fire off ping locally, and typically in
about 60-90 seconds I get pings back, and then ssh in. If I don't
get the pings back the system is locked. That means a 15-20 minute
drive to the site after 1AM [traffic is lighter then - both on the
net and on the road. The machine are inside the local Level 3
facility and I have 24x7 access.].

Then when the new kernel is running, I perform 'make installworld'
and ALL the binaries in the system are updated to the latest
compiled versions. I then run 'mergemaster' which compares
all the old config files with newly compiled ones, and I make the
choice of keep the old, install the new, or merge the files with
the utility that compares both and I select what lines to keep in
the merge.

That never takes more than 20 minutes. Another reboot, and I'm
done with that upgrade for another year. <hopefully>.

I've only had about 2 upgrades that required rebuilding the kernel
and rebooting - as they were library related. Most of the patches
just required changing to the sources of the module, and then
perform make clean, make, make install. It's a dream to maintain.

And when I have to move our busiest site - www.springbreak.com
[which when it got to 300,000 spam messages received per day had
all it's MX pointers removed - built a parallel machine and changed
IPs on the fly without rebooting. Disable the main IP [there were
other IPs there] and since I had logins to both machine
simultaneously I enable that IP on the upgrade machine. Total time
it was inaccessible was less than 15 seconds. MS has finally
figured out how to change IP's without rebooting - but that doesn't
seem to be universal.

At the first ISP for which I was running the tech side - it was all
SGI. We all had SGI Indy workstation, and the servers were
Challengers - small devices - not the big desk side units.

Those were running 400Mhz or maybe 500MHZ MIPS 4000 RISC
processors, and running the commercial Netscape servers and SGI
distributed sendmail. 256 or 512MB of ECC memory.

I moved the web sites to a 150MHz [or maybe 120Mhz] Pentiums
with 128MB memory and FreeBSD 2.8 [maybe 2.7 it was a long time
ago] and Apache, and performance went way up. The FreeBSD was much
leaner than the SGI's IRIX which was basically a System V.4.

I will say this however, the SGI's had the cleanest installs
and upgrades and when there were conflicts you were told and had
the choice to remove the programs that conflicted or not install
the new program. The only thing I miss about the SGIs is their
SCSI utilities which let you do anything to the drive you wanted -
change vendor IDs, change sectoring, magnificent diagnostics and
test suites, with the caveat you had to know what you were doing
because one mistake meant a drive might have to go back to the
factory.

I'm getting ready to bring up a more powerful server, as we have
been testing the Darwin Streaming Server and it works fairly well.
Our colo facility has all the things needed for us to start
multicasting on streaming video, which is something not a lot of
ISPs are willing to do.

We pulled a suite of sites from ?? [I forget who it was - but one
of the biggest] because they couldn't do the extra steps in
customizing things. And it wasn't that difficult. I'm getting
the distinct impression that there is a dearth of technical ability
at some ISPs.

We're doing niche market hosting. But a couple have some very
impressive members. If you don't recognize the general and
principal members at www.aafassociation.org then you have not been
paying attention. :-)

Just put me down as an old Unix guy. Set in my ways, lazy so I
pick systems that are easy to keep running and administer, and still
love to play with technology - 28 years after I got my first
computers.

Bill

-- 
Bill Vermillion - bv @ wjv . com

• Previous message: Tony Lawrence: "Re: SCO 5.0.7 AS FIREWALL"
• Next in thread: Tony Lawrence: "Re: Linux vs FreeBSD vs SCO"
• Reply: Tony Lawrence: "Re: Linux vs FreeBSD vs SCO"
• Reply: Joe Dunning: "Re: Linux vs FreeBSD vs SCO"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]