On 2021/02/17 09:53, John Paul Adrian Glaubitz wrote:
It's rather obvious that a rolling release distribution isn't something
that corporations should use. You don't want your database server to
become offline because the daemon won't restart after an update because
the database format changed from one major version to another.
But you might want the new version of the latest CMS
to go with your website. If you wait for 2-3 years till it comes
out in leap, you've missed most of your window. Similarly with any
product, one might need a new feature from a newer product and might
even be able to _test_ the product to see if it meets one's needs. That
does not mean one wants an unstable system by replacing all packages
every day as could be the case w/TW.
be honest, I want to update my linux system about as often
as I change Win OS's. Win 7 was out for about 12 years w/support. I was
an early adopter and am still using it. But never was Win7 keeping me
from using new programs (well until recently). How many progs from
an opensuse release from 2008 would work on a system from today?
How much do you pay for openSUSE and how much did you pay for Windows?
0 and 0.
Is there a point? You might claim I paid some fee for Win, but
that's a tax on the HW platform I don't have much choice about. Given that
its the same cost for openSUSE as Windows. If oSS published a broken, gimped
or "nerf"ed package, it _should_ be possible to build it myself and
I could, (and _have_) sent back the fixes.
With Windows I wouldn't be able to do that, though also, w/Windows,
I'd be less likely to know the state of the package.
So what's your point?
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.
MS 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
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.
although I think Flatpak does the balance between easy
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.
So far, I'm not seeing solutions that allow me to rebuild suse apps
from source rpm's.