[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: Fedora and the System Administrator -- I'm probably distracting people here, but ...
- From: "Bryan J. Smith" <b j smith ieee org>
- To: "Michael K. Johnson" <johnsonm redhat com>
- Cc: fedora-list redhat com
- Subject: Re: Fedora and the System Administrator -- I'm probably distracting people here, but ...
- Date: Fri, 03 Oct 2003 14:48:33 -0400 (EDT)
Quoting "Michael K. Johnson" <johnsonm redhat com>:
> First of all: It did not jump to "3.0". There's no ".0" in it. Just
> "Red Hat Enterprise Linux 3" with no decimal or decimal-ish part.
My ignorance, my apologies.
So from a product marketing standpoint, it is just "3". Will Red Hat maintain
an internal/technical designation for revisions at least? E.g., 3.x???
I know the industry has this "dot-fobia" right now, but I like it _much_better_
than the whole "service pack" nomenclature. But tag it as you will. ;-ppp
> There are lots of changes. I think the more interesting questions
> would probably be what *hasn't* changed. Yes, NPTL is in.
Okay, that would explain the move to 3. I just miss those "good old days" when
I could could on the major version to stick with the same GLibC/GCC. I guess
that's what we now have in a single 18 month RHEL release, instead of 3 x 6
month RHL releases.
> If I tried to present the new features here I'd miss lots of them,
> even in my area of the kernel.
Understood. I think NPTL says a lot.
> I know that our sales force has the capability to talk about the
> features that have been added.
As always. ;-ppp
At least you don't send out your sales people and have them tell people that
they are "engineers." That's the #1 reason why even MCSEs dislike Microsoft.
> We're not going to avoid deploying new technology in Fedora just
> because you want to be able to build Fedora packages on RHEL. :-)
No more than you have done with Rawhide in the past, I know. But if I was Red
Hat management, I'd have to believe that by seeing 3rd party packages built to
my commercial product, I'd sell more commercial product. But they know
Which brings me to the culmination of a point I wanted to bring up before.
Does Red Hat see either ...
1) Two tags in Fedora -- one for Fedora, one [subset] for RHEL, or
2) Expecting community software projects to release a RHEL version
themselves, all while working with Fedora to release one for Fedora
I'm not trying to tell Red Hat what to do. After all, unlike Debian, you have
to support what you ship. So that means you're limited in what you can ship.
But I think #1 might be in its best interest, from a commercial perspective, to
provide a framework for this, to help sell your own RHEL products.
Because the problem with #2 is why people prefer Debian, and might not move to
Fedora en masse. #2 still means there is no community built around RHEL, which
means there is less incentive for the regular user to purchase it (or worse,
purchase SuSE Linux Personal/Professional instead).
If Red Hat does not consider this a market consideration, then I'd understand
(and I'm _not_ deamonizing Red Hat here). But I think other people have hit on
it. There needs to be a new "consumer" between the new Fedora "enthusiast" and
the RHEL "business" products.
So I've suggested that Red Hat consider help supporting a "tag" in Fedora, even
if it is a subset, of popular packages for its current RHEL release. That
would help Red Hat sell more RHEL WS/ES boxes. I leave it up to Red Hat to
decide if the costs of doing such are worth the potential increase in sales of
> If you look historically, the changes have tended to be small and
> manageable most of the time.
Right. As long as GLibC/GCC doesn't change, most things are accomodated. And
given that RHEL release are supposed to be 18 months apart, this is basically
what we had with the 3 x 6 month model of X.0 - X.2+.
> But let's take a concrete example of a major change. Let's say, for
> example, that RPM was changed so that you didn't have to list patches
> in one place any apply them in another; that you could say something
> %patch(foo-1.0-fixblah.patch) -p1
> in the prep section, and RPM wouldn't need a separate
> Patch0 foo=1.0-fixblah.patch
> line to know that the foo-1.0-fixblah.patch file existed and should
> be packaged.
> We wouldn't wait until a version of RHEL had that capability to start
> to use in in Fedora packages. If you wanted to rebuild the modified
> packages, you'd have to modify the spec files.
And I understand that.
But I also see that preventing people from buying RHEL, because it is no
different than what they had before. Now Red Hat could choose to hope that
another party picks up that end, or the Fedora community themselves. But given
why Fedora now exists, I want to believe Red Hat might consider "unofficially"
(i.e. unsupported) maintaining its own "tag sub-set" of the Fedora repositories
that easily build on their current version of RHEL.
Do you see where I'm coming from, just a recommendation?
> fedora-devel-list is where we'll be talking about any such changes.
FYI, I promise to avoid posting discussions like the above, unless I'm directly
supporting a package myself (not likely anytime soon -- as I'm too busy "cert
whoring" until probably mid next year, long story ;-).
> And it's simply not a promise we're making.
Oh, I guess I should clarify. I'm not expecting Red Hat promise such. It's
not feasible for Red Hat to do so.
If there is one thing I _know_ of Red Hat, they make small promises and deliver
_more_ than most people expect. So that's all I'm hoping for here.
> It might work on a technical basis, opportunisticaily, though if
> you replace RHEL3 apps with hand-built ones you'll want to check
> your SLA wording to see what it does to your support level.
The idea here is to _not_ replace anything that RHEL ships. Only _augment_
what is in it. That would make SLA a nightmare for Red Hat, and be self-
hindering to support such an effort.
Which is why I'm calling it a "tag subset."
So if that means you can't run the latest GNOME, or a GNOME app that requires
the latest GNOME, that's totally understandable. I think I made that known in
the other post.
Bryan J. Smith, E.I. mailto:b j smith ieee org http://thebs.org
There is no greater ignorance than the popular American environ-
mental movement, which focuses on the most useless details. Be it
recycling the world's most renewable resource or refusal to use
proven CFC insulation on launch vehicles, no lives will be spared
in the further pursuit of, ironically, harming the environment.
[Date Prev][Date Next] [Thread Prev][Thread Next]