Date: Sun, 19 Aug 2001 16:38:19 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Mike Meyer" <mwm@mired.org> Cc: <questions@FreeBSD.ORG> Subject: RE: IDS Message-ID: <000501c12908$072ab0c0$1401a8c0@tedm.placo.com> In-Reply-To: <15230.58997.927550.888016@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message-----
>From: owner-freebsd-questions@FreeBSD.ORG
>[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Mike Meyer
>Sent: Saturday, August 18, 2001 3:05 PM
>To: Ted Mittelstaedt
>Cc: questions@FreeBSD.ORG
>Subject: RE: IDS
>
>
>[Context lost to top posting.]
>
Applicable context that was lost was included in the respose posted.
>Ted Mittelstaedt <tedm@toybox.placo.com> types:
>> then please consider this carefully. We already have many ports in FreeBSD
>> that
>> have been abandonded by their maintainers and cause a lot of trouble for
>> users.
>
>We do? While I sometimes run into one that's broken, a note to the
Yes. It's not always immediately obvious because the Project tends to prune
them out or get them reassigned so you don't see them for long. For example,
did you ever know that there was once a port of Ingres that Julian maintained?
That got pruned a long time ago from FreeBSD 2 when they changed something in
FreeBSD that broke it.
You can argue all you want that nobody uses Ingres, but that is specious
because since it's not available, of course practically no one would use it.
Actually, I'll admit that Ingres is a bad example because it has a direct
replacement. And no, I'm not keeping a list, and yes ports that get
abandonded by one maintainer often do get picked up by another rather than
dropped. But sometimes it takes a few releases. For another example, I
remember when the OpenLDAP port was broken by some change in FreeBSD it took
at least one release for that to get fixed.
>maintainer ("make -V MAINTAINER" gets the email address) usually gets
>it dealt with. Things that fail to build on bento tend to get pruned
>if the maintainer doesn't deal with the problem.
>
>If you've got a long list of broken ports, possibly you should notify
>the various maintainers to see if you can get the problem fixed.
>
Generally I've found that simply waiting until the next FreeBSD version and
then trying again will take care of the problem because enough other people
complain about it. But, sometimes the problems aren't immediately obvious.
For example, take ucd-snmp. It's a long and involved and complex program. In
FreeBSD 4.1, it worked perfectly, I had it running for up to a year on a
router. In FreeBSD 4.2, it was changed to a newer version that built fine and
all that, responded to queries and all that. But, 6 months after upgrading
the router to 4.2 I discovered that every once in a while the snmp daemon
would go nuts, consuming all available free ram in the router. I looked into
what they had changed and discovered that the additions were totally
inapplicable to probably like 95% of the people would would ever want to run
it. So I went back to the older version and found a number of problems
compiling it, I eventually fixed those and got it built and it's been fine
ever since.
Now, it took probably 9 months for me to even document that a problem exists,
and verify that it wasn't due to the switch from 4.1 FreeBSD to 4.2 FreeBSD,
and by then version 4.3 FreeBSD was out, and the current ucd-snmp was yet an
even newer version. It's highly unlikely that reporting this to the ucd-snmp
developers will get anyone to investigate because I never found the trigger
and I certainly can't put a buggy version back on a production router to
investigate further. Right now that router is up to version 4.3 and with the
old version of snmp on it, because I know I can trust that version. Maybe 2
or 3 years from now I'll try the version of snmp that's current then. But
I've spent probably 30 hours over the 6 months that the buggy version was
running just responding to customer complaints that were caused by it, not to
mention the time creating a fix, and at this point I can't spend any more
money on it, nor can I afford to risk the damage to the perception of
reliability of our network that testing the new version would cause. And
there's no other router I have that is a tenth as busy as that one, all of the
rest of our routers are running the newer version of snmp without problems.
For another example, how about all those ports that have error messages about
them being insecure, like uw-imap? What's that all about? I guess the
maintainer is so unresponsive there to fixing the security bugs that the
Project has just thrown up their hands in disgust and slapped in warning
labels.
Now, I don't want to give the impression that the FreeBSD ports collection is
full of bugs and trouble because it's not. All I'm trying to get across is
that when you or anybody decide to become a maintainer of a port, you need to
understand that by placing that software into FreeBSD, that your casting the
"veneer of
worthiness" on the software and that there's a lot of people who are going to
start looking at using this for production environments as a result. If you
are doing this on a lark, or conditionally to where you will stop doing it if
it takes up too much time, then your just setting up traps that are going to
harm those of us who start using your port. It would be better if the port
was never done because then we would be steered into other similar packages
who are maintained by people that _are_ committed.
Ted Mittelstaedt tedm@toybox.placo.com
Author of: The FreeBSD Corporate Networker's Guide
Book website: http://www.freebsd-corp-net-guide.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000501c12908$072ab0c0$1401a8c0>