On Fri, Feb 19, 2021 at 06:08:37PM -0800, L A Walsh wrote:
On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote:
Which itself is already incorrect, you can install
of glibc in parallel, but that's really not easy and you don't want
that as normal user.
The user doesn't keep the multiple lib versions in Windows -- the OS
does. It's not a matter of "can't" its a matter of the linux world
about 15 years behind in supporting new progs and old on the same OS.
Multiple copies of the same library is a security problem which is why
Linux distributions avoid that.
Good thing the MS platform never has security problems. Oh
wait -- they do, but don't seem to have the same security problem(s)
Linux has. Are you implying Linux can't handle security problems as
easily as MS can? Perhaps Linux should copy MS's methodology for that --
i.e. providing multiple versions.
That multiplies the work for them, and at some
point they decide to stop
supporting soe of the old libraries and they stay forever broken yet
your abandonware software will keep using it forever.
used to have 'dll/so' "hell", because they used to only be able
to have 1 copy of a lib loaded in shared mem by the OS, but they fixed
it so different progs can have different versioned libs -- why hasn't
linux gone that route?
Shipping every program with every shared library it needs isn't a solution,
That would be an onerous burden if it was what anyone did. Fortunately
that's not what MS or developers on that platform do. Presenting
a straw-man problem as the counterpoint to the broken linux way, is
Yes, MS developers don't their code is part of the platform and
maintain the parts of the platform that are still under supporte. But
application developers do. That's actually what MS suggests them to do.
it's a hack. I would argue that there
isn't really the perfect solution
to the shared library problem
So in addition to not knowing how MS solves this issue you also say it
can't be solved and 'punt' with a poorly integrated solution
that dwarfs the disk cost of shipping an update.exe along with the
app-install.exe that only loads the minimal set of libs needed and that are
not already on the users machine.
Well, they don't solve it. They update the
MS platform and punt updating
any other libraries to the software vendors. So when there is a bug in a
popular library every vendor that uses it must release update of ther
software with the bundled library. If the software in question is some
abandonware that is no longer developed or some freeware side project
that gets little attention you are out of luck. It will stay broken for
a long tie or even forever.
although I think Flatpak does the balance between
and handling of security updates and shared library deduplication
"a sandbox environment in which users can run application software in isolation
from the rest of the system" - wikipedia
isolated from the rest of the OS doesn't mean "integrated" nor
dedupped. Flatpak's store shared resources in a
So for TW, that'd be a different lib for each day TW is released. i.e. zero
You don't use flatpak to install TW. You use flatpak to
applications that are not available on a stable distribution (in the
version you want). Of course, doing that has some disadvantages.
At the very least flatpak aims to do some deduplication of installed
libraries as opposed to full vendoring other distribution-neutral