| |||||||||||||
Free is too expensive (Economist)Free is too expensive (Economist)Posted Mar 30, 2012 22:36 UTC (Fri) by robert_s (subscriber, #42402)In reply to: Free is too expensive (Economist) by jcm Parent article: Free is too expensive (Economist)
"We need to get out of the business of providing 20,000 packages in a distro and get into the business of providing a 100% stable OS platform for others to build upon."
Except in my experience almost 100% of the time the distribution packagers get it right and the application authors more often than not get it wrong.
You'll have to excuse me for not wanting to go back to the wild west of system management or maintain the systems of those who do.
(Log in to post comments)
Free is too expensive (Economist) Posted Mar 30, 2012 23:17 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] cyberax@cybnb:~$ sudo apt-get install photoshop Reading package lists... Done Building dependency tree Reading state information... Done E: Unable to locate package photoshopPersonally, I'm willing to sacrifice some usability of 'apt-get install' to get commercial applications and games on Linux.
Free is too expensive (Economist) Posted Mar 31, 2012 0:39 UTC (Sat) by ewan (subscriber, #5533) [Link]
To what end? If you want the experience of running Windows or MacOS, and you're happy with proprietary software, then there a a couple of perfectly decent ways of getting those experiences. I run Linux because of the things it does differently - we don't need another Mac OS, we have one already.
Free is too expensive (Economist) Posted Mar 31, 2012 7:19 UTC (Sat) by alecs1 (guest, #46699) [Link]
To what end? To have new KDE4 release in Debian at the same moment I have them in Windows, not 6 months later for example (this argument I've already given at least once in LWN).
I don't take notes, but I've seen it in other places too: source and Windows releases of software are at version x.2 while .deb file is at x.0. Also, beta builds are many times only available for Windows and OSX. Being able to run multiple versions is useful at times, but let's skip this argument as it's more complex.
Free is too expensive (Economist) Posted Mar 31, 2012 9:29 UTC (Sat) by niner (subscriber, #26151) [Link]
Strange. I usually have new KDE releases installed before the Windows packages are even ready. Just had to add the repository which is just a click on a Website with openSUSE's 1-click-install.
Free is too expensive (Economist) Posted Mar 31, 2012 19:19 UTC (Sat) by alecs1 (guest, #46699) [Link]
It's true that OpenSUSE has much earlier (better?) KDE support than Debian, but turning the discussion into a Debian vs. OpenSUSE would be bikeshedding*. My grief is not that that OpenSUSE has KDE earlier, but that _Windows_ has it earlier.
*but I'm pretty convinced OpenSUSE is lacking stuff that Debian has; after all, I left OpenSUSE and got Debian some years ago precisely because it was missing some packages Debian had.
Free is too expensive (Economist) Posted Apr 1, 2012 19:40 UTC (Sun) by robert_s (subscriber, #42402) [Link]
"Personally, I'm willing to sacrifice some usability of 'apt-get install' to get commercial applications and games on Linux."
Not interested thanks.
Free is too expensive (Economist) Posted Apr 2, 2012 11:33 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
Personally, I'm willing to include a stable platform and software installation mechanism that third party developers (including commercial ones) would be able to support and willing to use if it means that the market share of Linux, and thus the aggregate freedom of all people, goes up by an order of magnitude.
Free is too expensive (Economist) Posted Mar 31, 2012 5:53 UTC (Sat) by PhilHannent (guest, #1241) [Link]
"Except in my experience almost 100% of the time the distribution packagers get it right and the application authors more often than not get it wrong."
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) [Link] 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.
Free is too expensive (Economist) Posted Apr 1, 2012 8:10 UTC (Sun) by pabs (subscriber, #43278) [Link]
Excellent comment, thanks for bringing some reality to this discussion.
Free is too expensive (Economist) Posted Apr 2, 2012 9:07 UTC (Mon) by michaeljt (subscriber, #39183) [Link]
> 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.
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.
|
|||||||||||||