Reference (maybe Live) Distribution for Rev Linux
Peter Alcibiades
palcibiades-first at yahoo.co.uk
Mon Feb 8 05:31:07 EST 2010
I've got Andre's Suse based distribution but have not yet burned to usb and
fired up. However, thinking about this, there are some considerations
about a reference distro, which could be a very useful possible way out of
the Linux issues. Thoughts:
1) it needs to run Rev exactly as the developers expect.
So, if revPrintField and multiple desktops are not supported, they should
not work on the reference distribution, and the release notes should say
so. Or, if they are, the release notes should say so, and they should work
on the reference distribution. Rev Browser as well!
This is normal quality management procedures, and Rev needs to start this
right away. Define the standard and define the tests and give the results.
Then we can be certain that if we don't get the same results, its down to
our particular installation.
2) The chosen distribution should be reasonably pure.
Many of the larger distributions are not. I don't think this is much of a
problem in practice for users, but if you are using a reference distro, it
should be one that has as few custom mods as possible. It should be one
where you can be pretty sure that if a given feature works on this, it will
work on anything, because you know its working on a non-customized install.
A personal view: this will rule out using many large favorites as your
reference distro. From this perspective perhaps the reference distro
should be Slackware? That is the least tweaked distribution there is. A
Debian stable standard installation would also be a candidate. What you
do not want is one where all the configuration files are covered in
##do not edit this file it is generated automatically##
It would be nice if its live, but probably not essentiaI. I am tempted to
suggest Slax, which is Slackware live, very popular, and very compact, but
its probably excessively customized to serve as a reference distribution.
The point of a reference distribution is it should be unquestionable that
if a feature works on this, it is implemented correctly. Slackware, I
think most people would agree, meets this test. This is probably more
important than being live.
3) Testing and certification, if thats the word, should be done running on
real hardware, not in a virtual machine. It may be interesting that Rev
does not work properly in XP running on VirtualBox on a Mac, but
establishing that is not a robust way of testing a reference XP
installation. Nor is the equivalent for Linux. Nor indeed would we test
Rev for OSX on a Hackintosh as a reference installation! So we should not
rely on this approach for Linux.
The thing is, to prove a feature is implemented correctly, you only need to
produce one standard distro on which it works to spec. At the moment we
are in a situation where there is no reference, and people can always say,
well, it works/does not work for me. And then they have to start talking
which release of which version, all of which may well be, most probably is,
totally irrelevant. But how do we know? I assume that when Mac or
Windows releases are feature tested, it is against some specific version or
feature pack. Same thing is needed for Linux. It would save a huge amount
of time, speculation and irritation.
Peter
More information about the use-livecode
mailing list