Re: draft of DebConf5 debian-kernel paper

[dann frazier <dannf@dannf.org>]

On Mon, 2005-05-30 at 23:47 +0200, maximilian attems wrote:
> On Mon, 30 May 2005, dann frazier wrote:
> 
> > hey,
> >   I posted a draft of a paper for DebConf here:
> >      http://people.debian.org/~dannf/debconf5/
> 
> cool
> 
>  
> >   If you have time in the next couple of days, please take a look and
> > tell me where I went wrong :)  I tried to talk about both day-to-day
> > type tasks, as well as some history and some notable stuff happening on
> > the list lately (kernel freeze, ABI issues, unified source package,
> > security support, firmware redistributability, etc).
> the bet on a stable abi is bad,
> please refer to Documentation/stable_api_nonsense.txt
> d-i needs to improve a lot in that aspect,
> nice to get those archive hacks, but showing wrong direction.

Thanks.  I think my statement that the ABI changes occasionally is still
accurate, since we actually haven't had to role the SONAME much.  I
hadn't read stable_api_nonsense.txt before, and after doing so I added
the following footnote:

        The upstream ABI interface policy does not discourage ABI
        changes.  In fact, changing an interface to resolve a security
        issue can have positive characteristics.  Quoting from
        Documentation/stable_api_nonsense.txt: ``Security issues are
        also
        a very important for Linux (SIC).  When a security issue is
        found, it is fixed in a very short amount of time.  A number of
        times this has caused internal kernel interfaces to be reworked
        to prevent the security problem from occuring.  When this
        happens, all drivers that use the interfaces were also fixed at
        the same time, ensuring that the security problem was fixed and
        could not come back at some future time accidentally.  If the
        internal interfaces were not allowed to change, fixing this kind
        of security problem and insuring that it could not happen again
        would not be possible.''
        

>  
> >   I'm very open to changes - new topics included.  I think a number of
> > people on this list will be there - if you'd like to co-present on one
> > of these topics (or one I didn't mention), let me know.
> 
> please mention the ongoing work of jbailey concerning
> the replacement of the initrd-tools by initramfs.

I've added a section on Jeff's initramfs work; mostly content lifted
from his wiki and what I've gleaned from irc.

Thanks for the suggestions!  I'll post a new version shortly.