Slashdot Mirror
Zero Install Project Makes 1.0 Release
tal197 writes "Zero Install, the decentralized cross-distribution software installation system, announced 0install 1.0 today after 8 years in development. 0install allows authors to publish directly from their own web-sites while supporting familiar features such as shared libraries, automatic updates, and digital signatures. Is this the end of the walled-gardens of traditional app stores and Linux distributions and the beginning of a true 'Web of Software'?"
Sadly, things now look like they're heading in exactly the opposite direction.
Having multiple copies of shared libraries is bad for the system memory profile, not to mention bad for leaving lingering bugs long after they have been fixed in the library's mainline code.
Which is why a solo approach to dependency management has sever limitations. Distros may have messy process, but they are on the right track in that a lot of collaboration, and the tools to make it smooth, is needed to do things right.
Someone had to do it.
No, he doesn't mean patch "because my application broke!"
You write an e-mail client.
You give it to your user in a .app. It's v1.03 of MacMailGarbage.app.
Now you release v1.04 of MacMailGarbage.app, your user has to download it.
Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users ... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04 .app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed HELO from the server, executing malware on the user's machine.
Now libssl has a security hole. If you don't release a new version of MacMailGarbage.app, your users will be susceptible to rogue SNMP connections, possibly by a MitM.
Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update your MacMailGarbage.app specifically, because the system-wide libpng they installed isn't the one MacMailGarbage.app is using. Firefox.app also needs updating, because it contains a bad libpng version.
You've made no new releases at all, but your users needed a new .app 3 times. And getting a .app from you doesn't make using any other software safe, as that other software could come in a .app with the same exact library exhibiting the same exact security hole, and so they could be hacked unless they update it.
Support my political activism on Patreon.
Now libsnmp is found to have a bug. Linux users update libsnmp. Apple users ... well, you have to rebuild MacMailGarbage.app with the new libsnmp, put it in the v1.04 .app, and ship it to your users. If you don't, then MacMailGarbage.app can be hacked by sending a deformed HELO from the server, executing malware on the user's machine.
You're assuming that Apple does not include such basic libraries in the OS. They do. It isn't normally an issue.
Now libssl has a security hole. If you don't release a new version of MacMailGarbage.app, your users will be susceptible to rogue SNMP connections, possibly by a MitM.
Again, SSL is a basic OS X API.
Now libpng has a security hole. Again, Linux users update libpng. Mac users have to update...
And again, PNG support is built into OS X. Not an issue. I understand your point in general, but 3 of the 3 examples you gave off the top of your head are not really issues at all. In practice, this is not a major concern for OS X developers or users.
As far as I am concerned, .app software packaging is a HUGE advantage that OS X has over both WIndows and Linux. I would not trade it away. It is one of those things that keeps me using OS X.
Not all rolling releases are binary-only. Gentoo lets you do source based if you want. Keywords let you use pulse audio on every application if you want, or not have that library at all on the system. It's fairly straightfoward how to keep multiple versions of a package as well. To get custom locations you can copy the ebuild to an overlay and change a couple of the options that get passed to the configuration tool if your into that sort of thing. There are also methods to use versions that are newer of older than the latest stable I don't see how it could get any more flexible unless you're going to do it all by hand or use a separate prefix for every application statically link to libraries within, but either of those options seems fairly inefficient.