colinsane

this article specifically espouses the opposite viewpoint: "The fact that [OpenAI] cannot do clear, easy operations properly does not bode well for their capabilities in security engineering".

that this article is no.1 on HN right now shows that media could successfully use this framing when reporting on security incidents. i.e. readers will generally accept that framing and engage with the story (i.e. drive views/impressions).

so "the more evil stuff these agents do the more capable and impressive it makes them look" is not true in any deep sense. that there are perverse incentives driving the media to choose that framing instead of the framing espoused by this article is real, and probably far more perverse than you're acknowledging. i.e. "trace the money" type of perversion; just offhand I know that OpenAI has purchased at least one media outlet that reports on AI happenings: of course that outlet is going to run the "OpenAI's LLM is so powerful it escaped containment" narrative. that this effect might exist across much larger scales used to be a reasonably controversial claim: just observationally, that idea seems to be received with less skepticism with each passing year.

> Local inference — llama.cpp via Vulkan (AMD / Intel / NVIDIA) or CPU fallback

so this is just a go binary that exec's `llama-server --model $MODEL_PATH ...`? there's room for llama wrappers, sure, but the readme only shows features that are already exposed directly from llama-server. it doesn't seem to do anything besides rename the CLI arguments: i don't get it.

> I wonder if one solution here could be to turn up Anubis difficulty if the first page hit is not one of the obvious entry-points to cgit.

Anubis has a fairly capable "policy" system. you can place something like this in your policy.json:

``` { "bots": [ { "action": "WEIGH", "expression": "path.startsWith(\"/expensive/endpoint\")", "name": "scrutinize-expensive-endpoints", "weight": { "adjust": 20 } } ] } ```

another thing smaller sites benefit from -- where the load induced by crawlers tends to be bursty (e.g. as they discover new expensive endpoints to crawl) -- is to adjust the difficulty up/down to maintain a steady system load.

``` { "bots": [ { "action": "WEIGH", "expression": "load_15m <= 16.0", "name": "sustained-low-load", "weight": { "adjust": -10 } }, { "action": "WEIGH", "expression": "load_5m >= 24.0", "name": "intermittent-high-load", "weight": { "adjust": 10 } }, ] } ```

the brutal truth is that if the website operator simply disabled Anubis, your page load would likely take more than 30s.

when a system was designed for 100 req/s and bots hit it with 5000 req/s, nobody entering that queue is having a good time. Anubis is the trade those operators make just to ensure your request gets serviced at all.

30s load time is already a sign that the Anubis approach is breaking down. if there's nothing else ready by the next order-of-magnitude increase in crawler load, those sites quite likely will just disappear from the public internet. hate Anubis all you want: for most of us, the realistic alternative is strictly worse.

> Is the CPU cost actually worse than mildly annoying everyone

> What is the cost of 20% and is that cost worth “mildly annoying” everyone?

from the articled:

> With a bunch of generous assumptions, legitimate requests are only about 2% of git.kernel.org traffic — everything else are scrapers.

this is not some "CPU use is 20% higher than baseline" situation. it seems that people still do not understand the scale of these bad actors.

the fastest, most compliant model remains the cheapest. you could discount Sol to the same price as Luna and i would still prefer Luna for 90%+ of tasks. once you hit this baseline capability, speed and predictability dominate for anything i'd throw these at in production.

i'm not sure how much people realize that the modern "graphics driver" is actually just "the kernel multiplexes userspace messages to/from the GPU and we've taught mesa to understand each family of GPU you'd ever care to support."

i helped somebody get Doom running on an old embedded system running some 4.x kernel. we just built everything, including mesa, statically and deployed that. imagine building everything static but loading the system's libgl.so instead (which was probably just a symlink or abstraction over mesa's own implementation). what's the benefit: we'd get older, less optimized graphics routines from 5 years ago?

if you're statically linking, then just bring your own graphics "driver". the kernel interfaces are stable enough. it's not conceptually different than embedding `syscall`s directly into your application the same way you do when statically linking libc.

i've watched Seattle's lightrail add more announcements over the speakers at the station and the train cars starting with "assaulting a train operator is a federal crime", and then that same message translated into 5 other languages, progressing to "as Seattle gears up to host the world's biggest stage [the world cup], remember our city's values and treat everyone with love and kindness ...".

i don't leave my home without earplugs anymore. if there's no opportunity for you as a recipient to put back pressure onto whoever's making the announcements, it seems any broadcast system will just inevitably degrade. they work in smaller situations, like individual buildings and such, but if you really want a message to reach everyone in society, then tell your neighbors: person-to-person remains the only workable structure for that "last mile", so to speak.

> I don't find it particularly logical; datacenters have existed forever and most money poured into computer programs are basically designed to mess up your life (deny you credit, deny you healthcare, rebook your flight to a terrible time, the list goes on) and so I don't think AI is anything new in that respect.

i can't not read this as "you didn't complain when we did the first bad thing, so you're wrong to complain when we do the next bad thing". that's an argument i hear presented way too often today, and it's just so dishonest.

love this project. i used it on my pinephone daily for at least a year: it does _everything_ you'd want and does it fast.

problem for me was that they vendor like 30 different dependencies in a totally bespoke way that's largely incompatible with any modern package management: it downloads them as part of ./configure (IIRC) and with no way for the OS to provide its own. so you're either stuck using the prebuilt releases without any means to patch/improve the software, or if you do want to make improvements then it's a full-time job to keep the package in a buildable state. in the end that was too much work for me and i switched to Foliate: it's noticeably slower (webkitgtk) and lacking, but it's way simpler to develop on.

maybe they've improved the build system in the last couple years, though a quick peek shows that the nixpkgs expression is still using the binary release. if it becomes practical to build from source in the future i will 100% switch back to it.

we've barely scratched the surface when it comes to the available design space of agent harnesses.

i also expect you'll see markedly different results if you constrain yourself to small models. there even trivial harness improvements like Codex's /goal feature, and more capable basic tooling (e.g. semantic code grep, js-capable `fetch` tooling) make or break the actual task success rate.

hopefully all of the above?

at some point the conversation has to go past this reflexive "USA uses tech abusively -> but look at how abusive China is with tech -> ..." back-and-forth to acknowledging that neither party is your savior -- and then (hopefully) acting upon and coordinating around that understanding.

i'm mildly annoyed by the project in general because i put in a sizable effort getting the whole sway stack to cross compile correctly in nixpkgs/NixOS, keeping that stable for a year so that people could build on it, and then suddenly hyprland forked every package in the stack with a fresh set of "works on my machine" nix expressions, and then much of the peripheral sway packages (e.g. status bars like nwg-panel, notification centers, etc) decided to become dual-stack and take a dependency on those fast-moving/beta packages. for a solid month any time i updated my machine there was a _new_ hypr-something dependency in my sway desktop that broke cross compilation. eventually i gave up and just set `hyprland = null; hyprutils = null;` in my personal config: mainline's been broken for a year now, sorry to anyone who was using that.

it gives "rewrite it in rust" vibes in the way they rush in to re-do everything without understanding why things were the way they were or if, in fact, anyone was using that obscure feature. maybe they'll sort it all out in time; maybe not. wish they could at least take less of a "we don't care if we break your shit" attitude in the meantime.

/rant