On 2023-12-20, TimS <tim@streater.me.uk> wrote:

> On 20 Dec 2023 at 15:11:23 GMT, "David Taylor"
> <david-taylor@blueyonder.co.uk.invalid> wrote:
>
>> On 20/12/2023 13:46, TimS wrote:
>>
>>> Microsoft, perhaps, given the posts I've seen here about needing to take a
>>> backup first or of Windows erasing the disk first before doing the upgrade.
>>
>> As usual, you hear the posts about the problems, nothing from the very
>> many users for whom updates are without issue. Backup up regularly is
>> good practice with any OS.
>
> I didn't say I didn't back up regularly. I said I didn't do a special backup
> just because I'm updating the machine.

I do updates immediately after a regular backup. :-)

Let's face it, shit happens. It's best to be ready just in case.
Usually I find that Linux updates go slick as a whistle. But there
have also been times when things have gone so wrong that it was faster
to reformat the root partition, install the new release from scratch,
and restore my backup. That's much less frustrating than losing everything.

--
/~\ Charlie Gibbs | The Internet is like a big city:
\ / <cgibbs@kltpzyxm.invalid> | it has plenty of bright lights and
X I'm really at ac.dekanfrus | excitement, but also dark alleys
/ \ if you read it the right way. | down which the unwary get mugged.

On 20/12/2023 16:08, TimS wrote:
> I didn't say I didn't back up regularly. I said I didn't do a special backup
> just because I'm updating the machine.

It's a very good idea to do one before updating, as it involves an awful
lot of writing to the SD card, and if it's getting close to its wear
level limits, this could push it over into failure.

---druck

On 20/12/2023 13:21, Theo wrote:
> Ubuntu is using 'held back' for phased updates:
> https://ubuntu.com/server/docs/about-apt-upgrade-and-phased-updates
>
> Are Debian or Raspberry Pi OS also using that mechanism?

I notice they explain how to turn off phased updates so you always get
the new potentially breaking packages, but I must have missed the bit on
how to set it up so you never get randomly chosen to install these
packages.

---druck

The Natural Philosopher wrote:

>> 1. you never break an upgrade (problems preprogrammed)
> ??? Sorry...English pliz!
CTRL+C or reboot, or interrupt the power supply

>
>> 2. when you break an upgrade you never reboot (even more problems
>> preprogrammed)
>>
> A computer that is bricked is less use than one that cannot be powered
> on unless its has a reinstalled OS.

often the system can be repaired easily when still running.

>
>> you should have solved the issues beforehand and then reboot
>>
> How?
>

well depends on the situation, but it was about the kernel that did not
install if I understood correctly

>> I am surprised you expected any other outcome. Better think of rescue
>> strategy to avoid such outcomes - i.e. backup/restore or clone to another
>> SD and try there first. I do it with borg and for the PI it is diskless
>> anyway.
>>
>
> My rescue strategy for that unit was what  I followed. There was nothing
> I couldn't afford to lose. It is at this point an experimental setup.

I use Borg since couple of years. I used it once to completely restore a
firewall that lost it's disk and couple of times to extract files.

But a dd to an external drive or SD card is also easily doable.
The need to do backup is proportional to the value of the system (the effort
to configure it).
I recently bought a couple of USB sticks 32-64GB for < $10,- each and few SD
cards even cheaper. And they are good quality brands.
I have one USB that I use as emergency tool and 2-3 SDs for experimenting
and quick fix backup. This is where I use Borg to completely restore a
system.

In any case there are so many ways to take precautions and it is even
recommended in any documentation. Why bother everybody with this?
But I do not mean to insult you. Just pick up some backup strategy that
suits you best and look forward to do better next time.

On 20 Dec 2023 at 21:08:31 GMT, "druck" <news@druck.org.uk> wrote:

> On 20/12/2023 16:08, TimS wrote:
>> I didn't say I didn't back up regularly. I said I didn't do a special backup
>> just because I'm updating the machine.
>
> It's a very good idea to do one before updating, as it involves an awful
> lot of writing to the SD card, and if it's getting close to its wear
> level limits, this could push it over into failure.

I was responding to a comment that macOS upgrades were sub-optimal, not
talking about Pi upgrades.

--
Tim

On 12/20/23 5:58 PM, TimS wrote:
> On 20 Dec 2023 at 21:08:31 GMT, "druck" <news@druck.org.uk> wrote:
>
>> On 20/12/2023 16:08, TimS wrote:
>>> I didn't say I didn't back up regularly. I said I didn't do a special backup
>>> just because I'm updating the machine.
>>
>> It's a very good idea to do one before updating, as it involves an awful
>> lot of writing to the SD card, and if it's getting close to its wear
>> level limits, this could push it over into failure.
>
> I was responding to a comment that macOS upgrades were sub-optimal, not
> talking about Pi upgrades.
>

"Mac-OS" is, underneath, BSD. As such it gains, or loses,
from the same issues as mainstream Linux/Unix insofar as
'packages/upgrades' go.

ON THE WHOLE I've not suffered much from PI 'upgrades'.
They mostly follow the Debian lead. Yes, "held back"
IS annoying ... but then we are also talking an OS in
constant evolution (devolution maybe considering 'Worm')
so SOME attention to keeping older apps running MUST
be considered and 'held back' helps with this.

Linux/BSD always suffers from the "version curse".
SO many writers tie their apps to VERY specific
versions of other apps/code/drivers/etc and will
REFUSE to work even with the slightest change of
a library version (even though said libraries
are almost always super-sets and WOULD support
the same old stuff).

This is ONE area where Winders is actually BETTER.
You can still run relatively ancient apps Without
Complaint (esp if you have a pre-8/16 ban chip).

On Thu, 21 Dec 2023 02:22:31 -0500
"56g.1183" <56g.1183@ztq4.net> wrote:

> "Mac-OS" is, underneath, BSD. As such it gains, or loses,
> from the same issues as mainstream Linux/Unix insofar as
> 'packages/upgrades' go.

Not really MacOS is the Mach kernel, a POSIX userland derived
mostly from FreeBSD, a proprietary GUI and package system.

There is a lot of variety among package systems in the unix world.
They are not all equal.

Some package systems such as MacOS and FreeBSD use a central build
system that ensures consistency across the entire package set. Others take
contributed builds that do not.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 20/12/2023 13:49, Jean-Pierre Kuypers wrote:
> In article (Dans l'article) <uluoh7$ibt0$7@dont-email.me>, The Natural
> Philosopher <tnp@invalid.invalid> wrote (écrivait) :
>
>> Linux is generally really really good about upgrades. Way better than
>> Apple or Microsoft.
>
> Do you have experience with this type of material?
>
Some.

I follow the technical press. The occurrence of updates breaking
machines is common with Windows, and my experience with Apple was less
than encouraging.

I think if you stay on the One True Apple path then things are probably
OK, just don't install any third party apps....

--
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.

Mark Twain

On 20/12/2023 14:41, Richard Kettlewell wrote:
> Theo <theom+news@chiark.greenend.org.uk> writes:
>> Richard Kettlewell <invalid@invalid.invalid> wrote:
>>> Packages being _held_ back means the local administrator has blocked
>>> their upgrade with ‘apt-mark hold’ (or equivalent).
>>>
>>> Packages being _kept_ back means that a package can’t be upgraded due to
>>> a dependency issue (e.g. because the administrator only asked for a
>>> partial upgrade, but the new version of the package depends on a package
>>> that isn’t installed).
>>>
>>> Neither reflects any kind of upstream decision to block upgrades.
>>
>> Ubuntu is using 'held back' for phased updates:
>> https://ubuntu.com/server/docs/about-apt-upgrade-and-phased-updates
>>
>> Are Debian or Raspberry Pi OS also using that mechanism?
>
> Oh, that’s new. Confusing that they’ve used the same diagnostic. They
> could in principle use it, but none of the packages files I can see
> contain the header for it which suggests they aren’t. But I don’t know
> where TNP is getting his packages from.
>
Well you need to just ask. I get them from whatever is the default PIOS
repository.

Coriolanus:/etc/apt$ more sources.list

deb http://deb.debian.org/debian bookworm main contrib non-free
non-free-firmware
deb http://deb.debian.org/debian-security/ bookworm-security main
contrib non-free non-free-firmware
deb http://deb.debian.org/debian bookworm-updates main contrib non-free
non-free-firmware
# Uncomment deb-src lines below then 'apt-get update' to enable 'apt-get
source'
#deb-src http://deb.debian.org/debian bookworm main contrib non-free
non-free-firmware
#deb-src http://deb.debian.org/debian-security/ bookworm-security main
contrib n
on-free non-free-firmware
#deb-src http://deb.debian.org/debian bookworm-updates main contrib
non-free non
-free-firmware

And I downloaded my installations from the official PIOS site.

https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-64-bit

Where this image

2023-12-11-raspios-bookworm-arm64-lite.img

was the one that kernel panicked (twice) on boot.

But the one I had used before

2023-10-10-raspios-bookworm-arm64-lite.img

Installed perfectly again.

It may all be something to do with this. But you are in a better
position to judge that than I.

https://www.theregister.com/2023/12/14/linux_kernel_of_the_beast/

--
There is something fascinating about science. One gets such wholesale
returns of conjecture out of such a trifling investment of fact.

Mark Twain

On Thu, 21 Dec 2023 10:15:53 +0000
The Natural Philosopher <tnp@invalid.invalid> wrote:

> I think if you stay on the One True Apple path then things are probably
> OK, just don't install any third party apps....

I believe you are correct in this, I have never seen any issues
when following the OTAP but third party stuff is only tolerated not
supported and it shows.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

On 21 Dec 2023 at 11:05:36 GMT, "Ahem A Rivet's Shot" <steveo@eircom.net>
wrote:

> On Thu, 21 Dec 2023 10:15:53 +0000
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> I think if you stay on the One True Apple path then things are probably
>> OK, just don't install any third party apps....
>
> I believe you are correct in this, I have never seen any issues
> when following the OTAP but third party stuff is only tolerated not
> supported and it shows.

Which third party apps are you referring to? I've not had any obvious
problems, not even for apps I've written myself. Apart from utilities, the
only Apple app I use is Pages.

--
Tim

On 20/12/2023 22:58, TimS wrote:
> On 20 Dec 2023 at 21:08:31 GMT, "druck" <news@druck.org.uk> wrote:
>
>> On 20/12/2023 16:08, TimS wrote:
>>> I didn't say I didn't back up regularly. I said I didn't do a special backup
>>> just because I'm updating the machine.
>>
>> It's a very good idea to do one before updating, as it involves an awful
>> lot of writing to the SD card, and if it's getting close to its wear
>> level limits, this could push it over into failure.
>
> I was responding to a comment that macOS upgrades were sub-optimal, not
> talking about Pi upgrades.
>
Well lets try to keep this discussion on-topic.

---druck

On 12/21/23 3:31 AM, Ahem A Rivet's Shot wrote:
> On Thu, 21 Dec 2023 02:22:31 -0500
> "56g.1183" <56g.1183@ztq4.net> wrote:
>
>> "Mac-OS" is, underneath, BSD. As such it gains, or loses,
>> from the same issues as mainstream Linux/Unix insofar as
>> 'packages/upgrades' go.
>
> Not really MacOS is the Mach kernel, a POSIX userland derived
> mostly from FreeBSD, a proprietary GUI and package system.

They prettied it up Real Nice ... but it's still BSD underneath.

There are rumors that Winders is headed in the same direction
because what-is has become just a total Gordian Knot and they
can't maintain it or predict interactions. It's why there are
a bazillion security flaws they can never seem to deal with.

> There is a lot of variety among package systems in the unix world.
> They are not all equal.
>
> Some package systems such as MacOS and FreeBSD use a central build
> system that ensures consistency across the entire package set. Others take
> contributed builds that do not.

Yea ... but "contributed" isn't necessarily the issue.
It's "dependencies". They are handled rather badly by
Linux and also by BSD to a fair extent. Part of the
problem is the programmers - they link their code to
VERY VERY specific versions of libs, alas OTHER ones
also do so - and their needs/requirements are not going
to be the same all the time. If you don't have lib-XYZ
version 8.33.04 then they freak. The Unix universe IS a
bit more boring ... so fewer problems ... but still ....

The sad bit is that most of those libs are super-sets,
still support all the old params, just add some new ones.
They COULD be used as-is ... IF the apps/update system
was a bit more savvy. I've noted the rise in apps now
distributed as ".run" images - all the needed code fully
included in the executable. They're bigger - but they
work no matter what. No compile/link BS.

On 2023-12-22 05:49, 56g.1183 wrote:
>
>   There are rumors that Winders is headed in the same direction
>   because what-is has become just a total Gordian Knot and they
>   can't maintain it or predict interactions.

Any links to confirm that ?

> Part of the
>   problem is the programmers - they link their code to
>   VERY VERY specific versions of libs, alas OTHER ones
>   also do so - and their needs/requirements are not going
>   to be the same all the time. If you don't have lib-XYZ
>   version 8.33.04 then they freak.

How do you do that in practice ?
When I link with say PostgreSQL's libpq
which is the native lib for accessing the database as a client,
I add '-lpq' to the link command.

That is it. How do I tie it to a specific version of the lib?

--
/Björn

Bj?rn Lundin <bnl@nowhere.com> wrote:
> On 2023-12-22 05:49, 56g.1183 wrote:
>> Part of the
>> problem is the programmers - they link their code to
>> VERY VERY specific versions of libs, alas OTHER ones
>> also do so - and their needs/requirements are not going
>> to be the same all the time. If you don't have lib-XYZ
>> version 8.33.04 then they freak.
>
> How do you do that in practice ?
> When I link with say PostgreSQL's libpq
> which is the native lib for accessing the database as a client,
> I add '-lpq' to the link command.
>
> That is it. How do I tie it to a specific version of the lib?

As with all the best options, I can't find it documented in the
GCC manual, but I think it's something like "-l:libxyz.so.1.2.3"
to specify an explicit shared object file to link against.

Ah OK, it's mentioned in the ld(1) man page, but not in the GCC
manual. But gcc will also pass it through to ld, I think.

The complaint probably wasn't really about that though, rather
about new versions of libraries changing their ABI and thereby
forcing users to match library versions to the program they want
to use. Really it's the fault of the library developers more than
the application developers, although it might sometimes be fair to
blame the latter for choosing to use unstable libraries in the
first place. It's hardly a rare problem though, with OpenSSL being
a prime example.

Also the Debian package manager can be unnecessarily picky about
library versions sometimes, which I think is the trouble that a
previous incarnation of 56g.1183 complained about at length once
before.

--
__ __
#_ < |\| |< _# | Note: I won't see posts made from Google Groups |

On 12/22/23 8:21 AM, Björn Lundin wrote:
> On 2023-12-22 05:49, 56g.1183 wrote:
>>
>>    There are rumors that Winders is headed in the same direction
>>    because what-is has become just a total Gordian Knot and they
>>    can't maintain it or predict interactions.
>
> Any links to confirm that ?

Not as such ... I just "hear things", 'rumors', as said.
It'd be a big Top Secret at M$ regardless.

However I think it's their ONLY sane path. Apple knew
this some time ago. M$ has been stubborn - but it's
still an increasing functional/security nightmare and
SOMETHING needs to be done.

>>    Part of the
>>    problem is the programmers - they link their code to
>>    VERY VERY specific versions of libs, alas OTHER ones
>>    also do so - and their needs/requirements are not going
>>    to be the same all the time. If you don't have lib-XYZ
>>    version 8.33.04 then they freak.
>
>
> How do you do that in practice ?

The crux of the proverbial biscuit lies with the
practice of re-compiling apps/updates when you go
to install them. The THEORY is that it makes them
most compatible with your specific distro/version
but in PRACTICE it seems to enhance the library curse
these days. The sheer diversity of distros/sub-distros
keeps exacerbating the issue. There is a "standard
Winders", but NO "standard Linux/Unix" at the core.

As I noted somewhere, I keep seeing more and more apps
distributed as ".run" style executables. All the libs
used to compile it are contained within the (fat)
executable. It doesn't have to dynamically link-to
anything. HOWEVER - they'll run on almost any kind
of Linux/Unix - no bitching because lib-XYZ 8.33.04
is missing, no bitching because installing 8.33.04
will destroy everything using 8.33.03

I see this crap ALL the damned time. Use something
like Synaptic and try to install some slightly
newer lib - and SEE the gigantic list of progs
that will be UN-installed because of it - often
your core stuff.

Tried to install a newer/better version of ffmpeg
not so long ago. It was a bottomless rabbit-hole
of dependencies and dependencies for dependencies
and can't-get-there-from-here's. FORGET THAT CRAP !

> When I link with say PostgreSQL's libpq
> which is the native lib for accessing the database as a client,
> I add '-lpq' to the link command.
>
> That is it. How do I tie it to a specific version of the lib?

As said, when you install/upgrade whatever is compiled
on your box. The install script contains which libs
are supposed to be there. If they aren't it will try
to FIND them - but then that messes with your EXISTING
progs.

I've seen this get worse and worse over 20 years. The
more distros/variants out there the worse it gets.

Winders, on the other hand, has tremendous backwards
compatibility. The only thing that kinda broke it was
the newest requirement for Gen8+ processors, and none
of them support 8/16 code anymore. However if you
use something below Win-11 and have a CPU that WILL
still execute 8/16 code then whatever will WORK without
complaints. That's just extraordinary.

I have an old Core-2-Quad board that can run XP. It's
not such a slouch either. Can still run most .com progs
I wrote for the original IBM-PCs.

If Linux is to move forwards it too needs this degree
of backwards compatibility - and between all distros.
No more re-compiling everything over and over and
over again every time there's the slightest tweak.
Sounded like a good plan - but it's getting less good
all the time. 'Diversity' in this case becomes a
liability.

Been with Linux since Slack and RedHat on 5-1/4 floppies.
Overall the superior paradigm, but there ARE problems too.

On 12/22/23 5:52 PM, Computer Nerd Kev wrote:
> Bj?rn Lundin <bnl@nowhere.com> wrote:
>> On 2023-12-22 05:49, 56g.1183 wrote:
>>> Part of the
>>> problem is the programmers - they link their code to
>>> VERY VERY specific versions of libs, alas OTHER ones
>>> also do so - and their needs/requirements are not going
>>> to be the same all the time. If you don't have lib-XYZ
>>> version 8.33.04 then they freak.
>>
>> How do you do that in practice ?
>> When I link with say PostgreSQL's libpq
>> which is the native lib for accessing the database as a client,
>> I add '-lpq' to the link command.
>>
>> That is it. How do I tie it to a specific version of the lib?
>
> As with all the best options, I can't find it documented in the
> GCC manual, but I think it's something like "-l:libxyz.so.1.2.3"
> to specify an explicit shared object file to link against.
>
> Ah OK, it's mentioned in the ld(1) man page, but not in the GCC
> manual. But gcc will also pass it through to ld, I think.
>
> The complaint probably wasn't really about that though, rather
> about new versions of libraries changing their ABI and thereby
> forcing users to match library versions to the program they want
> to use. Really it's the fault of the library developers more than
> the application developers, although it might sometimes be fair to
> blame the latter for choosing to use unstable libraries in the
> first place. It's hardly a rare problem though, with OpenSSL being
> a prime example.
>
> Also the Debian package manager can be unnecessarily picky about
> library versions sometimes, which I think is the trouble that a
> previous incarnation of 56g.1183 complained about at length once
> before.

You're mostly correct here. The prob is that anytime you apt install
anything the source of the desired pgm is compiled on YOUR box.
The dependencies list is part of the info in what you're installing.

But, if you have to replace xxx-2.3.4 with xxx-2.3.5 then all
the installers freak out and want to un-install some, or a LOT,
of what you already have because it's not "compatible".

This BS is why we see more and more apps distributed as ".run"
style code - completely self-contained, requiring NO re-compile.
So long as the Linux kernel doesn't change TOO much they'll
Just Work. This is not necessarily in the best interests of
"open source", but it IS in the bests interests of "I will
run fine almost anywhere".

I first encountered this with
"Balena Etcher" but just last week I got the much-larger
"OpenShot" video-editor ... also a stand-alone executable.
I think this is the future - a way AROUND the infinitely-
deep dependencies rabbit-hole.

With now SUCH diversity in distros/sub-distros the "compile
from scratch on install" model is NOT helping things.

Win does NOT have an inbuilt C/C++ compiler. It relies
on an all-compatible core. You install ready-2-go
executables and (with a little magic in the background)
it Just Works. People LIKE that. No spending hours
or days dealing with microscopic dependencies issues.

And yes, Deb installers ARE very picky. They are writ
to try and ensure "solidity" and total compatibility.
This is most important for BIG concerns ... but most
of us aren't Bank Of America or the CIA.

On Fri, 22 Dec 2023 23:48:53 -0500
"56g.1183" <56g.1183@ztq4.net> wrote:

> You're mostly correct here. The prob is that anytime you apt install
> anything the source of the desired pgm is compiled on YOUR box.

It most certainly is NOT!

Compiling a .deb package is quite complex usually involving a
docker based build environment, the source package (which is not the same
as the binary package that is normally used and a degree of understanding
and patience. We have a number of packages with local source patches so
this process is very familiar to me.

It does not happen when you apt install $PACKAGE - that process
simply installs the various files binaries, libraries, config etc. along
with the dependencies. You can apt install a package on a system without a
compiler.

> The dependencies list is part of the info in what you're installing.

Yes it is and the install operation will fetch any dependencies
that you lack and will upgrade anything that is too old. The dependencies
can specify the dependent package optionally with minimum and maximum or
even specified versions.

The problem is that the universe of packages does not form a
coherent set - this is not a problem with FreeBSD or NetBSD packages
because they *do* form a coherent set.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

"56g.1183" <56g.1183@ztq4.net> writes:
> On 12/22/23 8:21 AM, Björn Lundin wrote:
>> On 2023-12-22 05:49, 56g.1183 wrote:
>>> There are rumors that Winders is headed in the same direction
>>> because what-is has become just a total Gordian Knot and they can't
>>> maintain it or predict interactions.
>> Any links to confirm that ?
>
> Not as such ... I just "hear things", 'rumors', as said.
> It'd be a big Top Secret at M$ regardless.
>
> However I think it's their ONLY sane path. Apple knew
> this some time ago. M$ has been stubborn - but it's
> still an increasing functional/security nightmare and
> SOMETHING needs to be done.

This idea is detached from reality. Microsoft are committed to backward
compatibility with existing application software, and maintaining that
in such a fundamental rewrite is not possible.
https://www.hyrumslaw.com/ is relevant here.

Apple have never had the same compatibility goals, and have regularly
killed application software backward compatibility.

--
https://www.greenend.org.uk/rjk/

On Fri, 22 Dec 2023 23:22:55 -0500
"56g.1183" <56g.1183@ztq4.net> wrote:

> The crux of the proverbial biscuit lies with the
> practice of re-compiling apps/updates when you go
> to install them.

I'll say it again - this does NOT happen. You have thoroughly
misunderstood the root cause of the problem, which is that there the
available packages do not form a coherent set in most (all?) Linux distros.
Instead it is easy to find yourself installing package A which depends on
library L < 1.0 and package B which depends on library L > 2.0.

Windows is not immune to this - in that world it is known as
DL-Hell.

This does not happen with FreeBSD packages because they are all
built together as a consistent set. The downside of this approach is that
the package build takes several days and so the rate of package updates is
limited.

For the record dynamic linking happens at runtime not install time,
that's what makes it dynamic.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem A Rivet's Shot <steveo@eircom.net> writes:
> "56g.1183" <56g.1183@ztq4.net> wrote:
>> The crux of the proverbial biscuit lies with the practice of
>> re-compiling apps/updates when you go to install them.
>
> I'll say it again - this does NOT happen. You have thoroughly
> misunderstood the root cause of the problem, which is that there the
> available packages do not form a coherent set in most (all?) Linux
> distros. Instead it is easy to find yourself installing package A
> which depends on library L < 1.0 and package B which depends on
> library L > 2.0.

Debian does ensure consistency in this area (at least in stable &
testing and I think usually in unstable too).

Trying to mix releases will (obviously) create inconsistency, however,
as will taking packages from outside Debian, or deliberately taking an
incoherent subset of offered upgrades.

> Windows is not immune to this - in that world it is known as DL-Hell.

AFAICT the Windows response to the problem is generally to co-install
multiple versions of dependencies. Happens in Linux too - you can easily
have multiple versions of a runtime library with different sonames, for
example.

--
https://www.greenend.org.uk/rjk/

On 23/12/2023 09:07, Richard Kettlewell wrote:
> "56g.1183" <56g.1183@ztq4.net> writes:
>> On 12/22/23 8:21 AM, Björn Lundin wrote:
>>> On 2023-12-22 05:49, 56g.1183 wrote:
>>>> There are rumors that Winders is headed in the same direction
>>>> because what-is has become just a total Gordian Knot and they can't
>>>> maintain it or predict interactions.
>>> Any links to confirm that ?
>>
>> Not as such ... I just "hear things", 'rumors', as said.
>> It'd be a big Top Secret at M$ regardless.
>>
>> However I think it's their ONLY sane path. Apple knew
>> this some time ago. M$ has been stubborn - but it's
>> still an increasing functional/security nightmare and
>> SOMETHING needs to be done.
>
> This idea is detached from reality. Microsoft are committed to backward
> compatibility with existing application software, and maintaining that
> in such a fundamental rewrite is not possible.
> https://www.hyrumslaw.com/ is relevant here.
>
But that law is regularly broken by Microsoft anyway.

> Apple have never had the same compatibility goals, and have regularly
> killed application software backward compatibility.
>
Indeed. Try running Power PC code on an intel platform...

I think you shouldn't be so dismissive.

When you look at what Microsoft is *actually* selling it is mostly a
*consistent* platform for third part applications to run in domestic
and industrial contexts. Not necessarily an *unchanging* one.

Later apps will not run on earlier versions. Developers are quite
capable of porting apps to a newer platform, if that is what is going to
sell the most product.

Look at say Linux Mint. Most casual users would neither know nor care
that it wasn't some version of windows. It behaves in a very similar way
at user (rather than admin) levels.

What is crucial is that its API is completely different to Windows or OS/X.
But look at say MATE. Built on top of Gnome, which is built on top of
X-windows.

It is not beyond the bounds of credibility for Microsoft to create an
API with exactly the same calls into it as in Windows, and call that
Microsoft X Windows or whatever, and *sell* that to run on Linux.
Programs would need relinking with that library in order to create linux
executables, but that wouldn't be a huge issue for most vendors.

And if that relieves Microsoft of a layer of development they really
don't want to do, and allows them to concentrate on what brings in the
money, I don't see why they wouldn't.

What would be the worst issue is hardware drivers which would inevitably
have to change as I don't think a compatibility shim would really work.

Full backwasswards compatibility for .exes is simply down to providing
e.g. Virtualbox as standard equipped with whatever legacy version of
windows people wanted. Until Intel chips become obsolete and the whole
world goes ARM...

The world is changing, and what looks to be relevant is that ARM based
hardware is where consumers are going. And you cant have legacy WINTEL
apps on that anyway.

The more interesting question is where industrial computing is going.
Apple still hold sway in the graphics and sound processing areas, but
when it comes to CAD CAM I don't think windows really has a rival. But
that is a real chicken and egg situation. People buy the computer for
the application, and if it only ran on Linux, they would buy Linux (or a
computer with it preinstalled). Just as they do with IBM .

Many other industrial apps are becoming heavily cloud based - an
interface to a large corporate database is probably better dine by a web
browser anyway, and who cares what is underneath.

The real issue for me if I was in charge of Microsoft, after the failure
to crack mobile phones or fondleslabs is 'where are we going? What do we
have that is a unique selling point? And how do we leverage that into
future sales?'

Microsoft started out as a BASIC interpreter. Then a character based
standardised operating system, where it was clear that the
standardisation was far more important than the actual performance,
stability or security.

If Microsoft decided that the new standard format was going to be a
Windows look and feel window manager and an API stuck on top of a Linux
core, I don't think most people would be unhappy about the fact it
couldn't run legacy .exes. Most of them are still running XP anyway,
because it was 'more than good enough' . And if wrapped in a sandboxed
virtual machine, it's also secure enough.

Basically if existing applications could be rapidly re-linked, or
recompiled to run on 'Windows on Linux on Intel, with legacy Virtual
box' or 'Windows on Linux, on ARM' I think the apps guys would be happy.
The hardware guys would be happy too, as all of their kit would be
obsolete,so they would just bring out Linux drivers for *new* kit.

--
For in reason, all government without the consent of the governed is the
very definition of slavery.

Jonathan Swift

On 23/12/2023 09:50, Ahem A Rivet's Shot wrote:
> On Fri, 22 Dec 2023 23:22:55 -0500
> "56g.1183" <56g.1183@ztq4.net> wrote:
>
>> The crux of the proverbial biscuit lies with the
>> practice of re-compiling apps/updates when you go
>> to install them.
>
> I'll say it again - this does NOT happen.

It sort of does with kernels ... AIUI the modules are linked at least.
Though not necessarily compiled, as such.

--
New Socialism consists essentially in being seen to have your heart in
the right place whilst your head is in the clouds and your hand is in
someone else's pocket.

On 23 Dec 2023 at 12:06:57 GMT, "The Natural Philosopher"
<tnp@invalid.invalid> wrote:

> The world is changing, and what looks to be relevant is that ARM based
> hardware is where consumers are going. And you cant have legacy WINTEL
> apps on that anyway.

Sure you can - and do. SWMBO has an M1 Mini - which of course has an ARM CPU.
All her old intel-based software runs with no issues. Of course that means not
just having Rosetta, but also all the libs and frameworks have to be supplied
in both intel and ARM binary formats. That means twice as much testing at the
dev stage for new OS versions too. Which is why at some point a future OS
version will only come with the ARM versions, and all your old apps will
become history. The alternative would have been to keep frameworks/libs
avialable in 32/64 bit versions, and in PowerPC/intel/ARM versions. So, 5 or 6
versions of all libs and frameworks.

Windows is going to face something similar too, if they really want to push
moving to ARM.

--
Tim

The Natural Philosopher <tnp@invalid.invalid> writes:
> It is not beyond the bounds of credibility for Microsoft to create an
> API with exactly the same calls into it as in Windows, and call that
> Microsoft X Windows or whatever, and *sell* that to run on
> Linux. Programs would need relinking with that library in order to
> create linux executables, but that wouldn't be a huge issue for most
> vendors.

It’d be a crazy thing to do. Huge amounts of effort to maintain
compatibility, compared to the much easier strategy of just keeping the
existing Windows codebase trundling along. Which is, demonstrably, what
they’re actually doing.

And for what? The end result would be a Windows API implementation on
top of a kernel designed for a completely different application layer.

--
https://www.greenend.org.uk/rjk/