Re: New releases query

On 04/01/08 20:22, Moe Trin wrote:
> On Mon, 31 Mar 2008, in the Usenet newsgroup alt.os.linux, in article
> <fsrbpm$odl$1@scrotar.nss.udel.edu>, Douglas O'Neal wrote:
> 
>> The differences between the default installs of Redhat ES5 and Debian
4
>> are on the same order as the differences between SunOS 4.x and SGI
Irix
>> V4.x.
> 
> Same order, meaning same gross number of differences - yeah, I can
> sorta buy that.
> 
>> For the CLI user they are almost identical as both were BSD-based.
> 
> Say WHAT???    Why did I have to carry a cheaters book with sections
> for SunOS 4.1.x, another for some ancient version if IRIX (most of
> the SGI boxes were running something later - 6.1.something), not to
> forget OSF/1 (please don't barf on the carpets). Then we also had a
> few Sparcs running Sol 5.5,  and also had to put up with HPUX 10.mumble
> (for some bizarre reason, we had one HP 9000, and an RS/6000 running
> AIX 4.1.3).     So tell me, what are the common options you use to 'ps',
> and 'ping'?    My ~/.profile attempted to figure what P.O.S O/S was
> running, set the PS1 prompt to be the name/version of the O/S, set the
> PATH  to include /usr/ucb/bin if needed to get around some of the worst
> of the abominations, and a number of aliases to try to avoid a lot of
> other pitfalls.       "It's a UNIX system! I know this!" Yeah,
right.

Both SunOS 4.x and Irix 4 were BSD based so to see all of the processes
running on the system you would use 'ps -aux'.  Irix went to a SVR4
based environment in version 5 and the equivalent command then went
to 'ps -fe'.  Irix 6 came out around 1995 and I will agree that there
are significant difference between Irix 6.1 and SunOS 4.1.3.

I don't think the options I generally used for ping changed much across
systems.  -c for count, -f for flood ping, -n for no name resolution.

OSF/1 was awful.  HPUX wasn't much better.  AIX managed to break sed.
Risc/OS wasn't bad.  Ultrix needed updating to bsd4.3 even in 1990 but
was solid once you got used to it.

> 
>> However, the desktop environments were generally different
> 
> I tried to avoid using X on all but my own workstation, and even
> there the main use was to give me a bunch of xterms.
> 
>> and the administration tools were quite different.  
> 
> If you're talking about the GUI crap, I avoided that as much as possible.
> The cheater book told me what files I needed to mess with, and that was
> the end of that problem.

I still avoid GUI admin tools as much as possible.  I'm talking about
/etc/rc.single, /etc/rc.local, etc. vs. /etc/init.d/* startup scripts,
package management, useradd scripts, location of configuration files,
ways to tweak to kernel, and the myriad other features that Sun, DEC,
IBM, AT&T, and others decided they needed to change to make their
version of Unix unique.

> 
>> "Flavor" was the terminology adopted at the time to encompass
the
>> differences between the large number of Unix variants.  The
>> differences in flavors could be dramatic (DEC Ultrix vs. AT&T
SVR4)
> 
> That's the reason for that cheaters book.

Do you still use the book (or a new edition of it) when you move
between linux distributions?

>> or subtle (RiscOS/Motif vs. SGI Irix), just as in sensory taste.
> 
> that could still whip the legs out from underneath you just as
> easily.     We still walked into a buzz saw regularly.

Definitely.

> 

On Wed, 02 Apr 2008, in the Usenet newsgroup alt.os.linux, in article
<fsvugc$6b3$1@scrotar.nss.udel.edu>, Douglas O'Neal wrote:

>Moe Trin wrote:

>> Say WHAT???    Why did I have to carry a cheaters book with sections
>> for SunOS 4.1.x, another for some ancient version if IRIX (most of
>> the SGI boxes were running something later - 6.1.something), not to
>> forget OSF/1 (please don't barf on the carpets). Then we also had a
>> few Sparcs running Sol 5.5,  and also had to put up with HPUX
10.mumble
>> (for some bizarre reason, we had one HP 9000, and an RS/6000 running
>> AIX 4.1.3).     So tell me, what are the common options you use to
'ps',
>> and 'ping'?    My ~/.profile attempted to figure what P.O.S O/S was
>> running, set the PS1 prompt to be the name/version of the O/S, set the
>> PATH  to include /usr/ucb/bin if needed to get around some of the
worst
>> of the abominations, and a number of aliases to try to avoid a lot of
>> other pitfalls.       "It's a UNIX system! I know this!"
Yeah, right.
>
>Both SunOS 4.x and Irix 4 were BSD based so to see all of the processes
>running on the system you would use 'ps -aux'.  Irix went to a SVR4
>based environment in version 5 and the equivalent command then went
>to 'ps -fe'.  Irix 6 came out around 1995 and I will agree that there
>are significant difference between Irix 6.1 and SunOS 4.1.3.

I thought IRIX 6.0 was earlier than that. We got a handful of Challenge's
for a project in mid-1994, and I'm pretty sure they were running 6.0

>> If you're talking about the GUI crap, I avoided that as much as
possible.
>> The cheater book told me what files I needed to mess with, and that
was
>> the end of that problem.
>
>I still avoid GUI admin tools as much as possible.  I'm talking about
>/etc/rc.single, /etc/rc.local, etc. vs. /etc/init.d/* startup scripts,
>package management, useradd scripts, location of configuration files,
>ways to tweak to kernel, and the myriad other features that Sun, DEC,
>IBM, AT&T, and others decided they needed to change to make their
>version of Unix unique.

I'm not sure they did it to make their versions unique - I suspect
that each decided that they needed to do $SOMETHING better, and each
had their own opinion developed more or less independently.  You still
see this in Linux. Heck, all of the distributions know how to make a
better kernel than anyone else (including kernel.org), which is why
kernels aren't portable and haven't been for over ten years.

Package management - that's a two edged sword. I like the idea that
we're able to run a cron job that basically looks at a local update
server, and if anything is in "this" directory, then run the
package manager and things are done. Yes, we've got people working
behind the scenes to make sure the update is going to work before
hand, but anyone running production systems does something similar.
On the other hand, package management can be a fun thing with
multiple dependencies - which is why some of our locally produced
stuff has to be recompiled when a distribution errata comes along
and changes things.

Usually, we had one or two people who were designated as the expert
on $FOO version/release, and they were the one who created the cheater
book section for that version/release. With just a single or a few
boxes of this/that, they'd struggle to figure out how the vendor tool
was supposed to do something, touch a reference file, use the vendor
tool, then use find -newer to see what actually got changed.

I will admit that I liked the concept of the SysV initscripts as this
was a lot easier to throw in new/replacement services, but the BSD
scripts were a bit easier to read/follow.

>> That's the reason for that cheaters book.
>
>Do you still use the book (or a new edition of it) when you move
>between linux distributions?

I'm no longer doing user support, so I have less call to try to figure
out where configuration items got moved to this week. Yes, we still use
a cheater book, and it's only taking a couple of days to create a new
one when we adopt a new release.  Linux is getting a bit more
standardized if you stick with the command line for admin. Of course
each distribution has their own cute tool that is supposed to help you
do things, but if I'm going to move a box to a different subnet, it's
a lot faster to use 'find /etc/ -exec grep' than to worry about which
magic tool I should be trying to use, but even that is less of a problem
because we try to stick with one distribution company wide, and that
means I know the two files I'll have to edit manually..

One problem that has appeared on "popular" distributions is some
helper
nanny that will silently correct your mistakes. Now I can understand
the rational for something to reset permissions from 0777 or such, but
when I set /etc/resolv.conf to be 'this', and some application author
decides I really wanted it to be 'that' and "I'll fix it for you",
that nanny program is history, and if it doesn't come out easily, then
the whole distribution is going to be replaced by something that I
know is going to work.