Re: Red Hat user shopping around
May 9, at 09:45, dman sent through the Star Gate: Whenever a library goes through a major incompatible revision, debian keeps both around as separately named packages designed to co-exist. That by itself is a good enough reason for me to try Debian. I tried as a newbie to upgrade some packages in my RH 5.2 box so I could run some programs I needed. After I finished, other progams I needed no longer worked. I ended up having to wipe the box and reinstall from scratch. Upgrading Red Hat has been a major nightmare. Right now I have a Red Hat 7.2 box that I use to host a couple hundred non-profits, mostly churches. For security reasons I need to keep it upgraded to the latest releases of the programs I'm using. I tried to upgrade two other boxes. Neither worked. I had to wipe them and install from scratch. I have so many customizations to this box that if the upgrade fails, I'm going to lose a bunch of services I provide that will take me months to reinstall. Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, May 08, 2002 at 10:24:39PM -0500, Jamin W. Collins wrote: | On Wed, 8 May 2002 19:09:13 -0500 | Glen Lee Edwards [EMAIL PROTECTED] wrote: | What are the main differences between Debian and Red Hat (I'm assuming | there are a few current or ex-Red Hat users here)? | | The main thing that struck me on the move are that some of the | configuration files are automagically updated (modules.conf for example) | and if you make changes to them directly you can end up losing those | changes. Yes, with good reason too :-). That's why you'll want to ask stupid[1] questions on this list -- so that you can have the design explained and reduce the amount of banging against a wall your head does. -D [1] stupid in quotes because the question only feels stupid, but really isn't :-) -- Whoever gives heed to instruction prospers, and blessed is he who trusts in the Lord. Proverbs 16:20 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgphUMVrFi8YI.pgp Description: PGP signature
Re: Red Hat user shopping around
dman writes: On Wed, May 08, 2002 at 07:09:13PM -0500, Glen Lee Edwards wrote: I don't know about *install*, but it certainly *runs* (and sometimes crawls :-)) on 8MB. Linux and low RAM boxes don't get along well. I found that I can run FVWM on a remote box using X-forwarding to a better box on the LAN and get acceptable performance as long as I don't use high graphics programs, such as gimp or a graphics web browser. Unfortunately this only works if you have a quality computer around, which wasn't the case here for several years. For the first couple of years I ran Linux, I did everything on the console. My wife didn't know Linux had graphics, and referred to Linux as the X-ray vision operating system. (I couldn't get my 8MB clunker to boot from a cd and didn't have any floppies handy so I stuffed the hd in a bigger machine for the install. Be aware that with only 8MB RAM package updates and many other operations cause lots of thrashing. 16MB would be much better :-)). That's what I call resourceful. I'd have put Windows 95 back in it and then used it for target practice. | What are the main differences between Debian and Red Hat Policy is the first difference. Availability and findability and quality of packages is next. I recently had to install RH 7.2 on a machine, and I saw first-hand how badly RH is organized. Config files are strewn about the FS, but on debian they are always in /etc/pkgname. The dependencies in They recently dumped inet for xinet. Instead of having one configuration file in /etc/inetd.conf, they now have individual files per service in /etc/xinetd.d/. I'm sure that makes sense to somebody, but it makes configuring it a real headache. debian packages are much saner too -- for example try installing python2 on a headless RH box *without* also installing the X server and X font server. Package dependencies are a real killer. Try installing XFree86 first. It has dependencies, which in turn have dependency requirements, which also have them - 4 or 5 deep. These of course conflict with other packages you already have installed. Some packages you need use older libraries, others newer libraries. So you get to chose one or the other, or run different releases on different computers. As far as availability and findability goes, RH has sendmail as the only MTA. Debian has sendmail, exim, postfix, ssmtp, and I'm sure there are others as well. The same goes for many other tools. When I made the switch from RH to Debian I was amazed to find included on the cd many little-known programs I had failed to compile on my RH system. I need one that's secure and gives you real control over it. I've been using Sendmail. But I've been receiving mail from spammers that, according to the message ID, are originating from my own box. I'm guessing that they're either sending mail directly from their home system to my Sendmail program, using it as the MTA, which they aren't supposed to be able to do (relaying denied is set), or they've somehow hacked me and are originating spam mail from my computer. I need an MTA that gives me more control over the mail in my system, including the ability to have copies of all mail that originates in my system sent to me by the MTA. | (I'm assuming there are a few current or ex-Red Hat users here)? Yep. RH 7.0 pushed me over the edge (I only started with 5.2 which didn't like my vid. card and then 6.1). I started with 5.2 also. Actually I tried Slackware first. That was a nightmare. How'd I know they'd expect me to keep a copy of my monitor refresh rates lying around? I then tried Red Hat. It installed, so I've remain unconditionally loyal to it since. Heh, one upgrade from 6.1 to 6.2 literally took 6 days. | Does Debian support the old Sound Blaster Pro CDRoms (sbpcd module)? It's in the kernel source and image packages. I presume it works :-). (that's a kernel thing, really, and all distros should be the same wrt it) Good. I don't know what if any tweaking of the kernel different packagers do. Thought I'd better ask. | How well does FVWM run on Debian systems? I currently build FVWM | rpms for Red Hat. I use sawfish but I have fvwm installed just in case something goes wack with sawfish. It runs, but I can't speak for how well because I don't usually use it. I've spent way to much time personalizing FVWM to give it up. I'll occasionally use KDE just for the variety, but I have so may keyboard customizations and mouse shortcuts designed into FVWM that I quickly get frustrated when I try something else. | I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. I recommend running spamassassin with your mail service. It won't take kindly to low memory (it uses around 8-9MB on my machine) though some people run it on a 486 with 32MB RAM. (I think those are terminal machines with relatively low volumes of mail) You can have 'spamd' running on a different machine than your MTA, though. I'll try it and see
Re: Red Hat user shopping around
On Wed, 2002-05-08 at 23:49, Glen Lee Edwards wrote: dman writes: On Wed, May 08, 2002 at 07:09:13PM -0500, Glen Lee Edwards wrote: [snip] debian packages are much saner too -- for example try installing python2 on a headless RH box *without* also installing the X server and X font server. Package dependencies are a real killer. Try installing XFree86 first. It has dependencies, which in turn have dependency requirements, which also have them - 4 or 5 deep. These of course conflict with other packages you already have installed. Some packages you need use older libraries, others newer libraries. So you get to chose one or the other, or run different releases on different computers. Yeah, that's why I dumped Mandrake... It was _impossible_ to upgrade mdk8.0 from kde 2.2.1 to 2.2.2. The RPM Hell was infuriating. Debian is _so_ easy in that regard. Twice a week, do a apt-get update apt-get -u upgrade and you're home free. [snip] You'll get plenty of those. I've read through the list mail over the last couple of days. There are noticeable differences in the language Debian users speak. One user posted a question about finding configuration files. I didn't respond because of the differences. But on Red Hat you can find most configuration files with $ locate .conf For a specific program, such as proftp: $ locate .conf | grep proftp /etc/proftpd.conf.rpmnew /etc/proftpd.conf /etc/proftpd.conf.new /etc/proftpd1.conf /etc/proftpd.conf~ /etc/proftpd1.conf~ /home/glenlee/etc/proftpd.conf /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/complex-virtual.conf /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/PFTEST.conf.in /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/anonymous.conf /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/basic.conf /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/mod_sql.conf /usr/share/doc/proftpd-1.2.5rc1/sample-configurations/virtual.conf Guess I need to delete some files! Isn't that how everyone does it? Even in Debian/woody, there are .conf files in more places than just the /etc tree. [snip] That by itself is good enough for me to try it. I absolutely dread Red Hat upgrades. I don't know why they can't do it so you can just upgrade individual packages without having to re-install the whole system. Most of the time when I upgrade I can guarantee that the box will be down for one to several days. Ugh! Note, though, that even with Debian, if a package requires, say, perl5.6, and your old stable/Potato box only has perl5, you're going to download a _whole_lot_ of dependant packages. A Debian policy-that-I-think-is-a-quirk: there is the the concept of the meta-package. mail-transport-agent is an example. When, for example, you install exim, mail-transport-agent is also installed. If you want to install postfix to test it out, apt will remove exim, since the exim postfix packages are both members of the same meta-package. It won't let me manage inetd.conf to make sure that 2 different programs are combating for the same port. -- ++ | Ron Johnson, Jr.Home: [EMAIL PROTECTED]| | Jefferson, LA USA http://ronandheather.dhs.org:81| || | You ask us the same question every day, and we give you| | the same answer every day. Someday, we hope that you will | | believe us... | | Donald Rumsfeld, to a reporter | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
Ron writes: That by itself is good enough for me to try it. I absolutely dread Red Hat upgrades. I don't know why they can't do it so you can just upgrade individual packages without having to re-install the whole system. Most of the time when I upgrade I can guarantee that the box will be down for one to several days. Ugh! Note, though, that even with Debian, if a package requires, say, perl5.6, and your old stable/Potato box only has perl5, you're going to download a _whole_lot_ of dependant packages. I don't have a problem as much with downloading dependencies as I do with needing programs that require conflicting libraries. I'm fortunate in that I have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm accessing can handle it. If the perl dependencies in your example install without breaking other dependencies, I'm good to go. A Debian policy-that-I-think-is-a-quirk: there is the the concept of the meta-package. mail-transport-agent is an example. When, for example, you install exim, mail-transport-agent is also installed. If you want to install postfix to test it out, apt will remove exim, since the exim postfix packages are both members of the same meta-package. It won't let me manage inetd.conf to make sure that 2 different programs are combating for the same port. Not sure I'm following what you mean. Are you trying to get inetd to read queries to the port, and based on the query determine which program to open? I don't think you can do that. Technically it's possible, but based on Internet standards my understanding is that specific ports are designed for specific programs (protocols). And trying to get inetd to pick between exim and postfix based on the incoming packets I would think would require a complete rewrite of inet. I may have totally missed what you're trying to say. Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, 8 May 2002, Glen Lee Edwards wrote: The Debian web site says that Debian will install on 12 Meg RAM. Is that information current? I haven't seen a reason why it wouldn't be. What are the main differences between Debian and Red Hat (I'm assuming there are a few current or ex-Red Hat users here)? Based against Red Hat 5.2, an experiance that scarred me for life and nearly turned me off to Linux entirely as I was starting out until I found Debian, so this will be a bit biased and outdated. - dpkg makes life easier than dealing with RPM. The dpkg isn't a complete bitch to deal with like RPM on the command line. You also have to make an effort to install two versions of the same package with dpkg, instead of it being the default behaviour like it is with RPM. - apt makes life easier than dealing with... oh yeah, Red Hat doesn't have anything to resolve dependancies and download packages automatically. So apt is better than getting cozy with a bash prompt and rpmfind.net for a few hours. - Filesystem layout is sane. No more trying to have to remember how to translate the layout from what's in the howto to what's on your system, it'll be closer to, if not the same. - We're the largest. Heck, the Apache package used to come with a few ad banners for Debian which bragged about having nearly 6000 packages as part of the distro. Most people will have under a tenth of that installed, but the point is, you have selection and variety. - Installer's not as scary (as of Debian hamm, which was the last time I had to use the installer). Yeah, it doesn't autodetect beyond what the kernel can (ie, you don't necissarily have to know module parameters, but you at least need to know which modules), but it gives you a bit more control over what packages get installed right off, and it doesn't try to partition your disk by default into a bizarre layout. - Upgrading is easy. I've been using Debian since bo, reinstalled to get hamm (kinda like the easiest way to upgrade Red Hat), and somewhere around that time someone pointed out an early apt release to me at a LAN party. Every once in a while I go through and clean out the cruft, but it hasn't had a bad cruft buildup yet. Does Debian support the old Sound Blaster Pro CDRoms (sbpcd module)? Not sure, but if the linux kernel supports it, shouldn't be that big of a problem. How well does FVWM run on Debian systems? I currently build FVWM rpms for Red Hat. fvwm2 and fvwm95 (the two fvwm flavors I'm familiar with) run great. I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. X would be nice, but I usually use X forwarding on those boxes to another one that can handle the load (500 MHZ, 512 Meg RAM). XF864 is great here, bind9 runs nice, I use it for my local network myself. exim runs great, and thank you, dman, for that spamassassin+exim howto; it's working wonders. Adding spamassassin and sending an email reminding users to report spam has worked wonders (as opposed to just reminding users to report spam). distribution that will work as both a server and a desk top environment. And I need one that will remain loyal to its customer base, including those with low resource PCs. Welcome to Debian. -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 2002-05-09 at 01:09, Glen Lee Edwards wrote: Ron writes: [snip] A Debian policy-that-I-think-is-a-quirk: there is the the concept of the meta-package. mail-transport-agent is an example. When, for example, you install exim, mail-transport-agent is also installed. If you want to install postfix to test it out, apt will remove exim, since the exim postfix packages are both members of the same meta-package. It won't let me manage inetd.conf to make sure that 2 different programs are combating for the same port. Not sure I'm following what you mean. Are you trying to get inetd to read queries to the port, and based on the query determine which program to open? I don't think you can do that. Technically it's possible, but based on Internet standards my understanding is that specific ports are designed for specific programs (protocols). And trying to get inetd to pick between exim and postfix based on the incoming packets I would think would require a complete rewrite of inet. I may have totally missed what you're trying to say. Must have. But, that's why I'm not a teacher! On mandrake (the one I know), I can rpm -ihv exim and postfix. Of course, like you say, 2 progs can't use the same port. So, I'd have 2 lines in inetd.conf for smtp: one each for exim and postfix. Then, I'd comment out, say, exim, and NOHUP inetd to run postfix. So, I can run exim or postfix depending on what's commented out in inetd.conf. No problem. Debian won't let you do that. A beauty of the meta-package is that (staying with the MTA example), if a package requires an MTA, but doesn't care _which_ MTA, the package developer simply requires mail-transport-agent, instead of exim|postfix|sendmail|blahblah. Also more flexible if someone packages a new MTA. All he must do it add it as a member of mail-transport-agent, instead of changing the requirements of each package that requires an MTA. -- ++ | Ron Johnson, Jr.Home: [EMAIL PROTECTED]| | Jefferson, LA USA http://ronandheather.dhs.org:81| || | You ask us the same question every day, and we give you| | the same answer every day. Someday, we hope that you will | | believe us... | | Donald Rumsfeld, to a reporter | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 2002-05-09 at 01:18, Paul 'Baloo' Johnson wrote: On Wed, 8 May 2002, Glen Lee Edwards wrote: [snip] - dpkg makes life easier than dealing with RPM. The dpkg isn't a complete bitch to deal with like RPM on the command line. You also have to make an effort to install two versions of the same package with dpkg, instead of it being the default behaviour like it is with RPM. I don't remember being able to easily install 2 versions of the same package. - apt makes life easier than dealing with... oh yeah, Red Hat doesn't have anything to resolve dependancies and download packages automatically. So apt is better than getting cozy with a bash prompt and rpmfind.net for a few hours. RH now has Red Carpet, which does something similar to apt-get, but I think you must go only to redhat.com. No choosing the fastest mirror. - Installer's not as scary (as of Debian hamm, which was the last time I had to use the installer). Yeah, it doesn't autodetect beyond what the kernel can (ie, you don't necissarily have to know module parameters, but you at least need to know which modules), but it gives you a bit more control over what packages get installed right off, and it doesn't try to partition your disk by default into a bizarre layout. Doing a network install (over cable modem) of woody wasn't so difficult. -- ++ | Ron Johnson, Jr.Home: [EMAIL PROTECTED]| | Jefferson, LA USA http://ronandheather.dhs.org:81| || | You ask us the same question every day, and we give you| | the same answer every day. Someday, we hope that you will | | believe us... | | Donald Rumsfeld, to a reporter | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, 8 May 2002, Glen Lee Edwards wrote: Linux and low RAM boxes don't get along well. Not sure what paralell universe that's from. Linux runs on PDAs, for chrissake. 8:o) I ran ursine.dyndns.org on a 386 with 8MB RAM and 111MB of disk space (I was in high school and had to scrape together scrap hardware to get that far...this was sick. The onboard controller was MFM/RLL, I had added an IDE controller, both had drives attached...I took that box, which hadn't been booted in years, to a LAN party and scared people with it when I raised the hood (old flip-open AT style case that had a button on either side to release the case cover, which flipped open like a car hood except it would go to perpendicular to the rest of the case)), even installed hamm on it back then. I've been keeping the same install on every upgrade, though, just updating packages and kernels. Got bored earlier, and found an MP3 with a date back from 1997 on it. (mp3blaster is your friend when you want music on a 386). couple of years I ran Linux, I did everything on the console. My wife didn't know Linux had graphics, and referred to Linux as the X-ray vision operating system. I don't get it. They recently dumped inet for xinet. Instead of having one configuration file in /etc/inetd.conf, they now have individual files per service in /etc/xinetd.d/. I'm sure that makes sense to somebody, but it makes configuring it a real headache. That just hurts...why would someone implement something in such an obviously painful manner? message ID, are originating from my own box. I'm guessing that they're either sending mail directly from their home system to my Sendmail program, using it as the MTA, which they aren't supposed to be able to do (relaying denied is set), or they've somehow hacked me and are originating spam mail from my computer. I IIRC, relaying is either enabled by default or overly-easy to enable in one of Red Hat's GUI admin tools. And if they're connecting to you directly to send thier spam, they're not relaying, they're doing what any other mail server would be doing. need an MTA that gives me more control over the mail in my system, including the ability to have copies of all mail that originates in my system sent to me by the MTA. This is best done by hacking procmail into the message path on an existing MTA, no MTA has this ability out of the box. You'll probably like Debian's default, exim, which is easy to configure and doesn't have relaying enabled by default. I started with 5.2 also. Actually I tried Slackware first. That was a nightmare. How'd I know they'd expect me to keep a copy of my monitor refresh rates lying around? Before I install X on any system, I go to monitorworld.com and look up the data on the monitor, then use a magic marker to write it on the back of the monitor if it's not already printed there. I never could understand why such a basic spec isn't printed right on the same label as the make, model and FCC id. -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 9 May 2002, Glen Lee Edwards wrote: I don't have a problem as much with downloading dependencies as I do with needing programs that require conflicting libraries. I'm fortunate in that I have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm accessing can handle it. If the perl dependencies in your example install without breaking other dependencies, I'm good to go. Jeez...I'm so glad I'm back on cable. 66kbps is infuriatingly slow... installed. If you want to install postfix to test it out, apt will remove exim, since the exim postfix packages are both members of the same meta-package. It won't let me manage inetd.conf to make sure that 2 different programs are combating for the same port. Not sure I'm following what you mean. Are you trying to get inetd to read queries to the port, and based on the query determine which program to open? I don't think you can do that. Technically it's possible, but based on Internet I may have totally missed what you're trying to say. I think I did, too. Especially since I don't think the dependancies quite pan out the way he said, if I'm understanding him right. -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On 9 May 2002, Ron wrote: I don't remember being able to easily install 2 versions of the same package. Countless times I had installed a newer version of a package only to discover it managed to slip it in there in some borken manner that left the old version completely intact *and* installed the new version. Especially with libraries. RH now has Red Carpet, which does something similar to apt-get, but I think you must go only to redhat.com. No choosing the fastest mirror. So even getting with the times they still remain broken... Doing a network install (over cable modem) of woody wasn't so difficult. No, it wasn't. -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
Paul 'Baloo' Johnson writes: On Wed, 8 May 2002, Glen Lee Edwards wrote: Linux and low RAM boxes don't get along well. Not sure what paralell universe that's from. Linux runs on PDAs, for I mis-stated myself; Low RAM boxes and Linux GUIs (X and gimp, desktop applications (Gnome, KDE), etc.) don't get along. Linux from the console and 16M RAM worked great for me. But fire up X with Gnome, and I could fix supper before Gnome would finish loading. Try to start Netscape and I could go to bed and get up the next morning and hope it would be started. Pages would load at 20 bites/second. couple of years I ran Linux, I did everything on the console. My wife didn't know Linux had graphics, and referred to Linux as the X-ray vision operating system. I don't get it. Linux from console reminded her of reading xrays - black background with everything pertinent in white. It's a poor analogy, because xrays are pictures while the console is solely text, but that's what she called it. need an MTA that gives me more control over the mail in my system, including the ability to have copies of all mail that originates in my system sent to me by the MTA. This is best done by hacking procmail into the message path on an existing MTA, no MTA has this ability out of the box. I'll have to research that one. I know that Sendmail can be configured to use Procmail as the MDA, but I didn't know that Procmail could be used as the front end for the MTA. You'll probably like Debian's default, exim, which is easy to configure and doesn't have relaying enabled by default. I'll look into it. I need some way to kill the spam that goes through my servers. Yesterday I received an email from Brazil. I'm not real sure what it said, but it looked official, made several references to spam, and quoted at the bottom something that looked like legal text. I'm assuming that they received some spam with a message ID that matched one of my machines. I started with 5.2 also. Actually I tried Slackware first. That was a nightmare. How'd I know they'd expect me to keep a copy of my monitor refresh rates lying around? Before I install X on any system, I go to monitorworld.com and look up the data on the monitor, then use a magic marker to write it on the back of the monitor if it's not already printed there. I never could understand why such a basic spec isn't printed right on the same label as the make, model and FCC id. Or why they don't include the sound card specs, etc., with the PC documentation. Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
Paul 'Baloo' Johnson writes: On Thu, 9 May 2002, Glen Lee Edwards wrote: I don't have a problem as much with downloading dependencies as I do with needing programs that require conflicting libraries. I'm fortunate in that I have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm accessing can handle it. If the perl dependencies in your example install without breaking other dependencies, I'm good to go. Jeez...I'm so glad I'm back on cable. 66kbps is infuriatingly slow... Actually that's KBytes - or 528 kBits/second. The line is rated at 640 kb/s download, but slightly over 520 is what I usually get. That allows me to download a full cdrom in about 2 1/2 hours. I just download the 3 CDRom Red Hat 7.3 distro in less than 8 hours. Took weeks on my old 14.4 modem. Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 2002-05-09 at 07:39, Ron wrote: On Thu, 2002-05-09 at 01:18, Paul 'Baloo' Johnson wrote: On Wed, 8 May 2002, Glen Lee Edwards wrote: [snip] - dpkg makes life easier than dealing with RPM. The dpkg isn't a complete bitch to deal with like RPM on the command line. You also have to make an effort to install two versions of the same package with dpkg, instead of it being the default behaviour like it is with RPM. I don't remember being able to easily install 2 versions of the same package. - apt makes life easier than dealing with... oh yeah, Red Hat doesn't have anything to resolve dependancies and download packages automatically. So apt is better than getting cozy with a bash prompt and rpmfind.net for a few hours. RH now has Red Carpet, which does something similar to apt-get, but I think you must go only to redhat.com. No choosing the fastest mirror. Not so. In fact, Red Carpet isn't part of Red Hat Linux, and you /can/ choose your mirror. It's a product from Ximian. The integrated update tool is called up2date, and /does/ automatically resolve dependencies. In fact, you can automatically resolve dependencies if you have the redhat-rpmdb package installed. RPM is a capable packaging system, with meta-packages, dependency resolution and all that good stuff. The real mystery is why Ximian are the only people who have chosen to leverage that. By the way, you can use Red Carpet on your Debian Woody system - it's package-manager agnostic. -- Peter Whysall [EMAIL PROTECTED] The TLD in my email address is sdrawkcab. Debian GNU/Linux 3.0 sid -- kernel 2.4.18 signature.asc Description: This is a digitally signed message part
Re: Red Hat user shopping around
On Thu, 2002-05-09 at 01:43, Paul 'Baloo' Johnson wrote:
On Wed, 8 May 2002, Glen Lee Edwards wrote:
[snip]
They recently dumped inet for xinet. Instead of having one configuration
file
in /etc/inetd.conf, they now have individual files per service in
/etc/xinetd.d/. I'm sure that makes sense to somebody, but it makes
configuring
it a real headache.
That just hurts...why would someone implement something in such an
obviously painful manner?
Here's are the contents of /etc/xinetd.d/wu-ftpd
service ftp
{
disable = no
id = ftp-stream
flags = REUSE
socket_type = stream
protocol= tcp
port= 21
wait= no
user= root
server = /usr/sbin/in.ftpd
server_args = -l -a
log_on_failure += USERID
}
It's supposed to be more secure, and it logs to syslog which
services are bound to which ports, and logs if something fails
to initialize. Also, it may be a bit more secure to not have to
edit inetd.conf for _everything_. When you install a new package,
the pkg manager just creates a new file in /etc/xinetd.d.
All in all, though, I still prefer inetd. Mdk must think it's
special, since they haven't shipped inetd since 7.1.
--
++
| Ron Johnson, Jr.Home: [EMAIL PROTECTED]|
| Jefferson, LA USA http://ronandheather.dhs.org:81|
||
| You ask us the same question every day, and we give you|
| the same answer every day. Someday, we hope that you will |
| believe us... |
| Donald Rumsfeld, to a reporter |
++
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 9 May 2002, Glen Lee Edwards wrote: have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm accessing can handle it. If the perl dependencies in your example install without breaking other dependencies, I'm good to go. Jeez...I'm so glad I'm back on cable. 66kbps is infuriatingly slow... Actually that's KBytes - or 528 kBits/second. The line is rated at 640 kb/s download, but slightly over 520 is what I usually get. That allows me to download a full cdrom in about 2 1/2 hours. I just download the 3 CDRom Red Hat 7.3 distro in less than 8 hours. Took weeks on my old 14.4 modem. Erk, I meant 66kBps. Any time I've pulled less than 130 kBps on cable I've had all my roommates were awake at the same time and had people over with thier computers, or the server I was connecting to just didn't have the bandwidth to send to me that quickly. My DSL experiance wasn't good: Installation took forever. It crapped out constantly. Repairs took forever. It was bloody expensive compaired to cable (about $5 more a month than cable based on time, and more than that based on uptime, and more than that based on bytecount.) -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, May 09, 2002 at 12:20:44AM -0500, Ron wrote: Isn't that how everyone does it? Even in Debian/woody, there are .conf files in more places than just the /etc tree. Reading configuration (that the user might be expected to change) out of anywhere other than /etc is considered a bug ... A Debian policy-that-I-think-is-a-quirk: there is the the concept of the meta-package. mail-transport-agent is an example. When, for example, you install exim, mail-transport-agent is also installed. If you want to install postfix to test it out, apt will remove exim, since the exim postfix packages are both members of the same meta-package. That's a virtual package. (Meta-packages are something else - they're real packages that exist for the sole purpose of depending on other packages for convenience.) They do provide quite a lot of flexibility. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, May 09, 2002 at 08:37:56AM +0100, Peter Whysall wrote: | On Thu, 2002-05-09 at 07:39, Ron wrote: | On Thu, 2002-05-09 at 01:18, Paul 'Baloo' Johnson wrote: | On Wed, 8 May 2002, Glen Lee Edwards wrote: | [snip] | - dpkg makes life easier than dealing with RPM. The dpkg isn't a | complete bitch to deal with like RPM on the command line. You also have | to make an effort to install two versions of the same package with dpkg, | instead of it being the default behaviour like it is with RPM. | | I don't remember being able to easily install 2 versions of | the same package. Use -i (install) instead of -u (upgrade). With rpm, the version number is kinda part of the package name. The package name is as much as you specify, rather than having specific delimiters like dpkg. rpm also allows multiple packages with the same name (different version) installed, as long as no two files have the same name. It's a real PITA. Whenever a library goes through a major incompatible revision, debian keeps both around as separately named packages designed to co-exist. | - apt makes life easier than dealing with... oh yeah, Red Hat doesn't | have anything to resolve dependancies and download packages | automatically. So apt is better than getting cozy with a bash prompt | and rpmfind.net for a few hours. | | RH now has Red Carpet, which does something similar to apt-get, | but I think you must go only to redhat.com. No choosing the | fastest mirror. | | Not so. In fact, Red Carpet isn't part of Red Hat Linux, and you /can/ | choose your mirror. It's a product from Ximian. | | The integrated update tool is called up2date, and /does/ automatically | resolve dependencies. In fact, you can automatically resolve | dependencies if you have the redhat-rpmdb package installed. RPM is a | capable packaging system, with meta-packages, dependency resolution and | all that good stuff. The real mystery is why Ximian are the only people | who have chosen to leverage that. When I tried up2date (a long time ago) it really sucked and didn't work well and supported almost no packages. Someone has even ported apt to rpm. It has some problems though -- it's potato's apt (no preferences) and it mmaps the Packages file. I tried using it (within the last few months) on a machine with 96MB RAM. It dies with an out-of-memory error. Potato's apt on my 8MB clunker _works_ even though it gets a sound thrashing in the process. -D -- A)bort, R)etry, D)o it right this time GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpvgEMytZOV3.pgp Description: PGP signature
Re: Red Hat user shopping around
On Thu, May 09, 2002 at 01:11:30AM -0700, Paul 'Baloo' Johnson wrote: | On Thu, 9 May 2002, Glen Lee Edwards wrote: | | have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm | accessing can handle it. If the perl dependencies in your example install | without breaking other dependencies, I'm good to go. | | Jeez...I'm so glad I'm back on cable. 66kbps is infuriatingly slow... | | Actually that's KBytes - or 528 kBits/second. The line is rated at 640 kb/s | download, but slightly over 520 is what I usually get. That allows me to | download a full cdrom in about 2 1/2 hours. I just download the 3 CDRom Red Hat | 7.3 distro in less than 8 hours. Took weeks on my old 14.4 modem. | | Erk, I meant 66kBps. Any time I've pulled less than 130 kBps on cable | I've had all my roommates were awake at the same time and had people | over with thier computers, or the server I was connecting to just didn't | have the bandwidth to send to me that quickly. My DSL experiance wasn't | good: Installation took forever. It crapped out constantly. Repairs | took forever. It was bloody expensive compaired to cable (about $5 more | a month than cable based on time, and more than that based on uptime, | and more than that based on bytecount.) It all depends on your local services. Where I'm from (Roch. NY) cable is more expensive. It only took about a month, I think, from the first phone call to have the line setup. I did the in-the-house install myself (plugged in the Cisco 677 bridge and configured that NIC for DHCP and masquerading). My ADSL line is rated 3Mbps downstream and something small upstream. The actual performance ranges from bad (~20KBps) to great (~100-200KBps) (note the capitalization of 'B'). The local cable service costs about $10/mo more IF you have bettter-than-Basic cable TV service and about $10/mo more than that if you have Basic or no cable TV service. My (parents') house has no cable TV wiring between the street and it. The cable internet service is rated at 2Mbps downstream. Both services are mostly ok (from what I hear). The DSL service _was_ rather crappy in that it required logging on via a web form before IP routing would work (apart from the DNS server and that web server). I automated it in /etc/network/interfaces and a python script. They've since elminated that source of failure. Right now I have T1 access, but the gateway at home still has the DSL service. -D -- (E)ventually (M)allocs (A)ll (C)omputer (S)torage GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpUu7pqIGyXX.pgp Description: PGP signature
Re: Red Hat user shopping around
On Thu, May 09, 2002 at 01:09:42AM -0500, Glen Lee Edwards wrote: | Ron writes: | | That by itself is good enough for me to try it. I absolutely dread Red Hat | upgrades. I don't know why they can't do it so you can just upgrade individual | packages without having to re-install the whole system. Most of the time when I | upgrade I can guarantee that the box will be down for one to several days. Ugh! | | Note, though, that even with Debian, if a package requires, say, | perl5.6, and your old stable/Potato box only has perl5, you're | going to download a _whole_lot_ of dependant packages. | | I don't have a problem as much with downloading dependencies as I do with | needing programs that require conflicting libraries. I'm fortunate in that I | have an ADSL line that will allow 66+ kB/s downloads, assuming the site I'm | accessing can handle it. If the perl dependencies in your example install | without breaking other dependencies, I'm good to go. That's the beauty of apt combined with Debian-quality packages. The deps Just Work (unless maybe if you run unstable, but that's why it's called unstable). | A Debian policy-that-I-think-is-a-quirk: there is the the concept | of the meta-package. mail-transport-agent is an example. When, | for example, you install exim, mail-transport-agent is also | installed. If you want to install postfix to test it out, apt | will remove exim, since the exim postfix packages are both | members of the same meta-package. It won't let me manage | inetd.conf to make sure that 2 different programs are combating | for the same port. | | Not sure I'm following what you mean. Are you trying to get inetd to read | queries to the port, and based on the query determine which program to open? I | don't think you can do that. Technically it's possible, but based on Internet | standards my understanding is that specific ports are designed for specific | programs (protocols). And trying to get inetd to pick between exim and postfix | based on the incoming packets I would think would require a complete rewrite of | inet. I'll explain with an example : [EMAIL PROTECTED] # apt-get --simulate install mail-transport-agent Reading Package Lists... Done Building Dependency Tree... Done Package mail-transport-agent is a virtual package provided by: zmailer-ssl 2.99.55-3 exim-tls 3.35-3 zmailer 2.99.55-3 ssmtp 2.50.6 smail 3.2.0.114-4 sendmail 8.12.3-4 postfix-snap 0.0.20020115-5 postfix 1.1.4-2 nullmailer 1.00RC5-16 masqmail 0.1.16-2 exim 3.35-1 courier-mta 0.37.3-2 You should explicitly select one to install. E: Package mail-transport-agent has no installation candidate [EMAIL PROTECTED] # dpkg -l exim Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++-==-==-= hi exim 3.35-1 An MTA (Mail Transport Agent) [EMAIL PROTECTED] # apt-get --simulate install postfix Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: postfix-ldap postfix-pcre The following packages will be REMOVED: exim The following NEW packages will be installed: postfix postfix-ldap postfix-pcre The following held packages will be changed: exim 0 packages upgraded, 3 newly installed, 1 to remove and 5 not upgraded. Remv exim (3.35-1 Debian:testing) [mutt pms mailx ] Inst postfix-ldap (1.1.4-2 Debian:testing) [mutt pms mailx ] Inst postfix-pcre (1.1.4-2 Debian:testing) [mutt pms mailx ] Inst postfix (1.1.4-2 Debian:testing) Conf postfix-pcre (1.1.4-2 Debian:testing) Conf postfix (1.1.4-2 Debian:testing) Conf postfix-ldap (1.1.4-2 Debian:testing) [EMAIL PROTECTED] # I have exim installed. It provides the virtual package mail-transport-agent. postfix also provides mail-transport-agent. Both conflict with mail-transport-agent. If I try to install one of them, the other will be removed. It's supposed to be a feature, and fortunately packages can be removed without obliterating their config files, and apt stores package files in /var/cache/apt so it isn't too painful to switch back and forth (unless your machine thrashes when apt runs). -D -- One man gives freely, yet gains even more; another withholds unduly, but comes to poverty. Proverbs 11:24 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpuAdZxL8FtO.pgp Description: PGP signature
Re: Red Hat user shopping around
On Wed, May 08, 2002 at 11:43:21PM -0700, Paul 'Baloo' Johnson wrote: | On Wed, 8 May 2002, Glen Lee Edwards wrote: | They recently dumped inet for xinet. Instead of having one configuration file | in /etc/inetd.conf, they now have individual files per service in | /etc/xinetd.d/. I'm sure that makes sense to somebody, but it makes configuring | it a real headache. | | That just hurts...why would someone implement something in such an | obviously painful manner? Have you ever tried to read RH init scripts? Have you ever tried to find an init script? -D -- Do not pay attention to every word people say, or you may hear your servant cursing you -- for you know in your heart that many times you yourself have cursed others. Ecclesiastes 7:21-22 GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpjnEKKjXZAk.pgp Description: PGP signature
Re: Red Hat user shopping around
On Wed, May 08, 2002 at 11:49:16PM -0500, Glen Lee Edwards wrote: [some quotes re-arranged for better cohesiveness of replies] | dman writes: | On Wed, May 08, 2002 at 07:09:13PM -0500, Glen Lee Edwards wrote: | (I couldn't get my 8MB clunker to boot from a cd and didn't have any | floppies handy so I stuffed the hd in a bigger machine for the | install. Be aware that with only 8MB RAM package updates and many | other operations cause lots of thrashing. 16MB would be much better | :-)). | | That's what I call resourceful. I'd have put Windows 95 back in it and then | used it for target practice. :-). The machine had no cd drive; I borrowed the (2x) sony drive and the corresponding sound blaster controller card from my dad's old machine. The BIOS wouldn't boot it, and I couldn't figure out the DOS driver to allow using loadlin. I had stolen the floppy drive from it because I was too cheap to buy one for my new machine (that I assembled) and didn't have any installer floppies handy (I'm not sure if I had a NIC in the machine at the time either). It served masquerading for the phone line for a while until we got DSL. I didn't want to buy another ISA NIC so I moved the masq onto my desktop machine. When I moved to Illinois a few months ago (co-op job with International Teams, check it out at www.iteams.org) I revived the machine to handle the firewall and masquerading. It was capable of upgrading from potato to woody, but I got tired of the thrashing so I put the drive into my modern machine (again) and did the upgrade there and then moved it back. It's been running great and even serves as my secondary MX. (well, I half-killed it when I forgot to include load-limiting options in my exim configuration and the kernel started killing processes. I couldn't log in because sshd was dead; and when I went home even login was dead! It still managed the routing though :-)) | As far as availability and findability goes, RH has sendmail as the | only MTA. Debian has sendmail, exim, postfix, ssmtp, and I'm sure | there are others as well. The same goes for many other tools. When I | made the switch from RH to Debian I was amazed to find included on the | cd many little-known programs I had failed to compile on my RH system. | | I need one that's secure and gives you real control over it. I've been using | Sendmail. But I've been receiving mail from spammers that, according to the | message ID, are originating from my own box. I'm guessing that they're either | sending mail directly from their home system to my Sendmail program, using it as | the MTA, which they aren't supposed to be able to do (relaying denied is set), | or they've somehow hacked me and are originating spam mail from my computer. I | need an MTA that gives me more control over the mail in my system, including the | ability to have copies of all mail that originates in my system sent to me by | the MTA. Sendmail is wholly under your control -- I've heard that it's configuration language is Turing complete. For the same reason it's horrid to configure and would be a good enough reason to try linuxconf :-). Beware -- linuxconf doesn't properly configure sendmail on debian! Use exim instead, it's much easier to configure. | | I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. | | I recommend running spamassassin with your mail service. It won't | take kindly to low memory (it uses around 8-9MB on my machine) though | some people run it on a 486 with 32MB RAM. (I think those are | terminal machines with relatively low volumes of mail) You can have | 'spamd' running on a different machine than your MTA, though. | | I'll try it and see how it handles it. I don't think it'll be a problem. The | box I need to run it on only has 16 Meg RAM, but currently Sendmail is using 0% | of the processor and 2.05% of memory, while Named is using 0% of the processor | and 11.72% of memory. For a no-source-changes configuration see these docs : http://dman.ddts.net/~dman/config_docs/exim3_spamassassin.html The downside of that technique is each message is handled by exim twice. If you want to compile exim yourself, then this is a neat new method : http://marc.merlins.org/linux/exim/sa.html It requires exim 4 (which isn't yet packaged for debian because the maintainer didn't want to try and introduce a major incompatible change right before woody's release) and due to the newness of the local scan api requires recompilation of exim any time you change the local_scan. Marc has his own debian packages of exim4+sa on that site too. I'm currently using Marc's local_scan, which is really slick! | | (I'm assuming there are a few current or ex-Red Hat users here)? | | Yep. RH 7.0 pushed me over the edge (I only started with 5.2 which | didn't like my vid. card and then 6.1). | | I started with 5.2 also. Actually I tried Slackware first. That was a | nightmare. How'd I know they'd expect me to keep a copy
Re: Red Hat user shopping around
Glen Lee Edwards wrote: What are the main differences between Debian and Red Hat (I'm assuming there are a few current or ex-Red Hat users here)? isntallation 'looks' much different (i like it - simpler), config files are much easier to find in debian, apt is such a slick tool, and i find the debian site (IMHO) is SO much simpler to browse than redhat when you're looking for support/packages. How well does FVWM run on Debian systems? I currently build FVWM rpms for Red Hat. fvwm (at least for me) runs great. but then again, most of my systems have at least 32 mb of ram. fvwm, windowmaker, and a new charmer on the scene, fluxbox - which is based on blackbox. I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. X would be nice, but I usually use X forwarding on those boxes to another one that can handle the load (500 MHZ, 512 Meg RAM). shouldn't be a problem at all. as long as your servers aren't handling a million users a day or something. :) Any thoughts or suggestions you have will be appreciated. I need to run a Linux distribution that will work as both a server and a desk top environment. And I need one that will remain loyal to its customer base, including those with low resource PCs. granted i've only been 'playing' with linux for about 2 years now...it seems that debian has not only a loyal user base, you might even call it 'lethal'. hop on IRC and go to the debian channel on irc.openprojects.net. most debian peeps defend this nice distro tooth and nail...and they're definitely not afraid to speak their mind. :) but i find them to be serious and helpful...albeit a bit snotty. they're not getting paid tho so i don't complain. :) i think once you get in the drivers seat, you'll want to take it home. Regards, Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] good luck -jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, May 08, 2002 at 10:24:39PM -0500, Jamin W. Collins wrote: ( ... ) The main thing that struck me on the move are that some of the configuration files are automagically updated (modules.conf for example) and if you make changes to them directly you can end up losing those changes. I agree that things like update-modules and update-menus seem complicated at the beginning. But now I find them very useful and well-designed. Many changes are indeed done automagically (e. g. on installing a new package) but you can also make changes by hand if you know how. Regards, Joachim -- Joachim Fahnenmüller Lehrer für Mathematik und Physik Herder-Gymnasium Kattowitzer Straße 52 51065 Köln -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On 0, dman [EMAIL PROTECTED] wrote: On Wed, May 08, 2002 at 11:43:21PM -0700, Paul 'Baloo' Johnson wrote: | On Wed, 8 May 2002, Glen Lee Edwards wrote: | They recently dumped inet for xinet. Instead of having one configuration file | in /etc/inetd.conf, they now have individual files per service in | /etc/xinetd.d/. I'm sure that makes sense to somebody, but it makes configuring | it a real headache. | | That just hurts...why would someone implement something in such an | obviously painful manner? Have you ever tried to read RH init scripts? Have you ever tried to find an init script? It's actually not very dissimillar to debian... /etc/rc/init.d instead of /etc/init.d... ducking what='the inevitable stones'I think it makes more sense to put all the init stuff in a subdirectory.../ducking Tom -- Tom Cook Information Technology Services, The University of Adelaide Classifications of inanimate objects: Those that don't work, those that break down, and those that get lost. Get my GPG public key: https://pinky.its.adelaide.edu.au/~tkcook/tom.cook-at-adelaide.edu.au pgphVEVR8Dnot.pgp Description: PGP signature
Re: Red Hat user shopping around
On Thu, 9 May 2002, dman wrote: number is kinda part of the package name. The package name is as much as you specify, rather than having specific delimiters like dpkg. rpm also allows multiple packages with the same name (different version) installed, as long as no two files have the same name. It's a real PITA. Which to this day is still (accurately) speculated as being one of the reasons why I moved my school to Debian in '97. *Way* too easy to completely mismanage a RPM based system simply due to inconsistancies in package naming, numbering, and it's other counterintuitive perks... Someone has even ported apt to rpm. It has some problems though -- it's potato's apt (no preferences) and it mmaps the Packages file. I tried using it (within the last few months) on a machine with 96MB RAM. It dies with an out-of-memory error. Potato's apt on my 8MB clunker _works_ even though it gets a sound thrashing in the process. Good. New fodder in how Red Hat *can't* use our tools against us. 8:o) -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 9 May 2002, dman wrote: | That just hurts...why would someone implement something in such an | obviously painful manner? Have you ever tried to read RH init scripts? Have you ever tried to find an init script? Yes, I have, which is why I wonder why they made the same fscking mistake twice. -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Thu, 9 May 2002, dman wrote: debian! Use exim instead, it's much easier to configure. I'm going to have to strongly agree with that. It's mail simplicity and easier than walking your boss through OE by phone (my current measure for the most difficult anything should be). -- Baloo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Red Hat user shopping around
Hi, I've been a loyal Red Hat user for the last 4 or 5 years. Their recent distributions will no longer install on all my computers because they now require more than 16 Meg RAM. I have a few questions: The Debian web site says that Debian will install on 12 Meg RAM. Is that information current? What are the main differences between Debian and Red Hat (I'm assuming there are a few current or ex-Red Hat users here)? Does Debian support the old Sound Blaster Pro CDRoms (sbpcd module)? How well does FVWM run on Debian systems? I currently build FVWM rpms for Red Hat. I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. X would be nice, but I usually use X forwarding on those boxes to another one that can handle the load (500 MHZ, 512 Meg RAM). Any thoughts or suggestions you have will be appreciated. I need to run a Linux distribution that will work as both a server and a desk top environment. And I need one that will remain loyal to its customer base, including those with low resource PCs. Regards, Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, May 08, 2002 at 07:09:13PM -0500, Glen Lee Edwards wrote: | Hi, | | I've been a loyal Red Hat user for the last 4 or 5 years. Their recent | distributions will no longer install on all my computers because they now | require more than 16 Meg RAM. I have a few questions: | | The Debian web site says that Debian will install on 12 Meg RAM. Is that | information current? I don't know about *install*, but it certainly *runs* (and sometimes crawls :-)) on 8MB. (I couldn't get my 8MB clunker to boot from a cd and didn't have any floppies handy so I stuffed the hd in a bigger machine for the install. Be aware that with only 8MB RAM package updates and many other operations cause lots of thrashing. 16MB would be much better :-)). | What are the main differences between Debian and Red Hat Policy is the first difference. Availability and findability and quality of packages is next. I recently had to install RH 7.2 on a machine, and I saw first-hand how badly RH is organized. Config files are strewn about the FS, but on debian they are always in /etc/pkgname. The dependencies in debian packages are much saner too -- for example try installing python2 on a headless RH box *without* also installing the X server and X font server. As far as availability and findability goes, RH has sendmail as the only MTA. Debian has sendmail, exim, postfix, ssmtp, and I'm sure there are others as well. The same goes for many other tools. When I made the switch from RH to Debian I was amazed to find included on the cd many little-known programs I had failed to compile on my RH system. | (I'm assuming there are a few current or ex-Red Hat users here)? Yep. RH 7.0 pushed me over the edge (I only started with 5.2 which didn't like my vid. card and then 6.1). | Does Debian support the old Sound Blaster Pro CDRoms (sbpcd module)? It's in the kernel source and image packages. I presume it works :-). (that's a kernel thing, really, and all distros should be the same wrt it) | How well does FVWM run on Debian systems? I currently build FVWM | rpms for Red Hat. I use sawfish but I have fvwm installed just in case something goes wack with sawfish. It runs, but I can't speak for how well because I don't usually use it. | I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. I recommend running spamassassin with your mail service. It won't take kindly to low memory (it uses around 8-9MB on my machine) though some people run it on a 486 with 32MB RAM. (I think those are terminal machines with relatively low volumes of mail) You can have 'spamd' running on a different machine than your MTA, though. | X would be nice, but I usually use X forwarding on those boxes to | another one that can handle the load (500 MHZ, 512 Meg RAM). | | Any thoughts or suggestions you have will be appreciated. I need to | run a Linux distribution that will work as both a server and a desk | top environment. Debian is up to the job, and you won't regret the conversion. Just take it one machine at a time, stick with it and ask this list even stupid questions. You'll get the hang of debian's organization and how to use the package management tools and then you'll enjoy it. | And I need one that will remain loyal to its customer base, | including those with low resource PCs. Debian is it's customer base. Since we are the ones who build the system, we can determine what goes into it and what it requires. Oh, yeah, you'll never need to re-install either. Some people have had 'bo' (one of the earlier releases) machines that haven't seen an installation cd since those days. The upgrade process is quite smooth in comparision to other OSes. -D -- How to shoot yourself in the foot with Java: You find that Microsoft and Sun have released incompatible class libraries both implementing Gun objects. You then find that although there are plenty of feet objects implemented in the past in many other languages, you cannot get access to one. But seeing as Java is so cool, you don't care and go around shooting anything else you can find. (written by Mark Hammond) GnuPG key : http://dman.ddts.net/~dman/public_key.gpg pgpaaD0u9v8EM.pgp Description: PGP signature
Re: Red Hat user shopping around
Glen, I'm fast becoming an ex RedHat user. RH releases often with lots of bugs. Debian releases aren't frequent, but the testing version is pretty current with other distributions, and at least as good. Debian may be a little harder to configure, but configuration files are not hidden and in general make a lot of sense. Upgrading Debian is easier than any other distribution. I have no ideas about where RAM size enters the picture, or how that might change in the future, but my guess is that Debian will be running on low end hardware longer than the other distributions. -- Sincerely, David Smead http://www.amplepower.com. On Wed, 8 May 2002, Glen Lee Edwards wrote: Hi, I've been a loyal Red Hat user for the last 4 or 5 years. Their recent distributions will no longer install on all my computers because they now require more than 16 Meg RAM. I have a few questions: The Debian web site says that Debian will install on 12 Meg RAM. Is that information current? What are the main differences between Debian and Red Hat (I'm assuming there are a few current or ex-Red Hat users here)? Does Debian support the old Sound Blaster Pro CDRoms (sbpcd module)? How well does FVWM run on Debian systems? I currently build FVWM rpms for Red Hat. I need to run servers on two 16 Meg RAM boxes - DNS and mail mainly. X would be nice, but I usually use X forwarding on those boxes to another one that can handle the load (500 MHZ, 512 Meg RAM). Any thoughts or suggestions you have will be appreciated. I need to run a Linux distribution that will work as both a server and a desk top environment. And I need one that will remain loyal to its customer base, including those with low resource PCs. Regards, Glen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
Lo, on Wednesday, May 8, Glen Lee Edwards did write: Hi, I've been a loyal Red Hat user for the last 4 or 5 years. Their recent distributions will no longer install on all my computers because they now require more than 16 Meg RAM. I have a few questions: SNIP How well does FVWM run on Debian systems? I currently build FVWM rpms for Red Hat. Quite well; it's my standard WM. It's available as a normal Debian package, as well, so you don't need to build it yourself. Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Red Hat user shopping around
On Wed, 8 May 2002 19:09:13 -0500 Glen Lee Edwards [EMAIL PROTECTED] wrote: The Debian web site says that Debian will install on 12 Meg RAM. Is that information current? I just finished installing 6 systems (2 P100s and 4 P166s) here. Most had 32 megs of memory, however two did have 16 megs of memory. On these two systems I was able to do an install of Woody, it was however very slow due to the swapping. Swap usage was at about 12-14 megs most of the time. What are the main differences between Debian and Red Hat (I'm assuming there are a few current or ex-Red Hat users here)? The main thing that struck me on the move are that some of the configuration files are automagically updated (modules.conf for example) and if you make changes to them directly you can end up losing those changes. -- Jamin W. Collins -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
