On 4/22/24 8:16 AM, John McCue wrote:
> Mich <mich@none.edu> wrote:
>> I dug out an old workstation with Centos 8 stream. (...snip)
>> It is more or less going to remove KDE Plasma if I say y.
>
> Not a big surprise to me :(
>
> When I had a RHEL Workstation, when I upgraded from 7 to 8
> (or 8-9?), KDE was broken during that upgrade and Fluxbox
> started to have issues too.
>
> Seems RHEL wants you to use GNOME or nothing. On Fluxbox
> some applications and almost all proprietary applications I
> had to use at work would fail unless you are running GNOME 3.
> Same with KDE, but pieces of KDE would also fail.
>
> At the time, I did a search and seems Red Hat is doing all
> it can to prevent the use of KDE on RHEL. Maybe that
> philosophy moved to CentOS.
>
> Sad to say, may be time to move to another distro.

Look, it's not JUST RHEL/Centos/Etc (though now you
are kinda being a beta-tester for IBM by using
Centos).

One of the biggest issues with Linux is the "dependencies
problem". Everything is writ to use THE existing versions
of libs and such and you can't update one thing without
parallel updates on everything downstream, and downstream
from them and ....

As the OS and selection of apps got much bigger, this
problem became much bigger. It's almost in an 'exponential'
phase now. SOMEWHERE you're gonna run into a missing
dependency.

For all its crappiness, DOS/Winders is MUCH better in
this respect. Hell, I've got an old Core-2-Quad board
that will still run 8/16 DOS apps from the Ancient Days.
Anybody remember ".COM" files ? :-)

Library writers are expected to maintain backwards
compatibility, so it doesn't matter if your app is 2024
and yer libs are 1994. So long as they exist, things
generally work pretty well. This has changed a bit
for Win 11/12 ... dem bastards ... but still most of
yer older apps will still run fine.

Linux needs a new paradigm, kind of like with Win.
Alas I think Linux is too set-in-stone and this
will never happen. We will have to wait for some
whole new OS.

As for RHEL/etc and Gnome ... it's a HORRIBLE
GUI ! Don't know WHY they're so stuck on it.

On 2024-06-01, 26xh.0717 <26xh.0718@e6t4y.net> wrote:
> On 4/22/24 8:16 AM, John McCue wrote:
>> Mich <mich@none.edu> wrote:
>>> I dug out an old workstation with Centos 8 stream. (...snip)
>>> It is more or less going to remove KDE Plasma if I say y.
>>
>> Not a big surprise to me :(
>>
>> When I had a RHEL Workstation, when I upgraded from 7 to 8
>> (or 8-9?), KDE was broken during that upgrade and Fluxbox
>> started to have issues too.
>>
>> Seems RHEL wants you to use GNOME or nothing. On Fluxbox
>> some applications and almost all proprietary applications I
>> had to use at work would fail unless you are running GNOME 3.
>> Same with KDE, but pieces of KDE would also fail.
>>
>> At the time, I did a search and seems Red Hat is doing all
>> it can to prevent the use of KDE on RHEL. Maybe that
>> philosophy moved to CentOS.
>>
>> Sad to say, may be time to move to another distro.
>
> Look, it's not JUST RHEL/Centos/Etc (though now you
> are kinda being a beta-tester for IBM by using
> Centos).
>
> One of the biggest issues with Linux is the "dependencies
> problem". Everything is writ to use THE existing versions
> of libs and such and you can't update one thing without
> parallel updates on everything downstream, and downstream
> from them and ....
>
> As the OS and selection of apps got much bigger, this
> problem became much bigger. It's almost in an 'exponential'
> phase now. SOMEWHERE you're gonna run into a missing
> dependency.
>
> For all its crappiness, DOS/Winders is MUCH better in
> this respect. Hell, I've got an old Core-2-Quad board
> that will still run 8/16 DOS apps from the Ancient Days.
> Anybody remember ".COM" files ? :-)
>
> Library writers are expected to maintain backwards
> compatibility, so it doesn't matter if your app is 2024
> and yer libs are 1994. So long as they exist, things
> generally work pretty well. This has changed a bit
> for Win 11/12 ... dem bastards ... but still most of
> yer older apps will still run fine.
>
> Linux needs a new paradigm, kind of like with Win.
> Alas I think Linux is too set-in-stone and this
> will never happen. We will have to wait for some
> whole new OS.
>
> As for RHEL/etc and Gnome ... it's a HORRIBLE
> GUI ! Don't know WHY they're so stuck on it.

I will say this is one thing that I do think Microsoft have done very
well, backwards binary compatibility. It has come at a cost, the OS
has to have cruft to support these old programs, but binary backward
compatibility IS important. Linux doesn't fare as well, mostly
because the libraries break. But then again, DOS programs are self
contained, they are statically linked and always contain the library
code within the application, whereas with Unix, theyve used system
libraries from the start, and this makes backwards compatibility more complex.

I have been able to keep the same Linux binaries running for years and
years, as long as they are just linked against glibc. Those
statically linked, or pure assembler have no issues continuing to run.

I guess its swings and roundabouts as they say, how often do you NEED
to run, natively, a really old binary? Today, I run old .COM files in
DosBox, which gives me a better chance than Windows or even FreeDOS if
that .COM needs EGA or CGA graphics. DosBox runs fine on Linux.

On Sat, 1 Jun 2024 12:44:38 -0000 (UTC), Borax Man wrote:

> I will say this is one thing that I do think Microsoft have done very
> well, backwards binary compatibility.

Sure it is. Which is why “DLL Hell” never happens on Windows, does it?

Except that’s where the phrase was coined.

On Sat, 1 Jun 2024 00:45:35 -0400, 26xh.0717 wrote:

> For all its crappiness, DOS/Winders is MUCH better in this respect.

Sure, that’s why “DLL Hell” never happens on Windows, does it?

Except that’s where the phrase was coined.

On 2024-06-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Sat, 1 Jun 2024 12:44:38 -0000 (UTC), Borax Man wrote:
>
>> I will say this is one thing that I do think Microsoft have done very
>> well, backwards binary compatibility.
>
> Sure it is. Which is why “DLL Hell” never happens on Windows, does it?
>
> Except that’s where the phrase was coined.

It's a simple matter of emprical evidence. Windows 98 when I last
used it supported newer software far more than the Linux Distros
released at the time. I could run early versions of Firefox on
Windows 98SE, as well as Windows 3.1 software from the early 90s.

I never said it wasn't without its problems, but show me a system
which had better backwards compatibility?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Sat, 1 Jun 2024 00:45:35 -0400, 26xh.0717 wrote:
>
>> For all its crappiness, DOS/Winders is MUCH better in this respect.
>
> Sure, that’s why “DLL Hell” never happens on Windows, does it?
>
> Except that’s where the phrase was coined.

IIRC, they did improve the situation somewhat around the time of Win
XP. They did it by brute force though, and just kept around a whole
batch of application-specific DLLs, rather than managing versions on a
system-wide basis like Linux or Unix does.

I feel there were a lot of mistakes made, perhaps from lack of knowledge
and experience, when DOS, Win 3.x and 9x, and then NT were
developed. They've dragged a lot of those problems along with them over
the years, like a stinky diaper they really should change.

Windows has probably been improved in a number of ways over the years,
but "improved" is still relative IMO.

On 2024-06-07, Bud Frede <frede@mouse-potato.com> wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> On Sat, 1 Jun 2024 00:45:35 -0400, 26xh.0717 wrote:
>>
>>> For all its crappiness, DOS/Winders is MUCH better in this respect.
>>
>> Sure, that’s why “DLL Hell” never happens on Windows, does it?
>>
>> Except that’s where the phrase was coined.
>
> IIRC, they did improve the situation somewhat around the time of Win
> XP. They did it by brute force though, and just kept around a whole
> batch of application-specific DLLs, rather than managing versions on a
> system-wide basis like Linux or Unix does.

Much to my chagrin, I discovered a Linux equivalent of DLL Hell a few
weeks ago. I've been upgrading our programs to use a newer SSL library
(libssl.so.1.1 to libssl.so.3), and found a dependency on libc.so.6
which draws a line in the sand between Ubuntu 20 and Ubuntu 22 (and
their Debian equivalents). I've always prided myself on creating
binaries that will run on any version of an OS, but this dream has
been derailed. We've told our Ubuntu 20 customers that if they want
TLS 1.3 they have no choice but to upgrade their OS to Ubuntu 22.
Only then can we send them new binaries. By the same token, our
older binaries, which only support TLS 1.1, will not run under
Ubuntu 22, so if they attempt an OS upgrade our existing stuff
will stop working. It's an unfortunate mess.

> I feel there were a lot of mistakes made, perhaps from lack of knowledge
> and experience, when DOS, Win 3.x and 9x, and then NT were
> developed. They've dragged a lot of those problems along with them over
> the years, like a stinky diaper they really should change.

The way I like to put it, Windows is a shining edifice built over
a rickety old shack whose door squeaks and jams. In the name of
backward compatibility, every door in the new building also squeaks
and jams.

> Windows has probably been improved in a number of ways over the years,
> but "improved" is still relative IMO.

Oh, you mean like ads in the Start button...

--
/~\ 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 6/1/24 8:44 AM, Borax Man wrote:
> On 2024-06-01, 26xh.0717 <26xh.0718@e6t4y.net> wrote:
>> On 4/22/24 8:16 AM, John McCue wrote:
>>> Mich <mich@none.edu> wrote:
>>>> I dug out an old workstation with Centos 8 stream. (...snip)
>>>> It is more or less going to remove KDE Plasma if I say y.
>>>
>>> Not a big surprise to me :(
>>>
>>> When I had a RHEL Workstation, when I upgraded from 7 to 8
>>> (or 8-9?), KDE was broken during that upgrade and Fluxbox
>>> started to have issues too.
>>>
>>> Seems RHEL wants you to use GNOME or nothing. On Fluxbox
>>> some applications and almost all proprietary applications I
>>> had to use at work would fail unless you are running GNOME 3.
>>> Same with KDE, but pieces of KDE would also fail.
>>>
>>> At the time, I did a search and seems Red Hat is doing all
>>> it can to prevent the use of KDE on RHEL. Maybe that
>>> philosophy moved to CentOS.
>>>
>>> Sad to say, may be time to move to another distro.
>>
>> Look, it's not JUST RHEL/Centos/Etc (though now you
>> are kinda being a beta-tester for IBM by using
>> Centos).
>>
>> One of the biggest issues with Linux is the "dependencies
>> problem". Everything is writ to use THE existing versions
>> of libs and such and you can't update one thing without
>> parallel updates on everything downstream, and downstream
>> from them and ....
>>
>> As the OS and selection of apps got much bigger, this
>> problem became much bigger. It's almost in an 'exponential'
>> phase now. SOMEWHERE you're gonna run into a missing
>> dependency.
>>
>> For all its crappiness, DOS/Winders is MUCH better in
>> this respect. Hell, I've got an old Core-2-Quad board
>> that will still run 8/16 DOS apps from the Ancient Days.
>> Anybody remember ".COM" files ? :-)
>>
>> Library writers are expected to maintain backwards
>> compatibility, so it doesn't matter if your app is 2024
>> and yer libs are 1994. So long as they exist, things
>> generally work pretty well. This has changed a bit
>> for Win 11/12 ... dem bastards ... but still most of
>> yer older apps will still run fine.
>>
>> Linux needs a new paradigm, kind of like with Win.
>> Alas I think Linux is too set-in-stone and this
>> will never happen. We will have to wait for some
>> whole new OS.
>>
>> As for RHEL/etc and Gnome ... it's a HORRIBLE
>> GUI ! Don't know WHY they're so stuck on it.
>
> I will say this is one thing that I do think Microsoft have done very
> well, backwards binary compatibility. It has come at a cost, the OS
> has to have cruft to support these old programs, but binary backward
> compatibility IS important. Linux doesn't fare as well, mostly
> because the libraries break. But then again, DOS programs are self
> contained, they are statically linked and always contain the library
> code within the application, whereas with Unix, theyve used system
> libraries from the start, and this makes backwards compatibility more complex.
>
> I have been able to keep the same Linux binaries running for years and
> years, as long as they are just linked against glibc. Those
> statically linked, or pure assembler have no issues continuing to run.
>
> I guess its swings and roundabouts as they say, how often do you NEED
> to run, natively, a really old binary? Today, I run old .COM files in
> DosBox, which gives me a better chance than Windows or even FreeDOS if
> that .COM needs EGA or CGA graphics. DosBox runs fine on Linux.

DosBox is good, as are KVM and VirtualBox. However none
are QUITE as good as running native on the hardware.

I do have a few DOS apps I still use - but I long since
went all Linux/Unix so I don't have to run 'em under
Winders. I also have some DOS apps I just *like* to
run - the old multi-pass 'C' and Pascal compilers
plus Turbo. Wrote a lot of apps for those and it's
fun to bring 'em up and play around. Even have
CP/M-86 and Winders-1 running in VirtualBox.

Still, at least until quite recently, M$ and Intel
DID maintain impressive backwards compatibility.
Linux, except maybe those simpler 'core' type
utilities, has more problems here. TOO many
versions of TOO many libs. It's become a MESS
and an IMPEDIMENT.

Is there a fix ?

On Mon, 3 Jun 2024 03:25:50 -0000 (UTC), Borax Man wrote:

> On 2024-06-02, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>
>> On Sat, 1 Jun 2024 12:44:38 -0000 (UTC), Borax Man wrote:
>>
>>> I will say this is one thing that I do think Microsoft have done very
>>> well, backwards binary compatibility.
>>
>> Sure it is. Which is why “DLL Hell” never happens on Windows, does it?
>>
>> Except that’s where the phrase was coined.
>
> It's a simple matter of emprical evidence. Windows 98 when I last used
> it supported newer software far more than the Linux Distros released at
> the time.

Not sure what this has to do with the well-known Windows phenomenon of
“DLL Hell”.

Do you have any evidence from this century?

On Fri, 07 Jun 2024 18:09:09 GMT, Charlie Gibbs wrote:

> ... and found a dependency on libc.so.6
> which draws a line in the sand between Ubuntu 20 and Ubuntu 22 (and
> their Debian equivalents). I've always prided myself on creating
> binaries that will run on any version of an OS, but this dream has been
> derailed. We've told our Ubuntu 20 customers that if they want TLS 1.3
> they have no choice but to upgrade their OS to Ubuntu 22.
> Only then can we send them new binaries. By the same token, our older
> binaries, which only support TLS 1.1, will not run under Ubuntu 22 ...

Interesting. Were you able to track down the incompatibility any further?
Because it’s always been my understanding that binaries linked against
older versions of libc.so.6 will continue to run against newer versions,
and a lot of work is done with symbol versioning in glibc to ensure this.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 07 Jun 2024 18:09:09 GMT, Charlie Gibbs wrote:
>> ... and found a dependency on libc.so.6 which draws a line in the
>> sand between Ubuntu 20 and Ubuntu 22 (and their Debian equivalents).
>> I've always prided myself on creating binaries that will run on any
>> version of an OS, but this dream has been derailed. We've told our
>> Ubuntu 20 customers that if they want TLS 1.3 they have no choice but
>> to upgrade their OS to Ubuntu 22. Only then can we send them new
>> binaries. By the same token, our older binaries, which only support
>> TLS 1.1, will not run under Ubuntu 22 ...
>
> Interesting. Were you able to track down the incompatibility any further?
> Because it’s always been my understanding that binaries linked against
> older versions of libc.so.6 will continue to run against newer versions,
> and a lot of work is done with symbol versioning in glibc to ensure this.

They do; his issue is the other way around, i.e. trying to run newer
code on older Glibc.

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

Richard Kettlewell <invalid@invalid.invalid> wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Fri, 07 Jun 2024 18:09:09 GMT, Charlie Gibbs wrote:
>>> ... and found a dependency on libc.so.6 which draws a line in the
>>> sand between Ubuntu 20 and Ubuntu 22 (and their Debian equivalents).
>>> I've always prided myself on creating binaries that will run on any
>>> version of an OS, but this dream has been derailed. We've told our
>>> Ubuntu 20 customers that if they want TLS 1.3 they have no choice but
>>> to upgrade their OS to Ubuntu 22. Only then can we send them new
>>> binaries. By the same token, our older binaries, which only support
>>> TLS 1.1, will not run under Ubuntu 22 ...
>>
>> Interesting. Were you able to track down the incompatibility any further?
>> Because it's always been my understanding that binaries linked against
>> older versions of libc.so.6 will continue to run against newer versions,
>> and a lot of work is done with symbol versioning in glibc to ensure this.
>
> They do; his issue is the other way around, i.e. trying to run newer
> code on older Glibc.

It's pretty lucky that it worked before in that case. I thought
Glibc broke backwards compatibility very regularly and therefore
the "line in the sand" might mean an issue with Ubuntu 20's
binaries running on newer Glibc in Ubuntu 22, in spite of the
usual efforts at forwards compatibility.

Musl libc is more forgiving with this, so switching to that might
be a solution provided no Glibc-specific features are being used
by the software or its users. It's packaged for Debian.

--
__ __
#_ < |\| |< _#

not@telling.you.invalid (Computer Nerd Kev) writes:
> Richard Kettlewell <invalid@invalid.invalid> wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> Interesting. Were you able to track down the incompatibility any
>>> further? Because it's always been my understanding that binaries
>>> linked against older versions of libc.so.6 will continue to run
>>> against newer versions, and a lot of work is done with symbol
>>> versioning in glibc to ensure this.
>>
>> They do; his issue is the other way around, i.e. trying to run newer
>> code on older Glibc.
>
> It's pretty lucky that it worked before in that case. I thought Glibc
> broke backwards compatibility very regularly and therefore the "line
> in the sand" might mean an issue with Ubuntu 20's binaries running on
> newer Glibc in Ubuntu 22, in spite of the usual efforts at forwards
> compatibility.

It maintains backward compatibility well, in the sense that executables
and shared libraries built against an older version of Glibc will
generally run on newer versions. That’s what the OP was doing
‘before’. In the instance that didn’t work, they were attempting to do
the opposite.

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