Fedora Core Customizer

This is a new project to write a new software to enhance and customize Fedora Core X systems.

Wednesday, March 08, 2006

Shifted to WordPress!!

Owing to really cool features provided by WordPress (www.wordpress.com), I have shifted to it.


PS: All posts of this blog (except this one) have been ported there, so there is no need to keep checking this one.

Monday, October 10, 2005

How much relevant is this?

We've been having talks about the relevance of this project. There is this "Redhat Scholarships", and we had thought of doing this one for this scholarship.

Analysing the requirement of this project, we see, what all it will "actually" add.

* I wont be required to install a few media players manually.
* I will have one more icon to start XMMS for me, heh.
* It will possibly install all other softwares I need!

Lets look into it this way.
* How many softwares are actually provided in palatable form such as RPM or SRC RPM or even an easily compilable source?
* How many times does it happen that we can install a software flawlessly, and flawlessly on more than one system with the same procedure?
* How many people will actually consider installing it for installing media players for them, which are in some way, easily installable?
* How will it do any better than YUM?
* How many softwares does Fedora lack? (its almost a complete solution for everything)

With the current state, its not possible to frame a really convincing "Requirements list". We will wait for more ideas to pour in, and begin only when the relevance of the project is proved.

Wednesday, September 21, 2005


Well, its been long since we last had a discussion on this project, but, another IDEA which has struck me is, instead of trying really hard to get "Fedora Core 2", "Fedora Core 3" and "Fedora Core 4" into a more usable form by providing software in addition to the basic setup, why don't we try to MODIFY Fedora Core 4, and create a custom Operating System that has all the features MISSING in Fedora Core 4.

Legally, this can be done as FC4 is released under GPL. I read more about the licensing policy and end user license agreement of Redhat Inc. It clearly states that we are free to modify and redistribute a modified version of Fedora Core, but we are NOT ALLOWED to use "Fedora Core" "Redhat" brand names or logos in the new software. That'd just mean changing some screens and image files.

Technically, I was looking at how the REDHAT 8/9/Fedora Core CDROM is formatted. It follows something called the "comps.xml" format. We need the comps-extras rpm package installed in order to "edit" the default installation of Fedora Core, add, substract packages, etc. This will enable us to safely add packages to the "basic setup", and also allow us to replace "mp3 crippled" kdemultimedia packages with the original ones compiled from kde.org. Similarly, we can include the good media players and some initial scripts plus a good theme, etc. to make the "new operating system" as BETTER THAN FEDORA CORE 4. I still haven't thought of any name, but for the time being, lets call it "JOSH" (Josh Operating System Hai! .. kind of recursive name, hehe)

I'll be trying to understand this more and more, and will simultaneously look for all the required things not "already" present in FC4, and also those "not installed by default".

Another point is, legally, we CAN use Fedora Core 4 (modified) as the brand name, if "there is a provision" to separate out "Fedora Core 4" and the "(modified)", and the user has an option to "use the Fedora Core 4 original setup" as well as "install the customized setup", so we might consider that too.

In addition to these plus points with the new idea, there are a few drawbacks too.
1. Generally Linux users are reluctant to REINSTALL their distro.
2. This would mean, if you want to have a user friendly Fedora, get my distro, there is no other option, while, providing a customizer disk would provide all people to modify their distro, even if the basic setup was the same old.
3. Its more mechanical to follow this idea, and more challenging to try to make a generic customizer software.
4. Creating a new distro will somewhat cripple it, because no server has updates for it.
5. I kind of like the name Fedora Core ;)

Redhat Trademark Guidelines
formatting comps.xml
Creating a custom OS

Friday, August 05, 2005

Trying out with understanding .HDR format...

The first thing to simulate YUM is to understand the format in which it downloads the headers of any RPM package. As YUM clearly specifies that HDR are the headers of any RPM and it uses RPM API to access the information, we need to first learn to parse a .HDR file.

The most intuitive feeling which arises is, do the first bytes of RPM files match with HDR files? No, they don't. But it is not the case that there is no relation. If we ignore some of the bytes in both files, we find that the bytes are exactly same.

Doing a statistical analysis of a RPM and a HDR, (kernel-2.6.12-1.1398_FC4), I found that ignoring the first 440 bytes of the RPM, the HDR is exactly same with the corresponding bytes in the RPM. Thus, there is certainly a relation. It must certainly have been mentioned in the RPM API. I am still reading and trying.

Also, the YUM sourcecode is of help. Still trying to find a file which actually downloads the header from the server and parses it.



Thursday, August 04, 2005

Query response for poorna shashank...

So does that mean when a joe wants to play mp3s on his pc, your (5th cd)/FCC will take care of all that?

does that mean that once joe doesnt want to play the media, the software installed will be deleted from user?

Can i assume that your software will be similar to 'Software-On-CD' something akin to 'Linux-On-CD'. Which simply means, once the cd is taken out the system is as is? Or you are going to make permanent changes to the system?

No, its not a "Linux-On-CD" kind of a thing. If you see Discussion No. 1, we clearly state that it is "installed on the system just like a control panel".
* AJ can open FCC (FC Customizer).
* Search for a particular capability and install.
* Browse through the already installed capabilities and use.
* Remove a capability.
* Set the preferences about the Internet Repos, etc.
* Update the software database/version using the next released CDROM.
* Some other features which we might think of later.

So, what is your response after you know this additional information about the whole design? Is there any way of improving? Is there any other feature which is a MUST-INCLUDE? Waiting for a prompt response. You can get membership of this blog and post directly, want it?

Discussion No. 1

This is a brief summary of a discussion Sag and I had about the rough outline of the project.

What could be the possible features of the software?
* User should get a fully configured system to suit all needs without any searching/compiling/installing/etc.
* User should be able to easily locate and install more features on demand almost automatically.

How can we go about doing it?
* Finding out the basic config of FC2/3/4.
* Finding what all packages will be required.
* Writing/editing required scripts automatically.

One more thing or feature required is.."finding the current config and installing a new capability"

When a person installs FCX, he install some of the packages in the complete setup of FCX. Then he updates, installs, removes packages from the system. This config which is thus generated is the input to our software.

* We need to get this input.
* We need to ask the user what new thing he wants.
* We need to figure out what packages will be required.
* Is it even possible to get the new thing or is it practically unlikely?
* Where will we get the packages from?
* How to guarantee that we get the latest versions?
* We need to configure some of the scripts to set up a working environment for the software.
* We need to provide a link in the software to access that new "capability"

RPM, YUM, APT are a few software which have some of the capabilities listed above. We can use these softwares/APIs to
* calculate dependencies
* fetch the required packages
* install them

For Average Joe, the domain of thinking is like...
[MP3 player] [Video player] [Browser] [Messenger]

and for us it is...
[xmms] [configure aRts to run on startup] [xmms-mp3] [xmms-arts]
[if aRts is not running, tell xmms to use alsa] [install a good xmms skin]

So, the Average Joe domain will be called "capabilities" and to "enable" a capability, we need to perform tasks of..
* installing packages
* configuring the general scripts
* run time checking (like aRts running or not?)

Run time checking is a feature we are capable of providing because we said, our software is also an "application launcher", so all the softwares average joe requires, he can run by clicking on an icon in our software, and so we can run some scripts prior to loading the specified application.

For Average Joe, the software will be..
* Installed on the system.
* Like a control panel.
* Everything that Joe ever wanted.

He doesn't understand many alternatives available and when we ask...
"You wanna use Firefox or Konqueror or Mozilla?", he says, Linux sucks, lets switch to Windows.
So, another feature would be
* Enforcing some standard. (Now if Average Joe says "Browser", then "firefox" is what we understand, none other)

How will the software be framed for providing necessary functionality for the above mentioned task?
It will definitely be in a CDROM. Now, we need to know that the world is changing fast. So, to provide Average Joe the capability to move with the world, the software must not be hardcoded and should change according to need.

For this, the software will have three parts(as of now, as in what we discussed yesterday night).

* Software.
* Capabilities Database.
* Sources Database.

Software is nothing but code, hehe.

Capabilities Database will be a database mapping capabilities like [Playing MP3] to [all tasks of installing the correct software and running/editing/creating suitable scripts]. The CDROM will provide a database for some of the basic capabilities required in general. The database could be extended or changed by downloading more information from a internet server or another CDROM or disk. Thus, this will be very dynamic and configurable.

You will argue, why do we need it?
I think, AJ wants Browser, MP3, Video and Messenger. He got a new cam! He wants to capture videos! I didn't expect that. So, he can connect to a server "dedicated to providing capability info" (just like YUM repos) and try to look for a tuple related to information about "Video Capturing". Thus, enhancing the usage of the software altogether.

This would require on the part of the "enligtened people" to contribute in making such repositories of "capabilities", and also make sure that "only the best" software for that job is listed to be installed, because as we said, AJ doesn't like options.

The third part, which is somewhat similar to YUM is "Sources Database". This will essentially contain information about what all packages can be fetched from which places, etc. The CDROM could contain information about which package in the FCX setup lies in which CDROM of FCX. Also, it could contain a small database about the packages which are in the CDROM we provide to enable some minimal requirements.

Most of the time, the sources database will not strictly require downloading a package from the FCX setup CDROM. Our software could as well download it from the internet mirrors of Redhat. Similarly, softwares not in the basic setup could be downloaded from YUM repositories and other places.

Thus, a major part will also include "updating the Databases" through the internet or will additional CDROMs which we release.

Also, when the software is installed initially, it should automatically install and configure some of the things to bring it to some prescribed configuration. A lot of times our software needs to go for alternatives, like, I don't have KDE, so even if our software knows "best MP3 player is Amarok", because its not possible to install it, we select the "second best" as XMMS. Thus, the capabilities database should somehow contain a priority order of all the possible alternatives to a "capability".

For eg. I look for MP3 Player, the software shows, Amarok (a maybe a screenshot), XMMS, Rhythmbox, etc. along with the "goodness" and the cost "amount of data in MBs to be downloaded, etc". Then Average Joe can choose, or our software can autochoose based on some AI. We can keep this option in the preferences as to "auto Choose" or "allow the user to choose".

There can be modifications and a lot more people need to pour in.
http://www.linuxquestions.org/questions/showthread.php?s=&threadid=349723 is a link to the forum where you can post your comments and views and ideas. We can also work as a team in the development process.

Wednesday, August 03, 2005

Understanding YUM

* How does YUM do it?
* Why is it so fast?
* What is the header?
* How to use it in my software?
* etc etc.

These are some of the questions that are coming to our minds in the process of making this new piece of software. The beauty of open source is that I can download the sourcecode of YUM, and read it to get what is it doing. Also, I can read their site to find out things. And then, I can use it in my code to make it run better.

YUM mentions that the header is actually a small part of the RPM itself, so that the information about the particular RPM is given by itself, which removes a lot of complexity. Now, there is no specification about what this header actually is or how does YUM use this header to actually find out information about the RPM. It also mentions that YUM directly uses "RPM's dependency resolution" to resolve dependencies, and doesn't implement its own.


Rough Draft No. 1

I am a Fedora Core user since long now. I am beginning a project out of my own interest in order to enhance or customize Fedora Core(2/3/4) to make it usable for an average user.

The idea is to provide an addition 5th CDROM with the FC Setup, which will install a software into the system (similar to YasT), which will enable to user to configure and enhance the user experience for Fedora Core 2/3/4 systems.

One of the many uses of this software would be "Getting software". Now, "getting software" should not be confused with just "installing" RPMS or sources. Here, we are dealing with a different level.

Average Joe says "I want to play MP3".
I would say,
* install XMMS, XMMS-arts, XMMS-mp3, XMMS-skins.
* Configure KDE to start ARTS
* Configure XMMS to use ARTS
* Configure XMMS to use a good theme
* Provide a link to "MP3 Player" in my software. (YES, the software will behave as a app launcher too)

So, the "CAPABILITY" of "playing MP3" is provided by the set of operations given above. So, the software will basically function using a database that is built based on "CAPABILITY" rather than "PACKAGE NAMES".

Most of the time, "enabling a particular capability" will include
* installing packages/sources
* configuring some scripts of KDE/GNOME/etc.
* giving a link to the capability in the software.

We are just beginning the project, and are just analysing the problem. We would like to know if the idea is good enough or needs any amendment?

To install packages, we need to
* resolve dependencies
* identify sources of packages and dependencies (CDROM/ISO/INTERNET)
A lot of this capability seems to be built in the RPMLIB and YUM. We are trying to figure out how to use YUM or YUM API or YUM REPOSITORIES or ALL to benifit our cause. Please help us for the same.

anurag_rana [AT] students [DOT] iiit [DOT] ac [DOT] in