[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
The Tech page
This is the page for people who are programmers or have a deep knowledge
Linux submitted for comments.
Jean Francois Martinez
The Independence project: because Linux should be for everyone
Technical tasks for Independence
Indy needs programmers of course but it also needs people
with a good knowledge of Linux to help with some
technical tasks who don't require programming.
Programming projects open
A screen adjuster
At the end of installation it is not unfrequent the user finds under X
only part of the screen is used. User can use xvidtune to solve this,
provided he knows about it and he still has to patch the numbers in
the XF86config. It also means the installation does not deliver a
ready for use machine.
Suse has an a attractive solution for this problem but it is
The goal would be to provide a GPLed tool for screen adjustement.
Since it will be used in the installer it must use Gtk or Perl/Gtk.
Finally we plan to use the Mandrake X config tool (who allows to change
resolution and color depth) and we want it being able to call the
A general installer for software we cannot distribute
If you want to play 3D games in Linux you need hardware-accelerated
OpenGL. The most widely used 3D cards are NVidia. NVidia provides
drivers but user needs to:
This only an example, not the most difficult one; of installing a
driver the distribution cannot ship. Unfortunately NVidia drivers
(and some others) are critical for Linux success. So the goal would be
to create a general installer who would take a description file
(provided by Indy) as input and by following it would be able to
install the software. It is acceptable to prompt the user at times and
to have some manual operations: in the example above the user would
- Download the driver
- Download a special kernel module
- Compile that kernel module
- Install it
- Install the driver
- Modify the XF86Config-4
- Restart X
Modify the internet configurator for USB-based ADSL modems
Indy ships a pretty good configurator for internet access. But it
only supports analogic modems and ethernet-based ADSL modems.
Unfortunately the USB-based ADSL modems are cheaper and more popular.
That means Linux users have to pay more than Windows users (or
configure by hand). It also means the first thing a new user sees
from Linux is that he is not able to surf the internet. Pretty bad
propaganda. The goal would be to add a backend to the configurator
for USB modems support. Configurator uses Gtk.
There is much software we would like to include but were unable to
build RPMS for it. Some other we have included but were unable to add
the final little touch at installation who would have allowed for
better integration, greater usefulness or to have it work out of the
box. Finally there is a time gap between the moment we build a
package and the moment it included in the distro. Having more people
building or maintaining RPMS would allow us to ship more, better
polished and newer software. There is a free e-book at ftp://ftp.rpm.org/max-rpm. You
will need to read Indy's
requirements for RPM building. Read also our list of software we would like to include in
Fear of kernel recompiling and lack of support for crucial peripherals
have ever been major deterrents for people considering use of Linux.
About recompiling I consider that since 1996 it should be a thing of
the past: we have technoloy (modules) to avoid it so if user
needs to recompile the kernel then we did something
wrong and we should fix it.
About unsupported hardware we
need to make an effort towards widely used budget peripherals like
Winmodems or USB-based ADSL modems (AFAIK Independence is the sole
distro who has made something about the popular SpeedTouch ADSL
modem). Telling Winmodems suck and should not be used under Linux is
not an answer: what the user sees is that he is unable to connect to
the net, what he sees is that he has to buy a new modem more expensive
than his own and what we see is him dropping Linux. The Indy
answer will be to go to href="http://www.linmodem.org grab all
the drivers who seem good and include them. About USB modems the
SpeedTouch required a proprietary component to work. But it also
required several free components and installing it was a nigtmare.
The Indy answer was to include all the free components and make the
installation less of a nightmare. We would like to make the same for
other peripherals. In Indy we try to support those peripherals people
buy when they are paying from their own pocket. Indy's goals require
Indy having best sound available so we are considering shifting to
Alsa drivers. But we need a person caring for the kernel.
Software comparison, technological watch
There is software who IMHO is better judged by people who are NOT Unix
experts: example sound software is better judged by a musician. Other
programs should be judged by people who are not biased by a long
familiarity with Unix ergonomy. But judging technical programs like
mail transport agents is best left to people with Unix expertise and
preferently expertise in that field. Indy's philosophy requires we ship only the
best programs so we need people determining them.
We also need
people willing to investigate other distros (Suse, Mandrake, Caldera,
Redmond Linux, not RedHat since it is our base) looking for features
Indy lacks and studying how they work in order we can add them to Indy.
As a minimum you would have to track RedHat's security updates, mirror
them in the Indy tree and then announce in the security lists and in
Indy list. If package is specific to Indy (ie the string Indy appears
in the name) contact the package maintainer. If you feel more
ambitious you could build our own security fixes without waiting for
RedHat's. Indy needs developers, for that it needs to become known and
fast security fixes are a way to do it.
As long as fonts will look so ugly as now it will be difficult to push
Linux for desktop use. We want:
- Have Indy use antialiasing
- Assign priorities to font families so by default X ever uses the
best font available. Font order is presently non deterministic and
depends on the order of installation. The trick would be to use
directory scanning like it is done in init.
- Ensure the antialiasing libraries like gdkxft are in sync
with installed fonts
- Port to Indy Mandrake's solutions for including fonts from Windows
partitions and Windows sites
In Indy we assume user has to care for himself from day one and we
don't assume "root" has previous knowledge of Linux (typical for home
users). It means Indy must be tolerant to user errors, easy to
recover, secure out of the box and that we can't let customizations
for the user when we can deduce them. Some ideas are:
Make font handling in X more robust: if font server has been
stopped then X will not start. Solution would be to use a short fixed
font path in the X config (so X will ever start) and use an xset
fp command in the X startup files so X will use the font server if
there is one.
- Insert entries in the boot menu for "disaster repair" boots
(single user, no startup, init=/bin/sh) or a text explaining how to do
it: if user is unable to boot he will be unable to reach the info
lying in his Linux partition
Cut the list of daemons started
at boot time. They are less of a security problem than they were
since Indy is firewalled out of the box but they still use unnecessary
Automatically detect attacks, inform the user and take countermeasures
Properly care of dial up sites: in many countries online time is
expensive so through a proper daemon selection (eg wwwoffle is better
than squid for dialup sites) and configuration we want Indy users
being able to shorten their online time. We also want daemons taking
action when dialup link changes state: eg an MTA should automatically
send mail when site becomes online.
Implement changes in desktop's ergonomy: design a system for
translating RedHat and Mandrake's menus to our standards, populate the
screen background with icons, have Indy default to black screen saver
and use power saving...
"Release early, release often" is vital in a free project
since it is good for developper's moral, keep users excited and
attracts attention about the project. But building a newer Indy
release is not a trivial task and the overhead it involves precludes
us from implementing a "release often" policy: it requires to merge
updated and Indy specific packages with the base distribution, weed
out deprecated software, edit the files controlling the installation,
build the database, slice the distro in CD-sized chunks, burn the isos
and check the install works. Even with software tools (both our own
and RedHat's) development is stopped for a significant amount of time.
A person taking charge of the masterization phase would allow us to
noticeably increase development pace and generate more interest about
Indy through frequent releases (around once a month).
Indy is no longer vanilla RedHat: some programs have been removed,
some others have been added and in at least one significant area
(printing) it has undergone some drastic changes. Distance between
Indy and RedHat is only going to increase in future releases. That
means RedHat's doc will be more and more unadequate for the Indy user.
We need a doc detailing how things are done in Indy and presenting the
software we ship so the user knows it is there.
Welcoming people who want to contribute, tracking task status, caring
about infrastructure (mailing lists, ftp space, mirrors), ensuring the
web site is uptodate and all what is needed for the project flowing
smoothly and resources being used efficiently.