Fedora opens up to bundling
The ups and downs of bundling
There can be any of a number of reasons for the bundling of software. Typically, developers of a large package want to have stable versions of important libraries to develop against; if they rely on libraries installed by others, they lose control over which versions are installed. Bundling can make the build process easier for others by freeing them from the need to chase down dependencies. Sometimes these projects have their own special patches that they apply to make a bundled library work the way they want. And sometimes bundling just seems like the easiest way to go, even if there is no particular need to do things that way.
Distributors, of course, would rather not distribute multiple versions of libraries, so they tend to push back against bundling. Multiple copies of libraries bloat the size of the distribution, of course, but they also raise security concerns: if a given library proves to have a vulnerability, the distribution must somehow locate and patch every version of that library it ships. In practice, that means that vulnerabilities can lurk for a long time in hidden copies of libraries; the "zlib" compression library has been particularly famous for propagating hidden vulnerabilities in distributions.
To avoid this kind of problem, Fedora has long had a strong policy against the bundling of libraries; if a library is used by more than one package, policy requires that library to be shipped as an independent package. Any exceptions to this rule had to go before the Fedora packaging committee (FPC) for approval, and that approval was often not forthcoming.
This intransigence with regard to bundled libraries has certainly had its intended effect: Fedora ships relatively few of them, and a number of upstream projects that bundled libraries have been fixed to not do so. But the policy also has its costs. Unbundling libraries is not always a trivial task, especially if patches have been applied by the project doing the bundling. Upstream projects may not be willing to accept the patches needed to successfully unbundle a library, with the result that Fedora ends up carrying its own private fork — a task for which few resources are available. The work required to undo bundling is such that, it seems, developers simply give up on the idea of packaging some programs entirely. Bundling issues are at the core of why Google's Chromium browser does not ship with Fedora, for example.
The bundle of straw that broke the camel's back this time around may well have been the darktable raw image editor. Darktable bundles a number of libraries, a fact that was first noted in a bug report in 2013. Over time, some of that bundling has been undone, but it still carries its own copy of rawspeed, a library for raw image decoding. The issue was brought before the FPC last July; the FPC rejected the request for a bundling exception in its July 9 meeting.
The interesting thing here is that the rawspeed library is evidently intended by its developer to be shipped as a bundled library; no effort has gone into distributing it as a system shared library. Some saw this decision as taking the anti-bundling policy too far; in response, Adam Williamson complained that the FPC went beyond its mandate:
As it happens, the FPC did eventually backtrack a bit and grant a temporary exception, good only for the Fedora 23 and 24 releases, to darktable; this was done because the "Design Suite" spin needs it. But a number of developers seemingly saw this incident as an example of the sort of collateral damage that the no-bundling policy can cause.
A proposal
Stephen Gallagher decided to do something about it; the result was, initially, this proposal to weaken Fedora's anti-bundling policy. In short, he proposed a change of rules such that, in cases where a package is unable to link against a shared system library, it would be allowed to bundle its own version instead with no special exception required. The proposal did require the packagers to occasionally nag the upstream project about fixing the problem. Unbundled libraries are still better, he said, but:
Stephen expected a lively discussion to follow from this proposal, and he wasn't disappointed. Some participants decried it as a surrender to poor practices that would end up burying Fedora in inferior bundled libraries. Others were cautiously positive, noting that, if users cannot get the software they want from Fedora, they will simply get it from elsewhere, possibly ditching Fedora entirely in the process. Still others got into the details of the proposed policy, suggesting various tweaks.
The result of that latter discussion was a new proposal, posted in early October. It made the policy somewhat more complicated, and, in particular, banned outright the bundling of software in critical-path packages. These are packages that are deemed to provide essential, core functionality; in practice, there are a lot of them in Fedora. Desktop environments, for example, are so designated. In cases where a non-critical-path package bundles a library, packages would be required to publicly contact the upstream community about fixing the bundling issue; if upstream declines to cooperate, then the bundled libraries could be shipped without a special exception.
This is the version of the proposal that was taken to the Fedora engineering steering committee (FESCo) for approval. When the minutes from the October 7 meeting were published, though, it became clear that what had emerged was a bit different. The policy approved by FESCo is relatively simple, reading, in full:
- All packages whose upstreams allow them to be built against system
libraries must be built against system libraries.
- All packages whose upstreams have no mechanism to build against system
libraries must be contacted publicly about a path to supporting system
libraries. If upstream refuses, this must be recorded in the spec file
using a persistent mechanism to be clarified in the packaging
guidelines.
- All packages whose upstreams have no mechanism to build against system libraries may opt to carry bundled libraries, but if they do, they must include Provides: bundled(<libname>) = <version> in their RPM spec file.
This text, which, among other things, entirely drops the "critical path" language, was arrived at in the meeting itself; it was not posted for discussion prior to its approval. That has led to charges that FESCo is acting in haste to try to resolve an issue that has been discussed for many years. It looks, to some, like a move to take some power away from FPC in response to a decision that some on FESCo didn't like, and a vote for packaging more software regardless of quality concerns. It would seem, though, that much of the community has accepted the view posted by FESCo member Adam Jackson after the vote:
So now the policy has been adjusted; the part about building the tools to track and manage bundled software, needless to say, will take somewhat longer.
Changing roles
In the end, this policy change may well reflect a realization that the role of distributors is changing and that distributions are becoming less central. The prominence of non-distributor packaging mechanisms is increasing; most language communities have such a mechanism, for example. Upstream projects are increasingly interested in shipping their software directly to users without having middlemen in the way. And the real elephant in the room, arguably, is containers, which, by their very nature, are large blobs of bundled software.
Distributors have been an important actor in the free-software ecosystem;
they see to the needs of users and provide an integrated, supported system
for easy use. The lessening of their role may thus not be without its
costs. But, if distributors are able to adapt to the changing
software-distribution environment, they should be able to provide a lot of
value for a long time to come. The policy change in the Fedora community
is an attempt to adapt in this way. Whether the new policy will be
successful remains to be seen, but one can easily argue that what came
before was not.
Posted Oct 13, 2015 20:54 UTC (Tue)
by hkario (subscriber, #94864)
[Link] (128 responses)
It's stupid, it's damaging and it's insecure, but sometimes you can't fix the world. Maybe after the containers will cause multiple CTOs and CIOs to get burned by old library versions we will see a shift, but it doesn't look like it will be any time soon.
Posted Oct 13, 2015 21:18 UTC (Tue)
by raven667 (subscriber, #5198)
[Link] (125 responses)
Posted Oct 13, 2015 22:22 UTC (Tue)
by cry_regarder (subscriber, #50545)
[Link] (4 responses)
Posted Oct 22, 2015 9:34 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (3 responses)
I use lilypond. Which is still stuck on Guile v1.
"cat input | guile > output"
Assuming all guile does is read from stdin and copy to stdout, unfortunately Guile v2 breaks the expectation that "input == output", and this breaks lilypond :-( In very subtle and hard-to-fix ways :-(
So this is another, pretty classic, example of a program with bundled dependencies because mainstream (no longer) provides features on which it relies.
For info, as I understand it, Guile v2 converts deprecated code points on the fly to up-to-date ones. All composite characters (eg a-umlaut, e-acute etc) are now deprecated and should be <compose><accent><letter> or whatever the correct version is. Lilypond assumes that a character offset in the input will point to the same character in the output, and of course if any of these conversions has happened, it breaks that assumption :-(
Cheers,
Posted Oct 22, 2015 13:26 UTC (Thu)
by wingo (guest, #26929)
[Link] (2 responses)
Before Guile 2.0, Guile's strings were byte strings -- like in Python 2. Guile 2 changed so that strings were composed of characters. To Guile, a character is a unicode codepoint.
When reading strings from a byte stream, as from an fd, those characters have an encoding, which is usually taken from your locale. In some encodings, like ISO-8859-1, all byte sequences are valid, so reading data in and writing it out will produce the same byte sequence. In others, like UTF-8, maybe Guile could read an invalid sequence. In that case it can error, or replace the character with "?", depending on what the application chose to do. Likewise when writing, it could be Guile tries to write a codepoint that can't be expressed in the desired encoding; at which point it can error or write a ?. The application decides what strategy to take.
There is no such thing as a deprecated codepoint.
Posted Oct 22, 2015 17:53 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
aiui, there is a unicode character for a-acute. There is also the sequence <compose><acute><a>. What are you going to do when one string uses one encoding, and another string uses the other? Apparently, the Unicode spec now says you are supposed to use the <compose> sequence, which Guile v2 implements.
Hence lilypond blowing up when what it thinks is a string COPY, is turned by v2 into a string TRANSLATION :-( Please note, that BOTH the input AND the output in this case are not some random encoding, but are quite explicitly Unicode character strings.
Cheers,
Posted Oct 22, 2015 20:18 UTC (Thu)
by wingo (guest, #26929)
[Link]
So when Guile reads a byte sequence which according to the given locale it decodes as U+0065 LATIN SMALL LETTER E followed by U+0301 COMBINING ACUTE ACCENT, those are the code points it stores internally. It does not normalize the codepoint sequence, although there are the string-normalize-nfc, string-normalize-nfd, string-normalize-nfkc, and string-normalize-nfkd procedures if the application chooses to do so, for whatever reason.
Posted Oct 14, 2015 3:10 UTC (Wed)
by josh (subscriber, #17465)
[Link] (25 responses)
s/ABI/API/. A standard ABI doesn't matter for distribution unbundling goals, because any software such a distribution would ship comes in source form, not binary form.
Posted Oct 14, 2015 15:29 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (24 responses)
If distros want developers to unbundle their dependancies then the distros need to start making some promises about compatibility, for 5-7 years, of the libraries they want developers to be able to depend on otherwise this doesn't fix the pressure toward bundling and containerizing.
Posted Oct 14, 2015 15:40 UTC (Wed)
by hkario (subscriber, #94864)
[Link] (23 responses)
But developers don't want to program to old API that is in a 2-3 year old distro. "Screw support, I need this newest and greatest feature from this unstable development branch of foobaz library."
You can't have the cake and eat it.
Posted Oct 14, 2015 16:37 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (9 responses)
Posted Oct 14, 2015 16:49 UTC (Wed)
by josh (subscriber, #17465)
[Link] (8 responses)
Posted Oct 14, 2015 17:45 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
Posted Oct 14, 2015 18:23 UTC (Wed)
by josh (subscriber, #17465)
[Link] (1 responses)
Posted Oct 14, 2015 18:36 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 17, 2015 13:32 UTC (Sat)
by krake (guest, #55996)
[Link] (4 responses)
In my opinion, the mistake was to standardize on what was already shipped, instead of specifying what should be shipped.
Basically catering to the wishes of the distributors instead of the needs of the developers.
Posted Oct 18, 2015 2:41 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Oct 18, 2015 8:56 UTC (Sun)
by krake (guest, #55996)
[Link] (1 responses)
Instead of providing something that developers would want to develop against, they choose to specify something that distributors are automatically in compliance with.
Of course that is great for marketing, but rather useless for engineering.
Posted Oct 18, 2015 9:13 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
LSB should have realized that the GUI toolkits in Linux can't be standardized, except at the lowest level (X-server or Wayland). And as for the startup system and configuration, LSB tried to be as flexible as possible to accommodate all distributions, so it ended up less than useful for all of them.
Posted Oct 22, 2015 9:39 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
> Basically catering to the wishes of the distributors instead of the needs of the developers.
Sort of yes ...
They shouldn't have standardised on what was shipped, they should have standardised a way of describing what was required...
I tried to get them to do that - the example I give is I wanted to create an LSB virtual package that would pull in the components required by WordPerfect. That approach would have been great - an app developer just specifies the pre-requisites and leaves it to the distro to ensure they are met.
What's the point of describing what's there, if there's no way of prescribing what's needed?
Cheers,
Posted Oct 15, 2015 10:19 UTC (Thu)
by NAR (subscriber, #1313)
[Link] (11 responses)
Of course, there's still the classic problem of "I want old stable version of everything except the browser which I want the latest", but the browser depends on newer libraries, so I have to upgrade everything. Unless the distributions start to support all versions of all libraries during their lifetime, application software will bundle their libraries. As they generally tend to lack manpower, I doubt this will come to pass.
Posted Oct 15, 2015 15:50 UTC (Thu)
by josh (subscriber, #17465)
[Link] (7 responses)
Assuming you don't have specific feature requirements that necessitate a more recent version, you should use 1.54 on Ubuntu LTS, 1.49 on SuSE, and 1.55 on Debian stable. (Hopefully the C++ ABI will stabilize to the point that if you *really* want to build just one version for all distributions, you can build against the oldest you support and run with any newer version. But when you build as part of a distribution, you use that distribution's package and whatever version it provides.)
Posted Oct 15, 2015 18:14 UTC (Thu)
by ms_43 (subscriber, #99293)
[Link] (1 responses)
Well, most of boost is header-only anyway, so the bundling is fully automated by cpp.
Posted Oct 15, 2015 20:18 UTC (Thu)
by josh (subscriber, #17465)
[Link]
Posted Oct 16, 2015 13:21 UTC (Fri)
by NAR (subscriber, #1313)
[Link] (2 responses)
Posted Oct 16, 2015 16:33 UTC (Fri)
by josh (subscriber, #17465)
[Link]
Posted Oct 16, 2015 16:45 UTC (Fri)
by bronson (subscriber, #4806)
[Link]
Posted Oct 16, 2015 16:27 UTC (Fri)
by stevem (subscriber, #1512)
[Link] (1 responses)
*giggle* Sorry, that's just pure comedy...
Posted Oct 16, 2015 16:34 UTC (Fri)
by josh (subscriber, #17465)
[Link]
Posted Oct 17, 2015 19:33 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (2 responses)
None of the above. Use a sane library that offers a proper interface and keeps it stable across releases. Then you can pick the feature set of the oldest version you want to support and it will continue to work on all later versions.
Even if all distributions had the exact same version of boost, that wouldn't solve your problem. When boost version n+1 gets released and included in distributions, your stuff would still break unless someone commits to maintaining old boost versions indefinitely. Distros won't (and can't) do that with an upstream that is as hostile to backwards compatibility as boost.
Posted Oct 21, 2015 16:12 UTC (Wed)
by rwmj (subscriber, #5474)
[Link] (1 responses)
Posted Oct 21, 2015 17:43 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Posted Oct 18, 2015 10:57 UTC (Sun)
by paulj (subscriber, #341)
[Link]
Posted Oct 14, 2015 4:21 UTC (Wed)
by xtifr (guest, #143)
[Link] (62 responses)
When library developers refuse to follow best practices at keeping backwards compatibility, and proper versioning, then maybe app developers should think twice about depending on such poorly maintained libraries in the first place.
And if the app developers want to use poorly maintained libraries anyway, they either need to step it up and maintain their own forks of the libraries, including handling any security issues that may arise, or they need to admit that their software isn't good enough to be included in any decent distribution!
Trying to put the blame on the people making the distribution for the idiocy of the library developers is really bad form. Trying to blame the people making the distribution for your own idiocy is even stupider.
There is no excuse for bundling ever, period, end statement. If the upstream libraries aren't good enough you either need to fork or find a replacement. And if you're going to fork, because the upstream developers of the library aren't good enough, then fork good and hard!
And stop blaming your fellow victims.
Posted Oct 14, 2015 5:51 UTC (Wed)
by marcH (subscriber, #57642)
[Link]
In other words you need: either infinite time, or an ideal world with plenty of quality replacements to choose from.
I'll take both.
Posted Oct 14, 2015 5:54 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (34 responses)
Security issues? Who cares, just update all the libraries once in a while. Utilize OS-level sandboxing and exploit protection to help mitigate the usual exploits.
Nobody's going to target your small app specifically, anyway. And if it ever grows big, then sign for your libraries' mailing lists and monitor them for security announcements - in practice that's at most a couple of issues a month for a complicated project. It's so much easier to deal with occasional (and usually ABI-compatible) updates than with the constant headache of 6-month distro release cycles.
Stop worrying about security. Instead, focus on FEATURES that benefit your users.
--
Posted Oct 14, 2015 6:57 UTC (Wed)
by Karellen (subscriber, #67644)
[Link] (4 responses)
If not, or for the benefit of those who actually think like this - security *is* a feature that benefits your users. If you do not think so, I sincerely hope I'm never in the position that I need to use any of the software you've had any significant hand in.
Posted Oct 14, 2015 7:54 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Of course, security is a feature. But it's rarely the central feature of an app (with obvious exceptions like payment or banking apps). And as I've said, most security problems attributed to bundled libraries are way overblown.
Bundling is here to stay. Distributions should stop fighting it and instead should concentrate on making it safer.
Stop the war on drugs^W bundling, legalize safe bundling!
> If you do not think so, I sincerely hope I'm never in the position that I need to use any of the software you've had any significant hand in.
Posted Oct 14, 2015 9:10 UTC (Wed)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Oct 14, 2015 17:50 UTC (Wed)
by alankila (guest, #47141)
[Link] (1 responses)
The problem is exact behavioral stability -- software is so fragile that any changes to the environment, no matter how benign or useful -- risks breaking the software. The API can be the same, all it takes is some little race condition, or some change to the behavior of the underlying functions, and boom! breakage results. To keep software working, we basically have to choose between "features that function" and "has useful things like security updates".
Linux distributions have, so far, prioritized security updates, and the feasibility of tracking them. However, I still think that the only right solution is severe hardening of the operating system such that minor problems and buffer overflows in the application or its libraries can only have a limited security impact. It is far more useful to get away from the "egg" security model, aka "the hard shell and soft interior" model than it is to design elaborate update protocols and security requirements that assume we can find the bugs and then patch them without breaking the software in the process in the first place.
So yeah, bring us bundling, but also bring us a security model that ensures that even if there is a buffer overflow or whatever security issue that permits arbitrary code execution, it at best destroys that application's data rather than compromises the entire user account.
Posted Oct 14, 2015 17:55 UTC (Wed)
by hkario (subscriber, #94864)
[Link]
https://xkcd.com/1200/
Posted Oct 14, 2015 7:55 UTC (Wed)
by jezuch (subscriber, #52988)
[Link] (4 responses)
In other words, everyone needs to be their own distribution?
Posted Oct 14, 2015 8:12 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 14, 2015 8:34 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
The most complicated part in a real distro is forcing all the different software packages play together nicely. You sidestep this whole mess, since you usually care only about just one app. You also don't need the startup/shutdown infrastructure and all the thousands packages for all of the free software.
Posted Oct 14, 2015 9:52 UTC (Wed)
by hkario (subscriber, #94864)
[Link] (1 responses)
developers have already proven that they are not capable and do not care enough to provide good support for bundling, be it in form of direct source bundling or container images
Posted Oct 14, 2015 14:57 UTC (Wed)
by drag (guest, #31333)
[Link]
There is nothing within a distribution's power to fix ruby so that it's trivial to upgrade without breaking anything.
There is not enough manpower in the distribution to rewrite ruby to make it 'sane' and there is not enough manpower to package every possible version of every possible library needed by ruby applications and maintain properly.
If you want to make a distribution that forces developers to 'behave' you are going to behave then it's going to have to prevent people from using any ruby/python/java/C/C++/etc application that isn't pre-packaged by the distribution. Doing this will effectively make the OS worthless to the majority of people.
The reality is that if you want to run your applications on Linux you can't depend on distributions to provide everything you need. Linux distributions are not capable of providing all things needed.
> developers have already proven that they are not capable and do not care enough to provide good support for bundling,
This is not necessarily a issue that rests entirely with the developers. The fact that installing and maintaining software on Linux is such a huge pain in the ass that they don't have the time to deal with it is a big issue as well.
I think the solution to these problems is to see how people want to use the OS and then make it easy for them to do so. For example: provide tools that makes it easy to install software from upstream and maintain those installations without forcing everybody to go through distribution repositories. Security concerns should be addressed not by forcing everybody to use distribution-provided dependencies, but by having tools that analyze software and look for library versions and other things that are known issues. You will never be able to create a 'perfect' solution to these problems, but you can provide a realistic one.
Posted Oct 14, 2015 17:20 UTC (Wed)
by tpo (subscriber, #25713)
[Link] (23 responses)
> Security issues? Who cares, just update all the libraries once in a while. Utilize OS-level sandboxing and exploit protection to help mitigate the usual exploits.
The perspective from the other side - the user side - might be different.
As a sysadmin I see software that I need to maintain that:
* bundles half the world
It makes me vomit. Every piece of such software lives in it's own special snowflake world. Consistent config management is impossible. Consistent version control is impossible. Consistent log management is impossible. Consistent backup procedures are impossible. Updating the environment is extremely brittle and risky. Migrating the software to a new platform is hit or miss. Security it a complete unknown. Which directly limits the use of such software to amateur environments, or you need guarantees that the vendor will not give you. The cost of completely ignoring best practice (== distro standards) is very high for the sysadmin.
As a end user I see software that bundles the whole world. Each piece of shit bundles its own Java. Do taxes for 2014? 100 GB, there you go. And 2015? Another 150 GB. You moved to a different town? And so on. And you need to back that crap up as well.
And there are appliances and hardware devices. The device has some bug? Bad luck. Your environment evolves and the device should be adapted accordingly? Bad luck! You know it's based on some Linux or library with known exploits? Bad luck!! The device is running out of some resources under your operating conditions? Bad luck!!!!
Then there's the ilk of web apps. Each comming with it's own ruby, gems, php, rails version, java script and ruby libraries, hard dependencies on some version of xml headers and mysql headers and so on. Never mind those are write once and forget because no one will ever care to update or maintain that crap. It's the router firmware plague of web apps. If I'd had to crack some company then I'd start by having a look at their "content management system".
Don't misunderstand me - I do believe that it is possible to maintain a bundle containing the full software stack of some application well - Chrome might be an example. On the other hand it is also possible to maintain a package for the top half dozen of popular distros and platforms well. Both of these approaches come with non-negligible costs.
But it's arguably far easier to bundle together some random mix of git checkouts, data and config files and libraries that just happened to work at the moment they were shipped and that was that. In my experience if some software has it's own non-distro-provided installer then it'll be gross with a very high proability.
So if you are preaching to the "elite" software developers backed by honest companies with a horizon of a dozen or more years to maintain their software and serious documentation and integration surfaces, then all the power to you.
I doubt however yours is a good advice to give to to Joëlle developer from Standard company - see my experience above.
Posted Oct 14, 2015 18:06 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
>* comes with it's own init system
>* logs into /usr/share/software
>* doesn't have the ability to log to rsyslog
>* has configuration at completely random places, sometimes indistinguishable from binary files
> It makes me vomit. Every piece of such software lives in it's own special snowflake world.
Posted Oct 15, 2015 7:29 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (21 responses)
Of course it does. The root reason for bundling is that a developer wants to take as many shortcuts as possible and avoid thinking at anything but his ego-boosting code. That's why a bundled environment is crap crap and more obsolete unsupported unsecured undocumented hastily patched crap. It's only there to allow the precious developer code to run, and any problem in the bundled substrate is "someone else's" problem.
If the developper could he would image his ide and ask users to push the run button there.
Log management and use of common system services is 200% in the "avoid work" zone.
Posted Oct 15, 2015 7:53 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
As long as she gets users, why not.
"The customer is always right" - and the thief impersonating him even more.
Posted Oct 15, 2015 12:01 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
Posted Oct 15, 2015 8:01 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
Posted Oct 15, 2015 18:49 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (17 responses)
Posted Oct 15, 2015 21:00 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (16 responses)
Just sandbox it to make sure it can't harm other apps.
Posted Oct 17, 2015 18:34 UTC (Sat)
by lsl (subscriber, #86508)
[Link] (15 responses)
Back in 2005, Raymond Chen wrote about the issues with putting old programs into a VM, so you don't have to maintain proper backwards compatibility. Short form: it doesn't really work that well. The specific problems encountered back then might be different from those of the new-fangled container sandbox approaches you see today, but the common theme is the same. Users expect their programs to interoperate.
http://blogs.msdn.com/b/oldnewthing/archive/2005/10/05/47...
And no, asking the user at every step of the way is not a solution.
Posted Oct 18, 2015 2:39 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (14 responses)
It's also possible to do the inverse - a browser can set up a protected storage for sensitive data which is not accessible to normal processes (it also automatically disables debugging for the sensitive process).
This is a far better approach than playing whack-a-mole with bugs where one single bug in an "Exploding Kittens" game might be enough to get access to ALL your files.
Posted Oct 20, 2015 22:15 UTC (Tue)
by javispedro (guest, #83660)
[Link] (13 responses)
That doesn't even start to cover all the holes that should be poked. What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.
Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...
There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.
And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.
> This is a far better approach than playing whack-a-mole with bugs where one single bug in an "Exploding Kittens" game might be enough to get access to ALL your files.
But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Being an idealist, I still think that a system that doesn't encourage huge monster applications (and thus keeps bug numbers at manageable levels) is a much better approach.
Posted Oct 20, 2015 23:29 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
> What if you want to share a spell checker whitelist between Abiword and Libreoffice? What if you just installed the Zotero plugin and want to run it in both Abiword, Libreoffice, and Firefox, preferably with the same bibliography? Hidden file dependencies? etc.
> Even for compiling a single .c file the amount of required holes is mind-boggling. Or running a trivial NumPy number-crunching script. Or creating a basic plot with R. Or ...
> But sandboxing as it is done now usually involves making programs larger
> (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Posted Oct 22, 2015 9:54 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
> Nope. It'll only get access to that presentation and perhaps some recent files.
Cyberax, sometimes you need to "engage brain before opening mouth".
"One bug" == "pwned", and who knows what damage is done :-( If it has LO's permissions, then it can access all of LO's files. (Which for most users, is pretty much everything.)
(Incidentally, LO is not a monolithic blob. Although I'll admit it often feels like it ...)
Cheers,
Posted Oct 22, 2015 14:32 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
On Linux, a compromised document can slurp browser's history and secret storage and send it to nice folks in Nigeria.
Now, which model do you trust more?
Posted Oct 22, 2015 15:15 UTC (Thu)
by javispedro (guest, #83660)
[Link] (9 responses)
i.e. punch specific holes in the sandbox. Hard to do when there are gazillions of possible usecases, and most of them we don't even envision today.
> Command-line apps are somewhat special.
And this I disagree with. Specially in the context of a distro's packaging, command-line apps are _the norm_.
> Uhm? What?
Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.
Otherwise, something as trivial as copying and pasting a plot from the spreadsheet program to the word processing program using anything more advanced (i.e. vector, linking, etc.) than a shared .png file becomes a nightmare.
An example of this is iOS.
> Nope. It'll only get access to that presentation and perhaps some recent files.
Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files, esp. all of the text documents, the spreadsheets with financial data, presentations, drawings, the mailing list with all of your patients which you used once with your word processor, and the list of all words you've even written on any document so far (which obviously are only kept for "training purposes"), etc.
Posted Oct 22, 2015 22:52 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (8 responses)
> Because "command line apps are special", and because you break many of the common approaches which programs use to share data, you are encouraging developers to create "all-in-one" suites instead of collections of small programs (the so misnamed "unix way") and bigger shared libraries.
> Yeah... as well as any future file you open with that program, which for many users includes _ALL_ of the user's most important files
Please, educate yourself about the state of the art, at least.
Posted Oct 25, 2015 14:22 UTC (Sun)
by mp (subscriber, #5615)
[Link] (1 responses)
Through complex LSMs that NOBODY understands? Oh well.
Posted Oct 26, 2015 5:57 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
To be fair, in Mac OS X command line utilities invoked through exec() from sandboxed apps do have read-only access to Unix system directories, but they don't have access to users' directories.
Posted Oct 26, 2015 15:53 UTC (Mon)
by javispedro (guest, #83660)
[Link] (5 responses)
That's a _huge_ thing to say. How do you even know 6 months by now there won't be a usecase that needs direct access from your word processor to your phone?
Hell, I'm sure _I_ wouldn't bet against it!
> And so? App Store model works for most users.
NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.
> Sandboxing command-line utilities is also possible
> No, that's incorrect. Mac OS does not allow programs to store authorizations forever.
So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?
> Please, educate yourself about the state of the art, at least.
Please turn your brain on a bit before replying, as you've been told above.
Posted Oct 26, 2015 17:29 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> NO! You're affirming the consequent here. I'm precisely arguing that it does NOT work! And I even explicitly mentioned above how even MS has come to realize this.
> So I'll just infect the equivalent of normal.dot and reload myself on startup everytime. _A single bug on that binary compromises every further file saved by that binary_. Unless you want to prevent saving any state at all?
Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.
> Please turn your brain on a bit before replying, as you've been told above.
Posted Oct 26, 2015 19:55 UTC (Mon)
by javispedro (guest, #83660)
[Link] (3 responses)
> I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?
>> There's a reason unsandboxed new programs appear daily even on platforms where the default is to be sandboxed (such as Windows or OS X). Any current platform that only allows for sandboxed binaries (WinRT, iPad *cough*) falls straight into the "it's completely useless for any serious work" territory.
> You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.
> Please, explain how this is worse than the quagmire we have in Linux right now when a "dancing cows" LibreOffice document can send all your credit card info to Nigeria.
Posted Oct 26, 2015 20:16 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.
> Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria.
Also, AppStore model allows vendors to quickly make and QA a patch for a security issue. With distros you have to go through maintainers and slow release process. Then you have to do QA for multiple distro versions.
It's pretty clear which security model is more advantageous.
> Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.
Posted Oct 27, 2015 7:20 UTC (Tue)
by javispedro (guest, #83660)
[Link] (1 responses)
But you need _operating system_ updates in order to punch these new holes in the sandbox, not software vendor actions. And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux). Unless you're thinking final software developers will ship the list of sandbox holes they need, but while this is a very interesting approach for a user trusted catalog of software (e.g. distro repository) it does not seem valid for a general "app store" model.
Remember that I'm saying the Apple sandbox model does not even provide half of the holes required for even a mere office suite to work well. The only such program that I currently known working under the sandbox is NeoOffice, and they do trickery such as showing up an OSX open dialog pointing at the file it wants to read every time it wants to read some random file. They also disable all extensions and is generally a pain to use. And this is most probably an example of a program that in theory seems easy to sandbox.
> Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.
Sorry but we're going circles about this:
And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.
I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.
> Linux-style dependency management clearly doesn't work well.
Posted Oct 27, 2015 8:02 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
> And these introduce even more headaches, because punching new holes may break old software (or even new software, if we look into selinux).
> And in practice this is a much more common scenario than a malicious presentation reading your browser story -- see long tradition of Office viruses. After all, you've already compromised the office suite, so there's 0% additional effort in doing that, while there's sure to be some platform and browser-dependent code in reading browser history.
> I still believe in that a smaller programs model is much better for security, and that the App Store model clearly goes against smaller programs; if only because it becomes much harder to share data between programs.
So let's actually think about the threat model. Suppose I want to steal users' credit card information.
2) I have an exploit for LibreOffice itself. With a naïve distro model I simply need to hack LibreOffice and I instantly get access to browser's history with all the juicy CC info. With the sandboxed code I have to try and infect other documents, hoping that a user eventually opens a document with CC info.
So it appears that distro model provides no advantage here. Now, there might be a question of update speed. A distro might be able to update a shared library faster than a vendor can go through a full formal QA process. And that actually might be a disadvantage.
Posted Oct 14, 2015 6:36 UTC (Wed)
by ibukanov (subscriber, #3942)
[Link] (7 responses)
I think the only library on Linux that is really backward-compatible is the kernel interface. For this reason for software that is not a part of a distribution when developers provide binaries for the users on their own bundling is pretty much the only option. For example, I have found a convenience of static linking Go style is very hard to resist. Binary that just works on any Linux as long as the kernel in not too old makes life so much simpler.
Posted Oct 14, 2015 11:42 UTC (Wed)
by ms_43 (subscriber, #99293)
[Link] (5 responses)
This is quite wrong, there are certainly quite a few libraries that maintain very good ABI compatibility for the last 15 years now: glibc2, NSS, libxml2, glib2, various X11 client libraries, libGL come to mind.
The main problem is that it's not quite obvious which of the 100s of lib*.so on your system tend to be stable and which not.
There are some hints, like the LSB, which was intended as a solution to the problem and is actually implemented by most of the popular distributions (but notably not Debian).
For RHEL it's also documented which are the supported stable ABIs, you may note the "Compatibility level 1" list is rather short:
Sadly the most stable libraries are not necessarily the most popular, for example developers often prefer the volatile OpenSSL over NSS.
Posted Oct 14, 2015 18:30 UTC (Wed)
by xtifr (guest, #143)
[Link] (4 responses)
Far more than that if you consider bumping the version when incompatibilities are introduced to be part of maintaining compatibility. Bumping the version means that the old and new versions of the library can co-exist, which is and should be all that app developers need.
Posted Oct 14, 2015 18:49 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
It also means you must continue to support the old versions indefinitely.
Posted Oct 15, 2015 2:24 UTC (Thu)
by xtifr (guest, #143)
[Link] (2 responses)
Posted Oct 15, 2015 14:43 UTC (Thu)
by ms_43 (subscriber, #99293)
[Link]
From an application developer's point of view, anything less than 5 years after the new version is available is clearly unreasonable.
Posted Oct 15, 2015 15:54 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 14, 2015 13:01 UTC (Wed)
by lisandropm (subscriber, #69317)
[Link]
Posted Oct 14, 2015 10:16 UTC (Wed)
by roc (subscriber, #30627)
[Link] (12 responses)
There is huge value in delivering applications bundled with the library versions they have been most thoroughly tested with. That doesn't mean bundling is always the right thing to do, but failing to acknowledge the value of bundling makes you sound non-serious.
Posted Oct 14, 2015 18:27 UTC (Wed)
by xtifr (guest, #143)
[Link] (11 responses)
This is nothing more than saying that writing bug-free code is impossible. That's true but irrelevant. When a bug is found, it should be fixed. When a failure in backwards compatibility is found...
No one's asking for perfect backwards compatibility for ever and ever. When you need to change the ABI/API for your library in an incompatible way, you can bump the major version number, and now the old and new versions of the library can co-exist.
Posted Oct 14, 2015 18:44 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Oct 15, 2015 7:41 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
There is a high correlation between "having a sane run environment" (without bundling) and "being still there 5 years later".
Bundling-rich projects are shiny but tend to break under the technical debt they tried to hide in the bundled goo after a while. Their authors display full-rewrite tendencies aka I-care-about-something-else-now about the time the goo obsolescence becomes critical enough they can't ignore it anymore.
Posted Oct 15, 2015 7:59 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Oct 15, 2015 19:13 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link]
But in the FLOSS world, the bills is good reusable code since money is not reinjected in the system.
Posted Oct 15, 2015 0:29 UTC (Thu)
by roc (subscriber, #30627)
[Link] (5 responses)
... it's often too late, because you've already shipped, and your users are having a bad time.
> Then how come we've been able to get along so well for the last couple of decades without?
As someone who has observed a lot of bug reports due to library version skew with unbundled Firefox --- we have not been getting along "very well".
> I've seen countless security problems fixed in a whole set of apps by upgrading a shared library.
You've also seen countless security problems fixed by bundled-library applications updating the whole package. (It's worth keeping in mind that any application vendor who deploys on Windows or Mac or iOS or Android must bundle libraries, must monitor them for security issues, and must provide timely security updates for the entire package on those platforms, so for them, unbundling on desktop Linux reduces the work required by a negligible amount.)
> But I've seen less than a handful of apps have serious problems when a library is upgraded, and such problems have always been treated as a bug in the library
That's odd. In my experience, users blame the application when it doesn't work. E.g. when Firefox freezes on a Web page using HTML5 canvas, the user blames Firefox. They do not say "hey, this must be a bug in the system cairo library!" and complain to the cairo developers.
Posted Oct 16, 2015 23:56 UTC (Fri)
by dirtyepic (guest, #30178)
[Link] (4 responses)
So they complain to their distro Firefox maintainer who does have enough of a clue to say "hey, this is a bug in cairo" and gets it fixed in the library, a fix that solves the problem for everyone, including Firefox, which means one less problem you need to debug and fix yourself in your bundled copy when you get around to updating it.
Posted Oct 18, 2015 19:52 UTC (Sun)
by flussence (guest, #85566)
[Link]
Was it a bug in cairo? The gpu driver? The browser? We'll never know - like any sane person he didn't go through the ordeal of making Yet Another ****ing Bugzilla Account, he switched to Microsoft Edge and the problem vanished.
Similarly, my own quality of life has vastly improved since switching to Vivaldi; no more waiting literally minutes for the browser to open or pages to load. My netbook is *usable* again, imagine that.
And imagine trying to get anywhere by reporting *that* bug to *those* people.
(FWIW, I do make good use of my distro's bug tracker, but I've found trying to contribute to browsers is just an exercise in extreme masochism. It's better to let them fail.)
Posted Oct 18, 2015 21:33 UTC (Sun)
by roc (subscriber, #30627)
[Link] (2 responses)
Posted Oct 19, 2015 11:54 UTC (Mon)
by micka (subscriber, #38720)
[Link] (1 responses)
That would be the first time someone says getting fixes upstream is not something sane to do.
Posted Oct 19, 2015 23:14 UTC (Mon)
by roc (subscriber, #30627)
[Link]
Posted Oct 15, 2015 5:01 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
The software update is already widely deployed and the damage is done? It's not as if all the ABI breaks are intentional.
Posted Oct 14, 2015 10:34 UTC (Wed)
by andresfreund (subscriber, #69562)
[Link]
To me that's a simplistic portrayal. Maintaining ABI and API compatibility across major releases of a library has significant development and maintenance cost. I don't think anybody that has maintained such compatibility will say differently.
Which means one needs to judge between the advantages of maintaining compatibility and having the time to do other stuff, e.g. add new features. I do think that the balance shifts a bit too often towards the latter, yes. But your statement is far too one sided for me.
Posted Oct 14, 2015 15:31 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
You haven't developed for Windows (hell, even OS X for that matter) have you? Sure, for *nix, this makes sense, but that's not the end of the world.
I work on some apps that bundle, but they provide "use system version?" options for all but one or two of them. That's the better half-way point, but it's not perfect (and much harder than just plain bundling since you need to mangle symbols so as not to conflict with other bundled copies of the same library).
Posted Oct 17, 2015 5:25 UTC (Sat)
by cas (guest, #52554)
[Link] (1 responses)
The fact that it's common in Windows is not an excuse. certainly not a good excuse.
It's annoying in the Windows world, too. I have a win7 box which exists solely for the purpose of running Steam games, and I've bought several hundred steam games over the years. It's extremely annoying to have to go through the nvidia physx installer and Direct X installer and C library installer etc etc etc for almost every single one of those several hundred games.
It's worse than annoying, it's just plain stupid. I already have system copies of all those libs (and more) - i don't need or want more copies, or even to waste time while the installer figures out I don't need yet another copy in the game's own directory.
Posted Oct 17, 2015 17:29 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
> It's extremely annoying to have to go through the nvidia physx installer and Direct X installer and C library installer etc etc etc for almost every single one of those several hundred games.
These really are "system" libraries in the sense that they should be provided there (like OpenGL backends on Linux).
> I already have system copies of all those libs (and more)
Yeah, but what about OpenSSL? Boost? Qt? Python? There's no standard place to put them that doesn't become hell once more than one app thinks they know how things are supposed to work gets it wrong. And the Windows store certainly isn't going to provide such things.
Posted Oct 14, 2015 15:48 UTC (Wed)
by raven667 (subscriber, #5198)
[Link]
The distro providing the libraries to use and encouraging people to use them by a policy of un-bundling is a kind of implicit endorsement that the library is going to be maintained with an ABI and that the distro is going to take responsibility for this maintenance even if the upstream is uncooperative. It doesn't really make sense for a distro to take a hardcore no-bundling stance and simultaneously disclaim any responsibility for the libraries they package and force developers to use.
Maybe it makes more sense for a distro to seperate into a core of maintained software that people are expected to depend on, and a universe of software packaged for convenience only with no expectation for unbundling. Each distro trying to consume all of the software in the world and treat it as one blob in-house doesn't seem to be working all that well
Posted Oct 14, 2015 10:08 UTC (Wed)
by hkario (subscriber, #94864)
[Link] (23 responses)
Posted Oct 14, 2015 17:38 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (22 responses)
> Oh! You want stable API and new features and security updates? Then go work with upstream to fix their behaviour or fork hard and handle security issues yourself.
Posted Oct 14, 2015 17:51 UTC (Wed)
by hkario (subscriber, #94864)
[Link] (21 responses)
My windows 10 Metro app doesn't work on grandmas Windows 7 laptop, will a reboot fix it? /s
yes, if you want stability, you need to standardise on one distro. Don't like it? Make the library developers provide backwards compatibility or fork and do it yourself. Somehow glibc, NSS, libgtk, QT, Linux kernel and a dozen others can manage to do that just fine, but then there are special snowflakes that somehow are "too complex" to do that.
Posted Oct 14, 2015 18:34 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (20 responses)
> yes, if you want stability, you need to standardise on one distro. Don't like it?
> Make the library developers provide backwards compatibility or fork and do it yourself.
> Somehow glibc, NSS, libgtk, QT, Linux kernel and a dozen others can manage to do that just fine, but then there are special snowflakes that somehow are "too complex" to do that.
Posted Oct 14, 2015 18:40 UTC (Wed)
by dlang (guest, #313)
[Link] (19 responses)
and as always, other people have no problem doing exactly this. It all depends on the app and what libraries it uses.
There are windows apps that worked on 7 and don't work on 10, windows isn't perfectly backwards compatible either (and the difference between RHEL4 and RHEL7 isn't Windows7 vs Windows10, it's more like XP/Vista -> Windows10
Posted Oct 14, 2015 18:57 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (18 responses)
> There are windows apps that worked on 7 and don't work on 10, windows isn't perfectly backwards compatible either (and the difference between RHEL4 and RHEL7 isn't Windows7 vs Windows10, it's more like XP/Vista -> Windows10
Posted Oct 14, 2015 20:42 UTC (Wed)
by dlang (guest, #313)
[Link]
Posted Oct 15, 2015 10:09 UTC (Thu)
by hkario (subscriber, #94864)
[Link] (2 responses)
sure, as simple app that uses two dozen syscalls in total will continue to work between windows releases but it is also true of Linux applications
Posted Oct 17, 2015 2:40 UTC (Sat)
by zlynx (guest, #2285)
[Link] (1 responses)
Heck, Master of Orion 2, one of my favorite Windows 95 games still runs on Windows 10 64 bit.
Quake 3? Still runs. Half Life and Half Life 2? Yep. Unreal Tournament 2003? Why yes.
If you were having problems you might have forgotten to reinstall DirectX 9c (I think c?) The preinstalled DX9l compatibility library didn't quite do everything.
Posted Oct 17, 2015 17:29 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 17, 2015 1:31 UTC (Sat)
by HenrikH (subscriber, #31152)
[Link] (4 responses)
Posted Oct 17, 2015 11:19 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link] (3 responses)
OpenSSL is not ABI compatible between even micro versions, but they all build a "libeay32.dll" and a "ssleay32.dll".
In the Win32 library search order, the system32 directory *precedes* %PATH%, so this is going to *break* unrelated applications that bundle their own libeay32.dll, if it's located in a different directory than the executable.
Posted Oct 18, 2015 2:42 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Oct 20, 2015 22:21 UTC (Tue)
by javispedro (guest, #83660)
[Link] (1 responses)
In Windows it would be completely impossible to do any sensible "per-application" thing. How do you even determine which executables are part of each application?
Posted Oct 20, 2015 23:24 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Yeah, it's extra-ugly but works.
Posted Oct 22, 2015 10:02 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (8 responses)
> All of my 32-bit XP apps still work on Win10 64-bit. Microsoft does an amazing job to make sure that old apps are not broken with each OS release. Their quality slipped a bit recently, though.
Many older apps may have been 32-bit, but their installers were 16-bit. So it's no f***ing use that they work, if you can't install the things!!!
Cheers,
Posted Oct 22, 2015 14:35 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
But it's hard to blame MS about this one - there's no 16-bit support in 64-bit mode. They could have used a CPU emulator, but at this point it just makes sense to drop 20-year-old compatibility.
Posted Oct 22, 2015 17:58 UTC (Thu)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Oct 26, 2015 20:53 UTC (Mon)
by javispedro (guest, #83660)
[Link] (5 responses)
Nitpick: actually that's wrong. 64-bit processors certainly support 16-bit mode, otherwise they wouldn't be proper supersets of 32-bit processors. MS not supporting 16-bit is just a cost-benefit trade-off. In fact, for similar reasons Linux does not support vm86 on amd64, but there's a patch floating around for it, and it works quite well.
Posted Oct 26, 2015 21:00 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
No it's not. 64-bit mode has no support for vm86 mode, and so you can't run 16-bit code. You can certainly switch back to 32-bit mode and use vm86, which is presumably what the patch you're talking about does - but that's a pretty awful hack.
Posted Oct 27, 2015 2:27 UTC (Tue)
by deater (subscriber, #11746)
[Link] (2 responses)
Whether you can run unmodified code written for x86 real mode operating systems is a different story.
I know this is a bit of a nitpick, but there's a lot of confusion out there about this.
Posted Oct 27, 2015 2:33 UTC (Tue)
by mjg59 (subscriber, #23239)
[Link]
Posted Oct 27, 2015 3:08 UTC (Tue)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 27, 2015 6:41 UTC (Tue)
by javispedro (guest, #83660)
[Link]
So why you keep saying you can't if it turns out you can? It was even documented on the original AMD64 manual albeit they did certainly mention it was tricky.
I've been always curious about this, since I've been doing exactly that for at least a decade, it's a ~4k patch in 3.x, performance is still better than qemu or vt-x, and I guess no one wants to talk about the security/races of vm86 in general.
Posted Oct 14, 2015 14:39 UTC (Wed)
by drag (guest, #31333)
[Link] (5 responses)
The OS distributor CANNOT do this because it's not up to the OS distributor to write and maintain those libraries. If any solution to 'bundling problems' is 'all libraries must be XXX by distribution' then it's a non-solution. It is simply something that will never happen because it's not something that Linux distributions can do anything about. It is, very simply, beyond their control.
Whether or not it's in the interests of libraries to provide a 'stable API/ABI' is up to that library author. They have their own timelines, own purposes, own goals, and sometimes having this magical 'versioned ABI' may be what they want, and other times it isn't.
Unless distributions can come up with a solution that realistically acknowledges that it is detrimental to many application developers and users to try shoehorn all possible libraries and applications into timetable and release policies that are convenient for distributions... then application developers and users will simply treat any effort to 'debundle apps' as the anti-feature it is and work around it accordingly.
The more difficult distributions make to distribute software that doesn't adhere to restrictive unrealistic policies the worse the distribution is.
Posted Oct 14, 2015 16:31 UTC (Wed)
by raven667 (subscriber, #5198)
[Link] (4 responses)
I think we are in agreement, it would be great if the distros would stop pretending that they are capable of packaging the world and would agree on a subset of software that app developers could rely on to be maintained with compatibility across systems.
Posted Oct 14, 2015 17:54 UTC (Wed)
by drag (guest, #31333)
[Link] (3 responses)
Follow the TCP/Network-style layered model (which is unix derived anyways) and apply it to the distribution design.
Something like this:
Layer 1 = Hardware
Layer 2 = Kernel
Layer 3 = Linux Plumbing: (Systemd, kernel modules, dbus, etc.)
Layer 4 = Linux Distribution: Core libraries, userland drivers, 'most stable' libraries, OS daemons, and low level dependencies and software management facilities.
Layer 5 = User sessions: Desktop environment for desktops or whatever system people are using to manage their servers.. openstack, puppet, docker, fleet, chef, etc.
Layer 5.5 = Applications and/or servers. Sandboxed or containers or whatever system people are using to manage their software installs.
That seems like the way to go from what I can tell. Layers should been relatively isolated from each other to try to avoid leaking dependencies and to make it simpler to implement a more universal distro-agnostic way to manage everything.
Posted Oct 14, 2015 18:05 UTC (Wed)
by rahulsundaram (subscriber, #21946)
[Link] (1 responses)
https://lists.fedoraproject.org/pipermail/devel/2013-July...
Posted Oct 14, 2015 20:07 UTC (Wed)
by drag (guest, #31333)
[Link]
Posted Oct 14, 2015 18:29 UTC (Wed)
by JFlorian (guest, #49650)
[Link]
Posted Oct 18, 2015 10:54 UTC (Sun)
by paulj (subscriber, #341)
[Link]
If distributions like Fedora had had similar policies and pressure on upstreams to pay attention to ABI and API backward compatibility, then maybe their no-bundling policy might have been more tenable.
Fedora is an absolute churn-fest ABI and API wise, from release to release. That's not directly Fedora's per se, but more a wider problem in their upstreams. However, not tackling that completely undermined the chances of success of any no-bundling policy.
Posted Oct 14, 2015 17:58 UTC (Wed)
by smckay (guest, #103253)
[Link] (1 responses)
Posted Oct 17, 2015 5:34 UTC (Sat)
by cas (guest, #52554)
[Link]
What programmers care about, first and foremost, is making THEIR STUFF work. And they don't give a damn what else they break to achieve that goal. They are intently and narrowly focused on their tiny little corner of the world and have no regard at all for the bigger picture, the systems on which their code will one day have to run.
There. FTFY.
Posted Oct 14, 2015 0:54 UTC (Wed)
by fuhchee (guest, #40059)
[Link]
Posted Oct 14, 2015 2:00 UTC (Wed)
by davexunit (guest, #100293)
[Link]
Posted Oct 14, 2015 2:55 UTC (Wed)
by dlang (guest, #313)
[Link] (7 responses)
If the library is not packaged as a shared library, it makes no sense to demand that users of that library convert it.
It also makes no sense to make the exception being for programs that can't link against system shared libraries, because any program can make that claim with a trivial fork of said library.
Let's face it, most of the time when libraries are bundled it's because they have been changed slightly from the upstream version and the change hasn't been merged (and a large percentage of the rest of the time it's because the upstream version won't maintain a stable API)
Let someone package rawspeed as a system shared library, then you can fuss at other programmers to use it instead of bundling their own version. But demanding that a project (or the maintainers of a project) turn a library that they are using into a shared library is going too far.
This looks to me like someone was overreaching trying to force 'unbundling' too much and the push has backfired on them and now allows far more bundling than is reasonable.
Posted Oct 14, 2015 3:12 UTC (Wed)
by josh (subscriber, #17465)
[Link] (2 responses)
Posted Oct 15, 2015 12:04 UTC (Thu)
by mattdm (subscriber, #18)
[Link] (1 responses)
This is basically the new policy in a nutshell.
Posted Oct 17, 2015 20:56 UTC (Sat)
by dlang (guest, #313)
[Link]
and the terminology used seems point make an exception based on the convienience of the project using the library.
Posted Oct 14, 2015 5:24 UTC (Wed)
by xtifr (guest, #143)
[Link] (3 responses)
You might as well just incorporate the code into your own and stop calling it a library.
Posted Oct 14, 2015 6:15 UTC (Wed)
by dlang (guest, #313)
[Link]
that's effectively what people are doing, except that there are other people who are modifying and enhancing a portion of your codebase. some of those updates you take. others you don't (at least not right away)
Remember that in some cases, the people writing the code are only releasing source, they aren't creating or shipping a shared library.
Expecting an app developer to first turn a pile of code into a shared library, then finding someone to maintain it for the distro (including said bugs and security holes), before they can use it for their app is NOT less work.
Posted Oct 15, 2015 7:10 UTC (Thu)
by aleXXX (subscriber, #2742)
[Link] (1 responses)
If you feel really responsible for your application, this can also be a good thing:
Alex
Posted Oct 15, 2015 8:04 UTC (Thu)
by xtifr (guest, #143)
[Link]
Posted Oct 14, 2015 2:59 UTC (Wed)
by pabs (subscriber, #43278)
[Link] (11 responses)
https://wiki.debian.org/EmbeddedCodeCopies
Posted Oct 14, 2015 6:33 UTC (Wed)
by epa (subscriber, #39769)
[Link] (2 responses)
Posted Oct 15, 2015 2:21 UTC (Thu)
by prometheanfire (subscriber, #65683)
[Link] (1 responses)
Posted Oct 17, 2015 6:09 UTC (Sat)
by dirtyepic (guest, #30178)
[Link]
Gentoo does strongly discourage bundled packages but it's usually not something that would keep a package out of the tree. There's a couple examples where we compromised and let the user make the decision themselves of whether to use the bundled code or the system library, the most notable being Firefox where there are such options for system cairo, icu, jpeg, vpx, and sqlite.
I think there's one advantage of distro unbundling that software developers overlook. By building your package against system libraries we often find bugs and incompatibilities in those libraries early. When the time does come for you to update your bundled code to a newer version those bugs, that would have cost you valuable time and manpower to debug, test, and fix have already been resolved upstream. That means fewer local patches for you to carry around and less divergence from the upstream code, making it easier to backport any future bug fixes, etc. etc. Just as often we find bugs or incompatibilities in your package and can also get them fixed early, or at least make you aware of them.
Posted Oct 14, 2015 7:07 UTC (Wed)
by Karellen (subscriber, #67644)
[Link]
It's not a complete failure if you don't get every project completely unbundled all the time; that's just going to happen occasionally. But you keep trying to help as many projects as you can, with practical help (patches) where you can spare the effort, evangelism on the benefits of unbundling in other places, and tough love (such as refusing to carry a package) in some cases where that seems to be the best option. And always be there ready to support projects who become ready to want to change their ways.
Posted Oct 15, 2015 20:19 UTC (Thu)
by smoogen (subscriber, #97)
[Link] (6 responses)
The reason I ask is that there are a ton of packages that have never been included in Fedora in the past because of bundled libraries.. but in the vast number of cases it was pointed out that they were in Debian without patches.. is it that there are different definitions of what bundling means or just that bundling creep made it that the first review came clean and later versions were not?
Posted Oct 15, 2015 21:38 UTC (Thu)
by debacle (subscriber, #7114)
[Link] (2 responses)
Posted Oct 15, 2015 22:05 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Oct 17, 2015 14:42 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Oct 16, 2015 0:51 UTC (Fri)
by cortana (subscriber, #24596)
[Link] (2 responses)
New packages have to pass review by the ftpmasters, who check for bundled libraries. There's a wiki page (I forget the name) that keeps track of the known approved bundled libraries in the archive, which is permitted by the wording in policy if necessary. But the maintainer of a new package has to convince the ftpmasters that bundling is necessary.
Posted Oct 16, 2015 22:08 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Oct 17, 2015 14:44 UTC (Sat)
by pabs (subscriber, #43278)
[Link]
Posted Oct 14, 2015 6:48 UTC (Wed)
by mjthayer (guest, #39183)
[Link] (1 responses)
Make it harder to exploit possible unknown vulnerabilities in the libraries (like general hardening of the bundling application). Try to estimate the real security risk, weigh it against the added value of the application and document it clearly so that users can take their own decisions.
Automatically pull the library from a stable upstream at build time and apply patches (one could select a version of Redhat Enterprise Linux new enough to be maintained and to have a recent enough library version - they diligently apply security patches but otherwise keep things stable enough that application-specific patches would likely keep working).
Find a way of automatically tracking security issues which might affect a package through bundled libraries might also be an efficient use of resources - the information is all already out there, it just needs to be automated, so that the right people are notified, maybe even by automatic e-mail to the packagers and upstream developers.
If a library is bundled because it is not available everywhere an application needs to run, loading it dynamically (or shelling out to a locally installed tool instead of using a library) may be an option.
And yes, look for low-hanging fruit (or high risk libraries) to unbundle.
And of course, for open source applications, every user is also a potential developer. So working with upstream (really working, not just dropping patches of course), whether the application, the distribution or the library is also a way of solving this. If no users have time for that in a particular case then perhaps it is not as important as all that - and perhaps it is unfair to pressure other people to do that work.
Posted Oct 14, 2015 7:33 UTC (Wed)
by mjthayer (guest, #39183)
[Link]
develop methodology to evaluate the risks and benefits of bundling on a case by case basis (one application bundling five libraries is five cases).
develop bundling best practices for when the benefits seem to outweigh the risks.
Posted Oct 15, 2015 1:49 UTC (Thu)
by edgan (guest, #73370)
[Link] (3 responses)
Lack of bundling, backward compatibility, and serious QA are exactly why I have stuck with CentOS over Ubuntu.
Examples:
Elastic's Kibana(part of Elasticsearch, Logstash, and Kibana) bundles NodeJS, and not 0.12 or higher, but 0.10.
VMware Workstation has bundled system libraries like GTK for years and years. In more recent years they started just making their rpm a wrapper around their sh installer. So you really get the sh installer either way.
Sumologic bundles their own version of python with headers in their agent packages.
Datadog also their own version of python with headers with their agent packages.
Hashicorp's Omnibus is the biggest reason I don't use Chef server for configuration management. It is full bundling. Their Chef Server 12 RHEL7 rpm is 452mb. It contains it's own copies of Ruby, Perl, Python, Erlang, NodeJS, Redis, Runit, Postgres, Nginx, Keepalived, Logrotate, and more. It is a mini-distribution unto itself.
Posted Oct 16, 2015 4:25 UTC (Fri)
by roc (subscriber, #30627)
[Link]
If your customers are developers, then you can assume developers will be able to diagnose breakage and update libraries if necessary, and might want to take advantage of updated support libraries, so unbundling makes sense. But if your customers are end users, then they just want your product to work and are totally uninterested in updating libraries or figuring out breakage, so bundling makes more sense.
In your list above, those are all developer-focused products and so unbundling makes sense --- except for VMWare Workstation. And VMWare's bundling of GTK has never caused me any problems.
Posted Oct 20, 2015 7:19 UTC (Tue)
by ploxiln (subscriber, #58395)
[Link] (1 responses)
Pip, the standard python package installer nowadays, bundles ("vendors") its dependencies. Ubuntu 14.04 unbundled them for its pip package, and if you install a version of the popular "requests" module from just a few months after ubuntu 14.04 was released (into the site-packages dir where it won't conflict with the dist-packages dir for ubuntu-packaged modules), it breaks the packaged pip.
Most nodejs applications use dependencies that bundle their dependencies. So overall they end up bundling multiple different versions of the same libraries! Then often end up with literally over a thousand bundled libraries, which are various versions of somewhere under 100 different libraries, which provide maybe 20 different sets of functionality. And they think this is the greatest thing ever! C and Python suck because you don't have private dependencies, they say!
So as "common" developers and "popular" libraries get accustomed to this sort of thing, respect for backwards compatibility and security maintenance goes out the window. (Even as they tout their "semver" versioning.) It really is ridiculous. But it's also just the definition of "common" and "popular" changing, as entirely new groups of developers come to exist at a magnitude larger than the previous groups.
Posted Oct 23, 2015 22:11 UTC (Fri)
by HelloWorld (guest, #56129)
[Link]
Posted Oct 19, 2015 13:36 UTC (Mon)
by emptysquare (guest, #101937)
[Link] (4 responses)
Posted Oct 20, 2015 15:47 UTC (Tue)
by pabs (subscriber, #43278)
[Link] (3 responses)
Posted Oct 20, 2015 16:16 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link] (2 responses)
https://fedoraproject.org/wiki/Packaging:JavaScript#Stati...
Posted Oct 20, 2015 16:40 UTC (Tue)
by lsl (subscriber, #86508)
[Link] (1 responses)
Posted Oct 20, 2015 16:46 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Wol
guile and unicode
guile and unicode
Wol
guile and unicode
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
That's an even deeper mess. Now a committee will have to design API for the future, without feedback from actual developers. This only leads to pain, suffering and the original POSIX specification.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Wol
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Who cares about bundling? I say, bundle the whole world and to hell with distributions. Bundle everything above syscalls: ditch glibc for musl, jettison distro-provided libraries, get rid of complicated packaging.
Sincirely yours,
practical application developer.
Fedora opens up to bundling
Fedora opens up to bundling
Too late. You're likely using a service (maybe indirectly) that I'm helping to develop and supporting.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
> ensures that even if there is a buffer overflow or whatever
> security issue that permits arbitrary code execution, it at best
> destroys that application's data
just switch "computer" for "browser"
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
* comes with it's own init system
* logs into /usr/share/software
* fails to rotate its logs
* doesn't have the ability to log to rsyslog
* has configuration at completely random places, sometimes indistinguishable from binary files
* fails to upgrade properly
* is 32bit only
Fedora opens up to bundling
Yawn.
Inevitable, since each distro has its own mess. Systemd fixed this, but it's not yet everywhere.
>* fails to rotate its logs
Inexcusable but has nothing to do with bundling.
Nothing to do with bundling.
>* fails to upgrade properly
>* is 32bit only
Nothing to do with bundling.
So why do you insist then that your special snowflake of a distro should be supported? It's RHEL4 time for you.
Fedora opens up to bundling
>>* fails to rotate its logs
>Inexcusable but has nothing to do with bundling.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
You got it in one. But you're saying it like it's a bad thing. Why?
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Apple does this just fine with their sandboxing for AppStore applications. Basically, "Open File" action allows an application to access user-specified files.
Fedora opens up to bundling
Fedora opens up to bundling
It covers most.
If your spellchecker is specific to AbiWord and Libreoffice - you can explicitly whitelist it in each application. Otherwise, a user must grant your application (somewhat mislabeled) "Accessibility" permissions.
Command-line apps are somewhat special. They can be sandboxed, but nobody really cares about them.
Uhm? What?
Nope. It'll only get access to that presentation and perhaps some recent files.
Fedora opens up to bundling
Wol
Fedora opens up to bundling
That's not true for sandboxed apps on Mac OS X. A document file with an embedded exploit will probably not be able to access even the recently opened documents. It definitely won't be able to modify the LO executable files or even _read_ other user's files.
Fedora opens up to bundling
Fedora opens up to bundling
Not really. Most of the integration points for regular desktop use are known by now. Anything more advanced will require special-level access, but even developer desktops these days are pretty much vanilla.
And so? App Store model works for most users. Sandboxing command-line utilities is also possible - through SELinux or similar approaches.
No, that's incorrect. Mac OS does not allow programs to store authorizations forever.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
And precisely from a decade of SELinux experiences I know how stupid most sandboxing is, and how hard it is to actually make it usable.
Fedora opens up to bundling
> Hell, I'm sure _I_ wouldn't bet against it!
Operating systems are not set in stone. If there's a demand then new integration points are likely to be added. That is happening all the time both with iOS and Android.
I think a billion smartphone users might disagree with you. And can you point me to an MS article about failing AppStore models?
You can't do it. It's an obvious vector and so Apple's own processor tools have a special sandbox mode for it. It allows you to open and write the shared config, but nothing else.
Should I repeat my advice?
Fedora opens up to bundling
To sum it up: not only there's a huge amount of holes that need to be punched, but you need to keep punching brand new holes "all the time".
>> And please don't use the "people do real work on an iPad" argument. By now even MS marketing guys have realized how stupid it is: they actually promote the completely unsandboxed environment called Win32 as their distinguishing feature over the plethora of tablets.
Why not? As long as there's _any_ saved state (call it normal.dot, call it "shared config" -- what's the difference?) between invocations, then every future document you open with that program is compromised.
Point is, even with OS X style sandboxing, a single "dancing cows" document will also be able to send all your company finances to Nigeria. Not only that, but OS X style sandboxing is so problematic to implement, it might very well be not worth the effort, save perhaps for platform that are already usability limited from the start.
Fedora opens up to bundling
And that's fine. Vendors release new versions of applications all the time.
You assume that you can infiltrate through configuration. It's much less likely, especially if good config framework is used.
Nope, it _might_ be able to infiltrate documents as you open them. It won't be able to read browser history or install spyware.
So what's your proposal? Linux-style dependency management clearly doesn't work well.
Fedora opens up to bundling
>> But sandboxing as it is done now usually involves making programs larger (e.g. Libreoffice-like huge suites instead of collections of individual programs cooperating, like in TeX), and this means that one single bug in the almost never used code that imports .mp4 fart sounds to use in Libreoffice presentations would also be enough to access ALL your sikret files.
Note that sandboxing is independent of dependency management.
Fedora opens up to bundling
Yes. But currently application vendors are not just at the mercy of the OS, but at the mercy of many packagers! It's even worse - what if your app depends on a feature of a package with asshole maintainer?
Quite unlikely. New APIs rarely affect the old APIs.
Viruses these days exist to actually earn money for their developers. Botnetting and browser history (including CC information) are the easiest target, while documents are almost always useless.
So basically you're saying: "I believe in magic and unicorns". No packaging system can make a complicated office suite a "small" program. It might remove a bunch of peripheral dependencies, but nothing else.
1) If I have an exploit for a widely used library like zlib or libpng then I probably wouldn't want to bother exploiting LibreOffice, never mind trying to exploit a sandboxed LibreOffice.
Fedora opens up to bundling
Fedora opens up to bundling
https://access.redhat.com/articles/rhel-abi-compatibility
Fedora opens up to bundling
This is quite wrong, there are certainly quite a few libraries that maintain very good ABI compatibility for the last 15 years now: glibc2, NSS, libxml2, glib2, various X11 client libraries, libGL come to mind.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
For a reasonably complex library, maintaining perfect backward compatibility is impossible.
There is huge value in delivering applications bundled with the library versions they have been most thoroughly tested with.
"Huge value?" Then how come we've been able to get along so well for the last couple of decades without? In all the years I've been using Linux, I've seen countless security problems fixed in a whole set of apps by upgrading a shared library. I've also seen countless cases where minor bugs in (again) a whole set of apps are fixed by upgrading the library. Or where performance in a whole set of apps is improved by upgrading a library. But I've seen less than a handful of apps have serious problems when a library is upgraded, and such problems have always been treated as a bug in the library, and the buggy version of the library deprecated.
Are library maintainers getting more lazy? In that case, perhaps we need to persuade more people to work on producing high-quality libraries. But I suspect that's not the problem....
Fedora opens up to bundling
By being about 1% of the market (I'm speaking about "classic" desktop Linux).
Fedora opens up to bundling
Fedora opens up to bundling
Yup. But in the meantime it pays the bills and runs the world.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
> Sure, for *nix, this makes sense, but that's not the end of the world.
Fedora opens up to bundling
Fedora opens up to bundling
OS distributors do provide stable, versioned API that you can build your applications against. It's even supported with security fixes for more than 5 years (or more) - it's what we call Long Term Support releases or simply Enterprise distributions.
Fedora opens up to bundling
Oh! You want stable API and new features and security updates? Then go work with upstream to fix their behaviour or fork hard and handle security issues yourself.
Can't have the cake and eat it.
Fedora opens up to bundling
No, they don't. Unless you limit yourself to ONE distro.
Hm. I submitted a patch for Debian, but for some reason my SuSE is still not updated. Will a reboot help to fix it?
Fedora opens up to bundling
> SuSE is still not updated. Will a reboot help to fix it?
Fedora opens up to bundling
Yet a Windows 7 application will most probably work on Windows 10. I can't say that about an app from RHEL4 on RHEL7.
No, because users somehow don't want to work on vintage distros that are not even supported by the current generation of hardware.
I thought about taking their firstborn children as hostages. Do you think it's a good plan?
QT doesn't have a long enough support cycle. Libgtk is dead and NSS shouldn't even exist.
Fedora opens up to bundling
Fedora opens up to bundling
You _can_ do it, if you bundle pretty much all libraries. Even basic libraries like zlib had ABI-breaking changes in that period.
All of my 32-bit XP apps still work on Win10 64-bit. Microsoft does an amazing job to make sure that old apps are not broken with each OS release. Their quality slipped a bit recently, though.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Wol
Fedora opens up to bundling
Fedora opens up to bundling
Wol
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
https://lwn.net/Articles/563395/
Fedora opens up to bundling
I think this or something very much like it must happen eventually. The pain of not doing so will eventually make us realize the pain of doing so is the lesser evil. Look at the building codes for homes with so much overkill everywhere you look, yet you don't need to rebuild your house simply because you want to install a heavy granite counter-top or live in 70s style with a water-bed.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
> version, and you're going to bundle them, all of a sudden, that library is now *your responsibility*!
> You're now responsible for any bugs. Or security holes.
you can now fix bugs, or security holes, instead of having to rely on others (the distro or library maintainers).
Fedora opens up to bundling
Fedora opens up to bundling
https://wiki.debian.org/UpstreamGuide
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Amazon is a huge offender of bundling. If you want the latest copy of aws-cli, written in python, they bundle their own versions of other people's python modules.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
And they're completely right. When I depend on a library x I shouldn't need to care what libraries x depends on, as long as they're not somehow exposed through x's API.
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling
Fedora opens up to bundling