Slashdot Mirror
Introduction to Debian
[vmlinuz] writes "SitePoint has an article that I wrote that introduces Debian and has guidelines on installing it. This could be usefull for managers, new users and other people that may be interested in using Debian." And honestly, who among us isn't interested in using the obviously superior Linux Distribution against which there can be no other contenders? (Oh dear god don't flame me! It's a joke people!)
I'd like to be able to pin the newest KDE/gnome/whatever to stable and do an apt-get upgrade without breaking a million things.
You can pin the newest KDE/gnome/whatever to unstable. Newest always goes in unstable first. Unstable is pretty cutting edge, but with an occasional hiccup.
The point of stable is that it works. Things go there after they are 'tried and true' in unstable, and then in testing.
People keep saying that debian evolves far too slowly. These people, obviously, have not tried unstable. About a dozen new packages get added every week (check the bottom of each Debian Weekly News for a list), and lots more get updates.
To summarize: debian/rules.
Hey, don't forget Knoppix.
To list installed packages, there are some tools that will do that for you... I would just do this: /var/db/pkg/ | grep ':'
ls -R
And for the kernel compile, it really *is* a walk in the pack... but don't forget there are new emerging technologies that make installing KDE, X and mozilla a walk in the pack too...
For example, DistCC is a cross-compiler that allows you to distribute your compiling over multiple boxes... those boxes can be running any distro that has the same compiler and libc running on it...
We (at work) use the old boxes on our network as a compile farm and it works darn well...
we have 2 Athlon XP-2400 w/1Gb of ram for the workstations and 3 older machines that help out with compiling... We can get all these packages installed in a few hours...
Another utility is CCache... it's basically a caching utility that caches your compiles on-the-fly so if you emerge a large package again,
your computer will only have to compile the parts of the source that have changes...
this saves hours when upgrading packages...
But, for those of you who want the bleeding edge without risking instability, Debian does just fine there if you know what you're doing. Go ahead and jump to unstable. Seriously!
The only thing you're missing is "apt-listbugs," which does this automatically with every update...
Before starting installation, apt-listbugs fetches all the bug reports for versions between your current version and the target version. We can see that two bugs have been closed (fixed by later versions, or the bug reports were bogus), and we see that the tetex-bin bug is still open.
In this case, we'd type 'h tetex-bin' to hold the broken package and proceed with a perfectly usable system.
Of course, this still leaves you in the position to be the one in ten thousand who finds a critical bug on installing any given package. If that happens, be a Good Debizen and use reportbug so the next guy is notified. Further, if you flag a critical bug, it's rare that it isn't fixed within a couple hours, even at 2am on Sunday. Once you've reported your bug, go ahead and roll back a version and carry on until the developer closes the bug -- if you used reportbug, you'll get an all-clear email automatically when he or she closes the bug.
With unstable and the apt-listbugs' automatic reports, the chances of ever winding up with a broken system are exceptionally low. Showstopper bugs are rare even in unstable -- maybe one package update in five thousand. But, with thousands of other users snarfing packages and reporting any bugs, the chances of your being the one to discover breakage without apt-listbugs warning you first are virtually nil.
All that said, if you can bear to be a week to a month behind the bleeding edge, you can use apt-listbugs with testing as well. The chances of getting a broken system with testing and apt-listbugs are about the same as the chance of Windows Service Update not needing a reboot. Virtually nil.
I use Debian and I really like it. A very welcome departure from the nightmare RedHat has become.
Yet, I agree with you. The installer is a pain in the arse. Bear in mind however that I only installed Debian once. All the other installations were "cloned" from the original one.
In any case, I'd love to see Knoppix HW detection routines incorporated into Debian. Knoppix is a killer in this area.
Heh, I've justing finished writing an article about the problems with APT (What's wrong with APT?).
Try Debian Help or Debian Community or even one of the mailing lists. And, of course, you can usually get instant answers by asking on irc.debian.org.
There is plenty of good community support available for Debian. The only time I've ever seen anyone suggest "RTFM" is when someone posts nonsence questions to the developers mailing lists without bothering to check the various developers manuals. I don't think it's unreasonable to expect DEVELOPERS to RTFM. Users are a whole different subject.
The GUI installer is on its way, and will probably be in the next stable (released, at its earliest, near the end of 2003). Here is a relevant post from a Debian mailinglist.
since I was not familiar with the Debian way of building packages
I assume you are familiar with it now, but for others, the process is (as yourself, no need to be root):
The result is a .deb which you can install with dpkg -i. If you needed to patch the sources, you'd have to do it between the apt-get and building the package, obviously. dpkg-buildpackage may complain about missing -dev package prerequisites; if so, just apt-get install them. You can omit the "-uc -us" if you have a gpg keypair; dpkg-buildpackage will invoke gpg to sign the created packages (and prompt for your passphrase).
For example, if a new OpenSSH security flaw is discovered and a security update will be available at security.debian.org, I have no clue how the version number conflict is solved.
You can use dselect or aptitude to "hold" the package you built. This will prevent apt-get from upgrading that package even when new versions are available. When a new version is available and you apt-get upgrade, apt will tell you that it's not upgrading that package, so you know to deal with the issue.
I would also recommend one other optional step before building the package: Modify the changelog to change the version number and to indicate what you changed (patch applied, etc.). Just edit <packagename>/debian/changelog and add another entry at the top that looks just like all the others in the file (but with your name, appropriate content, etc.). Change the version number to include your name or something and a number. For example, if the package is 3.6.1, I might make it 3.6.1-shawn.1. That way you can see which packages you've modified. When an update comes along that has a "greater" version number, according to normal lexical ordering rules, apt-get will replace your modified package unless it's held.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Plenty of other otherwise excellent OSes have difficult or non-user-friendly installations. FreeBSD is a good example. But it gets the job done, it isn't really that hard if you RTFM, and once you are finished you have a far superior OS to Mandrake (in my opinion).
No, Debian isn't going to be on the desktop of Windows users anytime soon. That's a position most likely to be filled by RedHat or Mandrake. But not just because of the installation; desktop users want features and bleeding-edge more than code maturity or stability. Debian doesn't even have KDE3 in the stable tree yet. So while a nicer installation may be nice, the kind of users Debian targets don't really need it.