Better packaging for older hardware?
by M. Fioretti
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
20 years, 5 months
rsync and rawhide
by Chris Ricker
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
compare them....
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
client side?
later,
chris
20 years, 5 months
Union mounts
by Jens Knutson
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.)
- jck
--
"The bugs in Sawfish, and its greater configurability, are not
orthogonal/unrelated facts"
-- Havoc Pennington
20 years, 5 months
Gnome System Tools toughts
by Jaap A. Haitsma
Hi,
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
# Bootloaders
# Runlevels
See: http://www.gnome.org/projects/gst/index.html
The nice thing is that the front end (The GUI) is distribution
independent and the backend (configuration files etc.) are distribution
dependent.
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.
Jaap
20 years, 5 months
rawhide report: 20031019 changes
by Build System
Updated Packages:
caching-nameserver-7.2-9
------------------------
* Sun Oct 19 2003 Dan Walsh <dwalsh(a)redhat.com>
- Fix post install processing
gnopernicus-0.7.0-4
-------------------
* Sat Oct 18 2003 Florian La Roche <Florian.LaRoche(a)redhat.de>
- prereq scrollkeeper-update
rawhide-release-20031019-1
--------------------------
20 years, 5 months
DVD Isos
by Michael A. Koziarski
Hey guys,
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.
Cheers
Koz
20 years, 5 months
ink
by Florin Andrei
Another too-late-for-this-time-but-maybe-next-round application:
http://home.arcor.de/markusheinz/ink.html
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:
ftp://andrei.myip.org/ink/
--
Florin Andrei
http://florin.myip.org/
20 years, 5 months
early userspace and volume management
by Bill Rugolsky Jr.
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
early userspace.
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.
Regards,
Bill Rugolsky
20 years, 5 months