> ----- Original Message ----- > From: "Michael Balcos" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, March 12, 2002 4:48 PM > Subject: Re: [plug] why not slackware? > > > > I'm using Slackware to deploy thin servers. Slackware alone is functional > > in this arena. Packages are well selected in the distribution, and should > > I need something else there is no problem in compiling from the source on > > your own. True, Slackware has no dependency provisions for its packages. > > But since simplicity is in the philosophy of the distribution, it takes > > little time to get acquainted with many of its packages, thus rendering > > packet management less useful. The "D" disk set, even by default, will > > suffice for compiling most of the code necessary for servers should they > > be not included in the distribution. True, also, that Slackware has no big > > set of secure packages. But this means that distribution maintenance will > > not be bloated with package maintainers. You will also have a rather > > greater control over your system since you don't have a big set of > > packages where you rely on package management, and you virtually know > > every functional component in your system. > >
When it comes to maintaining several 10s or hundreds of linux servers, this "knowing every functional component in your system" is not sustainable. Don't get the idea that it is, because it's not. When it comes to maintaining the security of your system, it's so terribly important that there's an MD5 signature you can rely on to see if a binary has been compromised. When it comes to determining versions of packages, and reliably and completely purging a file system of the files associated with it, there needs to be an all-encompassing list of files so they are not 'lost' when it's time for uninstallation. When it comes to determining package dependencies and which one breaks what, and which version depends on which version, this is absolutely a requirement when dealing with dynamically linked linux applications! Think about it, if the 'tar.gz' approach filled up the needs of a modern distribution, there would be no need for RPMs and DEBs, and no one would code such 'monsters'. Tarballs are important, no doubt. We all learned from them, We hand-toiled around our 20 3.5 inch diskettes of slackware years ago. But now that linux is second nature, it's time to move on, and advance. Learning how to compile your own .src.rpm can be even more fulfilling and productive than being able to adapt a tar.gz to your box. Why? Because all the stuff and keystrokes you did to adapt the tarball goes into the .spec of the source rpm. You can share your work with others, maybe not willing to go through the process of 'hand-compiling'. And that's what open source is all about. Sharing. It's 4 in the morning. Do you know what /usr/bin/pawd is for? Oooh, i know! it's: rpm -qi `rpm -qf /usr/bin/pawd` _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
