Readit News logoReadit News
farkin88 commented on The X11 Security extension from the 1990s   uninformativ.de/blog/post... · Posted by u/zdw
rnhmjoj · 4 months ago
It's worth mentioning that the X11Libre fork of X.org has recently added the Xnamespace extension [1], which is inspired by this. Instead of a single bit trusted/untrusted it allows to isolate clients into containers where interactions are restricted to be within the same container only.

[1]: https://github.com/X11Libre/xserver/blob/master/doc/Xnamespa...

farkin88 · 4 months ago
Thanks for sharing. That's really cool.
farkin88 commented on The X11 Security extension from the 1990s   uninformativ.de/blog/post... · Posted by u/zdw
farkin88 · 4 months ago
X11's SECURITY extension was its long-forgotten stab at sandboxing: flip a bit and every client is either trusted or untrusted. It does kill trivial key-logging, but it also breaks the clipboard, disables GLX and makes various apps fall over, leaving the desktop unusable while Firefox somehow works just fine. A cool reminder that X11 could've had proper sandboxing 25 years ago, but the UX cost sank it and Wayland is the lifeboat now.
farkin88 commented on Tokens are getting more expensive   ethanding.substack.com/p/... · Posted by u/admp
andyferris · 5 months ago
I actually think Anthropic's plans with capped usage per 5-hour period and per week is good, for exactly this problem.

I'd prefer it just specify a number of tokens rather than be variable on demand - I see that lets them be more generous during low periods but the opacity of it all sucks. I have 5-minute time-of-use pricing on my electricty and can look up the current rate on my phone in an insant - why not simply provide an API to look up the current "demand factor" for Claude (along with the rules for how the demand factor can change - min and max values for example) and let it be fully transparent?

farkin88 · 5 months ago
Anthropic still relies on quotas (5-hour rolling + weekly coming at the end of the month) so the next step is dynamic per-token pricing. But, even with transparent off-peak rates only batch jobs will shift and history suggests variable pricing usually smooths rather than sharpens peaks. The long-term fix stays the same: route 100 MB PDFs, repo refactors and other whale jobs through retrieval or analysis pipelines and keep the flagship chat model for real-time conversation.
farkin88 commented on Writing a good design document   grantslatton.com/how-to-d... · Posted by u/kiyanwang
closeparen · 5 months ago
Then do Security, Privacy, Compliance, and the review committees of all affected orgs become blocking reviewers on any PR that touches an ADR? Are these PRs getting merged in less than 90 days?
farkin88 · 5 months ago
Fair point about process bloat. Just to clarify: I'm not an ADR expert nor do I personally know Harmel-Law. Just deriving insights from his blog post that I linked to earlier because I thought it was interesting.

But, I think you might be picturing ADRs as heavier than they need to be. Most changes seem like routine updates ("We decided Postgres" → "We're migrating to Aurora") that go through normal code review. The big architectural shifts that would trigger Security/Compliance review probably should anyway, ADR or not.

The key insight is that ADRs document decisions, they don't create them. If a change is big enough to need committee review, it likely needs that scrutiny regardless of whether there's documentation.

The alternative, undocumented drift, often creates much longer delays when people rediscover decisions during incidents. Curious to hear from folks who've actually implemented this at scale, though.

farkin88 commented on Show HN: Mcp-use – Connect any LLM to any MCP   github.com/mcp-use/mcp-us... · Posted by u/pzullo
farkin88 · 5 months ago
The prod-readiness concerns are fair, but mcp-use fills a real gap in the MCP stack: orchestration across many servers with far less boilerplate than the official SDK. Even if the agent is as another commenter fairly pointed out, just a LangChain wrapper, the six-line setup and server manager are a nice DX upgrade.

What’s still missing is structured error semantics. Right now, when a tool explodes the LLM only sees a raw stack trace, so it can’t decide whether to retry or bail. Today, I saw another Show HN post on MCP here: https://news.ycombinator.com/item?id=44778968 which converts exceptions into a small JSON envelope (error, details, isRetryable, etc.) that agents can interpret. Dropping that into mcp-use’s client loop would give you observability + smarter retries for almost free.

I might be missing some important nuances here between client side and server side MCP error handling, which I’ll leave to the authors to discuss. Just thought there might be a good open source collab opportunity here.

farkin88 commented on So you want to parse a PDF?   eliot-jones.com/2025/8/pd... · Posted by u/UglyToad
UglyToad · 5 months ago
You're right, this was a fairly common failure state seen in the sample set. The previous reference or one in the reference chain would point to offset of 0 or outside the bounds of the file, or just be plain wrong.

What prompted this post was trying to rewrite the initial parse logic for my project PdfPig[0]. I had originally ported the Java PDFBox code but felt like it should be 'simple' to rewrite more performantly. The new logic falls back to a brute-force scan of the entire file if a single xref table or stream is missed and just relies on those offsets in the recovery path.

However it is considerably slower than the code before it and it's hard to have confidence in the changes. I'm currently running through a 10,000 file test-set trying to identify edge-cases.

[0]: https://github.com/UglyToad/PdfPig/pull/1102

farkin88 · 5 months ago
That robustness-vs-throughput trade-off is such a staple of PDF parsing. My guess is that the new path is slower because the recovery scan now always walks the whole byte range and has to inflate any object streams it meets before it can trust the offsets even when the first startxref would have been fine.

The 10k-file test set sounds great for confidence-building. Are the failures clustering around certain producer apps like Word, InDesign, scanners, etc.? Or is it just long-tail randomness?

Reading the PR, I like the recovery-first mindset. If the common real-world case is that offsets lie, treating salvage as the default is arguably the most spec-conformant thing you can do. Slow-and-correct beats fast-and-brittle for PDFs any day.

farkin88 commented on Writing a good design document   grantslatton.com/how-to-d... · Posted by u/kiyanwang
gerdesj · 5 months ago
I'm going to have to read that MF.com link fully and properly but I can't help but notice this:

"That’s it. That’s the Advice Process in its entirety." (speak to everyone involved).

Presumably anyone with the term Managing as a prefix in their job title is expected to glaze over at roughly this point.

Then we get to the meat: "The four supporting Elements". So I try to find out about ADRs:

I follow the first link:

https://www.thoughtworks.com/radar/techniques/lightweight-ar...

and eventually end up with this beauty (big download button at the bottom of the page from above):

https://www.thoughtworks.com/content/dam/thoughtworks/docume...

Would you mind pointing us at an actual definition of ADRs, please?

farkin88 · 5 months ago
There are so many external links, it's easy to get lost in this article. Look under content for the section titled "1. A Thinking and Recording Tool: Decision Records." It's under "The Four Supporting Elements." Here's a direct link if it's easier https://martinfowler.com/articles/scaling-architecture-conve... (Just search on that page for "The Four Supporting Elements)

There Harmel-Law defines ADRs as "lightweight documents, frequently stored in source code repositories alongside the artefacts they describe." He also provides a handy "Elements of an ADR" table. Let me know if you're still having problems finding it.

farkin88 commented on So you want to parse a PDF?   eliot-jones.com/2025/8/pd... · Posted by u/UglyToad
farkin88 · 5 months ago
Great rundown. One thing you didn't mention that I thought was interesting to note is incremental-save chains: the first startxref offset is fine, but the /Prev links that Acrobat appends on successive edits may point a few bytes short of the next xref. Most viewers (PDF.js, MuPDF, even Adobe Reader in "repair" mode) fall back to a brute-force scan for obj tokens and reconstruct a fresh table so they work fine while a spec-accurate parser explodes. Building a similar salvage path is pretty much necessary if you want to work with real-world documents that have been edited multiple times by different applications.
farkin88 commented on Writing a good design document   grantslatton.com/how-to-d... · Posted by u/kiyanwang
farkin88 · 5 months ago
Solid advice on clarity and editing. The only gap is what happens after the doc is approved? Without upkeep it decays into "design archaeology." A few years ago, Andrew Harmel-Law wrote about an interesting approach to scaling architecture conversationally, which includes lightweight Architecture Decision Records (ADRs) as one tool that could help here. ADRs live beside the code (adr/001-use-postgres.md) and capture context, decision, and status in a format short enough to, I think, revisit in every PR and easy to supersede when reality changes so the original rationale stays searchable months later.

Here’s a link to Harmel-Laws’post if anyone's interested: https://martinfowler.com/articles/scaling-architecture-conve...

farkin88 commented on My bytecode optimizer beats Copilot by 2x   deviantabstraction.com/20... · Posted by u/top256
top256 · 5 months ago
Yes exactly and that was the hard part (extract and verify the invariants). Still it's surprising because llm needs to be able to do that for any complex code.

What you wrote is great can I copy/paste it in the blog post? (Referring you of course)

farkin88 · 5 months ago
For sure. Feel free to copy/paste it. Great blog by the way. Will keep any eye out more of your posts.

u/farkin88

KarmaCake day141March 7, 2023View Original