public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Jay Ashworth <jra@baylink.com>
Cc: xfs@oss.sgi.com
Subject: Re: A short digression on FOSS (Re: understanding speculative preallocation)
Date: Mon, 29 Jul 2013 12:05:55 -0500	[thread overview]
Message-ID: <51F6A0F3.8030604@sandeen.net> (raw)
In-Reply-To: <15781090.2540.1375111802121.JavaMail.root@benjamin.baylink.com>

On 7/29/13 10:30 AM, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Eric Sandeen" <sandeen@sandeen.net>
> 
>>>> From: "Dave Chinner" <david@fromorbit.com>
>>>
>>>> The "version" of XFS that you are running is that of the
>>>> kernel you are running. i.e. 2.6.32-279.x.y or 2.6.32-358.x.y.
>>>
>>> Those aren't kernel versions; those are kernel *package* versions.
>>
>> Those are RHEL kernel version numbers, which 100% uniquely identify
>> the code contained in those kernels.
> 
> So how, Eric, would that help, say, SuSE users -- 

Well, it doesn't... SuSE helps SuSE users.  And I'm not being glib,
that's just how it works.

> which the XFS website makes 
> special note to point out that there's a specific agreement in place to 
> support.  Even SLES users vice openSUSE, though the XFS.org website doesn't 
> make that distinction.

xfs.org is a public wiki run by a 3rd party, so I can't speak to the accuracy
of statements made about support agreements between SGI & SuSE, if any.

So I guess I have no useful insight there.

> I'm sticking with "those are kernel package versions", and I was yelled
> at the other day because I was interested in things that weren't "mainline
> kernel versions".  RHEL kernels are the *best available example* of "not
> a mainline kernel version", so I find these conflicting reports most
> conflicting.

You're welcome to be interested all you want, but availability of support
from either SGI (not related to CentOS at all), upstream (focused on new work,
not older distros), or Red Hat (who sells support, vs. gives it away, in
order to pay the people to keep maintaining the distro that CentOS is
more than welcome to pick up, rebuild, & ship, and support or not as *they* 
see fit).

You'll find that you usually get very good support for XFS issues & questions
related to near-current mainline kernels.  But people who can spend time
& effort supporting free distros containing custom codebases are going
to be few & far between.

The closer you get to mainline, the more willing & able the developers
will be to help you out.  The further you get into custom distro kernels,
the more it becomes the responsibility of that distro - CentOS, in your case,
and they pretty explicitly tell you what you can expect for support from
them.

I'm not trying to be flippant or glib or antagonistic here, that's just
the way things are structured; you chose CentOS, and "CentOS is designed for
people who need an enterprise class OS without the cost or support of
the prominent North American Enterprise Linux vendor."

>>> Kernel versions are w.x.y or w.x.y.z.
>>
>> ^Upstream.
> 
> "Mainline".  Which was not my choice of term.

(Ok, mainline; I was just differentiating between RHEL & Linux.)

-Eric


> Cheers,
> -- jra
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-07-29 17:06 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-26  7:23 understanding speculative preallocation jbr
2013-07-26 11:50 ` Dave Chinner
2013-07-26 17:40   ` Jason Rosenberg
2013-07-26 19:27     ` Stan Hoeppner
2013-07-26 19:43       ` A short digression on FOSS (Re: understanding speculative preallocation) Jay Ashworth
2013-07-27  3:52         ` Stan Hoeppner
2013-07-27 21:00           ` Jay Ashworth
2013-07-28  1:38             ` aurfalien
2013-07-28  1:50               ` Jay Ashworth
2013-07-28  2:08                 ` aurfalien
2013-07-28  2:21                   ` Jay Ashworth
2013-07-28  5:09                     ` Purpose of the XFS list -- was: " Stan Hoeppner
2013-07-28 15:45                       ` Jay Ashworth
2013-08-14 17:01                         ` Emmanuel Florac
2013-07-28  7:18                     ` Stefan Ring
2013-07-28 15:48                       ` Jay Ashworth
2013-07-29  0:02                       ` Dave Chinner
2013-07-29  0:06                         ` Jay Ashworth
2013-07-29  2:41                           ` Dave Chinner
2013-07-29  3:12                             ` Eric Sandeen
2013-07-29  4:11                               ` Stan Hoeppner
2013-07-29 14:33                                 ` Jay Ashworth
2013-07-29 15:25                                   ` Dave Howorth
2013-07-29  3:38                             ` Keith Keller
2013-07-29  4:32                               ` Eric Sandeen
2013-07-29  4:57                                 ` Keith Keller
2013-07-29 13:38                                   ` Eric Sandeen
2013-07-29 18:15                                     ` Keith Keller
2013-07-29 14:24                             ` Jay Ashworth
2013-07-29 14:36                               ` Jay Ashworth
2013-07-29 14:57                               ` Eric Sandeen
2013-07-29 15:30                                 ` Jay Ashworth
2013-07-29 17:05                                   ` Eric Sandeen [this message]
2013-07-29  0:00                     ` Dave Chinner
2013-07-28  5:15             ` Michael L. Semon
2013-07-26 20:38       ` understanding speculative preallocation Jason Rosenberg
2013-07-26 20:50         ` Ben Myers
2013-07-26 21:04           ` Jason Rosenberg
2013-07-26 21:11             ` Jason Rosenberg
2013-07-26 21:42               ` Ben Myers
2013-07-27  1:30               ` Dave Chinner
2013-07-28  2:19                 ` Jason Rosenberg
2013-07-29  0:04                   ` Dave Chinner
2013-07-26 21:45         ` Eric Sandeen
2013-07-27  4:26       ` Keith Keller
2013-07-27  1:26     ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F6A0F3.8030604@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=jra@baylink.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox