Re: tlug: Re: limits of acceptability

[Scott Stone <sstone@example.com>]

On Wed, 9 Dec 1998, Stephen J. Turnbull wrote:

> >>>>> "Chris" == Chris Sekiya <chris@example.com> writes:
> 
>     Chris> Even xf86config is pushing the limits of acceptability.
> 
> Chris is a real programmer.  He edits files by writing them to punch
> cards (barely acceptable) and then chewing on them (it's a shame they
> discontinued the cherry flavor, cards would be much more acceptable).
> 
> C'mon, Chris, it's just as easy for a newbie to fry hardware by
> editing the rc file directly as by trusting in configuration software.
> 
> The problem with configuration software is that most configuration
> software does _not_ limit itself to setting up common (and tested)
> configurations, but goes on to enforce its idea of what's right, and
> try to take possession of the rc:
> 
> # This file was written by SlackHat BFG-9000 Configurator.  Don't touch
> # a byte or your monitor will display the following and implode:
> #
> #			Hasta la vista, ba-by.
> 
> What they _should_ be doing (IMHO, and incidentally that of Debian),
> is to decide what they can handle and then let the user decide when to 
> use the config tools and when to do bloody surgery on the rc file.

putting the 'don't edit this by hand' into the generated config outputs is
done for the same reason that we wear pants - to cover our ass.

We know that people will hack the files themselves.  Heck, we do it
ourselves.  But, we don't want to be responsible when something breaks due
to some guy going in there with vi and messing it up.  Basically the full
context should be, "We're pretty sure this is going to work as-is, and
we'll give you support if it doesn't.  If you **** with it, you're on your
own".

If Linux is moving more towards {point,drool}-and-click, this is kinda
going to be how things go, since nobody wants liability for things beyond
our control.  Same reason that I don't want to do tech support on hardware
issues for people who recompile their own kernel - I have *no* idea what
they've screwed up, whereas I know how the standard TL kernel works.

--------------------------------------------------
Scott M. Stone <sstone@example.com, sstone@example.com>
Head of TurboLinux Development/Systems Administrator
Pacific HiTech, Inc (USA) / Pacific HiTech, KK (Japan)


------------------------------------------------------------------
Next Technical Meeting: 12 December, 12:30 at Temple Univ. Japan
*NEW LOCATION* a map is available at http://www.tuj.ac.jp/maps.html
Next Nomikai: 15 January 1999, 19:30 Tengu TokyoEkiMae 03-3275-3691
------------------------------------------------------------------
more info: http://tlug.linux.or.jp                     Sponsor: PHT