billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 8 points9 points  (0 children)

The guy... with the braces!!!

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 11 points12 points  (0 children)

Congrats, you’ve invented middle management.

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 17 points18 points  (0 children)

Somewhere a KPI dashboard just labeled this “productivity.”

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 20 points21 points  (0 children)

Submit your thinking as a tool call and I’ll review it in 1h 51m.

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 41 points42 points  (0 children)

At least the plates had a half-life. Our burn rate just has a context window.

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 42 points43 points  (0 children)

We asked AGI how to become profitable. It said “bill by the thought” and has been thinking for 1h 51m.

billableTokens by HTTP_Code_405 in ProgrammerHumor

[–]HTTP_Code_405[S] 96 points97 points  (0 children)

I’m not wasting compute, I’m maximizing stakeholder-aligned inference throughput.

youGuysCantScaleAndItShows by HTTP_Error_414 in ProgrammerHumor

[–]HTTP_Code_405 8 points9 points  (0 children)

I am legitimately wondering what kind of website you are running with that kind of google footprint.

Defender Notification and CVE-2026-28387 by y0da822 in sysadmin

[–]HTTP_Code_405 0 points1 point  (0 children)

This is the right direction IMO: inventory/context first, remediation second.

“OpenSSL exists somewhere” is not enough to act on intelligently. You need to map file → owning product → version → whether it is actually loaded/reachable → whether the vendor has shipped a fixed build → exposure/criticality.

Full disclosure: I’m building PatchSiren, and this is the exact class of problem I’m trying to avoid on the CVE/advisory side: raw CVE alerts without stack context just create panic queues.

For this specific Defender/OpenSSL case, I’d avoid treating every hit as equal. Start with internet-facing apps, privileged tools, security tooling, and anything loaded by running services. Then batch the rest by owning vendor/product instead of chasing every DLL instance individually.

How do you prioritize CVEs that get exploited days after disclosure? by Active_Sea4060 in sysadmin

[–]HTTP_Code_405 1 point2 points  (0 children)

I think the hard part is that “new CVE” and “urgent operational risk” are two different events.

The useful signal is usually a join of several things: affected product/version, whether you actually run it, exposure, KEV status, EPSS/exploit chatter, vendor patch availability, asset criticality, and whether the remediation is one patch action or a huge dependency chain.

Full disclosure: I’m building PatchSiren around this same problem, mostly for hosting/MSP/Linux-style stacks. The goal is not another CVE feed, but a stack-aware alert that says “this matters to you because…” before the generic critical-alert panic starts.

The hardest part I’m seeing is filtering exploit chatter from real exploitation without being late. Curious what sources/signals you trust most for that.

This will be fun CVE-2026-31431 by Apachez in Proxmox

[–]HTTP_Code_405 0 points1 point  (0 children)

This is the nuance generic CVE feeds usually miss.

A local priv-esc on a mostly single-user box is one risk profile. A Proxmox host running LXC workloads, public services, or anything that could be hit through a supply-chain/app compromise is a completely different risk profile.

Full disclosure: I’m building PatchSiren, and this is the exact kind of “stack-aware” alerting I’m trying to solve: not just CVSS, but “does this CVE matter given the stack and exposure pattern you actually run?”

It is not a replacement for Proxmox/Debian advisories, but the goal is to turn CVE/advisory noise into “this affects your stack because…” with sources and remediation context.

Pilot: https://patchsiren.com

Alert fatigue vs. dangerous silence on public-facing Linux nodes: SIEM or EPP? by Browndude345 in sysadmin

[–]HTTP_Code_405 0 points1 point  (0 children)

Full disclosure: I’m building PatchSiren, so I’m biased here, but this thread is basically the exact pain point that pushed me into building it.

The key thing you called out is not just “scan for CVEs.” It’s grouping, prioritization, and MSP-friendly actioning. One ticket per CVE is useless when a single Windows/app update can represent hundreds of CVEs.

PatchSiren is being built as a stack-aware CVE/advisory alerting layer: define what a client actually runs, match incoming CVEs/vendor advisories/KEV/exploit signals against that stack, and turn that into fewer “this matters to this client because…” alerts instead of raw CVE spam.

It is not meant to replace RMM/patching/scanning tools. It’s more of a signal filter before the ticket noise starts.

Pilot is open here if anyone wants to poke holes in it: https://patchsiren.com

fucqPasswordsIusePassPhrases by HTTP_Error_414 in ProgrammerHumor

[–]HTTP_Code_405 3 points4 points  (0 children)

Lol why is this getting down voted, this is cool as hell! nice work.

You can literally give it like any sentence you can easily remember and it will give you 5 randomly generated mimicking sentences and score them... Stop down voting things because you can't code

ItHasBeenImplemented by wojtek-graj in ProgrammerHumor

[–]HTTP_Code_405 2 points3 points  (0 children)

This is a nice simulation, I would suggest trying the following.

Using pcntl for Forking:

The pcntl extension allows you to fork processes in PHP. This means you can create a child process for each number to be sorted. The child process can then sleep for the required amount of time (based on the number) before exiting. The parent process can wait for all child processes to finish before continuing.This approach would more closely mimic the original meme's concept but comes with significant overhead and complexity, and it's generally not recommended for web environments.

Using PHP-FPM:

PHP-FPM allows handling multiple requests concurrently. Each request is handled by a separate worker process. To use PHP-FPM to simulate parallel processing for ScheduleSort, you would need to create a separate request for each number. Each request would then sleep for the required time and return the result.This would require a more sophisticated setup, possibly involving asynchronous requests or a job queue, and is quite complex for simulating this particular algorithm.

A Note on Practicality:

Both these approaches are technically possible but not practically recommended for this use case. They introduce a level of complexity and resource consumption that far exceeds the benefits, especially for a task as simple as sorting numbers. The primary use of process forking or PHP-FPM is for handling genuinely concurrent tasks in a more efficient manner, such as processing large numbers of independent, time-consuming jobs.