No subject
Fri Dec 19 16:39:21 PST 2008
<div><br>You have me party wrong here. Prefered for me is that applications use distribution runtime reduced uploads for ISV's cost saving. <br><br>But in case of issues there needs to be a clean and effective system to override distribution runtime. So lets say no distribution gets glibc wrong there would be no need for a override to exist. Problem is currently LSB provides no system that ISV's can say if it don't work due to a distribution glitch they can do anything about it other than ship the runtime in all future versions of there application effectively expanding size of application and secuirty risks. Currently from a simple cost point of view 0install is cheaper. <br>
<br>If valid system for overrides and shared runtimes if user finds they need a lot of overrides to make LSB applications work in there distributions it a clear sign that things the distribution they selected is either being poorly maintained or running a lot of experminental stuff.<br>
<br>Blame goes where it belongs. LSB model currently means defective runtime in a distribution can end up blamed on the ISV not supporting that distribution. ISV is better not to support Linux at all than get in the middle of distribution politics.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
But I believe in the LSB's merits. I believe that we *can* rely on the LSB base system and the runtime it provides, as every other operating system's runtime is relied on. Let's not daemonize the distributors as unreliable because they, in theory, *could* break their compliance promises, but just trust their ability to build a reliable, stable runtime platform for third-party software, as many have proven long enough. Of course this means that each application will have to ship a copy of their dependencies that are not covered by the LSB, and of course this will mean duplication to a certain degree, but this is, in every case, preferable to a system that encourages a culture of distrust between third-party software providers on the one and distributions on the other side; with such a culture, such a source of hatred between core system developers and independent software providers, the rise of Linux will fail miserably.<br>
<br>
For this reason, please, reconsider the LSB as a reliable building block for the future of Linux software deployment. Otherwise, I see no further ground for our discussions.<br>
<font color="#888888"></font></blockquote><div><br>Problem you are not getting here. Current design LSB design is unreliable. Not all distributions have good maintainers this is a simple fact. People running like fedora a testing ground for experimental code of course will never be reliable platform for a LSB runtime. Even Ubuntu will use experimental patches.<br>
<br>This is the brick wall. ISV's don't want bad press like application does not work on Ubuntu so users go to competitor. Distributions even do manage to break compatibility with there own packages let alone LSB ones. Like installing applications that need mpeg processing and will crash with out it Ubuntu does this. Reson they altered a lib applications have all there dependances meet only one problem 1 of the dependances don't work.<br>
<br>Ok if Distributions never ever broke compadiblity with there own packages leading to applications failure you might have a leg to stand on that LSB can work.<br></div></div><br>I see LSB as something just by adding support for runtimes number 1 becomes a truly reliable system. Number 2 promtes runtime sharing between distributions.<br>
<br>Linux Standard Base is about bring distributions to a common core. Key objective of Linux Standard Base is to allow ISV's applications to operate on other distributions. Remember distributions themselfs are ISV's.<br>
<br>You line is exactly the same as saying I should trust that my harddrive does not fail so should not make backups of my data when you are saying I should trust distributions to get it right. I want a plan B. If plan A distributions providing runtime fails. I want a dependable fall back location in plan B. You cannot promise me plan A will not fail from time to time it has failed in the past and will fail in the future this is just the way it is.<br>
<br>Peter Dolding<br>
------=_Part_75706_12055018.1230132122193--
More information about the packaging
mailing list