Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taming Servers for Fun and Profit

blog.railway.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Taming Servers for Fun and Profit

#11

Post by Imustaskforhelp »

Nextgrid wrote: post #9
Imustaskforhelp wrote: post #7

Earlier quoted context omitted.

Probably because it isn't memory efficient ? I am not sure , please take what I am saying is with a grain of salt. I may be wrong , I usually am. But even if that's the case , couldn't they use something like vram if they are running out of memory of are we back to square one?

I mean yes, you are sacrificing some RAM. But a typical Linux OS to run VMs/containers could fit in a couple gigs. For the amount of RAM these servers have, this is peanuts and would save a lot of headaches dealing with statefulness.

Could this be an issue that ram can cause issues where a server can shut down and it would lose it causing data backup issues

Re: Taming Servers for Fun and Profit

#12

Post by orev »

Nextgrid wrote: post #3

Out of interest, why not just PXE boot prebuilt images (buildroot/etc) that run from memory as your OS? That would save you the hassle of maintaining a stateful server, installing an OS, ensuring configuration is up to date, etc.

As a general rule, a statement that starts with “why don’t you just…” typically leans far too heavily on the “just” to handwave away the reasons why the next part of the statement isn’t going to be helpful.

In this case, you’re assuming a huge number of things like infrastructure and other requirements are in place, and all of those things take a lot of time and work, if they’re even appropriate at all.

Re: Taming Servers for Fun and Profit

#13

Post by cadamsdotcom »

Great writeup even though the dots aren’t connected between a lot of the aspects presented. Didn’t know about udev exposing consistent device names for network interfaces for example, or the efforts to open source switch software, or how easy it’s become to run intra-datacenter BGP. Thanks for all the links!

And of course the brilliant use of AI and discussion of how cost-effective it is. “Hook it up to an AI to save money” is the world we can look forward to. In this case the problem is recognizing which state a thing is in from a list of known states. Once the LLM gives the state in text form, all kinds of automation are unlocked. I think that class of problem - converting a state based on an image into text form - is wildly common, and will be on the lookout for it in my own automation work!

Re: Taming Servers for Fun and Profit

#14

Post by bananapub »

Imustaskforhelp wrote: post #11
Nextgrid wrote: post #9

Earlier quoted context omitted.

I mean yes, you are sacrificing some RAM. But a typical Linux OS to run VMs/containers could fit in a couple gigs. For the amount of RAM these servers have, this is peanuts and would save a lot of headaches dealing with statefulness.

Could this be an issue that ram can cause issues where a server can shut down and it would lose it causing data backup issues

no

Re: Taming Servers for Fun and Profit

#15

Post by Imustaskforhelp »

bananapub wrote: post #14
Imustaskforhelp wrote: post #11

Earlier quoted context omitted.

Could this be an issue that ram can cause issues where a server can shut down and it would lose it causing data backup issues

no

then I don't understand the issue ! this seems really great imo.

Re: Taming Servers for Fun and Profit

#16

Post by chatmasta »

ordersofmag wrote: post #4
bovermyer wrote: post #2

Using Claude to parse screen-scrapes of a server's boot status is certainly novel. I did not expect a mention of AI usage in an article like this. With that said, I wonder why they used AI at all here. Could they not have keyed off certain keywords or other information present in a screen scrape, rather than rely on Claude to parse it?

The article says "...we can obtain a near real-time image of the server screen". Implying that what they have is an image file, not text. Getting keywords out of an image file would normally take an OCR step. A single API call to Claude does the trick without the extra tooling.

I asked ChatGPT to make text from a photo of a whiteboard and it just executed some Pytesseract code…

I’m reminded of the guy who setup an iPhone farm to use the iOS on-device OCR because he couldn’t find anything better.

Re: Taming Servers for Fun and Profit

#17

Post by ca508 »

Nextgrid wrote: post #8
bovermyer wrote: post #2

Using Claude to parse screen-scrapes of a server's boot status is certainly novel. I did not expect a mention of AI usage in an article like this. With that said, I wonder why they used AI at all here. Could they not have keyed off certain keywords or other information present in a screen scrape, rather than rely on Claude to parse it?

I wonder how much of this is just to get a talking point about AI in the article (and I guess it works - we're talking about it). If you literally need to just detect whether it's at the firmware splash screen or not, simply checking if enough pixels on the image are white would detect that splash screen just fine.

author here; Claude use here was pure laziness - and personally, I found it quite funny that it worked. We could sample pixels and try and build that detection, but $Maybe it needs to have more complex logic/detection and we need something more complex down the road. But it's like easy and cheap OCR for now.

what was kinda funnier was that I tried to get Claude to generate its own Go client code to upload the image and run the prompt; it totally totally hallucinated on that part :).

Re: Taming Servers for Fun and Profit

#18

Post by ca508 »

Nextgrid wrote: post #9
Imustaskforhelp wrote: post #7

Earlier quoted context omitted.

Probably because it isn't memory efficient ? I am not sure , please take what I am saying is with a grain of salt. I may be wrong , I usually am. But even if that's the case , couldn't they use something like vram if they are running out of memory of are we back to square one?

I mean yes, you are sacrificing some RAM. But a typical Linux OS to run VMs/containers could fit in a couple gigs. For the amount of RAM these servers have, this is peanuts and would save a lot of headaches dealing with statefulness.

Author here; RAM is so much more expensive than disk though. Two 500G M.2 NVMes for a RootFS in RAID1 are basically max ~$150 which is I think much cheaper than a single 64G DDR5 ECC RAM module [I don't have exact numbers on me, but ECC RAM is pricey]. It's also a lot harder to debug when things go wrong because you lose the machines state if everything was ephemeral.

We run a thin base OS on the boxes and then VMs on top which we consider more ephemeral. The frequency of needing to update that base OS is v. low.

I think there's a case for building a custom PXE booted RAMdisk image to replace the install though; something like what Equinix Metal (formerly Packet) do with Tinkerbell (https://github.com/tinkerbell); they call it an OS Install Environment, but the idea is a small lightweight linux install agent that can DD a golden image onto the disk (vs. an install each time).

Re: Taming Servers for Fun and Profit

#19

Post by ca508 »

cadamsdotcom wrote: post #13

Great writeup even though the dots aren’t connected between a lot of the aspects presented. Didn’t know about udev exposing consistent device names for network interfaces for example, or the efforts to open source switch software, or how easy it’s become to run intra-datacenter BGP. Thanks for all the links! And of course the brilliant use of AI and discussion of how cost-effective it is. “Hook it up to an AI to save…

> the dots aren’t connected between a lot of the aspects presented

that's on me (author); I tried to cut the content down to a manageable post size that covered some interesting stuff - but probably dropped the connective tissue in the process. We'll keep this in mind for next time.

Re: Taming Servers for Fun and Profit

#20

Post by Nextgrid »

ca508 wrote: post #18
Nextgrid wrote: post #9

Earlier quoted context omitted.

I mean yes, you are sacrificing some RAM. But a typical Linux OS to run VMs/containers could fit in a couple gigs. For the amount of RAM these servers have, this is peanuts and would save a lot of headaches dealing with statefulness.

Author here; RAM is so much more expensive than disk though. Two 500G M.2 NVMes for a RootFS in RAID1 are basically max ~$150 which is I think much cheaper than a single 64G DDR5 ECC RAM module [I don't have exact numbers on me, but ECC RAM is pricey]. It's also a lot harder to debug when things go wrong because you lose the machines state if everything was ephemeral. We run a thin base OS on the boxes and then VMs o…

Are you guys still hiring? Would be keen to have a chat about this and see if anything comes out. Sent one of you guys a LinkedIn invite but no response yet.
Post reply on HN