9:15 a.m.
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
FWIW, one thing that we're not likely to do is just push the schedule
out by a week for project foo, another week for project bar, etc. ad
nauseum.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
9:14 a.m.
2.6 is looking good. There's a lot of integration work to do,
though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
gnome 2.6
-sv
10:04 a.m.
On Mon, Dec 08, 2003 at 10:14:59AM -0500, seth vidal wrote:
gnome 2.6
While I don't want to discount this, I'd like to state here the
problem with it. GNOME is basically on a 6-month cycle. We are
trying to go just a trifle faster than 6 months; we say 2-3 times
a year. To go that fast, we will narrowly miss a GNOME release,
Then we'll catch up over a few releases... We delayed FC1 enough
that GNOME 2.4 got in it; so to my mind that's the in-sync release
and it will be a few more releases before we are back in sync.
So even if we were to pick up GNOME 2.6 this time, we would have
the same discussion every release until we bit the bullet.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:41 a.m.
On Mon, Dec 08, 2003 at 11:04:18AM -0500, Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 10:14:59AM -0500, seth vidal wrote:
> gnome 2.6
While I don't want to discount this, I'd like to state here the
problem with it. GNOME is basically on a 6-month cycle. We are
...
So even if we were to pick up GNOME 2.6 this time, we would have
the same discussion every release until we bit the bullet.
Apparantly I wasn't clear. GNOME 2.6 is not overruled -- I just
wanted to have the arguments for both sides on the table. It is
still very much an option worth discussing.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:46 a.m.
Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 11:04:18AM -0500, Michael K. Johnson wrote:
>On Mon, Dec 08, 2003 at 10:14:59AM -0500, seth vidal wrote:
>
>>gnome 2.6
>
>While I don't want to discount this, I'd like to state here the
>problem with it. GNOME is basically on a 6-month cycle. We are
...
>So even if we were to pick up GNOME 2.6 this time, we would have
>the same discussion every release until we bit the bullet.
Apparantly I wasn't clear. GNOME 2.6 is not overruled -- I just
wanted to have the arguments for both sides on the table. It is
still very much an option worth discussing.
I am very much in favor of gnome 2.6 as well as inclusion of xfce!
--
csm
Lunar Project Leader
Disclaimer: "I am not a curmudgeon! No... really..."
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
11:55 a.m.
On Mon, 2003-12-08 at 12:46, Chuck Mead wrote:
I am very much in favor of gnome 2.6 as well as inclusion of xfce!
I'd say that people who really want XFCE would easily be able to add it
to their yum.conf. As it doesn't require half the world in dependencies,
as, say, gnome and kde do, I really see no reason for its inclusion in
the core.
Regards,
--
Konstantin ("Icon") Riabitsev
Duke Physics Sysadmin, RHCE
12:09 p.m.
On Mon, 2003-12-08 at 12:55, Konstantin Riabitsev wrote:
On Mon, 2003-12-08 at 12:46, Chuck Mead wrote:
> I am very much in favor of gnome 2.6 as well as inclusion of xfce!
I'd say that people who really want XFCE would easily be able to add it
to their yum.conf. As it doesn't require half the world in dependencies,
as, say, gnome and kde do, I really see no reason for its inclusion in
the core.
Regards,
I concur, when you start talking about window manager inclusion, you are
going to find tons of people waving flags who want their particular
window manager included. Opening this up to debate will only waste tons
of time and feelings will ultimately wind up being hurt; and division
could ensue.
This is to say nothing against XFCE, as it seems to be a very capable
window manager.
Trae
--
Trae McCombs
http://occy.net/
founder: themes.org || linux.com
12:18 p.m.
Trae McCombs wrote:
On Mon, 2003-12-08 at 12:55, Konstantin Riabitsev wrote:
>On Mon, 2003-12-08 at 12:46, Chuck Mead wrote:
>
>>I am very much in favor of gnome 2.6 as well as inclusion of xfce!
>
>I'd say that people who really want XFCE would easily be able to add it
>to their yum.conf. As it doesn't require half the world in dependencies,
>as, say, gnome and kde do, I really see no reason for its inclusion in
>the core.
>
>Regards,
I concur, when you start talking about window manager inclusion, you are
going to find tons of people waving flags who want their particular
window manager included. Opening this up to debate will only waste tons
of time and feelings will ultimately wind up being hurt; and division
could ensue.
This is to say nothing against XFCE, as it seems to be a very capable
window manager.
Actually, though I am not the author, I have been xfce's host for a
number of years so I guess that gives me a bit of *right* to discuss
it... no one that I know of will be offended if xfce is not included in
core but it would be nice to have, particularly if we intend to provide
support in fedora for lighter, smaller installations.
--
csm
Lunar Project Leader
Disclaimer: "I am not a curmudgeon! No... really..."
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
12:46 p.m.
On Mon, 8 Dec 2003, Trae McCombs wrote:
On Mon, 2003-12-08 at 12:55, Konstantin Riabitsev wrote:
> On Mon, 2003-12-08 at 12:46, Chuck Mead wrote:
> > I am very much in favor of gnome 2.6 as well as inclusion of xfce!
>
> I'd say that people who really want XFCE would easily be able to add it
> to their yum.conf. As it doesn't require half the world in dependencies,
> as, say, gnome and kde do, I really see no reason for its inclusion in
> the core.
>
> Regards,
I concur, when you start talking about window manager inclusion, you are
going to find tons of people waving flags who want their particular
window manager included. Opening this up to debate will only waste tons
of time and feelings will ultimately wind up being hurt; and division
could ensue.
While I understand your point, I think there's a definite place for a
functional window manager in Fedora Core. It currently doesn't have
anything usable more modern than twm.... The kinds of users Fedora targets
probably want more flexibility / usability than provided by metacity.
later,
chris
3:03 p.m.
On Mon, Dec 08, 2003 at 01:46:41PM -0500, Chris Ricker wrote:
While I understand your point, I think there's a definite place
for a
functional window manager in Fedora Core. It currently doesn't have
anything usable more modern than twm.... The kinds of users Fedora targets
probably want more flexibility / usability than provided by metacity.
Strong ACK. I've used Red Hat 6.2 with GNOME and Enlightenment as
my home desktop machine until recently on a 350MHz P2 machine. I've
now upgraded to a 2600MHz P4 with 1G RAM and FC1. And what can I say...
it's NOT feeling quicker (the GUI), but it (metacity) lacks serious
capabilites I've used all the time. You can't even force window
stacking.
I'd like to see Enlightenment coming back as window manager choice
(if not default), which is correctly integrated into the GNOME
environment. My own experiments to bring back my desktop to the same
usablility as my RHL 6.2 box had were not successful as Enlightenment's
concept of "virtual desktops" seems to be incompatible with GNOME's,
or I don't find the right knob to fiddle with - I am by no way GUI
stuff savvy. :-)
Best regards,
Daniel
1:53 a.m.
On Mon, 08 Dec 2003 13:09:25 -0500, Trae McCombs wrote:
This is to say nothing against XFCE, as it seems to be a very
capable
window manager.
If memory serves correctly, there's a XFCE package ticket at
http://fedora.us, so in case XFCE will not be included within Fedora Core,
people could work together on publishing it as add-on packages and
future Fedora Extras.
--
12:39 p.m.
Michael Schwendt wrote:
On Mon, 08 Dec 2003 13:09:25 -0500, Trae McCombs wrote:
>This is to say nothing against XFCE, as it seems to be a very capable
>window manager.
If memory serves correctly, there's a XFCE package ticket at
http://fedora.us, so in case XFCE will not be included within Fedora Core,
people could work together on publishing it as add-on packages and
future Fedora Extras.
Already done for the current version:
[xfce4rpms]
name=Fedora Compatible XFCE4 Packages
baseurl=http://www.moongroup.com/yum-repository/fedora/linux/1/i686/xfce4...
#gpgcheck=1
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
5:36 p.m.
On Tue, 09 Dec 2003 13:39:10 -0500, Chuck Mead wrote:
Michael Schwendt wrote:
> On Mon, 08 Dec 2003 13:09:25 -0500, Trae McCombs wrote:
>
>
>>This is to say nothing against XFCE, as it seems to be a very capable
>>window manager.
>
>
> If memory serves correctly, there's a XFCE package ticket at
> http://fedora.us, so in case XFCE will not be included within Fedora Core,
> people could work together on publishing it as add-on packages and
> future Fedora Extras.
>
Already done for the current version:
[xfce4rpms]
name=Fedora Compatible XFCE4 Packages
baseurl=http://www.moongroup.com/yum-repository/fedora/linux/1/i686/xfce4...
#gpgcheck=1
Any plans on pushing those through the fedora.us QA process, e.g.
together with the trusted developer of these packages...?
https://bugzilla.fedora.us/show_bug.cgi?id=1090
--
4:57 a.m.
On Mon, 2003-12-08 at 17:04, Michael K. Johnson wrote:
While I don't want to discount this, I'd like to state here
the
problem with it. GNOME is basically on a 6-month cycle. We are
trying to go just a trifle faster than 6 months; we say 2-3 times
a year. To go that fast, we will narrowly miss a GNOME release,
Though I think that Fedora will like to go for a 2-3 times a year
release, I think a 2 time a year release will probably be more
appropriaate, and more realistic as well.
You might not even get a "new" version of KDE, and remember, we don't
want to install beta software on this 2-3 times/year release.
So, let's stick to reality, and try to release twice a year. At least
this allows people/administrators to not run away from the Fedora
project. There's nothing worse than having to:
1. download 3 CD's every 3-4 months
2. install it
3. have it break something(s)
If this is the Fedora case, I see people moving quickly away.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
9:31 a.m.
On Mon, 2003-12-08 at 10:15, Michael K. Johnson wrote:
FWIW, one thing that we're not likely to do is just push the
schedule
out by a week for project foo, another week for project bar, etc. ad
nauseum.
-Ditto GNOME 2.6!
-I've been playing around with Open/Red Carpet on my Fedora box and with
a little bit of work I think it would make a great addition to the
distro. Populate it with the proper channels and maybe make it support
yum and we'd have a GUI manager for new users.
-Multiple filesystem support in the installer (XFS, etc.)
Thanks!
-jorge
9:31 a.m.
-I've been playing around with Open/Red Carpet on my Fedora box
and with
a little bit of work I think it would make a great addition to the
distro. Populate it with the proper channels and maybe make it support
yum and we'd have a GUI manager for new users.
common metadata repository format support should be on the list for
fedora core 2.
-sv
9:34 a.m.
On Mon, 8 Dec 2003, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Integration of fedora.us and fedora.redhat.com / infrastructure in place for
external contribution
inclusion of opengroupware would be nice, but that might be better in extras
at first
later,
chris
8:47 p.m.
New subject: OpenGroupware (was: Fedora Core 2 wishlists)
On Mon, 2003-12-08 at 08:34, Chris Ricker wrote:
inclusion of opengroupware would be nice, but that might be better in extras
at first
OpenGroupware is great. Once the Evolution connector is finished, I
expect to see a massive uptick in deployments.
I'm subscribed to the OpenGroupware development mailing list and the
there are folks on there who are working through issues of making proper
Debian packages of it.
There are are "unique" things about the OpenGroupware file layout that
will be changing to a more standardized approach in the near future. I
would suggest waiting for that to happen.
One other packing issue is that currently there hasn't been any
"releases" of it. The website just publishes nightly snapshots. This
isn't to say the code is immature, since OpenGroupware's source code
dates back seven years as the underlying source code for their
commercial SKYRiX Groupware Server.
Helge Hess (the main developer) stated that he might publish a 1.0
release that has been QA tested and whatnot early next year.
Anyways, I'm all in favor of including it (I know Harold has some RH
packages on the people.redhat.com server), but it may be a bit
premature.
Dax Kelson
Guru Labs
8:57 p.m.
New subject: OpenGroupware (was: Fedora Core 2 wishlists)
On Mon, 2003-12-08 at 18:47, Dax Kelson wrote:
Anyways, I'm all in favor of including it (I know Harold has some
RH
packages on the people.redhat.com server), but it may be a bit
premature.
Harald's RPMS are quite a bit out of date and the SRPMS that you can get
from the OGo download site don't actually build; I'm not sure what they
use to build them, but they don't work. I opened a bug report for them,
and they didn't know what spec files I was talking about.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
9:39 a.m.
Depending on planned release date(s) for FC2, i would love to see gtk 2.3 /
gnome 2.6 in the next release. It has a few very interesting features in the
works that would really help make FC2 a great experiance (on the simplest
level, having the new file picker and nautilus modes would already have a
big "how-it-feels" impact)
Also the new evolution (1.5 has just been released and working quite well),
and gimp (1.3.x is starting to look real good) would be great additions
Gnome 2.6 final should be out March 10, 2004. Is that in time for FC2's
plans?
Gnome's schedule, leading upto 2.6:
December 2003
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6
7 (8) 9(10)11 12 13 2.5.1, API/ABI Freeze
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28(29)30(31) 2.5.2 tarballs due and released
January 2004
Su Mo Tu We Th Fr Sa
1 2 3
4 5 6 7 8 9 10
11(12)13(14)15 16 17 2.5.3, Feature, Module and UI Freeze
18 19 20 21 22 23 24
25(26)27(28)29 30 31 2.5.4 tarballs due and released
February 2004
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 (9)10(11)12 13 14 Beta 1, String and Hard UI Freeze
15 16 17 18 19 20 21
22(23)24(25)26 27 28 Beta 2, HARD CODE FREEZE
29
March 2004
Su Mo Tu We Th Fr Sa
(1) 2 (3) 4 5 6 Release Candidate tarballs due and released
7 (8) 9(10)11 12 13 GNOME 2.6.0 FINAL
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
1:50 p.m.
Chris Chabot (chabotc(a)4-ice.com) said:
Also the new evolution (1.5 has just been released and working quite
well),
and gimp (1.3.x is starting to look real good) would be great additions
This depends on those reaching stable release states in a reasonable
time. For gimp I'd certainly question that based on history. *ducks*
Bill
4:42 p.m.
My wishlist for FC2:
- a fully working speedtch kernel module!
Tha means adding a pppd supporting plugins (libpppoa.o for example).
The way it is now is useless: either remove it or let it be able to work
out-of-the-box.
Cheers, Giacomo.
6:58 p.m.
On Mon, 2003-12-08 at 09:39, Chris Chabot wrote:
level, having the new file picker and nautilus modes would already
have a
big "how-it-feels" impact)
Amen to that. FC 2 should include GNOME 2.6/GTK+ 2.4 just for the new
file selector *alone*. It's nice, but the real reason I want it so
badly is that I can't be the only one who's sick of seeing reviews of
Red Hat/Fedora releases that say, "Wow, really great, and I really love
Gnome... except for the evil, ugly file selector. Because of this, I
must recommend KDE." Seriously, I've really seen people that consider
the file selector such a huge deal they spend whole paragraphs on it. A
final death for this annoyance would be lovely. This way we can move on
from fielding GTK file selector trolls to
misunderstanding-spatial-Nautilus trolls! Hooray!
Anyway, yeah, another +1 for GNOME 2.6 going in - maybe FC 3 can pass on
2.8?
- jck
--
"To turn $100 into $110 is work. To turn $100 million into $110 million
is inevitable"
-- Edgar Bronfman
9:42 p.m.
New subject: Which I/O scheduler as default [was Re: Fedora Core 2 wishlists]
In case people are not tracking the current tiobench numbers from OSDL,
so far the anticaptory io scheduler (AS) from 2.6 isn't that hot on TCQ
aware hardware. Keep in mind that AS is the default IO scheduler for 2.6
http://developer.osdl.org/judith/tiobench/test11/
Given that SATA controller/disks as well as 3ware IDE controllers are
SATA aware, it might be worthwhile to possibly switch to using deadline
as the default IO scheduler for FC2 or maybe switch to that incase
someone selects a server install
Nick,Jens,Andrew are aware of the current issues wrt AS-iosched on 2.6
Also, it would be nice to have libevent installed in FC2 (that would
help get applications migrated over to epoll)
http://www.monkey.org/~provos/libevent/
Regards, Yusuf
--
If you're not using Firebird, you're not surfing the web
you're suffering it
http://www.mozilla.org/products/firebird/why/
8:02 a.m.
New subject: Which I/O scheduler as default [was Re: Fedora Core 2 wishlists]
On Tue, Dec 09, 2003 at 11:42:19AM +0800, Yusuf Goolamabbas wrote:
Also, it would be nice to have libevent installed in FC2 (that would
help get applications migrated over to epoll)
http://www.monkey.org/~provos/libevent/
Here I thought that epoll was so simple no one would want to wrap it...
(Yes, I understand that's not all libevent is)
We don't normally include libraries that are not required by software
that's in the distribution. To do otherwise would mean utter lack of
testing.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
9:14 a.m.
New subject: Which I/O scheduler as default [was Re: Fedora Core 2 wishlists]
On Tue, Dec 09, 2003 at 11:42:19AM +0800, Yusuf Goolamabbas wrote:
> Also, it would be nice to have libevent installed in FC2 (that would
> help get applications migrated over to epoll)
>
> http://www.monkey.org/~provos/libevent/
Here I thought that epoll was so simple no one would want to wrap it...
(Yes, I understand that's not all libevent is)
We don't normally include libraries that are not required by software
that's in the distribution. To do otherwise would mean utter lack of
testing.
However, libevent is standard in NetBSD,OpenBSD (not sure about FreeBSD)
so it's been tested from that perspective.
and if libevent were available in Fedora, applications would start to
use it and be scalable and portable at the same time
Similar if Michael Tokarev's TinyCDB implementation were made available
http://www.corpit.ru/mjt/tinycdb.html, then maybe Wietse might even
consider including his CDB patch in an upcoming release
For those who want to build fast indexed files and don't want to go
through BerkeleyDB versioning hell, CDB is a godsend
9:41 a.m.
On Mon, 2003-12-08 at 10:15, Michael K. Johnson wrote:
2.6 is looking good. There's a lot of integration work to do,
though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
1) smoother PostgreSQL upgrade path (in progress)
2) better lightweight desktop/window manager solutions (e.g. xfce4)
3) better definition of a truly bare-bones server install
4) MozillaFirebird
(curious that 3 of these 4 things have to do with reducing code
footprint. I guess you can infer that either I have too much old
hardware, or bloat has become an issue, or I suppose that I'm just
totally off-base here)
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
9:50 a.m.
On Mon, 2003-12-08 at 10:41, Karl DeBisschop wrote:
4) MozillaFirebird
Yes! MozillaFirebird needs to be in Fedora. I'm not quite sure why it's
not included.
--
Trae McCombs
http://occy.net/
founder: themes.org || linux.com
10:05 a.m.
On Mon, 2003-12-08 at 10:48, seth vidal wrote:
On Mon, 2003-12-08 at 10:50, Trae McCombs wrote:
> On Mon, 2003-12-08 at 10:41, Karl DeBisschop wrote:
> > 4) MozillaFirebird
>
> Yes! MozillaFirebird needs to be in Fedora. I'm not quite sure why it's
> not included.
b/c it is so far from stable it's fairly painful right now.
I humbly beg to differ. I've had no crashes or lockups using it almost
exclusively for ~5 months now. Every now and then there are some issues,
but thats b/c I work off nightly builds. I don't think a 0.8 MozFirebird
should be excluded from consideration.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
10:11 a.m.
I humbly beg to differ. I've had no crashes or lockups using it
almost
exclusively for ~5 months now. Every now and then there are some issues,
but thats b/c I work off nightly builds. I don't think a 0.8 MozFirebird
should be excluded from consideration.
I used it for 15 minutes last week and it crashed once, locked up once
and ate my toolbar once.
not exactly stellar behavior, imo.
-sv
4:57 a.m.
On Mon, 2003-12-08 at 17:11, seth vidal wrote:
> I humbly beg to differ. I've had no crashes or lockups using
it almost
> exclusively for ~5 months now. Every now and then there are some issues,
> but thats b/c I work off nightly builds. I don't think a 0.8 MozFirebird
> should be excluded from consideration.
I used it for 15 minutes last week and it crashed once, locked up once
and ate my toolbar once.
not exactly stellar behavior, imo.
Seems to work wonderfully here. That said, we probably shouldn't include
Firebird or even Thunderbird, till these software packages become
stable.
Also, since by default we choose Ximian Evolution for e-mail,
Thunderbird's inclusion should be in the Extras repository.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
11:07 a.m.
On Mon, Dec 08, 2003 at 11:05:02AM -0500, Karl DeBisschop wrote:
On Mon, 2003-12-08 at 10:48, seth vidal wrote:
> > Yes! MozillaFirebird needs to be in Fedora. I'm not quite sure why
it's
> > not included.
> b/c it is so far from stable it's fairly painful right now.
I humbly beg to differ. I've had no crashes or lockups using it almost
exclusively for ~5 months now. Every now and then there are some issues,
but thats b/c I work off nightly builds. I don't think a 0.8 MozFirebird
should be excluded from consideration.
This just means that people are stumbling upon the begs and fixing them
before you get around to stumbling on them... Nightly builds may *reduce*
the chance that you will see one of the many bugs... :-)
mark
--
mark@mielke.cc/markm@ncf.ca/markm(a)nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
10:28 a.m.
On Mon, 8 Dec 2003, Karl DeBisschop wrote:
3) better definition of a truly bare-bones server install
I support this one.
Why must I waste min 64 megs ram on an old gateway box, I like the idea of
able to bare bones install on 32 megs ram or less, i have a 486 gw box
ran for years, no need to upgrade it for what it does, still runs a VERY
ancient version of RH because it has 8 megs ram and nothing since rh6 will
install, to put a modern OS on it i could put slackware, but why
slackware, when RH should do this as it used to, a text install should
use SFA as it doesnt need gui..
11:01 a.m.
On Mon, 2003-12-08 at 16:28, adam(a)ausics.net wrote:
On Mon, 8 Dec 2003, Karl DeBisschop wrote:
> 3) better definition of a truly bare-bones server install
I support this one.
Why must I waste min 64 megs ram on an old gateway box, I like the idea of
able to bare bones install on 32 megs ram or less, i have a 486 gw box
ran for years, no need to upgrade it for what it does, still runs a VERY
ancient version of RH because it has 8 megs ram and nothing since rh6 will
install, to put a modern OS on it i could put slackware, but why
slackware, when RH should do this as it used to, a text install should
use SFA as it doesnt need gui..
I'd really like to see a diet-Fedora iso which just does minimal setup
of partitions, formatting, base install etc, and doesn't do any package
installation etc until firstboot. If this were to happen, AIUI, the
biggest part of the "needs at least 64MB to install" problem would go
away.
Once we have bare-bones Fedora installation materials like this, the
doors would be open to all sorts of other fun projects like for e.g. a
firewall project based on Fedora.
Dave
11:55 a.m.
On Mon, Dec 08 2003 at 10:01,
Dave Jones <davej(a)redhat.com> wrote:
I'd really like to see a diet-Fedora iso which just does minimal
setup
of partitions, formatting, base install etc, and doesn't do any package
installation etc until firstboot. If this were to happen, AIUI, the
biggest part of the "needs at least 64MB to install" problem would go
away.
Once we have bare-bones Fedora installation materials like this, the
doors would be open to all sorts of other fun projects like for e.g. a
firewall project based on Fedora.
+1, bare-bones install would be high on my list for FC2.
Mike
1:53 p.m.
Dave Jones (davej(a)redhat.com) said:
I'd really like to see a diet-Fedora iso which just does minimal
setup
of partitions, formatting, base install etc, and doesn't do any package
installation etc until firstboot. If this were to happen, AIUI, the
biggest part of the "needs at least 64MB to install" problem would go
away.
No, that just moves the issue to the first boot, where it will *then*
die due to not enough memory.
Bill
2:17 p.m.
On Mon, 2003-12-08 at 21:53, Bill Nottingham wrote:
Dave Jones (davej(a)redhat.com) said:
> I'd really like to see a diet-Fedora iso which just does minimal setup
> of partitions, formatting, base install etc, and doesn't do any package
> installation etc until firstboot. If this were to happen, AIUI, the
> biggest part of the "needs at least 64MB to install" problem would go
> away.
No, that just moves the issue to the first boot, where it will *then*
die due to not enough memory.
Umm.. depends on what sort of monster you create out of firstboot. My
P90 with 32MB memory is happily running FC1 after having updated it with
apt, just the upgrade had to be done in couple of steps because of
disk-space shortage (450MB :)
- Panu -
2:48 p.m.
Panu Matilainen (pmatilai(a)welho.com) said:
> No, that just moves the issue to the first boot, where it will
*then*
> die due to not enough memory.
Umm.. depends on what sort of monster you create out of firstboot. My
P90 with 32MB memory is happily running FC1 after having updated it with
apt, just the upgrade had to be done in couple of steps because of
disk-space shortage (450MB :)
It's not firstboot that's the problem. It's the RPM transaction.
Bill
2:58 p.m.
On Mon, 2003-12-08 at 22:48, Bill Nottingham wrote:
Panu Matilainen (pmatilai(a)welho.com) said:
> > No, that just moves the issue to the first boot, where it will *then*
> > die due to not enough memory.
>
> Umm.. depends on what sort of monster you create out of firstboot. My
> P90 with 32MB memory is happily running FC1 after having updated it with
> apt, just the upgrade had to be done in couple of steps because of
> disk-space shortage (450MB :)
It's not firstboot that's the problem. It's the RPM transaction.
Remember we're talking about minimal installations with maybe 100
packages installed. 32MB with swap enabled is no problem for such an
installation memory wise, the transaction isn't big on these kind of
boxes...
- Panu -
3:12 p.m.
Panu Matilainen (pmatilai(a)welho.com) said:
> > Umm.. depends on what sort of monster you create out of
firstboot. My
> > P90 with 32MB memory is happily running FC1 after having updated it with
> > apt, just the upgrade had to be done in couple of steps because of
> > disk-space shortage (450MB :)
>
> It's not firstboot that's the problem. It's the RPM transaction.
Remember we're talking about minimal installations with maybe 100
packages installed. 32MB with swap enabled is no problem for such an
installation memory wise, the transaction isn't big on these kind of
boxes...
Have you *tested* a full RPM transaction here as opposed to in anaconda?
I'd think you'd find the results are somewhat similar.
Bill
3:32 p.m.
On Mon, 2003-12-08 at 23:12, Bill Nottingham wrote:
Panu Matilainen (pmatilai(a)welho.com) said:
> > > Umm.. depends on what sort of monster you create out of firstboot. My
> > > P90 with 32MB memory is happily running FC1 after having updated it with
> > > apt, just the upgrade had to be done in couple of steps because of
> > > disk-space shortage (450MB :)
> >
> > It's not firstboot that's the problem. It's the RPM transaction.
>
> Remember we're talking about minimal installations with maybe 100
> packages installed. 32MB with swap enabled is no problem for such an
> installation memory wise, the transaction isn't big on these kind of
> boxes...
Have you *tested* a full RPM transaction here as opposed to in anaconda?
I'd think you'd find the results are somewhat similar.
The box has been upgraded live from RHL 7.2->7.3->8.0->9 -> FC1 and up
to 8.0 the trimmed-down package set was small enough to fit into *disk*
(remember, 450MB disk..) simultaneously during upgrade so it was
possible to do the upgrade in single transaction.
Anaconda certainly consumes gobs of memory but 32MB memory + 32/64MB
swap will get you a long way.. A stock workstation class RHL 9 upgrade
to FC1 with apt (while testing the rpmlib-implementation) topped at
around 70MB (IIRC) memory usage so would get tight on a 32MB box but
again we're talking about a much smaller package set too.
Not that I really care, I've been running it more out of curiosity to
see how far it can go than anything else. So far it's done just fine :)
- Panu -
7:07 p.m.
On Mon, 2003-12-08 at 20:48, Bill Nottingham wrote:
> Umm.. depends on what sort of monster you create out of
firstboot. My
> P90 with 32MB memory is happily running FC1 after having updated it with
> apt, just the upgrade had to be done in couple of steps because of
> disk-space shortage (450MB :)
It's not firstboot that's the problem. It's the RPM transaction.
Was there a reason that we couldn't do multiple small transactions as
opposed to a single big one on systems with small amounts of RAM ?
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
7:34 p.m.
On Tue, 2003-12-09 at 01:18, seth vidal wrote:
> Was there a reason that we couldn't do multiple small
transactions as
> opposed to a single big one on systems with small amounts of RAM ?
>
Breaking up the transaction into sets is very difficult to do on large
sets of packages, iirc.
I'm more confused now than I was when this thread started.
On a minimal install, why is this transaction so large that it
still needs at least 64MB ?
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
1:02 a.m.
On Tue, 2003-12-09 at 03:48, seth vidal wrote:
> On a minimal install, why is this transaction so large that it
> still needs at least 64MB ?
doing the dependency calculations raise the transaction set size when
you're testing.
I think it has to do with expanding the headers in the ts. I'm not
completely sure..
Python + rpm-python probably cause some significant memory overhead. For
a full upgradeset from RHL 9 -> FC1 apt topped at somewhere around 70MB
memory usage (very unscientific method of watching top used to measure),
yum grew to over 100MB, put anaconda on top of that and ... you're in
serious trouble on a 32MB box.
But again for a minimal system with ~100 packages instead of hundreds of
packages..
- Panu -
1:02 a.m.
Python + rpm-python probably cause some significant memory overhead.
For
a full upgradeset from RHL 9 -> FC1 apt topped at somewhere around 70MB
memory usage (very unscientific method of watching top used to measure),
yum grew to over 100MB, put anaconda on top of that and ... you're in
serious trouble on a 32MB box.
the dep checking in yum is where memory is eaten from what I've seen.
That's b/c of all the 'a' mode headers being addInstalled. That part is
going away in the next major release. Pursuant to the metadata stuff.
-sv
1:19 a.m.
On Tue, 2003-12-09 at 09:02, seth vidal wrote:
> Python + rpm-python probably cause some significant memory
overhead. For
> a full upgradeset from RHL 9 -> FC1 apt topped at somewhere around 70MB
> memory usage (very unscientific method of watching top used to measure),
> yum grew to over 100MB, put anaconda on top of that and ... you're in
> serious trouble on a 32MB box.
the dep checking in yum is where memory is eaten from what I've seen.
Indeed - IIRC it drops significantly after that part is done.
That's b/c of all the 'a' mode headers being
addInstalled. That part is
going away in the next major release. Pursuant to the metadata stuff.
Excellent :)
- Panu -
8:06 a.m.
Bill,
On Mon, 8 Dec 2003, Bill Nottingham wrote:
Dave Jones (davej(a)redhat.com) said:
> I'd really like to see a diet-Fedora iso which just does minimal setup
> of partitions, formatting, base install etc, and doesn't do any package
> installation etc until firstboot. If this were to happen, AIUI, the
> biggest part of the "needs at least 64MB to install" problem would go
> away.
No, that just moves the issue to the first boot, where it will *then*
die due to not enough memory.
But what about the main point in question, if we can do it with upto RH6,
we can do it now with current slackware, so why cant we do a basic
text install in fedora with piddly amount of ram, I mean, this is linux
afterall, not winbloze :)
Regards
1:55 p.m.
adam(a)ausics.net (adam(a)ausics.net) said:
> 3) better definition of a truly bare-bones server install
I support this one.
Why must I waste min 64 megs ram on an old gateway box, I like the idea of
able to bare bones install on 32 megs ram or less, i have a 486 gw box
ran for years, no need to upgrade it for what it does, still runs a VERY
ancient version of RH because it has 8 megs ram and nothing since rh6 will
install, to put a modern OS on it i could put slackware, but why
slackware, when RH should do this as it used to, a text install should
use SFA as it doesnt need gui..
Note that Red Hat hasn't even shipped a kernel that supported that
box for multiple releases (since 7.3). I'm not sure that scaling
back the requirements that much is something that fits the model
of always moving forward with new technology.
Bill
2:09 p.m.
On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
Note that Red Hat hasn't even shipped a kernel that supported
that
box for multiple releases (since 7.3). I'm not sure that scaling
back the requirements that much is something that fits the model
of always moving forward with new technology.
Huh? Sure we have. You can use the BOOT kernel if you don't mind
missing a few pieces. :-)
Moving technology forward doesn't HAVE to mean being in a race with
memory, cpu, and disk producing companies. We want to scale small
as well as large, and I'm not strictly opposed to making this
available if we can figure out how to do it without making life
significantly harder for us.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:25 p.m.
Michael K. Johnson (johnsonm(a)redhat.com) said:
On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> Note that Red Hat hasn't even shipped a kernel that supported that
> box for multiple releases (since 7.3). I'm not sure that scaling
> back the requirements that much is something that fits the model
> of always moving forward with new technology.
Huh? Sure we have. You can use the BOOT kernel if you don't mind
missing a few pieces. :-)
... and having it configured with different built-ins, etc. If we
went this route, we'd want a generic kernel.
Moving technology forward doesn't HAVE to mean being in a race
with
memory, cpu, and disk producing companies. We want to scale small
as well as large, and I'm not strictly opposed to making this
available if we can figure out how to do it without making life
significantly harder for us.
To scale smaller generally requires changing the default applications,
which leads you down to including X versions of everything.
Bill
3:16 p.m.
On Mon, Dec 08, 2003 at 03:25:10PM -0500, Bill Nottingham wrote:
Michael K. Johnson (johnsonm(a)redhat.com) said:
> On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> > Note that Red Hat hasn't even shipped a kernel that supported that
> > box for multiple releases (since 7.3). I'm not sure that scaling
> > back the requirements that much is something that fits the model
> > of always moving forward with new technology.
>
> Huh? Sure we have. You can use the BOOT kernel if you don't mind
> missing a few pieces. :-)
... and having it configured with different built-ins, etc. If we
went this route, we'd want a generic kernel.
My point is that they can get *something* installed in those cases.
Obviously, if we want to take this seriously, we'd consider putting
back an i386 kernel configured normally.
> Moving technology forward doesn't HAVE to mean being in a
race with
> memory, cpu, and disk producing companies. We want to scale small
> as well as large, and I'm not strictly opposed to making this
> available if we can figure out how to do it without making life
> significantly harder for us.
To scale smaller generally requires changing the default applications,
which leads you down to including X versions of everything.
There's a difference between going out of our way to cater to this
use group and not putting artificial barriers in the way. I'm not
saying that we need to build, effectively, two different versions of
Fedora Core. I am saying that we should not take a father-knows-best
attitude and put up artificial barriers. So we shouldn't put lots
of work into it, but if something is easy to do to enable technical
experimentation with hardware, it's at *least* worth considering.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:24 p.m.
Michael K. Johnson (johnsonm(a)redhat.com) said:
> To scale smaller generally requires changing the default
applications,
> which leads you down to including X versions of everything.
There's a difference between going out of our way to cater to this
use group and not putting artificial barriers in the way. I'm not
saying that we need to build, effectively, two different versions of
Fedora Core. I am saying that we should not take a father-knows-best
attitude and put up artificial barriers. So we shouldn't put lots
of work into it, but if something is easy to do to enable technical
experimentation with hardware, it's at *least* worth considering.
Then build an i386 kernel; there, there's something that can be
done without lots of work. But if you really want to do it right,
it *will* be lots of work, some of it directly counter to other
goals of the project.
Bill
8:09 a.m.
On Tue, Dec 09, 2003 at 12:24:46AM -0500, Bill Nottingham wrote:
Michael K. Johnson (johnsonm(a)redhat.com) said:
> There's a difference between going out of our way to cater to this
> use group and not putting artificial barriers in the way. I'm not
> saying that we need to build, effectively, two different versions of
> Fedora Core. I am saying that we should not take a father-knows-best
> attitude and put up artificial barriers. So we shouldn't put lots
> of work into it, but if something is easy to do to enable technical
> experimentation with hardware, it's at *least* worth considering.
Then build an i386 kernel; there, there's something that can be
done without lots of work. But if you really want to do it right,
it *will* be lots of work, some of it directly counter to other
goals of the project.
I want to enable people to play with this. Yeah, we should build
a real i386 kernel besides BOOT. We should expose the Core component
under another name. You keep chasing a straw man and saying things
like "if you really want to do it right" even though I keep telling
you that this is NOT my goal. I want to enable experimentation.
THAT is consistent with the goals of the project. Building an i386
kernel and exposing the Core component under another name will not
damage the goals of the project.
And yes, I'm willing to draw a line in the sand and say "we are
not going to trim library dependencies just to make the dependency
set smaller for these kinds of installations". Does that make you
happier? :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
12:20 p.m.
Michael K. Johnson (johnsonm(a)redhat.com) said:
I want to enable people to play with this. Yeah, we should build
a real i386 kernel besides BOOT. We should expose the Core component
under another name. You keep chasing a straw man and saying things
like "if you really want to do it right" even though I keep telling
you that this is NOT my goal. I want to enable experimentation.
THAT is consistent with the goals of the project. Building an i386
kernel and exposing the Core component under another name will not
damage the goals of the project.
No, but I'm seeing proposals about alternate installers, changing
how packages are installed/transactions are handled; this is all
non trivial stuff to do with limited resources.
Bill
12:48 p.m.
On Tue, 2003-12-09 at 09:09, Michael K. Johnson wrote:
I want to enable people to play with this. Yeah, we should build
a real i386 kernel besides BOOT. We should expose the Core component
under another name.
Just "expose the Core component under another name" is a lot harder than
it sounds because there are a number of very real interface problems
that causes -- you then end up with what's basically "minimal" and
"more
minimal". Trust me, it's not hidden because I have some vendetta
against people wanting small installs. If that were the case, it
wouldn't exist at all. :)
Jeremy
2:15 p.m.
On Tue, Dec 09, 2003 at 01:48:49PM -0500, Jeremy Katz wrote:
Just "expose the Core component under another name" is a
lot harder than
it sounds because there are a number of very real interface problems
that causes -- you then end up with what's basically "minimal" and
"more
minimal". Trust me, it's not hidden because I have some vendetta
against people wanting small installs. If that were the case, it
wouldn't exist at all. :)
I've taken HCI, I'm not entirely clueless here. Obviously, the
language used to expose it must express what is happening. We
could call it the "Useless" class if you didn't want anyone to
select it, though that would get a flood of mailing list questions.
"Bare-bones" has been suggested. There's got to be the right name
somewhere to convey the right impression (install this and you are
on your own), but there's also the text that accompanies the name
and we really can describe what is going on there.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:50 p.m.
>>>> "MKJ" == Michael K Johnson
<johnsonm(a)redhat.com> writes:
MKJ> I've taken HCI, I'm not entirely clueless here. Obviously, the
MKJ> language used to expose it must express what is happening. We could
MKJ> call it the "Useless" class if you didn't want anyone to select it,
MKJ> though that would get a flood of mailing list questions. "Bare-bones"
MKJ> has been suggested. There's got to be the right name somewhere to
MKJ> convey the right impression (install this and you are on your own),
MKJ> but there's also the text that accompanies the name and we really can
MKJ> describe what is going on there.
Maybe focus on the way this type of install would be used. You install the
<foo> class and then manually add only the packages you need.
This brings to mind the following words:
o Fundamental
o Elemental
o Foundational
o Infrastructural (though "infrastructure" is a relatively overloaded
term these days)
o Additive (thinking of what you need to do to get a useful configuration)
o Add-On (ditto)
Do any of these terms strike a chord with anyone?
Ed
--
Ed Bailey Red Hat, Inc. http://www.redhat.com/
4:46 p.m.
On Tue, 2003-12-09 at 12:50, Edward C. Bailey wrote:
Maybe focus on the way this type of install would be used. You
install the
<foo> class and then manually add only the packages you need.
This brings to mind the following words:
o Fundamental
o Elemental
o Foundational
o Infrastructural (though "infrastructure" is a relatively overloaded
term these days)
o Additive (thinking of what you need to do to get a useful configuration)
o Add-On (ditto)
Do any of these terms strike a chord with anyone?
Yes, but unfortunately, it's a diminished 5th.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
3:42 p.m.
On Tue, 2003-12-09 at 15:15, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 01:48:49PM -0500, Jeremy Katz wrote:
> Just "expose the Core component under another name" is a lot harder than
> it sounds because there are a number of very real interface problems
> that causes -- you then end up with what's basically "minimal" and
"more
> minimal". Trust me, it's not hidden because I have some vendetta
> against people wanting small installs. If that were the case, it
> wouldn't exist at all. :)
I've taken HCI, I'm not entirely clueless here. Obviously, the
language used to expose it must express what is happening. We
could call it the "Useless" class if you didn't want anyone to
select it, though that would get a flood of mailing list questions.
"Bare-bones" has been suggested.
How about 'smallest?'
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
3:56 p.m.
On Tue, Dec 09, 2003 at 04:42:04PM -0500, Karl DeBisschop wrote:
How about 'smallest?'
Mmm, doesn't really tell people what they are going to get.
In the context of this conversation, someone can probably
figure out what "smallest" was intended to mean, but in the
context of the installer, it's not at all obvious. They
would say "smallest *what*?"
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
4:28 p.m.
On Tue, 2003-12-09 at 16:56, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 04:42:04PM -0500, Karl DeBisschop wrote:
> How about 'smallest?'
Mmm, doesn't really tell people what they are going to get.
In the context of this conversation, someone can probably
figure out what "smallest" was intended to mean, but in the
context of the installer, it's not at all obvious. They
would say "smallest *what*?"
I was thinking for some reason that 'minimal' was a current choice in
the installer, that's what I was comparing 'smallest' to. It's not, I
guess. You're probably right about needed better context to work.
OTOH it does seem rather more descriptive than 'Server' -- is it a web
server, a print server...
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
4:38 p.m.
On Tue, Dec 09, 2003 at 04:56:38PM -0500, Michael K. Johnson wrote:
In the context of this conversation, someone can probably
figure out what "smallest" was intended to mean, but in the
context of the installer, it's not at all obvious. They
would say "smallest *what*?"
"Bootstrap", which is really all that
it should be -- enough to bootstrap by
yum groupinstall <group>
Alternatively, "Base" or "Basesystem", but I like
"Bootstrap."
Regards,
Bill Rugolsky
5:30 p.m.
On Tuesday 09 December 2003 14:38, Bill Rugolsky Jr. wrote:
"Bootstrap", which is really all that
it should be -- enough to bootstrap by
yum groupinstall <group>
Alternatively, "Base" or "Basesystem", but I like
"Bootstrap."
Ah but the barebones system won't include yum. The absolute must
include stuff will be a command line rpm capable of installing rpms
from a CD or such. Barebones means barebones.
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
6:04 p.m.
On Tuesday 09 December 2003 14:38, Bill Rugolsky Jr. wrote:
> "Bootstrap", which is really all that
> it should be -- enough to bootstrap by
>
> yum groupinstall <group>
>
> Alternatively, "Base" or "Basesystem", but I like
"Bootstrap."
Ah but the barebones system won't include yum. The absolute must
include stuff will be a command line rpm capable of installing rpms
from a CD or such. Barebones means barebones.
yum is pretty essential for a bare bones install. The absolute bare bones
install is a kernel glibc and bash, the rest isnt required
6:14 p.m.
On Tuesday 09 December 2003 16:04, Alan Cox wrote:
yum is pretty essential for a bare bones install. The absolute bare
bones install is a kernel glibc and bash, the rest isnt required
The idea was to create the minimal system while still having a
commandline rpm. Yum is a bit more, but with the command line rpm, one
can easily add yum to the system. Without a command line rpm, it gets
to be quite difficult to add software to the system. I still firmly
suggest that the "Barebones" install include enough to run commandline
rpm, but not pull in other tools such as yum or apt or up2date or.....
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
6:44 p.m.
On Tue, Dec 09, 2003 at 04:14:42PM -0800, Jesse Keating wrote:
Content-Description: signed data
On Tuesday 09 December 2003 16:04, Alan Cox wrote:
> yum is pretty essential for a bare bones install. The absolute bare
> bones install is a kernel glibc and bash, the rest isnt required
The idea was to create the minimal system while still having a
commandline rpm. Yum is a bit more, but with the command line rpm, one
can easily add yum to the system. Without a command line rpm, it gets
to be quite difficult to add software to the system. I still firmly
suggest that the "Barebones" install include enough to run commandline
rpm, but not pull in other tools such as yum or apt or up2date or.....
I agree. Once you get beyond the absolute minimum system you can
boot and update in the most minimal way, we're right down a slipperly
slope to the current minimal-but-not-really-minimal situation and we
might as well not bother to change a thing. This is something that
you should not use unless you know EXACTLY what you are doing.
Now, I really like Alan's name of bootstrap for this.
If someone wants bootstrap+yum, they can do that and the installer
can work out the dependencies for them.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
3:20 p.m.
On Tuesday 09 December 2003 19:44, Michael K. Johnson wrote:
I agree. Once you get beyond the absolute minimum system you can
boot and update in the most minimal way, we're right down a slipperly
slope to the current minimal-but-not-really-minimal situation and we
might as well not bother to change a thing. This is something that
you should not use unless you know EXACTLY what you are doing.
Now, I really like Alan's name of bootstrap for this.
If someone wants bootstrap+yum, they can do that and the installer
can work out the dependencies for them.
Perhaps "bootstrap mode only comes up if you do an "expert" install.
--
Gene
3:26 p.m.
On Wed, 2003-12-10 at 16:20, Gene C. wrote:
On Tuesday 09 December 2003 19:44, Michael K. Johnson wrote:
> I agree. Once you get beyond the absolute minimum system you can
> boot and update in the most minimal way, we're right down a slipperly
> slope to the current minimal-but-not-really-minimal situation and we
> might as well not bother to change a thing. This is something that
> you should not use unless you know EXACTLY what you are doing.
>
> Now, I really like Alan's name of bootstrap for this.
>
> If someone wants bootstrap+yum, they can do that and the installer
> can work out the dependencies for them.
Perhaps "bootstrap mode only comes up if you do an "expert" install.
I would prefer that it is generally available. But I see your point.
As I was thinking this over last night, I did come to one reservation
about the word 'bootstrap' - does anyone have a sense of how well that
translates?
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
3:47 p.m.
On Wed, 10 Dec 2003, seth vidal wrote:
> As I was thinking this over last night, I did come to one reservation
> about the word 'bootstrap' - does anyone have a sense of how well that
> translates?
I can think of some horribly inappropriate translations ;)
Especially if y'all is usin' EN_redneck ;-)
-n
--
-------------------------------------------
nathan hruby <nhruby(a)uga.edu>
uga enterprise information technology services
production systems support
metaphysically wrinkle-free
-------------------------------------------
4:57 a.m.
On Wed, 2003-12-10 at 22:20, Gene C. wrote:
> If someone wants bootstrap+yum, they can do that and the
installer
> can work out the dependencies for them.
Perhaps "bootstrap mode only comes up if you do an "expert" install.
Nope, it has to happen before that. Because by the time we get to
installer screens in the current Fedora setup, Anaconda gets fired up
and it will fail if there's less than 64MB. Of course, text mode will
work just fine....
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
5:40 a.m.
On Wed, Dec 17, 2003 at 11:57:33AM +0100, Colin Charles wrote:
On Wed, 2003-12-10 at 22:20, Gene C. wrote:
> > If someone wants bootstrap+yum, they can do that and the installer
> > can work out the dependencies for them.
>
> Perhaps "bootstrap mode only comes up if you do an "expert" install.
Nope, it has to happen before that. Because by the time we get to
installer screens in the current Fedora setup, Anaconda gets fired up
and it will fail if there's less than 64MB. Of course, text mode will
work just fine....
Yeah no, I think you will find that text mode falls too if you have less than
64MB of RAM. I know it definitely fails on 32.
--
Mark Lane, CET mailto:mark@harddata.com
Hard Data Ltd. http://www.harddata.com
T: 01-780-456-9771 F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--
4:51 p.m.
On Tue, Dec 09, 2003 at 03:15:44PM -0500, Michael K. Johnson wrote:
language used to expose it must express what is happening. We
could call it the "Useless" class if you didn't want anyone to
select it, though that would get a flood of mailing list questions.
"Bare-bones" has been suggested. There's got to be the right name
"Bootstrap"
Its an absolutely minimal install you then boot to add other stuff.
It also happens to be precisely the package set a minimal installer needs
for small machines for bootstrapping literally as the name suggests, and
if bootstrap is sufficiently fittable on a single CD it makes Debian like
1 CD and network installs easier
4:57 a.m.
On Tue, 2003-12-09 at 23:51, Alan Cox wrote:
On Tue, Dec 09, 2003 at 03:15:44PM -0500, Michael K. Johnson wrote:
> language used to expose it must express what is happening. We
> could call it the "Useless" class if you didn't want anyone to
> select it, though that would get a flood of mailing list questions.
> "Bare-bones" has been suggested. There's got to be the right name
"Bootstrap"
Its an absolutely minimal install you then boot to add other stuff.
It also happens to be precisely the package set a minimal installer needs
for small machines for bootstrapping literally as the name suggests, and
if bootstrap is sufficiently fittable on a single CD it makes Debian like
1 CD and network installs easier
And, it helps that you can get a booting system, with full console
access in a 40 meg ISO.
Debian's minimalist feel should start brushing itself onto
Fedora-minimal for instance. People with servers will like this (or
older machines even).
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
2:19 p.m.
On Monday 08 December 2003 15:25, Bill Nottingham wrote:
Michael K. Johnson (johnsonm(a)redhat.com) said:
> On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> > Note that Red Hat hasn't even shipped a kernel that supported that
> > box for multiple releases (since 7.3). I'm not sure that scaling
> > back the requirements that much is something that fits the model
> > of always moving forward with new technology.
>
> Huh? Sure we have. You can use the BOOT kernel if you don't mind
> missing a few pieces. :-)
... and having it configured with different built-ins, etc. If we
went this route, we'd want a generic kernel.
> Moving technology forward doesn't HAVE to mean being in a race with
> memory, cpu, and disk producing companies. We want to scale small
> as well as large, and I'm not strictly opposed to making this
> available if we can figure out how to do it without making life
> significantly harder for us.
To scale smaller generally requires changing the default applications,
which leads you down to including X versions of everything.
Actually, I believe that some of the problem with a minimal install is
incorrect packaging. Doing a "minimal" install, you still get XFree86
installed (including XFree86-devel and a whole bunch of other devel
packages). For a system which does not configure X and is intended to be
minimal, this does not make sense to me.
--
Gene
2:37 p.m.
On Tuesday 09 December 2003 15:19, Gene C. wrote:
On Monday 08 December 2003 15:25, Bill Nottingham wrote:
> Michael K. Johnson (johnsonm(a)redhat.com) said:
> > On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> > > Note that Red Hat hasn't even shipped a kernel that supported that
> > > box for multiple releases (since 7.3). I'm not sure that scaling
> > > back the requirements that much is something that fits the model
> > > of always moving forward with new technology.
> >
> > Huh? Sure we have. You can use the BOOT kernel if you don't mind
> > missing a few pieces. :-)
>
> ... and having it configured with different built-ins, etc. If we
> went this route, we'd want a generic kernel.
>
> > Moving technology forward doesn't HAVE to mean being in a race with
> > memory, cpu, and disk producing companies. We want to scale small
> > as well as large, and I'm not strictly opposed to making this
> > available if we can figure out how to do it without making life
> > significantly harder for us.
>
> To scale smaller generally requires changing the default applications,
> which leads you down to including X versions of everything.
Actually, I believe that some of the problem with a minimal install is
incorrect packaging. Doing a "minimal" install, you still get XFree86
installed (including XFree86-devel and a whole bunch of other devel
packages). For a system which does not configure X and is intended to be
minimal, this does not make sense to me.
OOPS!!
My mistake. I just grep'ed /root/install.log and noticed all of the "devel"
packages. I should have read it more closely!! Those were for packages
available BUT NOT installed!
Sorry!
--
Gene
10:07 a.m.
On Monday 08 December 2003 15:09, Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> Note that Red Hat hasn't even shipped a kernel that supported that
> box for multiple releases (since 7.3). I'm not sure that scaling
> back the requirements that much is something that fits the model
> of always moving forward with new technology.
Huh? Sure we have. You can use the BOOT kernel if you don't mind
missing a few pieces. :-)
Moving technology forward doesn't HAVE to mean being in a race with
memory, cpu, and disk producing companies. We want to scale small
as well as large, and I'm not strictly opposed to making this
available if we can figure out how to do it without making life
significantly harder for us.
While minimal does create a pretty small system, it still brings in a lot of
devel packages. There are no compilers or real development tools, why would
I need all of those devel packages?
--
Gene
2:29 p.m.
On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
Note that Red Hat hasn't even shipped a kernel that supported
that
box for multiple releases (since 7.3). I'm not sure that scaling
back the requirements that much is something that fits the model
of always moving forward with new technology.
It sounds to me like a job for an alternatives installer (like miniconda
or maybe some mini yum based installer)
2:53 p.m.
On Mon, 2003-12-08 at 15:29, Alan Cox wrote:
On Mon, Dec 08, 2003 at 02:55:39PM -0500, Bill Nottingham wrote:
> Note that Red Hat hasn't even shipped a kernel that supported that
> box for multiple releases (since 7.3). I'm not sure that scaling
> back the requirements that much is something that fits the model
> of always moving forward with new technology.
It sounds to me like a job for an alternatives installer (like miniconda
or maybe some mini yum based installer)
yum needs to be lighter-weight in the install phase - something I'm
working on.
you should look at 'cinch' a floppy-based installer being written for
the caosity project. it uses yum for installs, too.
-sv
2:21 p.m.
On Mon, 2003-12-08 at 11:28, adam(a)ausics.net wrote:
On Mon, 8 Dec 2003, Karl DeBisschop wrote:
> 3) better definition of a truly bare-bones server install
I support this one.
Why must I waste min 64 megs ram on an old gateway box, I like the idea of
able to bare bones install on 32 megs ram or less, i have a 486 gw box
ran for years, no need to upgrade it for what it does, still runs a VERY
ancient version of RH because it has 8 megs ram and nothing since rh6 will
install, to put a modern OS on it i could put slackware, but why
slackware, when RH should do this as it used to, a text install should
use SFA as it doesnt need gui..
/me points to Fedora Core Objective #1 at
http://fedora.redhat.com/about/objectives.html:
"Create a complete general-purpose operating system with capabilities
equivalent to competing operating systems..."
In my opinion, targeting old machines with low ram is more of a
special-purpose task and is outside the scope of Objective #1. Seems
like it would be better suited to a Fedora sub-project.
Cheers,
Brent
7:39 p.m.
On Mon, 2003-12-08 at 20:21, Brent Fox wrote:
/me points to Fedora Core Objective #1 at
http://fedora.redhat.com/about/objectives.html:
"Create a complete general-purpose operating system with capabilities
equivalent to competing operating systems..."
In my opinion, targeting old machines with low ram is more of a
special-purpose task and is outside the scope of Objective #1.
Depends on your definition of "competing operating systems".
"Fedora won't install on this box, so I'll have to put
Debian/SuSE/xxxBSD/whatever on there instead".
IMO, Objective #1 is about offering features not setting the minimal
requirements to match those found in other OS's.
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
4:57 a.m.
On Mon, 2003-12-08 at 21:21, Brent Fox wrote:
/me points to Fedora Core Objective #1 at
http://fedora.redhat.com/about/objectives.html:
"Create a complete general-purpose operating system with capabilities
equivalent to competing operating systems..."
In my opinion, targeting old machines with low ram is more of a
special-purpose task and is outside the scope of Objective #1. Seems
like it would be better suited to a Fedora sub-project.
This is where you're greatly mistaken, and comments like this tend to
make people push Debian or Slackware for older machines (and their
servers.)
We should not get rid of the user group of folk with older PCs.
Developing countries will tend to use Fedora (since they can't afford
RHEL), and will usually have older hardware. These people tend to hear
of Red Hat, and will of course benefit greatly from Fedora. Don't chase
them away...
Vector Linux for instance runs on fairly old hardware. X in 16MB (or
24MB) of RAM. But that's a little off-tangent to this discussion.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
6:45 a.m.
On Wed, 2003-12-17 at 14:27, Colin Charles wrote:
We should not get rid of the user group of folk with older PCs.
Developing countries will tend to use Fedora (since they can't afford
RHEL), and will usually have older hardware. These people tend to hear
of Red Hat, and will of course benefit greatly from Fedora. Don't chase
them away...
Hear, hear!
roozbeh
2:41 p.m.
On Wed, 2003-12-17 at 05:57, Colin Charles wrote:
On Mon, 2003-12-08 at 21:21, Brent Fox wrote:
> /me points to Fedora Core Objective #1 at
> http://fedora.redhat.com/about/objectives.html:
>
> "Create a complete general-purpose operating system with capabilities
> equivalent to competing operating systems..."
>
> In my opinion, targeting old machines with low ram is more of a
> special-purpose task and is outside the scope of Objective #1. Seems
> like it would be better suited to a Fedora sub-project.
This is where you're greatly mistaken, and comments like this tend to
make people push Debian or Slackware for older machines (and their
servers.)
We should not get rid of the user group of folk with older PCs.
Developing countries will tend to use Fedora (since they can't afford
RHEL), and will usually have older hardware. These people tend to hear
of Red Hat, and will of course benefit greatly from Fedora. Don't chase
them away...
I never said anything about chasing anybody away. All I suggested was
that perhaps machines with this level of computing power could be better
served by a Fedora sub-project as opposed to the main project. It could
still be under the Fedora banner, just not the main trunk.
But anyway, I'm not speaking in any official capacity about the future
of Fedora...I'm just giving one developer's opinion. I do, however,
feel that it is wise to accept that one distribution cannot satisfy all
classes of machines and users.
Cheers,
Brent
2:29 a.m.
On Wed, 2003-12-17 at 21:41, Brent Fox wrote:
> We should not get rid of the user group of folk with older PCs.
> Developing countries will tend to use Fedora (since they can't afford
> RHEL), and will usually have older hardware. These people tend to hear
> of Red Hat, and will of course benefit greatly from Fedora. Don't chase
> them away...
I never said anything about chasing anybody away. All I suggested was
that perhaps machines with this level of computing power could be better
served by a Fedora sub-project as opposed to the main project. It could
still be under the Fedora banner, just not the main trunk.
Fair enough, so I guess this will spawn something like the Fedora LiveCD
project.
My perspective is for developing countries and schools that like to use
Red Hat Linux. And no, Red Hat's educational discount for schools is not
like what RHL9 provided[1]. And from a developing country, I guess I do
realise that we have much old(er) hardware lying around.
But anyway, I'm not speaking in any official capacity about the
future
of Fedora...I'm just giving one developer's opinion. I do, however,
feel that it is wise to accept that one distribution cannot satisfy all
classes of machines and users.
Agreed. Thanks for the positive comments Brent. Even if someone does
bring up the Debian method of running on just about any hardware, some
bleeding edge hardware tends to only be supported on Fedora for
instance. So, its never a win-win situation (heck, even Windows XP won't
run on old boxen).
But just keep in mind developing countries, poorer nations, and
educational institutions.
[1] - Paul Gear writes...
http://gear.dyndns.org/~paulgear/the_page_formerly_known_as_rhel.html
(if you haven't already seen it)
Thanks.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
10:11 p.m.
Getting User Mode Linux back in (with tools) would make testing of
future FC releases simpler. I for one don't have a spare machine at home
to test test releases with (and at work there are other priorities).
- Get the extras framework sorted and consign lots of the
old 'small userbase pet program' stuff to it (eg joe)
+1 Again makes testing the Core release simpler.
I'd really like to see a diet-Fedora iso which just does minimal
setup
of partitions, formatting, base install etc, and doesn't do any package
installation etc until firstboot.
+1
Carwyn
--
Carwyn Edwards
School of Informatics
University of Edinburgh
11:01 p.m.
On Tue, 2003-12-09 at 22:11, Carwyn Edwards wrote:
Getting User Mode Linux back in (with tools) would make testing of
future FC releases simpler. I for one don't have a spare machine at home
to test test releases with (and at work there are other priorities).
+1 here - this would make testing of FC 'test' releases much easier, and
probably a lot more widespread as a result...
- jck
--
"To turn $100 into $110 is work. To turn $100 million into $110 million
is inevitable"
-- Edgar Bronfman
9:18 a.m.
On Tue, Dec 09, 2003 at 11:01:44PM -0600, Jens Knutson wrote:
On Tue, 2003-12-09 at 22:11, Carwyn Edwards wrote:
> Getting User Mode Linux back in (with tools) would make testing of
> future FC releases simpler. I for one don't have a spare machine at home
> to test test releases with (and at work there are other priorities).
>
+1 here - this would make testing of FC 'test' releases much easier, and
probably a lot more widespread as a result...
I'd think that qemu (especially after it grows a PCI subsystem) would
be more useful for that testing.
Or, for a good large subset, just use anaconda to install into a
chroot. :-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
10:43 a.m.
Hi,
On Wed, 2003-12-10 at 04:11, Carwyn Edwards wrote:
Getting User Mode Linux back in (with tools) would make testing of
future FC releases simpler. I for one don't have a spare machine at home
to test test releases with (and at work there are other priorities).
I'm currently using qemu for this. FC1 runs great under it, and using
VNC you can also get proper X logins running from within a qemu
sandbox. I'm mostly running custom kernel builds with it but it will
boot a standard i686 kernel too. I believe arjan has even got anaconda
running in it over VNC; we plan to put together a howto for that.
The last major upstream qemu release wasn't quite stable for me, but
recent CVS has been pretty solid. I've got RPMS available at
http://people.redhat.com/sct/packages/
and see
http://fabrice.bellard.free.fr/qemu/
for docs. (In particular, see the bit about sudo: you'll need to set up
a sudoers entry for /etc/qemu-ifup if you want to be able to network the
virtual host.)
Cheers,
Stephen
11:20 a.m.
On Mon, 2003-12-08 at 08:41, Karl DeBisschop wrote:
1) smoother PostgreSQL upgrade path (in progress)
2) better lightweight desktop/window manager solutions (e.g. xfce4)
I think the xfce is useful, but I think it would require a proof of
concept from outside of RH to get it going (ie putting it in the
non-existant Extras), and getting the people to QA it. Heck getting
people to QA Fedora.us and getting the packages put into their Extras
would be a good thing.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
11:30 a.m.
On Mon, 2003-12-08 at 12:20, Stephen Smoogen wrote:
On Mon, 2003-12-08 at 08:41, Karl DeBisschop wrote:
> 2) better lightweight desktop/window manager solutions (e.g.
xfce4)
>
I think the xfce is useful, but I think it would require a proof of
concept from outside of RH to get it going (ie putting it in the
non-existant Extras), and getting the people to QA it. Heck getting
people to QA Fedora.us and getting the packages put into their Extras
would be a good thing.
Fair enough. I just wanted to clarify that xfce4 is an example.
What I really wanted to get at was the desire for a lighter but
functional alternative to Gnome/KDE. Something between twm and
Gnome/KDE. It could be fvwm2, or whatever. I happen to like xfce, but if
people agree on the need for a lighter option, I'd like to steer the
discussion toward what might be suitable alternative, not reasons to
ignore the issue.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
11:45 a.m.
Stephen Smoogen wrote:
On Mon, 2003-12-08 at 08:41, Karl DeBisschop wrote:
>1) smoother PostgreSQL upgrade path (in progress)
>
>2) better lightweight desktop/window manager solutions (e.g. xfce4)
>
I think the xfce is useful, but I think it would require a proof of
concept from outside of RH to get it going (ie putting it in the
non-existant Extras), and getting the people to QA it. Heck getting
people to QA Fedora.us and getting the packages put into their Extras
would be a good thing.
Smooge,
I have a yum repository for xfce already up (imagine that eh?).
[xfce4rpms]
name=Fedora Compatible XFCE4 Packages
baseurl=http://www.moongroup.com/yum-repository/fedora/linux/1/i686/xfce4...
#gpgcheck=1
--
csm
Lunar Project Leader
Disclaimer: "I am not a curmudgeon! No... really..."
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
1:52 p.m.
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
3) better definition of a truly bare-bones server install
There's the Core package group already. It's *very* small.
IMO, 'Server' is more or less a meaningless description without
an adjective attached describing what you want. Web server?
CVS server? DNS server? Shell server? Database server?
4) MozillaFirebird
One problem is that you've already got:
- mozilla
- konqueror
- epiphany
and people requesting galeon2, etc.
There's definitely a level of 'Too Much Choice' when it comes
to Fedora Core. I'd suspect that to add Firebird, something
else would go. (quite possibly Mozilla classic.)
Bill
2:17 p.m.
On Mon, 2003-12-08 at 14:52, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> 3) better definition of a truly bare-bones server install
There's the Core package group already. It's *very* small.
But nobody ever finds it in the text install. For my needs, I would have
been happy if only core were an option next to minimal in the text
install that I tend to use for my servers. In other words, to me the
problem is mostly that minimal is in fact not minimal.
IMO, 'Server' is more or less a meaningless description
without
an adjective attached describing what you want. Web server?
CVS server? DNS server? Shell server? Database server?
Right. And Core + BIND would get you a pretty good start on a DNS
server. But you can't pick core out of the install - so you end up
picking minimal because it sounds, well, minimal. THen remove a boatload
of RPMS.
So for my needs, putting 'Core' into the install dialogs would be
enough. But I wrote the suggestion in a little more open format to se if
ithers had a different view of things.
> 4) MozillaFirebird
One problem is that you've already got:
- mozilla
- konqueror
- epiphany
and people requesting galeon2, etc.
There's definitely a level of 'Too Much Choice' when it comes
to Fedora Core. I'd suspect that to add Firebird, something
else would go. (quite possibly Mozilla classic.)
Can't speak for others, but I'd take that trade. It's probably not
really practical, however, because epiphany (and galeon2) both depend on
the libs from mozilla classic, so ath that point why would you not have
the browser since you already had the libs. Or could galeon and epiphany
be made to run on the Firebird libs?
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
2:51 p.m.
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
On Mon, 2003-12-08 at 14:52, Bill Nottingham wrote:
> Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> > 3) better definition of a truly bare-bones server install
>
> There's the Core package group already. It's *very* small.
But nobody ever finds it in the text install.
That's because it's only selectable via kickstart (since you
asked... ;) ) This could be changed, I suppose.
Bill
3:05 p.m.
On Mon, 2003-12-08 at 15:51, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> On Mon, 2003-12-08 at 14:52, Bill Nottingham wrote:
> > Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> > > 3) better definition of a truly bare-bones server install
> >
> > There's the Core package group already. It's *very* small.
>
> But nobody ever finds it in the text install.
That's because it's only selectable via kickstart (since you
asked... ;) ) This could be changed, I suppose.
That's all I ask ;-)
Should I bugzilla that as an RFE?
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
3:21 p.m.
On Mon, Dec 08, 2003 at 03:51:50PM -0500, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> On Mon, 2003-12-08 at 14:52, Bill Nottingham wrote:
> > Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> > > 3) better definition of a truly bare-bones server install
> >
> > There's the Core package group already. It's *very* small.
>
> But nobody ever finds it in the text install.
That's because it's only selectable via kickstart (since you
asked... ;) ) This could be changed, I suppose.
From a human factors standpoint, we'll need to change the name
when we expose it. Fedora Core Core is going to confuse people.
That said, I support exposing it.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
4:13 p.m.
On Mon, 2003-12-08 at 22:21, Michael K. Johnson wrote:
From a human factors standpoint, we'll need to change the name
when we expose it. Fedora Core Core is going to confuse people.
That said, I support exposing it.
Fedora Core Minimal doesn't sound that bad :).
On my wishlist:
- Backup tool available in menu (supporting incremental backup to
external hard drive would be great :)
- GUI for editing RPM sources, at least one of
up2date/yum/apt/open-carpet/...
- For people with more than one machine on their
home network, easy GUI setup so that RPMs are
downloaded only once, stored on one machine disk
and other just have to pick-up things on the local network
(may be with up2date option and minimal system-config-nfs ?)
- If installer sees a big disk (say >= 80GB), recommand to reserve
a partition (say ~ 8GB) so that it's easy for a not that technical user
to test FC3 betas when they're out without risking
too much of their system. The idea being that
FC3 betas are able to detect this partition, install
themselves there, add their entry to the existing
grub and don't otherwise touch other partitions. This might
increase the feedback on betas and help form a tester community
with more end users. I don't know if this is a goal,
but this might help for 2.6 kernels and various hardware,
or brand new GNOME/KDE versions, etc...
- Nightly or frequent builds of XFree86 FC RPMs for the
aventurous (okay, not specific to FC2, and might
already exist for FC1, URLs welcomed).
I know most of these things are doable with FC1, the
idea is to make this a bit more GUI-easy :).
Sincerely,
Laurent
4:43 p.m.
- For people with more than one machine on their
home network, easy GUI setup so that RPMs are
downloaded only once, stored on one machine disk
and other just have to pick-up things on the local network
(may be with up2date option and minimal system-config-nfs ?)
I wish I even remotely understood this. You want the current
repositories to ALL be downloaded and dumped into some dir?
Why not just rsync the repositories?
-sv
5:01 p.m.
On Mon, 2003-12-08 at 23:43, seth vidal wrote:
> - For people with more than one machine on their
> home network, easy GUI setup so that RPMs are
> downloaded only once, stored on one machine disk
> and other just have to pick-up things on the local network
> (may be with up2date option and minimal system-config-nfs ?)
I wish I even remotely understood this. You want the current
repositories to ALL be downloaded and dumped into some dir?
I run an update tool (let's say up2date) on machine 1,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
I run the same update tool on machine 2,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
=> Replace all "download" in the second paragraph by
look at machine 1 previously downloaded headers
and RPMs and don't download anything from the net.
Why not just rsync the repositories?
Where's the "easy GUI setup"?
Laurent
5:07 p.m.
I run an update tool (let's say up2date) on machine 1,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
I run the same update tool on machine 2,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
=> Replace all "download" in the second paragraph by
look at machine 1 previously downloaded headers
and RPMs and don't download anything from the net.
install a squid proxy cache on machine 1.
> Why not just rsync the repositories?
Where's the "easy GUI setup"?
Use gftp then and download the repositories.
there is a point where complex configurations SHOULD require the user to
learn how to do it on the command prompt.
-sv
5:35 p.m.
I already know how to do it in various ways (thanks to answers to an
earlier post and my 8 years experience in installing and using Linux),
the wishlist item is to make it easily available for people
who have a local network and are not pros, that's a situation more
and more common given that on other OSes and on network
hardware like home routers you need only to follow a basic
GUI wizard to make a local network and share stuff (may
be not OS updates though, but probably for bad reasons).
Some of the system-config-tools help setting up complex
configurations, I assume that following your reasoning
they all should be removed?
I hope that people working on FC will continue to expand
the scope of those easy to use GUI tools despite your opinion.
May be they'll consider this particular wishlist item (it might
save some bandwidth bucks too - not sure it's an issue
nowadays though :).
Sincerely,
Laurent
On Tue, 2003-12-09 at 00:07, seth vidal wrote:
> I run an update tool (let's say up2date) on machine 1,
> it figures out it needs to download a few headers,
> then downloads 50 Megabytes of RPMs, then install things.
>
> I run the same update tool on machine 2,
> it figures out it needs to download a few headers,
> then downloads 50 Megabytes of RPMs, then install things.
>
> => Replace all "download" in the second paragraph by
> look at machine 1 previously downloaded headers
> and RPMs and don't download anything from the net.
>
install a squid proxy cache on machine 1.
> > Why not just rsync the repositories?
>
> Where's the "easy GUI setup"?
Use gftp then and download the repositories.
there is a point where complex configurations SHOULD require the user to
learn how to do it on the command prompt.
-sv
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
5:37 p.m.
Some of the system-config-tools help setting up complex
configurations, I assume that following your reasoning
they all should be removed?
I hope that people working on FC will continue to expand
the scope of those easy to use GUI tools despite your opinion.
_You_, of course, could work on this since you have such interest in it.
-sv
5:55 p.m.
On Tue, 2003-12-09 at 00:37, seth vidal wrote:
_You_, of course, could work on this since you have such interest in
it.
The subject of the thread contains "wishlist"
and in the first email Michael K. Johnson wrote:
<<
[...] I'd like to hear people's wishlists. Not everything will be
possible, but it would be nice to have a good list from which to pick
the possibilities, and from which to also pick ideas later for Fedora
Core 3. [...]
>
Sorry if I misunderstood the purpose of this thread and sent OT emails.
Sincerely,
Laurent
5:55 p.m.
On Mon, 2003-12-08 at 18:55, Laurent GUERBY wrote:
On Tue, 2003-12-09 at 00:37, seth vidal wrote:
> _You_, of course, could work on this since you have such interest in it.
The subject of the thread contains "wishlist"
and in the first email Michael K. Johnson wrote:
<<
[...] I'd like to hear people's wishlists. Not everything will be
possible, but it would be nice to have a good list from which to pick
the possibilities, and from which to also pick ideas later for Fedora
Core 3. [...]
>>
Sorry if I misunderstood the purpose of this thread and sent OT emails.
No, you didn't misunderstand it. But as his been the norm on this thread
various wishlist items are being discussed as to their relative merits.
-sv
6:15 p.m.
On Tue, 2003-12-09 at 00:55, seth vidal wrote:
No, you didn't misunderstand it. But as his been the norm on this
thread
various wishlist items are being discussed as to their relative merits.
And your proposed criteria is (paraphrasing): it's "complex" and doable
using CLI and editing configuration files then it's low on the list.
I then remarked that some people (and many thanks to them) have been
developping easy to use GUI for somewhat complex tasks, they
hopefully may rate higher than you those wishes, people writing
these tools obviously don't need them for their own use
given their technical skills :).
This is a relatively new and IMHO positive attitude in the Linux
world that often meet very negative comments by some members of the
community, I just wanted to encourage further developments
in this particular area by suggesting a few wishlist items.
Sincerely,
Laurent
6:18 p.m.
I then remarked that some people (and many thanks to them) have been
developping easy to use GUI for somewhat complex tasks, they
hopefully may rate higher than you those wishes, people writing
these tools obviously don't need them for their own use
given their technical skills :).
This is a relatively new and IMHO positive attitude in the Linux
world that often meet very negative comments by some members of the
community, I just wanted to encourage further developments
in this particular area by suggesting a few wishlist items.
My point was not that it wasn't something that was doable but that the
people benefited by this development seemed to me to be a small group,
therefore not worthy of devoting developer time to it.
Hence, my suggestion that your interest in it should be propel you to
working on it.
-sv
6:05 p.m.
On Tue, Dec 09, 2003 at 12:01:42AM +0100, Laurent GUERBY wrote:
On Mon, 2003-12-08 at 23:43, seth vidal wrote:
> > - For people with more than one machine on their
> > home network, easy GUI setup so that RPMs are
> > downloaded only once, stored on one machine disk
> > and other just have to pick-up things on the local network
> > (may be with up2date option and minimal system-config-nfs ?)
>
> I wish I even remotely understood this. You want the current
> repositories to ALL be downloaded and dumped into some dir?
I run an update tool (let's say up2date) on machine 1,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
I run the same update tool on machine 2,
it figures out it needs to download a few headers,
then downloads 50 Megabytes of RPMs, then install things.
=> Replace all "download" in the second paragraph by
look at machine 1 previously downloaded headers
and RPMs and don't download anything from the net.
you need to nfs mount a shared directory.
Edit /etc/sysconfig/rhn/up2date, set keepAfterInstall to 1
and storageDir to that shared directory.
GUI won't work because primarilly you need a shared space, and
except NFS that won't work well, and setting up an NFS space is
not a simple GUI click option. But it ain't hard for a sysadmin.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:31 p.m.
On Tue, 2003-12-09 at 01:05, Daniel Veillard wrote:
you need to nfs mount a shared directory.
Edit /etc/sysconfig/rhn/up2date, set keepAfterInstall to 1
There's an option in one of the GUI for it (don't remember
where but I clicked on it). All package manager
I know of have this option off by default, looks
wrong when I look at 1$/gig for disk vs consumer monthly
price of bandwidth :).
and storageDir to that shared directory.
Don't remember seeing a GUI for setting up the directory
(/var/spool/up2date and /var/cache/yum, I use
rpm -ql package|grep var to find out where stuff
is cached...).
GUI won't work because primarilly you need a shared space, and
except NFS that won't work well, and setting up an NFS space is
not a simple GUI click option.
redhat-config-nfs? Looks nice and simple to me :). Not used yet though.
For mounting I'm so used of fstab that I didn't
look at what might exist GUI wise, any suggestion
on where to look?
Then the only missing piece is the option
in the up2date GUI to be master or slave
of storageDir (and storageDir to
be world readable for easy sharing,
nothing secret in there :).
But it ain't hard for a sysadmin.
I use scp and a little script for my home network
(could read the rsync man page one of these days :).
At work our setup is a bit more industrial for our
150 linux servers (number soon to doubled :).
Laurent
3 p.m.
On Tue, Dec 09, 2003 at 01:31:47AM +0100, Laurent GUERBY wrote:
On Tue, 2003-12-09 at 01:05, Daniel Veillard wrote:
> you need to nfs mount a shared directory.
> Edit /etc/sysconfig/rhn/up2date, set keepAfterInstall to 1
Then the only missing piece is the option
in the up2date GUI to be master or slave
of storageDir (and storageDir to
be world readable for easy sharing,
nothing secret in there :).
shared storageDir is "supported",
aka, It seems to work, but it's not something
I test.
Adrian
4:37 a.m.
On Tue, 2003-12-09 at 01:31, Laurent GUERBY wrote:
On Tue, 2003-12-09 at 01:05, Daniel Veillard wrote:
> you need to nfs mount a shared directory.
> Edit /etc/sysconfig/rhn/up2date, set keepAfterInstall to 1
There's an option in one of the GUI for it (don't remember
where but I clicked on it). All package manager
I know of have this option off by default, looks
wrong when I look at 1$/gig for disk vs consumer monthly
price of bandwidth :).
You seem to have no idea how this makes /var/spool/up2date grow over the
time... On several occasions I had this filling up my /var partition
making other stuff break. Given that (I think) the majority of people
who have to think about online costs cater only one machine from it, I'd
say the default is good. Even more so because there's a nice, shiny GUI
tool to change it ;-).
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
5:26 p.m.
On Dec 8, 2003, seth vidal <skvidal(a)phy.duke.edu> wrote:
> - For people with more than one machine on their
> home network, easy GUI setup so that RPMs are
> downloaded only once, stored on one machine disk
> and other just have to pick-up things on the local network
> (may be with up2date option and minimal system-config-nfs ?)
Why not just rsync the repositories?
Or, even simpler, set up a transparent http proxy on your home
gateway.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
6:07 p.m.
On Mon, 2003-12-08 at 14:43, seth vidal wrote:
> - For people with more than one machine on their
> home network, easy GUI setup so that RPMs are
> downloaded only once, stored on one machine disk
> and other just have to pick-up things on the local network
> (may be with up2date option and minimal system-config-nfs ?)
I wish I even remotely understood this. You want the current
repositories to ALL be downloaded and dumped into some dir?
I think he means something like 'apt-proxy' (or whatever it's called).
It's a little more intelligent about what gets stored than a simple HTTP
proxy like Squid.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
6:35 p.m.
On Tue, 2003-12-09 at 01:07, Wil Cooley wrote:
I think he means something like 'apt-proxy' (or whatever
it's called).
It's a little more intelligent about what gets stored than a simple HTTP
proxy like Squid.
It would be nice to be able to copy easily downloaded packages
on a CD or on an external disk (to share the joy with people on modems),
that's a small bonus from the shared directory approach.
Laurent
7:20 p.m.
On Mon, 2003-12-08 at 17:35, Laurent GUERBY wrote:
On Tue, 2003-12-09 at 01:07, Wil Cooley wrote:
> I think he means something like 'apt-proxy' (or whatever it's called).
> It's a little more intelligent about what gets stored than a simple HTTP
> proxy like Squid.
It would be nice to be able to copy easily downloaded packages
on a CD or on an external disk (to share the joy with people on modems),
that's a small bonus from the shared directory approach.
I know I shouldn't get involved... but I thought it *was* easy to copy
RPMs to a CD and share with others. Just tell up2date to not delete the
packages after installation and pluck them out of /var/spool/up2date.
Aw well.
2:58 p.m.
On Mon, Dec 08, 2003 at 11:13:19PM +0100, Laurent GUERBY wrote:
On Mon, 2003-12-08 at 22:21, Michael K. Johnson wrote:
> From a human factors standpoint, we'll need to change the name
> when we expose it. Fedora Core Core is going to confuse people.
> That said, I support exposing it.
Fedora Core Minimal doesn't sound that bad :).
On my wishlist:
- Backup tool available in menu (supporting incremental backup to
external hard drive would be great :)
- GUI for editing RPM sources, at least one of
up2date/yum/apt/open-carpet/...
dunno about gui, but planning on at least
adding a comandline way to do this... maybe something
vaguely like the urmpi.addmedia stuff. It's not
a high priority, but I'd like to add it.
- For people with more than one machine on their
home network, easy GUI setup so that RPMs are
downloaded only once, stored on one machine disk
and other just have to pick-up things on the local network
(may be with up2date option and minimal system-config-nfs ?)
maybe a yum/apt-mirror tool would be handy, just
for convience, even if its isn't much beyond rsync/wget
and some config.
Adrian
3:07 p.m.
On Wed, 2003-12-10 at 16:58, Adrian Likins wrote:
On Mon, Dec 08, 2003 at 11:13:19PM +0100, Laurent GUERBY wrote:
> On Mon, 2003-12-08 at 22:21, Michael K. Johnson wrote:
> > From a human factors standpoint, we'll need to change the name
> > when we expose it. Fedora Core Core is going to confuse people.
> > That said, I support exposing it.
>
> Fedora Core Minimal doesn't sound that bad :).
>
> On my wishlist:
>
> - Backup tool available in menu (supporting incremental backup to
> external hard drive would be great :)
>
> - GUI for editing RPM sources, at least one of
> up2date/yum/apt/open-carpet/...
>
dunno about gui, but planning on at least
adding a comandline way to do this... maybe something
vaguely like the urmpi.addmedia stuff. It's not
a high priority, but I'd like to add it.
Will not be possible to add the capability to read the yum.conf file
instead of duplicating the configuration files?
Yum supports and exclude directive at the repository level, up2date only
allow to configure ignored packages globally, this can be a nice feature
> - For people with more than one machine on their
> home network, easy GUI setup so that RPMs are
> downloaded only once, stored on one machine disk
> and other just have to pick-up things on the local network
> (may be with up2date option and minimal system-config-nfs ?)
>
maybe a yum/apt-mirror tool would be handy, just
for convience, even if its isn't much beyond rsync/wget
and some config.
Adrian
3:15 p.m.
Will not be possible to add the capability to read the yum.conf file
instead of duplicating the configuration files?
Yum supports and exclude directive at the repository level, up2date only
allow to configure ignored packages globally, this can be a nice feature
Let's table this for the moment.
-sv
9:27 a.m.
>
maybe a yum/apt-mirror tool would be handy, just
for convience, even if its isn't much beyond rsync/wget
and some config.
This has been asked for for yum repeatedly. There is one, It's called
yum-sync.
http://scopira.org/~ademko/yum-sync
It will sync the whole repo.
However, I think I should work on something to do the same for the new
repo format too.
Shouldn't be too hard, ultimately.
hmmm.
:)
-sv
3:31 p.m.
On Mon, Dec 08, 2003 at 04:21:03PM -0500, Michael K. Johnson wrote:
From a human factors standpoint, we'll need to change the name
when we expose it. Fedora Core Core is going to confuse people.
That said, I support exposing it.
Perhaps call it "Foundation" instead of "Core".
Best regards,
Daniel
3:37 p.m.
On Tue, 2003-12-09 at 16:31, Daniel Roesen wrote:
On Mon, Dec 08, 2003 at 04:21:03PM -0500, Michael K. Johnson wrote:
> From a human factors standpoint, we'll need to change the name
> when we expose it. Fedora Core Core is going to confuse people.
> That said, I support exposing it.
Perhaps call it "Foundation" instead of "Core".
and an alternate grouping more focused for the empathic user would be
Fedora Core Second Foundation?
:)
-sv
5:11 p.m.
On Tue, Dec 09, 2003 at 10:31:46PM +0100, Daniel Roesen wrote:
On Mon, Dec 08, 2003 at 04:21:03PM -0500, Michael K. Johnson wrote:
> From a human factors standpoint, we'll need to change the name
> when we expose it. Fedora Core Core is going to confuse people.
> That said, I support exposing it.
Perhaps call it "Foundation" instead of "Core".
Hum, Foundation has a clear legal meaning and that would be horribly
confusing IMHO.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
6:11 p.m.
On Mon, 2003-12-08 at 11:52, Bill Nottingham wrote:
There's definitely a level of 'Too Much Choice' when it
comes
to Fedora Core. I'd suspect that to add Firebird, something
else would go. (quite possibly Mozilla classic.)
Please, only if Firebird doesn't suck as much as the others on the
list! By "suck" mean a few different things:
o Konq doesn't render some things as well as Moz does, esp with
JS+DHTML.
o AFAICT, neither Galeon nor Ephipany were able to properly handle my
bookmarks, which are deeply structured and mostly in my "Personal
Toolbar Folder".
o They also didn't seem to be able to use or import my stored
passwords, which I've come to rely on pretty heavily. Importing or
migrating cookies and certificates would be nice too, but less
important.
Look and feel be damned, I need my functionality. I haven't tried
Firebird yet, so maybe I should have just kept my mouth shut.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
9:52 a.m.
Bill Nottingham wrote:
>4) MozillaFirebird
>
>
One problem is that you've already got:
- mozilla
- konqueror
- epiphany
and people requesting galeon2, etc.
There's definitely a level of 'Too Much Choice' when it comes
to Fedora Core. I'd suspect that to add Firebird, something
else would go. (quite possibly Mozilla classic.)
Agreed. Also, firebird and thunderbird haven't reached 1.0 yet. And
they are missing migration tools. And they don't even play nice
together yet (you can't click on a link in mail and have it open in the
browser.) I'm also hoping that we get to a world where they can all
share a GRE that works as well.
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------
10:13 a.m.
On Tue, 2003-12-09 at 10:52, Christopher Blizzard wrote:
Bill Nottingham wrote:
> > 4) MozillaFirebird
> >
> One problem is that you've already got:
>
> - mozilla
> - konqueror
> - epiphany
>
> and people requesting galeon2, etc.
>
> There's definitely a level of 'Too Much Choice' when it comes
> to Fedora Core. I'd suspect that to add Firebird, something
> else would go. (quite possibly Mozilla classic.)
>
Agreed. Also, firebird and thunderbird haven't reached 1.0 yet.
Neither has pam.
What's more, in this case many of the bugs are actually bugs against
Gecko. So the difference between Mozilla 1.6 and FireBird's 0.8 may well
be semantic. Or the Firebird team has a higher standard of quality.
Surely that is a good thing.
And they are missing migration tools.
True.
And they don't even play nice together yet (you can't click
on a link
in mail and have it open in the browser.)
If firebird is set up as your default browser in Gnome, clicking on the
link in Evolution works fine.
The bigger problem might be that you can't click on a mailto: link and
have it work. Firebird doesn't know about your Gnome prefernces in that
regard. I assume the same is true in KDE.
I'm also hoping that we get to a world where they can all share
a
GRE that works as well.
Not sure what you mean by GRE
I think there are a lot of good points here. OTOH, firebird is the
advertised direction that Mozilla.org is heading in, so I cite Fedora
objective #5: Be on the leading edge of open source technology, by
adopting and helping develop new features and version upgrades.
While I'm at it, #6 says: 'Emphasize usability and a "just works"
philosophy in selecting default configuration and designing features'
which could almost be a quote from the Firebird mission statement.
I'm not sure that now is the right time for Firebird, but I think a case
can be made that it is. At least as strong a case as there is for
galeon2, IMO, and for the record I'm a big fan of galeon as well, so I'm
not trying to dis it.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
10:23 a.m.
Karl DeBisschop wrote:
>Agreed. Also, firebird and thunderbird haven't reached 1.0 yet.
>
>
Neither has pam.
What's more, in this case many of the bugs are actually bugs against
Gecko. So the difference between Mozilla 1.6 and FireBird's 0.8 may well
be semantic. Or the Firebird team has a higher standard of quality.
Surely that is a good thing.
I'm not worried about the Gecko bits. That's fine, sure. I'm worried
about them breaking things before 1.0 which they have been perfectly
willing to do in the past:
http://www.mozilla.org/projects/firebird/release-notes.html
*PLEASE NOTE: You should create a new profile for Mozilla Firebird 0.7*.
To create a new profile, start Mozilla Firebird by running
MozillaFirebird.exe -p and click on the "Create Profile" button.
*You must also delete your old Mozilla Firebird directory rather than
just overwriting the files there.* Not doing so WILL result in problems
and you should not file any bugs on Mozilla Firebird unless you've first
done a clean install and tested on a new profile. As Mozilla Firebird
stabilizes more this will not be necessary but until then these steps
are absolutely necessary.
That's not acceptable to me, nor would I expect it to be for my users.
>And they don't even play nice together yet (you can't click on a link
>in mail and have it open in the browser.)
>
>
If firebird is set up as your default browser in Gnome, clicking on the
link in Evolution works fine.
The bigger problem might be that you can't click on a mailto: link and
have it work. Firebird doesn't know about your Gnome prefernces in that
regard. I assume the same is true in KDE.
It's worse than that. If you have firebird running and you click on a
link in gnome, odds are that firebird will get the open event, and it
can't handle those kinds of urls. So your browser setup is busted.
--Chris
Not sure what you mean by GRE
This means that firebird, the embedding widget (aka epiphany),
thunderbird and seamonkey (what most people call "Mozilla") all share
the same runtime. This means they all use the same disk image, etc.
Lots of savings there.
I think there are a lot of good points here. OTOH, firebird is the
advertised direction that Mozilla.org is heading in, so I cite Fedora
objective #5: Be on the leading edge of open source technology, by
adopting and helping develop new features and version upgrades.
While I'm at it, #6 says: 'Emphasize usability and a "just works"
philosophy in selecting default configuration and designing features'
which could almost be a quote from the Firebird mission statement.
Except for the fact that it doesn't always "just work." (see
above.)
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------
10:29 a.m.
On Tue, Dec 09, 2003 at 11:13:38AM -0500, Karl DeBisschop wrote:
I think there are a lot of good points here. OTOH, firebird is the
advertised direction that Mozilla.org is heading in, so I cite Fedora
objective #5: Be on the leading edge of open source technology, by
adopting and helping develop new features and version upgrades.
Right, along with the focus on upstream development, and that "advertised
direction" means that the choice should be mozilla OR Firebird/Thunderbird
not both.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
10:53 a.m.
On Tue, 2003-12-09 at 11:29, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 11:13:38AM -0500, Karl DeBisschop wrote:
> I think there are a lot of good points here. OTOH, firebird is the
> advertised direction that Mozilla.org is heading in, so I cite Fedora
> objective #5: Be on the leading edge of open source technology, by
> adopting and helping develop new features and version upgrades.
Right, along with the focus on upstream development, and that "advertised
direction" means that the choice should be mozilla OR Firebird/Thunderbird
not both.
I'm a lot more comfortable with Firebird than Thunderbird at the moment.
In those terms, I'd have to stick with classic for FC2 :-(
Of course, the reason I started using evolution at all is that a
netscape browser crash will kill the mail client as well, which is just
not acceptable. And I still found the same thing in Mozilla just last
week. So for my purposes, FireBird + Evolution is worth a lot more than
than Mozilla Classic. But I think I've said enough on the topic. Thanks
for hearing me out.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
10:18 a.m.
Christopher Blizzard wrote:
Agreed. Also, firebird and thunderbird haven't reached 1.0 yet.
And
they are missing migration tools. And they don't even play nice
together yet (you can't click on a link in mail and have it open in
the browser.)
That's supposedly fixed in the just released thunderbird 0.4, but I
agree both need a bit of polish...
I'm also hoping that we get to a world where they can all share
a
GRE that works as well.
I'm hoping for a cross-platform mozilla/xul runtime which can be easily
installed (especially on the win32 side). That would certainly help
adoption of the mozilla platform for web applications.
Klaasjan
12:13 p.m.
On 8:52:23 am 12/09/03 Christopher Blizzard <blizzard(a)redhat.com> wrote:
Bill Nottingham wrote:
>
>> 4) MozillaFirebird
>>
>>
>
> One problem is that you've already got:
>
> - mozilla
> - konqueror
> - epiphany
>
> and people requesting galeon2, etc.
>
> There's definitely a level of 'Too Much Choice' when it comes
> to Fedora Core. I'd suspect that to add Firebird, something
> else would go. (quite possibly Mozilla classic.)
>
>
Agreed. Also, firebird and thunderbird haven't reached 1.0 yet. And
they are missing migration tools. And they don't even play nice
together yet (you can't click on a link in mail and have it open in the
browser.)
The rel notes for Tbird .4 say that is fixed.
Agreed that a shared GRE would be best.
Dax Kelson
Guru Labs
3:18 p.m.
Dax Kelson wrote:
>Agreed. Also, firebird and thunderbird haven't reached 1.0
yet. And
>they are missing migration tools. And they don't even play nice
>together yet (you can't click on a link in mail and have it open in the
>browser.)
The rel notes for Tbird .4 say that is fixed.
https://bugzilla.fedora.us/show_bug.cgi?id=1113
If that is so, then please help us fix the fedora.us packages.
Warren
9:42 a.m.
Concurrent FC2 releases for x86_64 and i386. While I *think* we have been
planning for it, I will explicitly state it as a request, and I do intend
to work on that request myself, but I ask others working on code or
packaging to FC2 to please consider the other archs out there. IE if it is
a lib, but has outside components, please try to make it so that concurrent
32-bit/64-bit install doesnt step on each other. If you are patching
something that works on x86_64, please include x86_64 in your arch specific
changes, or let us know so that we can take a look at it if you do not have
hardware available, and we can ensure that it continues to work on
x86_64.
Thanks,
Justin M. Forbes
2:43 a.m.
Hi,
bi-arch system for x86_64 would be nice.
One should be able to compile 32 bit libs and
applications on x86_64. E.g. I would like to use
rpmbuild --target=i386 to produce 32-bit compiled
rpm packages on x84_64. rpmbuild should give the
proper --libdir= etc. options to the software's
configure script in such a way that the produced
libraries can be installed on both ia32 and x86_64
Fedoras.
The rpm packages should be more refined
so i386 and x86_64 does not conflict. E.g.
the documentation files under /usr/share/doc/<package>
and other common files should be in a <package>-common rpm,
the development header files in a <package>-devel-common, etc.
These rpms can be noarch.rpm since they only contain
textfiles.
Bill Nottingham írta:
Justin M. Forbes (64bit_fedora(a)comcast.net) said:
>Concurrent FC2 releases for x86_64 and i386.
If everything is working, that would certainly be a goal.
Bill
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Best regards,
Zoltán Böszörményi
---------------------
What did Hussein say about his knife?
One in Bush worth two in the hand.
8:28 a.m.
On Tue, Dec 09, 2003 at 09:43:25AM +0100, Boszormenyi Zoltan wrote:
bi-arch system for x86_64 would be nice.
One should be able to compile 32 bit libs and
applications on x86_64. E.g. I would like to use
rpmbuild --target=i386 to produce 32-bit compiled
rpm packages on x84_64. rpmbuild should give the
proper --libdir= etc. options to the software's
configure script in such a way that the produced
libraries can be installed on both ia32 and x86_64
Fedoras.
We can look at adding this, as I think it would be beneficial all the way
around, I will do some research on the logistics of this, and see if the
package maintainers will buy in.
The rpm packages should be more refined
so i386 and x86_64 does not conflict. E.g.
the documentation files under /usr/share/doc/<package>
and other common files should be in a <package>-common rpm,
the development header files in a <package>-devel-common, etc.
These rpms can be noarch.rpm since they only contain
textfiles.
This is a lot of change to packaging, right now our goal is more to ensure
the files do not confilct, so that if you have both arches installed, they
just overwrite each other, and sizes remain the same. That way you can
verify your installs, and the only thing that might differ would be
timestamp. In the future though I do not think that this is a bad idea.
Once again it comes down to package maintainers, and getting their buy in.
Justin M. Forbes
9:43 a.m.
On Mon, 2003-12-08 at 11:15, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
FWIW, one thing that we're not likely to do is just push the schedule
out by a week for project foo, another week for project bar, etc. ad
nauseum.
Make default applications configurable, for example instead of Mozilla
Web Browser, call it Web Browser and allows the user to change it
without messing around with the .desktop files
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
9:57 a.m.
On Mon, 2003-12-08 at 10:43, Robert Marcano wrote:
> However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
> hear people's wishlists...
Make default applications configurable, for example instead of Mozilla
Web Browser, call it Web Browser and allows the user to change it
without messing around with the .desktop files
We have a system mechanism for this in the alternatives system. Any
chance of extending that to provide a uniform user-level way of
specifying alternatives? Maybe a GUI would be in order to move the
concept out to userland, but this seems like something that is best done
by the OS, rather than reimplemented N-times over for each windowmanager
and/or desktop. (This is really sort of an RFE, I'd gladly bugzilla it
and work on some coding id there a sense that people think it is a
reasonable approach)
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
1:57 p.m.
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
On Mon, 2003-12-08 at 10:43, Robert Marcano wrote:
> > However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> > hear people's wishlists...
>
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
We have a system mechanism for this in the alternatives system. Any
chance of extending that to provide a uniform user-level way of
specifying alternatives?
I'd prefer not; the alternatives hack is something that should be
severely limited in where it's used.
Bill
9:23 a.m.
On Mon, 2003-12-08 at 14:57, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> On Mon, 2003-12-08 at 10:43, Robert Marcano wrote:
>
> > > However, that won't be the ONLY feature of Fedora Core 2. I'd
like to
> > > hear people's wishlists...
> >
> > Make default applications configurable, for example instead of Mozilla
> > Web Browser, call it Web Browser and allows the user to change it
> > without messing around with the .desktop files
>
> We have a system mechanism for this in the alternatives system. Any
> chance of extending that to provide a uniform user-level way of
> specifying alternatives?
I'd prefer not; the alternatives hack is something that should be
severely limited in where it's used.
Are there alternatives to alternatives?
While I agree that it has some real shortcomings, there are also
shortcomings to having the user-land equivalents be totally divorced
from alternatives. There are also shortcomings to having the KDE and
Gnome equivalents be divorced from each other and having to set default
browsers in both.
And icing on the cake, the PostgreSQL smooth-upgrade effort will
probably end up reimplementing the functionality of alternatives because
alternatives itself is too limited for the task at present.
So yes, it may be a hack. But isn't one hack better than 4?
Or is there another option?
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
12:46 p.m.
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
Are there alternatives to alternatives?
While I agree that it has some real shortcomings, there are also
shortcomings to having the user-land equivalents be totally divorced
from alternatives. There are also shortcomings to having the KDE and
Gnome equivalents be divorced from each other and having to set default
browsers in both.
That should be handled by better desktop interoperation, not wrapping
everything in a forest of symlinks, IMO; take, for example, a unified
MIME system.
Bill
1:16 p.m.
On Tue, 2003-12-09 at 13:46, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> Are there alternatives to alternatives?
>
> While I agree that it has some real shortcomings, there are also
> shortcomings to having the user-land equivalents be totally divorced
> from alternatives. There are also shortcomings to having the KDE and
> Gnome equivalents be divorced from each other and having to set default
> browsers in both.
That should be handled by better desktop interoperation, not wrapping
everything in a forest of symlinks, IMO; take, for example, a unified
MIME system.
That sort of assumes you are starting with a document of some sort,
right?
It does not extend to setting a system default MTA, for instance, that a
user can choose to override. Or a system wide print system. Although I
suppose there could be extensions...but MTAs and printers handle many
mime types, most of which are also handled by some desktop viewer. So
it's both mime type and context that determines the app that gets
invoked.
Nor does it let me choose a default RDBMS for users to access, whether
it mysql or PostgreSQL, or running a single server with multiple
versions of PostgreSQL installed. There no document attached to that at
all -- just the invocation of the pgsql or mysql shell.
It's becoming clear to me that the lens I see this through is different
than yours. But with respect, I don't see how what you propose is a
complete replacement for alternatives for the set of issues I raised.
Oh well, if there's that much discussion around the point, ita good
guess that not much will change for FC2. So we will look forward to one
implementation for KDE, another for Gnome, another for the system admin,
and another to facilitate PostgreSQL upgrades (assuming that even gets
built in time). That's life I guess, It's no worse than things are now.
Again, thanks for your thought on the matter. Even if we don't come to
the same conclusion, it seemed worth bringing up.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
1:45 p.m.
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
It does not extend to setting a system default MTA, for instance,
that a
user can choose to override. Or a system wide print system. Although I
suppose there could be extensions...but MTAs and printers handle many
mime types, most of which are also handled by some desktop viewer. So
it's both mime type and context that determines the app that gets
invoked.
Well, I'm coming from a different perspective. Basically....
Supporting two printing systems in the core OS is dumb. It's a waste
of development effort all around, and it was probably a mistake when
we did it. The way to a stable, mature, robust OS is to support one
solution that does it *right* in the general case. It's why I'm leery
of the sendmail/exim/postfix or wu-ftpd/vsftpd/pure-ftpd/proftpd
situation, and I think using alternatives for three flavors of vi is
extremely crazy.
Basically, in my opinion, spending a lot of time implementing an
infrastructure to support choosing between 6 web browsers is better
spent *fixing* one of the web browsers to support all of the
features you need.
Nor does it let me choose a default RDBMS for users to access,
whether
it mysql or PostgreSQL,
It's not logical for this; they don't have the same interface in a way
that would be handled by alternatives.
or running a single server with multiple versions of PostgreSQL
installed.
This sounds more like a parallel install situation:
http://ometer.com/parallel.html
Bill
2:05 p.m.
On Tue, 2003-12-09 at 14:45, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> It does not extend to setting a system default MTA, for instance, that a
> user can choose to override. Or a system wide print system. Although I
> suppose there could be extensions...but MTAs and printers handle many
> mime types, most of which are also handled by some desktop viewer. So
> it's both mime type and context that determines the app that gets
> invoked.
Well, I'm coming from a different perspective. Basically....
Supporting two printing systems in the core OS is dumb...
Long term, yes. Maybe in the short term, facilitating the transition is
part of what open source OSs have to do. I don't really know...
> or running a single server with multiple versions of PostgreSQL
> installed.
This sounds more like a parallel install situation:
http://ometer.com/parallel.html
It is, and that part is well thought out by the PostgreSQL packagers.
And in principle is not really different than what is in the link above.
(Actually, the whole think is well thought out on their part - I don't
mean to be cutting anyone's work down).
What the link above ignores is some way to manage the parallel install,
both from the sysadmin's point of view, and from the user's point of
view. And it's my contention, that it is all about choosing apps,
whether by mime type, or by user preference, or by sysadmin fiat. So at
that level, it seems like the same problem to me.
What irks me is that they are going to some effort to essentially
reimplement alternatives because the need to do what alternaives does
both in system settings and in per-user settings. (Actually, it is a
little more complex than that).
Now if the viewpoint is that alternatives will not be there, then I
guess that's fine. It's what you have to do. But if it is already there,
then doing it a different way all over again seems a waste. But I guess
that's the way it'll be.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
2:06 p.m.
Am Dienstag, 9. Dezember 2003 20:45 schrieb Bill Nottingham:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> It does not extend to setting a system default MTA, for instance, that a
> user can choose to override. Or a system wide print system. Although I
> suppose there could be extensions...but MTAs and printers handle many
> mime types, most of which are also handled by some desktop viewer. So
> it's both mime type and context that determines the app that gets
> invoked.
Well, I'm coming from a different perspective. Basically....
Supporting two printing systems in the core OS is dumb. It's a waste
of development effort all around, and it was probably a mistake when
we did it. The way to a stable, mature, robust OS is to support one
solution that does it *right* in the general case. It's why I'm leery
Most
often people don't agree on "right" and/or "general case".
of the sendmail/exim/postfix or wu-ftpd/vsftpd/pure-ftpd/proftpd
situation, and I think using alternatives for three flavors of vi is
extremely crazy.
Basically, in my opinion, spending a lot of time implementing an
infrastructure to support choosing between 6 web browsers is better
spent *fixing* one of the web browsers to support all of the
features you need.
I agree with you completly on this point.
This would also mean replacing vsftpd with pure-ftpd. (I think enough points
were made in the prevous discussion on this topic.)
For the MTA the answer is not so simple, it depends on how much (sendmail/old
unix [aka /var/spool/mail]) compatibility is needed/wanted.
--
http://LinuxWiki.org/RonnyBuchmann
2:57 p.m.
Le mar 09/12/2003 à 21:06, Ronny Buchmann a écrit :
This would also mean replacing vsftpd with pure-ftpd. (I think enough
points
were made in the prevous discussion on this topic.)
For the MTA the answer is not so simple, it depends on how much (sendmail/old
unix [aka /var/spool/mail]) compatibility is needed/wanted.
Postfix is there from 7.3 (and was in powertools before I think).
People who wanted a sane MTA jumped ship a long time ago. Others wont
unless sendmail is moved in extras.
So if one wants to get rid of sendmail you only need to pull its plug
now. The grace period is long over.
--
Nicolas Mailhot
2:20 p.m.
On Tue, 2003-12-09 at 15:45, Bill Nottingham wrote:
Karl DeBisschop (kdebisschop(a)alert.infoplease.com) said:
> It does not extend to setting a system default MTA, for instance, that a
> user can choose to override. Or a system wide print system. Although I
> suppose there could be extensions...but MTAs and printers handle many
> mime types, most of which are also handled by some desktop viewer. So
> it's both mime type and context that determines the app that gets
> invoked.
Well, I'm coming from a different perspective. Basically....
Supporting two printing systems in the core OS is dumb. It's a waste
of development effort all around, and it was probably a mistake when
we did it. The way to a stable, mature, robust OS is to support one
solution that does it *right* in the general case. It's why I'm leery
of the sendmail/exim/postfix or wu-ftpd/vsftpd/pure-ftpd/proftpd
situation, and I think using alternatives for three flavors of vi is
extremely crazy.
I don´t think it was a mistake, i believe that it was the best solution
to allow people to migrate gradually to cups
Basically, in my opinion, spending a lot of time implementing an
infrastructure to support choosing between 6 web browsers is better
spent *fixing* one of the web browsers to support all of the
features you need.
> Nor does it let me choose a default RDBMS for users to access, whether
> it mysql or PostgreSQL,
It's not logical for this; they don't have the same interface in a way
that would be handled by alternatives.
> or running a single server with multiple versions of PostgreSQL
> installed.
This sounds more like a parallel install situation:
http://ometer.com/parallel.html
Bill
--
Robert Marcano
4:35 p.m.
While I agree that it has some real shortcomings, there are also
shortcomings to having the user-land equivalents be totally divorced
from alternatives. There are also shortcomings to having the KDE and
Gnome equivalents be divorced from each other and having to set default
browsers in both.
In the Gnome case its even worse because the panel doesn't have a good
way to put "default web browser" on it. So you get one browser for
dingus-click and one for panel. Endless pain and suffering
10:44 a.m.
On Mon, 8 Dec 2003, Karl DeBisschop wrote:
On Mon, 2003-12-08 at 10:43, Robert Marcano wrote:
> > However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> > hear people's wishlists...
>
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
We have a system mechanism for this in the alternatives system. Any
chance of extending that to provide a uniform user-level way of
specifying alternatives?
Debian already does this -- even which Vi gets run when you type vi is
controlled by alternatives. It's extremely messy, IMHO, and has the drawback
that it doesn't offer any per-user configuration, so it doesn't really do
what you want. I think fedora should avoid alternatives as much as
possible....
Maybe what's needed is extension of existing config GUIs so they edit all
configs and not just their own (for example, selecting default editor in
Gnome changes Gnome's editor, but also sets VISUAL and EDITOR variables,
changes KDE's editor, etc.). That's more likely than unified
configuration....
later,
chris
11:10 a.m.
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
Make default applications configurable, for example instead of
Mozilla
Web Browser, call it Web Browser and allows the user to change it
without messing around with the .desktop files
GNOME supposedly allows you to do this. I haven't succeeded in getting
it to work, but then, I haven't tried very hard:
"Start" menu (well, mine still has a Red Hat) -> Preferences ->
Preferred Applications -> Web Browser
mark
--
mark@mielke.cc/markm@ncf.ca/markm(a)nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
11:25 a.m.
On Mon, 2003-12-08 at 13:10, Mark Mielke wrote:
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
GNOME supposedly allows you to do this. I haven't succeeded in getting
it to work, but then, I haven't tried very hard:
"Start" menu (well, mine still has a Red Hat) -> Preferences ->
Preferred Applications -> Web Browser
Yes i know, preferred applications works when another app requires to
open the browser, but not when the user starts the application from the
gnome panel main menu or kde menu applications menu
mark
1:25 p.m.
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
Make default applications configurable, for example instead of
Mozilla
Web Browser, call it Web Browser and allows the user to change it
without messing around with the .desktop files
Certainly make epiphany the default web browser for gnome desktops so the
UI is consistent.
I think my big ones are:
- Fix the translations process to avoid the FC1 menu fiasco
- Fix or drop apps that just dont work in FC1. If they dont
work and nobody fixed them then there isnt any point
continuing to ship them (eg the terminal server client)
- Gnome 2.6 (deadline depending)
- Opengroupware IFF there is a calendaring solution for
evolution and it by then
- Get the extras framework sorted and consign lots of the
old 'small userbase pet program' stuff to it (eg joe)
- Font coverage for missing fonts where possible
- Make metacity actually work properly if we are going to
ship it.
and most critical of all by then to me is a working arrangement for user
created content and discussion on a web site.
7:46 p.m.
Hmm. My other machine is grumpy and doesn't want to send mail at the
moment. My apologies if this comes through more than once.
On Mon, 2003-12-08 at 19:25, Alan Cox wrote:
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
There was a story on OSNews today (doh, yesterday now - must go to
bed)related to this, about MIME systems in GNOME. See
http://www.gnome.org/~jrb/files/mime/ and
http://www.osnews.com/comment.php?news_id=5343
Having the GNOME menu (rather than an "open..." part of a context menu)
reflect these settings in some way would be interesting. You couldperhaps
have a menu item that expanded into "default web browser" and"other web
browsers". You could remove/disable this item if you didn'tlike it. If it
was installed/enabled then it could perhaps optionallyhide any other menu
items for the applications it "provided".
So without it I have:
.../Network/Mozilla
Konqueror
Links
FTP
...
With it (and the hiding option off) I have:
.../Network/Web browser
Other web browsers/Konqueror
Links
Konqueror
Links
FTP
With it (and the hiding option on) I have:
.../Network/Web browser
Other web browsers/Konqueror
Links
FTP
Of course the "other" and "hiding" parts would only work
forapplications
that had been associated with "web browsing" - but that'sjust a case of
packaging things right. The bigger problem is that thearticle above is
about MIME types - not application types ("webbrowsers", "ftp
clients",
"MUAs" etc). It's too late for me to work outwhether one can draw a
connection or whether the tie-in doesn't makesense. :) Also, I've no idea
how the GNOME menu is implemented so thismay be impractical. Perhaps the
RedHat author of the proposal above is reading and can comment.
[back on topic...]
Certainly make epiphany the default web browser for gnome desktops so
the UI is consistent.
I would probably be in favour of this as default - despite normallybeing a
Mozilla user myself.
- Fix or drop apps that just dont work in FC1. If they
dont
work and nobody fixed them then there isnt any point
continuing to ship them (eg the terminal server client)
Great - smaller CDs, less wasted time for RedHat employees so they canfix
the things we do care about. Also even less of a big deal if...
- Get the extras framework sorted and consign lots of
the
old 'small userbase pet program' stuff to it (eg joe)
... this happens - which is my #1 priority wish. I feel there is
someconfusion over it, plus I'm getting bored of pointing people at
theright repositories when it could all be there from the start. Plus,
thesooner it's sorted the sooner I'm going to spend my time scratching
myown package itches and also helping out on others.
- Font coverage for missing fonts where possible
Would certainly be good.
My #2 priority wish is a 2.6 kernel. I would much rather than this
thanGNOME 2.6. I also think it would make more sense. Release FC2 with a
2.6kernel ASAP. Do not ship it with a 2.4 kernel. Keep FC1 updated
longerthan you would normally for Fedora after a new release (though this
maynot be as longer overall if the new release is early). That way
peoplewho need/want to can hold back and not upgrade so soon. FC3 then
gets aby then stable GNOME 2.6, and a more fully tested 2.6 kernel.
Ifpossible, release FC3 as soon as (or just before) RedHat's support
forFC1 goes away. This is kind of stretching (OK, it's breaking)
RedHat'srelease plans for Fedora - but I believe it would be worth it in
thiscase. One downside is that it gives the wrong impression by
indicatingit's not really a policy and leaves you open to being asked to
do thesame again in future. On the other hand, this time of flux is
probablythe best time to bend rules. :)
My smaller wishes have already been mentioned further down the thread,or
(even better) appearing in RawHide/testing updates for FC1.
Cheers
--
Stuart
1:23 a.m.
El Lunes, 8 diciembre, 2003, a las 01:25 PM, Alan Cox escribió:
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
Certainly make epiphany the default web browser for gnome desktops so
the
UI is consistent.
I think my big ones are:
- Fix the translations process to avoid the FC1 menu fiasco
....
I have seen the spanish translation of comps and have some fatals
errors; but, this list will care about this, or is another list
specific to translations?
Regards,
4 a.m.
On Tue, 2003-12-09 at 18:23, Daniel Guerrero wrote:
I have seen the spanish translation of comps and have some fatals
errors; but, this list will care about this, or is another list
specific to translations?
Some new mailing lists were created less than 24 hours ago to deal
with specific translations. There used to be only one email list for
translations (i18n-list(a)redhat.com), but now there are at least 9 new
language-specific lists.
The translation list you're probably interested in (Spanish) can be
found here:
http://www.redhat.com/mailman/listinfo/fedora-trans-es
The i18n list is also being "decimated" and is being moved to:
http://www.redhat.com/mailman/listinfo/fedora-trans-list
As quoted from an email originally sent to me: "This list will be the
main place to discuss all fedora translation related issues, including
software and documentation. This list will also be used to post any
queries, instructions, tips, and updates."
Cheers,
Daniel
--
Daniel Hedlund
daniel(a)digitree.org
CEO & Chief Consultant
DigiTree Studios Pty Ltd.
2:49 a.m.
On Mon, 2003-12-08 at 19:25, Alan Cox wrote:
On Mon, Dec 08, 2003 at 11:43:48AM -0400, Robert Marcano wrote:
> Make default applications configurable, for example instead of Mozilla
> Web Browser, call it Web Browser and allows the user to change it
> without messing around with the .desktop files
Certainly make epiphany the default web browser for gnome desktops so the
UI is consistent.
Please don't do that until this showstopper bug is fixed:
http://bugzilla.gnome.org/show_bug.cgi?id=105153
It seems to be a mozilla-related bug affecting epiphany... yet it makes
epiphany very frustrating to use as it doesn't put focus on the URL bar
when new tabs are opened.
--
Julien Olivier <julo(a)altern.org>
5:45 p.m.
Please don't do that until this showstopper bug is fixed:
http://bugzilla.gnome.org/show_bug.cgi?id=105153
It seems to be a mozilla-related bug affecting epiphany... yet it makes
epiphany very frustrating to use as it doesn't put focus on the URL bar
when new tabs are opened.
I have this problem with mozilla sometimes too. Switching window manager
fixes it bizarrely enough
9:39 p.m.
New subject: Default Applications (was: Fedora Core 2 wishlists)
On Mon, 2003-12-08 at 08:43, Robert Marcano wrote:
Make default applications configurable, for example instead of
Mozilla
Web Browser, call it Web Browser and allows the user to change it
without messing around with the .desktop files
At least with the web browser, this already exists.
$ head -n 16 /usr/bin/htmlview
#!/bin/bash
#
# Invoke whatever HTML viewer is installed...
# Usage:
# htmlview [URL]
#
# Changes:
# v2.0.0
# ------
# - Allow users to override default settings in
# ~/.htmlviewrc and /etc/htmlview.conf.
# Users can define X11BROWSER, TEXTBROWSER and
# CONSOLE variables to indicate their preferences.
# - --remote and --local are deprecated, we don't
# have any non-browser HTML viewers these days.
#
There is a GUI configuration tool for it -- gnome-default-applications-properties
The tool can be launched from "Preferred Applications" in the Preferences menu.
Dax Kelson
Guru Labs
9:44 a.m.
On Mon, 2003-12-08 at 08:15, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
cyrus-imapd
I have to take Simon Mater's RPMS at the moment, remove items that we
dont need, alter some other items, and then recompile it. While this
would be going on anyway, I much prefer having one that has a lot more
eyes looking at it.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
11:11 a.m.
On Mon, Dec 08, 2003 at 08:44:54AM -0700, Stephen Smoogen wrote:
On Mon, 2003-12-08 at 08:15, Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.
cyrus-imapd
I have to take Simon Mater's RPMS at the moment, remove items that we
dont need, alter some other items, and then recompile it. While this
would be going on anyway, I much prefer having one that has a lot more
eyes looking at it.
Looks like this is in fedora-devel right now. How do you find it compares
to dovecot?
mark
--
mark@mielke.cc/markm@ncf.ca/markm(a)nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
11:41 a.m.
On Mon, 2003-12-08 at 09:11, Mark Mielke wrote:
Looks like this is in fedora-devel right now. How do you find it
compares
to dovecot?
Cyrus IMAP is designed with large sites in mind; there are organizations
using Cyrus to serve tens of thousands of mailboxes. It's also very
feature-complete as far as IMAP servers go.
2.2 is reported stable in beta now and would probably be the best
choice.
Dovecot appears to be a good choice when you've already got a large
installation with mbox or Maildir folder and don't want to try to
migrate.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
6:10 p.m.
On 2003-12-08 at 08:44:54-0700 Stephen Smoogen <smoogen(a)lanl.gov> wrote:
cyrus-imapd
I have to take Simon Mater's RPMS at the moment, remove items that
we dont need, alter some other items, and then recompile it. While
this would be going on anyway, I much prefer having one that has a
lot more eyes looking at it.
But does it really make sense for Fedora to contain cyrus-imapd RPMs
if it is expected that most sites who are using it seriously will have
to recompile from SRPM anyway?
Would a better solution not be to see if Simon would be willing to
maintain his cyrus-imapd RPMs in fedora-extras?
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
9:47 a.m.
Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2. I'd
like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
* Well tested inplace upgrade from FC1 -> FC2. I really would like to
be able to just edit my yum.conf file, and do a you update, wait a
little while, reboot, and done.
* KDE 3.2
10:16 a.m.
On Monday 08 December 2003 10:47 am, Matthew T. O'Connor wrote:
* Well tested inplace upgrade from FC1 -> FC2. I really would
like to
be able to just edit my yum.conf file, and do a you update, wait a
little while, reboot, and done.
+1
* KDE 3.2
+1. Particularly interesting for me is KStars with
the INDI telescope
control... :-)
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
11:39 a.m.
* Well tested inplace upgrade from FC1 -> FC2. I really would
like to
be able to just edit my yum.conf file, and do a you update, wait a
little while, reboot, and done.
I would like to see two things:
* An easy upgrade as described above
* An easy clean install without burning to CDs
Boot from USB drive + all ISOs sitting on a local fileserver
Ian
2 p.m.
Ian Wells (ian(a)yoshian.freeserve.co.uk) said:
> * Well tested inplace upgrade from FC1 -> FC2. I really
would like to
> be able to just edit my yum.conf file, and do a you update, wait a
> little while, reboot, and done.
I would like to see two things:
* An easy upgrade as described above
* An easy clean install without burning to CDs
Boot from USB drive + all ISOs sitting on a local fileserver
In what way do existing mechanisms not work for this?
Bill
2:26 p.m.
Bill Nottingham wrote:
Ian Wells (ian(a)yoshian.freeserve.co.uk) said:
> > * Well tested inplace upgrade from FC1 -> FC2. I really would like to
> > be able to just edit my yum.conf file, and do a you update, wait a
> > little while, reboot, and done.
>
>I would like to see two things:
>
>* An easy upgrade as described above
>
>* An easy clean install without burning to CDs
> Boot from USB drive + all ISOs sitting on a local fileserver
>
>
In what way do existing mechanisms not work for this?
I can't say specifically. I just know that I heard of lots of users
having trouble using yum or up2date to upgrade their box from one older
versions of RH to FC1. All I was saying with my original post, is that
I see easy continuous upgrades between Fedora releases as a priority. I
want to be confident that I can upgrade from FC1 -> FC2 without causing
major problems, and minimal downtime.
Is there an upgrade support policy? Something like, every FC release is
supposed to cleanly upgrade from the previous release. Upgrading from
anything older than the previous release is not supported.
3:18 p.m.
On Mon, Dec 08, 2003 at 03:26:12PM -0500, Matthew T. O'Connor wrote:
Is there an upgrade support policy? Something like, every FC release
is
supposed to cleanly upgrade from the previous release. Upgrading from
anything older than the previous release is not supported.
Well, test releases may theoretically hose your system, and the
installer won't have hacks to work around test release brokenness.
That aside, the *installer* should be able to upgrade your system
over multiple releases. There is a lot of "do the right thing"
magic in the installer, and you will minimally get *different*
results upgrading with yum.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
3:35 p.m.
That aside, the *installer* should be able to upgrade your system
over multiple releases. There is a lot of "do the right thing"
magic in the installer, and you will minimally get *different*
results upgrading with yum.
I'd like to see the 'do the right thing' magic reduced and the ability
for shared depresolution mechanism b/t s-c-p, yum and anaconda so the
whitelists and blacklists in anaconda can be taken advantage of by the
other updating tools.
-sv
4:19 p.m.
I would really like to see some type of video playback.
Since most media is to be handled by the gstreamer libraries, It would
seem logical to add a video app that uses these libraries as rythmbox
does for audio?
Some that come to mind are:
gst-player
totem
BTW I add a vote for the inclusion of Firebird (very stable)!
Earle Nietzel
7:06 a.m.
On Mon, Dec 08, 2003 at 04:35:38PM -0500, seth vidal wrote:
> That aside, the *installer* should be able to upgrade your
system
> over multiple releases. There is a lot of "do the right thing"
> magic in the installer, and you will minimally get *different*
> results upgrading with yum.
I'd like to see the 'do the right thing' magic reduced and the ability
for shared depresolution mechanism b/t s-c-p, yum and anaconda so the
whitelists and blacklists in anaconda can be taken advantage of by the
other updating tools.
Well, this isn't just white/blacklists. I'll let the installer folks
discuss this in more detail because I don't know all the functionality
involved.
But yes, I think that sharing the white/blacklists somehow would be
useful. But I don't have any suggestions for how to do it.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:52 p.m.
From: "Bill Nottingham" <notting(a)redhat.com>
> * An easy clean install without burning to CDs
> Boot from USB drive + all ISOs sitting on a local fileserver
In what way do existing mechanisms not work for this?
In October there was a discussion on this issue:
Suggestions for the Installer (regarding network installs)
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00576.html
It talks about "USB boot images" and booting from USB to start a network
install.
Maybe Jeremy Katz or someone can shed some light on any progress made
Ian
3:14 p.m.
Ian Wells (ian(a)yoshian.freeserve.co.uk) said:
In October there was a discussion on this issue:
Suggestions for the Installer (regarding network installs)
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00576.html
It talks about "USB boot images" and booting from USB to start a network
install.
Well, I've seen a boot key, so it's certainly possible in that manner.
It's just a matter of having a bunch of images all there for booting
a different way (floppy, CD, <other>)
Bill
4:47 p.m.
Bill Nottingham wrote:
Ian Wells (ian(a)yoshian.freeserve.co.uk) said:
>In October there was a discussion on this issue:
>
>Suggestions for the Installer (regarding network installs)
>http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00576.html
>
>It talks about "USB boot images" and booting from USB to start a network
>install.
Well, I've seen a boot key, so it's certainly possible in that manner.
It's just a matter of having a bunch of images all there for booting
a different way (floppy, CD, <other>)
Making a usb stick drive work is really as simple as the link
suggests. Assuming the usb device is already formated as fat, and our
cdrom is in the drive. All you need to do is this:
mount /mnt/cdrom
mount /dev/(usb device) /mnt/usb
cp /mnt/cdrom/isolinux/* /mnt/usb
rm /mnt/usb/isolinux.bin
mv /mnt/usb/isolinux.cfg /mnt/usb/syslinux.sys
umount /mnt/cdrom /mnt/usb
syslinux -s /dev/(usb device)
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <sflory(a)rackable.com>
10:27 a.m.
On Monday 08 December 2003 07:15, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like
to hear people's wishlists. Not everything will be possible, but it
would be nice to have a good list from which to pick the
possibilities, and from which to also pick ideas later for Fedora
Core 3.
I would like to see mondo rescue included (http://www.mondorescue.org)
as well as it's tool chain (mindi, afio, buffer, lzo, lzop). I already
maintain RPMS for all of these as the main packager for the Mondo
Rescue project. I'd be willing to sponsor them in Fedora, and be the
bugzilla interface as well.
We're coming up on a full release shortly, which will include xmondo, a
QT based graphical frontend to running mondo, as well as DVD+RW/-RW
support. It's this release (or later) that I'd like to get included
with FC2.
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
2:02 p.m.
Jesse Keating (jkeating(a)j2solutions.net) said:
Content-Description: signed data
On Monday 08 December 2003 07:15, Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like
> to hear people's wishlists. Not everything will be possible, but it
> would be nice to have a good list from which to pick the
> possibilities, and from which to also pick ideas later for Fedora
> Core 3.
I would like to see mondo rescue included (http://www.mondorescue.org)
as well as it's tool chain (mindi, afio, buffer, lzo, lzop). I already
maintain RPMS for all of these as the main packager for the Mondo
Rescue project. I'd be willing to sponsor them in Fedora, and be the
bugzilla interface as well.
The last time I looked at mondo, the packages consisted of already-built
binaries of various sort; it didn't self-host on the system. This
turned me off of it; has this changed?
Bill
2 p.m.
On Monday 08 December 2003 12:02, Bill Nottingham wrote:
The last time I looked at mondo, the packages consisted of
already-built binaries of various sort; it didn't self-host on the
system. This turned me off of it; has this changed?
We're working to resolve that. Almost all of it is self hosting now,
mindi has been ported to perl to facilitate most of this, and mondo is
almost all C now. (with the exception of xmondo which is c++ I think).
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
8:52 p.m.
On Mon, 8 Dec 2003, Jesse Keating wrote:
I would like to see mondo rescue included
(http://www.mondorescue.org)
as well as it's tool chain (mindi, afio, buffer, lzo, lzop). I already
maintain RPMS for all of these as the main packager for the Mondo
Rescue project. I'd be willing to sponsor them in Fedora, and be the
bugzilla interface as well.
2nd that.
Very usefull tool.
We're coming up on a full release shortly, which will include xmondo, a
QT based graphical frontend to running mondo, as well as DVD+RW/-RW
support. It's this release (or later) that I'd like to get included
with FC2.
Sounds like I need to check it out again.
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: raven(a)themaw.net
v Web: http://themaw.net/
10:53 a.m.
On Mon, 08 Dec 2003 10:15:30 -0500
"Michael K. Johnson" <johnsonm(a)redhat.com> wrote:
--- SNIP ---
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
FWIW, one thing that we're not likely to do is just push the schedule
out by a week for project foo, another week for project bar, etc. ad
nauseum.
michaelkjohnson
My wish lists are mostly adding to what is already here.
1.)
The OSSNET - Proposal for Swarming Data Propagation by Warren Togami.
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg01083.html
Or anything in the direction of cleaning up repositories for speed and
causing less confusion. There should really only be two repository's the one
for supported and one for everything else. Right now I have redhat's core,
fedora.us, DaG, XFCE, and one for java. Legal issues can not be helped but
some documentation or guidence in this area would be great. Consistency is
defiantly needed in this area so I'm posting another set of ideas:
The Repository feature proposal posted by Peter Backlund
http://www.redhat.com/archives/fedora-devel-list/2003-October/msg00797.html
2.)
I'm not sure how this would work, but a better solution than fedora-rmdevelrpms.
As it is now developers have to remove all devel RPM's to be assured they are
making an accurate spec file. Most of these are just users wanting to put
their favorite app in a repo and won't delete half the system to do it.
3.)
Documentation, Documentation, Documentation. Which as I understand is in the works.
11:31 a.m.
On Mon, 2003-12-08 at 15:15, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
1) IPSEC kernel support. I am assuming we will get this as part of the
move to 2.6.
2) IPSEC user space daemons and tools.
3) system-config-ipsec to provide a simple GUI for configuring common
IPSEC scenarios.
4) Documentation updates to cover IPSEC and the common tasks relating to
IPSEC.
Thanks,
Keith.
11:34 a.m.
On Mon, 2003-12-08 at 09:31, Keith Sharp wrote:
1) IPSEC kernel support. I am assuming we will get this as part of
the
move to 2.6.
2) IPSEC user space daemons and tools.
3) system-config-ipsec to provide a simple GUI for configuring common
IPSEC scenarios.
4) Documentation updates to cover IPSEC and the common tasks relating to
IPSEC.
+1
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
11:38 a.m.
On Mon, Dec 08, 2003 at 05:31:27PM +0000, Keith Sharp wrote:
1) IPSEC kernel support. I am assuming we will get this as part of
the
move to 2.6.
Yes.
2) IPSEC user space daemons and tools.
Yeah, we already packaged them for RHEL3.
3) system-config-ipsec to provide a simple GUI for configuring
common
IPSEC scenarios.
system-config-network is to configure ipsec as well; doesn't make sense
to have system-config-ipsec.
4) Documentation updates to cover IPSEC and the common tasks relating
to
IPSEC.
This could probably use help.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:23 p.m.
New subject: IPSec configuration (was: Fedora Core 2 wishlists)
On Mon, 2003-12-08 at 10:38, Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 05:31:27PM +0000, Keith Sharp wrote:
> 1) IPSEC kernel support. I am assuming we will get this as part of the
> move to 2.6.
Yes.
> 2) IPSEC user space daemons and tools.
Yeah, we already packaged them for RHEL3.
racoon. Uggh.
As a user and an administrator of variety of production systems IKE
daemons ranging from racoon, isakmpd, Solaris 8/9 IKE, FreeSWAN, and
SuperFreeSWAN, I can comment that I've found all but SuperFreeSWAN
sorely lacking.
I don't do the John Gilmore opportunistic encryption (OE)
save-the-free-world stuff (although I respect that, and the idea is
cool), I just use SuperFreeSWAN as:
* An IPsec VPN concentrator
* An IPsec client on road-warrior Linux laptops
* An IPsec client for LAN-LAN
The critical features the IKE daemon are:
* Ability to be configured as VPN concentrator supporting both road
warriors and remote LANs as well as transport mode (aka host-to-host)
all at the same time.
* X.509 certificate support
* Virtual-IP support to consistent inner IP address in ESP packets. This
allows no-headache IPsec through non-brain dead NATing routers/firewalls
without resorting to the following.
* NAT-T (ala ESP-over-UDP) for IPsec through brain dead NATing
routers/firewalls.
The other nice features are:
* AES support
* Notify/Delete SA (for Cisco interop)
SuperFreeSWAN's IKE daemon (pluto) gets you all the above and can sit on
top of the native 2.6 kernel IPsec.
Dax Kelson
Guru Labs
11:39 a.m.
Keith Sharp wrote:
1) IPSEC kernel support. I am assuming we will get this as part of
the
move to 2.6.
2) IPSEC user space daemons and tools.
3) system-config-ipsec to provide a simple GUI for configuring common
IPSEC scenarios.
4) Documentation updates to cover IPSEC and the common tasks relating to
IPSEC.
I also vote for ipsec with x509 support.
plus ext2/3 acl support both in 2.4 and 2.6 kernel.
--
Levente "Si vis pacem para bellum!"
2:03 p.m.
Farkas Levente (lfarkas(a)bppiac.hu) said:
Keith Sharp wrote:
>1) IPSEC kernel support. I am assuming we will get this as part of the
>move to 2.6.
>
>2) IPSEC user space daemons and tools.
>
>3) system-config-ipsec to provide a simple GUI for configuring common
>IPSEC scenarios.
>
>4) Documentation updates to cover IPSEC and the common tasks relating to
>IPSEC.
I also vote for ipsec with x509 support.
It's there, given the proper kernel, AFAIK. x509 stuff is completely
untested, though.
Bill
2:05 p.m.
Keith Sharp (kms(a)passback.co.uk) said:
1) IPSEC kernel support. I am assuming we will get this as part of
the
move to 2.6.
Yes.
2) IPSEC user space daemons and tools.
/me rebuilds them
3) system-config-ipsec to provide a simple GUI for configuring
common
IPSEC scenarios.
Included in system-config-network.
4) Documentation updates to cover IPSEC and the common tasks relating
to
IPSEC.
There's stuff in:
http://www.redhat.com/docs/manuals/enterprise/
Bill
11:33 a.m.
On Mon, 2003-12-08 at 07:15, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
pwdutils in addition to or instead of shadow-utils:
http://www.thkukuk.de/pam/pwdutils/
I haven't looked closely at these, but I know Thorsten Kukuk is the
maintainer for NIS/NIS+ and a bunch of glibc stuff, so it should be
pretty good and I like the feature set. (Remember the discussion last
week about LDAP?)
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
12:43 p.m.
On Mon, 8 Dec 2003, Wil Cooley wrote:
pwdutils in addition to or instead of shadow-utils:
http://www.thkukuk.de/pam/pwdutils/
Somewhat tangentially related:
it'd be nice if pam config files were restructured somewhat so that things
like default password policies could be established easily. Some of the
stuff in system-auth is managed by authconfig, and some isn't, which makes
it hard to work with currently (non-authconfig managed info should be moved
to a separate file so policy can be established w/o authconfig blowing your
changes away later)
later,
chris
5:25 p.m.
On Mon, Dec 08, 2003 at 01:43:19PM -0500, Chris Ricker wrote:
it'd be nice if pam config files were restructured somewhat so
that things
like default password policies could be established easily. Some of the
stuff in system-auth is managed by authconfig, and some isn't, which makes
it hard to work with currently (non-authconfig managed info should be moved
to a separate file so policy can be established w/o authconfig blowing your
changes away later)
When you mention "some of the stuff", do you mean cracklib's parameters,
or something else entirely?
Nalin
9:16 p.m.
On Mon, 2003-12-08 at 16:25, Nalin Dahyabhai wrote:
On Mon, Dec 08, 2003 at 01:43:19PM -0500, Chris Ricker wrote:
> it'd be nice if pam config files were restructured somewhat so that things
> like default password policies could be established easily. Some of the
> stuff in system-auth is managed by authconfig, and some isn't, which makes
> it hard to work with currently (non-authconfig managed info should be moved
> to a separate file so policy can be established w/o authconfig blowing your
> changes away later)
When you mention "some of the stuff", do you mean cracklib's parameters,
or something else entirely?
Besides the various cracklib parameters, there is also pam_unix's
"remember" parameter.
I would be nice to have both them configurable in some /etc/security
file instead (so authconfig doesn't blow em away).
Dax Kelson
Guru Labs
9:58 p.m.
I want to bring a little know application to everyones attention. It is
called MultiSync and can be found at http://www.multisync.org . It is
used to sync different data sources such as bluetooth phones, SyncML
compliant devices, with evolution. I've been using it to sync my palm
and sony-ericcson t616 with evolution for quite some time. It is very
nice and clean code and I think it should be included in the base
distro.
--Jack
1:03 a.m.
Also, the addition of distcc to core, and also maybe ccache? Two very
important tools.
The addition of the culmus project fonts for hebrew (culmus.sf.net) to
replace the real ugly hebrew fonts that are in place now.
7:55 a.m.
On Mon, 8 Dec 2003, Nalin Dahyabhai wrote:
When you mention "some of the stuff", do you mean
cracklib's parameters,
or something else entirely?
Two slightly different problems, really, and they're both due to how
authconfig works now:
1. all the stuff currently done by authconfig can't be customized beyond
what little authconfig supports. For example, if I want stronger password
quality enforcement than authconfig's defaults, I can't do that.
2. I can't extend it and add anything not known by authconfig. I've got some
additional modules which need to always be included in my environment here.
They'd logically work inserted into system-auth, but authconfig run later
would blow them away.
later,
chris
5:39 a.m.
Le lun 08/12/2003 à 21:42, Dan Young a écrit :
Wil Cooley said:
> (Remember the discussion last week about LDAP?)
Apropos LDAP integration, how about a purty system-config-ldap
(slapd/schemas/replication/etc.) tool? Probably need to pull in the
python-ldap module.
Well, what we certainly need is tools and sane default templates to
easily integrate a new system in a small (or not so small) network,
either as a station or as the main server.
IE :
- centralised user info & password (ldap + kerberos)
- file server (nfs4 ?)
- print server
- windows integration (samba)
Most of the software is already there, what we need is something that
doesn't need a week reading half-baked english howtos to work.
This would target all SMEs that need relief from MS licensing but do not
have the internal know-how to integrate all the various pieces, and all
the home networks (which I do expect to proliferate soon with broadband
availability, wireless and computer replacement instead of first buys).
Fedora right now is a great single-box solution, we need it to take over
the small networks now (or let the NT bits in XP do it).
Another killer app would be spamassassin with all the blacklist bridges
in fedora.us, basic fedora spamassassin is not good enough to kill the
various swen-like worm storms.
Cheers,
--
Nicolas Mailhot
7:13 a.m.
Nicolas.Mailhot(a)laPoste.net (Nicolas Mailhot) writes:
Well, what we certainly need is tools and sane default templates to
easily integrate a new system in a small (or not so small) network,
either as a station or as the main server.
- centralised user info & password (ldap + kerberos)
- print server
This will need more than some tools and templates.. AFAIK, there does not
exist a solution for a cups printserver with kerberos authentication.
Enrico
7:55 a.m.
Le mar 09/12/2003 à 14:13, Enrico Scholz a écrit :
Nicolas.Mailhot(a)laPoste.net (Nicolas Mailhot) writes:
> Well, what we certainly need is tools and sane default templates to
> easily integrate a new system in a small (or not so small) network,
> either as a station or as the main server.
>
> - centralised user info & password (ldap + kerberos)
> - print server
This will need more than some tools and templates.. AFAIK, there does not
exist a solution for a cups printserver with kerberos authentication.
So no authentication for print services at first (or only through
samba?). The fact is, no one will bother with authentified print
services when basic stuff like single user db & file server isn't there
yet (ie you can do them but joe average can not)
Cheers,
--
Nicolas Mailhot
9:25 a.m.
On 6:13:04 am 12/09/03 Enrico Scholz <enrico.scholz(a)informatik.tu-chemnitz.de>
wrote:
Nicolas.Mailhot(a)laPoste.net (Nicolas Mailhot) writes:
> Well, what we certainly need is tools and sane default templates to
> easily integrate a new system in a small (or not so small) network,
> either as a station or as the main server.
>
> - centralised user info & password (ldap + kerberos)
> - print server
This will need more than some tools and templates.. AFAIK, there does not
exist a solution for a cups printserver with kerberos authentication.
Correct. Michael Sweet (CUPS author) says he is waiting for an official
GSSAPI-over-HTTP specification.
BTW, LPRng does do GSSAPI printing authentication.
Dax Kelson
Guru Labs
10:45 a.m.
dax(a)gurulabs.com ("Dax Kelson") writes:
> This will need more than some tools and templates.. AFAIK, there
> does not exist a solution for a cups printserver with kerberos
> authentication.
Correct. Michael Sweet (CUPS author) says he is waiting for an official
GSSAPI-over-HTTP specification.
Microsoft published such a draft
http://wftp.tu-chemnitz.de/pub/documents/internet-drafts/draft-brezak-spn...
Recent mod_auth_kerberos (http://modauthkerb.sourceforge.net) contains
such an SPNEGO implementation.
BTW, LPRng does do GSSAPI printing authentication.
Wasn't LPRng removed from RH/Fedora recently?
Enrico
7:16 p.m.
A few more I've thought of:
o Web interface to management utils. This is kinda big, because a lot
of the installs I do are not managed by people running X on their
desktops, and setting up an X server or VNC is difficult enough that
it's not really a good option. I haven't looked at rhpl enough to know
how well abstracted between interface and controller it is, so it might
not be workable. I know Webmin has been floated before and shot down
before and I totally understand why from having looked at the code.
o I'd prefer to see /usr/bin/python2 handled as a symlink to
/usr/bin/python2.X{,.X} through a scriptlet or with alternatives. It's
easy to install multiple versions of Python except for this. Anyone
else thing this should be filed in Bugzilla as an RFE?
o GNOME Time Tracker.
o GQ, LDAP browser.
o +1 for OpenGroupware.org; it's got a usable web mail interface too.
o Rekall looks promising.
Stuff probably for Extras:
o SQL-Ledger and Zope + Plone would be good candidates for Extras.
There are plenty of good web applications and frameworks that could be
included in Extras too.
o An Apache 1.3 built specifically for running mod_perl, with mod_perl
built statically (because a lot of heavy mod_perl apps require or at
least recommend it, and recommend against version 2.)
o FreeRADIUS
o analog
o arc, unarj, unrar, zoo (needed for amavisd-new)
o dcc, Razor2 (with taint patch)
o fping
o pure-ftpd
o Tons of CPAN modules (discussed before)
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
10:32 p.m.
Wil Cooley (wcooley(a)nakedape.cc) said:
o I'd prefer to see /usr/bin/python2 handled as a symlink to
/usr/bin/python2.X{,.X} through a scriptlet or with alternatives. It's
easy to install multiple versions of Python except for this. Anyone
else thing this should be filed in Bugzilla as an RFE?
While I can see having multiple versions of some things on the system,
I'm not sure why there's a *lot* of gain with having multiple
versions of python. Unless, I suppose, you have large multi-threaded
python server apps that don't quite work the same with later versions,
but I don't know anyone that does that. :)
o GQ, LDAP browser.
This was in at one point and was removed. It's probably an
extras candidate.
o FreeRADIUS
Erm... that's in FC1.
Bill
10:47 p.m.
On Mon, 2003-12-08 at 20:32, Bill Nottingham wrote:
While I can see having multiple versions of some things on the
system,
I'm not sure why there's a *lot* of gain with having multiple
versions of python. Unless, I suppose, you have large multi-threaded
python server apps that don't quite work the same with later versions,
but I don't know anyone that does that. :)
Zope, for example :) It requires Python 2.1 (IIRC, I've been running
the binary build with Python built-in so I don't have to worry about
it). Development and experimentation with later versions would be
another benefit; otherwise all those system-config-* and other Python
apps which are not tested with later versions might break.
> o GQ, LDAP browser.
This was in at one point and was removed. It's probably an
extras candidate.
I'd be happy with it in Extras; it's probably one of the top 10
applications I use regularly.
> o FreeRADIUS
Erm... that's in FC1.
D'oh! I remember this now.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
2:06 p.m.
Greg KH (greg(a)kroah.com) said:
On Mon, Dec 08, 2003 at 10:15:30AM -0500, Michael K. Johnson wrote:
>
> 2.6 is looking good. There's a lot of integration work to do, though.
Is there anything we can do to provide help with this intergration?
Like provide udev packages, etc... :)
I'd like some 40-hour days, please.
Bill
1:58 p.m.
On Mon, 2003-12-08 at 18:38, Greg KH wrote:
On Mon, Dec 08, 2003 at 10:15:30AM -0500, Michael K. Johnson wrote:
>
> 2.6 is looking good. There's a lot of integration work to do, though.
Is there anything we can do to provide help with this intergration?
Like provide udev packages, etc... :)
This would be great - Kernel 2.6 without udev wouldn't really make
sense, would it? :-)
It would also be great to have an updated version of D-BUS as the
current D-BUS in Fedora is 0.13, and udev can use D-BUS>=0.20 to emit
D-BUS signals on the system message bus when device nodes are added and
removed (it's not enabled by default in udev).
The bad part is that packages depending on D-BUS 0.13 would require
changes on a source-level basis as non-API compatible changes were
introduced in D-BUS post 0.13. From memory, I recall that this at least
involves some CUPS stuff, the recently patched magicdev and possibly
bluez-pin if that is in FC1 today.
Thanks,
David
(My real motivation behind this cheering is of course, that at some
point I'd like to propose the freedesktop.org hal stuff I'm working on
for FC1 and I'd like to have my dependencies resolved before that :-) )
12:06 p.m.
On Mon, 2003-12-08 at 15:15, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
FWIW, one thing that we're not likely to do is just push the schedule
out by a week for project foo, another week for project bar, etc. ad
nauseum.
michaelkjohnson
Ooh wishlist time :)
1. Inclusion of speex so it can be made use of in Gnome Meeting and
leveraged in other applications e.g. accessibility and games etc.
2. Inclusion of valgrind - A very useful dev tool!
3. Inclusion of Sweep or equally good simple audio editor.
4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
see it go in favour of making the distro richer tool wise and still 3
binary CD's.
5. Inclusion of Theora etc. etc. :) Maybe not for FC2, but FC really
needs video support and tools.
6. Inclusion of the Anjuta IDE.
Regards
Philip Wyett
--
Email: philip(a)wyett.net
Website: http://www.wyett.net
Public key: http://www.wyett.net/gpg/public_key.txt
--
12:20 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Will the 2.6 kernel shipped with Fedora Core 2 have the preemptible
kernel feature enabled? I would like to see that, since it would make
Fedora ready for low-latency pro audio work out of the box.
- --
Ori Pessach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1MDuzA/uWWyw6uQRArJxAKC45yFk7/toNVqTUHg5KjUIG4RsUgCfW1DX
/lKEakBt8/q+1rNrgipbnB4=
=K6fU
-----END PGP SIGNATURE-----
12:31 p.m.
On Mon, Dec 08, 2003 at 11:20:35AM -0700, Ori Pessach wrote:
Will the 2.6 kernel shipped with Fedora Core 2 have the preemptible
kernel feature enabled? I would like to see that, since it would make
Fedora ready for low-latency pro audio work out of the box.
No, the pre-emptible kernel feature doesn't seem to be quite ready
yet. However, the 2.6 kernel also has the lowlatency patchset applied,
and that gives pretty much all of the benefit. Clark Williams wrote
a good paper on this a while ago.
However, we *are* exporting an easier initial configuration generation
mechanism with these kernels that will make it easier to rebuild a
kernel to your specifications; you'll be able to make configuration
changes in the fewest logical places and rebuilt SRPMs, which should
make Fedora Alternatives projects that include modified kernels easier.
When kernel-2.6.0-0.test11.1.8 or later is in devel, you can look at
its SRPM for the config-* files of the kernel-*-config files. These
config-* files are merged together into kernel-*-config files at
build time.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
12:47 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael K. Johnson wrote:
| On Mon, Dec 08, 2003 at 11:20:35AM -0700, Ori Pessach wrote:
|
|>Will the 2.6 kernel shipped with Fedora Core 2 have the preemptible
|>kernel feature enabled? I would like to see that, since it would make
|>Fedora ready for low-latency pro audio work out of the box.
|
|
| No, the pre-emptible kernel feature doesn't seem to be quite ready
| yet. However, the 2.6 kernel also has the lowlatency patchset applied,
| and that gives pretty much all of the benefit. Clark Williams wrote
| a good paper on this a while ago.
What are the issues? (a pointer to the Clark Williams paper would be
fine as an answer). I saw a dramatic improvement in scheduling latency
when I recompiled the 2.6 test 11 kernel to enable the pre-emptible
kernel. When compared to the RPM available from
http://people.redhat.com/arjanv/2.5/RPMS.kernel/, scheduling latency was
down by an order of magnitude, if I remember correctly. If that kernel
RPM doesn't contain the lowlatency pathces, that's understandable, but
otherwise I'm not sure what's going on.
It would be nice not to have to recompile the kernel to get this
functionality.
- --
Ori Pessach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1McrzA/uWWyw6uQRAhJsAJ4mmFDweNbXZ5tPC2Gzx9Md4e68PACfSBba
yJnot5jojR/LyoIbAz5deoE=
=dIbP
-----END PGP SIGNATURE-----
1:31 p.m.
On Mon, 2003-12-08 at 19:47, Ori Pessach wrote:
| No, the pre-emptible kernel feature doesn't seem to be quite
ready
| yet. However, the 2.6 kernel also has the lowlatency patchset applied,
| and that gives pretty much all of the benefit. Clark Williams wrote
| a good paper on this a while ago.
What are the issues? (a pointer to the Clark Williams paper would be
fine as an answer). I saw a dramatic improvement in scheduling latency
when I recompiled the 2.6 test 11 kernel to enable the pre-emptible
kernel. When compared to the RPM available from
http://people.redhat.com/arjanv/2.5/RPMS.kernel/, scheduling latency was
down by an order of magnitude, if I remember correctly. If that kernel
RPM doesn't contain the lowlatency pathces, that's understandable, but
otherwise I'm not sure what's going on.
There are some strange, not-easily-reproducible bugs that seems to get
triggered when preemptible is enabled.
It would be nice not to have to recompile the kernel to get this
functionality.
Currently, it's impossible to do that, since pre-emption support can't
be enabled as a module. Enabling preemption on-the-fly is not an easy
task so, for the time being, you'll need to recompile.
3:27 a.m.
Le lun 08/12/2003 à 20:31, Felipe Alfaro Solana a écrit :
On Mon, 2003-12-08 at 19:47, Ori Pessach wrote:
> | No, the pre-emptible kernel feature doesn't seem to be quite ready
> | yet. However, the 2.6 kernel also has the lowlatency patchset applied,
> | and that gives pretty much all of the benefit. Clark Williams wrote
> | a good paper on this a while ago.
>
> What are the issues? (a pointer to the Clark Williams paper would be
> fine as an answer). I saw a dramatic improvement in scheduling latency
> when I recompiled the 2.6 test 11 kernel to enable the pre-emptible
> kernel. When compared to the RPM available from
> http://people.redhat.com/arjanv/2.5/RPMS.kernel/, scheduling latency was
> down by an order of magnitude, if I remember correctly. If that kernel
> RPM doesn't contain the lowlatency pathces, that's understandable, but
> otherwise I'm not sure what's going on.
There are some strange, not-easily-reproducible bugs that seems to get
triggered when preemptible is enabled.
However Linus' opinion seems to be this is not preempt code that is
buggy, but preempt makes it a lot easier to hit *existing* races.
So preempt should certainly go in rawhide and maybe even be available as
a debug kernel later.
> It would be nice not to have to recompile the kernel to get
this
> functionality.
Currently, it's impossible to do that, since pre-emption support can't
be enabled as a module. Enabling preemption on-the-fly is not an easy
task so, for the time being, you'll need to recompile.
And since preempt touches core code it probably can not even be
modularised.
Cheers,
--
Nicolas Mailhot
5:33 a.m.
On Tue, Dec 09, 2003 at 10:27:50AM +0100, Nicolas Mailhot wrote:
> Currently, it's impossible to do that, since pre-emption
support can't
> be enabled as a module. Enabling preemption on-the-fly is not an easy
> task so, for the time being, you'll need to recompile.
And since preempt touches core code it probably can not even be
modularised.
The best you could hope for is have it compiled in, but disabled,
and make it enable-able through a sysctl. Linus objected to this
idea a year or so back, so this is unlikely to happen upstream,
and tbh, unlikely to happen in the Red Hat kernel any time soon.
Dave
11:06 a.m.
New subject: Preemptible kernel in Fedora Core 2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I understand you correctly, then the 2.6 kernel has lowlatency
patches, but has the pre-emptable kernel disabled.
This is not what I've seen. In my experience, and also according to the
Clark Williams paper, the biggest imporovement in scheduling latency
comes from the lowlatency patches. The 2.6 kernels I tried (from the
RPMs I mentioned earlier) had really bad scheduling latency when the
pre-emptible kernel feature wasn't compiled in. They behaved just like
the 2.4 kernel without lowlatency.
That means that the 2.6 kernel RPMs I've seen were useless for pro audio
work without turning on the preemptible kernel.
Am I missing something? Is the 2.6 kernel slated for inclusion in FC2
different from the one available in
http://people.redhat.com/arjanv/2.5/RPMS.kernel/ ?
- --
Ori Pessach
Michael K. Johnson wrote:
| On Mon, Dec 08, 2003 at 11:20:35AM -0700, Ori Pessach wrote:
|
|>Will the 2.6 kernel shipped with Fedora Core 2 have the preemptible
|>kernel feature enabled? I would like to see that, since it would make
|>Fedora ready for low-latency pro audio work out of the box.
|
|
| No, the pre-emptible kernel feature doesn't seem to be quite ready
| yet. However, the 2.6 kernel also has the lowlatency patchset applied,
| and that gives pretty much all of the benefit. Clark Williams wrote
| a good paper on this a while ago.
|
| However, we *are* exporting an easier initial configuration generation
| mechanism with these kernels that will make it easier to rebuild a
| kernel to your specifications; you'll be able to make configuration
| changes in the fewest logical places and rebuilt SRPMs, which should
| make Fedora Alternatives projects that include modified kernels easier.
| When kernel-2.6.0-0.test11.1.8 or later is in devel, you can look at
| its SRPM for the config-* files of the kernel-*-config files. These
| config-* files are merged together into kernel-*-config files at
| build time.
|
| michaelkjohnson
|
| "He that composes himself is wiser than he that composes a book."
| Linux Application Development -- Ben Franklin
| http://people.redhat.com/johnsonm/lad/
|
|
| --
| fedora-devel-list mailing list
| fedora-devel-list(a)redhat.com
| http://www.redhat.com/mailman/listinfo/fedora-devel-list
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1gD5zA/uWWyw6uQRAqM8AJ0UMHzlm5yXFoEt46ZXT8HxWEPOtwCgxgbT
mHFuCIOnYlu7V1PWD7dBxZk=
=6Aks
-----END PGP SIGNATURE-----
1:31 p.m.
New subject: Preemptible kernel in Fedora Core 2
On Tue, 2003-12-09 at 18:06, Ori Pessach wrote:
If I understand you correctly, then the 2.6 kernel has lowlatency
patches, but has the pre-emptable kernel disabled.
So, what's the problem? You can always recompile it yourself to enable
preemptible support. I have been compiling 2.5 kernels myself since
2.5.1, since I don't want/need all the stuff that comes by default with
Fedora kernels.
2:04 p.m.
New subject: Preemptible kernel in Fedora Core 2
On Tue, Dec 09, 2003 at 10:06:03AM -0700, Ori Pessach wrote:
comes from the lowlatency patches. The 2.6 kernels I tried (from the
RPMs I mentioned earlier) had really bad scheduling latency when the
pre-emptible kernel feature wasn't compiled in. They behaved just like
the 2.4 kernel without lowlatency.
Existing lowlatency patches were included. That doesn't mean that no
new latency points have crept in since. "lowlatency patches" means
fixing high latency points by explicitly yeilding; pre-emption is
implicit yields.
I would suggest that using kernel profiling to track down additional
latency points, since you are clearly hitting latency points now,
would be a useful thing to do.
Am I missing something? Is the 2.6 kernel slated for inclusion in
FC2
different from the one available in
http://people.redhat.com/arjanv/2.5/RPMS.kernel/ ?
A bit different (no 4g/4g support); new 2.6 kernels in the FC track are
now showing up in devel.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
4:06 p.m.
New subject: Preemptible kernel in Fedora Core 2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael K. Johnson wrote:
| I would suggest that using kernel profiling to track down additional
| latency points, since you are clearly hitting latency points now,
| would be a useful thing to do.
Probably. I'll try that.
- --
Ori Pessach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1kdKzA/uWWyw6uQRAvk2AJ9hy5+u6eYtpzzEOx3jtwsWmHSujgCcD1DP
0DAg7DGGYwPTVbWzE2PDq2c=
=5IuC
-----END PGP SIGNATURE-----
2:34 p.m.
New subject: Preemptible kernel in Fedora Core 2
On Tue, Dec 09, 2003 at 03:04:52PM -0500, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 10:06:03AM -0700, Ori Pessach wrote:
> comes from the lowlatency patches. The 2.6 kernels I tried (from the
> RPMs I mentioned earlier) had really bad scheduling latency when the
> pre-emptible kernel feature wasn't compiled in. They behaved just like
> the 2.4 kernel without lowlatency.
Existing lowlatency patches were included. That doesn't mean that no
new latency points have crept in since. "lowlatency patches" means
fixing high latency points by explicitly yeilding; pre-emption is
implicit yields.
I would suggest that using kernel profiling to track down additional
latency points, since you are clearly hitting latency points now,
would be a useful thing to do.
i've seen some improvements from using one of the arjan
kernels to useing arjan kernel+preempt while doing audio stuff.
It's hard to quantify, but ll+preemt doesn't cause overruns with
jackd, while the same settings with just ll sometimes causes them.
That said 2.6+ll is still way way way better than the
stock rh2.4 for that kind of thing.
I'd say at least turn on preempt for rawhide, if
for no other reason than to find those mysterious bugs
no one can put a finger on.
Adrian
3:23 p.m.
New subject: Preemptible kernel in Fedora Core 2
On Tue, 2003-12-09 at 12:06, Ori Pessach wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If I understand you correctly, then the 2.6 kernel has lowlatency
patches, but has the pre-emptable kernel disabled.
Aren't people still having some serious issues pre-empt?
This is not what I've seen. In my experience, and also according
to the
Clark Williams paper, the biggest imporovement in scheduling latency
comes from the lowlatency patches. The 2.6 kernels I tried (from the
RPMs I mentioned earlier) had really bad scheduling latency when the
pre-emptible kernel feature wasn't compiled in. They behaved just like
the 2.4 kernel without lowlatency.
Wow I totally disagree with you here. I've been using 2.6 for a couple
months now and it has _drastically_ improved latency. Might I suggest
you are hitting some snags specific to your kernel/system?
That means that the 2.6 kernel RPMs I've seen were useless for
pro audio
work without turning on the preemptible kernel.
Here again I disagree. Maybe pre-empt would make it better, but as far
as multimedia and sound work go, again 2.6 is working awesome for me.
Have you tried recompiling the kernel yourself? I'm not using a default
kerenl, perhaps a custom kernel minus some fluff would yield some etter
results?
Am I missing something? Is the 2.6 kernel slated for inclusion in
FC2
different from the one available in
http://people.redhat.com/arjanv/2.5/RPMS.kernel/ ?
Well the arjan's RPMs are kind of an incomplete set, I had to modify
numerous things in order to get my system working correctly, including
modify init scripts. In FC2 I expect there will be much improved system
integration, etc...
- --
Ori Pessach
-sb
3:40 p.m.
New subject: Preemptible kernel in Fedora Core 2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stan Bubrouski wrote:
| Wow I totally disagree with you here. I've been using 2.6 for a couple
| months now and it has _drastically_ improved latency. Might I suggest
| you are hitting some snags specific to your kernel/system?
What kind of numbers have you been seeing? I have seen scheduling
latency of well below 2ms with preempt enabled (usually below 1ms), and
in the double digits with preempt disabled. I'll run more tests, but
that was basically the picture.
| Here again I disagree. Maybe pre-empt would make it better, but as far
| as multimedia and sound work go, again 2.6 is working awesome for me.
What do you mean by "multimedia"? Running xmms and running Ardour, for
example, are two different things. What kind of things do you run?
| Have you tried recompiling the kernel yourself? I'm not using a default
| kerenl, perhaps a custom kernel minus some fluff would yield some etter
| results?
I don't see why merely compiling less drivers is going to make a
difference. Unless you have something else in mind when you use the word
"fluff".
- --
Ori Pessach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1kFHzA/uWWyw6uQRAq6PAJ9K2aXM6pEw1z2VSxvNxax0rlzfNwCgpqor
BzWBAEa+W+V1K5s6hYuTWKc=
=hNnY
-----END PGP SIGNATURE-----
4:10 p.m.
New subject: Preemptible kernel in Fedora Core 2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've done some more tests. Again, with 2.6 test11 without preempt, I get
scheduling latencies as high as 27ms or so. With preempt enabled, I get
nothing higher than 5 ms.
So, I do take one statemnt back, sort of: 2.6 isn't as bad as an
unpatched 2.4 kernel, but it's still unusable for low latency audio
work, at least on my system. I works just fine with preempt enabled, though.
I (and many other people, I'm sure) would probably prefer not to have to
recompile their kernel just to get their recording software to work.
This was my motivation for bringing up the subject in the first place.
- --
Ori Pessach
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/1khuzA/uWWyw6uQRAgzlAJ9wxgBfz6QN2e52XRrNFGNW/M/RfACeMYwa
VwfezpiLSbmaVn2VRqiTxi0=
=wToB
-----END PGP SIGNATURE-----
1:03 p.m.
On Mon, Dec 08, 2003 at 06:06:24PM +0000 or thereabouts, Philip Wyett wrote:
On Mon, 2003-12-08 at 15:15, Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.
Ooh wishlist time :)
1. Inclusion of speex so it can be made use of in Gnome Meeting and
leveraged in other applications e.g. accessibility and games etc.
Oh, yes. speex is handy. Some conferences are recording talks in
speex format these days.
2. Inclusion of valgrind - A very useful dev tool!
This has come up before. An RFE of "include valgrind" at
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=78403
was closed with WONTFIX. (For those not inclined to click
on the URL, one word: "patents")
A list of "we'd love to, but patents prevent.." software
somewhere might not go amiss. I don't see anything like
that on a cursory (very cursory) skim of RH and Fedora
pages. I have the vague idea that there are quite a few
packages this affects.
Telsa
1:40 p.m.
On Mon, 2003-12-08 at 19:18, Felipe Alfaro Solana wrote:
On Mon, 2003-12-08 at 19:06, Philip Wyett wrote:
> 4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
> see it go in favour of making the distro richer tool wise and still 3
> binary CD's.
Why not GNOME? I prefer KDE.
Just seriously, I think both *must* be included.
Well... other than I prefer Gnome, there is no reason at all why Gnome
should not be the one to go. My real point is I think we are reaching a
point of critical mass (or soon will) with the larger Window Managers,
their apps and for the sake of distro size and to allow additional much
needed tools in - one may have to go.
Regards
Philip Wyett
--
Email: philip(a)wyett.net
Website: http://www.wyett.net
Public key: http://www.wyett.net/gpg/public_key.txt
--
1:47 p.m.
On Mon, Dec 08, 2003 at 07:40:48PM +0000, Philip Wyett wrote:
Well... other than I prefer Gnome, there is no reason at all why
Gnome
should not be the one to go. My real point is I think we are reaching a
point of critical mass (or soon will) with the larger Window Managers,
their apps and for the sake of distro size and to allow additional much
needed tools in - one may have to go.
DVD players get common, DVD burners get cheaper, average bandwidth rises.
I'm not sure who is winning the race - the package builders or the media
people 8)
Being able to do things like pull large less critical stuff cleanly onto
a specific CD (eg so generic installs dont need CD3) would be great but
the kind of juggling required isnt trivial
2:17 p.m.
On Mon, 2003-12-08 at 14:40, Philip Wyett wrote:
On Mon, 2003-12-08 at 19:18, Felipe Alfaro Solana wrote:
> On Mon, 2003-12-08 at 19:06, Philip Wyett wrote:
> > 4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
> > see it go in favour of making the distro richer tool wise and still 3
> > binary CD's.
>
> Why not GNOME? I prefer KDE.
> Just seriously, I think both *must* be included.
>
Well... other than I prefer Gnome, there is no reason at all why Gnome
should not be the one to go. My real point is I think we are reaching a
point of critical mass (or soon will) with the larger Window Managers,
their apps and for the sake of distro size and to allow additional much
needed tools in - one may have to go.
I know I'm going to get flamed for this one... But here goes.
1st idea: Make Fedora strictly GNOME based.
2nd idea: Have two different ISO bases for GNOME or KDE
3rd idea: Split Window Managers / Desktop enviorments out to a disc3.
Then, you simply download: ISO 1 and 2, and then make disc3 WM/DE
dependent. You could download: fedora_core-disc3-KDE.iso or
fedora-core-disc3-GNOME.iso
Again, please don't read this in as KDE bashing, I think KDE is pretty
nifty myself. I've used it for years at a time. I simply think
worrying about different desktops, divides an effort to truly move
forward.
The only reason I didn't suggest KDE was because Redhat^WFedora
currently defaults to Gnome.
Trae
--
Trae McCombs
http://occy.net/
founder: themes.org || linux.com
3:15 p.m.
On Mon, 2003-12-08 at 20:17, Trae McCombs wrote:
On Mon, 2003-12-08 at 14:40, Philip Wyett wrote:
> On Mon, 2003-12-08 at 19:18, Felipe Alfaro Solana wrote:
> > On Mon, 2003-12-08 at 19:06, Philip Wyett wrote:
> > > 4. Removal of KDE. Ok, this ain't likely, but I'd personally like
to
> > > see it go in favour of making the distro richer tool wise and still 3
> > > binary CD's.
> >
> > Why not GNOME? I prefer KDE.
> > Just seriously, I think both *must* be included.
> >
>
> Well... other than I prefer Gnome, there is no reason at all why Gnome
> should not be the one to go. My real point is I think we are reaching a
> point of critical mass (or soon will) with the larger Window Managers,
> their apps and for the sake of distro size and to allow additional much
> needed tools in - one may have to go.
I know I'm going to get flamed for this one... But here goes.
1st idea: Make Fedora strictly GNOME based.
To reduce development effort down to one Window manager, making the
choice between the big two would be the best solution IMHO.
/me is now being real careful not to say which one!
2nd idea: Have two different ISO bases for GNOME or KDE
I'm getting a headache just thinking about this one.
3rd idea: Split Window Managers / Desktop enviorments out to a
disc3.
Then, you simply download: ISO 1 and 2, and then make disc3 WM/DE
dependent. You could download: fedora_core-disc3-KDE.iso or
fedora-core-disc3-GNOME.iso
Hmm...
An idea certainly. Soon to be squashed by an RH employee soon I expect!
Again, please don't read this in as KDE bashing, I think KDE is
pretty
nifty myself. I've used it for years at a time. I simply think
worrying about different desktops, divides an effort to truly move
forward.
I also use KDE with Fedora and other distro's. A concern for me is lots
of things in distro's all doing the same or similar things, this is why
I brought this up. Yup, I know we get into that old nugget of choice and
getting the balance right for everyone is virtually impossible <sigh>.
Regards
Philip Wyett
--
Email: philip(a)wyett.net
Website: http://www.wyett.net
Public key: http://www.wyett.net/gpg/public_key.txt
--
3:15 a.m.
On Mon, 2003-12-08 at 21:17, Trae McCombs wrote:
I know I'm going to get flamed for this one... But here goes.
1st idea: Make Fedora strictly GNOME based.
Consider yourself flamed ;-)
I completely disagree on this. Currently, KDE and GNOME are of equal
value. There's great GNOME software, like Evolution, and incredible KDE
software, like K3B. Many people, use both, like me. Removing one of them
is a great mistake, I think.
2nd idea: Have two different ISO bases for GNOME or KDE
Someone propsed the idea to better organize ISO images. For example, CD
#2 and #3 could be GNOME software, while CD #4 and #5 could be KDE
software.
3rd idea: Split Window Managers / Desktop enviorments out to a
disc3.
Then, you simply download: ISO 1 and 2, and then make disc3 WM/DE
dependent. You could download: fedora_core-disc3-KDE.iso or
fedora-core-disc3-GNOME.iso
Again, please don't read this in as KDE bashing, I think KDE is pretty
nifty myself. I've used it for years at a time. I simply think
worrying about different desktops, divides an effort to truly move
forward.
I don't see why... Instead, both KDE and GNOME communities are working
together towards integration and common goals. Removing KDE or GNOME
completely makes no sense and limits the freedom of choice.
3:26 a.m.
Consider yourself flamed ;-)
I completely disagree on this. Currently, KDE and GNOME are of equal
value. There's great GNOME software, like Evolution, and incredible KDE
software, like K3B. Many people, use both, like me. Removing one of them
is a great mistake, I think.
Well, as K3B isn't provided on the isos, I fail to see how removing KDE
from the isos would make you lose K3B :)
I don't see why... Instead, both KDE and GNOME communities are
working
together towards integration and common goals. Removing KDE or GNOME
completely makes no sense and limits the freedom of choice.
My idea on the subject is that Fedora *Core* should provide only one DE
(GNOE) but could (should) provide apps from the other DE (KDE). What I
don't like is have several apps for the same task. So I'd say that the
best is to provide GNOME libs and KDE libs, the GNOME desktop and the
best apps for each task (OOO for office, Mozilla for web-browsing,
Evolution for email, K3B for CD burning, Quanta for HTML editing,
etc...).
If people want to replace the GNOME desktop by the KDE desktop, they
could still yum install it.
--
Julien Olivier <julo(a)altern.org>
6:07 a.m.
On Wednesday 10 December 2003 10:26, Julien Olivier wrote:
> Consider yourself flamed ;-)
> I completely disagree on this. Currently, KDE and GNOME are of equal
> value. There's great GNOME software, like Evolution, and incredible KDE
> software, like K3B. Many people, use both, like me. Removing one of them
> is a great mistake, I think.
Well, as K3B isn't provided on the isos, I fail to see how removing KDE
from the isos would make you lose K3B :)
> I don't see why... Instead, both KDE and GNOME communities are working
> together towards integration and common goals. Removing KDE or GNOME
> completely makes no sense and limits the freedom of choice.
My idea on the subject is that Fedora *Core* should provide only one DE
(GNOE) but could (should) provide apps from the other DE (KDE). What I
don't like is have several apps for the same task. So I'd say that the
best is to provide GNOME libs and KDE libs, the GNOME desktop and the
best apps for each task (OOO for office, Mozilla for web-browsing,
Evolution for email, K3B for CD burning, Quanta for HTML editing,
etc...).
If people want to replace the GNOME desktop by the KDE desktop, they
could still yum install it.
KDE has a user base as strong as GNOME.
Removing KDE from Core (on CD) would mean that all KDE users need a broadband internet
connection.
Also there is no "best" E-Mail Client, KMail for example has many advantages
over Evolution.
--
ronny
6:17 a.m.
> If people want to replace the GNOME desktop by the KDE desktop,
they
> could still yum install it.
KDE has a user base as strong as GNOME.
Removing KDE from Core (on CD) would mean that all KDE users need a broadband internet
connection.
Don't get me wrong. I haven't stated that KDE wasn't important. What I
mean is that, *as Fedora defaults to GNOME*, if Fedora had to provide
only 1 desktop it would be GNOME. More over, as CDs are not available in
stores anymore, you can guess that the majority of Fedora users will
have downloaded the isos through their broadband connection. I could be
very wrong though (I hope so :)). However, if I am wrong and most people
really don't have broadband connections, then i agree that it's better
to have CDs full of *alternative* packages (as opposed to Fedora's
default packages).
Also there is no "best" E-Mail Client, KMail for example
has many advantages over Evolution.
There might well not be a "best" email client, but Fedora has to default
to one, even if there are good alternatives.
The question is more: do we want CDs full of alternative software or CDs
containing only the default apps ?
--
Julien Olivier <julo(a)altern.org>
3:47 p.m.
On Wed, 2003-12-10 at 13:17, Julien Olivier wrote:
> Removing KDE from Core (on CD) would mean that all KDE users
need a broadband internet
> connection.
>
Don't get me wrong. I haven't stated that KDE wasn't important. What I
mean is that, *as Fedora defaults to GNOME*, if Fedora had to provide
only 1 desktop it would be GNOME.
And *SuSE defaults to KDE*. However, SuSE has kept shipping GNOME. I
still don't see why people want to remove KDE from Fedora CD's.
4:04 p.m.
> Don't get me wrong. I haven't stated that KDE wasn't
important. What I
> mean is that, *as Fedora defaults to GNOME*, if Fedora had to provide
> only 1 desktop it would be GNOME.
And *SuSE defaults to KDE*. However, SuSE has kept shipping GNOME. I
still don't see why people want to remove KDE from Fedora CD's.
Could you please also read the last 12 words of my sentence ? It says
"if Fedora had to provide only 1 desktop it would be GNOME". What is
wrong in this sentence ?
--
Julien Olivier <julo(a)altern.org>
5:04 p.m.
On Wed, 2003-12-10 at 23:04, Julien Olivier wrote:
> > Don't get me wrong. I haven't stated that KDE
wasn't important. What I
> > mean is that, *as Fedora defaults to GNOME*, if Fedora had to provide
> > only 1 desktop it would be GNOME.
>
> And *SuSE defaults to KDE*. However, SuSE has kept shipping GNOME. I
> still don't see why people want to remove KDE from Fedora CD's.
Could you please also read the last 12 words of my sentence ? It says
"if Fedora had to provide only 1 desktop it would be GNOME". What is
wrong in this sentence ?
Nothing... It's me. Sorry... I need to get some sleep.
12:47 p.m.
On Monday 08 December 2003 15:17, Trae McCombs wrote:
I know I'm going to get flamed for this one... But here goes.
1st idea: Make Fedora strictly GNOME based.
2nd idea: Have two different ISO bases for GNOME or KDE
3rd idea: Split Window Managers / Desktop enviorments out to a disc3.
Then, you simply download: ISO 1 and 2, and then make disc3 WM/DE
dependent. You could download: fedora_core-disc3-KDE.iso or
fedora-core-disc3-GNOME.iso
The problem is that while I run metacity/gnome, I also run a number of kde
applications such as kmail.
--
Gene
3:20 a.m.
The problem is that while I run metacity/gnome, I also run a number
of kde
applications such as kmail.
That might not be the answer you were waiting for, but why not simply
run "yum install kmail" after the installation ?
Personally, I had to install K3B this way, and it was very easy. So I
won't even ask for inclusion of K3B in Fedora Core :)
--
Julien Olivier <julo(a)altern.org>
2:18 p.m.
On Mon, 8 Dec 2003, Philip Wyett wrote:
On Mon, 2003-12-08 at 19:18, Felipe Alfaro Solana wrote:
> On Mon, 2003-12-08 at 19:06, Philip Wyett wrote:
> > 4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
> > see it go in favour of making the distro richer tool wise and still 3
> > binary CD's.
>
> Why not GNOME? I prefer KDE.
> Just seriously, I think both *must* be included.
>
Well... other than I prefer Gnome, there is no reason at all why Gnome
should not be the one to go. My real point is I think we are reaching a
point of critical mass (or soon will) with the larger Window Managers,
their apps and for the sake of distro size and to allow additional much
needed tools in - one may have to go.
Smells like we would have 4 binary CDs for FC2. What about
putting all GNOME apps in a single isolated CD, all KDE's in
another one. So you can skip burning one CD. This way we have
lotsa space to include GNOME/KDE apps.
$0.02
behdad
Regards
Philip Wyett
2:54 p.m.
Behdad Esfahbod (behdad(a)cs.toronto.edu) said:
Smells like we would have 4 binary CDs for FC2. What about
putting all GNOME apps in a single isolated CD, all KDE's in
another one. So you can skip burning one CD. This way we have
lotsa space to include GNOME/KDE apps.
This will generally lead to CD-swapping-galore.
Bill
1:35 p.m.
On Mon, 2003-12-08 at 11:06, Philip Wyett wrote:
4. Removal of KDE. Ok, this ain't likely, but I'd personally
like to
see it go in favour of making the distro richer tool wise and still 3
binary CD's.
Obviously the suggestion wouldn't even be taken seriously. However, it
does bring up a good point.
I would like to see well-organized ISOs. E.g. you shouldn't even need
Disk 3 for the default install, and probably not even Disk 2 for a
minimal install. KDE stuff would then be located almost entirely on Disk
3.
I wouldn't object to the old Mandrake technique of telling the installer
what CDs you actually have, then having it disable packages that aren't
available on your CDs.
2:07 p.m.
On Mon, 2003-12-08 at 14:35, Tyler larson wrote:
On Mon, 2003-12-08 at 11:06, Philip Wyett wrote:
> 4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
> see it go in favour of making the distro richer tool wise and still 3
> binary CD's.
Obviously the suggestion wouldn't even be taken seriously. However, it
does bring up a good point.
I would like to see well-organized ISOs. E.g. you shouldn't even need
Disk 3 for the default install, and probably not even Disk 2 for a
minimal install. KDE stuff would then be located almost entirely on Disk
3.
I believe that if you do a Gnome-only desktop installation in FC1, you
will only need cd's 1 & 2.
Cheers,
Brent
I wouldn't object to the old Mandrake technique of telling the installer
what CDs you actually have, then having it disable packages that aren't
available on your CDs.
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
10:16 a.m.
----- Original Message -----
From: "Julien Olivier" <julo(a)altern.org>
To: <fedora-devel-list(a)redhat.com>
Sent: Monday, December 15, 2003 9:51 PM
Subject: Re: Fedora Core 2 wishlists
> I believe that if you do a Gnome-only desktop installation in
FC1, you
> will only need cd's 1 & 2.
You're right. That wasn't the case for Redhat 9 but it's the case for
Fedora 1.
Unless you try to install FC1 in a language other than english (spanish at
least).
Alfredo
2:07 p.m.
Philip Wyett (philip(a)wyett.net) said:
1. Inclusion of speex so it can be made use of in Gnome Meeting and
leveraged in other applications e.g. accessibility and games etc.
Hm, that's definitely an idea. Flac is going in, so Speex could logically
follow.
2. Inclusion of valgrind - A very useful dev tool!
Not happening due to patent issues, sorry.
Bill
2:27 p.m.
Bill Nottingham wrote:
Philip Wyett (philip(a)wyett.net) said:
>1. Inclusion of speex so it can be made use of in Gnome Meeting and
> leveraged in other applications e.g. accessibility and games etc.
>
>
Hm, that's definitely an idea. Flac is going in, so Speex could logically
follow.
YEAH! FLAC ROCKS!
3:25 a.m.
On Mon, 2003-12-08 at 21:07, Bill Nottingham wrote:
Philip Wyett (philip(a)wyett.net) said:
> 1. Inclusion of speex so it can be made use of in Gnome Meeting and
> leveraged in other applications e.g. accessibility and games etc.
Hm, that's definitely an idea. Flac is going in, so Speex could logically
follow.
Speex is included in openh323 already, so should work in gnomemeeting.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's a sword-wielding flyboy matador on the run. She's a scantily clad psychic
schoolgirl from a secret island of warrior women. They fight crime!
11:51 p.m.
Bill Nottingham (notting(a)redhat.com) said:
Philip Wyett (philip(a)wyett.net) said:
> 1. Inclusion of speex so it can be made use of in Gnome Meeting and
> leveraged in other applications e.g. accessibility and games etc.
Hm, that's definitely an idea. Flac is going in, so Speex could logically
follow.
Actually, OpenH323 includes its own copy of speex... does GnomeMeeting
not use this version?
Bill
12:01 a.m.
On Fri, 2003-12-12 at 05:51, Bill Nottingham wrote:
Bill Nottingham (notting(a)redhat.com) said:
> Philip Wyett (philip(a)wyett.net) said:
> > 1. Inclusion of speex so it can be made use of in Gnome Meeting and
> > leveraged in other applications e.g. accessibility and games etc.
>
> Hm, that's definitely an idea. Flac is going in, so Speex could logically
> follow.
Actually, OpenH323 includes its own copy of speex... does GnomeMeeting
not use this version?
Bill
A look shows that yes it does. However, we really need speex to be
packaged separate, so it can be made use of elsewhere easily.
Regards
Phil
--
Email: philip(a)wyett.net
Website: http://www.wyett.net
Public key: http://www.wyett.net/gpg/public_key.txt
--
2:54 p.m.
On Mon, 2003-12-08 at 13:06, Philip Wyett wrote:
Ooh wishlist time :)
1. Inclusion of speex so it can be made use of in Gnome Meeting and
leveraged in other applications e.g. accessibility and games etc.
Is speex stable enough yet?
2. Inclusion of valgrind - A very useful dev tool!
3. Inclusion of Sweep or equally good simple audio editor.
4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
see it go in favour of making the distro richer tool wise and still 3
binary CD's.
5. Inclusion of Theora etc. etc. :) Maybe not for FC2, but FC really
needs video support and tools.
Theora is only in CVS correct? And on a side note I have yet to compile
a working Theora library from ogg cvs yet on FC1. Numerous unresolved
symbols when trying to link anything against the libs. I'm doubtful on
this till it at least links correctly on FC1.
6. Inclusion of the Anjuta IDE.
Regards
Philip Wyett
-sb
3:27 p.m.
On Mon, 2003-12-08 at 20:54, Stan Bubrouski wrote:
On Mon, 2003-12-08 at 13:06, Philip Wyett wrote:
> Ooh wishlist time :)
>
> 1. Inclusion of speex so it can be made use of in Gnome Meeting and
> leveraged in other applications e.g. accessibility and games etc.
>
Is speex stable enough yet?
Seems to be quite stable in the 1.0.x releases. Not personally moved to
the 1.1.x unstables yet to check where speex is at present in
development.
> 2. Inclusion of valgrind - A very useful dev tool!
>
> 3. Inclusion of Sweep or equally good simple audio editor.
>
> 4. Removal of KDE. Ok, this ain't likely, but I'd personally like to
> see it go in favour of making the distro richer tool wise and still 3
> binary CD's.
>
> 5. Inclusion of Theora etc. etc. :) Maybe not for FC2, but FC really
> needs video support and tools.
>
Theora is only in CVS correct? And on a side note I have yet to compile
a working Theora library from ogg cvs yet on FC1. Numerous unresolved
symbols when trying to link anything against the libs. I'm doubtful on
this till it at least links correctly on FC1.
Yes, other than the quite dated alpha's Theora is CVS. As of the last
time I built Theora (which was a while ago now) it did require you have
the nightly vorbis snapshot to add newer features which are needed for
successful Theora builds. When I get some spare time (which does happen
occasionally, but is rare at the mo) I will checkout how Theora is with
FC1 at the present time - Unless of course someone else can answer the
question? :)
Regards
Philip Wyett
--
Email: philip(a)wyett.net
Website: http://www.wyett.net
Public key: http://www.wyett.net/gpg/public_key.txt
--
2:10 a.m.
On Mon, 08 Dec 2003 18:06:24 +0000, Philip Wyett wrote:
Ooh wishlist time :)
2. Inclusion of valgrind - A very useful dev tool!
Help testing the packages published at http://rpm.livna.org
3. Inclusion of Sweep or equally good simple audio editor.
Audacity => http://fedora.us (mp3 plugin waiting in public
QA queue at rpm.livna.org)
Glame => http://rpm.livna.org
Gnusound => http://fedora.us/QA
6. Inclusion of the Anjuta IDE.
=> http://fedora.us
Whenever some popular or most wanted software isn't included with Fedora
Core, people should work together on getting good packages published in
Fedora Extras.
--
12:09 p.m.
I'd love to see comps.dtd included in the comps rpm; even nicer would
be to include in the %post scriptlet the appropriate xmlcatalog magic
to make it visible to the system.
If no one at Red Hat has actually coded up a comps.dtd, I'd be happy
to do it.
--Paul Heinlein <heinlein(a)madboa.com>
12:15 p.m.
On Mon, 2003-12-08 at 13:09, Paul Heinlein wrote:
I'd love to see comps.dtd included in the comps rpm; even nicer
would
be to include in the %post scriptlet the appropriate xmlcatalog magic
to make it visible to the system.
If no one at Red Hat has actually coded up a comps.dtd, I'd be happy
to do it.
Actually. I wrote a dtd for a comps-like list. It's something some of us
have been working on as a part of the metadata work.
-sv
12:48 p.m.
1. WorkRave (http://www.workrave.org)
"Workrave is a program that assists in the recovery and prevention of
Repetitive Strain Injury (RSI). The program frequently alerts you to
take micro-pauses, rest breaks and restricts you to your daily limit"
Copied from workrave website
I've been suffering from RSI quite badly some years ago, a.o. a program
like workrave helped me controlling the problem. I think every desktop
should include one even if it only is to prevent RSI.
2. Mozilla Firebird (My experience is also that it's already very stable)
3. Gnome 2.6
12:57 p.m.
On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
I've been suffering from RSI quite badly some years ago, a.o. a
program
like workrave helped me controlling the problem. I think every desktop
should include one even if it only is to prevent RSI.
Menu -> Preferences -> Keyboard -> Typing Break
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
1:05 p.m.
Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>I've been suffering from RSI quite badly some years ago, a.o. a program
>like workrave helped me controlling the problem. I think every desktop
>should include one even if it only is to prevent RSI.
Menu -> Preferences -> Keyboard -> Typing Break
michaelkjohnson
I know this option but it's far to simple. AFAIK it doesn't
adapt if you
take a break your self. WorkRave really measures your activity and
forces you to have small micro breaks if your mousing or typing. If you
are reading it doesn't stop you.
1:13 p.m.
Michael K. Johnson wrote:
> On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>
>> I've been suffering from RSI quite badly some years ago, a.o. a
>> program like workrave helped me controlling the problem. I think
>> every desktop should include one even if it only is to prevent RSI.
>
>
>
> Menu -> Preferences -> Keyboard -> Typing Break
>
> michaelkjohnson
I know this option but it's far to simple. AFAIK it doesn't adapt if you
take a break your self. WorkRave really measures your activity and
forces you to have small micro breaks if your mousing or typing. If you
are reading it doesn't stop you.
Forgot to mention. I think it can be a selling
point when RedHat decides
to target the corporate desktop market again, that you have advanced RSI
software included which protects their employees against RSI
1:41 p.m.
>Menu -> Preferences -> Keyboard -> Typing Break
>
>michaelkjohnson
I know this option but it's far to simple. AFAIK it doesn't adapt if you
take a break your self. WorkRave really measures your activity and
forces you to have small micro breaks if your mousing or typing. If you
are reading it doesn't stop you.
Agreed - workrave is a good tool, but it seems to suck in gnome-mm and a
pile of other stuff
4:57 a.m.
On Mon, 2003-12-08 at 20:41, Alan Cox wrote:
> I know this option but it's far to simple. AFAIK it
doesn't adapt if you
> take a break your self. WorkRave really measures your activity and
> forces you to have small micro breaks if your mousing or typing. If you
> are reading it doesn't stop you.
Agreed - workrave is a good tool, but it seems to suck in gnome-mm and a
pile of other stuff
I've been using xwrits. Is that a good alternative to workrave? I've not
given the latter a shot.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
5:11 p.m.
On Wed, Dec 17, 2003 at 11:57:37AM +0100, Colin Charles wrote:
> Agreed - workrave is a good tool, but it seems to suck in
gnome-mm and a
> pile of other stuff
I've been using xwrits. Is that a good alternative to workrave? I've not
given the latter a shot.
xwrits is to workrave what the bicycle is to the SUV. I pick SUV deliberately
for the analogy as while workrave is comfortable and full of neat features it
uses a ton of resources and libraries
8:02 p.m.
Once upon a time, Alan Cox <alan(a)redhat.com> said:
xwrits is to workrave what the bicycle is to the SUV. I pick SUV
deliberately
for the analogy as while workrave is comfortable and full of neat features it
uses a ton of resources and libraries
Does workrave also roll over and crash at the drop of a hat? :-)
--
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:42 p.m.
On Mon, Dec 08, 2003 at 08:05:56PM +0100, Jaap Haitsma wrote:
Michael K. Johnson wrote:
>On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>
>>I've been suffering from RSI quite badly some years ago, a.o. a program
>>like workrave helped me controlling the problem. I think every desktop
>>should include one even if it only is to prevent RSI.
>
>
>Menu -> Preferences -> Keyboard -> Typing Break
>
>michaelkjohnson
I know this option but it's far to simple. AFAIK it doesn't adapt if you
take a break your self. WorkRave really measures your activity and
forces you to have small micro breaks if your mousing or typing. If you
are reading it doesn't stop you.
So this, in opinion, would be a place to take up the discussion of
enhancing GNOME's included support, rather than having lots of
different tools that try, with varying amounts of success, to do
the same job.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:12 p.m.
Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 08:05:56PM +0100, Jaap Haitsma wrote:
>Michael K. Johnson wrote:
>
>>On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>>
>>
>>>I've been suffering from RSI quite badly some years ago, a.o. a program
>>>like workrave helped me controlling the problem. I think every desktop
>>>should include one even if it only is to prevent RSI.
>>
>>
>>Menu -> Preferences -> Keyboard -> Typing Break
>>
>>michaelkjohnson
>
>I know this option but it's far to simple. AFAIK it doesn't adapt if you
>take a break your self. WorkRave really measures your activity and
>forces you to have small micro breaks if your mousing or typing. If you
>are reading it doesn't stop you.
So this, in opinion, would be a place to take up the discussion of
enhancing GNOME's included support, rather than having lots of
different tools that try, with varying amounts of success, to do
the same job.
Why bother redoing so much work (unless you like getting RSI ;-) )when
there is already a good alternative, which has the advantage that you
can also use it under KDE. (OK I admit you need GTK libraries installed
for that)
What do you think of including WorkRave in Gnome 2.5 or later somewhere
down the line? There are all kind of accesibility features for people
with physical problems. I guess a good RSI program complements these
tools nicely.
Jaap
2:25 p.m.
"Michael K. Johnson" <johnsonm(a)redhat.com> writes:
On Mon, Dec 08, 2003 at 08:05:56PM +0100, Jaap Haitsma wrote:
> Michael K. Johnson wrote:
> >On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
> >
> >>I've been suffering from RSI quite badly some years ago, a.o. a program
> >>like workrave helped me controlling the problem. I think every desktop
> >>should include one even if it only is to prevent RSI.
> >
> >
> >Menu -> Preferences -> Keyboard -> Typing Break
> >
> >michaelkjohnson
> I know this option but it's far to simple. AFAIK it doesn't adapt if you
> take a break your self. WorkRave really measures your activity and
> forces you to have small micro breaks if your mousing or typing. If you
> are reading it doesn't stop you.
So this, in opinion, would be a place to take up the discussion of
enhancing GNOME's included support, rather than having lots of
different tools that try, with varying amounts of success, to do
the same job.
Workrave is more of an AT tool than the simple typing break that comes
with GNOME. I believe there was discussion of finding a way to put it
in the 'Assistive Technologies' dialog in the past -- you could look
through the desktop-devel-list(a)gnome.org and
gnome-accessibility-list(a)gnome.org archives for more information.
It might be nice to ship it for FC2 as-is anyway, but we'd have to make
sure it doesn't have weird interaction with the current typing break.
Thanks,
-Jonathan
3:24 p.m.
Jonathan Blandford wrote:
"Michael K. Johnson" <johnsonm(a)redhat.com> writes:
>On Mon, Dec 08, 2003 at 08:05:56PM +0100, Jaap Haitsma wrote:
>
>>Michael K. Johnson wrote:
>>
>>>On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>>>
>>>
>>>>I've been suffering from RSI quite badly some years ago, a.o. a
program
>>>>like workrave helped me controlling the problem. I think every desktop
>>>>should include one even if it only is to prevent RSI.
>>>
>>>
>>>Menu -> Preferences -> Keyboard -> Typing Break
>>>
>>>michaelkjohnson
>>
>>I know this option but it's far to simple. AFAIK it doesn't adapt if you
>>take a break your self. WorkRave really measures your activity and
>>forces you to have small micro breaks if your mousing or typing. If you
>>are reading it doesn't stop you.
>
>So this, in opinion, would be a place to take up the discussion of
>enhancing GNOME's included support, rather than having lots of
>different tools that try, with varying amounts of success, to do
>the same job.
Workrave is more of an AT tool than the simple typing break that comes
with GNOME. I believe there was discussion of finding a way to put it
in the 'Assistive Technologies' dialog in the past -- you could look
through the desktop-devel-list(a)gnome.org and
gnome-accessibility-list(a)gnome.org archives for more information.
It might be nice to ship it for FC2 as-is anyway, but we'd have to make
sure it doesn't have weird interaction with the current typing break.
Yes, the author of workrave told me this. In the end they didn't make it
into 2.4 because they had to have a release within a week or so and were
not able to manage that. I saw on the desktop-devel-list that they
already wanted to call Gnome 2.4 "The caring desktop". Not bad from a
marketing point I guess ;-)
Jaap
2:25 p.m.
On Mon, 8 Dec 2003, Jaap Haitsma wrote:
Michael K. Johnson wrote:
> On Mon, Dec 08, 2003 at 07:48:30PM +0100, Jaap Haitsma wrote:
>
>>I've been suffering from RSI quite badly some years ago, a.o. a program
>>like workrave helped me controlling the problem. I think every desktop
>>should include one even if it only is to prevent RSI.
>
>
> Menu -> Preferences -> Keyboard -> Typing Break
>
> michaelkjohnson
I know this option but it's far to simple. AFAIK it doesn't
adapt if you
take a break your self. WorkRave really measures your activity and
forces you to have small micro breaks if your mousing or typing. If you
are reading it doesn't stop you.
Yes, that's pretty annoying currently so I have to turn it off.
I spend half an hour resting, then come back and in the middle of
an irc chat, it shows up for rest... and insists on that...
A better solution would be nice. Perhaps we can file RFEs for
GNOME people.
behdad
3:27 a.m.
On Mon, 2003-12-08 at 19:48, Jaap Haitsma wrote:
1. WorkRave (http://www.workrave.org)
"Workrave is a program that assists in the recovery and prevention of
Repetitive Strain Injury (RSI). The program frequently alerts you to
take micro-pauses, rest breaks and restricts you to your daily limit"
Copied from workrave website
I've been suffering from RSI quite badly some years ago, a.o. a program
like workrave helped me controlling the problem. I think every desktop
should include one even if it only is to prevent RSI.
There is already an RSI app built into gnome 2.4. Check out the keyboard
preferences.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl(a)redhat.com alla(a)lysator.liu.se
He's an uncontrollable pirate ex-con on a search for his missing sister. She's
a time-travelling belly-dancing single mother from a secret island of warrior
women. They fight crime!
4:56 p.m.
Have the meta packages in the installer be available from yum, and
apt. I think that Debian calls them tasks? So we can just do an
apt-get install KDE.
--
There is no such thing as obsolete hardware.
Merely hardware that other people don't want.
(The Second Rule of Hardware Acquisition)
Sam Flory <sflory(a)rackable.com>
4:55 p.m.
On Mon, 2003-12-08 at 17:56, Samuel Flory wrote:
Have the meta packages in the installer be available from yum, and
apt. I think that Debian calls them tasks? So we can just do an
apt-get install KDE.
for repositories that have done it:
the comps.xml for fc1 can be copied to the top of the repository as
yumgroups.xml
and you can yum groupinstall "some group here"
and it will work.
-sv
12:41 a.m.
On Tue, 2003-12-09 at 00:55, seth vidal wrote:
On Mon, 2003-12-08 at 17:56, Samuel Flory wrote:
> Have the meta packages in the installer be available from yum, and
> apt. I think that Debian calls them tasks? So we can just do an
> apt-get install KDE.
for repositories that have done it:
the comps.xml for fc1 can be copied to the top of the repository as
yumgroups.xml
and you can yum groupinstall "some group here"
and it will work.
..and with apt you can use apt-groupinstall from contrib of the apt-rpm
distribution, it'll use the comps.xml from your system and then you can
say
apt-get groupinstall "some group here"
- Panu -
12:42 a.m.
..and with apt you can use apt-groupinstall from contrib of the
apt-rpm
distribution, it'll use the comps.xml from your system and then you can
say
apt-get groupinstall "some group here"
<mode oneupmanship, tongue-in-cheek>
But yum can merge the files from multiple repositories!
But we've got 11! It's one better!
</mode>
(sorry, had to do it, too late at night and too funny)
-sv
12:51 a.m.
On Tue, 2003-12-09 at 08:42, seth vidal wrote:
> ..and with apt you can use apt-groupinstall from contrib of the
apt-rpm
> distribution, it'll use the comps.xml from your system and then you can
> say
>
> apt-get groupinstall "some group here"
<mode oneupmanship, tongue-in-cheek>
But yum can merge the files from multiple repositories!
But we've got 11! It's one better!
</mode>
Well I had to leave something to add in the next version of the
Lua-thing :)
(sorry, had to do it, too late at night and too funny)
I know, hard to resist... OTOH I can do "apt-get groupremove somegroup"
:)
- Panu -
1:08 a.m.
On Tue, 2003-12-09 at 08:52, seth vidal wrote:
>
> I know, hard to resist... OTOH I can do "apt-get groupremove somegroup"
> :)
what policies for the recursive group removal and metapackages does that
follow?
Nothing currently, just the packages directly listed in a group. In fact
I just realized when replying to the "for example KDE" mail that I'm not
processing the groupreq's at all, causing
"apt-get groupinstall kde" to be an empty set, whereas it should pull in
kde-desktop and it's dependencies. Oh well, more to do for the next
version :)
I didn't implement it in yum b/c I wasn't certain which path to follow
for recursively removing group reqs
Perfectly understandable.. "apt-get -D remove" which does recursive
removal of dependencies can easily blow up in your face :(
- Panu -
7:33 a.m.
Le mar 09/12/2003 à 07:42, seth vidal a écrit :
> ..and with apt you can use apt-groupinstall from contrib of the
apt-rpm
> distribution, it'll use the comps.xml from your system and then you can
> say
>
> apt-get groupinstall "some group here"
What I'd be interested in is some standard way of distributing group
descriptors.
Build-in comps.xml is all yummy and all, but it's too static for most
usages and do not allow any customisation or extra-core packages.
Cheers,
--
Nicolas Mailhot
7:51 a.m.
On Tue, 9 Dec 2003, Nicolas Mailhot wrote:
Le mar 09/12/2003 à 07:42, seth vidal a écrit :
> > ..and with apt you can use apt-groupinstall from contrib of the apt-rpm
> > distribution, it'll use the comps.xml from your system and then you can
> > say
> >
> > apt-get groupinstall "some group here"
What I'd be interested in is some standard way of distributing group
descriptors.
Build-in comps.xml is all yummy and all, but it's too static for most
usages and do not allow any customisation or extra-core packages.
comps.xml (or very similar) is part of the common repository format
project. If you need something right now.. well, take the comps/group.xml
merge code from yum, fit into the lua-python helper and voila we have that
in apt too :)
- Panu -
8:26 a.m.
Le mar 09/12/2003 à 14:51, Panu Matilainen a écrit :
On Tue, 9 Dec 2003, Nicolas Mailhot wrote:
> Le mar 09/12/2003 à 07:42, seth vidal a écrit :
> > > ..and with apt you can use apt-groupinstall from contrib of the apt-rpm
> > > distribution, it'll use the comps.xml from your system and then you
can
> > > say
> > >
> > > apt-get groupinstall "some group here"
>
> What I'd be interested in is some standard way of distributing group
> descriptors.
>
> Build-in comps.xml is all yummy and all, but it's too static for most
> usages and do not allow any customisation or extra-core packages.
comps.xml (or very similar) is part of the common repository format
project. If you need something right now.. well, take the comps/group.xml
merge code from yum, fit into the lua-python helper and voila we have that
in apt too :)
Well, I was thinking more about kickstart-like custom comps.xml bits.
Though having it in the repository metadata would help a lot too.
Anyway, I'm not complaining, just stating wishes like everyone here.
Take whatever time you need to get something you like;)
--
Nicolas Mailhot
2:17 p.m.
On Tue, Dec 09, 2003 at 01:42:49AM -0500, seth vidal wrote:
> ..and with apt you can use apt-groupinstall from contrib of the
apt-rpm
> distribution, it'll use the comps.xml from your system and then you can
> say
>
> apt-get groupinstall "some group here"
<mode oneupmanship, tongue-in-cheek>
But yum can merge the files from multiple repositories!
But we've got 11! It's one better!
</mode>
(sorry, had to do it, too late at night and too funny)
fwiw, up2date can do this now as well. (based heavily
on the yum code...). defaults to the system comps file, config
option to add others.
circa up2date-4.3.2 or so...
Adrian
6:03 p.m.
2.6 is looking good. There's a lot of integration work to do,
though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Some stuff that comes to mind:
- ALSA configurator (most probably a given if FC2 uses kernel 2.6.x)
- ALSA configurator that can deal with more than one card and with USB
audio and midi devices.
- apt database (and yum if it is not already there) in the install
cdrom's so that they can be fed to apt-cdrom.
If ALSA is included and configurable a bunch of useful audio stuff could
be merged in from Planet CCRMA[*] (the site I mantain).
Too bad that 2.6.x will not include the preemptible kernel feature
activated (saw this on another thread), I was hoping to not have to
provide custom kernels anymore :-(
-- Fernando
[*] http://www-ccrma.stanford.edu/planetccrma/software/
10:36 p.m.
Fernando Pablo Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) said:
Some stuff that comes to mind:
- ALSA configurator (most probably a given if FC2 uses kernel 2.6.x)
For basic stuff, I'm certainly of the opinion that you shouldn't
have a configuration program. One card should just work, for
any modern hardware.
Bill
11:49 p.m.
Bill Nottingham wrote:
Fernando Pablo Lopez-Lezcano (nando(a)ccrma.Stanford.EDU) said:
>Some stuff that comes to mind:
>
>- ALSA configurator (most probably a given if FC2 uses kernel 2.6.x)
For basic stuff, I'm certainly of the opinion that you shouldn't
have a configuration program. One card should just work, for
any modern hardware.
Bill
Regarding ALSA, please see fedora.us QA queue. The alsa-* packages have
gone through many revisions.
Warren
2:30 a.m.
New subject: Fedora Core 2 wishlists [ALSA]
On Mon, 08 Dec 2003 19:49:31 -1000, Warren Togami wrote:
Regarding ALSA, please see fedora.us QA queue. The alsa-* packages
have
gone through many revisions.
alsa-lib, alsa-utils, alsa-oss have my publish vote already, all are
version 1.0.0 rc2 and work great with Fedora Core 1:
alsa-lib: https://bugzilla.fedora.us/show_bug.cgi?id=590
alsa-utils: https://bugzilla.fedora.us/show_bug.cgi?id=591
alsa-oss: https://bugzilla.fedora.us/show_bug.cgi?id=592
alsa-driver builds fine and works for me, but doesn't adhere to the
fedora.us package naming guidelines. I'd really appreciate additional
comments on this. In particular, from the fedora.us guys who created C.5
and whether to put the UP and SMP modules into a single package.
Since Thorsten Leemhuis took over the ALSA packages at fedora.us, ALSA is
my primary sound system with Fedora Core 1.
--
6:03 p.m.
On 2003-12-08 at 10:15:30-0500 "Michael K. Johnson" <johnsonm(a)redhat.com>
wrote:
I'd like to hear people's wishlists.
Encrypted loopback support out-of-the-box.
http://www.pobox.com/~ralston/dev/
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=56698
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=111536
(I'd also like to see support for all common SATA chipsets, native
x86_64 support, etc., but those are things that people already know
about.)
--
James Ralston, Information Technology
Software Engineering Institute
Carnegie Mellon University, Pittsburgh, PA, USA
7:56 p.m.
On Tue, Dec 09, 2003 at 01:14:54AM +0100, Xose Vazquez Perez wrote:
James Ralston wrote:
> (I'd also like to see support for all common SATA chipsets, native
SATA is already supported in RHEL 3, and in kernel 2.6 too.
Actually 2.6 appears to be missing the mmio mapping fixes so 2.6 doesnt
support as much SATA as 2.4 right now
6:24 p.m.
Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Xose's wishes list. All for this year ;-)
o SPAM and virus are blight, spamassassin is a good tool to combat
spam, but it is necessary a filter like mailscanner, or amavis or...
to get a good mta/antivirus integration.
o more feature rich POP3 server, like popa3d, solid-pop3d,
tpop3d, cucipop, teapop, cyrus ...
o replacement for cpio. afio is a better and more secure 'cpio':
- makes cpio-format archives
- It deals somewhat gracefully with input data corruption
- supports multi-volume archives during interactive operation
- can make compressed archives that are much safer than compressed
tar or cpio archives.
- provides more diverse magnetic tape options
o I know that there is a lot of text processors in fedora, but LyX is
WYSIWYM document processor, and now it has a qt interface.
o lighter web server. Apache is too big for basic web services.
Candidates : mathopd, thttpd, boa, fnord, ...
o a better syslog. syslog-ng has more options. It adds the possibility
to filter based on message contents using regular expressions. It's
more flexible, more secure and has better support for transport
logs through the net.
o lighter dns server, bind is too big for basic dns services.
Candidates: http://maradns.org http://powerdns.com ...
o A good network monitoring program:
http://www.nagios.org http://www.opennms.org http://bb4.com
o more _user_ frienly apps. Multimedia apps: to watch TV, sound
systems..., more and better graphics tools...
http://www.suse.com/us/private/products/suse_linux/i386/graphics.html
http://www.suse.com/us/private/products/suse_linux/i386/multimedia.html
o There is no test suite like SUNvts http://www.sun.com/oem/products/vts/
to test hardware.
Candidates:
- cpuburn, for CPU, cooling system, motherboard(especially
voltage regulators) and power supply.
- cts_cerberus/memtst for memory
- netpipe for NET http://www.scl.ameslab.gov/netpipe/
- dt, scu, sg utils for SCSI
- http://linux-diag.sourceforge.net
- fs stress tests
- ....
o more security oriented distribution with john, snort... and
Bastille Hardening System.
Daemons must not put version and/or name in their banner and they
don't run by default(chkconfig off)
o Supporat to files bigger than 2G in _all_ programs:
http://freshmeat.net/articles/view/709
o live updated with yum, with the system up and runnig(without boot
from CD/NET... and without run anaconda)
o really a minimal installation, there are too much packages in
the minimal installation and it takes a lot of space 490MB(rhl_9).
And with the possibility of don't install documentation with the
rpm option "--excludedocs"
o and the last, to send feedback/patches to *original sofware writers*.
It's very annoying to see that a bug was corrected in rh but the
upstream version still has the bug in newer releases.
# EOF
7:25 p.m.
Xose Vazquez Perez wrote:
Michael K. Johnson wrote:
>However, that won't be the ONLY feature of Fedora Core 2. I'd like to
>hear people's wishlists. Not everything will be possible, but it would
>be nice to have a good list from which to pick the possibilities, and
>from which to also pick ideas later for Fedora Core 3.
Xose's wishes list. All for this year ;-)
o SPAM and virus are blight, spamassassin is a good tool to combat
spam, but it is necessary a filter like mailscanner, or amavis or...
to get a good mta/antivirus integration.
While on this topic, the three augmenting tools of spamassassin that
would be really useful too:
* dccproc
* perl-Razor-Spamassassin
* pyzor
All three are as simple as installing a single package, and without
configuration they improve your spamasssassin accuracy
pyzor has been published at fedora.us for a long time, while
perl-Razor-Spamassassin is in QA. dcc is a bit difficult to package
properly...
Warren
7:46 p.m.
On Mon, 2003-12-08 at 17:25, Warren Togami wrote:
dcc is a bit difficult to package
properly...
Is it? I've got a DCC RPM I built for 7.3 that I'm pretty sure comes
right from their web site... Maybe there's something improper about it,
but it Works For Me.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * Linux Services for Small Businesses * * * * * *
* Easy, reliable solutions for small businesses *
* Naked Ape Business Server http://nakedape.cc/r/sms *
7:58 p.m.
Wil Cooley wrote:
On Mon, 2003-12-08 at 17:25, Warren Togami wrote:
>dcc is a bit difficult to package
>properly...
Is it? I've got a DCC RPM I built for 7.3 that I'm pretty sure comes
right from their web site... Maybe there's something improper about it,
but it Works For Me.
Wil
Last I tried their package, it only builds as root. Has that changed?
Warren
9:12 p.m.
On Mon, 2003-12-08 at 17:58, Warren Togami wrote:
Last I tried their package, it only builds as root. Has that
changed?
I just rebuilt the SRPM I have for 1.1.43 as non-root, so it appears to
have changed.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
7:38 a.m.
Le mar 09/12/2003 à 01:24, Xose Vazquez Perez a écrit :
Xose's wishes list. All for this year ;-)
+1
o more security oriented distribution with john, snort... and
Bastille Hardening System.
+1
--
Nicolas Mailhot
9:09 a.m.
On Tue, 2003-12-09 at 08:38, Nicolas Mailhot wrote:
Le mar 09/12/2003 à 01:24, Xose Vazquez Perez a écrit :
> Xose's wishes list. All for this year ;-)
> o A good network monitoring program:
> http://www.nagios.org http://www.opennms.org http://bb4.com
Just to pipe in, I'm the packager for nagios and the lead developer and
packager for plugins that run the actual tests. I'd be more than happy
to closely target development for Fedora, but personally I tend to agree
that it is more of an extras thing.
Also, while the plugins in alpha have been updated to use gettext, no
translations have yet been done. And nagios itself has not really been
internationalizied at all yet, AFAIK. So the FC2 time table might not be
ideal for inclusion of nagios either. FC3 might be better.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
Pearson Education/Information Please
10:34 a.m.
Karl DeBisschop wrote:
On Tue, 2003-12-09 at 08:38, Nicolas Mailhot wrote:
>Le mar 09/12/2003 à 01:24, Xose Vazquez Perez a écrit :
>
>
>>Xose's wishes list. All for this year ;-)
>
>> o A good network monitoring program:
>> http://www.nagios.org http://www.opennms.org http://bb4.com
Just to pipe in, I'm the packager for nagios and the lead developer and
packager for plugins that run the actual tests. I'd be more than happy
to closely target development for Fedora, but personally I tend to agree
that it is more of an extras thing.
Also, while the plugins in alpha have been updated to use gettext, no
translations have yet been done. And nagios itself has not really been
internationalizied at all yet, AFAIK. So the FC2 time table might not be
ideal for inclusion of nagios either. FC3 might be better.
nagios used by sysadm and not the endusers and they usualy don't need
i18zed version.
ps. is there any chance to open the extras and alternatives directory in
the near future?
--
Levente "Si vis pacem para bellum!"
3:03 p.m.
Le mar 09/12/2003 à 17:34, Farkas Levente a écrit :
nagios used by sysadm and not the endusers and they usualy don't
need
i18zed version.
Please don't. The sysadm likes a nice localized app as much as anyone
else. The argument "the sysadm can eat howtos and untranslated apps" is
very flawed.
Plus the nagios status board is a great way to impress management,
having it untranslated is not yummy at all.
--
Nicolas Mailhot
4:41 p.m.
On Tue, Dec 09, 2003 at 05:34:53PM +0100, Farkas Levente wrote:
>Also, while the plugins in alpha have been updated to use
gettext, no
>translations have yet been done. And nagios itself has not really been
>internationalizied at all yet, AFAIK. So the FC2 time table might not be
>ideal for inclusion of nagios either. FC3 might be better.
nagios used by sysadm and not the endusers and they usualy don't need
i18zed version.
Really. Thats not what statistics on sysadmin languages spoke worldwide
says.
8 a.m.
On Tue, 9 Dec 2003, Xose Vazquez Perez wrote:
o SPAM and virus are blight, spamassassin is a good tool to combat
spam, but it is necessary a filter like mailscanner, or amavis or...
to get a good mta/antivirus integration.
pointless w/o clamav (which is includable, but probably better Extras for
now)
o a better syslog. syslog-ng has more options. It adds the
possibility
to filter based on message contents using regular expressions. It's
more flexible, more secure and has better support for transport
logs through the net.
SDSC Syslog is another option, and has more interesting features
later,
chris
8:12 a.m.
On Tue, 2003-12-09 at 07:00, Chris Ricker wrote:
On Tue, 9 Dec 2003, Xose Vazquez Perez wrote:
> o SPAM and virus are blight, spamassassin is a good tool to combat
> spam, but it is necessary a filter like mailscanner, or amavis or...
> to get a good mta/antivirus integration.
pointless w/o clamav (which is includable, but probably better Extras for
now)
I would like to have a nice mix of mimedefang, spamassassin, clamav, and
some sort of script set that downloads RBL's for local use. I have a
couple already done.. but dont know about the RBL yet.
> o a better syslog. syslog-ng has more options. It adds the possibility
> to filter based on message contents using regular expressions. It's
> more flexible, more secure and has better support for transport
> logs through the net.
SDSC Syslog is another option, and has more interesting features
Hmm never heard of it.. what is its comparison points?
later,
chris
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
10:44 a.m.
On Tue, 9 Dec 2003, Stephen Smoogen wrote:
> SDSC Syslog is another option, and has more interesting
features
>
Hmm never heard of it.. what is its comparison points?
<http://security.sdsc.edu/software/sdsc-syslog/>
I'm not claiming it's ready for inclusion (I don't think it is, except in
Extras perhaps), but it implements RFC 3195 (secure TCP delivery --
syslog-ng does kinda the same thing but AFAIK it's an ad-hoc
implementation), is high-performance, etc.
later,
chris
9:28 a.m.
On Tuesday 09 December 2003 09:00 am, Chris Ricker wrote:
On Tue, 9 Dec 2003, Xose Vazquez Perez wrote:
> o SPAM and virus are blight, spamassassin is a good tool to combat
> spam, but it is necessary a filter like mailscanner, or amavis or...
> to get a good mta/antivirus integration.
pointless w/o clamav (which is includable, but probably better Extras
for
now)
MailScanner can strip executables easily, doing basically everything
MIMEdefang does and then some. I found the installation extremely easy, even
on an Aurora 1.0 SPARC box. It does, however, override the default sendmail
initscript, and starts both itself and sendmail in one initscript. This
might be a minor stumblingblock. The way it's installer is distributed is
alos not the Regular Way, being a tarball of source RPMs of a bunch of perl
modules, an installer script (which rebuilds all of the Perl RPMs from source
RPM, to get everything in the right place), and a binary RPM of the tnef
code. I had to track down and rebuild the tnef RPM for my SPARC box, but
intel users don't have that problem.
ClamAV is a nice addition to MailScanner, but 99% of e-mailed viruses are in
executable attachments, which doesn't require an AV scanner to strip, which
lessens the load on the mailserver.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
10:12 a.m.
On Tue, Dec 09, 2003 at 10:28:05AM -0500, Lamar Owen wrote:
MailScanner can strip executables easily, doing basically everything
MIMEdefang does and then some. I found the installation extremely easy, even
on an Aurora 1.0 SPARC box. It does, however, override the default sendmail
initscript, and starts both itself and sendmail in one initscript. This
So every time you upgrade sendmail, your MailScanner config is hosed?
Ick! Or do they use triggers? (worse)
might be a minor stumblingblock.
Well, it would certainly need to be fixed.
The way it's installer is distributed is
alos not the Regular Way, being a tarball of source RPMs of a bunch of perl
modules, an installer script (which rebuilds all of the Perl RPMs from source
RPM, to get everything in the right place), and a binary RPM of the tnef
code. I had to track down and rebuild the tnef RPM for my SPARC box, but
intel users don't have that problem.
That would all have to be regularized, which shouldn't be a big deal,
if the whole point of that mess is to adapt it to the installation
environment. If that environment becomes a constant, then that whole
rigamarole isn't useful.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
10:41 a.m.
On Tue, 2003-12-09 at 09:12, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 10:28:05AM -0500, Lamar Owen wrote:
> MailScanner can strip executables easily, doing basically everything
> MIMEdefang does and then some. I found the installation extremely easy, even
> on an Aurora 1.0 SPARC box. It does, however, override the default sendmail
> initscript, and starts both itself and sendmail in one initscript. This
So every time you upgrade sendmail, your MailScanner config is hosed?
Ick! Or do they use triggers? (worse)
I have a hard time believing it does everything MD does and then some..
I mean they are both perl so you can do pretty much any kitchen sink
item. Having worked with another virus scanner that does the replacement
of sendmail scripts.. I know the pain of breaking on an upgrade. I would
prefer something completely different.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
10:51 a.m.
On Tuesday 09 December 2003 11:12 am, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 10:28:05AM -0500, Lamar Owen wrote:
> [MailScanner] does, however, override the default
> sendmail initscript, and starts both itself and sendmail in one
> initscript. This
So every time you upgrade sendmail, your MailScanner config is
hosed?
Ick! Or do they use triggers? (worse)
Neither. They are MTA-agnostic, and allow you to config which MTA you use in
a /etc/sysconfig/MailScanner configuration file. The startup for sendmail
runs newaliases and a make pass through /etc/mail for you, then starts the
incoming and outgoing sendmails. I could post their initscript if you would
like, although it's available on the mailscanner website
(www.mailscanner.info)
> might be a minor stumblingblock.
Well, it would certainly need to be fixed.
Since the newer sendmail initscripts start both sendmail and sm-client, this
may be more fixable. But they do not have you edit any sendmail config files
at all. The installation worked on my Fedora Core laptop as well and as
smoothly as it did on the Aurora box which has a substantially earlier
sendmail on it, so I don't think a sendmail upgrade would cause a problem.
Looking over the MailScanner initscript, it doesn't appear to be a problem.
> The way it's installer is distributed is
> alos not the Regular Way, being a tarball of source RPMs of a bunch of
That would all have to be regularized, which shouldn't be a big
deal,
if the whole point of that mess is to adapt it to the installation
environment. If that environment becomes a constant, then that whole
rigamarole isn't useful.
It seems to just be a rebuild of the perl modules for your particular version
of perl. The rebuild worked fine on the SPARC (as long as I remembered to
execute it with sparc32, that is: without the sparc32 invocation, there was a
perl module went bellyup during the build, but that again doesn't cause a
problem with intel users), and it worked fine on my Fedora laptop. It does
require some non-standard perl modules, but it is intelligent enough to check
for modules that the base OS already has installed.
The modules it wants (and bundles as either source RPMS or, in one case, as a
tarball)
perl-IO-stringy-2.108-1.src.rpm
perl-MailTools-1.50-1.src.rpm
ExtUtils-MakeMaker-6.05.tar.gz
perl-MIME-Base64-2.12-1.src.rpm
perl-MIME-tools-5.411-pl4.2.src.rpm
mailscanner-4.25-14.noarch.rpm
perl-Net-CIDR-0.08-2.src.rpm
perl-Convert-TNEF-0.17-1.src.rpm
perl-TimeDate-1.1301-2.src.rpm
perl-File-Spec-0.82-1.src.rpm
perl-File-Temp-0.12-1.src.rpm
perl-HTML-Parser-3.26-2.src.rpm
perl-HTML-Tagset-3.03-1.src.rpm
It includes the requisite tnef-1.1.4+sizelimit binary rpm, which I had to hunt
down and rebuild for sparc.
The install.sh script even went as far as testing for the required MakeMaker
version and updating it if the installed version was not high enough.
A similar wrapper for MIMEdefang would be welcome, since it's not the most
straightforward installation.
The key things I found with MailScanner that were attractive to me was simply
that it doesn't require milter, and it doesn't require procmail, nor does it
require any change to any sendmail config. With the older version of
sendmail on the SPARC box (Aurora is, after all, based on Red Hat 7.3), I
wasn't terribly excited about rebuilding a gaggle of things that would break
the next time I did an up2date (which on Aurora accesses a current server for
the Aurora project), or when I update to the next version of Aurora (which
will be Fedora Core based).
It does need an installed SpamAssassin (I have 2.55 on my SPARC box) and
optionally an installed antivirus (it works with several packages, including
the commercial Sophos, which I use at another site on RHL 8.0, and the OS
ClamAV).
YMMV of course, since this is what I liked and it works for me in my
particular instance... :-) (then again, I don't use Apache as my standard web
server; I use AOLserver, which I've used and grown a codebase for for over 6
years).
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
7:53 p.m.
On Tue, 9 Dec 2003, Michael K. Johnson wrote:
So every time you upgrade sendmail, your MailScanner config is hosed?
Ick! Or do they use triggers? (worse)
Thats not been my experience.
It leaves Sendmail config alone. It just runs 2 copies, one with a couple
of command line options, to seperate in and out queues.
You may need to turn off the init script though.
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: raven(a)themaw.net
v Web: http://themaw.net/
10:45 a.m.
On Tue, 9 Dec 2003, Lamar Owen wrote:
On Tuesday 09 December 2003 09:00 am, Chris Ricker wrote:
> On Tue, 9 Dec 2003, Xose Vazquez Perez wrote:
> > o SPAM and virus are blight, spamassassin is a good tool to combat
> > spam, but it is necessary a filter like mailscanner, or amavis or...
> > to get a good mta/antivirus integration.
> pointless w/o clamav (which is includable, but probably better Extras for
> now)
MailScanner can strip executables easily, doing basically everything
MIMEdefang does and then some. I found the installation extremely easy, even
on an Aurora 1.0 SPARC box. It does, however, override the default sendmail
initscript, and starts both itself and sendmail in one initscript. This
might be a minor stumblingblock. The way it's installer is distributed is
alos not the Regular Way, being a tarball of source RPMs of a bunch of perl
modules, an installer script (which rebuilds all of the Perl RPMs from source
RPM, to get everything in the right place), and a binary RPM of the tnef
code. I had to track down and rebuild the tnef RPM for my SPARC box, but
intel users don't have that problem.
ClamAV is a nice addition to MailScanner, but 99% of e-mailed viruses are in
executable attachments, which doesn't require an AV scanner to strip, which
lessens the load on the mailserver.
I was referring more to amavis, which is only useful to include if you
include something for it to hook to (clamav, mimedefang, spamassassin, etc)
Mailscanner isn't includable for other reasons. For starters, it's not
usable with Postfix -- it directly grabs mail in the queue, which Postfix
forbids. Wietse doesn't support and frequently warns people not to use it
b/c it eats email, etc.
later,
chris
11 a.m.
On Tuesday 09 December 2003 11:45 am, Chris Ricker wrote:
Mailscanner isn't includable for other reasons. For starters,
it's not
usable with Postfix -- it directly grabs mail in the queue, which Postfix
forbids. Wietse doesn't support and frequently warns people not to use it
b/c it eats email, etc.
Is this true with the current version 4.25? As I use sendmail and not
postfix, this doesn't bother me anyway. Just addressing the comment made;
not saying the MailScanner is worthy of inclusion in FC, as it has quirks
that may preclude its inclusion. But all software has quirks, some more
quirky and others.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
11:20 a.m.
On Tue, 9 Dec 2003, Lamar Owen wrote:
On Tuesday 09 December 2003 11:45 am, Chris Ricker wrote:
> Mailscanner isn't includable for other reasons. For starters, it's not
> usable with Postfix -- it directly grabs mail in the queue, which Postfix
> forbids. Wietse doesn't support and frequently warns people not to use it
> b/c it eats email, etc.
Is this true with the current version 4.25? As I use sendmail and not
postfix, this doesn't bother me anyway.
Yes. I wouldn't be surprised if it could also lose mail under some
circumstances with sendmail. The milter interface is there for a reason ;-)
Just addressing the comment made; not saying the MailScanner is
worthy
of inclusion in FC, as it has quirks that may preclude its inclusion.
But all software has quirks, some more quirky and others.
IMO, mimedefang would be a better choice of the two to include, as it does
work with postfix and sendmail, and uses their defined interfaces for
hooking in. Now that exim's included I suppose software should be chosen
which works with it as well -- don't know about it and mimedefang
later,
chris
11:43 a.m.
On Tuesday 09 December 2003 12:20 pm, Chris Ricker wrote:
Yes. I wouldn't be surprised if it could also lose mail under
some
circumstances with sendmail. The milter interface is there for a reason
;-)
Well, like I said, I haven't had any problems as yet. The portability of
milter might be an issue for some, in that the MTA has to support it. Then
there's the issue of versions. I guess i could rebuild the latest sendmail,
but it's not something I relish.
IMO, mimedefang would be a better choice of the two to include, as it
does
work with postfix and sendmail, and uses their defined interfaces for
hooking in. Now that exim's included I suppose software should be chosen
which works with it as well -- don't know about it and mimedefang
FWIW, MailScanner advertises Postfix, Exim, ZMailer, and Sendmail
compatibility.
But if there were a good installation wrapper for MIMEdefang and my older
sendmail on my SPARC box then I wouldn't have a problem switching over, if
the features are worth it. I have found MailScanner to be quite flexible in
its configuration, thus far. Time will tell.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
12:33 p.m.
Xose Vazquez Perez wrote:
... a better syslog. syslog-ng has more options. It adds the
possibility
to filter based on message contents using regular expressions. It's
more flexible, more secure and has better support for transport
logs through the net.
or msyslog ( http://www.coresecurity.com/corelabs/freesoft/ )
Ricardo.-
6:25 p.m.
Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Xose's wishes list. All for this year ;-)
here goes:
o SPAM and virus are blight, spamassassin is a good tool to combat
spam, but it is necessary a filter like mailscanner, or amavis or...
to get a good mta/antivirus integration.
o more feature rich POP3 server, like popa3d, solid-pop3d,
tpop3d, cucipop, teapop, cyrus ...
o replacement for cpio. afio is a better and more secure 'cpio':
- makes cpio-format archives
- It deals somewhat gracefully with input data corruption
- supports multi-volume archives during interactive operation
- can make compressed archives that are much safer than compressed
tar or cpio archives.
- provides more diverse magnetic tape options
o I know that there is a lot of text processors in fedora, but LyX is
WYSIWYM document processor, and now it has a qt interface.
o lighter web server. Apache is too big for basic web services.
Candidates : mathopd, thttpd, boa, fnord, ...
o a better syslog. syslog-ng has more options. It adds the possibility
to filter based on message contents using regular expressions. It's
more flexible, more secure and has better support for transport
logs through the net.
o lighter dns server, bind is too big for basic dns services.
Candidates: http://maradns.org http://powerdns.com ...
o A good network monitoring program:
http://www.nagios.org http://www.opennms.org http://bb4.com
o more _user_ frienly apps. Multimedia apps: to watch TV, sound
systems..., more and better graphics tools...
http://www.suse.com/us/private/products/suse_linux/i386/graphics.html
http://www.suse.com/us/private/products/suse_linux/i386/multimedia.html
o There is no test suite like SUNvts http://www.sun.com/oem/products/vts/
to test hardware.
Candidates:
- cpuburn, for CPU, cooling system, motherboard(especially
voltage regulators) and power supply.
- cts_cerberus/memtst for memory
- netpipe for NET http://www.scl.ameslab.gov/netpipe/
- dt, scu, sg utils for SCSI
- http://linux-diag.sourceforge.net
- fs stress tests
- ....
o more security oriented distribution with john, snort... and
Bastille Hardening System.
Daemons must not put version and/or name in their banner and they
don't run by default(chkconfig off)
o Supporat to files bigger than 2G in _all_ programs:
http://freshmeat.net/articles/view/709
o live updated with yum, with the system up and runnig(without boot
from CD/NET... and without run anaconda)
o really a minimal installation, there are too much packages in
the minimal installation and it takes a lot of space 490MB(rhl_9).
And with the possibility of don't install documentation with the
rpm option "--excludedocs"
o and the last, to send feedback/patches to *original sofware writers*.
It's very annoying to see that a bug was corrected in rh but the
upstream version still has the bug in newer releases.
# EOXWL
-thanks-
6:42 p.m.
On Mon, 2003-12-08 at 16:25, Xose Vazquez Perez wrote:
o SPAM and virus are blight, spamassassin is a good tool to combat
spam, but it is necessary a filter like mailscanner, or amavis or...
to get a good mta/antivirus integration.
I have kind of a half-assed package of amavisd-new; it's not exactly
easy to set up and there are lots of knobs for various things, but it
does work with both Postfix and Sendmail (I think it works with Exim
too, now that that's included).
o more feature rich POP3 server, like popa3d, solid-pop3d,
tpop3d, cucipop, teapop, cyrus ...
Cyrus and Dovecot seem to be rawhide; both support POP in addition to
IMAP, IIRC.
o lighter web server. Apache is too big for basic web services.
Candidates : mathopd, thttpd, boa, fnord, ...
I don't know how much of a necessity there is for other web servers;
Apache can be big but it's also modular; it's not terribly resource
hungry for serving static pages.
Nagios is about the only viable option here; OpenNMS requires Java and
Big Brother is not free software, AFAICT. I looked at MIDAS the other
night and while it shows promise, I don't know if it's usable, since the
docs are a little thin and I wasn't able to get it working after several
hours. That said, Nagios might be a better candidate for Extras, since
it's not useful for a lot of installations, although for a monitoring
host it's invaluable. It would also be nice to have a variety of
network stats-tracking (SNMP) in Extras too.
o There is no test suite like SUNvts
http://www.sun.com/oem/products/vts/
to test hardware.
Candidates:
- cpuburn, for CPU, cooling system, motherboard(especially
voltage regulators) and power supply.
- cts_cerberus/memtst for memory
- netpipe for NET http://www.scl.ameslab.gov/netpipe/
- dt, scu, sg utils for SCSI
- http://linux-diag.sourceforge.net
- fs stress tests
- ....
Definitely.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
6:46 p.m.
----- Original Message -----
From: "Xose Vazquez Perez" <xose(a)wanadoo.es>
To: <fedora-devel-list(a)redhat.com>
Sent: Monday, December 08, 2003 4:25 PM
Subject: Re: Fedora Core 2 wishlists
o lighter web server. Apache is too big for basic web services.
Candidates : mathopd, thttpd, boa, fnord, ...
This gets my vote as well, with the qualification that the basic web
server needs to be an option, not a replacement for Apache.
o a better syslog. syslog-ng has more options. It adds the
possibility
to filter based on message contents using regular expressions. It's
more flexible, more secure and has better support for transport
logs through the net.
+1
o lighter dns server, bind is too big for basic dns services.
Candidates: http://maradns.org http://powerdns.com ...
See note for Apache...
We use Nagios here with much success...the only downside is that it can
be a bit difficult to setup the first time. A nice web configuration
interface wouldn't go amiss (One of these days, I might actually write
one...)
o really a minimal installation, there are too much packages in
the minimal installation and it takes a lot of space 490MB(rhl_9).
And with the possibility of don't install documentation with the
rpm option "--excludedocs"
+1
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
8:01 p.m.
On Tue, Dec 09, 2003 at 01:25:27AM +0100, Xose Vazquez Perez wrote:
Candidates:
- cpuburn, for CPU, cooling system, motherboard(especially
voltage regulators) and power supply.
- cts_cerberus/memtst for memory
- netpipe for NET http://www.scl.ameslab.gov/netpipe/
- dt, scu, sg utils for SCSI
- http://linux-diag.sourceforge.net
- fs stress tests
- ....
Interesting idea, because it would help beta QA and the kit for this
needless to say does get run inhouse by Red Hat.
o and the last, to send feedback/patches to *original sofware
writers*.
It's very annoying to see that a bug was corrected in rh but the
upstream version still has the bug in newer releases.
Its always been Red Hat policy to do so, sometimes they won't take them,
some times they play dead, sometimes they get lost.
8:06 p.m.
Xose Vazquez Perez wrote:
o and the last, to send feedback/patches to *original sofware
writers*.
It's very annoying to see that a bug was corrected in rh but the
upstream version still has the bug in newer releases.
# EOXWL
I fotgot:
o 2.4 kernel as backup
o a _mininal_ window manager, some times in servers it's necessary to
run X and kde or gnome environments are too much big and heavy.
IMO Window Maker is the natural selection, it was latest WM to be
deleted from the distribution, is stable, fast, light, and is
compatible with mottif, qt and gtk apps.
8:06 p.m.
I fotgot:
o 2.4 kernel as backup
no.
This has been discussed, a lot, on this list, it's either one kernel or
the other, not both.
o a _mininal_ window manager, some times in servers it's
necessary to
run X and kde or gnome environments are too much big and heavy.
IMO Window Maker is the natural selection, it was latest WM to be
deleted from the distribution, is stable, fast, light, and is
compatible with mottif, qt and gtk apps.
what's wrong with twm for this?
-sv
8:15 p.m.
seth vidal wrote:
>o 2.4 kernel as backup
no.
This has been discussed, a lot, on this list, it's either one kernel or
the other, not both.
I know it, one try more it doesn't hurt nobody ;-)
what's wrong with twm for this?
well, twm is very spartan. Thisisnota Window Manager :-)
4:08 p.m.
> o a _mininal_ window manager, some times in servers it's
necessary to
> run X and kde or gnome environments are too much big and heavy.
> IMO Window Maker is the natural selection, it was latest WM to be
> deleted from the distribution, is stable, fast, light, and is
> compatible with mottif, qt and gtk apps.
what's wrong with twm for this?
It uses a lot of memory and it doesnt support all the motif and
other hints.
Alan
7:35 a.m.
On Mon, Dec 08, 2003 at 06:31:13PM -1000, Warren Togami wrote:
Good idea. This is especially important because of the critical
drivers
that are not yet ported to 2.6 kernel... for example dpt_i2o SCSI RAID.
There are several months for them to be ported. If no one cares enough
to port them, well, that's an indicator that they aren't critical.
Really, trying to do backup kernels is a bad idea. It messes up
testing, it duplicates lots of effort, it wastes space.
Are we have 6 ISO's for this release yet? =)
6 DVD ISOs, man, get with the program! ;-)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:54 a.m.
Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 06:31:13PM -1000, Warren Togami wrote:
>Good idea. This is especially important because of the critical
drivers
>that are not yet ported to 2.6 kernel... for example dpt_i2o SCSI RAID.
There are several months for them to be ported. If no one cares
enough
to port them, well, that's an indicator that they aren't critical.
False. If nobody cares for it means that no _developer_ cares for it.
Today nodody cares for aacraid in 2.4 kernel and this's a *critical driver*.
And there are more SCSI drivers in the same situation that aacraid.
Really, trying to do backup kernels is a bad idea. It messes up
testing, it duplicates lots of effort, it wastes space.
Really to run an incomplete kernel is a bad idea ;-).
4:45 p.m.
On Tue, Dec 09, 2003 at 06:54:27PM +0100, Xose Vazquez Perez wrote:
Today nodody cares for aacraid in 2.4 kernel and this's a
*critical driver*.
And there are more SCSI drivers in the same situation that aacraid.
Adaptec has Mark assigned to work on aacraid part time. But don't expect
anything for 2.6 until 2.6 is out and a bit more stable. Thats been a general
vendor reaction unfortunately.
I normally also do bits on aacraid but I'm doing an MBA right now so its
just a fraction of Mark's time, and the truth is nobody is asking Adaptec
for 2.6 support yet and won't until 2.6 is in the deployment radar of
people like Dell.
Alan
5:29 p.m.
New subject: linux devel [was Re: Fedora Core 2 wishlists]
Alan Cox wrote:
Adaptec has Mark assigned to work on aacraid part time. But don't
expect
anything for 2.6 until 2.6 is out and a bit more stable. Thats been a general
vendor reaction unfortunately.
I normally also do bits on aacraid but I'm doing an MBA right now
so its
just a fraction of Mark's time, and the truth is nobody is asking Adaptec
for 2.6 support yet and won't until 2.6 is in the deployment radar of
people like Dell.
Yes, and he is also responsible for dpt_i2o driver.
After you left the kernel development, nobody worried to include latest aacraid
patches in 2.4, yes 2.4!! But for 2.6 inclusion the responsible of it is
Mark Haverkamp <markh(a)osdl.org>.
aacraid was an example, but there are more drivers in the same situation. Mainly
SCSI, IMO the most critical out there (NET drivers are _very_ well maintained).
HW companies work in the 'tradicional way': they write drivers, then it pass
to control quality team and later they put it on a web page for rh_YY, suse_XX...
And it never reaches linux-ZZ-ml. Only if a hacker worry by it, it's included
into the kernel.
This is a real cut of some thoughts of HW vendors:
"Incorporation into the tree can not be performed as no one is designated as
the gatekeeper. We do have a designated gatekeeper for the XXXXXX driver,
which is kept relatively up-to-date in the 2.6 tree."
annoying.
6:35 p.m.
New subject: linux devel [was Re: Fedora Core 2 wishlists]
On Wed, Dec 10, 2003 at 12:29:53AM +0100, Xose Vazquez Perez wrote:
Yes, and he is also responsible for dpt_i2o driver.
After you left the kernel development, nobody worried to include latest aacraid
patches in 2.4, yes 2.4!! But for 2.6 inclusion the responsible of it is
Mark Haverkamp <markh(a)osdl.org>.
aacraid was an example, but there are more drivers in the same situation. Mainly
SCSI, IMO the most critical out there (NET drivers are _very_ well maintained).
Well, for a while SCSI drivers were the only thing people would use for
kernel development, while the IDE tree was in shambles... So there are
at least the most common drivers working, which should give a path for
the rest. And we can talk to maintainers.
I'm not quite ready to dispair here.
HW companies work in the 'tradicional way': they write
drivers, then it pass
to control quality team and later they put it on a web page for rh_YY, suse_XX...
And it never reaches linux-ZZ-ml. Only if a hacker worry by it, it's included
into the kernel.
Plenty of vendors were initially annoyed when I asked them why they
thought that something was not good enough for the mainstream kernel,
but was good enough for the Red Hat kernel. That was a very different
perspective, but that wording also helped get a lot more vendor drivers
more actively maintained upstream because they could see what our
perspective was. I like to think that I was at least one small part
of helping Intel become the example of near-perfect cooperation that
Dave and Jeff use when describing to other vendors how to work with the
Linux community on network drivers. (If anyone remembers what the case
was like with the e100 and e1000 drivers a few years back, you'll
realize what an impressive transformation that was -- hats off to
Intel for such a great change.)
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
4:29 p.m.
On Tue, Dec 09, 2003 at 08:35:52AM -0500, Michael K. Johnson wrote:
On Mon, Dec 08, 2003 at 06:31:13PM -1000, Warren Togami wrote:
> Good idea. This is especially important because of the critical drivers
> that are not yet ported to 2.6 kernel... for example dpt_i2o SCSI RAID.
There are several months for them to be ported. If no one cares enough
to port them, well, that's an indicator that they aren't critical.
Or that only two people on the planet have the docs.
Really, trying to do backup kernels is a bad idea. It messes up
testing, it duplicates lots of effort, it wastes space.
Its an inevitability for FC2, its simply a question of whether Red Hat
does it, or everyone uses an alternative boot disk. Remember most of the
boxes 2.6 doesn't work on will be total install blockers, so instead
of pushing 2.6 you'll simply destroy fedora.
4:17 p.m.
On Mon, Dec 08, 2003 at 06:31:13PM -1000, Warren Togami wrote:
Xose Vazquez Perez wrote:
>o 2.4 kernel as backup
>
Good idea. This is especially important because of the critical drivers
that are not yet ported to 2.6 kernel... for example dpt_i2o SCSI RAID.
Huge amounts of hardware items are 2.4 only right now but it depends how
much that changes over early 2.6 releases. Many vendors wont port their
drivers until 2.6.x is out.
It may be by FC2 that nobody needs 2.4 but I don't believe that is remotely
likely. Current 2.6 test doesn't support most of my hardware.
2:44 a.m.
El Lunes, 8 diciembre, 2003, a las 06:25 PM, Xose Vazquez Perez
escribió:
Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it
> would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.
Xose's wishes list. All for this year ;-)
here goes:
[...]
o lighter dns server, bind is too big for basic dns services.
Candidates: http://maradns.org http://powerdns.com ...
And have also poweradmin as his web frontend.
Regards,
2:56 a.m.
tisdagen den 9 december 2003 09.44 skrev Daniel Guerrero:
El Lunes, 8 diciembre, 2003, a las 06:25 PM, Xose Vazquez Perez
escribió:
> Michael K. Johnson wrote:
>> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
>> hear people's wishlists. Not everything will be possible, but it
>> would
>> be nice to have a good list from which to pick the possibilities, and
>> from which to also pick ideas later for Fedora Core 3.
>
> Xose's wishes list. All for this year ;-)
>
> here goes:
[...]
> o lighter dns server, bind is too big for basic dns services.
> Candidates: http://maradns.org http://powerdns.com ...
And have also poweradmin as his web frontend.
What about qmail and the other djbwares?
;)
3:02 a.m.
On Tue, 2003-12-09 at 00:56, Oden Eriksson wrote:
What about qmail and the other djbwares?
;)
Been discussed before... None of them are Free Software or Open Source
and the restrictions are such that they could not easily be included.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Naked Ape Consulting http://nakedape.cc *
7:31 p.m.
On Mon, 8 Dec 2003, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
My autofs4 patches.
It's unlikely they will get into 2.6.0 as I have only recently ported
them to 2.6.
--
,-._|\ Ian Kent
/ \ Perth, Western Australia
*_.--._/ E-mail: raven(a)themaw.net
v Web: http://themaw.net/
7:38 a.m.
On Tue, Dec 09, 2003 at 09:31:02AM +0800, Ian Kent wrote:
My autofs4 patches.
It's unlikely they will get into 2.6.0 as I have only recently ported
them to 2.6.
We really are trying to hold to upstream as much as possible.
Work this one upstream for now. If upstream maintainers have
issues with the code, then that's also another reason to work
it upstream...
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
9:06 a.m.
On Tue, 2003-12-09 at 13:38, Michael K. Johnson wrote:
We really are trying to hold to upstream as much as possible.
Work this one upstream for now. If upstream maintainers have
issues with the code, then that's also another reason to work
it upstream...
And as Linus is very difficult to get patches past these days,
you may be better off sending them to Andrew when he returns from
Vacation, and see if he'll take them for -mm for a while,
with a view to merging them post 2.6.0
Dave
9:39 a.m.
On Tue, 9 Dec 2003, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 09:31:02AM +0800, Ian Kent wrote:
> My autofs4 patches.
>
> It's unlikely they will get into 2.6.0 as I have only recently ported
> them to 2.6.
We really are trying to hold to upstream as much as possible.
Work this one upstream for now. If upstream maintainers have
issues with the code, then that's also another reason to work
it upstream...
They won't make 2.6.0, but please do try to submit upstream. Usable Linux
autofs which works more like Solaris would be a big plus in my
environment....
later,
chris
8:08 p.m.
On Mon, Dec 08, 2003 at 10:15:30AM -0500, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
I only have a few quibbles - in the sense that they are not the end of
the world.
I propose having pam_mount shipped with Fedora Core. It is invaluable,
especially when integrating Linux into an existing Microsoft-based
infrastructure. I have deployed it with success on a number of systems
at this large, unnamed healthcare institution in SE Minnesota (the only
thing, along with IBM's plant, to stand out in an ocean of corn). Having
pam_mount is much better than any alternative, such as the existing
setups I found being used before my deployment - namely, storing
passwords in files or having one user mount a share for everyone else to
use promiscuously ...or *shiver* both.
I've helped a bit Mike Petullo with the spec file and testing, in
particular on multiuser systems. The only real hurdle at the moment is
tying some support into authconfig. After installation, pam_mount
requires being implanted into PAM's system-auth configuration file and,
of course, that's probably better left to authconfig. Adding pam_mount
support to Anaconda might also be ideal for some.
Another pet peeve of mine is a more comprehensive GROUPS file for rpm.
The current one is pretty anaemic. For example, I have been building
bioinformatic packages (good candidates for Fedora Extras rather than
FC, I guess) and, for lack of more descriptive options, tagged them all
with Applications/Engineering. I do know that the "Group:" tag has only
token value, but as a completist I would still like to see a bit more
choice. On the other hand, it's a good idea to refrain from getting
carried away and from defining too many new groups.
Then there's DHCP Vendor Class Identifier support for pump and Anaconda.
My understanding is that this made it to Red Hat's internal CVS
repository, but - quite obviously - was a bit late for FC1. I have
uploaded separate new patches for FC1 and RH9, along with source and
binary packages:
http://uberh4x0r.org/~yax/dhcp_classid/
I am going to upload a bit more information and a slightly improved
version of Chris Adams' custom-modules.pl, simplifying the creation of
new boot images with a custom/patched loader. That's what I really
needed when I was trying to test and debug my own patches.
Rudi
8:33 p.m.
New subject: Moving from Groups to Trove
Rudi Chiarito <nutello(a)sweetness.com>:
Another pet peeve of mine is a more comprehensive GROUPS file for
rpm.
The current one is pretty anaemic.
That's because the Groups tree is rather half-assed to begin with. I
think it ought to be scrapped and replaced with Trove specifiers, and
I'd think that even if I hadn't designed the original Trove.
Freshmeat and SourceForge have both used Trove and found it effective.
And there are obvious examples to having just one classification system.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
11:23 p.m.
New subject: DHCP VCI (was: Fedora Core 2 wishlists)
On Mon, 2003-12-08 at 19:08, Rudi Chiarito wrote:
Then there's DHCP Vendor Class Identifier support for pump and
Anaconda.
My understanding is that this made it to Red Hat's internal CVS
repository, but - quite obviously - was a bit late for FC1. I have
uploaded separate new patches for FC1 and RH9, along with source and
binary packages:
http://uberh4x0r.org/~yax/dhcp_classid/
Rudi, a couple comments on the VCI patch.
Isn't the main goal here so that the DHCP can return conditional
responses (aka paths to unique kickstart files) based on the VCI?
IMO, it should send a VCI by default. If it doesn't and it requires
specifying the ksclass option, I might as well type the explicit path to
the kickstart file (ala ks=http://server/foo.ks).
The default VCI should identify:
* The distro (RHEL, Fedora, Debian, etc)
* The version of the distro (version of Anaconda?)
* The CPU architecture
Dax Kelson
Guru Labs
11:40 p.m.
* Perl-LDAP - This is such an incredibly useful swiss army knife. I've
been begging for it for 2 years (Bugzilla 59225).
* ldapmigrate - My script that replaces the PADL.COM migration scripts.
It has many pluses over the PADL scripts. Requires Perl-LDAP.
* Directory Administrator - AFAIK currently the best GUI app for
managing users in a LDAP-as-NIS-replacement directory.
* A generic LDAP browser (GQ or something).
* Use Bitstream vera fonts by default
* redhat-config-printer to use foomatic v3 and support PPD files
* Add more common ports to the list in redhat-config-securitylevel
* FLAC (I saw that Bill said it is going in, excellent!)
* APG - a good password generator
* A GNOME replacement for "kprinter" to select PPD options on a per
print job basis.
11:49 p.m.
On Mon, 2003-12-08 at 21:40, Dax Kelson wrote:
* Perl-LDAP - This is such an incredibly useful swiss army knife.
I've
been begging for it for 2 years (Bugzilla 59225).
Having forgotten that I build this myself, I'll add +1.
* A GNOME replacement for "kprinter" to select PPD options
on a per
print job basis.
+1 I'd really like something like this, for non-CUPS aware apps that
print through piping to LPD (mainly in my use, Mozilla and Acrobat
Reader).
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
8:01 a.m.
On Mon, 8 Dec 2003, Wil Cooley wrote:
> * A GNOME replacement for "kprinter" to select PPD
options on a per
> print job basis.
+1 I'd really like something like this, for non-CUPS aware apps that
print through piping to LPD (mainly in my use, Mozilla and Acrobat
Reader).
kprinter works with Mozilla and acrobat reader. Why reinvent the wheel?
later,
chris
8:15 a.m.
> > print job basis.
>
> +1 I'd really like something like this, for non-CUPS aware apps that
> print through piping to LPD (mainly in my use, Mozilla and Acrobat
> Reader).
kprinter works with Mozilla and acrobat reader. Why reinvent the wheel?
If you're not already in KDE there is startup overhead with bringing up
kprinter.
A lot of startup overhead, in fact.
-sv
12:31 a.m.
On Mon, 2003-12-08 at 23:50, seth vidal wrote:
> * Use Bitstream vera fonts by default
I'm pretty sure it's not using this now b/c Bitstream vera doesn't
support all the characters necessary for display of a significant number
of latin languages.
Can anyone from RH verify? Is this true?
- jck
--
"To turn $100 into $110 is work. To turn $100 million into $110 million
is inevitable"
-- Edgar Bronfman
6:45 a.m.
On Tue, Dec 09, 2003 at 12:31:42AM -0600, Jens Knutson wrote:
> I'm pretty sure it's not using this now b/c Bitstream
vera doesn't
> support all the characters necessary for display of a significant number
> of latin languages.
Can anyone from RH verify? Is this true?
It is true at least for Czech and
Slovak.
Mirek
10:18 a.m.
On Tue, Dec 09, 2003 at 01:45:23PM +0100 or thereabouts, Miloslav Trmac wrote:
On Tue, Dec 09, 2003 at 12:31:42AM -0600, Jens Knutson wrote:
> > I'm pretty sure it's not using this now b/c Bitstream vera doesn't
> > support all the characters necessary for display of a significant number
> > of latin languages.
>
> Can anyone from RH verify? Is this true?
It is true at least for Czech and Slovak.
Mirek
And Welsh. Although something tells me it's not the same letters
involved :)
Telsa
4:04 p.m.
On Tue, 9 Dec 2003, Telsa Gwynne wrote:
On Tue, Dec 09, 2003 at 01:45:23PM +0100 or thereabouts, Miloslav
Trmac wrote:
> On Tue, Dec 09, 2003 at 12:31:42AM -0600, Jens Knutson wrote:
> > > I'm pretty sure it's not using this now b/c Bitstream vera
doesn't
> > > support all the characters necessary for display of a significant number
> > > of latin languages.
> >
> > Can anyone from RH verify? Is this true?
> It is true at least for Czech and Slovak.
> Mirek
And Welsh. Although something tells me it's not the same letters
involved :)
Telsa
Perhpahs they can be added? Is the license problem with
Bitstream Vera fonts resolved? I assume so as they are included.
What are the minimum blocks that should be covered? Just latin?
Greek? Cyrrilic?
behdad
4:46 p.m.
Le mar 09/12/2003 à 23:04, Behdad Esfahbod a écrit :
On Tue, 9 Dec 2003, Telsa Gwynne wrote:
> On Tue, Dec 09, 2003 at 01:45:23PM +0100 or thereabouts, Miloslav Trmac wrote:
> > On Tue, Dec 09, 2003 at 12:31:42AM -0600, Jens Knutson wrote:
> > > > I'm pretty sure it's not using this now b/c Bitstream vera
doesn't
> > > > support all the characters necessary for display of a significant
number
> > > > of latin languages.
> > >
> > > Can anyone from RH verify? Is this true?
> > It is true at least for Czech and Slovak.
> > Mirek
>
> And Welsh. Although something tells me it's not the same letters
> involved :)
>
> Telsa
Perhpahs they can be added?
So far people have been more interested in playing with Vera metrics
than adding new glyphs.
Drawing new glyphs is hard.
Is the license problem with
Bitstream Vera fonts resolved? I assume so as they are included.
What are the minimum blocks that should be covered? Just latin?
Greek? Cyrrilic?
W4GL I think, like for the corefonts.
Cheers,
--
Nicolas Mailhot
4:56 p.m.
On Tue, Dec 09, 2003 at 05:04:27PM -0500, Behdad Esfahbod wrote:
Perhpahs they can be added? Is the license problem with
Bitstream Vera fonts resolved? I assume so as they are included.
What are the minimum blocks that should be covered? Just latin?
Latin would be a good start. Right now the coverage is basically
"American". Third party symbols exist for Welsh and I think a couple of
other bits now and can be merged under the licensing (vera has a very
nice license).
Isabella would be a nice GPL font to have too but I can't make a good case
for it 8)
4:19 p.m.
On Tue, Dec 09, 2003 at 12:31:42AM -0600, Jens Knutson wrote:
On Mon, 2003-12-08 at 23:50, seth vidal wrote:
> > * Use Bitstream vera fonts by default
>
> I'm pretty sure it's not using this now b/c Bitstream vera doesn't
> support all the characters necessary for display of a significant number
> of latin languages.
Can anyone from RH verify? Is this true?
True last time I checked. People have added other symbols but there seems
to be no mechanism for merging them all together and no font maintainer
12:22 a.m.
On Monday 08 December 2003 21:40, Dax Kelson wrote:
* APG - a good password generator
Whats wrong with mkpasswd? Seriously, I use it to generate passwords
for our company.
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.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:14 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Tue, 2003-12-09 at 22:18, Alan Cox wrote:
On Mon, Dec 08, 2003 at 10:40:03PM -0700, Dax Kelson wrote:
> * A generic LDAP browser (GQ or something).
> * Use Bitstream vera fonts by default
This would need Vera updating to include symbols the rest of the world
apart from Americans need.
Maybe a naive question, but wouldn't it be possible to fall-back to
another font when trying to display symbols unavailable in vera ? Or
make vera the default when you select a West European or American
timezone ?
Or a third possibility (maybe impossible for legal or technical reasons)
would be to add the missing symbols directly into the Vera fonts (by
copy/paste of the symbols from Nimbus). Is it a stupid proposition ?
I really love Vera fonts. Too bad they also lack an oblique serif font
(OpenOffice doesn't seem to support the fontconfig hack to simulate
oblique fonts).
--
Julien Olivier <julo(a)altern.org>
9:03 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 04:14, Julien Olivier wrote:
On Tue, 2003-12-09 at 22:18, Alan Cox wrote:
> On Mon, Dec 08, 2003 at 10:40:03PM -0700, Dax Kelson wrote:
> > * A generic LDAP browser (GQ or something).
> > * Use Bitstream vera fonts by default
>
> This would need Vera updating to include symbols the rest of the world
> apart from Americans need.
Maybe a naive question, but wouldn't it be possible to fall-back to
another font when trying to display symbols unavailable in vera ? Or
make vera the default when you select a West European or American
timezone ?
It *will* fall back currently, but that looks really ugly. You
don't want some characters in a word to have a different font
than others.
If LC_CTYPE is set to a language that isn't supported by your top
font in the Sans alias, fontconfig will use a different font by
default (e.g., cyrillic languages won't get Luxi as the default),
but in general, we would like to have the same defaults for all
Western languages ... it's hard to do QA / graphics design if
you get different fonts for different languages.
Or a third possibility (maybe impossible for legal or technical
reasons)
would be to add the missing symbols directly into the Vera fonts (by
copy/paste of the symbols from Nimbus). Is it a stupid proposition ?
That would also look really ugly :-)
I should point out that the main reason for staying with Luxi Sans/Luxi
Mono/Nimbus Roman as our default fonts instead of the Vera fonts is that
I wasn't convinced that the Vera fonts actually looked better...
coverage was a secondary issue.
Regards,
Owen
10:53 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
I should point out that the main reason for staying with Luxi
Sans/Luxi
Mono/Nimbus Roman as our default fonts instead of the Vera fonts is that
I wasn't convinced that the Vera fonts actually looked better...
coverage was a secondary issue.
I don't know if it's hardware related or something else but, on my
laptop, Vera fonts with subpixel smoothing on are *way* nicer than
Luxi/Nimbus fonts with or without subpixel smoothing.
--
Julien Olivier <julo(a)altern.org>
11:03 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
Le mer 10/12/2003 à 17:53, Julien Olivier a écrit :
> I should point out that the main reason for staying with Luxi
Sans/Luxi
> Mono/Nimbus Roman as our default fonts instead of the Vera fonts is that
> I wasn't convinced that the Vera fonts actually looked better...
> coverage was a secondary issue.
I don't know if it's hardware related or something else but, on my
laptop, Vera fonts with subpixel smoothing on are *way* nicer than
Luxi/Nimbus fonts with or without subpixel smoothing.
Well, that's certainly the first time I see anyone writing that
Luxi/Nimbus is better than Vera. Must have had some trauma in his past;)
--
Nicolas Mailhot
11:34 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
> I don't know if it's hardware related or something else
but, on my
> laptop, Vera fonts with subpixel smoothing on are *way* nicer than
> Luxi/Nimbus fonts with or without subpixel smoothing.
Well, that's certainly the first time I see anyone writing that
Luxi/Nimbus is better than Vera. Must have had some trauma in his past;)
If we are more than 2 people thinking that Vera is really better than
Nimbus/Luxi, is there a hope to see Fedora use them by default then
(provided that there is a good solution to the coverage issue and to the
fact that the serif oblique font doesn't work in OpenOffice) ?
--
Julien Olivier <julo(a)altern.org>
11:41 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 18:34, Julien Olivier wrote:
> > I don't know if it's hardware related or something
else but, on my
> > laptop, Vera fonts with subpixel smoothing on are *way* nicer than
> > Luxi/Nimbus fonts with or without subpixel smoothing.
>
> Well, that's certainly the first time I see anyone writing that
> Luxi/Nimbus is better than Vera. Must have had some trauma in his past;)
If we are more than 2 people thinking that Vera is really better than
Nimbus/Luxi, is there a hope to see Fedora use them by default then
(provided that there is a good solution to the coverage issue and to the
fact that the serif oblique font doesn't work in OpenOffice) ?
I must concur
that Luxi is better than Vera, at least the Sans Serif
typeface. The Vera Serif looks OK, especially at sizes >= 14.
BTW what font does OpenOffice in FC1 use for its menus? It doesn't look
good. I tried to change the font to Luxi Sans using a replacement for
'Andale Sans UI', but this doesn't seem to work anymore. I also tried to
replace 'Bitstream Vera' but to no avail.
Regards
--
Gérard Milmeister
Tannenrauchstrasse 35
8038 Zürich
gemi(a)bluewin.ch
12:20 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
In OOo 1.1.0-6 and higher at least, OOo uses the Luxi fonts where
possible, and Nimbus Roman No 9 L for Serif. The Bitstream Vera fonts
do not have the required coverage for at least Eastern European locales,
so we can't use them as the default UI font, even though they look good
there.
Dan
On Wed, 2003-12-10 at 12:41, Gerard Milmeister wrote:
On Wed, 2003-12-10 at 18:34, Julien Olivier wrote:
> > > I don't know if it's hardware related or something else but, on
my
> > > laptop, Vera fonts with subpixel smoothing on are *way* nicer than
> > > Luxi/Nimbus fonts with or without subpixel smoothing.
> >
> > Well, that's certainly the first time I see anyone writing that
> > Luxi/Nimbus is better than Vera. Must have had some trauma in his past;)
>
> If we are more than 2 people thinking that Vera is really better than
> Nimbus/Luxi, is there a hope to see Fedora use them by default then
> (provided that there is a good solution to the coverage issue and to the
> fact that the serif oblique font doesn't work in OpenOffice) ?
I must concur that Luxi is better than Vera, at least the Sans Serif
typeface. The Vera Serif looks OK, especially at sizes >= 14.
BTW what font does OpenOffice in FC1 use for its menus? It doesn't look
good. I tried to change the font to Luxi Sans using a replacement for
'Andale Sans UI', but this doesn't seem to work anymore. I also tried to
replace 'Bitstream Vera' but to no avail.
Regards
12:58 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 18:20, Dan Williams wrote:
In OOo 1.1.0-6 and higher at least, OOo uses the Luxi fonts where
possible, and Nimbus Roman No 9 L for Serif. The Bitstream Vera fonts
do not have the required coverage for at least Eastern European locales,
so we can't use them as the default UI font, even though they look good
there.
According to Owen, there could be a solution to solve the coverage
problem. Wouldn't it be worth trying to solve it if it's the case ?
--
Julien Olivier <julo(a)altern.org>
1:08 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
Its not a solution if it requires using Fontconfig to remap certain
ranges. OOo doesn't use fontconfig.
Now I don't know if thats the solution or not, it probably isn't. I'd
love to know what it is though.
dan
On Wed, 2003-12-10 at 13:58, Julien Olivier wrote:
On Wed, 2003-12-10 at 18:20, Dan Williams wrote:
> In OOo 1.1.0-6 and higher at least, OOo uses the Luxi fonts where
> possible, and Nimbus Roman No 9 L for Serif. The Bitstream Vera fonts
> do not have the required coverage for at least Eastern European locales,
> so we can't use them as the default UI font, even though they look good
> there.
>
According to Owen, there could be a solution to solve the coverage
problem. Wouldn't it be worth trying to solve it if it's the case ?
11:49 a.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 05:34:39PM +0000, Julien Olivier wrote:
If we are more than 2 people thinking that Vera is really better
than
Nimbus/Luxi, is there a hope to see Fedora use them by default then
(provided that there is a good solution to the coverage issue and to the
fact that the serif oblique font doesn't work in OpenOffice) ?
More than 2 isn't really a significant fraction of the community... :-)
This is almost certainly a topic for fedora-desktop-list rather than
fedora-devel-list.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
12:21 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
Julien Olivier (julo(a)altern.org) said:
If we are more than 2 people thinking that Vera is really better
than
Nimbus/Luxi, is there a hope to see Fedora use them by default then
(provided that there is a good solution to the coverage issue and to the
fact that the serif oblique font doesn't work in OpenOffice) ?
Solving the coverage issue is rather nontrivial though - good fontographers
are hard to find.
Bill
12:59 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On 11:21:17 am 12/10/03 Bill Nottingham <notting(a)redhat.com> wrote:
Julien Olivier (julo(a)altern.org) said:
> If we are more than 2 people thinking that Vera is really better than
> Nimbus/Luxi, is there a hope to see Fedora use them by default then
> (provided that there is a good solution to the coverage issue and to
> the fact that the serif oblique font doesn't work in OpenOffice) ?
Solving the coverage issue is rather nontrivial though - good
fontographers are hard to find.
How about BitStream? Might they be interested in finishing the work they
started? Anyone have a contact?
On my laptop, the difference between Nimbus/Luxi and Vera is night and day.
In Evolution 1.4+, with the default fonts the contrast between unread
(bold) and read messages is not enough. With Vera it is terrific -- and
gorgeous.
Dax Kelson
Guru Labs
6:11 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 11:59:37AM -0700, Dax Kelson wrote:
On 11:21:17 am 12/10/03 Bill Nottingham <notting(a)redhat.com>
wrote:
> Julien Olivier (julo(a)altern.org) said:
> > If we are more than 2 people thinking that Vera is really better than
> > Nimbus/Luxi, is there a hope to see Fedora use them by default then
> > (provided that there is a good solution to the coverage issue and to
> > the fact that the serif oblique font doesn't work in OpenOffice) ?
>
> Solving the coverage issue is rather nontrivial though - good
> fontographers are hard to find.
How about BitStream? Might they be interested in finishing the work they
started? Anyone have a contact?
I talked to them about it briefly when there was possible funding to add
8859-14 coverage. They pointed me at Jim Gettys and showed no interest
1 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 18:21, Bill Nottingham wrote:
Julien Olivier (julo(a)altern.org) said:
> If we are more than 2 people thinking that Vera is really better than
> Nimbus/Luxi, is there a hope to see Fedora use them by default then
> (provided that there is a good solution to the coverage issue and to the
> fact that the serif oblique font doesn't work in OpenOffice) ?
Solving the coverage issue is rather nontrivial though - good fontographers
are hard to find.
Oh sorry, I thought there was a technical hack to solve this. If there
is not, then it will obviously be hard to write all the missing symbols
in a few months, or even years :)
Bill
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Julien Olivier <julo(a)altern.org>
5:48 p.m.
New subject: About Vera fonts (was: Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 09:14:34AM +0000, Julien Olivier wrote:
Maybe a naive question, but wouldn't it be possible to fall-back
to
another font when trying to display symbols unavailable in vera ? Or
make vera the default when you select a West European or American
timezone ?
The font code actually figures out which default font to use, quite how
is a bit of magic I don't claim to understand.
Or a third possibility (maybe impossible for legal or technical
reasons)
copy/paste of the symbols from Nimbus). Is it a stupid proposition ?
They won't match. You already get the substitution - its quite visible
when its done
4:57 a.m.
On Tue, 2003-12-09 at 06:40, Dax Kelson wrote:
* Use Bitstream vera fonts by default
With Vera Serif broken (not supporting italics), I don't think it's
appropriate. Support for non-Western (American) fonts are also no good.
* redhat-config-printer to use foomatic v3 and support PPD files
+1.
* APG - a good password generator
+1. It's unfortunate that if a user tries to change a password and if
the user doesn't get an appropriate password, it just doesn't change it.
A password generator will help, and userpasswd for instance can have a
new button that allows you to generate passwords.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
3:32 p.m.
On Wednesday 17 December 2003 02:57, Colin Charles wrote:
+1. It's unfortunate that if a user tries to change a password
and if
the user doesn't get an appropriate password, it just doesn't change
it. A password generator will help, and userpasswd for instance can
have a new button that allows you to generate passwords.
mkpasswd
part of expect.
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.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:50 a.m.
Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
MySQL 4.x instead of MySQL 3.x
--
Best regards,
Yovko Lambrev, M.Sc., eng.
http://www.openintegra.com
OpenIntegra Ltd.
This e-mail has been sent using Open Source software
Transmitted via OpenIntegra secure TLS/SMTP service
4:03 a.m.
Yovko Lambrev wrote:
Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it would
MySQL 4.x instead of MySQL 3.x
We really need to have an auto-responder that searches for certain
strings like this...
MySQL 4.x is currently not possible because it is a violation of the
license to link GPL with LGPL. That means stuff like PHP cannot link to
it. At least that's how I last heard the situation. I didn't follow it
closely enough.
Warren
5:21 a.m.
Hi!
I'd like to see more localization specific packages, more precisely for
the Catalan language ;-)
aspell-ca was riped out because of a questionable license, but Debian
ships it, any chances to include it again?
I'd like to know how could I help in assuring that Fedora includes the
necessary packages to provide a "Catalan environment", like what files
would you require, etc... I can point out where to find the
"ca-localization" files for Mozilla, ispell, OpenOffice (all of them
GPL)...
If told how, I could also build packages myself.
Congratulations for the good work!
/jpc
4:25 p.m.
necessary packages to provide a "Catalan environment", like
what files
would you require, etc... I can point out where to find the
"ca-localization" files for Mozilla, ispell, OpenOffice (all of them
GPL)...
Ditto Welsh, all of which for some reason aren't in the base packages
but have been done, mostly by Canolfan Bedwar
4:23 p.m.
On Tue, Dec 09, 2003 at 11:50:15AM +0200, Yovko Lambrev wrote:
Michael K. Johnson wrote:
>However, that won't be the ONLY feature of Fedora Core 2. I'd like to
>hear people's wishlists. Not everything will be possible, but it would
MySQL 4.x instead of MySQL 3.x
Then you can't use MySQL with PHP
3:21 a.m.
On Tue, Dec 09, 2003 at 04:06:35PM -0800, Paul Heinlein wrote:
On Tue, 9 Dec 2003, Alan Cox wrote:
> > MySQL 4.x instead of MySQL 3.x
>
> Then you can't use MySQL with PHP
Is there an instructive URL regarding this issue?
The license document. MySQL4 changed the client libraries from LGPL to GPL
which makes using mysql with a lot of stuff like PHP infeasible
2:12 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
Warren Togami wrote:
We really need to have an auto-responder that searches for certain
strings like this...
Sorry, Warren it won't work if the problem still exist. I don't want to
argue but I cannot agree so easy. With all my respect to you and Mr. Cox.
I believe that this new Fedora community is much more open than the
RedHat's one! I have been an user, fan and admin of the old RedHat Linux
for more than 7 years and I feel myself closely enough to all the
RedHat's issues, problems, feelings... Usually I'm here reading... I am
not core developer till now here but I feel Fedora/RedHat like my kind
of distribution. I have been an user and admin of MySQL for more than
2-3 years also and I feel it like my kind of database and my kind of
open community.
I knew about the problem you mentioned but I still don't know the
Fedora's solution... SuSE and Debian already has their solutions. To
throw out of the box MySQL 4.x is not the solution at all!
Let's go through the facts:
MySQL 3.x client libraries - LGPL
MySQL 4.x client libraries - GPL (whole MySQL 4 is GPL)
PHP license is not GPL (it is much more BSD-like)
Fedora Core is GPL. All the software in Fedora Core 1 is GPL
So...?
We cannot put MySQL 4.x in Fedora collection because it is GPL but we
will allow PHP which is not?!! Let's throw out the kernel also!? I just
can't agree...
Let's find a real solution... As far as I know there is no contacts
between Fedora/RedHat community and MySQL developers. Why? I will inform
about this issue a few of my friends from MySQL and will ask them for
help. I think this is the right way to find a solution. I will write to
Mr. Zak Greant also - he is ex-PHP and current MySQL community advocate
- very friendly and helpful guy and will ask him for advice.
Nobody's bugless... But if the Fedora community is open let's open
ourself and talk with MySQL people...
Alan Cox wrote:
Then you can't use MySQL with PHP
Warren Togami wrote:
MySQL 4.x is currently not possible because it is a violation of the
license to link GPL with LGPL. That means stuff like PHP cannot link
to it. At least that's how I last heard the situation. I didn't
follow it closely enough.
--
With all my respect and grateful,
Yovko Lambrev, M.Sc., eng.
http://www.openintegra.com
OpenIntegra Ltd.
This e-mail has been sent using Open Source software
Transmitted via OpenIntegra secure TLS/SMTP service
4 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 10:12:04AM +0200, Yovko Lambrev wrote:
Fedora Core is GPL. All the software in Fedora Core 1 is GPL
Completely wrong... where did you get this idea ?!
localhost:~ -> rpm -qa --queryformat '%{License}\n' | sort | uniq | wc -l
61
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
4:49 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
Daniel Veillard wrote:
| Completely wrong... where did you get this idea ?!
| rpm -qa --queryformat '%{License}\n' | sort | uniq | wc -l
| 61
OK! I'm wrong! It was hyperbolization... Sorry!
I just cannot accept that the reason to not include MySQL 4.x is the GPL
license...
--
Best regards,
Yovko Lambrev, M.Sc., eng.
http://www.openintegra.com
OpenIntegra Ltd.
This e-mail has been sent using Open Source software
Transmitted via OpenIntegra secure TLS/SMTP service
5:15 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 12:49:16PM +0200, Yovko Lambrev wrote:
Daniel Veillard wrote:
| Completely wrong... where did you get this idea ?!
| rpm -qa --queryformat '%{License}\n' | sort | uniq | wc -l
| 61
OK! I'm wrong! It was hyperbolization... Sorry!
I just cannot accept that the reason to not include MySQL 4.x is the GPL
license...
well it's clear it is, this has been debated to death already !
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:08 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 03:49, Yovko Lambrev wrote:
Daniel Veillard wrote:
| Completely wrong... where did you get this idea ?!
| rpm -qa --queryformat '%{License}\n' | sort | uniq | wc -l
| 61
OK! I'm wrong! It was hyperbolization... Sorry!
I just cannot accept that the reason to not include MySQL 4.x is the GPL
license...
Lets try different words then. It is not becuase it is GPL software. The
problem is that because it is GPL software many applications that
'embed' with it can not be used with it. PHP is one example because of
its license isnt one that can be embedded into GPL items. Thus Fedora2
could ship with MySQL-4. but it could not ship various php-mysql tie-ins
as that would violate the licenses (or Fedora could ship with it and
then open itself to lawsuits, bad press of violating licenses.)
The price of freedom is eternal vigilance(sp). That means to use Free
Software you have to be vigilant and strict about the licenses.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
11:49 a.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 13:08, Stephen Smoogen wrote:
On Wed, 2003-12-10 at 03:49, Yovko Lambrev wrote:
> Daniel Veillard wrote:
> | Completely wrong... where did you get this idea ?!
> | rpm -qa --queryformat '%{License}\n' | sort | uniq | wc -l
> | 61
>
> OK! I'm wrong! It was hyperbolization... Sorry!
> I just cannot accept that the reason to not include MySQL 4.x is the GPL
> license...
Lets try different words then. It is not becuase it is GPL software. The
problem is that because it is GPL software many applications that
'embed' with it can not be used with it. PHP is one example because of
its license isnt one that can be embedded into GPL items. Thus Fedora2
could ship with MySQL-4. but it could not ship various php-mysql tie-ins
as that would violate the licenses (or Fedora could ship with it and
then open itself to lawsuits, bad press of violating licenses.)
I think that the real "problem" fall over the person that develops php
based software and is using MySQL, remember that the GPL does not
restrict you to distribute GPL licensed code with software that uses
other licenses, If you develop an application with php and mysql4 your
code must be GPL (unless you obtain a different license from the MySQL
developers)
The price of freedom is eternal vigilance(sp). That means to use Free
Software you have to be vigilant and strict about the licenses.
12:57 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
I think that the real "problem" fall over the person that develops php
based software and is using MySQL, remember that the GPL does not
restrict you to distribute GPL licensed code with software that uses
other licenses, If you develop an application with php and mysql4 your
code must be GPL (unless you obtain a different license from the MySQL
developers)
As it has been explined to me by a lawyer: That's only true if you are
embedding the mysql library in your software (statically linking). Merely
using MySQL as a database for PHP does not tie you to either license because
you are not embedding code from either program.
The same goes for Perl or C/C++. Writing code that utilizes the language
does not automatically tie you to the license the programming language uses,
unless you statically link against the libraries.
Otherwise, pretty much nothing in Linux would be other then GPL, since
that's what glibc is licensed under, including PHP, Perl and Apache, all of
which have licenses other then GPL.
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
1:35 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, 10 Dec 2003, Adam Debus wrote:
As it has been explined to me by a lawyer: That's only true if you are
embedding the mysql library in your software (statically linking). Merely
using MySQL as a database for PHP does not tie you to either license because
you are not embedding code from either program.
The same goes for Perl or C/C++. Writing code that utilizes the language
does not automatically tie you to the license the programming language uses,
unless you statically link against the libraries.
Otherwise, pretty much nothing in Linux would be other then GPL, since
that's what glibc is licensed under, including PHP, Perl and Apache, all of
which have licenses other then GPL.
What you are mentioning is almost true about *LGPL*, not GPL.
Fortunately glibc is LGPLed. If it was GPLed, yes, you could not
run anything non-GPL-compatible.
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
2:11 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
What you are mentioning is almost true about *LGPL*, not GPL.
Fortunately glibc is LGPLed. If it was GPLed, yes, you could not
run anything non-GPL-compatible.
Ah. My mistake. Thanks :)
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
2:22 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, 2003-12-10 at 14:57, Adam Debus wrote:
>
> I think that the real "problem" fall over the person that develops php
> based software and is using MySQL, remember that the GPL does not
> restrict you to distribute GPL licensed code with software that uses
> other licenses, If you develop an application with php and mysql4 your
> code must be GPL (unless you obtain a different license from the MySQL
> developers)
>
As it has been explined to me by a lawyer: That's only true if you are
embedding the mysql library in your software (statically linking). Merely
using MySQL as a database for PHP does not tie you to either license because
you are not embedding code from either program.
That was true before the client libraries for MySQL (Java, C, etc..)
were changed from LGPL to GPL
The same goes for Perl or C/C++. Writing code that utilizes the
language
does not automatically tie you to the license the programming language uses,
unless you statically link against the libraries.
Otherwise, pretty much nothing in Linux would be other then GPL, since
that's what glibc is licensed under, including PHP, Perl and Apache, all of
which have licenses other then GPL.
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
6:10 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 10:57:11AM -0800, Adam Debus wrote:
As it has been explined to me by a lawyer: That's only true
if you are
embedding the mysql library in your software (statically linking). Merely
using MySQL as a database for PHP does not tie you to either license because
you are not embedding code from either program.
You are embedding the client library and a derivative work of it. The core
dbase has always been GPL which isnt a problem, now the client libraries
are
The same goes for Perl or C/C++. Writing code that utilizes the
language
does not automatically tie you to the license the programming language uses,
unless you statically link against the libraries.
If you call functions provided by the interpreter ...
Otherwise, pretty much nothing in Linux would be other then GPL,
since
that's what glibc is licensed under, including PHP, Perl and Apache, all of
which have licenses other then GPL.
glibc has specific statements to cover linking for apps. Guess why
6:21 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
Yeah, I had that explained to me a couple times through private e-mail so
far today.
I think I shant be using said lawyer again for this sort of work. :)
Thanks,
Adam Debus
Network Engineer, ReachONE Internet
adam(a)reachone.com
----- Original Message -----
From: "Alan Cox" <alan(a)redhat.com>
To: <fedora-devel-list(a)redhat.com>
Sent: Wednesday, December 10, 2003 4:10 PM
Subject: Re: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 10:57:11AM -0800, Adam Debus wrote:
> As it has been explined to me by a lawyer: That's only true if you
are
> embedding the mysql library in your software (statically
linking).
Merely
> using MySQL as a database for PHP does not tie you to either
license
because
> you are not embedding code from either program.
You are embedding the client library and a derivative work of it. The core
dbase has always been GPL which isnt a problem, now the client libraries
are
> The same goes for Perl or C/C++. Writing code that utilizes the
language
> does not automatically tie you to the license the programming
language
uses,
> unless you statically link against the libraries.
If you call functions provided by the interpreter ...
> Otherwise, pretty much nothing in Linux would be other then GPL,
since
> that's what glibc is licensed under, including PHP, Perl and
Apache, all
of
> which have licenses other then GPL.
glibc has specific statements to cover linking for apps. Guess why
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
5:40 p.m.
New subject: MySQL client libraries licensing (was Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 10:12:04AM +0200, Yovko Lambrev wrote:
Fedora Core is GPL. All the software in Fedora Core 1 is GPL
Nothing of the sort. The collection copyright and the individual works
copyright is unrelated
So...?
We cannot put MySQL 4.x in Fedora collection because it is GPL but we
will allow PHP which is not?!! Let's throw out the kernel also!? I just
can't agree...
The kernel isnt a library linked with an app using incompatible licenses.
One is derivative work the other is mere aggregation
Let's find a real solution... As far as I know there is no
contacts
between Fedora/RedHat community and MySQL developers. Why? I will inform
This is months old stuff. The php and mysql people are all quite aware of
the entire thing
1:06 a.m.
On Tue, 9 Dec 2003, Alan Cox wrote:
On Tue, Dec 09, 2003 at 11:50:15AM +0200, Yovko Lambrev wrote:
> Michael K. Johnson wrote:
> >However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> >hear people's wishlists. Not everything will be possible, but it would
>
> MySQL 4.x instead of MySQL 3.x
Then you can't use MySQL with PHP
# rpm -qf /usr/sbin/mysqld
MySQL-server-4.0.15-0
# rpm -qa "php*"
php-pgsql-4.1.2-7.3.6
php-ldap-4.1.2-7.3.6
php-devel-4.1.2-7.3.6
php-mysql-4.1.2-7.3.6
php-4.1.2-7.3.6
I use the mysql original rpms together with php in a production system.
Pau
6 a.m.
Hi,
Michael K. Johnson's"Fedora Core 2 wishlists" wrote:
However, that won't be the ONLY feature of Fedora Core 2. I'd
like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
What was thought of is mentioned.
I think that it is difficult to realize all by FC2.
- advanced UTF-8 correspondence
There is rpm which UTF-8-ization has not completed.
- Exact localization
For example, neither MUA nor an irc client can treat Japanese correctly.
- mbstring-izing of PHP
In the case of Japanese environment, a mbstring module is near indispensable.
- The addition of a PHP's PECL module
There is a convenient extended module called PECL in PHP.
- Update of logrotate
It is old.;-)
- rrdtool
http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/
RRD is the Acronym for Round Robin Database. RRD is a system to store and display
time-series data (i.e. network bandwidth, machine-room temperature, server load average).
It stores the data in a very compact way that will not expand over time, and it presents
useful graphs by processing the data to enforce a certain data density. It can be used
either via simple wrapper scripts (from shell or Perl) or via frontends that poll network
devices and put a friendly user interface on it.
- The web interface management tool
- cacti
http://www.raxnet.net/products/cacti/
When it comes to network monitoring/graphing, Tobi Oetiker's RRDTool does it best. It
gives you the ability to put data into a database, then represent that data on a graph as
you see fit.
- phpMyAdmin
http://www.phpmyadmin.net/
phpMyAdmin is a tool written in PHP intended to handle the administration of MySQL over
the WWW. Currently it can create and drop databases, create/drop/alter tables,
delete/edit/add fields, execute any SQL statement, manage keys on fields, manage
privileges,export data into various formats and is available in 47 languages.
- phpPgAdmin
http://phppgadmin.sourceforge.net/
phpPgAdmin is a web-based administration tool for PostgreSQL. It is perfect for PostgreSQL
DBAs, newbies and hosting services.
- The web contents management systems and colabolation systems.
- XOOPS
http://www.xoops.org/
XOOPS is a dynamic OO (Object Oriented) based open source portal script written in PHP .
XOOPS supports a number of databases (currently only mySQL is supported), making XOOPS an
ideal tool for developing small to large dynamic community websites
- PukiWiki
http://pukiwiki.org/
PukiWiki consists of a series of PHP Scripts designed to build a collection of web pages
which can be edited by anyone without any restriction.
Pukiwiki is more flexible than moderate bulletinboards.
--
----.----1----.----2----.----3----.----4----.----5----.----6----.----7
Tadashi Jokagi/Shibuya city mailto:elf@elf.no-ip.org
Yokukitana http://elf.no-ip.org/
Yokukitawiki http://elf.no-ip.org/wiki/
Yokukitablog http://elf.no-ip.org/blog/
Fedora JP Project http://www.linuxml.net/
9 p.m.
Hi,
Thank you. My check was insufficient ;-(
And he might forget further.
PHP have --zend-multibyte option. This is the option which strengthens
internationalization of zend engine.
If this is used, a script can be written by character code SHIFT_JIS.
If SHIFT_JIS can be used, creation of mobile contents will become easy.
#It must be unnecessary in fact. However, the demand in Japan is high.
--
----.----1----.----2----.----3----.----4----.----5----.----6----.----7
Tadashi Jokagi/Shibuya city mailto:elf@elf.no-ip.org
Yokukitana http://elf.no-ip.org/
Yokukitawiki http://elf.no-ip.org/wiki/
Yokukitablog http://elf.no-ip.org/blog/
Fedora JP Project http://www.linuxml.net/
9:11 p.m.
Hi,
It is an addition.;-)
- ntop
http://www.ntop.org/
ntop is a network traffic probe that shows the network usage, similar to what the popular
top Unix command does.
- logsurf
http://www.cert.dfn.de/eng/logsurf/
The program "logsurfer" was designed to monitor any text-based logfiles on your
system in realtime.
--
----.----1----.----2----.----3----.----4----.----5----.----6----.----7
Tadashi Jokagi/Shibuya city mailto:elf@elf.no-ip.org
Yokukitana http://elf.no-ip.org/
Yokukitawiki http://elf.no-ip.org/wiki/
Yokukitablog http://elf.no-ip.org/blog/
Fedora JP Project http://www.linuxml.net/
10:35 a.m.
Core functionality:
o SELinux (in progress)
Along with the 2.6 kernel, this should be the central focus
of FC2, IMHO. I'm happy to see work progressing.
o OTPW - One-time password PAM (http://www.cl.cam.ac.uk/~mgk25/otpw.html).
o A tool (DKMS or otherwise) for building and managing modules that are
not included in the distro kernel.
o Ext3 online fs growth (may get merged upstream ...)
o Encrypted block device. (I'm partial to Christophe Saout's
device mapper crypt target, dm-crypt, http://www.saout.de/misc/ )
o root-on-LVM2/EVMS support in mkinitrd/initscripts
o Packet-writing (http://w1.894.telia.com/~u89404340/patches/packet/)
o OpenIPMI (http://openipmi.sourceforge.net)
o ln -s /proc/self/mounts /etc/mtab
*and* fix the kernel to show the mount options.
[This is desirable for using private namespaces.]
o UML - a User-mode Linux kernel.
o kernel-utils split. UML tools should be in a separate package,
as should the S.M.A.R.T. stuff. These tools change at varying paces;
combining them creates an administrative headache.
Functional/Performance testing:
o Regression Test suite. Ideally, the user could chose to run
(non-)destructive tests, compare with earlier runs, and optionally
mail or POST the results (including a hardware description) to a central
database.
o Oprofile "service" for long-term profiling, config file in
/etc/sysconfig, etc., cron job to generate summaries, optionally mail
or POST to central database. [Need to consider privacy issues.]
Random tools:
o CSSC - A base *nix install really ought to have SCCS-compatible tools,
and the latest version works with BitKeeper's enhanced format.
o sg3_utils - These are very handy.
Generally, I see no reason to burden Fedora Core with lots more packages.
There can readily be "Best of Fedora Extras" CDs for the folks who don't
have broadband and need to install huge packages.
Regards,
Bill Rugolsky
1:12 p.m.
On Tue, 9 Dec 2003, Bill Rugolsky Jr. wrote:
Core functionality:
...
o UML - a User-mode Linux kernel.
I would like this as well, but there are still some serious bugs in 2.6
UML.
o kernel-utils split. UML tools should be in a separate package,
as should the S.M.A.R.T. stuff. These tools change at varying paces;
combining them creates an administrative headache.
This is partially done already, in the sense that the UML tools at least
dropped out of kernel-utils shortly before FC1, however they haven't
reappeared as a separate package yet.
Michael Young
3:07 p.m.
On Tue, Dec 09, 2003 at 07:12:12PM +0000, M A Young wrote:
On Tue, 9 Dec 2003, Bill Rugolsky Jr. wrote:
> o kernel-utils split. UML tools should be in a separate package,
> as should the S.M.A.R.T. stuff. These tools change at varying paces;
> combining them creates an administrative headache.
This is partially done already, in the sense that the UML tools at least
dropped out of kernel-utils shortly before FC1, however they haven't
reappeared as a separate package yet.
I actually have such a package that I haven't submitted to fedora.us
yet. (Available on request.)
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
4:57 a.m.
On Tue, 2003-12-09 at 20:12, M A Young wrote:
> o UML - a User-mode Linux kernel.
I would like this as well, but there are still some serious bugs in 2.6
UML.
This is assuming Kernel 2.6 is what we decide to use for FC2. I'm still
leaning on a patched 2.4 kernel...
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
8:04 a.m.
On Wed, Dec 17, 2003 at 11:57:40AM +0100, Colin Charles wrote:
This is assuming Kernel 2.6 is what we decide to use for FC2. I'm
still
leaning on a patched 2.4 kernel...
You can lean all you want, but that doesn't really affect this
decision.
Please take a look at
http://fedora.redhat.com/participate/schedule/
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
5:15 p.m.
On Wed, Dec 17, 2003 at 09:04:07AM -0500, Michael K. Johnson wrote:
On Wed, Dec 17, 2003 at 11:57:40AM +0100, Colin Charles wrote:
> This is assuming Kernel 2.6 is what we decide to use for FC2. I'm still
> leaning on a patched 2.4 kernel...
You can lean all you want, but that doesn't really affect this
decision.
Im sure a 2.4 kernel will be appearing as an alternative pretty rapidly 8).
Even if I have to do it.
7:23 a.m.
On Wed, 2003-12-17 at 15:04, Michael K. Johnson wrote:
> This is assuming Kernel 2.6 is what we decide to use for FC2.
I'm still
> leaning on a patched 2.4 kernel...
You can lean all you want, but that doesn't really affect this
decision.
Please take a look at
http://fedora.redhat.com/participate/schedule/
My bad, I was going thru the devel list and didn't get to this post in
time!
And kernel 2.6 has been officially released. So, I guess, FC2 should
include it then...
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
2:37 p.m.
On Tue, 2003-12-09 at 16:35, Bill Rugolsky Jr. wrote:
o Ext3 online fs growth (may get merged upstream ...)
This appeared in Arjan's 2.6 RPM, but I chose not to include
it in the rawhide kernel. The reasoning behind this was the
'Stay close to mainline' objective of Fedora.
At some point before FC2 beta1, decisions are going to have to be
made to decide how much we want to deviate away from this goal.
User feedback is an important factor here. A feature 1-2 people want
is far less likely to get included than something dozens of folks
are clamouring for.
o Packet-writing (http://w1.894.telia.com/~u89404340/patches/packet/)
This one is unlikely. It's still not mature. See previous discussions
on this list.
o OpenIPMI (http://openipmi.sourceforge.net)
IPMI is part of the standard 2.6 kernel already.
o UML - a User-mode Linux kernel.
Would make a good subproject.
Functional/Performance testing:
o Regression Test suite. Ideally, the user could chose to run
(non-)destructive tests, compare with earlier runs, and optionally
mail or POST the results (including a hardware description) to a central
database.
Someone else on this list (Xose?) suggested this, and I agree it'd be
good to have some stress test tools/regression suites. However I can't
help thinking that they'd belong more in Fedora extras.
o Oprofile "service" for long-term profiling, config file
in
/etc/sysconfig, etc., cron job to generate summaries, optionally mail
or POST to central database. [Need to consider privacy issues.]
SELinux interaction with oprofile is an interesting problem that needs
to be worked out.
o CSSC - A base *nix install really ought to have SCCS-compatible
tools,
and the latest version works with BitKeeper's enhanced format.
Sounds reasonable.
Generally, I see no reason to burden Fedora Core with lots more
packages.
There can readily be "Best of Fedora Extras" CDs for the folks who don't
have broadband and need to install huge packages.
It'd be good to have some yum.conf/up2date defaults for 3rd party
repositories included as standard too. Not all of them, but the more
popular ones such as fedora.us
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
3:15 p.m.
The ext3 online fs growth patch, would really hit one of my sweet spots,
so I will gladly be one of the hopefully dozens of people who asks for
this to be included!
+1 on ext3 online fs growth ;)
tir, 09.12.2003 kl. 21.37 skrev Dave Jones:
On Tue, 2003-12-09 at 16:35, Bill Rugolsky Jr. wrote:
> o Ext3 online fs growth (may get merged upstream ...)
This appeared in Arjan's 2.6 RPM, but I chose not to include
it in the rawhide kernel. The reasoning behind this was the
'Stay close to mainline' objective of Fedora.
At some point before FC2 beta1, decisions are going to have to be
made to decide how much we want to deviate away from this goal.
User feedback is an important factor here. A feature 1-2 people want
is far less likely to get included than something dozens of folks
are clamouring for.
> o Packet-writing (http://w1.894.telia.com/~u89404340/patches/packet/)
This one is unlikely. It's still not mature. See previous discussions
on this list.
> o OpenIPMI (http://openipmi.sourceforge.net)
IPMI is part of the standard 2.6 kernel already.
> o UML - a User-mode Linux kernel.
Would make a good subproject.
> Functional/Performance testing:
>
> o Regression Test suite. Ideally, the user could chose to run
> (non-)destructive tests, compare with earlier runs, and optionally
> mail or POST the results (including a hardware description) to a central
> database.
Someone else on this list (Xose?) suggested this, and I agree it'd be
good to have some stress test tools/regression suites. However I can't
help thinking that they'd belong more in Fedora extras.
> o Oprofile "service" for long-term profiling, config file in
> /etc/sysconfig, etc., cron job to generate summaries, optionally mail
> or POST to central database. [Need to consider privacy issues.]
SELinux interaction with oprofile is an interesting problem that needs
to be worked out.
> o CSSC - A base *nix install really ought to have SCCS-compatible tools,
> and the latest version works with BitKeeper's enhanced format.
Sounds reasonable.
> Generally, I see no reason to burden Fedora Core with lots more packages.
> There can readily be "Best of Fedora Extras" CDs for the folks who
don't
> have broadband and need to install huge packages.
It'd be good to have some yum.conf/up2date defaults for 3rd party
repositories included as standard too. Not all of them, but the more
popular ones such as fedora.us
Dave
5:46 p.m.
On Tue, Dec 09, 2003 at 08:37:43PM +0000, Dave Jones wrote:
On Tue, 2003-12-09 at 16:35, Bill Rugolsky Jr. wrote:
> o Ext3 online fs growth (may get merged upstream ...)
This appeared in Arjan's 2.6 RPM, but I chose not to include
it in the rawhide kernel. The reasoning behind this was the
'Stay close to mainline' objective of Fedora.
At some point before FC2 beta1, decisions are going to have to be
made to decide how much we want to deviate away from this goal.
User feedback is an important factor here. A feature 1-2 people want
is far less likely to get included than something dozens of folks
are clamouring for.
On the scale from RH9 kernel <---> "close to mainline", I'd like to
argue for a middle ground for patches that are not intrusive to the point
that they break most other patches. IMHO, the only thing wrong with 100
bugfix or minor enhancement patchlets is that they aren't being merged
into mainline quick enough. But if they are orthogonal, I'd rather
see them in there.
E.g., in earlier Red Hat kernels, rmap, O(1)-sched, and the inode shrink
patches led to frequent patching headaches, because they touched central
parts of the core (VM, scheduler, VFS) all over the place. No joy applying
NFS and other fixes. But I persisted in using the Red Hat kernels as a
base, because I *wanted* the benefits of all of that stabilization work.
The numerous cleanups in 2.5 may have seemingly made this type of thing
less of a problem. (It seems that Linus v. -mm causes fewer headaches
than -ac ever did).
On the specific issue of Ext3 online resizing, I think that if it
is thoroughly tested, it should go into Fedora, even if Andrew Morton
is in no hurry to merge it into 2.6.
- Technically, the patch seems rather safe and unintrusive. The
crucial step -- inform the kernel about the new block groups --
is well-localized.
- Device Mapper is going to make volume management attractive,
if only for the consistent backups and background fsck.
- The other journaling filesystems have it already.
IPMI is part of the standard 2.6 kernel already.
Yup, I meant the userland pieces.
> o Regression Test suite. Ideally, the user could chose to run
> (non-)destructive tests, compare with earlier runs, and optionally
> mail or POST the results (including a hardware description) to a central
> database.
Someone else on this list (Xose?) suggested this, and I agree it'd be
good to have some stress test tools/regression suites. However I can't
help thinking that they'd belong more in Fedora extras.
It probably ought to start in Extras. Eventually putting it in Core and
plugging it during installation/upgrade could have good "social
engineering" consequences. Wouldn't it be nice to have results for
thousands of different configurations in a database?
In years past, Alan Cox acted as that database.
Everyone mailed their problems to Alan Cox, or posted them
on innumerable mail lists. Alan would do pattern recognition across
hundreds or thousands of reports, then chime in with something like
"your foobar IDE drive doesn't work with the B1 revision of the
xyzzy IDE chipset when using bios 2.0. You can work around it by
upgrading to bios 2.0.3 or booting with kernel parameter bar=baz."
Alas, Alan has a life too, and can't always be there to hold our
hands. 8-P
Regards,
Bill Rugolsky
10:07 a.m.
On Tue, 2003-12-09 at 21:37, Dave Jones wrote:
On Tue, 2003-12-09 at 16:35, Bill Rugolsky Jr. wrote:
> o Ext3 online fs growth (may get merged upstream ...)
This appeared in Arjan's 2.6 RPM, but I chose not to include
it in the rawhide kernel. The reasoning behind this was the
'Stay close to mainline' objective of Fedora.
At some point before FC2 beta1, decisions are going to have to be
made to decide how much we want to deviate away from this goal.
User feedback is an important factor here. A feature 1-2 people want
is far less likely to get included than something dozens of folks
are clamouring for.
+1 for ext3 online growth from me, not just from an "I want this"
perspective, but also from an "this will eventually land in the next
RHEL version" POV.
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
11:23 a.m.
On Wed, 2003-12-10 at 16:07, Nils Philippsen wrote:
+1 for ext3 online growth from me, not just from an "I want
this"
perspective, but also from an "this will eventually land in the next
RHEL version" POV.
Not that everything that will be included in future RHEL will appear
in Fedora. The 4g/4g patch being one such example.
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
12:35 p.m.
On Mon, 2003-12-08 at 16:15, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Can we get rid of sendmail
and standardize on a different MTA, such as
postfix? Sendmail should still be part of the distro, but not as a
default MTA. It's way too difficult to configure, and security-wise, it
doesn't compare that well to others.
Also, how about shipping with the Ximianized OOo? It looks much better
than the default, and gives a better impression.
-windi
2:11 p.m.
On Tue, Dec 09, 2003 at 07:35:14PM +0100, Stephan Windischmann wrote:
Can we get rid of sendmail and standardize on a different MTA, such
as
postfix? Sendmail should still be part of the distro, but not as a
default MTA. It's way too difficult to configure, and security-wise, it
doesn't compare that well to others.
Well, sendmail has not been so particularly bad in terms of security,
and it's a lot easier to configure now with m4 -- speaking as someone
who has written .cf files by hand from scratch.
Security-wise, it really hasn't done particularly worse than most daemons
in the recent past.
We can still have a discussion about the default mailer for new
installations. We should probably do it in a different thread,
though -- I'm already getting beat up enough for starting such a
massive thread. :-)
Also, how about shipping with the Ximianized OOo? It looks much
better
than the default, and gives a better impression.
Check the archives, Dan is working on the gnomified OOo code base
along with Ximian folks.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
2:25 p.m.
On Tue, Dec 09, 2003 at 03:11:35PM -0500, Michael K. Johnson wrote:
On Tue, Dec 09, 2003 at 07:35:14PM +0100, Stephan Windischmann
wrote:
> Can we get rid of sendmail and standardize on a different MTA, such as
> postfix? Sendmail should still be part of the distro, but not as a
> default MTA. It's way too difficult to configure, and security-wise, it
> doesn't compare that well to others.
The development tree now contains also "exim". Said to be really easy to setup
and work well. Even postfix can be hard to setup for some cases. ;-)
I am not sure we can move away from the "classic" sendmail app as default MTA,
but we at least open up the discussion and look at the other MTAs.
greetings,
Florian La Roche
2:31 p.m.
Michael K. Johnson wrote:
Well, sendmail has not been so particularly bad in terms of
security,
and it's a lot easier to configure now with m4 -- speaking as someone
who has written .cf files by hand from scratch.
Security-wise, it really hasn't done particularly worse than most daemons
in the recent past.
Sorry, but sendmail still gets security bugs:
"Sendmail 8.12.10 is available; it contains a fix for a critical security
problem discovered by Michal Zalewski. Sendmail urges all users to upgrade
to sendmail 8.12.10. Note: this is a different problem than earlier problems.
If you cannot upgrade to 8.12.10, then you must apply a patch. This patch is
valid for all supported sendmail versions before 8.12.10.
For those not running the open source version, check with your vendor for a
patch. If you use the commercial version from Sendmail, Inc. then please see
the download page."
and
"sendmail 8.12.10 is available (2003-09-17). Unfortunately we were forced to
release this version early without having a chance to coordinate with vendors
that distribute sendmail."
Sendmail 8 should die, it's big ugly old.
They are *rewriting* it: http://www.sendmail.org/~ca/email/sm-9-rfh.html
ZMailer, Postfix ... are _much better_ than the dinosaur.
4:25 p.m.
On Tue, 2003-12-09 at 12:11, Michael K. Johnson wrote:
> Also, how about shipping with the Ximianized OOo? It looks much
better
> than the default, and gives a better impression.
Check the archives, Dan is working on the gnomified OOo code base
along with Ximian folks.
This is great as long as it doesn't stupidly default to saving in MS
formats and crash when saving in native formats, as the Ximian one did
when I tried it (which was a while ago, I admit).
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * * * * Good, fast and cheap: Pick all 3! * * * * * * *
* Naked Ape Consulting http://nakedape.cc *
2:14 p.m.
On 11:35:14 am 12/09/03 Stephan Windischmann <windi(a)myrealbox.com> wrote:
On Mon, 2003-12-08 at 16:15, Michael K. Johnson wrote:
> However, that won't be the ONLY feature of Fedora Core 2. I'd like to
> hear people's wishlists. Not everything will be possible, but it
> would be nice to have a good list from which to pick the
> possibilities, and from which to also pick ideas later for Fedora
Core 3. Can we get rid of sendmail and standardize on a different MTA,
such as postfix? Sendmail should still be part of the distro, but not as
a default MTA. It's way too difficult to configure, and security-wise, it
doesn't compare that well to others.
I agree, though this is likely controversial. FWIW, SUSE uses Postfix by
default.
Didn't Red Hat make a financial investment in Sendmail, Inc.?
Dax Kelson
Guru Labs
3:17 a.m.
Can we get rid of sendmail and standardize on a different MTA, such
as
postfix? Sendmail should still be part of the distro, but not as a
default MTA. It's way too difficult to configure, and security-wise, it
doesn't compare that well to others.
Do whatever you want on the server-side, but I really need sendmail (or
anything that provides the same functionality) installed on workstations
to be able to send mail (I can't use my ISP's SMTP server).
Also, how about shipping with the Ximianized OOo? It looks much
better
than the default, and gives a better impression.
+1
--
Julien Olivier <julo(a)altern.org>
4:57 a.m.
On Tue, 2003-12-09 at 19:35, Stephan Windischmann wrote:
Also, how about shipping with the Ximianized OOo? It looks much
better
than the default, and gives a better impression.
We are. Dan has joined forces with Michael Meeks. Soon, Red Hat, SuSe,
and Ximian Desktop will have the Ximianized OOo. Debian already uses the
Ximian OOo.
The only "proper" build will probably be available from the OOo website
at some stage I can imagine. And the next release of OOo will have an
option to use the Ximianized icon options too.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
3:30 p.m.
New subject: bridging (was Re: Fedora Core 2 wishlists)
I was hoping to come up with a nice patch for initscripts before I
suggested this, but I'd really love to see some support for bridged
interfaces.
I have a trivial /sbin/ifup-pre-local and /sbin/ifdown-local (both
attached, in case anyone is interested) setting everything up for me
now, but I'd love to be able to stop using them.
On a system with these two scripts, this works as
/etc/sysconfig/network-scripts/ifcfg-br0:
DEVICE=br0
BOOTPROTO=static
IPADDR=10.0.0.1
NETMASK=255.255.255.0
ONBOOT=yes
MEMBERS="eth0 wlan0"
BROPTIONS[0]="stp off"
BROPTIONS[1]="setfd 0"
BROPTIONS[2]="sethello 0"
(Both ifcfg-eth0 and ifcfg-wlan0 have ONBOOT set to "no".)
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
11:02 p.m.
New subject: bridging (was Re: Fedora Core 2 wishlists)
Steven Pritchard (steve(a)silug.org) said:
I was hoping to come up with a nice patch for initscripts before I
suggested this, but I'd really love to see some support for bridged
interfaces.
There is support. David Woodhouse stopped nagging me about the
patch, so either it works or he got tired of trying to get me
to fix it. What does the current support not do for you?
Bill
2:03 p.m.
New subject: bridging (was Re: Fedora Core 2 wishlists)
On Wed, Dec 10, 2003 at 12:02:09AM -0500, Bill Nottingham wrote:
There is support. David Woodhouse stopped nagging me about the
patch, so either it works or he got tired of trying to get me
to fix it. What does the current support not do for you?
*sigh*
Perhaps I'll learn to start paying more attention to the rest of the
world before I post to the list.
Honstly, I hadn't noticed that FC1 had been appropriately modified, so
I have no idea how well it works. I'll certainly try it out though.
Sorry about that.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
5:43 p.m.
On Mon, Dec 08, 2003 at 10:15:30AM -0500, Michael K. Johnson wrote:
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists.
OK, I'll bite.
- full IPSEC support
VPN server and client, with easy client setup foo (ifup/down-ipsec
is there, but references racoon which seems not to be included in FC1,
at least I find no *ipsec* or *racoon* RPMs). Please use
SuperFreeSWAN's IKE daemon (pluto), reasons outlined by Dax Kelson
in another mail in this thread.
- SELinux (work already in progress. NICE.)
- XFS support in installer
- mtr with IPv6 support (patches are available)
[and please provide a /usr/bin/mtr -> xmtr symlink]
- support (also in the installer!) for encrypted filesystems
- WaveLAN drivers: madwifi and prism54
http://sourceforge.net/projects/madwifi/
http://www.prism54.org/
Most cards nowadays use the Atheros (madwifi) or Prism chipsets,
otherwise you're really dead in the water for waveLAN under Linux
- Enlightenment, with proper integration into GNOME like it was in
Red Hat Linux 6.2 *sniff*
- barebone install, as already discussed in this thread
- Postfix default MTA, probably get rid of sendmail altogether
- Courier as IMAP4/POP3 daemon with IPv6 and SSL support out-of-the-box,
to replace the other imap/pop server daemons.
Also include maildrop (procmail-like tool which integrates with
Courier's virtual user management) and perhaps squirrelmail (webmail
frontend).
- support secondary addresses for interfaces also for IPv4
(already supported for IPv6 via IPV6_SECONDARIES in the ifcfg files)
- Galeon as lightweight, but still usable and quite stable browser
- syslog-ng (really)
- RRDTOOL, Cricket (network statistics)
- online filesystem resizing (shrinking & expansion)
- l2tpd, L2TP tunneling support (client & server, same as with IPSEC)
Best regards,
Daniel
6:01 p.m.
On Wed, Dec 10, 2003 at 12:43:30AM +0100, Daniel Roesen wrote:
- online filesystem resizing (shrinking & expansion)
Shrinking is difficult -- once a resource is reachable, one must
keep track of who is using it. One will also need a disk
defragmenter. [Andrew Morton did have some patches for 2.4 that did
that by providing a "move this file block" feature for Ext3.]
By contrast, adding resources is almost trivial, because nobody
has a reference to it until it is explicitly made visible.
Regards,
Bill Rugolsky
10:12 p.m.
Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
- Postfix default MTA, probably get rid of sendmail altogether
Don't get rid of sendmail unless you've got something to replace it.
Last I looked, postfix cannot replace sendmail on my servers, although
it is a lot better than qmail (gag!).
What is the bias against sendmail? Don't give me security history; how
many security holes have there been in OpenSSL, OpenSSH, Apache, the
Linux kernel, rsync, etc. over the last couple of years? Now, how many
in sendmail? I don't see people ranting to replace OpenSSH because they
recently had several security releases in less than a week.
Sendmail still happens to be one of the more powerful MTAs around.
--
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.
10:51 p.m.
What is the bias against sendmail? Don't give me security
history; how
many security holes have there been in OpenSSL, OpenSSH, Apache, the
Linux kernel, rsync, etc. over the last couple of years? Now, how many
in sendmail? I don't see people ranting to replace OpenSSH because they
recently had several security releases in less than a week.
that's just it - there is no well tested, well respected, more efficient
and less crufty alternative to openssl and openssh around.
If there was I'd expect you'd have people requesting replacements for
them.
Sendmail still happens to be one of the more powerful MTAs around.
powerful doesn't make something a good idea.
-sv
1:34 a.m.
Le mer 10/12/2003 à 05:12, Chris Adams a écrit :
Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
> - Postfix default MTA, probably get rid of sendmail altogether
Don't get rid of sendmail unless you've got something to replace it.
Last I looked, postfix cannot replace sendmail on my servers, although
it is a lot better than qmail (gag!).
What is the bias against sendmail?
Too hard to configure is the reason I switched to postfix + cyrus imap
I'm interested in why postfix can't replace sendmail on your servers?
Tony Grant
--
WWW.tgds.net | Logiciels de gestion de centre d'art | Hébergement de
bases de données en ligne | hush - ordinateurs silencieux pour
bibliothèques, documentations et bureaux
3:08 a.m.
On Wed, 2003-12-10 at 08:34, tony wrote:
Le mer 10/12/2003 à 05:12, Chris Adams a écrit :
> Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
> > - Postfix default MTA, probably get rid of sendmail altogether
>
> Don't get rid of sendmail unless you've got something to replace it.
> Last I looked, postfix cannot replace sendmail on my servers, although
> it is a lot better than qmail (gag!).
>
> What is the bias against sendmail?
Too hard to configure is the reason I switched to postfix + cyrus imap
Also, it's a lot easier to run Postfix in a chroot jail.
As you, I switched back ago to Postfix + Cyrus IMAP + Kerberos.
2:47 a.m.
Le mer 10/12/2003 à 05:12, Chris Adams a écrit :
Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
> - Postfix default MTA, probably get rid of sendmail altogether
Don't get rid of sendmail unless you've got something to replace it.
Last I looked, postfix cannot replace sendmail on my servers, although
it is a lot better than qmail (gag!).
What is the bias against sendmail? Don't give me security history; how
many security holes have there been in OpenSSL, OpenSSH, Apache, the
Linux kernel, rsync, etc. over the last couple of years?
These examples do not have credible alternatives with a better history.
sendmail has.
--
Nicolas Mailhot
7:32 a.m.
On Tue, 9 Dec 2003, Chris Adams wrote:
Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
> - Postfix default MTA, probably get rid of sendmail altogether
Don't get rid of sendmail unless you've got something to replace it.
Last I looked, postfix cannot replace sendmail on my servers, although
it is a lot better than qmail (gag!).
Out of curiosity, why not?
What is the bias against sendmail? Don't give me security
history; how
many security holes have there been in OpenSSL, OpenSSH, Apache, the
Linux kernel, rsync, etc. over the last couple of years? Now, how many
in sendmail? I don't see people ranting to replace OpenSSH because they
recently had several security releases in less than a week.
Postfix is a viable alternative to sendmail with a much better security
history and architecture. These other projects don't have secure usable
replacements.
later,
chris
7:41 a.m.
On Wed, 2003-12-10 at 09:32, Chris Ricker wrote:
On Tue, 9 Dec 2003, Chris Adams wrote:
> Once upon a time, Daniel Roesen <dr(a)cluenet.de> said:
> > - Postfix default MTA, probably get rid of sendmail altogether
>
> Don't get rid of sendmail unless you've got something to replace it.
> Last I looked, postfix cannot replace sendmail on my servers, although
> it is a lot better than qmail (gag!).
Out of curiosity, why not?
> What is the bias against sendmail? Don't give me security history; how
> many security holes have there been in OpenSSL, OpenSSH, Apache, the
> Linux kernel, rsync, etc. over the last couple of years? Now, how many
> in sendmail? I don't see people ranting to replace OpenSSH because they
> recently had several security releases in less than a week.
Postfix is a viable alternative to sendmail with a much better security
history and architecture. These other projects don't have secure usable
replacements.
I think Postfix is pretty much the best alternative since it even has a
sendmail command (called the Postfix to Sendmail compatibility
interface) so programs that sends mail using sendmail will still work.
I'm not aware of any other MTA that can replace sendmail in this way,
though I could be wrong...
Jean-Rene Cormier
7:57 a.m.
On Wed, 2003-12-10 at 13:41, Jean-Rene Cormier wrote:
I think Postfix is pretty much the best alternative since it even has
a
sendmail command (called the Postfix to Sendmail compatibility
interface) so programs that sends mail using sendmail will still work.
I'm not aware of any other MTA that can replace sendmail in this way,
though I could be wrong...
Most MTAs have some degree of sendmail command line compatibility simply
because its the historic unix way of mail injection - however since its
also evolved and never been documented its also interesting to implement
:-(
Exim can be used as a drop in replacement for sendmail (including
handling aliases & .forwards, but the config is significantly
different).
I'd look favourably on the idea of having the default default (as in
absolutely no questions asked on install) MTA be something that does no
local delivery at all, but is intended to punt everything to your
company or ISP smarthost.
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham(a)InTechnology.co.uk ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
9:01 a.m.
Once upon a time, Chris Ricker <kaboom(a)gatech.edu> said:
On Tue, 9 Dec 2003, Chris Adams wrote:
> Don't get rid of sendmail unless you've got something to replace it.
> Last I looked, postfix cannot replace sendmail on my servers, although
> it is a lot better than qmail (gag!).
Out of curiosity, why not?
Milter is probably the biggest reason at the moment. I filter 1000
spams a minute with a multi-server setup using milter (sendmail is
running on several servers and the milter server is on another server).
Also, I have some heavily tuned custom configs. Can postfix allow
multiple DNSBLs to be merged into one (with different response code) to
cut down on DNS requests, and allow some to reject before RCPT TO and
some after?
I also know of people that still use UUCP.
Postfix is a viable alternative to sendmail with a much better
security
history and architecture. These other projects don't have secure usable
replacements.
There's plenty of other web servers and there are a couple of other SSH
servers IIRC.
There've only been a few problems with sendmail in recent years, and
those have been found by people examining the code closer than ever. I
think that sendmail is one of the more scrutinized pieces of code
around.
--
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:17 a.m.
Chris Adams wrote:
Once upon a time, Chris Ricker <kaboom(a)gatech.edu> said:
>On Tue, 9 Dec 2003, Chris Adams wrote:
>
>>Don't get rid of sendmail unless you've got something to replace it.
>>Last I looked, postfix cannot replace sendmail on my servers, although
>>it is a lot better than qmail (gag!).
>
>Out of curiosity, why not?
Milter is probably the biggest reason at the moment. I filter 1000
spams a minute with a multi-server setup using milter (sendmail is
running on several servers and the milter server is on another server).
Also, I have some heavily tuned custom configs. Can postfix allow
multiple DNSBLs to be merged into one (with different response code) to
cut down on DNS requests, and allow some to reject before RCPT TO and
some after?
Why not just block this garbage at the smtp port and stop all this silly
post-receipt processing? Postfix can do this!
Read up on header_checks, body_checks, and mime_checks with postfix!
RBL stuff works in postfix the same way it works in sendmail.
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
10:28 a.m.
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
Why not just block this garbage at the smtp port and stop all this
silly
post-receipt processing? Postfix can do this!
Because that is not acceptable. First of all, anyone that blocks email
to postmaster and abuse email is violating RFCs. Second, not all of our
users want the same spam filtering; some opt out of Brightmail (which is
what I'm talking to with a milter) for example. Brightmail works by
sidelining spam, so that if there is a false positive, the user can
fetch the message via a web interface. Content based checks cannot be
done at the "smtp port"; you have to accept the message and then process
it.
Telling someone that what they are doing is "silly" is not exactly a way
to sway their opinion.
RBL stuff works in postfix the same way it works in sendmail.
DNSBLs (RBL is a trademark and should only be used when talking about
the MAPS RBL) don't work by default in sendmail the way I described, but
I have my own sendmail rulesets that do, and it only took about a half
dozen lines (plus one for each DNSBL used to return an informational
error message specific to that DNSBL).
I'm not arguing that maybe sendmail shouldn't be the default; I'm just
tired of everyone bashing sendmail based on 5+ year old information. I
do think if the default is changed it should be to a "queue/relay only"
SMTP server, not postfix, exim, or whatever.
--
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:33 p.m.
Chris Adams wrote:
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
>Why not just block this garbage at the smtp port and stop all this silly
>post-receipt processing? Postfix can do this!
Because that is not acceptable. First of all, anyone that blocks email
to postmaster and abuse email is violating RFCs.
I don't think I have ever recommended that in a corporate environment
(nor was I here) and that is one of the things that is problematic with
access checks themselves as they (if implemented that way) may block
mail based upon it's point of origin regardless of sender or content. I
much prefer to attack the offending content as opposed to the offending
ip address, host, or domain.
Second, not all of our
users want the same spam filtering; some opt out of Brightmail (which is
what I'm talking to with a milter) for example. Brightmail works by
sidelining spam, so that if there is a false positive, the user can
fetch the message via a web interface. Content based checks cannot be
done at the "smtp port"; you have to accept the message and then process
it.
Content based checks *ARE* done with postfix at the SMTP port and that
was my point... using postfix I can certainly block via host, email
address, network ip or range the same as I can with sendmail but I can
also block content at the SMTP port using mime_checks, header_checks, or
body_checks using regexp or pcre. I have a suspicion that the fact you
are unaware of that capability is *why* you prefer sendmail. :-)
Telling someone that what they are doing is "silly" is not
exactly a way
to sway their opinion.
Sorry... I wasn't denigrating you (just the action which, to me appears
artifically self limiting) so no offense intended.
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
12:48 p.m.
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
Content based checks *ARE* done with postfix at the SMTP port and
that
was my point... using postfix I can certainly block via host, email
address, network ip or range the same as I can with sendmail but I can
also block content at the SMTP port using mime_checks, header_checks, or
body_checks using regexp or pcre. I have a suspicion that the fact you
are unaware of that capability is *why* you prefer sendmail. :-)
Okay, I guess I don't know what you mean by "at the SMTP port".
--
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:14 p.m.
Chris Adams wrote:
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
>Content based checks *ARE* done with postfix at the SMTP port and that
>was my point... using postfix I can certainly block via host, email
>address, network ip or range the same as I can with sendmail but I can
>also block content at the SMTP port using mime_checks, header_checks, or
>body_checks using regexp or pcre. I have a suspicion that the fact you
>are unaware of that capability is *why* you prefer sendmail. :-)
Okay, I guess I don't know what you mean by "at the SMTP port".
inbound mail ----- > regexp/pcre at port 25 [pre-receipt match will bounce]
It is about that simple.
URL http://moongroup.com/outbound.config shows a postfix config which
does this.
Expression matches could look like this:
/etc/postfix/header_checks:
/^Subject: .*Viagra/ REJECT
Reference: http://www.postfix.org/uce.html#header_checks
/etc/postfix/body_checks:
/This Is A One[-\ ]*Time (email|e-mail|mailing|offer)/ REJECT
Reference: http://www.postfix.org/uce.html#body_checks
/etc/postfix/mime_header_checks:
/name=[^>]*your_details.zip/ REJECT SecuritySage mail filters have
determined that your email appears to be infected with the Sobig virus.
Please see
http://securityresponse.symantec.com/avcenter/venc/data/w32.sobig.e@mm.html
for information about the virus.
Reference: mime checks are actually an extension of existing checks
executed via config... not an added capability.
So a match on one of these expressions would reject the mail and
delivery is never attempted, nor is the mail accepted on the host.
body_checks rejection sample:
Sep 28 21:03:30 varmint postfix/cleanup[12671]: 30FA2DA60D: reject: body
ver-co.com/rm/remove.php"><font color=3D"#0000FF"
size=3D"1"
face=3D"Arial"= from unknown[200.180.154.68];
from=<frankie(a)gorgeousgeorge.biz> to=<xxxxx(a)moongroup.com> proto=ESMTP
helo=<mail.focuspro.com.br>
mime or header_checks rejection sample:
Sep 29 13:18:44 varmint postfix/cleanup[30994]: 63C23DA60C: reject:
header Content-Type: application/octet-stream;??name=SRC.scr from
smtp3.arnet.com.ar[200.45.191.14]; from=<iactucuman(a)arnet.com.ar>
to=<xxxxxx(a)xfce.org> proto=SMTP helo=<smtp3.arnet.com.ar>: Potentially
dangerous file attachment
header_checks rejection samples:
Dec 4 16:43:26 varmint postfix/cleanup[24627]: 9A09DDA4BF: reject:
header Subject: bsi The lowest priced Sildenafil Citrate (Viagra) for
xxxxx(a)xfce.org. ore from ACB9EB9B.ipt.aol.com[172.185.235.155];
from=<ndsuree(a)iname.com> to=<xxxxx(a)xfce.org> proto=ESMTP
helo=<ACB9EB9B.ipt.aol.com>
Sep 29 04:50:50 varmint postfix/cleanup[21880]: EB9F9DA4BF: reject:
header Subject: Merchant Accounts Increase Sales fxje vghnnt c from
unknown[203.131.110.14]; from=<Pmcxa4eR05Q3(a)esuperhotwebdeals.com>
to=<xxxxx(a)moongroup.com> proto=SMTP helo=<adsl-131.110.14.info.com.ph>
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
1:54 p.m.
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
inbound mail ----- > regexp/pcre at port 25 [pre-receipt match
will bounce]
I see - you do all your content checks in your MTA. I don't, nor do I
want to. First of all, I use Brightmail, which is a separate software
package/service for spam filtering. Since I use milter to talk to it,
I can run Brightmail on a separate server to spread the load around so
the SMTP servers don't have to spend CPU scanning mail.
Also, not all spam checks are just regular expressions; there are a lot
of scoring techniques in use (you can score on the headers in sendmail,
but sendmail doesn't look in the message body). Brightmail also tries
to decode some things spammers use to obfuscate URLs and such.
--
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:04 p.m.
Chris Adams wrote:
Once upon a time, Chuck Mead <csm(a)redhat.com> said:
>inbound mail ----- > regexp/pcre at port 25 [pre-receipt match will bounce]
I see - you do all your content checks in your MTA. I don't, nor do I
want to. First of all, I use Brightmail, which is a separate software
package/service for spam filtering. Since I use milter to talk to it,
I can run Brightmail on a separate server to spread the load around so
the SMTP servers don't have to spend CPU scanning mail.
Also, not all spam checks are just regular expressions; there are a lot
of scoring techniques in use (you can score on the headers in sendmail,
but sendmail doesn't look in the message body). Brightmail also tries
to decode some things spammers use to obfuscate URLs and such.
Yup... I understand what you're doing just fine. I guess the reason I
prefer this is two fold....
1. It puts the load on the sender instead of me.
2. Pre-recipt filters decrease the over all load on my machine which
allows me to process more mail per day.
One thing I think is useful is a blend of different techniques using
different MTA's and the best of their capabilities together to architect
an overall all mail system which is "best of breed" but that's going far
afield for Fedora and this discussion.
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
2:08 a.m.
On Wed, 10 Dec 2003 14:14:28 -0500
Chuck Mead <csm(a)redhat.com> wrote:
Chris Adams wrote:
> Once upon a time, Chuck Mead <csm(a)redhat.com> said:
cool, your mail was filtered here, because of a x-warning i n sylpheed:
"Message contains advertised URL"
;-)
--
Nine (not 9)
Never trust a hippie
7:17 a.m.
For the wishlist:
- Rewrite the tools that use gtk1 to use gtk2, e.g. usbview
Maybe include gimp-1.3 instead of gimp-1.2. I don't know
how this fill affect gimp-print and sane though
- Just experimented with an usb memory stick; adapt magicdev
and the usb subsystem so that a memory stick is automatically
mounted just like a cdrom.
--
Gérard Milmeister
Tannenrauchstrasse 35
8038 Zürich
gemi(a)bluewin.ch
9:32 a.m.
On Wed, 10 Dec 2003, Chris Adams wrote:
Milter is probably the biggest reason at the moment. I filter 1000
spams a minute with a multi-server setup using milter (sendmail is
running on several servers and the milter server is on another server).
Okay. Postfix certainly doesn't support milter, though the equivalent can be
done other ways. There have been noises about writing a milter-compatible
extension to Postfix, but AFAIK no one's scratched that itch b/c so far it's
just been easier to do things Postfix-style instead....
Also, I have some heavily tuned custom configs. Can postfix allow
multiple DNSBLs to be merged into one (with different response code) to
cut down on DNS requests, and allow some to reject before RCPT TO and
some after?
Assuming I'm following how you're doing this, yes.
I also know of people that still use UUCP.
Postfix can do uucp.
> Postfix is a viable alternative to sendmail with a much better
security
> history and architecture. These other projects don't have secure usable
> replacements.
There's plenty of other web servers and there are a couple of other SSH
servers IIRC.
Not that are as usable and any more secure. SSH alternatives that are open
source are worse than OpenSSH. Other web servers don't support all the
modules Apache does....
There've only been a few problems with sendmail in recent years,
and
those have been found by people examining the code closer than ever. I
think that sendmail is one of the more scrutinized pieces of code
around.
Yes. The fact that it's been scrutinized for 25 years now and people are
still unearthing remote remote exploits when they examine it certainly does
say something about its design and coding style. I'm not certain that's the
point you were trying to make, though ;-)
later,
chris
10:37 a.m.
Once upon a time, Chris Ricker <kaboom(a)gatech.edu> said:
Okay. Postfix certainly doesn't support milter, though the
equivalent can be
done other ways. There have been noises about writing a milter-compatible
extension to Postfix, but AFAIK no one's scratched that itch b/c so far it's
just been easier to do things Postfix-style instead....
I've seen people talk about it a few times, but nobody has ever done it
(and I don't have the time to investigate it or do it myself).
> Also, I have some heavily tuned custom configs. Can postfix
allow
> multiple DNSBLs to be merged into one (with different response code) to
> cut down on DNS requests, and allow some to reject before RCPT TO and
> some after?
Assuming I'm following how you're doing this, yes.
What I do is this: to reduce DNS lookups and improve DNSBL performance,
I use rbldnsd (which would be a nice addition to FC, but I guess is more
of an Extras kind of thing). I merge all the DNSBLs I use into one zone
(we do some type of zone transfer for all of them), with a different IP
returned for each zone (i.e. an IP in the MAPS RBL returns 127.0.0.2, an
IP in the MAPS DUL returns 127.0.0.3, etc.). That way sendmail only has
to do one DNS lookup to get DNSBL information.
I also wrote a patch to the sendmail DNS map that allows it to use a
different set of nameservers for a DNS map, so sendmail doesn't even
talk to the normal nameservers for DNSBL info (this has been submitted
to sendmail, so hopefully it will show up in a future release).
I use sendmail's delay_checks feature so that not all addresses get spam
checking (postmaster and abuse don't for example), but I'm switching the
primary MXes to have some DNSBLs reject for all addresses (so virus
infected cable modem computers spewing spam get rejected sooner to lower
the load on the primaries; this will block postmaster and abuse on the
primaries but I won't do this on secondary MXes).
Not that are as usable and any more secure. SSH alternatives that are
open
source are worse than OpenSSH. Other web servers don't support all the
modules Apache does....
My point is that postfix is also not necessarily as usable as sendmail,
and I think sendmail's security is just about as good as anyone else's
these days.
--
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.
5:41 p.m.
On Wed, 10 Dec 2003, Chris Adams wrote:
What I do is this: to reduce DNS lookups and improve DNSBL
performance,
I use rbldnsd (which would be a nice addition to FC, but I guess is more
of an Extras kind of thing). I merge all the DNSBLs I use into one zone
(we do some type of zone transfer for all of them), with a different IP
returned for each zone (i.e. an IP in the MAPS RBL returns 127.0.0.2, an
IP in the MAPS DUL returns 127.0.0.3, etc.). That way sendmail only has
to do one DNS lookup to get DNSBL information.
I also wrote a patch to the sendmail DNS map that allows it to use a
different set of nameservers for a DNS map, so sendmail doesn't even
talk to the normal nameservers for DNSBL info (this has been submitted
to sendmail, so hopefully it will show up in a future release).
I use sendmail's delay_checks feature so that not all addresses get spam
checking (postmaster and abuse don't for example), but I'm switching the
primary MXes to have some DNSBLs reject for all addresses (so virus
infected cable modem computers spewing spam get rejected sooner to lower
the load on the primaries; this will block postmaster and abuse on the
primaries but I won't do this on secondary MXes).
Okay, that's about where I thought you were going. That configuration is
doable with Postfix.
> Not that are as usable and any more secure. SSH alternatives
that are open
> source are worse than OpenSSH. Other web servers don't support all the
> modules Apache does....
My point is that postfix is also not necessarily as usable as sendmail,
and I think sendmail's security is just about as good as anyone else's
these days.
I can't think of anything significant sendmail can do (other than deliver
mail to /var/mail/root ;-) which postfix can't do. It might require you to
do it in a different fashion (such as your milter configuration), but
they're very similar in terms of feature set these days.
That said, I've never seen Brightmail used with Postfix and discussions
about it on the Postfix mailing list don't suggest anyone else has either.
The features Brightmail offers are available in other products which are
commonly used with Postfix and which interface in other ways, and they tend
to be preferred by Postfix users for technical and cost reasons. I presume
Brightmail has non-milter hooks and is usable w/ Postfix, but it might not.
later,
chris
10:14 p.m.
On Wed, 2003-12-10 at 07:01, Chris Adams wrote:
> Out of curiosity, why not?
Milter is probably the biggest reason at the moment. I filter 1000
spams a minute with a multi-server setup using milter (sendmail is
running on several servers and the milter server is on another server).
Postfix has a 'content_filter' mechanism which acts as an SMTP proxy;
the receiving server can be anywhere, if your filtering server supports
it. With amavisd-new, you have to use Sendmail in a dual-server setup
and not Milter if you want to be able modify the message (like adding
*SPAM* to the header); the Postfix content_filter mechanism is much
cleaner and seems less hackish on a single-host setup. The
content_filter can also be configured per-transport.
Also, I have some heavily tuned custom configs. Can postfix allow
multiple DNSBLs to be merged into one (with different response code) to
cut down on DNS requests, and allow some to reject before RCPT TO and
some after?
Like, you've imported the zones from the RBLs and serve them locally?
Sure, don't see why not.
I also know of people that still use UUCP.
I've heard of such people. Apparently there are also people using
dial-in BBSes and running DOS applications.
> Postfix is a viable alternative to sendmail with a much better
security
> history and architecture. These other projects don't have secure usable
> replacements.
There's plenty of other web servers and there are a couple of other SSH
servers IIRC.
'lsh' is the only replacement SSH server I know of, but from what I've
heard it's not really usable yet. (Aside, perhaps, from proprietary
versions, like F-Secure's or Cisco's.)
There've only been a few problems with sendmail in recent years,
and
those have been found by people examining the code closer than ever. I
think that sendmail is one of the more scrutinized pieces of code
around.
Architecture. You can audit code until your eyes bleed, but without a
proper architecture with security in mind, you're just waiting until
someone finds a clever way of exploiting something that hadn't been
thought of or of exploiting some part of the underlying framework the
application is built on. Proper design is a hedge against that and
limits the scope of damage even when a vulnerability if found.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Naked Ape Consulting http://nakedape.cc *
5:17 a.m.
On Wed, 2003-12-10 at 16:01, Chris Adams wrote:
Once upon a time, Chris Ricker <kaboom(a)gatech.edu> said:
> On Tue, 9 Dec 2003, Chris Adams wrote:
> > Don't get rid of sendmail unless you've got something to replace it.
> > Last I looked, postfix cannot replace sendmail on my servers, although
> > it is a lot better than qmail (gag!).
>
> Out of curiosity, why not?
[...]
I also know of people that still use UUCP.
I'm using UUCP with Postfix just fine (on my machine at home). IMO the
best solution for having an own domain on dialup.
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
11:06 p.m.
Daniel Roesen (dr(a)cluenet.de) said:
- full IPSEC support
VPN server and client, with easy client setup foo (ifup/down-ipsec
is there, but references racoon which seems not to be included in FC1,
at least I find no *ipsec* or *racoon* RPMs). Please use
SuperFreeSWAN's IKE daemon (pluto), reasons outlined by Dax Kelson
in another mail in this thread.
racoon is currently in the devel tree. Patches for ifup/ifdown-ipsec
to support pluto accepted. :)
- WaveLAN drivers: madwifi and prism54
http://sourceforge.net/projects/madwifi/
That driver includes binary-only components.
http://www.prism54.org/
Most cards nowadays use the Atheros (madwifi) or Prism chipsets,
otherwise you're really dead in the water for waveLAN under Linux
Get the driver upstream! :)
- Enlightenment, with proper integration into GNOME like it was in
Red Hat Linux 6.2 *sniff*
-> extras, most likely. The greater demand for the !KDE !GNOME wm
is for XFCE, at the moment.
- Courier as IMAP4/POP3 daemon with IPv6 and SSL support
out-of-the-box,
to replace the other imap/pop server daemons.
Also include maildrop (procmail-like tool which integrates with
Courier's virtual user management) and perhaps squirrelmail (webmail
frontend).
Yes, we'll perhaps include squirrelmail as a followon to the
inclusion of squirrelmail in RHL 8.0, 9, and FC1. :)
Seriously, we're already looking at Cyrus, so I doubt that we'd ship
courier as well in Core.
Bill
11:19 p.m.
New subject: tsclient
I have updated the tsclient package to 0.132. I believe that it now has
addressed the issues in the posted bugs: 107857, 110061, and 99570. I am
wondering if there were some people I could to test the RDP and RDPv5
connections. I am lacking a MS Terminal server at this point in time.
Mike
--
It's perfectly fine to use the name of you pet or child as a password.
How ever, for the sake of security, make sure the names of all your pets
and children contain several non-alphanumeric characters.
2:39 a.m.
On Wed, Dec 10, 2003 at 12:06:51AM -0500, Bill Nottingham wrote:
> - WaveLAN drivers: madwifi and prism54
> http://sourceforge.net/projects/madwifi/
That driver includes binary-only components.
Well, have fun trying to convince the FCC... as far as I understand
the madwifi folks in their tarball README, all other drivers might
be in FCC rules violation:
<cite>
The ath_hal module contains the Atheros Hardware Access Layer (HAL).
This code manages much of the chip-specific operation of the driver.
The HAL is provided in a binary-only form in order to comply with FCC
regulations. In particular, a radio transmitter can only be operated at
power levels and on frequency channels for which it is approved. The
FCC
requires that a software-defined radio cannot be configured by a user
to operate outside the approved power levels and frequency channels.
This makes it difficult to open-source code that enforces limits on
the power levels, frequency channels and other parameters of the radio
transmitter. See
http://ftp.fcc.gov/Bureaus/Engineering_Technology/Orders/2001/fcc01264.pdf
for the specific FCC regulation. Because the module is provided in a
binary-only form it is marked "Proprietary"; this means when you load
it you will see messages that your system is now "tainted".
</cite>
So, unless FCC changes rules or the Atheros people decide to
deliberately violate those, we might never see support for those cards
(and probably all others if they are also found to be relevant)
will never exist without always patching vendor kernels.
Rejecting binary drivers because vendors want to keep secrets is
one holy war I can understand and support. But trying to change
(understandable) FCC rules (and actually I guess german regulatory
rules are quite similar in this regard) is probably a lost battle
before starting. FCC doesn't care at all about inconvenience of Linux
users with WLAN cards.
> http://www.prism54.org/
> Most cards nowadays use the Atheros (madwifi) or Prism chipsets,
> otherwise you're really dead in the water for waveLAN under Linux
Get the driver upstream! :)
I'm not the driver author, so not in any position to run uphill for
this. :-)
Seriously, we're already looking at Cyrus, so I doubt that
we'd ship
courier as well in Core.
Why Cyrus?
It has:
- a proprietary storage format (Courier uses Maildir)
- it has no IPv6 support (only in beta releases, Courier since years)
I don't think that "we're looking at Cyrus, so we don't look at others
anymore" is a rational approach, esp. since Courier looks superior
to me for all average users (perhaps not for the 1-million-mailboxes
shops, but those install and hack up Cyrus themselves). :-)
Please reconsider. :-)
Best regards,
Daniel
5:44 p.m.
Well, have fun trying to convince the FCC... as far as I understand
the madwifi folks in their tarball README, all other drivers might
be in FCC rules violation:
Hardly. The other vendors put their controls in the firmware or used
crypto tricks. In the case of the madwifi cards such things are merely
demonstrations of the value of hindsight but the card isnt open source
so its driver stays outside fedora.
11:44 p.m.
On Wed, 2003-12-10 at 00:39, Daniel Roesen wrote:
It has:
- a proprietary storage format (Courier uses Maildir)
It's no more proprietary than an MTA's mail spool or an SQL database's
disk storage. The notion of proprietary is only a question if you
expect multiple applications to access the data, for which Cyrus
expressly not designed; otherwise, there are questions of locking issues
and enhancability. With the Cyrus storage, it uses a database for
header indexes (which can be Berkeley DB, although skiplist is
preferable since it was designed for IMAP-specific operations and to
avoid the number of buglets that seem to plague BDB) and for the
'squatter' indexes, which allows very fast full-text searching on
messages. The actual messages are stored in single files. The
"application-specific" storage also allows them to implement some of the
extended capabilities defined in later IMAP RFCs.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
11:56 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 10 Dec 2003, Daniel Roesen wrote:
The HAL is provided in a binary-only form in order to comply with
FCC regulations. In particular, a radio transmitter can only be
operated at power levels and on frequency channels for which it is
approved. The FCC requires that a software-defined radio cannot be
configured by a user to operate outside the approved power levels
and frequency channels. This makes it difficult to open-source code
that enforces limits on the power levels, frequency channels and
other parameters of the radio transmitter.
AIUI, there are plenty of 'hacks' available for the Windows binary
drivers to twiddle radio settings. Ie binary only is no protection /
this shouldnt be an impediment to open-source drivers.
(understandable) FCC rules (and actually I guess german regulatory
rules are quite similar in this regard)
Possibly. They were restrictive for ISDN at least, yet we still had
open-source drivers. The driver(s) were 'certified' and gave a
warning when loaded if they (it) suspected tampering/modification.
Why Cyrus?
It has:
- a proprietary storage format (Courier uses Maildir)
not true. the message texts are per file. various indexes are kept in
configurable (and open) DB formats.
Best regards,
Daniel
regards,5A
--
Paul Jakma paul(a)clubi.ie paul(a)jakma.org Key ID: 64A2FF6A
warning: do not ever send email to spam(a)dishone.st
Fortune:
Owe no man any thing...
-- Romans 13:8
8:36 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Sun, Dec 14, 2003 at 05:56:08AM +0000, Paul Jakma wrote:
> Why Cyrus?
>
> It has:
> - a proprietary storage format (Courier uses Maildir)
not true. the message texts are per file. various indexes are kept in
configurable (and open) DB formats.
OK, let me rephrase: which MUA can I use to easily edit the mailboxes
of a Cyrus user?
Regards,
Daniel
11:02 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Sun, 2003-12-14 at 06:36, Daniel Roesen wrote:
OK, let me rephrase: which MUA can I use to easily edit the
mailboxes
of a Cyrus user?
I don't know what you mean by "edit the mailboxes", but if you want to
create and destroy mailboxes, move messages around, and so on, Evolution
works OK with Cyrus for these kinds of tasks.
I wouldn't touch Cyrus again unless someone was holding a gun to my
head, though.
<b
6:05 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Mon, Dec 15, 2003 at 09:02:48AM -0800, Bryan O'Sullivan wrote:
> OK, let me rephrase: which MUA can I use to easily edit the
mailboxes
> of a Cyrus user?
I don't know what you mean by "edit the mailboxes",
Accessing the mailboxes via filesystem, viewing/deleting/copying/etc.
mails in them without having an operational IMAP/POP server. Something
a mail system admin might need to do.
With Maildir, I can use pretty much every somewhat modern MUA like mutt.
but if you want to
create and destroy mailboxes, move messages around, and so on, Evolution
works OK with Cyrus for these kinds of tasks.
Yeah, but for you own user and via IMAP4. Mail server storage format
becomes especially important if this is not available for whatever
reasons.
I've seen more than one IMAP/POP server having bugs where special
mails in their mailboxes made the daemon dying when user tries to
access his mailbox. Then the admin needs to identify and isolate/
delete the "offending" mail manually, without IMAP/POP. There, you
want to use your command line MUA. :-)
Regards,
Daniel
6:20 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Mon, 2003-12-15 at 16:05, Daniel Roesen wrote:
Yeah, but for you own user and via IMAP4. Mail server storage format
becomes especially important if this is not available for whatever
reasons.
Actually, the IMAP protocol and Cyrus supports proxy authentication,
where you authenticate as an admin user ('cyrus' usually) and work as if
you were that user. Any c-client-based client should support it,
although it's been reported that PHP doesn't.
I've seen more than one IMAP/POP server having bugs where
special
mails in their mailboxes made the daemon dying when user tries to
access his mailbox. Then the admin needs to identify and isolate/
delete the "offending" mail manually, without IMAP/POP. There, you
want to use your command line MUA. :-)
I've never seen Cyrus die like this; I've seen it reject messages with
nulls, but it rejects them at deliver-time, not when it's reading them.
Even if some obscure problem does crop up, you can always delete the
message in the backend storage and run 'reconstruct' to rebuild the
indexes.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Naked Ape Consulting http://nakedape.cc *
4:57 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Tue, 2003-12-16 at 01:05, Daniel Roesen wrote:
With Maildir, I can use pretty much every somewhat modern MUA like
mutt.
I'll vote against Maildir by default. PINE for instance won't read
Maildir conveniently (either you patch it, or you get PINE to read over
IMAP).
Other MUA's don't too, iirc. elm iirc, doesn't too.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
5:51 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, Dec 17, 2003 at 11:57:44AM +0100, Colin Charles wrote:
On Tue, 2003-12-16 at 01:05, Daniel Roesen wrote:
> With Maildir, I can use pretty much every somewhat modern MUA like mutt.
I'll vote against Maildir by default. PINE for instance won't read
Maildir conveniently (either you patch it, or you get PINE to read over
IMAP).
Personally, I think that pine should be left out. It is starting to develop
quite a track record as a security threat. I can think of at least 2 problems
in the last several years that allow people to run code on your system from a
malformed email.
--
Mark Lane, CET mailto:mark@harddata.com
Hard Data Ltd. http://www.harddata.com
T: 01-780-456-9771 F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--
1:56 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 2003-12-17 at 03:51, Mark Lane wrote:
Personally, I think that pine should be left out. It is starting to
develop
quite a track record as a security threat. I can think of at least 2 problems
in the last several years that allow people to run code on your system from a
malformed email.
Pine was dropped as of at least FC1; possibly RH9.
Wil
--
Wil Cooley wcooley(a)nakedape.cc
Naked Ape Consulting http://nakedape.cc
* * * * Linux, UNIX, Networking and Security Solutions * * * *
* Tired of spam and viruses in your e-mail? Get the *
* Naked Ape Mail Defender! http://nakedape.cc/r/maildefender *
5:13 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, Dec 17, 2003 at 04:51:57AM -0700, Mark Lane wrote:
Personally, I think that pine should be left out. It is starting to
develop
quite a track record as a security threat. I can think of at least 2 problems
in the last several years that allow people to run code on your system from a
malformed email.
Pine isnt in Fedora anyway 8)
6:45 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 2003-12-17 at 18:13, Alan Cox wrote:
Pine isnt in Fedora anyway 8)
I've never liked pine, but I've always found pico to be quite useful,
any chance of it being included, or are there licenese problems with
including it at all?
-sb
6:46 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, Dec 17, 2003 at 07:45:46PM -0500, Stan Bubrouski wrote:
On Wed, 2003-12-17 at 18:13, Alan Cox wrote:
> Pine isnt in Fedora anyway 8)
I've never liked pine, but I've always found pico to be quite useful,
any chance of it being included, or are there licenese problems with
including it at all?
See "nano" instead
7:34 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 2003-12-17 at 19:46, Alan Cox wrote:
On Wed, Dec 17, 2003 at 07:45:46PM -0500, Stan Bubrouski wrote:
> On Wed, 2003-12-17 at 18:13, Alan Cox wrote:
> > Pine isnt in Fedora anyway 8)
>
> I've never liked pine, but I've always found pico to be quite useful,
> any chance of it being included, or are there licenese problems with
> including it at all?
See "nano" instead
Just checked it out, it will do nicely. Thanks Alan :)
-sb
11 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
Stan Bubrouski wrote:
On Wed, 2003-12-17 at 18:13, Alan Cox wrote:
>Pine isnt in Fedora anyway 8)
I've never liked pine, but I've always found pico to be quite useful,
any chance of it being included, or are there licenese problems with
including it at all?
If you miss pico then use nano... it *IS* included.
--
Chuck Mead <csm(a)redhat.com>
Instructor II, GLS
Disclaimer: "It's Thursday and my name is Locutus of B0rk!"
Addendum: "Bwahahaha! Fire up the orbital mind-control lasers!"
10:49 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, Dec 17, 2003 at 11:57:44AM +0100, Colin Charles wrote:
I'll vote against Maildir by default. PINE for instance won't
read
Maildir conveniently (either you patch it, or you get PINE to read over
IMAP).
Other MUA's don't too, iirc. elm iirc, doesn't too.
And both pine and elm are long gone from the distribution.
Personally, I like the idea of moving to Maildir by default. All of
the mail programs included in Fedora now can either do Maildir or
IMAP, and it wouldn't be hard to switch for those who don't like the
default.
If OpenGroupware (or something like it, Kolab for example) is
included, you'd have an Exchange killer out of the box.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
11:28 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 17 Dec 2003, Steven Pritchard wrote:
And both pine and elm are long gone from the distribution.
pine is an interesting case. A quick header check on this message will
show that I use it, so I'm not an unbiased observer.
Leaving aside the issue of security vulnerabilities raised by Mark
Lane, the problem as I understand it is that the UW license doesn't
allow third parties to distribute patched binary versions of pine.
IOW,
* I can distribute a binary version of pine if and only if I don't
alter the official source release at all.
* I can distribute patches alongside the official pine source code,
but only in source format.
Obviously, Fedora is no place for a package with a restrictive license
like that. Still, pine is well known and will continue to be widely
used for some time.
Is there a way that we can make available some packages *only* in
src.rpm format? Then we could add patches to our heart's content,
without violating either the letter or the spirit of UW's license.
--Paul Heinlein <heinlein(a)madboa.com>
12:26 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 2003-12-17 at 10:28, Paul Heinlein wrote:
Is there a way that we can make available some packages *only* in
src.rpm format? Then we could add patches to our heart's content,
without violating either the letter or the spirit of UW's license.
So you are suggesting something similar to the qmail, other djb programs
srpms provided for Mandrake. Though the package maintainer works for
Mandrake, I don't think they are official Mandrake packages just
something similar to freshrpms.
regards,
--
Mark Lane, CET mailto:mark@harddata.com
Hard Data Ltd. http://www.harddata.com
T: 01-780-456-9771 F: 01-780-456-9772
11060 - 166 Avenue Edmonton, AB, Canada, T5X 1Y3
--> Ask me about our Excellent 1U Systems! <--
12:39 p.m.
New subject: [OT] Re: Fedora Core 2 wishlists
On Wed, 17 Dec 2003, Mark Lane wrote:
On Wed, 2003-12-17 at 10:28, Paul Heinlein wrote:
> Is there a way that we can make available some packages *only* in
> src.rpm format? Then we could add patches to our heart's content,
> without violating either the letter or the spirit of UW's license.
>
So you are suggesting something similar to the qmail, other djb
programs srpms provided for Mandrake. Though the package maintainer
works for Mandrake, I don't think they are official Mandrake
packages just something similar to freshrpms.
Sorry, I'm sufficiently unfamiliar with Mandrake to be able to answer
that question.
--Paul Heinlein <heinlein(a)madboa.com>
6:59 p.m.
Paul Heinlein writes:
* I can distribute a binary version of pine if and only if I
don't
alter the official source release at all.
* I can distribute patches alongside the official pine source code,
but only in source format.
Obviously, Fedora is no place for a package with a restrictive license
like that. Still, pine is well known and will continue to be widely
used for some time.
You forgot one more bullet point:
• Pine does not support UTF-8; neither it is likely to support UTF-8 any
time soon.
That, more than anything else, dooms Pine future on Linux.
8:49 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 17 Dec 2003, Sam Varshavchik wrote:
Paul Heinlein writes:
> * I can distribute a binary version of pine if and only if I don't
> alter the official source release at all.
>
> * I can distribute patches alongside the official pine source code,
> but only in source format.
>
> Obviously, Fedora is no place for a package with a restrictive license
> like that. Still, pine is well known and will continue to be widely
> used for some time.
You forgot one more bullet point:
Б─╒ Pine does not support UTF-8; neither it is likely to support UTF-8 any
time soon.
Pine have supported UTF-8 with a little patch. Pine is used by me on my
Fedora and I want to see it on Linux.
That, more than anything else, dooms Pine future on Linux.
- --
"This is UNIX country. //=\ Tommy Tovbin
if you listen carefully, \=//
you can hear //=\ tovbin at niisi dot msk dot ru
Windows reboot..." \=// http://m1.sm.bmstu.ru
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE/4b5nYrHu8lMSp6ERAt4TAJsGynceb4jS+AGmJXS0Hy2sp1P3/gCfUMoX
+w7bzb5nlhT/odJdcmmQbjU=
=fvpu
-----END PGP SIGNATURE-----
9:08 a.m.
>
> Б─╒ Pine does not support UTF-8; neither it is likely to support UTF-8 any
> time soon.
Pine have supported UTF-8 with a little patch. Pine is used by me on my
Fedora and I want to see it on Linux.
That's nice. Then you can package it up for yourself. But 1. it's not
allowed to be redistributed in that way 2. it's got some other issues
that the pkg maintainer from red hat has worried with.
it's best if pine goes away.
-sv
9:36 a.m.
On Thu, 18 Dec 2003, seth vidal wrote:
> >
> > Ðââ Pine does not support UTF-8; neither it is likely to support UTF-8
any
> > time soon.
> Pine have supported UTF-8 with a little patch. Pine is used by me on my
> Fedora and I want to see it on Linux.
That's nice. Then you can package it up for yourself. But 1. it's not
allowed to be redistributed in that way 2. it's got some other issues
that the pkg maintainer from red hat has worried with.
it's best if pine goes away.
Maybe but the real problem is that there is no replacment for it.
And no mutt is not a replacment. It is too different and too hard to
configure. That is one of the strengths of pine it is simple to setup and
use. Mutt is not intuitive at all. At least not for me.
Apparently there are other people who agree with me or pine would have died
a long time ago.
Just my $.02
.........Tom
10:24 a.m.
On Thu, 18 Dec 2003, Tom Diehl wrote:
On Thu, 18 Dec 2003, seth vidal wrote:
> > >
> > > Ðââ Pine does not support UTF-8; neither it is likely to support
UTF-8 any
> > > time soon.
> > Pine have supported UTF-8 with a little patch. Pine is used by me on my
> > Fedora and I want to see it on Linux.
>
> That's nice. Then you can package it up for yourself. But 1. it's not
> allowed to be redistributed in that way 2. it's got some other issues
> that the pkg maintainer from red hat has worried with.
>
> it's best if pine goes away.
Maybe but the real problem is that there is no replacment for it.
And no mutt is not a replacment. It is too different and too hard to
configure. That is one of the strengths of pine it is simple to setup and
use. Mutt is not intuitive at all. At least not for me.
Apparently there are other people who agree with me or pine would have died
a long time ago.
Indeed. I've tried to get used to mutt several times over the years, with
and without "pine-keybindings" which really bring it zero closer to pine,
only add to the confusion (at least did that for me).
Been trying to get used to Evolution since I bought a box which doesn't
choke on it in the spring: I still don't *like* because of various little
(and some bigger) details it doesn't do "right" (for me). Problem is,
Evolution is not an option when reading mails remotely, still need to go
back to pine for that, daily (and don't bother suggesting webmail
solution, I *hate* those).
Pine's far from perfect, especially in these days of UTF-8, but it's hard
to unlearn habits from 9 years of usage :-/
- Panu -
10:44 a.m.
On Thu, Dec 18, 2003 at 10:36:12AM -0500, Tom Diehl wrote:
On Thu, 18 Dec 2003, seth vidal wrote:
And no mutt is not a replacment. It is too different and too hard to
configure. That is one of the strengths of pine it is simple to setup and
use. Mutt is not intuitive at all. At least not for me.
I'd agree (and check the headers, I'm a happy Mutt user, although I use
Evolution when I'm sitting at my desk at home).
The problem would appear to be that while the folks building mail clients
like Kmail and Evolution are putting a lot of effort into basic usability,
the folks creating text-mode clients aren't doing the same: it's power
users building for other power users (or as Joel Spolsky put it recently,
programmers writing programs for other programmers).
Pine filled that niche fairly well; plenty to configure if you wanted to,
but the defaults were sane out-of-the-box, and the on-screen help coupled
with context-sensitive help screens everywhere gave the user a lot of
confidence that they wouldn't get stuck.
Mutt, on the other hand, feels more like vi; it's exceptionally efficient,
once you've learned it, but that learning curve isn't an easy one. The
context-sensitive help is self-generating and cryptic, there's very little
in the way of on-screen assistance, and you can't count on the behavior of
the program being the same from system to system (on this OS, the key
mappings are like Pine's; on this machine, you've got color; over here,
the keybindings are emacs-like, etc). The ultra-configurability is a boon
for power users, but it's a pain for someone who just wants to read their
mail remotely.
It's really a shame that the license for Pine is so poorly conceived; as
an example, c-client Maildir patches have been around forever, but the
Pine team refuses to integrate them, and you can't distribute a patched
version that supports Maildir. :-P
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
10:36 a.m.
On Thu, 2003-12-18 at 07:08, seth vidal wrote:
That's nice. Then you can package it up for yourself. But 1.
it's not
allowed to be redistributed in that way 2. it's got some other issues
that the pkg maintainer from red hat has worried with.
Hrm, Mike Harris seems to disagree with that statement (on IRC). Can
you show me where in the pine license it states you can't redistribute
patched binaries?
--
Jesse Keating RHCE MCSE (geek.j2solutions.net)
Fedora Legacy Team (www.fedora.us/wiki/FedoraLegacy)
Mondo DevTeam (www.mondorescue.org)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
Was I helpful? Let others know:
http://svcs.affero.net/rm.php?r=jkeating
10:46 a.m.
On Thu, 18 Dec 2003, Jesse Keating wrote:
On Thu, 2003-12-18 at 07:08, seth vidal wrote:
> That's nice. Then you can package it up for yourself. But 1. it's not
> allowed to be redistributed in that way 2. it's got some other issues
> that the pkg maintainer from red hat has worried with.
Hrm, Mike Harris seems to disagree with that statement (on IRC). Can
you show me where in the pine license it states you can't redistribute
patched binaries?
See the FAQ, esp. section 10.1:
10.1 Is Pine Open Source?
It depends on how that term is defined. Source for Unix Pine is
provided to allow users and system administrators to customize and
adapt Pine for their own requirements. UW's Pine license allows
anyone to download source code for Unix Pine and make modifications
for their own local use without asking permission. Anyone can also
create and distribute patch files to implement bug fixes or minor
enhancements without asking permission. However, redistribution of a
modified version of Pine requires explicit permission from the
University of Washington.
[http://www.washington.edu/pine/faq/legal.html]
--Paul Heinlein <heinlein(a)madboa.com>
11:19 a.m.
Other than the FAQ clarifications on not getting source, there is also
that UofW seems to be rather litigous about the source code. When the
FSF decided to try and do a fork back in 1999 using an older version
with a very lose license.. the project was dropped because UoW
threatened to sue, and the FSF decided it wasnt worth the effort.
In the end, I think it is up to the community to really write a user
friendly mail client (and I agree mutt doesnt fit the need for
everyone.. I have given up on it because my brain isnt vi like.. and it
isnt going to be.). It may look like pine, but it couldnt have access to
the code to base anything off of it.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
11:40 a.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 2003-12-18 at 12:19, Stephen Smoogen wrote:
In the end, I think it is up to the community to really write a user
friendly mail client (and I agree mutt doesnt fit the need for
everyone.. I have given up on it because my brain isnt vi like.. and it
isnt going to be.). It may look like pine, but it couldnt have access to
the code to base anything off of it.
Apparently the Courier folks are attempting to do so with their 'cone'
program (heh heh). It also includes an editor, 'leaf'.
See http://www.courier-mta.org/cone/
--Jeremy
--
/---------------------------------------------------------------------\
| Jeremy Portzer jeremyp(a)pobox.com trilug.org/~jeremy |
| GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 |
\---------------------------------------------------------------------/
11:45 a.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 18 Dec 2003, Jeremy Portzer wrote:
On Thu, 2003-12-18 at 12:19, Stephen Smoogen wrote:
> In the end, I think it is up to the community to really write a user
> friendly mail client (and I agree mutt doesnt fit the need for
> everyone.. I have given up on it because my brain isnt vi like.. and it
> isnt going to be.). It may look like pine, but it couldnt have access to
> the code to base anything off of it.
Apparently the Courier folks are attempting to do so with their 'cone'
program (heh heh). It also includes an editor, 'leaf'.
See http://www.courier-mta.org/cone/
For long-time pine users (or at least this one), it's no more suitable than
mutt....
later,
chris
2:41 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, Dec 18, 2003 at 12:45:51PM -0500, Chris Ricker wrote:
For long-time pine users (or at least this one), it's no more
suitable than
mutt....
As in, it's not an exact replacement, no. But from looking through the
screens for it, it's definitely not a far cry. On-screen help is there,
and the interface would appear to be built in the same spirit. I'd be
amazed if an average Pine user couldn't sit down at that and find their
way around. See http://www.courier-mta.org/cone/book.html ... the first
few links have screenshots of what "cone" looks like to the user, and
at first glance, I'd have thought it was Pine.
Not bad, I had no idea that existed. Sam Varshavchik has been one busy
fellow.
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
3:40 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 18 Dec 2003, Edward S. Marshall wrote:
On Thu, Dec 18, 2003 at 12:45:51PM -0500, Chris Ricker wrote:
> For long-time pine users (or at least this one), it's no more suitable than
> mutt....
As in, it's not an exact replacement, no.
Right. But if you're a long-term pine user, you're likely still using it
because you're deeply used to the keystrokes (which are different in cone).
If you're going to bother to learn new keystrokes, you might as well just go
for mutt which is:
0. already in the distro, and widely found elsewhere
1. easier to build elsewhere, if it's not already there
2. smaller
3. more stable
cone's a good choice for people needing an easy-to-pickup text MUA to start
with....
later,
chris
4:02 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 18 Dec 2003, Chris Ricker wrote:
On Thu, 18 Dec 2003, Edward S. Marshall wrote:
> On Thu, Dec 18, 2003 at 12:45:51PM -0500, Chris Ricker wrote:
> > For long-time pine users (or at least this one), it's no more suitable than
> > mutt....
>
> As in, it's not an exact replacement, no.
Right. But if you're a long-term pine user, you're likely still using it
because you're deeply used to the keystrokes (which are different in cone).
If you're going to bother to learn new keystrokes, you might as well just go
for mutt which is:
0. already in the distro, and widely found elsewhere
1. easier to build elsewhere, if it's not already there
2. smaller
3. more stable
That depends on just how hard it is to configure. I fought with mutt to try to
understand it and get it to do some of the thing I am used to in pine. I gave
up after several days. If I can get something else to do what I want easially
I think it would be better for me even if I need to learn new keystrokes.
I wonder if there are rpms for cone??
cone's a good choice for people needing an easy-to-pickup text
MUA to start
with....
This is where mutt fails miserably. It is too hard to configure and the docs
do a poor job of explaining how to config it. I have used pine for ~10 years
and I very seldom if ever have read the docs for it. Even with its warts it
just kinda works.
.............Tom
4:56 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, Dec 18, 2003 at 05:02:16PM -0500, Tom Diehl wrote:
This is where mutt fails miserably. It is too hard to configure and the docs
do a poor job of explaining how to config it. I have used pine for ~10 years
and I very seldom if ever have read the docs for it. Even with its warts it
just kinda works.
Out of curiosity, what would you waént to configure mutt to do?
Maybe we can help.
Emmanuel
8:08 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 18 Dec 2003, Emmanuel Seyman wrote:
On Thu, Dec 18, 2003 at 05:02:16PM -0500, Tom Diehl wrote:
>
> This is where mutt fails miserably. It is too hard to configure and the docs
> do a poor job of explaining how to config it. I have used pine for ~10 years
> and I very seldom if ever have read the docs for it. Even with its warts it
> just kinda works.
Out of curiosity, what would you waént to configure mutt to do?
Maybe we can help.
Well ok I will try to explain what I have. When I start pine it opens up
in my inbox. From there if I press the tab key I go to the first one of my
other folders that has 1 or more unread messages. It skips over any empty
folders. From there tab will take me to the next unread message or folder
that contains unread messages. In addition each time I press tab any
messages that are marked for deletion are deleted and any read messages
are filed in the correct archiving folder. That way the incoming folders
only ever have new messages in them. In addition all of this is done via
imap. Someone said using mutt is like using vi. I am not sure I agree
since so far I have been unable to use mutt but I am typing this message
in vi. :-)
Hopefully the above makes sense if not let me know and I will try to clairify.
Oh btw I think pine calls what I tried to describe above "cruise mode".
I really like it and I have never come across another mua that works like it.
Cheers,
.............Tom
8:45 a.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, Dec 18, 2003 at 09:08:51PM -0500, Tom Diehl wrote:
Oh btw I think pine calls what I tried to describe above "cruise
mode".
I really like it and I have never come across another mua that works like it.
I was addicted to that. ;-)
In mutt, I achieved the same effect by adding a "mailboxes" line to my
.muttrc, like so:
mailboxes ! =spam =redhat =linux-kernel =subversion
(That's "INBOX", "spam", "redhat",
"linux-kernel", and "subversion" IMAP
mailboxes, in my configuration; you'll want to check the docs for the
various magical symbols you can use to refer to mailbox location for
your setup. I found that I needed to specify INBOX ("!") to reliably catch
new mail there.)
Then, when I want to flip to the next mailbox that has new mail in it, I
type "c" (change mailbox), and it searches through the list looking for
one with new mail.
Now, I just want a feature that Cone appears to have: save my config file
on an IMAP server. ;-)
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
9:24 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Fri, 19 Dec 2003, Edward S. Marshall wrote:
On Thu, Dec 18, 2003 at 09:08:51PM -0500, Tom Diehl wrote:
> Oh btw I think pine calls what I tried to describe above "cruise mode".
> I really like it and I have never come across another mua that works like it.
I was addicted to that. ;-)
In mutt, I achieved the same effect by adding a "mailboxes" line to my
.muttrc, like so:
mailboxes ! =spam =redhat =linux-kernel =subversion
(That's "INBOX", "spam", "redhat",
"linux-kernel", and "subversion" IMAP
mailboxes, in my configuration; you'll want to check the docs for the
various magical symbols you can use to refer to mailbox location for
your setup. I found that I needed to specify INBOX ("!") to reliably catch
new mail there.)
Then, when I want to flip to the next mailbox that has new mail in it, I
type "c" (change mailbox), and it searches through the list looking for
one with new mail.
Now, I just want a feature that Cone appears to have: save my config file
on an IMAP server. ;-)
Oh yea, pine has that too, and I use it. :-)
.......Tom
7:47 a.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 18 Dec 2003, Tom Diehl wrote:
That depends on just how hard it is to configure. I fought with mutt
to try to
understand it and get it to do some of the thing I am used to in pine. I gave
up after several days. If I can get something else to do what I want easially
I think it would be better for me even if I need to learn new keystrokes.
Depends on what you're wanting. A lot of how I use pine isn't in cone. YMMV.
I wonder if there are rpms for cone??
<http://www.courier-mta.org/cone/install.html> covers all the details of
building the RPMs.
This is where mutt fails miserably. It is too hard to configure and
the docs
do a poor job of explaining how to config it. I have used pine for ~10 years
and I very seldom if ever have read the docs for it. Even with its warts it
just kinda works.
Well, but mutt *is* configurable. cone's not, to any great extent. You can
tell it your mailboxes, and your colors, and your mime handlers, and that's
about it.
later,
chris
2:03 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 2003-12-18 at 14:40, Chris Ricker wrote:
On Thu, 18 Dec 2003, Edward S. Marshall wrote:
> On Thu, Dec 18, 2003 at 12:45:51PM -0500, Chris Ricker wrote:
> > For long-time pine users (or at least this one), it's no more suitable than
> > mutt....
>
> As in, it's not an exact replacement, no.
Right. But if you're a long-term pine user, you're likely still using it
because you're deeply used to the keystrokes (which are different in cone).
If you're going to bother to learn new keystrokes, you might as well just go
for mutt which is:
Where I have always decided Pine was an easier client was that I could
configure it in a consistant manner. Everything was in nice menu forms
that seemed to be easily readable with nice help and clear instructions
on the bottom. My brain just could not grok mutts configuration system,
and most people would tell me to just edit the .muttrc directly when I
wanted to tell someone over the phone.. do this, do this, and there you
can send me an email on what is broken with your machine. [I will put
this down as probably 80% me knowing pine very well and 20% that pine
seems more user-oriented. I know people who can explain vi in 10 minutes
to a complete newbie and it seems to stick.. me all I know is enough vi
to be able to configure the old emacs-14 makefiles.]
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
2:48 p.m.
New subject: pine cone - Re: Fedora Core 2 wishlists
On Thu, 2003-12-18 at 10:45, Chris Ricker wrote:
On Thu, 18 Dec 2003, Jeremy Portzer wrote:
> Apparently the Courier folks are attempting to do so with their
'cone'
> program (heh heh). It also includes an editor, 'leaf'.
>
> See http://www.courier-mta.org/cone/
For long-time pine users (or at least this one), it's no more suitable than
mutt....
Well that may be true.. but what is? And why not? I mean it has to be
something more than typing something other than pine?
later,
chris
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
10 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
On Thu, 18 Dec 2003, Paul Heinlein wrote:
On Thu, 18 Dec 2003, Jesse Keating wrote:
> On Thu, 2003-12-18 at 07:08, seth vidal wrote:
> > That's nice. Then you can package it up for yourself. But 1. it's not
> > allowed to be redistributed in that way 2. it's got some other issues
> > that the pkg maintainer from red hat has worried with.
>
> Hrm, Mike Harris seems to disagree with that statement (on IRC). Can
> you show me where in the pine license it states you can't redistribute
> patched binaries?
See the FAQ, esp. section 10.1:
10.1 Is Pine Open Source?
It depends on how that term is defined. Source for Unix Pine is
provided to allow users and system administrators to customize and
adapt Pine for their own requirements. UW's Pine license allows
anyone to download source code for Unix Pine and make modifications
for their own local use without asking permission. Anyone can also
create and distribute patch files to implement bug fixes or minor
enhancements without asking permission. However, redistribution of a
modified version of Pine requires explicit permission from the
University of Washington.
[http://www.washington.edu/pine/faq/legal.html]
So what's so difficult about simply asking for permission then? That's
what SuSE did, and their version of Pine includes quite a number of
patches.
Bye,
LenZ
- --
Lenz Grimmer <lenz(a)mysql.com>
Senior Production Engineer
MySQL GmbH, http://www.mysql.de/
Hamburg, Germany
For technical support contracts, visit https://order.mysql.com/?ref=mlgr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
iD8DBQE/5cOQSVDhKrJykfIRAohuAJ906hOiICcWlLVVw9YIdtihl/gEJwCfdcTD
mgAOUse2W1ZkUwp+9b9AvHU=
=Z2li
-----END PGP SIGNATURE-----
7:25 a.m.
On Dec 21, 2003, Lenz Grimmer <lenz(a)mysql.com> wrote:
> However, redistribution of a modified version of Pine requires
> explicit permission from the University of Washington.
So what's so difficult about simply asking for permission then?
If such permission doesn't apply to third parties, then mirrors
wouldn't be authorized to carry it, commercial redistribution of the
released CDs would be forbidden and you wouldn't be authorized to lend
the CDs your burned yourself to a friend. Sounds a lot like non-Free
Software to me. So what's the point?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
10:43 a.m.
On Sun, 2003-12-21 at 09:00, Lenz Grimmer wrote:
>
> [http://www.washington.edu/pine/faq/legal.html]
So what's so difficult about simply asking for permission then? That's
what SuSE did, and their version of Pine includes quite a number of
patches.
SuSE in the past have not had the same view of the subsidiary rights of
their users as Red Hat has. It could be that they were a German company
and didnt have to worry too much about US contractual vaguaries (and
vice versa). I am thinking that a lot of these items will be part of the
'paring down' of SuSE distrobution that was mentioned in one of the
Novell interviews.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
7:38 a.m.
On Sun, Dec 21, 2003 at 05:00:15PM +0100, Lenz Grimmer wrote:
So what's so difficult about simply asking for permission then?
That's
what SuSE did, and their version of Pine includes quite a number of
patches.
http://fedora.redhat.com/about/objectives.html
2. Build the operating system exclusively from open source software.
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
11:40 a.m.
New subject: [OT] Re: Fedora Core 2 wishlists
Possibly. They were restrictive for ISDN at least, yet we still had
open-source drivers. The driver(s) were 'certified' and gave a
warning when loaded if they (it) suspected tampering/modification.
The european ISDN rules really put the duty on the person who plugged it in
to do the right thing, and the hardware vendor to use the right stickers for
approval. The wireless one comes from pure hardware so isnt really translating
so well to software
Most of the ISDN rules have been relaxed - not least because "bad driver might
bring down exchange" is seen as a terror threat not a reason for certification
of protocols. (Obviously hw cert is different - blowing up phone engineers is
not good)
Alan
5:55 a.m.
On Wed, 2003-12-10 at 00:06, Bill Nottingham wrote:
Daniel Roesen (dr(a)cluenet.de) said:
- Courier as IMAP4/POP3 daemon with IPv6 and SSL support
out-of-the-box...
Seriously, we're already looking at Cyrus, so I doubt that
we'd ship courier as well in Core.
I also tend to think it would be an extras thing, in part because I
don't see what would be moved out, and in part because there are MTA
components with a lot more proven maturity.
But it's worth mentioning that courier really shines, in my experience
when installed as one suite. You get an MTA + POP + IMAP + Webmail +
Webadmin without needing to configure them to work together. It just
works out of the box. And out of the box, they are all SSL-aware, as
well (which wasn't the case a few years back when I started using it for
my home network).
So whether in core, or more likely in extras, I'd like to plug the
entire courier suite instead of just the IMAP/POP3 components. It could
be very well suited to the home or small office where the person in the
sysadmin role might not have a great deal of experience setting up a
complete mail system to work together.
--
Karl DeBisschop <kdebisschop(a)alert.infoplease.com>
2:18 a.m.
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists.
Excuse me, Japanese issues but
- Revert Canna to work it fine.
- Fix FreeWnn to work.
to let people be enable to input Japanese.
Those are supported to be first priorities around Japanese issue.
I've been tired to hear those brokeness with Fedora Core 1 in Japan.
--
Nakai
3:07 a.m.
>>>> On Wed, 10 Dec 2003 17:18:53 +0900,
>>>> "YN" == Yukihiro Nakai <ynakai(a)redhat.com> wrote:
YN> Excuse me, Japanese issues but
YN> - Revert Canna to work it fine.
YN> - Fix FreeWnn to work.
YN> to let people be enable to input Japanese.
YN> Those are supported to be first priorities around Japanese issue.
YN> I've been tired to hear those brokeness with Fedora Core 1 in Japan.
What the problems did you see? we didn't get any bugs
related that. so no way to fix the problem ;)
Please submit a bug to bugzilla when you see a problem.
Regards,
--
Akira TAGOH
3:07 a.m.
Yukihiro Nakai wrote:
>However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
>hear people's wishlists.
Excuse me, Japanese issues but
- Revert Canna to work it fine.
- Fix FreeWnn to work.
All these years I have never been able to get FreeWnn to work with
kinput2, so I always use kinput2 -canna. What bad behaviors in Canna
are you talking about? Has FreeWnn ever worked at all?
What about the status of IIIMF?
Warren
2:11 a.m.
>>>> "WT" == Warren Togami
<warren(a)togami.com> writes:
WT> All these years I have never been able to get
WT> FreeWnn to work with kinput2, so I always use
WT> kinput2 -canna.
WT> Has FreeWnn ever worked at all?
Erm, works for me. Admittedly the xinput script doesn't
handle the choice between Canna and FreeWnn in a very smart
way if you have them both installed, but in what way does it
not work for you? "kinput2 -wnn" should just work.
WT> What about the status of IIIMF?
Have you played with CannaLE in im-sdk?
Jens
5:40 p.m.
On Wed, Dec 10, 2003 at 05:18:53PM +0900, Yukihiro Nakai wrote:
> However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
> hear people's wishlists.
Excuse me, Japanese issues but
- Revert Canna to work it fine.
- Fix FreeWnn to work.
to let people be enable to input Japanese.
Those are supported to be first priorities around Japanese issue.
I've been tired to hear those brokeness with Fedora Core 1 in Japan.
Do fixed versions exist. If so we need to push them as FC1 updates in my
opinion, just like we need to push a redhat-menus without missing
translations
8:38 a.m.
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
I suggest PPTP (client and server). The GPL compatibility issues seems
to be resolved according to https://bugzilla.fedora.us/show_bug.cgi?id=962
Alfredo
9:07 a.m.
On Wed, 2003-12-10 at 14:38, Alfredo Sanjuan wrote:
> However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
> hear people's wishlists. Not everything will be possible, but it would
> be nice to have a good list from which to pick the possibilities, and
> from which to also pick ideas later for Fedora Core 3.
I suggest PPTP (client and server). The GPL compatibility issues seems
to be resolved according to https://bugzilla.fedora.us/show_bug.cgi?id=962
If the license problems have been worked out, I'd much rather see
lobbying to get it included in the mainline kernel.
Several reasons:
1) "If its not good enough for mainline, why is it good enough for
Fedora".
2) It's more likely to get looked over and improved by other folks
3) Lower maintenance overhead for Fedora kernel
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
3:46 p.m.
On Wed, Dec 10, 2003 at 03:38:19PM +0100, Alfredo Sanjuan wrote:
I suggest PPTP (client and server).
I couldn't disagree more. Even M$ has moved away from that mess.
http://www.jacco2.dds.nl/networking/msl2tp.html
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
7:32 a.m.
On Thu, Dec 11, 2003 at 12:15:42PM +0100, Alfredo Sanjuan wrote:
We all know that PPTP is a mess, but it's an easy setup for
the average
Windows user.
My point was that M$ has released a free (as in beer, of course)
L2TP/IPsec client for Win9x, so at this point it would make a *lot*
more sense to just include l2tpd.
Steve
--
Steven Pritchard - K&S Pritchard Enterprises, Inc.
Email: steve(a)kspei.com http://www.kspei.com/
Phone: (618)398-7360 Mobile: (618)567-7320
10:50 a.m.
On Thu, Dec 11, 2003 at 07:32:44AM -0600, Steven Pritchard wrote:
My point was that M$ has released a free (as in beer, of course)
L2TP/IPsec client for Win9x, so at this point it would make a *lot*
more sense to just include l2tpd.
Except, of course, when those in the field are running Fedora, and the
VPN service offered by the office/remote network is PPTP.
--
Edward S. Marshall <esm(a)logic.net>
http://esm.logic.net/
Felix qui potuit rerum cognoscere causas.
10:04 a.m.
On Mon, 2003-12-08 at 16:15, Michael K. Johnson wrote:
http://fedora.redhat.com/participate/schedule/
No dates set yet, but a driving goal or defining characteristic will
be the 2.6 Linux kernel -- unless the 2.6 Linux kernel takes too
long to arrive. That is, we'll shorten the schedule to accomodate an
earlier release of the 2.6 kernel, but not lengthen it to accomodate
a later release of the 2.6 kernel.
2.6 is looking good. There's a lot of integration work to do, though.
However, that won't be the ONLY feature of Fedora Core 2. I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Update from upstream if update is available. ImageMagick comes to mind
and IIRC there are other packages where we don't ship the latest stable
(according to upstream) version. If we can't ship it, it should be
documented why we can't (to both the community and upstream).
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
10:56 a.m.
On Monday 08 December 2003 10:15, Michael K. Johnson wrote:
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
OK, my wishlist --
1. Full AMD64 support ... this should be a goal for FC2 but with the idea
that it would be certainly done by FC3. By full AMD64 support I mean the
ability to build/install Fedora Core on an Athlon64 or Opteron with a 64-bit
kernel and both 64-bit and 32-bit libraries so that you can run both 32 and
64 bit applications. While we may be able to get partially there for FC2, it
may take more time to get all libraries correctly configured. If at all
possible, the i386 and AMD64 versions should be issued at the same time.
2. SELinux ... "enabled" in all binaries but not turned on by default. No
recompiling packages necessary although you might/will need to install some
extra packages.
3. Integrated up2date/redhat-config-packages ... I understand that
redhat-config-packages is currently undergoing redesign from a blank piece of
paper. The new package should be capable of getting input via http, ftp,
local directory trees, iso images as well as cdroms (this last one is a soft
requirement by me). I should be able to get updates, to install "groups" of
packages (e.g., X Development, Gnome Development, etc), to install individual
packages.
Currently, up2date has most of the needed capabilities but a redesign is
probably needed to "get things done right". Specifically, I can use up2date
to get/install updated packages via http, ftp, and local directory trees.
With --show-package-dialog I can install packages not previously installed
(this only works if you have at least one pending update or hack gui.py to
comment out the sys.exit(0) if there are no updates.
4. Some type of triage process for prioritizing bugs which must be fixed
before "gold". While my opinions as an individual (or anyone else as an
individual) who is not a Red Hat employee should not drive such a process,
there should be something which involves at least some (non Red Hat)
end-users. If something cannot be fixed for "gold", then it should have
priority to be fixed (assuming there is a fix) post official release. This
"post official release" is occurring but very unevenly.
Now for my pet peeves, I have fixes which work to my satisfaction. That does
not make them satisfactory in general nor does it make those fixes generally
available to others. Currently, my pet peeves are:
- gftp handling of http does not work in gftp-2.0.14 BUT gftp-2.0.16 is
available from upstream and that fixes most things.
- gnome-panel drawers do not work with gnome-panel-2.4.0-3 (launchers added
to a drawer become just pictures after a logout). The fix is a patch to
button-widget.c (which was available in mid September) or to use
gnome-panel-2.4.1 ... both fix the draw problem ... but reveal another
problem which the panel is hidden (drawers fly open). Now, to me it is
better to have drawers that work than to worry about the hidden panel.
Waiting for FC2 for a fix is not reasonable to me (which is why I created my
own ... actually applying work from upstream).
While I realize that the folks at Red Hat are a limited resource and cannot
address everything, perhaps there needs to be some secondary repository with
user created fixes for Fedora Core packages. I find the current situation
which updated packages for packages included in Fedora Core being added to
Fedora Extras to be unreasonable! Case in point: gftp.
5. Fedora Extras needs to work. If we are going to be able to shuffle of
some packages (galeon come to mind) to Extras rather than having it in Core,
the the process needs to work. Currently the QA queue at fedora.us is
clogged. IMHO, this cannot be resolved without a different approach. From
my viewpoint, the fedora.us QA process exceeds that done by Red Hat for some
of their packages. Furthermore, doing a source-code audit of a package as an
alternative to QA testing is a very expensive process (lots of people hours).
Unless you really know what you are doing, I am not sure what a source code
audit will prove.
Some extra packages are widely used but not so widely used that they should be
part of Core ... these should go into Extras and have good QA done. I agree
with Warren about something needs to be done about the large QA queue on
fedora.us but I am skeptical that a source-code audit is the answer (or maybe
I do not understand what Warren means by a source-code audit).
To me, testing of a package by a user does not require any special skills by
the user -- just a desire to use the package and the willingness to do
testing. On the other hand, doing a source-code audit requires an individual
with good understanding of the programming languages involved (c, c++, perl,
whatever) as well as an understanding of what can cause problems (e.g.,
buffer overflows, not paranoid testing of parameters, etc.).
Another thought that occurs to me is that perhaps for a package to be even
considered for Extras (even before it enters QA processing), it should have
multiple "sponsors" who agree that addition of the package to Extras would be
a good idea.
For the rest of the packages which are not necessarily widely used, I suggest
that a "Contrib" category be established .. a buyer-beware repository of
packages. I do not know if this is a good idea or not. Red Hat used to have
a contrib directory and some good stuff (and a lot of crap) got put there. I
have not looked lately but I believe it has been discontinued.
Enough for now. I look forward to comments.
--
Gene
8:36 a.m.
On Wed, 10 Dec 2003 11:56:58 -0500, Gene C. wrote:
available to others. Currently, my pet peeves are:
- gftp handling of http does not work in gftp-2.0.14 BUT gftp-2.0.16 is
available from upstream and that fixes most things.
gftp 2.0.16 is available in fedora.us "patches" repository.
While I realize that the folks at Red Hat are a limited resource and
cannot
address everything, perhaps there needs to be some secondary repository with
user created fixes for Fedora Core packages. I find the current situation
which updated packages for packages included in Fedora Core being added to
Fedora Extras to be unreasonable! Case in point: gftp.
Hopefully in the near future, changed packaging policies for such updates
will make it possible to offer them as official Fedora Core Test Updates.
Currently the QA queue at fedora.us is clogged.
There seems to be a general misconception about that QA queue. It is not
processed in FIFO order. Popular software or important updates would be
prioritized. Active package request tickets draw the attention of people
who can help approving a package if help is needed. It's just that an
increasing number of package submissions seem to be of not much interest
to users other than the packager.
IMHO, this cannot be resolved without a different approach. From
my viewpoint, the fedora.us QA process exceeds that done by Red Hat for some
of their packages.
Which is partly because an online repository has a different release
scheme. Red Hat's distribution has a development stream and test releases.
Furthermore, doing a source-code audit of a package as an
alternative to QA testing is a very expensive process (lots of people hours).
Well, right now two people can approve a package according to the QA
policy. Provided that two people show interest and commitment.
To me, testing of a package by a user does not require any special
skills by
the user
Right.
-- just a desire to use the package and the willingness to do
testing.
... and probably be open for additional review criteria, such as build
requirements or package content sanity checks (e.g. everything installed
in the right place? good file permissions?)
--
6:35 p.m.
Hi @all,
On Mo, 08 Dez 2003, Michael K. Johnson sent incredible lines:
[...]
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
[...]
christmas time, wishlist time? ;-))
OK, these are the wishes from my side:
Wish 1:
NTFS kernel support (any reason why it's not integrated?)
Reason:
Great improvment for FC2 on workstations with Windows installed
(think this happend very often).
Wish 2:
JFS/XFS support (also in installation)
Reason:
Both filesystems are stable and performing great in larger
environmnents, so looks like an improvment for getting FC2
focused to bigger servers also.
Wish 3:
native IPSEC/X.509/SecurID support
Reason:
The combination of X.509 or SecurID is mainly used in all bigger
companies I know about, so great for focus FC2 to bigger
companies.
Wish 4:
Webbased CA support
Reason:
Related to wish above, gives the administrator the possibility
to easy manage certificates (i.e. for IPSEC). A good looking
tool I found at http://elyca.eurodev.net/.
Wish 5:
J2EE server
Reason:
Many comercial companies currently develop Java application (SAP
in the CRM i.e.). Would be nice to have a distro wich includes
stuff like this.
Wish 6:
newest cdrecord version
Reason:
Either I'm to stupid or the current version is not able to use
dev=ATAPI:0,0,0 for IDE DVD writer. This would be, focused to the
workstation, a nice possiblilty if FC2 is able to generate DVD
without additional tools.
I think, that's from my side so far, maybe when I think about it on
my ski vacation the next week, I will find something more which
would be great in FC2 ;-)).
... may the Tux be with you! =Thomas=
P.S.: Great work on FC1 so far!
--
() ascii ribbon campaign - against html e-mail
/\ - against microsoft attachments
7:54 a.m.
On Fri, 2003-12-12 at 00:35, Thomas Bendler wrote:
Wish 1:
NTFS kernel support (any reason why it's not integrated?)
Potential patent issues.
Wish 2:
JFS/XFS support (also in installation)
Done for FC2. (Both are in 2.6 as standard)
Wish 3:
native IPSEC/X.509/SecurID support
IPSEC is in 2.6
Wish 6:
newest cdrecord version
Reason:
Either I'm to stupid or the current version is not able to use
dev=ATAPI:0,0,0 for IDE DVD writer. This would be, focused to the
workstation, a nice possiblilty if FC2 is able to generate DVD
without additional tools.
In 2.6, for ide devices, you burn with cdrecord dev=/dev/hdc
(or was it just dev=hdc, I forget..)
You'll no longer need ide-scsi for this too.
Dave
--
Dave Jones <davej(a)redhat.com>
Red Hat
10:29 a.m.
On Fri, 2003-12-12 at 06:54, Dave Jones wrote:
On Fri, 2003-12-12 at 00:35, Thomas Bendler wrote:
> Wish 1:
> NTFS kernel support (any reason why it's not integrated?)
Potential patent issues.
I am guessing that FAT system may also be removed or paired down at some
point?
I am happy about the XFS. At this point I am looking at having to hack
it into some special case systems.
--
Stephen John Smoogen smoogen(a)lanl.gov
Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545
-- So shines a good deed in a weary world. = Willy Wonka --
4:57 a.m.
On Fri, 2003-12-12 at 17:29, Stephen Smoogen wrote:
> > Wish 1:
> > NTFS kernel support (any reason why it's not integrated?)
>
> Potential patent issues.
>
I am guessing that FAT system may also be removed or paired down at some
point?
No! Removing FAT support will be a real problem for Fedora IMHO. People
will start using it less, and its not going to be easy to get
partitioning done.
Removing FAT support will have negative implications.
--
Colin Charles, byte(a)aeon.com.my
http://www.bytebot.net/
5:17 a.m.
Le mer 17/12/2003 à 11:57, Colin Charles a écrit :
On Fri, 2003-12-12 at 17:29, Stephen Smoogen wrote:
>
> > > Wish 1:
> > > NTFS kernel support (any reason why it's not integrated?)
> >
> > Potential patent issues.
> >
>
> I am guessing that FAT system may also be removed or paired down at some
> point?
No! Removing FAT support will be a real problem for Fedora IMHO. People
will start using it less, and its not going to be easy to get
partitioning done.
Removing FAT support will have negative implications.
FAT is mandatory as long as all the usb keys/cards/gadjets out there use
it.
Cheers,
--
Nicolas Mailhot
9:40 a.m.
On Wed, 2003-12-17 at 03:57, Colin Charles wrote:
On Fri, 2003-12-12 at 17:29, Stephen Smoogen wrote:
>
> > > Wish 1:
> > > NTFS kernel support (any reason why it's not integrated?)
> >
> > Potential patent issues.
> >
>
> I am guessing that FAT system may also be removed or paired down at some
> point?
No! Removing FAT support will be a real problem for Fedora IMHO. People
will start using it less, and its not going to be easy to get
partitioning done.
Removing FAT support will have negative implications.
FAT is patented my Microsoft, and they're recently announced that
they're going to start enforcing that patent. It's not a question of how
useful FAT is, it's a question of whether or not we *have* to remove it.
10:19 a.m.
On Dec 17, 2003, Tyler larson <fedora-devel(a)tlarson.com> wrote:
FAT is patented my Microsoft
Some FAT extensions are. The FAT filesystem format in general isn't,
AFAIK.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva(a){redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp oliva(a){lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist Professional serial bug killer
10:54 a.m.
On Wed, Dec 17, 2003 at 02:19:45PM -0200, Alexandre Oliva wrote:
On Dec 17, 2003, Tyler larson <fedora-devel(a)tlarson.com>
wrote:
> FAT is patented my Microsoft
Some FAT extensions are. The FAT filesystem format in general isn't,
AFAIK.
Information from the source:
http://www.microsoft.com/mscorp/ip/tech/fat.asp
It appears that they are only charging for it if it's being used on
hardware devices (flash cards, portable devices, etc.). They don't
mention anything about shipping *software* with FAT support.
Perhaps someone should email "fatspec at microsoft dot com" to find out
for sure.
And of course...there's a HUGE Slashdot thread about this ;-)
http://slashdot.org/article.pl?sid=03/12/04/1318212&mode=thread&t...
I would personally like to see Fedora continue to ship FAT if possible.
I use it for the occasional floppy disk, and CF cards, etc.
Cheers,
Vic
--
Vic Gedris | Linux and Free Software: http://oclug.on.ca
vic-at-gedris.org | Bikes and HPVs: http://hpv.tricolour.net
http://vic.dyndns.org | GNU Privacy Guard (GPG) Key-ID: D77B43FB
12:36 p.m.
Vic Gedris wrote:
On Wed, Dec 17, 2003 at 02:19:45PM -0200, Alexandre Oliva wrote:
>On Dec 17, 2003, Tyler larson <fedora-devel(a)tlarson.com> wrote:
>
>
>>FAT is patented my Microsoft
>
>Some FAT extensions are. The FAT filesystem format in general isn't,
>AFAIK.
Information from the source:
http://www.microsoft.com/mscorp/ip/tech/fat.asp
Anyone know the dates on those patents?
My old Atari ST computer used FAT on floppies. I think Amiga did to.
Were these patents liscensed by Atari/Commodore? Did they even exist then?
Then again, what the hell is patentable in a filesystem. Man, the USPTO
really needs to stop patenting theis crap, and invalidate a lot of bogus
junk they granted.
Not only are we loosing fair use, since the DMCA allow one to hide
inside an protection scheme, the USPTO is going to make every thing
patented, just in case somone cannot hide it in a protection scheme.
(and the EPO seam to be heading the same way)
-Thomas
1:44 p.m.
El Miércoles 17 Diciembre 2003 19:36, Thomas Dodd escribió:
Vic Gedris wrote:
> On Wed, Dec 17, 2003 at 02:19:45PM -0200, Alexandre Oliva wrote:
>>On Dec 17, 2003, Tyler larson <fedora-devel(a)tlarson.com> wrote:
>>>FAT is patented my Microsoft
>>
>>Some FAT extensions are. The FAT filesystem format in general isn't,
>>AFAIK.
>
> Information from the source:
> http://www.microsoft.com/mscorp/ip/tech/fat.asp
Anyone know the dates on those patents?
My old Atari ST computer used FAT on floppies. I think Amiga did to.
Were these patents liscensed by Atari/Commodore? Did they even exist then?
Then again, what the hell is patentable in a filesystem. Man, the USPTO
really needs to stop patenting theis crap, and invalidate a lot of bogus
junk they granted.
I think those patents only apply in the US as software patents aren't valid in
Europe and most part of the world. So if finally FAT support is removed from
Fedora you should consider including it as an extra (are there non-US
packages in Fedora?).
--
Antonio Buiza Calero
antonio(a)buiza.org
abuiza(a)esi.us.es
7:30 p.m.
Sam Varshavchik ha scritto:
My old Atari ST computer used FAT on floppies. I think Amiga did to.
No. Amiga used a very funny filesystem for their floppies.
Maybe AFFS is funny by today's standards, but at the time it was much
more advanced than fat:
- long filenames
- more data on a floppy (880K instead of 720K)
- much faster (even for todays standard: ever tried formatting a floppy
under Win?)
Cheers, Giacomo.
9:46 p.m.
Giacomo Magnini writes:
Sam Varshavchik ha scritto:
> My old Atari ST computer used FAT on floppies. I think Amiga did to.
> No. Amiga used a very funny filesystem for their floppies.
Maybe AFFS is funny by today's standards, but at the time it was much
more advanced than fat:
- long filenames
- more data on a floppy (880K instead of 720K)
That had nothing to do with the filesystem format per se. The additional
room was obtaining by completely eliminating inter-sector gaps.
FAT-formatted floppies have gaps placed in-between sectors on a track, in
order to take into account the setup time needed to place the R/W head into
write mode, and to take into account variations in recording speeds between
different drives.
Amiga floppies didn't have inter-sector gaps, which is where the additional
storage came from. Amiga floppies were read and written a whole track at a
time.
- much faster (even for todays standard: ever tried formatting a
floppy
under Win?)
You've got to be kidding. Do you even recall the experience of trying to
open a folder from a floppy, in Workbench? Amiga's filesystem used hashed
directories. Reading a directory meant, essentially, traversing hash chains
all over the floppy. One block per file. Meaning that each directory entry
usually required a floppy head seek.
Each file block itself had a header. I think that each 512-byte block had
only 488 bytes of file data, the rest was the header. I forgot the exact
byte count, I think it was 488. That didn't really matter much with
floppies, but that meant that you couldn't exactly use DMA to read/write
data to/from a hard drive. An intermediate buffer had to be used for
processing the header and reading/writing it from the hear drive.
A “Fast File System” was added to a later revision of AmigaOS, which
basically removed headers from data blocks, allowing for much faster DMA
to/from hard drives.
3:17 p.m.
Giacomo Magnini wrote:
Sam Varshavchik ha scritto:
> My old Atari ST computer used FAT on floppies. I think Amiga did to.
> No. Amiga used a very funny filesystem for their floppies.
Maybe AFFS is funny by today's standards, but at the time it was much
more advanced than fat:
- long filenames
- more data on a floppy (880K instead of 720K)
That's a crock. A standard single sided floppy is 1MB, unformatted.
I used to format 920K all the time on my STe. Some disks couldn't
reliably hold it, but I could format it.
Take a look at the fd* entries in
<kernel_source>/Documentation/devices.txt for several formats.
They use different numbers of sectors and track than the default thay
gives 720K/1440K formats.
-Thomas
11:49 a.m.
On Thu, 18 Dec 2003 02:30:33 +0100, Giacomo Magnini wrote:
Sam Varshavchik ha scritto:
> My old Atari ST computer used FAT on floppies. I think Amiga did to.
> No. Amiga used a very funny filesystem for their floppies.
Maybe AFFS is funny by today's standards, but at the time it was much
more advanced than fat:
- long filenames
- more data on a floppy (880K instead of 720K)
- much faster (even for todays standard: ever tried formatting a floppy
under Win?)
Even faster with low-level ASM based and Blitter-optimized file system
access routines. ;)
--
6:56 p.m.
Vic Gedris writes:
On Wed, Dec 17, 2003 at 02:19:45PM -0200, Alexandre Oliva wrote:
> On Dec 17, 2003, Tyler larson <fedora-devel(a)tlarson.com> wrote:
>
> > FAT is patented my Microsoft
>
> Some FAT extensions are. The FAT filesystem format in general isn't,
> AFAIK.
Information from the source:
http://www.microsoft.com/mscorp/ip/tech/fat.asp
It appears that they are only charging for it if it's being used on
hardware devices (flash cards, portable devices, etc.). They don't
mention anything about shipping *software* with FAT support.
That's what that web page says today. What makes you think that this is
what it will say tomorrow? Next week? Month? Year?
The decision whether to rip FAT out is not likely to be based on what that
webpage says today.
Perhaps someone should email "fatspec at microsoft dot com"
to find out
for sure.
Neither will it be based on any response anyone gets from that E-mail
address.
5:23 p.m.
On Wed, Dec 17, 2003 at 08:40:02AM -0700, Tyler larson wrote:
> Removing FAT support will have negative implications.
FAT is patented my Microsoft, and they're recently announced that
they're going to start enforcing that patent. It's not a question of how
useful FAT is, it's a question of whether or not we *have* to remove it.
and what is actually patented and what is actually relevant and what prior art
exists. FAT itself is very old but VFAT is a bit different. Obviously this is
all something Red Hat legal people have to look into.
More likely however is that Microsoft will push a "new" super-fat DRM encrypted
system to all the camera people.
9:32 p.m.
On Wed, 2003-12-17 at 16:23, Alan Cox wrote:
On Wed, Dec 17, 2003 at 08:40:02AM -0700, Tyler larson wrote:
> > Removing FAT support will have negative implications.
>
> FAT is patented my Microsoft, and they're recently announced that
> they're going to start enforcing that patent. It's not a question of how
> useful FAT is, it's a question of whether or not we *have* to remove it.
and what is actually patented and what is actually relevant and what prior art
exists. FAT itself is very old but VFAT is a bit different. Obviously this is
all something Red Hat legal people have to look into.
More likely however is that Microsoft will push a "new" super-fat DRM
encrypted
system to all the camera people.
While Microsoft is definitely pushing licensing on the flash
media/digital camera people, the irony is that the patents listed cover
the FAT extensions that handle long filenames... which digital cameras
never use.
It'll be interesting to see how that plays out.
5:55 p.m.
Rather than a wishlist of things I'd like to see in Fedora Core 2, I'd
like to see if somethings could be eliminated. I would suggest a careful
inventory of all that is included to see what could be eliminated for
the sake of simplicity and size.
For example, there has been some good talk of trimming the fat from the
screensaver list and delivering a much smaller list of good screensavers
(rather than a giant list of mediocre ones). I would like to see similar
efforts throughout the distribution.
I'm not suggesting anything controversial or significant be removed -
just a search for 'low hanging fruit' - trim the obvious fat (if it's
out there).
I don't have any specific suggestions for this (sorry) - just the vague
suggestion to keep an eye out for things that could be
eliminated/cut-back. Less code means easier debugging, faster downloads,
easier distribution, etc.
Thanks,
Steven Garrity
6 p.m.
I think no one asked for :
XFree86 4.4
I get a whitewashed screen on my radeon 9200 with current rawhide
XFree86, the binary XFree86 4.4 snapshots on XFree86.org fix it but I've
just discovered an exec-shielded 2.6 kernel kills them:(
Cheers,
--
Nicolas Mailhot
1:03 a.m.
I would really double that one!
Now that everyone can make a cheap file cluster using for instance
firewire disk connected to two computers. It would really be great if
fedora encurage people to play with it.
It would really be a big value add for redhat EL series if a good tested
gfs implementation got in it. And for that to happend, fedora should be
its testing ground!
+1 On GFS
--Kjetil
fre, 19.12.2003 kl. 01.10 skrev Bill Rugolsky Jr.:
One more item for the FC2 wishlist:
o GFS! :-)
Regards,
Bill Rugolsky
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
8:40 a.m.
On Thu, Dec 18, 2003 at 07:10:12PM -0500, Bill Rugolsky Jr. wrote:
One more item for the FC2 wishlist:
o GFS! :-)
:-)
I think it's a matter of timing more than anything. But it's time
for me to chant my mantra: upstrea, upstream, upstream. We are very
cautious about putting things in Fedora Core that aren't upstream,
even our own stuff. Honestly, it's a bit early to set timeframe
for GFS in regards to FC.
But I'm glad to hear that this announcement we made sounds good to
you!
michaelkjohnson
"He that composes himself is wiser than he that composes a book."
Linux Application Development -- Ben Franklin
http://people.redhat.com/johnsonm/lad/
9:30 a.m.
On Monday 08 December 2003 10:15 am, Michael K. Johnson wrote:
2.6 is looking good. There's a lot of integration work to do,
though.
However, that won't be the ONLY feature of Fedora Core 2.
I'd like to
hear people's wishlists. Not everything will be possible, but it would
be nice to have a good list from which to pick the possibilities, and
from which to also pick ideas later for Fedora Core 3.
Alright, I'll put in my two cents worth, with a really off-the-wall request.
I'd like to see the linux-atm userland and ATM configuration in
redhat-config-network. I'd like to see interface bonding working with both
CIP and LANE ATM connections. (for hot failover, just like I get with my
switch-to-switch PNNI connections). Being able to bind multiple LANE
interfaces to a single ATM NIC would also be very nice. Or a mixed LANE
interface and a CIP interface on one ATM NIC. PVC setup would be wonderful!
I have the network, machines, switches, NICS, and fiber to test all of this,
too. Both OC-3c and OC-12c NICs here, with the OC-12c NICs being the very
well supported Fore Marconi HE622.
And if no one else can do so, I just might have to do the work myself.... :-)
But, if I do the work, I'd like to see it integrated so others can use it.
3Com Corebuilder 7000's are so cheap on eBay right now that anyone can have an
OC-12 network for little money.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu
7440
days inactive
7455
days old
535 comments
126 participants
participants (126)
-
Adam Debus -
adam＠ausics.net -
Adrian Likins -
Akira TAGOH -
Alan Cox -
Alexander Larsson -
Alexandre Oliva -
Alfredo Sanjuan -
Antonio Buiza Calero -
Behdad Esfahbod -
Bill Nottingham -
Bill Rugolsky Jr. -
Brent Fox -
Bryan O'Sullivan -
Carwyn Edwards -
Chris Adams -
Chris Chabot -
Chris Ricker -
Christopher Blizzard -
Chuck Mead -
Chuck Mead -
Colin Charles -
Dan Williams -
Dan Young -
Daniel Guerrero -
Daniel Hedlund -
Daniel Roesen -
Daniel Veillard -
Dave Jones -
David Zeuthen -
Dax Kelson -
Earle Nietzel -
Ed Marshall -
Edward C. Bailey -
Emmanuel Seyman -
Enrico Scholz -
Eric S. Raymond -
Farkas Levente -
Felipe Alfaro Solana -
Fernando Lopez-Lezcano -
Florian La Roche -
Gene C. -
Giacomo Magnini -
Greg KH -
Gérard Milmeister -
Ian Kent -
Ian Wells -
Jaap A. Haitsma -
Jack Aboutboul -
James Ralston -
Jean-Rene Cormier -
Jens Knutson -
Jens-Ulrik Petersen -
Jeremy Katz -
Jeremy Portzer -
Jesse Keating -
Joe Orton -
Jonathan Blandford -
jorge o. castro -
Josep Puigdemont -
Julien Olivier -
Justin M. Forbes -
Jörn Rink -
Karl DeBisschop -
Keith Sharp -
Kjetil Mikkelborg -
Klaasjan Brand -
Konstantin Ryabitsev -
Lamar Owen -
Laurent GUERBY -
Lenz Grimmer -
M A Young -
Mark Lane -
Mark Mielke -
Matthew T. O'Connor -
Michael Honeyfield -
Michael K. Johnson -
Michael Schwendt -
Mike Snitzer -
Miloslav Trmač -
Nalin Dahyabhai -
nathan r. hruby -
Nicolas Mailhot -
Nigel Metheringham -
Nils Philippsen -
Oden Eriksson -
Ori Pessach -
Owen Taylor -
Panu Matilainen -
Pau Aliagas -
Paul Heinlein -
Paul Jakma -
Philip Wyett -
Ricardo Ariel Gorosito -
Robert Marcano -
Ronny Buchmann -
Roozbeh Pournader -
Rudi Chiarito -
Sam Varshavchik -
Samuel Flory -
seth vidal -
Stan Bubrouski -
Stephan Windischmann -
Stephen C. Tweedie -
Stephen Smoogen -
Steven Garrity -
Steven Pritchard -
Stuart Children -
Tadashi Jokagi -
Telsa Gwynne -
Thomas Bendler -
Thomas Dodd -
Tom Diehl -
Tommy Tovbin -
tony -
Trae McCombs -
Tyler Larson -
Vic Gedris -
Vincent -
Warren Togami -
Wil Cooley -
Xose Vazquez Perez -
Yovko Lambrev -
Yukihiro Nakai -
Yusuf Goolamabbas -
Zoltan Boszormenyi