JackC

> What Reame is NOT for — said plainly, because trust is built here

It is so weird (or, used to be) to see an LLM's internal thought process pop up this way. Like imagine how strange it would be to read human writing that accidentally included thoughts undercutting the ongoing sentence. It's the moment you know that nothing you're reading has necessarily been seen by a human before or relates to reality.

I mean, we're talking about an administration that has already over-reached in regulating this specific company out of personal bias; is openly seeking leverage over companies for favoritism and graft; hires on the basis of loyalty to whims of a narcissist; makes fun of the whole idea of competent government based on expertise; provides a range of conflicting explanations for whatever it chooses to do; and has been unable to field a team capable of understanding or explaining whatever real risks are here.

Your question is like asking what evidence would convince us that a bag of rocks doesn't have rocks in it. Easy, just take the rocks out.

"They may speed up the good programmers a little, but those people were able to program anyway without LLMs."

I don't think this is realistic. I'm a good programmer, and it speeds up my work a lot, from "make sense of this 10 repo project I haven't worked on recently" to "for this next step I need a vpn multiplexer written in a language I don't use" to, yeah, "this 10k line patch lets me see parts of design space we never could have explored before." I think it's all about understanding the blast radius. Sonetimes a lot of code is helpful, sometimes more like a lot of help proving a fact about one line of code.

Like Simon says, if I'm driving by someone else's project, I don't send the generated pull request, I just file the bug report / repro that would generate it.

The article argues that shared memory and message passing are the same thing because they share the same classes of potential failure modes.

Isn't it more like, message passing is a way of constraining shared memory to the point where it's possible for humans to reason about most of the time?

Sort of like rust and c. Yes, you can write code with 'unsafe' in rust that makes any mistake c can make. But the rules outside unsafe blocks, combined with the rules at module boundaries, greatly reduce the m * n polynomial complexity of a given size of codebase, letting us reason better about larger codebases.

I don't have a job where I need this, but I love the UI experimentation you're doing here -- "fast muscle memory folder-based encrypted snippets for devops" makes total sense as a different need than most password manager users, and I love it when people discover a way of interacting that clicks more with their brain.

I wonder if you could try a variation that keeps passwords in an existing password manager and just uses this as an alternate UI client -- for example with the 1Password sdk https://developer.1password.com/docs/sdks/desktop-app-integr... or this technique for KeePassXC https://pypi.org/project/keepassxc-proxy-client/ . You could expose existing secrets under an "uncategorized" folder, and add a field like "sklad_folder": "foo/bar" to the secret if the user organizes them.

This way your crypto surface area narrows a lot -- you still need to do the integration securely and be thoughtful about any metadata you cache locally (maybe you don't need any!), but you barely touch actual secrets. And you can freeride on all the edge cases existing password managers handle -- recovery, autolock, sync etc. And you don't need to update passwords in two places. And the trust you're asking from users is less -- if I'm considering using your thing, I don't have to fret about all the little policy things you might have done differently from 1Password, I just have to check if you've made a secure frontend. And I can go partway, open up one vault to the frontend but not others, in a way I clearly understand. I'm paranoid and still wouldn't use a 3rd party client to my password manager, but for people who need this it seems like a much more attractive offer that way.

I knew about those internment camps -- because they were widely recognized afterward as a stain on our national character, something never to be repeated.

And I knew about the hieleras[1] and about Guantanamo.

And about so many other instances in history, from so many governments.

But I hoped our arc would not be toward more people treated this way, more proudly. I hoped we would stop running so eagerly toward the poison.

[1] https://www.hrw.org/report/2018/02/28/freezer/abusive-condit...

Thanks for your work!

Is the project interested in supporting http-vfs readonly usecases? I'm thinking of tools like DuckDB or sql.js-httpvfs that support reading blocks from a remote url via range requests.

Curious because we build stuff like this https://news.ycombinator.com/item?id=45774571 at my lab, and the current ecosystem for http-vfs is very slim — a lot of proofs of concept, not many widely used and optimized libraries.

I have no idea if this makes sense for postgres — are the disk access patterns better or worse for http-vfs in postgres than they are in sqlite?

> The president has something to offer as a solution. For everything.

Unfortunately it is not a coincidence that the solution to all problems is always (a) make a loud noise (b) take your stuff (c) take away your ability to object to taking your stuff. Amoral sadistic narcissist gonna amoral sadistic narcissist. If you think you don't have enough information to predict how that's going to play out as far as family members you care about, ok.

Opinion from 10 years ago, I suspect still valid:

There are a million python libraries and tools to do some overlapping subset of the things you'd want to do with a pdf.

There are no doubt another million in other languages.

These are each basically bundles of some of the transformations you'd want to make to the same underlying data structure.

So, complex pdf scripts often need two or three different libraries to get their thing done, which is wasteful at borh a dev effort and computational level.

The ecosystem would be greatly improved if someone made a great (probably rust based) in-memory low level pdf reading and writing data structure.

PDF libraries in any language could switch to using that structure and library internally, with the carrot that the switch would result in needing less code, and likely being some combination of faster and safer.

And then if they just exposed get_structure_pointer() and set_structure_pointer(), they could all interoperate for free. (Another carrot for joining -- small libraries could usefully add features and be adopted without needing to pick an existing popular library to glom onto.)

Not sure what would economically cause this to happen, but it would be great.

Cases are being filed -- of ones with decisions, about 138 successful cases to block executive actions so far, and 91 unsuccessful. https://apnews.com/projects/trump-executive-order-lawsuit-tr...

Meanwhile the Supreme Court has granted 16 out of 19 emergency petitions filed by the executive to overturn those rulings, grants that often require shifts in precedent without written reasoning, leading a Justice voting in the minority to describe the Court's current shadow docket practice as "Calvinball."

So (a) they are filing cases (b) they are winning (c) the Supreme Court is giving every indication that the law will be whatever it needs to be to have those cases ultimately lose.

> First people complain the app store has a ridiculous approvals process and people keep getting rejected unfairly. Now people complain that they are too loose and letting in shovelware. What’s it going to be?

At best a walled garden is collective bargaining -- a group of users (buyers) lock into requiring vendors to negotiate with their representative, and because their business is collectively valuable vendors have to meet higher privacy standards or whatever the users care about, which they couldn't extract if negotiating individually with huge companies like Facebook.

So, Apple will get yelled at whenever it fails to be a good agent in collective bargaining -- either by excluding quality vendors and driving up their costs, or by including low-quality vendors. Either one gives up the benefits to users of the walled garden.

An index of reliable apps is, you know, fine. An index with a business structure that ensures better collective bargaining gets interesting.

Amusingly this makes them more like actual fingerprints, which also lack enough information for "true fingerprinting" -- there seems to be little scientific knowledge of the error rates in matching human fingerprints in court. "Many have said that friction ridge identification is only legally admissible today because during the time when it was added to the legal system, the admissibility standards were quite low."[1]

[1] https://en.wikipedia.org/wiki/Fingerprint

This is why Slay the Spire is as loved as it is -- clearly defined skill and luck checks delivered one after the other at the precise limits of your ability.

Minesweeper is more like a quirky old wooden board game, charming because it's always been what it is, warts and all.

Here https://royalsociety.org/news-resources/projects/climate-cha...

It's been below 300 ppm for at least the last 800,000 years, had now increased to over 400 ppm in a pattern that directly maps to the industrial revolution, radiocarbon dating traces the carbon in the atmosphere to "old" carbon like that from fossil fuels, and the known sources of human emissions adequately explain the increase.

(I read the post but not paper.)

Did you measure subjective fatigue as one way to explain the misperception that AI was faster? As a developer-turned-manager I like AI because it's easier when my brain is tired.

> Signal already offers reproducible builds

After a short google, I think it does not have reproducible builds for Mac, Windows, or iOS. It does for Linux and Android, though there's a long Android bug thread that sounds like the reproduction test script is typically broken.

The difference in fields is key here: AI models are going to have a very different impact in fields where ground truth is available instantly (does the generated code have the expected output?) or takes years of manual verification.

(Not a binary -- ground truth is available enough for AI to be useful to lots of programmers.)

> It only seats two yet has a bed big enough to hold a sheet of plywood.

Not really the point of the article, but, does it? This[0] says the bed is 60 inches long and 43 wide, and plywood is 96x48 inches. Is it like, any vehicle fits plywood if you cut it to the size of the truck or stack it on top?

[0] https://www.thedrive.com/news/the-slate-truck-is-two-feet-sh...

> People could have invented crypto versions of real-life things like insurances and mortgages.

Crypto makes large technical sacrifices for the sake of being harder to regulate. I don't think that's a desirable quality for insurance and mortgages.

> I work for an org with close ties to arXiv, and just like us they are getting a lot more demand due to AI crawling

Funny, I also work on academic sites (much smaller than arXiv) and we're looking at moving from AWS to bare metal for the same reason. The $90/TB AWS bandwidth exit tariff can be a budget killer if people write custom scripts to download all your stuff; better to slow down than 10x the monthly budget.

(I never thought about it this way, but Amazon charges less to same-day deliver a 1TB SSD drive for you to keep than it does to download a TB from AWS.)

This might be what you mean, but for anyone reading -- the point of Simon's article is the whole agent and all of its tools have to be considered part of the same sandbox, and the same security boundary. You can't sandbox MCPs individually, you have to sandbox the whole system together.

Specifically the core design principal is you have to be comfortable with any possible combination of things your agent can do with its tools, not only the combination you ask for.

If your agent can search the web and can access your WhatsApp account, then you can ask it to search for something and text you the results -- cool. But there's some possible search result that would take over its brain and make it post your WhatsApp history to the web. So probably you should not set up an agent that has MCPs to both search the web and read your WhatsApp history. And in general many plausibly useful combinations of tools to provide to agents are unsafe together.

I'll add "reduce code size and complexity" to the list of benefits. A python library to calculate a simhash, or track changes on a django model, or auto generate test fixtures, will often be 90% configuration cruft for other usecases, and 10% the code your app actually cares about. Reading the library and extracting and finetuning the core logic makes you responsible for the bugs in the 10%, but no longer affected by bugs in the 90%.

Here's the full decision, which (like most decisions!) is largely written to be legible to non-lawyers: https://storage.courtlistener.com/recap/gov.uscourts.ded.721...

The core story seems to be: Westlaw writes and owns headnotes that help lawyers find legal cases about a particular topic. Ross paid people to translate those headnotes into new text, trained an AI on the translations, and used those to make a model that helps lawyers find legal cases about a particular topic. In that specific instance the court says this plan isn't fair use. If it was fair use, one could presumably just pay people to translate headnotes directly and make a Westlaw competitor, since translating headnotes is cheaper than writing new ones. And conversely if it isn't fair use where's the harm (the court notes no copyright violation was necessary for interoperability for example) -- one can still pay people to write fresh headnotes from caselaw and create the same training set.

The court emphasizes "Because the AI landscape is changing rapidly, I note for readers that only non-generative AI is before me today." But I'm not sure "generative" is that meaningful a distinction here.

You can definitely see how AI companies will be hustling to distinguish this from "we trained on copyrighted documents, and made a general purpose AI, and then people paid to use our AI to compete with the people who owned the documents." It's not quite the same, the connection is less direct, but it's not totally different.

It is on core Harvard funds, and we also have paid accounts used by law firms and journalists.

As an innovation lab we often minimize Harvard branding with project websites because it's more instructive to win or lose on our own merits than based on how people feel about Harvard, in either direction.

We're coauthors on the wacz-auth spec, which is designed to solve this sort of thing by signing archives with the domain cert of the archive that created them. If you cross-sign with a private cert you can do pretty well with this approach against various threat models, though it has to be part of a whole PKI security design.

I think the best approach for high stakes archiving is to have a standard for "witness APIs" so that you could fetch archives from independent archiving institutions. That also solves for the web looking different from different places. That hasn't gelled yet, though.

I think the biggest distinction is between archiving platforms made primarily for authors and primarily for web crawlers.

If you're an author (say, of a court decision) and you archive example.com/foo, Perma makes a fresh copy of example.com/foo as its own wacz file, with a CPU-intensive headless browser, gives it a unique short URL, and puts it in a folder tree for you. So you get a higher quality capture than most crawls can afford, including a screenshot and pdf; you get a URL that's easy to cite in print; you can find your copy later; you get "temporal integrity" (it's not possible for replays to pull in assets from other crawls, which can result in frankenstein playbacks); and you can independently respond to things like DMCA takedowns. It's all tuned to offer a great experience for that author.

IA is primarily tuned for preserving everything regardless of whether the author cared to preserve it or not, through massive web crawls. Which is often the better strategy -- most authors don't care as much as judges about the longterm integrity of their citations.

This is what I'm getting at about the specific benefits of having multiple archives. It's not just redundancy, it's that you can do better for different users that way.

Hi! Perma is made by the Harvard Library Innovation Lab, which I direct, and I wrote a bunch of the early code for it back in 2015 or so.

For HN readers, I'd suggest checking out https://tools.perma.cc/, where we post a bunch of the open source work that backs this. Due to the shift from warc to wacz, (a zipped-web-archive format developed by WebRecorder), it's now possible to pass around fully interactive high fidelity web archives as simple files and host them with client side javascript, which opens up a bunch of new possibilities for web archive designs. You can see some tech demos of that at our page https://warcembed-demo.lil.tools/ , where each page is just a static file on the server and some client side javascript.

It's best to think of Perma.cc itself, the service, as some UX and user support wrapping to help solve linkrot primarily in the law journal, courts, law journals, and journalists area (for example, dashboards for a law journal to collaborate on the links they're archiving for their authors), and our work on this as building from that usecase to try to make it easier for everyone to build similar things.

I saw some mentions of the Internet Archive, which is great, and is also kind enough to keep a copy of our archives and expose them through the Wayback Machine. One thing I've been thinking about recently in archiving is that there's a risk to overstandardizing -- you don't want things too much captured with the same software platforms, funded through the same models, governed by the same people, exposed through the same interfaces, etc. There's supposed to be thousands of libraries, not one library. Unlike "don't roll your own crypto," I'd honestly love to see more people roll their own archives.

Happy to answer any questions!

I think the distinction is these usecases require an ABI, but not the same ABI? You could in theory migrate both sides to Carbon for all of these, if it was worth it.

I spent a bunch of time on this project feeling like it was futile to jump in and then just jumped in; messing with data is fun even if it turns out someone else has your data. But the government is huge; if you find an interesting report and then poke around for the .gov data catalog or directory index structure or whatever that contains it, you're likely to find a data gathering approach no one else is working on yet.

There's coordinated efforts starting to come together in a bunch of places -- some on r/datahoarders, some around specific topics like climate data (EDGI) or CDC data, there's datasets being posted on archive.org. I think one way is to find a topic or kind of data that seems important and search around for who's already doing it. Eventually maybe there'll be one answer to rule them all, but maybe not; it's just so big.

As a library, the very high level prioritization framework is "what would patrons find useful." That's how we started with data.gov and federal Github repos as broad but principled collections; there's likely to be something in there that's useful and gets lost. Going forward I think we'll be looking for patron stories along the lines of "if you could get this couple of TB of stuff it would cover the core of what my research field depends on."

In practice it's some mix of, there aren't already lots of copies, it's valuable to people, and it's achievable to preserve.

> Is the second question about figuring out how to prioritize valuable stuff behind two depth traversals?

Right -- how do you look at the 300,000 entries and figure out what's not at depth one, is archivable, and is worth preserving? If we started with everything it would be petabytes of raw datasets that probably shouldn't be at the top of the list.