Re: Observation re third parties supporting Debian kernels
On Sun, Sep 25, 2005 at 03:58:31PM +1000, Andrew Pollock wrote: 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... I think that a few things are worth noting. Firstly, it is pretty common practice amongst Linux distributions to ship multiple flavours (though they might be called other things) of the same kernel for the same architecture. I am pretty sure that Red Hat do this, well at least they used to. They do it in a slightly different way (I'm not going to be drawn on saying more than that :) way. But its much the same thing from a vendor point of view. The reason this is done is simple, performance. People want it, and there is a school of thought that having various flavours is the way to go. I believe that the Ubuntu kernel people are looking into just how much the performance win is, and if it is worth it or not. The Debian kernel team would certainly be happy to trim down the number of flavours if it turns out the optimisation value is slim. But I think at the least you are going to have a cover-all (in i386 terms that probably means 386 or 486) kernel that runs on everything and an optimised (in i386 that probably means p4 or pIII) kernel that works faster on a hardware that is in wide-spread use. Secondly, the Kernel ABI changes, so unfortunately this means the ABI presented by distributions changes. This happens at least every time the upstream kernel is changed (e.g. 2.6.12-2.6.13). Distributions tend to try and avoid ABI changes between upstream changes, but sometimes they are unaviodable. ABI changes hurt because external modules have to be recompiled. In Debian these changes are managed by an ABI number in the kernel package (this was missing for some architectures, such as powerpc in Sarge, but should be there for all architectures in Etch). This at least allows people to control the change - essetianlly they have to opt to get a kernel with a new ABI installed. And as for why the ABI changes, upstream have stated repeatedly that this is just they way they opperate and people who want their drivers supported should get them into the kernel, and make them GPL. If a vendor doesn't want to play that game, unfortunately they get the cold sholder from kernel upstream. And there is only so much distributions can do to soften that. And frankly, if their code isn't GPL, well, you heard what Christoph had to say... Lastly, as Sven mentioned, Debian does have infastructure to allow out of tree modules to be built. Its not perfect, but I think its superiour to a lot of other distributions support. Improvements are always welcome, but I think that the main problem here is a communication issue, not a techincal issue. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
On Sun, Sep 25, 2005 at 03:54:14PM +1000, Andrew Pollock wrote: At the end of the day, I think we need to accept that we live in a mixed world of free and proprietary software. If the kernel team want to thumb their noses at the proprietary, then it may come at the cost of lost installations of Debian, which I think is a bad thing. Yes, but those guys need to play with the rules also, and produce something usable for debian, and not some ugly hack which works only on some random x86 flavour. Also, i beleive there is nothing arch-specific in their stuff, so they could as well enable support for more than just x86, at least for those arches they can easily get a build machine for. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
On Sun, Sep 25, 2005 at 08:16:51AM +0200, Sven Luther wrote: On Sun, Sep 25, 2005 at 03:58:31PM +1000, Andrew Pollock wrote: 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... Indeed. 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... Nope, we have the infrastructure, so they can easily enough produce real debian packages for all debian supported flavours. The idea is to : for a given set of architectures (probably i386 and amd64 for them, but maybe they could do powerpc and ia64 too), build-depends on the linux-headers-version package, which will : Mmm, this one is not active on 2.6.12 kernels, at least not in -8, we need to fix that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
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. And why should the kernel team support propritary software, especially where a better free alternative exists already? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Observation re third parties supporting Debian kernels
On Sat, Sep 24, 2005 at 12:58:40PM +0200, Christoph Hellwig 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. And why should the kernel team support propritary software, especially where a better free alternative exists already? That's the attitude I feared I'd find, but was hoping I wouldn't... In this particular instance, without being intimately familiar with CA's product, I can't readily comment on how it stacks up with SE Linux, it just *sounds* SE Linuxish from the description, and from how it was described at the product briefing. As I said, the nature of the software wasn't the point of this email, it could be doing something for which there isn't a comparable free product out there. At the end of the day, I think we need to accept that we live in a mixed world of free and proprietary software. If the kernel team want to thumb their noses at the proprietary, then it may come at the cost of lost installations of Debian, which I think is a bad thing. Taking the example of where I previously worked. I'd deployed a fairly nice to manage Internet gateway infrastructure using Debian. Due to a bit of nepotism, and general higher-up management decisions, we had CA Unicenter foisted on us. We didn't get a say in it. Of course, it was supposed to do all this fandanged stuff that we already had Nagios doing, but management wanted to to be able to name drop some commercial software to clients, rather than a mish-mash of this open source stuff. We're not able to fight a massive management reeducation/attitude readjustment battle, so we have to accept what we're given. The problem is, when said commercial software starts mandating what Linux distribution(s) it'll support, if the management push is for that commercial software, then if it doesn't support Debian, then Debian's going to be the loser, not the hundreds of thousands of dollars spent on the commercial software. So it doesn't matter that those of us that have to manage the Linux boxes happen to firmly believe that Debian's got a lower cost of ownership in terms of management than say Red Hat, management just see it as we want this $100,000 piece of software, and your Linux distribution choice is blocking that implementation. I'm sure I'm not the only person who's been in this situation. So, if you don't want to try and ease that pain, maintain the attitude you're currently expressing, but I don't believe it is in the best interests of our users to be so exclusive. regards Andrew signature.asc Description: Digital signature
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
