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!)
KDE was broken in unstable for a long time, due to the G++ upgrade, but it works fine now, and is updated quite frequently. Since unstable is really quite stable, there's no reason not to use it.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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.
The only good things about debian is: stability, and apt-get
The price to pay with stability is that you get to use very old applications. If you use unstable, then it breaks.
Apt-get has been copied off by every distro now. So if you are using linux in a desktop, skip debian (great for servers though)
Open Source Java Web Forum with LDAP authentication
Uh, get the 10MB bootflooppies netinst cd. Install woody.
/etc/apt/sources.list
$EDITOR
Replace all instances of 'stable' with 'testing'
apt-get update
apt-get upgrade
Congradulations, you're running testing.
TODO: Something witty here...
Specifically, unstable can be successfully implemented in a production environment IF you pull you're own copy of it to a local mirror periodically, and then verify on a non-critical machine that updating does not foobar things. Installing straight from unstable to a real machine can cause headaches.
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.
Exactly. If you want the newest stuff you'll need to be running unstable/testing, if you want to make absolutely certain you don't have any problems then run stable. I run unstable and the only problem I ever had was whatever that recent problem with SSH was where it would disconnect randomly every now and then. That was annoying, but really not a big deal. I don't have X on that box though so maybe there are some other problems other people have run into with graphical stuff. So basically, in my experience Debian unstable is, well, actually pretty stable.
And perhaps more important (to Debian anyway) is that the one installer runs on pretty much all systems - 11 architectures, and some pretty small systems that the newer, more "advanced" hieroglyphic installers fail on.
Debian has different priorities than Redhat etc. If Debian chose to implement an installer for just i586+ boxes they could make a lot of assumptions about hardware that cannot be made in the more general installer. Knoppix and the other Debian-based distros *do* make these assumptions in their installers, if that's what you want. Want it in Debian? PGI has been uploaded, or you could pay someone to do what you want.
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.
Whatever happened to the Progeny GUI installer? Is it still in the Debian unstable tree?
Because the 'main branch' is 3.0 aka woody aka 'stable' and debian does not introduce stuff like Hardware Detection in Point Releases ala 3.0r2.
Be assured that there will be automatic Hardware Detection in the next stable release (whenever that will be). It has been in the new, still alpha, Installer for months now I think.
Michael
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.
I have to agree with this, mostly. I just installed Debian a few nights ago for the first time - and really, it just wasn't that bad. As a matter of fact, the installation went more smoothly than others I've put on my Mac Powerbook G3. The only slight problems I had were related to the fact that I didn't RTFM at all. I think that even if a somewhat new user read the manuals carefully, in detail, the install would be fine and interesting. So far things are working quite well - my wife got X working in about 10 minutes and had a wireless card going in about an hour.
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.
Morphix is a modular variant of Knoppix. The FAQ explains the differences between Morphix and Knoppix. Simply put, Morphix is much more flexible than Knoppix.
I did an HD-install of the KDE (3.1.1) main-mod. The only problem I had was the with boot configuration (I have an unusual setup), the problem was solved by downloading the boot-disk image that contains the ever-useful Smart Boot Manager (I wish that more distros would, at least, include this as an option).
Minor problem asside, the install went smoothly, it was much, much easier than installing Debian from DVD. You also get much more recent versions of the desktop packages.
Debian, Knoppix, and Morphix are all excellent projects.
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.
I have several computers running, and I don't even remember when I did the "original" install. To put it on a new machine each time I restore a tarfile backup of some other machine, then tailor what needs tailoring. Works for me.
There is an easy way to install Debian: Knoppix. For one thing, it gives you a chance to work with a Linux environment BEFORE committing to an install. While it IS true that you will need to tweak a hard drive install once completed, the tweaks are being done from WITHIN Linux, either from the HD install or from the CD-booted environment. You can then go to http://www.Knoppix.net for details as to massaging the install as you see fit. -- Michael Rudas
yes, that's right. the point of a computer is to configure and recompile your kernel, not to actually use software on it. burn the naysayers!!!
You should never, except in very rare cases, have to recompile your own kernel to get hardware working on Debian. The "stock" Debian kernel comes with zillions of modules for everything under the sun, and there are a few *-modules packages containing extras. There are plenty of reasons to recompile a kernel, but getting your network card working isn't one of them.
The biggest problem is finding out what the hell module to install. It's not exactly as simple as seeing "I have X network card, so I'll install the X module." Many network cards are based on other companies' chipsets, and you have to load the right driver for your chipset. So your card with some random brand name on it might internally be based on the Tulip chipset, in which case you need to load the 'tulip' module. This information isn't often very easy to find, especially if you're someone who doesn't even know that network cards are generally based on a few generic chipsets that get licensed and rebranded (which the majority of computer users don't know).
It's even more fun when you try to tell people it should've been intuitive that they need to load the 'emu10k1' module to get their Soundblaster Live! working.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10