It has 3 HIGH RISK issues because

    - DNSSEC is not configured
    - Few cookies are send and (ALERT!) Google marketing cookie
    - Missing ROA

I get it, it's aggregator but showing red maps is at leals sensationalists

Seems that results are taken from internet.nl, which has WAY better UI than page posted.

https://batch.internet.nl/site/um.warszawa.pl/17768032/#

Make alias called sdo that echoes sudo path and hash every time you use it to stderr.

That's security by obscurity though.

Upon initial request I have you "URPAY1". If you never check URPAY1 for status, we'll callback you and expect the result. If neither check nor callback succeeded rollback actions are ran (this is contractual agreement on partnership level).

You can verify your status with URPAY1. You need to provide your status check with check ID (URPAY1) and an unique request ID. You will receive a timestamped response. You won't get different responses for same CheckID + RequestID because it's a activity log and also procedure check (e.g. grossly simplifying success at 23:59:58 might be something different than success at 00:00:05 - these times can vary depending on partner, continent, so it's not only midnight etc.) If at any point you didn't get response you can retry and you will always get the same response.

Didn't get URPAY1 for the first time? No problem try againt second time. You'll get the same URPAY1. No new effects needed.

In this design you, as requester are in full power. You can make the same request 100 times which will cause only 1 effect. If networking is lost, something will crash you're still guaranteed to have effect AT MOST once.

In case you're curious for the full flows and handling edge cases Stripe has great documentation regarding how process looks like from merchant's customer's side (as this is their business and you can integrate with them).

It's not about trying again but about making sure you get consistent state.

Imagine request for payment. You made one and timeouted. Why did it timeout? Your network or payment service error?

You don't know, so you can't decide between retry and not retry.

Thus practice is: make request - ack request with status request id (idempotent, same request gives same status id) - status checks might or might not be idempotent but they usually are - each request need to have unique id to validate if caller even tried to check (idenpotency requires state registration).

If you want to try again you give new key and that's it.

There might of course be bug in implementation (naive example: idempotency key is uint8) but proper implementation should scope keys so they don't clash. (Example implementation: idempotency keys are reusable after 48h).

If same calls result in different responses (doesn't matter if you saw it or not) then API isn't idempotent.

If idempotent key was seen then send back response.

Clients intention is outside the scope. If contract says "idempotency on key" the idempotent response on key. If contract says "idempotent on body hash" then response on body hash (which might or might not include extra data).

APIs are contracts. Not the pinky promise of "I'll do my best guess"

It doesn't auto vectorize image, but rather allow for guided process. Final SVG still should be edited.

Few fun features like genetic algorithm fit optimization, semi-manual tracing and color preservation.

Perfect if you want to have lightweight SVG from huge PNG image.

Note: If there's interest I might open-source it, just not sure if anyone would want to see it :)

Comments URL: https://news.ycombinator.com/item?id=47902793

Points: 3

# Comments: 0

I couldn't find any crate that would be ergonomic enough to use and provide features I deem essential, i.e. retryability, scheduling, poison job detection, barriers, backoff strategies etc.

it's an area I'm familiar with so after spending 2 days trying to integrate external libs I decided to roll my own and I'm quite happy how it turned out in 2 days of development.

I plan to open-source it in the near future but right now using it in my another project and it's running quite well.

- Someone likes tool X

- Figures, that they can vibe code alternative

- They take Rust for performance or FAVORITE_LANG for credentials

- Claude implements small subset of features

- Benchmark subset

- Claim win, profit on showcase

Note: this particular project doesn't have many visible tells, but there's pattern of overdocumentation (17% comment-to-code ratio, >1000 words in README, Claude-like comment patterns), so it might be a guided process.

I still think that the project follows the "subset is faster than set" trend.

Comments URL: https://news.ycombinator.com/item?id=47532242

Points: 2

# Comments: 0

I mean - I understand, some people have fun looking at new tech no matter the source, but my question is is there a person who would be designated to pick a GraphQL in language and would ignore all the LLM flags and put it in production.

One thing to keep in mind is that leetcode is testing (surprise) social anxiety. You can be a great engineer, terrific peer to have in the time when crisis hits but still fail at leetcode problem because someone is watching.

This is a solved problem if you just throw an LLM at it. Define your requirements, attach your resume, Gemini scores and ranks everything. Built in Rust with egui.

Bring your own Gemini key — no backend, no subscription. Desktop because some listings are walls of text and a scrollable cell in a scrollable table was the only UI that made sense.

Comments URL: https://news.ycombinator.com/item?id=47322713

Points: 1

# Comments: 0

As they say, you can't see the light in the darkness and the difference between two is like between night and day.

Stable performance, consistent Remote Play to Steam Deck, quick bootup and no "hey want to play, that's a shame cause I got 20 minutes of patches to install".

Sure it's still a Linux with all consequences (had to switch from Wayland to Xorg for remote play and being returning user after couple years it wasn't straightforward) but it works much better.

I won't ever install Windows on my family computers. If I can afford to equip them with Macs I'll do so. If not - they'll get Linux instead.

So the take would be that 84% heavily Claude driven PRs are riddled with ~7.5 issues worthy bugs.

Not a great ad of agent based development quality.

Comments URL: https://news.ycombinator.com/item?id=47253922

Points: 2

# Comments: 2