NY <me@privacy.invalid> wrote:

Silly question: is there any fundamental advantage of LE over BE or vice-versa, or is it a fairly arbitrary choice that once a given chip has been designed, needs to be adhered for in perpetuity so any future CPU of that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't *all* adopt the same endian-ness as that first one?

In brief:

Big endian is useful because the most significant part comes first.
For example, when comparing two decimal numbers aaa and bbb you start with the hundreds digit, and if the hundred digit from a is greater than the hundreds digit from b, then you have your answer and can skip the rest. This is
useful in eg network routing, eg if you want to pattern match 192.168.x.x
you only need wait for the 192.168 bytes to arrive on the wire before you
can route the packet.

Little endian is useful because the address of an object does not depend on
its type. In other words:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", *y);

will still print '5'. On a big endian machine it would print '0' (being the most significant byte of x). You have to know that the object is 32 bits to offset the calculation for the LSB:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", y[3]);

but that would need to be adjusted to y[1] if x was a 16 bit type.

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? What about CPUs in early mainframes - were they all the same byte-ordering?

8 bit CPUs didn't have much of an endianness, because you had to do 16
bit ops by joining together 8 bit ones, so you could do it either way round. Where there was hardware support for 16 bit values, I think it was mostly
LE. Wikipedia tells me 6800, 6809, 68K were BE.

A reason for LE's rise and BE's decline is that the memory conversion
between different types has become more important, but the sorting thing is less important - you're now doing comparisons on 32 or 64 bit chunks, or in networking hardware, where the byte-by-byte comparison doesn't matter.

Theo

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

Theo <theom+news@chiark.greenend.org.uk> writes:

Big endian is useful because the most significant part comes first.
For example, when comparing two decimal numbers aaa and bbb you start with the
hundreds digit, and if the hundred digit from a is greater than the hundreds digit from b, then you have your answer and can skip the rest. This is useful in eg network routing, eg if you want to pattern match 192.168.x.x
you only need wait for the 192.168 bytes to arrive on the wire before you
can route the packet.

Little endian is useful because the address of an object does not depend on its type. In other words:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", *y);

will still print '5'. On a big endian machine it would print '0' (being the most significant byte of x). You have to know that the object is 32 bits to offset the calculation for the LSB:

uint32_t x = 5;
uint8_t *y = &x;
printf("%d\n", y[3]);

but that would need to be adjusted to y[1] if x was a 16 bit type.

BE mostly makes reading hexdumps easier l-) An exception is
multiprecision arithmetic, where word order within a bignum is often little-endian regardless of platform byte order. In that case a
big-endian platform means you have mix-endian bignums, which are no fun
at all to read in a raw hexdump.

Apart from I’m not convinced there’s much to choose between them in a modern general-purpose computer, unless you’re trying to run legacy code
with deeply embedded endianness assumptions (which I gather is an issue
for some businesses).

--
https://www.greenend.org.uk/rjk/

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

On Sat, 26 Feb 2022 22:04:22 +0000, NY wrote:

Was there any reason that all CPUs designed after the very first one
didn't *all* adopt the same endian-ness as that first one?

I suspect not. In any case a number (most) early mainframes except IBM
(?) used memory organised as words rather than bytes and AFAIK all word- addressed systems were bigendian.

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the minority
in being BE?

<
All Motorola MPUs (6800, 6809, 68xxx families) were big-endian. just as
AFAIK all Intel devices are little-endian. Thank Bog all mpus I've seen
used ASCII encoding rather than EBCDIC, where the collation sequence was defined by card handling equipment and is a total mess.

What about CPUs in early mainframes - were they all the same
byte-ordering?

Somebody else can speak for IBM, but I *think* they all used byte
addressing, little endian arithmetic and EBCDIC .

It oldest machine I used was an Elliott 503, built using discrete
transistors. I/O was via 8 track paper tape and a lineprinter. It was a scientific machine, with 8K of 39 bit words implemented in ferrite core
memory. It did floating point calculations a little bit faster than
integer ones. Each word could hold 2 19 bit instructions and if the B
digit (bit 19, the centre bit) was set, the first instruction could
modify the second instruction. Several programs could be loaded at once
but only one ran at a time: the user-provided program was run by the
operator via a 75 word control program and typewriter, had full control.
It treated other programs in memory as co-resident function libraries and
i/o handlers for the tape reader/punches and the lineprinter. IIRC there
was no linker: the Algol 60 compiler left your program in a 32 kWord
ferrite code backing store: if there were no compilation errors it was automatically loaded into main memory and run.

A lot of the later mainframes such as ICL 2900/3900 were far more software-defined:

Burroughs B series were microcoded and used different microcode
interpreters depending on the language a program was written in, with wach program runnin in its own virtual machine.

ICL 1900 series memory, and so also its accumulators, were 24 bit words. Characters were ISO coded 6 bits, packed 4 per word. Each program had its
own address space and there was no stack.

ICL 2900/3900 series architecture was software defined. VME/B, the 2900
OS, ran each user application in a separate virtual machine whose
architecture was software defined. COBOL programs used byte oriented addressing, bytes were EBCDIC coded 8 bits, a stack was used for function calls, register lengths were software definable. Each VM implemented
rings of protection to protect code at different lower levels in the VM
from interference: user-level code could call functions at a lower level
but not modify anything at the lower level, and of course programs could
only communicate with those in other VMs via OS-level system calls. Last,
but not least, the machine could run George 3 and VME/B programs simultaneously. The only sign this was happening was that the operators
had two control consoles - one for each OS. I don't know for surem but
strongly suspect that George 3 was actually running in its own VME/B
defined virtual machine which contained microcode that emulated 1900
hardware.

I was told, on an ICL-run course, that the microcode used to run VME/B in
an OCP (Order Code Processor) in a 2966 mid-range mainframe was executed
by a single 2MHz 6809 MPU.

You may have also heard of the ICL 2903. This was a desk-size box,
capable of running on an office environment, was contained the hardware
of a 2900 disk file controller running microcode that emulated a 1900 mainframe: it would not surprise me if this was the exact same microcode
used under VME/B to run a copy of George 3 on a 2966.

I believe that IBM AS/400 (now called i-Series) used s similar software structure to ICL's VME/B. This would would make sense since both VME/B
and OS/400 were developed at about the same time and both could draw in
the ideas behind the earlier MULTICs OS.

I've also done a lot of work on AS/400 systems and noticed that there
wewre a lot of similarities between the way that VME/B and OS/400 did
things and organised disk space, etc. which also points to the likelihood
that MULTICS was a common ancestor.

ls

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

On 26/02/2022 07:10, Vincent Coen wrote:

Running fstrim is a required process if you are running with a SSD at least in
two primary Linux based systems that have it as a boot drive otherwise failing
to do so will make the SSD run out of disk space when the only fault is that it
has not run Garbage collection to clean up the unused clusters.

This seems to be a case of unadulterated wombat turds

- *nix ext2/3/4 type systems do not benefit from garbage collection
- SSDs do nor benefit from garbage collection as seek times are
essentially zero
- garbage collection has no effect on available disk space
- fstrim, whilst beneficial in theory, is probably redundant as SSD
lifetimes in terms of write cycles already exceed that of spinning
rust. It is certainly *not* mandatory.

In short if you want to increase SSD lifetime from 20 years to 21 years,
use FSTRIM. :-)


--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

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

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message
news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

NY> Does arm have the same
NY> byte-ordering as Intel, or is it the opposite way round (like SPARC >>>> is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode >>> if
you need it, though I don't know of anything that uses that mode. The
different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or
vice-versa, or is it a fairly arbitrary choice that once a given chip has
been designed, needs to be adhered for in perpetuity so any future CPU of
that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't >> *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) >> BE, or were the all LE like the 6502? Was SPARC in the minority in being BE? >> What about CPUs in early mainframes - were they all the same byte-ordering?

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big
endian as well.

--
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)

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher <tnp@invalid.invalid> wrote:

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

<scott@alfter.diespammersdie.us> wrote in message
news:8l9SJ.49823$Y1A7.14509@fx43.iad...

Shaun Buzza <nospam.Shaun.Buzza@f110.n229.z1.fidonet.org> wrote:

NY> Does arm have the same
NY> byte-ordering as Intel, or is it the opposite way round (like SPARC >>>>> is)?

Honestly, I'm not sure about that.

ARM is little-endian by default, like x86 or AMD64 (or, going back
further,
the 6502 :-) ). Unlike those two, it can be kicked into big-endian mode >>>> if
you need it, though I don't know of anything that uses that mode. The >>>> different flavors of Linux available for the Raspberry Pi are all
little-endian.

Silly question: is there any fundamental advantage of LE over BE or
vice-versa, or is it a fairly arbitrary choice that once a given chip has >>> been designed, needs to be adhered for in perpetuity so any future CPU of >>> that type can run binaries compiled for an older version of the CPU.

Was there any reason that all CPUs designed after the very first one didn't >>> *all* adopt the same endian-ness as that first one?

Were any of the CPUs used in early domestic computers (eg Z80, 6809, 68000) >>> BE, or were the all LE like the 6502? Was SPARC in the minority in being BE?
What about CPUs in early mainframes - were they all the same byte-ordering? >>

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big endian as well.

PDP-11 and VAX were LE.

--
Tim

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

On 27/02/2022 13:55, TimS wrote:

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher <tnp@invalid.invalid>

I think - not sure - memory rusty - some of the minicomoputers were big
endian as well.

PDP-11 and VAX were LE.

There were a lot more minicomputer makers than DEC..

Prior to the development of LSI CPUs, in the ECL TTL and CMOS eras, you
could build a CPU and architecture any way you wanted.



--
Climate is what you expect but weather is what you get.
Mark Twain

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

On 27 Feb 2022 at 13:35:45 GMT, Martin Gregorie <martin@mydomain.invalid> wrote:

On Sat, 26 Feb 2022 22:04:22 +0000, NY wrote:

What about CPUs in early mainframes - were they all the same
byte-ordering?

Somebody else can speak for IBM, but I *think* they all used byte
addressing, little endian arithmetic and EBCDIC .

BE.

--
Tim

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

Hello The!

Sunday February 27 2022 13:32, you wrote to me:

On 26/02/2022 07:10, Vincent Coen wrote:

Running fstrim is a required process if you are running with a SSD
at least in two primary Linux based systems that have it as a boot
drive otherwise failing to do so will make the SSD run out of disk
space when the only fault is that it has not run Garbage collection
to clean up the unused clusters.

This seems to be a case of unadulterated wombat turds

- *nix ext2/3/4 type systems do not benefit from garbage collection
- SSDs do nor benefit from garbage collection as seek times are
essentially zero
- garbage collection has no effect on available disk space
- fstrim, whilst beneficial in theory, is probably redundant as SSD lifetimes in terms of write cycles already exceed that of spinning
rust. It is certainly *not* mandatory.

In short if you want to increase SSD lifetime from 20 years to 21
years, use FSTRIM. :-)

The purpose of the SSD garbage collection process for want of a better name is to find all clusters no longer in use and make them available in the - yes available lists/index.

Failure to do this process whether within the SSD's controller or by application s/w on the platform will result in no free clusters available to create, add, extend replace a file or file record.

A case in point my media system which uses a Samsung SSD was over loaded a year
or so ago when I loaded up around 1 Tb of video despite saving them on a HDD as
clearly the system was first saving all data to the boot (SSD) drive.

This process took up many time more than the total video content being transferred and the facility stopped because there was no more clusters available until I ran fstrim -av and left it some minutes. At which point I could continue with the load.

I have now changed the cron process to run it 2 times per day and before when ever I have a large video load up to do as a safeguard.

Windows does this process using it's own version of a similar process to fstrim
but thats as far as I know or can guess as I have never bothered to look closely into it.

I am sure you can research this in more detail than outlined above if required.

Using fstrim has absolutely nothing to do with extending the life of a SSD and possibly could decrease it slightly but it is a needed function unless the SSD controller does it automatically and for the SSD's designed for server use they
do so but you have to pay the extra cost for those devices - a lot more.
The cost increase is not justified for a desktop type system unless you need the faster write speeds they tend to have but the closest to which is a M.2 NVME or similar device set.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 27 Feb 2022 13:55:06 GMT
TimS <timstreater@greenbee.net> wrote:

On 27 Feb 2022 at 13:22:14 GMT, The Natural Philosopher
<tnp@invalid.invalid> wrote:

On 26/02/2022 22:16, TimS wrote:

On 26 Feb 2022 at 22:04:22 GMT, "NY" <me@privacy.invalid> wrote:

Were any of the CPUs used in early domestic computers (eg Z80, 6809,
68000) BE, or were the all LE like the 6502? Was SPARC in the
minority in being BE? What about CPUs in early mainframes - were they
all the same byte-ordering?

68000 is BE, and all IBM and similar mainframes are too.

I think - not sure - memory rusty - some of the minicomoputers were big endian as well.

PDP-11 and VAX were LE.

But the PDP-10 was BE as was early SPARC, MIPS could go either way.
A lot of the minis were based on 68K, MIPS or SPARC so yes there would
have been a number of big endian minis around - especially during the era
of samey unix boxes with a QIC tape on the front and bunch of serial ports
on the back.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

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

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to load when I
selected it in a AMD X64 system so yes I am reasonably confident that it's for
a Pi.

AMD is not ARM, so it wont work on a Pi

---druck

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

On Mon, 28 Feb 2022 09:58:43 +0000
druck <news@druck.org.uk> wrote:

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to load when I selected it in a AMD X64 system so yes I am reasonably confident that it's for a Pi.

AMD is not ARM, so it wont work on a Pi

Er Druck - he said it *didn't* work on an AMD so it probably is ARM.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/

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

Hello druck!

Monday February 28 2022 09:58, you wrote to me:

On 24/02/2022 14:39, Vincent Coen wrote:

Hello druck!

Thursday February 24 2022 20:08, you wrote to me:

> On 23/02/2022 10:50, Vincent Coen wrote:
>> So next again using the Pi O/S install software installed
Ubuntu
>> overwriting the SSD with Desktop 21.04? x64 and rebooted.

> Is that ARM 64 bit, or x86/64 ?
> You need the former.

Just had a look at the SD and it has 2 partitions and it failed to
load when I selected it in a AMD X64 system so yes I am reasonably
confident that it's for a Pi.

AMD is not ARM, so it wont work on a Pi

Yes I am more than aware of such hence the comment!

My Pi is using the 64 bit operational properties which is why I specified X64 and this is NOT exclusive to Intel, Amd, Zilog, IBM etc.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

First things to try when it's frozen:

- press Ctrl-Alt-F1 (and other F keys, see if you can get to a console where you can login)

- if not, can you ping it over the network? (if plugged into ethernet, your router should tell you the IP)

It's possible it's just the GUI that's crashed, rather than a hard
lockup.

This is good advice, on *any* Linux machine.

You can also try downclocking it via config.txt. Open config.txt on the first partition on the SD card/SSD (from another machine) and add:

arm_freq=600
gpu_freq=400

That will slow down the processor, perhaps enough to get in and run the script. You may need to play around with the numbers (in MHz) as I'm
just guessing and I don't know what's accepted.

I think those numbers would work. But, the more important issue is making the device useable.

Possibly worth checking your power supply - maybe Ubuntu takes more current?

I don't think this is possible. It shouldn't matter which OS is installed,
the CPU uses a certain maximum.

I am "assuming" here that 8Gb Ram is more than enough for it !

A good assumption. Lubuntu, or Xubuntu, can run fine with only 1 GB of RAM.
And older versions of Ubuntu (I don't like their version of Gnome) worked
just fine with 4 GB.

Another possible thing to try is this: https://ubuntu-mate.community/t/single-user-mode/5104
(I *think* Ubuntu on the Pi is using GRUB like other platforms - that 'e' keystroke is when you're in GRUB)

I wonder about this. Normally, on a Pi, the "shift" key is reserved on boot, for NOOBS or PINN. Perhaps, after that, this would work?

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello All!

So an update:

I gave up at least for the moment on the ubuntu distro and installed
using the same tool Bullseye X64 direct to the SSD M.2 device using a
usb3 plugged cable and booted it (all today) after I was wide awake.

Needless to say it is working fine for a Debian Pi distro but I do not like the
basic Gui interface and would like to use KDE or Gnome (if I have to),
how ever
there is not a procedure the install one of them without picking each element for say KDE and that would be a accident waiting to happen.

Why the devil don't they offer a change of gui system instead of the
very basic
one they use ?

PiOS specifically chose a UI that definitely works on *any* Pi. Can you blame them? However, it is still a Debian-based system. I don't see why you
couldn't 'sudo apt-get install' any other UI, like kde or gnome.

Yes, I know I am getting older but was hoping I am not that senile yet !

That remains to be proven! (o_-)

When I get a chance or have to shut the system down I will install the
SD card on the offchance the boot sequence will see the card and load
from it. Failing that I will disconnect the USB link and try it -
perhaps try that method first :)

I am confused. I was under the impression that your Pi was locking up *after* the boot process. Meaning, it has already started loading from your USB
device, and locked up while trying to load Ubuntu...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

I think every Pi 4 user looking to try things out needs at least two SD cards:

1. One card for "Raspberry Pi OS 32-bit (Bullseye) with desktop and recommended software".

2. One card for the other OS.

This is very good advice!

Always have one card with a working OS. Then, even if you totally destroy the other one, you'll still have some way of working with the Pi.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello All!

One thing I have noticed with the M.2 SSD is that when running
sudo fstrim -av it exits with the implied not finding a SSD so I have to guess that the WD M.2 SSD is not being treated as a SSD and that is a worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You
shouldn't have to use fstrim.

I may try contacting WD (assuning they have a tech support dept) and see if they can shed any light on this as PiHut does not seem to have that level of technical support in-house like wise Argon who do not respond
to emails.

I am using a Argon One M.2 case which includes a board to install a M.2 SSD in that is liked to the Pi via a USB bridge double plug.

That USB bridge is basically the same as any that would be used in any
external SSD device. I really think you're worrying about a non-issue. Concentrate on your first problem: getting the damned thing to boot!

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Running fstrim is a required process if you are running with a SSD at least in two primary Linux based systems that have it as a boot drive otherwise failing to do so will make the SSD run out of disk space when the only fault is that it
has not run Garbage collection to clean up the unused clusters.

No, sir! This was a problem, for certain, in the early days of SSDs. But, as I've mentioned, modern SSDs perform their own garbage collection!

Only drawback to using SSD's under *nix. Windows does it automatically some how but for *nix you have to specify fstrim to run once every 24 hours for lightly used systems and 12 hourly for heavier load systems -
it might need to be more often if using them in a busy server.

Please refer to my first comment.

Now I have had a quick look at the SD card in use and it has Ubuntu Desktop 21.10 so I will continue using Bullseye and give up on it.
There is a wee list of issues with the Pi in the release notes (for
21.10) but they do not mention these noticed issues.

Honestly, I don't see why you didn't just use PiOS from the start. You can install KDE, or Gnome, or even Cinnamon from there. Not to mention that PiOS and Ubuntu are *both* Debian-based. What exactly were you trying to achieve?

I will look in on the Debian website for their release notes for v11 and see what the procedure is to upgrade the distro to use KDE or failing
that Gnome, however that does not mean they will work with a Pi in a reasonable manner - suck it and see, I guess.

"sudo apt install kde-desktop"? Or maybe "sudo apt install gnome-desktop"?
I'm not certain that this would work, because the necessary packages may not
be on the official Pi repos. But, it's not hard to add ppa's...

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

On Mon, 28 Feb 2022 16:08:55 +1200,
nospam.Vincent.Coen@f1.n250.z2.fidonet.org (Vincent Coen) declaimed the following:

My Pi is using the 64 bit operational properties which is why I specified X64

To most of the readership, X## is an implicit reference to Intel (old iAPX nomenclature)/AMD processors.

https://docs.elementscompiler.com/Platforms/Cocoa/CpuArchitectures/
"""
x86_64 is the architecture of Intel's 64-bit CPUs, sometimes also simply referred to as x64. It is the architecture for all Intel Macs shipped
between 2005 and 2021.

arm64 is the architecture used by newer Macs built on Apple Silicon,
shipped in late 2020 and beyond.
"""

Generalized 64 bit would be a simple "64-bit". ARM specific would be, as
shown above, "arm64".

https://docs.microsoft.com/en-us/answers/questions/10614/what-is-the-difference-between-x64-and-arm64.html
https://www.quora.com/What-is-arm64-vs-x64

and this is NOT exclusive to Intel, Amd, Zilog, IBM etc.

So far the first three links from Google show the X-notation IS specific to Intel/AMD, and a different notation is used for ARM chips.
There are easily five more links making the same distinction (and one discussing the difference between ARM64 and AARCH64 -- mostly coming down
to which compiler back-end was used <G>).



--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/

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

Hello Shaun!

Monday February 28 2022 12:17, you wrote to me:

When I get a chance or have to shut the system down I will
install the SD card on the offchance the boot sequence will see
the card and load from it. Failing that I will disconnect the USB
link and try it - perhaps try that method first :)

I am confused. I was under the impression that your Pi was locking up *after* the boot process. Meaning, it has already started loading from
your USB device, and locked up while trying to load Ubuntu...

No, it locked up (no clock updating) after I loaded Terminal but looking yesterday it is just terminal that does nothing after loading - no keyed input,
cannot select anything from the menu bar etc.

I did a system update from the gui and after a minute where it shows the progress bar at around 2cm's worth it just - well shows no progress even after an hour with just occasional hit on the access light which is very hard to see - must be the smallest led available anywhere in the world :)
It really is a pin prick size which you can see at night with the room light off - just. Well it is made to a price - a low one :)


Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

No, it locked up (no clock updating) after I loaded Terminal but looking yesterday it is just terminal that does nothing after loading - no keyed input,
cannot select anything from the menu bar etc.

I did a system update from the gui and after a minute where it shows the progress bar at around 2cm's worth it just - well shows no progress even after an hour with just occasional hit on the access light which is very hard to see - must be the smallest led available anywhere in the world :) It really is a pin prick size which you can see at night with the room light off - just. Well it is made to a price - a low one :)

Hahaha! I feel you, there! (^_^)

But, you might need to blame your Argon enclosure for that. The bog-standard Pi4 enclosure doesn't interfere with the LEDs.

As others have mentioned, you should try to SSH (or VNC) into your Pi, and
make sure it's actually stalled, rather than just not responding to desktop.

To be clear, I've never tried to install Ubuntu on a Pi. I know a bit about Ubuntu, and a bit about the Pi, but I've never tried to combine the two.

I'm very interested in this, because I want to buy the Argon enclosure for my own Pi4. I am certain that your problem has nothing to do with Argon, though.
I think your problem is with Ubuntu, or at least with Ubuntu on a Pi.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) writes:

One thing I have noticed with the M.2 SSD is that when running
sudo fstrim -av it exits with the implied not finding a SSD so I have to
guess that the WD M.2 SSD is not being treated as a SSD and that is a
worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You shouldn't have to use fstrim.

It’s more complicated than that. A physical page can be marked garbage
when the corresponding logical page is overwritten. But a logical page
that a filesystem stops using without overwriting (e.g. when deleting a
file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard
option supply the missing information.

Whether it’s worthwhile probably depends on access patterns.

--
https://www.greenend.org.uk/rjk/

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

On Mon, 28 Feb 2022 23:07:26 +0000, Richard Kettlewell wrote:

nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) writes:

One thing I have noticed with the M.2 SSD is that when running sudo
fstrim -av it exits with the implied not finding a SSD so I have to
guess that the WD M.2 SSD is not being treated as a SSD and that is a
worry if there is no garbage collection taking place.

To be clear, any modern SSD performs its own garbage collection. You
shouldn't have to use fstrim.

It’s more complicated than that. A physical page can be marked garbage
when the corresponding logical page is overwritten. But a logical page
that a filesystem stops using without overwriting (e.g. when deleting a
file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard option supply the missing information.

Whether it’s worthwhile probably depends on access patterns.

logwatch reports are a big help here.

I have an old Lenovo R61i that was fitted with a 128 GB Sandisk SSD when
its original 120GB HDD died.

These days it mostly just runs protein folding software. Apart from that, there's a weekly rsync backup followed by a Fedora update, so this
workload is making what I'd call low use of the SSD. The weekly smartd
report shows that the SSD has been active 1-2 hours per week, confirming
low usage.

Yet the weekly fstrim run usually reports its added a little over 1GB of storage space to the free blocks list. To me that shows that the weekly
fstrim run is worthwhile, but running it more frequently is probably not
worth the effort of retiming the cron job to run it more frequently.

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

It’s more complicated than that. A physical page can be marked garbage when the corresponding logical page is overwritten. But a logical page that a filesystem stops using without overwriting (e.g. when deleting a file) still appears to be in use to the controller, at until such as
time as the filesystem uses it for something else. fstrim or the discard option supply the missing information.

You're correct, sir. It is definitely more complicated than my simplified explanation. Hence why I simplified it.

But you make a good point! I normally add 'discard' on any SSD in my fstab,
on a PC. So much so, that I didn't even think about that. I need to check my own Pi to see if I'm using that on its SSD...

Vincent, if you didn't know: /etc/fstab is where (Debian) Linux stores its
info about storage space. Literally, 'File System TABlature'. This applies to Ubuntu, and PiOS too. There's a whole bunch of stuff you should know before attempting to edit /etc/fstab though. One can easily brick a system with a
typo in that file.

However, none of this information will help get Ubuntu to work with a Pi...Richard...

(o_O)

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello Shaun!

Monday February 28 2022 19:28, you wrote to Richard Kettlewell:

But you make a good point! I normally add 'discard' on any SSD in my
fstab, on a PC. So much so, that I didn't even think about that. I
need to check my own Pi to see if I'm using that on its SSD...

Vincent, if you didn't know: /etc/fstab is where (Debian) Linux stores
its info about storage space. Literally, 'File System TABlature'. This applies to Ubuntu, and PiOS too. There's a whole bunch of stuff you
should know before attempting to edit /etc/fstab though. One can
easily brick a system with a typo in that file.

However, none of this information will help get Ubuntu to work with a Pi...Richard...

Can you provide the o/p from a cat /etc/fstab where you are using the discard sub command.

Thanks,


That said I have not found a reason why running sudo fstrim -av does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial branded versions that cause serious problems switched (having had advise from Linux users) to Samsung 850/950/960 series over the years.
These unlike Crucial use a fair better device controller that processes garbage
collections within the controller without requiring the system being idle for long periods. A totally better class of SSD.

That is not to say I have not had snags with them but always not running fstrim
often enough when there has been a lot of files being stored on them during the
day. Remember it is not just the initial storing of files but also any files that are updated where the current clusters are replaced with new one's and that of course includes coping data from one location to another. I was about to including moving them but technically that should not affect anything as
the file details are not changed only the location holding the file record although that does change one cluster.

I do know (but not why) that if I download a large number of files to a HDD mounted as /mnt/disk1 where the SSD is at / that for some reason the system stores the data on a SSD before moving it to the HDD.

That one has got me beat as to the reason why.
Needless to say running fstrim twice a day resolves the problem providing I keep below 1 Tb of loaded files at any one time.

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not result in the
expected display from the program unless it is just NOT finding the SSD so the question arises as to what is different with a SSD as a M.2 2280 mount ?

I should point out that I have been in IT since 1963 with M/F's, mini's, etc., and in micros since 1974/5 and building micro based systems since 1976 and with
Linux since 1997 (*nix systems the late 70's) or so since giving up on OS/2 when IBM did, having replaced it with Linux for running my server platforms that also run a BBS among other services 24/7.

My wife's and the various laptop devices around the house, I stick to Windows 10 and 11 but there again if they fail it is not difficult to fix one way or another, but I do not use in un-secure environments even when taking one on holiday / vacation etc to act as a back up system for my photography using large cameras althoug I might, just might check on my house system using a hotels wi-fi services having switched the laptop to very high security if not already so set up.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Again nothing here explains why running fstrim on the Pi does not result in the expected display from the program

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-trim

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

Can you provide the o/p from a cat /etc/fstab where you are using the discard sub command.

Thanks,

I'll send you the fstab from my laptop in netmail. It's running Linux Mint, another Debian-based OS. Give me a bit to get around to that...

That said I have not found a reason why running sudo fstrim -av does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial branded versions that cause serious problems switched (having had advise from Linux users) to Samsung 850/950/960 series over the years.
These unlike Crucial use a fair better device controller that processes garbage
collections within the controller without requiring the system being
idle for long periods. A totally better class of SSD.

Oh, I agree with you there! Samsung SSDs in general are better performers
that most of the competition. There's a reason they can get away with
charging a premium.

I do know (but not why) that if I download a large number of files to a HDD mounted as /mnt/disk1 where the SSD is at / that for some reason the system stores the data on a SSD before moving it to the HDD.

Sounds like your OS is cacheing the data before sending it to the HDD. I'm
not sure why it would do so by default, though. Perhaps through SWAP? Are you copying more data than would fit in RAM?

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not result in the
expected display from the program unless it is just NOT finding the SSD
so the question arises as to what is different with a SSD as a M.2 2280 mount ?

It could be that the Pi is mistaking it for a USB stick? After all, you're
not actually using SATA or PCI-Ex to connect.

I should point out that I have been in IT since 1963 [...]

I certainly haven't been working with computers for as long as you have.
Heck, even my dad would only have been...six? eight?...in '63! (^_^)

But I've been a 'computer guy' my entire life. I put my entire academic effort into learning anything I could about them. I even owned a 'boutique' computer shop for a while. I was never much for datacenter work, though.

McDoob
SysOp, PiBBS
pibbs.sytes.net

--- Mystic BBS v1.12 A46 2020/08/26 (Raspberry Pi/32)
* Origin: PiBBS (1:229/110)

Hello A!

Tuesday March 01 2022 18:36, you wrote to me:

Vincent Coen <nospam.Vincent.Coen@f1.n250.z2.fidonet.org> wrote:

Again nothing here explains why running fstrim on the Pi does not
result in the expected display from the program

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-t
rim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

Yes there are lines between these two.

I left a message about it on the website.

May be buying a Argon one M.2 case was a mistake but I could not work out what was needed with a geekworm solution case and SSD board wise.

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

Hello Shaun!

Tuesday March 01 2022 15:58, you wrote to me:

Can you provide the o/p from a cat /etc/fstab where you are using
the discard sub command.

Thanks,

I'll send you the fstab from my laptop in netmail. It's running Linux
Mint, another Debian-based OS. Give me a bit to get around to that...

That said I have not found a reason why running sudo fstrim -av
does not pick up that a SSD is present.

I have been using SSD's for some years and after trying Crucial
branded versions that cause serious problems switched (having had
advise from Linux users) to Samsung 850/950/960 series over the
years. These unlike Crucial use a fair better device controller
that processes garbage collections within the controller without
requiring the system being idle for long periods. A totally
better class of SSD.

Oh, I agree with you there! Samsung SSDs in general are better
performers that most of the competition. There's a reason they can get
away with charging a premium.

I do know (but not why) that if I download a large number of
files to a HDD mounted as /mnt/disk1 where the SSD is at / that
for some reason the system stores the data on a SSD before moving
it to the HDD.

Sounds like your OS is cacheing the data before sending it to the HDD.
I'm not sure why it would do so by default, though. Perhaps through
SWAP? Are you copying more data than would fit in RAM?

These are loaded via a large USB stick directly on the box.

Again nothing here explains why running fstrim on the Pi does not
result in the expected display from the program unless it is just
NOT finding the SSD so the question arises as to what is
different with a SSD as a M.2 2280 mount ?

It could be that the Pi is mistaking it for a USB stick? After all,
you're not actually using SATA or PCI-Ex to connect.

I should point out that I have been in IT since 1963 [...]

I certainly haven't been working with computers for as long as you
have. Heck, even my dad would only have been...six? eight?...in '63!
(^_^)

But I've been a 'computer guy' my entire life. I put my entire
academic effort into learning anything I could about them. I even
owned a 'boutique' computer shop for a while. I was never much for datacenter work, though.

From around 1976 I was running a company inporting and distributing micro Books, Magazines and software running on CPM, MPM, Cromix (*nix) for Cromemco's
and some hardware. This was mostly imported from the US which I feighted over by air after a cargo consolidation each month (normally) any ways around 1978 business man starting up a shop called The Byte Shop asked me to run it for him
and I agreed after he accepted that it would buy from my company products that I sold and distributed at a 40% discount assuming prompt payments and I would get a basic salary of around 5k but be on a 20% bonus for every item sold.

Good deal as it gave me around a 40% total commission on item I imported and sold in the shop and to give you a wee hint - We were opened Monday through Saturday but were so busy I never had the time to do the paper work in full.

So I would go in Sunday morning around 08:00 or so most often or not moving the
paper work etc into the shop desk to wrok on it all.
Wee I started to people knocking on the door to be let in so in the end I just opened up once I got a coffee. Now one of the products sold was a Commodore Pet and the first one was a one piece unit with screen and keyboard and during the week would sell at a guess around 100 or more.

Once I opened on a Sunday I sold anywhere from 50 to 100+ between opening time and 13:00 when I closed the door to do the paper work which was increased with the sales - OTher products was also sold during this time frame including magazines, books games etc.

I made more money in bonuses / commission etc that the rest of the week - it was slightly embarrassing - OK, only a little but after a year or so the owner wanted me to quit and as my company was getting busy i.e, turnover well over 1M
I left. Money want towards my commercial pilots licences and aircraft hire both
singles and twins etc with lots of change.

Within one year the Byte shop opened 3 - 4 outlets but with in 3 or so they all
folded and a few more years so did my company - too much competition for the bread and butter trade. Needless to say within a month of us shutting down
the competition folder - so I might have been able to continue but it was too late by then. I have cut a long story short here .

During all this time period I was still doing mainframe and micro programming and system design etc just to keep the wolf from the door and keep in current practice - bit like flying really but made up for it when it all closed down by
doing well over 500 hours per year - well over as was doing some 500+ hours just for my private flying let alone the flight instructing and commercial work
on a wide range of a/c from singles, twin, heavies with the occasional military
flight, etc.

I wonder now, how I found the time :)

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

On 01-03-2022 12:34, Vincent Coen wrote:

Tuesday March 01 2022 18:36, you wrote to me:

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enabled-trim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

I don't know what "first test" you're talking about. Those mounting
points look normal. Maybe this more recent version is easier to follow
for you: https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-on-raspberry-pi

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

Hello A!

Wednesday March 02 2022 07:32, you wrote to me:

On 01-03-2022 12:34, Vincent Coen wrote:

Tuesday March 01 2022 18:36, you wrote to me:

https://lemariva.com/blog/2020/08/raspberry-pi-4-ssd-booting-enable
d-trim

The first test failed as I only have via df :

/dev/root /
/dev/sda1 /boot

I don't know what "first test" you're talking about. Those mounting
points look normal. Maybe this more recent version is easier to follow
for you: https://www.jeffgeerling.com/blog/2020/enabling-trim-on-external-ssd-o n-raspberry-pi

Following that post and rebooting has fixed it, many thanks.
This was using a Argon one M.2 pi 4B case with a WD 240 GB SSD with a M.2 interface that is NON NVME but a M.2 Key B (Sata ?), so nowhere as fast as MVME.

I have NOT enabled a weekly auto run of fstrim and will run it as and when, as currently I only have the box running some times, but as I want to install :

gnucobol compiler
mbse Bulletin board system as a back up system running two special program/s that will mean it will be on 24/7 connected to the intenet via a firewall port forwarding link.

After that#s up and running I will do a weekly fstrim as file creation should be
fairly low allowing for system updates etc.

Thanks again for the help, that's one less problem to deal with.
Now to find out why I am getting 'can't find libraries' message when building the compiler..

Vincent

--- Mageia Linux v8 X64/Mbse v1.0.7.24/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)