Not logged in
Log in now
Create an account
Subscribe to LWN
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
Surely that means that the package system is too complex and requires dedicated experts to get it right.
Free is too expensive (Economist)
Posted Mar 31, 2012 8:51 UTC (Sat) by angdraug (subscriber, #7487)
Actually, authors do get it wrong on occasion, and even when they don't, lack of coordination between different interdependent project often makes it unnecessarily hard for the latest versions of their programs to co-exist. Distributions are the only place where this kind of coordination happens.
And no, static compilation is not a solution, people do care how much memory their applications use (observe Mozilla's and LibreOffice's tremendous efforts towards that goal), and they shouldn't have to upgrade all their applications just because a vulnerability was discovered in one of the fundamental libraries.
Yes, the package system is complex. It has to be, because it's solving a complex problem. And yet, it's not that hard to use: there's a lot of good documentation and a lot of tools that automate the packaging, maintainance, building, inspecting your packages for common problems, and even basic integration testing.
A much larger part of the problem is created by the increased rate of change and a growing disregard for backwards compatibility in projects that are essential to Linux desktop and development experiences. That's what jcm is talking about in the first comment in this thread: many projects haven't yet realized that becoming part of our platform carries a certain responsibility to the users, and changes the balance between the benefits of rapid development and backwards compatibility.
Posted Apr 1, 2012 8:10 UTC (Sun) by pabs (subscriber, #43278)
Posted Apr 2, 2012 9:07 UTC (Mon) by michaeljt (subscriber, #39183)
I may be completely off here, but I suspect that most libraries are so small (taking into account that parts of them won't be used by the application) that static linking won't be a big problem, and that many of the remaining libraries will be sufficiently exotic that only one or two applications will be using them anyway, and the gains from dynamic linking will be minimal or not. So it might be worth thinking of strategies to deal with libraries which don't fall into either category (like the Gtk+/Qt complexes, which in any case don't take well to multiple versions in use on a single system - perhaps using the system Python interpreter to access the system versions?)
Regarding vulnerabilities, perhaps this could be solved by distributing applications compiled but unlinked, so that just the vulnerable library needed to be updated? One might even find some half-way house between the way free software distributions work now and a fully do-it-yourself approach which would let multiple pieces of software get updated together. Though I suspect that for most software smaller than Mozilla or LO the gain would probably not be worth the effort.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds