Hacker Newsnew | past | comments | ask | show | jobs | submit | oefrha's commentslogin

> An official United States government app is injecting CSS and JavaScript into third-party websites to strip away their cookie consent dialogs, GDPR banners, login gates, and paywalls.

Giving people a taste of web with Ublock Origin annoyance filters applied, refreshing. Can’t believe orange man regime is doing one thing right.


You can define your own rm shell alias/function and it will use that. I also have cp/mv aliases that forces -i to avoid accidental clobbering and it confuses Claude to no end (it uses cp/mv rare enough—rarer than it should, really—that I don’t bother wasting memory tokens on it).

I did this, Claude detected it and decided to run /bin/rm directly.

This is terrifying. I have not used agents because I do not have a sandbox machine I do not care about. Am I crazy to worry about a sandboxed agent running on my home network? Anyone experienced anything weird by doing that?

Don’t dangerously skip permissions and actually read commands when you get prompted and you’re fine.

Yeah, I actually have both an alias for `rm` and a custom seatbelt sandbox which means the agent can only delete stuff within the directory it’s working in, so wasn’t an issue, was just fun to watch it say “hm, that doesn’t seem to work. Looks like the user has aliased rm. I’ll just go ahead and work around it”

Well grep is just better sometimes. Like you want to copy some lines and grep at the end of a pipeline is just easier than rg -N to suppress line numbers. Whatever works, no need to facepalm.

Does M5 series have better video encoding chip/chiplet/whatever it is called than M4 series? Because while I’m happy with my M4 Pro overall, H.264 encoding performance with videotoolbox_h264 is disappointingly basically exactly the same as a previous 2018 model Intel Mac mini, and blown out of water by nvenc on any mid to high end Nvidia GPU released in the last half-decade, maybe even full decade. And video encoding is a pretty important part of video editing workflow.

If you mean editing ProRes is a better fit, if you mean final export software always beats hardware encoders in terms of quality, if you mean mass h.264 transcoding a Mac workstation is probably not the right place though.

This is interesting and I’d like to see a follow-up from Cursor, but the tone is unbearable and egregiously misrepresent the Cursor blog post, I guess for a circle of followers who won’t bother to check the original anyway and is just there for the dunking.

> So how cursor came up with such a beautiful solution only in 2026? Is everyone around dumb and never did anything like this before?

Cursor post doesn’t claim anything original, they attribute every approach discussed to someone else, including the one they claim to have settled on:

> Here's another very smart idea. You may have seen it used in ClickHouse for their regular expression operator, and also at GitHub, in the new Code Search feature that shipped a couple years ago and which does allow matching regular expressions. It's called Sparse N-grams, and it is the sweetest of the middle grounds.

The very next sentence in the fff article is amusing

> No, actually all the theory in the blog post they made (that makes sense) is coming from the paper https://swtch.com/~rsc/regexp/regexp4.html that is stated behind google code search project.

Because 1. the paper is prominently cited in the original, and 2. no it doesn’t cover all the subsequent optimizations discussed. “That makes sense” is doing a lot of work apparently.

Now, the main claims in the fff article are:

- Few/no people need to search entire repos that large;

- For large repos (no one needs to search), fff’s index is smaller (~100MB for chromium vs ~1GB for Cursor) and faster to create (~8s vs ~4m) and still fast (~100ms vs ?).

But all the comparisons are weirdly fixated on the MAX_FILE_SIZE query used for algorithm demonstration purposes in the original. That’s hardly a fucking regex search. Readers have no idea of how, say, MAX_.+_SIZE does after reading that rebuttal.

So, again, interesting, unbearable tone and egregious misrepresentation, would like a follow up.

Disclosure: no affiliation, not using either now.


> Swift could have easily dethroned Python

No way something that compiles as slowly as Swift dethrones Python.

Edit: Plus Swift goes directly against the Zen of Python

> Explicit is better than implicit.

> Namespaces are one honking great idea -- let's do more of those!

coupled with shitty LSP support (even to this day) makes code even harder to understand than when you `import *` in Python.

Edit 2: To expand a little on how shitty the LSP support is for those who don't work with Swift: any trivial iOS or macOS project that builds fine in Xcode can have a bunch of SourceKit-LSP (the official Swift LSP) errors because it fails to resolve frameworks/libraries. The only sane way to work with Swift in VS Code or derivatives I've found is to turn off SourceKit diagnostics altogether and only keep swiftc diagnostics. And I have the swift-lsp plugin in Claude Code, there's a routine baseline of SourceKit errors ignored. So you have symbols without explicit namespaces, and the LSP simply can't resolve lots of them, so no lookup for you. Good luck.


>No way something that compiles as slowly as Swift dethrones Python.

This must have pushed Chris Lattner towards making Mojo both interpreted and compiled at the same time.


Plus Swift goes directly against the Zen of Python

The Zen of Python is how we got crap like argparse where arguments are placed in the namespace instead of a dict.


I wouldn't change that in any way. I'd might make it an Arguments class, but I wound't make what parser returns merely a dict.

Yeah, so what happens when you have an option with a '-' in it that isn't valid as a variable name (I know what happens). It's just stupid.

The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.

It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.

>It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict

If you had some feature flag args, you'd keep accessing them via the dict? Highly unlikely...


> Explicit is better than implicit.

That's funny. To me magic is implicit by definition and Python strikes me as a very magical language compared to something like Java that is way more explicit.


Until you start using frameworks like Spring and then everything is so painfully magic that no one knows how the program actually runs.

Magical language how? And you should see what reflection based Java monstrosities do in the background.

Well, my non-tech execs get development world view from YouTubers among other influencers.

Given that subagents have different thinking/effort behavior from the main agent and very limited control on that front (I’m not completely sure about this but see https://github.com/anthropics/claude-code/issues/14321 and I’ve also noticed very different behavior when the same prompt is used in the main agent or passed to a subagent), I’m not sure this skill will be the same.

At least in codex you can configure agents as you wish: https://developers.openai.com/codex/subagents

Might work out fine on codex.


> No immutable types (in Go)

The typical answer is opaque types with only readonly methods exported. Not elegant, but it’s there. I guess it’s arguably not a “good way” to do it.


In fact it was “the Java way” for many years and “useless getters” was always a big complaint about Java.

Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!

I do agree to a certain degree, but with getters/setters you could properly hide/set to read-only fields.

Fundamentals should have even higher weight in learning budgets now, because AI can’t reliably reason complex architectural problems. It’s the surface level APIs you don’t have to learn/memorize.

Maybe you mean “AI tools are making me lose interest in learning anything”, which is… a common reaction, I suppose.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: