Fedora Linux

[cbbrowne-HInyCGIudOg at public.gmane.org]

> > Lloyd Budd wrote:
> >> > And there also lies another challenge; why should someone experiment
> >> with contributing to Fedora which might fall as quickly as it rises
> >> when they could join an already-strong network of Debian packagers?
> >> Fedora needs to draw from that same set of people.
> >>
> >> Debian is still too hard for many.
> >
> > This should influence people to move from the network of Debian
> > packagers to Fedora precisely why?

> Errr, you mention "join [...] Debian".  I was not suggesting that this
> will win anyone away from Debian.  Retention of *useful* RH Users is
> what is important.  If no one is skilled and wants to be skilled on
> RH, then RH will fail.


> > Furthermore, this should influence people who _are_ capable of building
> > packages to prefer the paucity of package management tools for Fedora
> > precisely why?  (e.g. - debconf, lintian, fakeroot, debhelper, debmake,
> > cvs-buildpackage, ...)
> See initial errr.

> Speaking of package management and becoming a packager, if that it is
> part of one's motivation "the opinion" seems to be that Gentoo is
> easier to learn and maintain packages for, but still has some way to
> go to be as 'flawless' as Debian.

> It is interesting though that the comments back from that article that
> I provided a link to
> <http://www.linuxjournal.com/article.php?sid=7169> seemed most
> concerned that Fedora is not giving enough focus on making their pkg
> mngmnt Debian enough.

Right.  

I have LONG argued that a _severe_ problem in the "RPM world" is that
they haven't had NEARLY enough tools publicly available to help out with
the "software engineering" side of managing distributions.  

Too much of the management of Red Hat Linux was internal to RHAT
engineers; ditto for all the others.

>> And as near as I can tell, the people to whom Debian is "too hard"
>> are those that wind up with Red Hat systems that are questionably
>> configured and susceptible to rootkitting.  They may have won, in the
>> process, a system that they simply can't manage.

> FUD.  Red Hat's available system administration and more-so Enterprise
> Administration Tools are at least as good as Debian's.

They ALL include the very same webmin and cfengine tool sets.  They have
the SAME nagios tool set.  I'm afraid I don't see the difference.

> >> I found http://www.linuxjournal.com/article.php?sid=7169 quite
> >> interesting, but if it is as the author suggests then I fear an
> >> outcome as you predict.  The best thing that Fedora could do is for
> >> the core to stay snuggled up to the RH releases.  This homogeneity
> >> would encourage the most likely users of Fedora to contribute to the
> >> community.
> >
> > For it to stay thus "snuggled" requires that RHAT be highly
> > interventionist in their management of it, which would discourage
> > outsiders from participating, and prevent it from growing into a
> > 'community' effort.

> Well not if they estable a few releases/branches -- this is one of the
> successes of Debian.  Also, I am referring to the core.

You are missing the "political process" point.

In order for "Fedora Linux" to be tightly tied to whatever RHAT is
releasing requires that it be kept, _politically_, on a very short leash
that is pulled by Red Hat Software.

If it is kept on such a short leash, then that will discourage public
participation, which will prevent it from thriving as a "community
effort."

A policy that makes it an "experimental" version of RHAT's production
releases prevents it from being "community driven."  You can't have both
things within the same political process.
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://www3.sympatico.ca/cbbrowne/nonrdbms.html
"Problem  solving under linux  has never  been the  circus that  it is
under AIX."  -- Pete Ehlke in comp.unix.aix
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml