• RISC OS 5.30 on The Register

    From Richard Porter@21:1/5 to All on Fri May 3 20:28:24 2024
    https://www.theregister.com/2024/05/02/rool_530_is_here/?utm_source=weekly&utm_medium=newsletter&utm_content=article

    RISC OS Open 5.30 is here - with Pi Wi-Fi support - The Register

    Why isn't 5.29 considered a "stable release"?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to Richard Porter on Sat May 4 00:01:06 2024
    In article <[email protected]>,
    Richard Porter <[email protected]> wrote:
    https://www.theregister.com/2024/05/02/rool_530_is_here/?utm_source=weekly&utm_medium=newsletter&utm_content=article

    RISC OS Open 5.30 is here - with Pi Wi-Fi support - The Register

    Why isn't 5.29 considered a "stable release"?

    Because it is an odd-numbered Development release. They can change on
    a daily basis with latest changes, and occan cause problems.

    Even-numbered releases have been through a checking process on many
    platforms before release, and once released do not change.

    See https://www.riscosopen.org/content/documents/stable-releases
    for details.

    --
    Martin Avison
    Note that unfortunately this email address will become invalid
    without notice if (when) any spam is received.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Steve Fryatt@21:1/5 to Martin on Sat May 4 17:48:52 2024
    On 4 May, Martin wrote in message
    <[email protected]>:

    In article <[email protected]>,
    Richard Porter <[email protected]> wrote:

    Why isn't 5.29 considered a "stable release"?

    Because it is an odd-numbered Development release. They can change on a
    daily basis with latest changes, and occan cause problems.

    More specifically, on any given day, the 5.29 download will have been
    whetever was built from the source tree on the previous night. Now that 5.30 has come out, a new 5.31 is getting built every night.

    There will be many thousands of different odd numbered releases with the
    same version number. The only way to tell them apart is to look at the build date and then trawl through the version control logs on ROOL's repository.

    This is why some hardware houses producing their own "stable" releases of odd-numbered OS versions is... unhelpful.

    Even-numbered releases have been through a checking process on many
    platforms before release, and once released do not change.

    And, more importantly, if there remain serious issues, a platform doesn't
    get a stable release.

    See https://www.riscosopen.org/content/documents/stable-releases for
    details.

    --
    Steve Fryatt - Leeds, England

    http://www.stevefryatt.org.uk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Liam Proven@21:1/5 to Richard Porter on Tue Jul 16 18:19:44 2024
    On 03/05/2024 8:28 pm, Richard Porter wrote:
    RISC OS Open 5.30 is here - with Pi Wi-Fi support - The Register

    Ah, yes, that was my story. :-)

    I really enjoyed experimenting with it on a Pi 400 and Pi 3. Sadly, I
    can't find any straightforward way of expanding the filesystem to use
    all my card, and in copying stuff off my old RISC OS Direct card, I have
    mostly filled the disk now.

    I am aware that there is some paid-for tool, but I very rarely use the
    OS and as El Reg's FOSS chap, paying for software is something I have
    not done in about 3 or 4 decades now, I'm afraid.


    --
    Liam Proven -- lproven+es on Hotmail, liamproven+es on AOL & Yahoo https://about.me/liamproven

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From druck@21:1/5 to Liam Proven on Wed Jul 17 12:01:29 2024
    On 16/07/2024 18:19, Liam Proven wrote:
    On 03/05/2024 8:28 pm, Richard Porter wrote:
    RISC OS Open 5.30 is here - with Pi Wi-Fi support - The Register

    Ah, yes, that was my story. :-)

    I really enjoyed experimenting with it on a Pi 400 and Pi 3. Sadly, I
    can't find any straightforward way of expanding the filesystem to use
    all my card, and in copying stuff off my old RISC OS Direct card, I have mostly filled the disk now.

    I am aware that there is some paid-for tool, but I very rarely use the
    OS and as El Reg's FOSS chap, paying for software is something I have
    not done in about 3 or 4 decades now, I'm afraid.

    Hi Liam,

    Unfortunately the situation is far from ideal. Currently the only way is
    to get a new larger SD card, run Elesar's SystemDisc tool on it, which
    formats it with a special variation of the RISC OS FileCore format, that
    leaves room at the start for the FAT partition containing the Raspberry
    Pi start up code. You then need to copy all the RISC OS files over from
    the old to the new card.

    However, there is now a new free RISC OS Partition manager program, see https://www.riscosopen.org/forum/forums/5/topics/16064 which aims to
    create the necessary FileCore/FAT partitions to allow the card to be
    used to boot RISC OS. I'm not sure of the state of this feature at the movement.

    But why isn't there a way to expand the card?

    As the author of DiscKnight, the repair tool for the FileCore format,
    (an assuming I can remember anything about Filecore after 25 years) I've
    been asked to make a tool which can expand the file system several
    times. Each time I've looked in to it, come up with a number of options,
    but eventually declined, as there isn't really a good or safe solution,
    that I'd be happy to deliver, although that shouldn't stop anyone else
    from trying.

    The Filecore disc format is very size dependent. It's main unit of
    granularity, the LFAU (large file allocation unit) is chosen to be as
    small as necessary for the size of disc, as the minimum size of file is currently 22x larger than this unit. Each time the disk size doubles (as
    SD cards tend to do), the LFAU must also be doubled, leading to a trade
    off between disc size and the wastage which storing small files.

    The problem this give is that just about every file is aligned to the
    LFAU, and changing it would mean shifting most of the files on the disc
    to the new alignments, and re-writing all the directory entries and
    recreating a new disc map. It could be done, but it would be a long
    process during which any interruption would leave the card in a
    partially completed and non recoverable state. Copying everything to a
    card, is over twice as fast, completely safe and leaves you with a handy
    backup at the end of the day.

    I have looked in to several Franken-formats, which would use the LFAU
    and alignment of a much larger disc, so it could be expanded either on
    first use or later (more difficult). But the drawback is that with
    people using anywhere between 8GB and 256GB SD cards, you don't really
    want to be stuck with an LFAU suitable for 256GB if only using a 16GB or
    32GB and end up a few hundred MB of small files taking up many GB.

    My personal solution is to use a small SD card to hold RISC OS and it's applications, which are invariably many thousands of small files, and
    use a different USB drive or network based storage for larger data files.

    ---druck

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stuart@21:1/5 to druck on Wed Jul 17 13:30:03 2024
    In article <v788aa$1q95d$[email protected]>,
    druck <[email protected]> wrote:
    My personal solution is to use a small SD card to hold RISC OS and it's applications, which are invariably many thousands of small files, and
    use a different USB drive or network based storage for larger data files.

    With USB3 available on the latest Pi it makes no sense not to use an
    external USB drive. I have a 128G SSD, formatted to RISC OS, in a portable enclosure, attached to my Pi. It was originally in my Iyonix, via an IDE
    to SATA adaptor, and when we go away on holiday, I unplug it, take it with
    me, and connect to my Pinebook; essentially taking all my files with me to
    work on away from home should I wish.

    128G USB sticks are freely available now, as an alternative.

    --
    Stuart Winsor

    Tools With A Mission
    sending tools across the world
    http://www.twam.co.uk/

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Martin@21:1/5 to Stuart on Wed Jul 17 14:46:56 2024
    In article <[email protected]>,
    Stuart <[email protected]> wrote:
    With USB3 available on the latest Pi

    Snag is that there is no USB3 driver for RISC OS!
    It will be running at USB2 speeds, surely?

    --
    Martin Avison
    Note that unfortunately this email address will become invalid
    without notice if (when) any spam is received.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Liam Proven@21:1/5 to druck on Wed Jul 17 15:46:26 2024
    On 17/07/2024 12:01 pm, druck wrote:

    Unfortunately the situation is far from ideal. Currently the only way is
    to get a new larger SD card, run Elesar's SystemDisc tool on it, which formats it with a special variation of the RISC OS FileCore format, that leaves room at the start for the FAT partition containing the Raspberry
    Pi start up code. You then need to copy all the RISC OS files over from
    the old to the new card.

    However, there is now a new free RISC OS Partition manager program, see https://www.riscosopen.org/forum/forums/5/topics/16064 which aims to
    create the necessary FileCore/FAT partitions to allow the card to be
    used to boot RISC OS. I'm not sure of the state of this feature at the movement.

    I didn't know about that -- TVM.

    But why isn't there a way to expand the card?

    As the author of DiscKnight, the repair tool for the FileCore format,
    (an assuming I can remember anything about Filecore after 25 years) I've
    been asked to make a tool which can expand the file system several
    times. Each time I've looked in to it, come up with a number of options,
    but eventually declined, as there isn't really a good or safe solution,
    that I'd be happy to deliver, although that shouldn't stop anyone else
    from trying.

    The Filecore disc format is very size dependent. It's main unit of granularity, the LFAU (large file allocation unit) is chosen to be as
    small as necessary for the size of disc, as the minimum size of file is currently 22x larger than this unit. Each time the disk size doubles (as
    SD cards tend to do), the LFAU must also be doubled, leading to a trade
    off between disc size and the wastage which storing small files.

    The problem this give is that just about every file is aligned to the
    LFAU, and changing it would mean shifting most of the files on the disc
    to the new alignments, and re-writing all the directory entries and recreating a new disc map. It could be done, but it would be a long
    process during which any interruption would leave the card in a
    partially completed and non recoverable state. Copying everything to a
    card, is over twice as fast, completely safe and leaves you with a handy backup at the end of the day.

    Yup. I spent a _lot_ of time digging into PartitionMagic back in the
    mid-1990s and I remember the issues well. I suspect FAT and ADFS are
    similar in this.

    Resizing a partition _down_ was quick, but left it horribly fragmented. Resizing up took forever, and as you say, if interrupted you were in
    trouble.

    (For comparison: UEFI firmware uses a FAT32 partition for boot images.
    Some Linux bootloaders now keep the kernel and initrd in the ESP, and
    can easily fill it. *But* the GParted tool can't manipulate FAT32
    volumes of under ~400MB and doesn't warn you until it tries and fails. I destroyed my ESP and made a machine unbootable this way.

    The problems are not just historical.

    I have looked in to several Franken-formats, which would use the LFAU
    and alignment of a much larger disc, so it could be expanded either on
    first use or later (more difficult). But the drawback is that with
    people using anywhere between 8GB and 256GB SD cards, you don't really
    want to be stuck with an LFAU suitable for 256GB if only using a 16GB or
    32GB and end up a few hundred MB of small files taking up many GB.

    True.

    My personal solution is to use a small SD card to hold RISC OS and it's applications, which are invariably many thousands of small files, and
    use a different USB drive or network based storage for larger data files.

    I think there is a shortcut here that you have not mentioned.

    A tool which could extend the partitions _onto a new medium_ would be
    very acceptable and given the costs in 2024 very doable.

    In March I had to go buy a new card for a work project. I bought a 64GB
    card. It was a tenner. I went back a week later for a second. That promo
    offer had gone but a 128GB card was £16.

    So what this notional tool does is easy. You just need 2 cards and a way
    to connect both at once, like a £5 USB adaptor.

    You extract the OS onto whatever random card. You make sure it works.
    Then you attach the destination card and click a button to say "fit it
    onto this one".

    Then it makes the new structures, and copies your stuff onto the new size.

    There's no need to edit _in place_. That's hard. Just write a new image
    onto a new medium.

    --
    Liam Proven -- lproven+es on Hotmail, liamproven+es on AOL & Yahoo https://about.me/liamproven

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)