Re: New shell script to check for available linux facilities for poplog

[Jeff Best]

Aaron,

In message <200411301844.iAUIijks030513@acws-0051.cs.bham.ac.uk>, Aaron 
Sloman <A.Sloman@cs.bham.ac.uk> writes
> Hi Jonathan
>
> > On Tue, 30 Nov 2004 12:50:39 +0000 (UTC), Aaron Sloman
> > <A.Sloman@cs.bham.ac.uk> wrote:
> > ......
> > >
> > >It seems that linux vendors are now trying to package linux to be as
> > >much like windows as possible and most windows users do not compile
> > >or link anything???
> >
> > It's in part, I think, a security thing. If you are running a
> > secure server, then naturally you spend every waking minute
> > thinking about securty vulnerabilities and installing patches
> > the very second they are released.
>
> In the case of SuSe it seems the developers think that they can provide
> pre-compiled versions of everything their users will want (via
> their stupidly named tool 'YAST' -- how many novice users will
> recognize that that's what they need to help configure their system?
> I failed that test when I tried SuSe 9.1!).

SuSE Professional comes with the most comprehensive set of manuals for 
any operating system that I have ever bought. Chapter 1 of both the User 
Guide and the Administration Guide introduce YaST, while Chapter 2 of 
the latter covers package management. The recent versions have even 
finished the translation to English, so entries in the table of 
contents, such as "Der Crashmanager" no longer appear.

When you update a SuSE installation, YaST will give the option of 
selecting exactly what packages you want to update or install. Possibly 
the initial installation requires you to do this from YaST after the new 
installation is on the disk.

SuSE (along with other variants) is increasingly being pitched at a 
variety of users, and there will be future releases that are intended to 
provide just a desktop for ordinary users who are not happy to mess 
around with compilers and linkers. In fact, people who program and 
people who want to compile packages are a small minority of the 
potential market for the operating system.

We may find that we will need to build a release package that uses a 
post-RPM shell script (or a Pop11 procedure) to fetch relevant packages 
from appropriate web-sites and install them.

Like all Linuxes, there is extensive support for packages released using 
the RedHat Package Manager. Unfortunately, we don't yet have a Poplog 
RPM validated across as many Linux variants as we can lay our hands on. 
As Jonathan has mentioned, this is something we would like to achieve 
with OpenPoplog, although finding the resource to do it has been 
somewhat difficult, of late. I am considering paying someone to do some 
of this work during this month or next. It is vital that the package 
build process is based on code checked out of code-control, so that we 
can reliably replicate builds and know exactly what is in each version.

> > On the OpenPoplog "todo" list is a task to make standard binary
> > packages for the common distros, so that recompilation is not
> > necessary.
>
> Who will decide which the common distros are? Someone who wants
> something as unusual as poplog may also be the sort of person who
> wants an unusual version of the operating system for some reason.
>
> While I applaud the intention to provide packaged versions that work,
> I suspect that will never cover all the requirements.
>
> I switched from providing a packaged version of Poplog to relinking on
> installation, partly because that coped better with changes in operating
> systems, and partly because it made the Poplog tar file smaller.
>
> But that is defeated by linux installations that don't include gcc!

I believe that we will need a variety of options, all built from code 
checked out of code control for the build. This way people can choose 
which version best matches their needs.

There is a Linux Standard Base, supported by a number of Linux 
providers, system and component manufacturers (Mandrake, SuSE, Red Hat, 
Dell, HP, IBM, AMD, Intel, etc.). It has been submitted to the ISO for 
ratification as a de jure standard. The Free Standards Group defines a 
hierarchy of certificates, such as LSB Runtime, LSB Application, LSB 
Build and LSB Internationalised Build. There is a certification process 
(and a website), that tells us what certificated level of support a 
given release has achieved. At the moment, it looks as if only LSB 
Runtime certification is listed. LSB also defines modules, such as 
processor, application, graphics, embedded, etc., that define the 
compliance required to meet each standard (or should that be a 
"sub-standard"?).

I don't know what is happening in the rest of the Linux world, but I 
suspect we should investigate which elements of Poplog fit into various 
LSB categories.

Regards,
--
Jeff