FOSSwire

Fedora, like many distributions, has a requirement that all the software in its repositories conform to a what is free software and open source.

Fedora as it currently stands has guidelines which only accept Free or open source software. The differences in licenses between what FSF considers Free software the OSI approved list of open source licenses are very limited currently to the reciprocal license (which is not a license under which we ship any Fedora software, and the OSI is reconsidering it anyway), few other licenses and we would gain better credibility, community support by changing our packaging guidelines to only allow Free software as defined by the FSF. We would gain by explicitly declaring what we already follow in our strong commitment to Free software.

Sometimes, you might want to install some software that doesn't quite meet these requirements, however, such as a proprietary driver or some software that has a different licence type.

On Fedora 7, there are several repositories for additional software you can enable for this purpose. Probably the most popular is Livna. Once you enable the Livna repository, installing the software you might want should be a simple yum install away.

So how do you get the repository up and running?

The installation process involves downloading a single RPM package from the Livna and installing it. It is sort of a 'metapackage', in the sense that installing it will grab all the stuff you need and configure your yum installation to use Livna's software repositories.

Download the metapackage from http://rpm.livna.org/livna-release-7.rpm and once the download is complete, simply double-click the file.

After confirming your root password, it should install. Now you are ready to go to your package manager and install all that additional software!

One feature of the free software/open source development model that is largely unique and differs from the proprietary model is sheer diversity.

For any one particular task, there might be several different implementations. Looking for a graphical email client? You've got Kmail, Evolution, Thunderbird; the list could go on. These programs might all bascially do the same thing, yet you've got three different projects with three different sets of developers, three different channels of distribution and so on.

One of the benefits of this, of course, is that you get a certain amount of 'survival of the fittest' within the FOSS world. Two different approaches to solve a problem can be developed in parallel and the strongest solution may win out and go on to become a fully-fledged software solution.

The second benefit is choice for the end user. Not everyone will want a particular bit of software to work in a particular way. When you have multiple solutions for a problem, the user gets to choose the one that works best for them. Variety and choice is most definitely a good thing in this case.

You could also argue that more diversity means more secure solutions as well.

A significant disadvantage of this diversity and fracturing, however, is duplicated work. Two developers working again in parallel on a single solution will end up implementing the same things twice between them. "Don't reinvent the wheel" programmers are told - but that's exactly what they will be doing.

Add in another complication - forking. Forking, for the uninitiated, is when a project splits into two (or more theoretically). The source code from the original is taken and becomes a new project.

In the case of a fork, it is often that the changes from a forked version will not end up propagating back to the original. Licence differences between the two projects can even legally prevent this, so again we get stuck with a high potential for duplicated work.

Also from a commercial viewpoint - having lots of choice and lots of diversity can make it more difficult to pick a solution, as you won't necessarily be able to guarantee the one you pick will remain in development and will 'win' over any competing solutions.

So what can we do to try and make the best of the diversity of FOSS, while minimising the likelihood of and impact of duplicated effort?

Getting developers to talk to each other is certainly a start. Where collaboration is possible, they can work together on common code.

This sort of collaboration is much easier to achieve when you're working with software libraries and frameworks - i.e. code that is mostly on the backend and is shared between applications. A good example of this working well is some of the coordination that Freedesktop does to achieve common standards between desktop environments like GNOME and KDE (although even that is far from perfect).

I think it's more about striking a balance between working together and letting things be done separately. Ultimately, there is no 'solution'. The FOSS model is a double-edged sword with both good and bad points - with unique advantages but also unique challenges.

There's only really one universally interchangeable archiving and compression format that works across all major platforms, and that's the Zip format. Like it or not, that's what you are stuck with using if you need to exchange files with other operating systems.

Creating a Zip archive using a GUI is usually a very simple process which involves right-clicking a group of files or a folder and choosing the relevant option.

From a command line, it's a little more complex, but it's still very achievable and it is always useful to know how to do it from the command line.

Unzipping is easy, simply get yourself a suitable Zip file, and do the following:

$ unzip archive.zip

You will see some messages about deflating the files and then you should end up with the archive decompressed to your current working directory.

Compressing is slightly more complex and works something like this:

$ zip -b . stuff *

Let's take a look at the anatomy of that command in more detail. First of all, you run zip. Pretty simple, right?

The -b . switch indicates the directory in which you want the Zip archive file to be created. In this example, I've said . (i.e. the current working directory), but you can specify any directory which will be where your .zip file ends up.

stuff in this example is the name of the archive. Your filename will be this, with .zip added to the end.

Finally, * indicates that I want to zip all the files that are in this directory. That is probably the easiest way to work as you can just set up a directory containing your files, cd to it and use the * wildcard.

Of course, it is possible to be more advanced, so if you want to take your command line zip-fu a little further, then go ahead and read the man page.

Just remember - Zip files don't support Unix permissions, ownership or anything special like that. If you need to preserve that sort of information, you'll need to use tar instead!