My Pi5 running bookworm has developed flaky WiFi behavior about
24 hours after the latest upgrade.
Where should I look for error messages? Nothing shows up on the
screen during negotiation, it appears that the Pi negotiates
for a minute or two and then gives up. Two red X's appear in
the Wifi entry in the top-right menu bar and that's it.
The only visible hint is that even if the connection is specified
at 2.4 GHz a wavemon window is left showing what appears to be a
5 GHz attempt. My access point doesn't support 5 GHz, making the
attempt, if it is one, appear to be a mistake.
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
bob prohaska
On 25/10/2024 04:02, bp@www.zefox.net wrote:
All I can say is that my PiZero running bookworm became stable with
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
bob prohaska
wifi after a more powerful PSU was fitted to it.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 25/10/2024 04:02, bp@www.zefox.net wrote:
All I can say is that my PiZero running bookworm became stable with
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
bob prohaska
wifi after a more powerful PSU was fitted to it.
It turns out that moving the Pi5 within three feet the access point
restores normal WiFi operation. Signal quality reported by wavemon
went from 90% to 100% and the WiFi connected automatically in parallel
to a wired connection. However, neighbor's APs using the 2.4GHz band
appear with 67-76% signal quality. If I were to move the Pi5 back to
its original location, its signal strength at the AP would be much lower.
It's difficult to improve the Pi5's antenna, but my AP has an
SMA connector. Does anybody have experience with directional
antennas?
At the moment, the Pi5 is showing 5.05 volts at the GPIO header.
I think that's slightly lower than I saw previously when the Pi5
was in the troublesome location. The PSU doesn't seem the prime suspect.
Thanks for reading, and any suggestions.
bob prohaska
On 25/10/2024 17:11, bp@www.zefox.net wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 25/10/2024 04:02, bp@www.zefox.net wrote:
All I can say is that my PiZero running bookworm became stable with
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
bob prohaska
wifi after a more powerful PSU was fitted to it.
It turns out that moving the Pi5 within three feet the access point
restores normal WiFi operation. Signal quality reported by wavemon
went from 90% to 100% and the WiFi connected automatically in parallel
to a wired connection. However, neighbor's APs using the 2.4GHz band
appear with 67-76% signal quality. If I were to move the Pi5 back to
its original location, its signal strength at the AP would be much lower.
It's difficult to improve the Pi5's antenna, but my AP has an
SMA connector. Does anybody have experience with directional
antennas?
At the moment, the Pi5 is showing 5.05 volts at the GPIO header.
I think that's slightly lower than I saw previously when the Pi5
was in the troublesome location. The PSU doesn't seem the prime suspect.
Thanks for reading, and any suggestions.
bob prohaska
Can you not use ethernet cable?
Does anybody have experience with directional antennas?
On Fri, 25 Oct 2024 16:11:17 -0000 (UTC), bp wrote:
Does anybody have experience with directional antennas?
Back in the early days when broadband Internet was still exotic and
expensive and wi-fi was new, people experimented with using it for
longer range point-to-point connections. I remember reports that empty Pringles potato-chip cans were a remarkably cost-effective way of
achieving the necessary directionality.
On Fri, 25 Oct 2024 16:11:17 -0000 (UTC), bp wrote:
Does anybody have experience with directional antennas?
Back in the early days when broadband Internet was still exotic and
expensive and wi-fi was new, people experimented with using it for longer range point-to-point connections. I remember reports that empty Pringles potato-chip cans were a remarkably cost-effective way of achieving the necessary directionality.
On 26/10/2024 17:04, bp@www.zefox.net wrote:
f I understand my problem correctly the need is to "shadow"
my access point from the neighbors more than to direct transmit power
to my clients (signal level at the client location is ~90% per wavemon,
80% gave good connectivity until recently).
Moving transmitted frequency can help a lot
f I understand my problem correctly the need is to "shadow"
my access point from the neighbors more than to direct transmit power
to my clients (signal level at the client location is ~90% per wavemon,
80% gave good connectivity until recently).
On 10/24/24 23:02, bp@www.zefox.net wrote:
My Pi5 running bookworm has developed flaky WiFi behavior about
24 hours after the latest upgrade.
Where should I look for error messages? Nothing shows up on the
screen during negotiation, it appears that the Pi negotiates
for a minute or two and then gives up. Two red X's appear in
the Wifi entry in the top-right menu bar and that's it.
The only visible hint is that even if the connection is specified
at 2.4 GHz a wavemon window is left showing what appears to be a
5 GHz attempt. My access point doesn't support 5 GHz, making the
attempt, if it is one, appear to be a mistake.
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
This sounds very familiar. I fought the same pitched battle here with
Wifi and Pi5 under Bookworm. Finally discovered that HDMI output
interferes with the 2.4 GHz band. Try running headless over ssh and see
if that's any better? Made an improvement here for 2.4 GHz, but did not help 5 GHz connectivity.
I finally ended up replacing an 8 year old Wifi router and that fixed
the 5 GHz band. Something about the Pi5 Wifi implementation really does
not like older routers.
On 10/24/24 23:02, bp@www.zefox.net wrote:
My Pi5 running bookworm has developed flaky WiFi behavior about
24 hours after the latest upgrade.
Where should I look for error messages? Nothing shows up on the
screen during negotiation, it appears that the Pi negotiates
for a minute or two and then gives up. Two red X's appear in
the Wifi entry in the top-right menu bar and that's it.
The only visible hint is that even if the connection is specified
at 2.4 GHz a wavemon window is left showing what appears to be a
5 GHz attempt. My access point doesn't support 5 GHz, making the
attempt, if it is one, appear to be a mistake.
The access point works with other devices, so I don't think it's
the problem.
Thanks for reading and any suggestions!
This sounds very familiar. I fought the same pitched battle here with Wifi and Pi5 under Bookworm. Finally discovered that HDMI output interferes with the 2.4 GHz band. Try running headless over ssh and see if that's any better?
Made an improvement here for 2.4 GHz, but did not help 5 GHz connectivity.
I finally ended up replacing an 8 year old Wifi router and that fixed the 5 GHz band. Something about the Pi5 Wifi implementation really does not like older routers.
old, D-Link DI-524,
My AP is using 2417 MHz ch 2, none of the nearby Aps are using it.
On 27/10/2024 16:27, bp@www.zefox.net wrote:
old, D-Link DI-524,
You really need to get a router that was already considered obsolete by people like Marconi and move into the modern era.
My Pi5 running bookworm has developed flaky WiFi behavior about
24 hours after the latest upgrade.
Where should I look for error messages?
On 26/10/2024 18:09, bp@www.zefox.net wrote:
My AP is using 2417 MHz ch 2, none of the nearby Aps are using it.
On 2.4 GHz only use channels 1, 6 and 11, as the others overlap those
and cause worse interference than sharing with a stronger signal on 1,6
or 11.
I'll try channel 11 and see what happens.
On 27/10/2024 19:37, mm0fmf wrote:
On 27/10/2024 16:27, bp@www.zefox.net wrote:
old, D-Link DI-524,
You really need to get a router that was already considered obsolete
by people like Marconi and move into the modern era.
Aye, but it were good enough for my father, and his father before 'im.
:)
---druck
On 28/10/2024 15:01, druck wrote:
On 27/10/2024 19:37, mm0fmf wrote:
On 27/10/2024 16:27, bp@www.zefox.net wrote:
old, D-Link DI-524,
You really need to get a router that was already considered obsolete
by people like Marconi and move into the modern era.
Aye, but it were good enough for my father, and his father before 'im.
:)
---druck
ROTFL
mm0fmf <none@invalid.com> wrote:
On 28/10/2024 15:01, druck wrote:
On 27/10/2024 19:37, mm0fmf wrote:
On 27/10/2024 16:27, bp@www.zefox.net wrote:
old, D-Link DI-524,
You really need to get a router that was already considered obsolete
by people like Marconi and move into the modern era.
Aye, but it were good enough for my father, and his father before 'im.
:)
---druck
ROTFL
Not exactly 8-)
I avoid throwing money at problems until I at least _think_
I understand them.
For the moment it's fairly clear I don't understand.
mm0fmf <none@invalid.com> wrote:
On 28/10/2024 15:01, druck wrote:
On 27/10/2024 19:37, mm0fmf wrote:
On 27/10/2024 16:27, bp@www.zefox.net wrote:
old, D-Link DI-524,
You really need to get a router that was already considered obsolete
by people like Marconi and move into the modern era.
Aye, but it were good enough for my father, and his father before 'im.
:)
---druck
ROTFL
Not exactly 8-)
I avoid throwing money at problems until I at least _think_
I understand them.
For the moment it's fairly clear I don't understand.
The only hint so far is an error message from journalctl -g wlan0
saying " association took too long ".
At that point the Pi5 appears to start scanning 5 GHz access points,
despite being told otherwise in /etc/NetworkManager/NetworkManager.conf . That looks to me like a software problem.
There's on oldish thread that seems related here: https://github.com/raspberrypi/bookworm-feedback/issues/220
Unfortunately, the thread ended months ago, without resolution.
Thanks for reading,
bob prohaska
At that point the Pi5 appears to start scanning 5 GHz access points,
despite being told otherwise in /etc/NetworkManager/NetworkManager.conf . That looks to me like a software problem.
For some reason it's difficult to get rid of old connection presets,try looking in :
making it a little unclear if changes I'm trying to save actually
work as intended.
But a lot of technology does improve over time...
Of course if you've set silly names for network interfaces
It appears avahi has something to do with Apple hardware, so I don't
think it'll be missed
try looking in :
/etc/NetworkManager/system-connections
You should be able to delete the appropriate unwanted wifi connection
On Mon, 28 Oct 2024 21:03:50 -0000 (UTC), bp wrote:
It appears avahi has something to do with Apple hardware, so I don't
think it'll be missed
Avahi is the name of an open-source software suite that implements the “Zeroconf” protocol suite <https://wiki.archlinux.org/title/Avahi>. Zeroconf was created several decades ago by an Apple engineer named Stuart Cheshire, as a way to make TCP/IP behave more like the AppleTalk of yore, where you could just plug new machines into your LAN and turn them on, and they would Just Work™, with Zero Configuration™ (see what I did there?).
Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
At that point the Pi5 appears to start scanning 5 GHz access points,
despite being told otherwise in /etc/NetworkManager/NetworkManager.conf . That looks to me like a software problem.
On 28/10/2024 18:54, bp@www.zefox.net wrote:
At that point the Pi5 appears to start scanning 5 GHz access points,
despite being told otherwise in /etc/NetworkManager/NetworkManager.conf .
That looks to me like a software problem.
This is why I wasn't happy about Raspbian moving from dhcpcd to Network Manager. Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless systems.
You could try disabling the NetworkManager service, and reinstalling
dhcpcd so the WiFi is only selected by the contents of the wpa_supplicant.conf file. It worked fine for everything before Bookworm.
---druck
On 28/10/2024 18:54, bp@www.zefox.net wrote:
At that point the Pi5 appears to start scanning 5 GHz access points,
despite being told otherwise in /etc/NetworkManager/NetworkManager.conf .
That looks to me like a software problem.
This is why I wasn't happy about Raspbian moving from dhcpcd to Network Manager. Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless systems.
You could try disabling the NetworkManager service, and reinstalling
dhcpcd so the WiFi is only selected by the contents of the wpa_supplicant.conf file. It worked fine for everything before Bookworm.
---druck
It seems wiser to learn how to live with Bookworm sooner rather than later. Up to now RasPiOS has been trouble-free to the point that I know very little about it. Trying to second-guess the developers is likely to end badly,
at least when I'm the one doing the guessing 😎
On Tue, 29 Oct 2024 20:28:40 +0000, druck wrote:
Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
You could use nmcli to control it.
On 29.10.2024 22.28, druck wrote:
You could try disabling the NetworkManager service, and reinstalling
dhcpcd so the WiFi is only selected by the contents of the
wpa_supplicant.conf file. It worked fine for everything before Bookworm.
dhcpcd is not needed: systemd-networkd contains a pretty good DHCP
client when properly configured.
druck <news@druck.org.uk> wrote:
This is why I wasn't happy about Raspbian moving from dhcpcd to Network
Manager. Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless systems. >>
Were the unwanted wifi explorations immediate and consistent,
You could try disabling the NetworkManager service, and reinstalling
dhcpcd so the WiFi is only selected by the contents of the
wpa_supplicant.conf file. It worked fine for everything before Bookworm.
It seems wiser to learn how to live with Bookworm sooner rather than later. Up to now RasPiOS has been trouble-free to the point that I know very little about it. Trying to second-guess the developers is likely to end badly,
at least when I'm the one doing the guessing 8-)
On 29/10/2024 21:08, Lawrence D'Oliveiro wrote:
On Tue, 29 Oct 2024 20:28:40 +0000, druck wrote:
Quite often my Linux Laptops which use Network Manager decide they
would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
You could use nmcli to control it.
If you can log in to a headless system which isn't connecting to the
Wifi.
On 30/10/2024 08:20, Tauno Voipio wrote:
dhcpcd is not needed: systemd-networkd contains a pretty good DHCP
client when properly configured.
I have no desire to give any more control of my systems to the systemd
virus.
On 29/10/2024 21:08, Lawrence D'Oliveiro wrote:
On Tue, 29 Oct 2024 20:28:40 +0000, druck wrote:
Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
You could use nmcli to control it.
If you can log in to a headless system which isn't connecting to the Wifi.
---druck
On 30/10/2024 16:18, bp@www.zefox.net wrote:
druck <news@druck.org.uk> wrote:
This is why I wasn't happy about Raspbian moving from dhcpcd to Network
Manager. Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
Were the unwanted wifi explorations immediate and consistent,
Seemingly random.
You could try disabling the NetworkManager service, and reinstalling
dhcpcd so the WiFi is only selected by the contents of the
wpa_supplicant.conf file. It worked fine for everything before Bookworm. >>>
It seems wiser to learn how to live with Bookworm sooner rather than
later.
Up to now RasPiOS has been trouble-free to the point that I know very
little
about it. Trying to second-guess the developers is likely to end badly,
at least when I'm the one doing the guessing 8-)
The maturity of Raspbian's Bookworm is there yet. I had to jump to it
for my new Pi 5 machines, and I've also got it on a Pi 4 for reference,
but the older headless machines are staying on Bullseye until some of
the problems have been ironed out.
Well at least all headless Pis will run a console session via some form
of USB keyboard and HDMI screen.
On 30/10/2024 21:24, druck wrote:
On 29/10/2024 21:08, Lawrence D'Oliveiro wrote:Well at least all headless Pis will run a console session via some form
On Tue, 29 Oct 2024 20:28:40 +0000, druck wrote:
Quite often my Linux Laptops which use Network Manager decide
they would like to try WiFi networks other than the one I've chosen,
that's easily fixed via the gui, but not what you want on headless
systems.
You could use nmcli to control it.
If you can log in to a headless system which isn't connecting to the
Wifi.
of USB keyboard and HDMI screen. You wont need a mouse so one USB port
is enough
That what I have used when faced with loss of of connectivity.
However, when using Network Manager, it sometimes decides to try a
different network ...
A Raspberry Pi still has a built-in Ethernet interface, doesn’t it?
If it was in range of an Ethernet switch, I wouldn't be using WiFi!
However, when using Network Manager, it sometimes decides to try a
different network, leaving a remote headless Pi stuffed. Whilst all my 'desktop/media' Pi's (connected to monitors and keyboards) are on
Bookworm, all the headless ones are remaining on Bullseye for the time
being.
On 31/10/2024 21:54, druck wrote:
However, when using Network Manager, it sometimes decides to try a
different network, leaving a remote headless Pi stuffed. Whilst all my
'desktop/media' Pi's (connected to monitors and keyboards) are on
Bookworm, all the headless ones are remaining on Bullseye for the time
being.
I already told you the solution to that.
There is a priority system in network manager.
Otherwise it will connect to whatever it connected to last time, or
sometimes not
If you have more than one connection profile use:
sudo nmcli c modify MYCONNECTIONNAME connection.autoconnect-priority 1
Randomly created connections are default priority zero
This is also an accessible parameter from the GUI widget if you have a
GUI interface
It will then at least try only that SSID *first*
Or delete any alternative connection profiles.
On Wed, 30 Oct 2024 21:26:30 +0000, druck wrote:
On 30/10/2024 08:20, Tauno Voipio wrote:
dhcpcd is not needed: systemd-networkd contains a pretty good DHCP
client when properly configured.
I have no desire to give any more control of my systems to the systemd
virus.
Give people a way out of their pain, some people prefer the pain.
Why? Answers on a postcard, please.
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all my Pi'sThen delete the 2,4 GHZ SSID...
which have both 2.4 GHz and 5 GHz WiFi with a higher priority to the
5GHz network which has a different SSID to the 2.4 GHz one. Most of
the time they honour that but occasionally I find one has switched
back to 2.4 GHz, and it's not because the 5GHz signal strength has
dropped according to the logging.
On 01/11/2024 10:24, The Natural Philosopher wrote:
On 31/10/2024 21:54, druck wrote:
However, when using Network Manager, it sometimes decides to try a
different network, leaving a remote headless Pi stuffed. Whilst all
my 'desktop/media' Pi's (connected to monitors and keyboards) are on
Bookworm, all the headless ones are remaining on Bullseye for the
time being.
I already told you the solution to that.
There is a priority system in network manager.
Otherwise it will connect to whatever it connected to last time, or
sometimes not
If you have more than one connection profile use:
sudo nmcli c modify MYCONNECTIONNAME connection.autoconnect-priority 1 >>
Randomly created connections are default priority zero
This is also an accessible parameter from the GUI widget if you have a
GUI interface
It will then at least try only that SSID *first*
Or delete any alternative connection profiles
Except it doesn't actually work all the time. I've set up all my Pi's
which have both 2.4 GHz and 5 GHz WiFi with a higher priority to the
5GHz network which has a different SSID to the 2.4 GHz one. Most of the
time they honour that but occasionally I find one has switched back to
2.4 GHz, and it's not because the 5GHz signal strength has dropped
according to the logging.
Network manager has not yet reached the required level of stability.
---druck
On 01/11/2024 13:47, The Natural Philosopher wrote:
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all my Pi'sThen delete the 2,4 GHZ SSID...
which have both 2.4 GHz and 5 GHz WiFi with a higher priority to the
5GHz network which has a different SSID to the 2.4 GHz one. Most of
the time they honour that but occasionally I find one has switched
back to 2.4 GHz, and it's not because the 5GHz signal strength has
dropped according to the logging.
That's really not the point is it.
---druck
On 01/11/2024 14:15, druck wrote:
On 01/11/2024 13:47, The Natural Philosopher wrote:
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all myThen delete the 2,4 GHZ SSID...
Pi's which have both 2.4 GHz and 5 GHz WiFi with a higher priority
to the 5GHz network which has a different SSID to the 2.4 GHz one.
Most of the time they honour that but occasionally I find one has
switched back to 2.4 GHz, and it's not because the 5GHz signal
strength has dropped according to the logging.
That's really not the point is it.
---druck
It is. If you have an SSID registerd with the Pi that is 2.4GHZ its
going to sometimes connect to it
So remove it from the PI. It then wont know it exists.
On 01/11/2024 at 15:16, The Natural Philosopher wrote:
On 01/11/2024 14:15, druck wrote:
On 01/11/2024 13:47, The Natural Philosopher wrote:
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all myThen delete the 2,4 GHZ SSID...
Pi's which have both 2.4 GHz and 5 GHz WiFi with a higher priority
to the 5GHz network which has a different SSID to the 2.4 GHz one.
Most of the time they honour that but occasionally I find one has
switched back to 2.4 GHz, and it's not because the 5GHz signal
strength has dropped according to the logging.
That's really not the point is it.
---druck
It is. If you have an SSID registerd with the Pi that is 2.4GHZ its
going to sometimes connect to it
So remove it from the PI. It then wont know it exists.
Well it will still know it exists; it just won't know the password for it.
On 31/10/2024 00:00, Lawrence D'Oliveiro wrote:
On Wed, 30 Oct 2024 21:26:30 +0000, druck wrote:
On 30/10/2024 08:20, Tauno Voipio wrote:
dhcpcd is not needed: systemd-networkd contains a pretty good DHCP
client when properly configured.
I have no desire to give any more control of my systems to the systemd
virus.
Give people a way out of their pain, some people prefer the pain.
Anything to do with systemd is enviably more pain.
On 01/11/2024 14:15, druck wrote:
On 01/11/2024 13:47, The Natural Philosopher wrote:
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all myThen delete the 2,4 GHZ SSID...
Pi's which have both 2.4 GHz and 5 GHz WiFi with a higher priority
to the 5GHz network which has a different SSID to the 2.4 GHz one.
Most of the time they honour that but occasionally I find one has
switched back to 2.4 GHz, and it's not because the 5GHz signal
strength has dropped according to the logging.
That's really not the point is it.
It is. If you have an SSID registerd with the Pi that is 2.4GHZ its
going to sometimes connect to it
So remove it from the PI. It then wont know it exists.
On 01/11/2024 15:16, The Natural Philosopher wrote:
On 01/11/2024 14:15, druck wrote:
On 01/11/2024 13:47, The Natural Philosopher wrote:
On 01/11/2024 12:50, druck wrote:
Except it doesn't actually work all the time. I've set up all myThen delete the 2,4 GHZ SSID...
Pi's which have both 2.4 GHz and 5 GHz WiFi with a higher priority
to the 5GHz network which has a different SSID to the 2.4 GHz one.
Most of the time they honour that but occasionally I find one has
switched back to 2.4 GHz, and it's not because the 5GHz signal
strength has dropped according to the logging.
That's really not the point is it.
It is. If you have an SSID registerd with the Pi that is 2.4GHZ its
going to sometimes connect to it
So remove it from the PI. It then wont know it exists.
No it's not. You are recommending the use of Network Manager instead of DHCPCD/WPA_Supplicant for headless Pi's, when it has serious problems
which I and others have detailed. Your response is to suggest an
increasing number of workarounds, some of which reduce useful
functionality.
The reason the 2.4GHz SSID is configured is in case the Pi needs to be relocated to another part of the property where 5 GHz is too weak.
has never been a problem when using DHCPCD/WPA_Supplicant, so I'm not
about to remove it in order to use a flaky Network Manager.
The sensible solution is to use the correct tool for the job, rather
than whatever happens to be installed by default by Raspbian. This is an advantage of Linux, instead of being stuck with whatever Microsoft
mandates you should use in Windows.
---druck
On 01/11/2024 20:40, druck wrote:
The sensible solution is to use the correct tool for the job, rather
than whatever happens to be installed by default by Raspbian. This is
an advantage of Linux, instead of being stuck with whatever Microsoft
mandates you should use in Windows.
---druck
If you want to tread a lone path that is your privilege.
Don't expect support from those who have chosen to understand the main
road.
On 02/11/2024 11:10, The Natural Philosopher wrote:
On 01/11/2024 20:40, druck wrote:
The sensible solution is to use the correct tool for the job, rather
than whatever happens to be installed by default by Raspbian. This is
an advantage of Linux, instead of being stuck with whatever Microsoft
mandates you should use in Windows.
---druck
If you want to tread a lone path that is your privilege.
Don't expect support from those who have chosen to understand the main
road.
I hate to interrupt your argument, but I'm the one giving support not
asking for it. Remind me what your motivation is again?
---druck
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 371 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 175:00:26 |
| Calls: | 7,915 |
| Files: | 12,983 |
| Messages: | 5,797,724 |