此人正在写For IIS的SVN WebDAV模块，基于ASP.NET等等一系列东西。正是我所需要的。

Adobe已经发表声明，通过38亿美元的代价兼并了Macromedia.

巨人越来越高大了。Macromedia被兼并意味永远也不会有Dreamweaver for Linux了，也不知道这是好事还是坏事。

Adobe的声明

Slashdot的相关评论

连载文章，介绍了Open Source的起源与发展，目前出到第三章。

http://www.groklaw.net/article.php?story=20050327184603969

不知道这个叫价是不是会每18个月翻一倍
lol

Gordon Moore's famous prediction, labeled Moore's Law, was originally published in the April 19, 1965 issued of Electronics. Sometime since, he lent out his copy and it has never been returned. Intel would like an original copy of the now defunct magazine and is offering ,000 for a copy, presumably in good condition. The story is carried on Reuters, and if you happen to have a copy (of your own, not stolen from a museum or library) you may contact Intel via eBay's WantItNow.

Linux社区的确有不好的习惯，习惯于鄙视新手。昨天我就不耐烦的对一个问问题的新手说，google去。
我不知道这样做对或者不对，但我知道他被我吓回去了。

Within the computer world; "operators," gosh remember that term, have been broken down into sub categories. Networking technicians/designers/administrators, computer technicians/designers, and of course end users. So what is the real difference between say a networking technician and an end user. The obvious difference is the knowledge base. The networking tech who could have worked on a backbone internet company using OSPF, RIP, EIGRP, BGP, etc... while the end user mainly knows how to double click the 'Internet Explorer' icon.

Let's say the end user is a neurosurgeon; now obviously the end user would be able to perform a lobotomy while the networking tech knows mainly how to use his/her brain. So now that we have established that every person has their own thing they are good at, let's look deeper into the computer realm. There have become two distinct groups of people, although there are more these are the two largest groups of users, Windows and *nix users. Going back to the previous expression where each group was almost completely separated by their jobs. Now when you look at Windows users, a very small percentage of Windows users could use GNOME as well as Window. However, almost every Linux user can use Windows if thrown into the environment which makes them more flexible and smarter than the average Windows user, but only in that field.

Suppose all Windows users became *nix users, the entire community that we have grown to know and love would crash. We would all become clicks and hate the "new Linux user," it's happening now. Not many people are actually willing to help the new Linux user learn what he/she already knows. And that is against everything the Linux community has tried to stand for in the past. And if the community continues to disrespect Windows users for not switching to or using Linux, then that community which has been built to stop the corporate Microsoft in an effort to keep KNOWLEDGE and software accessible and free to everyone has become one giant hypocrisy. How can you be so hypocritical of people? So the neurosurgeon likes his Internet Explorer or his Outlook Express, that is his choice as was his choice to become a neurosurgeon. The next time you want to make fun of someone for running Windows think about this, "is it killing, hurting, or even disturbing my life that he wants to run Windows?" As I stated in the original example, not everyone has the same job, so why does everyone need to run the same operating system?

http://www.onlamp.com/pub/a/onlamp/2005/03/31/packaging.html
linux平台上软件开发人员必读。

Making Packager-Friendly Software
by Julio M. Merino Vidal
03/31/2005

A package maintainer, or packager, is a person who creates packages for software projects. He eventually finds common problems in these projects, resulting in a complex packaging process and a final package that is a nightmare to maintain. These little flaws exist because in most cases the original developers are not packagers, so they are not aware of them. In other words, if you do not know something is wrong, you cannot fix it.

This article describes some of these common problems and possible solutions. Consequently, it is of most value to software developers who make their creations publicly available. Keep in mind that any published project will eventually catch a packager's attention; the easier it is to create the package, the sooner someone can package it.

This document can also help package maintainers to show them some problems they may not be aware of. Remember that a task of a good packager is to send bug reports--with appropriate fixes, if possible--to the mainstream developers about any problems that are found. That way, future versions of the program will be easier to maintain. Note that by doing this, they will help not only themselves, but also all other packagers who handle the same piece of software in other operating systems or platforms.

In case you're wondering whether I know what I'm talking about, let me present myself. I have worked for The NetBSD Packages Collection (pkgsrc) since November 2002. During that time, I have done more than 1,600 package updates and created around 200 packages, most of which are related to GNOME; I am the main maintainer of its packages. While doing this, I have repeatedly encountered and fixed the problems described in this article, so I would like to solve them at their root (by the original software developers). I hope this gives you a bit of confidence.

Related Reading
Managing Projects with GNU make, 3rd Edition

Managing Projects with GNU make, 3rd Edition
By Robert Mecklenburg
Table of Contents
Index
Sample Chapter

Read Online--Safari Search this book on Safari:


Code Fragments only

When presenting solutions for the problems described, I have focused on the most popular build infrastructure in the free software world: GNU Autoconf, GNU Automake, and GNU Libtool. However, the ideas outlined here apply to any build infrastructure you can think of.

I would like to thank Ben Collver, Thomas Klausner, and Todd Vierling, all of them pkgsrc developers, due to their suggestions; and in general all other developers of this system for continuously improving its quality.
Terminology

It's a good idea to be familiar with the following basic terms, which will be used in this article:

   *

     Distribution file (distfile, for short)--A file that contains the pristine sources of a program, as published by the original authors. They usually come in the form of a tarball, such as tar.gz or tar.bz2.
   *

     Packaging system--The infrastructure used to build and/or install packages in a system in their preferred form. This includes the utilities used to generate binary packages (see below) and to handle them on a running system.
   *

     Source package--The set of files used to build a binary package from a distribution file. This concept is very clear in, for example, NetBSD's pkgsrc, FreeBSD's ports, or Gentoo's Portage, because it refers to a single directory in the centralized tree holding all packages.

     However, this term also applies to other packaging systems that always use binary packages. For example, when talking about Debian packages, it refers to the debian subdirectory included in some distribution files. When talking about RPMs, this alludes to the Source RPM files (SRPMs).
   *

     Binary package--A file that provides a program in a ready-to-install manner, usually including prebuilt binaries and possibly providing some scripts to finish its configuration. This is the most common form of packages in Linux distributions, as .deb and .rpm files are exactly this.
   *

     Package (n.)--Used to refer to a binary package and a source package indistinctly.
   *

     Package (v.)--To create a source package from scratch, based on a published distribution file.
   *

     Broken package--A package that, due to an unexpected reason, fails to work properly. This can be either because its build fails, because it does not install some expected files, because it cannot be fetched, and so on.
   *

     Packager--The person who creates a package.

The Distribution File

The first problems in packaging come from the way that project maintainers create or handle the distfiles. These issues are uncommon, but once you start maintaining an affected package, you are likely to suffer its problems forever (unless you persuade the author to fix them). Here's how you can avert trouble:

   *

     Avoid modifying published distfiles. Once you have made a distfile available, never modify it. Even if it includes a stupid bug, don't touch it; instead, publish a new version.

     Rationale: Many packaging systems store cryptographic digests of the distfiles they use in the source packages. This helps verify that no third party has modified the package since its creation. If you change a distfile, you will break the package because the digest test will fail. The maintainer has to check why the test fails, to ensure that there are no malicious changes--not an easy task.
   *

     Avoid moving published distfiles. Once you have published a distfile and distributed its URL, don't remove it from the server or move it around. If you must do it, it would be nice if you contacted all known package maintainers to let them know this issue.

     Rationale: Many source packages download distfiles from their original sites; if the file is moved or removed, the fetch process will fail and the package will be broken. This isn't difficult to fix, but it opens a time window during which people cannot download the package.
   *

     Always use versioned distfiles. The distfile's name must always include a version string identifying it, whether a version number or a timestamp. If you want a static name that refers to the latest version, use a symbolic link on your sever pointing to the full name.

     Rationale: This is very similar to the modification of published distfiles described above. If you replace a distfile with one containing a new version, you implicitly break the cryptographic digests stored in source packages.
   *

     Do not include prebuilt files in your distfile. Be sure that your distfile does not contain prebuilt files that are OS- or architecture-specific. For example, it is erroneous to include a prebuilt object file, but correct to include a Lex-generated C source file.

     Rationale: When building on operating systems and/or architectures different from yours, those files will not be built again because the rebuild rules will not fire. They will cause strange errors later, as their format will be incorrect.

Documentation Files

Several build tools force developers to include documentation files in their distfiles. For example, GNU Automake checks for the existence of README, NEWS, COPYING, and other files, although it does not check the contents. Unfortunately, many developers create those files to shut up errors but forget to fill them in. Although it's hard to believe, I have found several distfiles without any kind of information, many of which are GNOME core libraries.

Why are these files important? They provide very valuable information to the packager. At the very least, he needs:

   *

     Description of the program: Two or three paragraphs are enough. Ideally, this goes at the very beginning of the README file.

     Rationale: Source packages usually provide a file with the description of the package. If the packager has to write it without any reference, he may write something inaccurate or forget to say something important.
   *

     License: Make clear the license terms under which you have distributed your work. This often manifests itself as a COPYING file in the top-level directory of the source tree, containing a summary of the license that affects all the files in it.

     Rationale: It's important to know which restrictions apply to your work when creating a package. A common example is the Sun Java Virtual Machines: we can create a package for them for personal use, but cannot redistribute it later. Plus the source package cannot download them automatically, so the packager has to tell the user how to do it manually.
   *

     Changes between versions: You should provide a list of major changes between all the versions you have published. Ideally, this goes in the NEWS file as an enumeration. Note that ChangeLogs are conceptually different, as they detail every change in every source file. Those are useful too, but not as much as a digest of changes between versions.

     Rationale: When updating a source package to the latest version, the packager must know which changes happened. Guessing them is very difficult and inaccurate, which will result in updates lacking information (something other packagers dislike). Also keep in mind that this information is very valuable when tracking down bugs in a software project.

     If you are using GNU Automake, you can tweak it to bomb out when doing a make dist if the NEWS file is not up to date. Do this by adding the check-news flag to the call to AM_INIT_AUTOMAKE. You might change your configure.ac file to include the following line:

AM_INIT_AUTOMAKE(1.9 check-news)

Note that keeping all this information in a web page is not as useful as including it in the package. Web pages are by nature volatile, so they may become unavailable after some time, especially if the project is abandoned or moved from the original server.

Additionally, please be careful when writing these files. Lots of projects include incomplete notes and are full of typos and incorrect spacing, which denotes that the author does not care about them. These files are usually the first thing the occasional user of your program will examine; if they look sloppy, he will have a bad impression of your project, even if it is coded perfectly.

Configuration Techniques

Before you can build a program from its sources, you have to tune several details to adapt it to your system. Other times, you have to change some default settings so that it fits your expectations. This process is known as source configuration. Believe me when I say that all software packages have some configurable aspect at this stage and that somebody, somewhere, will need to change it; there are very, very, few exceptions. To understand why this is so important, consider the following scenarios:



   *

     The installation prefix must be changeable. You cannot force a user to install a program in a specific directory. He must be able to choose where the program will end up, because your preferred directory may not meet his administration policies. When discussing packaging systems, consider that the package must follow some layout policies. That is, do not assume that /usr and /usr/local are the only possible locations.
   *

     There must be no hardcoded paths in the sources. This includes paths to data files, configuration files, extra libraries, and devices. All of these are good candidates for configuration.

     Suppose your program is a simple Perl script; you have to offer the user an easy way to tell it where the interpreter is. Using #!/usr/bin/perl won't work on many systems, as people can install Perl in many other places (for example, /usr/pkg/bin/perl on a default NetBSD setup).

     Perhaps you think, But... #!/usr/bin/env perl" will do the trick, won't it? Yes, it will--sometimes. Consider multiple versions of Perl installed on the system: Perl 5.6's binary is /usr/bin/perl, and Perl 5.8's binary is /usr/local/bin/perl. Now assume that you have a program that requires Perl 5.8, but you used the line mentioned before. What happens? The script will pick up the first Perl binary it finds in the PATH, which may not match the version your program expects.

     Remember, relying on the PATH is, generally, bad. This is why in pkgsrc we always replace such lines with a full path to the real Perl binary. Obviously, you can extrapolate this to any other situation affected by absolute filenames.

     Besides, there are also some programs that try to cover all "known" possibilities to locate the file they are looking for by using paths like /usr/local/somewhere, /usr/somewhere, and /opt/package/somewhere. Simply put, you cannot know where the user has his stuff installed, so you need to let him specify where it is. For example, pkgsrc places all its files under /usr/pkg, but this location is configurable: this may lead to a program working on a system using the default settings, but not on another one that has been modified.
   *

     There has to be an easy way to choose optional features. If your program includes optional functionalities--such as a GTK front end--there has to be an easy way for the user to enable or disable them. This can occur automatically, but see Automatic decisions below.

Given these reasons, I hope you see the need for a configuration framework in almost all scenarios. Without it, your program is neither portable nor usable, because it will be very problematic to make it work on any system different from yours.

Assuming that this has convinced you, you now have to choose which configuration framework to use. The most common alternatives are:

   *

     A Makefile with easy-to-change variables. This is an old way to configure software. It consists of a Makefile placed in your source tree with a section where the user can modify some variables to specify paths, system features, and more. This Makefile can either be the same as the top-level one, or one specially designed for configuration.

     This approach works quite well if the amount of customizable features is small and you expect people to install the package manually. Note that many novice users will find this frightening and will probably make mistakes.

     Packaging systems work in an unattended manner, so this framework is difficult to manage. The packager has to patch the configuration Makefile to mark lines to customize; then, the package must run sed(1) over it to replace the previous marks with real values.

     Consider a simple example: if the original Makefile includes a line saying PREFIX=/usr/local, the packager has to change it to PREFIX=@PREFIX@ and then use a regular expression such as s|@PREFIX@|${PREFIX}|g to put the correct value in there. Remember, the installation prefix must be configurable, hence the need for dynamic replacement.

     As you can imagine, these patches easily fall out of sync and must be remade in every update of the package. Using this approach will only discourage packagers to create a package for your program.
   *

     A configuration script. This is a very common way to configure software and works very well if the script is smart enough. A script gathers all the required information, either automatically or through flags given by the user, to create the Makefiles and other files accordingly.

     These scripts often use GNU Autoconf, which is usually a safe choice because it integrates well with several packaging systems. Of course there are several other frameworks that you can use, and if you have enough energy, you can even create your homegrown script. Be very careful if you do this, though, as it may not be as portable and useful as you may think.

     The configuration script can do much more than the previous approach (a static Makefile): it can check whether required dependencies are present, whether specific functionality exists in libraries, and more. This is definitely the best way to go, even if it requires a bit more of extra work on your side. It will not only simplify packaging, but also make your package nicer to the end user.

From now on I will assume that your program includes a configuration script. If it does not, well, read the reasons again. Keep reading, even if you still resist the idea, as the concepts explained below should apply to whichever method you use.
Configuration Script Tips

As explained earlier, a configuration script adapts the source code of a program to build and work properly on the build host. (I will not consider cross-compilation here, but that is often a focus of problems, too.) What kinds of details must a developer care about to make his creations package-friendly?

   *

     The script should be noninteractive. Of course, it may require information from the user, but this should be optional and should come from command-line options or environment variables (see the next point).

     Rationale: Passing options to a script from a packaging system is trivial; append them to the call to the configuration script and everything will be automatic. However, if the script requires interaction, the packaging system must simulate it, which may be "easy" if it is command-line oriented--redirecting stdin from a previously stored file--or almost impossible if using a utility such as dialog(1). Other solutions include hand-patching the script, which is equally problematic.
   *

     Do not hardcode paths or other values in the sources. If you have to put a specific path or value such as a user name or group name in your program, do not hardcode it in the sources. This is a very good candidate to customize from the configuration script, either through automatic detection or through a user-specific flag.

     Rationale: The paths or values you hardcoded may not be acceptable for every system. Remember that not everything is GNU/Linux running on i386.
   *

     Be careful with hardcoded paths in the configuration script. If you are looking for some file in a running system, you might try some common paths. Nevertheless, let the user override these defaults if necessary.

     Suppose you need to locate the xmlcatmgr utility. An incorrect approach could be to search for it in /usr/bin, then try /usr/local/bin, and at last abort the operation if it's not found. This is incorrect because the application may be present in an unexpected path.

     A better solution is to provide the user a way to override the search patch so that he can explicitly tell the configuration script where to look; for example, in ${HOME}/local/bin:/opt/xmlcatmgr/bin. In the case where the user has not specified a path, falling back to your favorite built-in directories is still a valid option.

     The best solution is to let the user explicitly specify which utility to use. In this example, that could be through a XMLCATMGR variable, which includes an absolute path to the binary.
   *

     Do not use the == operator when calling test(1). This is a GNU extension, and it breaks on more conservative systems such as NetBSD.

Automatic Decisions

An automated decision is one taken based on the software available on the system at configuration time, without user intervention. They are very harmful, as they make maintenance harder and often lead to incorrect dependency tracking, which is a very serious problem in a package.

As an example, consider the following scenario: your program comes with an optional GTK front end, and your configuration script provides an --enable-gtk-fe={yes,no} flag to specify whether to build it. The default action, however, is to take an automatic decision based on the presence of GTK in the system; that is, if GTK is available, build and install the GTK front end. (To make this more credible, this is what xchat and other programs do.)

This behavior is acceptable, and often very good, if the user is installing your program by hand. Unfortunately, it makes things (very) difficult in the face of package maintainers, especially when the amount of optional features is large (gst-plugins is one such beast).

When a maintainer creates a package for a software program, he must choose a known set of default build options for it. He does this to create the same--or almost equal--binary packages no matter which machine they are built on. The goal behind this is to keep a fixed dependency tree that is easy to track properly. The common procedure to do this is as follows:

  1.

     Manually analyze the available configure-time options (as given by ./configure --help or as seen in the README file) and the output of the configuration script.
  2.

     Check which features are optional and decide whether to enable them for the actual package.
  3.

     Adapt the source package to use only the chosen dependencies, either by giving extra flags to the configuration script or by patching it manually. Doing the latter is often quite difficult (because configuration scripts are pregenerated and unreadable shell code).

As you can imagine, this task is prone to error: it is easy to miss a required dependency, especially if it is unclear (which unfortunately is the case 90 percent of the time). Think, for example, about the yacc and lex utilities: if the packager forgets to add a dependency on them, the end user will probably have trouble building the package. It's even worse if the package finds an extra library and uses it but does not record this fact anywhere. Any mistake here will surely cause trouble to end users, who may experience build failures, extra files being installed, and so on.

Another problem appears when it is time to update the package. The packager has to repeat the same procedure to verify that the package has introduced no new dependencies. If all of them were off (or on!) by default, this could mitigate the pain, but due to the automatic decisions explained above, this causes a lot of headache.

Consider gst-plugins, which I mentioned earlier. This can build a huge amount of plugins depending on the libraries and codecs available on the system. In pkgsrc, we explicitly disable them all through configuration arguments and select them one by one in individual packages (see its Makefile.common). New versions of gst-plugins often come with new modules, so the set of arguments to pass to the configuration script needs manual adjustment on every update.

Now imagine that the packager misses the --disable-arts argument. The aRts plugin (libgstartsdsink.so) will build on some systems but not others due to the automatic detection. If the packager does not have aRts in his system, he will not add a dependency on aRts because he will not notice it. When another user builds it on his aRts-enabled system, aRts will become a dependency; however, this fact will go unrecorded. aRts has become a hidden dependency of gst-plugins. A further removal of the former will mysteriously break the latter. This kind of situation is a very serious problem that comes up over and over again.

What are some possible solutions to this dilemma?

  1.

     Make the configuration script abort its process when it cannot activate a feature because of missing dependencies. For example, if the default behavior of xchat is to build the GTK front end, abort the configuration process if GTK is not available. (The word default is important here; if the default is to not enable the GTK front end, the script should not care at all about GTK presence.) I know; this solution is too drastic because it makes things difficult to people building by hand (though, if they are building by hand, they should take all the consequences ...).
  2.

     Add an --enable-packager-mode (or similar) flag. Passing this flag to the configuration script should disable all automatic decisions, as explained in the previous solution. However, if the flag is absent, the script should behave as usual, taking automatic decisions.

In my opinion, you should use the second solution, as it does not intrude and is more flexible. Is it too complex? Not really. The following code snippet adds the --enable-packager-mode in your own GNU Autoconf scripts:

AC_ARG_ENABLE([packager-mode],
             AS_HELP_STRING([--enable-packager-mode],
                            [Change configuration behavior
                             to ease packaging]),
             [if test x"${enableval}" = xyes
              then
                  automatic_detection=no
              else
                  automatic_detection=yes
              fi],
             [automatic_detection=yes])

Assuming that you choose this option, consider how this flag could affect the first example of this section (the one to enable or disable an optional GTK front end):

AC_ARG_ENABLE([gtk-fe],
             AS_HELP_STRING([--enable-gtk-fe=auto/yes/no],
                            [Enable the GTK frontend
                            (default=auto or yes)]),
             [enable_gtk_fe=${enableval}],
             [if test x"${automatic_detection}" = xyes
              then
                  enable_gtk_fe=auto
              else
                  enable_gtk_fe=yes
              fi])

build_gtk_fe=no
if test x"${enable_gtk_fe}" = xyes ||
  test x"${enable_gtk_fe}" = xauto
then
   PKG_CHECK_MODULES(GTK,
                     [gtk+-2.0 >= 2.6.0],
                     [build_gtk_fe=yes],
                     [if test x"${enable_gtk_fe}" = xyes
                      then
                          AC_MSG_ERROR([GTK not found, but
                                        the GTK frontend
                                        is explicitly
                                        enabled])
                      else
                          build_gtk_fe=no
                      fi])
fi
AM_CONDITIONAL(BUILD_GTK_FE,
              [test x"${build_gtk_fe}" = xyes])

What's Next

This article has introduced the problems of software packaging and why developers should be aware of them. It discussed multiple problematic issues that can be usually found in the distribution files and in documentation. Finally, it analyzed in detail the need for configuration scripts, techniques to implement them, and multiple problems that arise during their creation.

The next article will focus on the build infrastructure used by third-party packages, as well as some code portability issues. Until then, if you are the maintainer of a specific software project, you have enough time to apply all the tips explained. Time to work!

Julio M. Merino Vidal studies computer science at the FIB faculty in Barcelona, Spain.

http://www.howtoforge.com/apt_for_rpm

Apt-For-RPM-Howto

Version 1.0
Author: Falko Timme <ft [at] falkotimme [dot] com>
Last edited 04/08/2005

In this short tutorial I will show how to install and use Debian's package manager apt on various rpm-based distributions like Fedora, Mandrake (or Mandriva, they changed their name...), RedHat, SUSE, and Yellow Dog Linux. apt for rpm is also known as apt4rpm, or aptrpm.

Why do I want to use apt instead of rpm? The answer is easy: apt cares much better for package dependencies than rpm (apt resolves all dependencies by itself!) and saves me a lot of trouble and time. It lets me install, remove or upgrade packages with just a single command, and I can even update my whole Linux distribution to a new release! To find out more about apt's capabilities, please have a loot at http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html.

Apt has originally been ported from Debian to the rpm-based distribution of Conectiva which uses it now as their package manager in their distribution. You can find more information about it on https://moin.conectiva.com.br/AptRpm. The project that made this port available to other rpm-based distributions is called apt4rpm.

This tutorial is split into two parts: in the first I will demonstrate how to install and use apt based on an example (apt on SUSE 9.2), and in the second part I will give you an overview of the packages to install and the package repositories for each distribution mentioned above.


1 Example: Install Apt On SUSE 9.2

Run

rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-rbos/\
apt-libs-0.5.15cnc6-rb.suse092.6.i586.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-rbos/\
apt-0.5.15cnc6-rb.suse092.6.i586.rpm

To check that the installtion was ok you can execute

rpm -qa | grep -E "^apt-"

It should show the two packages you have just installed.

Now apt is installed on your system. We have to tell apt where our package repositorie(s) is/are from which it will fetch new packages. This is done by editing/etc/apt/sources.list. It should contain the following line:

rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/9.2-i386 base update security

Comment out all other lines in this file. This tells apt to use packages that belong to the base system as well as updates and security updates. Please note that these options differ from distribution to distribution (see the overview).

Run

apt-get update

apt will now fetch a list of all available packages from the repository server.

Now let's say we want to install SpamAssassin but don't know how the package is called. No problem, we can search for available packages:

apt-cache search spamassassin

This is the output:

amavisd-new - High-Performance E-Mail Virus Scanner
perl-spamassassin - the perl modules for using spamassassin within an own perl script
razor-agents - SPAM catalogue inquiry and update tool
spamassassin - SpamAssassin is an extensible email filter which is used to identify spam
sylpheed-claws - An Email client similar to Eudora on Windows

We guessed right, our package is called spamassassin, so let's install it:

apt-get install spamassassin

Let's see what happens:

Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
 perl-Digest-HMAC perl-Net-DNS perl-spamassassin
The following NEW packages will be installed:
 perl-Digest-HMAC perl-Net-DNS perl-spamassassin spamassassin
0 upgraded, 4 newly installed, 0 removed and 52 not upgraded.
Need to get 965kB of archives.
After unpacking 2835kB of additional disk space will be used.
Do you want to continue? [Y/n]

apt discovered that spamassassin needs some extra packages (perl-Digest-HMAC perl-Net-DNS perl-spamassassin) and asks if you want to install them. Answer with Y. Now all needed packages will be installed:

Get:1 ftp://ftp.gwdg.de SuSE/9.2-i386/base perl-Digest-HMAC 1.01-494 [21.3kB]
Get:2 ftp://ftp.gwdg.de SuSE/9.2-i386/base perl-Net-DNS 0.48-2 [215kB]
Get:3 ftp://ftp.gwdg.de SuSE/9.2-i386/base perl-spamassassin 3.0.0-3 [623kB]
Get:4 ftp://ftp.gwdg.de SuSE/9.2-i386/base spamassassin 3.0.0-3 [105kB]
Fetched 965kB in 15s (60.7kB/s)
Checking GPG signatures...
Committing changes...
Preparing...                ########################################### [100%]
  1:perl-Digest-HMAC       ########################################### [ 25%]
  2:perl-Net-DNS           ########################################### [ 50%]
  3:perl-spamassassin      ########################################### [ 75%]
  4:spamassassin           ########################################### [100%]
Updating etc/sysconfig/spamd...
Done.
apt executing: /sbin/SuSEconfig
Starting SuSEconfig, the SuSE Configuration Tool...
...

If you want to remove spamassassin simply run

apt-get remove spamassassin

To upgrade all installed packages on your server to the newest versions available in the repository, you have to execute

apt-get upgrade

(Do not mix this up with apt-get update (see above)! apt-get update is used for updating the list of available packages after /etc/apt/sources.list has been changed.)


2 Overview: Apt For Fedora, Mandrake/Mandriva, SUSE, RedHat And Yellow Dog Linux
Fedora Core 3
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/3/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/3/apt/\
apt-0.5.15cnc6-1.1.fc3.fr.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net fedora/linux/3/i386 core updates freshrpms
rpm http://ayo.freshrpms.net fedora/linux/3/i386 tupdates
rpm-src http://ayo.freshrpms.net fedora/linux/3/i386 core updates freshrpms
rpm-src http://ayo.freshrpms.net fedora/linux/3/i386 tupdates

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
Fedora Core 2
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/2/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/2/apt/\
apt-0.5.15cnc6-1.1.fc2.fr.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net fedora/linux/2/i386 core updates freshrpms
rpm http://ayo.freshrpms.net fedora/linux/2/i386 tupdates
rpm-src http://ayo.freshrpms.net fedora/linux/2/i386 core updates freshrpms
rpm-src http://ayo.freshrpms.net fedora/linux/2/i386 tupdates

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
Fedora Core 1
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/1/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/fedora/linux/1/apt/\
apt-0.5.15cnc6-0.1.fc1.fr.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net fedora/linux/1/i386 core updates freshrpms
rpm http://ayo.freshrpms.net fedora/linux/1/i386 tupdates
rpm-src http://ayo.freshrpms.net fedora/linux/1/i386 core updates freshrpms
rpm-src http://ayo.freshrpms.net fedora/linux/1/i386 tupdates

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
Mandrake 10.1
Apt-rpms: Where? ftp://fr2.rpmfind.net/linux/Mandrake/10.1/i586/media/contrib/
Installation rpm -ivh ftp://fr2.rpmfind.net/linux/Mandrake/10.1/i586/media/contrib/\
libapt-pkg0-0.5.15cnc6-3mdk.i586.rpm
rpm -ivh ftp://fr2.rpmfind.net/linux/Mandrake/10.1/i586/media/contrib/\
apt-0.5.15cnc6-3mdk.i586.rpm
Check Installation rpm -qa | grep -E "^apt-0|^libapt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.lip6.fr/pub/linux/distributions/Mandrakelinux/official/10.1/i586/media/ media_info/hdlist_main main

Further Information
List of mirrors: http://www1.mandrivalinux.com/en/ftp.php3
Mandrake 10.0
Apt-rpms: Where? ftp://194.199.20.114/linux/Mandrake/10.0/contrib/i586/
Installation rpm -ivh ftp://194.199.20.114/linux/Mandrake/10.0/contrib/i586/\
libapt-pkg0-0.5.15cnc5-4mdk.i586.rpm
rpm -ivh ftp://194.199.20.114/linux/Mandrake/10.0/contrib/i586/\
apt-0.5.15cnc5-4mdk.i586.rpm
Check Installation rpm -qa | grep -E "^apt-0|^libapt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.sunet.se/pub/Linux/distributions/mandrakelinux/official/10.0/i586/Mandrake/ base/hdlist RPMS

Further Information
List of mirrors: http://www1.mandrivalinux.com/en/ftp.php3
Mandrake 9.2
Apt-rpms: Where? ftp://194.199.20.114/linux/Mandrake/9.2/contrib/i586/
Installation rpm -ivh ftp://194.199.20.114/linux/Mandrake/9.2/contrib/i586/\
libapt-pkg0-0.5.5cnc6-2mdk.i586.rpm
rpm -ivh ftp://194.199.20.114/linux/Mandrake/9.2/contrib/i586/\
apt-0.5.5cnc6-2mdk.i586.rpm
Check Installation rpm -qa | grep -E "^apt-0|^libapt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.sunet.se/pub/Linux/distributions/mandrakelinux/official/9.2/i586/Mandrake/ base/hdlist RPMS

Further Information
List of mirrors: http://www1.mandrivalinux.com/en/ftp.php3
Mandrake 9.1
Apt-rpms: Where? ftp://194.199.20.114/linux/Mandrake/9.1/contrib/i586/
Installation rpm -ivh ftp://194.199.20.114/linux/Mandrake/9.1/contrib/i586/\
libapt0.5-0.5.5cnc3-1mdk.i586.rpm
rpm -ivh ftp://194.199.20.114/linux/Mandrake/9.1/contrib/i586/\
apt-0.5.5cnc3-1mdk.i586.rpm
Check Installation rpm -qa | grep -E "^apt-0|^libapt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.sunet.se/pub/Linux/distributions/mandrakelinux/official/9.1/i586/Mandrake/ base/hdlist RPMS

Further Information
List of mirrors: http://www1.mandrivalinux.com/en/ftp.php3
RedHat 9
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/9/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/9/apt/\
apt-0.5.5cnc6-fr1.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/9/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/9/i386 os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat 8.0
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/8.0/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/8.0/apt/\
apt-0.5.5cnc6-fr0.rh80.1.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/8.0/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/8.0/i386 os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat 7.3
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/7.3/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/7.3/apt/\
apt-0.5.5cnc5-fr0.rh73.2.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/7.3/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/7.3/i386 os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat 7.2
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/7.2/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/7.2/apt/\
apt-0.3.19cnc55-fr7.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/7.2/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/7.2/i386 os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat 7.0
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/7.0/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/7.0/apt/\
apt-0.5.5cnc6-fr0.rh70.1.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/7.0/i386 os updates freshrpms
rpm http://ayo.freshrpms.net redhat/7.0/i386 powertools dma
rpm-src http://ayo.freshrpms.net redhat/7.0/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/7.0/i386 powertools dma

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat 6.2
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/redhat/6.2/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/redhat/6.2/apt/\
apt-0.5.4cnc7-fr0.62.1.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net redhat/6.2/i386 os updates freshrpms
rpm http://ayo.freshrpms.net redhat/6.2/i386 powertools
rpm-src http://ayo.freshrpms.net redhat/6.2/i386 os updates freshrpms
rpm-src http://ayo.freshrpms.net redhat/6.2/i386 powertools

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
RedHat Enterprise Linux 3 (RHEL 3)
Apt-rpms: Where? ftp://ftp.uninett.no/pub/linux/apt/RHEL/3-i386/RPMS.base/
Installation rpm -ivh ftp://ftp.uninett.no/pub/linux/apt/RHEL/3-i386/RPMS.base/\
apt-0.5.15cnc3-2.RHEL3.i386.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm ftp://ftp.uninett.no/linux/RHEL/apt RHEL/3-i386 base
rpm-src ftp://ftp.uninett.no/linux/RHEL/apt RHEL/3-i386 base

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
SUSE 9.2
Apt-rpms: Where? ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-rbos
Installation rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-rbos/\
apt-libs-0.5.15cnc6-rb.suse092.6.i586.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.2-i386/RPMS.suser-rbos/\
apt-0.5.15cnc6-rb.suse092.6.i586.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/9.2-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 9.1
Apt-rpms: Where? ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.suser-rbos/
Installation rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.suser-rbos/\
apt-libs-0.5.15cnc6-0.suse091.rb.5.i586.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.1-i386/RPMS.suser-rbos/\
apt-0.5.15cnc6-0.suse091.rb.5.i586.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/9.1-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 9.0
Apt-rpms: Where? ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.0-i386/RPMS.suser-rbos/
Installation

rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.0-i386/RPMS.suser-rbos/\
apt-libs-0.5.15cnc7-0.suse090.rb.0.i586.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/9.0-i386/RPMS.suser-rbos/\
apt-0.5.15cnc7-0.suse090.rb.0.i586.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/9.0-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 8.2
Apt-rpms: Where? ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.2-i386/RPMS.suser-rbos/
Installation rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.2-i386/RPMS.suser-rbos/\
apt-libs-0.5.5cnc6-rb3.i386.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.2-i386/RPMS.suser-rbos/\
apt-0.5.5cnc6-rb3.i386.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/8.2-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 8.1
Apt-rpms: Where? ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.1-i386/RPMS.suser-rbos/
Installation rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.1-i386/RPMS.suser-rbos/\
apt-libs-0.5.5cnc6-rb2.i386.rpm
rpm -ivh ftp://ftp.gwdg.de/pub/linux/suse/apt/SuSE/8.1-i386/RPMS.suser-rbos/\
apt-0.5.5cnc6-rb2.i386.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/8.1-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 8.0
Apt-rpms: Where? http://linux01.gwdg.de/apt4rpm/apt-0.5.4/
Installation rpm -ivh http://linux01.gwdg.de/apt4rpm/apt-0.5.4/RPMS.tested/\
apt-0.5.4cnc9-1cl.i386.rpm
rpm -ivh http://linux01.gwdg.de/apt4rpm/apt-0.5.4/RPMS.tested/\
apt-devel-0.5.4cnc9-1cl.i386.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/8.0-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
SUSE 7.3
Apt-rpms: Where? http://linux01.gwdg.de/apt4rpm/apt-0.5.4/
Installation rpm -ivh http://linux01.gwdg.de/apt4rpm/apt-0.5.4/RPMS.tested/\
apt-0.5.4cnc9-1cl.i386.rpm
rpm -ivh http://linux01.gwdg.de/apt4rpm/apt-0.5.4/RPMS.tested/\
apt-devel-0.5.4cnc9-1cl.i386.rpm
Check Installation rpm -qa | grep -E "^apt-"

Content of
/etc/apt/sources.list
rpm ftp://ftp.gwdg.de/pub/linux/suse/apt/ SuSE/7.3-i386 base update security

Further Information
http://linux01.gwdg.de/apt4rpm/
Yellow Dog Linux 4.0
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/yellowdog/4.0/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/yellowdog/4.0/apt/\
apt-0.5.15cnc6-1.0.yd4.fr.ppc.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net yellowdog/4.0/ppc os updates freshrpms
rpm-src http://ayo.freshrpms.net yellowdog/4.0/ppc os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
Yellow Dog Linux 3.0
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/yellowdog/3.0/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/yellowdog/3.0/apt/\
apt-0.5.15cnc5-0.2.fr.ppc.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
rpm http://ayo.freshrpms.net yellowdog/3.0/ppc os updates freshrpms
rpm-src http://ayo.freshrpms.net yellowdog/3.0/ppc os updates freshrpms

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/
Yellow Dog Linux 2.3
Apt-rpms: Where? http://ftp.freshrpms.net/pub/freshrpms/yellowdog/2.3/apt/
Installation rpm -ivh http://ftp.freshrpms.net/pub/freshrpms/yellowdog/2.3/apt/\
apt-0.5.5cnc4.1-fr1.ppc.rpm
Check Installation rpm -qa | grep -E "^apt-0"

Content of
/etc/apt/sources.list
Fix me.

Further Information
http://freshrpms.net/apt/
http://apt.freshrpms.net/

有趣的文章，把Windows, UNIX, Linux, BeOS等等比做不同的车型，颇有道理.


OS Car Analogies

Microsoft Windows Station Wagon
The Model T is the Standard when it comes to automobiles, used by over 90% of the car driving population. It's robust, has widely available parts, is relatively cheap, is econimical to run and is very reliable. It is so widely available, that most new houses built in the last few years all have have a new Model-T ready in the garage (although Microsoft did get into an anticompetitive dispute with the government recently due to this practice). Today the dominant model from Microsoft is the NT - Station Wagon, which has a very nice compromise between performance, passanger space and boot space. Previous models were the DOS, W311 and W95 models.

The only downside to the Model T is that is is manufactured by only 1 company. The engine schematics are not available to the general public. And you can have any colour you want - as long as it's black.

Apple Mac 4WD
Apple brought automatic transmission systems to the masses with their Classic Beetle model, and have over the years relentlessly been the pioneers of including a large number of luxury features in all their models. Apple's vechicles use Diesel fuel instead of Unleaded petrol, which makes fuel slighly more troublesome to get since not all petrol stations stock Diesel. Their latest model (OSX) is a 4 wheel drive model, and Apple have even made the engine design schematics public. Apples cars have won a number of industrial design awards.

The biggest issue with Apple automobiles is that, just like Windows, it is only available from 1 manufacturer. Apple constantly include luxury fittings in all their models, which make them slightly more expensive than bare bones automobiles from other manufacturers.

Unix Trucks
Trucks. Without them, our modern way of life would disappear. They are the work horses of the modern industrialised world. These beasts are build to last, and can transport tons of goods day and night, without rest. They come in all shapes and sizes, depending on the cargo transported. Although perfect for industrial use, they are unsuitable for average motorists.

Linux - Truck assembly kit
Since trucks are so vital to modern society, it would be foolish to have only one truck manufacturing company. A group of individuals got together and decided to design their own truck, one which would be completely customisable and available in all shapes and sizes, for free. The only condition is, if you come up with a better truck design based on the current designs, you must also make your design freely available to everyone else.

Enthusiasts love to tinker with the Truck Assembly Kit, so its not unusual to find trucks with reclining leather seats, sunroofs, climate controls and cup holders. The sheer flexibility scares away people which are not mechanically minded - they just want to turn the ignition on and drive, not to spend hours under the hood adjusting the air-fuel intake ratio. Due to their weight, they take longer to reach cruising speed from a total stop, so you wouldn't want to be behind one at a red light. Once they've reached cruising speed, these vechicles are very efficient, and have quite a bit of power under the bonnet.

BeOS Sports Car
Vrrrrrrroommmm. The sports car for racing enthusiasts, for people who love speed, performance and handling. The station wagon crowd complain about no rear seats for the kids, while the trucking people complained about the lack of cargo space at the back?!?!? Hello!!! It's a bloody sports car!!! Unfortunately, the original owners of the car got distracted during a test drive (due to lack of focus), and ended up slamming the car into a San Francisco cable car. The original owners were thus hospitalised, while the remains of the new prototype car were sold to a german panel beater.

A small community of performance car enthusiasts vowed to recreate their beloved sports car. Even though they still drive station wagons and trucks during the week, late at night and during weekends they can be found in their garages banging away, molding and trying to recreate the Haiku sports car. Apparaently the car is already revvvvvving, and a lot of the componets are already created and are waiting for the car framework to be completed before they can be assembled. These guys expect to start road testing their cars during 2005. Word from Europe is that the panel beaters have not only finished all the repair work, they've also hired engineers to continue working on the design of the sports car.

Amiga Convertible
A car from a long gone era. These beautiful cars promised the convenience of a station wagon, the transportability of a truck with the performance of a sports car, but alas, the owners never knew what a jewel they had locked up in their garage. The car was sold to a german construction company, then to some cattle farmers, then resold numerous times, until disappearing from public view. It's still a popular vechicle in Cuba.

http://os.newsforge.com/article.pl?sid=05/04/11/118211&from=rss

BitKeeper and Linux: The end of the road?
Monday April 11, 2005 (12:00 PM GMT)
By: Joe Barr

 Printer-friendly   Email story  
BitKeeper, the proprietary source management tool used by Linus Torvalds and other Linux kernel hackers to apply patches to their versions of the kernel, is once again at the center of controversy. This time it looks as if the relationship between BitKeeper and the poster-child project for free software is going to come to an end as the result of irreconcilable differences. We spoke with the three primary figures involved in the dispute -- Larry McVoy, Linus Torvalds, and Andrew "Tridge" Tridgell -- to learn what happened and whether it could have been avoided.

Click Here
We asked Larry McVoy, BitKeeper's primary author, to tell us what happened to cause him to end the relationship by giving Torvalds and the Linux kernel developers using BitKeeper three months to move to another tool for their source code management. He explained:

   Back on February 23 I learned from Linus that Tridge was reverse-engineering BK so that he could pull stuff out of BK trees without agreeing to the BK license. As you might expect, we were less than thrilled and began having talks with Linus, Tridge, and Stuart Cohen, the CEO of OSDL. These talks didn't go anywhere. Tridge believes strongly enough in free software that he thinks anyone using non-free software is living in sin.

   Linus worked very hard to get Tridge to stop. He and I spent a significant amount of time on this issue and Linus understands my position very well He summarized it nicely:

       Larry is perfectly fine with somebody writing a free replacement. He's told me so, and I believe him, because I actually do believe that he has a strong moral back-bone.

       What Larry is _not_ fine with, is somebody writing a free replacement by just reverse-engineering what _he_ did.

       Larry has a very clear moral standpoint: "You can compete with me, but you can't do so by riding on my coat-tails. Solve the problems on your own, and compete _honestly_. Don't compete by looking at my solution."

       And that is what the BK license boils down to. It says: "Get off my coat-tails, you free-loader". And I can't really argue against that.

   This position seemed to be lost on Tridge.

   Concurrently we were working with OSDL's management. In this area I pulled in calmer heads than mine and our VP of sales got involved. He negotiates all of our enterprise level agreements, (his strength is finding common ground) so you can imagine he's a pretty reasonable guy. He was unsuccessful in getting anywhere with OSDL's CEO. Stuart's position was that this was not their problem and this is the sort of activity you expect in the open source world. We did get a verbal promise from OSDL that Tridge had discontinued his work and would not begin again as long as we were trying to work things out. We believed we had an uneasy truce, but it ends up Tridge was still working.

   We ended up in a no-win situation. OSDL didn't appear to care and we couldn't trust what we were being told. With that we were fairly confident that Tridge was going to release his code. That was a problem for us for two reasons:

   a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs ,000 plus a custom release to fix it.

   If Tridge's tool is out there we are now supporting our code and his code. We couldn't do that.

   b) IP loss. If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering.

   Internally, we were looking at ways to best handle this. One option was to have two versions of BK, one that we gave away and another that was commercial only. This had been our course for some time and it wasn't working out. The difficulty with that solution is we couldn't just stop all work on the free version because of future compatibility issues. Trying to maintain compatibility between a free product and commercial version was grinding our development to a halt. Everyone was losing. In order for this to work we had to continuing throwing resources at the problem. We're already up to about 0K/year for the free version and continuing to ratchet that up wouldn't be prudent.

   At that point we started looking at what it would be like to discontinue the free BK. Linus strongly encouraged us to do this once he came to the conclusion that the costs of the free version to BitMover outweighed the benefits to BitMover.

   OSDL's management was kept informed of what we were thinking and again they seemed rather apathetic about it. Their position was that it was BitMover's problem and we needed to figure out how to fix it. That is until we set the wheels in motion to discontinue the free product. They did make motions very recently that we should work together on this, but it was too little too late.

   We finalized our discussions with Linus last weekend and he began the process of migrating off of BK. Linus is a very ethical guy. His feeling was that we were getting a bad deal and he didn't want to be part of that. So off he went. We spent the next couple of days scrambling to figure out how we were going to handle this, announcements, migrations, programs moving forward, etc. We're still working on the details moving forward with some of these issues, but our hope is to make this as smooth as could be expected for this sort of transition.

Torvalds' take on the situation

After reading McVoy's response (he cc:ed Torvalds on the email he sent to us so that he would not misquote or take out of context anything he quoted from their correspondence), we asked Torvalds three questions.

NewsForge: What will you use to replace BitKeeper?

Torvalds: I don't even know yet. I'm playing around with my own scripts and tools right now, and talking to various open-source source code management (SCM) people. In fact, I'm trying to get as many people as are interested in the problem to just explore the options.

NewsForge: How will this impact your workload short or long term?

Torvalds: Short-term we'll merge patches. Right now the -mm tree should work like usual, so people can go on developing. On the other hand, especially people that used BK will just slow down, take a breather, and look around at the alternatives.

And some people will just continue to use BK. It didn't go away, and it's still the best SCM out there, it just got harder to merge with me (and some of the people I work with). So you export BK changes by patches instead, but some people largely worked like that _anyway_ before (i.e. they used BK for its merge capabilities).

So we'll definitely have a slowdown in the short run, but it's not likely to be a huge deal. The biggest worry is developer frustration about the uncertainty, so I'm certainly trying to get to a decision, but on the other hand I don't want to hurry it _too_ much either.

(Ironically, many users and distributions are likely to actually not mind slightly slower development for a while. One of the most common worries for users is just the fact that 2.6.x has continued to be developed at a very high rate thanks to just how smoothly it's been working, so I bet some people are both upset and gratified by this all. ;)

In the long run, we'll just have to see. I think in the _medium_ run the problem is going to be just having to live with less capable tools, and having to possibly teach old developers (me included) new tricks.

And I don't mean the various syntactic differences between different SCMs, I mean new ways of working and adapting to new constraints (and likely new freedoms too -- BK had its own set of constraints simply due to the model of development that _it_ imposed -- every SCM tool to some degree has a "world view," and it takes time to get comfortable with that world view...

NewsForge: Was this split inevitable, or could it have been avoided?

Torvalds: I think everybody saw the split as inevitable _eventually_. I don't think anybody believes that the open-source SCMs wouldn't grow up, and when they would, there would have been obvious reasons to switch over eventually.

But I think it could have been a lot less painful if it happened a year or two down the road, and that's my only real regret. That said, we did get three very productive years out of it, and we not only learnt how SCMs can work, we also taught a lot of people what to expect of a _good_ SCM, so anybody who claims that it was a waste of time to go with BK obviously doesn't have his head screwed on right. BK did good.

Tridge offers his side

There is no doubt Tridge is being cast as the villain in this piece. Here's what he had to tell us when we asked him for his side of the tale:

   I expect that in the future I will be able to give a more detailed response, but for now I can only tell you the following:

   - In late February I wrote a tool that is interoperable with BitKeeper. The aim was to provide export to other source code management tools and provide a useful tool to the community.

   - I did not use BitKeeper at all in writing this tool and thus was never subject to the BitKeeper license. I developed the tool in a completely ethical and legal manner.

At the end

In spite of the end of the relationship, McVoy and Torvalds seem to have lost no respect for each other's integrity or professionalism. Torvalds still admires BitKeeper, and still feels it to be the best tool for the job. Whether this outcome was inevitable or not, it's a little bit sad to see this marriage of proprietary and free software come to an unhappy end. Not to mention a little unsettling, due to the uncertain handling of patches in the future.

http://www.anandtech.com/linux/showdoc.aspx?i=2308&p=1

这篇文章详细比较了p4M和p4, Athlon的性能，非常不错。绝大多数linux发行版不能完全发挥p4 M的性能，因为他们是用-march=i686来编译的。

看来要用-march=pentium-m来emerge -e world了...

Gentoo论坛上找到的，调整ext2/ext3性能的一些方法。

Copyright (c) 2005 Peter Gordon

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2
or any later version published by the Free Software Foundation;
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license can be found here.

Overview
I'm a big fan of the Third Extended ("ext3") filesystem. It's in-kernel and userspace code has been tried, tested, fixed, and improved upon more than almost every other Linux-compatible filesystem. In this article I intend to explain some tips that can improve both the performance and the reliability of the filesystem.

In the document, /dev/hdXY will be used as a generic partition. You should replace this with the actual device node for your partition, such as /dev/hdb1 for the first partition of the primary slave disk or /dev/sda2 for the second partition of your first SCSI or Serial ATA disk.

I: Using The tune2fs and e2fsck Utilities

Before we begin, we need to make sure you are comfortable with using the tune2fs utility to alter the filesystem options of an ext2 or ext3 partition. Please make sure to read the tune2fs man page:
Code:
$ man tune2fs
It's generally a good idea to run a filesystem check using the e2fsck utility after you've completed the alterations you wish to make on your filesystem. This will verify that your filesystem is clean and fix it if needed. You should also read the manual page for the e2fsck utility if you have not yet done so:
Code:
$ man e2fsck

Exclamation WARNING: Make sure any filesystems are unmounted before altering them with the tune2fs or e2fsck utilities! (Boot from a LiveCD if you need to.) Altering or tuning a filesystem while it is mounted can cause severe corruption! You have been warned!

II: Using Directory Indexing

This feature improves file access in large directories or directories containing many files by using hashed binary trees to store the directory information. It's perfectly safe to use, and it provides a fairly substantial improvement in most cases; so it's a good idea to enable it:
Code:
# tune2fs -O dir_index /dev/hdXY

This will only take effect with directories created on that filesystem after tune2fs is run. In order to apply this to currently existing directories, we must run the e2fsck utility to optimize and reindex the directories on the filesystem:
Code:
# e2fsck -D /dev/hdXY

Idea Note: This should work with both ext2 and ext3 filesystems. Depending on the size of your filesystem, this could take a long time. Perhaps you should go get some coffee Wink

III: Enable Full Journaling

By default, ext3 partitions mount with the 'ordered' data mode. In this mode, all data is written to the main filesystem and its metadata is committed to the journal, whose blocks are logically grouped into transactions to decrease disk I/O. This tends to be a good default for most people. However, I've found a method that increases both reliability and performance (in some situations): journaling everything, including the file data itself (known as 'journal' data mode). Normally, one would think that journaling all data would decrease performance, because the data is written to disk twice: once to the journal then later committed to the main filesystem, but this does not seem to be the case. I've enabled it on all nine of my partitions and have only seen a minor performance loss in deleting large files. In fact, doing this can actually improve performance on a filesystem where much reading and writing is to be done simultaneously. See this article written by Daniel Robbins on IBM's website for more information:

http://www-106.ibm.com/developerworks/linux/library/l-fs8.html#4

In fact, putting /usr/portage on its own ext3 partition with journal data mode seems to have decreased the time it takes to run emerge --sync significantly. I've also seen slight improvements in compile time.

There are two different ways to activate journal data mode. The first is by adding data=journal as a mount option in /etc/fstab. If you do it this way and want your root filesystem to also use it, you should also pass rootfsflags=data=journal as a kernel parameter in your bootloader's configuration. In the second method, you will use tune2fs to modify the default mount options in the filesystem's superblock:
Code:
# tune2fs -O has_journal -o journal_data /dev/hdXY
Please note that the second method may not work for older kernels. Especially Linux 2.4.20 and below will likely disregard the default mount options on the superblock. If you're feeling adventurous you may also want to tweak the journal size. (I've left the journal size at the default.) A larger journal may give you better performance (at the cost of more disk space and longer recovery times). Please be sure to read the relevant section of the tune2fs manual before doing so:
Code:
# tune2fs -J size=$SIZE /dev/hdXY

IV: Disable Lengthy Boot-Time Checks

Exclamation WARNING: Only do this on a journalling filesystem such as ext3. This may or may not work on other journalling filesystems such as ReiserFS or XFS, but has not been tested. Doing so may damage or otherwise corrupt other filesystems. You do this AT YOUR OWN RISK.

Hmm..It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journalling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journalled transactions. Therefore, we can safely disable these mount-count- and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. You may do so using the following command:
Code:
# tune2fs -c 0 -i 0 /dev/hdXY


This concludes this filesystem tweaking guide for now. Happy hacking! Very Happy