ALPHA_V732_MASTER_ECO_LIST.txt
Phillip Helbig---remove CLOTHES to reply
UPDATE-V1100 and a few patches which came out after it. In
ALPHA_V732_MASTER_ECO_LIST.txt one can read "At the current time, no
further UPDATE kits are scheduled for OpenVMS V7.3-2". Since
UPDATE-V1100 was released on 7-MAR-2007, it seems that the plans changed
rather quickly.
Anyway, the main question is: what is in this UPDATE patch which I don't
already have. ALPHA_V732_MASTER_ECO_LIST.txt has two lists:
KITS INCLUDED IN UPDATE KIT (with a note if there is a newer version
of the patch than the one in the kit)
and
ECO KITS NOT INCLUDED IN UPDATE KIT
The latter contains mostly the newer versions of the ECOs which are
marked as superseded in the former.
It would be nice to have a third list, namely
ECO KITS NOT INCLUDED IN THE PREVIOUS UPDATE KIT
since that is probably the thing most people are interested in.
Basically, I have to go through the list in the section
CONSOLIDATION OF PREVIOUSLY RELEASED V7.3-2 ECO KITS
and check which of the ECOs are installed. I can't use PRODUCT because
some of them will have been installed via an UPDATE patch, so I have to
check the release notes.
Actually, it would be enough if in the lists of ECOs, release notes and
images there was a note indicating if the corresponding patch wasn't in
the previous update kit.
Can the patch maintainer at HP implement this relatively easy change?
Does anyone have any code to automate this (i.e. from the contents of
the release notes in SYS$HELP and the contents of
ALPHA_V732_MASTER_ECO_LIST.txt determine which patches I don't yet have?
norm.r...@metso.com
starts to become a prerequisite for new patches.
Thus, even if one has installed all ECO's in the latest UPDATE ECO, one
must perforce install the UPDATE ECO in order to
have later-released ECO's install successfully.
I once asked if the UPDATE ECO could check for the presence of installed
ECO contained within and just either install the ones
not yet present or (since if some we not there it may well be because the
are unwanted/unneeded--non-category-one ECO's
somehow get into these UPDATE ECO's), provide a switch to just mark the
database so later ECO's don't fail; IOW trust the
system manager--what a concept. The comment was that this was too hard to
do.
hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)
Ron Johnson
--
Ron Johnson, Jr.
Jefferson LA USA
Give a man a fish, and he eats for a day.
Hit him with a fish, and he goes away for good!
Phillip Helbig---remove CLOTHES to reply
<OFDC37DF3E.7CBC3E3E-ON852572...@metso.com>,
norm.r...@metso.com writes:
> Actually, this becomes moot, because after the UPDATE patch is release, it
> starts to become a prerequisite for new patches.
> Thus, even if one has installed all ECO's in the latest UPDATE ECO, one
> must perforce install the UPDATE ECO in order to
> have later-released ECO's install successfully.
OK, but by knowing what new stuff is in it, I can decide if I want to
install it soon, or perhaps later (maybe even just before the ECO after
it).
> I once asked if the UPDATE ECO could check for the presence of installed
> ECO contained within and just either install the ones
> not yet present or (since if some we not there it may well be because the
> are unwanted/unneeded--non-category-one ECO's
> somehow get into these UPDATE ECO's), provide a switch to just mark the
> database so later ECO's don't fail; IOW trust the
> system manager--what a concept. The comment was that this was too hard to
> do.
Are you saying that one ECO is a TECHNICAL requirement for installing
future ones? I've certainly skipped some updates. Of course, although
they are cumulative, if the stuff is already installed, it doesn't get
installed again.
norm.r...@metso.com
hel...@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to reply)
wrote on 06/07/2007 03:16:05 PM:
> In article
> <OFDC37DF3E.7CBC3E3E-ON852572...@metso.com>,
> norm.r...@metso.com writes:
>
> > Actually, this becomes moot, because after the UPDATE patch is release,
it
> > starts to become a prerequisite for new patches.
> > Thus, even if one has installed all ECO's in the latest UPDATE ECO, one
> > must perforce install the UPDATE ECO in order to
> > have later-released ECO's install successfully.
>
> OK, but by knowing what new stuff is in it, I can decide if I want to
> install it soon, or perhaps later (maybe even just before the ECO after
> it).
You might could tell from the release dates in the included list, if you
could trust the editing - which you cannot.
>
> > I once asked if the UPDATE ECO could check for the presence of
installed
> > ECO contained within and just either install the ones
> > not yet present or (since if some we not there it may well be because
the
> > are unwanted/unneeded--non-category-one ECO's
> > somehow get into these UPDATE ECO's), provide a switch to just mark the
> > database so later ECO's don't fail; IOW trust the
> > system manager--what a concept. The comment was that this was too hard
to
> > do.
>
> Are you saying that one ECO is a TECHNICAL requirement for installing
> future ones?
Yes, often the UPDATE ECO's are made prerequisites for ECO's that come out
after them.
> I've certainly skipped some updates. Of course, although
> they are cumulative, if the stuff is already installed, it doesn't get
> installed again.
>
AFAIK, the UPDATE reinstalls ECO's unless there are NEWER version of the
files being replaced. It's not if the old one is (greater than or equal)
that it skips, but only (greater than).
P. Sture
<OF0F3F4B28.DB548492-ONC22572...@metso.com>,
norm.r...@metso.com wrote:
> AFAIK, the UPDATE reinstalls ECO's unless there are NEWER version of the
> files being replaced. It's not if the old one is (greater than or equal)
> that it skips, but only (greater than).
Yep. Just had a bunch of those with V83A-UPDATE 3.0:
The following product will be installed to destination:
DEC AXPVMS VMS83A_UPDATE V3.0 DISK$ALPHASYS:[VMS$COMMON.]
%PCSI-I-RETAIN, file [SYS$LDR]IO_ROUTINES.EXE was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]IO_ROUTINES.STB was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]IO_ROUTINES_MON.EXE was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]IO_ROUTINES_MON.STB was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]PROCESS_MANAGEMENT.EXE was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]PROCESS_MANAGEMENT.STB was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]PROCESS_MANAGEMENT_MON.EXE was not
replaced because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]PROCESS_MANAGEMENT_MON.STB was not
replaced because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$CLUSTER.EXE was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$CLUSTER.STB was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$CLUSTER_MON.EXE was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$CLUSTER_MON.STB was not replaced
because file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$PEDRIVER.EXE was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$PEDRIVER.STB was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$VM.EXE was not replaced because file
from kit has lower generation number
%PCSI-I-RETAIN, file [SYS$LDR]SYS$VM.STB was not replaced because file
from kit has lower generation number
%PCSI-I-RETAIN, file [SYSLIB]DECC$SHR.EXE was not replaced because file
from kit has lower generation number
%PCSI-I-RETAIN, file [SYSLIB]DECC$SHR_EV56.EXE was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, file [SYSUPD]DECC$RTLDEF.TLB was not replaced because
file from kit has lower generation number
%PCSI-I-RETAIN, imglib module DECC$SHR was not replaced because imglib
module from kit has lower generation number
Portion done:
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
The following product has been installed (and a recovery data set
created):
DEC AXPVMS VMS83A_UPDATE V3.0 Patch (maintenance update)
DEC AXPVMS VMS83A_UPDATE V3.0: OpenVMS Alpha V8.3 UPDATE V3.0
VMS83A_UPDATE-V0300 Release notes available
Release notes for the VMS83A_UPDATE-V0300 kit and
all included kits are available at SYS$COMMON:[000000.SYSHLP]
--
Paul Sture
David J Dachtera
>
> You know... installing "patches" in Linux is a *lot* simpler.
You're joking, right?
--
David J Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial OpenVMS Marketing Home Page
http://www.djesys.com/vms/market/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Unofficial OpenVMS-IA32 Home Page:
http://www.djesys.com/vms/ia32/
Unofficial OpenVMS Hobbyist Support Page:
http://www.djesys.com/vms/support/
Ron Johnson
> Ron Johnson wrote:
>> You know... installing "patches" in Linux is a *lot* simpler.
>
> You're joking, right?
Dead serious. In Debian/Ubuntu, it's as simple as:
# apt-get update && apt-get upgrade
Then it shows you the outstanding critical bugs and you answer Y or N.
If you're stupid, it's even easier:
# apt-get update && apt-get -y upgrade
(The "-y" switch means, "answer yes to all questions.)
John Santos
> In article
> <OFDC37DF3E.7CBC3E3E-ON852572...@metso.com>,
> norm.r...@metso.com writes:
>
>
>>Actually, this becomes moot, because after the UPDATE patch is release, it
>>starts to become a prerequisite for new patches.
>>Thus, even if one has installed all ECO's in the latest UPDATE ECO, one
>>must perforce install the UPDATE ECO in order to
>>have later-released ECO's install successfully.
>
>
> OK, but by knowing what new stuff is in it, I can decide if I want to
> install it soon, or perhaps later (maybe even just before the ECO after
> it).
>
What do you mean by "new" stuff? ECOs that haven't previously been
released as separate kits? Or ECOs that you haven't already installed?
If the 1st meaning, the answer is "NONE". AFAIK, there has *never* been
an ECO included in an UPDATE kit that wasn't previously issued as a
separate kit.
>
>>I once asked if the UPDATE ECO could check for the presence of installed
>>ECO contained within and just either install the ones
>>not yet present or (since if some we not there it may well be because the
>>are unwanted/unneeded--non-category-one ECO's
>>somehow get into these UPDATE ECO's), provide a switch to just mark the
>>database so later ECO's don't fail; IOW trust the
>>system manager--what a concept. The comment was that this was too hard to
>>do.
>
>
> Are you saying that one ECO is a TECHNICAL requirement for installing
> future ones? I've certainly skipped some updates. Of course, although
> they are cumulative, if the stuff is already installed, it doesn't get
> installed again.
>
Generally, ECOs issued more than a short while (a few days, weeks, or
maybe a month?) after an UPDATE kit require that UPDATE version as a
prerequisite, assuming they have any prerequisites at all. Is that
what you mean by a TECHNICAL requirement? You could always hack the
PCSI database to make it think the ECO was there, but that is completely
unsupported and undocumented, and anyway it's much easier to just install
the UPDATE. And after many years of UPDATEs, it is certainly much easier,
faster and safer to install the latest UPDATE than to install dozens if
not hundreds of individual ECOs. Plus the latest ECOs have only been
tested with the listed prerequisites, and not with all possible random
sets of previous ECOs, so you would be swimming in shark-infested waters
(VMS joke :-) if you tried to hack it and had left out some "I don't really
need this" ECOs.
Why are you trying so hard to avoid just installing the UPDATE? If
your scared of breaking something, don't install at all until you need
to, or wait for a month or two to see if anything problematic crops up.
(The original March 07 V7.3-2 UPDATE (V10.0) had a bug in it and was
replaced a few days later by V11.0. If there's a serious problem, they
usually notice pretty quickly. And all the component ECOs had been
out for at least a month when it was released.)
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
Phillip Helbig---remove CLOTHES to reply
writes:
> Phillip Helbig---remove CLOTHES to reply wrote:
> > In article
> > <OFDC37DF3E.7CBC3E3E-ON852572...@metso.com>,
> > norm.r...@metso.com writes:
> >
> >
> >>Actually, this becomes moot, because after the UPDATE patch is release, it
> >>starts to become a prerequisite for new patches.
> >>Thus, even if one has installed all ECO's in the latest UPDATE ECO, one
> >>must perforce install the UPDATE ECO in order to
> >>have later-released ECO's install successfully.
> >
> >
> > OK, but by knowing what new stuff is in it, I can decide if I want to
> > install it soon, or perhaps later (maybe even just before the ECO after
> > it).
> >
>
> What do you mean by "new" stuff? ECOs that haven't previously been
> released as separate kits? Or ECOs that you haven't already installed?
The latter.
george.p...@hp.com
I'm responsible for the patch process. I thought it was best to
answer all this in the form of an FAQ.
*Can patch lists in the UPDATE kits and master lists say which kits
were not in the previous UPDATE kit?
Absolutely, good idea. What I will do on future UPDATE kits is to add
an asterisk to the patch kit name if that patch was not in the
previous UPDATE kit.
*Why are there still UPDATE kits for V7.3-2.
At the time the VMS732_UPDATE-V1100 kit came out, the official plans
were to make that the last UPDATE kit for V7.3-2. As it turned out,
it was later decided that was not the best decision for our customers
and another one was planned. That's about the state of V7.3-2 UPDATE
kits now - when the time comes to start producing the next round of
UPDATE
kits we'll decide if we should do another one for V7.3-2. Personally,
at some point UPDATE kits for V7.3-2 will stop but I don't see it
happening for the next year (my opinion, not official policy).
*Why are UPDATE kits required kits?
A little history here. We often send out patch kits that have
dependencies on other patch kits. Before UPDATE kits , these
dependencies, over time, would get unmanageable - Kit A requires Kit
B, Kit B does not require kit A but Kit A does require Kit C which
now, since Kit B requires Kit A, it also now requires Kit C
but.....you get the idea. UPDATE kits were started as a way to set a
new patch baseline and eliminate all those dependencies. To
accomplish this, once an UPDATE kit ships it beccomes a required kit
for any patch kit that is produced after the release of the UPDATE
kit. There is one caveat - when we started regularly scheduled
releases of UPDATE kits we changed the requirement policy. Now, patch
kits that require a reboot will require the latest UPDATE kit. Patch
kits that do not require a reboot will require the UPDATE kit released
before the latest kit. This is to try and help customers avoid an
unnecessary reboot if they haven't yet installed the latest kit.
*Why can't UPDATE kits only install what has not yet been installed
with individual patch kits?
The UPDATE kits set a baseline patch level. Without installing
everything in the UPDATE kit we really have no assurance that the
baseline has been set. With that said, two things were mentioned -
marking the database that an image has already been installed. As Norm
has mentioned, forget it, it's too difficult from an engineering
standpoint. You are talking a major rewrite of the PCSI facility.
It's not that it is difficult, there is not enough payback for such an
investment of resources. The other option is to do something within
the patch itself. I actually built a test UPDATE kit that checked to
see what had already been installed and did not reinstall those
images. I installed it on a system with no previous patches and on a
system with all the previous patches installed. I purposely used a
version (I think it was V7.3-2) that had a lot of patches against it;
my expectation being that there would be a significant reduction in
installation time. There was almost none and for that reason and
becuse of the baseline thing, I abandoned this idea.
*What patches are included in UPDATE kits?
UPDATE kits do not ship anything new. They only ship patch kits that
have been released and in the field for some time. The length of time
is dependent on the complexity of the patch kit. If an UPDATE kit has
a functional problem with an included image that requires us to pull
the kit, what we will do is pull the kit and remove the offending
patch kit and re-issue the UPDATE kit ; not add a new fix to the
UPDATE kit and re-issue it.
* How does PCSI treat images?
If a patch kit is contains an image that is the same version, or
later, as the image in an already installed patch kit, the image will
be installed. If the image in the new kit is older, the image in the
new kit will not be installed. If PCSI has no way of knowing, e.g.
the image on the system is an engineering test image, and does not
have the needed data in the image header, the image in the patch kit
will be installed, wiping out the older, questionable image. There is
a warning in the patch docmentation about this.
George Pagliarulo
ECO Release Process
OpenVMS Sustaining Engineering
Hewlett-Packard Company
e-mail: george.p...@hp.com
norm.r...@metso.com
"george.p...@hp.com" <george.p...@hp.com> wrote on 06/08/2007
08:38:11 AM:
> Hi,
>
> I'm responsible for the patch process. I thought it was best to
> answer all this in the form of an FAQ.
>
Thanks, George.
Will this find it's way into the OpenVMS FAQ?
> *Can patch lists in the UPDATE kits and master lists say which kits
> were not in the previous UPDATE kit?
> Absolutely, good idea. What I will do on future UPDATE kits is to add
> an asterisk to the patch kit name if that patch was not in the
> previous UPDATE kit.
>
> *Why are there still UPDATE kits for V7.3-2.
>
> At the time the VMS732_UPDATE-V1100 kit came out, the official plans
> were to make that the last UPDATE kit for V7.3-2. As it turned out,
> it was later decided that was not the best decision for our customers
> and another one was planned. That's about the state of V7.3-2 UPDATE
> kits now - when the time comes to start producing the next round of
> UPDATE
> kits we'll decide if we should do another one for V7.3-2. Personally,
> at some point UPDATE kits for V7.3-2 will stop but I don't see it
> happening for the next year (my opinion, not official policy).
So what changed was the commitment to scheduled UPDATE ECO's, not the
commitment to do the reasonable thing. That's goodness IMHO.
>
> *Why are UPDATE kits required kits?
>
> A little history here. We often send out patch kits that have
> dependencies on other patch kits. Before UPDATE kits , these
> dependencies, over time, would get unmanageable - Kit A requires Kit
> B, Kit B does not require kit A but Kit A does require Kit C which
> now, since Kit B requires Kit A, it also now requires Kit C
> but.....you get the idea.
Ah, yes, I remember well those games. I had to create a hierarchy of
ECO directories and apply the ECO's in each in turn, sometimes rebooting
in between applications. Not pretty.
> UPDATE kits were started as a way to set a
> new patch baseline and eliminate all those dependencies.
This is not well-understood. I'm glad to see it spelled out.
> Toaccomplish this, once an UPDATE kit ships it beccomes a required kit
> for any patch kit that is produced after the release of the UPDATE
> kit. There is one caveat - when we started regularly scheduled
> releases of UPDATE kits we changed the requirement policy. Now, patch
> kits that require a reboot will require the latest UPDATE kit. Patch
> kits that do not require a reboot will require the UPDATE kit released
> before the latest kit. This is to try and help customers avoid an
> unnecessary reboot if they haven't yet installed the latest kit.
>
> *Why can't UPDATE kits only install what has not yet been installed
> with individual patch kits?
>
> The UPDATE kits set a baseline patch level. Without installing
> everything in the UPDATE kit we really have no assurance that the
> baseline has been set. With that said, two things were mentioned -
> marking the database that an image has already been installed. As Norm
> has mentioned, forget it, it's too difficult
"...it's too difficult..."
> from an engineering
> standpoint. You are talking a major rewrite of the PCSI facility.
> It's not that it is difficult;
"It's not that it is difficult..."
Oh, well, difficult or not, counter to intuition it has slight
payback, so what does that matter.
My difficulty was that if I had already installed _all_ the ECO's included
in an UPDATE ECO and then I needed -- that's needed -- a subsequent level
1 ECO, the later one would perforce carry the (uninstalled because all it's
included ECO's were on the system) UPDATE ECO as a prerequisite, so I'd
have to install both the UPDATE ECO and the needed ECO, a process that
does take longer than just applying the single ECO. So I was really
looking for a way to have the UPDATE ECO be run and do a precheck; if
all it's contents were already in the database, mark the UPDATE ECO as
installed in the database and forgo any reboot. That should be quicker
that reistalling, allow later ECO's one or more at a time, and maintain
the baseline. That said, I agree that it's not much harder to just bite
the bullet and schedule the UPDATE ECO appropriately. If you have to
reboot anyway, and you usually do if the ECO is "important," the extra
time is not worth the explaination of the workaround.
Phillip Helbig---remove CLOTHES to reply
"george.p...@hp.com" <george.p...@hp.com> writes:
> I'm responsible for the patch process. I thought it was best to
> answer all this in the form of an FAQ.
Thanks; much appreciated!
> *Can patch lists in the UPDATE kits and master lists say which kits
> were not in the previous UPDATE kit?
> Absolutely, good idea. What I will do on future UPDATE kits is to add
> an asterisk to the patch kit name if that patch was not in the
> previous UPDATE kit.
Great.
I am normally up-to-date. But, if I come back from holiday, say, and
see some new patches AND a new update kit, it's nice to see whether all
the new patches are in the update kit (this is not always the case).
(Someone pointed out that there has never been a patch in an update kit
which was not released individually first; can one count on this?)
Thus, in such cases I could install just the update kit.
> *Why are there still UPDATE kits for V7.3-2.
Because I'm still using it! :-)
> At the time the VMS732_UPDATE-V1100 kit came out, the official plans
> were to make that the last UPDATE kit for V7.3-2.
Right. I think this was even documented.
> *Why are UPDATE kits required kits?
>
> A little history here. We often send out patch kits that have
> dependencies on other patch kits. Before UPDATE kits , these
> dependencies, over time, would get unmanageable - Kit A requires Kit
> B, Kit B does not require kit A but Kit A does require Kit C which
> now, since Kit B requires Kit A, it also now requires Kit C
> but.....you get the idea. UPDATE kits were started as a way to set a
> new patch baseline and eliminate all those dependencies. To
> accomplish this, once an UPDATE kit ships it beccomes a required kit
> for any patch kit that is produced after the release of the UPDATE
> kit. There is one caveat - when we started regularly scheduled
> releases of UPDATE kits we changed the requirement policy. Now, patch
> kits that require a reboot will require the latest UPDATE kit. Patch
> kits that do not require a reboot will require the UPDATE kit released
> before the latest kit. This is to try and help customers avoid an
> unnecessary reboot if they haven't yet installed the latest kit.
Good idea.
> *Why can't UPDATE kits only install what has not yet been installed
> with individual patch kits?
>
> The UPDATE kits set a baseline patch level. Without installing
> everything in the UPDATE kit we really have no assurance that the
> baseline has been set. With that said, two things were mentioned -
> marking the database that an image has already been installed. As Norm
> has mentioned, forget it, it's too difficult from an engineering
> standpoint. You are talking a major rewrite of the PCSI facility.
> It's not that it is difficult, there is not enough payback for such an
> investment of resources. The other option is to do something within
> the patch itself. I actually built a test UPDATE kit that checked to
> see what had already been installed and did not reinstall those
> images. I installed it on a system with no previous patches and on a
> system with all the previous patches installed. I purposely used a
> version (I think it was V7.3-2) that had a lot of patches against it;
> my expectation being that there would be a significant reduction in
> installation time. There was almost none and for that reason and
> becuse of the baseline thing, I abandoned this idea.
OK. But is it correct that if a NEWER version is installed, the one
from the patch isn't (makes sense), but if the SAME version is
installed, it is (doesn't hurt, but not necessary; maybe not a
significant reduction in time, but if you have checked anyway)? (Of
course, if the version from the update kit is newer, it gets installed.)
> If a patch kit is contains an image that is the same version, or
> later, as the image in an already installed patch kit, the image will
> be installed. If the image in the new kit is older, the image in the
> new kit will not be installed. If PCSI has no way of knowing, e.g.
> the image on the system is an engineering test image, and does not
> have the needed data in the image header, the image in the patch kit
> will be installed, wiping out the older, questionable image. There is
> a warning in the patch docmentation about this.
OK, but why >= instead of >?
Bob Koehler
> Ron Johnson wrote:
>>
>> You know... installing "patches" in Linux is a *lot* simpler.
>
> You're joking, right?
No he's serious. Patching Linux goes something like this:
1) identify bug
2) identify which application has the bug
3) search for the source for a functionally equivalent version of the
application
4) study the source for a while
5) change the source to fix the bug
6) built, test, repeat
How much simpler could it be? (Bought RedHat. Bought RedHat
support. Never got a single bug fix via their automated update tool.)
JF Mezei
What percentage of shops running Linux in production have not only the
sources for all the stuff that came with Linux but also the tools to
build executables ?
If only a very small percentage of Linux shops have the tools needed to
change the source and rebuild the faulty executable to put into
production, then the ability for a shop to make their own fixes to
Linux is only theoretical.
Ron Johnson
> In article <466898C8...@spam.comcast.net>, David J Dachtera
> <djes...@spam.comcast.net> writes:
>> Ron Johnson wrote:
>>> You know... installing "patches" in Linux is a *lot* simpler.
>>>
>> You're joking, right?
>
> No he's serious. Patching Linux goes something like this:
>
> 1) identify bug
You do that no matter which OS you run.
> 2) identify which application has the bug
You do that no matter which OS you run.
> 3) search for the source for a functionally equivalent version of
> the application
This is 2007, not 1997.
> 4) study the source for a while
This is 2007, not 1997.
> 5) change the source to fix the bug
This is 2007, not 1997.
> 6) built, test, repeat
This is 2007, not 1997. Unless you are a distro. I haven't *had*
to build new software in years. (Ever since I was using Mandrake.)
> How much simpler could it be? (Bought RedHat. Bought RedHat
> support. Never got a single bug fix via their automated update
> tool.)
You must have set up something wrong.
But then, maybe not. Anyway I use Debian, and there's a definite
stream of security fixes flowing into v4.0 ("stable").
Arne Vajhøj
> How much simpler could it be? (Bought RedHat. Bought RedHat
> support. Never got a single bug fix via their automated update tool.)
Mysterious.
I my experience up2date works very nicely.
Arne
Arne Vajhøj
Most neither has the skills nor any interest in doing so.
But there are a group of volunteers and there are some companies
with commercial interest in Linux (IBM, Redhat, Oracle, Novell etc.)
that do use the possibility.
The end users advantage is that thery are not dependent on a
single company.
Arne
David J Dachtera
>
> On 06/07/07 18:46, David J Dachtera wrote:
> > Ron Johnson wrote:
> >> You know... installing "patches" in Linux is a *lot* simpler.
> >
> > You're joking, right?
>
> Dead serious. In Debian/Ubuntu, it's as simple as:
> # apt-get update && apt-get upgrade
> Then it shows you the outstanding critical bugs and you answer Y or N.
>
> If you're stupid, it's even easier:
> # apt-get update && apt-get -y upgrade
>
> (The "-y" switch means, "answer yes to all questions.)
...until it fails. Then, heaven help you. You'll either spend months recovering
from it (based on postings in other groups where I lurk but do not participate),
or you'll scrap it, reformat and start over from a clean install.
Ron Johnson
> Ron Johnson wrote:
>> On 06/07/07 18:46, David J Dachtera wrote:
>>> Ron Johnson wrote:
>>>> You know... installing "patches" in Linux is a *lot* simpler.
>>> You're joking, right?
>> Dead serious. In Debian/Ubuntu, it's as simple as:
>> # apt-get update && apt-get upgrade
>> Then it shows you the outstanding critical bugs and you answer Y or N.
>>
>> If you're stupid, it's even easier:
>> # apt-get update && apt-get -y upgrade
>>
>> (The "-y" switch means, "answer yes to all questions.)
>
> ...until it fails. Then, heaven help you. You'll either spend months recovering
> from it (based on postings in other groups where I lurk but do not participate),
> or you'll scrap it, reformat and start over from a clean install.
*Exactly!* Which is why you should never, ever do it. "-y" is
useful, though, for automated downloads. Put this in root's crontab
to run at night or weekend, when corporate bandwidth usage should be
lower:
# apt-get update && apt-get -d -y upgrade
The "-d" switch means download-only. Makes things easier for you
the next day.
george.p...@hp.com
installing a kit and, for some reason or another, having to re-install
to get an image back on the system. Since the database saw the image
as already being installed, with it being >, it would not install the
"new" (same) image. DOH.
George Pagliarulo
ECO Release Process
OpenVMS Sustaining Engineering
Hewlett-Packard Company
On Jun 8, 3:59 pm, hel...@astro.multiCLOTHESvax.de (Phillip Helbig---
remove CLOTHES to reply) wrote:
> In article <1181306291.602139.49...@k79g2000hse.googlegroups.com>,
> > If a patch kit is contains an image that is the same version, or
> > later, as the image in an already installed patch kit, the image will
> > be installed. If the image in the new kit is older, the image in the
> > new kit will not be installed. If PCSI has no way of knowing, e.g.
> > the image on the system is an engineering test image, and does not
> > have the needed data in the image header, the image in the patch kit
> > will be installed, wiping out the older, questionable image. There is
> > a warning in the patch docmentation about this.
>
> OK, but why >= instead of >?- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Phillip Helbig---remove CLOTHES to reply
"george.p...@hp.com" <george.p...@hp.com> writes:
> It used to be > and was changed to >= . We had instances of customers
> installing a kit and, for some reason or another, having to re-install
> to get an image back on the system. Since the database saw the image
> as already being installed, with it being >, it would not install the
> "new" (same) image. DOH.
This sounds like the database marked the image as installed before it
actually was. I can see this happening if a disk fills up or whatever,
but only if the database is updated before the actual installation. Is
that the case?
george.p...@hp.com
remove CLOTHES to reply) wrote:
>
> "george.pagliar...@hp.com" <george.pagliar...@hp.com> writes:
> > It used to be > and was changed to >= . We had instances of customers
> > installing a kit and, for some reason or another, having to re-install
> > to get an image back on the system. Since the database saw the image
> > as already being installed, with it being >, it would not install the
> > "new" (same) image. DOH.
>
> This sounds like the database marked the image as installed before it
> actually was. I can see this happening if a disk fills up or whatever,
> but only if the database is updated before the actual installation. Is
> that the case?
No. The case I'm talking about is when, sometime after installation,
an image is deleted or there is some other problem that causes a user
to want to re-install the images in the kit. And PCSI will check for
adequate disk space before it atempts to install a kit.
Bob Koehler
The theory is that you're always running the latest so you just go
get the latest source and run that.
My son is a Linux "hobbyist". Spends a tremendous amount of time on
that first part. I am a Linux user, running out of date RedHat
distributions.
Reality bites.
Bob Koehler
>
> This is 2007, not 1997.
>
I've been fixing software bugs since 1977. It hasn't changed.
Oh, you were expecting someone else to provide the bug fix? 8-)
Bob Koehler
> The end users advantage is that thery are not dependent on a
> single company.
So what do they do when RedHat no longer supports the version they
bought? Start over with Debian? Hardly an option in a lot of cases,
where _everything_ must be 100% tested and proven right.
Bill Gunshannon
I would guess the same thing they do when the vendor they bought OSF1.
Tru64 or Ultrix from no longer supports them. (Hint: the same thing
can happen to VMS!)
bill
--
Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves
bi...@cs.scranton.edu | and a sheep voting on what's for dinner.
University of Scranton |
Scranton, Pennsylvania | #include <std.disclaimer.h>
Ron Johnson
He needs Debian. Keeping it up-to-date is quick and simple.
> I am a Linux user, running out of date RedHat
> distributions.
But then again, *you* need Debian. He probably *like* doing it. 35
years ago, he'd have been constantly fiddling with his car, and
you'd have been grumbling about that...
> Reality bites.
Nah. What bites is not having a son who has the same priorities as
you. :\
Ron Johnson
Bob Koehler
> He needs Debian. Keeping it up-to-date is quick and simple.
>
No matter how easy it is to get and apply the update, in many shops
testing and distributing on a regular basis is simply not in the
budget.
>> I am a Linux user, running out of date RedHat
>> distributions.
>
> But then again, *you* need Debian. He probably *like* doing it. 35
> years ago, he'd have been constantly fiddling with his car, and
> you'd have been grumbling about that...
>
No, I need to stick with VMS where I have no fear of some latent bug
coming up in my out of date distribution.
Arne Vajhøj
Pay you to support it, because you have access to the all the code.
Or maybe slightly more realistic they pay Oracle, which now offers
support for Redhat Linux.
Arne
Arne Vajhøj
> On 06/12/07 07:40, Bob Koehler wrote:
>> In article <b9cdc$466a03cf$cef8887a$14...@TEKSAVVY.COM>, JF Mezei
>> <jfmezei...@vaxination.ca> writes:
>>> Question:
>>>
>>> What percentage of shops running Linux in production have not only
>>> the sources for all the stuff that came with Linux but also the tools
>>> to build executables ?
>>>
>>> If only a very small percentage of Linux shops have the tools needed
>>> to change the source and rebuild the faulty executable to put into
>>> production, then the ability for a shop to make their own fixes to
>>> Linux is only theoretical.
>>
>> The theory is that you're always running the latest so you just go
>> get the latest source and run that.
>>
>> My son is a Linux "hobbyist". Spends a tremendous amount of time on
>> that first part.
>
> He needs Debian. Keeping it up-to-date is quick and simple.
up2date/yum works fine.
Arne