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.

FYI, x86_64-linux and i686-linux nixpkgs bootstrap seed is not 25 bundled binaries, but 181 bytes, since https://github.com/NixOS/nixpkgs/pull/479322. at publication date this article would apply to non-x86 platforms like aarch64-linux, risvc64-linux, etc.

if you're concerned about this and not on x86, i encourage you to extend this to other platforms! i believe it's possible to generalize this to every linux platform musl itself supports, in time.

> 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

i hadn't considered that Seattle might be an outlier; the numbers vary by city more than i knew.

https://www.soundtransit.org/sites/default/files/documents/2...

page 11 has the $ figures. "link" is the commuter rail system: $408M operating expenses but only $51M revenue from fares, i.e. fares cover 12% of op ex.

the "average fare per boarding" is $1.34 (page 3; this is ticket price multiplied by the proportion of trips where the rider pays that ticket). throw that together: even with 100% payment compliance the average ticket price would be $11 per boarding for that to be a complete funding source. $11 would force more riders onto the subsidized fare programs, plus other knock-on effects from raising fares (e.g. reduced ridership in general) means the sticker price would have to be higher yet.

the commuter rail here was never designed for ridership fares to cover its operating costs. it just wasn't. the recent focus on fares in the face of all this is misinformed, that's the kindest way i can phrase that.

(apologies to hijack much of this with what turns out to be more of a Seattle-specific issue).

the turnstile thing is more complex than you perceive because almost every transit system relies on public funding. here (Seattle) those fares only fund about 10% of the _operating cost_ of the transit per Sound Transit's own reports. not to derail the point, but please do go read your transit system's quarterly reports instead of taking the conclusion of fare dodging for granted. just about every city has public budget reports for their transit system precisely because they are the product of public funding.

i just prompted Kimi & it replied with an uncensored version.

i posted the transcript as a reply to you, and HN automatically flagged it.

but go on.

> The bigger problem with the post is that it talks out of both ends of the mouth: it’s clearly meant as a personal attack, but also insists that it isn’t.

my instinct is to step up and defend Andrew: to say that truly, he has strong opinions -- which is to say he _cares_ about doing things right -- but that he's more patient and accommodating than you're judging him to be from this 10,000ft view.

that's kinda weird: you might view this as a personal attack _from_ Andrew against Bun and i might view the reactions as personal attacks _against_ Andrew. viewing it through this lens without our preconceptions ought to make either both parties or neither party look bad, i think? i don't know the solution except to highlight the outsized impact that our individual preconceptions play when judging a situation from 10,000ft away.

the options available to small web hosts are:

1. do nothing: everyone gets page loads of 30s if not worse.

2. put the content behind anubis -> load drops by 80% and page loads are back to "a couple of seconds" (including the client-side challenge).

3. take the content offline -> load drops to 0.

which of these would you prefer?

just their smallest dataset looks to be 6 TB _compressed_. not a thing you can really ship as part of the agent. but if somebody made a fetch_url tool that sharded that across all users of it, i'd give it a try. could probably just layer that on top of bittorrent or IPFS or something.

ironically (?) i prefer to improve Pi by connecting MCP servers instead of native extensions in part due to this (process-level sandboxing is trivial; anything more granular -- as would be required for in-process plugins -- is far more intimidating).

any tips for calibrating or even just validating these handheld CO2 meters?

i've taken a few Amazon-listed CO2 meters from $dirt-cheap to $150, tossed them in a ziplock, and then discharged CO2 from a canister into the bag & sealed it. none of them read notably differently after an hour, nor show any sort of range error, etc.

i've also done this without the ziplock: put them in a large pot, fill that with CO2. CO2's heavier than the rest of the air so the concentration should remain elevated within the pot, but same deal.

i like the idea of monitoring CO2, but it's hard enough to get certainty about the _effects_ of CO2 level; without confidence in my meter i fear the conclusions i draw from it are more noise than signal.

i installed the playwright MCP to let my agent access walled sites (specifically ebay and WSJ). i noticed that 90% of the time it was bounced from a site, it just reached out to a different site that wasn't walled, and i think it's the right move: most information exists at multiple places on the web, it's cheaper and _faster_ to just skip over walled sources.

for the forum example: many forums have a policy to only allow access to attachments to logged-in users. i can't remember the last time i registered at a new forum just to view an attachment: the effect has always been to drive me elsewhere. no complaints -- these solutions work if your goal is to reduce load. i'm suspicious that they can drive monetization outside of a very few niches.

that's somewhere between saying "use Android, just switch to Graphene if/when they lock it down", and saying "just switch to postmarketOS/Ubuntu Touch/whatever flavor of Linux takes off".

i've watched friends try that route; i've been through this before. taking a downgrade is never fun: if it's a thing you're likely to care about in the future, then sometimes it's better to place yourself in the right ecosystem early.

AgentWorld is _fantastic_. i just migrated "down" from the 122B A10B qwen model to agentworld (35B A3B) because it feels as capable, easier to steer, and it's 3x faster.

also i like that if i drop more sophisticated tools into my harness (e.g. any of the NLP/RAG-based search tools in place of grep/rg), the agent will actually reach for them and make progress faster; previous models have been reluctant to embrace new tools.

i like that people are taking the privacy argument seriously, after however many decades. i think there are other arguments to be made for running these locally which are less settled, but IMO the Fable debacle drives it home: the surest way to embrace this technology without worry that it will be taken away from you down the road is to physically own the compute.

the _one_ downside i've seen is on an airplane serviced by Starlink: UDP was extremely lossy to the point that whatever recursive resolver i was using at the time would mark half of all nameservers it saw as "unhealthy" and start returning NXDOMAINs to the clients before even trying to hit the authoritative NS.

Buy Bitcoin.

look, i'm sorry, but this is a thoroughly solved problem by now.

the companies which have the power to alleviate these shortages are the same companies who are profiting most from the shortage. scarcity is an asset, it's not irrational that a concentrated marked will produce more of that asset.

can those macs boot linux? i've heard about Asahi but have no idea how far along they are. i've got my fleet configured with nix and sure, nix can target darwin, but there's a _lot_ of sharp edges there: i don't really want to pull that thread unless i have to...