• Pi4 to Pi5 migration

    From bp@www.zefox.net@3:770/3 to All on Wed Jun 5 16:07:46 2024
    What's the easiest way to migrate from Pi4 to Pi5?

    In this case I've a Pi4 running from a USB mechanical
    hard disk. What I'd like to do is upgrade the existing
    system OS to boot either Pi4 or Pi5, but I'm wary of
    unintended consequences. The disk is fairly new and so
    far has been reliable, so there's no strong incentive
    to replace it.

    Thanks for reading, and any suggestions.

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Pancho on Thu Jun 6 18:24:34 2024
    Pancho <Pancho.Jones@proton.me> wrote:
    On 05/06/2024 17:07, bp@www.zefox.net wrote:
    What's the easiest way to migrate from Pi4 to Pi5?

    In this case I've a Pi4 running from a USB mechanical
    hard disk.


    Why not use an SD card as the system disk, booting OS + apps and reserve
    the hdd for data?

    I used to do that, before it was possible to boot from USB. There's
    nothing wrong with it, excecpt that it requires a custom /etc/fstab.
    Since the appearance of direct USB booting on the Pi3 eliminating
    the microSD gets rid of one thing that can go wrong.


    The trick is to separate app installation, executables etc, from data. I
    get that from using Docker containers. It's worth looking at Docker
    because life is just so much easier, in the long run. Not only does
    Docker separate exes and data it also tends to script setup/config
    making changes easier.

    All the stuff I'll need to carry over from one install to the next
    is in my home directory, Docker is overkill, I think....

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to druck on Thu Jun 6 19:03:12 2024
    druck <news@druck.org.uk> wrote:
    Yes sorry its bullseye to BOOKWORM


    In light of private comments on bookworm's new "features" it
    appears that I should set up a bookworm install and play with it
    some. The existing Pi4 works very well under Bullseye, but it'll
    get superceded at some point and I'll have to face Bookworm
    eventually. In principle I like the idea of upgrading from X11,
    though the actual experience may not be fun.....

    One thing I hadn't considered until now is migrating away from
    RasPiOS to something else. Are there any alternatives that offer
    comparable support that will run on the Pi5? The biggest issue
    for me is probably browser support, most other things I do are
    in terminal windows running shells on FreeBSD hosts (also RPi,
    but headless). I'm a less-bad admin with FreeBSD, but it does
    not yet make use of the GPU on any Pi that I know of. AFAIK
    FreeBSD can't yet boot on a Pi5.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Deloptes on Thu Jun 6 19:28:36 2024
    Deloptes <deloptes@gmail.com> wrote:
    druck wrote:

    Pi5 needs bookwork, which is the one that adds Wayland. The previous was >>> bullseye, not buster

    Yes sorry its bullseye to BOOKWORM

    Bookworm can provide also X11. It is the desktop that requires Wayland not Pi5 per se.

    In this case it's the desktop that I want.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to bp@www.zefox.net on Fri Jun 7 08:43:30 2024
    bp@www.zefox.net wrote:
    One thing I hadn't considered until now is migrating away from
    RasPiOS to something else. Are there any alternatives that offer
    comparable support that will run on the Pi5? The biggest issue
    for me is probably browser support,

    Mozilla are publishing ARM64 Firefox binaries for Linux now, so
    that removes the main roadblock to running up-to-date Firefox on
    other Linux distros that didn't compile it regularly themselves.

    I use the PiCore version of Tiny Core Linux, which supports the
    RPi 5. It certainly avoids all the excessive layers of complexity
    in RPiOS (and I'm talking from when I gave up on that about four
    years ago), though there is quite a lot that you need to set up
    from scratch, and very limited packages available. Probably not
    what you mean by "comparable support". Other alternative Linux
    distros are likely better in those regards, maybe Arch Linux?

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Pancho@3:770/3 to bp@www.zefox.net on Fri Jun 7 10:39:38 2024
    On 06/06/2024 20:03, bp@www.zefox.net wrote:

    One thing I hadn't considered until now is migrating away from
    RasPiOS to something else. Are there any alternatives that offer
    comparable support that will run on the Pi5? The biggest issue
    for me is probably browser support,

    Yes, I tried Ubuntu on the rPi5 back in December, it wasn't tailored to
    the Pi. Either the browser support or GPU support was broken, so I
    switched to Pi OS. That might be fixed now, but there isn't much to be
    gained by not using Pi OS.

    I successfully configured the Pi OS desktop to use Gnome and look like
    Ubuntu. It took a bit of messing around, but nothing too difficult.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Scott Alfter on Sat Jun 8 02:11:56 2024
    Scott Alfter <scott@alfter.diespammersdie.us> wrote:
    In article <v3t15g$1kl11$1@dont-email.me>, <bp@www.zefox.net> wrote:
    One thing I hadn't considered until now is migrating away from
    RasPiOS to something else. Are there any alternatives that offer
    comparable support that will run on the Pi5?

    It depends on what you want to do.

    Probably browser performance is the main bottleneck. Far as I know
    the RasPiOS version of chromium is the only browser that exploits
    the VideoCore portion of the Pi. Is this still true?

    It's been a genuine dissapointment that Broadcom failed to open
    VideoCore in a useful way. It's most of the Pi's horsepower. Or,
    am I being unfair?

    Thanks to everyone for reading and replying!

    bob prohaska



    I have Alpine running on a CM4 that
    serves as a headless OctoPrint host for my 3D printer. I've not tried running any of the desktop bits because I don't need them in that application. I've run Gentoo on various RPis, but updates can be painfully slow if you don't cross-compile them on more powerful hardware. I might've had Armbian running at one point (or maybe I'm confusing the RPi with other SBCs on which I've run Armbian).

    None are going to be as easy to get up and running, but if you don't mind getting your hands dirty, they all have their uses and you'll learn
    something from the experience. :)


    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to bp@www.zefox.net on Sun Jun 9 10:19:12 2024
    bp@www.zefox.net wrote:
    Scott Alfter <scott@alfter.diespammersdie.us> wrote:
    In article <v3t15g$1kl11$1@dont-email.me>, <bp@www.zefox.net> wrote:
    One thing I hadn't considered until now is migrating away from
    RasPiOS to something else. Are there any alternatives that offer >>>comparable support that will run on the Pi5?

    It depends on what you want to do.

    Probably browser performance is the main bottleneck. Far as I know
    the RasPiOS version of chromium is the only browser that exploits
    the VideoCore portion of the Pi.

    Via Mesa drivers, hardware 3D graphics rendering should be supported
    in Firefox just like on PC, this has been the case for years. Check
    the details on the about:support page to see whether Firefox on your
    RPi has detected that it's available.

    Of course it's really a matter of what you mean by "exploits". Even
    pure framebuffer mode uses "the VideoCore portion of the Pi", so
    what specific exploitation are you looking for?

    Is this still true?

    I believe Chromium has HW video decoding on the Pi (not sure about
    encoding), so that's probably what you mean. A quick search for
    "Raspberry pi firefox hardware video decoding" brings up many
    results announcing that support was added in Firefox 116. Note that
    this means it's not available in the current Firefox ESR releases,
    if you're using them.

    It's been a genuine dissapointment that Broadcom failed to open
    VideoCore in a useful way. It's most of the Pi's horsepower. Or,
    am I being unfair?

    If you're talking about video en/decoding, then yes that's a bit
    unfair because Broadcom have made the APIs for common functionality
    like that available. Also the Raspberry Pi developers have access to
    all the secret documentation and development kits from Broadcom, and
    it's the code that they've written for their fork of the Linux
    kernel which has become some of the unofficial open-source reference
    material for talking to the RPi's GPU. As the ones selling the
    product, traditionally it's their job to submit code to projects
    like Firefox to help get it supported if they so desire, or fork
    them like they've done with the Linux kernel. Actually Firefox is
    apparantly using a Linux kernel interface for this video decoding
    support, so the RPi developers have up an API as conveniently as
    possible and left the Firefox developers to take the last step of
    using it at their end (quite a few years after Chromium, VLC,
    FFmpeg, etc. did). So you could blame Mozilla too for being so
    slow. Take your pick.

    What Broadcom would enable by fully open-sourcing their GPU code
    and documentation is that the firmware that these APIs talk to
    could be expanded as well. Then extra GPU-accellerated functions
    could be written such as for newer video codecs, or other things
    entirely. By publishing the documentation for the QPU units in the
    VideoCore IV GPUs Broadcom did open some doors towards that, but
    it's not really enough information for a full open-source GPU
    firmware to be independently developed (there's a project for that
    with VideoCore IV, but it stalled years ago).

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Computer Nerd Kev on Sun Jun 9 14:38:28 2024
    Computer Nerd Kev <not@telling.you.invalid> wrote:

    Via Mesa drivers, hardware 3D graphics rendering should be supported
    in Firefox just like on PC, this has been the case for years. Check
    the details on the about:support page to see whether Firefox on your
    RPi has detected that it's available.


    Firefox is Extended Support Release 115.11.0esr(64-bit), installed using
    apt. There's a checkbox to "use hardware acceleration when available"
    but no hint whether it _is_ available or in use.

    My browser of choice is chromium Version 124.0.6367.73 (Official Build)
    Built on Debian , running on Debian 11 (64-bit). It seems a bit faster.
    It also offers a checkbox "Use graphics acceleration when available"
    without giving a hint of what it's actually using. I do remember that highligting the button caused trouble around a year ago.

    Both are up-to-date according to apt.

    Of course it's really a matter of what you mean by "exploits". Even
    pure framebuffer mode uses "the VideoCore portion of the Pi", so
    what specific exploitation are you looking for?

    AIUI a GPU is a coprocessor with its own registers and cache that
    can do single-instruction-multiple-data operations in parallel
    with the CPU such as vector math. That's what I _think_ I'm looking
    for. Compiler enhancements seem necessary, is that the bottleneck?


    I believe Chromium has HW video decoding on the Pi (not sure about
    encoding), so that's probably what you mean. A quick search for
    "Raspberry pi firefox hardware video decoding" brings up many
    results announcing that support was added in Firefox 116. Note that
    this means it's not available in the current Firefox ESR releases,
    if you're using them.


    Aye, there's the rub 8-)

    It's been a genuine dissapointment that Broadcom failed to open
    VideoCore in a useful way. It's most of the Pi's horsepower. Or,
    am I being unfair?

    If you're talking about video en/decoding, then yes that's a bit
    unfair because Broadcom have made the APIs for common functionality
    like that available. Also the Raspberry Pi developers have access to
    all the secret documentation and development kits from Broadcom, and
    it's the code that they've written for their fork of the Linux
    kernel which has become some of the unofficial open-source reference
    material for talking to the RPi's GPU. As the ones selling the
    product, traditionally it's their job to submit code to projects
    like Firefox to help get it supported if they so desire, or fork
    them like they've done with the Linux kernel. Actually Firefox is
    apparantly using a Linux kernel interface for this video decoding
    support, so the RPi developers have up an API as conveniently as
    possible and left the Firefox developers to take the last step of
    using it at their end (quite a few years after Chromium, VLC,
    FFmpeg, etc. did). So you could blame Mozilla too for being so
    slow. Take your pick.

    What Broadcom would enable by fully open-sourcing their GPU code
    and documentation is that the firmware that these APIs talk to
    could be expanded as well. Then extra GPU-accellerated functions
    could be written such as for newer video codecs, or other things
    entirely. By publishing the documentation for the QPU units in the
    VideoCore IV GPUs Broadcom did open some doors towards that, but
    it's not really enough information for a full open-source GPU
    firmware to be independently developed (there's a project for that
    with VideoCore IV, but it stalled years ago).

    Do other GPU companies (Nvidia comes to mind) handle things any better?

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Theo@3:770/3 to bp@www.zefox.net on Sun Jun 9 22:02:12 2024
    bp@www.zefox.net wrote:
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    Of course it's really a matter of what you mean by "exploits". Even
    pure framebuffer mode uses "the VideoCore portion of the Pi", so
    what specific exploitation are you looking for?

    AIUI a GPU is a coprocessor with its own registers and cache that
    can do single-instruction-multiple-data operations in parallel
    with the CPU such as vector math. That's what I _think_ I'm looking
    for. Compiler enhancements seem necessary, is that the bottleneck?

    On the Pi the GPU is a black box, or rather a collection of black boxes
    inside a black box. There is some ability to launch code on small parts of
    the GPU (the QPUs) and some limited compiler support for them. But the
    parts that are used for most of the graphics pipeline aren't accessible -
    the GPU firmware presents an API and the Linux driver talks to that API, but
    we don't get to look at or change the software behind the API.

    What Broadcom would enable by fully open-sourcing their GPU code
    and documentation is that the firmware that these APIs talk to
    could be expanded as well. Then extra GPU-accellerated functions
    could be written such as for newer video codecs, or other things
    entirely. By publishing the documentation for the QPU units in the VideoCore IV GPUs Broadcom did open some doors towards that, but
    it's not really enough information for a full open-source GPU
    firmware to be independently developed (there's a project for that
    with VideoCore IV, but it stalled years ago).

    Do other GPU companies (Nvidia comes to mind) handle things any better?

    Everyone does it. Nvidia is much worse because, unlike RPi and AMD, they
    don't even open source any of the software running on the CPU side of things
    - both the kernel driver and the userspace components are closed source binary-only. Intel is probably the best in that there's good Linux drivers
    and some documentation for how their GPU hardware works, which you don't get with anyone else.

    (Intel make discrete GPUs. You can plug them in but they don't work on a Pi: https://pipci.jeffgeerling.com/cards_gpu/intel-arc-a750.html
    )

    Theo

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to bp@www.zefox.net on Tue Jun 11 09:31:30 2024
    bp@www.zefox.net wrote:
    Computer Nerd Kev <not@telling.you.invalid> wrote:

    Via Mesa drivers, hardware 3D graphics rendering should be supported
    in Firefox just like on PC, this has been the case for years. Check
    the details on the about:support page to see whether Firefox on your
    RPi has detected that it's available.


    Firefox is Extended Support Release 115.11.0esr(64-bit), installed using
    apt. There's a checkbox to "use hardware acceleration when available"
    but no hint whether it _is_ available or in use.

    The hints are all on the about:support page that I pointed you to.
    To be specific, type "about:support#graphics" in the URL bar and press
    Enter. There you'll find the specifics of what hardware accelleration
    is used, or maybe a clue why it's not. You might need to look up the
    terms used to see how they relate to the specific GPU accelleration
    you want, but if my guess about your intentions is correct then look
    at "HARDWARE_VIDEO_DECODING".

    My browser of choice is chromium Version 124.0.6367.73 (Official Build)
    Built on Debian , running on Debian 11 (64-bit). It seems a bit faster.
    It also offers a checkbox "Use graphics acceleration when available"
    without giving a hint of what it's actually using. I do remember that highligting the button caused trouble around a year ago.

    Both are up-to-date according to apt.

    Debian package the ESR versions, but you could manually install the
    Mozilla ARM64 Firefox binaries, though I think currently they're
    only nightly builds, so the other extreme of stability. Firefox ESR
    128 will be released on the 9th of July (Debian packages may take
    some time longer to arrive).

    Of course it's really a matter of what you mean by "exploits". Even
    pure framebuffer mode uses "the VideoCore portion of the Pi", so
    what specific exploitation are you looking for?

    AIUI a GPU is a coprocessor with its own registers and cache that
    can do single-instruction-multiple-data operations in parallel
    with the CPU such as vector math. That's what I _think_ I'm looking
    for. Compiler enhancements seem necessary, is that the bottleneck?

    No the code running on the GPU is all written by Broadcom and Linux
    software just talks to that, so nothing needs to be compiled for
    the GPU in order to use functionality that's in the stock GPU
    firmware. The bottleneck at this point seems to be mainly
    application developers adding support for the APIs, but this isn't
    an issue with compilers, just the usual limits of time, money, and
    willpower.

    If you want to do more with the GPU than using the routines
    Broadcom's firmware includes, such as support en/decoding other
    video codecs, or using it as a co-processor for non-graphics-related
    tasks, then free compiler options become limited. That gets
    complicated, but it's not much to do with PC-like GPU acceleration
    in web browsers, that is already facilitated by Broadcom's
    pre-compiled GPU firmware binary which runs on the GPU from
    start-up (in fact it's what starts the CPU and Linux up).

    What Broadcom would enable by fully open-sourcing their GPU code
    and documentation is that the firmware that these APIs talk to
    could be expanded as well. Then extra GPU-accellerated functions
    could be written such as for newer video codecs, or other things
    entirely. By publishing the documentation for the QPU units in the
    VideoCore IV GPUs Broadcom did open some doors towards that, but
    it's not really enough information for a full open-source GPU
    firmware to be independently developed (there's a project for that
    with VideoCore IV, but it stalled years ago).

    Do other GPU companies (Nvidia comes to mind) handle things any better?

    No, it's unlikely to be in their interest to release documents to
    help others write open-source firmware for GPUs, because then
    people could add features and performance improvements to cheaper
    GPU chips that might reduce the market for their more expensive
    models. Still the degree of openness varies, overall Broadcom isn't
    great, but better than Nvidia and no worse than others.

    Much the same applies to other parts on the RPi boards like the
    WiFi/Bluetooth chips which also run closed-source firmware
    binaries. There are other SBCs that try to use more "open
    hardware", but the RPis prioritise low-cost ahead of that.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Newyana2@3:770/3 to bp@www.zefox.net on Mon Jun 10 20:31:02 2024
    On 6/6/2024 3:03 PM, bp@www.zefox.net wrote:
    druck <news@druck.org.uk> wrote:
    Yes sorry its bullseye to BOOKWORM


    In light of private comments on bookworm's new "features" it
    appears that I should set up a bookworm install and play with it
    some. The existing Pi4 works very well under Bullseye, but it'll
    get superceded at some point and I'll have to face Bookworm
    eventually. In principle I like the idea of upgrading from X11,
    though the actual experience may not be fun.....


    For what it's worth, I moved from Buster to Bookwrm on a
    Pi4 recently. I really only use it for streaming movies. The
    streaming services would no longer accept Firefox on Buster.
    It maxed out at v. 92 if I remember correctly.

    I was pleasantly surprised. I couldn't tell you what's different.
    It just runs quicker and feels more solid on the same hardware.
    It's a pleasure to see an update require *less* resources. All I
    care about is getting Netflix, Kanopy, PBS, etc in Firefox. Now
    that's working better than ever.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to newyana@invalid.nospam on Tue Jun 11 02:20:52 2024
    Newyana2 <newyana@invalid.nospam> wrote:

    For what it's worth, I moved from Buster to Bookwrm on a
    Pi4 recently. I really only use it for streaming movies. The
    streaming services would no longer accept Firefox on Buster.
    It maxed out at v. 92 if I remember correctly.

    I was pleasantly surprised. I couldn't tell you what's different.
    It just runs quicker and feels more solid on the same hardware.
    It's a pleasure to see an update require *less* resources. All I
    care about is getting Netflix, Kanopy, PBS, etc in Firefox. Now
    that's working better than ever.


    That's most encouraging. The Pi5 is on order, should show up
    in a week or so. I'll set up a clean install on a new disk
    to see how it behaves.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to bp@www.zefox.net on Tue Jun 11 18:41:40 2024
    bp@www.zefox.net wrote:
    Computer Nerd Kev <not@telling.you.invalid> wrote:

    No the code running on the GPU is all written by Broadcom and Linux
    software just talks to that, so nothing needs to be compiled for
    the GPU in order to use functionality that's in the stock GPU
    firmware. The bottleneck at this point seems to be mainly
    application developers adding support for the APIs, but this isn't
    an issue with compilers, just the usual limits of time, money, and
    willpower.


    Ok, that clarifies things considerably. Is the API public, at least?
    Then folks could experiment.

    Broadcom's API is DispmanX, which some programs have used directly,
    but libbrcmEGL is their library that presents an OpenGL interface
    and is thus easier to adapt software to. Separately the Linux
    kernel now has its own drivers, which are used via Mesa. I'm not
    sure how the performance compares, but the Mesa drivers are the
    popular ones these days.

    There's more info about the various APIs indexed here: https://forums.raspberrypi.com/viewtopic.php?t=317511

    If you want to do more with the GPU than using the routines
    Broadcom's firmware includes, such as support en/decoding other
    video codecs, or using it as a co-processor for non-graphics-related
    tasks, then free compiler options become limited. That gets
    complicated, but it's not much to do with PC-like GPU acceleration
    in web browsers, that is already facilitated by Broadcom's
    pre-compiled GPU firmware binary which runs on the GPU from
    start-up (in fact it's what starts the CPU and Linux up).

    Is this to say that if somebody wanted to write a cryptocurrency
    miner for the Raspberry Pi VideoCore they'd need Broadcom's help?

    Only that it would be easier with Broadcom's help. But there's
    enough info about the QPUs available that it should be possible.

    Here's an early example of the QPUs being used to run custom
    routines:
    http://www.aholme.co.uk/GPU_FFT/Main.htm

    More recent is this OpenCL implementation which probably makes it
    easier to do things like cryptocurrency mining:
    https://github.com/doe300/VC4CL

    https://kenny-peng.com/2021/09/14/raspi_zero_opencl.html

    The QPU processor cores are used along with one of two more
    capable VPU processor cores in the VideoCore IV GPU for running
    the stock GPU firmware. Broadcom released some documentation on
    the QPUs, but information on the VPU is all reverse-engineered or
    based on code written by Raspberry Pi developers who obviously have
    access to the proprietary docs. So that makes writing an
    open-source replacement for Broadcom's GPU firmware very difficult,
    but the QPUs can be used for parallel data processing jobs like
    crypto mining, and some simple things can be done with the VPUs as
    well.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Computer Nerd Kev@3:770/3 to Computer Nerd Kev on Sun Jun 16 11:06:54 2024
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    bp@www.zefox.net wrote:
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    No the code running on the GPU is all written by Broadcom and Linux
    software just talks to that, so nothing needs to be compiled for
    the GPU in order to use functionality that's in the stock GPU
    firmware. The bottleneck at this point seems to be mainly
    application developers adding support for the APIs, but this isn't
    an issue with compilers, just the usual limits of time, money, and
    willpower.

    Ok, that clarifies things considerably. Is the API public, at least?
    Then folks could experiment.

    Broadcom's API is DispmanX, which some programs have used directly,
    but libbrcmEGL is their library that presents an OpenGL interface
    and is thus easier to adapt software to. Separately the Linux
    kernel now has its own drivers, which are used via Mesa. I'm not
    sure how the performance compares, but the Mesa drivers are the
    popular ones these days.

    At the risk of correcting myself about details that nobody cares
    about anyway, it turns out the original work on Mesa's VC4 driver
    was led by a Broadcom developer as well. So that would really be
    Broadcom's current graphics API. Seems it actually bypasses the
    original closed-source firmware running on the VPU, to do that
    graphics processing on the CPU instead, which is a bit of a waste
    of the GPU's processing abilities. But it seems they preferred that
    to opening the sources and build system for the VPU firmware and
    improving upon that, though that's still used for hardware
    management tasks.

    Here's the VC4 driver developer's blog:
    https://anholt.livejournal.com/

    And their post about being hired by Broadcom to write the GPU
    driver for Mesa and the Linux kernel:
    https://anholt.livejournal.com/44239.html

    More recently the GPU drivers for the RPi4 and 5 have be developed
    by Igalia, presumably as sub-contractor for Broadcom since Igalia
    took over from the Broadcom developer: https://www.raspberrypi.com/news/vc4-and-v3d-opengl-drivers-for-raspberry-pi-an-update/
    https://www.igalia.com/2023/09/28/Raspberry-Pi-5-Announced.html https://www.igalia.com/technology/graphics

    It's interesting to find out where all this code comes from.
    Broadcom have been more involved than I thought.

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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Computer Nerd Kev on Sun Jun 16 23:42:40 2024
    Computer Nerd Kev <not@telling.you.invalid> wrote:
    [huge snip]

    It's interesting to find out where all this code comes from.
    Broadcom have been more involved than I thought.

    Indeed. It's interesting to note that about ten years have
    elapsed, and it looks as if the Pi GPU is getting close to
    general usefulness.

    That's about how long it took from the advent of the i386 to
    the general availability of *nix clones.

    Thank you for a most informative post!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Mon Jun 17 17:02:36 2024
    On 17/06/2024 02:37, Ahem A Rivet's Shot wrote:
    On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    Indeed. It's interesting to note that about ten years have
    ...
    That's about how long it took from the advent of the i386 to
    the general availability of *nix clones.

    More like five years, the 80386 came out in 1987. There were BSD
    ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.

    Very hard to put a decent Unix on a 286 - Venix was the only one, I
    recally. No memory management.

    the 386 made porting unix pretty simple. SCO unix was extremely stable.
    Wasn;'t that a Xenix evolution?


    Interactive was a bit shitty, but it ran.


    --
    Karl Marx said religion is the opium of the people.
    But Marxism is the crack cocaine.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to The Natural Philosopher on Mon Jun 17 17:51:40 2024
    On Mon, 17 Jun 2024 17:02:37 +0100
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    Very hard to put a decent Unix on a 286 - Venix was the only one, I
    recally. No memory management.

    XENIX was available for the 8086 and the 80286.

    Altos used to make a surprisingly usable XENIX machine with an 8086 main processor and a pair of Z80B IO processors (one for the serial ports,
    one for the tape and disc). They kept this basic architecture while
    upgrading processors (80286+2x8086, 80386+2*80186).

    The 80286 had a protected mode with memory management but did not supply any means to exit from it so the transition to kernel side
    unprotected mode had to be done by calling on the keyboard controller to
    reset the processor - code then checked a flag location for the value that
    said this wasn't a cold boot.

    the 386 made porting unix pretty simple. SCO unix was extremely stable.

    It certainly did.

    Wasn;'t that a Xenix evolution?

    Yes SCO bought XENIX from Microsoft, then when they switched to the SysVR4 codebase (AT&T pulled in everything they could from XENIX and BSD)
    they got to rename it to Unix. The earlier XENIX was also rock solid IME on
    PC or Altos hardware.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Ahem A Rivet's Shot on Mon Jun 17 18:03:36 2024
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    Indeed. It's interesting to note that about ten years have
    ...
    That's about how long it took from the advent of the i386 to
    the general availability of *nix clones.

    More like five years, the 80386 came out in 1987. There were BSD ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.

    We're comparing different endpoints. I started with 386BSD and it
    could be made to install and run by about 1992, but that alone was
    an accomplishment for a non-expert like me. It took a few more
    years to become _usable_ by non-experts, in the form of FreeBSD.
    Maybe I'm off a little on the dates (I learned of 386BSD about a
    year after the Byte Magazine series by Jolitz) but then it was
    still very fiddly. By about 1997-8 I was using FreeBSD for email.

    Others were doubtless quicker on the uptake, but they were a select
    group. I was (and am) merely an early-adopting consumer.

    Thanks for posting,

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bp@www.zefox.net on Mon Jun 17 21:31:02 2024
    On Mon, 17 Jun 2024 18:03:37 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Sun, 16 Jun 2024 23:42:41 -0000 (UTC)

    More like five years, the 80386 came out in 1987. There were
    BSD ports available by 1993 and the first Linux release was in 1991. However that's just open source - There were commercial XENIX and Interactive ports earlier - even for the 80286.

    We're comparing different endpoints. I started with 386BSD and it
    could be made to install and run by about 1992, but that alone was
    an accomplishment for a non-expert like me. It took a few more

    Indeed it was - did you have the patch kit ?

    years to become _usable_ by non-experts, in the form of FreeBSD.

    Nope FreeBSD 1.0 came out in November 1993 - I was using 1.1.5.1 to
    run a Dublin based ISP in 1994. We gave Jordan Hubbard a free account when
    we discovered he was visiting Ireland and he gave us a stack of 1.1 discs.
    He got the better deal :)

    Maybe I'm off a little on the dates (I learned of 386BSD about a
    year after the Byte Magazine series by Jolitz) but then it was
    still very fiddly. By about 1997-8 I was using FreeBSD for email.

    That would be late 2.2 or early 3.0 days - 3.0 was the release that included APM support for laptops, one of the few occasions I ran -current.

    Others were doubtless quicker on the uptake, but they were a select

    Many others between 1994 and 1998.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to druck on Mon Jun 24 22:28:00 2024
    druck <news@druck.org.uk> wrote:
    On 06/06/2024 19:24, bp@www.zefox.net wrote:
    Pancho <Pancho.Jones@proton.me> wrote:
    Why not use an SD card as the system disk, booting OS + apps and reserve >>> the hdd for data?

    I used to do that, before it was possible to boot from USB. There's
    nothing wrong with it, excecpt that it requires a custom /etc/fstab.
    Since the appearance of direct USB booting on the Pi3 eliminating
    the microSD gets rid of one thing that can go wrong.


    You shouldn't need to customise /etc/fstab with USB data discs as they
    will be automatically mounted in /media unless you want them mounted elsewhere.

    It just dawned on me that I was writing about FreeBSD, not RasPiOS;
    apologies for the confusion!

    In the meantime, the Pi5 is up and running on a fresh install of Bookworm. Impressively faster than the Pi4 running Bullseye.

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Both machines are connecting via DHCP, so the WAP is the default route
    for both. Do I need to do something special to use sftp between them?

    Thanks for reading!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to bp@www.zefox.net on Tue Jun 25 10:20:06 2024
    On 24/06/2024 23:28, bp@www.zefox.net wrote:
    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Both machines are connecting via DHCP, so the WAP is the default route
    for both. Do I need to do something special to use sftp between them?
    Hang on a minute.

    Is the WAP capable of routing?

    I assumed you had a proper router somewhere doing routing and DHCP and
    the WAP was merely bridging to it

    From where is the ssh working?b sftp IS ssh.
    --
    Ideas are more powerful than guns. We would not let our enemies have
    guns, why should we let them have ideas?

    Josef Stalin

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Jean-Pierre Kuypers@3:770/3 to bp@www.zefox.net on Tue Jun 25 11:57:04 2024
    In article (Dans l'article) <v5crtg$153r4$1@dont-email.me>,
    <bp@www.zefox.net> wrote (écrivait) :

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.

    What about "ifconfig -a"

    --
    Jean-Pierre Kuypers

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to The Natural Philosopher on Tue Jun 25 17:20:06 2024
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    Both machines are connecting via DHCP, so the WAP is the default route
    for both. Do I need to do something special to use sftp between them?
    Hang on a minute.

    Is the WAP capable of routing?

    I assumed you had a proper router somewhere doing routing and DHCP and
    the WAP was merely bridging to it


    I didn't think routing would be needed, since both hosts are on the
    same network.
    The Pi5 is at 192.168.1.10,
    the Pi4 is at 192.168.1.11
    a printer at 192.168.1.250
    and a Mac at 192.168.1.22

    Both Pi4 and Pi5 can ping the printer sucessfully.
    Neither Pi can ping the other, nor the Mac.
    both can ping themselves using their assigned IP number.
    The Mac can ping the printer but neither Pi.

    From where is the ssh working?b sftp IS ssh.

    It works to the WAN, no problem. I don't think I've tried using
    ssh/sftp across the LAN until now, or at least not recently.

    The Pi4 is running Bullseye, the Pi5 Bookworm.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Chris Townley@3:770/3 to bp@www.zefox.net on Tue Jun 25 18:36:02 2024
    On 25/06/2024 18:20, bp@www.zefox.net wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    Both machines are connecting via DHCP, so the WAP is the default route
    for both. Do I need to do something special to use sftp between them?
    Hang on a minute.

    Is the WAP capable of routing?

    I assumed you had a proper router somewhere doing routing and DHCP and
    the WAP was merely bridging to it


    I didn't think routing would be needed, since both hosts are on the
    same network.
    The Pi5 is at 192.168.1.10,
    the Pi4 is at 192.168.1.11
    a printer at 192.168.1.250
    and a Mac at 192.168.1.22

    Both Pi4 and Pi5 can ping the printer sucessfully.
    Neither Pi can ping the other, nor the Mac.
    both can ping themselves using their assigned IP number.
    The Mac can ping the printer but neither Pi.

    From where is the ssh working?b sftp IS ssh.

    It works to the WAN, no problem. I don't think I've tried using
    ssh/sftp across the LAN until now, or at least not recently.

    The Pi4 is running Bullseye, the Pi5 Bookworm.

    Thanks for writing!

    bob prohaska


    What netmask are using on these devices? 192.168 can be either B or C

    --
    Chris

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bp@www.zefox.net on Tue Jun 25 19:24:04 2024
    On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Is the WAP configured to block traffic between clients ? That seems
    to be the default with many consumer WAPs.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Chris Townley on Tue Jun 25 18:23:26 2024
    Chris Townley <news@cct-net.co.uk> wrote:
    On 25/06/2024 18:20, bp@www.zefox.net wrote:
    The Natural Philosopher <tnp@invalid.invalid> wrote:

    Both machines are connecting via DHCP, so the WAP is the default route >>>> for both. Do I need to do something special to use sftp between them?
    Hang on a minute.

    Is the WAP capable of routing?

    I assumed you had a proper router somewhere doing routing and DHCP and
    the WAP was merely bridging to it


    I didn't think routing would be needed, since both hosts are on the
    same network.
    The Pi5 is at 192.168.1.10,
    the Pi4 is at 192.168.1.11
    a printer at 192.168.1.250
    and a Mac at 192.168.1.22

    Both Pi4 and Pi5 can ping the printer sucessfully.
    Neither Pi can ping the other, nor the Mac.
    both can ping themselves using their assigned IP number.
    The Mac can ping the printer but neither Pi.

    From where is the ssh working?b sftp IS ssh.

    It works to the WAN, no problem. I don't think I've tried using
    ssh/sftp across the LAN until now, or at least not recently.

    The Pi4 is running Bullseye, the Pi5 Bookworm.

    Thanks for writing!

    bob prohaska


    What netmask are using on these devices? 192.168 can be either B or C

    The Pi4, Pi5 and Mac are all using 255.255.255.0.

    Could this be some sort of security feature? In a classroom
    environment direct communication between student workstations
    might be worth suppressing, especially at exam time 8-)

    Thanks for writing,

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Ahem A Rivet's Shot on Tue Jun 25 19:53:10 2024
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Is the WAP configured to block traffic between clients ? That seems to be the default with many consumer WAPs.

    I think the answer is "no". There is an "advanced" tab in the router
    config mentioning IP filters, but explains "Use IP Filters to deny
    LAN IP addresses access to the Internet" which isn't my problem.
    Both firewalls and DMZ are disabled. There's also a "block WAN Ping"
    option, but that's to "Discard PING from WAN side" and disabled.

    The Pi4 and Pi5 hosts can ping the printer, but the two Pi's can't
    ping each other, nor will they answer ping from a Mac. Both Pi's
    can self-ping on their assigned LAN address.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Ahem A Rivet's Shot@3:770/3 to bp@www.zefox.net on Tue Jun 25 21:18:48 2024
    On Tue, 25 Jun 2024 19:53:11 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Is the WAP configured to block traffic between clients ? That
    seems to be the default with many consumer WAPs.

    I think the answer is "no". There is an "advanced" tab in the router
    config mentioning IP filters, but explains "Use IP Filters to deny

    It's usually called something to do with isolation "wireless" or "client" most often. I'd be surprised if there wasn't the option.

    --
    Steve O'Hara-Smith
    Odds and Ends at http://www.sohara.org/
    For forms of government let fools contest
    Whate're is best administered is best - Alexander Pope

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to Ahem A Rivet's Shot on Wed Jun 26 00:04:08 2024
    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Tue, 25 Jun 2024 19:53:11 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    Ahem A Rivet's Shot <steveo@eircom.net> wrote:
    On Mon, 24 Jun 2024 22:28:01 -0000 (UTC)
    <bp@www.zefox.net> wrote:

    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    Is the WAP configured to block traffic between clients ? That
    seems to be the default with many consumer WAPs.

    I think the answer is "no". There is an "advanced" tab in the router
    config mentioning IP filters, but explains "Use IP Filters to deny

    It's usually called something to do with isolation "wireless" or "client" most often. I'd be surprised if there wasn't the option.

    It's an old router, a D-Link di-524.

    The "wireless" page on the router configuration is exclusively about configuring client connections (radio on, ssid, security). The LAN
    page sets the router's LAN IP, subnet mask and local domain, along
    with "dns relay", which is enabled.

    There is a long list of "virtual servers", but I think that's to do
    with services to the WAN. All are disabled.

    I again tried to connect from the Mac to the Pi4 and Pi5, this time
    using sftp. That timed out, but it didn't report "no path to host"
    like ping did. Using ssh failed with a host key error, suggesting
    the connections to the Pi4 and Pi5 worked but ssh on the Mac is too
    old. It _is_ old, being Mac OS X 10.7.5, but that's nothing to do
    with why the two Pi's cannot ssh each other. An attempt to connect
    via sftp reported
    ssh: connect to host 192.168.1.10 port 22: No route to host
    Connection closed
    after a short delay.

    Thanks for writing!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to bp@www.zefox.net on Wed Jun 26 13:30:02 2024
    <bp@www.zefox.net> writes:

    Could this be some sort of security feature? In a classroom
    environment direct communication between student workstations
    might be worth suppressing, especially at exam time 8-)

    Yes, some WAPs have a feature like that so clients connected to it can't
    see each other. It seems like a common thing to do in open and
    semi-secure WLANs.

    So, check the settings of your WAP.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From The Natural Philosopher@3:770/3 to Anssi Saari on Wed Jun 26 15:34:56 2024
    On 26/06/2024 11:30, Anssi Saari wrote:
    <bp@www.zefox.net> writes:

    Could this be some sort of security feature? In a classroom
    environment direct communication between student workstations
    might be worth suppressing, especially at exam time 8-)

    Yes, some WAPs have a feature like that so clients connected to it can't
    see each other. It seems like a common thing to do in open and
    semi-secure WLANs.

    So, check the settings of your WAP.
    And if it isnt the main dhcp server, disable it for DHCP as well

    --
    In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

    - George Orwell

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to bp@www.zefox.net on Wed Jun 26 21:23:56 2024
    On 24/06/2024 23:28, bp@www.zefox.net wrote:
    At this point both machines are on the same 192.168.1.y network, but
    they don't seem able to communicate at all, simply reporting
    "no route to host" from either end. Ping fails, losing all packets.
    It looks like sshd is running, based on ps output.

    I've recently found an wireless access point which wouldn't route
    between 2.4GHz and 5GHz WiFi networks. Devices on either WiFi could
    other devices on the same, or on Ethernet, but not the other.

    It was a bugger to tack down as the Pi talked to my laptop when I was
    near it, but stopped working when I was further away. Although the Pi 3B
    has both 2.4 and 5, it was far away from the AP so used 2.4 as did the
    laptop when it was nearby. However moving away the the laptop switched
    to back 5 GHz, and couldn't see the Pi any more.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Andy Burns@3:770/3 to druck on Wed Jun 26 21:29:04 2024
    druck wrote:

    Although the Pi 3B has both 2.4 and 5, it was far away from the AP

    Are you saying you added a USB 5GHz dongle? Because otherwise an rPi 3B
    is 2.4GHz only ...

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From Anssi Saari@3:770/3 to Andy Burns on Thu Jun 27 15:45:44 2024
    Andy Burns <usenet@andyburns.uk> writes:

    druck wrote:

    Although the Pi 3B has both 2.4 and 5, it was far away from the AP

    Are you saying you added a USB 5GHz dongle? Because otherwise an rPi
    3B is 2.4GHz only ...

    Or maybe he meant 3B+ instead of 3B.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From druck@3:770/3 to All on Thu Jun 27 14:59:30 2024
    T24gMjYvMDYvMjAyNCAyMToyOSwgQW5keSBCdXJucyB3cm90ZToNCj4gZHJ1Y2sgd3JvdGU6 DQo+IA0KPj4gQWx0aG91Z2ggdGhlIFBpIDNCIGhhcyBib3RoIDIuNCBhbmQgNSwgaXQgd2Fz IGZhciBhd2F5IGZyb20gdGhlIEFQDQo+IA0KPiBBcmUgeW91IHNheWluZyB5b3UgYWRkZWQg YSBVU0IgNUdIeiBkb25nbGU/wqAgQmVjYXVzZSBvdGhlcndpc2UgYW4gclBpIDNCIA0KPiBp cyAyLjRHSHogb25seSAuLi4NCg0KTm8sIHNvcnJ5IEkgbGVmdCB0aGUgcGx1cyBvdXQsIHRo YXQgb25lIGlzIGEgM0IrLg0KDQotLS1kcnVjaw0K

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From bp@www.zefox.net@3:770/3 to All on Sat Jun 29 17:41:12 2024
    I elected to simply sftp my existing home directory to another
    local host, clean out the trash and then sftp the files to my
    Pi5 account.

    Copying my personal files presented no problem. Now the question
    is how to merge the dotfiles, preserving things like browsing
    history, saved passwords, bookmarks and cookies used for recognition.
    At the moment that's the biggest sticking point. My first try at
    a manual merge failed utterly, chromium seems oblivious to my
    browsing history. I'm in a position to delete and re-create any
    and all, up to and including the OS install if necessary.


    I now appreciate much better some of the reservations folks have
    about bookworm. The look and feel is quite different, clicking
    on icons often brings up something called "geany", which I gather
    is some sort of programming environment, instead of a text editor.
    Not so sure I like that part. I do very much like the speed of the Pi5,
    though.

    Thanks for reading and any guidance!

    bob prohaska

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)