[codyd51]

Hi everyone!

As a bit of a gag, I’ve made a graphical IRC Client that runs entirely in the UEFI preboot environment. It features completely overdone features such as TrueType fonts, a cursor, and GUI decorations.

I first started this project as I was getting a bit tired building a from-scratch GPS receiver, and wanted to make something relatively quick and lighthearted. As tends to happen, this took a fair bit longer than I anticipated at the outset!

A fair chunk of that time was spent on the visualisations in the post showing how scroll views are modelled and how they’re rendered to a static viewport. I really hope you enjoy them!

When I first began wanting to "stuff something in UEFI that really shouldn’t be in UEFI", my first instinct was a Twitter client. As it turns out, someone has already done a great job making this by using UEFI’s HTTP protocol! I therefore decided that whatever I made shouldn’t use HTTP at all, because that’s taken. I went with IRC since it sits on top of TCP and has the same social media feel that doesn’t belong anywhere near a preboot environment.

[johannes1234321]

> feel that doesn’t belong anywhere near a preboot environment.

Seems to be quite the right place for me. How else would I get help on boot issues?

[molticrystal]

It would be an interesting experience to dcc somebody RU [0], run it from ram, and guide that person through diagnostics.

[0] https://ruexe.blogspot.com/

[codyd51]

Ha! I take your point.

[1vuio0pswjnm7]

Looking forward to ditching these bloated operating systems with all this cruft I I do not need for something smaller and simpler: UEFI. Not to mention faster startup. Easier "embedded" development.

Of course I am joking. Sort of.

As a minimalist I do not need a GUI or a mouse. It seems UEFI already has more than I need.

Here is the Twitter client mentioned:

https://github.com/arata-nvm/mitnal

[tucnak]

Plan9 on LiteX FPGA arrangement from open source tooling is all the rage these days now that there's RV32 and RV64 compilers for it.

[myself248]

I would contend that software too large to cram into UEFI is all superfluous bloatware anyway. In my day, we had dual 360k floppies and that was plenty!

[knodi123]

Dual? Pffft.

[myself248]

One for the program, one for the data. It made storing the files easier. In a file cabinet, natch.

[hex4def6]

This is extremely cool!

I've had an idea percolating in my mind for a while: Would it be possible to have VPN credentials stored in UEFI, and have a system reach out to a server for PXE network boot?

It seems like it would be a neat way of (securely?) allowing a remote system to automatically recover in the event of a nuked install that prevents proper bootup.

[contingencies]

Actually, all it takes on modern hardware for PXE boot to occur on hardware failure is the BIOS boot order setting.

As PXE inherently trusts the LAN, and a LAN may have VLAN support, you can assign a default VLAN to the port which equates to the PXE server you want.

The PXE server can further configure by client MAC prefix, DHCP-assigned IP mapped to physical port number or similar. Configured systems can report status and/or other hardware identifiers to a server after installation and have default VLAN changed by the network fabric (more secure), or can actively request to join alternate VLANs (less secure).

With PXE, any information can be fed to the machine, not just VPN credentials.

This is how a lot of clusters are built, especially diskless (for CPU-bound operations) in this era of more-RAM-than-you-can-use.

All of the above should work with IPMI ports if the controller is flashed with PXE-enabled firmware.

[nucleardog]

Well shit, glad I stumbled on this comment. Thanks for posting.

Biggest gripe with my home lab setup is managing when something does or doesn’t PXE boot.

Plug anything in and PXE boot it and it wipes the drive, does a scripted Debian install chained to an Ansible playbook that eventually installs k3s, discovers the rest of the cluster, and joins itself to it. So 0-click and 10 minutes from plug in to node in the cluster. If anything breaks, just PXE boot it and wait 10 minutes and it’s back. If anything needs updating, just PXE boot it and wait 10 minutes and it’s back.

Except… these are a bunch of tiny PCs on a high shelf in my utility room. Selecting the boot order is a _project_.

Never even thought about handling this from the network end. Either swapping the untagged VLAN on the switch or setting DHCP options per MAC address would let me handle this without getting up from my desk.

[kbenson]

> Except… these are a bunch of tiny PCs on a high shelf in my utility room. Selecting the boot order is a _project_.

Every once in a while I look for a cheap remote KVM I can use as a crappy IPMI stand in, either with RJ45 or WiFi. I haven't looked in a year or so, but at the time the options I found all seemed far more costly than I would have hoped (the pi based ones seemed interesting but once you add the requirements together it wasn't cheap enough to be attractive to me for a home use). Server class equipment with built-in IPMI is quite a bit more expensive. I just want something affordable to put in front of a NUC to make dealing with it easier in some instances. You could stick some refurbished old KVM device in front of it to support multiple systems on that one KVM as long as they were in close proximity.

Seems like you could benefit from that as well (but in your case you might get a workable solution out of switch config though).

[toast0]

Per mac dhcp probably works. Also, per mac pxe config... I have pxe for general use that is just a menu, but for my test machine autoboots my hobby os.

[ahepp]

I believe if you are on a UEFI system, “systemctl reboot” has some flags to let you select boot options.

[Jhsto]

Not OP, but what is much simpler is buying a motherboard with IPMI and placing that behind a VPN. If you cannot afford the couple hundred extra bucks for the motherboard, then a USB stick with minimal Linux setup + SSH and then doing a kexec from that is another option.

[E39M5S62]

https://docs.zfsbootmenu.org/en/v2.3.x/general/tailscale.htm... . Connect to your bootloader via your Tailscale network, select your ZFS boot environment and kexec in to it, all through a 'pretty' TUI !

[Ecoste]

I wanna know more about the from scratch GPS receiver

[codyd51]

I am really glad to hear that there's interest, and hopefully I will have a 3-part series to share on this some time soon! Similar to Andrew's project linked down below, this is a 'true' home-brew receiver. I didn't know anything about DSP, etc, when I started out, so I learned a lot about signal processing (and the incredible techniques that make GPS work), and really hope I'll be able to publish it all soon!

[Terr_]

Not OP, but in the meantime this may help alleviate your thirst for "how could someone do GPS from scratch", especially the end parts about radio signals and encoding: https://ciechanow.ski/gps/

[thatcherc]

This is my favorite write up of someone truly building a GPS receiver from scratch: http://www.aholme.co.uk/GPS/Main.htm

A real tour de force of DSP - really cool stuff, and well-written

[codyd51]

Andrew Holme's receiver was a crucial resource in my journey! There were times when a sentence or two from his post unlocked an insight for me.

[CamperBob2]

Nice presentation!

[anthk]

Gopher it's easy, and you can read gopher://hngopher.com and gopher://magical.fish as starting points.

[backspace_]

This does not include ssl support? How much does this limit the number of irc nets that you can connect to?

[ijijijjij]

I never seen an IRC server that only support SSL.... I don't use many networks nowadays though... I only know of one channel that supports encrypted DCC transfers though.

[Biganon]

Many channels have a flag to only accept users connected through SSL

[backspace_]

Link-net comes to mind

[_8j50]

If this supports TLS, I would use it all the time.

[nxobject]

I mean, UEFI apps don't just have to be preboot environments – not with that attitude, at least!

[pred_]

FYI: The site keeps crashing the tab in Firefox 115.7.0esr.

[b112]

You should report it to Mozilla, nothing a site does should ever crash a browser.

(Also, it could be an extension)

[o11c]

With the possible exception of "consumes a lot of memory, leading to the OoM killer being invoked".

[gkbrk]

No, even excessive memory usage should be prevented by the browser. If any page can crash a tab/browser it's a browser bug.