>So eastern culture has going to right as "going >back" and to the left as forward? Hunh? Where >does that come from?
When scanning a dialog, it is fairly well established that the first two areas of attention for an LTR (left to right) user is the upper-left corner, followed by the lower-right. Likewise, an RTL user would tend towards upper-right, followed by lower-left.
There is widget reodering in Gnome 2 to account for this. Basically a user in an RTL locale is presented with a mirrored version of the dialog, so ordering decisions have the same benefit (or detiment) for everyone.
The choice of using implementing Mac style button order was partially to take advantage of this principle; i.e. the "first choice" option is given the most noticable location.
An added benefit of this arrangement is that the first choice option is in a predictable location, whereas with Windows style layout, the location is dependent on the number of buttons on the dialog. This is a *big* win in my opinion.
>Yes. All this should be done when you install >telnetd - it's just a "preconfigure" script.
The Red Hat policy is not to have packages require user interaction, and I happen to agree with this. When you manage more than a single machine, being able to install packages unattended is a big deal.
Besides, why the hell would I want every single network related package to configure firewalling, access rules and attempt to download packages? It's much easier to do that all in one step.
>My point (that you haven't addressed yet) is that >there is no need to actually have telnetd >installed without it being activated. It doesn't >to anything. At all. Nothing. It is sitting >there, taking up space. This is why configuring >and installing should be done in one step, not >two separate steps.
If you don't want it installed... don't choose to install it. Simple, eh?
You're also ignoring the possibility that I might have a daemon that I enable only for testing purposes at various times.
>Um, training people who run operating systems is >one of the basic functions of the operating >system creator. You want to make people more >fluent in using the operating system - i.e., the >computer.
No, providing reasonable default behaviour and documentation is a basic function of the operating system vendor.
There is no way that a vendor can force a user to learn anything (especially something as tedious as good administration policy).
>By the logic you're using, it's not Red Hat's >responsibility to teach (remind) people to >download patches, etc.
Nope. They provide an automated process for doing that, since you can't trust that the average user will pay attention to any warnings you give them on the subject. They also firewall off any incoming connections by default so that, unless a user decides to change things, they're not vulnerable to remote exploits in the first place.
>If something isn't safe, don't have it even >available at the default install.
It's not a simple black/white issue. If a given piece of software is inherently unsafe, it shouldn't be available at all.
>The default install should be to get the system >up and running, not to install every piece of >software you need.
The default install *is* just that. There is an option for more, which is a matter of convienence for those people who know what they need ahead of time.
There is very little to be gained from forcing some software to be installed after the installation.
>This is good debugging/testing practice - start >minimal, and add things from there. That way you >know when things break.
The only time one package should have the chance of breaking another is if its a dependency. In which case it needs to be installed anyways.
Even if you did conjecture that unrelated packages could somehow break one another, you're ignoring the fact that the market that Red Hat is targeting is businesses, who will be QAing a full platform including all the software they need.
>So when people say "Install everything", okay, >install everything that's safe.
That wouldn't be everything, now would it? There's already an option for installing predefined subsets of packages.
>If you're going to deactivate something don't >install it. Heck, that way they can't >"accidentally" activate it without specifically >knowing what they're doing.
It's pretty difficult to "accidently" activate a service.
As I said, as a matter of policy it makes sense to allow an administrator to make sure a system is configured to his liking BEFORE a service is activated, and I don't think its feasible (or desirable) for install scripts to try and divine what tasks might be performed for configuration.
>I am not saying they should leave services on. >What I am saying is if you are going to turn >them off, don't install them. There's no point to >it.
Sure there is. Our standard builds at work have a specified subset of services which get installed. Before they are activated, they need configuration files rsynced to them. Once that's done, they can be enabled.
>If you're going to force users to configure >telnet for it to be useful, why not just tack on >the added cost of installing it as well?
They already have the added cost of installing it... in the installer, of all places.:)
Having it done post install requires one of several things:
a) Red Hat runs a free service similar to apt.
This would cost them money and give them
little to no real benefit.
b) The user would have to run an server that
provides similar functionality. Not really
feasible for a home user.
c) The user would have to copy every RPM to
his hard disk on the off chance that he might
want it later. This negates the "saves them
disk space" argument.
d) The user has to go through putting in at
least one, and up to three CDs during a post
install setup. This is a hassle and would
inevitably lead to the question "Why does
Red Hat make me do this? Mandrake/SuSE/etc
don't! Red Hat sUxx0rs d00d!"
>This way it saves them the disk space, and the >hassle of not understanding why telnet doesn't >work.
If a user doesn't know how to how to configure running services, they shouldn't be running them.
And for a user who wants to system to learn on/test on/play with, there may be good reasons to have all the software readily available. Afterall, at current prices, a full install costs about $3 worth of hard drive space.
>if the admin is installing it, obviously he wants >to configure it, right? Do both in the same step.
Configuring for a new service might include modifying tcp wrapper configurations, firewall rules, etc as well as configuring the service. Or maybe you'd like a chance to patch the server before you start enabling services.
It's really NOT that big a deal to type "chkconfig on" to enable it when you've got the system ready. I swear.
>"It is far from uncommon for newbies to install >software without knowing what it is" - this isn't >intelligent behavior. Retrain them.
Why should it be Red Hat's responsibility to train everyone who buys or even downloads their distribution? And how do you propose they do it?
Besides, how many people started calling them "Root Hat" (oh, that is just so witty I can't stand it) when they left more services on by default?
>Really, what would happen if Red Hat had a >package management system as easy as apt, and >didn't ship telnetd? Who'd complain?
I personally find the apt v. rpm argument silly, so I'm not going to comment on that.
What is wrong with the current setup (not installing telnet unless you specifically ask for a server install or choose it explicitely)? What would be the point of changing that?
>That may be true, but to get more you have to rpm >-i stuff, oh no, it needs these dependencies, >install that, bla bla. To get a good desktop >(Gnome or KDE) at install time you need to install >tons of junk.
That's going to be true regardless of what distribution you install Gnome or KDE on. There are very few false dependencies in Red Hat, and they will remove them if you find them (for example, I noticed an unnecessary dependency in etherereal on 7.2, filed a bug report, and it was fixed in the next package release).
>I tried installing RedHat on a 800 meg hard >drive. Couldn't get a decent desktop. It was a >lot of hassle selecting the packages too, >selecting general things, then unchecking junk I >don't want, etc. Much easier in Debian, just >apt-get what you want.
If you're doing this during the install, select the packages you want, and let it resolve the dependencies for you. So far as I know (I haven't installed it anywhere yet) this capability is in RPM itself now.
Other RPM frontends (Red Carpet, urpmi, apt-rpm, etc) have implemented this for quite a while now.
>Yeah, but hard drive space is a big issue.
The disk space required by a particular package is barely affected by distribution as well.
>And it's true, you can disable init scripts you >don't want starting up (I do that a little with >Debian,) but why have em there in the first >place? What desktop user needs a NFS server, >gimme a break?
The NFS server is part of the "NFS File Server" package group, which isn't selected by default. In fact, in the default and workstation installs NO servers are installed.
>It just took FOREVER for RedHat to start up on an >old computer I installed it on once.
Which version of Red Hat, and what software is installed? Unless you're starting a lot of daemons (which it won't by default) or have something misconfigured, it doesn't take appreciatively longer than any other distribution.
>(Side note, who's idea was it to run depmod > -a on every start up anyway?)
It runs depmod -A, not depmod -a. This uses timestamps to determine if it should actually update anything, so typically runs in less than a second.
Matt
Re:Why do i care?
on
Linux 3.0
·
· Score: 3, Informative
>Absolutly. If what you have now works, then by >all means, don't upgrade......with a caveat. As >with any OS, after 3.0 or 2.6 whatever it's going >to be called comes out, then bug fixes may not be >done for that much longer to the 2.4 series.
You'd have to worry more about new features and hardware support getting in than bug fixes. The 2.0 kernel is still being maintained and its over six years old.
>After a while, you will probably want to upgrade >anyway especially if your company pays for >support from Red Hat or whoever.
If you're paying for support from a company, you'd probably be best off running whatever kernel that's current for the distribution, unless you have some specific reason to deviate. And with the lengthened life cycle of products like Advanced Server, the likelyhood of having to move to a new kernel for support reasons is even lower.
>If you install telnet server, it disables it by >default. Same with ftp - ftpd is currently >installed on the one Red Hat machine I deal with, >and it's disabled.
There's a couple reasons I can think of that make this Correct Behaviour - a) daemons should remain disabled until such time the admin has configured them, and b) it is far from uncommon for newbies to install software without knowing what it is (e.g. "install everything").
And of course if Red Hat didn't do this, you'd have the hordes of Red Hat haters screaming "Root Hat"... Oh wait, they do that anyways, despite a default configuration leaving services off and firewalling off any incoming connections.
>Red Hat ships with bunches of servers disabled - >why have them installed if they're disabled?
The only daemons installed as part of base are apmd, atd, crond, sendmail, and syslogd. These are all system level daemons that required on a normal distribution. (Note - Sendmail is configured to only accept local connections by default).
>I personally like the install. Unlike some >distros (cough..Red Hat...cough) it totally lets >me in control.
What in particular do you think you can't control in a Red Hat install? If you don't like what's available in the installer you can even switch over to the command prompt and do things manually.
>I decide exactly how I partition my drive, which >partitions I format, and which I mount and how.
You can do that all in Red Hat as well.
>And then, it install ONLY what I tell it to >install, no megs and megs of junk you never use >(again, Red Hat is especially nasty in this area.)
The base package list for Red Hat is actually pretty lean. About 150 packages, totalling a bit over 100MB. There's some stuff which isn't strictly necessary (tcsh, gpm, slocate) and some stuff which isn't necessary for every system (raidtools, hotplug, dhcpd).
I don't really consider it a drawback to include some low level utiltiies that might be useful on some systems or later on in a systems life. And honestly, the savings of a couple megs of disk space isn't worth the risk of relying on users to actually know if they need particular tools and the hassle on the users part of having to go through the list.
Even better, if it bugs you THAT much, you can unpack the CDs, remove the packages you don't want in the install from the RedHat/base/comps file, and use that as your install server. We do that where I work because we have our own packages that we want as part of the base install and also wanted to pull out a couple things (gpm is useless on racks of headless servers, for example).
>And it's great for older computers, unlike that >other distro!!!
Resource requirements have very little to do with your distribution. It's the software that you're going to be running that is the issue.
>And Debian polishes packages up until their are >ultra-stable and then moves them from "testing" to >"stable".
Except of course when a package (php4) sits broken in testing for months, with multiple bug reports filed against it, and they go ahead and move it to "stable" anyways, with a note in the readme "Sessions do NOT work on hppa, m68k, mips, powerpc, sparc, s390. Sorry about that.:(". Note that this is a regression of functionality as compared to 2.2, which worked fine.
Or when post-installation scripts fail for certain packages (squirrellmail) on a fresh install. Which doesn't really matter that much since there's been a known exploit for the package for a month, but a new release hasn't been packaged yet. (And in my case it won't work anyways due to the aforementioned php4 bug).
Or when binaries (cftp) segfault on startup.
I'm not saying Debian doesn't do an admirable job considering the bulk of software they offer. However I have actually run into more issues with Debian than I have with Red Hat, and in most cases I have seen quicker response from Red Hat in terms of fixing things that are broken.
Keep in mind that this my experiences are not necessarily typical, and I understand that Debian is working on volunteer effort, and supports a much broader range of hardware and packages.
I am, afterall, still using Debian on several machines, but my comfort level is not high enough to put it into serious production.
>Ever tried to make a decent Linux boot floppy? >It's hard, and would be easier if the kernel were >more modular. Fortunately, it is moving in that >direction.
Yep. Pretty easy actually. Snag the kernel, uClibc, busybox and tiny login. Compile the kernel modular, compile everything else against uClibc.
You could install a modular Linux kernel since at least 1993. The older kernels are actually easier to get working since the core is signifigantly smaller (the kernel and modules only take up a few hundred K).
The biggest headache is my experience is getting the userspace stuff small enough to fit in the remaining space. Since you can do compressed initrds with Linux, you can create a 2-2.5MB filesystem and have it fit, but that quickly becomes tight when glibc + pals take up 1.25MB or so.
Traditionally a lot of single disk systems used libc5, which was signifigantly lighter, but nowadays uClibc provides a very nice solution, and can be compiled down to about 284k (including libc, libm, libcrypt, libutil and ldlinux).
Busybox, compiled shared, only takes up 401k, and includes four shells (ash, hush, lash, msh), an editor (vi), networking tools (traceroute, ping, nc, wget, ifconfig), archive tools (gzip, cpio, tar, dpkg_deb, uudecode, rpm2cpio, dos2unix), and most other common utilities. Don't need something (like three extra shells), comment it out, and you can easily get this down to 200-250k.
Throw in tinylogin for another 38k or so for authentication and user tools (add/deluser, add/delgroup, getty, login, password, su, sulogin, vlock) and you've got a pretty complete Unix environment for well under a megabyte.
>The MINIX file system is still available, and >makes a very good choice for floopies: full file >permissions and very little space wasted.
It also is limited to a maximum size of 64MB and only supports filenames up to 14 characters.
>ext2 takes up half the floppy and reiserfs >doesn't even fit on it.
I'll agree with you on reiserfs, since it imposes a minimum filesystem size, but bollocks to your ext2 claim.
As a test, I created two 1MB filesystem images, here's the output of df with them empty:
>MINIX may be dead as a production system, but its >legacy lives on, and it's still good for OS >courses, which is what it was made for.
I agree with this sentiment, with the possible change of saying MINIX was never really alive as a production system. It was never meant to be anything other than an educational tool.
>Well, if you aren't, then the GPL isn't binding >either, since you aren't intrinsically "signing" >anything when you use GPL'd code.
As has been pointed out numerous times before, there is nothing preventing you from *using* GPL code without agreeing to the GPL.
The license is for *distribution* not use. As you have no right to distribute copyrighted works otherwise, you are bound to seek licensing before doing so, in which case the authors provide the GPL.
>I'd love it see it move into more major >acceptance, but the problem is that sendmail is >the default for many distros. RedHat doesn't even >have a qmail RPM to install.
You won't see that happen unless Bernstein changes the license. Mandrake, Red Hat, Debian, and the OpenBSD maintainers have all stated explicitely that they cannot ship qmail because of the license.
The issue is even more prevalent now that distributions are striving for LSB compliance, as every piece of Bernstein's software flouts the FHS, and even traditional Unix conventions (BINARIES DO NOT BELONG IN VAR).
Even if they chose to ignore that and added qmail in a Bernstein approved way, they'd be taking a huge step backwards in functionality, since the license also doesn't approve of shipping modified source or binaries, and qmail has extremely limited standards support. No more out of the box support for SSL/TLS connections or secure authentication. They'd have to instruct their customers to download the source, patch it themselves, and recompile if they wanted that.
Qmail's lack of adoption lies solely on Bernstein's shoulders, noone else's.
>You must be use to MS who has to do contsant >releases for bug fixes and more money. See, >sometimes software can actually become stable.
Actually, no, the last time I ran an MS product at home for any length of time was DOS 5.0. I used NT 4.0 at one of my jobs for a period, but that was only to run a 3270 emulator for accessing the mainframe.
For the record, I *do* use qmail in a production environment, for thousands of domains. It requires a lot of patching to make it a usable product.
>Would you rather use a stable mail server that has >really no known bugs in like 3-4yrs, or one that >is contantly updated and has had a trojan horse?
Actually, I'd rather use a mail server that implements at least SOME of the standards that have come out in the past seven or eight years.
Stable doesn't mean jack shit if the software doesn't do what you need it to.
>Packages like djbdns and qmail make service >configuration trivial, as it should be.
It really depends on what you're doing with them.
First off, installing either usually involves compiling from source, due to the restrictive licensing.
The software also isn't built to start under native Unix facilities like init or xinetd, so you either need to deal with installing and configuring ucspi and tcpserver, or hacking the source.
The lack of standards support in qmail also ends up requiring patching in a lot of common configurations, further complicating things. And honestly, configuring qmail isn't exactly a dream - permissions issues are easy to miss, a lot of configuration data requires compilation to a binary format, and configuration data is spread across a fairly large number of files and is hardly in the most intuitive of formats, e.g.:
+foo.com-:foo.com:500:500:/domains/foo.com:-::
Djbdns can either be very easy (simple case) or a pain in the ass.
For starters, there are a lot of standards it doesn't bother starting (IXFR, NOTIFY, TSIG, DNSSEC, etc). So interoperability with other servers is at best suboptimal.
Even if you're going to run a pure djbdns environment, there's no built in facility to transfer zone data, so you also need to either install and configure the axfr-dns program or install and configure rsync and ssh or some other method of copying the zone data to the remote server. In either case the propogation isn't automatic, so you'll probably want to write your own scripts to automate this.
Doing split-dns is a lot less intuitive than in BIND, in my opinion. You can add location tags to entries in the database, but the format only allows one per entry, so if you have different location definitions, you need to add the data multiple times (or store your data in a different format and process it into what tinydns-data expects). And those location tags are limited to only two characters, which prevents any meaningful name.
>Last time I checked you need to devote some >serious time and brain power to properly setting >up sendmail.
When did you last check? The mid-ninties?
Configuring Sendmail since the switch to m4 files is *trivial* for most setups.
What's even better is that, since Sendmail is under a permissive license, virtually all versions of Unix offer it by default, pre-installed and with a basic configuration.
For example, if you're doing a single domain setup the extent of your configuration on Red Hat would be adding your domain name to the/etc/mail/local-host-names, and commenting out "DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')".
Want mail sent to phil@mydomain.net to go to bob instead?? Simple, add "phil@mydomain.net bob" to/etc/mail/virtuserstable. Want to send all the mail in the domain? Change it to "@mydomain.net". Want to create dummy accounts named mydomain-USERNAME? Make the line "@mydomain.net mydomain-%1".
And on Red Hat you don't even have to deal with compiling the database files, since the init scripts do it for you. Just run "/sbin/service sendmail restart".
>Well, If you don't mind using a proprietary >program written by a person with the same level of >maturity and social skills as a mentally retarded >5 year-old.
Don't forget "that hasn't had a new release in over four years and neglects to implement a lot of basic standards like authentication or encryption".
>KDE and Gnome... they need stop all development >and focus on getting a 50% speed increase. If they >have to cut and slash to do it, then do it. >Mozilla needs to do this as well as Open Office.
Have you compared Gnome 2.0 against Gnome 1.4? The memory footprint has dropped, there have been speed increases across the board (Nautilus in particular shows massive improvement), and responsiveness is markedly better with double buffering.
>Quite frankly, it's quite powerful and its default >install is kinda simple to use except (except!) >for that stupid map command to build virtual >users, access tables and the likes.
This doesn't have to be all that difficult either. Red Hat, for example, has the init script rebuild those files automatically for you when you run the init script. Just add the entries you need, and type:/sbin/service sendmail reload
> And what gives *you* more credibility than > Mosfet? He contributes things to Open Source, do > you?
Well, he didn't make stupid statements like:
The other problem is switching the default
applications for things like the web browser and
email client from their KDE implementations to
Gnome apps.
The three applications they changed defaults to are Mozilla (not a Gnome app), OpenOffice (also not a Gnome app), and Evolution (okay, so one Gnome app).
He also didn't include a jab at Red Hat's filesystem layout when they are fully LSB and FHS compliant.
>I've been over this, and over this, and over this >again! 128Kbps CBR *IS* [r3mix.net] *CRAPPY* >[r3mix.net]! You'd better believe that I'm not >going to be downloading much.
By crappy I was refering to people using buggy encoders, rippers without proper error correction, etc. I won't argue that the files from emusic are exceptionally high fidelity, but they are of consistent good quality for what they are.
Most of the music I *really* like that I download, I fully intend to pick up on CD, and encode myself, either to high quality vorbis, or perhaps to flac, once I have a large fileserver set up.
But on the other hand, for albums that I merely like, I'd be hard pressed to pay $15 for something I already got for about fifty cents.
Slashdot Mirror
400Mb/sec vs 150MB/sec
Pay attention to case, it does matter. As for what's in development, call me when its actually available.
Matt
>So eastern culture has going to right as "going
>back" and to the left as forward? Hunh? Where
>does that come from?
When scanning a dialog, it is fairly well established that the first two areas of attention for an LTR (left to right) user is the upper-left corner, followed by the lower-right. Likewise, an RTL user would tend towards upper-right, followed by lower-left.
There is widget reodering in Gnome 2 to account for this. Basically a user in an RTL locale is presented with a mirrored version of the dialog, so ordering decisions have the same benefit (or detiment) for everyone.
The choice of using implementing Mac style button order was partially to take advantage of this principle; i.e. the "first choice" option is given the most noticable location.
An added benefit of this arrangement is that the first choice option is in a predictable location, whereas with Windows style layout, the location is dependent on the number of buttons on the dialog. This is a *big* win in my opinion.
Matt
>Yes. All this should be done when you install
:)
>telnetd - it's just a "preconfigure" script.
The Red Hat policy is not to have packages require user interaction, and I happen to agree with this.
When you manage more than a single machine, being able to install packages unattended is a big deal.
Besides, why the hell would I want every single network related package to configure firewalling, access rules and attempt to download packages? It's much easier to do that all in one step.
>My point (that you haven't addressed yet) is that
>there is no need to actually have telnetd
>installed without it being activated. It doesn't
>to anything. At all. Nothing. It is sitting >there, taking up space. This is why configuring
>and installing should be done in one step, not
>two separate steps.
If you don't want it installed... don't choose to install it. Simple, eh?
You're also ignoring the possibility that I might have a daemon that I enable only for testing purposes at various times.
>Um, training people who run operating systems is
>one of the basic functions of the operating
>system creator. You want to make people more
>fluent in using the operating system - i.e., the
>computer.
No, providing reasonable default behaviour and documentation is a basic function of the operating system vendor.
There is no way that a vendor can force a user to learn anything (especially something as tedious as good administration policy).
>By the logic you're using, it's not Red Hat's
>responsibility to teach (remind) people to
>download patches, etc.
Nope. They provide an automated process for doing that, since you can't trust that the average user will pay attention to any warnings you give them on the subject. They also firewall off any incoming connections by default so that, unless a user decides to change things, they're not vulnerable to remote exploits in the first place.
>If something isn't safe, don't have it even
>available at the default install.
It's not a simple black/white issue. If a given piece of software is inherently unsafe, it shouldn't be available at all.
>The default install should be to get the system
>up and running, not to install every piece of
>software you need.
The default install *is* just that. There is an option for more, which is a matter of convienence for those people who know what they need ahead of time.
There is very little to be gained from forcing some software to be installed after the installation.
>This is good debugging/testing practice - start
>minimal, and add things from there. That way you
>know when things break.
The only time one package should have the chance of breaking another is if its a dependency. In which case it needs to be installed anyways.
Even if you did conjecture that unrelated packages could somehow break one another, you're ignoring the fact that the market that Red Hat is targeting is businesses, who will be QAing a full platform including all the software they need.
>So when people say "Install everything", okay, >install everything that's safe.
That wouldn't be everything, now would it? There's already an option for installing predefined subsets of packages.
>If you're going to deactivate something don't
>install it. Heck, that way they can't
>"accidentally" activate it without specifically
>knowing what they're doing.
It's pretty difficult to "accidently" activate a service.
As I said, as a matter of policy it makes sense to allow an administrator to make sure a system is configured to his liking BEFORE a service is activated, and I don't think its feasible (or desirable) for install scripts to try and divine what tasks might be performed for configuration.
>I am not saying they should leave services on.
>What I am saying is if you are going to turn
>them off, don't install them. There's no point to
>it.
Sure there is. Our standard builds at work have a specified subset of services which get installed.
Before they are activated, they need configuration files rsynced to them. Once that's done, they can be enabled.
>If you're going to force users to configure
>telnet for it to be useful, why not just tack on
>the added cost of installing it as well?
They already have the added cost of installing it... in the installer, of all places.
Having it done post install requires one of several things:
a) Red Hat runs a free service similar to apt.
This would cost them money and give them
little to no real benefit.
b) The user would have to run an server that
provides similar functionality. Not really
feasible for a home user.
c) The user would have to copy every RPM to
his hard disk on the off chance that he might
want it later. This negates the "saves them
disk space" argument.
d) The user has to go through putting in at
least one, and up to three CDs during a post
install setup. This is a hassle and would
inevitably lead to the question "Why does
Red Hat make me do this? Mandrake/SuSE/etc
don't! Red Hat sUxx0rs d00d!"
>This way it saves them the disk space, and the
>hassle of not understanding why telnet doesn't
>work.
If a user doesn't know how to how to configure running services, they shouldn't be running them.
And for a user who wants to system to learn on/test on/play with, there may be good reasons to have all the software readily available. Afterall, at current prices, a full install costs about $3 worth of hard drive space.
Matt
>if the admin is installing it, obviously he wants
>to configure it, right? Do both in the same step.
Configuring for a new service might include modifying tcp wrapper configurations, firewall rules, etc as well as configuring the service. Or maybe you'd like a chance to patch the server before you start enabling services.
It's really NOT that big a deal to type "chkconfig on" to enable it when you've got the system ready. I swear.
>"It is far from uncommon for newbies to install
>software without knowing what it is" - this isn't
>intelligent behavior. Retrain them.
Why should it be Red Hat's responsibility to train everyone who buys or even downloads their distribution? And how do you propose they do it?
Besides, how many people started calling them "Root Hat" (oh, that is just so witty I can't stand it) when they left more services on by default?
>Really, what would happen if Red Hat had a
>package management system as easy as apt, and
>didn't ship telnetd? Who'd complain?
I personally find the apt v. rpm argument silly, so I'm not going to comment on that.
What is wrong with the current setup (not installing telnet unless you specifically ask for a server install or choose it explicitely)? What would be the point of changing that?
Matt
>That may be true, but to get more you have to rpm
>-i stuff, oh no, it needs these dependencies,
>install that, bla bla. To get a good desktop
>(Gnome or KDE) at install time you need to install
>tons of junk.
That's going to be true regardless of what distribution you install Gnome or KDE on. There are very few false dependencies in Red Hat, and they will remove them if you find them (for example, I noticed an unnecessary dependency in etherereal on 7.2, filed a bug report, and it was fixed in the next package release).
>I tried installing RedHat on a 800 meg hard
>drive. Couldn't get a decent desktop. It was a
>lot of hassle selecting the packages too,
>selecting general things, then unchecking junk I
>don't want, etc. Much easier in Debian, just
>apt-get what you want.
If you're doing this during the install, select the packages you want, and let it resolve the dependencies for you. So far as I know (I haven't installed it anywhere yet) this capability is in RPM itself now.
Other RPM frontends (Red Carpet, urpmi, apt-rpm, etc) have implemented this for quite a while now.
>Yeah, but hard drive space is a big issue.
The disk space required by a particular package is barely affected by distribution as well.
>And it's true, you can disable init scripts you
>don't want starting up (I do that a little with
>Debian,) but why have em there in the first
>place? What desktop user needs a NFS server,
>gimme a break?
The NFS server is part of the "NFS File Server" package group, which isn't selected by default. In fact, in the default and workstation installs NO servers are installed.
>It just took FOREVER for RedHat to start up on an
>old computer I installed it on once.
Which version of Red Hat, and what software is installed? Unless you're starting a lot of daemons (which it won't by default) or have something misconfigured, it doesn't take appreciatively longer than any other distribution.
>(Side note, who's idea was it to run depmod
> -a on every start up anyway?)
It runs depmod -A, not depmod -a. This uses timestamps to determine if it should actually update anything, so typically runs in less than a second.
Matt
>Absolutly. If what you have now works, then by >all means, don't upgrade......with a caveat. As
>with any OS, after 3.0 or 2.6 whatever it's going
>to be called comes out, then bug fixes may not be
>done for that much longer to the 2.4 series.
You'd have to worry more about new features and hardware support getting in than bug fixes. The 2.0 kernel is still being maintained and its over six years old.
>After a while, you will probably want to upgrade
>anyway especially if your company pays for >support from Red Hat or whoever.
If you're paying for support from a company, you'd probably be best off running whatever kernel that's current for the distribution, unless you have some specific reason to deviate. And with the lengthened life cycle of products like Advanced Server, the likelyhood of having to move to a new kernel for support reasons is even lower.
Matt
>If you install telnet server, it disables it by
>default. Same with ftp - ftpd is currently
>installed on the one Red Hat machine I deal with,
>and it's disabled.
There's a couple reasons I can think of that make this Correct Behaviour - a) daemons should remain disabled until such time the admin has configured them, and b) it is far from uncommon for newbies to install software without knowing what it is (e.g. "install everything").
And of course if Red Hat didn't do this, you'd have the hordes of Red Hat haters screaming "Root Hat"... Oh wait, they do that anyways, despite a default configuration leaving services off and firewalling off any incoming connections.
Matt
>Red Hat ships with bunches of servers disabled -
>why have them installed if they're disabled?
The only daemons installed as part of base are apmd, atd, crond, sendmail, and syslogd. These are all system level daemons that required on a normal distribution. (Note - Sendmail is configured to only accept local connections by default).
Matt
>I personally like the install. Unlike some
>distros (cough..Red Hat...cough) it totally lets
>me in control.
What in particular do you think you can't control in a Red Hat install? If you don't like what's available in the installer you can even switch over to the command prompt and do things manually.
>I decide exactly how I partition my drive, which
>partitions I format, and which I mount and how.
You can do that all in Red Hat as well.
>And then, it install ONLY what I tell it to
>install, no megs and megs of junk you never use
>(again, Red Hat is especially nasty in this area.)
The base package list for Red Hat is actually pretty lean. About 150 packages, totalling a bit over 100MB. There's some stuff which isn't strictly necessary (tcsh, gpm, slocate) and some stuff which isn't necessary for every system (raidtools, hotplug, dhcpd).
I don't really consider it a drawback to include some low level utiltiies that might be useful on some systems or later on in a systems life. And honestly, the savings of a couple megs of disk space isn't worth the risk of relying on users to actually know if they need particular tools and the hassle on the users part of having to go through the list.
Even better, if it bugs you THAT much, you can unpack the CDs, remove the packages you don't want in the install from the RedHat/base/comps file, and use that as your install server. We do that where I work because we have our own packages that we want as part of the base install and also wanted to pull out a couple things (gpm is useless on racks of headless servers, for example).
>And it's great for older computers, unlike that
>other distro!!!
Resource requirements have very little to do with your distribution. It's the software that you're going to be running that is the issue.
Matt
>And Debian polishes packages up until their are
:(". Note that this is a regression of functionality as compared to 2.2, which worked fine.
>ultra-stable and then moves them from "testing" to
>"stable".
Except of course when a package (php4) sits broken in testing for months, with multiple bug reports filed against it, and they go ahead and move it to "stable" anyways, with a note in the readme "Sessions do NOT work on hppa, m68k, mips, powerpc, sparc, s390. Sorry about that.
Or when post-installation scripts fail for certain packages (squirrellmail) on a fresh install. Which doesn't really matter that much since there's been a known exploit for the package for a month, but a new release hasn't been packaged yet. (And in my case it won't work anyways due to the aforementioned php4 bug).
Or when binaries (cftp) segfault on startup.
I'm not saying Debian doesn't do an admirable job considering the bulk of software they offer. However I have actually run into more issues with Debian than I have with Red Hat, and in most cases I have seen quicker response from Red Hat in terms of fixing things that are broken.
Keep in mind that this my experiences are not necessarily typical, and I understand that Debian is working on volunteer effort, and supports a much broader range of hardware and packages.
I am, afterall, still using Debian on several machines, but my comfort level is not high enough to put it into serious production.
Matt
>Ever tried to make a decent Linux boot floppy?
/ext2.img 1003 13 939 2% /mnt/ext2
/minix.img 1009 1 1008 1% /mnt/minix
/ext2.img 1003 944 8 100% /mnt/ext2
/minix.img 1009 1005 4 100% /mnt/minix
>It's hard, and would be easier if the kernel were
>more modular. Fortunately, it is moving in that
>direction.
Yep. Pretty easy actually. Snag the kernel, uClibc, busybox and tiny login. Compile the kernel modular, compile everything else against uClibc.
You could install a modular Linux kernel since at least 1993. The older kernels are actually easier to get working since the core is signifigantly smaller (the kernel and modules only take up a few hundred K).
The biggest headache is my experience is getting the userspace stuff small enough to fit in the remaining space. Since you can do compressed initrds with Linux, you can create a 2-2.5MB filesystem and have it fit, but that quickly becomes tight when glibc + pals take up 1.25MB or so.
Traditionally a lot of single disk systems used libc5, which was signifigantly lighter, but nowadays uClibc provides a very nice solution, and can be compiled down to about 284k (including libc, libm, libcrypt, libutil and ldlinux).
Busybox, compiled shared, only takes up 401k, and includes four shells (ash, hush, lash, msh), an editor (vi), networking tools (traceroute, ping, nc, wget, ifconfig), archive tools (gzip, cpio, tar, dpkg_deb, uudecode, rpm2cpio, dos2unix), and most other common utilities. Don't need something (like three extra shells), comment it out, and you can easily get this down to 200-250k.
Throw in tinylogin for another 38k or so for authentication and user tools (add/deluser, add/delgroup, getty, login, password, su, sulogin, vlock) and you've got a pretty complete Unix environment for well under a megabyte.
>The MINIX file system is still available, and
>makes a very good choice for floopies: full file
>permissions and very little space wasted.
It also is limited to a maximum size of 64MB and only supports filenames up to 14 characters.
>ext2 takes up half the floppy and reiserfs
>doesn't even fit on it.
I'll agree with you on reiserfs, since it imposes a minimum filesystem size, but bollocks to your ext2 claim.
As a test, I created two 1MB filesystem images, here's the output of df with them empty:
I then created 10k files. The ext2 filesystem fit 92 of them, the minix filesytem only fit 90 of them. Here's the output of df after:
>MINIX may be dead as a production system, but its
>legacy lives on, and it's still good for OS
>courses, which is what it was made for.
I agree with this sentiment, with the possible change of saying MINIX was never really alive as a production system. It was never meant to be anything other than an educational tool.
Matt
>I mean, Coca Cola is a popular drink, but you
:)
>don't see them claiming it builds muscle or makes
>your penis/breats grow.
Three words. Coke. Adds. Life.
Matt
>Well, if you aren't, then the GPL isn't binding
>either, since you aren't intrinsically "signing"
>anything when you use GPL'd code.
As has been pointed out numerous times before, there is nothing preventing you from *using* GPL code without agreeing to the GPL.
The license is for *distribution* not use. As you have no right to distribute copyrighted works otherwise, you are bound to seek licensing before doing so, in which case the authors provide the GPL.
Matt
>I'd love it see it move into more major
>acceptance, but the problem is that sendmail is
>the default for many distros. RedHat doesn't even
>have a qmail RPM to install.
You won't see that happen unless Bernstein changes the license. Mandrake, Red Hat, Debian, and the OpenBSD maintainers have all stated explicitely that they cannot ship qmail because of the license.
The issue is even more prevalent now that distributions are striving for LSB compliance, as every piece of Bernstein's software flouts the FHS, and even traditional Unix conventions (BINARIES DO NOT BELONG IN VAR).
Even if they chose to ignore that and added qmail in a Bernstein approved way, they'd be taking a huge step backwards in functionality, since the license also doesn't approve of shipping modified source or binaries, and qmail has extremely limited standards support. No more out of the box support for SSL/TLS connections or secure authentication. They'd have to instruct their customers to download the source, patch it themselves, and recompile if they wanted that.
Qmail's lack of adoption lies solely on Bernstein's shoulders, noone else's.
Matt
>You must be use to MS who has to do contsant
>releases for bug fixes and more money. See,
>sometimes software can actually become stable.
Actually, no, the last time I ran an MS product at home for any length of time was DOS 5.0. I used NT 4.0 at one of my jobs for a period, but that was only to run a 3270 emulator for accessing the mainframe.
For the record, I *do* use qmail in a production environment, for thousands of domains. It requires a lot of patching to make it a usable product.
>Would you rather use a stable mail server that has
>really no known bugs in like 3-4yrs, or one that
>is contantly updated and has had a trojan horse?
Actually, I'd rather use a mail server that implements at least SOME of the standards that have come out in the past seven or eight years.
Stable doesn't mean jack shit if the software doesn't do what you need it to.
Matt
I was wondering if anyone would think the same thing I was when I was writing that comment. :)
Matt
>Packages like djbdns and qmail make service
/etc/mail/local-host-names, and commenting out "DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')".
/etc/mail/virtuserstable. Want to send all the mail in the domain? Change it to "@mydomain.net". Want to create dummy accounts named mydomain-USERNAME? Make the line "@mydomain.net mydomain-%1".
>configuration trivial, as it should be.
It really depends on what you're doing with them.
First off, installing either usually involves compiling from source, due to the restrictive licensing.
The software also isn't built to start under native Unix facilities like init or xinetd, so you either need to deal with installing and configuring ucspi and tcpserver, or hacking the source.
The lack of standards support in qmail also ends up requiring patching in a lot of common configurations, further complicating things. And honestly, configuring qmail isn't exactly a dream - permissions issues are easy to miss, a lot of configuration data requires compilation to a binary format, and configuration data is spread across a fairly large number of files and is hardly in the most intuitive of formats, e.g.:
+foo.com-:foo.com:500:500:/domains/foo.com:-::
Djbdns can either be very easy (simple case) or a pain in the ass.
For starters, there are a lot of standards it doesn't bother starting (IXFR, NOTIFY, TSIG, DNSSEC, etc). So interoperability with other servers is at best suboptimal.
Even if you're going to run a pure djbdns environment, there's no built in facility to transfer zone data, so you also need to either install and configure the axfr-dns program or install and configure rsync and ssh or some other method of copying the zone data to the remote server. In either case the propogation isn't automatic, so you'll probably want to write your own scripts to automate this.
Doing split-dns is a lot less intuitive than in BIND, in my opinion. You can add location tags to entries in the database, but the format only allows one per entry, so if you have different location definitions, you need to add the data multiple times (or store your data in a different format and process it into what tinydns-data expects). And those location tags are limited to only two characters, which prevents any meaningful name.
>Last time I checked you need to devote some
>serious time and brain power to properly setting
>up sendmail.
When did you last check? The mid-ninties?
Configuring Sendmail since the switch to m4 files is *trivial* for most setups.
What's even better is that, since Sendmail is under a permissive license, virtually all versions of Unix offer it by default, pre-installed and with a basic configuration.
For example, if you're doing a single domain setup the extent of your configuration on Red Hat would be adding your domain name to the
Want mail sent to phil@mydomain.net to go to bob instead?? Simple, add "phil@mydomain.net bob" to
And on Red Hat you don't even have to deal with compiling the database files, since the init scripts do it for you. Just run "/sbin/service sendmail restart".
Matt
>After the number of open e-mail relays I've had to
>deal with, sendmail leaves a sour taste in my
>mouth.
Sendmail hasn't allowed relaying at all for about five years unless you explicitely turn it on. In otherwords, blame site admins, not Sendmail.
Matt
>It is still funny, simply because it is yet
>another sendmail problem.
Yeah, and if someone breaks into your house and pees on your carpet, it's yet another carpet problem.
Matt
>Well, If you don't mind using a proprietary
>program written by a person with the same level of
>maturity and social skills as a mentally retarded
>5 year-old.
Don't forget "that hasn't had a new release in over four years and neglects to implement a lot of basic standards like authentication or encryption".
Matt
>What amazes me is I wasn't even aware anyone
>really used Sendmail anymore.
What amazed me is I wasn't even aware anyone really used Unix anymore. Man, look at all the security holes in *that* software's history.
Sendmail hasn't had a remote exploit in over two years. Named has had a single advisory posted against it (a DoS) since the 9.x series was released.
Matt
>KDE and Gnome... they need stop all development
>and focus on getting a 50% speed increase. If they
>have to cut and slash to do it, then do it.
>Mozilla needs to do this as well as Open Office.
Have you compared Gnome 2.0 against Gnome 1.4? The memory footprint has dropped, there have been speed increases across the board (Nautilus in particular shows massive improvement), and responsiveness is markedly better with double buffering.
Matt
>Quite frankly, it's quite powerful and its default
/sbin/service sendmail reload
>install is kinda simple to use except (except!)
>for that stupid map command to build virtual
>users, access tables and the likes.
This doesn't have to be all that difficult either. Red Hat, for example, has the init script rebuild those files automatically for you when you run the init script. Just add the entries you need, and type:
Matt
> And what gives *you* more credibility than
> Mosfet? He contributes things to Open Source, do
> you?
Well, he didn't make stupid statements like:
The other problem is switching the default
applications for things like the web browser and
email client from their KDE implementations to
Gnome apps.
The three applications they changed defaults to are Mozilla (not a Gnome app), OpenOffice (also not a Gnome app), and Evolution (okay, so one Gnome app).
He also didn't include a jab at Red Hat's filesystem layout when they are fully LSB and FHS compliant.
Matt
>I've been over this, and over this, and over this
>again! 128Kbps CBR *IS* [r3mix.net] *CRAPPY*
>[r3mix.net]! You'd better believe that I'm not
>going to be downloading much.
By crappy I was refering to people using buggy encoders, rippers without proper error correction, etc. I won't argue that the files from emusic are exceptionally high fidelity, but they are of consistent good quality for what they are.
Most of the music I *really* like that I download, I fully intend to pick up on CD, and encode myself, either to high quality vorbis, or perhaps to flac, once I have a large fileserver set up.
But on the other hand, for albums that I merely like, I'd be hard pressed to pay $15 for something I already got for about fifty cents.