[linux-elitists] What to do about cluebatting such companies, that require possibly *YEARS* old Distros
Wed Jan 26 22:42:31 PST 2005
On Wed, 2005-01-26 at 17:57 -0500, Aaron Sherman wrote:
> On Wed, 2005-01-26 at 16:45, glen martin wrote:
> > Aaron takes issue with the word 'improperly'.
> > It is a question of goals. In a large telecom
> > manufacturer at which I once worked, tests were
> > fully automated and thorough. More people wrote
> > tests than wrote the system under test. This was
> > because for that environment bugs were simply
> > unacceptable period. There are other environments
> > that are the same: nuclear reactor control systems,
> > radiation therapy machines, etc. The economics don't
> > permit error. The word 'improperly' absolutely
> > applies in this sort of context.
> I would agree, and yet how often did that telco upgrade the OS on their
The obligatory: When needed to be.
> > For the rest of us, it is an optimisation
> > problem. Cost of defects vs cost of rigor at
> > initial development time.
> I disagree. For the rest of us, it's a matter of the cost of upgrading
> vs the benefits of incremental versions of the system software. In most
> cases, it's simply not a win to upgrade more than once every few years
> (not counting security updates, of course).
What is different from a security update, to a system that slowly
trudges along from version to version... auto-magically?
That slowly trudging along is similar to what I use cron-apt for on my
"perishable" systems. I use them as a lethal gas indicator. I then go to
these machine and figure out what went bad... and prevent these problems
from occurring on the Real machines. Tell, me what I am doing wrong? I
dist-upgrade everyday on the perishable systems... and usually at least
weekly on those machines that need uptime and availability... but also
need to be uptodate.
I still wonder, if what you are prescribing is a terrible thing to do,
when the ability to have what I do be exceptionally possible overall.
Multi-Leveled Automated Build Systems keep sounding better and better.
All with controllable and automated rollout with approvals, set tasking
and so on.
The technology that is
Stronger, better, faster: Linux
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://allium.zgp.org/pipermail/linux-elitists/attachments/20050127/78358ebc/attachment.pgp
More information about the linux-elitists