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!)
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
With respect to the KDE case, if there were (with the same builds,
from the same source RPMs already available)
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?
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
Now that the fedora process is opening up development a bit more, I suspect
more people are frequently downloading rawhide. Has there been any thought
about making it available usably over rsync?
The current drawback to using rsync is that what's posted to rawhide are
packages, and package names change so rsync can't find the preexisting
similar bits. Consider, just to pick one example, unixODBC. Yesterday,
unixODBC-2.2.5-8 was pushed to rawhide. Today, unixODBC-2.2.5-9 was pushed.
The only difference between the two is that in -9 Fernando tweaked ~4 lines
of text in /etc/odbcinst.ini, yet to get that I have to download the whole
thing again b/c rsync sees them as different files and therefore doesn't
One way to make rsync work with rawhide would be to autogenerate isos (not
full working isos which can be booted off of and such, just the RPMs) on a
daily basis, then to use the hardlinks script that the RH mirrors often use
to explode the contents off of loopback-mounted isos. People could then just
rsync ftp.redhat.com/pub/redhat/linux/rawhide/iso/daily.iso and save some
bandwidth on both sides....
Thoughts? Is this feasible on the RH side? Of interest to anyone else on the
I've been doing some research on getting union mounts to work on Linux,
but it doesn't appear that Fedora currently supports it! Is this
accurate? If so, is there anything on the horizon, or will I have to
use *BSD to get this? (ewwwwww.)
"The bugs in Sawfish, and its greater configurability, are not
-- Havoc Pennington
yum 2.0.4 is out:
- update the russian translations from Grigory Bakunov
- make reference to the yum howto from README
- fix distroverpkg to look for something providing the
name - not just the pkg named that
- arch cleanups - add some stuff for sparc64, ppc64 and x86_64
might not be perfect for those but in the right ballpark.
- better error reporting for file and other conflicts.
- make modes work better for yum list and yum info in the event
it's being run as a user and the headers haven't been updated
- yum provides/ yum search more intuitive with use of wildcards
- progress bar
- update out of dep loop
- increased default number of retries from 3 to 6.
- misc bugfixes and cleanups.
Get it from here:
MD5SUM = 17a436b024a9e7144ae2183bb731b726
let me know what's broken - yum bugzilla:
I came across the announcement of a new version of Gnome System Tools (a
project lead by Ximian) a few days ago. They resemble the redhat config
tools quite a bit, though they have only have 5 tools up to now (not
really production ready according to the website but still)
# Users and groups
# Date and time
# Network configuration
The nice thing is that the front end (The GUI) is distribution
independent and the backend (configuration files etc.) are distribution
Just some thoughts/questions.
Wouldn't it be better for RedHat, SuSE, Debian etc. to just join this
effort. It's a lot more effective then every distro provider making
their own tools. (I see that there's maybe an issue for KDE users)
Are there any initiatives to have a standard of configuration files,
which are used by all providers. I heard of LSB, but it seems to me they
do not standardise configuration files.
* Sun Oct 19 2003 Dan Walsh <dwalsh(a)redhat.com>
- Fix post install processing
* Sat Oct 18 2003 Florian La Roche <Florian.LaRoche(a)redhat.de>
- prereq scrollkeeper-update
I see in the FAQ (http://fedora.redhat.com/about/faq/) that fedora
intends to provide DVD ISOs. Are these available?
I have a lovely new DVD-Writer and I'm more than happy to help test.
Another too-late-for-this-time-but-maybe-next-round application:
Essentially, it's a tool for checking the ink level of inkjet printers
under Linux. It allows you to figure out what's wrong with the printer,
even if your printserver is not running Windows so you can't run the
proprietary printer tools.
I missed this functionality badly since i bought my Epson Stylus Photo
780, but now i can do it, thanks to ink.
It works pretty well, it can access the printer even if CUPS is running,
there's no device access conflict or anything.
So perhaps it's worth including it in the distribution.
Since the RPM packages offered on the website do not compile on Red Hat,
i made some packages on RH9 and uploaded them here:
Back in January I started packaging up Device-Mapper, and LVM2, and
made some changes to initscripts, mkinitrd, etc., to get root-on-lvm2.
Now that device-mapper is stabilizing, I'd like to take up this task
again and contribute the changes to Fedora core. Before doing so,
I'd like to solicit some feedback on how to proceed with changes to
1. nash is inadequate to the task. Replacing it with a real shell
and other tools will take us over the size limit for
a floppy. Does it matter any more? A kernel with ACPI won't fit
on a floppy either, and we are going to want to include a lot of
userland discovery code in initramfs as we move into 2.7.
Once we exceed the size of a floppy, is there another "natural"
size constraint that would prevent just using the usual tools, such
as mdadm, perhaps in a multi-call binary or rebuilt against klibc?
2. People are going to use various combinations of MD, Device-Mapper,
LVM2, and EVMS2. Do we want to support the simultaneous, stacked
use of all of these? Is that too complicated, and should, e.g.,
(LVM2+dmsetup) and EVMS2 be mutually exclusive? One of the nicest
features of EVMS2 is the support for legacy partitions. This can
also be done with dmsetup and some scripting, or by generalizing LVM2.
3. We currently lack any infrastructure for reconfiguration in early
userspace. There are numerous maintenance tasks that require that
a resource be taken offline, e.g., repartitioning, or shrinking a
filesystem. I am currently working on scripts to do a system upgrade
(repartition, etc.) on a RAID1 system with minimal downtime by (a)
breaking the mirror, (b) upgrading the detached half, (c) reboot
using the upgraded system image, and (d) resyncing the mirror.
One could as well imagine support for pulling a new system image
from a server. Ideally, there would be infrastructure to just drop
in early userspace scripts. Initramfs makes this easy, because one
can just append a cpio archive with the required files.
4. Volume management is just one of many tasks that need attention
in early userspace. Is there a roadmap anywhere?
Any thoughts or pointers to works-in-progress would be appreciated.