1:29 a.m.
Greetings,
As some of you may already know, the RULE project (see my signature)
works to make the latest stable release of Red Hat useable on very
low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks).
This is not an academic exercise: students and schools in developing
(and "developed") countries often have only 5/6 years old computers
from donations, without money to buy more parts for them, when those
parts still exist.
To have an idea of what we do in RULE, please have a look at our
website, maybe starting from these very short pages:
http://www.rule-project.org/en/faq.php (please start here!)
http://www.rule-project.org/en/what_can_rule_do.php
http://www.rule-project.org/en/sw/kdrive.php
http://www.rule-project.org/en/news/vumbox.php
http://www.rule-project.org/en/news/state_of_the_rule_200310.php
Now to the actual issue. RULE will now switch to Fedora. Since this is
a community based project, we hope that the issues addressed by RULE
can receive more attention than a corporation could afford (this is not
a critic to Red Hat: a company must make ends meet and produce money,
no question about that).
We are not going to ask that the whole project is turned upside
down. There are a few things, however, that would make the life of
RULE school and private users a whole lot easier, and be almost
transparent to other users.
I refer to building:
1) kdrive RPMs whenever the XFree86 ones are updated.
2) i386 kernel RPMs, possibly tweaked for low RAM.
3) (this is maybe the most important) single RPMs of several user
friendly desktop applications.
Practical example: a lot of RULE end users will be non programmers
without any prior PC experience, and they will only need email, web
browsing and to do simple homework.
They would have real problems to use mutt, no possibility to run a
compiler, no skills to do it. Their ideal solutions would be to have
fedora RPMs to install (just as an example!!!) ONLY Kmail (or
sylpheed), Gnumeric or KOffice, Konqueror... without any other
applications and/or the most advanced/cool features of Gnome and
KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice
or blackbox.
With respect to the KDE case, if there were (with the same builds,
from the same source RPMs already available)
kmail.rpm
konqueror.rpm
and the current kde packages, which are actually monolithic bundles of
much more stuff, became "meta-packages" which just require the single
things, situation would be:
much much better for RULE users, no more forced to trash a computer
because it won't fit "hidden" apps never needed.
almost transparent to power end users: they would continue to
install/update as usual "kde desktop", "gnome desktop", and so on,
without ever noticing what happened below.
What do you think?
Ciao,
Marco Fioretti
RULE project coordinator
--
Marco Fioretti m.fioretti, at the server inwind.it
Red Hat for low memory http://www.rule-project.org/en/
Human beings act intelligently only after they have exhausted the
alternatives -- Abba Eban
2:14 a.m.
On Sat, 18 Oct 2003, M. Fioretti wrote:
Greetings,
As some of you may already know, the RULE project (see my signature)
works to make the latest stable release of Red Hat useable on very
low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks).
This is not an academic exercise: students and schools in developing
(and "developed") countries often have only 5/6 years old computers
from donations, without money to buy more parts for them, when those
parts still exist.
To have an idea of what we do in RULE, please have a look at our
website, maybe starting from these very short pages:
http://www.rule-project.org/en/faq.php (please start here!)
http://www.rule-project.org/en/what_can_rule_do.php
http://www.rule-project.org/en/sw/kdrive.php
http://www.rule-project.org/en/news/vumbox.php
http://www.rule-project.org/en/news/state_of_the_rule_200310.php
Now to the actual issue. RULE will now switch to Fedora. Since this is
a community based project, we hope that the issues addressed by RULE
can receive more attention than a corporation could afford (this is not
a critic to Red Hat: a company must make ends meet and produce money,
no question about that).
We are not going to ask that the whole project is turned upside
down. There are a few things, however, that would make the life of
RULE school and private users a whole lot easier, and be almost
transparent to other users.
I refer to building:
1) kdrive RPMs whenever the XFree86 ones are updated.
2) i386 kernel RPMs, possibly tweaked for low RAM.
3) (this is maybe the most important) single RPMs of several user
friendly desktop applications.
Practical example: a lot of RULE end users will be non programmers
without any prior PC experience, and they will only need email, web
browsing and to do simple homework.
They would have real problems to use mutt, no possibility to run a
compiler, no skills to do it. Their ideal solutions would be to have
fedora RPMs to install (just as an example!!!) ONLY Kmail (or
sylpheed), Gnumeric or KOffice, Konqueror... without any other
applications and/or the most advanced/cool features of Gnome and
KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice
or blackbox.
With respect to the KDE case, if there were (with the same builds,
from the same source RPMs already available)
kmail.rpm
konqueror.rpm
and the current kde packages, which are actually monolithic bundles of
much more stuff, became "meta-packages" which just require the single
things, situation would be:
much much better for RULE users, no more forced to trash a computer
because it won't fit "hidden" apps never needed.
almost transparent to power end users: they would continue to
install/update as usual "kde desktop", "gnome desktop", and so on,
without ever noticing what happened below.
IMHO it is bloat. I thought the idea was to reduce the size of FC. See below.
What do you think?
Sounds like something for fedora extras once that is setup. Since Red Hat is
still controlling the devel on FC I do not think it would get in there and
as long as someone wants to maintain the packages I do not see a problem with
that. If the RULE project is already maintaining these packages they could
simply be moved to FE, IMHO putting an i386 kernel etc in the main FC distro
would be a waste, but that is just me.
--
......Tom Registered Linux User #14522 http://counter.li.org
tdiehl(a)rogueind.com My current SpamTrap -------> mtd123(a)rogueind.com
3:43 a.m.
On Sat, Oct 18, 2003 03:14:07 at 03:14:07AM -0400, Tom Diehl (tdiehl(a)rogueind.com) wrote:
>
> almost transparent to power end users: they would continue to
> install/update as usual "kde desktop", "gnome desktop", and so
on,
> without ever noticing what happened below.
IMHO it is bloat. I thought the idea was to reduce the size of FC. See below.
The kernel is a special case, I agree, and it is not really the most
important things. Proper packages are. Why do you think the
repackaging I suggest would be against reducing the size of FC (Fedora
Core, right? Sorry, I just came in...)? Which size do you refer to?
byte size would increase little or nothing: I'm proposing to make 10
packages of 1 MB instead of 1 of 10 MB (very rough approximation, I
agree)
Pure *Number* of binary packages: that would increase a lot, yes, but
not the complexity or maintenance effort. If you keep the same source
kdebase RPM you have today (one only) and modify the spec file so that
it creates kde_app1.rpm, kde_app2.rpm, etc... you still have *one*
code base: you apply patches to that one, and packages are rebuilt
automatically. Please let me know if and why this is not possible.
Ciao,
Marco Fioretti
--
Marco Fioretti m.fioretti, at the server inwind.it
Red Hat for low memory http://www.rule-project.org/en/
Furious activity is no substitute for understanding. -- H.H. Williams
4:02 a.m.
On Sat, 18 Oct 2003, M. Fioretti wrote:
> > almost transparent to power end users: they would continue
to
> > install/update as usual "kde desktop", "gnome desktop", and
so on,
> > without ever noticing what happened below.
>
> IMHO it is bloat. I thought the idea was to reduce the size of FC. See below.
The kernel is a special case, I agree, and it is not really the most
important things. Proper packages are. Why do you think the
repackaging I suggest would be against reducing the size of FC (Fedora
Core, right? Sorry, I just came in...)? Which size do you refer to?
byte size would increase little or nothing: I'm proposing to make 10
packages of 1 MB instead of 1 of 10 MB (very rough approximation, I
agree)
Pure *Number* of binary packages: that would increase a lot, yes, but
not the complexity or maintenance effort. If you keep the same source
kdebase RPM you have today (one only) and modify the spec file so that
it creates kde_app1.rpm, kde_app2.rpm, etc... you still have *one*
code base: you apply patches to that one, and packages are rebuilt
automatically. Please let me know if and why this is not possible.
It _is_ possible, and in fact our KDE used to be split up into
more packages. There are _always_ tradeoffs in this world
however, and more packages and subpackages _DO_ increase package
maintenance efforts. That doesn't mean subpackages should be
avoided, but it does very much mean that a balance is needed, and
that there are many other factors which determine things.
Should I put every single binary application which comes with
XFree86 in it's own separate rpm for example? Do you use xcalc?
Someone might put forth that including xcalc, xditview, etc. are
bloat, and that they only want to install the apps they will
actually use. They might even make the bogus disk space claim.
What's funny though, is that for XFree86 packaging at least,
every single sub package consumes at least a minimum of 150-200Kb
each on your hard disk, even if the package were to contain zero
files. This is because the rpm spec file changelog is stored in
the rpm database once per installed package (instead of merging
and refcounting, unless this has changed and I'm wrong now), so
any subpackage that isn't at least 400-500Kb or more in size
argueably is *wasting* space and should be merged into a
different subpackage. ;o)
Someone out there is now no doubt multiplying the size of the
changelog by the number of subpackages and calculating the total
wasted disk space in the rpm database when XFree86 is installed.
If not, it'll likely be something to the effect of:
$ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c
4433085
Or roughly 4.5Mb of your RPM database files is XFree86
changelogs. Wowsers. ;o)
Before someone asks/complains/flames/whatever about this
wasteage, I'm considering trimming the changelog down so that it
only includes changes since 4.1.0, and moving the older changes
into /usr/share/doc/XFree86-* somewhere with a pointer to them at
the end of the rpm changelog. I just checked and removing all
changelog entries from 4.2.1 and older would cut wasteage only in
half, so not that huge of a gain anyway. ;o)
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
4:18 a.m.
Mike A. Harris wrote:
...
What's funny though, is that for XFree86 packaging at least,
every single sub package consumes at least a minimum of 150-200Kb
each on your hard disk, even if the package were to contain zero
files. This is because the rpm spec file changelog is stored in
the rpm database once per installed package (instead of merging
and refcounting, unless this has changed and I'm wrong now), so
any subpackage that isn't at least 400-500Kb or more in size
argueably is *wasting* space and should be merged into a
different subpackage. ;o)
Someone out there is now no doubt multiplying the size of the
changelog by the number of subpackages and calculating the total
wasted disk space in the rpm database when XFree86 is installed.
If not, it'll likely be something to the effect of:
$ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c
4433085
Or roughly 4.5Mb of your RPM database files is XFree86
changelogs. Wowsers. ;o)
Not a complaint, but why did they/you move changelogs from the doc
directory into the RPM database? It doesn't seem like a very necessary
thing...
--
Paul
http://paulgear.webhop.net
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
4:51 a.m.
On Sat, 18 Oct 2003, Paul Gear wrote:
> Someone out there is now no doubt multiplying the size of the
> changelog by the number of subpackages and calculating the total
> wasted disk space in the rpm database when XFree86 is installed.
> If not, it'll likely be something to the effect of:
>
> $ rpm -q --changelog $(rpm -qa |grep ^XFree86) |wc -c
> 4433085
>
> Or roughly 4.5Mb of your RPM database files is XFree86
> changelogs. Wowsers. ;o)
Not a complaint, but why did they/you move changelogs from the doc
directory into the RPM database? It doesn't seem like a very necessary
thing...
I/we did not and have not ever moved changelogs from doc
directory to rpm database. You misunderstand what an rpm
changelog is.
The rpm spec file contains an optional changelog, which is very
highly recommended for everyone packaging software in rpm format
to use, and it is mandatorily required by Red Hat and most other
distributions for all software they ship, as well as most high
quality 3rd party repositories.
The rpm spec file changelog deals with distribution packager
changes to the packaging of the software, not changes to the
upstream software itself. The changelog that a given piece of
software might include in it's source code, and might install
into the doc directory is a totally different concept. That log
documents upstream changes to the software itself as it gets
checked into CVS and turned into stable releases. To keep with
my previous example of XFree86, the XFree86 upstream changelog,
is included in my XFree86 packaging and is located at:
$ dir /usr/share/doc/XFree86-4.3.0/CHANGELOG
-rw-r--r-- 1 root 935244 Jun 11 13:37 /usr/share/doc/XFree86-4.3.0/CHANGELOG
That changelog is the one produced by XFree86.org to log the
changes they make while developing XFree86.
The rpm spec file changelog, which gets stored in the rpm
database for each subpackage, is the list of
packager/distribution changes that relate to the packaging of the
software, including things like spec file changes, addition or
removal of new subpackages, addition or removal of patches along
with an explanation of what a given patch is fixing, and other
packager related changes to the packaging itself.
The two changelogs are totally different in concept, and the rpm
spec file changelog has always existed in rpm and been stored in
the rpm database, and a given upstream program's changelog - if
one exists for a given piece of software has never been stored in
the rpm database.
So your assumption that we have moved changelogs around and
stuffed them in rpm's database is incorrect.
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
7:54 p.m.
Mike A. Harris wrote:
...
>
>Not a complaint, but why did they/you move changelogs from the doc
>directory into the RPM database? It doesn't seem like a very necessary
>thing...
I/we did not and have not ever moved changelogs from doc
directory to rpm database. You misunderstand what an rpm
changelog is.
...
The two changelogs are totally different in concept, and the rpm
spec file changelog has always existed in rpm and been stored in
the rpm database, and a given upstream program's changelog - if
one exists for a given piece of software has never been stored in
the rpm database.
OK - i am now enlightened. Please forgive my ignorance.
--
Paul
http://paulgear.webhop.net
A: Because we read from top to bottom, left to right.
Q: Why should i start my email reply *below* the quoted text?
4:51 a.m.
As some of you may already know, the RULE project (see my signature)
works to make the latest stable release of Red Hat useable on very
low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks).
Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of
RAM 8)
I refer to building:
1) kdrive RPMs whenever the XFree86 ones are updated.
As I understand it keiths current kdrive XFree is very much split from
the base XFree project now because XFree86 threw him out.
2) i386 kernel RPMs, possibly tweaked for low RAM.
386/486 kernel RPMs make sense but you probably also want to think
about that as a seperate kernel with less options selected and without the
more high end tuning Red Hat has.
fedora RPMs to install (just as an example!!!) ONLY Kmail (or
sylpheed), Gnumeric or KOffice, Konqueror... without any other
applications and/or the most advanced/cool features of Gnome and
KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice
or blackbox.
Stuff like Rox instead of nautilus etc you mnean ?
Alan
5 a.m.
On Sat, 18 Oct 2003, Alan Cox wrote:
> As some of you may already know, the RULE project (see my
signature)
> works to make the latest stable release of Red Hat useable on very
> low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks).
Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of
RAM 8)
> I refer to building:
> 1) kdrive RPMs whenever the XFree86 ones are updated.
As I understand it keiths current kdrive XFree is very much split from
the base XFree project now because XFree86 threw him out.
Just so other people who read that and start possibly incorrect
rumours however, Keith wrote kdrive himself (the k in kdrive ==
keith's driver). He maintained kdrive in XFree86.org's CVS
repository officially because he had CVS write permission at the
time and it seemed logical. However since he's been removed from
the XFree86 core team for just under a year now, and doesn't have
CVS write permission anymore he is unable to maintain his kdrive
X server(s) inside XFree86.org's CVS repository any longer. In
order to continue maintaining kdrive, he had to open up a new CVS
repository in order to continue to do development on the project.
It isn't clear wether XFree86.org will update kdrive in their
tree in the future or not, or if they'll strip it from the source
code tree. It doesn't much matter IMHO either way, as Keith's
repository will always be the official repository for kdrive.
;o)
Keith has also of course been the official upstream maintainer of
Xrender, Xft, Xcursor, fontconfig, Xrandr, and other stuff, and
since he no longer has CVS repository access to further develop
those, they are also now maintained outside of XFree86
officially. All of these things are now hosted on
freedesktop.org and hopefully XFree86.org will track them and
update their sources.
It's of no real consequence if XFree86.org doesn't follow the
externally maintained libraries, etc. however as all major OS
distributions will be shifting to splitting out these libraries
anyway for easier maintenance and updating. Similar to
freetype/fontconfig/expat and other stuff being included with
XFree86 sources, but we don't use the included version, instead
we use the official upstream versions of all those. Debian,
FreeBSD, Mandrake and others most likely will track the official
upstream versions of Keith's various projects also.
HTH
--
Mike A. Harris ftp://people.redhat.com/mharris
OS Systems Engineer - XFree86 maintainer - Red Hat
6:36 a.m.
On Sat, Oct 18, 2003 05:51:05 at 05:51:05AM -0400, Alan Cox (alan(a)redhat.com) wrote:
> As some of you may already know, the RULE project (see my
signature)
> works to make the latest stable release of Red Hat useable on very
> low end hardware (i386+ 16 MB+ RAM, 3/400 MB hard disks).
Some of us know yes. Its what I used to install RH9 on a 486 with 24Mb of
RAM 8)
Gee, great. If we were a company, you'd be receiving an offer for an
outrageously overpaid ad campaign RSN. Can we quote you on that?
On a more serious note, I'd really like to hear any direct feedback
from how you found RULE and its installer. Probably offline, no need
to fill the list with it.
> 2) i386 kernel RPMs, possibly tweaked for low RAM.
386/486 kernel RPMs make sense but you probably also want to think
about that as a seperate kernel with less options selected and
without the more high end tuning Red Hat has.
Absolutely. The problem is that we realize this would be a very good
thing, but, almost by definition, have not enough expertise,
bandwidth, and CPU power to investigate all the possible
alternatives.
Please have a look to the archives of the Linux Kernel Mailing List:
less than a week ago I started a thread there, called "unbloating the
kernel". I almost explicitly say there that few things would make me
happier (software wise, of course) if some real kernel hacker spends
some day explaining to us how to tweak for RULE scenarios the
*official* SRPMs of Red Hat, soon Fedora kernels.
We can walk (almost) alone after that, just need a very good initial
push in the right direction. Right .config, proper /proc settings,
whatever.
> fedora RPMs to install (just as an example!!!) ONLY Kmail (or
> sylpheed), Gnumeric or KOffice, Konqueror... without any other
> applications and/or the most advanced/cool features of Gnome and
> KDE. On plain X or Kdrive with only Qt / Gtk and a basic WM like Ice
> or blackbox.
Stuff like Rox instead of nautilus etc you mnean ?
Exactly. In user space the first problem is that lean and mean
applications receive less and less press, especially for those coming
to desktop Linux for the first time: they have to given the choice at
install time among:
"Full featured GNOME desktop, too big for your hard disk and RAM"
"Full featured KDE desktop, too big for your hard disk and RAM"
"Dive head first for hours in an unknown foggy maze of dependencies
trying to get a leaner system"
Here we are pretty good, we just lack enough hours in the day...
The last (serious) problem in userspace is that even when you find a
seemingly light application, often it is built to pretend on disk a
tons of other libraries not needed by our users, so in the end it is
no light at all. This is what prompted my original request here.
Ciao,
Marco Fioretti
--
Marco Fioretti m.fioretti, at the server inwind.it
Red Hat for low memory http://www.rule-project.org/en/
None can love freedom heartily but good men; the rest love not freedom
but license. John Milton
9:05 a.m.
On Sat, Oct 18, 2003 at 01:36:48PM +0200, M. Fioretti wrote:
On Sat, Oct 18, 2003 05:51:05 at 05:51:05AM -0400, Alan Cox
(alan(a)redhat.com) wrote:
> 386/486 kernel RPMs make sense but you probably also want to think
> about that as a seperate kernel with less options selected and
> without the more high end tuning Red Hat has.
Absolutely. The problem is that we realize this would be a very good
thing, but, almost by definition, have not enough expertise,
bandwidth, and CPU power to investigate all the possible
alternatives.
Please have a look to the archives of the Linux Kernel Mailing List:
less than a week ago I started a thread there, called "unbloating the
kernel". I almost explicitly say there that few things would make me
happier (software wise, of course) if some real kernel hacker spends
some day explaining to us how to tweak for RULE scenarios the
*official* SRPMs of Red Hat, soon Fedora kernels.
We can walk (almost) alone after that, just need a very good initial
push in the right direction. Right .config, proper /proc settings,
whatever.
It wouldn't be hard for us to provide an appropriately trimmed
config file in the kernel srpm, automatically maintained to follow
generic changes to the config files but with specific slimming
changing, even if we didn't build that kernel by default. It
might break without our noticing in that case, but then that could
always be fixed...
However, the only "slimming" bits we have expertise of any sort in
is summed up in the BOOT kernel config file, so we'd need a pretty
good idea of what kinds of changes we were going to make that would
really satisfy most everyone... That's the real hard part.
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:07 a.m.
On Sat, Oct 18, 2003 10:05:41 at 10:05:41AM -0400, Michael K. Johnson
(johnsonm(a)redhat.com) wrote:
It wouldn't be hard for us to provide an appropriately trimmed
config file in the kernel srpm
Please do it! This would be an excellent solution. RULE and similar
projects could create the RPMs with the confidence that they have been
reviewed by expert, and that the resulting kernel would have the
highest probabilities to work fine with fedora libraries and userland
packages. At the same time, FC would not see uninteresting packages
added.
However, the only "slimming" bits we have expertise of any sort in
is summed up in the BOOT kernel config file, so we'd need a pretty
good idea of what kinds of changes we were going to make that would
really satisfy most everyone... That's the real hard part.
Maybe is not so hard. Once we have agreed on the procedure above,
whenever we at RULE find or are told some other trick we'll pass along
it here and/or the srpms maintainers, maybe after testing them
ourselves: In this way, everybody would know it, even if not
immediately interested, and you would know how to further patch that
special .config file whenever the official FC kernel is updated.
When it comes to "what would really satisfy everyone" it might be even
simpler. As far as I can see, today everybody who needs to run a Red
Hat/Fedora distro on low end hardware:
1) does it himself, for fun and profit, or
2) is already involved/using RULE, or
3) is told to go try RULE
(I'm just summing up the current situation, not pretending to
establish any kind or monopoly/hegemony: this is just what I see from
where I sit. So far, almost everybody passing through point 3) because
1) was above his possibilities:
ended up happily in point 2), or
changed distro altogether because eventually no Red Hat
lookalike would not fit his bill)
In other words, you might look at the RULE requirements, and just go
for them. Specifically, a good starting point are these urls:
http://www.rule-project.org/en/en/what_can_rule_do.php (use cases)
http://www.rule-project.org/en/test/ (the kind of HW
we need to make useful)
I have to leave now, but will be happy to provide whatever further
feedback you might need.
The corner case(s) we could safely ignore is somebody who just needs
to use some extremely weird piece of NON-standard very old hardware,
only 100 units still existing on the whole planet, which requires more
patching of the kernel. Nobody can do miracles.
Ciao,
Marco Fioretti
--
Marco Fioretti m.fioretti, at the server inwind.it
Red Hat for low memory http://www.rule-project.org/en/
The whole world is a tuxedo and you are a pair of brown shoes.
-- George Gobel
2:26 p.m.
On Sun, Oct 19, 2003 at 04:07:15PM +0200, M. Fioretti wrote:
On Sat, Oct 18, 2003 10:05:41 at 10:05:41AM -0400, Michael K. Johnson
(johnsonm(a)redhat.com) wrote:
> It wouldn't be hard for us to provide an appropriately trimmed
> config file in the kernel srpm
Please do it! This would be an excellent solution.
What we can't do is come up with the definition of what to trim...
So when you have an initial set of suggestions for changes, lets
discuss the suggestions of changes here.
Just post them as
# CONFIG_FOO is not set
CONFIG_BLAH=128
etc, for discussion.
In other words, you might look at the RULE requirements, and just go
for them. Specifically, a good starting point are these urls:
Well, Red Hat isn't going to create the set of suggested changes.
We can review suggestions and if some general agreement is reached
we can help keep a config file in sync because we have the
infrastructure to do it without too much pain; as I said before,
that would be opportunistic and when it broke, we wouldn't know
until the breakage was reported, and then we'd want to see the
suggested fix from RULE.
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:03 a.m.
On Mon, Oct 20, 2003 15:26:27 at 03:26:27PM -0400, Michael K. Johnson
(johnsonm(a)redhat.com) wrote:
So when you have an initial set of suggestions for changes, lets
discuss the suggestions of changes here.
Just post them as
# CONFIG_FOO is not set
CONFIG_BLAH=128
etc, for discussion.
I will forward this to the RULE mailing list. Personally, I have
almost no idea about the settings to change. Others on the list are
more expert. Every suggestion here is still welcome, of course.
Ciao,
Marco Fioretti
--
Marco Fioretti m.fioretti, at the server inwind.it
Red Hat for low memory http://www.rule-project.org/en/
Furious activity is no substitute for understanding. -- H.H. Williams
7495
days inactive
7498
days old
13 comments
6 participants
participants (6)
-
Alan Cox -
M. Fioretti -
Michael K. Johnson -
Mike A. Harris -
Paul Gear -
Tom Diehl