On Mon, Mar 11, 2002 at 09:52:30PM +0800, Ian C. Sison wrote: > > Slackware as an 'training distro' is the best training tool one can have. > Linux from scratch is too crude. Slackware will allow you to learn what > goes on 'under the hood', so that you will know just how everything comes > together in a linux system. > > Slackware used as a distro for multiple servers is an unwise decisision. > It does not have a package manager like RPM or DEB. To have a > maintainable and sustainable network of linux servers, you need good > package management.
Like Ian, I hold the same view. Having cut my teeth on SLS, Yggdrasil and Slackware in the early days, I have had my share of rolling-my-own, compiling sources from tarballs, and a slew of other chores that you do need to learn in order to understand what goes on under the hood. I flirted with RedHat for a spell, and then met Debian. Ever since, I've been hooked to Debian. Although compiling completely from tarballs is suitable for a personal machine, and though could be useful for developers who need to work close-to-low-level, or are just learning, over time, it becomes a big ball of mud. Configuration files and documentation will be strewn in so many different places on the file system, no organization to speak of unless you've taken steps to keep the system organized and well documented. But if you're just beginning to learn, it's unlikely that you'll have a good sense of where to place what. Couple this with the fact that replicating your work on multiple installations will be a completely new task. I'm not sure if you've handled more than a handful of machines and with a bunch of other system administrators. Unless you all do everything to the systems together and have effective communications within your team, the tarball approach might not work in the long run. A package management system as well as a well thought out filesystem layout (like FSSTND/FHS) becomes an important feature of your systems. The problems of synchronizing binaries across machines also becomes a matter of propagating the packages. Of course, this -can- be done with tarballs too, but you save yourself the trouble of fixing the source to meet with your site specific stuff. Maintainability through upgrades is an important feature that package managers should have in them. The primary difficulty with working with pristine sources for the most part is that you will end up with a variety of variations for file placement, which the packagers would have fixed to conform with the particular distribution's filesystem layout. Other benefits include dependency management. How many times have you tried compiling pristine source only to find you don't have the required support/development libraries? Then you go through the trouble of installing the libraries from source and then pull your hair out trying to get it to work? For the developer as well, who would like to spend more of eir time producing code, the ease with which e can install the required development environment components is a godsend. Rather than wasting eir time figuring out how to install the libraries and getting them to work together, e can simply install a pre-packaged library and development environment and get to work straightaway. Of course, if e later decides e wants to tweak eir setup further, e's free to do that. Now, let's go one step further. As a developer, you need to consider your target market too. Requiring your end-user to match your personal setup at home would be ludicrous. However, you do need to document what dependencies your code requires, and in turn, it makes quite a lot of sense for a package to have that information in the metacontainer that holds it. That's probably what the packages are best used for. A tarball will have the information about dependencies and all that but require the human to ensure that those dependencies are met. The dependencies are usually contained in one of the documentation files that humans have to read. A package on the other hand, whether it is Slackware's mechanism, or RedHat's RPM, or Debian's DEB, will have this information available to the machine itself so that the process of meeting those dependencies can be automated as well. Now, I haven't really organized my thoughts on this matter that well, but those are my from-the-seat-of-my-pants notions on this. If you're using Linux strictly for personal use and enjoy doing the hard stuff, go ahead, steer clear of distributions which make it easy. If you've gotten past the point where you have to tweak every little source on your personal machine and need to maintain more than one server for other people with other people, look for a distribution that offers good package management. If you want to still use sources and still maintain your sanity, you can still use package managed distributions because they do have their sources still available. You can also look at source.RPMs and source.DEBs or try that other free OS that traces its origins from the Berkeley guys. -- ___ eric pareja ([EMAIL PROTECTED]) User #8159 http://counter.li.org \e/ [ Chiba City: A Cyberpunk MUSH - http://chibacity.erisian.net ] GNU/Linux v [ Philippine Linux Users' Group + http://plug.linux.org.ph ] Software & [ IRC /join #plug @irc.free.net.ph every evening 10pm onwards ] Freedom "All those moments will be lost in time like tears in the rain." _ 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]
