You are not currently logged in. If you do not have a user account then please consider creating one and logging in before you post your comment. This will allow you to track replies to your comment, and take part in the site much more freely.

To add your comment, fill in all the boxes below and then preview it to make sure you're happy with the way that it looks.

This is the comment you were replying to, attached to the article Question: From FreeBSD to Debian, in four days?:

#4 Re: Question: From FreeBSD to Debian, in four days? Posted by simonw (212.24.xx.xx) on Fri 2 Sep 2005 at 15:38 There really aren't that many gotcha's. Learn "apt" thoroughly, the Debian reference is a good read, if rather dry. Features like "apt-get remove -purge", "apticron", "cron-apt" are worth their weight in gold. If you find your self struggling with the packaging system you've probably missed a command that does it for you, ask someone ;) But also understand the releases properly, and why they exist, it isn't difficult, but there are a lot of people with funny ideas about them, and it took me a remarkably long time to get the grips with the basics of them (mostly for not reading the Debian reference material on them carefully enough). I've built fairly complex systems on top of Debian Sarge, for email and web, without having to step outside of the prepared packages in Sarge once. Which is a tribute to the maturity of the packaging system. But I'd never managed anything as complex with other Unix like systems without reverting to source far more frequently (even if in some cases I built my own packages). Stepping outside of the packaging system really is evil, that isn't just lipservice. Hardening is an interesting question. I tend not to explicitly harden Debian, apart from the trivial things like "apt-get remove portmap" after vanilla installs, so that the only listening processes are the ones I want listening. There is a lot of hardening advice, much of which will I suspect appeal to anyone coming from FreeBSD, but I suspect a lot of it will break the existing packaging assumptions, and thus make the boxes harder to maintain. None of the caching tools for packages are any good , either build your own Debian mirror (how to stress test rsync in one easy lesson), or tell squid that hanging onto a lot of huge .deb files is good karma, if you need to build or maintain a lot of boxes (or you are experimenting a lot and impatient). We did a special Debian LUG meet, and made our own mirror for it (2 minute job, plus 4 days of rsync on a 2Mbps connection to get x86 packages for stable/testing/unstable and install media), and it is just great if you are experimenting or trying a lot of stuff. Really 100Mbps fullduplex to the mirror saves a lot of time... Oh and we have a gigabit switch now ;) As regards the Linux Kernel, Debian has tools for building bespoke kernel packages ("apt-get install kernel-package", docs are always in /usr/share/doc/kernel-package). Use them, don't even think of not using them, don't even read "non Debian" kernel HOW-TOs. Indeed there is one right way to build a Linux kernel, and non-Debian people are all doing it wrong ;). I'm guessing with fancy hardware you may have to build bespoke kernels, or at least bespoke kernel modules. Although these days all my servers run stock kernels (again staying inside the packaging system means getting the latest kernel upgrades automatically). My Desktop box has a hideously bespoke kernel, with bespoke modules, it almost certainly could run a stock kernel if I'd known as much then as I do now.

Username:	Anonymous
Title:
Your Comment:
Posting Format:	BBCode HTML Text Plain Text Textile

Inappropriate comments will be removed.

Username:

Password:

[ Advanced Login ]

Register Account