strip FreeBSD a bit
Christer Solskogen
Since perl has been moved to ports, why should not other stuff also go
the same way?
I`m thinking BIND and Sendmail at first. Both BIND and sendmail[2] is
already in ports.
[1] /usr/ports/net/bind{8,84,9}
[2] /usr/ports/mail/sendmail
---
Solskogen
_______________________________________________
freebs...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-chat
To unsubscribe, send any mail to "freebsd-chat...@freebsd.org"
Doug Barton
> To try to continue a previous thread....
> Since perl has been moved to ports, why should not other stuff also go
> the same way?
1. -chat is 100% the wrong list for this.
2. There is EXTENSIVE discussion of this topic in the archives, do your
homework first.
Doug
--
This .signature sanitized for your protection
Christer Solskogen
> On Sat, 30 Aug 2003, Christer Solskogen wrote:
>
>
>>To try to continue a previous thread....
>>Since perl has been moved to ports, why should not other stuff also go
>>the same way?
>
>
> 1. -chat is 100% the wrong list for this.
mmkay, what`s the right list then? After reading
http://lists.freebsd.org/mailman/listinfo and looking at the
descriptions, this was the best i found.
> 2. There is EXTENSIVE discussion of this topic in the archives, do your
> homework first.
>
Remember what list?
--
Med vennlig hilsen / Best regards
Christer Solskogen
http://dtz.cjb.net - http://carebears.mine.nu
"Cheap, but not as cheap as your girlfriend!"
-Spider Jerusalem
Andreas Klemm
I think its a bad idea to remove components from FreeBSD that
everybody would expect in a BSD.
I think you touch areas here like tradition ...
In Linux its another thing, they don't have such a tradition,
since Linux is only a kernel and Linux never defined a Linux
basde system. So there you can discuss of having sendmail,
exim, postfix or qmail installed by default or not.
IMHO I think its a good thing that a normal FreeBSD installation
includes bind and sendmail. This makes FreeBSD a complete
(standard/traditional) Unix after basic installation.
Things like perl had to go for other reasons in 5.x it was
related to difficulties in the build process and RPITA concerning
how the p5- ports fit into a scheme perl5 in base system + newer
perl5 under /usr/local.
Andreas ///
--
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? -> http://www.apsfilter.org/
Colin Percival
>IMHO I think its a good thing that a normal FreeBSD installation
>includes bind and sendmail. This makes FreeBSD a complete
>(standard/traditional) Unix after basic installation.
I disagree. There's lots of important stuff in the ports tree -- cvsup,
portupgrade, various languages -- which are pretty basic elements of
FreeBSD these days. No sane person is going to be running just the base
FreeBSD system except in very unusual circumstances.
The ports tree may have once been a set of FreeBSD ports of software
written for other operating systems, but it is now useful primarily as a
packaging system. Ideally, things like sendmail and bind would be taken
out of the base system, and sysinstall would offer people the option of
installing sendmail/qmail/exim/portfix/nothing and bind/djbdns/nothing; for
that matter, most things under contrib/ are probably good candidates for
removing from base.
The problem, of course, is actually getting it done.
Colin Percival
Andreas Klemm
> At 08:50 31/08/2003 +0200, Andreas Klemm wrote:
> >IMHO I think its a good thing that a normal FreeBSD installation
> >includes bind and sendmail. This makes FreeBSD a complete
> >(standard/traditional) Unix after basic installation.
>
> I disagree. There's lots of important stuff in the ports tree -- cvsup,
> portupgrade, various languages -- which are pretty basic elements of
> FreeBSD these days. No sane person is going to be running just the base
> FreeBSD system except in very unusual circumstances.
cvsup needs modula to compile. You would have to add modula 3 into
the FreeBSD build environment, thats one big reason why you won't
see cvsup in FreeBSDs base system.
Portupgrade relies on ruby. Same issue here. These are the things
that the FreeBSD developers dislike, a bloated FreeBSD with tools
that need a bunch of other tools as a prerequisite.
rewrite cvsup and portupgrade in C or C++, then I think these tools
could go in. Like mergemaster, which was at the beginning also a port
but has been migrated into base system when the two following two
things has been met:
a) stable enough
b) has a maintainer in the base system who takes care of it
in all active release branches
> The ports tree may have once been a set of FreeBSD ports of software
> written for other operating systems, but it is now useful primarily as a
> packaging system. Ideally, things like sendmail and bind would be taken
> out of the base system, and sysinstall would offer people the option of
> installing sendmail/qmail/exim/portfix/nothing and bind/djbdns/nothing; for
> that matter, most things under contrib/ are probably good candidates for
> removing from base.
I disagree here. sendmail and bind have a long tradition in the
FreeBSD base system. So everybody expect them there.
You would have to write wrappers for all those tools, sendmail
and bind, so that they appear to be in the base system paths ...
/usr/bin, /usr/sbin etc ....
I would dislike seeing sendmail and bind commands somewhere under
/usr/local.
Another thing is, that tools that live under /usr/src IMHO
are naturally better integrated into the base system and are
better tested and reviewed than tools that live under /usr/local !
FreeBSD developer who have commit rights under /usr/src certainly
take better care of what comes into /usr/src and what not !
Ports sometimes get updated a bit "sloppy". Therefore I prefer
a well tested sendmail and bind in the base system, that getting
all this bits from ports.
Andreas ///
--
Andreas Klemm - Powered by FreeBSD 4.8-STABLE
Need a magic printfilter today ? -> http://www.apsfilter.org/
Simon L. Nielsen
--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 2003.08.31 00:09:47 -0700, Colin Percival wrote:
> packaging system. Ideally, things like sendmail and bind would be taken=
=20
> out of the base system, and sysinstall would offer people the option of=
=20
As stated in the archives, bind can't just be removed due to the
resolver code being used in libc.
> installing sendmail/qmail/exim/portfix/nothing and bind/djbdns/nothing; f=
or=20
Bernsteins programs can't be distributed, since we are not allowed to
distribute modified binary versions.
Besides, sysinstall in 5.x actually allows to install exim/postfix to
use instead of sendmail. Sysinstall doesn't remove sendmail, but it's
just not used.
> that matter, most things under contrib/ are probably good candidates for=
=20
> removing from base.
> The problem, of course, is actually getting it done.
A lot of the things in contrib/ are important to normal operation of a
FreeBSD system, e.g. compilers, groff (for manual pages) and many more.
Well, I guess that was enough repeating of what's in the archives
multiple times already :-).
--=20
Simon L. Nielsen
FreeBSD Documentation Team
--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/UdJzh9pcDSc1mlERAlkoAJ0Y5cS9WLl/Bu0cPGcXHiuinPg6BgCgprW8
8lFXNuMLYWjLB3q1tz2R6Qk=
=ZIrB
-----END PGP SIGNATURE-----
--Nq2Wo0NMKNjxTN9z--
Christian Weisgerber
> rewrite cvsup and portupgrade in C or C++, then I think these tools
> could go in.
This is actually happening, sort of, for cvsup.
Masahide Maekawa has created cvsync (ports/net/cvsync), a designated
replacement for cvsup, written in plain C, with POSIX threads as
the only noteworthy requirement. So far cvsync still misses checkout
mode, but otherwise it already provides equivalent functionality
to cvsup. It isn't compatible with cvsup, though.
I don't expect FreeBSD users to flock to cvsync anytime soon, since
FreeBSD has an extensive cvsup infrastructure and hardly anybody
runs FreeBSD on a platform where cvsup isn't available. There is
more pressure in the NetBSD and OpenBSD camps, where cvsup is not
very entrenched and availability across a wide range of platforms
is a significant concern.
Once cvsync is feature complete and development settles down, I
expect a push to import it into the respective base systems.
--
Christian "naddy" Weisgerber na...@mips.inka.de
Darren Pilgrim
> On 2003.08.31 00:09:47 -0700, Colin Percival wrote:
>
> > bind/djbdns/nothing; for
>
> distribute modified binary versions.
>
> Besides, sysinstall in 5.x actually allows to install exim/postfix to
> use instead of sendmail. Sysinstall doesn't remove sendmail, but it's
> just not used.
Where is this option?
Simon L. Nielsen
--pY3vCvL1qV+PayAL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
[CC: trimmed]
On 2003.08.31 14:50:15 -0700, Darren Pilgrim wrote:
> On 2003-08-31 12:48:20 +0200, si...@FreeBSD.org wrote:
> > On 2003.08.31 00:09:47 -0700, Colin Percival wrote:
> >=20
> > > installing sendmail/qmail/exim/portfix/nothing and
> > > bind/djbdns/nothing; for=20
> >=20
> > Bernsteins programs can't be distributed, since we are not allowed to
> > distribute modified binary versions.
> >
> > Besides, sysinstall in 5.x actually allows to install exim/postfix to
> > use instead of sendmail. Sysinstall doesn't remove sendmail, but it's
> > just not used.
>=20
> Where is this option?
Configure -> Networking -> MTA
But it was actually committed after 5.1, so it hasn't been in any real
FreeBSD release yet, only -CURRENT snapshots. I should have been more
clean about that.
--=20
Simon L. Nielsen
FreeBSD Documentation Team
--pY3vCvL1qV+PayAL
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/Uns3h9pcDSc1mlERAirvAJ9FNOB9NwIppY9mNUraLNxPttKGsQCghIAQ
d4AJ0iTC+reLL5SMrKLu7cQ=
=zE+i
-----END PGP SIGNATURE-----
--pY3vCvL1qV+PayAL--
Jeremy C. Reed
> As stated in the archives, bind can't just be removed due to the
> resolver code being used in libc.
Then just that "resolver" code could be used (and not entire BIND suite).
> > installing sendmail/qmail/exim/portfix/nothing and bind/djbdns/nothing; for
>
> Bernsteins programs can't be distributed, since we are not allowed to
> distribute modified binary versions.
Or another alternative is his resolver code. His low-level DNS resolver
routines are in "public domain".
Has anyone integrated djb's public domain resolver code into libc?
Jeremy C. Reed
http://bsd.reedmedia.net/
Terry Lambert
> On Sun, 31 Aug 2003, Simon L. Nielsen wrote:
> > Bernsteins programs can't be distributed, since we are not allowed to
> > distribute modified binary versions.
>
> Or another alternative is his resolver code. His low-level DNS resolver
> routines are in "public domain".
>
> Has anyone integrated djb's public domain resolver code into libc?
I didn't see that the djbdns license declared it to be in the
public domain.
I looked at trying to use this, but there were a number of
problems:
1) As far as I can tell, it's not *all* in the public domain.
2) The interfaces are incompatible with historical ones.
3) In accordance with his standard diatribe on SRV and other
new record types, he only supports address records, MX,
and TXT records, which is less than useful in the real
world.
All of these are pretty much show-stoppers, as far as I'm concerned:
1) License is incredibly important to most of us.
2) I don't want to have to rewrite all the software in the
world to use the new API; even if I wanted to, and was
willing to, doing so would make it incompatabile with
any standard UNIX system which does not also have Dan's
library loaded on it.
3) I can't live without SRV records.
-- Terry
Jeremy C. Reed
> > Or another alternative is his resolver code. His low-level DNS resolver
> > routines are in "public domain".
> >
> > Has anyone integrated djb's public domain resolver code into libc?
>
> I didn't see that the djbdns license declared it to be in the
> public domain.
I am not sure where either. But DJB noted to bugtraq
<2002070416424...@cr.yp.to> a while back that:
The .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c,
dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c,
dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c,
dns_txt.c) and all necessary lower-level .[ch] files are now in the
public domain.
This is also mentioned at http://cr.yp.to/djbdns/res-disaster.html
Looking at this source (djbdns-1.05), I don't see any copyrights or
licenses in any of these individual files.
> 3) In accordance with his standard diatribe on SRV and other
> new record types, he only supports address records, MX,
> and TXT records, which is less than useful in the real
> world.
I have no answer; I do not (knowlingly) use SRV records.
> 2) I don't want to have to rewrite all the software in the
> world to use the new API; even if I wanted to, and was
> willing to, doing so would make it incompatabile with
> any standard UNIX system which does not also have Dan's
> library loaded on it.
I haven't looked at it closely. I just read that it is "designed to
replace the old BIND res_*/dn_* library" at
http://cr.yp.to/djbdns/blurb/library.html.
I don't know how easy it would be (or if it would be worth it) to create
wrappers.
Anyways, I am curious if anyone uses it (or has tried it) as an
alternative.
Jeremy C. Reed
http://bsd.reedmedia.net/
_______________________________________________
Terry Lambert
> On Mon, 1 Sep 2003, Terry Lambert wrote:
> > > Or another alternative is his resolver code. His low-level DNS resolver
> > > routines are in "public domain".
> > >
> > > Has anyone integrated djb's public domain resolver code into libc?
> >
> > I didn't see that the djbdns license declared it to be in the
> > public domain.
>
> I am not sure where either. But DJB noted to bugtraq
> <2002070416424...@cr.yp.to> a while back that:
>
> The .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c,
> dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c,
> dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c,
> dns_txt.c) and all necessary lower-level .[ch] files are now in the
> public domain.
>
> This is also mentioned at http://cr.yp.to/djbdns/res-disaster.html
Yes, I saw this note at that location. However, I did not see
a claim and then a disclaim in the source files themselves.
> Looking at this source (djbdns-1.05), I don't see any copyrights or
> licenses in any of these individual files.
Exactly. Berne states that any files not explicitly disclaimed
by the author are inherently copyright the author, and without an
explicit disclaim by the author of record stating that it's in the
public domain, or a license, the code is not legal to use, since
nothing gives me any rights to it.
> > 3) In accordance with his standard diatribe on SRV and other
> > new record types, he only supports address records, MX,
> > and TXT records, which is less than useful in the real
> > world.
>
> I have no answer; I do not (knowlingly) use SRV records.
Too bad. They are required for zeroconf, and "Rendevous".
> I haven't looked at it closely. I just read that it is "designed to
> replace the old BIND res_*/dn_* library" at
> http://cr.yp.to/djbdns/blurb/library.html.
Yes, in about the same way that Windows NT was designed to replace
UNIX. 8-). Not plug compatible...
> I don't know how easy it would be (or if it would be worth it) to create
> wrappers.
Doing so would actually defeat his purpose in creating his new
API, at least according to the page you referenced on his site.
> Anyways, I am curious if anyone uses it (or has tried it) as an
> alternative.
I looked at it. The API is "OK", though it's not inherently
thread safe, unless you implement thread local storage, or open
a socket per outstanding request, either of which are not nice.
It's inherently reentrant, so in theory it could be made thread
safe relatively easily, if you wanted to put in the effort.
With no license attached to the code, though, it was uninteresting
to me to adopt a new API, when I could write my own and not be
under the license cloud, at the same time maintaining binary
compatability. 8-).
-- Terry
Christer Solskogen
> On Mon, 1 Sep 2003, Terry Lambert wrote:
>
>> > Or another alternative is his resolver code. His low-level DNS
>> resolver
>> > routines are in "public domain".
>> >
>> > Has anyone integrated djb's public domain resolver code into libc?
>>
>> I didn't see that the djbdns license declared it to be in the
>> public domain.
>
> I am not sure where either. But DJB noted to bugtraq
> <2002070416424...@cr.yp.to> a while back that:
>
> The .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c,
> dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c,
> dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c,
> dns_txt.c) and all necessary lower-level .[ch] files are now in the
> public domain.
>
How about the compat libs?
compat is in ports and in /usr/src, right?
Is there a reason why?
--
Med vennlig hilsen / Best regards
Christer Solskogen
http://dtz.cjb.net - http://carebears.mine.nu
"Cheap, but not as cheap as your girlfriend!"
-Spider Jerusalem
_______________________________________________