Re: Tux Racer 0.10 Released

[Steve Baker <sjbaker1@airmail.net>]

Thomas Lund wrote:

> Steve: please don't take our mails as hostile. We are just honest I
> think.

Sure - I'm not upset - I'm always interested in constructive criticism.

But I don't see what it is that you want me to do that will help these
people who refuse to tell me when something doesn't work.  Shipping
binaries isn't the answer - if their systems are badly set up or if
I make a bad assumption about what constitutes a 'correctly' setup
machine - no amount of RPM's are going to help.

> I myself did not send any reports to you about buggy/hard installation,
> since there are TONS of projects out there. If I had to report things
> that do not work on each and every one of them, I would not have time to
> do anything else.

Well, I'm not happy with that attitude.  The only way OpenSource can
possibly work is if users take a minute to feed back problems to the
authors of the package.  That's the ONLY way things can improve.

If everyone took your attitude, authors would get no bug reports at
all and no software would ever work on anything other than the
exact setup that it was written on.

It's part of the informal contract between me (the author who spent
an entire year's worth of spare time to write this damned thing) and you
(the guy who just spent two minutes to download it).

You might also want to stop and ask yourself how come all those thousands
of other people have it running OK - yet it won't build on your machine.
For VERY new software, that's likely to be simply that it's badly broken,
but for something that's been around on the net for a year or more, you
have to suspect that there is something broken on your machine - and that
says that you should try to see why.  When your car starts shuddering
and shimmying at 62mph, you don't just shrug your shoulders and make
sure you drive at 61 or 63.

> It is like going to the bookshop. Millions of books. You judge the book
> by a cover + an teaser text. I have surely put lots of good books back
> on the shelf because of that.
> 
> With the games you then also have to figure out how to "get the book
> unlocked, so that you can start reading". If this is really hard, the
> book goes back to the shelf. If I get in and see some nice pictures, a
> good story, I will buy it and read it.

I don't like your analogy.

The cover+teaser text is the web site...you look at the web site - and
maybe the happypenguin review.  Tux_AQFH should look good to you since
HappyPenguin rates it with a full 5 stars and there are lots of glowing
reviews "on the back cover" from people who compiled it and got it to
work.

Downloading the code is like actually buying the book...but at this point
there is nothing analogous to the compilation step.  You read some of the
book - and if you don't like it, you are screwed - you already paid for it.
It's a complete waste of time trying to write to the author to tell him his
book is crap - and nobody does it.  Hence, bad authors with flashy book
covers sell lots of books...this certainly happens.

OpenSource software is better than that - you get to read a bit of the
book - and if you don't like it, you can easily contact the author who
will happily change it so you WILL like it.  The next person who buys
the book likes it a bit better.  Over time, all books get good.

But if you don't tell the author that his book is crap - you just get
more crap books.

> The typical way I check out a new game/application/whatever is:
> 
> * read about it on linuxgames (or one of the other ones)
> 
> * go to the webpage (if webpage is "pro" or has nice screenshots, then I
> will try it. If the webpage is shitty, I will only try the software if
> it sound REALLY good)

Hmmm - that assumes that someone's ability to write good code is in
some way related to how well he designs web pages...of course the
quality of a book author doesn't particularly relate to the quality
of the cover artist he employs either.
 
> * if I can install easy (using RPM) I will try it, run it and remove if
> I don't like it
> 
> * if I have to compile I give it a one shot. I will rather use a
> packaged binary to not clutter up my system with obscure libs that I
> have a hard way to remove again

Most games (Tux_AQFH included) can be run without installing them.
That's what I do.  If the game plays well, I'll do a make install,
otherwise it's an rm -r * and I'm all cleaned up.
 
> * If either does not work more or less first time, I move on to
> something else - without sending a bug report

Well, that's the bit that I object to.  It shouldn't take more than
a minute to dash off a mail to the author - and that's a small thing
compared to all the time it took you to download and install it...and
who knows, maybe the author fixes your problem in a minute and you get
to run that game that you always *thought* would be a good game.
 
> * If I get the program running and it looks OK, then I will keep it and
> send bug reports and the like, because now I am interested in getting it
> running as good as possible on my machine

Too late!  If it runs and doesn't crash and stuff then there is much less
need to send a bug report.
 
> The reason I list this is because I think that is the typical way for a
> lot of people.

It's hard to tell because if people refuse to send in reports of problems,
you never find out that these people exist.  It's probably a Darwinian
thing.  People who don't report problems end up with mis-configured systems
that are so bad that they eventually conclude that most things don't work
under Linux and go back to Windoze.
 
> Would it not be possible to create a binary with static linked plib,
> SDL, whatever lib is needed? Possibly except Mesa, since that is usually
> system dependant.

Well, Mesa is the cause of all the problems in 99% of the cases I see
with Tux_AQFH.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)



---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk