Live data from Hacker News

An IRC client in your motherboard

axleos.com

51–60 of 78 posts

Re: An IRC client in your motherboard

#51
> 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.

Re: An IRC client in your motherboard

#52

Earlier quoted context omitted.

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.

Link-net comes to mind

Re: An IRC client in your motherboard

#54

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

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.

Re: An IRC client in your motherboard

#55
> “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).

Re: An IRC client in your motherboard

#56

Earlier quoted context omitted.

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!

Dual? Pffft.

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

Re: An IRC client in your motherboard

#59
post #14
post #7

Earlier quoted context omitted.

I wanna know more about the from scratch GPS receiver

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/

Nice presentation!

Re: An IRC client in your motherboard

#60

Earlier quoted context omitted.

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.

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 stat…

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.

Post reply on HN