cogman10 (u/cogman10)

cogman10 commented on Kids Rarely Read Whole Books Anymore. Even in English Class nytimes.com/2025/12/12/us... · Posted by u/signa11

gambiting · 13 hours ago

>>It's print. With upper and lowercase letters.

So like.......not linking the letters together then? Doesn't that just actually take more effort than just writing cursive? And is slower?

>>But of course this is HN where most people are technical.

For sure, and as a professional programmer I keep a notebook with hand written notes - the fact that I have a keyboard and multiple monitors in front of me doesn't change the fact that hand writing is still the best(for me) way to save and recall information.

cogman10 · 12 hours ago

> not linking the letters together then?

Correct.

> Doesn't that just actually take more effort than just writing cursive? And is slower?

Probably yes to both counts.

However, when I'm handwriting I'm generally not in a position where speed or effort is the most important thing. To me, it's not much more effort to print and I get the added bonus of legibility. When I write cursive, it can be hard for me to understand what I wrote when I come back to it. I'm just a little too sloppy. It would take effort for me to get to the point where my cursive is neat and I frankly just don't handwrite enough to warrant that effort.

Consider this, do you use shorthand? I'd assume not. But why not? It's the fastest way to write anything. Cursive, by comparison, is both a lot of effort to write, is slower, and it wastes space.

I'd say for (some of) the same reasons you likely don't write shorthand, I don't write in cursive.

cogman10 commented on Kids Rarely Read Whole Books Anymore. Even in English Class nytimes.com/2025/12/12/us... · Posted by u/signa11

gambiting · 13 hours ago

>>Why would you write in cursive?

I'm confused. How do you write if not in cursive? Do you just write in block capitals? With each letter on its own? Do you just not hand write anymore?

>>Cursive is an outdated skill for when it was the fastest way to get words written to paper.

But....It still is? Without using some kind of machine of course.

cogman10 · 13 hours ago

> Do you just write in block capitals?

Block capitals? no. It's print. With upper and lowercase letters.

I rarely handwrite now. The last time I really did was in college.

> But....It still is? Without using some kind of machine of course.

But of course this is HN where most people are technical. We all have some sort of machine at our disposal otherwise we'd not be writing back and forth to one another.

cogman10 commented on Security issues with electronic invoices invoice.secvuln.info/... · Posted by u/todsacerdoti

boston_clone · 13 hours ago

this is just one instance of a vulnerability associated with unzipping; a curious search would yield more.

cogman10 · 13 hours ago

A curious search reveals that vulnerabilities that do exist are of 2 flavors.

1. Standard C memory vulnerabilities

2. Unsafe file traversal while unzipping

The entire second class is avoided in a fixed file format. The first class of vulnerabilities plague everything. A quick look at libxml2 CVEs shows that.

cogman10 commented on Building small Docker images faster sgt.hootr.club/blog/docke... · Posted by u/steinuil

maccard · 17 hours ago

Thanks - this is an interesting idea I had never considered. I do like the layer based caching of dockerfiles, which you give up entirely for this but it allows for things like running containerised builds cached SCM checkouts (our repository is 300GB…)

cogman10 · 15 hours ago

Yeah, it's basically tradeoffs all around.

The benefit of this approach is it's a lot easier to make sure dependencies end up on the build node so you aren't redownloading and caching the same dependency for multiple artifacts. But then you don't get to take advantage of docker build caching to speed up things when something doesn't change.

That's the part about docker I don't love. I get why it's this way, but I wish there was a better way to have it reuse files between images. The best you can do is a cache mount. But that can run into size issues as time goes on which is annoying.

cogman10 commented on Show HN: I audited 500 K8s pods. Java wastes ~48% RAM, Go ~18% github.com/WozzHQ/wozz... · Posted by u/wozzio

wozzio · 17 hours ago

The JVM expands to fill the container, but the scheduler still counts that 8GB request as used when packing the node. Even if the app only needs 2GB of working set, we are blocked from scheduling other pods on that wasted 6GB buffer.

cogman10 · 15 hours ago

No, it doesn't. Believe me, I'm an expert this.

The JVM determines the maximum allocation it will take at startup. It will not grow beyond what that determination is. Effectively it sets the `XMX` setting once whether explicitly or implicitly from various memory settings.

The JVM, without explicit configuration, is also reluctant to give back memory to the OS. Most of the collectors will keep whatever memory they have requested.

And now that you've posted 8GB and 2GB, that pretty much confirms to me that you are both running older JVMs and using the default settings. For older JVMs the default was to take 25% of the available memory without further configuration.

Here's an article describing exactly this problem [1].

Your devs likely ran into OOME problems in production and merely increased their pod request. Cutting it down to "save" memory is a bad move, you need to do that in tandom with having the devs correctly set the JVM settings in their container. Otherwise, you reducing it to 2gb will cause the app to run with 512MB max heap size (almost certainly causing problems).

You may have seen a pod exceed that 2GB. That is simply because there are a lot of situations where the JVM can do "off heap" allocations, application dependent. The 2GB max is for the heap and not all the off heap allocations.

For Java, off heap allocations are somewhat rare. But you should know about them just so you don't set the JVM heap to 100% the pod memory. You need to leave a buffer big enough to accommodate those off heap scenarios (including garbage collections). For smaller heaps (<1gb) 60% is probably a good target. For larger heaps (10+gb) 80 or even 90% is a pretty good target.

[1] https://www.baeldung.com/java-docker-jvm-heap-size

cogman10 commented on Show HN: I audited 500 K8s pods. Java wastes ~48% RAM, Go ~18% github.com/WozzHQ/wozz... · Posted by u/wozzio

karolinepauls · 18 hours ago

> Python: ~60% waste (Mostly sized for startup spikes, then idles empty).

I understand we're talking about CPU in case of Python and memory for Java and Go. While anxious overprovisioning of memory is understandable, doing the same for CPU probably means lack of understanding of the difference between CPU limits and CPU requests.

Since I've been out of DevOps for a few years, is there ever a reason not to give each container the ability to spike up to 100% of 1 core? Scheduling of mass container startup should be a solved problem by now.

cogman10 · 18 hours ago

I don't think there is. You should set both and limit doesn't need to match request for CPU.

Your limit should roughly be "what should this application use if it goes full bore" and your request should be "what does this use at steady state".

At least at my company, the cluster barely uses any CPU even during the busiest hours. We are fairly over provisioned there because a lot of devs are keeping limit and request the same.

cogman10 commented on Analysis finds anytime electricity from solar available as battery costs plummet pv-magazine-usa.com/2025/... · Posted by u/Matrixik

nomel · 18 hours ago

No, it's a bad fit. it would be pure marketing. Lipo slowly destroy themselves when charged. Lead acid slowly destroy themselves when not charged.

cogman10 · 18 hours ago

There are different LIPO chemistries. LFP in particular has little problem with being fully charged. You'll see it get swapped in for lead acid chemistries even in places like car/motorcycle batteries.

If you want an Lithium power supply then the keyword to look for is "LFP".

cogman10 commented on Show HN: I audited 500 K8s pods. Java wastes ~48% RAM, Go ~18% github.com/WozzHQ/wozz... · Posted by u/wozzio

wozzio · a day ago

I've been consulting on EKS/GKE cost optimization for a few mid-sized companies and kept seeing the same pattern: massive over-provisioning of memory just to be safe.

I wrote a simple CLI tool (bash wrapper around kubectl) to automate diffing kubectl top metrics against the declared requests in the deployment YAML.

I ran it across ~500 pods in production. The "waste" (allocated vs. used) average by language was interesting:

Python: ~60% waste (Mostly sized for startup spikes, then idles empty).

Java: ~48% waste (Devs seem terrified to give the JVM less than 4Gi).

Go: ~18% waste.

The tool is called Wozz. It runs locally, installs no agents, and just uses your current kubecontext to find the gap between what you pay for (Requests) and what you use (Usage).

It's open source. Feedback welcome.

(Note: The install is curl | bash for convenience, but the script is readable if you want to audit it first).

cogman10 · 18 hours ago

Actually, this sounds like your java devs have misconfigured containers.

Java will happily eat all the memory you throw at it. The fact that it isn't means they are probably relying on the default JVM settings. Those are too conservative inside a container, especially if they are running on older JVM versions.

What you'll find is the JVM will constantly have "waste" due to it's default configuration. The question is if it ends up throwing out of memory exceptions due to the lower memory limit.

If your devs haven't looked at the heap allocation of a running application, there's no way to know if this is too much or too little memory.

Go/python much more readily give memory back to the OS.

cogman10 commented on Security issues with electronic invoices invoice.secvuln.info/... · Posted by u/todsacerdoti

boston_clone · a day ago

hello,

https://nvd.nist.gov/vuln/detail/CVE-2025-11001

cogman10 · 21 hours ago

Right, so long as step 1 in reading your file isn't "extract everything" you're pretty safe.

This specific exploit is one that only exists when you are extracting a zip on windows.

cogman10 commented on Building small Docker images faster sgt.hootr.club/blog/docke... · Posted by u/steinuil

maccard · 2 days ago

I’m inclined to agree with you about not building containers. That said, I find myself going around in circles. We have an app that uses a specific toolchain version, how do we install that version on a build machine without requiring an SRE ticket to update our toolchain?

Containers nicely solve this problem. Then your builds get a little slow, so you want to cache things. Now your docker file looks like this. You want to run some tests - now it’s even more complicated. How do you debug those tests? How do those tests communicate with external systems (database/redis). Eventually you end up back at “let’s just containerise the packaging”.

cogman10 · a day ago

You can mount the current directory into docker and run an image of your tool.

Here's an example of that from the docker maven.

`docker run -it --rm --name my-maven-project -v "$(pwd)":/usr/src/mymaven -w /usr/src/mymaven maven:3.3-jdk-8 mvn clean install`

You can get as fancy as you like with things like your `.m2` directory, this just gives you the basics of how you'd do that.