[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Observation re third parties supporting Debian kernels



On Sat, Sep 24, 2005 at 12:58:39PM +0200, Sven Luther wrote:
> On Sat, Sep 24, 2005 at 07:02:57PM +1000, Andrew Pollock wrote:
> > Hi,
> > 
> > I attended a product briefing at Computer Associates on Thursday, and one of
> > the products that was discussed more than demonstrated was something called
> > eTrust Access Control[1], which, from my interpretation, sounds like it
> > achieves something similar to what SE Linux probably does. That's not really
> > the point of this email though.
> > 
> > I asked one of the engineering types about their Linux support for this
> > product during one of the breaks. It can enforce a policy on Windows, a few
> > commercial Unix variants, and on "Linux". When I pressed the engineer on
> > what Linux distros were supported, it was just RedHat Enterprise Linux.
> > 
> > He did mention that they'd looked into supporting Debian, but slammed the
> > lid back down on it after they had discovered (and I'm paraphrasing)
> > "multiple kernels with the same version number".
> 
> Seems like uninformed non-sense, but then maybe due to the previous messy
> situation. I think these guys are lying when speakign about linux support
> anyway, and only mean linux/x86 anyway.

Possibly (uninformed). I didn't go into details with the guy. I don't even
know what version of Debian they'd looked at, and yes, Linux/x86 is
absolutely correct. These guys are coming from the world where there were
only commercial Unices, so in that case, there'd be one commercial Unix per
CPU architecture, so the model of distributing binaries would work. I'm not
suggesting that it's a good model...
 
> We provide the linux-headers apckage to make it as easy to build external
> modules against those kernels as possible, so it should be no real problem.

As I said to the guy from CA, they're probably best doing something like
what nVidia do with their binary video driver - compile a shim against the
installed kernel's headers, and have their binary crap talk to that, but I
don't know enough about their product...
 
> I agree that the pre-2.6.12 situation was messy, but the new common
> infrastructure should be no major problem for those guys.
> 

Well it'd be interesting to see if either party was interested in talking
about it...

regards

Andrew



Reply to: