Re: GNOME libs 1.0.7 has been released

[James Green <gnome cyberstorm demon co uk>]

In message <370F70D2.3518DBEF@userfriendly.net>, hUnTeR
<hunter@userfriendly.net> writes
>Ryan Leduc wrote:
>> 
>> 1)  Yes, it's true that people could compile from src themselves..
>> 
>>     If you have an RPM based system, you're just making a mess..
>>     I prefer to keep tar installations to a minimum.  It's cleaner and
>>     easier to keep track of things..

Depends on the person. I began with RedHat Linux 5.1 over a year ago -
it lasted about a month on my system before I declared it unusable due
to complexity and that fact this it couldn't deal with my hardware. I
was starting my Comp Sci degree at the time. Certainly then I would not
have considered anything but precompiled RPMs, but I'm now a lot wiser
to the world (having come back with RH5.2 a couple of months ago) and
have ambitions for being in a career where RPMs can't be a relied upon
installation method, so I am learning sysadmin using tarballs. I have to
say I am seriously considering moving away from RedHat due to rpm
dependencies and suchlike, but since the competition mostly all use
either RPMs or debs there's not much to choose from.

>Excellent point Ryan, the beauty of the linux (redhat and debian)
>distros is that they are basically package based and updating and
>keeping a database of installed packages is MUCH easier to maintain than
>tarballs. Cron does this nightly thru update.db and keeps track of your
>currently installed RPMs...i dont think it cares much for independently
>compiled tars.

Indeed. We (the Linux community) are on the verge of a vast swing from
the average user knowing what tarballs and RPMs are to a day when the
average user is the same with Windows; these people often refer to their
machines having Windows97 - Win95 with Office97 (I work pt at a uni
helpdesk) - and they'd not consider anything other than click and go.

If I have one gripe I'd say I'm annoyed that RPMs can be a little:

a) difficult to find
b) inconsistent

I went off to my local sunsite mirror of contrib.redhat.com for some
suggested updates and found the ones up their older than the ones
installed already! If only people kept them up-to-date and well
distributed right across the broad range of packages I bet uptake
wouldn't half go up on RPM-based distros.

[ snip ]

>Exactly the point, newbies dont have a clue how to properly compile,
>especially when the compile and install docs are not thoroughly
>documented with every step they need to follow fo a successful install.
>These users just want to RUN the software and not take the time to learn
>the inter-steps to use it.

Actually the GNU configure - make - make install method together with
regular tarball diffs work quite nicely. It is a lot easier than
downloading updated RPMs (often large) on a very regular basis which is
not a lot of fun using a 56k modem in the UK due to heavy (per/min)
phone tarifs.

[ ... ]

>>     C) One of the purposes of the gnome project is to attract newcomers to
>>        linux by providing an easy to use graphical environment..
>> 
>>        What's the point of that if they have to first figure out how to
>>        compile the software, then learn how to make RPMs, just to try out
>>        this GUI that will make linux easier for the newbie..

Agreed. But you're forgetting the dependencies - a lot of work to get
these going too sometimes (imagine getting a required library,
downloading it, unpacking it, reading the README and then discovering a
load more deps, then recurse).


[ ... ]

>>        If you are making an "ease of use" software, the first rule of
>>        thumb is to make it easy to install..

Enter Bill Gates and the Add/Remove Programs applet. Glint is a nice
idea but a bit unfriendly. Personally one thing that has always put me
off Linux X apps is the widget sets used - they all come with far-spaced
widgets (esp. glint) that take up a lot of screen space. Windows does at
least have a nice compact look with soft rulebars seperating areas. I
wish GTK could be more like it.

>Again, EXACTLY. Its hard enough to attract new comers to the linux
>community because they already cant run "standard business apps" such as
>MS office (primary example). So we must give them SOMETHING to attract
>them to the distro - GNOME is perfect for this, since most newcomers
>almost ALWAYS use linux for the xwindows and associated apps. Most dont
>ever, or hardly ever use the command-line (old style UNIX) for their day
>to day activities. Perhaps this is a legacy we must live with thanks to
>WINDOWS and other GUI OSs. But, in order NOT to loose attraction they
>INSIST on a GUI-based UNIX.

Computers are for everyone, not used CLI-lovers. Most people don't use
computers more than necessary and certainly don't like looking at a
command-prompt without any self-explanatory way of getting where they
want to go. The CLI will forever be for the power-user only. The GUI is
the masses.

Windows was designed (read: nicked) for the masses. Microsoft spent a
lot of money researching how users look at their monitor-space, how they
react to things, how they get things done. We should be using the fruits
of their labour as inspiration for the Linux GUIs. Windows may crash,
but the UI, while not for everyone, is usable by the average man in the
street. It wouldn't have changed the world if it wasn't.

>> I think it's clear that some sort of organized method is needed
>> so that RPMs and debian packages can be made available as soon as a new
>> update is released.

Well, releasing them (tarball and RPM) together would be start. AIUI,
once you have a base RPM package, the spec file shouldn't be too
difficult to maintain for newer releases.

>> I think this needs to be coordinated with the gnome team so that the RPMs
>> are consistent with the previous ones  (ie there should be a standardized
>> set with the final say  going to the package maintainer), and can be made
>> available at the gnome site.

Agreed. RPMs ought to be available same day as tarballs, especially with
so many people available and willing :)

-- 
James Green