further package removals/potential package removals

[Kyrre Ness Sjobak]

søn, 23.01.2005 kl. 03.12 skrev Michael A. Peters:
> On 01/22/2005 12:11:32 PM, Jeff Spaleta wrote:
> 
> > 
> > If there is serious interest in slimming Core down.. then a decision
> > has to be made to define a reference usage case or two so we can get
> > past personal preference and make decisions based on the design needs
> > of the usage case goal.  If a reference usage case for Core is  
> > suppose
> > to be a developer oriented workspace thats going to impact the
> > decisions as to what is important to include. If a reference usage
> > case for Core is suppose to be a desktop for the average human,  
> > that's
> > going to impact the decisions in very different ways. If Core is
> > suppose to provide both.. well guess what.. Core will continue to be
> > 4+ CD images.
> 
> I definitely want to see Fedora Core shrink.
> I want to see Linux on the Desktop really take off - as in someday see  
> 20% or more marketshare. That only is going to happen with OEM's.
> 
> Other than Apple users, most people I know use the version of the OS  
> that their PC ships with - they don't bother to buy updates let alone  
> other operating systems. Corporate desktop is different, there they run  
> whatever IT trusts - which also often is not latest.
> 
> Anyway - to get Fedora on OEM's it has to be smaller because up the  
> cost of support - it's cheaper to train support staff for a smaller  
> base of software.
> 
> IMHO it should be easy for an OEM to start with a smaller base, rip  
> either KDE or GNOME out (depending upon what their staff is trained  
> in), rip the dev tools out, add some patented stuff (like GStreamer  
> plugins from fluendo or whoever) and have well under a gig of packages.
> 
> They can do that now, but it is harder because there is a lot more to  
> sift through.
> 

Another reason to shrink core, is that a smaller core will make sure
each package will get more developer time => higher quality of the
"main" stuff. And by moving the more obscure packages into extras, that
will make it possible for upstream developers themselves to actually
take controll of their own packages (=> higher quality).