The Tech page

[Jean Francois Martinez <jfm2@club-internet.fr>]

This is the page for people who are programmers or have a deep knowledge
of
Linux submitted for comments.
-- 
                Jean Francois Martinez

The Independence project: because Linux should be for everyone
http://independence.seul.org

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 proprietary
  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 screen adjuster.

• 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:
  1. Download the driver
  2. Download a special kernel module
  3. Compile that kernel module
  4. Install it
  5. Install the driver
  6. Modify the XF86Config-4
  7. Restart X
  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 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.

Build RPMS

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
Independence.

Kernel affairs

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.

Security maintenance

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.

Font problem

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

Customizations

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 resources
• 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...

Masterization

"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).

Documentation

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.

Coordination

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.

Joining