An IRC client in your motherboard(axleos.com)
axleos.com
An IRC client in your motherboard
https://axleos.com/an-irc-client-in-your-motherboard/
77 comments
> 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?
Seems to be quite the right place for me. How else would I get help on boot issues?
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/
[0] https://ruexe.blogspot.com/
Ha! I take your point.
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
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
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.
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.
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.
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.
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.
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.
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.
> 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).
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).
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.
I believe if you are on a UEFI system, “systemctl reboot” has some flags to let you select boot options.
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.
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 !
I wanna know more about the from scratch GPS receiver
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!
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/
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
A real tour de force of DSP - really cool stuff, and well-written
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.
Nice presentation!
[deleted]
Gopher it's easy, and you can read gopher://hngopher.com and gopher://magical.fish as starting points.
This does not include ssl support? How much does this limit the number of irc nets that you can connect to?
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.
Many channels have a flag to only accept users connected through SSL
Link-net comes to mind
If this supports TLS, I would use it all the time.
I mean, UEFI apps don't just have to be preboot environments – not with that attitude, at least!
FYI: The site keeps crashing the tab in Firefox 115.7.0esr.
You should report it to Mozilla, nothing a site does should ever crash a browser.
(Also, it could be an extension)
(Also, it could be an extension)
I love this!
I think it also emphasizes the complexity and capability of software that underlies the systems most people think about. I think it is a common misconception that your OS is the "lowest level" of the software stack, but in actuality, there is this firmware-ish code that truly owns your system. Sometimes it does a job and goes away, other times stays running the whole time your system is up, transparent even to the OS.
Sometimes, the attitude people have about this is along the lines of... "who cares, its just low level code to get my devices running, nothing serious can happen down there".
But knowing that you can get a whole IRC client down there doesn't make it too hard to imagine all the other nefarious things that could go on.
I think it also emphasizes the complexity and capability of software that underlies the systems most people think about. I think it is a common misconception that your OS is the "lowest level" of the software stack, but in actuality, there is this firmware-ish code that truly owns your system. Sometimes it does a job and goes away, other times stays running the whole time your system is up, transparent even to the OS.
Sometimes, the attitude people have about this is along the lines of... "who cares, its just low level code to get my devices running, nothing serious can happen down there".
But knowing that you can get a whole IRC client down there doesn't make it too hard to imagine all the other nefarious things that could go on.
> “Why”? What kind of question is “why”?
This is the spirit I come to HN for. Thank you for sharing.
> The most frightening realization hit me: there wasn't any reason behind what I'd done. I mean, I knew why I'd done it - I just did it because it would be fun. But I knew they would ask, "Why the hell did you do this?" and if I didn't have a good enough reason, they would probably throw me into a mental institution." -- Boyd Rice
This is the spirit I come to HN for. Thank you for sharing.
> The most frightening realization hit me: there wasn't any reason behind what I'd done. I mean, I knew why I'd done it - I just did it because it would be fun. But I knew they would ask, "Why the hell did you do this?" and if I didn't have a good enough reason, they would probably throw me into a mental institution." -- Boyd Rice
> I told a friend I was making a joke project, then explained it. She said she wasn’t sure when to laugh. I’m not so sure either.
Don't sell yourself short. There's a botnet C&C client project here!
OK the UI is a bit funny. :)
Don't sell yourself short. There's a botnet C&C client project here!
OK the UI is a bit funny. :)
This is super cool. Had no idea UEFI APIs were so readily-available and well-documented. Awesome work! Out of curiosity, what was the dev cycle like? I assume you were running the thing in a VM. Did you have to "boot up" every time you wanted to run the client?
Thanks very much!
The other commenter is correct that the work loop typically revolved around booting a QEMU instance which ships my UEFI application. The main run script will regenerate an EFI filesystem that contains a fresh build of UEFIRC, then pass it to QEMU.
However, the overhead here can get a bit cumbersome when trying to build a GUI. I set things up such that the app could target either bare-bones UEFI, or a hosted environment that runs on my Mac. By flipping a build flag, my GUI toolkit would either draw directly to the UEFI-provided framebuffer, or would hook into my Mac's windowing system and receive/push events to that. You can see some of the overhead of this 'dual-target' approach in the app's entry point: https://github.com/codyd51/uefirc/blob/main/src/main.rs.
Parsing IRC messages also really doesn't need any accoutrements, so I developed those with a unit test suite running directly on my Mac - you can see part of that here: https://github.com/codyd51/uefirc/blob/main/src/irc/response....
The other commenter is correct that the work loop typically revolved around booting a QEMU instance which ships my UEFI application. The main run script will regenerate an EFI filesystem that contains a fresh build of UEFIRC, then pass it to QEMU.
However, the overhead here can get a bit cumbersome when trying to build a GUI. I set things up such that the app could target either bare-bones UEFI, or a hosted environment that runs on my Mac. By flipping a build flag, my GUI toolkit would either draw directly to the UEFI-provided framebuffer, or would hook into my Mac's windowing system and receive/push events to that. You can see some of the overhead of this 'dual-target' approach in the app's entry point: https://github.com/codyd51/uefirc/blob/main/src/main.rs.
Parsing IRC messages also really doesn't need any accoutrements, so I developed those with a unit test suite running directly on my Mac - you can see part of that here: https://github.com/codyd51/uefirc/blob/main/src/irc/response....
QEMU can run UEFI apps
Nice! I would like to someday finish writing an OS for my IRC bot that is still running.
Maybe the most useless comment but: that non-linear mouse movement (aka acceleration) is the very first thing I turn off when I boot up a new OS. It literally hurts my hand somehow. For example linearmouse is free for Mac. For Windows you can just turn off acceleration. For Linux its easy, obviously.
Using mouse acceleration stops you from learning to map a distance traveled by the mouse to a distance on the screen. I do think its more efficient in the long run without it. Something I learned to do from gamers, and something I think all gamers still do for a good reason.
Maybe the most useless comment but: that non-linear mouse movement (aka acceleration) is the very first thing I turn off when I boot up a new OS. It literally hurts my hand somehow. For example linearmouse is free for Mac. For Windows you can just turn off acceleration. For Linux its easy, obviously.
Using mouse acceleration stops you from learning to map a distance traveled by the mouse to a distance on the screen. I do think its more efficient in the long run without it. Something I learned to do from gamers, and something I think all gamers still do for a good reason.
I don’t change any mouse settings, so I’m not sure what the default is, but I can still accurately click parts of my screen that are covered.
I think you’d get a feel for it either way. Like how the throttle pedal in your car (probably) doesn’t map to a speed.
I think you’d get a feel for it either way. Like how the throttle pedal in your car (probably) doesn’t map to a speed.
My main gripe with nonlinear mouse movenement is that it breaks learned behaviour if you do it faster. This is why most gamers use raw linear mouse data.
> “Why”? What kind of question is “why”?
Because low-level applications like this were promised when UEFI was introduced, that's why. UEFI's creators went even as far as to dream of replacing the Linux-based Internet-only mini-OSes of some vendors which could be accessed by pressing a certain key during boot (though I don't remember what they were called).
Because low-level applications like this were promised when UEFI was introduced, that's why. UEFI's creators went even as far as to dream of replacing the Linux-based Internet-only mini-OSes of some vendors which could be accessed by pressing a certain key during boot (though I don't remember what they were called).
Those were the quick view / quick boot festures that old Dell and the likes had. Usually booting into some bars ones productivity apps.
I did see a video on YT that did a deep dive into this. I beleive you are correct they were originally stripped down Linux or other custom OSes but then eventually switching to UEFI apps before falling okay of favor.
I did see a video on YT that did a deep dive into this. I beleive you are correct they were originally stripped down Linux or other custom OSes but then eventually switching to UEFI apps before falling okay of favor.
I think this might be the video you're talking about, in case anyone is also interested in a brief history of quick boot operating systems and UEFI: https://www.youtube.com/watch?v=ssob-7sGVWs
Nice writeup! This reminds me of the barebox bootloader April fools two years back, which will connect you to #barebox, when all other boot targets fail[1]. :-)
The focus there was on adding TCP support to barebox though and it lacks your nice GUI elements. Only interface was CLI (which can be drawn on top of EFI GOP when barebox is built as EFI payload).
[1]: https://lore.barebox.org/barebox/20220401145902.GF4351@telli...
The focus there was on adding TCP support to barebox though and it lacks your nice GUI elements. Only interface was CLI (which can be drawn on top of EFI GOP when barebox is built as EFI payload).
[1]: https://lore.barebox.org/barebox/20220401145902.GF4351@telli...
This instantly made me think of a recent video by the Cathode Ray Dude, talking about HP's 'email client' (read: Outlook Plugin) "QuickLook" which was a shipped product implemented this way: https://www.youtube.com/watch?v=ssob-7sGVWs (also goes into some even weirder stuff they did).
This does the hard bit of networking that QuickLook skipped though.
This does the hard bit of networking that QuickLook skipped though.
Amazing visualizations in the article, very impressive.
Thank you very much, I've spent a lot of time on them over the past week and am really pleased to hear that you enjoyed them!
I was really impressed when I clicked the reload button -- inspiring attention to detail!
How did you create those?
Wow, thank you so much! I made these using HTML canvases and TypeScript. I’m drawing everything in code, including the pixel art (which is defined in the source).
The animations are made using a small animation system that I made for this post. This system has two useful properties:
1. It allows me to animate whatever property of the object I’m interested in (alpha, frame, etc).
2. It allows me to set up other work to be triggered when the animation has reached a certain completion threshold, which lets the animations flow into each other. This is how (for example) the grid lines ‘cascade’ in after each other.
The 3D animations are also primarily HTML canvases, and I used Three.js to place them as textures in a 3D scene. I have some logic to map the coordinate system of the canvases to the 3D scene, so that I can draw the connective tissue between the canvases and run animations that operate on objects both on the 2D canvases and the 3D scene.
The animations are made using a small animation system that I made for this post. This system has two useful properties:
1. It allows me to animate whatever property of the object I’m interested in (alpha, frame, etc).
2. It allows me to set up other work to be triggered when the animation has reached a certain completion threshold, which lets the animations flow into each other. This is how (for example) the grid lines ‘cascade’ in after each other.
The 3D animations are also primarily HTML canvases, and I used Three.js to place them as textures in a 3D scene. I have some logic to map the coordinate system of the canvases to the 3D scene, so that I can draw the connective tissue between the canvases and run animations that operate on objects both on the 2D canvases and the 3D scene.
I can't but think about some music related applications that would benefit from a bare metal environment that boots very quickly and doesn't contain unnecessary bloat, for example a synthesizer (just like MiniDexed for the Raspberry Pi, but not limited to FM), and a effect processor that interfaces with an external pedal board, for guitars, bass etc. Both would require also support for audio cards, although most recent mainboards certainly have decent converters.
I don't know whether to think this is awesome, or a horrifying demonstration of bloat in UEFI.
I don't think this really demonstrates UEFI bloat. A tcp/ip stack from boot services is handy and useful for 'legitimate' network booting, not really bloat IMHO; pxe and undi is similar in a bios environment but ddoesn't necessarily come from the motherboard firmware. Access to input devices, such as keyboard and mouse is reasonable too. Graphical output seems reasonable too.
And then everything else is stuff the author did or linked in. Where's the firmeware bloat?
And then everything else is stuff the author did or linked in. Where's the firmeware bloat?
Sit back and relax. Make this project more popular. People will decide for themselves.
You are right and it is already going your way, even if you are not seeing it yet.
You are right and it is already going your way, even if you are not seeing it yet.
As always, the relevant xkcd: https://xkcd.com/1782/
I understand that BIOS had limitations but I still think that UEFI is way too much.
I understand that BIOS had limitations but I still think that UEFI is way too much.
> Each time we draw a bit of graphical content to a scroll view, we first allocate the tiles necessary to display the corresponding visual area.
I get the intent here, to avoid the issue of not knowing how large a buffer to allocate for your scroll view in the first place. But doesn't this still use way too much memory? Especially for something like an irc client, the scroll view will only grow as the program is used longer, and as such the number of tiles of rendered content will also only grow. You'll of course need to keep the textual history in memory, but that's far smaller than the rendered screen contents.
Proper GUI toolkits (disclaimer: I have worked with few, and only a little at that) handle this, I think, by not considering the scroll view a canvas to draw stuff on, but instead a thing that you can place widgets on. Each widget has access to some data that allows it to re-draw its graphical content at some position on-screen, and the scroll view forgets rendered content far outside the visible area, and asks widgets to re-draw their content whenever they get scrolled onto the screen again.
Of course, you could expect requests for even more over-engineering ;)
Cool stuff! As someone else mentioned, you missed April 1st.
I get the intent here, to avoid the issue of not knowing how large a buffer to allocate for your scroll view in the first place. But doesn't this still use way too much memory? Especially for something like an irc client, the scroll view will only grow as the program is used longer, and as such the number of tiles of rendered content will also only grow. You'll of course need to keep the textual history in memory, but that's far smaller than the rendered screen contents.
Proper GUI toolkits (disclaimer: I have worked with few, and only a little at that) handle this, I think, by not considering the scroll view a canvas to draw stuff on, but instead a thing that you can place widgets on. Each widget has access to some data that allows it to re-draw its graphical content at some position on-screen, and the scroll view forgets rendered content far outside the visible area, and asks widgets to re-draw their content whenever they get scrolled onto the screen again.
Of course, you could expect requests for even more over-engineering ;)
Cool stuff! As someone else mentioned, you missed April 1st.
Yes, you're absolutely correct! The design here totally suffers from unbounded memory use if you draw onto a large canvas. (Restating parts of your comment for confirmation that this is also how I think about it.)
To resolve this while maintaining the spirit of the design, I think two representations need to be kept: one for the rendered pixel data, and one 'out of band' representation (such as the textual data - you also highlighted this in your comment).
The idea is that, when the pixel buffer memory gets too large, some of it can be dropped. When it scrolls back into view again, it can be repopulated by the secondary representation. What I don't like about this is how it doesn't feel like it generalises well - you always need to be able to store the secondary representation, and have code to redraw it.
I think the concept you suggested is a really good one: just make sure everything that's drawn is its own 'encapsulated' widget with its own drawing logic, and you can ask it to render itself whenever that's convenient. I'm grateful for the input here, and think I will end up switching to this sort of approach in the future.
To resolve this while maintaining the spirit of the design, I think two representations need to be kept: one for the rendered pixel data, and one 'out of band' representation (such as the textual data - you also highlighted this in your comment).
The idea is that, when the pixel buffer memory gets too large, some of it can be dropped. When it scrolls back into view again, it can be repopulated by the secondary representation. What I don't like about this is how it doesn't feel like it generalises well - you always need to be able to store the secondary representation, and have code to redraw it.
I think the concept you suggested is a really good one: just make sure everything that's drawn is its own 'encapsulated' widget with its own drawing logic, and you can ask it to render itself whenever that's convenient. I'm grateful for the input here, and think I will end up switching to this sort of approach in the future.
I'm not sure "correct" engineering really fits UEFIRC, somehow :p
But if it's fun, go ahead! Perhaps it's helpful for axle too. :)
But if it's fun, go ahead! Perhaps it's helpful for axle too. :)
This is Awesome. Next up is Doom on the motherboard? Or has someone already done it lol.
This would be even better if it were a chat interface to ChatGPT so you could ask it troubleshooting questions next time your machine won't boot into OS.
I think we'll soon see a ChatGPT embedded in UEFI, and it will be solving boot issues on its own.
Considering there're ChatGPT IRC bots, can already do that indirectly.
But not on a pre-booted system!
I recall contributing to IRC client that was running inside a SoftICE debugger... but this is another level ;)
UEFI is basically protected-mode 32/64-bit DOS.
Makes me miss KillerNIC
Now do a gopher client and head to gopher://hngopher.com
Lol, this is great. You missed your chance to release it on 4/1 though.
bad ideas are bad. even if one can do them
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.