Re: and yet another zdnet "article" re: Lnx

[Dirk H Bartley <bartleyd2@xxxxxxxxxxxxx>]

Adam Williams wrote:
> 
> >>>I could be wrong on this but I really get the impression
> >>>he hasn't used Linux any / much at all. The wording in
> >>>the article suggest it.
> >>Which is the problem with 98% of Linux articles at the major IT
> >>publications these days.  Most of them are complaining that Linux
> >>"should have this" and "should have that" when it, in fact, DOES!
> >As requested I will attempt to move this to os-discuss.  I want to say this
> >without slamming the talented MS admins out there.  So here is my attempt.
> >Most articles I see that say Linux needs to do this but it does not often times
> >is about a subject that it does do.  The writers of the article describe that
> >Linux is more difficult to administer than with the M$ gui interfaces.  (i.e.
> >therefore it is not possible is the conclusion)  I think these writers want
> >Linux to be just as simple to administer as the MS counterpart.  Take the MSSQL
> >admin interface as an example, I was impressed when I first used MS SQL admin
> >interface.  Now I'm glad I am not a slave to it.
> 
> This is indicative of poor investigation on part of the reviewers.  When
> was the last time you say a schtick about a GUI DB admin tool talk about
> how they deliberately trashed a table/index and used the GUI took
> quick-and-easy point-and-click there way back to validity?  Product
> reviews have gotten to a point where they are barely worth reading.
> 
> >Now to the good part.  With any software program: as the number and complexity
> >of features increases, so does the difficulty to administer/use.  Hey, it takes
> 
> Not neccesarily true.  98.44% of people can get the sendmail
> functionality they want by spending 15 seconds in Linuxconf.  Are you
> saying sendmail is simple? :)

Sendmail is most definitely not simple.  It has features I will most likely
never use in my lifetime.  Do I need to know every little detail about how to
configure.  NO.  Is it immoral to use Linuxconf to get the functionality I
need.  NO.  But, what if I need the results of linuxconf where I can not use it.

> 
> >longer to learn more features.  In general linux server side programs have a
> >great deal of features.  This is usually because many people have added more
> >features to the software that someone else started, then it snowballs.  Many
> >times people spend hours looking for that one thing they don't understand that
> >makes some package behave in an undesired way.  My first one was the encryption
> >line in smb.conf.
> 
> True,  but only of people using advanced features.  I hold the opinion
> that regardless of product most such people will meet with equal grief.
> Intelligent (or better yet, adaptive) defaults are the best solution to
> this problem.
> 
> >To me the choice is clear.  Be forced to learn more about the software you use
> >or administer, feel good when it works and let it work for a long time, have a
> >greater number of choices with how to change it if more is needed.  OR: Get
> >something functioning quickly with little understanding of it, reboot, live
> >without much flexibility, reboot again.  When asked why the service goes down
> >shrug your shoulders and look stupid.  Reboot.  Tell everyone it works.  Wait,
> >try to figure out what happened. ... ...
> 
> Your missing one other point: life-span.  How long does M$ hold to any
> one technology.  Visual Basic anyone?  Version 4, 5, or 6? Oh, don't use
> that, use: C#, .NET, and Commerce server.  I certainly don't want to
> spend a significant portion of my time re-tooling all my projects.
> 
> >Which brings me to the projects making an effort to gui-fy Linux.  I'm all for
> >it.  However, they really ought to tell you what text/configuration files it is
> 
> How about looking in /proc?  Or running strace, fuser, or lsof?
> 
> >editing when they do it.  A big difference to me between Linux and MS is that
> >windows is a mystery, Linux is an open book.  I'd like the new people trying to
> >use Linux see the book through gui.  Lets say I'm in Linuxconf and I just
> >changed something in sendmail.  I would really like it if it told me what file
> >it changed what the original file was renamed to and give me the option to see a
> >result of a diff command between the two.  They also could have more
> >explanations.  Assume you don't understand something, url to an explanation on
> >the web somewhere.  I know what your thinking, Join the linuxconf team then.  OK
> >I'm a hypocrite.
> 
> But Linuxconf does exactly this:  Just pick View Changes.
> 
> > Everything is clear if known.

Once again I will say everything is clear if known.  

So I'll try it again.  What I wanted to do was administer a machine via a slow
dialup connection.  I wanted to change the ip addresses that sendmail would
accept mail from on the remote machine.  It is "easy" (interpret known) to do
this using linuxconf.  Linuxconf was not installed on the remote machine or I
couldn't run an X client through the slow connection.  (of course now I know
that you can run linuxconf --text) I could however run linuxconf on a local
machine and try to see what config files it was changing.

Before the only way I figured out what file was changed was by running a
tripwire filesystem check.  But I'll try it your way now just to see.  Looking
for "View Changes" in linuxconf was to no avail.  Maybe I am running a different
version, but I could find no option.  I tried both the text and the X linuxconf
program looking for "view changes" and failed.  

Now the strace option.  I ran linuxconf (gui) like so
strace linuxconf > file 2>&1
then I assumed the file that would be edited would be a sub somewhere of etc and
that a system call of write would be performed.

cat file | grep write | less

then search (using / search command in less) the file for etc and low and behold
I could have found the answer this way.  /etc/mail/ip_allow was indeed edited.

Looking at a M$ administrator coming into this environment I can understand
their frustration from a personal experience as well as a philosophical stand
point.  Lets look at what needed to be easy (interpret known).

1 What strace is.

2 How to use the bash shell to redirect the output both standard and error to a
file.

3 That the file edited would be a sub of etc (an assumption, SWAG if you will)

4 cat and less and grep (do I count this as three things)

5 how to search for the string "etc" in vi or less

That's alot from point and click to this I'd say.  I'm not complaining.  I can
appreciate the elegance of this kind of method.  The use of multiple tools to
chisel away at a problem has a very strong appeal.  It's still a mile away from
point and click.  At least the problem was solveable without rebooting or
reinstalling.

So there is more than one way to skin a cat if I had not been brain cramping at
the moment.  I could have made the change to some searchable ip address like
193.123.75. and then executed
grep -r '193\.123\.75\.' /etc 
but brain cramps do occur.  Running tripwire just sort of happend because It
runs every night on that machine and I gave up on that after a half an hour or
so.  Then I got the mail from tripwire and it just sort of clicked.

OK so what is the point here.  Umm.  Oh yes I remember, an administrator going
from windows to linux.  Are the gui's a help or a hinderance.  I still want to
see linuxconf tell me what was changed.  Right now it just tells me what
services it will restart.  I don't see why every time I changed the ip_allow it
tells me I need to restart lpd and xfs.

Dirk