[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 of
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

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:


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:


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