Please wait...
After decades of using source code control systems, I have finally learned the proper way to format a commit message.
Duuurrrrrrrrr....
You should see some of my commit messages.
Tue Dec 27 2022 22:23:06 EST from IGnatius T FoobarLOOK AT ME, I'M SO SMART AND STUFF
After decades of using source code control systems, I have finally learned the proper way to format a commit message.
Duuurrrrrrrrr....
well this is weird.
Sending mail via python, nothing new. But as of last night, if i send to my own domain the send from field is bank in my mailbox. If i send to my office or gmail account it shows.
If anyone is interested, Leo Brodie is going to be on zoom this weekend speaking with my FORTH user group.
FORTH is still used in a tiny program called loader. Part of the FreeBSD Project, loader is responsible for booting the FreeBSD kernel. Loader has kept up with the times, it has a UEFI binary and moar recently, it got Lua support. Loader still knows FORTH, tho.
Mon Mar 13 2023 12:42:25 EDT from IGnatius T FoobarI'm more interested in knowing where and why FORTH is still a thing. Something in the embedded systems world?
Yes, its still there, honoring its roots. Aside from what our resident cat just said: while its not a thing now. all MacBooks for years had it .. it was part of OpenBoot.
Being around back when Charles first gave it to the world back when it was really just meant to run his Observatory, its amazing to see it running as a web server/IDE on a ESP32..
Mon Mar 13 2023 12:42:25 PM EDT from IGnatius T FoobarI'm more interested in knowing where and why FORTH is still a thing. Something in the embedded systems world?
FreeBSD Project, loader is responsible for booting the FreeBSD
kernel. Loader has kept up with the times, it has a UEFI binary and
I wonder how much longer we will have bootloaders. It seems like it would be a much better idea to just make the kernel a UEFI binary and let it boot on its own.
Apparently this can be done, but no one is publishing a finished operating system that uses it?
That would be added complexity. There are a multitude of LOADER binaries for FreeBSD, and for each kernel version. LOADER is intentionally kept smol.
LOADER must work for: UEFI, BIOS/MBR, PXE, EFIPXE (NetEFI is handled by this one), OpenBoot (for those pesky POWER machines). Some of these boot methods have rather small maximum payload sizes. LOADER must also be able to handle booting from either UFS2 or ZFS, and the PXE builds also need to support both TFTP and NFS.
That's quite a lot for just one binary to handle, especially when the maximum size for some of these boot methods is a measly 64K. So, there are multiple builds of LOADER for all the various use cases.
Tue Mar 14 2023 21:56:58 EDT from IGnatius T FoobarFreeBSD Project, loader is responsible for booting the FreeBSD
kernel. Loader has kept up with the times, it has a UEFI binary and
I wonder how much longer we will have bootloaders. It seems like it would be a much better idea to just make the kernel a UEFI binary and let it boot on its own.
Apparently this can be done, but no one is publishing a finished operating system that uses it?
I wonder how much longer we will have bootloaders. It seems like it
would be a much better idea to just make the kernel a UEFI binary and
let it boot on its own.
Call me crazy, but I like conventional bootloaders that allow you to do crazy things, such as unpack live media to a hard drive filesystem and then edit simple text files in the bootloader configuration to accomplish different effects.
I know you can replicate it with some UEFI monstruosity, but it is not going to be as easy and convenient.
A lot of PCs are are already legacy-free (meaning either: no CSM support in the UEFI, or limited CSM support such as the lack of a video BIOS when running in CSM mode)
This caused a bit of confusion when I built my dad's current PC. I was migrating his Windows installation without doing a reinstall, which is a two-step process: first bring it up in BIOS mode, then use a Microsoft commandline tool to convert the installation to UEFI.
No video from the integrated graphics. System boots into windows but you can't *see* anything.
Solution was to temporarily install the discrete graphics card from the old PC, until the UEFI conversion was complete.
I should just get a FPGA board, emulate an old 8086 and run free dos and say to the hell with fancy modern stuff.
Dig out my copy of framework III that i paid way too much for, desqview x ... something to play music and video with,,
Dig out my copy of framework III that i paid way too much for,
desqview x ... something to play music and video with,,
Last time I installed FreeDOS, I was absolutely blown away by the amount of relatively modern code and capabilities that people have developerd for DOS. You can almost live in that environment, even today.
Some 25 years ago it saved my ass.
Microsoft pulled licensing on us for DOS "move to NT, shut up" and we had some machine controllers in the past that required DOS and could not run windows, of any kind, They were basically used like embedded devices and needed low level control of the hardware, not something a "DOS emulator" would work with ( i tried ). What ran was fine of course, but if a drive died, we were f-ed. Ran across FDoS, it was not perfect at the time but it was close enough to run our app and keep the machine going. I even had the company donate $.
Call me crazy, but I like conventional bootloaders that allow you to
do crazy things, such as unpack live media to a hard drive filesystem
and then edit simple text files in the bootloader configuration to
accomplish different effects.
That basically *is* UEFI.
Anyone who remembers the old days of 32-bit operating systems will recognize the similarities. If you wanted to start up something like Netware, or a pre-NT version of Windows, you booted into DOS first. Maybe you even booted Linux that way, if your system had LOADLIN instead of LILO. You might have had a little DOS partition that contained your 32-bit kernel compiled as an executable, and it contained everything you needed to get the kernel running, using only features supplied by the system ROMs.
UEFI is quite simply a more modern version of that. It's a very small operating system, built into the system ROM (and any extension ROMs supplied by hardware), whose only purpose is to organize and coordinate the booting of a general-purpose operating system. You can sit around at the UEFI prompt and play around all day with it.
Traditional bootloaders exist because IBM made a decision 42 years ago to simply start executing whatever was on the very first sector of the boot media.
UEFI eliminates the need for that, because the boot process mounts the EFI boot partition, reads it for configuration and instructions, and follows an organized boot process from there. And yet, most operating systems throw away that functionality and simply run a UEFI program that chain-loads a legacy bootloader.
We can do better, and we should.
And it looks like we might be getting there slowly. I don't know about Windows or BSD -- and I would assume Apple is already there -- but Linux kernels can now be compiled with something called "EFISTUB" which turns the kernel into an EFI executable. Debian kernels on x86 have apparently been compiled with this option since Wheezy. [ https://wiki.debian.org/EFIStub ] I may have to try this, especially if it can be done in a way that will survive a kernel update.
I would like to get rid of GRUB. I don't like GRUB and I don't like the people who wrote its documentation.
FreeBSD's LOADER is used with UEFI systems, using the UEFI build of LOADER. It does some extra stuff that a UEFI system can't do, like load kernel modules into the FreeBSD kernel before booting it. UEFI does provide some advantages - LOADER uses UEFI's raw access mode to read the filesystem FreeBSD is installed on, and since UEFI binaries can be quite large - it supports both UFS2 and ZFS, plus it's a single binary. Back in the days before UEFI, LOADER was split up into 4 stages. That was annoying.