Advanced Linux Distributions You Should Try

Quoting:What does that do in plain English (Dutch will do as well)?

1) "apt-get build-dep " or "aptitude build-dep "

Install all packages, libraries, headers and tools that you need to build the binary package.

2) "apt-get source " or "aptitude source "

I forgot this one in the list above. This downloads the original source tarball into the current directory, downloads the Debian package and merges it with the original source. It's a 3-step process because Debian does not modify upstream source code. They keep the original tarball and put patches separately into the Debian package.

3) tweak

Show off your l33t coding skillz

4) dch

Short for "Debian Changelog". Update the Changelog in the Debian package. This also increases the version number of the package. You need to do that so that when you install it, Debian sees that your version overrides the standard version (which will have a lower version number).

5) "debuild -i -us -uc -b"

This builds an installable Debian binary package from the sources. Just "debuild -b" like I wrote will also work, but this is better. -i runs an extra check on your package after building it. -us and -uc mean that you do not wish to sign the package contents with your GPG key.

6) "dpkg -i "

Dpkg is the low-level debian package manager. apt, aptitude and synaptic are all built on top of this. -i means install, so this installs your custom package.

And that's it! You have now built and installed your custom Debian package. Currently I have two such custom packages installed. I have patched exuberant-ctags for better PHP5 support (provides PHP highlighting in Vim. Patch here: http://sourceforge.net/tracker/index.php?func=detail&aid=227...) and I have installed an updated Vim 7.2 from experimental, so I could use the latest netrw plugin.

Manually backporting packages from newer debian releases is done much in the same way, only instead of "apt-get source" I simply download the package files from the Debian Experimetal repository manually. Then Debuild takes care of building it on my Etch system. Of course, with backporting you do need to take care of any changed dependencies yourself since "apt-get build-dep" installs the dependencies of the version in your repository, not the newer version you downloaded manually.

PS: That's the hard way of creating a backport yourself. Many packages have already been backported and can simply be installed by adding backports.org to your repository list.

It all depends on the hardware, the user(s), the application(s) and the administrator.

Sometimes having a box that you can apt-get update apt-get upgrade is the best choice.

Others might feel better running Slackware, either with or without slapt-get. If you're happy with all the goodness that comes in a full Slackware install, you like KDE and don't want to add/maintain a lot of packages, it's a very solid choice.

For "normal" people, Ubuntu or even Debian using the GNOME update manager might work better.

Even though I really feel at home in Debian especially, I'm setting up a laptop with OpenBSD 4.4. Even in this situation I have tradeoffs. As secure as OpenBSD is, you don't maintain the -release branch the same way as Debian or even Slackware. Critical patches are publicized and should be applied, but when running -release or patched release (aka -stable), the 4,000+ precompiled packages for i386 and 4,000+ ports for all architectures are NOT generally updated at all for the six months between releases.

So if I decide not to worry about package updates during that six-month interval, I don't have to do almost any updates for six months, at which time the not-so-easy OpenBSD upgrade will await me. Truth be told, I don't know how I feel about that at this very moment.

Most OpenBSD geeks run -current, which is updated continuously but which either must be refreshed with new snapshots or through a whole lot of compiling.

I hate sitting and waiting for things to compile. Like watching paint dry.

I'm having fun with OpenBSD, but there are plenty of other situations in which I'd use Debian, Ubuntu, Slackware (for which I continue to have a great deal of respect and fondness) and now CentOS/Red Hat, which I've recently been running quite successfully.

My lack of love for compiling would probably make Gentoo something I shouldn't even try ...

Quoting:I hate sitting and waiting for things to compile. Like watching paint dry.

Then you should detach screen and go on browsing, go out or go to bed if it's late, just like most people who are compiling do. At least that's what I do. But on the other hand I like watching for hours at gcc output. Just like I liked watching at the blocks of the Win98 defrag-program. But then came XP, and the thousands of blocks on the screen were gone! What a disaster that was, it ruined my life! Glad Gentoo was there.

I also tried to patch some things in Gentoo once (actually I tried to patch a hardened kernel with swsusp-patches) but that didn't work, and after manually patching some files where the two patches (hardened is also a patch) conflicted, I gave up. Adding patches to Gentoo ebuilds is rather easy; as far as I know you need an overlay (to prevent screwing things up) and there in the ebuild you can just add the web-address of the patch, update the digest and that should be it. I've never done so however. I was going to look at an ebuild to see if it's really that simple, but believe it or not, I'm typing this on my two-hours ago installed Debian system now.

So great there's going to be an article on how to patch my Debian packages, but I'm not that far; currently I'm trying to find out if my update to Lenny succeeded or not; but at least KDE4.1 won't install (darn, I almost wrote "compile"). Don't have any clue for now; I'm afraid the dist-upgrade didn't work. So after all, it seems Gentoo isn't advanced, because there's only one version of it so you never have to worry what you're using and you never have to switch between versions.