debian vs. freebsd
sdieselil
I'm must choose between Debian GNU/Linux and FreeBSD. I heard that
they have very similiar packaging systems but I don't know differences
between them.
Please compare Debian and Freebsd installation and packaging systems
without relating to these OS'es or kernels.
Regards, Sergei
ta...@lpthe.jussieu.fr
: Hi
Quite similar indeed if you refer to apt-get or aptitude in Debian and
portupgrade on FreeBSD. Both can download automatically packages tracking
dependencies. Since quite a lot of FreeBSD ports don't exist as packages
at time t, for various reasons (the ports tree has been updated, but the
new package doesn't still exist in the repository, or the software has some
License restrictions prohibiting redistribution like java) you may expect
that portupgrade may fire up some long compilations during the process.
In the case of License restrictions you may be required to download manually
the sources. This is the main difference with Debian, which has all packages
precompiled, for the good or the worse (think mplayer for example).
Otherwise the FreeBSD ports system has provisions to preconfigure and
postconfigure the build, as Debian. In my experience there are more
postconfiguration screens in Debian, which one may like or not, while
FreeBSD most frequently requires that the user edit its configuration files.
Another difference is that FreeBSD has frequently very up to date versions of
the softs, while Debian laggs a lot, at least in the stable repository.
Still another one, Debian (and other Linux distros) have the habit of cutting
a piece of soft into a lot of different packages, headers being separated
from libraries etc. Of course this allows to install on small disks, but i
find this exasperating. You will not observe this in FreeBSD.
I was forgetting the most contentious point! Some people are horrified that
Linux dumps everything under /usr. FreeBSD does the CORRECT (TM) way by
dumping all packages under /usr/local, hence not polluting the base install,
which would be nice if the base was really basic (that is not encumbered
by sendmail and other crap).
: Regards, Sergei
--
Michel TALON
Eric P. McCoy
The difference can be summed up thusly: FreeBSD wants you to build all
your packages from vanilla source (possibly with FreeBSD-specific
patches applied), whereas Debian wants you to install all your
packages in binary form. Both can be convinced to work otherwise
(FreeBSD has binary packages, Debian can build packages from source),
but it's more difficult and less common.
The installers are fairly similar, since we can't discuss differences
in the OSes. So by "fairly similar" I mean "they both use dialog,"
which is the only thing you've left us to discuss.
--
Eric McCoy (reverse "ten.xoc@mpe", mail to "ctr2sprt" is filtered)
"Last I checked, it wasn't the power cord for the Clue Generator that
was sticking up your ass." - John Novak, rasfwrj
David Schultz
> : Please compare Debian and Freebsd installation and packaging systems
> : without relating to these OS'es or kernels.
> Since quite a lot of FreeBSD ports don't exist as packages
> at time t, for various reasons (the ports tree has been updated, but the
> new package doesn't still exist in the repository, or the software has some
> License restrictions prohibiting redistribution like java) you may expect
> that portupgrade may fire up some long compilations during the process.
> In the case of License restrictions you may be required to download manually
> the sources. This is the main difference with Debian, which has all packages
> precompiled, for the good or the worse (think mplayer for example).
The problem that some software has license restrictions that prevent
distribution of binaries is not unique to FreeBSD. Debian has this
problem, too. Java is a special case, though; the Linux binaries
(which can be installed in FreeBSD, I might add) have received Sun's
approval for binary distribution.
Zenin
>snip<
: I was forgetting the most contentious point! Some people are horrified
: that Linux dumps everything under /usr. FreeBSD does the CORRECT (TM) way
: by dumping all packages under /usr/local, hence not polluting the base
: install, which would be nice if the base was really basic (that is not
: encumbered by sendmail and other crap).
For better or worse, pretty much all Unix apps that need to mail
something expect to find sendmail available to do so, or at least a
utility that uses the same (non-network) interfaces. This is a Good
Thing, as it allows the system to have a single place to configure
how mail leaves the box.
Apps (MUA) that directly use SMTP (An MTA level protocol) are
inherently problematic. If the SMTP host isn't currently available,
how do you que mail? The MUA isn't a server; how does that que, if
any, get sent when the SMTP server is back? Does the MUA know
enough to lookup the MX of the SMTP host it's using for priority and
backups, or does it just blindly connect to smtp_host:25 and thus
assume (possibly wrongly) that smtp_host actually can accept mail?
Windows brought the thinking that the MUA should also try to be the
MTA, which does nothing but cause problems. In Unix, the defacto
standard MTA is sendmail. On FreeBSD, if you don't like sendmail
you're free to change it and adjust /etc/mail/mailer.conf
accordingly so everything that expect "sendmail" will correctly find
your MTA instead. But *something* has to be the default MTA and
since everything Unix is going to expect something called "sendmail"
and acting like "sendmail" one might as well start with Sendmail.
FreeBSD offers the most commonly expected MTA and flexible ability
to change it if you'd like. Any other choice would be little more
then pandering to one group or the other's pet MTA of choice while
breaking defacto standard expectations of what a modern Unix-like
system has available by default.
For myself I'll likely be switching to Postfix, but for the
foreseeable future I'd still advocate Sendmail be the default MTA
for any system trying to claim itself "Unix" or "Unix-like".
--
-Zenin (ze...@rhps.org) From The Blue Camel we learn:
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
ta...@lpthe.jussieu.fr
: ta...@lpthe.jussieu.fr wrote:
: >snip<
:
........
But *something* has to be the default MTA and
: since everything Unix is going to expect something called "sendmail"
: and acting like "sendmail" one might as well start with Sendmail.
Of course i plainly agree with all you say, except the last sentence. Sendmail
is and has always been crap, slow, hard to configure and full of security
holes. Only by inertia is it still present on some systems. Now, to that,
sendmail adds new sorts of obfuscations to its configuration, as is the
authors were becoming crazy. So you are faced anyways to learn new stuff.
Simple and easy, there are good MTAs which are simple, efficient and secure,
and used by people who do serious mailing stuff, that is, qmail and postfix.
I don't know qmail, but i know for sure it is a very capable program used
by large scale providers. I know postfix, and that it has all qualities to be
the standard mailer in an OS like FreeBSD, in particular because it is easy
to configure. Its usefulness is exemplified by the fact that the FreeBSD
mailing lists run under Postfix.
: FreeBSD offers the most commonly expected MTA and flexible ability
: to change it if you'd like. Any other choice would be little more
: then pandering to one group or the other's pet MTA of choice while
: breaking defacto standard expectations of what a modern Unix-like
: system has available by default.
I hate this sort of conservatism which harms very much venerable institutions
like the *BSD. Well OpenBSD is still more conservative, it offers himself the
luxury of shipping Bind4. This is plainly ridiculous, so is shipping a
system which pretends to be top-notch with sendmail.
: For myself I'll likely be switching to Postfix, but for the
: foreseeable future I'd still advocate Sendmail be the default MTA
: for any system trying to claim itself "Unix" or "Unix-like".
I have used sendmail for quite a long time, and i would not advocate it
anymore to even ennemies because Postfix is far better. I don't say anything
about qmail and exim that i don't know, but presumably sendmail is the worst
choice of all, whatever says Brad Knowles.
--
Michel TALON
David Schultz
> Of course i plainly agree with all you say, except the last sentence. Sendmail
> is and has always been crap, slow, hard to configure and full of security
> holes. Only by inertia is it still present on some systems. Now, to that,
> sendmail adds new sorts of obfuscations to its configuration, as is the
> authors were becoming crazy. So you are faced anyways to learn new stuff.
> Simple and easy, there are good MTAs which are simple, efficient and secure,
> and used by people who do serious mailing stuff, that is, qmail and postfix.
> I don't know qmail, but i know for sure it is a very capable program used
> by large scale providers. I know postfix, and that it has all qualities to be
> the standard mailer in an OS like FreeBSD, in particular because it is easy
> to configure. Its usefulness is exemplified by the fact that the FreeBSD
> mailing lists run under Postfix.
Sendmail has actually cleaned up its act quite a bit. You have to
keep in mind that it's easy for criticisms to accumulate when you're
talking about a program that has been around since the second public
release of UNIX. The goal at the time was to have reliable mail on an
operating system that was, at the time, rather unreliable. Computer
security didn't mean anything. When it did mean something, it took a
while to rework all of those ideas that were clever in the 70's but
considered unsafe in the 90's.
Sendmail does still have some design problems from a security point of
view. For instance, there is still an incestuous relationship between
shell commands and email addresses. But for the most part, I think
the folks at Sendmail, Inc have done a good job of addressing those
issues in recent years. Realize that there have been several Apache
vulnerabilities since the latest security hole was found in Sendmail.
Sendmail is more reliable and scalable than Postfix and qm*** by a
long shot (at least as of ~2001, which is when I last saw some
plausible mailer benchmarks.) I'm not sure why you think it's slow.
In any case, unless you're running a really big mail server, the
performance of your MTA of choice isn't going to make a difference to
you. (However, a number of the people who *do* run big mail servers
use FreeBSD.)
Sendmail configuration *is* hard, but I consider that to be less
important than the other issues. (If I had to pick something that
bothered me about sendmail, it would be the security problems.) You
don't need to reconfigure your mailer every day. Moreover, part of
the reason that qm*** is so easy to configure is that it can't do all
of the things that sendmail can.
At this point, you're not going to be able to convince the FreeBSD
community that they have to switch mailers. Even if Postfix or exim
*is* better, sendmail is not so inferior that a switch and the
resulting chaos are justified.
> I hate this sort of conservatism which harms very much venerable institutions
> like the *BSD. Well OpenBSD is still more conservative, it offers himself the
> luxury of shipping Bind4. This is plainly ridiculous, so is shipping a
> system which pretends to be top-notch with sendmail.
Unlike sendmail, the state of BIND really is pretty bad. I tried to
do a security audit of it once. Some parts of it are great, but some
of the code was nearly unreadable; I couldn't figure out what their
algorithms were under the time constraints I had. From what I could
tell, someone could write a faster DNS server by simply using better
data structures. It's unfortunate that no reasonable
standards-compliant alternative exists. The only semi-reasonable
alternative I know of doesn't even support zone transfers because the
author wants to make a political statement.
FWIW, I ended up doing an audit of David Mills' ntpd instead, and
promptly found several buffer overflows and a private key
predictability bug. Still unfixed. That code has some of the
scariest uses of ifdefs I have ever seen...
Boris H.
I could never get Debian woody properly installed on my Omnibook and the
Sarge install was a complete failure. Now I'm running FreeBSD 5 with KDE 3
and there are no major problems so far.
Boris
Brent Busby
potential they always have, but this one did because I had to make the
exact same choice once. It wasn't easy. I like them both very much.
In fact, I ended up running Debian on another machine just because I
couldn't stand to be without it, even after I chose FreeBSD. It's the
type of choice that will really make you end up splitting hairs.
But here are some of those hairs:
Pros for FreeBSD...
1. FreeBSD likes to do things the traditional, classical Berkeley UNIX
way, not the GNU way. This is just more standard, unless you're one of
those people who think of Linux as a standard on its own weight. There
are numerous examples of this: FreeBSD puts installed apps in /usr/local
where they belong, not /usr/bin. FreeBSD has a real /bin/sh, not bash
running in Bourne shell emulation mode. FreeBSD's userland just
generally looks the way a pure UNIX directory hierarchy should, more
purely than even a lot of vendor UNIX systems that run on big iron that
I could name. (Sun and HP have gotten downright weird in this area.)
It's all just very orthodox.
2. FreeBSD maintains a big brick barrier between the OS and your apps,
and when you want to upgrade, they're handled independantly. This is a
nice breath of fresh air compared to Linux, which seems to have the
paradigm that every package you install is just an extension of the OS,
leading to system upgrades that end up upgrading every app you have on
the same day if you're not very deliberate about avoiding that. While
it is true that Debian, bless their hearts, gives you a "hold" marker
that you can put on packages before an upgrade to prevent them from
being touched...it's not the default. Which means unless you take the
time to mark as held every single non-core package on your system that
you don't want to upgrade, you will get a mass upgrade of everything
just like you would on non-Debian distributions of Linux. That kind of
sucks. FreeBSD's separation of OS from apps is more sane. I normally
only upgrade an app if there's a new feature I want, or a security
exploit has been discovered. The rest of the time, why on Earth would I
want to upgrade every app on my machine?
3. FreeBSD comes with the IPFilter stateful packet firewall software
built into the kernel. While it is true that Linux's firewall has
improved now that they have iptables, I still think that IPFilter is the
best firewall software I've ever used. It's also more standard, since
IPFilter can also be found on big iron platforms like Solaris, whereas
iptables, ipchains, and pretty much all other Linux firewalls are found
only on Linux and have their own unique syntaxes for their scripts.
4. FreeBSD's package system is based around the C compiler, like a real
UNIX system should be. It seems that many UNIX users -- not just in the
Linux world, but everywhere -- have forgotten over the decades just why
UNIX systems come with C compilers. It's not for C programming. It's
because C is a portable language that lets you get software across
platform barriers. A UNIX package system makes the most sense when it
takes full advantage of the power of C as a portable language. Linux on
the other hand encourages users to become dependant on binary package
formats like RPM and DEB. Though Linux obviously does come with a C
compiler, its user culture obfuscates the purpose for it being there,
and most Linux users end up truly believing that if they can't get
software in some native binary package format, that there is no way for
them to use it. One has only to use the FreeBSD ports tree once and
watch it automate a build of a complicated program like Mozilla or KDE
from source to appreciate the work that FreeBSD has put into making
their package system based around the compiler where it should be. (Of
course, Debian has some major perks for its package system, too -- more
on that later, just to confuse you....) ;-)
5. Related to #4, since the package system is built around the idea of
having source tarballs automatically FTP'ed from whatever site they
originally come from and built for you fresh on your machine, they
obviously tend to be much, much more current than any distribution of
Linux will generally give you, Debian especially. Debian has a bad
reputation for taking over a year or more to release packages of many
common end-user apps, leading to a general perception that the software
is usually stale and out-of-date by the time it reaches Debian. It's
often said that this is only true if you follow Debian's 'stable' tree,
which is made for production servers; if you follow their 'testing'
tree, the software is much newer, and aimed at desktop users (despite
the scary name, 'testing' is actually quite stable). That is true, but
not as true as it should be. I've found that generally even the
software in 'testing' is often quite old, and it's really hard to
compete with the currentness of the FreeBSD ports tree anyway, since it
FTP's the source right from the sites where it comes from right when you
ask for it. Probably no binary package collection a la Linux is going
to be able to beat the currentness of that.
6. This is the one everyone brings up, so it's probably obvious, but it
belongs in any comparison of FreeBSD versus Linux: The BSD kernel is
far, far less likely than Linux to go into a saturated CPU condition
under high loads, and bounces back far more gracefully after the load
conditions subside. This can be important for servers and desktops
alike, since often misbehaving, poorly written desktop apps can go into
a loop condition where they try to take all the CPU, and at that point,
it only becomes a question of whether the kernel is willing to let the
bad app have what it wants. Under FreeBSD, I've never seen that happen.
Again, this is a notorious difference that you've probably heard before.
7. We're starting to get into hairsplitting now, but this is something
that always impressed me: FreeBSD has the vidcontrol command. Yes,
it's a little thing, but the ramifications are important to me, since I
spend a lot of time using TTY mode. If you're mostly an X-Window user,
it may not be important to you. Anyway, vidcontrol lets you change the
hardware text mode of your video card on a per-tty basis any darn time
you like. You can go from the default 80x25 terminal to 132x43, to
80x30, to whatever else your video card's BIOS supports. Yes, Linux
lets you choose a hardware text mode from LILO...at bootup. On a real
UNIX system, you shouldn't be limited to doing *anything* only on a
reboot. Not even piddly things like changing your TTY video mode.
8. FreeBSD has a faster, more intelligent tape driver. I've done remote
backups to SCSI DAT tape on both systems, and trust me, if tape backups
are of any importance to you...you WANT the FreeBSD SCSI tape interface.
Actually, FreeBSD kicks Linux in regard to pretty much anything
SCSI-related in general. The scary thing is, Linux kicks Windows in
that area. Windows SCSI must be truly evil.
9. On many machines, it's faster than Linux. I know many people have
said that it's *always* faster than Linux, but after having compared the
two on many computers, I've found that it's a highly, highly hardware
dependant thing. You'll never be able to predict in advance whether a
particular computer will be more tuned for Linux or FreeBSD unless you
try them both on that machine. It seems to be very related to the
motherboard more than anything; Asus boards seem to be very friendly to
FreeBSD, and often run it faster than Linux running on any kind of
board. You'll just have to try them both on any given machine since the
quirks that make the difference are usually not anything that can be
isolated or identified.
10. FreeBSD has no special OS-specific "gimmicks" for system
administration: Processes are signaled with kill. Services are started
and shutdown with rc scripts. Packages are installed with pkg_add and
removed with pkg_delete, not some rpm nonsense. You get the idea. If
you know UNIX, you won't have to additionally learn FreeBSD. FreeBSD is
UNIX, and you administer it like you would administer classical UNIX.
Often the gimmicks various flavors of UNIX and Linux add to make
themselves more "friendly" just make them more confusing and
non-standard. Just give me UNIX, and I'll take it from there.
Pros for Debian...
1. The number one most advanced technology, in my opinion, that the
Debian developers have given to the world is the APT package system. No,
it's not based around the compiler like the beautiful FreeBSD ports
system is, it's based around pre-compiled binary packages like other
Linux distributions. The difference is, unlike RPM and the Windows
InstallShield and so many other attempts at managing installed software
on various platforms, it actually works. And that's something. No one
else has ever been able to do that, to do what normal users expect when
they say they want to have the computer handle installation, removal,
and upgrade of programs on their machine. No one. Not Windows, not
RedHat, not anybody. Everybody's software install management sucks. APT
is the only binary package system I've ever seen that does what such a
system is supposed to do: It doesn't let you have a dependancy conflict.
It fully automates upgrades of apps and OS components, or everything
all at once. When you remove things, it will get rid of just the
program leaving your configs and data intact, or remove everything,
depending on what you want, and knows the difference. When upgrades
happen, it leaves your existing configs in place, so you won't have to
recreate your environment. It even does some things that are beyond the
call of duty and somewhat mind-boggling, that nobody even expects of a
package system: It will automate *downgrades*, taking care of all the
dependancies as you rollback your system to an earlier version! And it
will upgrade programs and even network daemons while they are in use, by
doing an amazing script-automated acrobatic juggling feat during the
upgrade process to keep daemons in a sane state while the executables
underneath of them are being replaced. Though it's not advisable, you
can actually do software upgrades on a live server with Debian while the
services being affected are in use by multiple remote users! It's, as
they say, frigging unbelievable. You can even upgrade the entire
X-Window system and the apps you're running on it while you sit in
X-Windows and run the apps. You must see it to believe it. Again, I
believe APT is the most advanced thing Debian has done for software.
This is the reason they've never bowed to pressure to "standardize" and
use RPM like all the other Linux distributions, who assume Debian is
just being obtuse and arbitrarily uncooperative. It's because the APT
system is technically superior, and...let's face it, if you've ever been
on non-Linux UNIX systems, you know that RPM isn't really a standard
anyway. For that matter, it's not even standard on Linux.
2. Debian gets major kudos from me for being the only major Linux
distribution to stick with the original idea of installing a small core
system and adding to that as desired, rather than dumping five CD-ROM's
full of drivel you may never use or even identify on your hard drive as
part of the OS install. Some Linux distributions have even been known
to include the Apache web server amongst the spillage. (You always
wanted to be a webmaster on a Internet-connected machine without being
asked about it, right?) Thank you, thank you, thank you, Debian, for
not taking us the way of the fools.
3. Though I know a lot of people here on the FreeBSD newsgroups don't
particularly care for the GNU Public License (it's something I can see
both ways personally, the BSD versus GPL thing), one must at least
appreciate Debian for not being half-hearted about it. When they say
GPL, they mean it. You have to wonder about companies like RedHat that
sell an "Advanced Server" edition of their operating system for $800USD,
amounting to little more than software you could FTP from anywhere and
set up yourself with a little UNIX experience. Debian is truly free by
the GNU definition, whether you agree with the GNU definition or not.
4. Though the directory layout isn't nearly as orthodox as FreeBSD, it's
way more so than other Linux systems. Debian has actually given some
considerable thought regarding what goes in each subdirectory of the
filesystem, and makes no exceptions for anything to the rules they've
established: /var is *always* for anything that can change on a running
system. /etc is *always* where all config files end up, and so on.
They don't do it exactly like a normal UNIX system, but at least they
have a scheme, and that's more than you can say for the chaos you see on
most other Linux installations' directory trees.
5. Some of the packaged versions of programs in their distribution are
better than the upstream originals. Debian people like to debug
programs they aren't even responsible for. It's one of the main reasons
their releases take so long, and the software gets so out of date by the
time each new version of Debian comes out. They debug everything.
They'll debug stuff they didn't even write. They'll delay an OS release
until everything runs like it was made by God. It's no wonder their
release cycle is so slow. It's actually analogous to what it would be
like if we asked Microsoft to delay a new release of Windows until every
single major WIN32 app that existed had no important bugs. And they do
it every single time they release Debian. On the one hand, it makes
their releases way, way more smooth than any other Linux update from
anyone I've ever seen. On the other hand, you really have to wonder if
anyone has ever suggested to them the fact that they're not responsible
for maintaining every piece of UNIX software in the world. Anyway, you
often get Debian versions of programs that are way better than they
would be seen floating in the wild, as a result of all this work. (On
the minus side, sometimes the Debian customizations have been known to
complicate programs that are fairly simple anywhere else. Case in
point: Psionic Software's 'logcheck'. The Debian version is scary.)
6. If you like games, I've found that OpenGL games like Quake and such
tend to work much better on Linux. FreeBSD will run them, but in my
experience, not so terribly well, as they're really tweaked for Linux.
Point for Debian here, I guess. I actually use a Windows box for games.
7. USB and firewire are far more developed on Linux. In many areas, I
prefer Linux's implementation of them to Windows. FreeBSD on the other
hand has only the most rudimentary concept of USB, though it is
improving. Actually, peripheral support on Linux is more comprehensive
overall anyway, since Linux is focused on the desktop where a person
might be expected to have all kinds of things plugged into their
computer in all sorts of varied ways. FreeBSD is focused on the server
closet, and where varied peripheral support exists, it tends to be for
things like RAID arrays and WAN cards, and different other sorts of
things you might have to define to an average desktop user before you
could tell them why they'd want it (or wouldn't). The desktop devices
that are supported in FreeBSD tend to be the common ones that many
people have a need for, and the drivers for those are excellent.
8. SMP is also more developed on Linux, since the Linux people have put
considerable effort into being very advanced on multiple processors.
FreeBSD is actually much better at SMP than it's given credit for, and
is actually much better at it in the real world than Windows is. But it
must be said, Linux still kicks our rears on this one, at least until
the new SMP technology in FreeBSD 5.0 gets more sorted out.
9. Linux has ALSA, which no other UNIX type system currently does. Why
would this matter to you? Well, if you're not a musician, it probably
won't. But OSS sound architecture has been holding back UNIX from
moving into the arena of professional grade studio recording apps for
some time now, since it was never made for it. Basically, OSS lets you
play MP3's, play Quake, have GUI sound events, and other things like
that which wouldn't be too much of a hassle for a SoundBlaster card. If
you have an RME Hammerfall audio board with some forty-eight 96kHz
inputs that you plug into a mixer desk, which is in turn hooked into a
bunch of effects processors, synthesizers, guitar processors, drum
machines, a miked up drumset, and so on, and expect to record from
forty-eight sources at the same time and have audio control over them
all at the same time, OSS is going to leave you wanting a bit.
Actually, that's just a polite way of saying OSS has the brains of a
monkey going to special ed classes for jobs like that. It was a crude
attempt at desktop audio for UNIX systems, and Linux has grown beyond it
with ALSA. The rest of the UNIX world is still waiting for real audio.
10. It's easier to get questions answered on Debian than any other Open
Source system I've been on, due to prevalent documentation on the Web.
Yes, I know my FreeBSD brethren are going to scream at me about that
one, because FreeBSD always prides itself on the documentation. Well, I
must admit, FreeBSD has the best man pages. And it has a great
handbook. But if you've ever tried to find information on the Web for
FreeBSD, you've probably run into one of the three common scenarios:
1. You find a link to something that describes your problem
exactly...but it's in Russian or Japanese. I know one of
the interesting aspects of FreeBSD culture is the way it's
really taken off in the former U.S.S.R. countries and the
Far East, and that's fascinating. But sometimes...usually,
it'd be nice to get some help in English. I often see
Debian help on the Web in any of dozens of different
languages all the time, not just Russian and Japanese.
2. You find an article on Geocrawler's FreeBSD knowledge
base where somebody has asked the exact question you're
asking...and it has no follow-ups. Nobody answers. I
know that happens in knowledge base forums for everything,
even Windows software, but it seems epidemically common
on GeoCrawler regarding FreeBSD.
3. You ask a question on Usenet, and the opposite happens:
Nine people answer, each with different *wrong* answers.
Eventually, a tenth person will answer who knows what he's
talking about. Usually getting the right answer on Usenet
with FreeBSD just involves following the replies to your
question for enough days to wait for the real guru to come
along. It normally doesn't happen until six or seven other
people who really don't know have already answered. This
doesn't seem to be so much the norm on Debian forums, where
information seems to circulate a little more accurately.
11. Security updates on Debian are just plain easy. I know it's almost
tradition in UNIX circles to say that if you can't do something the
manual way, you're not a real UNIX user. Well, that tradition got its
roots in the fact that usually doing something the manual way gives you
more power and control. But for security updates, what power and
control are you seeking by making it harder than it has to be? Let's
face it, you're applying a patch from your OS or application developer
to fix an exploit. Patches are a fairly simple concept. Debian seems
to have figured that out, and using their APT package system, applying
security fixes is something a monkey could do. That's really the way it
should be. Is security really something we should be obfuscating?
Anyway, that's my comparison of Debian and FreeBSD. I love them both,
and run them both, and have flip-flopped my server between the two of
them twice trying to make up my mind. I finally settled on FreeBSD, but
it wasn't an easy choice. In my opinion, these are two of the best
offerings in the Open Source world, with NetBSD being the third not
looked at here. It's also worth checking out as well, especially if you
think you might want to run on big iron hardware like DEC Alpha, Sparc,
or something like that, which NetBSD is very good at.
-Brent
--
|-+{ Brent A. Busby } +-| "Imagine running a dog mind at very high |
|-+ br...@catmind.org |-| speed. Would a thousand years of doggy |
|-+ Normal, IL (USA) |-| living add up to any human insight?" |
|-* FreeBSD UNIX 4.7.0 *-| --Vernor Vinge, 1993 |
Donn Miller
> FreeBSD has a real /bin/sh, not bash running in Bourne shell
> emulation mode.
Actually, FreeBSD has "ash", not the "real" sh. Example from
/usr/src/bin/sh/TOUR:
# @(#)TOUR 8.1 (Berkeley) 5/31/93
# $FreeBSD: src/bin/sh/TOUR,v 1.6 1999/08/27 23:15:07 peter Exp $
NOTE -- This is the original TOUR paper distributed with ash and
does not represent the current state of the shell. It is provided anyway
since it provides helpful information for how the shell is structured,
but be warned that things have changed -- the current shell is
still under development.
================================================================
A Tour through Ash
Copyright 1989 by Kenneth Almquist.
Otherwise, I agree with your other points about not being able to live
without Linux. I still like Linux myself, but prefer FreeBSD. I like
Gentoo a lot, although it's bleeding-edge. AFAIK, Gentoo has been very
embracing of the BSD way of doing things. For example, isn't Gentoo's
rc a lot like Debian rc + NetBSD rc.subr? There are many Debian and BSD
influences in Gentoo, and that's why I think it's k3w1.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
ta...@lpthe.jussieu.fr
: Sendmail is more reliable and scalable than Postfix and qm*** by a
: long shot (at least as of ~2001, which is when I last saw some
: plausible mailer benchmarks.) I'm not sure why you think it's slow.
: In any case, unless you're running a really big mail server, the
: performance of your MTA of choice isn't going to make a difference to
: you. (However, a number of the people who *do* run big mail servers
: use FreeBSD.)
Yes i have seen several times Brad Knowles claiming that, and i don't beleive
him one instant. No more than his rants about Bind and tinydns. In fact he has
a personal dispute with D.J. Bernstein which obscures and nullifies everything
he has to say on the subject. Saying that a monster like sendmail is faster
than posfix or qmail is akin to saying that KDE is faster than icewm, and the
same for bind. Saying that sendmail has more functionality than its
concurrents is obviously true, but the point is that this functionality comes
at the expense of great complexity, both in the program and the configuration,
and is nowadays of next to nil usefulness, since there is no more Decnet,
Bitnet, uucp bang addresses etc. so basically no address rewriting is
necessary. Anyways i have already seen tests of running several hundred
simultaneous Postfix processes, but never heard of running several hundred
simultaneous sendmails, and the FreeBSD mailing lists use Postfix, not
sendmail, presumably for a good reason. Similarly look at all the large scale
providers who use qmail, do you think they are all idiots? Here we have a
provider which offers free connectivity for modem access and cheap
connectivity for ADSL. It has more than 2 millions customers and runs entirely
on qmail. Never a glitch, it has excellent mail and news service.
: Sendmail configuration *is* hard, but I consider that to be less
: important than the other issues. (If I had to pick something that
: bothered me about sendmail, it would be the security problems.) You
: don't need to reconfigure your mailer every day. Moreover, part of
: the reason that qm*** is so easy to configure is that it can't do all
: of the things that sendmail can.
Yes this is the point. Qmail and Postfix are easier to configure, in part
because they have less functionality, in part because everybody was ranting
about sendmail complexity and they started their project with the aim of being
simple and secure. My opinion is that, if FreeBSD needs a mailer in the base
system (and i am not really convinced), it should be:
- installed by default, but easy to remove, which is not the same as easy to
circumvent, the present status.
- and simple to configure, so that Joe User can send mail easily after having
installed his system.
The first condition allowing M. PowerUser or M. Brad Knowles to remove said
mailer in disgust and revert to his cherished baby.
: At this point, you're not going to be able to convince the FreeBSD
: community that they have to switch mailers. Even if Postfix or exim
: *is* better, sendmail is not so inferior that a switch and the
: resulting chaos are justified.
I don't have any illusion about my talents to persuade the FreeBSD community :-)
However newsgroups are also places where one can share opinions, as long as
it does not degenerate into endless trolls. I think there are many points
where FreeBSD is severely lagging behind Linux, one of the most proeminents
being the installer, and that this deters a lot of people from using it, in
spite of its qualities which on several other points are ahead of Linux.
The author of the installer, J. Hubbard is the first one to insist that
sysinstall is not adequate. However you will find a lot of people here
who will swear that sysinstall is the wonder tool in FreeBSD land, that
they do all their disk partitioning stuff with it, and even fire it to
install softs or configure their X server. These people are, in my opinion,
the ones who are slowing the FreeBSD progress. If some day FreeBSD ships with
a brand new flashy Mandrake-like installer, these same people will instantly
swear that sysinstall was crap and that nothing under the sun is equal to
their new toy. To revert to sendmail and postfix, i cannot understand what
chaos could ensue after a switch, since at present, the circumventing
mechanism (mailwrapper) is said to permit seamless change of mailer.
Personnally i have used it with absolutely no problem to switch from
sendmail to postfix on my laptop. It took me some minutes to erase all
sendmail files, edit /etc/make.conf, and install a refuse file for cvsup. No
big deal. Conversely i understand easily that a sysadm who has an heavily
edited sendmail configuration would rightly be reluctant to convert to an
other mailer. So i am pleading for leaving the choice the most open possible.
It seems to me that this implies removing any mailer from the base config,
except perhaps a minimalistic one able to send the output of cron jobs, or
more simply, ask at installation time what mailer to install.
:> I hate this sort of conservatism which harms very much venerable institutions
:> like the *BSD. Well OpenBSD is still more conservative, it offers himself the
:> luxury of shipping Bind4. This is plainly ridiculous, so is shipping a
:> system which pretends to be top-notch with sendmail.
: Unlike sendmail, the state of BIND really is pretty bad. I tried to
: do a security audit of it once. Some parts of it are great, but some
: of the code was nearly unreadable; I couldn't figure out what their
: algorithms were under the time constraints I had. From what I could
: tell, someone could write a faster DNS server by simply using better
: data structures. It's unfortunate that no reasonable
: standards-compliant alternative exists. The only semi-reasonable
: alternative I know of doesn't even support zone transfers because the
: author wants to make a political statement.
Of course you are perfectly right. Bind8 is also something which should not be
present in a base install. The resolver libraries need to be here, but most
people don't need to run named, and those who want to do so should have the
choice of running bind8 if they have performance problems and don't care about
security, bind9 if they want the new features and think that bind9 is more
secure, tinydns if they are in love with D.J. Bernstein and don't need the
zone transfers you are alluding to, or even newer alternatives like nsd, the
authoritative only name server whose performances completely crash bind, or
several other alternatives. All this points in the direction of making several
parts of the so-called base install into packages. This is not an heretic
idea, since FreeBSD has already removed parts like XFree3, perl, uucp
from the base install, which is a very good move.
: FWIW, I ended up doing an audit of David Mills' ntpd instead, and
: promptly found several buffer overflows and a private key
: predictability bug. Still unfixed. That code has some of the
: scariest uses of ifdefs I have ever seen...
--
Michel TALON
David Schultz
> Saying that a monster like sendmail is faster
> than posfix or qmail is akin to saying that KDE is faster than icewm, and the
> same for bind.
Don't confuse complexity with sluggishness. Lots of complicated
pieces of software are fast because people have spent a long time
thinking about how to make them efficient. The FreeBSD VM system, for
instance, is more complicated than the Linux one, but it also makes
better replacement decisions and scales better in many situations.
(These days, I hear Rik has been doing some work in Linux that brings
it closer to what FreeBSD has.)
In the case of sendmail, some of the optimizations are just plain
stupid by today's standards, but were originally designed to solve
real problems on older systems. For instance, parsing sendmail
configuration files used to be painfully slow. So a feature was
designed that allowed sendmail to parse its configuration file, then
write a core image to disk. When you wanted to start sendmail
subsequently, you just loaded the core image and no parsing was
needed. This feature led to the infamous wizard mode hole, because
the wizard mode password was in the data segment, whereas the wizard
mode enable bit was in the BSS segment, and only BSS was saved in the
core image. Needless to say, sendmail doesn't have that feature
anymore.
But it still does have a lot of features that still solve real
problems. For instance, I know someone who uses Exim on Debian. One
of his users managed to create a mail loop in a rather strange way,
and before long, the system load average was 150 and completely
unusable, even by the admin. The system was rebooted. The average
shot up to 150 again. Finally, the problem was found and corrected.
Sendmail automatically shuts itself down when the load average exceeds
a certain value, partly in order to prevent this problem. This is a
deceptively simple feature, and yet it exists because people have
learned things from years of using sendmail.
> Similarly look at all the large scale
> providers who use qmail, do you think they are all idiots? Here we have a
> provider which offers free connectivity for modem access and cheap
> connectivity for ADSL. It has more than 2 millions customers and runs entirely
> on qmail. Never a glitch, it has excellent mail and news service.
You can make any polynomial time algorithm scale if you throw enough
hardware at it. ;-) The benchmarks I've seen show sendmail and
Postfix both doing well, with qm*** lagging quite a bit. I can try to
find them if you're interested, but it's been a while, so they're
probably out of date. Certainly it may be the case that even the slowest
of the three performs well enough in practice that nobody appreciates
the difference.
> My opinion is that, if FreeBSD needs a mailer in the base
> system (and i am not really convinced), it should be:
> - installed by default, but easy to remove, which is not the same as easy to
> circumvent, the present status.
> - and simple to configure, so that Joe User can send mail easily after having
> installed his system.
> The first condition allowing M. PowerUser or M. Brad Knowles to remove said
> mailer in disgust and revert to his cherished baby.
IMO, it's not a good idea to have the installation of a port cause
part of the base system to go away. FreeBSD has a very clean
separation between the base system and third-party software for good
reasons. A better idea would be to support either sendmail or
$MAILER_OF_CHOICE in the base system. Here is what needs to be done
for that to happen:
- Wait until we have a better installer that can cope with
that idea, or hack up sysinstall (eew).
- Offer to integrate and support the new mailer.
- Convince the security officer and release engineering
folks that they should support two mailers.
You could alternatively argue that FreeBSD shouldn't have a mailer at
all. That would almost work, but you'd never get everyone to approve
that. Mail is integrated into Unix better than MSIE is stuck to
Windows.
> The author of the installer, J. Hubbard is the first one to insist that
> sysinstall is not adequate.
Yep, and some people are trying to rewrite it. Unfortunately, many
experienced FreeBSD hackers don't even use sysinstall, so there's not
much motivation. From what I can tell, most of the people trying to
replace sysinstall are working on the replacement because they like to
do UI work. Thus, they have lots of nice flashy screenshots, but not
enough functionality.
> Of course you are perfectly right. Bind8 is also something which should not be
> present in a base install.
Well, it's at least as integral at this point as NTP, ftpd, and gperf.
It's just unfortunate that it isn't better, and that the next best
thing doesn't have the functionality that many people want.
> The resolver libraries need to be here, but most
> people don't need to run named, and those who want to do so should have the
> choice of running bind8 if they have performance problems and don't care about
> security, bind9 if they want the new features and think that bind9 is more
> secure, tinydns if they are in love with D.J. Bernstein and don't need the
> zone transfers you are alluding to, or even newer alternatives like nsd, the
> authoritative only name server whose performances completely crash bind, or
> several other alternatives. All this points in the direction of making several
> parts of the so-called base install into packages.
You know, if you mention DJB and his software enough on a newsgroup,
he *will* show up and start a flamewar. ;-)
> This is not an heretic
> idea, since FreeBSD has already removed parts like XFree3, perl, uucp
> from the base install, which is a very good move.
True, it's not a completely off-the-wall idea. In the limit, FreeBSD
could be very minimalistic, like Debian, where the minimum install
barely gives you a usable operating system. But FreeBSD wants to have
a very well-integrated and well-tested userland that it can call ``the
base system'', document, and support. There were more reasons to
remove XFree3 and perl. BIND isn't that big, whereas XFree3 and Perl
are huge. Moreover, with Perl, people kept complaining that they
wanted this module and that module in the base system, and ``can you
please upgrade this other module'', etc, etc. Ports was just a more
appropriate mechanism for it. Perl also caused problems with release
building, because for some reason you can't cross-compile it.
Zenin
>snip<
: Yes this is the point. Qmail and Postfix are easier to configure, in part
: because they have less functionality, in part because everybody was
: ranting about sendmail complexity and they started their project with the
: aim of being simple and secure. My opinion is that, if FreeBSD needs a
: mailer in the base system (and i am not really convinced), it should be:
: - installed by default, but easy to remove, which is not the same as easy
: to circumvent, the present status.
: - and simple to configure, so that Joe User can send mail easily after having
: installed his system.
It's not this simple. The new MTA also needs to walk and talk
*exactly* like /usr/sbin/sendmail (asking MUAs to use loopback SMTP
isn't a valid option), and be found at exactly that executable name.
Does Postfix? QMail? Can they be made to relatively easily?
You also have to handle the transition smoothly. I know smooth
technical transitions are completely unimportant to the Linux camps,
but that's one of the defining features of FreeBSD: Stability,
including configuration stability from point release to point
release and major release to major release. If you want to swap out
the MTA, you better find a way to do it so smoothly that no one gets
burned, even a little, from the total Unix "n00b" to the 20 year
Unix vet who writes his own sendmail.cf completely by hand.
If you can't make the transition that smooth; it's simply not FreeBSD.
>snip<
: I don't have any illusion about my talents to persuade the FreeBSD
: community :-) However newsgroups are also places where one can share
: opinions, as long as it does not degenerate into endless trolls. I think
: there are many points where FreeBSD is severely lagging behind Linux, one
: of the most proeminents being the installer, and that this deters a lot of
: people from using it, in spite of its qualities which on several other
: points are ahead of Linux.
Which is a bit odd, considering for years the FreeBSD installer was
considered by most everyone to be far and away superior to anything
from the Linux camps. But time marches on, Linux got better, and
FreeBSD hasn't felt it's important enough to drastically update.
And you know what? They're right; it isn't.
Unlike many (most, all?) Linux systems, keeping your system upto
date doesn't imply at some point, often many some points, that
you're reinstalling the base system on FreeBSD. FreeBSD upgrades
and tech transitions (a.out to ELF, gcc updates, etc) are incredibly
smooth and problem free. It's a defining FreeBSD feature and infact
the largest reason I personally switched off Linux years ago. Linux
at large constantly finds a way to seriously break existing systems
and/or make sweeping changes so large that the only "safe" way to
upgrade is to reinstall. I've heard every year or so, XYZ
distribution is better and doesn't have this problem, but you know
what? When people claim this typically the new distribution is just
that; new. It hasn't been around long enough to go through one of
these major tech changes. And when it does, it typically screws up
as badly as everyone else has in the past and we get another round
of new "this time things are different!" distributions.
FreeBSD goes far out of its way to make transitions smooth, often to
the point of completely invisible to anyone that doesn't read the
release notes in detail. They have many, many YEARS more of trust
built up in proving this time and time again then ANY Linux
distribution. It's a bit like the boy who cried wolf; "No really,
THIS will be the end-all Linux distro!"...two years later it's the
same cry, but for another distro...
So Linux *NEEDS* the better installer; It's an extremely commonly
use app for many/most/all Linux users. FreeBSD users nearly forget
there is an installer; it's been that long since they actually
needed to use it on existing systems.
>snip<
: To revert to sendmail and postfix, i cannot understand what chaos could
: ensue after a switch, since at present, the circumventing mechanism
: (mailwrapper) is said to permit seamless change of mailer.
It's designed to, yes, but even the author considers it a hack and
AFAIK it hasn't been stressed on a wide scale (for instance, a major
MTA change in the base system imposed on thousands of users at once,
not even as a beta).
: Personnally i have used it with absolutely no problem to switch from
: sendmail to postfix on my laptop. It took me some minutes to erase all
: sendmail files, edit /etc/make.conf, and install a refuse file for cvsup.
: No big deal. Conversely i understand easily that a sysadm who has an
: heavily edited sendmail configuration would rightly be reluctant to
: convert to an other mailer. So i am pleading for leaving the choice the
: most open possible.
The first rule of medicine is "Do no harm". FreeBSD trys to take a
very similar approach. Sorry, but simply because you had no
problems doesn't mean many others won't.
Remember what you're talking about here. You are advocating a
complete revamp of the subsystem of far and away *THE* most
important Internet service (email) by replacing an incredibly deeply
entrenched, time honed, and complex system (another poster mentioned
Sendmail has been part of Unix since the 2nd public release), with a
system that's guaranteed reguardless of what choice you make to be:
-Configured completely differently (users forced to relearn
their MTA after possibly a decade or more)
-Not walk and talk exactly the same as sendmail in some
respect (you'll need tons of beta testing).
-Guaranteed to offer less functionality then what it's
replacing (I think we all agree, reguardless of any other
pluses for other MTAs, Sendmail has far and away more raw
functionality then everything else, for better or worse).
: It seems to me that this implies removing any mailer from the base config,
: except perhaps a minimalistic one able to send the output of cron jobs, or
: more simply, ask at installation time what mailer to install.
An option at install, which defaults to sendmail, adjusts
mailer.conf, make.conf, etc accordingly, would be the way to do it
if you had to.
The typical response however, which I happen to agree with, is that
the base system doesn't have any "or" options. All "or" options are
handled by the ports system. FreeBSD isn't a Build Your Own Distro
system; It's a tight, rock solid base system on which to build out
to your particular needs via additional ports. Perhaps it's ashame
that the MTA didn't get pushed off the base system decades ago, but
with how entrenched the Unix email system is with standard
operations (cron mail, etc) it's stuck now. And it's stuck with the
Sendmail APIs.
Remember it could be worse, much worse. We could be in the Windows
or Java worlds telling MUAs they should really should use SMTP, each
store their own configs, each handle their own queuing, never bother
to do MX lookups... Down that path lies madness...I know; as a
release manager for multiple large development groups, most of which
work writting server code in Java on Windows workstations to be used
on Unix servers, the move away from using the local MTA has been
nothing but a nightmare, but the last thing I want MUA code to have
to do is switch(mta) case postfix, case sendmail, etc.
: Of course you are perfectly right. Bind8 is also something which should
: not be present in a base install. The resolver libraries need to be here,
: but most people don't need to run named, and those who want to do so
: should have the choice of running bind8 if they have performance problems
: and don't care about security, bind9 if they want the new features and
: think that bind9 is more secure, tinydns if they are in love with D.J.
: Bernstein and don't need the zone transfers you are alluding to, or even
: newer alternatives like nsd, the authoritative only name server whose
: performances completely crash bind, or several other alternatives. All
: this points in the direction of making several parts of the so-called base
: install into packages.
But like you said, the libs and utilities need to be in the base.
At some point you have to pick some flavor of DNS server and run
with it. As named doesn't run by default, there is little reason to
then bother cutting up the bind code base so just named doesn't get
built, when users can still just as easily install their favorite
DNS server via ports.
: This is not an heretic idea, since FreeBSD has already removed parts like
: XFree3, perl, uucp from the base install, which is a very good move.
Those apps don't nest nearly as deep into the system or history as
the MTA and BIND resolver libs.
--
Z R /\ _ _ _ _
E H / \ | | |_ | _ | /\ |\ | / |_
N @ . O R G / \ |_ |_ |_ \_/ | / \ | \| \_ |_
I P "The Greatest Game You Never Played"
N S www.AllegianceHQ.org
ta...@lpthe.jussieu.fr
: True, it's not a completely off-the-wall idea. In the limit, FreeBSD
: could be very minimalistic, like Debian, where the minimum install
: barely gives you a usable operating system. But FreeBSD wants to have
: a very well-integrated and well-tested userland that it can call ``the
: base system'', document, and support. There were more reasons to
: remove XFree3 and perl. BIND isn't that big, whereas XFree3 and Perl
: are huge. Moreover, with Perl, people kept complaining that they
: wanted this module and that module in the base system, and ``can you
: please upgrade this other module'', etc, etc. Ports was just a more
: appropriate mechanism for it. Perl also caused problems with release
: building, because for some reason you can't cross-compile it.
I agree with you, one can have either the idea of shipping a reasonably
complete base system, or a minimalistic one. Personnally i would prefer
the second one, but i understand that other people prefer the first.
As you are saying Debian is the perfect example of the second strategy
and i have never seen anybody complaining of the general organization
of Debian (except the installer which is terrible).
--
Michel TALON
Ted Spradley
Zenin <ze...@rhps.org> wrote:
> Perhaps it's ashame
> that the MTA didn't get pushed off the base system decades ago,
> but with how entrenched the Unix email system is with standard
> operations (cron mail, etc) it's stuck now. And it's stuck with
> the Sendmail APIs.
You know, I agree with all you say in this thread. What seems a shame
to me is that all the "new, modern" MTA's seem to be designed for
performance, scalability, and configurability, but *most* Unix boxes
these days are *not* major mail hubs for large organizations. Wouldn't
it be nice if there was a tiny MTA designed for workstations?
Preferably with no configuration at all except a pointer to the nearest
real mail hub? Every box needs to run an MTA, but in most cases it
doesn't need to be a very sophisticated MTA.
> Remember it could be worse, much worse. We could be in the
> Windows or Java worlds telling MUAs they should really should
> use SMTP, each store their own configs, each handle their own
> queuing, never bother to do MX lookups... Down that path lies
> madness...
This is why every box needs to run its own MTA.
--
Remember, more computing power was thrown away last week than existed in
the world in 1982. -- http://www.tom.womack.net/computing/prices.html
Ted Spradley
Brent Busby <br...@telepath.catmind.org> wrote:
> But here are some of those hairs:
>
> Pros for FreeBSD...
>
> 1. FreeBSD likes to do things the traditional, classical Berkeley UNIX
> way, not the GNU way.
[...]
Pros for Debian...
1. The number one most advanced technology, in my opinion, that the
Debian developers have given to the world is the APT package system.
Thank you for a very complete, very well-reasoned comparison. I'm gonna
save that. Makes me want to go out and try Debian.
Still, I think the synopsis is "Linux is for people who hate Microsoft;
BSD is for people who love Unix". ;-)
Donn Miller
ta...@lpthe.jussieu.fr wrote:
> I agree with you, one can have either the idea of shipping a reasonably
> complete base system, or a minimalistic one. Personnally i would prefer
> the second one, but i understand that other people prefer the first.
Well, you know where to find Gentoo if you want it. That's exactly how
Gentoo treats things: everything is a port.
Andrea Paolini
> Wouldn't
> it be nice if there was a tiny MTA designed for workstations?
> Preferably with no configuration at all except a pointer to the nearest
> real mail hub? Every box needs to run an MTA, but in most cases it
> doesn't need to be a very sophisticated MTA.
In ports there are two MTAs using this kind of approach: ssmtp and
nullmailer. I used one of them (ssmtp) some time ago on a Linux box
without major problems (but OTOH it was just forwarding some occasional
system mail) and I don't know if it could be a suitable solution for
general workstation usage.
My 0.02EUR,
- ap
ta...@lpthe.jussieu.fr
: On Thu, 30 Jan 2003 19:38:07 -0000
: Zenin <ze...@rhps.org> wrote:
:> Perhaps it's ashame
:> that the MTA didn't get pushed off the base system decades ago,
:> but with how entrenched the Unix email system is with standard
:> operations (cron mail, etc) it's stuck now. And it's stuck with
:> the Sendmail APIs.
: You know, I agree with all you say in this thread. What seems a shame
: to me is that all the "new, modern" MTA's seem to be designed for
: performance, scalability, and configurability, but *most* Unix boxes
: these days are *not* major mail hubs for large organizations. Wouldn't
: it be nice if there was a tiny MTA designed for workstations?
: Preferably with no configuration at all except a pointer to the nearest
: real mail hub? Every box needs to run an MTA, but in most cases it
: doesn't need to be a very sophisticated MTA.
I agree also with a lot of Zenin's post, it was wonderful. But, to answer your
own quest, Postfix is typically a zero config program for the situation you
describe. I have just checked on my machine, here is the config:
myhostname = asmodee.lpthe.jussieu.fr
myorigin = $mydomain
relayhost = [parthe.lpthe.jussieu.fr]
virtual_maps = hash:/usr/local/etc/postfix/virtual
Period. The second line is a fantasy, to strip the hostname in addresses,
the third line is a little hack because the smart host is not the MX.
So basically the guy who sends to the next hub needs *2* lines of
configuration, declare hostaname, declare relay.
In fact i have also a hack to redirect root's mail, so a fourth line.
The fact that Postix is designed for huge scalability does not change in
any way the fact that its configuration for "standard" cases is of
utmost simplicity.
This is not to say that sendmail's .mc file is vastly more complicated
in the same situation, it has basically the same ingredients.
But if you want to achieve the same sort of things with the new version
of sendmail (non suid root) you may need to experiment a bit with
sendmail.cf and submit.cf. In fact my other machine has sendmail
sending through uucp and i spent quite a lot of time to fix the transition
to non suid sendmail. So i maintain that this stupid transition caused
(at least for me) much more hassle than the one to Postfix.
:> Remember it could be worse, much worse. We could be in the
:> Windows or Java worlds telling MUAs they should really should
:> use SMTP, each store their own configs, each handle their own
:> queuing, never bother to do MX lookups... Down that path lies
:> madness...
: This is why every box needs to run its own MTA.
: --
: Remember, more computing power was thrown away last week than existed in
: the world in 1982. -- http://www.tom.womack.net/computing/prices.html
--
Michel TALON
ta...@lpthe.jussieu.fr
: On Thu, 30 Jan 2003 10:03:33 GMT
: Brent Busby <br...@telepath.catmind.org> wrote:
:> But here are some of those hairs:
:>
:> Pros for FreeBSD...
:>
:> 1. FreeBSD likes to do things the traditional, classical Berkeley UNIX
:> way, not the GNU way.
: [...]
: Pros for Debian...
: 1. The number one most advanced technology, in my opinion, that the
: Debian developers have given to the world is the APT package system.
: Thank you for a very complete, very well-reasoned comparison. I'm gonna
: save that. Makes me want to go out and try Debian.
Then save yourself the stress of installing and configuring Debian (their
install tool is worse than the FreeBSD one), go download the Knoppix cdrom
(www.knoppix.org) boot on it and play with a Debian system. You can even
dump it on hard drive. After that experience you will have an example of
something that "just works" as they like to say here.
NetBSD has a very similar live-iso. You may have the perversity of downloading
and try it on the same machine. Do the experience and come back
saying Linux is slow, or Linux is unable to swap correctly, etc.
--
Michel TALON
?
I really shouldn't do this, but since I don't have anything better to do....
> where they belong, not /usr/bin. FreeBSD has a real /bin/sh, not bash
> running in Bourne shell emulation mode. FreeBSD's userland just
Actually Debian offers 'dash' for a nice non-bash POSIX compliant shell.
Debian policy is that rc and package management scripts be able to run
under a POSIX shell instead of bash.
>
> 2. FreeBSD maintains a big brick barrier between the OS and your apps,
> and when you want to upgrade, they're handled independantly. This is a
For folks that believe that 'vi', 'sendmail', 'grep', .... are not apps.
As for marking packages for hold. 'dpkg --get-selections' along with
'sed', 'vi', and 'dpkg --set-selections,' are your friends :-).
>
> 4. FreeBSD's package system is based around the C compiler, like a real
Actually it seems to be based around 'make'.
> UNIX systems come with C compilers. It's not for C programming. It's
> because C is a portable language that lets you get software across
> platform barriers.
Until you run into conflicting APIs (You'd think with POSIX that this
wouldn't be an issue, but I've had enough fun over the years shuffling
from Ultrix to AIX to *BSD to HPUX to Solaris to AIX).
Issues with lusers and PHBs and legal departments that believe that
legal software can only come from shrink wrapped boxes is more of a
cultural and education problem.
>
> 6. This is the one everyone brings up, so it's probably obvious, but it
> belongs in any comparison of FreeBSD versus Linux: The BSD kernel is
> far, far less likely than Linux to go into a saturated CPU condition
> under high loads, and bounces back far more gracefully after the load
> conditions subside. This can be important for servers and desktops
Yeah, it's also far far more likely that Al Viro can write yet another
exploit to gain root on *BSD. The reasonable response should be to see
if Al would be willing to act as a consultant to find and plug the holes.
> lets you choose a hardware text mode from LILO...at bootup. On a real
> UNIX system, you shouldn't be limited to doing *anything* only on a
> reboot. Not even piddly things like changing your TTY video mode.
So HP doesn't make real Unix boxes? (Video mode for text appears to
only be changeable just before boot if they are running HPUX).
>
> 10. FreeBSD has no special OS-specific "gimmicks" for system
> administration: Processes are signaled with kill. Services are started
> and shutdown with rc scripts. Packages are installed with pkg_add and
> removed with pkg_delete, not some rpm nonsense. You get the idea. If
> you know UNIX, you won't have to additionally learn FreeBSD. FreeBSD is
> UNIX, and you administer it like you would administer classical UNIX.
> Often the gimmicks various flavors of UNIX and Linux add to make
> themselves more "friendly" just make them more confusing and
> non-standard. Just give me UNIX, and I'll take it from there.
Define classical Unix. I mean I didn't have pkg_* on Ultrix nor AIX
(Well AIX 1.x, the one for intel, may have had it). HPUX's commands
behaved in a subtly different fashion until relatively recently.
And under the covers RHAT and Debian still use rc scripts and still
use kill(2) to signal most processes.
>
> Pros for Debian...
>
> 1. The number one most advanced technology, in my opinion, that the
> Debian developers have given to the world is the APT package system. No,
> it's not based around the compiler like the beautiful FreeBSD ports
> system is, it's based around pre-compiled binary packages like other
> Linux distributions. The difference is, unlike RPM and the Windows
> InstallShield and so many other attempts at managing installed software
> on various platforms, it actually works. And that's something. No one
It's worth pointing out that AIX's installp has been doing a superb job
of package management since the early 1990s (AIX 3.x, 4.x and 5.x).
AIX's installp lacks debian's network awareness, but AIX's network
install manager (AIX 4 and later) seems to address some of the issues.
HPUX also has a fair package management system that frequently feels like
a slightly less polished installp.
>
> 3. Though I know a lot of people here on the FreeBSD newsgroups don't
> particularly care for the GNU Public License (it's something I can see
> both ways personally, the BSD versus GPL thing), one must at least
> appreciate Debian for not being half-hearted about it. When they say
> GPL, they mean it. You have to wonder about companies like RedHat that
> sell an "Advanced Server" edition of their operating system for $800USD,
> amounting to little more than software you could FTP from anywhere and
> set up yourself with a little UNIX experience. Debian is truly free by
> the GNU definition, whether you agree with the GNU definition or not.
Until you add contrib and non-free and non-US.
Yes that still remains free as in beer but doesn't always succeed with
the free as in speech.
>
> 8. SMP is also more developed on Linux, since the Linux people have put
> considerable effort into being very advanced on multiple processors.
> FreeBSD is actually much better at SMP than it's given credit for, and
> is actually much better at it in the real world than Windows is. But it
> must be said, Linux still kicks our rears on this one, at least until
> the new SMP technology in FreeBSD 5.0 gets more sorted out.
That varies from year to year. For a while FreeBSD had better SMP
support. And part of it is corporate $$$$. Folks like Donald Becker
attract corporate money to get Linux working on SMP and NUMA systems.
>
> 9. Linux has ALSA, which no other UNIX type system currently does. Why
QNX has ALSA
>
> 10. It's easier to get questions answered on Debian than any other Open
> Source system I've been on, due to prevalent documentation on the Web.
Unless it was the character rendering/display corruption bug in the
zvt based gnome-terminal2.
As an aside, I generally prefer netbsd as a bounce point for finding
ipv6 and ipsec documentation :-).
>
> 11. Security updates on Debian are just plain easy. I know it's almost
> tradition in UNIX circles to say that if you can't do something the
> manual way, you're not a real UNIX user. Well, that tradition got its
> roots in the fact that usually doing something the manual way gives you
> more power and control. But for security updates, what power and
> control are you seeking by making it harder than it has to be? Let's
> face it, you're applying a patch from your OS or application developer
> to fix an exploit. Patches are a fairly simple concept. Debian seems
> to have figured that out, and using their APT package system, applying
> security fixes is something a monkey could do. That's really the way it
> should be. Is security really something we should be obfuscating?
I've always wondered how big the mess would be if some black-hat
tinkered with debian's DNS records and had a tainted server on a fat pipe.
In summary, the only correct answer is "They all suck differently."
--
Chris Dukes
"earthly insanity/brings us conformity
the tinkling bells call me/it plays a leading role
I never could foresee/the purity you stole" -- arte.fa(t's 'Purification'
Ted Spradley
ta...@lpthe.jussieu.fr wrote:
> I agree also with a lot of Zenin's post, it was wonderful. But, to
> answer your own quest, Postfix is typically a zero config program for
> the situation you describe.
Yeah, Postfix defaults are well chosen. But there's still a *lot* of
knobs you *could* turn. If Postfix is new to you, you still feel that
you should take a look at all these configuration options to make sure
you're not missing something important.
A big, complex, powerful program that looks simple on the outside is
still not the same thing as a small, simple program.
ta...@lpthe.jussieu.fr
: On Fri, 31 Jan 2003 00:07:47 +0000 (UTC)
: ta...@lpthe.jussieu.fr wrote:
:> I agree also with a lot of Zenin's post, it was wonderful. But, to
:> answer your own quest, Postfix is typically a zero config program for
:> the situation you describe.
: Yeah, Postfix defaults are well chosen. But there's still a *lot* of
: knobs you *could* turn. If Postfix is new to you, you still feel that
: you should take a look at all these configuration options to make sure
: you're not missing something important.
You are right. First time i tried postfix i feel obliged to read the
documentation on www.postfix.org. By the way, this amounts to something like
10 printed pages plus the FAQ which enters discussion of some fine points
which are of interest only to very special situations. Compare that to
the 500 pages or more of the bat book, or even the innumerable options
of sendmail described in cf/README, each one being explained in such
geekeese that you wonder what's its purpose, what does it do really,
the precise answer being presumably in the source code.
Anyways Debian has a nice postinstall script for Postfix that asks a few
questions and then write a very short main.cf. This hides all other options
that most people don't need.
: A big, complex, powerful program that looks simple on the outside is
: still not the same thing as a small, simple program.
Yes, but apparently nobody wants to take the pains to write a minimalistic
mailer which would not have all the bells and whistles to support funny
configurations. We have to live with that. On the other hand, there exists
minimalistic name servers, which are able to do the job quick and simple
for most uses while not having all the features of bind9. An example being
maradns (www.maradns.org). Being simple has the following result:
<quote>
The benchmark performed here was done with the "benchmark" tool supplied with
MaraDNS. I sent a series of 50,000 queries over the loopback interface to
DjbDNS 1.04, BIND 4.9.7, BIND 8.3.2, BIND 9.1.1rc6, and MaraDNS 0.5.09. Here
is how long the queries took, in seconds, to process on a Dell poweredge
computer with a single 800MHZ Pentium III CPU, running Linux 2.2.19:
maradns-0.5.09: 3.46
bind-8.2.3: 6.34
bind-9.1.1rc6: 6.40
bind-4.9.7: 6.48
djbdns-1.04: 9.95
These numbers, of course, do not tell the entire story. TinyDNS uses a disk-
based database, which allows it to do some things MaraDNS can not do, such as:
Changing data in the database without having to restart TinyDNS
Having a huge dataset (well, two gigbytes or less) without having to load the
entire dataset in to memory before processing queries
BIND has many capabilities that MaraDNS does not have, such as dynamic DNS and
signed DNS records.
<endquote>
In fact these numbers say at least one interesting thing. Note how bind4 bind8
and bind9 have the same performances. This is in sharp contrast with the
widely propagated notion that bind9 is much slower than bind8. If these
numbers are reliable, i don't see any reason to keep bind8 with all its
security risks, and not replace it with bind9.
: --
: Remember, more computing power was thrown away last week than existed in
: the world in 1982. -- http://www.tom.womack.net/computing/prices.html
--
Michel TALON