On Thu, Aug 31, 2000 at 10:20:44AM -0400, Paul D. Smith wrote:
>
> %% Kurt Seifried <seifried@securityportal.com> writes:
>
> ks> One question: where is it explicitly stated that Debian backports
> ks> fixes and that one needs to read /usr/doc/*/changelog?
>
> I'll answer this on two levels:
>
> First, if you're writing an article on a subject for publication it
> behooves you to find this information, even if it's not explicitly
> stated. In other words, if you think to yourself "hey, that's strange,
> this system seems to be shipping old, security-problem-ridden code!"
> (which you basically said you thought in your article) then you should
> try to find out if that's really true. One excellent way to do that is
> by posting one simple message to this mailing list.
>
This assumes that it is a reasonable assumption that there might be
another explanation. I would argue that Kurt's assumption, though
incorrect, was reasonable.
Basically, you are forking development. There is now a version to be
found in all the standard places where you get the tar-balls, and
another version to be found in Debian. But they both have the same
version number. This is misleading information.
> If this had been done, you could have blasted Debian for documentation
> issues, while still performing a valuable service by educating people,
> via your article, on how Debian handles security updates :).
>
Granted.
>
> ks> I spoke to several friends, comp sci, one with a degree in
> ks> software engineering, and they all agree this is a horrible way to
> ks> do things (the software engineer went so far as to say "a little
> ks> piece of me dies everytime someon does something like that").
>
> Uhm. Can you provide more details about exactly what they're objecting
> to?
>
First, you are forking development. You are applying code from future
modifications to old software. This poses a significant risk of
introducing bugs which will not be reproducible anywhere except in a
Debian environment. This cuts off the non-Debian part of the open
source community in cooperating to resolve problems.
Second, you are duplicating effort. Even if your backports of bug
fixes can be cleanly applied to the old code, you still must test
them. In some cases, it will not be possible to apply these backports
cleanly. This will require development which has already been done in
the main fork.
Third, the effort you invest in this detracts from the effort
desperately needed to improve and develop open source software.
For these reasons, I find the claim that you are retaining stability
to be dubious. Perhaps it really works sometimes. I suspect,
however, that you have merely chosen another form of instability which
is perhaps more to your liking, but not necessarily to mine.
> Backporting specific fixes to earlier releases is not only not "a
> horrible way to do things", but is absolutely de rigueur in the
> industry.
You overstate this. Some very valuable improvements are indeed often
backported. Far more often, the answer to software problems is,
instead, get the latest version.
> You can't afford to put the entire set of potentially very
> destabilizing changes into a current or almost-current product!
How can you be so confident that your backporting/forked development
model introduces significantly fewer destabilizing changes? Have you
any statistics to validate this?
> Instead, you extract the most important fixes and port them back into
> the stable release so people can get the benefits of that specific fix,
> in a stable environment.
>
> Most everybody does this. Even the Linux kernel, for example.
Again, you overstate the case. While the 2.0 kernel tree continues to
be maintained, it only sees what its maintainers believe are the most
important fixes. Other issues which may be troublesome are ignored.
And I believe you are, somewhat, begging the question. How many
people running the 2.0 kernel chose it for new installations? Are
they simply running the 2.0 kernel because they choose not to fix what
isn't broken or, given a new system to set up, are they choosing a 2.0
kernel for its vaunted stability?
> Many of
> the packages which have security fixes announced on CERT, etc. provide
> patches for older releases in addition to saying that the latest release
> has fixed the problem.
>
Perhaps I misunderstand, but my impression of this is that the patches
for older releases, where present, essentially upgrade older versions
to newer versions.
> I just don't understand your friends' revulsion.
I do. And the world of programming would have had to changed a whole
lot more than I think it has for my concerns about this approach to be
satisfied.
--
David Benfell
benfell@greybeard95a.com
ICQ 59438240 [e-mail first for access]
---
There are no physicists in the hottest parts of hell, because the
existence of a "hottest part" implies a temperature difference, and
any marginally competent physicist would immediately use this to
run a heat engine and make some other part of hell comfortably cool.
This is obviously impossible.
-- Richard Davisson
[from fortune]
Attachment:
pgp5BCMUTXah4.pgp
Description: PGP signature