On 15/06/2024 20:35, Dale wrote:

I'm not opposed to efi.  I remember when the old Grub reached its end of life. Grub2 is different but it works.  I don't use the eye candy part
so that makes it even easier.  The biggest thing, I copy my kernels and
such over manually and I keep a couple older ones that I want to be available.  I also plan to install memtest, a rescue image or two and
those need to be available as well.  I may still use Grub, I may not.
Right now, I'm clueless.  I'm just trying to follow the docs which given
all the options available are confusing to follow.

At the end of the day, all these things are pretty much the same. Back
in the ancient days, you had a switch panel you toggled to put in the
boot code.

Then they put a basic interpreter in ROM.

Then they got rid of basic and put code in that said "here's a bit of
disk controller code, go to chs(0,0,0), read one block and execute it".

Now UEFI is just a bit more fancy code that says "here's a gpt table
reader, a vFAT driver, and a mini program that looks in any FAT
partition it can find for an EFI directory, and runs whatever it finds
in there".

So the principle hasn't changed, but the detail has.

And of course, all the rules get bent by the various manufacturers. Bear
in mind that basic EFI predates vFAT so even in UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's nothing stopping GNU's
OpenBIOS project or whatever it is using ext4. But vFAT is the official
"lowest common denominator" which everything must support if it's not
"single vendor for hardware and software". Which is why, of course, MS
can't play fun and games - if they say Windows won't support vFAT
they'll get hammered for anti-trust.

More and more everything is turning into "System on a chip", and that
includes the bios! It has just enough of a driver now to read everything
it needs from the attached storage, and that's your modern UEFI.

Cheers,
Wol

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

On 2024-06-16, Wol wrote:

On 15/06/2024 20:35, Dale wrote:

I'm not opposed to efi.  I remember when the old Grub reached its
end of life. Grub2 is different but it works.  I don't use the eye
candy part so that makes it even easier.  The biggest thing, I copy
my kernels and such over manually and I keep a couple older ones
that I want to be available.  I also plan to install memtest, a
rescue image or two and those need to be available as well.  I may
still use Grub, I may not. Right now, I'm clueless.  I'm just
trying to follow the docs which given all the options available are
confusing to follow.

At the end of the day, all these things are pretty much the same. Back
in the ancient days, you had a switch panel you toggled to put in the
boot code.

Then they put a basic interpreter in ROM.

Then they got rid of basic and put code in that said "here's a bit of
disk controller code, go to chs(0,0,0), read one block and execute
it".

Now UEFI is just a bit more fancy code that says "here's a gpt table
reader, a vFAT driver, and a mini program that looks in any FAT
partition it can find for an EFI directory, and runs whatever it finds
in there".

I thought UEFI firmware as a replacement to PC BIOS tried to do more,
including handling video modes before loading the boot code.

So the principle hasn't changed, but the detail has.

And of course, all the rules get bent by the various
manufacturers. Bear in mind that basic EFI predates vFAT so even in
UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
nothing stopping GNU's OpenBIOS project or whatever it is using
ext4. But vFAT is the official "lowest common denominator" which
everything must support if it's not "single vendor for hardware and software". Which is why, of course, MS can't play fun and games - if
they say Windows won't support vFAT they'll get hammered for
anti-trust.

But there are systems using exFAT, right? You mean UEFI firmwares will
happily accept other filesystems?

I was under the impression (not having any UEFI computer here, so not
from personal experience, just from seeing instructions given to other
people a few times) that this was pretty much the usual "every
system wants the Microsoft FS", but made worse because instead of the commonplace and widely-supported FAT* it had to be exFAT.

(One might wonder why does it have to be a Microsoft filesystem at
all...)

Or is the problem that many UEFI bootloaders that are in the firmware
behave in a less than optimal way with implementation details and
unimplemented features?

More and more everything is turning into "System on a chip", and that includes the bios! It has just enough of a driver now to read
everything it needs from the attached storage, and that's your modern
UEFI.

--
Nuno Silva

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

On Sunday, 16 June 2024 20:39:52 BST Wol wrote:

... Back in the ancient days, you had a switch panel you toggled to put in the boot code.

I remember that. It was 1974. 24 key switches and lots of buttons. You set an address on the key switches and hit SET, then ditto its contents and STORE.
All set and ready, GO. That was a Ferranti Argus 500, like what was in the latest submarines, but these were for AGR power stations. 24-bit words, 16MB
of 2 microsecond core store, 2MB disks, ASTRAL assembler language. Full closed-loop reactor control.

They don't make them like that any more.

PS. Our gas-cooled reactors were intrinsically stable: rising temperature caused reduction of power, without any intervention. On the other hand, all water-cooled reactors are inherently unstable: rising temperature causes an increase of power. They have to be controlled by brute force.

PPS. Guess which I prefer.

--
Regards,
Peter.

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

On 16/06/2024 23:39, Nuno Silva wrote:

And of course, all the rules get bent by the various
manufacturers. Bear in mind that basic EFI predates vFAT so even in
UEFI vFAT isn't actually mandatory. Apple don't use it, iirc. There's
nothing stopping GNU's OpenBIOS project or whatever it is using
ext4. But vFAT is the official "lowest common denominator" which
everything must support if it's not "single vendor for hardware and
software". Which is why, of course, MS can't play fun and games - if
they say Windows won't support vFAT they'll get hammered for
anti-trust.

But there are systems using exFAT, right? You mean UEFI firmwares will happily accept other filesystems?

I don't know. But the formal specification of UEFI says it must accept
vFAT (I believe exFAT was not acceptable because Microsoft had patented
it). It does not say it can't accept other stuff. Which is why Apple
doesn't use vFAT.

And it explicitly states the version of vFAT. I don't know which
version, but it's along the lines of "version X dated Y", so that is
locked in stone.

So basically, the UEFI spec says it CAN accept multiple filesystems, but
it MUST accept vFAT if it wants the moniker "Universal". So unless (and probably even if) it's Apple hardware, it does support vFAT.

Cheers,
Wol

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

Hello, Peter.

On Sun, Jun 16, 2024 at 23:52:15 +0100, Peter Humphrey wrote:

On Sunday, 16 June 2024 20:39:52 BST Wol wrote:

... Back in the ancient days, you had a switch panel you toggled to put in the boot code.

I remember that. It was 1974. 24 key switches and lots of buttons. You set an address on the key switches and hit SET, then ditto its contents and STORE. All set and ready, GO. That was a Ferranti Argus 500, like what was in the latest submarines, but these were for AGR power stations. 24-bit words, 16MB of 2 microsecond core store, 2MB disks, ASTRAL assembler language. Full closed-loop reactor control.

They don't make them like that any more.

PS. Our gas-cooled reactors were intrinsically stable: rising temperature caused reduction of power, without any intervention. On the other hand, all water-cooled reactors are inherently unstable: rising temperature causes an increase of power. They have to be controlled by brute force.

PPS. Guess which I prefer.

Yes. There have been several serious accidents involving water cooled
reactors in the last few decades. None involving AGRs. At least, none
that have come to public attention.

Back in the late '70s, whilst still a student, I worked for a year at
the UKAEA Safety and Reliability Directorate in Culcheth (near Risley).
The topic which consumed most of my time was the modelling of the
aftermath of sodium fires in Fast Breeder Reactors. This was done via a differential equation package (whose name I forget) written in Fortran, controlled via a script which generated the input for it. All on ICL
2900 series mainframes. I seem to remember our 2980 had 8 MB of RAM,
and was shared between 30 - 40 simultaneous users. The response time
wasn't always what one might have desired, and neither was the
robustness of the operating system.

Sadly, the FBR never made it into commercial deployment.

--
Regards,
Peter.

--
Alan Mackenzie (Nuremberg, Germany).

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

On 17/06/2024 12:17, Alan Mackenzie wrote:

Sadly, the FBR never made it into commercial deployment.

Was that the one with the heavy water moderator? So a thermal runaway
was impossible because you'd have no moderator left?

Cheers,
Wol

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

Hello, Wol.

On Mon, Jun 17, 2024 at 13:39:35 +0100, Wols Lists wrote:

On 17/06/2024 12:17, Alan Mackenzie wrote:

Sadly, the FBR never made it into commercial deployment.

Was that the one with the heavy water moderator? So a thermal runaway
was impossible because you'd have no moderator left?

It was a long time ago, but as far as I remember, the physics is that
the plutonium reacts with fast unmoderated neutrons (hence "fast
reactor").

Anyway, we've kind of drifted off topic, here. Maybe we should stop
this discussion. ;-)

Cheers,
Wol

--
Alan Mackenzie (Nuremberg, Germany).

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

On Monday, 17 June 2024 13:39:35 BST Wols Lists wrote:

On 17/06/2024 12:17, Alan Mackenzie wrote:

Sadly, the FBR never made it into commercial deployment.

Was that the one with the heavy water moderator? So a thermal runaway
was impossible because you'd have no moderator left?

No, that was another design of water-cooled reactor with the same instability problem: it could have melted down long before the moderator was lost. I used to know the differences between reactor designs, but that was 40 or 50 years ago. Pressurised water reactor; boiling water reactor, ... I'm still convinced that the gas-cooled design is the best, and that's not just because we were
the first to market with it.

The fast breeder reactor at Dounreay used uranium and plutonium fuel (I think) and was cooled with liquid sodium - yes, really. It used the fast, Multi-MeV neutrons directly from the fission of uranium, not needing a moderator to bounce them around and cool them to thermal energies, 2KeV, as in all other uranium-fuelled reactors. The core was the size of a largish, red-hot dustbin and generated 120 MW. A quite astonishing power density. Frightening, too.
That will no doubt be why it was built at the most remote site in mainland Britain.

The breeding aspect is that it created thorium while it was operating, which could then be used as the fuel in other reactors. There's still a school of thought that thorium would make a much safer, more economical reactor.

I don't know why the FBR programme was cancelled; I thought it held great promise at the time, but perhaps the chemical challenges were too great:
liquid sodium flying around in steel pipes, and so on.

--
Regards,
Peter.

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