I dug out a dormant PC and tried upgrade 7 to 8. It gets up to last step
4744 of 4744, but that a repetition of "Running server-scriplet-*" with
dozens of kernel versions and apparently involves all disk partitions.
Has been going about 2 hours so far

On 2023-04-18 04:18, Woozy Song wrote:
> I dug out a dormant PC and tried upgrade 7 to 8. It gets up to last step
> 4744 of 4744, but that a repetition of "Running server-scriplet-*" with
> dozens of kernel versions and apparently involves all disk partitions.
> Has been going about 2 hours so far

Mageia 8 was released February 2021, more than two years ago. Mageia 7
was declared EOL the following June.

Upgrades from then-fully-updated Mageia 7 installs were tested
extensively before Mageia 8's release, and discovered problems were
corrected, some of them using Mageia 7 updates before Mageia 7 went EOL.

But, there have been many, many updates to Mageia 8 in the intervening
two years, including many kernels. If your Mageia 7 was not up-to-date
as of the EOL, it is quite possible that an upgrade install, depending
on the method you used, would stumble for now-unknown reasons.

I would have recommended a clean install of Mageia 8 at this late date
over an upgrade.

BTW, the beta2 release of Mageia 9 is expected to be released soon, with
the RC and Official releases not long after - assuming nothing new comes
up during testing. Upgrade installs will be tested on as many different
installs as possible before that release, but it's impossible for the
Mageia volunteers to test every conceivable selection of hardware and
software.

Mageia 8 will be supported for at least three months after Mageia 9 is
Official.

TJ
Deputy Leader
Mageia QA Team

On 4/18/23 4:18 AM, Woozy Song wrote:
> I dug out a dormant PC and tried upgrade 7 to 8. It gets up to last step
> 4744 of 4744, but that a repetition of "Running server-scriplet-*" with
> dozens of kernel versions and apparently involves all disk partitions.
> Has been going about 2 hours so far

Um .... are you trying to do updates/re-install
over WI-FI ??? If so there may be a DRIVER issue
that'd slow things down horribly.

On 2023-04-19 00:07, 26B.X939 wrote:
> On 4/18/23 4:18 AM, Woozy Song wrote:
>> I dug out a dormant PC and tried upgrade 7 to 8. It gets up to last
>> step 4744 of 4744, but that a repetition of "Running
>> server-scriplet-*" with dozens of kernel versions and apparently
>> involves all disk partitions. Has been going about 2 hours so far
>
>   Um .... are you trying to do updates/re-install
>   over WI-FI ??? If so there may be a DRIVER issue
>   that'd slow things down horribly.
>
>
Mageia's Nonfree Netinstall iso works well with many wifi devices, but
not all of them, even on secured networks. If I'm doing a fresh install
of whatever the Official release is some months after that release,
that's what I use when it's not convenient to use a wired connection to
the Web. But...

If going that route, mirror choice is important. Mageia has no control
over the operation of the mirrors - frequency of syncing from their
source, available bandwidth, etc. - and some of the mirrors are more
reliable than others. Back in the day, users were advised to choose the
mirror that was physically closest to them, but with today's Internet
that isn't always the best choice.

TJ

On 4/19/23 6:18 PM, TJ wrote:
> On 2023-04-19 00:07, 26B.X939 wrote:
>> On 4/18/23 4:18 AM, Woozy Song wrote:
>>> I dug out a dormant PC and tried upgrade 7 to 8. It gets up to last
>>> step 4744 of 4744, but that a repetition of "Running
>>> server-scriplet-*" with dozens of kernel versions and apparently
>>> involves all disk partitions. Has been going about 2 hours so far
>>
>>    Um .... are you trying to do updates/re-install
>>    over WI-FI ??? If so there may be a DRIVER issue
>>    that'd slow things down horribly.
>>
>>
> Mageia's Nonfree Netinstall iso works well with many wifi devices, but
> not all of them, even on secured networks. If I'm doing a fresh install
> of whatever the Official release is some months after that release,
> that's what I use when it's not convenient to use a wired connection to
> the Web. But...

Just sayin' ... the wi-fi drivers that come on some
install stick may NOT match your actual hardware
very well. If they work at all you may be getting
THE slowest wi-fi protocol.

I recently was setting up a "Banana Pi". It did not
have built-in wi-fi but you COULD plug in a USB
wi-fi dongle. Prob ... I had three or four such
dongles and NONE of them matched the drivers in
the BPi system. So, it was wired or nothin' ...
ok, wired or MAYbe 1mbs

> If going that route, mirror choice is important. Mageia has no control
> over the operation of the mirrors - frequency of syncing from their
> source, available bandwidth, etc. - and some of the mirrors are more
> reliable than others. Back in the day, users were advised to choose the
> mirror that was physically closest to them, but with today's Internet
> that isn't always the best choice.

Quite true. Often a 10x diff. Does not seem to
be a 'guide' published by anyone that'll point
out the fast/slow mirrors alas. While the distro
masters may not love it, you're usually better
off with their "main" repo - ie "debian.org" or
whatever.

On 20/04/2023 04:24, 26B.X939 wrote:
> Quite true. Often a 10x diff. Does not seem to
>   be a 'guide' published by anyone that'll point
>   out the fast/slow mirrors alas.

(Mint's) Synaptic will test the mirrors for speed and list them in order
and allow you to select the one you want from that.

Whilst not the definite best it generally avoids most of the worst.

--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

The Natural Philosopher <tnp@invalid.invalid> writes:

> On 20/04/2023 04:24, 26B.X939 wrote:
>> Quite true. Often a 10x diff. Does not seem to
>>   be a 'guide' published by anyone that'll point
>>   out the fast/slow mirrors alas.
>
> (Mint's) Synaptic will test the mirrors for speed and list them in
> order and allow you to select the one you want from that.
>
> Whilst not the definite best it generally avoids most of the worst.

Fedora (with RPM based dnf) has the same thing.

--
Dan Espen

On Thu, 20 Apr 2023 14:07:37 -0400, Dan Espen <dan1espen@gmail.com> wrote:
> The Natural Philosopher <tnp@invalid.invalid> writes:
>
>> On 20/04/2023 04:24, 26B.X939 wrote:
>>> Quite true. Often a 10x diff. Does not seem to
>>> be a 'guide' published by anyone that'll point
>>> out the fast/slow mirrors alas.
>>
>> (Mint's) Synaptic will test the mirrors for speed and list them in
>> order and allow you to select the one you want from that.
>>
>> Whilst not the definite best it generally avoids most of the worst.
>
> Fedora (with RPM based dnf) has the same thing.

I think it's due to the way rpm and either dnf or urpmi handles their indexes in
/var/lib/rpm and either /var/lib/urpmi or /var/lib/dnf including things like which
files are "owned" by which package, which packages require which other packages, and
also determining the order to install the packages.

When installing a number of packages larger than "X" (default 20 packages for
urpmi), the packages are grouped into transactions of at least "X" packages that
ensure dependencies are all installed at the right time ensuring dependencies are
met after each transaction, and then the indexes rebuilt. It appears to the user
like a long pause after every transaction as it's quite cpu intensive and the
process only runs on one core. It's not something that benefits from having more
cores.

While it makes upgrades rather slow, it makes it quite resilient so that if the
upgrade stops part way (for example, due to a power failure), it's usually fairly
easy to restart the upgrade from where it left off.

Regards, Dave Hodgins

On 4/20/23 4:36 AM, The Natural Philosopher wrote:
> On 20/04/2023 04:24, 26B.X939 wrote:
>> Quite true. Often a 10x diff. Does not seem to
>>    be a 'guide' published by anyone that'll point
>>    out the fast/slow mirrors alas.
>
> (Mint's) Synaptic will test the mirrors for speed and list them in order
> and allow you to select the one you want from that.
>
> Whilst not the definite best it generally avoids most of the worst.

Hmm .. never noticed that feature ....... I'll look.

On 4/20/23 4:02 PM, David W. Hodgins wrote:
> On Thu, 20 Apr 2023 14:07:37 -0400, Dan Espen <dan1espen@gmail.com> wrote:
>> The Natural Philosopher <tnp@invalid.invalid> writes:
>>
>>> On 20/04/2023 04:24, 26B.X939 wrote:
>>>> Quite true. Often a 10x diff. Does not seem to
>>>>    be a 'guide' published by anyone that'll point
>>>>    out the fast/slow mirrors alas.
>>>
>>> (Mint's) Synaptic will test the mirrors for speed and list them in
>>> order and allow you to select the one you want from that.
>>>
>>> Whilst not the definite best it generally avoids most of the worst.
>>
>> Fedora (with RPM based dnf) has the same thing.
>
> I think it's due to the way rpm and either dnf or urpmi handles their
> indexes in
> /var/lib/rpm and either /var/lib/urpmi or /var/lib/dnf including things
> like which
> files are "owned" by which package, which packages require which other
> packages, and
> also determining the order to install the packages.
>
> When installing a number of packages larger than "X" (default 20
> packages for
> urpmi), the packages are grouped into transactions of at least "X"
> packages that
> ensure dependencies are all installed at the right time ensuring
> dependencies are
> met after each transaction, and then the indexes rebuilt. It appears to
> the user
> like a long pause after every transaction as it's quite cpu intensive
> and the
> process only runs on one core. It's not something that benefits from
> having more
> cores.
>
> While it makes upgrades rather slow, it makes it quite resilient so that
> if the
> upgrade stops part way (for example, due to a power failure), it's
> usually fairly
> easy to restart the upgrade from where it left off.

"Dependencies" are the BANE of Linux IMHO. You run into
minor version incompatibilities and endless dependency
trees constantly.

More and more people are supplying "app-images" these days
as a way to circumvent a lot of this - pre-compiled
executables. Java-like languages are another way around
the issue.

On Thu, 20 Apr 2023 22:38:48 -0400, 26B.X939 <26BX939@zoq23q.net> wrote:
> More and more people are supplying "app-images" these days
> as a way to circumvent a lot of this - pre-compiled
> executables. Java-like languages are another way around
> the issue.

The app-images do simplify things for application creators, they are not
good for distributions.

I hate app-images. They mean having multiple versions of the same library
in multiple places. Applying security updates to multiple version is very
tedious, as is the testing that should also be done for each and every
app-image that it applies to.

While dependencies do end up requiring a few versions of some libraries in
a full distribution, there is a lot less duplication of the work required
for maintenance.

Using app-images can work, but only if the users learn to install the
applications directly from the creators website. It doesn't work well
for distributions. Teaching users to install applications from the
distributions repositories isn't hard. Teaching them to find and install
the applications from the creators is much harder.

Regards, Dave Hodgins

On 21/04/2023 03:38, 26B.X939 wrote:
> "Dependencies" are the BANE of Linux IMHO. You run into
>   minor version incompatibilities and endless dependency
>   trees constantly.
>
On the contrary, they assure you that at least if you download from a
distro, you will get all the dependencies you need installed as well.

Only when downloading from non distro sources onto slightly old
operating systems have I encountered 'dependency hell' where I cant
install the up to date libraries because they break the existing system...

>   More and more people are supplying "app-images" these days
>   as a way to circumvent a lot of this - pre-compiled
>   executables. Java-like languages are another way around
>   the issue.

Java was just as bad. I had to install a non standard Java package to
get one program to run

--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

On 4/21/23 1:03 AM, David W. Hodgins wrote:
> On Thu, 20 Apr 2023 22:38:48 -0400, 26B.X939 <26BX939@zoq23q.net> wrote:
>>    More and more people are supplying "app-images" these days
>>    as a way to circumvent a lot of this - pre-compiled
>>    executables. Java-like languages are another way around
>>    the issue.
>
> The app-images do simplify things for application creators, they are not
> good for distributions.
>
> I hate app-images. They mean having multiple versions of the same library
> in multiple places. Applying security updates to multiple version is very
> tedious, as is the testing that should also be done for each and every
> app-image that it applies to.

However the EXISTENCE of app-images points to a
very real, frustrating, sometimes paralyzing,
problem with the 'normal' approach of compiling
packages per-machine.

Also, how you DO app-images can affect the experience.
Fully compile a big 'c' program and everything needed
from the libraries is already "in there". I've done
some compiled on Mint, that work just fine if you
take them to any Deb-derived and even Fedora (have
not tried Arch or Slack). No extra libs need be
downloaded, the compiler created and bound-together
all the needed machine code.

> While dependencies do end up requiring a few versions of some libraries in
> a full distribution, there is a lot less duplication of the work required
> for maintenance.
>
> Using app-images can work, but only if the users learn to install the
> applications directly from the creators website. It doesn't work well
> for distributions. Teaching users to install applications from the
> distributions repositories isn't hard. Teaching them to find and install
> the applications from the creators is much harder.
>
> Regards, Dave Hodgins

On 4/21/23 7:14 AM, The Natural Philosopher wrote:
> On 21/04/2023 03:38, 26B.X939 wrote:
>> "Dependencies" are the BANE of Linux IMHO. You run into
>>    minor version incompatibilities and endless dependency
>>    trees constantly.
>>
> On the contrary, they assure you that at least if you download from a
> distro, you will get all the dependencies you need installed as well.

But if I need ONE little utility from a newer/older distro
to run on MY distro this afternoon ......

Had that experience when OpenSUSE switched to a stupid
version of ffmpeg ... and I needed the non-stupid version.
Down the dependency hole ... and dependencies of dependenceies.
Don't use OpenSUSE anymore because of that. Won't put up with
being stabbed in the back like that.

> Only when  downloading from non distro sources  onto slightly old
> operating systems have I encountered 'dependency hell' where I cant
> install the up to date libraries because they break the existing system...
>
>
>>    More and more people are supplying "app-images" these days
>>    as a way to circumvent a lot of this - pre-compiled
>>    executables. Java-like languages are another way around
>>    the issue.
>
> Java was just as bad. I had to install a non standard Java package to
> get one program to run

That's a prob on their end, but not with the CONCEPT of Java.

Of course concept -> reality ... well ......

Now you can write a bash script pretty much anywhere and it
will run on everything Linux.

Anyway, app-images, as I said to another it depends on HOW
the image is prepared. You can have GCC or whatever combine
all the needed libs at compile-time right into the executable.
I've done a number of 'app-image' style pgms like that and
they run on every Deb and Fedora of fairly recent make,
maybe Arch/Slack too (but I haven't checked). Basically you
want a self-contained executable. DOS/Win pretty much do
it that way ... it's why yer favorite Win2k pgm can still
run on XP/Vista/7/10 (dunno about 11, it's weird).

On Fri, 21 Apr 2023 14:43:55 -0400, 26B.X939 <26BX939@zoq23q.net> wrote:
> Anyway, app-images, as I said to another it depends on HOW
> the image is prepared. You can have GCC or whatever combine
> all the needed libs at compile-time right into the executable.
> I've done a number of 'app-image' style pgms like that and
> they run on every Deb and Fedora of fairly recent make,
> maybe Arch/Slack too (but I haven't checked). Basically you
> want a self-contained executable. DOS/Win pretty much do
> it that way ... it's why yer favorite Win2k pgm can still
> run on XP/Vista/7/10 (dunno about 11, it's weird).

Bundling the libs into the executable does nothing to help with ensuring
security updates get applied and tested later. It will probably make it
harder for users of that application to realize they are impacted by a
security bug that is being exploited in the wild.

If the application is for personal use, then that's your choice. If the
applications is being distributed to others, then they are being put at
risk and probably won't even know it.

Regards, Dave Hodgins

On 21/04/2023 19:20, 26B.X939 wrote:
> However the EXISTENCE of app-images points to a
>   very real, frustrating, sometimes paralyzing,
>   problem with the 'normal' approach of compiling
>   packages per-machine.

Yes. The use of dynamic libraries.

--
"When one man dies it's a tragedy. When thousands die it's statistics."

Josef Stalin

On 4/21/23 3:02 PM, David W. Hodgins wrote:
> On Fri, 21 Apr 2023 14:43:55 -0400, 26B.X939 <26BX939@zoq23q.net> wrote:
>>    Anyway, app-images, as I said to another it depends on HOW
>>    the image is prepared. You can have GCC or whatever combine
>>    all the needed libs at compile-time right into the executable.
>>    I've done a number of 'app-image' style pgms like that and
>>    they run on every Deb and Fedora of fairly recent make,
>>    maybe Arch/Slack too (but I haven't checked). Basically you
>>    want a self-contained executable. DOS/Win pretty much do
>>    it that way ... it's why yer favorite Win2k pgm can still
>>    run on XP/Vista/7/10 (dunno about 11, it's weird).
>
> Bundling the libs into the executable does nothing to help with ensuring
> security updates get applied and tested later. It will probably make it
> harder for users of that application to realize they are impacted by a
> security bug that is being exploited in the wild.

You issue security updates as newer versions of
the executable.

If you're using such an executable writ 25 years
ago ... well ... don't expect much security unless
you insulate the run environment. Actually, 25
years, nobody's gonna even be LOOKING for weaknesses
in that software anymore ... think anybody's hacking
Netscape 1.5 ? Mosaic ?

> If the application is for personal use, then that's your choice. If the
> applications is being distributed to others, then they are being put at
> risk and probably won't even know it.
>
> Regards, Dave Hodgins

On Sat, 22 Apr 2023 16:46:41 -0400, 26B.X938 <26BX938@zoq24q.net> wrote:
> On 4/21/23 3:02 PM, David W. Hodgins wrote:
>> Bundling the libs into the executable does nothing to help with ensuring
>> security updates get applied and tested later. It will probably make it
>> harder for users of that application to realize they are impacted by a
>> security bug that is being exploited in the wild.
>
>
> You issue security updates as newer versions of
> the executable.

It adds a lot more work. Instead of applying a security fix to one dynamically
loaded lib and testing enough applications that use it to ensure the change
has not caused any regressions and fixes the problem, the bundled copies of the
lib each have to have the fix applied. As the fix from upstream will not apply to
older versions, so it has to be rediffed for each version that contains the
buggy code.

Then each and every application has to be tested to ensure the fix has been
done properly with no unwanted regressions, and care must be taken to ensure
none of the bundled copies of the lib have been missed.

It's a lot more work and slows down getting critical security updates out to
all of the users. With zero day bugs being exploited in the wild, time is
critical.

Using bundled libs or app-images does have some benefits, but my opinion is
that the security drawbacks far outweigh them

Regards, Dave Hodgins

On 4/22/23 14:32, David W. Hodgins wrote:
> On Sat, 22 Apr 2023 16:46:41 -0400, 26B.X938 <26BX938@zoq24q.net> wrote:
>> On 4/21/23 3:02 PM, David W. Hodgins wrote:
>>> Bundling the libs into the executable does nothing to help with ensuring
>>> security updates get applied and tested later. It will probably make it
>>> harder for users of that application to realize they are impacted by a
>>> security bug that is being exploited in the wild.
>>
>>
>>    You issue security updates as newer versions of
>>    the executable.
>
> It adds a lot more work. Instead of applying a security fix to one
> dynamically
> loaded lib and testing enough applications that use it to ensure the change
> has not caused any regressions and fixes the problem, the bundled copies
> of the
> lib each have to have the fix applied. As the fix from upstream will not
> apply to
> older versions, so it has to be rediffed for each version that contains the
> buggy code.
>
> Then each and every application has to be tested to ensure the fix has been
> done properly with no unwanted regressions, and care must be taken to
> ensure
> none of the bundled copies of the lib have been missed.
>
> It's a lot more work and slows down getting critical security updates
> out to
> all of the users. With zero day bugs being exploited in the wild, time is
> critical.
>
> Using bundled libs or app-images does have some benefits, but my opinion is
> that the security drawbacks far outweigh them
>
> Regards, Dave Hodgins

If Mageia updates are too slow for you Dave, change to PCLinuxOS 64.
It is a rolling release with many of the features of the old
Mandrake/Mandriva. It must work fine because here I am again.

bliss “Nearly any fool can use a GNU/Linux computer. Many do.” After all
here I am...

--
bliss dash SF 4 ever at dslextreme dot com

On Sat, 22 Apr 2023 20:35:17 -0400, Bobbie Sellers <bliss@mouse-potato.com> wrote:
> If Mageia updates are too slow for you Dave, change to PCLinuxOS 64.
> It is a rolling release with many of the features of the old
> Mandrake/Mandriva. It must work fine because here I am again.

The conversation has drifted from why upgrades (not just Mageia) are slow to pros
and cons of app-images or bundled libs.

I'm the leader of the qa team for Mageia linux, so while I experiment with
other distros when I have time, I won't be switching.

Regards, Dave Hodgins

On Sun, 23 Apr 2023 07:26:59 -0400, The Natural Philosopher <tnp@invalid.invalid> wrote:
> Of course that entirely depends on the application. Here at home behind
> a NAT router with no public ports accessible directly , do I really care
> about security upgrades?
>
> My publiclty accessible servers are conservative in the extreme and run
> almost nothing but standard code apart from source code I have written
> myself.

That is unusual, however any software that works with traffic coming from the
internet still needs to be kept up-to-date. The nat router protects services that
the router doesn't forward traffic to from direct attack, but it doesn't protect
from reflected attacks.

Go to some website with a browser where one of it's advertisers is either
malicious or has had their website hacked. The page then includes javascript
that runs in your browser on your computer. That javascript can send the traffic
to the applications running on your computer or lan, with your level of authority.
It can also be used to hijack your router if it has known weaknesses, giving the
attacker control over the router dns settings.

Look at https://www.securityweek.com/webkit-vulnerabilities-allow-remote-code-execution-malicious-websites/
for an example. While Apple produces webkit, most linux distributions include
webkit2 as a package.

Run a search on "soap attacks".

The router, and all software that can process traffic either directly from the
web or from your user account must be kept up-to-date. The attackers love old
software where proof of concept attacks have been published.

It may sound far fetched, and you may get lucky and never encounter it, but that
is how so many of today's attacks work.

It's much easier to keep all of the software updated, then to cherry pick just
the security updates. It's tedious, and means adapting to changes in how the
applications work, but that's a requirement of basic security.

Even if your computer has no data on it you care about, having poor security on
it can make it part of a botnet without you being aware of it.

Regards, Dave Hodgins

On 22/04/2023 22:32, David W. Hodgins wrote:
> On Sat, 22 Apr 2023 16:46:41 -0400, 26B.X938 <26BX938@zoq24q.net> wrote:
>> On 4/21/23 3:02 PM, David W. Hodgins wrote:
>>> Bundling the libs into the executable does nothing to help with ensuring
>>> security updates get applied and tested later. It will probably make it
>>> harder for users of that application to realize they are impacted by a
>>> security bug that is being exploited in the wild.
>>
>>
>>    You issue security updates as newer versions of
>>    the executable.
>
> It adds a lot more work. Instead of applying a security fix to one
> dynamically
> loaded lib and testing enough applications that use it to ensure the change
> has not caused any regressions and fixes the problem, the bundled copies
> of the
> lib each have to have the fix applied. As the fix from upstream will not
> apply to
> older versions, so it has to be rediffed for each version that contains the
> buggy code.
>
> Then each and every application has to be tested to ensure the fix has been
> done properly with no unwanted regressions, and care must be taken to
> ensure
> none of the bundled copies of the lib have been missed.
>
> It's a lot more work and slows down getting critical security updates
> out to
> all of the users. With zero day bugs being exploited in the wild, time is
> critical.
>
> Using bundled libs or app-images does have some benefits, but my opinion is
> that the security drawbacks far outweigh them
>
> Regards, Dave Hodgins

Of course that entirely depends on the application. Here at home behind
a NAT router with no public ports accessible directly , do I really care
about security upgrades?

My publiclty accessible servers are conservative in the extreme and run
almost nothing but standard code apart from source code I have written
myself.

--
"An intellectual is a person knowledgeable in one field who speaks out
only in others...”

Tom Wolfe

On 2023-04-23 07:26, The Natural Philosopher wrote:
> On 22/04/2023 22:32, David W. Hodgins wrote:

>> It's a lot more work and slows down getting critical security updates
>> out to
>> all of the users. With zero day bugs being exploited in the wild, time is
>> critical.
>>
>> Using bundled libs or app-images does have some benefits, but my
>> opinion is
>> that the security drawbacks far outweigh them
>>
>> Regards, Dave Hodgins
>
> Of course that entirely depends on the application. Here at home behind
> a NAT router with no public ports accessible directly , do I really care
> about security upgrades?
>
> My publiclty accessible  servers are conservative in the extreme and run
> almost nothing but standard code apart from source code I have written
> myself.
>
Since you have the skills, that's for you to decide. And if Mageia was
being produced solely for people of your skill level, we might be doing
things differently.

But what about Mageia users like me? I'm 73 years old, still
self-employed full time. Any coding skills I once had are close to 50
years out of date, and I don't have the time or inclination to update them.

I'm living the life I want to live. I do this as a hobby, not a
vocation. I, and users like me, rely on the Mageia developers to keep
abreast of bugfixes and security problems, and plug the potential holes
when they are discovered, because we can't reliably do it for ourselves.

Everybody has to start somewhere, and skill sets grow with experience,
but they often reach a certain level and stay there. I've learned a
great deal in the 20+ years that I have used Mandrake/Mandriva/Mageia
Linux, but those skills are never going to include coding, and I'm OK
with that. A user shouldn't *have* to learn how to code to be able to
use a Linux distro.

Mageia is produced by an all-volunteer community for users of *all*
levels, from raw beginner to seasoned expert. That's been our philosophy
from the beginning, and we have no intention to change it.

TJ

On 4/22/23 11:05 PM, David W. Hodgins wrote:
> On Sat, 22 Apr 2023 20:35:17 -0400, Bobbie Sellers
> <bliss@mouse-potato.com> wrote:
>>     If Mageia updates are too slow for you Dave, change to PCLinuxOS 64.
>> It is a rolling release with many of the features of the old
>> Mandrake/Mandriva.  It must work fine because here I am again.
>
> The conversation has drifted from why upgrades (not just Mageia) are
> slow to pros
> and cons of app-images or bundled libs.
>
> I'm the leader of the qa team for Mageia linux, so while I experiment with
> other distros when I have time, I won't be switching.
>
> Regards, Dave Hodgins

Perfectly fair.

I don't think this was so much a real problem
with Mageia but POSSIBLY some of the mirrors
or the hardware/driver combo for that particular
user. The system itself is a sound and solid Linux.

As for the thread ... threads drift - think of it
as a form of entropy.

App-Images CAN get around the accursed library-version
problems in some cases though. This issue is my #1
complaint about Linux/BSD - the giant dependency tree,
more like a jungle of thorn vines, of what's totally
dependent on version x.y.z.3 of some boring little
library. Hey, x.y.z.4 is 99.999% as likely to work JUST
AS WELL but that's not how it all works.

An alt to app-images are Docker images, which sort
of do something similar by being kinda 'apart' from
the main OS.