From Newsgroup: alt.os.linux.slackware

Hi, guys

I'm in the process of upgrading my Slackware 14.2 CUPS service in order
to accommodate my system's new "IPP Everywhere" printer (a Brother
MFC-L8610cdw colour laser printer). As is my standard, I install
self-compiled programs and libraries under the /usr/local tree, so as
to distinguish them from the Slackware provided programs and libraries
found elsewhere, and I did so for this new version of CUPS. For the
record, I upgraded
qpdf to v8.3.0 (required by cups-filters),
cups to Openprinting Cups v2.4.14,
cups-filters to Openprinting Cups v1.28.16, and
gutenprint to v5.3.5

I built these in a "clean room" install of Slackware 14.2 running under
LXC on my development box, and (after some back and forth with ./configure settings) I managed to get the laser printer to work with this new
version of Cups. However, when I installed these upgrades (packaged as locally-built Slackware packages), my (hardware) Slackware 14.2 system
would not print, complaining of a cups "filter failure".

It turns out that the Slackware aaa_elflibs package includes two
libraries that the Cups package also supplies (/usr/lib64/libcups.so.2
and /usr/lib64/libcupsimage.so.2), which (as they had regestered in
ld.so.conf ahead of my new libraries) interfered with the proper
execution of the new filters.

I temporarily worked around this by softlinking those two libraries
to my new libraries in /usr/local/lib64, and managed to properly print
to the new printer. I recognize that this solution does not represent
the best fix for the problem, andI will pursue a better solution as I
progress in this install.

So, a caveat for those of you who are looking at replacing Cups, if
you find that you get filter failures when you shouldn't, check for
interfering libraries that aaa_elflibs may have populated.

TTFN
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Fri, 31 Oct 2025 15:07:33 -0000 (UTC), Lew Pitcher wrote:

It turns out that the Slackware aaa_elflibs package includes two
libraries that the Cups package also supplies (/usr/lib64/libcups.so.2
and /usr/lib64/libcupsimage.so.2), which (as they had regestered in >ld.so.conf ahead of my new libraries) interfered with the proper
execution of the new filters.

I temporarily worked around this by softlinking those two libraries
to my new libraries in /usr/local/lib64, and managed to properly print
to the new printer. I recognize that this solution does not represent
the best fix for the problem, andI will pursue a better solution as I >progress in this install.

So, a caveat for those of you who are looking at replacing Cups, if
you find that you get filter failures when you shouldn't, check for >interfering libraries that aaa_elflibs may have populated.

That's some good sleuthing work :) Thanks for sharing.

You wouldn't think printing would be on the list of "things that must absolutely work immediately after aaa_elflibs is installed and other system packages might be partially installed" (if I'm thinking correctly of aaa_elflibs' purpose)




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Fri, 31 Oct 2025 15:07:33 +0000, Lew Pitcher wrote:

Hi, guys

I'm in the process of upgrading my Slackware 14.2 CUPS service in order
to accommodate my system's new "IPP Everywhere" printer (a Brother MFC-L8610cdw colour laser printer). As is my standard, I install self-compiled programs and libraries under the /usr/local tree, so as
to distinguish them from the Slackware provided programs and libraries
found elsewhere, and I did so for this new version of CUPS. For the
record, I upgraded
qpdf to v8.3.0 (required by cups-filters),
cups to Openprinting Cups v2.4.14,
cups-filters to Openprinting Cups v1.28.16, and
gutenprint to v5.3.5

I built these in a "clean room" install of Slackware 14.2 running under
LXC on my development box, and (after some back and forth with ./configure settings) I managed to get the laser printer to work with this new
version of Cups. However, when I installed these upgrades (packaged as locally-built Slackware packages), my (hardware) Slackware 14.2 system
would not print, complaining of a cups "filter failure".

It turns out that the Slackware aaa_elflibs package includes two
libraries that the Cups package also supplies (/usr/lib64/libcups.so.2
and /usr/lib64/libcupsimage.so.2), which (as they had regestered in ld.so.conf ahead of my new libraries) interfered with the proper
execution of the new filters.

I temporarily worked around this by softlinking those two libraries
to my new libraries in /usr/local/lib64, and managed to properly print
to the new printer. I recognize that this solution does not represent
the best fix for the problem, andI will pursue a better solution as I progress in this install.

OK, I have found a better solution to my library problem. I removed
the /usr/lib64 symlinks I used to bypass the problem, and restored the
two aaa_elflibs libraries to /usr/lib64 (/usr/lib64/libcups.so.2 and /usr/lib64/libcupsimage.so.2)

Then I revised my /etc/ld.so.conf to place
/usr/local/lib64
ahead of
/usr/lib64
and reran ldconfig.

This updated the cache so that the dynamic linker will find the /usr/local/lib64 libraries before it finds the /usr/lib64 libraries,
and, thus, allows my new, locally-compiled cups libraries to supercede
the aaa_elflibs-supplied libraries.

I'm going to call this problem done for now.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Fri, 31 Oct 2025 19:32:21 +0000, Lew Pitcher wrote:

Then I revised my /etc/ld.so.conf to place
/usr/local/lib64
ahead of
/usr/lib64
and reran ldconfig.

Yes, that seems like the best solution to me. Now, all you need to think
about is to be careful not to install any dynamic libraries in /usr/local/ lib64 which you do _not_ want to allways be used instead of any libraries
in /usr/lib64.

If you want to install some software with its own dynamic libraries that
you don't want to be used by other software you can instead install that software below /opt and make a script in /usr/local/bin which sets the environment variable LD_LIBRARY_PATH before calling the binary.

Some software, especially non open source software tend to ship with
their own dynamic libraries which might mess things up for other programs.

Another, more intrusive, solution might be to consider upgrading to
Slackware 15.0. As security updates Slackware 15.0 got cups version
2.4.14 12/9 2025 and cups-filter 1.28.17 1/10 2024. Before any switch to
the 1.28.17 package (or build script) from Slackware 15.0 you might want
to consider the pros and cons of:

-8<-------------------------------------- patches/packages/cups-filters-1.28.17-x86_64-2_slack15.0.txz: Rebuilt.
Mitigate security issue that could lead to a denial of service or
the execution of arbitrary code.
Rebuilt with --with-browseremoteprotocols=none to disable incoming
connections, since this daemon has been shown to be insecure. If you
actually use cups-browsed, be sure to install the new
/etc/cups/cups-browsed.conf.new containing this line:
BrowseRemoteProtocols none
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2024-47176
(* Security fix *)
-8<--------------------------------------

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sat, 01 Nov 2025 09:54:04 +0000, Henrik Carlqvist wrote:

Another, more intrusive, solution might be to consider upgrading to
Slackware 15.0.

Anyone at this point contemplating an OS upgrade, should be looking at -current and not a near three year old release
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 02 Nov 2025 09:36:16 +1000, noel wrote:

Anyone at this point contemplating an OS upgrade, should be looking at -current and not a near three year old release

Anyone willing to be a long term beta tester should consider current for
non critical machines which you do not depend upon too much.

The fact that Lew is still sticking to 14.2 indicates a fear that an
upgrade would break something important. On current there is a risk that breaking updates can come any day.

Yes, it was more than three years since Slackware 15.0 was released (2022-02-03), but it is still a supported version of Slackware which gets security updates and bug fixes. However, if you want to run Slackware
15.0 on some newer hardware you might need to replace the longterm 5.15 kernel.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 02 Nov 2025 12:38:18 +0000, Henrik Carlqvist wrote:

On Sun, 02 Nov 2025 09:36:16 +1000, noel wrote:

Anyone at this point contemplating an OS upgrade, should be looking at
-current and not a near three year old release

Anyone willing to be a long term beta tester should consider current for
non critical machines which you do not depend upon too much.

Agreed, I'd never upgrade to the moving target of -current. Pat doesn't necessarily guarantee the stability of -current; it is a "work in progress".

The fact that Lew is still sticking to 14.2 indicates a fear that an
upgrade would break something important. On current there is a risk that breaking updates can come any day.

Good point, and there is a bit of that. But, moreover, I don't have the
time, at the moment, to upgrade my 3 Slackware 14.2 systems, two of which
are 24/7 operations (one handling my internet presence, along with some ancillary duties, and the other handling my telephone system).

I have an upgrade process that takes some of the pain out of a full
upgrade, but it takes a bit of setup time, and a lot of after-install adjustments, for each system.

Yes, it was more than three years since Slackware 15.0 was released (2022-02-03), but it is still a supported version of Slackware which gets security updates and bug fixes. However, if you want to run Slackware
15.0 on some newer hardware you might need to replace the longterm 5.15 kernel.

In fact, I've installed the kernel from Slackware 15.0 on one of my
Slackware 14.2 systems, just because of that point. And, I have it
in the cards to upgrade my systems, so long as I can get a week or
so of uninterrupted time to do so.
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sat, 01 Nov 2025 09:54:04 +0000, Henrik Carlqvist wrote:

On Fri, 31 Oct 2025 19:32:21 +0000, Lew Pitcher wrote:

Then I revised my /etc/ld.so.conf to place
/usr/local/lib64
ahead of
/usr/lib64
and reran ldconfig.

Yes, that seems like the best solution to me. Now, all you need to think about is to be careful not to install any dynamic libraries in /usr/local/ lib64 which you do _not_ want to allways be used instead of any libraries
in /usr/lib64.

If you want to install some software with its own dynamic libraries that
you don't want to be used by other software you can instead install that software below /opt and make a script in /usr/local/bin which sets the environment variable LD_LIBRARY_PATH before calling the binary.

I'm careful as to what goes into the /usr/local tree, and don't blindly populate it. Nothing in this tree (other than this CUPS issue) conflicts
with existing /usr/{bin,sbin,lib64} executables, and I try to keep it
that way.

I did try the LD_LIBRARY_PATH route, but still got the "filter failed"
errors that (seem to) come from conflicting libraries. But, it was
a good idea, and I wish it had worked.

Some software, especially non open source software tend to ship with
their own dynamic libraries which might mess things up for other programs.

Another, more intrusive, solution might be to consider upgrading to Slackware 15.0. As security updates Slackware 15.0 got cups version
2.4.14 12/9 2025 and cups-filter 1.28.17 1/10 2024. Before any switch to
the 1.28.17 package (or build script) from Slackware 15.0 you might want
to consider the pros and cons of:

-8<-------------------------------------- patches/packages/cups-filters-1.28.17-x86_64-2_slack15.0.txz: Rebuilt.
Mitigate security issue that could lead to a denial of service or
the execution of arbitrary code.
Rebuilt with --with-browseremoteprotocols=none to disable incoming
connections, since this daemon has been shown to be insecure. If you
actually use cups-browsed, be sure to install the new
/etc/cups/cups-browsed.conf.new containing this line:
BrowseRemoteProtocols none
For more information, see:
https://www.cve.org/CVERecord?id=CVE-2024-47176
(* Security fix *)
-8<--------------------------------------

Thanks, Henrik, for the heads-up. I had already seen the various
notices about cups-browsed. Those notices, in part, motivated
this move to a network-attached printer that each CUPS instance
can access independently, without the need of cups-browsed.

Where I /had/ used cups-browsed, I now have it disabled.
And, when I downloaded the cups-filters source from Openprinting.org
they only offered 1.28.16 and a version they called "1.20251004"
(which seemed, shall we say, "experimental" to me).

I'll check Openprinting.org again, to see what they have released
now (perhaps PV used the 1.20251004 release as 1.28.17).
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:

And, when I downloaded the cups-filters source from Openprinting.org
they only offered 1.28.16 and a version they called "1.20251004"
(which seemed, shall we say, "experimental" to me).

I'll check Openprinting.org again, to see what they have released
now (perhaps PV used the 1.20251004 release as 1.28.17).

Check this URL for cups-filter releases: https://github.com/OpenPrinting/cups-filters/releases
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 02 Nov 2025 12:38:18 +0000, Henrik Carlqvist wrote:

On Sun, 02 Nov 2025 09:36:16 +1000, noel wrote:

Anyone at this point contemplating an OS upgrade, should be looking at
-current and not a near three year old release

Anyone willing to be a long term beta tester should consider current for
non critical machines which you do not depend upon too much.

The fact that Lew is still sticking to 14.2 indicates a fear that an
upgrade would break something important. On current there is a risk that breaking updates can come any day.

Breakage, mostly on desktops, servers, not so much, I ran all of our smtp servers on -current for 18 months before 15.0 was eventually released,
but being behind hardware load balancer if they fell over (staggered
updates), and throw the old OS drives back in, eventually ran every
single server including web servers (we had to or fail PCI DSS
compliance) on -current for about 12 months or just over, nothing missed
a beat.


Im considering doing the same again now since I dont expect 15.1 out any
year soon, and I am open to a complete OS change, we already had to move
a couple services to debian

Yes, it was more than three years since Slackware 15.0 was released (2022-02-03), but it is still a supported version of Slackware which
gets security updates and bug fixes.

being supported and being "current" (eg: libs wise) are two entirely
different things.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 03 Nov 2025 16:05:30 +1000, noel wrote:

being supported and being "current" (eg: libs wise) are two entirely different things.

Yes it is, however in a perfect world, all supported versions of
Slackware should get patches for all security holes in libraries and applications. Current will get newer versions of libraries and
applications, in a perfect world those newer versions will be considered stable by upstream providers, but the newer versions might not be
backwards compatible with all the configuration files that you have.

In practice however, supported Slackware stable versions might silently
stop providing updates to libraries and applications when upstream
providers stop releasing versions on those branches. Even though
Slackware usually choose "LTS" versions those "long term support" cycles
from the upstream providers might not be as long as the lifetime of a supported Slackware version.

An example of an upstream provider with rather short release cycles is
samba.

Slackware 15.0 shiped with samba version 4.15.5 which back then was the current stable release of samba. A little more than a month later the
4.15 series of Samba went from "latest stable" to "maintenance mode". 2022-09-13 the 4.15 series of samba went to "security fixes only" and 2023-03-08 the 4.15 series was EOL.

It seems as if the 4.18 series of samba was rather backwards compatible
with 4.15 as it was provided as patches to Slackware 15.0, but the 4.22
series of samba has instead been provided in /extra for Slackware 15.0.

Was it because of some library requirement from PCI DSS that you had to upgrade to current?

regards Henrik

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On 2025-10-31, Lew Pitcher wrote:

I'm in the process of upgrading my Slackware 14.2 CUPS service in
order to accommodate my system's new "IPP Everywhere" printer (a
Brother MFC-L8610cdw colour laser printer). As is my standard, I
install self-compiled programs and libraries under the /usr/local
tree, so as to distinguish them from the Slackware provided programs
and libraries found elsewhere, and I did so for this new version of
CUPS. ...
....
I built these in a "clean room" install of Slackware 14.2 running
under LXC on my development box, and (after some back and forth with ./configure settings) I managed to get the laser printer to work with
this new version of Cups. However, when I installed these upgrades
(packaged as locally-built Slackware packages), my (hardware)
Slackware 14.2 system would not print, complaining of a cups "filter failure".

For what it's worth, on the odd occasion that I might "manually"
upgrade a Slackware component that would normally be provided by
the OS, I make a point to at least refer to, if not outright use,
the original SlackBuild script for that package, adapted, of course,
for the new software version that I'm working on installing. It can
easily be adjusted for installing to /usr/local if you insist on
that, but with a package normally installed by the OS, and with
Slackware-14.2 no longer actively getting updates, I rarely find
that using the local installation path is worth it (at least on my
own Slackware-14.2 system).

By using the "official" SlackBuild script, though, you get the
package built as it would likely have been done officially (modulo
any build-time options you handle differently than was done in the
original build script). If there's any question of how to handle
changes in a newer version of the software, it's easy enough to
also refer to the SlackBuild script from Slackware-15.0 or -current,
and adjust your script accordingly.

It turns out that the Slackware aaa_elflibs package includes two
libraries that the Cups package also supplies (/usr/lib64/libcups.so.2
and /usr/lib64/libcupsimage.so.2), which (as they had regestered in ld.so.conf ahead of my new libraries) interfered with the proper
execution of the new filters.

I temporarily worked around this by softlinking those two libraries
to my new libraries in /usr/local/lib64, and managed to properly print
to the new printer. ...

I agree that adjusting ld.so.conf is a better way to resolve this
problem, of course. I do have to admit to wondering why those two
files are even included in aaa_elflibs. No insight is available from
the aaa_elflibs source tree, I'm afraid.

I hope that I've helped you with whatever your next "manual" package
update might be ...
--
----------------------------------------------------------------------
Sylvain Robitaille syl@therockgarden.ca ----------------------------------------------------------------------
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 03 Nov 2025 06:35:52 +0000, Henrik Carlqvist wrote:

considered stable by upstream providers, but the newer versions might
not be backwards compatible with all the configuration files that you
have.

That's why we have major.minor.patch_level version releases of programs,
It's not unheard of Pat releasing new major.minors of programs into
"stable" releases.

An example of an upstream provider with rather short release cycles is
samba.

Samba, php, theres problably dozens more with life cycles of sub 2 years, although php as of this year is gone back to supporting 3 years.

Slackware 15.0 shiped with samba version 4.15.5 which back then was the current stable release of samba. A little more than a month later the
4.15 series of Samba went from "latest stable" to "maintenance mode". 2022-09-13 the 4.15 series of samba went to "security fixes only" and 2023-03-08 the 4.15 series was EOL.

4.15 was released in 2021, 2 year cycle, normal, the fact other key
daemons go longer for major.minor.x doesnt mean all should, but 2 years
is usually fair. Also, last version was earlier, our samba mirror shows: samba-4.15.13.tar.gz 2022-12-16 02:08 18M

It seems as if the 4.18 series of samba was rather backwards compatible
with 4.15 as it was provided as patches to Slackware 15.0, but the 4.22 series of samba has instead been provided in /extra for Slackware 15.0.

On our internal file server I'm running
# smbd -V
Version 4.22.6

ls -la /etc/samba/smb.conf
-rw-r--r-- 1 root root 7118 Dec 10 2020 /etc/samba/smb.conf

IOW, our config is 5 years last time it was edited, and I'm sure that was
just adding s share so the config used here was probably written quite
some time before that with no changes (YMMV as I recall a recent incompatability change if using active directory).

Was it because of some library requirement from PCI DSS that you had to upgrade to current?

several libs, and dont get started on php, which is what sparked the
audit and then we discovered number of libs that failed also (if we didnt
have to audit php, we'd never have found out about the libs) usually this
has not been a problem in the past because we'd get new releases well
before things like that went EOL. php 8.2 ends all support, including security, in a months time, so we now have to re-eval what we are going
to do, we tried 8.4 and it built, but did cause some conflicts - this
was back in February, now its up to 8.4.14 I'm hoping that will be
fixed, so we'll check that again, but that means the guys working over Christmas will be busy one way or another.

postfix also failed, couldnt build the latest versions on 14.2 - (we dont
use Pat's version either even since he replaced sendmail in 15.0 as we
have specific build requirements), have been using postfix since 2008
when we moved to it from qmail/vpopmail setup we'd run for years before.



Cheers
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Thu, 06 Nov 2025 20:44:44 +1000, noel wrote:

On our internal file server I'm running # smbd -V Version 4.22.6

That is at the time of this writing the latest version of Samba provided
for Slackware 15.0 in the /extra directory.

ls -la /etc/samba/smb.conf -rw-r--r-- 1 root root 7118 Dec 10 2020 /etc/samba/smb.conf

IOW, our config is 5 years last time it was edited, and I'm sure that
was just adding s share so the config used here was probably written
quite some time before that with no changes (YMMV as I recall a recent incompatability change if using active directory).

Yes, the fact that they have given themselves the liberty to introduce
non backwards compatible changes does not for sure mean that they will in every fixed date release. And some of those non backwards compatible
changes might only break things for a few users with rare settings in
their smb.conf.

and dont get started on php, which is what sparked the audit

Ouch, php is a beast of its own when it comes to introducing non
backwards compatible changes. "LAMP" used to be a de facto standard when
it comes to web servers, where "LAMP" stands for Linux, Apache, MySQL/
MariaDB and PHP. And what did PHP do a few years back? They completely
rewrote their interface to MySQL/MariaDB in a non backwards compatible
way meaning that anyone who had written a solution for LAMP needed to
rewrite his PHP code.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Fri, 07 Nov 2025 06:36:05 +0000, Henrik Carlqvist wrote:

and dont get started on php, which is what sparked the audit

Ouch, php is a beast of its own when it comes to introducing non
backwards compatible changes. "LAMP" used to be a de facto standard
when it comes to web servers, where "LAMP" stands for Linux, Apache,
MySQL/ MariaDB and PHP. And what did PHP do a few years back? They
completely rewrote their interface to MySQL/MariaDB in a non backwards compatible way meaning that anyone who had written a solution for LAMP
needed to rewrite his PHP code.

I assume you mean mysql to mysqli ? That had been coming for years, they warned it was deprecated and to be removed, they just took so long that programmers saw they didn't need to "rush" - until they did when they
actually finally removed it

Of course as of 8.0 can no longer interface directly with cracklib for
easy password checking, and 8.2 what we use to be able to run in php.ini
as "fallback" and over ride in apache's vhost blocks with php_admin_value
we cant, like disable_functions, now it and select other commands need to
be in php.ini only, apache passes it to mod_php, but php ignores it,
well... at least they didnt take away openbase, that might cause a riot :)

They have now realised the life support system needed a new life itself
and are back to 3 years support per version, although the last being
security only, and was it last night I saw release of 8.5.0 JHFC, they infuriate me.

Cheers
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Fri, 21 Nov 2025 22:01:52 +1000, noel wrote:

On Fri, 07 Nov 2025 06:36:05 +0000, Henrik Carlqvist wrote:

Ouch, php is a beast of its own when it comes to introducing non
backwards compatible changes. "LAMP" used to be a de facto standard
when it comes to web servers, where "LAMP" stands for Linux, Apache,
MySQL/ MariaDB and PHP. And what did PHP do a few years back? They
completely rewrote their interface to MySQL/MariaDB in a non backwards
compatible way meaning that anyone who had written a solution for LAMP
needed to rewrite his PHP code.

I assume you mean mysql to mysqli ?

Yes, thats the API change that I mean.

That had been coming for years, they warned it was deprecated and to be removed, they just took so long that programmers saw they didn't need
to "rush" - until they did when they actually finally removed it

No matter which timeframe, the fact still remains that every single LAMP implementation out there needed to be rewritten when it would have been possible to keep a backwards compatible layer or rewrite the API by only adding functionality without removing any old functinality.

Basically each programming language and library has 3 phases:

1) The unstable phase when new versions might break old code

2) The stable phase when new versions might add functionality but avoid breaking existing code

3) The obsolete phase when another programming language or library would
be an obvious better choice.

I was once very enthusiastic about php, but has since then regretted that
I did choose to implement a few projects in php. The unstable phase
status is also a reason for me to stay away from python, and at least historically it has been a reason for me to avoid C++.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 23 Nov 2025 11:51:41 +0000, Henrik Carlqvist wrote:

No matter which timeframe, the fact still remains that every single LAMP implementation out there needed to be rewritten when it would have been

You cant start to rewrite after several YEARS of warnings?

possible to keep a backwards compatible layer or rewrite the API by only adding functionality without removing any old functinality.

That's a most unrealistic belief, there are reasons they deprecated it
and years later removed it. Are you suggeting EVERY single bit of code
out there work forever until the universe implodes in the next ice age? Because thats what I see you saying, changes happen all the time in all software nix or win. I'm pissed at sangoma for many things they did in
freepbx - but at least PHP gave us YYEEAARRSS of warnings, sangoma just
did it, with piss poor documentation, Sun did it, Oracle does it, dovecot
too.

The brain dead catastrophe that is dovecot 2.4 is mind boggling compared
to all earlier versions and I let Aki and Timo know too, you can not even
do with 2.4 how we process mail using 2.3, so we are stuck on 2.3, which
is fine because its solid, never gives us any problems, and is not a
problem security wise with our configurations thus far, if a high CVE
scored issue arises, we'll see if they are still putting out security
updates, if not, we'll re-evaluate what impact it has on us if any, as we source build and only include components we need, our uses has excluded
us from impacts in years gone by, we could always go back to our sendmail (front ends) -> qmail (lmtp) combo and vpopmail I guess like we used in
the late 90's early 00's :) dovecot gave us no warning on that, again php
gave years and years of warnings.

I was once very enthusiastic about php, but has since then regretted
that I did choose to implement a few projects in php.

php is great for front ends, like roundcube, os ticket, opencart, billing
and provisioning, CRM's and so on, any dev worth their salt is on top of pending situations, especially with php since they are well known for
breakage :)

for me to stay away from python, and at least

yep, python is a resource hog compared to perl, so thats saying
something, and has less than intelligent error messaging, the only place
we use python is in fail2ban which ultimately means its on every server. everything else in the backend is C, perl or bash.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Sun, 14 Dec 2025 11:29:56 +1000, noel wrote:

You cant start to rewrite after several YEARS of warnings?

Of course I can, and of course I finally did, but spending those hours of unpaid work made me regret my choice of PHP.

Are you suggeting EVERY single bit of code out there work forever until
the universe implodes in the next ice age?

I am saying that breaking existing code is a sign of an unstable API not
ready for production. This is a fact which even has made me avoid C++.

Because thats what I see you saying, changes happen all the time in all software nix or win.

Do you have any such example of a backwards breaking compatibility API
change in any C function described by a man page where the "conforming
to" section refers to some posix standard?

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

Henrik Carlqvist writes:

Do you have any such example of a backwards breaking compatibility API
change in any C function described by a man page where the "conforming
to" section refers to some posix standard?

Certainly: putenv().

It changed behavior from POSIX.1-2001 to POSIX.1-2008


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

On Mon, 15 Dec 2025 07:06:50 -0500, Sam wrote:

Henrik Carlqvist writes:

Do you have any such example of a backwards breaking compatibility API
change in any C function described by a man page where the "conforming
to" section refers to some posix standard?

Certainly: putenv().

It changed behavior from POSIX.1-2001 to POSIX.1-2008

If I understand things right, the stipulated behavior of putenv didn't
change between POSIX.1-2001 and POSIX.1-2008 but between SUSv2 and SUSv3
where SUSv3 also got known as POSIX.1-2001. But yes, you are right, the implemented behavior did change when later glibc decided to implement the SUSv2 behavior which requires the input string to be static or malloced.

regards Henrik
--- Synchronet 3.21a-Linux NewsLink 1.2