zorlack

There's a lot of nonsense at every level. Especially when dealing with heterogenous infrastructure.

Some NICs support http. Some NICs support tftp. Some NICs have enough memory for a big iPXE, other NICs don't. Some BMC systems make next-boot-to-lan easy, but not all.

We almost always use iPXE in order to normalize our pxe environment before OS kickstart. There's a lot to it and quite a lot of little things that can go wrong. Oh, and every bit of it becomes critical infra.

The fun thing about learning to boot from PXE, is that you have to learn it every time you onboard a new type of hardware... or a new VM hypervisor... or new NIC firmware... or new BIOS firmware.

God help you if you actually want to install an operating system.

PXE is such a vital capability for working with on-prem servers. But it's ten different things which all have to play nicely together. Every time I build a PXE system I feel like I'm reinventing the universe in my tiny subnet.

That's a great catch! thank you!

You're certainly right that statically linked binary is the most optimal expression of this goal. Especially for use in a secure environment.

Alas, this is just a python tool :)

Yes, I used LLMs to develop this. I think the README has more emojis than any mortal could summon. Hehe

I used ChatGPT to design the solution that I wanted and Claude Sonnet to do most of the coding.

I'm trying to figure out what works for me in the brave new world of AI enabled development, so that I can make recommendations to my team.

A few things that really helped me here were:

- Having the gitlab cli (glab) installed and configured was very helpful because it allowed me to do things like lint the CI file and inspect the build output in the LLM context.

- Having the zereight/gitlab-mcp installed was useful as well. Even though I can make Issues and MRs using the CLI, the LLM frequently made escaping mistakes when writing long comment sections. The mcp tool was great for this.

- Almost all of my process started with me describing a bug or feature, then asking the LLM to investigate the feature and create an Issue. From there I tried as much as possible to keep the scope of my work small and exclusively tied to an issue branch.

I'm a reasonably good programmer - I've been at it for 30 years. I think there's no question that LLMs expand my "radius of capability." Just like everyone else, I'm trying to figure out the best way to safely maximize this new world of tools.

Thank you for reporting this!

Would you mind telling me what environment you found this behavior in, and how you installed the app?

I've been testing in ubuntu containers doing:

    pip3 install service-ping-sping --break-system-packages

Thank you so much!!

*EDIT:*

I think this is to do with me not being specific about what version of typer I depend upon... working on it now!

This is now fixed in 0.2.11. Thanks @johnQdeveloper

This booster is the record holder.

I'm sure they expect that a long-lasting reusable rocket will eventually fail.

SpaceX must be eager to study the wreckage to see where to improve their reconditioning process.

Lol. Probably because it's actually confusing.

I love all of the oddball projects being spun out by Rancher/Suse. It can be hard to keep track of them.

Oh wait this one is kubernetes distro, and that one's an OS and this thing... well it's a... err... binary container something-or-other?

My team does quite a bit of this. We handle it in two different ways:

For some clusters we carve nodes out of VMWare simply using OS templates. For other nodes we we use cheap-and-deep blade servers and install the OS on bare-metal using PXE. Once the nodes are provisioned we use ansible to deploy Kubernetes. (Lately it's been RKE2 on top of Rocky.)

Generally speaking VM-based nodes are extremely reliable and seldom have to be rebuilt. (If we're paying to run VMWare its because the underlying hardware is high-quality.) Bare-metal nodes, on the other hand, are built on inexpensive hardware and they tend to fail in different ways. When they fail we cordon and remove them from the cluster and put them in a list. (We maintain sufficient overcapacity to soak failures as they come.)

If we're using persistence we have to take care that the statefulsets are configured correctly. Sometimes we use local-disk persistence so that our services can benefit from local NVME performance. Other times we use NFS (when we need persistence but not performance.)

We monitor cluster node health internally to Kubernetes and also externally using Nagios (shudder).

Kubernetes upgrades are a pain in the ass. Lots of times we'll just set up a second cluster to avoid the risk of a failure during an upgrade.

I hope the advertising revenue is meaningful, because boy does it detract from the user experience.

So if this power line will carry 1250MW. And elsewhere Hacker News tells me that it takes 200J to restart a heart.

Math... math... math... wolframalpha... calc.exe... math

I think this can restart 6.25M hearts per second.

(Please don't try this)

Edit: The defib duty cycle is probably closer to 100ms. So you could probably do 10 times this number, especially since you don't need a charge capacitor.

> I still hear people talk about stuff that’s happening in the news

Well phew! Thankfully someone's still paying attention.

ULA: What if we're already falling behind in the orbital laser race?

> To trigger the vulnerable code path, an application on the target must be bound to a raw socket.

What is a "raw socket" in this context?

It'd be so interesting to collect aCropalypse-affected images. Maybe you could build a crop-suggester out of it...

Not that I'd want to maintain custody of such a dataset...

[] Make sure to place Mr. Epstein's gun in the table drawer. (P11)

OP should run their route backwards for a week. To see if the effect is symmetrical.

Sunsets are gradual...

Or to just dither the hell out of your image.

Luminance sensitivity information could probably be most-easily detected in the dark areas of an image. So just crush those areas.

I suspect the more you think about this problem the more the answer becomes: Compress your image in order to remove information density.

Still, a determined adversary might find this information discernable over a long enough series of images.

...and also leads would-be anonymous image-posters to increase the noise-floor of their photographs.

(web2)(web3) = (web5)

(web)(2)(web)(3) = (web)(5)

[SNIP]

(web) = (5/6)

Nailed it.

Er.. Or web = 0.

Hmm.

You could put the braking resistors above ground, no?

Or if the braking resistors have to be close the the coils, then you could use a heat-exchanger to move the heat somewhere else...

I can't decide if this is an educational blog post or veiled legal threat.

Kind of seems like the later.

If I'm shopping for a new car I expect it to have lane-keeping and adaptive-cruise-control and a host of other safety features which require sensors.

That said, I'd still drive an old beater. It's just that when I shell out for a new thing, it's because I want the new features.

"The sun warms my back this morning" -> "This morning, the sun will shine on my house again."

"Back" somehow became shelter?