[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggesstion

On Tue, 10 Nov 1998, Xavier Plasencia wrote:

>You make a lot of real good points.  But I think you missed what I was aming
>for, or you just didn't care :)

No, I care, but don't really see the point.

>Your philosophy about ugly and reliable is  really server mentality.  Game
>(consumer market) is more about flash.  If you do not agree look at all the
>games and top products.  

If I install a game (several years since I did that last time...) I really
don't want to have stupid flashing animations and fancy stuff flying
around, I want the installprocess to be quickly done so that I can start
playing the game. But, if moderna games are only about nice animations anf
gfx then that's the way to go. I was raised with games that had content...

I personally hate to install stuff like MS-Office where there are a lot of
fancy gfx shown during the installation. I'd like it to maybe open a small
progress-bar in one corner of the screen, _not_ take up the entire screen
for as simple as an installation!

>Show me a best seller w/o good graphics.  How many games
>have great intros that have noting to do with the game,... the list  is

I talked about the *installation process*. Maybe you missed that or don't
care? :-)

>> Which is good. We have RPM and DEB already, which do everything that could
>> be needed, except for showing stupid 'splash-screens' while installing.
>First RPM/DEB are a Linux thing... I thought this project spaned Linux ...
>maybe I was wrong

Nope, you can get for instance RPM to any Unix by now. MS platforms also
would need some similar good tool.

>> I'd rather go for a reliable but ugly installation compared to a lot of
>> bells'n'whistles but unreliable operation. You install the software only
>> once, but if it is unreliably installed you pay for the fancy installation
>> every time you run the game.
>I do not recall anywere in my post that I suddggest writing an urealiable
>flashy install.

Why reinvent the wheel. In that case if you want a GUI in front of a
reliable system I'd suggest building a frontend to RPM. Maybe run the
process and pipe the output to the GUI which interprets it? But, installs
with RPM are _fast_. 

But hey, it's not my job to be negative here. I just thought I'd give some
input before someone starts a possibly quite huge process.

  Jan 'Chakie' Ekholm   |  CS at Åbo Akademi University, Turku, Finland 
 Linux Inside since '94 |      chakie@infa.abo.fi, jekholm@abo.fi