From Newsgroup: comp.unix.programmer

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 4/14/2026 3:55 PM, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

https://www.zdnet.com/home-and-office/work-life/i-speed-tested-11-browsers-and-the-fastest-might-surprise-you/

"Start times [lower is better]

Chromium: 1.95 seconds \
Firefox: 1.93 seconds \___ Tests like this need a *lot* of attention to details
Chrome: 0.70 seconds / Clean OS, reboot before test run, and so on.

Speedometer 3.0 results [higher is better]

Firefox: 25.0
Chromium: 30.7
Chrome: 31.5
"

"The margins between the winners and losers here are fairly small. <===
The only reason you might switch to the fastest all-around browser (Chrome)
is if you regularly visit websites that demand speed in ways that require
switching browsers. Or maybe you're a power user who simply wants to ensure
you're using the absolute fastest browser on the market. In that case,
the choice is easyrCa Chrome. "

And that tells you, there is likely some configuration problem which could
be improved upon. Just an auto-proxy versus no-proxy setting could
do it. Go through the Preferences and make sure they're set the best
way possible. Then the difference between them will be smaller.

The cache on browsers, can be set to disk or set to memory. See
if both browsers are configured the same way. I like memory caching,
just to reduce wear on the SSD. If your cache2 has never been cleaned
and you set the cache size too large inadvertently, that can cause
a big problem. My brother phoned me once about browser speed, and
we decided the root cause was the humongous cache setting he was using.
There might have been something like 300,000 files in the cache at the time, cached to a hard drive.

Paul
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 14 Apr 2026 20:10:56 -0400, Paul wrote:

My brother phoned me once about browser speed, and we decided the
root cause was the humongous cache setting he was using. There might
have been something like 300,000 files in the cache at the time,
cached to a hard drive.

Caches are supposed to speed things up, not slow them down.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-04-15, Paul wrote:

On Tue, 4/14/2026 3:55 PM, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

https://www.zdnet.com/home-and-office/work-life/i-speed-tested-11-browsers-and-the-fastest-might-surprise-you/

[ After writing the reply below I opened the article, and it is by Jack
Wallen, a byname that has previously written not-so-great articles on
ZDnet and who also engages in content recycling. ]

see e.g. (from comp.os.linux.misc)
Message-ID: <10eglkf$nnrr$1@dont-email.me>
Message-ID: <10k9aif$btvl$2@dont-email.me>
Message-ID: <vshpm2$6sd5$2@dont-email.me>
Message-ID: <107j83e$5993$3@dont-email.me>


It's possible the article is actually good, but I hope my suspicions
here are understandable...

"Start times [lower is better]

Chromium: 1.95 seconds \
Firefox: 1.93 seconds \___ Tests like this need a *lot* of attention to details
Chrome: 0.70 seconds / Clean OS, reboot before test run, and so on.

And start times arguably don't matter much, as far as they're in an
acceptable ballpark. Also, could this difference be e.g. the result of
the approaches used in compilation and linking?

Speedometer 3.0 results [higher is better]

Firefox: 25.0
Chromium: 30.7
Chrome: 31.5
"

"The margins between the winners and losers here are fairly
small. <===

I'm more concerned about the difference between Chromium and Chrome. Is
it really significant, or is this highlighting the marging of error?

The only reason you might switch to the fastest all-around
browser (Chrome)

(Hey, I take offense to "fastest all-around browser", surely lynx and
elinks might be much faster, especially if ignoring CSS and so on!)

is if you regularly visit websites that demand speed in ways that require
switching browsers. Or maybe you're a power user who simply wants to ensure
you're using the absolute fastest browser on the market. In that case,
the choice is easyrCa Chrome. "

And that tells you, there is likely some configuration problem which could
be improved upon. Just an auto-proxy versus no-proxy setting could
do it. Go through the Preferences and make sure they're set the best
way possible. Then the difference between them will be smaller.

The cache on browsers, can be set to disk or set to memory. See
if both browsers are configured the same way. I like memory caching,
just to reduce wear on the SSD. If your cache2 has never been cleaned
and you set the cache size too large inadvertently, that can cause
a big problem. My brother phoned me once about browser speed, and
we decided the root cause was the humongous cache setting he was using.
There might have been something like 300,000 files in the cache at the time, cached to a hard drive.

At one point several years ago, I disabled on-disk cache. The problem
was that, besides its usefulness being questionable for most of my
browsing, it IIRC caused a problem where Firefox (at least I think when
this happened I was on Firefox) would become painfully slow after
resuming from hibernation, because of the on-disk cache.
--
Nuno Silva
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Paul <nospam@needed.invalid> wrote:

And that tells you, there is likely some configuration problem which could
be improved upon. Just an auto-proxy versus no-proxy setting could
do it. Go through the Preferences and make sure they're set the best
way possible. Then the difference between them will be smaller.

Using the newest Firefox on Fedora 43, the site I use is sluggish
as hell. When I type text, it takes 10-20 seconds for the first
letters to appear. Using Chromium, everything is almpost
instantaneous.

The difference is just staggering. Never going back to FF anymore.

br,
KK
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 14.04.2026 19:55 Uhr Kalevi Kolttonen wrote:

Sorry for the off-topic, but I have to let others
know...

Is there any issue posting in comp.os.linux.misc?
--
kind regards
Marco

Send spam to 1776189326muell@stinkedores.dorfdsl.de

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Marco Moock <mm@dorfdsl.de> wrote:

On 14.04.2026 19:55 Uhr Kalevi Kolttonen wrote:

Sorry for the off-topic, but I have to let others
know...

Is there any issue posting in comp.os.linux.misc?

I do not think so, but I was unaware of that group.

br,
KK
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for
all their builds. So it is at least 20% slower than it should be on
Fedora. Solution: https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for
all their builds. So it is at least 20% slower than it should be on
Fedora. Solution: https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/

The site I access, with Chromium works like a charm. Firefox is much slower than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 5/30/26 13:46, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for
all their builds. So it is at least 20% slower than it should be on
Fedora. Solution:
https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/

The site I access, with Chromium works like a charm. Firefox is much slower than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.

You probably did something retarded.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 5/30/26 13:46, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for >>> all their builds. So it is at least 20% slower than it should be on
Fedora. Solution:
https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/

The site I access, with Chromium works like a charm. Firefox is much slower >> than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.

You probably did something retarded.

If you consider accessing a website with the latest
Firefox "retarded", then yes indeed, it was "retarded".

However, I am happy that Chromium works while Firefox
does not. What is more, I subscribed to HBO Max to
see French Open tennis. Using Firefox, all I get is
an error message and the video streaming does not work.

With Chromium, it works.

For me, it is a no-brainer to use a browser that works.

br,
KK
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Kevin Bowling <kevin.bowling@kev009.com> writes:

On 5/30/26 13:46, Kalevi Kolttonen wrote:

[...]

The site I access, with Chromium works like a charm. Firefox is much
slower than 20%, taking 20-30 seconds to render text. The problem I
am seeing cannot be solved by using different compiler options.

You probably did something retarded.

*PLONK*
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-05-31, Keith Thompson wrote:

Kevin Bowling <kevin.bowling@kev009.com> writes:

On 5/30/26 13:46, Kalevi Kolttonen wrote:

[...]

The site I access, with Chromium works like a charm. Firefox is much
slower than 20%, taking 20-30 seconds to render text. The problem I
am seeing cannot be solved by using different compiler options.

You probably did something retarded.

*PLONK*

+1, it's amazing how some people will provide litmus tests and their
answers by themselves.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-05-31, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 5/30/26 13:46, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for >>>> all their builds. So it is at least 20% slower than it should be on
Fedora. [...]

The site I access, with Chromium works like a charm. Firefox is much slower >>> than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.

[...] [Also snipping the part with the inane comment, as it can be left
out]

However, I am happy that Chromium works while Firefox
does not. What is more, I subscribed to HBO Max to
see French Open tennis. Using Firefox, all I get is
an error message and the video streaming does not work.

With Chromium, it works.

For me, it is a no-brainer to use a browser that works.

br,
KK

Can you refresh my memory re: this thread: did you try different builds
(namely the Mozilla one), or other systems for comparison? (I'm not
saying you have to do this, nor that it's something even easy to do, can
easily be hard or impossible, but if you by chance did, these are
valuable and interesting data points.)

I'm wondering if this really is Firefox in itself (can very well be), or
if it's some other thing like OpenGL support or issues with different
ffmpeg versions.
--
br/yt,
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Sat, 5/30/2026 4:46 PM, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for
all their builds. So it is at least 20% slower than it should be on
Fedora. Solution:
https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/

The site I access, with Chromium works like a charm. Firefox is much slower than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.

In the Firefox URL bar, try

about:support

You can review your configuration a bit, using this in Terminal

inxi -F

and see what video driver you are running. One minor issue seems
to be running an external monitor off HDMI on a laptop, which seems
to be quite slow.

Fedora has zram (compression of RAM to save memory) as
an alternative to using only swap. But that's unlikely
to cause text to be that slow.

I use the web site "beautifier.io" to bring up a text window in Firefox.
That is code that runs locally, and what you type does not go to the cloud.
And that seems to be responding normally to text input, in Fedora 43
(SSD10 on Test Machine). I then installed the NVidia driver for Fedora 43,
but so far, the video decoder support in the table in the "about:support"
still shows only software decoders as working. Some amount of Firefox is
still hardware accelerated via having that driver.

Starting firefox from the Terminal is recommended, just to see
why some aspect of video decoding is not working (anyway). That
may affect DRM-protected materials. It looks like generally, video
decoding is more of a mess than getting nvidia itself installed via
rpmfusion.

Paul
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 5/30/26 16:05, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 5/30/26 13:46, Kalevi Kolttonen wrote:

Kevin Bowling <kevin.bowling@kev009.com> wrote:

On 4/14/26 12:55, Kalevi Kolttonen wrote:

Hello!

Sorry for the off-topic, but I have to let others
know...

I have been running Firefox as my browser, always.
Today I finally got tired of it being painfully
slow on some sites that I regularly visit.

I tried Chromium and it is so much faster!

Here are the versions that I used

~ $ rpm -qi firefox
Name : firefox
Version : 149.0
Release : 4.fc43
Architecture: x86_64

Name : chromium
Version : 146.0.7680.177
Release : 1.fc43
Architecture: x86_64

br,
KK

Fedora compiles Firefox with GCC and without PGO, which Mozilla uses for >>>> all their builds. So it is at least 20% slower than it should be on
Fedora. Solution:
https://blog.nightly.mozilla.org/2026/01/19/introducing-mozillas-firefox-nightly-rpm-package-for-rpm-based-linux-distributions/

The site I access, with Chromium works like a charm. Firefox is much slower >>> than 20%, taking 20-30 seconds to render text. The problem I am seeing
cannot be solved by using different compiler options.

You probably did something retarded.

If you consider accessing a website with the latest
Firefox "retarded", then yes indeed, it was "retarded".

Completely ignoring advice, proud how "correct" you are in not knowing
is indeed.. retarded. You don't know how to diagnose basic issues, and
seem to think a browser with 100s of millions of users is factually two magnitude slower at time to first paint.

However, I am happy that Chromium works while Firefox
does not. What is more, I subscribed to HBO Max to
see French Open tennis. Using Firefox, all I get is
an error message and the video streaming does not work.

With Chromium, it works.

For me, it is a no-brainer to use a browser that works.

Enjoy the ads. There are chromium forks that aren't actively hostile.

br,
KK

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Sun, 31 May 2026 04:51:27 -0400, Paul wrote:

Starting firefox from the Terminal is recommended, just to see why
some aspect of video decoding is not working (anyway).

If yourCOre looking for messages sent to stderr, systemd collects these
in its journal. You can find Firefox-related messages in your per-user
journal with something like

journalctl --user --user-unit=\*firefox\*
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-06-01, Lawrence DrCOOliveiro wrote:

On Sun, 31 May 2026 04:51:27 -0400, Paul wrote:

Starting firefox from the Terminal is recommended, just to see why
some aspect of video decoding is not working (anyway).

If yourCOre looking for messages sent to stderr, systemd collects these
in its journal. You can find Firefox-related messages in your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

That assumes systemd is present and used for that, it is more portable
to run it from a terminal or terminal emulator.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Sun, 31 May 2026 04:51:27 -0400, Paul wrote:

Starting firefox from the Terminal is recommended, just to see why
some aspect of video decoding is not working (anyway).

If yourCOre looking for messages sent to stderr, systemd collects these
in its journal. You can find Firefox-related messages in your per-user >journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these
in its journal. You can find Firefox-related messages in your per-user >>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user program is able to get its standard error log to /var.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 01 Jun 2026 14:13:01 GMT
Nicolas George <nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these >>>in its journal. You can find Firefox-related messages in your per-user >>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user >program is able to get its standard error log to /var.

I'll leave that to you to figure out, its not hard. Hint: It involves pipes.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Nicolas George <nicolas$george@salle-s.org> writes:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these >>>in its journal. You can find Firefox-related messages in your per-user >>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user >program is able to get its standard error log to /var.

$ man 3 syslog
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Mon, 1 Jun 2026 16:02:16 -0000 (UTC), boltar wrote:

On 01 Jun 2026 14:13:01 GMT
Nicolas George <nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC), Lawrence DrCOOliveiro wrote:

If yourCOre looking for messages sent to stderr, systemd collects
these in its journal. You can find Firefox-related messages in
your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for
systemd!

Your mocking would work better if you were capable of explaining
how a user program is able to get its standard error log to /var.

I'll leave that to you to figure out, its not hard. Hint: It
involves pipes.

Assuming yourCOre serious, you seem to be saying that the system log is
an acceptable place to dump per-user session crap.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 01 Jun 2026 14:13:01 GMT, Nicolas George wrote:

Your mocking would work better if you were capable of explaining how
a user program is able to get its standard error log to /var.

Or why it would want to.

In the old (pre-Wayland) days, there was a ~/.xsession-errors file <https://wiki.wlug.org.nz/XSessionErrors>. The stderr of every GUI
program was redirected here. So it was an ever-growing mess of random
messages, most of which seemed to do with sloppy programming of GUI
toolkits (How many rCL*CRITICAL*rCY errors can an app emit, and yet still
seem to continue functioning normally?).

systemd canrCOt fix the sloppy programming of GUI toolkits, but it has
at least imposed some order on the messages. You can filter based on
the source (instead of relying on some random substring in the message
itself) And it provides automatic timestamping of every line.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:

systemd canrCOt fix the sloppy programming of GUI toolkits, but it has
at least imposed some order on the messages. You can filter based on
the source (instead of relying on some random substring in the message >itself) And it provides automatic timestamping of every line.

The anonymous systemd hater will now proceed to explain you how you're
holding your system wrong.

Greetings
Marc
-- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 02 Jun 2026 07:35:48 +0200, Marc Haber wrote:

The anonymous systemd hater will now proceed to explain you how
you're holding your system wrong.

I wonder if any of them make a living from their Linux skills. ;)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 2 Jun 2026 00:13:10 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Mon, 1 Jun 2026 16:02:16 -0000 (UTC), boltar wrote:

On 01 Jun 2026 14:13:01 GMT
Nicolas George <nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC), Lawrence DrCOOliveiro wrote: >>>>>

If yourCOre looking for messages sent to stderr, systemd collects
these in its journal. You can find Firefox-related messages in
your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for
systemd!

Your mocking would work better if you were capable of explaining
how a user program is able to get its standard error log to /var.

I'll leave that to you to figure out, its not hard. Hint: It
involves pipes.

Assuming yourCOre serious, you seem to be saying that the system log is
an acceptable place to dump per-user session crap.

Is it straw man week again? If you want stderr to go to syslog its quite
easy. If you don't know how you shouldn't be posting to this group.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-06-02, Marc Haber wrote:

Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:

systemd canrCOt fix the sloppy programming of GUI toolkits, but it has
at least imposed some order on the messages. You can filter based on
the source (instead of relying on some random substring in the message >>itself) And it provides automatic timestamping of every line.

The anonymous systemd hater will now proceed to explain you how you're holding your system wrong.

There was an unnecessary systemd assumption upthread, but this question
really isn't something where systemd does something previously
impossible, rather one of these questions were you do have more than one approach already available, like it or not.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-06-01, Scott Lurndal wrote:

Nicolas George <nicolas$george@salle-s.org> writes:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |a--crit|e-a:

If you|ore4raore looking for messages sent to stderr, systemd collects these
in its journal. You can find Firefox-related messages in your per-user >>>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user >>program is able to get its standard error log to /var.

$ man 3 syslog

Yeah, I was wondering if I was still low on caffeine while reading that
- because isn't that really how syslog works?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On 2026-06-01, Nicolas George wrote:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these >>>in its journal. You can find Firefox-related messages in your per-user >>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user program is able to get its standard error log to /var.

The obvious answer has been pointed out already, but you may want to
look up certain parts of IEEE 1003.1:

<https://pubs.opengroup.org/onlinepubs/9799919799/functions/closelog.html#tag_17_83_06_03>

I'd also want to point out a different way of answering this:

Can you explain how a user program is able to get its log messages
to the systemd journal?

The point here not being a claim that that is not possible, or a need
for explanation, but a moment for you to consider "well, maybe syslog
does something similar-ish?".
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2026-06-02, Marc Haber wrote:

Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:

systemd canrCOt fix the sloppy programming of GUI toolkits, but it has
at least imposed some order on the messages. You can filter based on
the source (instead of relying on some random substring in the message >>>itself) And it provides automatic timestamping of every line.

The anonymous systemd hater will now proceed to explain you how you're
holding your system wrong.

There was an unnecessary systemd assumption upthread, but this question >really isn't something where systemd does something previously
impossible, rather one of these questions were you do have more than one >approach already available, like it or not.

This is one of the things that systemd does significantly better than
anything before. One can argue that this "better" stems from the fact
that system is willing to depart WIDE from how we did things before
and isn't willing to cater for so many idioms "we" expect.

Greetings
Marc
-- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:

On Tue, 02 Jun 2026 07:35:48 +0200, Marc Haber wrote:

The anonymous systemd hater will now proceed to explain you how
you're holding your system wrong.

I wonder if any of them make a living from their Linux skills. ;)

One wonders how trolls like you make a living at all.

One can admire the simplicity and flexibility of init scripts
without needing, or wanting systemd.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

In article <10vm7bo$2prmk$4@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2026-06-01, Nicolas George wrote:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these >>>>in its journal. You can find Firefox-related messages in your per-user >>>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd!

Your mocking would work better if you were capable of explaining how a user >> program is able to get its standard error log to /var.

The obvious answer has been pointed out already, but you may want to
look up certain parts of IEEE 1003.1:

<https://pubs.opengroup.org/onlinepubs/9799919799/functions/closelog.html#tag_17_83_06_03>

That's not the same thing, though.

The question was how one gets output written to the standard
error stream from some process into syslog. The `syslog` and
related functions don't really help with that, unless you write
a program that reads that data (presumably over a pipe) and pass
it as an argument to `syslog` et al. But even if one does that,
the user may not have permissions to write to the system log.

I'd also want to point out a different way of answering this:

Can you explain how a user program is able to get its log messages
to the systemd journal?

The point here not being a claim that that is not possible, or a need
for explanation, but a moment for you to consider "well, maybe syslog
does something similar-ish?".

See above.

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

cross@spitfire.i.gajendra.net (Dan Cross) writes:

In article <10vm7bo$2prmk$4@dont-email.me>,
Nuno Silva <nunojsilva@invalid.invalid> wrote:

On 2026-06-01, Nicolas George wrote:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

If yourCOre looking for messages sent to stderr, systemd collects these >>>>>in its journal. You can find Firefox-related messages in your per-user >>>>>journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for systemd! >>>

Your mocking would work better if you were capable of explaining how a user >>> program is able to get its standard error log to /var.

The obvious answer has been pointed out already, but you may want to
look up certain parts of IEEE 1003.1:

<https://pubs.opengroup.org/onlinepubs/9799919799/functions/closelog.html#tag_17_83_06_03>

That's not the same thing, though.

The question was how one gets output written to the standard
error stream from some process into syslog. The `syslog` and
related functions don't really help with that, unless you write
a program that reads that data (presumably over a pipe) and pass
it as an argument to `syslog` et al. But even if one does that,
the user may not have permissions to write to the system log.

Several C++ applications that I work with use an internal logger
framework. This was originally written for my burroughs V
series simulator. The framework supports multiple sinks;
one of which can be the syslog.

This is used instead of direct writes to stderr throughout
the entire application.

There's an interface class (c_logger) that
defines the interfaces to the subsystem, e.g.

class c_logger {

bool l_debug;

public:
c_logger(bool d) { l_debug = d; }
virtual ~c_logger(void) {};

void log(const char *, ...)
__attribute__((format(printf, 2, 3)));
size_t trace(const char *, ...)
__attribute__((format(printf, 2, 3)));

virtual void do_log(const char *, va_list) = 0;
virtual size_t do_trace(const char *, va_list) = 0;

void set_tracing(bool d=false) { l_debug = d; }
bool is_tracing(void) { return l_debug; }
};

There are a set of derived classes that provide the
sink(s).

c_file_logger Takes a filename
c_gzip_logger Takes a filename and gzips the output
c_stream_logger Takes an outputstream to which output is sent
c_syslog_logger Logs output via the syslog() system call

There is also a multiplexor:

c_mux_logger implements c_logger and keeps a list of
registered loggers. Any call to 'log' or 'trace'
will be passed to each of the registered loggers.

int
main(int argv, const char **argv)
{
c_logger *ml;
c_file_logger *fl;
c_syslog_logger *sl;

ml = new c_mux_logger();
ml->add(new c_file_logger(stderr));
if (argc > 1) {
ml->add(new c_file_logger(argv[1]);
}
ml->add(new c_syslog_logger());

ml->log("%s: Welcome to main\n", argv[0]);

return 0;
}

The Welcome message is replicated on all registered sinks.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

cross@spitfire.i.gajendra.net (Dan Cross) writes:

The question was how one gets output written to the standard
error stream from some process into syslog. The `syslog` and
related functions don't really help with that, unless you write
a program that reads that data (presumably over a pipe) and pass
it as an argument to `syslog` et al.

The program has existed for years, itrCOs called rCyloggerrCO.

But even if one does the user may not have permissions to write to the
system log.

Possible in principle I suppose, but it seems like a weird configuration
since itrCOd make it less convenient for non-root daemons to use syslog.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

In article <wwvv7c0vigp.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes:

The question was how one gets output written to the standard
error stream from some process into syslog. The `syslog` and
related functions don't really help with that, unless you write
a program that reads that data (presumably over a pipe) and pass
it as an argument to `syslog` et al.

The program has existed for years, itrCOs called rCyloggerrCO.

I'm aware. The point was that just linking to the POSIX
definitions for `syslog` et al was, again, answering a different
question than the one posed.

But even if one does the user may not have permissions to write to the
system log.

Possible in principle I suppose, but it seems like a weird configuration >since itrCOd make it less convenient for non-root daemons to use syslog.

It is actually quite common on a multi-user system.

As for system daemons that don't run as root, most versions of
`syslogd` these days support an option to specify the pathname
to multiple Unix domain sockets that they'll accept messages on;
those can be permitted differently for different daemons (many
of which may well be running in their own `chroot` prisons or
something similar, and thus unable to reach the standard socket
path anyhow).

- Dan C.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 02 Jun 2026 18:47:02 GMT
scott@slp53.sl.home (Scott Lurndal) gabbled:

cross@spitfire.i.gajendra.net (Dan Cross) writes:

The question was how one gets output written to the standard
error stream from some process into syslog. The `syslog` and
related functions don't really help with that, unless you write
a program that reads that data (presumably over a pipe) and pass
it as an argument to `syslog` et al. But even if one does that,
the user may not have permissions to write to the system log.

Several C++ applications that I work with use an internal logger
framework. This was originally written for my burroughs V
series simulator. The framework supports multiple sinks;
one of which can be the syslog.

Writing your own logger isn't hard. At its core its just an ostream or
file pointer surrounded by a mutex. The point was redirecting console output to the syslog which is easily done by piping to the logger utility.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 2 Jun 2026 08:22:05 -0000 (UTC), boltar wrote:

On Tue, 2 Jun 2026 00:13:10 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 1 Jun 2026 16:02:16 -0000 (UTC), boltar wrote:

On 01 Jun 2026 14:13:01 GMT Nicolas George
<nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC), Lawrence DrCOOliveiro
wrote:

If yourCOre looking for messages sent to stderr, systemd collects
these in its journal. You can find Firefox-related messages in
your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for
systemd!

Your mocking would work better if you were capable of explaining
how a user program is able to get its standard error log to /var.

I'll leave that to you to figure out, its not hard. Hint: It
involves pipes.

Assuming yourCOre serious, you seem to be saying that the system log
is an acceptable place to dump per-user session crap.

Is it straw man week again? If you want stderr to go to syslog its
quite easy. If you don't know how you shouldn't be posting to this
group.

Which is not an explanation of why you think itrCOs a good idea.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Mon, 8 Jun 2026 00:32:13 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 2 Jun 2026 08:22:05 -0000 (UTC), boltar wrote:

On Tue, 2 Jun 2026 00:13:10 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 1 Jun 2026 16:02:16 -0000 (UTC), boltar wrote:

On 01 Jun 2026 14:13:01 GMT Nicolas George
<nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC), Lawrence DrCOOliveiro
wrote:

If yourCOre looking for messages sent to stderr, systemd collects >>>>>>> these in its journal. You can find Firefox-related messages in
your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray for
systemd!

Your mocking would work better if you were capable of explaining
how a user program is able to get its standard error log to /var.

I'll leave that to you to figure out, its not hard. Hint: It
involves pipes.

Assuming yourCOre serious, you seem to be saying that the system log
is an acceptable place to dump per-user session crap.

Is it straw man week again? If you want stderr to go to syslog its
quite easy. If you don't know how you shouldn't be posting to this
group.

Which is not an explanation of why you think itrCOs a good idea.

Quite obviously so you can write a program that can run on the command line
or run as a daemon and it doesn't have to have different output code for each mode. Its stdout + stderr can just be redirected to the log using a simple
pipe when running as a daemon.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Mon, 8 Jun 2026 08:20:05 -0000 (UTC), boltar wrote:

On Mon, 8 Jun 2026 00:32:13 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Tue, 2 Jun 2026 08:22:05 -0000 (UTC), boltar wrote:

On Tue, 2 Jun 2026 00:13:10 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 1 Jun 2026 16:02:16 -0000 (UTC), boltar wrote:

On 01 Jun 2026 14:13:01 GMT Nicolas George
<nicolas$george@salle-s.org> gabbled:

boltar@caprica.universe, dans le message
<10vjf8j$23ctb$1@dont-email.me>, a |-crit-a:

On Mon, 1 Jun 2026 00:22:38 -0000 (UTC), Lawrence DrCOOliveiro
wrote:

If yourCOre looking for messages sent to stderr, systemd
collects these in its journal. You can find Firefox-related
messages in your per-user journal with something like

journalctl --user --user-unit=\*firefox\*

So much simpler than "grep firefox /var/log/syslog". Horray
for systemd!

Your mocking would work better if you were capable of
explaining how a user program is able to get its standard error
log to /var.

I'll leave that to you to figure out, its not hard. Hint: It
involves pipes.

Assuming yourCOre serious, you seem to be saying that the system
log is an acceptable place to dump per-user session crap.

Is it straw man week again? If you want stderr to go to syslog its
quite easy. If you don't know how you shouldn't be posting to this
group.

Which is not an explanation of why you think itrCOs a good idea.

Quite obviously so you can write a program that can run on the
command line or run as a daemon and it doesn't have to have
different output code for each mode. Its stdout + stderr can just be redirected to the log using a simple pipe when running as a daemon.

ThatrCOs how it already works with systemd. Before that, GUI apps used
to have their stderr redirected to the ~/.xsession-errors file <https://wiki.wlug.org.nz/XSessionErrors>. So this became an
ever-growing accumulation of random cryptic messages.

Now systemd collects all those messages, and records the source of
each, as well as the time at which it was emitted, making it much
easier to go back and fix the bugs in all those programs.

And no change was needed to any of those apps to work the new way --
no rCLdifferent output code for each moderCY.

Which *still* leaves the question unanswered: why do you think itrCOs a
good idea to put such messages into the *system* log, rather than a *per-user-session* log?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 9 Jun 2026 00:54:50 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Mon, 8 Jun 2026 08:20:05 -0000 (UTC), boltar wrote:

Quite obviously so you can write a program that can run on the
command line or run as a daemon and it doesn't have to have
different output code for each mode. Its stdout + stderr can just be
redirected to the log using a simple pipe when running as a daemon.

ThatrCOs how it already works with systemd. Before that, GUI apps used

Great, except you have to set it up to be run by systemd. You can't just
do it on the fly.

Now systemd collects all those messages, and records the source of
each, as well as the time at which it was emitted, making it much
easier to go back and fix the bugs in all those programs.

Right, because it was impossible to do that before systemd came along *cough*

And no change was needed to any of those apps to work the new way --
no rCLdifferent output code for each moderCY.

Which *still* leaves the question unanswered: why do you think itrCOs a
good idea to put such messages into the *system* log, rather than a >*per-user-session* log?

Where did I say it was? I simply answered the question of how it was done.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Tue, 9 Jun 2026 08:48:23 -0000 (UTC), boltar wrote:

On Tue, 9 Jun 2026 00:54:50 -0000 (UTC), Lawrence DrCOOliveiro wrote:

On Mon, 8 Jun 2026 08:20:05 -0000 (UTC), boltar wrote:

Quite obviously so you can write a program that can run on the
command line or run as a daemon and it doesn't have to have
different output code for each mode. Its stdout + stderr can just
be redirected to the log using a simple pipe when running as a
daemon.

ThatrCOs how it already works with systemd.

Great, except you have to set it up to be run by systemd. You can't
just do it on the fly.

<https://www.freedesktop.org/software/systemd/man/latest/systemd-cat.html>

Now systemd collects all those messages, and records the source of
each, as well as the time at which it was emitted, making it much
easier to go back and fix the bugs in all those programs.

Right, because it was impossible to do that before systemd came
along *cough*

Where was there a tool that made that easy to do before?

Which *still* leaves the question unanswered: why do you think itrCOs
a good idea to put such messages into the *system* log, rather than
a *per-user-session* log?

Where did I say it was? I simply answered the question of how it was
done.

No, you just kept saying that was how you would do it, not how normal
people do it. You never explained why.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.unix.programmer

On Wed, 10 Jun 2026 00:34:33 -0000 (UTC)
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> gabbled:

On Tue, 9 Jun 2026 08:48:23 -0000 (UTC), boltar wrote:

Now systemd collects all those messages, and records the source of
each, as well as the time at which it was emitted, making it much
easier to go back and fix the bugs in all those programs.

Right, because it was impossible to do that before systemd came
along *cough*

Where was there a tool that made that easy to do before?

Just to be clear - you're claiming the syslog before systemd didn't contain
any info about the process writing the message?

Where did I say it was? I simply answered the question of how it was
done.

No, you just kept saying that was how you would do it, not how normal
people do it. You never explained why.

No, I simply said how it could be done. You need to learn to read.

--- Synchronet 3.22a-Linux NewsLink 1.2