Date: Fri, 16 Feb 2001 23:22:17 -0800 (PST) From: Matt Dillon <dillon@earth.backplane.com> To: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca>, Dag-Erling Smorgrav <des@ofug.org>, Mark Murray <mark@grondar.za>, arch@FreeBSD.ORG Subject: Summary of List of things to move from main tree to ports Message-ID: <200102170722.f1H7MHm20405@earth.backplane.com>
next in thread | raw e-mail | index | archive | help
Ok, here's my summary. Yah yah, I inject my own opinions. Too bad.
This will be my last posting on the topic.
Least Controversial:
games
There does not seem to be much resistance to the idea of moving
most /usr/src/games out of the main source tree and into ports.
People seem to content to argue about other things.
My opinion is that while the base games are still fun to play,
there are so many games in ports that are as interesting or more
interesting that the usefullness of having the original set in
the base tree is marginal at best, even if you play 'hack' all
the time. My only exception is 'fortune', which many third party
apps (like xscreensaver) just assume exists on the system.
rdist (apparently already removed from current)
Medium Controversial:
UUCP (uucp, uucpd)
Robert Watson suggests, and others agree that
the best way to handle UUCP is to change the NO_UUCP make.conf
option into a BUILD_UUCP make.conf option. I would interject that,
in addition to that, we should not create the uucp directory hierarchy
unless uucp is selected in make.conf (i.e. not create
/var/spool/uucppublic, a directory which defaults to modes 777, by
default). Robert Watson also makes the point about the suid/sgid
nature of many uucp binaries, and I and others will attest to the
fact that UUCP is simply not maintained anymore. That is a
dangerous combination to have installed in the system by default.
There are fewer people screaming for UUCP to stay in the base tree
then, say, people screaming for rlogind to stay in the base tree.
Despite Terry's waxing poetic about UUCP's dialup capabilities,
every soul I know (except maybe Terry) who has ever used UUCP in the
past no longer does (and I should know: I wrote AmigaUUCP!).
However, if those people are going to make a big deal about it,
I suppose we can take the intermediate step of having a BUILD_UUCP
make.conf (opt-in) option for the next few years.
Kerberos IV
Robert Watson argues (several times) about the complexity of
integrating certain packages, namely KRB4, into the system.
A counter argument is made that such integration is not necessarily
a good thing. I would interject that KRB4 is so undesireably
complex that integration is pretty much the only way you can
support it, which is why we should throw it out and push KRB5
the last few yards it needs to be pushed to get it in as well
as KRB4. KRB4 is a nightmare, integrated or not.
Lyndon Nerenberg provides an example - his shop - which relies
on the massive integration provided in our KRB4 implementation.
He makes a reasoned argument for GSSAPI. But it can also be
argued fairly easily that GSSAPI is actually preventing us from
moving forward with its extremely limited scope. It may not
be a good idea to force oneself to stay in the past because the
future doesn't support your favorite API.
Terry brings up a good point in regards to PAM. I feel that PAM
is the most likely future, but it can't be use to justify moving
'older' pieces off the system until the newer pieces actually use
it in the proper way. That is, at the moment GSSAPI is more
proven then PAM, but PAM has the momentum and will likely be able
to take over completely sometime in the next few years. When
that occurs, anyone still using KRB4 is going to be faced with a
very tough decision.
So as far as KRB4 goes, I think we are going to have to keep it
around until PAM catches up and KRB5 reaches the same level
of integration. I am personally amazed at KRB4's staying power,
but the writing is on the wall.
Highly Controversial:
telnetd, rshd, rlogind, rexecd
rmt, rcp, rlogin, rsh
A number of people favor removing the server side utils. Virtually
nobody favors removing the client side utils. Terry argues that
he still uses the daemons (not a very good argument in my opinion),
others argue that the daemons are useful within firewalled networks
(also a terrible argument in my opinion). There was a reasonable
argument by Nate in regards to mixed windows <-> UNIX networks where
the windows boxes used the above standard utilities to access the
UNIX boxes. While I will point out that it is relatively easy to
use ssh on a windows box, it is still no where near as easy as it is
to use ssh on a UNIX box.
David O'Brien probably made the best argument, if you remove the
all-caps phrases from his posting. The daemons are turned off by
default, keeping the binaries around does not present a serious
burden on the system. Yes, it could be argued that this slows the
adoption of protocols like ssh, but the daemons are still used
enough that we cannot justify removing them from the system. And,
despite being old, the daemons do support kerberos connections
as an option (though I will add: Not very well. There are terrible
bugs with regards to streaming and EOF handling with the kerberized
telnet, for example. It's good enough for terminal sessions but
I don't trust them for anything else).
ftp, ftpd
Mostly specious arguments. There are obvious uses for ftp and even
ftpd in regards to anonymous downloading. Since ftpd is most often
used for anonymous operations on publically available files, there
is no real argument for removing it even though some idiots will
probably use it with sensitive materials.
Nobody seriously argued for the removal of ftp, but that didn't
stop others from freaking out and screaming loudly that it should
stay in the system.
sendmail
bind
I think only Cy Schubert is the only one in favor of moving
sendmail and bind to ports. Most everyone else is very loud
in wanting to keep it. However, even Cy is partial to using
make.conf options to select what to build and/or install and
others tend to agree that that is a reasonable approach.
Chris brings up a very good point about certain major packages
(e.g. sendmail) being actively maintained by committers whereas
other packages do not have the same level of commitment.
My opinion is that, like bind, sendmail is a core piece of the
system. If we were to provide alternatives, they would also have
to be brought into the main tree (e.g. on a vendor branch) and
maintained as such. Then you could choose via rc.conf and you
could disable elements with make.conf (unlike UUCP, which should
be opt-in, if we are given sendmail & bind equivalents to choose
from in the base system they should probably be opt-out in regards
to (not) compiling them, then selected with rc.conf).
I can see postfix being brought into the vendor branch and being
maintained as the same level that sendmail is maintained. I don't
really see qmail being maintainable at the same level that postfix
is maintainable, and three MTAs in the base tree is probably too
many. As Chris says, someone needs to be willing to seriously
maintain it.
Someone brought djbdns up. Security alone is not a good enough
reason to try to bring something into the base tree. To be in the
base tree the program must be supported and I don't know a single
person willing to maintain (long term) the unreadable, uncommented
djbdns code. I feel that the most likely course of action
is that bind8 will eventually become bind9. While Paul does not
produce the most secure code in the world, he's a lot easier to
work with and he acknowledges that bind8 has reached the end of
its usefullness.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102170722.f1H7MHm20405>