2:35 p.m.
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
You can view the list of new packages since FC3 (sorted by package size)
at http://people.redhat.com/sopwith/new-packages.txt
FYI,
-- Elliot
2:54 p.m.
Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
You can view the list of new packages since FC3 (sorted by package size)
at http://people.redhat.com/sopwith/new-packages.txt
FYI,
-- Elliot
It would be a shame to lose gnome-games, every computer needs easy
access to solitaire.
How about dropping some of the random documentation rpms we keep around,
they don't follow a pattern anyway (ie we have exim-doc but no
postfix-doc, we have python-doc but no php-doc or perl-doc)
exim-doc 3.2m
python-docs 2.4m
python-twisted-docs 6.4m
postgresql-docs 4.6m
(there are a couple more)
Or even better drop tetex-doc 51M (im pretty sure the php manual package
got dropped long before it got that big)
-josh
3:04 p.m.
On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote:
Elliot Lee wrote:
>Hi all,
>
>Here's a heads up that we need to get rid of about 300M of packages to
>make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
>xemacs, cfengine, and all the games are leading candidates. We also may
>try to start removing stuff from Core in hopes that it will appear in
>Extras if someone cares about it.
Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"?
If packages were properly distributed among the CD's, one didn't need to
download all images. I admit I am a bit biased since I use XEmacs
regularly. I you list I see many java-related packages. Why not bundle
them into a separate CD? Another option would be to retain 4 images and
create additional images with extras.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
3:16 p.m.
On Mon, 21 Feb 2005, [ISO-8859-1] G�rard Milmeister wrote:
On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote:
> Elliot Lee wrote:
>
> >Hi all,
> >
> >Here's a heads up that we need to get rid of about 300M of packages to
> >make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
> >xemacs, cfengine, and all the games are leading candidates. We also may
> >try to start removing stuff from Core in hopes that it will appear in
> >Extras if someone cares about it.
Why limit FC4 to 4 CD's? Is it out fear that someone will cry "bloat"?
If we add another CD:
The companies that create CD sets for magazines or resale will see
their media costs go up by 25%.
The mirror sites with limited bandwidth and disk space will be
likely to stop mirroring Fedora Core.
The users who don't want to download and burn another CD will go
elsewhere.
If packages were properly distributed among the CD's, one
didn't need to
download all images. I admit I am a bit biased since I use XEmacs
regularly. I you list I see many java-related packages. Why not bundle
them into a separate CD?
Because we don't have the infrastructure/tools to do it properly.
Another option would be to retain 4 images and create additional
images
with extras.
Which means removing things from Core so we can put them in Extras...
-- Elliot
3:23 p.m.
On Mon, 2005-02-21 at 16:16 -0500, Elliot Lee wrote:
>
> Why limit FC4 to 4 CD's? Is it out fear that someone will cry
"bloat"?
If we add another CD:
The companies that create CD sets for magazines or resale will see
their media costs go up by 25%.
The mirror sites with limited bandwidth and disk space will be
likely to stop mirroring Fedora Core.
The users who don't want to download and burn another CD will go
elsewhere.
> If packages were properly distributed among the CD's, one didn't need to
> download all images. I admit I am a bit biased since I use XEmacs
> regularly. I you list I see many java-related packages. Why not bundle
> them into a separate CD?
Because we don't have the infrastructure/tools to do it properly.
> Another option would be to retain 4 images and create additional images
> with extras.
Which means removing things from Core so we can put them in Extras...
-- Elliot
Ok, I understand your reasoning. However I think moving packages from
Core to Extras can only be done, if access to Extras is immediate after
Core has been installed. Which means: no manual setting up of repository
files in /etc/yum.repos.d or /etc/apt. And a usable graphical package
manager like synaptic instead of the braindead system-config-packages.
As I said, a set of optional Extras CDs, downloadable from the same
location as the Core CDs would be a benefit.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
3:29 p.m.
Gérard Milmeister (gemi(a)bluewin.ch) said:
Ok, I understand your reasoning. However I think moving packages
from
Core to Extras can only be done, if access to Extras is immediate after
Core has been installed. Which means: no manual setting up of repository
files in /etc/yum.repos.d or /etc/apt.
Planned.
And a usable graphical package
manager like synaptic instead of the braindead system-config-packages.
As I said, a set of optional Extras CDs, downloadable from the same
location as the Core CDs would be a benefit.
https://www.redhat.com/archives/fedora-config-list/2005-January/msg00017....
Bill
3:53 p.m.
Ok, I understand your reasoning. However I think moving packages
from
Core to Extras can only be done, if access to Extras is immediate after
Core has been installed. Which means: no manual setting up of repository
files in /etc/yum.repos.d or /etc/apt. And a usable graphical package
manager like synaptic instead of the braindead system-config-packages.
As I said, a set of optional Extras CDs, downloadable from the same
location as the Core CDs would be a benefit.
1. extras repo should ship, enabled, in yum.conf for fc4, I think.
2. system-config-packages is going away for pup - hopefully in fc4 - but
let's be clear about something - sometimes we have to take iterative
steps to get somewhere. We can't do everything all at once.
-sv
4:48 p.m.
* seth vidal <skvidal(a)phy.duke.edu> [2005-02-21 16:55]:
> Ok, I understand your reasoning. However I think moving packages from
> Core to Extras can only be done, if access to Extras is immediate after
> Core has been installed. Which means: no manual setting up of repository
> files in /etc/yum.repos.d or /etc/apt. And a usable graphical package
> manager like synaptic instead of the braindead system-config-packages.
> As I said, a set of optional Extras CDs, downloadable from the same
> location as the Core CDs would be a benefit.
1. extras repo should ship, enabled, in yum.conf for fc4, I think.
2. system-config-packages is going away for pup - hopefully in fc4 - but
let's be clear about something - sometimes we have to take iterative
steps to get somewhere. We can't do everything all at once.
I agree completely. Moving things to Extras without 1. being a given is
premature IMO.
Andrew
3:55 p.m.
On Feb 21, 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
On Mon, 21 Feb 2005, [ISO-8859-1] G�rard Milmeister wrote:
> On Mon, 2005-02-21 at 13:54 -0700, Joshua Eichorn wrote:
> > Elliot Lee wrote:
> > >Here's a heads up that we need to get rid of about
300M of packages to
> > >make sure that FC4 continues to fit on 4 CD's.
> Why limit FC4 to 4 CD's? Is it out fear that someone will cry
"bloat"?
If we add another CD:
The companies that create CD sets for magazines or resale will see
their media costs go up by 25%.
How about 1 DVD? The binaries for FC1 up to FC3 fit in that, and I
very much doubt FC4's wouldn't. CDs are *so* small...
People didn't have so much trouble installing GNU/Linux distros from
40+ floppies before I started playing with GNU/Linux myself. Why are
4 or 5 CDs such a big deal?
The mirror sites with limited bandwidth and disk space will be
likely to stop mirroring Fedora Core.
If they didn't have trouble mirroring the FC2 DVD images, that include
SRPMS, or even mirroring the FC2 i386 and x86_64 CD and DVD isos,
with a total of 4 copies of every SRPM (not counting the exploded RPMS
and SRPMS trees), why would they have trouble with an additional GiB
or so now that we don't include the SRPMS in the DVD images any more?
Which means removing things from Core so we can put them in Extras...
How about moving Gnome and KDE to extras? That would save a lot of
space. Then the same clueless users that would be driven away by the
additional half-CD would think: hey, cool, this distro is a single CD
(or maybe two), why not give it a try?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
4:14 p.m.
Alexandre Oliva wrote:
How about 1 DVD? The binaries for FC1 up to FC3 fit in that,
and I very much doubt FC4's wouldn't. CDs are *so* small...
Few folks have DVD burners...
How about moving Gnome and KDE to extras? That would save a
lot of space. Then the same clueless users that would be
driven away by the additional half-CD would think: hey, cool,
this distro is a single CD (or maybe two), why not give it a
try?
That's what I've done--reduced FC to one CD. This makes it easy
for folks to download & hand out. I got tired of burning 3+ CDs
each time I wanted to spread a copy.
It still has gnome, xfce, firefox, gimp, abiword, etc., plus
some FreshRPMS/Dag packages (inkscape, scribus, mplayer, ...).
All -devel packages, KDE, OOo, & developer tools are removed
from the CD, but in the repository. There's a DVD version that
has everything though.
I'm not suggesting Fedora do this... But perhaps Fedora could
move the -devel & devel tools to the last CDs so people
wouldn't have to download as large of a set. This would make it
easier for book/magazine publishers too. Developers know yum...
-Jeff
ftp://ftp.blagblagblag.org/pub/BLAG/linux/30000/en/iso/
3:58 p.m.
On Feb 21, 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
The mirror sites with limited bandwidth and disk space will be
likely to stop mirroring Fedora Core.
And as Fedora shrinks in out-of-the-box usability because more and
more important features will be pushed to Extras, that won't be
available from CD vendors nor downloadable in the form of CDs, they
might even stop mirroring Fedora Core since nobody will want it.
Or are Extras going to actually be made part of the distro for real,
as opposed to a dump of packages that we can't fit in 4 CDs, or don't
want to support, or both?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
4:05 p.m.
On Feb 21, 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
The companies that create CD sets for magazines or resale will see
their media costs go up by 25%.
Remember the Wide Open Magazine, that included Fedora Core 1, somehow
fit into 3 CDs instead of the 4 official CDs from the FC1 official
release? Why couldn't companies that create CD sets for magazines or
resale do something similar? We could surely amend the trademark
guidelines to enable anyone to distribute slim versions of fedora
containing a subset of the binary packages that we ship in the
official CDs, imposing a requirement such as that a list of the
omitted packages be made prominently visible.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
4:53 p.m.
* Elliot Lee <sopwith(a)redhat.com> [2005-02-21 16:18]:
The mirror sites with limited bandwidth and disk space will be
likely to stop mirroring Fedora Core.
What about Fedora Extras? If it's just as "first class" as Core is,
we'll
want just as many mirrors there, no? People don't want things moved to
Extras if they're going to be (pseudo- or not) second-class packages and
that includes mirroring and ease of installation at initial install time
IMHO.
Andrew
4:54 p.m.
On Mon, 2005-02-21 at 17:53 -0500, Andrew Overholt wrote:
* Elliot Lee <sopwith(a)redhat.com> [2005-02-21 16:18]:
>
> The mirror sites with limited bandwidth and disk space will be
> likely to stop mirroring Fedora Core.
What about Fedora Extras? If it's just as "first class" as Core is,
we'll
want just as many mirrors there, no? People don't want things moved to
Extras if they're going to be (pseudo- or not) second-class packages and
that includes mirroring and ease of installation at initial install time
IMHO.
no isos for extras.
that's the difference, by a long shot.
-sv
3:06 p.m.
On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn <josh(a)bluga.net> wrote:
It would be a shame to lose gnome-games, every computer needs easy
access to solitaire.
why? so office workers can be less productive?
How about dropping some of the random documentation rpms we keep
around,
they don't follow a pattern anyway (ie we have exim-doc but no
postfix-doc, we have python-doc but no php-doc or perl-doc)
Let me point out a hidden constraint for this fc4 timescale. You have
to think in terms of 'srpms' subpackages can only be dropped..
subpackages can not be moved out of Core into Extras. The -doc
packages you describe are actualy subpackages built from the same srpm
as the related runtime package. Its inappropriate to drop
documentation completely.. and since they are subpackages from the
same srpm you can't move them across the Core/Extras boundary. So
really the packages you suggest are non-starters.. unless package can
be re-engineered so that the docs are built from their own seperate
srpms.
-jef
3:11 p.m.
Jeff Spaleta wrote:
On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn
<josh(a)bluga.net> wrote:
>It would be a shame to lose gnome-games, every computer needs easy
>access to solitaire.
>
>
why? so office workers can be less productive?
Because every graphical OS since 1984 has shipped with it, and it has
more users then most other applications.
>How about dropping some of the random documentation rpms we keep
around,
>they don't follow a pattern anyway (ie we have exim-doc but no
>postfix-doc, we have python-doc but no php-doc or perl-doc)
>
>
Let me point out a hidden constraint for this fc4 timescale. You have
to think in terms of 'srpms' subpackages can only be dropped..
subpackages can not be moved out of Core into Extras. The -doc
packages you describe are actualy subpackages built from the same srpm
as the related runtime package. Its inappropriate to drop
documentation completely.. and since they are subpackages from the
same srpm you can't move them across the Core/Extras boundary. So
really the packages you suggest are non-starters.. unless package can
be re-engineered so that the docs are built from their own seperate
srpms.
We have dropped other large doc rpms in the past, its all the web
anyway. I'm not saying we can drop all the docs, but the docs for
programming languages would be an easy drop and would mesh well with
what has happened in the past (dropping php-manual between rh8-9 for
example)
-jef
-josh
3:29 p.m.
On Mon, 21 Feb 2005, Jeff Spaleta wrote:
On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn
<josh(a)bluga.net> wrote:
> How about dropping some of the random documentation rpms we keep around,
> they don't follow a pattern anyway (ie we have exim-doc but no
> postfix-doc, we have python-doc but no php-doc or perl-doc)
Let me point out a hidden constraint for this fc4 timescale. You have
to think in terms of 'srpms' subpackages can only be dropped..
subpackages can not be moved out of Core into Extras. The -doc
packages you describe are actualy subpackages built from the same srpm
as the related runtime package. Its inappropriate to drop
documentation completely.. and since they are subpackages from the
same srpm you can't move them across the Core/Extras boundary. So
really the packages you suggest are non-starters.. unless package can
be re-engineered so that the docs are built from their own seperate
srpms.
What you could do is have a subset of packages in the repository, but not
on the CD. I don't think there is a rule that everything in Fedora Core
has to be on the CD or that the repository should equal the CD content.
RHEL already does this and has extra packages (mostly -devel stuff) in a
special repository. You could release the CD with less packages and
release the extra packages in the updates repository at the same time. (I
like that more than having yet another repository)
Just a thought.
-- dag wieers, dag(a)wieers.com, http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]
4:10 p.m.
On Mon, Feb 21, 2005 at 04:06:27PM -0500, Jeff Spaleta wrote:
On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn
<josh(a)bluga.net> wrote:
> It would be a shame to lose gnome-games, every computer needs easy
> access to solitaire.
why? so office workers can be less productive?
Many people first used Linux because "the solitaire was better". Seriously.
11:04 a.m.
On Mon, Feb 21, 2005 at 04:06:27PM -0500, Jeff Spaleta wrote:
On Mon, 21 Feb 2005 13:54:20 -0700, Joshua Eichorn
<josh(a)bluga.net> wrote:
> It would be a shame to lose gnome-games, every computer needs easy
> access to solitaire.
why? so office workers can be less productive?
I'll tackle this one. There's very few other applications provided by an
operating system that are both fun/engaging, and a good learning tool for
most of the basic actions that a mouse requires.
After seeing my 73-year-old mother go from "what do you mean, drag it?" to
double clicking like she was born at a computer in a couple of days of
playing solitaire, I'm sold on it: it's an ingenious tool for teaching how
to use the mouse that doesn't bore the hell out of the student.
Does Fedora need all of gnome-games? No, that's just silly. But a few basic
games which emphasize the range of mouse interactions with the system widget
set should be there, IMHO.
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
3:19 p.m.
Le lundi 21 février 2005 à 13:54 -0700, Joshua Eichorn a écrit :
How about dropping some of the random documentation rpms we keep
around,
they don't follow a pattern anyway (ie we have exim-doc but no
postfix-doc, we have python-doc but no php-doc or perl-doc)
I am not agree. If we provide exim, we provide *all* exim.
3:30 p.m.
Féliciano Matias wrote:
Le lundi 21 février 2005 à 13:54 -0700, Joshua Eichorn a écrit :
>How about dropping some of the random documentation rpms we keep around,
>they don't follow a pattern anyway (ie we have exim-doc but no
>postfix-doc, we have python-doc but no php-doc or perl-doc)
>
>
>
I am not agree. If we provide exim, we provide *all* exim.
So we should drop packages used by high % of fedora users for the doc
for tetex or exim which are used by a very small % users, and which are
also available online?
And we should be held hostage in the future by any project that decides
that bundling there docs (no matter how big) with the program is a good
idea.
I would also like to point out, the exim docs are a good example of
general space waste on docs packages, it contains html, pdf, ps, and
texinfo docs so the same content 4 times (so im guessing just with some
new configure flags could take 1/4 the space).
-josh
5:48 p.m.
Le lundi 21 février 2005 à 14:30 -0700, Joshua Eichorn a écrit :
So we should drop packages used by high % of fedora users for the doc
for tetex or exim which are used by a very small % users, and which are
also available online?
Move exim to extra.
And we should be held hostage in the future by any project that
decides
that bundling there docs (no matter how big) with the program is a good
idea.
I would also like to point out, the exim docs are a good example of
general space waste on docs packages, it contains html, pdf, ps, and
texinfo docs so the same content 4 times (so im guessing just with some
new configure flags could take 1/4 the space).
Package only one format.
7:27 a.m.
On Mon, 21 Feb 2005 14:30:14 -0700, Joshua Eichorn <josh(a)bluga.net> wrote:
I would also like to point out, the exim docs are a good example of
general space waste on docs packages, it contains html, pdf, ps, and
texinfo docs so the same content 4 times (so im guessing just with some
new configure flags could take 1/4 the space).
-josh
The thing I hate most about modern *nix is the proliferation of different
documation formats. In the good old days we had man pages. Then Sun came
along and introduced it's own system that was graphical and all but was
really worse than man pages. Then there's info and docbook and programs
that have HTML documentation and PDF documentation, and...
This nonsense caused about ten minutes of extra downtime for a production
system when I did something dumb that overwrote the module utilities: the
2.6 module utilities source doesn't just have man page source in it, but
it compiles the pages out of docbook source. Well, this is RHEL 3 and
you wouldn't expect it to have packages that work, so to get "make
install" to work I had to smash the Makefile so it wouldn't try to compile
them.
10:41 a.m.
On 02/22/2005 05:27:49 AM, Paul A. Houle wrote:
The thing I hate most about modern *nix is the proliferation of
different documation formats.
Yes.
I think every command expected to be run from the cli should have a man
page. And not a man page that says "please see the info page"
Every gui app should have documentation in scrollkeeper.
That's my opinion, but whatever is chosen - it should be chosen and
stuck with, and projects that use different documentation methods
should have bugs files against them so that document writers can know
what needs to be done.
Huge documentation such as the php manual etc. obviously are not a man
page, and are not a gui app and thus not a scrollkeeper issue - for
those, texinfo has a high value because they can be exported from
texinfo to many types of documentation as needed (pdf, html, etc.)
following the documentation guidelines could (should?) even be imposed
as a requirement for a new package being excepted in Fedora Extras.
--
Michael A. Peters
http://mpeters.us/
4:13 p.m.
On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> postfix-doc, we have python-doc but no php-doc or perl-doc)
>
I am not agree. If we provide exim, we provide *all* exim.
Shove exim in extras then. Lets have one of everything (including databases)
in the base except where the are real divides (Gnome/KDE)
4:17 p.m.
On Mon, 2005-02-21 at 17:13 -0500, Alan Cox wrote:
Shove exim in extras then. Lets have one of everything (including
databases)
in the base except where the are real divides (Gnome/KDE)
I'd rather put sendmail and/or postfix in Extras instead. There's a
reason Debian has the default it does.
--
dwmw2
10 p.m.
David Woodhouse wrote:
On Mon, 2005-02-21 at 17:13 -0500, Alan Cox wrote:
>Shove exim in extras then. Lets have one of everything (including databases)
>in the base except where the are real divides (Gnome/KDE)
>
>
I'd rather put sendmail and/or postfix in Extras instead. There's a
reason Debian has the default it does.
I dont want to make this a sendmail/postfix/exim/other email server war,
but I think that is a little too much...
Just because one distribution ships exim/koffice/put your favourite app
here as default , it doesnt necessarily mean that's the right choice for
all distributions.
IMHO , Fedora should ship only one mail server/one app (maybe chosen by
% of users?) in the main CDs.
My suggestion: in FC4 , ship only one server of each type (no
alternatives) and put them on an alternatives repository (after all,
most users that require something different
already know how to use yum or apt). Then , for the next Fedora releases
, it would be interesting if anaconda was hacked to be able to use extra
cds. This way , it would be possible
to use an "alternatives" cd during install , for example.
As for the space spent on mirrors , we could always use jigdo ;)
--
Pedro Macedo
10:06 p.m.
IMHO , Fedora should ship only one mail server/one app (maybe chosen
by
% of users?) in the main CDs.
My suggestion: in FC4 , ship only one server of each type (no
alternatives) and put them on an alternatives repository (after all,
most users that require something different
already know how to use yum or apt). Then , for the next Fedora releases
, it would be interesting if anaconda was hacked to be able to use extra
cds. This way , it would be possible
to use an "alternatives" cd during install , for example.
anaconda using multiple repos is in the plans for fc5.
-sv
12:24 p.m.
On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote:
I dont want to make this a sendmail/postfix/exim/other email server
war,
but I think that is a little too much...
Just because one distribution ships exim/koffice/put your favourite app
here as default , it doesnt necessarily mean that's the right choice for
all distributions.
That's true, but in this case Debian happens to have it right. We should
do what Debian does here because they're _right_, not just because
they're doing it and we have to follow.
IMHO , Fedora should ship only one mail server/one app (maybe chosen
by
% of users?) in the main CDs.
Whatever we ship as default will have the largest percentage of users --
if it worked like that we'd never make any progress. If we switch the
default, people who already have experience of a mail server can always
switch to whatever they prefer, while the newbies get something which is
well-documented, versatile and easy to work with.
--
dwmw2
6:40 a.m.
On Tue, 2005-02-22 at 18:24 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote:
>I dont want to make this a sendmail/postfix/exim/other email server war,
>but I think that is a little too much...
>Just because one distribution ships exim/koffice/put your favourite app
>here as default , it doesnt necessarily mean that's the right choice for
>all distributions.
That's true, but in this case Debian happens to have it right. We should
do what Debian does here because they're _right_, not just because
they're doing it and we have to follow.
In that case I would be curious about the reasons which make exim more
"right" than say postfix, otherwise it's only an "everyone wants his
pet
MTA" thing.
Nils
--
Nils Philippsen / Red Hat / nphilipp(a)redhat.com
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- B. Franklin, 1759
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
7:07 a.m.
On Thu, 2005-02-24 at 13:40 +0100, Nils Philippsen wrote:
In that case I would be curious about the reasons which make exim
more
"right" than say postfix, otherwise it's only an "everyone wants his
pet MTA" thing.
Exim and Postfix are way ahead of sendmail, which should probably be
dropped in FC5 when it's sane to start dropping packages to Extras; more
than that is somewhat subjective.
Both Postfix and Exim should remain, but it's just a question of which
is the default. I'd go for Exim -- it's very well documented, fully IPv6
capable, at least as easy for the newbie to configure as postfix is, and
seems to be far more versatile for those who want to go a little
further. We ship it ready to do SMTP AUTH and automatically use
SpamAssassin to reject mail at incoming SMTP time, for example, rather
than only feeding it to SA later when it's too late because we've
already accepted it.
Right now, Postfix scores some points back by being SE-enabled, but Exim
will catch up on that front very soon; probably before test 1 even.
Postfix loses points for the fact that the admins of freedesktop.org
were unable for months to persuade it to send mail to a domain whose
primary MX was IPv6-only. I don't know if it's fixed even now the open
relay thing has been fixed -- they put an explicit route in for me in
the end, I think. That's not something I'd want a Fedora newbie trying
to diagnose.
--
dwmw2
10:49 a.m.
>>>> "DW" == David Woodhouse
<dwmw2(a)infradead.org> writes:
DW> Both Postfix and Exim should remain, but it's just a question of
DW> which is the default.
Honestly I would prefer that neither is the default. Both have far too
much functionality for hosts which are not mail servers.
What's really needed is something tiny, optimized for a machine that
rarely sends mail, has a highly-available smarthost, and never
receives mail from the network:
Starts from xinetd on port 25 (localhost only).
Will queue if smarthost is unavailable.
Runs from cron to flush queue.
Submission interface is not setuid; it talks SMTP to smarthost or
localhost.
Nothing else.
Exim has a mode which is close, but it rejects the message if it can't
talk to the smarthost. Someone who really wants to run a mail server
can install one.
- J<
12:15 p.m.
On Thu, 2005-02-24 at 10:49 -0600, Jason L Tibbitts III wrote:
Exim has a mode which is close, but it rejects the message if it
can't
talk to the smarthost. Someone who really wants to run a mail server
can install one.
Either you want it capable of queueing, or you don't -- you can't have
both ;)
The SE Linux patches for Exim should result in a submission interface
which is not setuid even when you're using it as a real MTA so that it
can queue stuff up for the smarthost. If there are no local deliveries,
it doesn't need to be setuid.
--
dwmw2
3:24 p.m.
>>>> "DW" == David Woodhouse
<dwmw2(a)infradead.org> writes:
DW> Either you want it capable of queueing, or you don't -- you can't
DW> have both ;)
Well, uh, yeah. The point is that even Exim's restricted mode isn't a
good fit because it won't queue. But then I stated earlier that Exim
(along with Postfix) posses far more functionality than is necessary
(or safe) for the average machine.
I have used Exim exclusively for years, BTW. But it and the other
SMTP servers really are the wrong tools for the job here. Or, to be
more precise, they are far too much tool for the job.
- J<
3:39 p.m.
Le jeudi 24 février 2005 à 15:24 -0600, Jason L Tibbitts III a écrit :
>>>>> "DW" == David Woodhouse
<dwmw2(a)infradead.org> writes:
DW> Either you want it capable of queueing, or you don't -- you can't
DW> have both ;)
Well, uh, yeah. The point is that even Exim's restricted mode isn't a
good fit because it won't queue. But then I stated earlier that Exim
(along with Postfix) posses far more functionality than is necessary
(or safe) for the average machine.
You do know that postfix design is a common example in advanced security
CS courses right ?
Moreover postfix default conf mostly works as-is so there is little risk
of someone compromising the setup by adding scores of directives he does
not understand because the damn thing doesn't work and he only got an
outdated howto to work from.
Regards,
--
Nicolas Mailhot
4:50 p.m.
>>>> "NM" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
NM> You do know that postfix design is a common example in advanced
NM> security CS courses right ?
What on Earth does that have to do with anything? I'm sure advanced
race mechanics study Ferrari engines, but I don't need one to drive to
the store.
I guess what you're trying to say is that all of the extra stuff that
Postfix comes with is secure, so it doesn't hurt anything to have it
on the machine. That's something definitely contradicted by those
advanced security CS courses you speak of.
- J<
1:16 a.m.
Le jeudi 24 février 2005 à 16:50 -0600, Jason L Tibbitts III a écrit :
>>>>> "NM" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
NM> You do know that postfix design is a common example in advanced
NM> security CS courses right ?
What on Earth does that have to do with anything? I'm sure advanced
race mechanics study Ferrari engines, but I don't need one to drive to
the store.
I guess what you're trying to say is that all of the extra stuff that
Postfix comes with is secure, so it doesn't hurt anything to have it
on the machine. That's something definitely contradicted by those
advanced security CS courses you speak of.
I'd rather have a full-featured secure program than a small one full of
holes because it's never been widely deployed by people who care. If you
take a look a security advisories they are not limited to big software,
far from it.
Postfix is secure because
1. it's well coded and
2. its multiple-processes design make it very difficult for an error to
propagate enough to be exploited
3. it's deployed widely enough on big setups any exploit would come to
light quickly. This wouldn't be the case of a small desktop-only util.
Who's auditing linux desktop systems nowadays ?
Small is beautiful. But that's not the only security factor you know.
Regards,
--
Nicolas Mailhot
1:50 a.m.
>>>> "NM" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
NM> I'd rather have a full-featured secure program than a small one
NM> full of holes because it's never been widely deployed by people
NM> who care.
Who was advocating deploying something full of holes? Certainly not
me, as I haven't even suggested a program to use. In fact I'm not
sure if any program meeting the criteria exists; I was hoping that
someone would provide suggestions, but it seems that people would
rather argue.
Debian shipped ssmtp for this purpose, but it and its replacement seem
to have been abandoned (and it didn't queue, which the author admits
as a problem). I suspect OpenBSD has something, because they seem to
have the same ideas as I do about needless functionality in general.
(Hence openntpd instead of xntpd.)
- J<
1:09 p.m.
Jason L Tibbitts III writes:
Debian shipped ssmtp for this purpose, but it and its replacement
seem
to have been abandoned (and it didn't queue, which the author admits
as a problem). I suspect OpenBSD has something, because they seem to
have the same ideas as I do about needless functionality in general.
OpenBSD has sendmail...
Tet
8:01 a.m.
On Thu, 24 Feb 2005 16:50:55 -0600, Jason L Tibbitts III
<tibbs(a)math.uh.edu> wrote:
>>>>> "NM" == Nicolas Mailhot
<Nicolas.Mailhot(a)laPoste.net> writes:
NM> You do know that postfix design is a common example in advanced
NM> security CS courses right ?
What on Earth does that have to do with anything? I'm sure advanced
race mechanics study Ferrari engines, but I don't need one to drive to
the store.
I guess what you're trying to say is that all of the extra stuff that
Postfix comes with is secure, so it doesn't hurt anything to have it
on the machine. That's something definitely contradicted by those
advanced security CS courses you speak of.
Most real postfix installations aren't going to be qualified as secure by
the authors of postfix, because if you want to implement POP
authentication you need to install Cyrus SASL -- which is the kind of
"security" software that introduces two buffer overflows for every
security hole it plugs. Throw in an average virus filter
(see
http://news.com.com/Take+three+Antivirus+apps+could+spread+infection/2100...)
and spam filter and I know it can be cracked. If you made a homebrew
system, it's likely that nobody's going to spend the time to weaponize an
attack, but ship an integrated system with every copy of FC4 and it's
worth the effort.
8:02 a.m.
On Thu, Feb 24, 2005 at 01:40:00PM +0100, Nils Philippsen wrote:
On Tue, 2005-02-22 at 18:24 +0000, David Woodhouse wrote:
> On Tue, 2005-02-22 at 01:00 -0300, Pedro Fernandes Macedo wrote:
> >I dont want to make this a sendmail/postfix/exim/other email server war,
> >but I think that is a little too much...
> >Just because one distribution ships exim/koffice/put your favourite app
> >here as default , it doesnt necessarily mean that's the right choice for
> >all distributions.
>
> That's true, but in this case Debian happens to have it right. We should
> do what Debian does here because they're _right_, not just because
> they're doing it and we have to follow.
In that case I would be curious about the reasons which make exim more
"right" than say postfix, otherwise it's only an "everyone wants his
pet
MTA" thing.
The config file is more stable and the way they maintain the package
more longterm. That's what I heard.
greetings,
Florian La Roche
8:09 a.m.
On Thu, 2005-02-24 at 15:02 +0100, Florian La Roche wrote:
> In that case I would be curious about the reasons which make
exim more
> "right" than say postfix, otherwise it's only an "everyone wants
his pet
> MTA" thing.
The config file is more stable and the way they maintain the package
more longterm. That's what I heard.
Yeah -- Phil refuses to make changes like defaulting the header_sender
callout to using a _real_ reverse-path instead of the empty sender,
because it would change the behaviour for existing users. It's a pain at
times, but overall it makes sense. It means you can upgrade with a very
good expectation that nothing will break.
That reminds me -- Exim's SMTP callouts correctly use the null sender,
where I believe Postfix's do not. I've had to implement a workaround for
broken Postfix callouts for certain addresses which only ever _send_
mail and shouldn't receive it.
--
dwmw2
5:07 p.m.
On 02/21/2005 02:13:14 PM, Alan Cox wrote:
On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> > postfix-doc, we have python-doc but no php-doc or perl-doc)
> >
> I am not agree. If we provide exim, we provide *all* exim.
Shove exim in extras then. Lets have one of everything (including
databases)
in the base except where the are real divides (Gnome/KDE)
Yes - that is why Abiword, Gnumeric, Balsa should be in extras - even
though I personally prefer them to OO.o and Evolution, the vast
majority of users never install them - but go with OO.o and Evolution,
so until that changes, it does not need to be downloaded by the users.
There are probably plenty of other apps like those as well.
--
Michael A. Peters
http://mpeters.us/
4:19 a.m.
On Mon, 2005-02-21 at 23:07 +0000, Michael A. Peters wrote:
Yes - that is why Abiword, Gnumeric, Balsa should be in extras - even
though I personally prefer them to OO.o and Evolution, the vast
majority of users never install them - but go with OO.o and Evolution,
so until that changes, it does not need to be downloaded by the users.
As someone who uses Gnumeric I say toss it into extras. In fact toss
it, abiword, balsa and koffice into extras.
Why? Well, as far as I am aware, these packages aren't installed by
default anyway. You have to manually add them (either at install, or
after the fact). If this is the case, then assuming extras is made
easy to access, installing them later should be easy enough.
So dump them in extras and those that want them can get them there.
Rodd
8:13 p.m.
On Monday 21 February 2005 17:13, Alan Cox wrote:
On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> > postfix-doc, we have python-doc but no php-doc or perl-doc)
>
> I am not agree. If we provide exim, we provide *all* exim.
Shove exim in extras then. Lets have one of everything (including
databases) in the base except where the are real divides (Gnome/KDE)
As a KDE user,
I say shove KDE into extras.
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
8:30 p.m.
On Mon, 2005-02-21 at 21:13 -0500, Richard June wrote:
On Monday 21 February 2005 17:13, Alan Cox wrote:
> On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> > > postfix-doc, we have python-doc but no php-doc or perl-doc)
> >
> > I am not agree. If we provide exim, we provide *all* exim.
>
> Shove exim in extras then. Lets have one of everything (including
> databases) in the base except where the are real divides (Gnome/KDE)
As a KDE user, I say shove KDE into extras.
What about kdeedu weighing in at 23M and having it's own SRPM?
--
Dan Young <dan_young(a)parkrose.k12.or.us>
Parkrose School District
9:53 p.m.
[snip]
> As a KDE user, I say shove KDE into extras.
What about kdeedu weighing in at 23M and having it's own SRPM?
--
Dan Young <dan_young(a)parkrose.k12.or.us>
Parkrose School District
core, n : a central and often foundational part usually
distinct from the
enveloping part by a difference in nature.
Fedora core should be just that, *core* ideally I would like to see it down to
one or two CDs push dev stuff extras, push docs to extras push all the
alternatives to extras. why? because quite frankly that's what core is. so
by all means push all the alternative stuff to core. *but* also make it easy
to add stuff from extras.
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
7:20 a.m.
On Mon, 21 Feb 2005 22:53:26 -0500, Richard June
<rjune(a)bravegnuworld.com> wrote:
core, n : a central and often foundational part usually distinct
from the
enveloping part by a difference in nature.
How about we don't get caught up the text book imagery of the word
'core' . I can do you one better and quote the textbook definition of
the word 'fedora'.. and then cry about how fedora core isn't actually
the central and often foundational part of a man's wide brimmed HAT.
'Core' like 'Fedora' is just a silly name. Instead of a dictionary,
i refer you instead to the objective list spelled out so far for the
project:
Objectives of Fedora Core:
1. Create a COMPLETE general-purpose operating system with
capabilities equivalent to competing operating systems, built for and
by a community — those who not only consume, but also produce for the
good of other community members
-jef
8:15 a.m.
On Mon, Feb 21, 2005 at 05:13:14PM -0500, Alan Cox wrote:
On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> > postfix-doc, we have python-doc but no php-doc or perl-doc)
> >
> I am not agree. If we provide exim, we provide *all* exim.
Shove exim in extras then. Lets have one of everything (including databases)
in the base except where the are real divides (Gnome/KDE)
I think exim still has potential to become our future default MTA.
greetings,
Florian La Roche
10:45 a.m.
On 02/22/2005 06:15:41 AM, Florian La Roche wrote:
On Mon, Feb 21, 2005 at 05:13:14PM -0500, Alan Cox wrote:
> On Mon, Feb 21, 2005 at 10:19:48PM +0100, Féliciano Matias wrote:
> > > postfix-doc, we have python-doc but no php-doc or perl-doc)
> > >
> > I am not agree. If we provide exim, we provide *all* exim.
>
> Shove exim in extras then. Lets have one of everything (including
databases)
> in the base except where the are real divides (Gnome/KDE)
I think exim still has potential to become our future default MTA.
That doesn't mean it has to sit in core while it is not.
I'm seriously hoping that AbiWord and Gnumeric someday will be the
default office apps in core, OOo imho is bloated and has a code base
that is just too big, I personally think OOo was a poor choice to
default to - and had the resources by various distros been put into
AbiWord/Gnumeric that were put into OOo - they would absolutely rock
even more than they already do.
But while OOo is what is being pushed and defaulted to, AbiWord/
Gnumeric need to live in Extras so that they do not add to what a user
who sticks with defaults has to download.
--
Michael A. Peters
http://mpeters.us/
3:50 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote:
I think exim still has potential to become our future default MTA.
I agree. We really shouldn't be inflicting sendmail on newcomers as the
default MTA. That's a far better candidate for going to Extras, for
those who really want it because they've already suffered the brain
damage its configuration inflicts.
Exim would be a far better default, because it's far easier to configure
and far better documented. In FC4 it ships with TLS enabled by default,
and SMTP AUTH support present but commented out in the specfile. It also
has built-in SpamAssassin support for rejecting spam at SMTP time, which
again is enabled by merely uncommenting it in the specfile.
I keep meaning to add more features there, like relaying all mail to a
smarthost. If we reach a consensus on making the default, I'll make sure
it all gets done.
--
dwmw2
3:54 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote:
Exim would be a far better default, because it's far easier to
configure
and far better documented. In FC4 it ships with TLS enabled by default,
and SMTP AUTH support present but commented out in the specfile. It also
has built-in SpamAssassin support for rejecting spam at SMTP time, which
again is enabled by merely uncommenting it in the specfile.
Bah. s/specfile/config file/g
--
dwmw2
3:55 p.m.
New subject: Exim as default MTA.
On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote:
I keep meaning to add more features there, like relaying all mail to
a
smarthost. If we reach a consensus on making the default, I'll make sure
it all gets done.
I think we should go ahead and make it the default. It doesn't help
anyone perpetuating sendmail as default, I don't think it's a long
term option. Users that know how to control it, know where to get it from.
--
Dimi.
3:59 p.m.
New subject: Exim as default MTA.
David Woodhouse wrote:
Exim would be a far better default
How does the argument stack up against postfix? I've found postfix +
procmail (optional) + dovecot + squirrelmail (optional) to be very easy
to manage.
I agree that sendmail is not something to inflict on people though.
Carwyn
4:10 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 21:59 +0000, Carwyn Edwards wrote:
How does the argument stack up against postfix? I've found postfix
+
procmail (optional) + dovecot + squirrelmail (optional) to be very easy
to manage.
I haven't had that much experience of postfix.
On the occasions I've looked at its configuration I've found it far more
difficult than Exim but that's partly because I'm familiar with Exim's
configuration so I find it hard to judge.
I'm also somewhat put off postfix by the fact that even the postfix
'experts' who insist on using it freedesktop.org were completely unable
to make it route mail properly to a domain with an IPv6-only primary MX.
Possibly something to do with the recent 'open relay' erratum for
postfix.
The thing that really tips the balance, though, is the documentation. As
I said, it's the best documentation I've ever seen for a Free Software
project. Set yourself a few common tasks which a basic Fedora sysadmin
might want to do, and have a play with
http://www.exim.org/exim-html-4.40/doc/html/spec.html and
http://www.exim.org/exim-html-4.40/doc/html/FAQ.html
--
dwmw2
4:33 p.m.
New subject: Exim as default MTA.
David Woodhouse wrote:
On the occasions I've looked at its configuration I've found
it far more
difficult than Exim
About a two years ago I sat down to evaluate an MTA to replace sendmail
- I specifically chose postfix because it was simpler to configure from
the point of view of transitioning from sendmail.
Carwyn
5:05 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 22:33 +0000, Carwyn Edwards wrote:
About a two years ago I sat down to evaluate an MTA to replace
sendmail
- I specifically chose postfix because it was simpler to configure from
the point of view of transitioning from sendmail.
Given that sendmail is widely acknowledged to cause brain damage, that
is hardly a resounding endorsement. :)
Seriously though, I'm not sure it's a criterion we're interested in.
We should be interested in what's easy to use for someone who's entirely
new to it. If they're already running sendmail, they can continue to use
sendmail -- and if they don't want to do so, they can make a choice
about what to replace it with.
Our default should be what's best for the newbie; not for the sendmail
victim in recovery.
I think Alan's wrong to suggest that there's no middle ground between
caring about how easy stuff is to configure, and needing a complete
point-and-drool configuration GUI for it. We don't _have_ a GUI
configuration tool for any MTA, but we do have a web browser and the
excellent and fully indexed Exim documentation, and a bunch of useful
default features commented out but ready to use in the default config
file.
--
dwmw2
7:18 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 23:05 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 22:33 +0000, Carwyn Edwards wrote:
>About a two years ago I sat down to evaluate an MTA to replace sendmail
>- I specifically chose postfix because it was simpler to configure from
>the point of view of transitioning from sendmail.
Given that sendmail is widely acknowledged to cause brain damage, that
is hardly a resounding endorsement. :)
Seriously though, I'm not sure it's a criterion we're interested in.
We should be interested in what's easy to use for someone who's entirely
new to it. If they're already running sendmail, they can continue to use
sendmail -- and if they don't want to do so, they can make a choice
about what to replace it with.
Ok, I consider myself a "newbie" when it comes to MTAs.
I currently run sendmail, but I've done as little as possible to get it
working. I have no spam filtering at SMTP, no auto-sorting of messages
into folders, basically nothing more than "get the mail to the spool".
Why? Because sendmail frightens me, I'm lazy, and what I have now
basically "works" and I don't want to break anything.
Now if exim can be used as a drop in replacement with just a bit of
tweaking for site specific stuff, great. If I can enable some of the
features I'd like by uncommenting a few options in the default config,
even better.
So I'll bite and look at the latest exim package in FC3 (I am running a
server, so I can't really use rawhide). I'd be glad to report how it
goes if anyone is interested.
I think Alan's wrong to suggest that there's no middle ground
between
caring about how easy stuff is to configure, and needing a complete
point-and-drool configuration GUI for it. We don't _have_ a GUI
configuration tool for any MTA, but we do have a web browser and the
excellent and fully indexed Exim documentation, and a bunch of useful
default features commented out but ready to use in the default config
file.
As a newbie, I don't really care about a GUI either. As long as the
documentation is easily accessible and the package provides sane
defaults, I don't see the need for a GUI.
Realistically, it would probably only be used once to setup the mail
server initially. After that, it'd just sit there on the hard drive
taking up space. Newbies have a tendency not to remove anything,
whether it's being used or note.
josh
1:37 a.m.
New subject: Exim as default MTA.
So I'll bite and look at the latest exim package in FC3 (I am
running a
server, so I can't really use rawhide). I'd be glad to report how it
goes if anyone is interested.
Do the FC3 RPMS actually have the exiscan patch built in?
I had to get the exim rpms for that feature:
ftp://ftp.exim.org/pub/rpms-for-exim/fedora-3-i386-updates
Why do we build our own, if they proivde FC3 ones?
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 742001
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
3:01 a.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 07:37 +0000, Gavin Henry wrote:
> So I'll bite and look at the latest exim package in FC3 (I
am running a
> server, so I can't really use rawhide). I'd be glad to report how it
> goes if anyone is interested.
Do the FC3 RPMS actually have the exiscan patch built in?
Yes.
There is much common ground between the exim.org rpms (which I used to
maintain) and the RH ones. Both Tim Waugh and I have unashamedly stolen
rpm spec features from each other in the past. The main difference is
that the FC/RH rpms do a single set of feature support tailored for
whats available on FC by default, and the exim.org ones have flavours
for different databases etc.
I had to get the exim rpms for that feature:
No idea why - exiscan has been in for a year or two. Certainly before
exim went into FC (was previously in rawhide for RHEL).
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
4:52 a.m.
New subject: Exim as default MTA.
Josh Boyer wrote:
So I'll bite and look at the latest exim package in FC3 (I am
running a
server, so I can't really use rawhide). I'd be glad to report how it
goes if anyone is interested.
Can you please look at postfix too and tell us what you think about
both? This could be interesting..
I cant comment much about this postfix/exim issue, since:
1 - I only used exim in debian and I configured it following a badly
written guide (the guide was written by one of my coworkers when
I was still a newbie)
2 - I moved from sendmail to postfix , so I suffered heavy cerebral
damage :P
--
Pedro Macedo
4:54 a.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote:
Ok, I consider myself a "newbie" when it comes to MTAs.
I currently run sendmail, but I've done as little as possible to get it
working. I have no spam filtering at SMTP, no auto-sorting of messages
into folders, basically nothing more than "get the mail to the spool".
Sounds like you're a reasonably good test candidate; thanks for
volunteeering.
So I'll bite and look at the latest exim package in FC3 (I am
running a
server, so I can't really use rawhide). I'd be glad to report how it
goes if anyone is interested.
If you have time, please could you also try the same with postfix? And
if your own setup isn't very interesting, pick some other tasks like
configuring mailman etc. to amuse yourself.
Like I said -- I'm far more adamant that sendmail should go, than I am
that Exim should be its replacement. I just happen to think that Exim is
a better choice.
--
dwmw2
6:25 a.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 10:54 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote:
>Ok, I consider myself a "newbie" when it comes to MTAs.
>
>I currently run sendmail, but I've done as little as possible to get it
>working. I have no spam filtering at SMTP, no auto-sorting of messages
>into folders, basically nothing more than "get the mail to the spool".
Sounds like you're a reasonably good test candidate; thanks for
volunteeering.
Ok, so far I'm finding exim to be much better than sendmail. The
default exim.conf file is heavily documented and I only had to set 2
lines in order to get the equivalent functionality that I did with
sendmail.
The only suggestion I have for the default config file is to use the
defered_ok switch on the malware and spam ACL entries. I uncommented
the acl_smtp_data = acl_check_content line and my server promptly
started rejecting mail because I don't have sophie installed. If
defered_ok had been used, the mail would have come through just fine.
Remember, we're looking at this from a newbie point of view. Getting
email is always better than rejecting everything when it's a setup type
issue.
If you have time, please could you also try the same with postfix? And
if your own setup isn't very interesting, pick some other tasks like
configuring mailman etc. to amuse yourself.
I'll try and take a look at postfix in the next day or two. Probably
tomorrow since my one user will be gone most of the evening :).
Like I said -- I'm far more adamant that sendmail should go, than I am
that Exim should be its replacement. I just happen to think that Exim is
a better choice.
I'd have to agree that exim is better than sendmail from a usability
standpoint. It was easier to configure, and the default config file
already has some of the features I'm looking for. Unless postfix proves
to be even better, I'll probably be sticking with exim.
josh
6:49 a.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 06:25 -0600, Josh Boyer wrote:
The only suggestion I have for the default config file is to use the
defered_ok switch on the malware and spam ACL entries. I uncommented
the acl_smtp_data = acl_check_content line and my server promptly
started rejecting mail because I don't have sophie installed. If
defered_ok had been used, the mail would have come through just fine.
If you really mean 'rejecting' mail then let me know and I'll look into
it right now. If as I suspect you just mean 'deferring' -- it was giving
a temporary error and no mail was lost, then I'm less sure.
One might argue that deferral is the correct behaviour -- if you enabled
the spam checking and your spamd is broken, it's better to keep the mail
in the queue elsewhere until your spamd is fixed than it is to just
accept the incoming mail, spam and all.
If the checking were enabled by default then I'd agree with you -- but
since you have to actually _ask_ for spam checking, I'm inclined to
suggest that it's better the way it is.
We can certainly add the defer_ok option to the comments though, so it
stares you in the face if you do enable the checking. Would that be
sufficient?
--
dwmw2
7:34 a.m.
New subject: Exim as default MTA.
On Wed, Feb 23, 2005 at 12:49:25PM +0000, David Woodhouse wrote:
On Wed, 2005-02-23 at 06:25 -0600, Josh Boyer wrote:
> The only suggestion I have for the default config file is to use the
> defered_ok switch on the malware and spam ACL entries. I uncommented
> the acl_smtp_data = acl_check_content line and my server promptly
> started rejecting mail because I don't have sophie installed. If
> defered_ok had been used, the mail would have come through just fine.
If you really mean 'rejecting' mail then let me know and I'll look into
it right now. If as I suspect you just mean 'deferring' -- it was giving
a temporary error and no mail was lost, then I'm less sure.
Yes, I meant deferring. But in my case, it was continually defering until
I bothered to check the logs, which to a newbie looks like rejecting. After
I commented the line out and restarted exim, the mail came through fine.
One might argue that deferral is the correct behaviour -- if you enabled
the spam checking and your spamd is broken, it's better to keep the mail
in the queue elsewhere until your spamd is fixed than it is to just
accept the incoming mail, spam and all.
Maybe. But I know some list maintainers that get cranky if they notice email
that is stuck in their queue ;).
If the checking were enabled by default then I'd agree with you -- but
since you have to actually _ask_ for spam checking, I'm inclined to
suggest that it's better the way it is.
That's just it. I _did_ ask for spam checking. I started spamassassin and
then uncommented that line. What I didn't expect is for it to defer email
when I don't even have a virus checker installed. Call it a newbie mistake.
We can certainly add the defer_ok option to the comments though, so it
stares you in the face if you do enable the checking. Would that be
sufficient?
Sure, adding that to the comments would be fine IMHO. That way newbies will at
least know what happens when they don't have spamassassin or a virus checker
running, and how to work around it if they don't want to do one or the other.
josh
1:15 p.m.
New subject: Exim as default MTA.
Le mercredi 23 février 2005 à 10:54 +0000, David Woodhouse a écrit :
On Tue, 2005-02-22 at 19:18 -0600, Josh Boyer wrote:
>Ok, I consider myself a "newbie" when it comes to MTAs.
>
>I currently run sendmail, but I've done as little as possible to get it
>working. I have no spam filtering at SMTP, no auto-sorting of messages
>into folders, basically nothing more than "get the mail to the spool".
Sounds like you're a reasonably good test candidate; thanks for
volunteeering.
>So I'll bite and look at the latest exim package in FC3 (I am running a
>server, so I can't really use rawhide). I'd be glad to report how it
>goes if anyone is interested.
If you have time, please could you also try the same with postfix? And
if your own setup isn't very interesting, pick some other tasks like
configuring mailman etc. to amuse yourself.
Like I said -- I'm far more adamant that sendmail should go, than I am
that Exim should be its replacement. I just happen to think that Exim is
a better choice.
Right. I think most postfix users are not rabid exim haters either (at
least I'm not). It seems both postfix and exim are good choices without
any of the big warts that make people hate sendmail.
IMHO it'd be a shame to drop postfix - it has spent quite a long time as
a sendmail alternative in powertools then RHL and FC waiting for RH
management to realise sendmail should die. I think the only reason the
postfix crowd is silent right now people can't even imagine RH relenting
on sendmail, while exim users still have some hope left.
Regards,
--
Nicolas Mailhot
2:29 a.m.
New subject: Exim as default MTA.
On 02/23/2005 11:15:07 AM, Nicolas Mailhot wrote:
I think the only reason the
postfix crowd is silent right now people can't even imagine RH
relenting
on sendmail, while exim users still have some hope left.
I'm a postfix fan because it was easy (as in cake) to set it up to run
in a chroot jail back when I first started using it, which was when
sendmail exploit after exploit ad infinitum were being found (a couple
years ago) - I was running an LFS system at the time, and that was a
PITA.
postfix didn't have those vulnerabilities, and I could chroot it as an
extra measure.
Now I just use the default Fedora rpm and don't run it in a chroot, but
OTOH I'm also now only using it for mail on a lan and not to talk to
(or receive from) outside world, so chroot isn't as critical to set up.
I'm not speaking up here though because I know nothing about exim.
--
Michael A. Peters
http://mpeters.us/
10:19 a.m.
New subject: Exim as default MTA.
On Tue, 22 Feb 2005 19:18:06 -0600, Josh Boyer
<jwboyer(a)jdub.homelinux.org> wrote:
Ok, I consider myself a "newbie" when it comes to MTAs.
I currently run sendmail, but I've done as little as possible to get it
working. I have no spam filtering at SMTP, no auto-sorting of messages
into folders, basically nothing more than "get the mail to the spool".
Why? Because sendmail frightens me, I'm lazy, and what I have now
basically "works" and I don't want to break anything.
I've run sendmail, qmail and postfix.
I had a love affair with qmail -- I used to love how it would push the
load average on my little cobalt qube (16 M of RAM) to 20 while sending
more than 1000 messages per minute.
In bigger installations I had all sorts of trouble, but the killer is
that Dan Bernstein doesn't want to maintain qmail and his license doesn't
let anybody fork it. You ~can~ put together a system that can do spam
filtering, sender authentication, you name it, but you're going to put
in a ~lot~ of patches and have a frankensystem that's different from
anybody elses frankensystem.
I've run a postfix installation, and I've been pretty happy with it.
It's pretty easy to set up virus and spam filtering with postfix, and
cyrus is a great back end, although there's more system integration
involved than average newbie would want. I had trouble during the virus
crises last year, and had to abandon an old email address that would get
50,000+ viruses a day. (/var fills up with log entries from the virus
checker, etc.) Since then the system will go for months without
intervention.
I've had a job where we use sendmail, and have even had to deal with
RHEL 3 kernel bugs that caused sendmail to fail. (Upgrade to 2.6 solved
this)
Sendmail isn't so bad, but the trouble is that the online documentation
is useless; if you can get the big O'Reilly book on it, Sendmail isn't
hard to configure at all.
> I think Alan's wrong to suggest that there's no middle ground between
> caring about how easy stuff is to configure, and needing a complete
> point-and-drool configuration GUI for it. We don't _have_ a GUI
> configuration tool for any MTA, but we do have a web browser and the
> excellent and fully indexed Exim documentation, and a bunch of useful
> default features commented out but ready to use in the default config
> file.
I really like the way configuration files work in Red Hat and Fedora. I
love /etc/sysconfig.
I hate the graphical configuration tools. It's not that I hate the
idea of them; the user interfaces for most of them are sound. (They
ought to be since they rip off Windows)
The trouble is that the authors seemed to quit working on them at the
time they reached the 80% working level. A graphical configuration tool
that screws up occasionally and needs workarounds is a big waste of time
-- particularly when I know my way around /etc/sysconfig and can make any
changes I want in thirty seconds with "sudo emacs."
I'm all for graphical configuration tools, but configuration tools that
work 80% are worse than graphical configuration tools that don't work at
all.
8:47 a.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 22:10 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 21:59 +0000, Carwyn Edwards wrote:
>How does the argument stack up against postfix? I've found postfix +
>procmail (optional) + dovecot + squirrelmail (optional) to be very easy
>to manage.
I haven't had that much experience of postfix.
One data point I'd like to add to this is that specifically in the
Fedora context (i.e. outside of the general exim vs postfix debate),
Postfix has the advantage in that its design (multiple independent
mutually untrusting processes¹) allows a strong SELinux policy to be
easily applied, further enhancing Postfix's already good security.
Exim re-execs itself to drop privilege, but this doesn't work well with
SELinux without source code changes (unwritten as of yet AFAIK) to
determine which context to transition to.
¹ http://www.postfix.org/big-picture.html
9:08 a.m.
New subject: Exim as default MTA.
Once upon a time, Colin Walters <walters(a)redhat.com> said:
One data point I'd like to add to this is that specifically in
the
Fedora context (i.e. outside of the general exim vs postfix debate),
Postfix has the advantage in that its design (multiple independent
mutually untrusting processes¹) allows a strong SELinux policy to be
easily applied, further enhancing Postfix's already good security.
I would definately give the edge to Postfix then.
I use sendmail everywhere myself, but for my main servers I have to roll
my own RPMs anyway to get additional things turned on (also I use the
same source RPM on Linux, Tru64, and Solaris). Having sendmail removed
wouldn't bother me.
The biggest question is still the upgrade issue; if sendmail is removed
from Core, what will happen on upgrades? Users will be left with the
old version of sendmail running.
What would be "nice" would be a hack in anaconda to check for a default
config sendmail install (i.e. nothing has been changed since install)
and replace it with the new default MTA (postfix or exim). If anything
has changed, just leave it alone. There currently isn't really a way to
handle changing the default provider of a service from one package to
another.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:19 a.m.
New subject: Exim as default MTA.
What would be "nice" would be a hack in anaconda to check
for a default
config sendmail install (i.e. nothing has been changed since install)
and replace it with the new default MTA (postfix or exim). If anything
has changed, just leave it alone. There currently isn't really a way to
handle changing the default provider of a service from one package to
another.
actually if the default install is still there, not exim or postfix
should be installed but ssmtp or smail or such; at least a very simple
"send only" mail app that has a smarthost as only configuration
parameter.
lots nicer for security overall ;)
9:28 a.m.
New subject: Exim as default MTA.
Chris Adams wrote:
I would definately give the edge to Postfix then.
I use sendmail everywhere myself, but for my main servers I have to roll
my own RPMs anyway to get additional things turned on (also I use the
same source RPM on Linux, Tru64, and Solaris). Having sendmail removed
wouldn't bother me.
I dunno if the suggestion is actually to remove it (move it to Extras)
rather than just make Postfix the default MTA.
The biggest question is still the upgrade issue; if sendmail is removed
from Core, what will happen on upgrades? Users will be left with the
old version of sendmail running.
See above for one thought. OTOH if it were removed Postfix would just
obselete sendmail and well... you'd have to reconfigure :)
What would be "nice" would be a hack in anaconda to check
for a default
config sendmail install (i.e. nothing has been changed since install)
and replace it with the new default MTA (postfix or exim). If anything
has changed, just leave it alone. There currently isn't really a way to
handle changing the default provider of a service from one package to
another.
Well one way to look at it is, rpm lets you remove a package but leave
the config files behind anyways, automatically converting between 2 very
different MTA's isn't feasible at this juncture (unless tools exist?)
since they have different features and vastly different config parameters.
Good thoughts though Chris, you made some good points I forgot about :)
-sb
2:54 p.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 09:08 -0600, Chris Adams wrote:
The biggest question is still the upgrade issue; if sendmail is
removed
from Core, what will happen on upgrades? Users will be left with the
old version of sendmail running.
As much as i hate saying it, probably dropping Sendmail is not a good
move. After all, it still is the standard MTA in many places.
The current situation (Sendmail as default, another MTA as an
alternative, plus an easy way to switch between them) is best at the
moment. If Sendmail's "market share" declines drastically, then
switching the default should be easy.
--
Florin Andrei
http://florin.myip.org/
3:25 p.m.
New subject: Exim as default MTA.
On Thu, Feb 24, 2005 at 12:54:06PM -0800, Florin Andrei wrote:
As much as i hate saying it, probably dropping Sendmail is not a
good
move. After all, it still is the standard MTA in many places.
The current situation (Sendmail as default, another MTA as an
alternative, plus an easy way to switch between them) is best at the
moment. If Sendmail's "market share" declines drastically, then
switching the default should be easy.
Dropping it may be drastic; it could be moved to extras.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
3:26 p.m.
New subject: Exim as default MTA.
On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote:
--
dwmw2
Dropping it may be drastic; it could be moved to extras.
Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't
going to fit onto 4 CDs, we have no need to drop _anything_ until then,
when we can do it in a controlled fashion.
3:31 p.m.
New subject: Exim as default MTA.
On Thu, Feb 24, 2005 at 09:26:26PM +0000, David Woodhouse wrote:
On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote:
>Dropping it may be drastic; it could be moved to extras.
Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't
going to fit onto 4 CDs, we have no need to drop _anything_ until then,
when we can do it in a controlled fashion.
Sounds reasonable.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
4:22 p.m.
New subject: Exim as default MTA.
David Woodhouse (dwmw2(a)infradead.org) said:
On Thu, 2005-02-24 at 16:25 -0500, Matthew Miller wrote:
>Dropping it may be drastic; it could be moved to extras.
Until FC5, those two are equivalent. Having accepted that FC4/i386 isn't
going to fit onto 4 CDs
FC4 i386 *is* going to fit on 4 CDs (almost certainly). It's x86_64
and possibly ppc that is over.
Bill
3:33 p.m.
New subject: Exim as default MTA.
Le jeudi 24 février 2005 à 12:54 -0800, Florin Andrei a écrit :
On Wed, 2005-02-23 at 09:08 -0600, Chris Adams wrote:
> The biggest question is still the upgrade issue; if sendmail is removed
> from Core, what will happen on upgrades? Users will be left with the
> old version of sendmail running.
As much as i hate saying it, probably dropping Sendmail is not a good
move. After all, it still is the standard MTA in many places.
Really someone should have the courage to drive the stake in sendmail's
heart. Else it'll still rise from its coffin in ten years. Being not
entreprise-oriented FC is the place to do so.
We've made much more impacting changes in the past. The few people who
really need sendmail can install it from extras - but I doubt there will
be so many of them (entreprise people will replace the distribution
sendmail with the one bundled in their favorite proprietary enterprise
bundle anyway). Most users either don't care about advanced features and
will be happy with the default config shipped by FC (regardless of the
MTA) or will be perfectly able to master postfix or exim syntax.
Despite what people think MTA config is not the same in 2005 as it was
in the 1990s. After all with the level spam reaches nowadays any admin
worth this name should have spend some time learning how to plug new
filters in his system. This is usually much more difficult than adapting
to the simplicity of postfix/exim config.
Regards,
--
Nicolas Mailhot
4 p.m.
New subject: Exim as default MTA.
On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote:
Exim would be a far better default, because it's far easier to
configure
and far better documented. In FC4 it ships with TLS enabled by default,
and SMTP AUTH support present but commented out in the specfile. It also
I must disagree. If the user has to know what the mail system is you've
already failed the main usability test for "the general user". If they know
what they are doing then they probably have an opinion already and a preferred
app, and can also work yum/up2date.
The point at which you start saying things like "we should use sendmail" with
that kind of user I think personally is the point at which you ship xyz
mailer because the GUI configuration tool supports it seamlessly
4:10 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 17:00 -0500, Alan Cox wrote:
I must disagree. If the user has to know what the mail system is
you've
already failed the main usability test for "the general user". If they know
what they are doing then they probably have an opinion already and a preferred
app, and can also work yum/up2date.
The point at which you start saying things like "we should use sendmail" with
that kind of user I think personally is the point at which you ship xyz
mailer because the GUI configuration tool supports it seamlessly
You haven't been watching #fedora much recently, have you?
I'm far more adamant about "it shouldn't be sendmail" than "it
should be
exim" but sendmail definitely needs to go, and on balance I think Exim
would make a better choice than Postfix, because it's so much better
documented.
--
dwmw2
4:57 a.m.
New subject: Exim as default MTA.
I'm far more adamant about "it shouldn't be
sendmail" than "it should be
exim" but sendmail definitely needs to go, and on balance I think Exim
would make a better choice than Postfix, because it's so much better
documented.
And a good development community caring about stability on how exim works.
greetings,
Florian La Roche
6:26 a.m.
New subject: Exim as default MTA.
David Woodhouse wrote:
I'm far more adamant about "it shouldn't be
sendmail" than "it should be
exim" but sendmail definitely needs to go, and on balance I think Exim
would make a better choice than Postfix, because it's so much better
documented.
OTOH I think, that exim4's configuration files are close to unreadable
and far to many parentheses in it. If you want to use a simple MTA as
default mailer, I'd opt to go to postfix - but I am biased, because I
switched from Exim3 to Exim4, as I disliked some of the new
configuration stuff (especially its readability, as stated above).
As to documentation: postfix 2.1 is very well documented, the
documentation cannot be compared to what was delivered with 2.0 or
earlier.
But that's just me.
Regards,
Ralph
6:31 a.m.
New subject: Exim as default MTA.
Ralph Angenendt wrote:
[...] I'd opt to go to postfix - but I am biased, because I
switched from Exim3 to Exim4, as I disliked some of the new
configuration stuff (especially its readability, as stated above).
Okay, what was I thinking when I wrote that? This should of course read
"... switched from Exim3 to Postfix ...".
Ralph
8:24 a.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 13:31 +0100, Ralph Angenendt wrote:
> [...] I'd opt to go to postfix - but I am biased, because I
> switched from Exim3 to Exim4, as I disliked some of the new
> configuration stuff (especially its readability, as stated above).
Okay, what was I thinking when I wrote that? This should of course read
"... switched from Exim3 to Postfix ...".
Yeah, Exim3 was somewhat arcane, but has now been obsolete for a number
of years. Exim4 is a lot more logical in its configuration and has
relatively few parentheses unless you're trying to do something evil
with it. :)
If course, if you _like_ it weird, you can do that too....
http://david.woodhou.se/eximconf/include/routers-ses or
http://david.woodhou.se/eximconf/include/acl-helo-csv being examples of
what you can do if you just want to be silly about it and do stuff
purely in Exim configuration rather than falling back to hacking it up
in C like normal people might.
--
dwmw2
4:17 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 17:00 -0500, Alan Cox wrote:
On Tue, Feb 22, 2005 at 09:50:46PM +0000, David Woodhouse wrote:
> Exim would be a far better default, because it's far easier to configure
> and far better documented. In FC4 it ships with TLS enabled by default,
> and SMTP AUTH support present but commented out in the specfile. It also
I must disagree. If the user has to know what the mail system is you've
already failed the main usability test for "the general user". If they know
what they are doing then they probably have an opinion already and a preferred
app, and can also work yum/up2date.
there also is the angle of security history. Ok no mail system is
perfect there.
I still rather install ssmtp or similar on all boxes by default unless
the admin explicitly asked for a mail *server* not just a mail
sender ... Esp since a simple mail sender ought to be easy to configure
"Enter the email server as your ISP told you to use below" and vroom
smarthost done...
from a security pov that ought to be a lot nicer.
4:06 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote:
>I think exim still has potential to become our future default MTA.
I agree. We really shouldn't be inflicting sendmail
What shouldn't be inflicted upon the users is bugware. Exim isn't
particularly famous (in a good way) as far as MTAs go in terms of
security. I would favour postfix, under this POV, but of course if
features is the chosen way, Exim might be your choice.
Rui
--
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
5:15 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 22:06 +0000, Rui Miguel Seabra wrote:
Exim isn't particularly famous (in a good way) as far as MTAs go
in
terms of security.
Exim has fairly good record. There's not really a lot of difference
between it and postfix from this POV. In fact even sendmail hasn't been
so bad recently as it used to be, but postfix and exim are probably
still ahead. It was Postfix which had the most recent erratum for the
open relay thing, wasn't it?
It's ease of use and documentation which tips the balance, I think.
--
dwmw2
5:38 p.m.
New subject: Exim as default MTA.
David Woodhouse wrote:
still ahead. It was Postfix which had the most recent erratum for
the
open relay thing, wasn't it?
Not really true, it was a 3rd party patch that Ubuntu chose to
integrate. This was sent to bugtraq by Wietse Venema:
FYI,
This is a bug in a third-party IPv6 patch that is not part of Postfix.
Neither the official Postfix release, nor the work-in-progress
version are not affected by this.
Wietse
Josko P.
5:47 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 18:38 -0500, Josko Plazonic wrote:
Not really true, it was a 3rd party patch that Ubuntu chose to
integrate. This was sent to bugtraq by Wietse Venema:
Ah, OK. Does the postfix we ship not support IPv6 then? That's
definitely a point against it.
--
dwmw2
5:50 p.m.
New subject: Exim as default MTA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Woodhouse wrote:
| On Tue, 2005-02-22 at 18:38 -0500, Josko Plazonic wrote:
|
|>Not really true, it was a 3rd party patch that Ubuntu chose to
|>integrate. This was sent to bugtraq by Wietse Venema:
|
|
| Ah, OK. Does the postfix we ship not support IPv6 then? That's
| definitely a point against it.
* Mon Oct 04 2004 Thomas Woerner <twoerner(a)redhat.com> 2:2.1.5-1
- - new version 2.1.5
- - new ipv6 and tls+ipv6 patches: 1.25-pf-2.1.5
- --
Chuck Mead <csm(a)redhat.com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCG8VGZfy0juH51WsRAiAuAJ0V9iPWTKbkC0nmuApJb37LGMmSMACdExGP
ejFZ7oYUmnVyIktQcBuUohs=
=7489
-----END PGP SIGNATURE-----
5:44 p.m.
New subject: Exim as default MTA.
On Tue, 22 Feb 2005, David Woodhouse wrote:
On Tue, 2005-02-22 at 22:06 +0000, Rui Miguel Seabra wrote:
>Exim isn't particularly famous (in a good way) as far as MTAs go in
>terms of security.
Exim has fairly good record. There's not really a lot of difference
between it and postfix from this POV. In fact even sendmail hasn't been
so bad recently as it used to be, but postfix and exim are probably
still ahead. It was Postfix which had the most recent erratum for the
open relay thing, wasn't it?
No, not really. It was a third party patch added by some distros to their
version of postfix. It was not included in the upstream code.
It's ease of use and documentation which tips the balance, I
think.
Have you looked at the postfix docs lately? I cannot comment on Exim at
all, since I have never used it but the docs here:
http://www.postfix.org/documentation.html seem pretty good to me.
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
5:52 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 18:44 -0500, Tom Diehl wrote:
Have you looked at the postfix docs lately? I cannot comment on Exim at
all, since I have never used it but the docs here:
http://www.postfix.org/documentation.html seem pretty good to me.
That looks a lot better than I remember. Certainly sendmail should go --
if our postfix actually supports IPv6 completely and can do the other
things like SpamAssassin on incoming mail at SMTP time, then I can't see
a lot to choose either way between it and Exim, although I'd personally
lean towards Exim.
--
dwmw2
5:57 p.m.
New subject: Exim as default MTA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Woodhouse wrote:
| On Tue, 2005-02-22 at 18:44 -0500, Tom Diehl wrote:
|
|>Have you looked at the postfix docs lately? I cannot comment on Exim at
|>all, since I have never used it but the docs here:
|>http://www.postfix.org/documentation.html seem pretty good to me.
|
|
| That looks a lot better than I remember. Certainly sendmail should go --
| if our postfix actually supports IPv6 completely and can do the other
| things like SpamAssassin on incoming mail at SMTP time, then I can't see
| a lot to choose either way between it and Exim, although I'd personally
| lean towards Exim.
~From my master.cf file:
spamassassin unix - n n - - pipe flags=Rq user=mail
argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient}
- --
Chuck Mead <csm(a)redhat.com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCG8cCZfy0juH51WsRAq4cAJ9HJPNdSL/p7GWssQNOgr974Kq2nwCdGYUJ
AnCzxjmS70qsVXeuxH23S5M=
=QBSt
-----END PGP SIGNATURE-----
6:11 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 18:57 -0500, Chuck Mead wrote:
spamassassin unix - n n - - pipe flags=Rq user=mail
argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient}
And how do you control the threshold at which it actually rejects the
mail for the failure? The equivalent of this part of Fedora's default
exim.conf and my http://david.woodhou.se/eximconf/include/acl-content,
for example:
# Reject spam messages with score over 10, using an extra condition.
deny message = This message scored $spam_score points. Congratulations!
spam = nobody:true
condition = ${if >{$spam_score_int}{100} {1}}
For that matter, can it do the rest of what's in that ACL? And can it do
what's in acl-helo and acl-helo-csv?
Some of those, particularly the CSV bit, aren't good examples of
"simple" configuration -- they're the baroque stuff I did when I was
bored and felt like improving my mailer configuration. But they're good
examples of "versatile".
--
dwmw2
6:17 p.m.
New subject: Exim as default MTA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Woodhouse wrote:
| On Tue, 2005-02-22 at 18:57 -0500, Chuck Mead wrote:
|
|>spamassassin unix - n n - - pipe flags=Rq user=mail
|>argv=/usr/local/bin/safilter.sh -f ${sender} ${recipient}
|
|
| And how do you control the threshold at which it actually rejects the
| mail for the failure? The equivalent of this part of Fedora's default
| exim.conf and my http://david.woodhou.se/eximconf/include/acl-content,
| for example:
|
| # Reject spam messages with score over 10, using an extra condition.
| deny message = This message scored $spam_score points. Congratulations!
| spam = nobody:true
| condition = ${if >{$spam_score_int}{100} {1}}
|
| For that matter, can it do the rest of what's in that ACL? And can it do
| what's in acl-helo and acl-helo-csv?
|
| Some of those, particularly the CSV bit, aren't good examples of
| "simple" configuration -- they're the baroque stuff I did when I was
| bored and felt like improving my mailer configuration. But they're good
| examples of "versatile".
Well... it ain't that complicated... :-)
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
- --
Chuck Mead <csm(a)redhat.com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCG8uOZfy0juH51WsRAuZKAJ94XXdQxctVMFyW9sKEBV3qejRxVwCgoc4N
zalHCvTBUHzdjwtbl+TcN50=
=082h
-----END PGP SIGNATURE-----
6:20 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 19:17 -0500, Chuck Mead wrote:
Well... it ain't that complicated... :-)
#!/bin/bash
/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
exit $?
Oh, I see. It looks like the old hacks for reintroducing mail into Exim
after SA checking then, before proper SA support was merged.
--
dwmw2
6:24 p.m.
New subject: Exim as default MTA.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David Woodhouse wrote:
| On Tue, 2005-02-22 at 19:17 -0500, Chuck Mead wrote:
|
|>Well... it ain't that complicated... :-)
|>
|>#!/bin/bash
|>/usr/bin/spamc | /usr/sbin/sendmail -i "$@"
|>exit $?
|
|
| Oh, I see. It looks like the old hacks for reintroducing mail into Exim
| after SA checking then, before proper SA support was merged.
Prolly... I do most of my work at the SMTP port via mime_header_checks
and other regexp/pcre stuff anyway. SA is a very small part of what I
do. :-)
- --
Chuck Mead <csm(a)redhat.com>
Instructor II (and resident Postfix bigot), GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCG81DZfy0juH51WsRAr2HAJ0dcVx9cyBudWZgm0XUo1Bb2EesrgCglRJ+
i8r/Rfs0RP73u7nRWdqOflA=
=xKzT
-----END PGP SIGNATURE-----
10:18 p.m.
New subject: Exim as default MTA.
On Tue, Feb 22, 2005 at 11:52:25PM +0000, David Woodhouse wrote:
That looks a lot better than I remember. Certainly sendmail should go
--
if our postfix actually supports IPv6 completely and can do the other
things like SpamAssassin on incoming mail at SMTP time, then I can't see
a lot to choose either way between it and Exim, although I'd personally
lean towards Exim.
Can exim easily do the "username+anystring@host" (or
"username-anystring@host") thing? I took a quick look at the much-vaunted
documentation :) and couldn't find anything about it. This is something I
really love with postfix. (The 'recipient_delimiter' option.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
2:48 a.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 23:18 -0500, Matthew Miller wrote:
Can exim easily do the "username+anystring@host" (or
"username-anystring@host") thing? I took a quick look at the much-vaunted
documentation :) and couldn't find anything about it. This is something I
really love with postfix. (The 'recipient_delimiter' option.)
Yes. The magic keyword is local_part_suffix - you can use whatever
delimiter you like (I use both + and - since some places won't accept +
in email addresses).
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
8:47 a.m.
New subject: Exim as default MTA.
On Wed, Feb 23, 2005 at 08:48:46AM +0000, Nigel Metheringham wrote:
> Can exim easily do the "username+anystring@host" (or
> "username-anystring@host") thing? I took a quick look at the much-vaunted
Yes. The magic keyword is local_part_suffix - you can use whatever
delimiter you like (I use both + and - since some places won't accept +
in email addresses).
In that case, postfix, exim, I don't really care. But I have a slight
preference for postfix since I've been using it for a while, it's been in
the distro longer, and we've been encouraging people to use it.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:44 p.m.
New subject: Exim as default MTA.
On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote:
On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote:
>I think exim still has potential to become our future default MTA.
<sigh>
Here we go again.
I agree. We really shouldn't be inflicting sendmail on newcomers
as the
default MTA. That's a far better candidate for going to Extras, for
those who really want it because they've already suffered the brain
damage its configuration inflicts.
Exim would be a far better default, because it's far easier to configure
and far better documented.
Far easier/better than what? Sendmail? Postfix?
I agree that Sendmail is harder to configure than pretty much any other
MTA, but as for the documentation part, it's actually pretty damn well
documented. To say that Sendmail lacks documentation just shows
ignorance on the subject and makes your whole position much weaker in
the debate.
Now, i still don't see any rational motive to inflict Exim upon users
when Postfix is comparable, if not better, on all accounts _and_ has
been already included for quite a while with Fedora / Red Hat and the
users are just getting used to it by now.
In fact, many Fedora users that i know switch to Postfix immediately
after installing the OS.
Please leave the partisan propaganda aside and start thinking
rationally.
--
Florin Andrei
http://florin.myip.org/
3:08 a.m.
New subject: Exim as default MTA.
On Tue, 22 Feb 2005 20:44:06 -0800, Florin Andrei
<florin(a)andrei.myip.org> wrote:
In fact, many Fedora users that i know switch to Postfix immediately
after installing the OS.
I am one of those, never used sendmail anymore since I found postfix.
7:16 a.m.
New subject: Exim as default MTA.
Florin Andrei wrote:
In fact, many Fedora users that i know switch to Postfix immediately
after installing the OS.
I switch to Qmail+vpopmail, since dumping sendmail 4 years ago :)
How are Exim & Postfix at handling several virtual domains? (with same
user@ names?)
7:21 a.m.
New subject: Exim as default MTA.
Hi.
Cream <lists(a)donut.dk> wrote:
How are Exim & Postfix at handling several virtual domains? (with
same
user@ names?)
A mailserver that is unable to do that is not worth being called by that
name. Exim is similar to sendmail in being more like a construction set
for mail servers than a mailserver. There are a lot of parts doing different
things that you can arrange at your leisure in order to route and transport
mail through the system. This means that there are usually several ways do
do something.
exims advantage is that it's config readable by human beings (ok, there
are a lot of {}).
--
Confucius say, "Man who sink into woman's arms soon have arms in woman's
sink."
7:55 a.m.
New subject: Exim as default MTA.
On Wed, 2005-02-23 at 14:21 +0100, Ralf Ertzinger wrote:
A mailserver that is unable to do that is not worth being called by
that
name. Exim is similar to sendmail in being more like a construction set
for mail servers than a mailserver. There are a lot of parts doing different
things that you can arrange at your leisure in order to route and transport
mail through the system. This means that there are usually several ways do
do something.
Exim does offer a lot of flexibility, yes. Although you _can_ contrive
many ways to do simple things, and even more ways to do compilated
things, the default configuration file ships with examples of the easy
way to do useful things -- and can have more such examples added on
request.
--
dwmw2
10:21 a.m.
New subject: Exim as default MTA.
On Wed, 23 Feb 2005 14:16:03 +0100, Cream <lists(a)donut.dk> wrote:
How are Exim & Postfix at handling several virtual domains? (with
same
user@ names?)
Postfix is great at this. It's solution isn't as elegant and flexible as
qmail's, but it's fine.
9:23 a.m.
New subject: Exim as default MTA.
Florin Andrei wrote:
On Tue, 2005-02-22 at 21:50 +0000, David Woodhouse wrote:
>On Tue, 2005-02-22 at 15:15 +0100, Florian La Roche wrote:
>
>>I think exim still has potential to become our future default MTA.
<sigh>
Here we go again.
I was just thinking the same thing myself.
>I agree. We really shouldn't be inflicting sendmail on newcomers as the
>default MTA. That's a far better candidate for going to Extras, for
>those who really want it because they've already suffered the brain
>damage its configuration inflicts.
>Exim would be a far better default, because it's far easier to configure
>and far better documented.
Far easier/better than what? Sendmail? Postfix?
I agree that Sendmail is harder to configure than pretty much any other
MTA, but as for the documentation part, it's actually pretty damn well
documented. To say that Sendmail lacks documentation just shows
ignorance on the subject and makes your whole position much weaker in
the debate.
He never said sendmail lacks documentation, he said exim and postfix
were better documented. And they are. Sendmail's documentation is so
needlessly complex people have it sitting in front of them and still
can't make heads or tails of how to configure it. So your position just
went out the window.
Now, i still don't see any rational motive to inflict Exim upon
users
when Postfix is comparable, if not better, on all accounts _and_ has
been already included for quite a while with Fedora / Red Hat and the
users are just getting used to it by now.
Both Exim and Postfix were added to RH Linux 6.2 Powertools at the same
time.
In fact, many Fedora users that i know switch to Postfix immediately
after installing the OS.
Biased are we? Not once do you mention why Exim shouldn't be the
default MTA, you merely claim that because you and your friends use
Postfix everyone should?
Please leave the partisan propaganda aside and start thinking
rationally.
Look who's talking. You twisted words, ignored Exim all together,
dissed someone who didn't say what you claimed, and then accuse them of
spreading Exim propoganda while you spread your postfix propaganda. You
could be a little nicer about it?
That said: my vote is Postfix simply because I like the configuration
files better than Exim. In terms of my needs both Exim and Postfix have
all the features anyone may need in an MTA. Sendmail's draconian
configuration files and basically extensive, but confusing documentation
really give a huge boost to Exim and Postfix in general.
9:30 a.m.
New subject: Exim as default MTA.
On Wed, Feb 23, 2005 at 10:23:28AM -0500, Stan Bubrouski wrote:
Both Exim and Postfix were added to RH Linux 6.2 Powertools at the
same
time.
But only postfix made the jump to the distro proper in RHL 7.3. (For
whatever that's worth -- not much, really. I think the SE Linux thing is the
biggest deal.)
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
4:14 p.m.
On Mon, 2005-02-21 at 22:19 +0100, Féliciano Matias wrote:
Le lundi 21 février 2005 à 13:54 -0700, Joshua Eichorn a écrit :
> How about dropping some of the random documentation rpms we keep around,
> they don't follow a pattern anyway (ie we have exim-doc but no
> postfix-doc, we have python-doc but no php-doc or perl-doc)
>
I am not agree. If we provide exim, we provide *all* exim.
Exim has the best documentation ever I've seen for any Free Software
project; it'd be a shame to drop it. But then again, it's available on
the web too, and the HTML version is probably the most usable because of
the indexing etc. So we could reasonably drop it.
--
dwmw2
5:54 p.m.
Le lundi 21 février 2005 à 22:14 +0000, David Woodhouse a écrit :
On Mon, 2005-02-21 at 22:19 +0100, Féliciano Matias wrote:
>Le lundi 21 février 2005 à 13:54 -0700, Joshua Eichorn a écrit :
>> How about dropping some of the random documentation rpms we keep around,
>> they don't follow a pattern anyway (ie we have exim-doc but no
>> postfix-doc, we have python-doc but no php-doc or perl-doc)
>>
>
>I am not agree. If we provide exim, we provide *all* exim.
Exim has the best documentation ever I've seen for any Free Software
project; it'd be a shame to drop it. But then again, it's available on
the web too, and the HTML version is probably the most usable because of
the indexing etc. So we could reasonably drop it.
So we could "reasonably" drop gcc, *-devel, ...
Not a good idea.
--
dwmw2
3:02 p.m.
On 02/21/2005 12:35:34 PM, Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages
to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse,
xfce,
xemacs, cfengine, and all the games are leading candidates. We also
may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
I would take a look at the alternatives that aren't planned to be
pushed - like AbiWord, Gnumeric, Balsa
Now - those particular packages are packages I personally use quite a
bit as I don't use OO.o or Evolution - but if they remained in Extras,
I would still be able to install them and thus be happy. I would prefer
they were on the core install, but they _are_ alternatives that
duplicate functionallity to what is installed by default when you click
the "Desktop" install.
As long as there isn't a delay for Extras for fc4 like there was for
fc3 (IE the day fc4 ships, I could yum install them)
Epiphany is another one - I was a die hard epiphany fan, but firefox
really is that good.
--
Michael A. Peters
http://mpeters.us/
4:22 p.m.
On Mon, 2005-02-21 at 21:02 +0000, Michael A. Peters wrote:
Epiphany is another one - I was a die hard epiphany fan, but firefox
really is that good.
I'm also using Firefox myself, but I think Epiphany is a better choice
for normal users. So move Firefox to Extras / Alternatives.
GNOME (evolution for SSL, gnome-panel, Epiphany) depend on Mozilla, so
Mozilla is needed anyway, and Epiphany is small, Firefox is 21779238
bytes (rpm -qi firefox).
François
--
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
5:38 a.m.
New subject: gnome-office, koffice (was Re: FC4 slimfast slimfest)
On Mon, 2005-02-21 at 21:02 +0000, Michael A. Peters wrote:
I would take a look at the alternatives that aren't planned to be
pushed - like AbiWord, Gnumeric, Balsa
yes, and koffice too. These could be
maintained in extras by people who
still use them, but the default OOo is quite good. abiword, gnumeric and
koffice aren't even installed by default when you check Office
Productivity category,
--
Marius Andreiana
Epon Business Applications
http://www.epon.ro
3:07 p.m.
On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Has anyone answered the question of whether RedHat will provide manpower to
maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would
get tossed about there.)
It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users
with downloading extra programs. It's another to say RedHat needs to keep
its maintenance of packages down; currently we can only support about 4 CDs
worth of stuff.
-Toshio
3:15 p.m.
On Mon, 2005-02-21 at 13:07 -0800, Toshio Kuratomi wrote:
On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote:
> Hi all,
>
> Here's a heads up that we need to get rid of about 300M of packages to
> make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
> xemacs, cfengine, and all the games are leading candidates. We also may
> try to start removing stuff from Core in hopes that it will appear in
> Extras if someone cares about it.
>
Has anyone answered the question of whether RedHat will provide manpower to
maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would
get tossed about there.)
It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users
with downloading extra programs. It's another to say RedHat needs to keep
its maintenance of packages down; currently we can only support about 4 CDs
worth of stuff.
No, That's the point - if fedora is going to work and going to have a
constantly increasing number of packages then people OUTSIDE of red hat
need to play ball.
if you don't know how to get on the team go here:
http://fedoraproject.org/wiki/Extras/CvsAccess
and learn! :)
-sv
4:11 p.m.
seth vidal <skvidal(a)phy.duke.edu>:
No, That's the point - if fedora is going to work and going to
have a
constantly increasing number of packages then people OUTSIDE of red hat
need to play ball.
if you don't know how to get on the team go here:
http://fedoraproject.org/wiki/Extras/CvsAccess
OK. There are a couple of packages I want to push into extras:
1. doclifter, for the document-conversion master plan.
2. gpsd, because David Zeuthen wants it for HAL
3. shipper, for reasons I explained at FUDcon.
Anyone willing to sponsor me?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
4:15 p.m.
On Mon, 2005-02-21 at 17:11 -0500, Eric S. Raymond wrote:
seth vidal <skvidal(a)phy.duke.edu>:
> No, That's the point - if fedora is going to work and going to have a
> constantly increasing number of packages then people OUTSIDE of red hat
> need to play ball.
>
> if you don't know how to get on the team go here:
> http://fedoraproject.org/wiki/Extras/CvsAccess
OK. There are a couple of packages I want to push into extras:
1. doclifter, for the document-conversion master plan.
2. gpsd, because David Zeuthen wants it for HAL
3. shipper, for reasons I explained at FUDcon.
Anyone willing to sponsor me?
Take this to fedora-extras-list, please.
thanks
-sv
4:26 p.m.
On Mon, Feb 21, 2005 at 04:15:20PM -0500, seth vidal wrote:
On Mon, 2005-02-21 at 13:07 -0800, Toshio Kuratomi wrote:
> On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote:
> > Hi all,
> >
> > Here's a heads up that we need to get rid of about 300M of packages to
> > make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
> > xemacs, cfengine, and all the games are leading candidates. We also may
> > try to start removing stuff from Core in hopes that it will appear in
> > Extras if someone cares about it.
> >
> Has anyone answered the question of whether RedHat will provide manpower to
> maintain packages in Extras? (I wasn't at FUDCon -- I was hoping it would
> get tossed about there.)
>
> It's one thing to talk about keeping FC4 to 4 CDs so we don't burden users
> with downloading extra programs. It's another to say RedHat needs to keep
> its maintenance of packages down; currently we can only support about 4 CDs
> worth of stuff.
>
No, That's the point - if fedora is going to work and going to have a
constantly increasing number of packages then people OUTSIDE of red hat
need to play ball.
Well yeah. But that's neither here nor there. You're stating that Core
is
defined as RedHat's contribution and Extras as The Community contribution to
the Fedora Project. But that's never been stated.
I want that clarified because it's a very different thing to look at Core
and say I wouldn't mind having to download that separate from the Core CDs
versus I wouldn't mind maintaining that package or seeing it go to
/dev/null.
This, of course, leads into the complementary question of whether RedHat
is willing to open up maintenance of Core packages to Community
contributers.
So there's a different set of criteria for choosing packages and a different
set of helpful suggestions outside the scope of adding/removing packages
depending on what we're actually trying to limit (disk space or RedHat
maintenence burden.)
if you don't know how to get on the team go here:
http://fedoraproject.org/wiki/Extras/CvsAccess
Yep. But fear of rejection has always kept me shy :-)
-Toshio
4:40 p.m.
On Mon, 2005-02-21 at 14:26 -0800, Toshio Kuratomi wrote:
> if you don't know how to get on the team go here:
> http://fedoraproject.org/wiki/Extras/CvsAccess
>
Yep. But fear of rejection has always kept me shy :-)
-Toshio
Same here.
/B
--
Brian Pepple <bdpepple(a)ameritech.net>
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E
7:41 p.m.
New subject: extras cvs sponsoring (was: Re: FC4 slimfast slimfest)
On Mon, 21 Feb 2005 17:40:52 -0500, Brian Pepple wrote:
On Mon, 2005-02-21 at 14:26 -0800, Toshio Kuratomi wrote:
> > if you don't know how to get on the team go here:
> > http://fedoraproject.org/wiki/Extras/CvsAccess
> >
> Yep. But fear of rejection has always kept me shy :-)
>
> -Toshio
>
Same here.
/B
I agree with the suggestion which has been made on fedora-extras-list.
Submit clean ready-to-ship updates (i.e. diffs against CVS, or complete
src.rpms) which can be imported into CVS without the QA overhead as
known from fedora.us. Then more developers (e.g. via extras-commits-list)
will see your changes and can build an opinion. For packagers, who've
met me in fedora.us QA queue, I'm willing to serve as proxy to CVS.
Before we see how this sponsoring works out in practice, I'm somewhat
conservative with whom to sponsor immediately. And I think the CVS
accounts maintenance thing is not ready yet either.
Private mail or a bugzilla ticket with proper CC should do
(bugs.michael AT gmx.net is my address in bugzilla).
5:32 p.m.
I think the point made here is quite important. Another package that
could be droped from core is nss_db because it's been half broken since
FC3 ( possibly before ) and is using at least 1mb of space needlessly.
It has been statically linked against db4.0 thereby driving up the size
of the binaries. Also, thrid party tools linked against db4.2 ( now
default ) libraries are incompatible with nss_db because it is
statically linked against 4.0.
I submitted a patched .src.rpm file that corrects those problems so that
not only are the libraries much smaller, but third party db generator
tools work ( since they are generally statically linked ) and it has
just sat there without any changes.
So, please, move it to extras so that someone can maintain it. There
may be dozens of packages like nss_db where the average person does not
use it, it has been poorly maintined, and it get isntalled by default on
all systems.
Cheers,
Eric
Toshio Kuratomi wrote:
>No, That's the point - if fedora is going to work and going to
have a
>constantly increasing number of packages then people OUTSIDE of red hat
>need to play ball.
>
Well yeah. But that's neither here nor there. You're stating that Core is
defined as RedHat's contribution and Extras as The Community contribution to
the Fedora Project. But that's never been stated.
I want that clarified because it's a very different thing to look at Core
and say I wouldn't mind having to download that separate from the Core CDs
versus I wouldn't mind maintaining that package or seeing it go to
/dev/null.
This, of course, leads into the complementary question of whether RedHat
is willing to open up maintenance of Core packages to Community
contributers.
So there's a different set of criteria for choosing packages and a different
set of helpful suggestions outside the scope of adding/removing packages
depending on what we're actually trying to limit (disk space or RedHat
maintenence burden.)
>if you don't know how to get on the team go here:
>http://fedoraproject.org/wiki/Extras/CvsAccess
>
Yep. But fear of rejection has always kept me shy :-)
-Toshio
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken
3:10 p.m.
On Mon, 21 Feb 2005, Elliot Lee wrote:
Here's a heads up that we need to get rid of about 300M of
packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
You can view the list of new packages since FC3 (sorted by package size)
at http://people.redhat.com/sopwith/new-packages.txt
Is there any particular reason to keep 'gv'? How important is it to keep around
pure X11 versions of tools like this? There are gnome & KDE versions of
PostScript & PDF viewers that are much more capable, and far less ugly.
Furthermore, I think it's time for 'ggv' and 'gpdf' to go as well, in
favor of
Evince as the Single Gnome Document Viewer for PS/PDF files. Its going to
happen at some point anyway, might as well be now.
Total savings from these three would be:
169938 gv-3.5.8-29.i386.rpm
936623 ggv-2.8.3-1.i386.rpm
775003 gpdf-2.9.3-1.i386.rpm
----------------------------
1881564
Dan
PS (I think xpdf has to stick around for now...)
3:25 p.m.
On Mon, 2005-02-21 at 16:10 -0500, Dan Williams wrote:
Is there any particular reason to keep 'gv'? How important
is it to keep around
pure X11 versions of tools like this? There are gnome & KDE versions of
PostScript & PDF viewers that are much more capable, and far less ugly.
In my experience it is the fasted PS viewer around. I occasionally use
it instead of ggv.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
3:33 p.m.
On Mon, 2005-02-21 at 22:25 +0100, Gérard Milmeister wrote:
On Mon, 2005-02-21 at 16:10 -0500, Dan Williams wrote:
> Is there any particular reason to keep 'gv'? How important is it to keep
around
> pure X11 versions of tools like this? There are gnome & KDE versions of
> PostScript & PDF viewers that are much more capable, and far less ugly.
>
In my experience it is the fasted PS viewer around. I occasionally use
it instead of ggv.
Did you try Evince yet? I haven't time it against gv, but it feels much
faster than ggv.
Also, it doen't allocate enough memory to trigger the oom-killer on PDFs
with big monochromatic bitmaps, like gpdf sometimes does (apparently
this is due to being based on an older version of xpdf, and since Evince
exists I doubt that gpdf is ever going to see more significant work). I
can't see any place where it's a regression compared to gv. I'd say kill
them all, as Dan suggested.
/Per
--
Per Bjornsson <perbj(a)stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University
4:11 p.m.
On Mon, Feb 21, 2005 at 04:10:15PM -0500, Dan Williams wrote:
Furthermore, I think it's time for 'ggv' and
'gpdf' to go as well, in favor of
Evince as the Single Gnome Document Viewer for PS/PDF files. Its going to
happen at some point anyway, might as well be now.
They all suck so shipping the one that people will make cool I agree with.
Is there a gnome plan for this ?
3:19 p.m.
Elliot Lee (sopwith(a)redhat.com) said:
Nothing is set in stone, but if you want to write in favor of
keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
OK, so:
- non-IIIMF input methods - they are now obsolete for a few releases
- mozilla (classic) - superseded by firefox, thunderbird, epiphany, etc
- XFCE - we already have GNOME and KDE
- Eclipse - it's just Too Big. Moreover, it won't cause the Upgrade problem (1)
- cfengine - it's not in use by Core packages, ergo, it makes sense for
Extras
- One of XEmacs/emacs. :)
- gpdf/ggv/gv/xpdf - superceded by evince
That's my opinion, anyway.
Bill
(1) The problem with moving any large package from Core to Extras is that,
until anaconda grows support for multiple repositories, upgrades
will cause failures. If you move stuff that isn't *yet* in a Core
release, you avoid that.
4:07 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
(1) The problem with moving any large package from Core to Extras is
that,
until anaconda grows support for multiple repositories, upgrades
will cause failures. If you move stuff that isn't *yet* in a Core
release, you avoid that.
That's also why I think there should be ISOs of Fedora Extras available.
Maybe not for FC4 (if pushing something significant from FC3 to FE4 can
be avoided), but down the road.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:12 p.m.
On Mon, 2005-02-21 at 16:07 -0600, Chris Adams wrote:
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
> (1) The problem with moving any large package from Core to Extras is that,
> until anaconda grows support for multiple repositories, upgrades
> will cause failures. If you move stuff that isn't *yet* in a Core
> release, you avoid that.
That's also why I think there should be ISOs of Fedora Extras available.
Maybe not for FC4 (if pushing something significant from FC3 to FE4 can
be avoided), but down the road.
Perhaps we should teach anaconda about multiple repositories, and then
both CD 5 and the Extras CDs can be optional parts of the install. And
of course the DVD will have them all anyway.
--
dwmw2
4:50 p.m.
David Woodhouse (dwmw2(a)infradead.org) said:
Perhaps we should teach anaconda about multiple repositories, and
then
both CD 5 and the Extras CDs can be optional parts of the install. And
of course the DVD will have them all anyway.
Multi-repository support for anaconda is planned for FC5.
Bill
4:57 p.m.
* Bill Nottingham <notting(a)redhat.com> [2005-02-21 17:55]:
David Woodhouse (dwmw2(a)infradead.org) said:
> Perhaps we should teach anaconda about multiple repositories, and then
> both CD 5 and the Extras CDs can be optional parts of the install. And
> of course the DVD will have them all anyway.
Multi-repository support for anaconda is planned for FC5.
Then I think we should slim down to extra repositories then.
Andrew
5 p.m.
Andrew Overholt (overholt(a)redhat.com) said:
> > Perhaps we should teach anaconda about multiple
repositories, and then
> > both CD 5 and the Extras CDs can be optional parts of the install. And
> > of course the DVD will have them all anyway.
>
> Multi-repository support for anaconda is planned for FC5.
Then I think we should slim down to extra repositories then.
Sorry, you've lost me here.
Bill
5:08 p.m.
* Bill Nottingham <notting(a)redhat.com> [2005-02-21 18:01]:
Andrew Overholt (overholt(a)redhat.com) said:
> > > Perhaps we should teach anaconda about multiple repositories, and then
> > > both CD 5 and the Extras CDs can be optional parts of the install. And
> > > of course the DVD will have them all anyway.
> >
> > Multi-repository support for anaconda is planned for FC5.
>
> Then I think we should slim down to extra repositories then.
Sorry, you've lost me here.
Sorry, I meant that we should only slim Core down when that support is in
anaconda (ie. for FC5).
Andrew
5:11 p.m.
On 02/21/2005 02:12:05 PM, David Woodhouse wrote:
Perhaps we should teach anaconda about multiple repositories, and
then
both CD 5 and the Extras CDs can be optional parts of the install.
And
of course the DVD will have them all anyway.
They should imho be a second DVD even if they would fit on a single.
--
Michael A. Peters
http://mpeters.us/
5:22 p.m.
On Mon, 2005-02-21 at 23:11 +0000, Michael A. Peters wrote:
> Perhaps we should teach anaconda about multiple repositories, and then
> both CD 5 and the Extras CDs can be optional parts of the install.
> And of course the DVD will have them all anyway.
They should imho be a second DVD even if they would fit on a single.
What's the point in that? If you want to force the user to _ask_ for
them and not install them by default, OK -- but why actually put them on
a separate DVD?
--
dwmw2
5:49 p.m.
On 02/21/2005 03:22:17 PM, David Woodhouse wrote:
On Mon, 2005-02-21 at 23:11 +0000, Michael A. Peters wrote:
>
>> Perhaps we should teach anaconda about multiple repositories, and
then
>> both CD 5 and the Extras CDs can be optional parts of the install.
>> And of course the DVD will have them all anyway.
>
>They should imho be a second DVD even if they would fit on a single.
What's the point in that? If you want to force the user to _ask_ for
them and not install them by default, OK -- but why actually put them
on
a separate DVD?
I don't want to have to download all of extras just to get the
convenience of a DVD install (no disk swapping) - especially since in a
month or so, a good portion of those extras will have updates that
would need to be individually downloaded anyway.
Most of extras I don't use - I would rather download a smaller install
iso and just yum install the extras that I do use.
--
Michael A. Peters
http://mpeters.us/
6:05 p.m.
On Mon, 2005-02-21 at 23:49 +0000, Michael A. Peters wrote:
I don't want to have to download all of extras just to get the
convenience of a DVD install (no disk swapping) - especially since in a
month or so, a good portion of those extras will have updates that
would need to be individually downloaded anyway.
Most of extras I don't use - I would rather download a smaller install
iso and just yum install the extras that I do use.
A problem is, that many people don't have fast internet connections,
therefore relying solely on yum install from remote repositories for
getting all the good stuff is not a good idea, IMHO. On the other hand
if someone has downloaded a couple of CDs or DVDs it is lot easier to
distribute it to those who cannot afford downloading large chunks.
Agreed the problem of updates will still exist.
--
Gérard Milmeister
Langackerstrasse 49
CH-8057 Zürich
6:15 p.m.
Once upon a time, Grard Milmeister <gemi(a)bluewin.ch> said:
A problem is, that many people don't have fast internet
connections,
therefore relying solely on yum install from remote repositories for
getting all the good stuff is not a good idea, IMHO. On the other hand
if someone has downloaded a couple of CDs or DVDs it is lot easier to
distribute it to those who cannot afford downloading large chunks.
Install-fests are another time that having media in hand is much more
convenient (bandwidth may be slow or non-existant at such events).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
6:55 p.m.
On 02/21/2005 04:15:53 PM, Chris Adams wrote:
Install-fests are another time that having media in hand is much more
convenient (bandwidth may be slow or non-existant at such events).
Install-fests typicall have one or two boxes acting as ftp/nfs servers
allowing boxes to install that way - needing nothing more than a small
boot iso.
--
Michael A. Peters
http://mpeters.us/
6:53 p.m.
On 02/21/2005 04:05:06 PM, Gérard Milmeister wrote:
A problem is, that many people don't have fast internet connections,
therefore relying solely on yum install from remote repositories for
getting all the good stuff is not a good idea
which is why you have a second DVD iso that has the extras - and not
put them on the first.
Those who want both at install time simply download and install two
iso's.
Of course - using something jigdo would be even better - as you could
have one jigdo image for just core, that creates just a core iso, and
second jigdo that creates a single dvd with core and extras. (and
jigdo's to create the CD's as well - all mirrors would need are the
packages and the jigdo files - works quite nicely for Debian)
--
Michael A. Peters
http://mpeters.us/
7:39 p.m.
On Tue, 2005-02-22 at 01:05 +0100, Gérard Milmeister wrote:
On Mon, 2005-02-21 at 23:49 +0000, Michael A. Peters wrote:
> I don't want to have to download all of extras just to get the
> convenience of a DVD install (no disk swapping) - especially since in a
> month or so, a good portion of those extras will have updates that
> would need to be individually downloaded anyway.
>
> Most of extras I don't use - I would rather download a smaller install
> iso and just yum install the extras that I do use.
A problem is, that many people don't have fast internet connections,
therefore relying solely on yum install from remote repositories for
getting all the good stuff is not a good idea, IMHO.
Yes, but .. why do you think I
am permanently nagging Seth to finally
implement a --download-only option into yum.
I think, the problem is yum, not "internet connections".
On the other hand
if someone has downloaded a couple of CDs or DVDs it is lot easier to
distribute it to those who cannot afford downloading large chunks.
Pardon? When
using yum/apt to install on a single-seat/home-desktop you
actually spare a lot of downloads, in comparison to downloading CDs,
because using yum/apt you'll only download a subset of all available
packages, in contrast to using CDs, which means to download everything.
Agreed the problem of updates will still exist.
I don't see
this as a problem.
Using the "download on demand strategy" as I outlined above, I actually
fail to see the need for having more CDs than a "minimalistic
bootstrap/installer CD" for "users on a small bandwidth connection".
Ralf
4:50 p.m.
Chris Adams (cmadams(a)hiwaay.net) said:
That's also why I think there should be ISOs of Fedora Extras
available.
Maybe not for FC4 (if pushing something significant from FC3 to FE4 can
be avoided), but down the road.
Having ISOs doesn't solve this at install/upgrade time, without the
support in the installer.
Bill
7:46 p.m.
On Feb 21, 2005, Bill Nottingham <notting(a)redhat.com> wrote:
Chris Adams (cmadams(a)hiwaay.net) said:
> That's also why I think there should be ISOs of Fedora Extras available.
> Maybe not for FC4 (if pushing something significant from FC3 to FE4 can
> be avoided), but down the road.
Having ISOs doesn't solve this at install/upgrade time, without
the
support in the installer.
Then we're about to make the big mistake of introducing extras before
being able to make it *feel* like part of the distribution.
Think of it this way: would you push OOo to extras? Why not? If so,
why insist on pushing other very, perhaps even more useful pieces of
software there, before they have be regarded as actually part of the
distro, not as second-class citizens?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
8:11 p.m.
Once upon a time, Alexandre Oliva <aoliva(a)redhat.com> said:
Think of it this way: would you push OOo to extras? Why not? If
so,
why insist on pushing other very, perhaps even more useful pieces of
software there, before they have be regarded as actually part of the
distro, not as second-class citizens?
How many Fedora users will use OOo vs. how many will use Java
development tools? The main use most users have for Java is applets,
and Fedora doesn't have anything for applets yet (you still have to use
Sun's JRE which can't be included in Fedora).
I think you are overestimating the importance of Java to the average
user.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:27 p.m.
On Mon, 2005-02-21 at 20:11 -0600, Chris Adams wrote:
Once upon a time, Alexandre Oliva <aoliva(a)redhat.com> said:
> Think of it this way: would you push OOo to extras? Why not? If so,
> why insist on pushing other very, perhaps even more useful pieces of
> software there, before they have be regarded as actually part of the
> distro, not as second-class citizens?
How many Fedora users will use OOo vs. how many will use Java
development tools? The main use most users have for Java is applets,
and Fedora doesn't have anything for applets yet (you still have to use
Sun's JRE which can't be included in Fedora).
I must respectfully disagree. You can reduce any package set to a
negligible corner case usage, but often I think the reality is
different. We need Java in some form to run Eclipse, which is an (open
source) IDE. Until now there has been no viable open source Java stack
available to support Eclipse (it requires a very decent implementation).
Now there is. The way that Eclipse is written is just one example of
Java applications that aren't the infamous applet example.
Regardless of whether you like Java, or Eclipse, there is a lot of open
source work going on with both. The Eclipse community is huge and
thriving community (eclipse.org), that has coverage for many, many
languages and environments (including C/C++/Python/Perl et al). Several
other distributions (like Debian, Gentoo etc) already have it integrated
into their systems.
I think you are overestimating the importance of Java to the average
user.
Which raises an interesting point. We are on tricky ground when we try
to define the median user of Fedora. More developers than user level
consumers? More academic than commercial? Who knows. We could have a
community just thirsting for Java ;)
Regards
Phil
12:53 p.m.
Le lundi 21 février 2005 à 20:27 -0600, Phil Muldoon a écrit :
applications that aren't the infamous applet example.
Regardless of whether you like Java, or Eclipse, there is a lot of open
source work going on with both. The Eclipse community is huge and
thriving community (eclipse.org), that has coverage for many, many
languages and environments (including C/C++/Python/Perl et al). Several
other distributions (like Debian, Gentoo etc) already have it integrated
into their systems.
One point to remember however is that a lot of contributors to FOSS java
projects are quite happy with a sort-of-free java platform (with the
core part being controlled by Sun). There are precious few actors that
can make a completely free java a reality if even Red Hat closes the
door on it. Just take a look at the mp3 situation.
Free java will require some changes in upstream java projects. How easy
do you think it'll be to ask for them if FC does not even eats its own
dog food ?
9:09 p.m.
On 02/21/2005 06:11:00 PM, Chris Adams wrote:
I think you are overestimating the importance of Java to the average
user.
I also would prefer JPackage handle Java.
Here's why - JPackage is very good at making things available on many
distributions. I've already sent e-mails to several developers of Java
apps suggesting they package their product in an rpm with the
dependencies satisfied by what is in JPackage, so that Linux users can
simply add the JPackage repository, and then yum localinstall the rpm -
and whatever is needed will just be grabbed. Some developers e-mailed
me saying they had not heard of JPackage but they liked what they saw.
In many cases this work for several distributions with just a single
rpm from the vendor, but if Fedora deviates from JPackage, then install
instructions for Fedora would have to be different than instructions
for other distro's.
I'm not a Java developer, I honestly don't like GUI Java apps in most
cases (it's the interface - not pretty) though I do like a few because
they are very good at what they do.
As far as packaging Java, JPackage is very good at what it does - I
have never before had such an easy time getting Java applications to
just work.
I would rather see support (and I do see it) of RH and Fedora for the
JPackage project, and let JPackage handle everything Java. Maybe ship a
JVM but not until it can do applets.
Ship with a jpackage.org repo file installed that a user just needs to
enable to use.
--
Michael A. Peters
http://mpeters.us/
1:14 p.m.
On Feb 21, 2005, Chris Adams <cmadams(a)hiwaay.net> wrote:
Once upon a time, Alexandre Oliva <aoliva(a)redhat.com> said:
> Think of it this way: would you push OOo to extras? Why not? If so,
> why insist on pushing other very, perhaps even more useful pieces of
> software there, before they have be regarded as actually part of the
> distro, not as second-class citizens?
How many Fedora users will use OOo vs. how many will use Java
development tools?
That's not my point. My point is that people claim pushing to extras
makes little to no difference to end users.
If that *was* the case, why not pushing OOo there? It's a very big
package, and nothing else depends on it.
I'm not seriously advocating for us to do that, it's more of a thought
experiment to point out the flaw in the argument of people who say
`you can always get it from extras'.
The point that OOo is a very big download offsets the higher costs of
bandwidth and slower network connections in most of the world, so you
can get an idea of how inconvenient it can be for most of the world to
get to extras if it's not available in CDs like the core of the
distro.
The other annoyance with having to install packages from extras is
that the install can have a significant number of drawbacks:
- it's slower: anaconda/rpm can take a number of shortcuts when doing
an install from scratch that they can't when the database is in a
fully consistent state.
- it pretty much requires network connection: you have to download
packages, and unless you have them all already downloaded onto your
box, and you have an alternate repo config to use them, you're out
of luck if your network goes down
- it requires far more storage: yum, up2date and all other
depsolvers/installers first download all packages you need, then
start installing them. So you need local space for the rpms plus
space for the installed packages. Compare that with having the rpms
in installable media, be it CD, DVD or a local NFS server.
- longer down time: it requires at least one box to remain down while
all packages that are not in the install media are downloaded, have
deps solved and then installed, adding one more interactive step to
the install, unlike the ideal model of `make all decisions, go',
which means the box is fully operational as soon as it comes up. It
means you can't start installing 50 boxes and go out to have dinner,
you have to stay around until they get to the first boot, then do
whatever amount of interaction it takes to get them functional, and
by then restaurants will all be closed so you go straight home,
hungry :-)
The advantages?
Can't really think of any.
Mirrors will want to carry extras anyway. Not making them available
as ISOs means they will get more requests for smaller files, which
thrash their disks, and pushes people away from bittorrent et al.
Users will be sad to find that their favorite apps are no longer
available in the CD set they got in a magazine or on a store, and
might not even realize they're still available in extras, *if* they
have the network connection and the bandwidth to get to it.
The DVD will be half-full instead of half-empty. Maybe that's a good
one :-)
FWIW, I don't have a DVD burner myself, and most if not all of my
installs are over NFS; I have a reasonably fast and reliable network
connection, but I happen to know the reality of most that live
around. Just getting updates is a lot of trouble already.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
1:42 p.m.
Alexandre Oliva (aoliva(a)redhat.com) said:
The point that OOo is a very big download offsets the higher costs
of
bandwidth and slower network connections in most of the world, so you
can get an idea of how inconvenient it can be for most of the world to
get to extras if it's not available in CDs like the core of the
distro.
Except... Core isn't available on CDs, except from third parties. I
don't see a reason why Extras couldn't have ISOs made from it
by those same third parties.
Bill
1:56 p.m.
Once upon a time, Bill Nottingham <notting(a)redhat.com> said:
Except... Core isn't available on CDs, except from third parties.
I
don't see a reason why Extras couldn't have ISOs made from it
by those same third parties.
Okay, then why does the Fedora Project provide ISO images of Core but
not Extras?
Also, see https://bugzilla.redhat.com/beta/show_bug.cgi?id=117647 -
there is currently no way to verify the validity of third-party CD/DVD
images since anaconda is not signed (the actual install run-time, not
the RPMs).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:59 p.m.
On Tue, 22 Feb 2005 14:42:35 -0500, Bill Nottingham <notting(a)redhat.com> wrote:
Except... Core isn't available on CDs, except from third parties.
I
don't see a reason why Extras couldn't have ISOs made from it
by those same third parties.
All you need is cookie-cutter instructions or an easy-bake tool.. and
the legal room to brand them as Fedora Extras (and co-brand them)
inside the trademark guidelines.
"Fedora Extras CD 1 - 12 brought to you by cruftyrpms.net" has to be
permissible under established trademark guidelines if the burden to
produce isos is going to be thrown out to 3rd parties like
cruftyrpms.net. My reading of the current trademark guidelines doesn't
lend me to believe that 3rd parties have the ability to brand a
locally spun up iso set as Fedora.
-jef
3:33 p.m.
On Feb 22, 2005, Bill Nottingham <notting(a)redhat.com> wrote:
Alexandre Oliva (aoliva(a)redhat.com) said:
> The point that OOo is a very big download offsets the higher costs of
> bandwidth and slower network connections in most of the world, so you
> can get an idea of how inconvenient it can be for most of the world to
> get to extras if it's not available in CDs like the core of the
> distro.
Except... Core isn't available on CDs, except from third parties.
I
don't see a reason why Extras couldn't have ISOs made from it
by those same third parties.
Third parties get the core isos from us. And they can't label it
Fedora if it's not our ISOs. How could they take Fedora Extras and
label it as such, especially if it's not the entire collection?
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
7:34 a.m.
On Mon, 21 Feb 2005 16:19:34 -0500, Bill Nottingham <notting(a)redhat.com>
wrote:
- non-IIIMF input methods - they are now obsolete for a few releases
Input methods are a big annoyance to people who don't use them; when we
installed RH 9 on my sister-in-law's computer, her first complaint was
that it "took too long to boot." I went in and cleaned up the boot
sequence and found that a number of different input methods that I'd never
heard of wasted many seconds at boot time.
- mozilla (classic) - superseded by firefox, thunderbird, epiphany,
etc
I have no idea why the world has embraced firefox after rejecting
mozilla. Perhaps there's a hidden way to do it, but I've had much better
luck configuring the pop-up blocker in mozilla... The are lots of little
features in mozilla I find myself missing in firefox.
On the other hand, RH always seems to ship a Mozilla that's hopelessly
out of date so I usually end up installing my own in /usr/local and rpm
--erasing the one that came with the OS. (Funny enough, I do that for
all of the software that I actually care about.)
9:27 a.m.
Paul A. Houle wrote:
> - mozilla (classic) - superseded by firefox, thunderbird,
epiphany, etc
I have no idea why the world has embraced firefox after rejecting
mozilla. Perhaps there's a hidden way to do it, but I've had much
better luck configuring the pop-up blocker in mozilla... The are
lots of little features in mozilla I find myself missing in firefox.
On the other hand, RH always seems to ship a Mozilla that's
hopelessly out of date so I usually end up installing my own in
/usr/local and rpm --erasing the one that came with the OS. (Funny
enough, I do that for all of the software that I actually care about.)
Then perhaps this is a good reason to move mozilla to Extras where
someone from the community can better maintain the packages.
Demond
"Extras != Extinction"
12:29 p.m.
On Tue, 22 Feb 2005 08:34:46 -0500, Paul A. Houle <ph18(a)cornell.edu> wrote:
Input methods are a big annoyance to people who don't use
them; when we
installed RH 9 on my sister-in-law's computer, her first complaint was
that it "took too long to boot." I went in and cleaned up the boot
sequence and found that a number of different input methods that I'd never
heard of wasted many seconds at boot time.
They only get installed when you select that language for installation
in Anaconda. You must have selected "install all languages". If you
had selected "English only" none of the CJK input methods would have
been installed.
Regards,
--
Konstantin Ryabitsev
Zlotniks, INC
3:25 p.m.
Le lundi 21 février 2005 à 15:35 -0500, Elliot Lee a écrit :
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
You can view the list of new packages since FC3 (sorted by package size)
at http://people.redhat.com/sopwith/new-packages.txt
Increase the CD size to 700 or 720 Mo ?
FYI,
-- Elliot
3:30 p.m.
Féliciano Matias (feliciano.matias(a)free.fr) said:
> You can view the list of new packages since FC3 (sorted by
package size)
> at http://people.redhat.com/sopwith/new-packages.txt
Increase the CD size to 700 or 720 Mo ?
This was tried around Red Hat Linux 8.0. There were too many failures,
really.
Bill
6:03 p.m.
Le lundi 21 février 2005 à 16:30 -0500, Bill Nottingham a écrit :
Féliciano Matias (feliciano.matias(a)free.fr) said:
> > You can view the list of new packages since FC3 (sorted by package size)
> > at http://people.redhat.com/sopwith/new-packages.txt
>
> Increase the CD size to 700 or 720 Mo ?
This was tried around Red Hat Linux 8.0.
More than 2 years ago. FC3 require at least a pentium class cpu, 64 Mo
of ram, ...
Hardware changes.
There were too many failures,
really.
Mandrake use 700 Mo iso.
Bill
6:06 p.m.
On Tue, Feb 22, 2005 at 01:03:30AM +0100, Féliciano Matias wrote:
Le lundi 21 février 2005 à 16:30 -0500, Bill Nottingham a écrit :
> Féliciano Matias (feliciano.matias(a)free.fr) said:
> > > You can view the list of new packages since FC3 (sorted by package size)
> > > at http://people.redhat.com/sopwith/new-packages.txt
> >
> > Increase the CD size to 700 or 720 Mo ?
>
> This was tried around Red Hat Linux 8.0.
More than 2 years ago. FC3 require at least a pentium class cpu, 64 Mo
of ram, ...
Hardware changes.
That doesn't necessarily mean it gets any better.
We already get far too many bugs about media-check failures.
Doing this is a recipe for disaster.
> There were too many failures,
> really.
Mandrake use 700 Mo iso.
Mandrake also included half-baked patches that ate CD drives
firmware at one point. Just because one distro does something
doesn't mean its a good idea for everyone to do it.
Dave
6:55 p.m.
Le lundi 21 février 2005 à 19:06 -0500, Dave Jones a écrit :
On Tue, Feb 22, 2005 at 01:03:30AM +0100, Féliciano Matias wrote:
> Mandrake use 700 Mo iso.
Mandrake also included half-baked patches that ate CD drives
firmware at one point.
And FC2 eat the mbr. That's not the point.
7:02 p.m.
On Tue, Feb 22, 2005 at 01:55:43AM +0100, Féliciano Matias wrote:
Le lundi 21 février 2005 à 19:06 -0500, Dave Jones a écrit :
> On Tue, Feb 22, 2005 at 01:03:30AM +0100, Féliciano Matias wrote:
> > Mandrake use 700 Mo iso.
>
> Mandrake also included half-baked patches that ate CD drives
> firmware at one point.
And FC2 eat the mbr. That's not the point.
No, it isn't. You chose to delete my second sentence which
contained my point, so I'll reiterate it.
Just because one distro jumps off a cliff does not mean all others have to follow.
When trying to come up with something that works on as many
different combinations of crappy hardware and/or media as
possible, being conservative is the only option.
Dave
7:28 p.m.
Le lundi 21 février 2005 à 20:02 -0500, Dave Jones a écrit :
On Tue, Feb 22, 2005 at 01:55:43AM +0100, Féliciano Matias wrote:
> Le lundi 21 février 2005 à 19:06 -0500, Dave Jones a écrit :
> > On Tue, Feb 22, 2005 at 01:03:30AM +0100, Féliciano Matias wrote:
> > > Mandrake use 700 Mo iso.
> >
> > Mandrake also included half-baked patches that ate CD drives
> > firmware at one point.
>
> And FC2 eat the mbr. That's not the point.
No, it isn't. You chose to delete my second sentence
I don't reply to the second sentence. Any problems ?
which
contained my point, so I'll reiterate it.
Just because one distro jumps off a cliff does not mean all others have to follow.
I don't say Fedora have to follow Mandrake.
I just give a proposition.
It seems you want to wait all other distros to switch to more than +650
Mo to do a new try (last one is for RH8.0).
So, wait and see (I hope other distros don't follow your reasoning).
When trying to come up with something that works on as many
different combinations of crappy hardware and/or media as
possible, being conservative is the only option.
Dave
7:59 a.m.
Bill Nottingham wrote:
Féliciano Matias (feliciano.matias(a)free.fr) said:
>>You can view the list of new packages since FC3 (sorted by package size)
>>at http://people.redhat.com/sopwith/new-packages.txt
>>
>>
>Increase the CD size to 700 or 720 Mo ?
>
>
This was tried around Red Hat Linux 8.0. There were too many failures,
really.
Bill
Whe should try it again. 700MB CDs aren't something rare now ... I
haven't seen any 650MB CD for some months now.And the price is the same
for both, so vendors will not have problems to keep their price.
Increasing the CD size from 650 to 700MB would give us 4*50MB =200MB
more space without increasing the CD count.
8:27 a.m.
Dnia 23-02-2005, śro o godzinie 14:59 +0100, dragoran napisał(a):
Whe should try it again. 700MB CDs aren't something rare now ...
IIRC, it was tried in RHL 7.3.93, it was 2,5 years ago, and even then I
thought the same as you. 2,5 years ago 700 MiB CD-R-s were cheaper than
650 MiB and now it's even hard to get 650 MiB blank disc (with an
exception on some "audio" 74 min CD-R-s worth 10 times the price of
standard 80 min CD-R). My 8-year-old CD burner can burn 90 min CD-R-s
with no problem at all. But if all of it wasn't enough 2 years ago, it's
not enough today, either.
I guess the problems were connected to older hardware, but remmeber
today Fedora doesn't include support for machines older than i586 and
doesn't even include support for some low-end 586s. Remember Anaconda
won't run on system with less than 64 MiB memory (the RULE project
looked nice, but it's not very active nowadays) and for graphical
install (Fedora is the desktop distro, remember) it requires 192 MiB of
system RAM according to FC3 release notes. Do we really still need to
think about machines that cannot use 700 MiB discs? :)
Lam
10:52 a.m.
Leszek Matok wrote:
Dnia 23-02-2005, śro o godzinie 14:59 +0100, dragoran napisał(a):
>Whe should try it again. 700MB CDs aren't something rare now ...
>
>
IIRC, it was tried in RHL 7.3.93, it was 2,5 years ago, and even then I
thought the same as you. 2,5 years ago 700 MiB CD-R-s were cheaper than
650 MiB and now it's even hard to get 650 MiB blank disc (with an
exception on some "audio" 74 min CD-R-s worth 10 times the price of
standard 80 min CD-R). My 8-year-old CD burner can burn 90 min CD-R-s
with no problem at all. But if all of it wasn't enough 2 years ago, it's
not enough today, either.
I guess the problems were connected to older hardware, but remmeber
today Fedora doesn't include support for machines older than i586 and
doesn't even include support for some low-end 586s. Remember Anaconda
won't run on system with less than 64 MiB memory (the RULE project
looked nice, but it's not very active nowadays) and for graphical
install (Fedora is the desktop distro, remember) it requires 192 MiB of
system RAM according to FC3 release notes. Do we really still need to
think about machines that cannot use 700 MiB discs? :)
Lam
Which kind of hardware cannot use 700Mib discs? Can't think of any
(atleast any which has the minimum requiments to run fedora...)
10:55 a.m.
On Wed, 2005-02-23 at 17:52 +0100, dragoran wrote:
>
Which kind of hardware cannot use 700Mib discs? Can't think of any
(atleast any which has the minimum requiments to run fedora...)
People have all sorts of weird hardware on their test systems etc. My
testbox which is a PIII/500Mhz and meeting the minimum requirements
otherwise has a truly ancient 4x cd-drive for example :)
- Panu -
12:57 p.m.
Dnia 23-02-2005, śro o godzinie 18:55 +0200, Panu Matilainen napisał(a):
People have all sorts of weird hardware on their test systems etc.
My
testbox which is a PIII/500Mhz and meeting the minimum requirements
otherwise has a truly ancient 4x cd-drive for example :)
All right, but doesn't
it read 700 MiB CD-R-s? I have one ancient 2x
drive (in a computer which doesn't meet any of the requirements) and it
does! :)
Lam
1:37 p.m.
On Wed, 2005-02-23 at 19:57 +0100, Leszek Matok wrote:
Dnia 23-02-2005, śro o godzinie 18:55 +0200, Panu Matilainen
napisał(a):
> People have all sorts of weird hardware on their test systems etc. My
> testbox which is a PIII/500Mhz and meeting the minimum requirements
> otherwise has a truly ancient 4x cd-drive for example :)
All right, but doesn't it read 700 MiB CD-R-s? I have one ancient 2x
drive (in a computer which doesn't meet any of the requirements) and it
does! :)
Hmm, actually I don't know, haven't tried :) I do know the damn box wont
boot from CD-RW's which is a major PITA for regular rawhide-testing.
- Panu -
1:51 p.m.
Panu Matilainen wrote :
On Wed, 2005-02-23 at 19:57 +0100, Leszek Matok wrote:
> Dnia 23-02-2005, śro o godzinie 18:55 +0200, Panu Matilainen
napisał(a):
> > People have all sorts of weird hardware on their test
systems etc. My
> > testbox which is a PIII/500Mhz and meeting the minimum requirements
> > otherwise has a truly ancient 4x cd-drive for example :)
> All right, but doesn't it read 700 MiB CD-R-s? I have one ancient 2x
> drive (in a computer which doesn't meet any of the requirements) and it
> does! :)
Hmm, actually I don't know, haven't tried :) I do know the damn box wont
boot from CD-RW's which is a major PITA for regular rawhide-testing.
Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing
Rawhide installs on those machines ever since the default boot media
doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide
boot images are just too volatile!
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3
Load : 0.19 0.44 0.41
1:58 p.m.
On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote:
Same here, with some cheapo' 24X CD-ROM readers... I've
stopped testing
Rawhide installs on those machines ever since the default boot media
doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide
boot images are just too volatile!
I'm confused -- who tests rawhide with images anyway? Surely you just do
a network install from an rsync'd install tree, and all you need for
that is a TFTP-capable Grub on a boot floppy (or on a bootable CD)?
--
dwmw2
2:03 p.m.
On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote:
On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote:
> Same here, with some cheapo' 24X CD-ROM readers... I've stopped testing
> Rawhide installs on those machines ever since the default boot media
> doesn't fit on a floppy anymore since they can't be fed CD-RWs and Rawhide
> boot images are just too volatile!
I'm confused -- who tests rawhide with images anyway?
Heh, I do, and apparently Matthias as well.
Surely you just do a network install from an rsync'd install
tree, and
all you need for that is a TFTP-capable Grub on a boot floppy (or on a
bootable CD)?
I've never gotten around to try that :)
- Panu -
2:12 p.m.
Panu Matilainen wrote :
On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote:
> On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote:
> > Same here, with some cheapo' 24X CD-ROM readers... I've stopped
testing
> > Rawhide installs on those machines ever since the default
boot media
> > doesn't fit on a floppy anymore since they can't be fed CD-RWs and
Rawhide
> > boot images are just too volatile!
>
> I'm confused -- who tests rawhide with images anyway?
Heh, I do, and apparently Matthias as well.
Yup :-)
> Surely you just do a network install from an rsync'd install
tree, and
> all you need for that is a TFTP-capable Grub on a boot floppy (or on a
> bootable CD)?
I've never gotten around to try that :)
Neither have I. I guess I should try some day now that I know it can be
done. But for me, the 2nd easiest after pure CD/DVD media install (w/o
network) is booting off the tiny ISO image burnt to a CD-RW and doing a
network install from a simple ftp, http or nfs server.
This reminds me that I've just made a bootable DVD of RHEL4 yesterday, with
all source rpms and html docs... works like a charm! (all new servers I
purchased have DVD-ROMs, and yes, I'm lazy ;-))
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3
Load : 0.51 0.50 0.37
2:18 p.m.
On Wed, Feb 23, 2005 at 10:03:16PM +0200, Panu Matilainen wrote:
On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote:
> On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote:
> > Same here, with some cheapo' 24X CD-ROM readers... I've stopped
testing
> > Rawhide installs on those machines ever since the default boot media
> > doesn't fit on a floppy anymore since they can't be fed CD-RWs and
Rawhide
> > boot images are just too volatile!
>
> I'm confused -- who tests rawhide with images anyway?
Heh, I do, and apparently Matthias as well.
I recently installed the FC3 i386 DVD into a spare LV on my FC3 x86-64 box
using QEMU. A bit slow, but usable. It now boots with either QEMU or
UML. It should be quite easy to create a few scripts to test various
install scenarios.
Bill Rugolsky
2:55 p.m.
On Wed, 23 Feb 2005, Panu Matilainen wrote:
On Wed, 2005-02-23 at 19:58 +0000, David Woodhouse wrote:
> On Wed, 2005-02-23 at 20:51 +0100, Matthias Saou wrote:
> > Same here, with some cheapo' 24X CD-ROM readers... I've stopped
testing
> > Rawhide installs on those machines ever since the default boot media
> > doesn't fit on a floppy anymore since they can't be fed CD-RWs and
Rawhide
> > boot images are just too volatile!
>
> I'm confused -- who tests rawhide with images anyway?
Heh, I do, and apparently Matthias as well.
> Surely you just do a network install from an rsync'd install tree, and
> all you need for that is a TFTP-capable Grub on a boot floppy (or on a
> bootable CD)?
I've never gotten around to try that :)
And if you already have grub installed on the machine another way to do it
is to add something like this:
title anaconda rawhide install
root (hd0,0)
kernel /grub/pxeboot/vmlinuz
initrd /grub/pxeboot/initrd.img
to the grub.conf and put the pxeboot kernel and initrd somewhere grub can
find it. Obviously season it to taste.
If you want to get fancy you can easially call a ks.cfg file to automate
things more.
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
3:36 p.m.
On Mon, 2005-02-21 at 22:25 +0100, Féliciano Matias wrote:
Increase the CD size to 700 or 720 Mo ?
And watch the bugzilla count rise very very quickly. Must use
conservative sizes on the isos given the wide array of burners and media
used.
--
Jesse Keating RHCE (geek.j2solutions.net)
Fedora Legacy Team (www.fedoralegacy.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
3:33 p.m.
* Elliot Lee <sopwith(a)redhat.com> [2005-02-21 15:36]:
Right now eclipse, xfce, xemacs, cfengine, and all the games are leading
candidates. We also may try to start removing stuff from Core in hopes
that it will appear in Extras if someone cares about it.
If Eclipse goes then so does all of the Java stuff since Eclipse is our
bytecode compiler.
Nothing is set in stone, but if you want to write in favor of
keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
I'm sorry, but I think this is silly and leads to finger-pointing. Just
because I work on and use Eclipse and lots of the Java-related stuff
doesn't mean that others don't see other things as being just as useful.
My only other comments are the following:
. there is a very active and vibrant "open source/free java" community
. having these in Core brings in a large segment of Java users who would
normally just download the non-free JVMs
. Eclipse is a well-supported upstream project
. we have people within RH working on all of this
Andrew "I'm sure I've violated trademarks with my use of the j-word"
Overholt
3:37 p.m.
On Mon, 21 Feb 2005, Andrew Overholt wrote:
> Nothing is set in stone, but if you want to write in favor of
keeping
> something, you'll have to suggest something else of equal or greater size
> to axe instead.
I'm sorry, but I think this is silly and leads to finger-pointing.
Just because I work on and use Eclipse and lots of the Java-related
stuff doesn't mean that others don't see other things as being just as
useful.
My only other comments are the following:
. there is a very active and vibrant "open source/free java" community
. having these in Core brings in a large segment of Java users who would
normally just download the non-free JVMs
. Eclipse is a well-supported upstream project
. we have people within RH working on all of this
I agree 100%, and I for one want Java to become much more widely used. At
the same time, we need to stick with a hard constraint of 4 CD's for
Fedora Core, and that means cutting out /something/.
Best,
-- Elliot
4:38 p.m.
On Mon, 2005-02-21 at 16:37 -0500, Elliot Lee wrote:
On Mon, 21 Feb 2005, Andrew Overholt wrote:
> > Nothing is set in stone, but if you want to write in favor of keeping
> > something, you'll have to suggest something else of equal or greater size
> > to axe instead.
>
> I'm sorry, but I think this is silly and leads to finger-pointing.
> Just because I work on and use Eclipse and lots of the Java-related
> stuff doesn't mean that others don't see other things as being just as
> useful.
>
> My only other comments are the following:
>
> . there is a very active and vibrant "open source/free java" community
> . having these in Core brings in a large segment of Java users who would
> normally just download the non-free JVMs
> . Eclipse is a well-supported upstream project
> . we have people within RH working on all of this
I agree 100%, and I for one want Java to become much more widely used. At
the same time, we need to stick with a hard constraint of 4 CD's for
Fedora Core, and that means cutting out /something/.
Where does this hard constraint come from?
Tom
4:53 p.m.
On Mon, 2005-02-21 at 17:38 -0500, Thomas Fitzsimmons wrote:
On Mon, 2005-02-21 at 16:37 -0500, Elliot Lee wrote:
>On Mon, 21 Feb 2005, Andrew Overholt wrote:
>
>> > Nothing is set in stone, but if you want to write in favor of keeping
>> > something, you'll have to suggest something else of equal or greater
size
>> > to axe instead.
>>
>> I'm sorry, but I think this is silly and leads to finger-pointing.
>> Just because I work on and use Eclipse and lots of the Java-related
>> stuff doesn't mean that others don't see other things as being just as
>> useful.
>>
>> My only other comments are the following:
>>
>> . there is a very active and vibrant "open source/free java"
community
>> . having these in Core brings in a large segment of Java users who would
>> normally just download the non-free JVMs
>> . Eclipse is a well-supported upstream project
>> . we have people within RH working on all of this
>
>I agree 100%, and I for one want Java to become much more widely used. At
>the same time, we need to stick with a hard constraint of 4 CD's for
>Fedora Core, and that means cutting out /something/.
>
Where does this hard constraint come from?
Sorry, hadn't read the rest of the thread. I saw Elliot's reasoning and
Alexandre's responses -- where he made all the arguments I was going to
make :)
Tom
3:43 p.m.
On Mon, 2005-02-21 at 16:33 -0500, Andrew Overholt wrote:
I'm sorry, but I think this is silly and leads to
finger-pointing. Just
because I work on and use Eclipse and lots of the Java-related stuff
doesn't mean that others don't see other things as being just as useful.
I agree with Andrew. I can make the argument of why Eclipse should stay;
but I don't know how to make the argument on what should go in equal
size. I can't do the math in such a way, because size != usefulness, at
least I believe, in this context.
Eclipse is important as it is the IDE with the largest open source
developer base; that various open source groups (like classpath) for
example, consistently ask us for improvement to it and rely on it; we do
a lot of work with Eclipse within Red Hat (RHN use it in their Java
stack), and that Eclipse already exists as a product in RHEL and should
have a Fedora Core mirror package. Fedora Core is the only place where
Eclipse exists as a completely free, natively built Java app, and where
we can proudly say, this product is completely free.
Regards
Phil
3:45 p.m.
I should also point out that once I get my new 3.1 M5a RPMs building,
they'll save us about 20 MB. I know it isn't much, but it's something.
Andrew
4:15 p.m.
On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote:
If Eclipse goes then so does all of the Java stuff since Eclipse is
our
bytecode compiler.
Suits me fine.
Java can all live in a java repository. There is a vast amount of it and we
don't have room. Not only that but a java repository set has a natural focus
and since most of it is in java it can run asynchronously to the OS updates too
4:22 p.m.
* Alan Cox <alan(a)redhat.com> [2005-02-21 17:17]:
On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote:
> If Eclipse goes then so does all of the Java stuff since Eclipse is our
> bytecode compiler.
[...]
Java can all live in a java repository. There is a vast amount of it
and we
don't have room.
I would like to see at least a minimal free Java toolchain/environment in
Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
stop with Java? Let's put all python stuff in its own repository as well.
Not only that but a java repository set has a natural focus and
since
most of it is in java it can run asynchronously to the OS updates too
Except for the natively-compiled stuff. Plus, I believe Sopwith said this
kind of 3rd party repository isn't possible ATM.
Andrew
4:24 p.m.
Once upon a time, Andrew Overholt <overholt(a)redhat.com> said:
I would like to see at least a minimal free Java
toolchain/environment in
Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
stop with Java? Let's put all python stuff in its own repository as well.
Well, in part because it wasn't there before (while python, perl, etc.
were). However, right now, Java requires a second C compiler (gcc4),
which is a significant penalty. Once the standard gcc can handle Java,
then maybe some base can be included.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:55 p.m.
* Chris Adams <cmadams(a)hiwaay.net> [2005-02-21 17:29]:
Once upon a time, Andrew Overholt <overholt(a)redhat.com> said:
> I would like to see at least a minimal free Java toolchain/environment in
> Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
> stop with Java? Let's put all python stuff in its own repository as well.
Well, in part because it wasn't there before (while python, perl, etc.
were).
It's sad that much of the java stuff wasn't in FC3 because a lot of it was
in FC2 and prior releases (IIRC). Correct me if I'm wrong here (and I know
that Eclipse wasn't there :) .
However, right now, Java requires a second C compiler (gcc4), which
is a
significant penalty. Once the standard gcc can handle Java, then maybe
some base can be included.
This leads me to one suggestion ...
Andrew
4:25 p.m.
On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote:
I would like to see at least a minimal free Java
toolchain/environment in
Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
stop with Java? Let's put all python stuff in its own repository as well.
The java stuff is new, its huge and its the easiest to push out for now
> Not only that but a java repository set has a natural focus and
since
> most of it is in java it can run asynchronously to the OS updates too
Except for the natively-compiled stuff. Plus, I believe Sopwith said this
kind of 3rd party repository isn't possible ATM.
Then how are we proposing to do Fedora extras ? It is definitely possible.
A Java themed disk may be trickier as a part of base.
If we can't do it then in my opinion its even more critical we keep the current
stuff and java should go into fedora extras or Fedora 5 when the tools are
fixed.
I'd much rather see a Java yum repository and a non-install time java .iso
(which is easy to do as a standalone)
5:26 p.m.
The java stuff is new, its huge and its the easiest to push out for
now
Easiest in what metric? I guess the confusing thing here is if this
really was a slim down of Fedora (IE AbiWord vs OpenOffice, and other
arguments throughout the thread), then there would be plenty of room;
there are lots of cross-over areas where duplication exists throughout
core. It's difficult to rank one language, package, or set of tools over
another, but for me, personally, a free java stack is of great
importance. And that includes Eclipse which is integral to that area.
Regards
Phil
> > Not only that but a java repository set has a natural focus and since
> > most of it is in java it can run asynchronously to the OS updates too
>
> Except for the natively-compiled stuff. Plus, I believe Sopwith said this
> kind of 3rd party repository isn't possible ATM.
Then how are we proposing to do Fedora extras ? It is definitely possible.
A Java themed disk may be trickier as a part of base.
If we can't do it then in my opinion its even more critical we keep the current
stuff and java should go into fedora extras or Fedora 5 when the tools are
fixed.
I'd much rather see a Java yum repository and a non-install time java .iso
(which is easy to do as a standalone)
5:36 p.m.
Phil Muldoon wrote:
It's difficult to rank one language, package, or set of tools over
another,
No, it's really not. Useful metrics include:
- how many of the critical packages already depend on them;
- how many widely-used packages are written in them.
Regardless of your opinions of the merits of the Java language, it's
just not heavily used by any of the things that desktop users bump into
every day. (Except, *possibly*, web page applets, but I gather you're
talking about a much bigger scope than that.)
You may argue that it would be more heavily used if it was more widely
available, but I don't think language advocacy is a good enough reason
to make people download more stuff that they don't *yet* want or need.
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
5:58 p.m.
Regardless of your opinions of the merits of the Java language,
it's
just not heavily used by any of the things that desktop users bump into
every day. (Except, *possibly*, web page applets, but I gather you're
talking about a much bigger scope than that.)
One of the products we have in RHEL is Red Hat Developer Suite, which is
based on java. We do active development on this, and we'd like to bring
it to Fedora. There is a huge community of Eclipse users out there.
Also, there is a large sphere of java usage out there. I'm not going to
argue usage metrics, but suffice to say there is enough usage that
warrants interest im(h)o.
You may argue that it would be more heavily used if it was more
widely
available, but I don't think language advocacy is a good enough reason
to make people download more stuff that they don't *yet* want or need.
I'm trying to avoid turning this into advocacy or philosophy of
languages. But having a free java solution in hand, that could be put in
Fedora, but we choose not to (and instead invite people to seek non open
java solutions elsewhere) just sends a conflicting message. The open
source java solution needs work. The open source Eclipse IDE needs work.
These are already well established and populated projects.
Regards
Phil
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
6:52 p.m.
Phil Muldoon wrote:
I'm trying to avoid turning this into advocacy or philosophy of
languages. But having a free java solution in hand, that could be put in
Fedora, but we choose not to (and instead invite people to seek non open
java solutions elsewhere) just sends a conflicting message. The open
source java solution needs work. The open source Eclipse IDE needs work.
These are already well established and populated projects.
There's a lot of space between "include it on the Fedora install CDs
that absolutely everyone who uses Fedora must acquire" and invite
people to use non-free solutions." For example, "put it on an
optional Fedora Java CD."
--
Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/
jwz(a)dnalounge.com http://www.dnalounge.com/
http://jwz.livejournal.com/
7:19 p.m.
There's a lot of space between "include it on the Fedora
install CDs
that absolutely everyone who uses Fedora must acquire" and invite
people to use non-free solutions." For example, "put it on an
optional Fedora Java CD."
You know in the long term, we agree. I absolutely believe Fedora should
be slimmer (even to the point of one basic CD and everything else being
optional). However, the argument that: "include it on the Fedora install
CDs that absolutely everyone who uses Fedora must acquire" is sort of
bogus when you cast your eyes over 4 CDs worth of Fedora Core software
that everyone in going to acquire anyway, and that there is no room for
Eclipse and the related open source Java stack there. In the future, I
could see the Java CD option being a great option. But this exercise is
getting FC4 down to a fixed size for the upcoming deadline.
Right now the most compelling argument is that it is big, and therefore
a good target to clip. There's no other metric being used, like usage in
the community, or how active a project it is, or value to the open
source community. There might be merit in the pure size argument; we all
have to make hard decisions in the light of deadlines, but I'm trying to
appeal to the notion that the size of the install is worth it, and bring
valuation to other aspects of Eclipse. In the future, say FC5 and beyond
there is much merit in the division of layers into separate CDs/Repos.
Regards
Phil
11:47 a.m.
On Mon, 21 Feb 2005, Phil Muldoon wrote:
> Regardless of your opinions of the merits of the Java language,
it's
> just not heavily used by any of the things that desktop users bump into
> every day. (Except, *possibly*, web page applets, but I gather you're
> talking about a much bigger scope than that.)
One of the products we have in RHEL is Red Hat Developer Suite, which is
based on java. We do active development on this, and we'd like to bring
it to Fedora. There is a huge community of Eclipse users out there.
Also, there is a large sphere of java usage out there. I'm not going to
argue usage metrics, but suffice to say there is enough usage that
warrants interest im(h)o.
Java is critical because it's the only language and development
environment that's a serious alternative to .NET.
So why am I leaning towards pulling eclipse (and Java stuff) out of
FC4test1? Because it seems like that's part of the best short-term
solution to a short-term problem. All we need to do is have FC4 come out
on four CDs. If we can wind up removing enough "other" stuff from FC to
allow putting eclipse back for test2, that'll be awesome. These removals
aren't permanent by any means, but for now they seem the best way to go.
We already know what the long-term solution is - multi-repo support in
anaconda, and moving stuff to Extras (hopefully allowing us to slim Core
down even more).
Another problem is the distribution of ecj - having the main Java compiler
be part of the eclipse tarball is really an aweful situation. Fortunately,
gcjx will help solve this - hopefully we won't need ecj at all in the
future.
Cheers,
-- Elliot
12:47 p.m.
Once upon a time, Elliot Lee <sopwith(a)redhat.com> said:
We already know what the long-term solution is - multi-repo support
in
anaconda, and moving stuff to Extras (hopefully allowing us to slim Core
down even more).
What exactly is "multi-repo support in anaconda"? Does that mean that
all installs will have to be network installs and anaconda will download
stuff from different repos during install?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:49 p.m.
On Tue, 2005-02-22 at 12:47 -0600, Chris Adams wrote:
Once upon a time, Elliot Lee <sopwith(a)redhat.com> said:
> We already know what the long-term solution is - multi-repo support in
> anaconda, and moving stuff to Extras (hopefully allowing us to slim Core
> down even more).
What exactly is "multi-repo support in anaconda"? Does that mean that
all installs will have to be network installs and anaconda will download
stuff from different repos during install?
no. It means that anaconda will not have to know about all possible cds
in the hdlist information on the first cd.
it will be able to assemble a list of packages from the individual
metadata on a set of cds (or, alternatively, from network repos)
-sv
12:51 p.m.
Once upon a time, seth vidal <skvidal(a)phy.duke.edu> said:
no. It means that anaconda will not have to know about all possible
cds
in the hdlist information on the first cd.
it will be able to assemble a list of packages from the individual
metadata on a set of cds (or, alternatively, from network repos)
Okay, but since there are not going to be ISOs of Fedora Extras, we're
back to requiring a high-speed network connection to upgrade.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
12:53 p.m.
On Tue, Feb 22, 2005 at 12:51:58PM -0600, Chris Adams wrote:
> it will be able to assemble a list of packages from the
individual
> metadata on a set of cds (or, alternatively, from network repos)
Okay, but since there are not going to be ISOs of Fedora Extras, we're
back to requiring a high-speed network connection to upgrade.
Or for someone to write 'extras to iso'
9:58 p.m.
On Mon, 21 Feb 2005 15:36:42 -0800, you wrote:
Phil Muldoon wrote:
>
> It's difficult to rank one language, package, or set of tools over
> another,
No, it's really not. Useful metrics include:
- how many of the critical packages already depend on them;
- how many widely-used packages are written in them.
None of which requires that the languages themselves need to be
included.
Regardless of your opinions of the merits of the Java language,
it's
just not heavily used by any of the things that desktop users bump into
every day. (Except, *possibly*, web page applets, but I gather you're
talking about a much bigger scope than that.)
And how many desktop users bump into or need gcc? Apache? Sendmail?
Fedora, like almost any of the Linux distributions is aimed at several
different audiences. If one of those target audiences is developers
then Java is a valid thing to include. Otherwise remove all the
compilers and just leave in the required runtimes.
You may argue that it would be more heavily used if it was more
widely
available, but I don't think language advocacy is a good enough reason
to make people download more stuff that they don't *yet* want or need.
There are a lot of people who need Java, whether it be students at
school or working developers or anyone else who is interested.
Perhaps most importantly though is that Novell is pushing Mono (C#)
and Red Hat is pushing Java. If Red Hat doesn't even include Java in
Fedora then that compromises the Red Hat message. Is this advocacy?
Yes. But sometimes you just can't avoid it.
Gerald
12:44 p.m.
Le lundi 21 février 2005 à 22:58 -0500, Gerald Henriksen a écrit :
Perhaps most importantly though is that Novell is pushing Mono (C#)
and Red Hat is pushing Java. If Red Hat doesn't even include Java in
Fedora then that compromises the Red Hat message. Is this advocacy?
Yes. But sometimes you just can't avoid it.
Moreover Red Hat pushes *free* java, and there are precious few other
supporters.
At one point you have to be realistic - if you want linux to keep the
traction it currently has in the server/entreprise space (traction of
which FC is a direct side effect) you need a high-level langage with
rich libraries such as java. If you want this successful linux to be
free that includes the high-level langage stack itself. For this to
happen someone that cares about the free part and has a large developer
mindshare must release this stack in a form that does not require days
of installations to start coding. Right now that means RH+FC+gcj.
Sure you can cull java. Users won't care. Don't come back crying by
FC5/6 time when RHEL goes closed java, FC has to accept mono, the free
java stacks fades like blackdown, and a lot of talented people that
contributed to it are lost to the FOSS movement (getting free java to
the level it is now is no small feat, the easy way is just to accept
being herded by Sun and big vendors, if after all this work an
emblematic Linux player like Red Hat closes the door I can imagine a lot
of people will give up in disgust).
One of the reasons I like FC (and Red Hat Linux before that) is it dares
taking difficult decisions like going full UTF-8, testing SELinux,
knowing the eventual result is worth the pain of including stuff no one
tried before. I'd be disappointed if FC where to lose that long-term
view and refuse to include stuff because it's not mainstream yet.
Without early adopters like FC Linux development will slow down
drastically.
--
Nicolas Mailhot
2:05 p.m.
Le mercredi 23 février 2005 à 19:44 +0100, Nicolas Mailhot a écrit :
One of the reasons I like FC (and Red Hat Linux before that) is it
dares
taking difficult decisions like going full UTF-8, testing SELinux,
knowing the eventual result is worth the pain of including stuff no one
tried before.
+10 :-)
10:02 a.m.
On Mon, 2005-02-21 at 23:25, Alan Cox wrote:
A Java themed disk may be trickier as a part of base.
I'd much rather see a Java yum repository and a non-install time
java .iso
(which is easy to do as a standalone)
Yeah, isn't that what the "Additional CDs" button in firstboot is for
anyway? Though. this means not telling Anaconda about the Java stuff,
which has the disadvantage of excluding Java in network installs.
/abo
4:28 p.m.
On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote:
> Java can all live in a java repository. There is a vast amount
of it and we
> don't have room.
I would like to see at least a minimal free Java toolchain/environment in
Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
stop with Java? Let's put all python stuff in its own repository as well.
The important difference here is that system-config-*, yum, up2date, rhn-applet and
various other 'core' components are written in python, not java, so the
comparison is meaningless imo.
Dave
4:46 p.m.
* Dave Jones <davej(a)redhat.com> [2005-02-21 17:29]:
On Mon, Feb 21, 2005 at 05:22:00PM -0500, Andrew Overholt wrote:
> > Java can all live in a java repository. There is a vast amount of it and we
> > don't have room.
>
> I would like to see at least a minimal free Java toolchain/environment in
> Fedora. This is a slippery slope that leads to language-ism, IMHO. Why
> stop with Java? Let's put all python stuff in its own repository as well.
The important difference here is that system-config-*, yum, up2date, rhn-applet and
various other 'core' components are written in python, not java, so the
comparison is meaningless imo.
I obviously wasn't serious :) .
I really do think that a re-evaluation of what is 'Core' and what is
'Extras' (which I really do believe is a misnomer, BTW) is necessary. Or
at least a clarification.
Andrew
4:40 p.m.
Alan Cox writes:
On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote:
> If Eclipse goes then so does all of the Java stuff since Eclipse is our
> bytecode compiler.
Suits me fine.
Java can all live in a java repository. There is a vast amount of it and we
don't have room. Not only that but a java repository set has a natural focus
and since most of it is in java it can run asynchronously to the OS updates too
I think that it makes sense to have just a JVM in the base distro.
Of course, we don't really have a JVM, last time I checked.
But, in theory, it makes sense to have a JVM in the distro, with all the
java stuff somewhere else.
7:47 p.m.
On Mon, Feb 21, 2005 at 04:33:54PM -0500, Andrew Overholt wrote:
> If Eclipse goes then so does all of the Java stuff since Eclipse is our
> bytecode compiler.
Suits me fine.
Java can all live in a java repository. There is a vast amount of it and we
don't have room. Not only that but a java repository set has a natural focus
and since most of it is in java it can run asynchronously to the OS updates too
Is there any way to put all the java stuff on it own on cd 5 and call
it 'CD 5 - Java' with a comment in the release notes saying 'if you
don't want or need Java related bits you don't need to download CD5'
With fear of beating a dead horse - all the Gnome 1 stuff (excluding
gtk1/xmms - not going to start that flame again :-) comes to around
20Mb. And by moving it to extras might encourage gnucash to bring on
the gtk2 release. And afterall we are lead to believe that extras
isn't second grade.
Also the original mozilla is around 16 meg as well and with 3 other
browsers (firefox, epiphany and the kde konkeror (sp?) do we need it.
Also is there a valid reason for have 3 versions of gcc, 5 versions of
automake and 2 versions of autoconf?
Peter
Pete
5:21 a.m.
On Tue, 2005-02-22 at 09:47 +0800, Peter Robinson wrote:
Is there any way to put all the java stuff on it own on cd 5 and call
it 'CD 5 - Java' with a comment in the release notes saying 'if you
don't want or need Java related bits you don't need to download CD5'
As I understand it, this will be possible in FC5 when Extras can be
supported similarly. I think we should wait for FC5 before undertaking
the task of slimming i386 down to 4 CDs. The PPC and x86_64 releases are
going to be 5CDs anyway.
--
dwmw2
7:56 a.m.
On Tue, Feb 22, 2005 at 11:21:13AM +0000, David Woodhouse wrote:
As I understand it, this will be possible in FC5 when Extras can be
supported similarly. I think we should wait for FC5 before undertaking
the task of slimming i386 down to 4 CDs. The PPC and x86_64 releases are
going to be 5CDs anyway.
Unless I am very much mistaken, this is possible right now. If you put all
the Java stuff on CD 5 (for example), and do not select any of it in the
anaconda, then anaconda will not request the fifth CD, so you do not need
it. In a similar way, I'd put all the development stuff on a seperate CD,
too (*-devel, gcc), so you'd be able to skip downloading that if you know
that you'd want a non-developer desktop, anyway.
And yes, I personally consider a Unix without a compiler crippled. But I
do not mind downloading that extra CD, either. But for the people I give
FC to (my girlfriend, my parents...) the devel part is just wasted space.
8:11 a.m.
On Tue, 22 Feb 2005 14:56:27 +0100, Ralf Ertzinger
Unless I am very much mistaken, this is possible right now. If you
put all
the Java stuff on CD 5 (for example), and do not select any of it in the
anaconda, then anaconda will not request the fifth CD, so you do not need
it. In a similar way, I'd put all the development stuff on a seperate CD,
too (*-devel, gcc), so you'd be able to skip downloading that if you know
that you'd want a non-developer desktop, anyway.
Careful, you have to consider the problems of space packing. Moving
-devel off onto its own cd and java on its own cd.. etc..etc.. might
actually end up with 6+ partially full cds. Once you start grouping
things into cds based function there's no garuntee you'll be able to
pack them as efficiently into the same number of isos. I'm not saying
this is a bad idea... im just saying that using this approach to drill
down to an 1 cd installable desktop.. might end up costing you 7 or 8
partially full cd iso images in the end if the requirement to ship all
of Core on isos remains.
-jef
10:56 a.m.
Jeff Spaleta wrote:
On Tue, 22 Feb 2005 14:56:27 +0100, Ralf Ertzinger
>Unless I am very much mistaken, this is possible right now. If you put all
>the Java stuff on CD 5 (for example), and do not select any of it in the
>anaconda, then anaconda will not request the fifth CD, so you do not need
>it. In a similar way, I'd put all the development stuff on a seperate CD,
>too (*-devel, gcc), so you'd be able to skip downloading that if you know
>that you'd want a non-developer desktop, anyway.
Careful, you have to consider the problems of space packing. Moving
-devel off onto its own cd and java on its own cd.. etc..etc.. might
actually end up with 6+ partially full cds. Once you start grouping
things into cds based function there's no garuntee you'll be able to
pack them as efficiently into the same number of isos. I'm not saying
this is a bad idea... im just saying that using this approach to drill
down to an 1 cd installable desktop.. might end up costing you 7 or 8
partially full cd iso images in the end if the requirement to ship all
of Core on isos remains.
-jef
And would it be a problem to end with 8 partially full CDs?
We could also make a 3/4 CD set for every use case and one DVD for the
magazines/books/stores.
What would have then is:
50% of the users only need to download CD 1 and 2
30% install CD 1-3 of their use case
15% install CD 1-4 of their use case
5% want everything (the DVD)
(numbers made up / guessed) :)
11:16 a.m.
On Tue, 22 Feb 2005 17:56:43 +0100, Harald Hoyer <harald(a)redhat.com> wrote:
And would it be a problem to end with 8 partially full CDs?
No matter what Red Hat decides to do for Fedora Core.. you will have problems.
Pick your poison.. i suggest the one that tastes like cherries.
We could also make a 3/4 CD set for every use case and one DVD for the
magazines/books/stores.
Long term... i think this is the start of an equitable solution. If
Core is going to continue to be 'general purpose' there must be a way
to repackage Core for 'specific purposes.' However from my
perspective over here on the grassy knoll outside the red hat
fenceline... I honestly don't think Red Hat currently has the ability
or political will to expend the resources to make spinning up mutliple
'official' usage case mediasets. For this to work, I believe that
the sheparding of use case mediasets needs to be expanded to include
community and the trademark guidelines re-worked to allow for anyone
in the community to pull packages from Core and Extras to create
use-case media sets as they see fit without official blessing.
I would point to mozilla's new tiered trademark policy that allows for
community editions to be built as an example of how to expand
trademark policy in a community inclusive way to allow community to
accomplish use-case oriented mediasets that are instantly
distinguishable from the 'official' sets. Mozilla's model would lead
to things named like Community Core - Usage Case Edition Release
Number, for community built mediasets that include only unmodified
Core packages to serve a defined usage role. Community Core - Mail
Server Edition Release 7.003 for example.
-jef
What would have then is:
50% of the users only need to download CD 1 and 2
30% install CD 1-3 of their use case
15% install CD 1-4 of their use case
5% want everything (the DVD)
(numbers made up / guessed) :)
4:50 p.m.
On Mon, 2005-02-21 at 16:33 -0500, Andrew Overholt wrote:
* Elliot Lee <sopwith(a)redhat.com> [2005-02-21 15:36]:
>
> Right now eclipse, xfce, xemacs, cfengine, and all the games are leading
> candidates. We also may try to start removing stuff from Core in hopes
> that it will appear in Extras if someone cares about it.
If Eclipse goes then so does all of the Java stuff since Eclipse is our
bytecode compiler.
Is it really necessary that we have mozilla and firefox, thunderbird and
evolution, abiword, gnumeric and OpenOffice.org, there are a lot of
areas with redundant packages in core. As well larger games like
tuxracer while nice aren't really necessary for something like core.
I'd hate for these packages which aren't adding much in the way of
functionality to push out java which really is missing functionality.
As it is currently a jvm is one of the first things downloaded by a
significant portion of users and java is used by a wide variety of apps.
I think functionality as important as java really needs to be left in
core.
For the aid of the discussion you can find all of the packages currently
in the development tree here.
http://download.fedora.redhat.com/pub/fedora/linux/core/development/
Aaron
5:04 p.m.
On Mon, Feb 21, 2005 at 05:50:03PM -0500, Aaron Luchko wrote:
Is it really necessary that we have mozilla and firefox, thunderbird
and
I recently had a situation where a .swf wouldn't work using the
Macromedia repo's flash plugin on firefox, but it worked fine in
mozilla. Not sure why.
evolution, abiword, gnumeric and OpenOffice.org, there are a lot of
areas with redundant packages in core. As well larger games like
tuxracer while nice aren't really necessary for something like core.
I agree that games aren't really "core" and could be moved to Extras.
Maybe just keep the basic games that are included with GNOME/KDE.
As it is currently a jvm is one of the first things downloaded by a
significant portion of users and java is used by a wide variety of apps.
I think functionality as important as java really needs to be left in
core.
If I'm not mistaken, I don't think the stuff in FC-devel can be used
to replace a jvm for web applets.
3:34 p.m.
I know this will be an unpopular suggestion, but 300MB is a lot to
loose. So I'm just throwing this out there.....
KDE by my estimates is 350mb, move it into extras.
Cheers,
Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
--
Eric Warnke Computer Programmer / Systems Analyst
eric(a)snowmoon.com 518-727-1523
GPG Fingerprint: E7C5 615B 2115 C9D9 7E75 5088 930B 91E5 218B 6259
'There is always an easy solution to every human problem -- neat,
plausible, and wrong.' - H.L. Mencken
4:17 a.m.
On Wednesday 23 February 2005 09:47, Emmanuel Seyman wrote:
On Wed, Feb 23, 2005 at 10:30:04AM +0100, Felipe Alfaro Solana
wrote:
> No, instead move GNOME.
Gnome is the default desktop. It makes better sense to move KDE.
Are we condemned to have this same discussion for every version of the
Fedora Core? ;-)
Both GNOME and KDE are more than simple programs they have all the
libraries associated. Is that framework what we want to exclude from Fedora
Core? :-)
Emmanuel
--
José Abílio
3:37 p.m.
On Monday 21 February 2005 21:35, Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
please not
the gnome/kde games, but some of the bigger ones (bzflag,
tuxracer,freeciv,...)
not xfce (the only thing usable on old hardware)
try to start removing stuff from Core in hopes that it will appear
in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
xscreensaver-gl-extras (could go in extras)
desktop-backgrounds-extra (could go in extras)
ggv,gpdf (I think evince can hanlde most stuff, and we still have gs and xpdf)
rpmdb-fedora (is this used anywhere else than rpm --redhatprovides/requires?)
kdeartwork-icons (could go in extras)
comps (what needs/uses this?)
HelixPlayer and/or xmms
samba-swat (it's as useful as the man page but not much more)
nedit (old motif stuff)
ncftp (lftp does the same)
--
http://LinuxWiki.org/RonnyBuchmann
11:03 a.m.
HelixPlayer and/or xmms
HelixPlayer, perhaps. But *not* xmms. The # of new users on
fedora-list and #fedora asking about mp3 support is already too high.
I understand the reasoning for separating xmms and xmms-mp3 (although
I think putting a warning on xmms telling how to get mp3 support would
be nice) but removing xmms altogether will just make things worse.
--
MG
1:05 p.m.
Dnia 23-02-2005, śro o godzinie 11:03 -0600, m g napisał(a):
I think putting a warning on xmms telling how to get mp3 support
would
be nice
Isn't it called "contributory infrigement"?
I vote for non-US version of Fedora Core including all the goodies we
Europeans can have legally :)
Lam
1:08 p.m.
Leszek Matok wrote:
Dnia 23-02-2005, śro o godzinie 11:03 -0600, m g napisał(a):
>I think putting a warning on xmms telling how to get mp3 support would
>be nice
Isn't it called "contributory infrigement"?
I vote for non-US version of Fedora Core including all the goodies we
Europeans can have legally :)
You mean something like
http://rpm.livna.org/
(-:
-- Rex
1:10 p.m.
On Wed, 2005-02-23 at 20:05 +0100, Leszek Matok wrote:
I vote for non-US version of Fedora Core including all the goodies
we
Europeans can have legally :)
There's not _that_ much which we in the Free World would add back to
Fedora -- what's wrong with having it in Livna?
--
dwmw2
1:15 p.m.
Dnia 23-02-2005, śro o godzinie 19:10 +0000, David Woodhouse napisał(a):
There's not _that_ much which we in the Free World would add back
to
Fedora -- what's wrong with having it in Livna?
Anvil's repo is almost all
I need, but I'd like to have the packages on
the CD, I don't want to be ashamed every time I give my copy of Fedora
to someone and this someone comes back and says "your stupid Linux
doesn't even play MP3-s". I play making such disks for my own joy, but
I'm not the only person who can benefit from having such version. It's
not a big deal to do this kind of isos and populate among the "more
free" mirrors.
Lam
1:24 p.m.
On Wed, 2005-02-23 at 20:15 +0100, Leszek Matok wrote:
Anvil's repo is almost all I need, but I'd like to have the
packages
on the CD, I don't want to be ashamed every time I give my copy of
Fedora to someone and this someone comes back and says "your stupid
Linux doesn't even play MP3-s". I play making such disks for my own
joy, but I'm not the only person who can benefit from having such
version. It's not a big deal to do this kind of isos and populate
among the "more free" mirrors.
As I understand it, FC5's anaconda should be able to handle additional
repositories like Extras and Livna at install time -- isn't that enough?
--
dwmw2
1:28 p.m.
Dnia 23-02-2005, śro o godzinie 19:24 +0000, David Woodhouse napisał(a):
As I understand it, FC5's anaconda should be able to handle
additional
repositories like Extras and Livna at install time -- isn't that enough?
Extras
- yes, Livna - no. Only option for non-US repositories will be to
enter its address by hand (and how can Linux newbie in Europe know the
address of additional repository containing MP3 support if they don't
even know MP3-s don't work out of the box?).
Lam
1:49 p.m.
On Wed, 2005-02-23 at 20:28 +0100, Leszek Matok wrote:
Extras - yes, Livna - no. Only option for non-US repositories will be
to
enter its address by hand (and how can Linux newbie in Europe know the
address of additional repository containing MP3 support if they don't
even know MP3-s don't work out of the box?).
You seem to know more about how anaconda will work with multiple
repositories than I do. Given that the Extras ISOs will be built
separately from the Core install ISOs, how will it know about them and
have them hard-coded? Surely it has to be flexible enough to accept
extra CDs which are generated _later_ than the Core install tree?
--
dwmw2
2:07 p.m.
Dnia 23-02-2005, śro o godzinie 19:49 +0000, David Woodhouse napisał(a):
Given that the Extras ISOs will be built
separately from the Core install ISOs, how will it know about them and
have them hard-coded? Surely it has to be flexible enough to accept
extra CDs which are generated _later_ than the Core install tree?
Yes, but Extras
will be distributed by the same vendor, and Livna won't.
The user will have to know about it and download additional iso from
some site he doesn't know about and burn additional few-megabytes CD, or
type in the yum/apt repository address of the same site (which he
doesn't know about) upon/after install.
Although it's possible to respin FC including Livna or Freshrpms, no
magazine I know of have decided to do that on their cover disks,
providing Fedora users incomplete desktop experience, while the other
cover distros seem much more complete out of the box. I can make such
disks and sell them/give them out to my friends, but how many people
will still think Fedora simply "doesn't work"?
Correct me if I'm wrong, but is Fedora aiming at being the desktop
distro to steal marketshare from Windows, or being a distro for
enthusiast Linux gurus loving to type three-line commands on their
terminals in order to print file or burn it onto CD-R? I thought we're
at least aiming to eventually becoming the former...
Lam
3:08 p.m.
On Wed, 23 Feb 2005 21:07:13 +0100, Leszek Matok wrote:
Dnia 23-02-2005, __ro o godzinie 19:49 +0000, David Woodhouse
napisa__(a):
> Given that the Extras ISOs will be built
> separately from the Core install ISOs, how will it know about them and
> have them hard-coded? Surely it has to be flexible enough to accept
> extra CDs which are generated _later_ than the Core install tree?
Yes, but Extras will be distributed by the same vendor, and Livna won't.
The user will have to know about it and download additional iso from
some site he doesn't know about and burn additional few-megabytes CD,
Users of a popular other operating system do that always for many (!)
additional applications. Widely spread FAQs and HOWTOs will guide newbies
appropriately, e.g. like http://fedorafaq.org does nowadays already.
3:30 p.m.
Dnia 23-02-2005, śro o godzinie 22:08 +0100, Michael Schwendt napisał
(a):
Users of a popular other operating system do that always for many
(!)
additional applications.
Well, you may be right about applications which aren't
present on the
system. But XMMS is expected to be included and it is included, only it
doesn't play most of music people have in their libraries. It can
encourage them to encode oggs using grip if they have the CD-s (it only
takes time), but some of their music will remain in MP3-s. Inclusion of
castrated XMMS version makes impression that Linux has WinAmp-clone,
only it doesn't play music :) Of course this is the first impression,
but first impression is the most important! :)
Widely spread FAQs and HOWTOs will guide newbies
appropriately, e.g. like http://fedorafaq.org does nowadays already.
Straight that
up for me again: if fedorafaq.org tells about ways to
enable MP3 support and others, can Red Hat make link to it from the
Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or
would it be contributory infringement?
Lam
3:57 p.m.
On Wed, 23 Feb 2005 22:30:31 +0100, Leszek Matok wrote:
Dnia 23-02-2005, __ro o godzinie 22:08 +0100, Michael Schwendt
napisa__
(a):
> Users of a popular other operating system do that always for many (!)
> additional applications.
Well, you may be right about applications which aren't present on the
system. But XMMS is expected to be included and it is included, only it
doesn't play most of music people have in their libraries. It can
encourage them to encode oggs using grip if they have the CD-s (it only
takes time), but some of their music will remain in MP3-s. Inclusion of
castrated XMMS version makes impression that Linux has WinAmp-clone,
only it doesn't play music :) Of course this is the first impression,
but first impression is the most important! :)
No. The first impression is a graphical dialogue which pops up and
explains the situation. Because exactly that is what happens in XMMS when
user tries to play an mp3 file. User will then see where to get a full
version of XMMS or an alternative media player. E.g. rpm.livna.org has
BMP now.
> Widely spread FAQs and HOWTOs will guide newbies
> appropriately, e.g. like http://fedorafaq.org does nowadays already.
Straight that up for me again: if fedorafaq.org tells about ways to
enable MP3 support and others, can Red Hat make link to it from the
Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or
would it be contributory infringement?
IANAL. Future will tell us.
It's not possible to generalise. With regard to mp3, I believe that
pointing end-users to software like XMMS can be done.
--
http://www.newsforge.com/business/02/08/29/1633205.shtml?tid=17
"No license fee is expected for desktop software mp3 decoders/players that
are distributed free-of-charge via the Internet for personal use of
end-users."
9:54 p.m.
On Wed, 2005-02-23 at 22:30 +0100, Leszek Matok wrote:
> Widely spread FAQs and HOWTOs will guide newbies
> appropriately, e.g. like http://fedorafaq.org does nowadays already.
Straight that up for me again: if fedorafaq.org tells about ways to
enable MP3 support and others, can Red Hat make link to it from the
Mozilla home page (file:///usr/share/doc/HTML/index.html in FC3) or
would it be contributory infringement?
Apparently so; we can't link to fedorafaq.org or even point folk to
livna
In fact, Ask Shadowman answers this rather nicely:
http://www.redhat.com/magazine/004feb05/departments/ask_shadowman/
(last question)
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
"First they ignore you, then they laugh at you, then they fight you,
then you win." -- Mohandas Gandhi
2:21 p.m.
Once upon a time, David Woodhouse <dwmw2(a)infradead.org> said:
Given that the Extras ISOs will be built
separately from the Core install ISOs,
There are no plans currently to make ISOs of Extras.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
2:49 p.m.
On Wed, 2005-02-23 at 14:21 -0600, Chris Adams wrote:
Once upon a time, David Woodhouse <dwmw2(a)infradead.org> said:
> Given that the Extras ISOs will be built
> separately from the Core install ISOs,
There are no plans currently to make ISOs of Extras.
I plan to make CDs of Extras/PPC. I don't know if people plan to do them
for other architectures, but I suspect it'll happen.
--
dwmw2
3:59 p.m.
On Wed, Feb 23, 2005 at 02:21:01PM -0600, Chris Adams wrote:
Once upon a time, David Woodhouse <dwmw2(a)infradead.org> said:
> Given that the Extras ISOs will be built
> separately from the Core install ISOs,
There are no plans currently to make ISOs of Extras.
There are no plans for anyone in Red Hat to make ISO's of extras..
2:16 p.m.
On Wed, 23 Feb 2005 20:15:27 +0100, Leszek Matok wrote:
Dnia 23-02-2005, __ro o godzinie 19:10 +0000, David Woodhouse
napisa__(a):
> There's not _that_ much which we in the Free World would add back to
> Fedora -- what's wrong with having it in Livna?
Anvil's repo is almost all I need, but I'd like to have the packages on
the CD, I don't want to be ashamed every time I give my copy of Fedora
to someone and this someone comes back and says "your stupid Linux
doesn't even play MP3-s".
Then do a better job at educating that person about extra packages and
how to get them easily. His choice of words ("stupid") is inappropriate
already. More friendlier of him would be to ask about how to add mp3
support, in case you had not warned him earlier.
2:52 p.m.
Dnia 23-02-2005, śro o godzinie 21:16 +0100, Michael Schwendt napisał
(a):
Then do a better job at educating that person about extra packages
and
how to get them easily. His choice of words ("stupid") is inappropriate
already. More friendlier of him would be to ask about how to add mp3
support, in case you had not warned him earlier.
In fact I warn and give
instruction how to install xmms-mp3, disable
librh_mp3.so, install mplayer etc., but only to few of my friends who
want to try out Linux and can count on my support. I don't sell copies,
but I can imagine the hell any Fedora CD/DVD seller has to go through :)
The typical user who wants to try out Fedora is disappointed when they
install for the first time. I for one don't want Linux to be 31337, I
want it to be seen as an alternative to Windows or MacOS even by
Windows/MacOS users, and that can happen only if such user doesn't get
disgusted after even test installation. I don't care if the users go
back to their systems if only they get the impression that Linux works.
The bad thing is only if they go back and say "I had Linux on my box
once, but it doesn't do this, this and this, and I had to find some
third-party packages which I didn't know how to install, so it sucks".
Of course the technical-savvy users will find the packages they need and
find instructions on how to install them, but I thought we're aiming at
making Fedora every-user-friendly :)
Lam
3:18 p.m.
On Wed, 23 Feb 2005 21:52:35 +0100, Leszek Matok wrote:
Dnia 23-02-2005, __ro o godzinie 21:16 +0100, Michael Schwendt
napisa__
(a):
> Then do a better job at educating that person about extra packages and
> how to get them easily. His choice of words ("stupid") is inappropriate
> already. More friendlier of him would be to ask about how to add mp3
> support, in case you had not warned him earlier.
In fact I warn and give instruction how to install xmms-mp3, disable
librh_mp3.so, install mplayer etc., but only to few of my friends who
want to try out Linux and can count on my support. I don't sell copies,
but I can imagine the hell any Fedora CD/DVD seller has to go through :)
The typical user who wants to try out Fedora is disappointed when they
install for the first time. I for one don't want Linux to be 31337, I
want it to be seen as an alternative to Windows or MacOS even by
Windows/MacOS users, and that can happen only if such user doesn't get
disgusted after even test installation.
Don't you think you are exaggerating a lot here? Not only do you reduce
the target group to "mp3 focused users who are not willing to read and
learn how to add more software", you also judge about the entire
distribution based on one or two missing features. If everything else
works amazingly well and just mp3 support is missing and can be added
quickly, a user is certainly not disgusted. As of FC3, additional
repositories can be added to Yum by clicking on a single package on a
well-configured web server. The graphical package utilities will become
more capable and more user-friendly, too.
3:48 p.m.
Dnia 23-02-2005, śro o godzinie 22:18 +0100, Michael Schwendt napisał
(a):
Not only do you reduce
the target group to "mp3 focused users who are not willing to read and
learn how to add more software",
I didn't want to say that. But such
people exist, don't deny it :) Also,
there are people, who are willing to read and learn, but don't know,
where to start and I think we could help them more with that (like my
homepage proposal - release notes describing differences between FC(X-1)
and FC(X) aren't interesting at all for a new user).
you also judge about the entire
distribution based on one or two missing features
Not me - I'm the user who
even hacked in-kernel device drivers to get
his system running properly and I'm not afraid to use Google if I need
an app, besides I know about many packages which aren't included in
Fedora (I'll try to push some of them into Extras when I'm ready :)).
I'm only saying there are people judging this way and the less reasons
they will have to grumble, the better.
The graphical package utilities will become
more capable and more user-friendly, too.
I'm counting on it and I want to say
while there always is room for
improvement, they do good job already. up2date refreshes its windows
strangely when downloading, shows 0 KiB file size, doesn't show errata
info (without RHN that is), but it's all my friends need to stay
updated :) I'm all excited about the things going in Fedora Core, and if
I say something can be done better, it's only because I think this will
make Fedora better. Really! :)
Lam
6:49 p.m.
On 02/23/2005 12:52:35 PM, Leszek Matok wrote:
Dnia 23-02-2005, śro o godzinie 21:16 +0100, Michael Schwendt
napisał
(a):
> Then do a better job at educating that person about extra packages
and
> how to get them easily. His choice of words ("stupid") is
inappropriate
> already. More friendlier of him would be to ask about how to add
mp3
> support, in case you had not warned him earlier.
In fact I warn and give instruction how to install xmms-mp3, disable
librh_mp3.so, install mplayer etc., but only to few of my friends who
want to try out Linux and can count on my support. I don't sell
copies,
but I can imagine the hell any Fedora CD/DVD seller has to go through
:)
I have gone through absolutely no hell.
When a customer asks how to play mp3's - I simply tell them how to
import gpg keys to Fedora Extras and rpm.livna.org - and how to add
them to yum.
Then - getting mp3 support is as easy as
yum install xmms-mp3 gstreamer-plugins-mp3
That then pulls in everything they need.
If they need it in sox - I provide a replacement rpm for them, if I
ever get a "cease and stop" for that, I'll just provide the simple
instructions (yum install mad-devel lame-devel; rpmbuild --rebuild sox-
***)
The typical user who wants to try out Fedora is disappointed when
they
install for the first time. I for one don't want Linux to be 31337, I
want it to be seen as an alternative to Windows or MacOS even by
Windows/MacOS users, and that can happen only if such user doesn't
get
disgusted after even test installation. I don't care if the users go
back to their systems if only they get the impression that Linux
works.
It does work.
MS for eons did not ship an mp3 encoder, they still don't ship a DVD
decoder. It's not hard to add the support, and certainly easier than
Fedora going to a non free distribution method in order to pay for the
patents.
The bad thing is only if they go back and say "I had Linux on my
box
once, but it doesn't do this, this and this, and I had to find some
third-party packages which I didn't know how to install, so it
sucks".
They have to get third party software, often $$$, to do stuff in
Windows or OS X as well. Stuff that Fedora provides functionallity for
OOB.
--
Michael A. Peters
http://mpeters.us/
7:12 p.m.
On Sat, 26 Feb 2005 00:49:31 +0000, Michael A. Peters wrote:
I have gone through absolutely no hell.
When a customer asks how to play mp3's - I simply tell them how to
import gpg keys to Fedora Extras and rpm.livna.org - and how to add
them to yum.
Then - getting mp3 support is as easy as
yum install xmms-mp3 gstreamer-plugins-mp3
That then pulls in everything they need.
If they need it in sox - I provide a replacement rpm for them, if I
ever get a "cease and stop" for that, I'll just provide the simple
instructions (yum install mad-devel lame-devel; rpmbuild --rebuild sox-
***)
yum install k3b-mp3 kdemultimedia-extras
That adds even more mp3 plugins.
3:45 p.m.
Is IIIMF ready to replace to the old input method stuff?
--
http://LinuxWiki.org/RonnyBuchmann
4:07 p.m.
On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote:
make sure that FC4 continues to fit on 4 CD's. Right now eclipse,
xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
What suddenely got so much larger ?
Nothing is set in stone, but if you want to write in favor of
keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
Really some games need to stay - they are one of the things that make people
use Linux and choose it. To be quite frank I'd rather see all the java stuff
dumped off to a java-extras CD or fedora extras. Ditto eclipse with it.
GFS is also clearly obscure extras material
9:40 a.m.
Alan Cox wrote:
On Mon, Feb 21, 2005 at 03:35:34PM -0500, Elliot Lee wrote:
Really some games need to stay - they are one of the things that make people
use Linux and choose it. To be quite frank I'd rather see all the java stuff
dumped off to a java-extras CD or fedora extras. Ditto eclipse with it.
I say let's look elsewhere before we start swinging the axe at Java
stuff. We can still keep them on the list, but I say start with the
bigger games and the redundant applications first.
10:17 a.m.
On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote:
I say let's look elsewhere before we start swinging the axe at
Java
stuff. We can still keep them on the list, but I say start with the
bigger games and the redundant applications first.
The few really redundant applications we have don't make a tiny dent in the
space required for java. The more I think about it the more it seems to come
down to "Gnome, KDE, Java, Open Office" pick any three.
10:39 a.m.
On Tue, 2005-02-22 at 11:17 -0500, Alan Cox wrote:
The few really redundant applications we have don't make a tiny
dent in the
space required for java. The more I think about it the more it seems to come
down to "Gnome, KDE, Java, Open Office" pick any three
None of which is really going to work. The answer is to just ship it
with 15 (5+5+4) CDs instead of the 14 (5+5+5) people are beating
themselves up to achieve, and sort it out for FC5 when anaconda can
handle multiple repositories during the install.
.
--
dwmw2
11:17 a.m.
An alternative approach is to adopt the Knoppix compressed file system.
Knoppix manages to get about 2.3Gig on a single CD.
Tim Daly
10:48 a.m.
On Tue, Feb 22, 2005 at 12:17:12PM -0500, Tim Daly wrote:
An alternative approach is to adopt the Knoppix compressed file
system.
Knoppix manages to get about 2.3Gig on a single CD.
The RPMs are already compressed; that's not going to help much.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
12:22 p.m.
On Tue, 22 Feb 2005, Tim Daly wrote:
An alternative approach is to adopt the Knoppix compressed file
system.
Knoppix manages to get about 2.3Gig on a single CD.
The .rpm packages are already compressed, so a compressed file system
won't help here. Thanks for thinking outside the box, though!
Best,
-- Elliot
12:53 p.m.
On Feb 22, 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
On Tue, 22 Feb 2005, Tim Daly wrote:
> An alternative approach is to adopt the Knoppix compressed file system.
> Knoppix manages to get about 2.3Gig on a single CD.
The .rpm packages are already compressed, so a compressed file system
won't help here. Thanks for thinking outside the box, though!
Talking of compressing stuff... Couldn't we perhaps compress the
hdlist and hdlist2 files in Fedora/base? Could we perhaps merge the
contents of hdstg2.img and netstg2.img that, given their similar size,
might be assumed to contain mostly the same contents? And how about
stage2.img, if that's a superset? This certainly wouldn't get us the
300MB we need, but it could get us 5-15% of that.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
12:59 p.m.
Alexandre Oliva wrote:
On Feb 22, 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
>On Tue, 22 Feb 2005, Tim Daly wrote:
>
>
>>An alternative approach is to adopt the Knoppix compressed file system.
>>Knoppix manages to get about 2.3Gig on a single CD.
>>
>>
>The .rpm packages are already compressed, so a compressed file system
>won't help here. Thanks for thinking outside the box, though!
>
>
Talking of compressing stuff... Couldn't we perhaps compress the
hdlist and hdlist2 files in Fedora/base? Could we perhaps merge the
contents of hdstg2.img and netstg2.img that, given their similar size,
might be assumed to contain mostly the same contents? And how about
stage2.img, if that's a superset? This certainly wouldn't get us the
300MB we need, but it could get us 5-15% of that.
You could also save similar amounts by only shipping either the
postscript or pdf version of docs and not both. (more if you ship 1 of
html,ps,pdf)
There really are some easy to get size savings around that don't entail
dropping packages.
-josh
1:03 p.m.
On Tue, 2005-02-22 at 15:53 -0300, Alexandre Oliva wrote:
Talking of compressing stuff... Couldn't we perhaps compress the
hdlist and hdlist2 files in Fedora/base?
Only if we increase the memory requirements to do an install
Could we perhaps merge the
contents of hdstg2.img and netstg2.img that, given their similar size,
might be assumed to contain mostly the same contents?
There are chunks that are the same, but the kernel modules are
different. If all of the kernel modules move into the initrd (probably
going to happen, although this does increase the memory requirements in
general), then these can merge.
And how about
stage2.img, if that's a superset? This certainly wouldn't get us the
300MB we need, but it could get us 5-15% of that.
It's a superset, but it's not really merge-able with the other images
without major filesystem work.
Jeremy
10:44 a.m.
Alan Cox wrote:
On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote:
>I say let's look elsewhere before we start swinging the axe at Java
>stuff. We can still keep them on the list, but I say start with the
>bigger games and the redundant applications first.
>
>
The few really redundant applications we have don't make a tiny dent in the
space required for java. The more I think about it the more it seems to come
down to "Gnome, KDE, Java, Open Office" pick any three.
I happen to agree with 3 out of 4, makes perfect sense to me.
However, I'm obligated to point out that there is some mechanical drudgery
that might put off the day of reckoning for what packages should be in
FC4.
The space constraints are approximately 4*650Mb = 2.3Gb.
Current overage is 300Mb, so package real estate is currently
(estimated) 2.6Gb.
Headers are (or were) ~12-15% of package real estate.
Let's use 10% for the analysis, or 260Mb of headers in current FC4.
Compressing headers would save about half of that, or ~130Mb, more if
changelogs
were truncated during build.
Much learned discussion (jnovy in particular iirc) points out additional
savings achievable
by choosing to use bzip2 for certain large package payloads. I'll wave
my hands here,
but I'm pretty sure that a big chunk of 170Mb could be saved.
Yes new rpm features, but zlib ain't exactly hard coding, nor is a date
comparison loop
for truncating changelogs, nor is configuring bzip2 payloads for certain
package payloads.
And yes, there's a knapsack problem fitting packages onto 4 CD's in
priority order
that is not addressed above at all.
Again, my personal belief is that 3 out of 4 is sounder (as in
soundboard) starting point
for FC discussion.
73 de Jeff
11:36 a.m.
Jeff Johnson wrote:
Alan Cox wrote:
> On Tue, Feb 22, 2005 at 10:40:34AM -0500, Demond James wrote:
>
>
>> I say let's look elsewhere before we start swinging the axe at Java
>> stuff. We can still keep them on the list, but I say start with the
>> bigger games and the redundant applications first.
>>
>
> The few really redundant applications we have don't make a tiny dent
> in the
> space required for java. The more I think about it the more it seems
> to come
> down to "Gnome, KDE, Java, Open Office" pick any three.
>
>
I happen to agree with 3 out of 4, makes perfect sense to me.
However, I'm obligated to point out that there is some mechanical
drudgery
that might put off the day of reckoning for what packages should be in
FC4.
The space constraints are approximately 4*650Mb = 2.3Gb.
Eeep, serves me right for multiplying in public, sigh.
s/2.3/2.6/
Current overage is 300Mb, so package real estate is currently
(estimated) 2.6Gb.
s/2.6/2.9/
Headers are (or were) ~12-15% of package real estate.
Let's use 10% for the analysis, or 260Mb of headers in current FC4.
s/260/290/
Compressing headers would save about half of that, or ~130Mb, more if
changelogs
were truncated during build.
s/130/145/
Much learned discussion (jnovy in particular iirc) points out
additional savings achievable
by choosing to use bzip2 for certain large package payloads. I'll wave
my hands here,
but I'm pretty sure that a big chunk of 170Mb could be saved.
s/170/155/
Yes new rpm features, but zlib ain't exactly hard coding, nor is a
date comparison loop
for truncating changelogs, nor is configuring bzip2 payloads for
certain package payloads.
And yes, there's a knapsack problem fitting packages onto 4 CD's in
priority order
that is not addressed above at all.
Again, my personal belief is that 3 out of 4 is sounder (as in
soundboard) starting point
for FC discussion.
The analysis is more important than the computational details ...
And 3 out of 4 is still my personal choice.
Sorry for the confusion.
73 de Jeff
8:14 p.m.
On Tue, 22 Feb 2005, Alan Cox wrote:
The few really redundant applications we have don't make a tiny
dent in
the space required for java. The more I think about it the more it seems
to come down to "Gnome, KDE, Java, Open Office" pick any three.
Also, these are all so big - surely it should be possible to
shrink all of them by a bit ?
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
4:09 p.m.
Elliot Lee wrote :
Here's a heads up that we need to get rid of about 300M of
packages to
make sure that FC4 continues to fit on 4 CD's.
For me, can go (into Extras) :
- desktop-backgrounds-extra
- compat-gcc-8-3.3.4.2
(if nothing in FC4 relies on it to be built anymore)
- tuxracer
(nothing new in ages, and not a really exciting game)
- abiword, gnumeric
(I use them a lot, but OOo is included)
I'd definitely like to see xfce kept, as it's a nice light desktop manager
alternative.
Looking at Eclipse and other java related stuff... wow, it's huge, and
represents an amazing number of packages... I definitely don't know enough
about it to identify anything that could be considered optional, but if
part of it is, I'd definitely agree to have it go back into a specialized
location.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3
Load : 0.69 0.29 0.15
5:20 p.m.
The eclipse packages are sub packages of a single source rpm, and that
is the basic eclipse distribution. All the other eclipse packages are
already going into Extras (C support/Bugzilla/Python Support and so on),
and there is little room to make changes there.
On Mon, 2005-02-21 at 23:09 +0100, Matthias Saou wrote:
Elliot Lee wrote :
> Here's a heads up that we need to get rid of about 300M of packages to
> make sure that FC4 continues to fit on 4 CD's.
For me, can go (into Extras) :
- desktop-backgrounds-extra
- compat-gcc-8-3.3.4.2
(if nothing in FC4 relies on it to be built anymore)
- tuxracer
(nothing new in ages, and not a really exciting game)
- abiword, gnumeric
(I use them a lot, but OOo is included)
I'd definitely like to see xfce kept, as it's a nice light desktop manager
alternative.
Looking at Eclipse and other java related stuff... wow, it's huge, and
represents an amazing number of packages... I definitely don't know enough
about it to identify anything that could be considered optional, but if
part of it is, I'd definitely agree to have it go back into a specialized
location.
Matthias
--
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora Core release 3 (Heidelberg) - Linux kernel 2.6.10-1.766_FC3
Load : 0.69 0.29 0.15
7:38 a.m.
On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
wrote:
- tuxracer
(nothing new in ages, and not a really exciting game)
This is my toddler's favorite game. It's the best way to put him to
sleep.
- abiword, gnumeric
(I use them a lot, but OOo is included)
So far as I'm concerned, all the "office" packages can go. I've
found that 90% compatibility with MS Office isn't enough to work with the
groups I work with and just wind up running the real thing under crossover.
8:59 a.m.
On Tuesday 22 February 2005 08:38, Paul A. Houle wrote:
On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
wrote:
> - tuxracer
> (nothing new in ages, and not a really exciting game)
This is my toddler's favorite game. It's the best way to put him to
sleep.
I agree, this is a great game to have in core. it's not huge, but it is
a lot
of fun.
> - abiword, gnumeric
> (I use them a lot, but OOo is included)
So far as I'm concerned, all the "office" packages can go.
I've
found that 90% compatibility with MS Office isn't enough to work with the
groups I work with and just wind up running the real thing under crossover.
I would
disagree with you here. for the groups I work with 90% is great, not
only that, some have wound up moving to OO.o on windows as well.
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
9:21 a.m.
On Tue, 2005-02-22 at 09:59 -0500, Richard June wrote:
On Tuesday 22 February 2005 08:38, Paul A. Houle wrote:
> On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou
>
> So far as I'm concerned, all the "office" packages can go.
I've
> found that 90% compatibility with MS Office isn't enough to work with the
> groups I work with and just wind up running the real thing under crossover.
I would disagree with you here. for the groups I work with 90% is great, not
only that, some have wound up moving to OO.o on windows as well.
For 2.0 a bunch of work went into the Word & Excel filters, so
compatibility there is much greater than just 90%. A lot also depends
on the fonts you have, even on Windows with Office if you don't have the
same fonts as the document requires, Office has to do some guessing same
as OOo does.
Dan
9:40 a.m.
On Tue, 22 Feb 2005 10:21:05 -0500, Dan Williams <dcbw(a)redhat.com> wrote:
For 2.0 a bunch of work went into the Word & Excel filters, so
compatibility there is much greater than just 90%. A lot also depends
on the fonts you have, even on Windows with Office if you don't have the
same fonts as the document requires, Office has to do some guessing same
as OOo does.
For me the showstopper is lacking the ability to write comments on
documents.
This is almost 100% of what I use MS word for. Even back in '99 when OO
was called Star Office I felt that it was adequate for writing
documents... I'd convert it to word and send it to the publisher and
everything was cool. But then I'd get it back in word format with
comments and I'd need to use Microsoft word in order to see the comments,
reply to them, make edits that the system could track with "track
changes".
Since my publisher went out of business, I've rarely used any kind of
office program to create a document -- I generally use "emacs". I think
that e-mail attachments are a great way to pass unimportant business
documents around, but if you really want me to read something (rather
than put it off to something I might do next week) you'd best do it as
ordinary text, and that's true even if I'm reading my mail on Windows.
I think the "import filter" idea is 100% of what's wrong with workflows
that involve office programs and other software (such as CMS systems.)
It's necessary, because different systems use different representations,
but then even 99.9% accuracy isn't enough because the kind of people that
exchange office documents with other people expect to be able to do
round-trip scenarios and even the slightest bit of mangling is a huge
annoyance when it has to get unmangled again and again. (Or doesn't get
noticed until you get back 1500 copies from the printer.)
My wife's sister works for a social service agency where they'd bought
one copy of MS word and installed it on all the machines. At some point
they realized they weren't in compliance with the license but they
couldn't afford to buy MS Office for all their computers -- so they
switched to Star Office. They had the kind of "round trip" problems
dealing with outside agencies and found it just wasn't worth the bother
and they finally found the cash to pay the troll.
10:19 a.m.
On Tue, 2005-02-22 at 10:40 -0500, Paul A. Houle wrote:
On Tue, 22 Feb 2005 10:21:05 -0500, Dan Williams
<dcbw(a)redhat.com> wrote:
> For 2.0 a bunch of work went into the Word & Excel filters, so
> compatibility there is much greater than just 90%. A lot also depends
> on the fonts you have, even on Windows with Office if you don't have the
> same fonts as the document requires, Office has to do some guessing same
> as OOo does.
>
For me the showstopper is lacking the ability to write comments on
documents.
Umm, Insert->Note?
This is almost 100% of what I use MS word for. Even back in '99 when OO
was called Star Office I felt that it was adequate for writing
documents... I'd convert it to word and send it to the publisher and
everything was cool. But then I'd get it back in word format with
comments and I'd need to use Microsoft word in order to see the comments,
reply to them, make edits that the system could track with "track
changes".
Umm, File->Versions? Edit->Changes?
All these things have been around for more than a year. They are
supposed to be more or less equivalent to the Word features they refer
to, and if there is missing functionality for them, that is a bug that
needs to get fixed.
I think the "import filter" idea is 100% of what's
wrong with workflows
that involve office programs and other software (such as CMS systems.)
It's necessary, because different systems use different representations,
but then even 99.9% accuracy isn't enough because the kind of people that
exchange office documents with other people expect to be able to do
round-trip scenarios and even the slightest bit of mangling is a huge
annoyance when it has to get unmangled again and again. (Or doesn't get
noticed until you get back 1500 copies from the printer.)
For most people, the functionality offered by at least OpenOffice.org,
and possibly KOffice/Abiword/Gnumeric is sufficient. We're not trying
to get 100% compatibility overnight here, that's impossible. But what
the project does try to do is be "Good Enough", which is the formula
that Microsoft itself uses for most things. When you're Good Enough for
most people, the product starts to get used, and you gain marketshare.
When you gain marketshare, people start having to deal with your file
format, and more and more people eventually are able to do both formats.
Its a gradual thing that takes a while, even MS Word took quite a while
to overtake WordStar (or whatever that was), as Excel too time to
overtake 123 and VisiCalc. It took years before Word & Excel were "Good
Enough", but when they were, people really started to use them.
Dan
12:22 p.m.
On Tue, 2005-02-22 at 11:19 -0500, Dan Williams wrote:
Umm, File->Versions? Edit->Changes?
All these things have been around for more than a year. They are
supposed to be more or less equivalent to the Word features they refer
to, and if there is missing functionality for them, that is a bug that
needs to get fixed.
Well, when I tried to do that yesterday on a Word document the menu item
was grayed out until I saved it as an OpenOffice.org document (.sxw). Is
it actually supposed to be handled in Word format documents? That would
be _wonderful_ for interoperability.
/Per
--
Per Bjornsson <perbj(a)stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University
10:33 a.m.
On Tuesday 22 February 2005 10:21, Dan Williams wrote:
On Tue, 2005-02-22 at 09:59 -0500, Richard June wrote:
> On Tuesday 22 February 2005 08:38, Paul A. Houle wrote:
> > On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou
> >
> > So far as I'm concerned, all the "office" packages can
go.
> > I've found that 90% compatibility with MS Office isn't enough to work
> > with the groups I work with and just wind up running the real thing
> > under crossover.
>
> I would disagree with you here. for the groups I work with 90% is great,
> not only that, some have wound up moving to OO.o on windows as well.
For 2.0 a bunch of work went into the Word & Excel filters, so
compatibility there is much greater than just 90%. A lot also depends
on the fonts you have, even on Windows with Office if you don't have the
same fonts as the document requires, Office has to do some guessing same
as OOo does.
I went through the trouble of installing a number of fonts for my
users. so
fonts aren't much of an issue.
I am looking forward to OO.o 2.0 though
--
Public Key available Here:
http://www.bravegnuworld.com/~rjune/pubkey.asc
7:41 p.m.
On 02/22/2005 06:59:33 AM, Richard June wrote:
I agree, this is a great game to have in core. it's not huge, but
it
is a lot
of fun.
Except it pukes on a lot of systems if you don't install kernel
tainting drivers.
--
Michael A. Peters
http://mpeters.us/
11:01 a.m.
Paul A. Houle wrote:
On Mon, 21 Feb 2005 23:09:25 +0100, Matthias Saou
<thias(a)spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
wrote:
> - tuxracer
> (nothing new in ages, and not a really exciting game)
This is my toddler's favorite game. It's the best way to put him
to sleep.
> - abiword, gnumeric
> (I use them a lot, but OOo is included)
>
So far as I'm concerned, all the "office" packages can go.
I've found that 90% compatibility with MS Office isn't enough to work
with the groups I work with and just wind up running the real thing
under crossover.
OK, that's your experience.
That's still not an argument for not having an office suite in Fedora
Core. It's not there for MS compatibility.
It also make abiword & gnumeric redundant and "extras" so they should be
moved to FE.
4:18 p.m.
If Eclipse and the other Java stuff were moved to extras, gcc4 could go
as well. Drop that and compat-gcc (and maybe the other compat-packages)
and it would be close.
Unpopular choices:
- emacs vs. xemacs
- mysql vs. postgresql
- mozilla vs. firefox/thunderbird
- openoffice.org vs. koffice vs. abiword
I don't see GNOME vs. KDE as an option; both are pretty much required to
provide a complete desktop. XFCE however could go.
Would there be a way to divide up the i18n stuff? Maybe move the Asian
support (which seems to be a large bit of space) to a separate disc?
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
4:20 p.m.
Here's a heads up that we need to get rid of about 300M of
packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
Tuxracer is definitely a candidate there. The last games to go should
probably be the standard KDE or GNOME games - if anything, for the
reason that they are expected to be part of the full desktop environment
release. Cfengine is IMHO not only worth keeping, but also documenting
and supporting elsewhere - hint: you could use it with kickstarts and
yum.
How many people are actually installing Mailman? Webalizer?
xcdroast? Is there a decent CD burning tool for GNOME?
Is OO.o ever going to drop the private Python tree it has always shipped
with?
lynx, elinks and w3m all have a noble purpose. One or two of them could
be moved to Extras, though.
--
Rudi
4:26 p.m.
On Mon, 2005-02-21 at 23:20 +0100, Rudi Chiarito wrote:
How many people are actually installing Mailman? Webalizer?
I think Mailman is fairly frequently used.
Is OO.o ever going to drop the private Python tree it has always
shipped with?
It's planned. They're working on making it use more of the system
libraries instead of its own. See
http://people.redhat.com/caolanm/progress/progress.png
--
dwmw2
5:01 p.m.
Keep XFce, i love that i can totally control my desktop layout from a
few XML files. (or my mom's, or a few hundred office pc's).
It really makes for a clutter free, productive enviroment.
The entire WM in FC3 is 16mb
and what about moving the OpenOffice dictionaries to extras?
6:37 p.m.
On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote:
On Tue, 22 Feb 2005 00:36:01 +0100, Cream <lists(a)donut.dk>
wrote:
> what about moving aspell to extras? 150mb "saved"
I don't think removing the spellchecker is a good idea. :)
no but the lang packs for the spellchecker are separate srpms. So
splitting off the non-major languages would be a savings.
with no offense to those people in bulgaria the aspell-bg pkg is 30mb -
maybe it could be somewhere else.
-sv
7:40 p.m.
On Mon, 2005-02-21 at 19:37 -0500, seth vidal wrote:
On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote:
>On Tue, 22 Feb 2005 00:36:01 +0100, Cream <lists(a)donut.dk> wrote:
>> what about moving aspell to extras? 150mb "saved"
>
>I don't think removing the spellchecker is a good idea. :)
>
no but the lang packs for the spellchecker are separate srpms. So
splitting off the non-major languages would be a savings.
People will read this as "the typical US" arrogance, ignorance and
nationalism.
Ralf
7:53 p.m.
On Tue, 22 Feb 2005 02:40:50 +0100, Ralf Corsepius <rc040203(a)freenet.de> wrote:
> no but the lang packs for the spellchecker are separate srpms.
So
> splitting off the non-major languages would be a savings.
People will read this as "the typical US" arrogance, ignorance and
nationalism.
Well, tell them that the Russian agrees with the American. They can
blame the Russians for a change. It seems increasingly popular these
days anyway. :)
Most countries have their own local distros that commonly re-roll
Fedora to reflect their regional needs, so I don't think making
spellcheck dictionaries for minor languages a download-only thing for
vanilla Fedora is a bad idea (let's say minor == fewer than a hundred
million speakers).
Regards,
--
Konstantin Ryabitsev
Zlotniks, INC
8:14 p.m.
On Mon, 2005-02-21 at 20:53 -0500, Konstantin Ryabitsev wrote:
On Tue, 22 Feb 2005 02:40:50 +0100, Ralf Corsepius
<rc040203(a)freenet.de> wrote:
> > no but the lang packs for the spellchecker are separate srpms. So
> > splitting off the non-major languages would be a savings.
>
> People will read this as "the typical US" arrogance, ignorance and
> nationalism.
Well, tell them that the Russian agrees with the American. They can
blame the Russians for a change. It seems increasingly popular these
days anyway. :)
I realize, to have entered dangerous political grounds ...
IMO, if you remove one language you must remove all and make all
languages optional (Including English) and reduce Fedora Core to "C".
Most countries have their own local distros that commonly re-roll
Fedora to reflect their regional needs, so I don't think making
spellcheck dictionaries for minor languages a download-only thing for
vanilla Fedora is a bad idea (let's say minor == fewer than a hundred
million speakers).
100 mill. speaker? This would exclude large groups and major languages.
You should be aware that i18n for "less spread" languages makes
distributions attractive to "niches".
Ralf
9:28 p.m.
People will read this as "the typical US" arrogance,
ignorance and
nationalism.
*yawn* - you got me - I was suggesting moving lesser-used language
packs to extras as a secret move toward american hegemeony.
yep.
that's it.
and you'll never stop me! You'll never foil my plans!!!!
*eye roll*
-sv
2 a.m.
On Mon, 2005-02-21 at 19:37 -0500, seth vidal wrote:
On Mon, 2005-02-21 at 18:59 -0500, Konstantin Ryabitsev wrote:
>On Tue, 22 Feb 2005 00:36:01 +0100, Cream <lists(a)donut.dk> wrote:
>> what about moving aspell to extras? 150mb "saved"
>
>I don't think removing the spellchecker is a good idea. :)
>
no but the lang packs for the spellchecker are separate srpms. So
splitting off the non-major languages would be a savings.
with no offense to those people in bulgaria the aspell-bg pkg is 30mb -
maybe it could be somewhere else.
aspell-bg is currently (FC3+updates and rawhide) unusable, see #142238
Redoing it in the manner proposed in the bug-report shaves half the
size. Fix seems to be held back by lack of rh manpower.
Cheers
Yanko
7:52 p.m.
On Feb 21, 2005, Konstantin Ryabitsev <mricon(a)gmail.com> wrote:
On Tue, 22 Feb 2005 00:36:01 +0100, Cream <lists(a)donut.dk>
wrote:
> what about moving aspell to extras? 150mb "saved"
I don't think removing the spellchecker is a good idea. :)
why nto? hwo neeeds aspel cheker anway? :)-
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
9:06 p.m.
On Mon, 21 Feb 2005 15:35:34 -0500 (EST), Elliot Lee <sopwith(a)redhat.com> wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
I will try to take over cfengine and xfce if they are to be dropped. I
need them more than I need the distro.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
9:31 p.m.
Hi,
Can I suggest two possible approaches...
1) we aren't willing to remove anything that was in FC3 due to the
upgrade problem, so we basically have to remove the stuff that's
new since FC3; just do that
2) maybe we are willing to consider removing anything,
if so I propose this approach:
- create "profiles" of complete sets of packages that some
common audiences would want; avoid duplicate-functionality/
indecision as much as possible in those
- try to include/exclude complete profiles
for example, a complete "corporate desktop",
"mail server", "print server", "file server",
"sysadmin
workstation", "C programming environment",
"java programming environment", etc.
dump entire use cases like that; and dump multiple ways
to do a single use case.
Rationale: it's stupid to include half of a use case, since
you are already causing that person to go to Extras, you
may as well send them there for everything.
Havoc
10:01 p.m.
Havoc Pennington wrote:
[...]
2) maybe we are willing to consider removing anything,
if so I propose this approach:
- create "profiles" of complete sets of packages that some
common audiences would want; avoid duplicate-functionality/
indecision as much as possible in those
- try to include/exclude complete profiles
for example, a complete "corporate desktop",
"mail server", "print server", "file server",
"sysadmin
workstation", "C programming environment",
"java programming environment", etc.
dump entire use cases like that; and dump multiple ways
to do a single use case.
Rationale: it's stupid to include half of a use case, since
you are already causing that person to go to Extras, you
may as well send them there for everything.
Havoc
Brilliant idea. Solves all our problems, but creates a set of new one.
Like, for example, what will the ISOs look like?
10:29 p.m.
Hi,
Tyler Larson wrote:
Havoc Pennington wrote:
> [...]
> 2) maybe we are willing to consider removing anything,
> if so I propose this approach:
> - create "profiles" of complete sets of packages that some
> common audiences would want; avoid duplicate-functionality/
> indecision as much as possible in those
>
> - try to include/exclude complete profiles
>
> for example, a complete "corporate desktop",
> "mail server", "print server", "file server",
"sysadmin
> workstation", "C programming environment", "java programming
> environment", etc.
>
> dump entire use cases like that; and dump multiple ways to do a
> single use case.
>
> Rationale: it's stupid to include half of a use case, since
> you are already causing that person to go to Extras, you
> may as well send them there for everything.
>
> Havoc
>
Brilliant idea. Solves all our problems, but creates a set of new one.
Like, for example, what will the ISOs look like?
Well, the most obvious way is to just use the 'profiles' guidelines
which are currently used for the installation - I imagine Havoc had this
in mind with his suggestion. The distribution is clearly already
partially divided up in the sense that when installing, one is asked to
choose between package groups like 'network server', 'workstation' etc
preselected with roughly the right RPM's.
Seems to me that the logical way this should be split is:
* 1 core/common CD which contains things like glibc, kernel, initscripts
and basic system stuff that everyone requires, enough to get a machine
up to runlevel 3 awaiting a login, with some basic stuff such as network
connectivity, python ready to go etc If someone had loads of bandwidth
from that point on they could even pull down whatever they wanted over
the network and install it.
* 1 desktop CD that has KDE/Gnome + + OpenOffice + X stuff eg games
(enough for the casual or home user to do what they want). For those
who love their spell checker, that can go here too ;)
* 1 server CD which contains servers and development applications
(probably where more packages of interest in RHEL live)
The future possibility of a packager shipping their own CD as #4 with
their own custom apps then looks quite easy, literally a 'bolt on' CD
that follows on from the core/common #1 CD.
The flexibility is there at this stage such that what won't fit on each
CD should be pushed to extras online, and on the other hand, if there is
spare space, possibly content from extras online could be pre-loaded
into an 'extras' directory on the CD to fill it up.
Given the number of mails from this list today, I think that the
suggestion of trimming packages to make space was very definitely done
on Monday morning at the start of the week ;) I imagine there was some
faint hope of a consensus of sorts being reached by Friday...............
reuben
5:20 a.m.
On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote:
Brilliant idea. Solves all our problems, but creates a set of new
one.
Like, for example, what will the ISOs look like?
CD #1 Download only this CD for a base install and use yum to add packages
CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs
via CD/DVD
Java CD Optional Download for java packages
Games CD Optional Download for extra games
etc..
8:35 a.m.
On Tue, 2005-02-22 at 06:20, Alan Cox wrote:
On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote:
> Brilliant idea. Solves all our problems, but creates a set of new one.
> Like, for example, what will the ISOs look like?
CD #1 Download only this CD for a base install and use yum to add packages
...with optional Live installer
CD #2,#3,#4 (for now) Fedora Core packages. Download for
updates/installs
via CD/DVD
Java CD Optional Download for java packages
Games CD Optional Download for extra games
etc..
+10
M
8:57 a.m.
On Tue, Feb 22, 2005 at 09:35:45AM -0500, Michael Tiemann wrote:
> CD #2,#3,#4 (for now) Fedora Core packages. Download for
updates/installs
> via CD/DVD
>
> Java CD Optional Download for java packages
> Games CD Optional Download for extra games
>
> etc..
+10
Agreed. Even though we may end up with a few more CDs this way (as some
may end up partially full), we get some room to grow so we don't have to
go through such painful reorganziation every FCx. And you get the huge
advantage that you would know apriori what CDs you need: no need to
download, burn, verify the images you don't care about. I think it would
end up saving time for many folks.
--
Dimi.
9:18 a.m.
On Tue, 22 Feb 2005 09:57:11 -0500, Dimitrie O. Paun <dpaun(a)rogers.com> wrote:
And you get the huge
advantage that you would know apriori what CDs you need: no need to
download, burn, verify the images you don't care about. I think it would
end up saving time for many folks.
i highly doubt that.... for upgrades... its going to be a HUGE time
suck trying to avoid downloading optional cds.
Sure you might install fc6 just using the cds you need.. .but then you
used yum and installed a game or two... and a little java.. and then a
few -devel packages because you wanted to compile something up from
srpm. 3 months later.... yer ready to install fc7.. have fun writing
the comparative scripts to figure out which 'optional' cds you now
need to download. Unless some in-distro tools are created to help
work it out for you.. its going to be a huge frelling mess for a large
class of users who want to upgrade from release to release.
-jef
11:44 a.m.
Jeff Spaleta wrote:
On Tue, 22 Feb 2005 09:57:11 -0500, Dimitrie O. Paun
<dpaun(a)rogers.com> wrote:
>And you get the huge
>advantage that you would know apriori what CDs you need: no need to
>download, burn, verify the images you don't care about. I think it would
>end up saving time for many folks.
i highly doubt that.... for upgrades... its going to be a HUGE time
suck trying to avoid downloading optional cds.
Sure you might install fc6 just using the cds you need.. .but then you
used yum and installed a game or two... and a little java.. and then a
few -devel packages because you wanted to compile something up from
srpm. 3 months later.... yer ready to install fc7.. have fun writing
the comparative scripts to figure out which 'optional' cds you now
need to download. Unless some in-distro tools are created to help
work it out for you.. its going to be a huge frelling mess for a large
class of users who want to upgrade from release to release.
-jef
What it sounds like Alan is suggesting is taking Havoc's "profiles" (there
may be 10 to 20 of them) and using them a guide to determine which packages go
on which of the 4 or 5 install CDs. This way, perhaps each CD will be less
full, but at least some people won't have to download all of them.
Furthermore, the CDs will (should) be marked to show which profiles they
fulfill. Something like "CD #3: print server, file server, mail server".
In this scenario, very little actually changes. We maybe add a CD or two, but
hopefully gain a little better organization of the packages in the process.
People who are upgrading can download the CD's they think they'll need based
on what software they have installed. If they want to play it safe, they can
download all the CDs before they begin. This isn't at all different than what
they do already.
9:10 a.m.
On Tue, 22 Feb 2005 09:35:45 -0500, Michael Tiemann <tiemann(a)redhat.com> wrote:
+10
Yes i agree, doing things that way would end up meaning +10 partially
full isos. This approach snowballs very quickly:
office cd
desktop-art cd
games cd
kde cd
java cd
devel cd
emacs cd
perl cd
All of them optional for a basic fedora install... whatever that
means. Now, this approach definitely is a benifit to fresh installers
who do targetted installs, and people who are networked with hi-band
and can do network installs. But I'm not so sure how an explosion of
partially full isos works out for people doing non-networked upgrades
or people with low-band who are forced to buy or manufacture
mediasets. Those 'optional' disks look highly less optional once you
start doing upgrades.. and each extra partially full iso increases the
overhead of producing full mediasets for sale or give away.
Oh and there has to be a 'clever' way for 'fedora' to tell people
which 'optional' cds they are going to want to burn before they burn
them. And clever does not mean a flat package list with associated cd
#/cd name next to it on the fedora website. Anyone doing an upgrade
via mediasets will want to know before they start downloading which
'optional' disks they will continue to need to do the full upgrade.
-jef
9:14 a.m.
On Tue, 2005-02-22 at 16:10, Jeff Spaleta wrote:
On Tue, 22 Feb 2005 09:35:45 -0500, Michael Tiemann
<tiemann(a)redhat.com> wrote:
> +10
Yes i agree, doing things that way would end up meaning +10 partially
full isos. This approach snowballs very quickly:
office cd
desktop-art cd
games cd
kde cd
java cd
devel cd
emacs cd
perl cd
Partial isos could be joined together.
Java + devel + emacs on one cd for example
games + kde + office on one?
-HK
9:24 a.m.
On Tue, 22 Feb 2005 16:14:26 +0100, Hans Kristian Rosbach
<hk(a)isphuset.no> wrote:
Java + devel + emacs on one cd for example
games + kde + office on one?
not sure how thats functionally better than what we have right now...
which i remind you goes something like this:
2 cds to do a default desktop install (does anyone actually do these)
3 cds to do workstation or install with kde (workstation installs are
probably the most common)
4 cds if yer a lunatic and want xfce
if fc4 went to 5 cds java without doing anything else... we'd end up
with pretty much what you are talking about..
-jef
11:52 a.m.
Alan Cox wrote:
On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote:
>Brilliant idea. Solves all our problems, but creates a set of new one.
>Like, for example, what will the ISOs look like?
CD #1 Download only this CD for a base install and use yum to add packages
CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs
via CD/DVD
Java CD Optional Download for java packages
Games CD Optional Download for extra games
etc..
This still sounds like most people will download all (or almost all) of the
CDs in order to install the packages they want.
However, I really like the idea of installing a base OS from just one CD and
installing the rest of the system using yum or up2date. After all, most users
will have to update the majority of the packages they've just installed
immediately after their first boot.
12:45 p.m.
Once upon a time, Tyler Larson <fedora-devel(a)tlarson.com> said:
However, I really like the idea of installing a base OS from just one
CD
and installing the rest of the system using yum or up2date. After all, most
users will have to update the majority of the packages they've just
installed immediately after their first boot.
That still assumes everyone has high-speed bandwidth available, which is
a broken assumption. If you think everyone should be downloading to get
most packages, why not make boot.iso the only distributed image and make
everything else downloaded? That "solves" all the CD/DVD count and
distribution issues.
I am disappointed that the setup for Fedora Extras is to just have a
rolling-update tree with no ISOs. That makes FE packages second class
citizens.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
1:25 p.m.
On Feb 22, 2005, Chris Adams <cmadams(a)hiwaay.net> wrote:
That still assumes everyone has high-speed bandwidth available, which
is
a broken assumption. If you think everyone should be downloading to get
most packages, why not make boot.iso the only distributed image and make
everything else downloaded? That "solves" all the CD/DVD count and
distribution issues.
I am disappointed that the setup for Fedora Extras is to just have a
rolling-update tree with no ISOs. That makes FE packages second class
citizens.
How about rolling out ISOs of Fedora Extras *and* Core weekly or so,
including all updates? This would address the issue of people who
install FC3 now and then have to download an additional 1.5 CD just to
get all of the available updates, then have them all installed
overnight.
If we keep the distribution of packages inside ISOs relatively stable,
rsync (which all? mirrors use to get contents from the master server)
would do a great job limiting the transferred data to the new
packages, and perhaps even less than that, since rsync could then take
advantage of similarities between the old version of the package and
the new build.
If we had tools to look into ISOs built into yum, then mirrors could
even refrain from carrying the exploded trees. Just like yum 2.1 uses
byte ranges to download the header portion of an rpm, it could extract
rpms from isos. Failing that, there's always loopback mount or
isoinfo.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
1:30 p.m.
Hi.
Alexandre Oliva <aoliva(a)redhat.com> wrote:
If we had tools to look into ISOs built into yum, then mirrors could
even refrain from carrying the exploded trees.
Err, I am quite happy that I am able to download individual RPMs by hand,
and I'd like to be able to continue to do so.
If (and that's a big if) it is either the ISOs or the trees, I'd vote
for the ISOs. Building an bit identical ISO file from scratch is relatively
easy, jidgo has been mentioned several times.
--
"This isn't all true." -- Steven Wright
1:48 p.m.
Alexandre Oliva (aoliva(a)redhat.com) said:
> I am disappointed that the setup for Fedora Extras is to just
have a
> rolling-update tree with no ISOs. That makes FE packages second class
> citizens.
How about rolling out ISOs of Fedora Extras *and* Core weekly or so,
including all updates? This would address the issue of people who
install FC3 now and then have to download an additional 1.5 CD just to
get all of the available updates, then have them all installed
overnight.
OK, all that discussion of how 5 CDs is bad for mirrors? This is worse.
Much worse. Even with rsync handling mirroring, you're doubling the
bandwidth used for updates.
Bill
3:35 p.m.
On Feb 22, 2005, Bill Nottingham <notting(a)redhat.com> wrote:
Alexandre Oliva (aoliva(a)redhat.com) said:
> > I am disappointed that the setup for Fedora Extras is to just have a
> > rolling-update tree with no ISOs. That makes FE packages second class
> > citizens.
>
> How about rolling out ISOs of Fedora Extras *and* Core weekly or so,
> including all updates? This would address the issue of people who
> install FC3 now and then have to download an additional 1.5 CD just to
> get all of the available updates, then have them all installed
> overnight.
OK, all that discussion of how 5 CDs is bad for mirrors? This is
worse.
Much worse. Even with rsync handling mirroring, you're doubling the
bandwidth used for updates.
How so? Wouldn't you'd be downloading the updates only once, in the
rolling ISOs? We already push most updates out on Monday mornings
anyway, so we might as well push them out in batch in the form of
ISOs.
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva(a){redhat.com, gcc.gnu.org}
Free Software Evangelist oliva(a){lsd.ic.unicamp.br, gnu.org}
3:57 p.m.
On Tue, Feb 22, 2005 at 06:35:45PM -0300, Alexandre Oliva wrote:
> OK, all that discussion of how 5 CDs is bad for mirrors? This is
worse.
> Much worse. Even with rsync handling mirroring, you're doubling the
> bandwidth used for updates.
How so? Wouldn't you'd be downloading the updates only once, in the
rolling ISOs? We already push most updates out on Monday mornings
anyway, so we might as well push them out in batch in the form of
ISOs.
So, wait, there'd be entirely new, small, iso images for each set of weekly
updates?
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
6:30 p.m.
Alexandre Oliva (aoliva(a)redhat.com) said:
> OK, all that discussion of how 5 CDs is bad for mirrors? This is
worse.
> Much worse. Even with rsync handling mirroring, you're doubling the
> bandwidth used for updates.
How so? Wouldn't you'd be downloading the updates only once, in the
rolling ISOs?
Wait, you want to push them *only* as ISOs? That breaks every tool
out there right now, and destroys the point of the metadata.
We already push most updates out on Monday mornings anyway
No, we don't.
Bill
1:43 p.m.
Chris Adams wrote:
Once upon a time, Tyler Larson <fedora-devel(a)tlarson.com>
said:
>However, I really like the idea of installing a base OS from just one CD
>and installing the rest of the system using yum or up2date. After all, most
>users will have to update the majority of the packages they've just
>installed immediately after their first boot.
That still assumes everyone has high-speed bandwidth available, which is
a broken assumption.
I'm certainly not suggesting that EVERYONE needs to install that way. But it
would be nice if it were easy to do.
I am disappointed that the setup for Fedora Extras is to just have a
rolling-update tree with no ISOs. That makes FE packages second class
citizens.
That's a good point. There really SHOULD be a set of Extras ISOs available.
Even if those ISOs are nothing more than a snapshot of the Extras tree at the
time the release. And those extras SHOULD be installable from Anaconda/S-C-P
-- even if they're put under a separate "Extras" heading.
Moving packages to Extras is tantamount to removing them completely if those
packages--to paraphrase Pirates of the Caribbean--"cannot be found except by
those who know where they are." These things will have to be installable from
a user-friendly interface. Otherwise, Extras is just another 3rd party repo.
1:45 p.m.
That's a good point. There really SHOULD be a set of Extras ISOs
available.
Even if those ISOs are nothing more than a snapshot of the Extras tree at the
time the release. And those extras SHOULD be installable from Anaconda/S-C-P
-- even if they're put under a separate "Extras" heading.
Then let's be completely clear.
The only way isos are getting made from extras is if SOMEONE steps up
and does them.
We don't have time, period.
we barely have time to do the infrastructure bits that we have to get
done for fc4.
so step up.
do the work, then you can get what you want.
-sv
5:20 p.m.
So,
A simple menu driven download & burn program, that lets you browse a yum
repository, could be like selecting individual packages in anaconda,
you could even have it check dependencies, and download those aswell.
And then burn your selection to a cd/dvd. (possibly spanning several cd's)
Then a set of "yum cd-list/cd-install/cd-etc.." commands to access your
newly homebuilt yum-repository-on-a-cd.
That way you can build your own up to date extra's cd, and go deploy it
offline.
And it would be easy to imagine:
- a shiny X manager/installer
- online cd sellers that would let you mix your own Extra's packages cd,
burn and ship it to you, or burn-to-order updated everything-included-dvd's
an idea?
6:06 p.m.
New subject: fc3 install hangs at "configuring kernel parameters"
Hi All,
I've tried installing FC3 several times with differing setups and
for each install, the final reboot hangs right as "configuring kernel
parameters" prints out. What is going on at this stage and what may be
the problem? I've done one FC3 install before on the same motherboard
(shuttle AK32v3.1) that worked just fine. The only difference I can see
is the processor is different (faster).
Any thoughts anyone? I'm going to try a live cd image boot and
replace the kernel with a 2.6.8 variant and see if that makes any
difference.
Bill Rees
Nascar Sillicon Motor Speedway
8:12 p.m.
New subject: fc3 install hangs at "configuring kernel parameters"
Bill,
You might want to repost this questions so that it doesn't appear as
part of an existing thread (bad form). As a rule of thumb, if your post
isn't part of the current thread, don't click on reply to start a new
one. (You could click on the email address for the list instead and
then go from there).
Also, this question is off-topic for devel (a list for develpoment
issues). Try fedora-list instead.
Rodd
On Tue, 2005-02-22 at 16:06 -0800, Bill Rees wrote:
Hi All,
I've tried installing FC3 several times with differing setups and
for each install, the final reboot hangs right as "configuring kernel
parameters" prints out. What is going on at this stage and what may be
the problem? I've done one FC3 install before on the same motherboard
(shuttle AK32v3.1) that worked just fine. The only difference I can see
is the processor is different (faster).
Any thoughts anyone? I'm going to try a live cd image boot and
replace the kernel with a 2.6.8 variant and see if that makes any
difference.
Bill Rees
Nascar Sillicon Motor Speedway
1:37 p.m.
New subject: fc3 install hangs at "configuring kernel parameters"
ons, 23.02.2005 kl. 01.06 skrev Bill Rees:
Hi All,
I've tried installing FC3 several times with differing setups and
for each install, the final reboot hangs right as "configuring kernel
parameters" prints out. What is going on at this stage and what may be
the problem? I've done one FC3 install before on the same motherboard
(shuttle AK32v3.1) that worked just fine. The only difference I can see
is the processor is different (faster).
Any thoughts anyone? I'm going to try a live cd image boot and
replace the kernel with a 2.6.8 variant and see if that makes any
difference.
Boot the system in single user mode. run "firstboot". next time you
reboot it will work w/o trouble.
3:13 p.m.
On Tue, Feb 22, 2005 at 06:20:21AM -0500, Alan Cox wrote:
On Mon, Feb 21, 2005 at 09:01:29PM -0700, Tyler Larson wrote:
> Brilliant idea. Solves all our problems, but creates a set of new one.
> Like, for example, what will the ISOs look like?
CD #1 Download only this CD for a base install and use yum to add packages
CD #2,#3,#4 (for now) Fedora Core packages. Download for updates/installs
via CD/DVD
Java CD Optional Download for java packages
Games CD Optional Download for extra games
Some people argued that mirror maintainers would complain about the
extra space needed, from that angle I don't care too much about 500
extra MB (on the other hand if you could reduce the debuginfo packaging
size in *some* ways !!!), but I do care about my bandwidth, and I prefer
users picking the 3 ISO they really need instead of downloading the
4 ISO blindly because it is not identified clearly what will be needed.
So from a mirror POV clearly labelled data chunks are better than
one glob a bit smaller than the sum to me.
From a distro user I also think clearly labelled ISO lead to less
confusion and also nobody should face
"Installation will need CD1 CD2 CD3 CD4"
"Okay" "Reboot"
and have to reboot/download/burn/restart because they forgot CD4,
if CD4 is not available it should be marked as such somewhere
and admin tools should suggest later on to insert the missing CDs
if needed or download the packages. I'm not saying it is easy
but it's the polish needed to try to get more desktop users IMHO.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
3:23 p.m.
On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard <veillard(a)redhat.com> wrote:
From a distro user I also think clearly labelled ISO lead to less
confusion and also nobody should face
"Installation will need CD1 CD2 CD3 CD4"
"Okay" "Reboot"
Clearly labeled? what does that mean exactly? The only way to be sure
you have the cds you need.. is to know exactly what is on each cd...
package by package. You aren't going to break out things with easily
digestable labels in such a way that makes sense to everyone.
You have a KDE cd and a game cd... which cd has the kde game you
want? Items can and will be intuitive members of multiple simple
labels.
You have a development tools cd and a java cd... which one
intuitively has the development tools for java? And god forbid we ever
see a java based game.
The only way to be absolutely sure is to have a mechanism likr say a
webpage.. people can go to before they download anything.. where they
run through a mock install-time package selection session and that
form spits out the isos they 'need'
-jef
3:51 p.m.
Jeff Spaleta wrote:
On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard
<veillard(a)redhat.com> wrote:
> From a distro user I also think clearly labelled ISO lead to less
>confusion and also nobody should face
> "Installation will need CD1 CD2 CD3 CD4"
> "Okay" "Reboot"
Clearly labeled? what does that mean exactly? The only way to be sure
you have the cds you need.. is to know exactly what is on each cd...
package by package. You aren't going to break out things with easily
digestable labels in such a way that makes sense to everyone.
Mandrake had (has?) a mechanism where, at the beginning of the installation,
you'd tell the installer which CDs you have. The installer would then disable
the package selections that weren't available with the selected CD set.
I think such a solution would be good enough for most users, even with
relatively vague labels on each CD. For the uber-curious, a listing of the
RPMS directory posted on some server would be fine.
The "OK, Reboot" solution is not really a solution at all. If you only have 3
CDs, the last thing you want to do is play "find the offending package",
spending 20 minutes creating a package selection, partition scheme, and system
setup; then find out that you still need CD4, and lather, reboot, repeat.
4:29 p.m.
On Tue, 22 Feb 2005 14:51:00 -0700, Tyler Larson
<fedora-devel(a)tlarson.com> wrote:
I think such a solution would be good enough for most users, even with
relatively vague labels on each CD. For the uber-curious, a listing of the
RPMS directory posted on some server would be fine.
There are 2 different but related problems.
1) Making sure users have the disks they need for what they want.
2) Making sure the installer doesn't let users try to install items
don't have the disks for. (assuming of course a non-networked install)
The solution you propose addresses problem 2. Whether or not its good
enough for 'most' users is an open question. This solution supposes
that the default package selection isn't good enough for most users.
If most users are customizing the package selection at install time, i
would argue they do so with specific items in mind and not finding
what they are looking for would be as frustrating as being told to get
extra cds. I think you would have to make absolutely clear that
certain packages aren't available at install time because they do not
have the full media set, so the user knows the missing crap can be
installed later after firstboot from media or from the network. Even
then.. solving problem 1.. prevents this all together.
-jef
4:53 p.m.
Jeff Spaleta wrote:
On Tue, 22 Feb 2005 14:51:00 -0700, Tyler Larson
<fedora-devel(a)tlarson.com> wrote:
There are 2 different but related problems.
1) Making sure users have the disks they need for what they want.
2) Making sure the installer doesn't let users try to install items
don't have the disks for. (assuming of course a non-networked install)
[...]
installed later after firstboot from media or from the network. Even
then.. solving problem 1.. prevents this all together.
-jef
True, but as you pointed out, solving problem 1 is a difficult task. And then,
even with a sophisticated CD-selection web application, you can rest assured
that most people won't use it. They'll get the CDs from their friends, or from
their network administrator, or they'll just download all of the ones they
think they might use, just in case.
My opinion is that we solve problem 2 ('cause it need solving anyway), and
give some general guidelines for problem 1 (e.g. I would certainly not
download a Java CD).
8:05 p.m.
On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote:
On Tue, 22 Feb 2005 16:13:11 -0500, Daniel Veillard
<veillard(a)redhat.com> wrote:
> From a distro user I also think clearly labelled ISO lead to less
> confusion and also nobody should face
> "Installation will need CD1 CD2 CD3 CD4"
> "Okay" "Reboot"
Clearly labeled? what does that mean exactly? The only way to be sure
you have the cds you need.. is to know exactly what is on each cd...
package by package. You aren't going to break out things with easily
digestable labels in such a way that makes sense to everyone.
I think better labeled disks is a great idea. disc1, disc2, etc isn't
exactly helpful. Having core1, core1, gnome, kde, games, devel, java,
etc would be much easier to understand.
You have a KDE cd and a game cd... which cd has the kde game you
want? Items can and will be intuitive members of multiple simple
labels.
Sure, you're going to have some overlap, but in general this could be
solved without too much pain. For example, gnome-games and kde-games
are, at the end of the day, games so put them on the games disk. If the
user really wants them and expected them on the Gnome or KDE disk, then
all they have to do is yum install them, so no biggy (as far as I'm
concerned). I'd much prefer to only have to download half the volume of
four disks (even if it still involved four disks) and then hvae to yum
install a couple of packages (using that tasty GUI yum tool that's
planned) than have to download a whole bunch of stuff I don't intend to
use just for the sake of 'simplicity'.
You have a development tools cd and a java cd... which one
intuitively has the development tools for java? And god forbid we ever
see a java based game.
Ah, but if you think about java like everything else, then you've really
got java and java-devel.
The only way to be absolutely sure is to have a mechanism likr say a
webpage.. people can go to before they download anything.. where they
run through a mock install-time package selection session and that
form spits out the isos they 'need'
What a great idea. A simple but elegant way to solve this limited
confusion where you can go and select the packages you want to install
(in a very similar way to the current installer) and then it tells you
what disks you'll need and maybe even how much of the particular disk
you actually need.
Say for example, you select gnome, OOo and gnome-games. The installer
*might* tell you that gnome-games is on the games disk but that it's the
only file you need from that disk and that you could just install it as
a single case after the fact. While this is a dream case, it could
tell you that you need 90% or core1, 85% or core2, 90% of gnome, 55% of
OOo (who needs all the languages) and 3% of games. Because so little of
games is needed, it might break down the few packages needed and look at
dependancies (and offer alternative ways to install these few packages).
Rodd
8:31 p.m.
Rodd Clarkson wrote:
On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote:
>You have a KDE cd and a game cd... which cd has the kde game you
>want? Items can and will be intuitive members of multiple simple
>labels.
Sure, you're going to have some overlap, but in general this could be
solved without too much pain. For example, gnome-games and kde-games
are, at the end of the day, games so put them on the games disk. If the
user really wants them and expected them on the Gnome or KDE disk, then
all they have to do is yum install them, so no biggy (as far as I'm
concerned). I'd much prefer to only have to download half the volume of
four disks (even if it still involved four disks) and then hvae to yum
install a couple of packages (using that tasty GUI yum tool that's
planned) than have to download a whole bunch of stuff I don't intend to
use just for the sake of 'simplicity'.
Except that now my games cd depends on both the gnome disc and the kde
disc. So I don't have a deterministic way to tell what CDs I need
again. So now I'm back to where I basically end up needing all the CDs.
Or I sometimes need all of them. And I don't know until I select my
packages.
Jeremy
9:41 a.m.
On Tue, 2005-02-22 at 21:31 -0500, Jeremy Katz wrote:
Rodd Clarkson wrote:
> On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote:
>>You have a KDE cd and a game cd... which cd has the kde game you
>>want? Items can and will be intuitive members of multiple simple
>>labels.
>
> Sure, you're going to have some overlap, but in general this could be
> solved without too much pain. For example, gnome-games and kde-games
> are, at the end of the day, games so put them on the games disk. If the
> user really wants them and expected them on the Gnome or KDE disk, then
> all they have to do is yum install them, so no biggy (as far as I'm
> concerned). I'd much prefer to only have to download half the volume of
> four disks (even if it still involved four disks) and then hvae to yum
> install a couple of packages (using that tasty GUI yum tool that's
> planned) than have to download a whole bunch of stuff I don't intend to
> use just for the sake of 'simplicity'.
Except that now my games cd depends on both the gnome disc and the kde
disc.
I don't think it's unreasonable to include the e.g. just KDE runtime
libraries on disc 1, but not necessarily all of KDE. The runtime
libraries should be fairly small relative to the entire desktop. Right?
9:59 a.m.
Colin Walters wrote:
On Tue, 2005-02-22 at 21:31 -0500, Jeremy Katz wrote:
>Rodd Clarkson wrote:
>
>>On Tue, 2005-02-22 at 16:23 -0500, Jeff Spaleta wrote:
>>
>>>You have a KDE cd and a game cd... which cd has the kde game you
>>>want? Items can and will be intuitive members of multiple simple
>>>labels.
>>
>>Sure, you're going to have some overlap, but in general this could be
>>solved without too much pain. For example, gnome-games and kde-games
>>are, at the end of the day, games so put them on the games disk. If the
>>user really wants them and expected them on the Gnome or KDE disk, then
>>all they have to do is yum install them, so no biggy (as far as I'm
>>concerned). I'd much prefer to only have to download half the volume of
>>four disks (even if it still involved four disks) and then hvae to yum
>>install a couple of packages (using that tasty GUI yum tool that's
>>planned) than have to download a whole bunch of stuff I don't intend to
>>use just for the sake of 'simplicity'.
>
>Except that now my games cd depends on both the gnome disc and the kde
>disc.
I don't think it's unreasonable to include the e.g. just KDE runtime
libraries on disc 1, but not necessarily all of KDE. The runtime
libraries should be fairly small relative to the entire desktop. Right?
If by small you mean huge, then yes :)
-sb
10:32 a.m.
Havoc Pennington wrote:
Hi,
Can I suggest two possible approaches...
1) we aren't willing to remove anything that was in FC3 due to the
upgrade problem, so we basically have to remove the stuff that's
new since FC3; just do that
If this is the case then maybe we should go with 5 CD for FC4 and wait
'til anaconda can handle multiple repos to trim packages. We run the
risk of releasing a FC3 with updated versions of the packages if you do
this. There no innovation there. I think some of the newer packages
need to be included in core to facilitate innovation in this distro.
3:54 p.m.
Elliot Lee wrote:
Hi all,
Here's a heads up that we need to get rid of about 300M of packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates. We also may
try to start removing stuff from Core in hopes that it will appear in
Extras if someone cares about it.
Nothing is set in stone, but if you want to write in favor of keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
You can view the list of new packages since FC3 (sorted by package size)
at http://people.redhat.com/sopwith/new-packages.txt
FYI,
-- Elliot
*Abridged Version*
Developers can be expected to work a little harder to establish a
working environment and have the knowledge skills and abilities to make
that happen. Consumers neither know how nor want to know how to work the
magic that makes everything the way they like it they would just like it
done for them. Towards this goals improve the end user experience so
that the developers continue to develop for a growing audience instead
of a shrinking one. I don't know if this is possible on short niotice
for FC4 but may be worth review for architecting fc5. Thank you and good
luck.
*Unabridged Version *
this seems like a discussion that is held frequently and is always
contentious. Instead of arguing the acceptability and merit of a
particular package perhaps our time is better spent working up a rough
framework of what our *specifications* are first. I think we are
designing the perfect solution to the indescribable problem here. I
would like to propose the following for consideration:
New/Average consumers represent the least experienced and the largest
growth segment for Fedora. They are most fickle in their adoption and
most skeptical in their approach. Developers, server administrators and
every other use case is commited to fedora for more substantial reasons
in most cases (development model, release cycles, etc) and have the
knowledge, skills and ability to take the time and perform and extra
step to transform the default working environment into their desired mode.
* New users that have little or no Linux experience seem to be
interested in Fedora at an increasing rate. I argue that they will
choose to adopt fedora if we make the dfeault environment as smooth as
possible for these users who have no knowledge and arguably shoudl
require no knowledge of repos and configuration files for things to Just
Work.
* Developers are basically knowledgable and communicative. If something
is not as we expected we ask each other on IRC or in a mailing list or
forum. We know how to configure repos and upgrade and install new
packages. If we don't it can at least be argued that we should be
able/required to learn.
* Fedora adoption of both consumers and developers is a good thin and
there are many more consumers than there are developers out there.
* Fedora relies on developers and will do so at an increasing rate with
the launch of fedora-extras
No I'm not arguing to purposefully make life more difficult for
developers. Instead i am arguing for the "greater good" created by the
developers ease of overcoming simple deviations and how detrimental
those same obstacles would be to the average/new user. To that end i am
suggesting that the user runtime environments (including a java runtime
that is differentiated from eclipse if they are currently bundled for
some odd reason), default desktop , and default applications (office,
web, file, mail, message) should take priority on the first CD['s]
(including required desktop libs to satisfy default apps). Once the
requirements for that are met than either place the alternatives on the
next/remaining cd's followed by the development tools or vice versa
depending on which user segment you think will benefit greater.
-mf
7:03 p.m.
On 15:35 21 Feb 2005, Elliot Lee <sopwith(a)redhat.com> wrote:
| Here's a heads up that we need to get rid of about 300M of packages to
| make sure that FC4 continues to fit on 4 CD's.
Something of an arbitrary limit, yes? The "we don't need lots of apps to do
the same thing" I can see, but this one?
| Right now eclipse, xfce,
| xemacs, cfengine, and all the games are leading candidates. We also may
| try to start removing stuff from Core in hopes that it will appear in
| Extras if someone cares about it.
Um, can't you "push it into extras and hope someone maintains it" instead
of this "drop it on the floor and hope someone picks it up and puts it
on another shelf" thing?
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
Prepare thy ablutions, worship the bean, and shun the abomination that is
decaf, and one day you too shall walk among the Blessd, whose blood flows
thick and brown with God's Chemical and whose hearts have been replaced with
the more efficient mechanism of a Mr. Coffee. - Keith Morris
3:48 p.m.
New subject: FC4 slimfast slimfest [minifc3]
As an exercise I made the "smallest" FC3 CD image possible that
installs, boots normal, brings up net, and can use yum. There
are no broken dependencies.
It uses 95 megs of RPMs. The full CD image is 288 megs, due to
size of Fedora/base/*.img which could also be shrunk.
If you're interested, take a look here:
ftp://ftp.blagblagblag.org/pub/BLAG/contrib/minifc3/
-Jeff
3:17 p.m.
Elliot Lee <sopwith(a)redhat.com> writes:
Here's a heads up that we need to get rid of about 300M of
packages to
make sure that FC4 continues to fit on 4 CD's. Right now eclipse, xfce,
xemacs, cfengine, and all the games are leading candidates.
Nothing is set in stone, but if you want to write in favor of
keeping
something, you'll have to suggest something else of equal or greater size
to axe instead.
Hi,
By all means axe games/eclipse/java/cfengine, but are you seriously
considering removing xemacs??
I really don't want to suggest other packages for removal. I hope
you'll find a solution that will keep the most essential tool *for me*
;-).
If you *absolutely* cannot keep xemacs, how about a compromise: keep
xemacs - 9681KB as reported by
ftp://download.fedora.redhat.com/pub/fedora/linux/core/3/i386/os/Fedora/R...
- and remove only xemacs-sumo (33611KB)? I have not checked, actually,
but it stands to reason that xemacs-sumo depends on xemacs but not the
other way around.
If you do this, then it would also be nice to put a notice regarding
where to get xemacs-sumo in the documentation, and maybe in the
default xemacs startup buffer.
Regards,
--
Oleg Goldshmidt | pub(a)NOSPAM.goldshmidt.org | http://www.goldshmidt.org
7035
days inactive
7036
days old
320 comments
101 participants
participants (101)
-
Aaron Luchko -
Alan Cox -
Alexander Boström -
Alexandre Oliva -
Andrew Overholt -
Arjan van de Ven -
Arjan van de Ven -
Bill Nottingham -
Bill Rees -
Bill Rugolsky Jr. -
Brian Pepple -
Cameron Simpson -
Carwyn Edwards -
Chris Adams -
Chuck Anderson -
Chuck Mead -
Colin Charles -
Colin Walters -
Cream -
Dag Wieers -
Dan Williams -
Dan Young -
Daniel Veillard -
Dave Jones -
David Woodhouse -
Demond -
Dimitrie O. Paun -
dragoran -
Ed Marshall -
Elliot Lee -
Emmanuel Seyman -
Eric S. Raymond -
Eric Warnke -
Felipe Alfaro Solana -
Florian La Roche -
Florin Andrei -
François Kooman -
Féliciano Matias -
Gavin Henry -
Genes MailLists -
Gerald Henriksen -
Gianluca Sforna -
Gérard Milmeister -
Hans Kristian Rosbach -
Harald Hoyer -
Havoc Pennington -
Jamie Zawinski -
Jason L Tibbitts III -
Jef Spaleta -
jeff -
Jeff Johnson -
Jeremy Katz -
Jesse Keating -
Josh Boyer -
Joshua Eichorn -
Josko Plazonic -
José Abílio Matos -
Konstantin Ryabitsev -
Kyrre Ness Sjobak -
Leszek Matok -
m g -
Marius Andreiana -
Matthew Miller -
Matthias Saou -
Michael A. Peters -
Michael Favia -
Michael Schwendt -
Michael Tiemann -
Nicolas Mailhot -
Nigel Metheringham -
Nils Philippsen -
Oleg Goldshmidt -
Panu Matilainen -
Paul A Houle -
Pedro Fernandes Macedo -
Per Bjornsson -
Peter Robinson -
Phil Muldoon -
Ralf Corsepius -
Ralf Ertzinger -
Ralph angenendt -
Reuben Farrelly -
Rex Dieter -
Richard June -
Rik van Riel -
Rodd Clarkson -
Ronny Buchmann -
Rudi Chiarito -
Rui Miguel Silva Seabra -
Sam Varshavchik -
seth vidal -
Stan Bubrouski -
Stephen John Smoogen -
Tet -
Thomas Fitzsimmons -
Tim Daly -
Tom Diehl -
Toshio Kuratomi -
Tyler Larson -
Ville Skyttä -
Yanko Kaneti