On 01/-10/-28163 02:59 PM, Always Learning wrote:
>
> On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
>> On Sep 7, 2011, at 9:57 AM, Always Learning wrote:
>>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches are
On Sep 8, 2011, at 9:16 PM, Always Learning wrote:
>
> On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
>> On Sep 7, 2011, at 9:57 AM, Always Learning wrote:
>>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches
On Thu, 2011-09-08 at 20:00 -0400, Ross Walker wrote:
> On Sep 7, 2011, at 9:57 AM, Always Learning wrote:
>
> > Perhaps a silly question, but why maintain patches ? Why not compile a
> > new version and discard all the patches ? Patches are a messy manner to
> > maintain programmes.
> RHEL nee
On Sep 7, 2011, at 9:57 AM, Always Learning wrote:
> Perhaps a silly question, but why maintain patches ? Why not compile a
> new version and discard all the patches ? Patches are a messy manner to
> maintain programmes.
RHEL needs to keep the same ABI (application binary interface) for both ker
On Thu, 2011-09-08 at 13:23 +1000, Steve Walsh wrote:
> Someone submits a patch as a quick-fix to a problem they've seen, which
> gets accepted and inserted into the package. Down the track, a better
> fix is submitted and accepted. All you need to do is pull the first
> patch file and insert
On 09/08/2011 12:53 AM, Always Learning wrote:
> So, if I understand the situation, patches create flexibility in
> run-time options not available in run-time configuration files ?
Someone submits a patch as a quick-fix to a problem they've seen, which
gets accepted and inserted into the packag
Greetings,
On Wed, Sep 7, 2011 at 9:11 PM, William Hooper wrote:
I tried RHEV once for about a fortnight with Openfiler as storage.
I started to hate openfiler ever since they switched over from centos
as a base to some other distro. Especially makes life difficult when
handlung NTFS partition
On Wed, Sep 7, 2011 at 11:31 AM, Les Mikesell wrote:
> On Wed, Sep 7, 2011 at 10:17 AM, William Hooper wrote:
>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches are a messy manner to
>>> maintain programmes.
>>
>> For
On Wed, Sep 7, 2011 at 10:17 AM, William Hooper wrote:
>> Perhaps a silly question, but why maintain patches ? Why not compile a
>> new version and discard all the patches ? Patches are a messy manner to
>> maintain programmes.
>
> For the same reason that Red Hat uses patches to back port securi
On Wed, Sep 7, 2011 at 9:57 AM, Always Learning wrote:
>
> On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
>
>> Red Hat is a business, and made a simple business decision. Maintaining
>> Xen support would have meant maintaining a very large set of patches.
>> They made the decision that the effo
On Wed, 7 Sep 2011, Always Learning wrote:
>
> On Wed, 2011-09-07 at 15:50 +0100, John Hodrien wrote:
>
>> On Wed, 7 Sep 2011, Always Learning wrote:
>>>
>>> A heavily patched programme is a messy compromise for system options
>>> which could be handled by run-time configuration options ?
>
>> But
On Wed, 2011-09-07 at 15:50 +0100, John Hodrien wrote:
> On Wed, 7 Sep 2011, Always Learning wrote:
> >
> > A heavily patched programme is a messy compromise for system options
> > which could be handled by run-time configuration options ?
> But without patches, you're either bound to an old ver
On Wed, 7 Sep 2011, Always Learning wrote:
>
> On Wed, 2011-09-07 at 15:39 +0100, John Hodrien wrote:
>
>> If that's all you're doing, there's no pain in having the patches.
>> But what happens if you don't want *all* the patches?
>
> A heavily patched programme is a messy compromise for system op
On Wed, 2011-09-07 at 15:39 +0100, John Hodrien wrote:
> If that's all you're doing, there's no pain in having the patches.
> But what happens if you don't want *all* the patches?
A heavily patched programme is a messy compromise for system options
which could be handled by run-time configuratio
On Wed, 7 Sep 2011, Always Learning wrote:
> On Wed, 2011-09-07 at 15:03 +0100, John Hodrien wrote:
>
>> On Wed, 7 Sep 2011, Always Learning wrote:
>>>
>>> Perhaps a silly question, but why maintain patches ? Why not compile a
>>> new version and discard all the patches ? Patches are a messy manne
Thanks Guys for the helpful info.
Paul.
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
On Wed, 2011-09-07 at 15:03 +0100, John Hodrien wrote:
> On Wed, 7 Sep 2011, Always Learning wrote:
> >
> > Perhaps a silly question, but why maintain patches ? Why not compile a
> > new version and discard all the patches ? Patches are a messy manner to
> > maintain programmes.
> That's fine if
On Wed, 2011-09-07 at 10:05 -0400, Digimer wrote:
> "At what point did we forget that the Space Shuttle was, essentially,
> a program that strapped human beings to an explosion and tried to stab
> through the sky with fire and math?"
And it worked. A tremendous and useful achievement now scrappe
On 09/07/2011 09:57 AM, Always Learning wrote:
>
> On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
>
>> Red Hat is a business, and made a simple business decision. Maintaining
>> Xen support would have meant maintaining a very large set of patches.
>> They made the decision that the effort (and
On Wed, 7 Sep 2011, Always Learning wrote:
>
> On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
>
>> Red Hat is a business, and made a simple business decision. Maintaining
>> Xen support would have meant maintaining a very large set of patches.
>> They made the decision that the effort (and mone
On Wed, Sep 7, 2011 at 3:51 PM, Digimer wrote:
> On 09/07/2011 09:34 AM, Rudi Ahlers wrote:
>> Red Hat (and thus CentOS) has native XEN support but dropped XEN in
>> favor of KVM (which is not as mature yet) in RH 6.
>
> This deserves clarification...
>
> Red Hat is a business, and made a simple b
On Wed, 2011-09-07 at 09:51 -0400, Digimer wrote:
> Red Hat is a business, and made a simple business decision. Maintaining
> Xen support would have meant maintaining a very large set of patches.
> They made the decision that the effort (and money) needed to maintain
> Xen outside of the mainline
On 09/07/2011 09:34 AM, Rudi Ahlers wrote:
> Red Hat (and thus CentOS) has native XEN support but dropped XEN in
> favor of KVM (which is not as mature yet) in RH 6.
This deserves clarification...
Red Hat is a business, and made a simple business decision. Maintaining
Xen support would have meant
23 matches
Mail list logo
