| |||||||||||||
Wheeler: Insecure open source software libraries?Wheeler: Insecure open source software libraries?Posted Apr 9, 2012 9:23 UTC (Mon) by khim (subscriber, #9252)In reply to: Wheeler: Insecure open source software libraries? by nix Parent article: Wheeler: Insecure open source software libraries?
Distributions *do* push new library versions out aggressively. No, they don't. Specifically, they push out security fixes, Usually, but not always. YMMV, as usual. and they push out publically released ABI/API changes when and only when there are things in the distro themselves that depend on them. IOW: they most definitely don't “push push new library versions out aggressively”. They do it only when it's convenient for them. Note: I don't see this as anything “wrong” or as “something which should be fixed”. But since they don't usually push new library versions out aggressively it's often easier to bundle new version of the library with your program rather then try to persuade distributions to do that for you. If you don't do the latter, you end up being trapped by things like the short-lived libjpeg7, which broke soname and required a massive relink only to change soname *again* and require another huge relink when you'd just finished the last one. Yup. This may be valid justification for distributions but what about poor applications which needed/wanted to use JPEG7 when JPEG8 was not yet available?
(Log in to post comments)
Wheeler: Insecure open source software libraries? Posted Apr 9, 2012 14:56 UTC (Mon) by nix (subscriber, #2304) [Link] Yup. This may be valid justification for distributions but what about poor applications which needed/wanted to use JPEG7 when JPEG8 was not yet available?Were there any? Major libraries with significant improvements (rather than the tiny ones in libjpeg7) will get packaged. Minor ones might not. In that situation, yes, you'll probably have to bundle them if unavailable on the distro -- but look at icculus's porting efforts to see how much work this isn't. This is really not as big a problem as you're making it out to be. (For games, at least, the state of Linux 3D support was much more of a problem until recently.)
Wheeler: Insecure open source software libraries? Posted Apr 10, 2012 9:43 UTC (Tue) by khim (subscriber, #9252) [Link] For games, at least, the state of Linux 3D support was much more of a problem until recently. That's because you can not bundle it with a game. The things which you can bundle (some kind of ffmpeg, lua or mono, etc) are just bundled without any considerations for the distribution's plight. You don't hear cries about games from the distribution packagers not because they don't bundle as much as Chromium is bundling, but because games mostly are from the “proprietary commercial software” category and as such is ignored by distributions totally. One example: World Of Goo. List of bundled libraries includes libSDL and libogg, zlib and libpng… Everything is bundled. Only three libraries are not bundled: GLibC, libstdc++ and libGL. And that's because you can not really bundle them: libGL is hardware dependent and for technical reasons usually needs shared GLibC and libstdc++… Some game developers try to play by distribution's rules and usually are burned: it's much harder to install these games because the libraries they require are just not there.
Wheeler: Insecure open source software libraries? Posted Apr 10, 2012 10:41 UTC (Tue) by Cato (subscriber, #7643) [Link]
Good point about some games that don't bundle libs - this might be what happened to me with Crayon Physics Deluxe (in one of the Humble Indie Bundles), as I couldn't easily get it working on Linux and ended up using Windows.
Wheeler: Insecure open source software libraries? Posted Apr 12, 2012 15:26 UTC (Thu) by nye (guest, #51576) [Link]
>Only three libraries are not bundled: GLibC, libstdc++ and libGL. And that's because you can not really bundle them: libGL is hardware dependent and for technical reasons usually needs shared GLibC and libstdc++…
Probably not co-incidentally, that also appears to be a more-or-less exhaustive list of libs which care deeply about long-term ABI compatibility. And I'm not so sure about libstdc++.
(I'm semi-joking, but mostly not)
|
|||||||||||||