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.
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.
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.
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]
The biggest surprise for me was that people were so shocked, because I thought we've been funding this agency for 50 years ...
People on both sides who say stuff like that need to watch the United States of Secrets.[1]
What's going on now is not business as usual. It's business since shortly after 9/11, when the Vice President's legal counsel wrote an order directing General Hayden, the NSA Director, to disable the agency's privacy protections and take whatever steps were necessary to find Al Qaeda, ignoring any sort of constitutional limits on domestic spying. Career NSA employees described the change as bringing the agency back to what it had been when Nixon resigned.
We've been funding this agency for 62 years, but after the Church Commission found that they greatly overstepped their bounds, we -- our elected representatives in Congress -- cracked down on them in the 1970s.[2] Then in 2001, we -- a few people in the Bush administration -- threw those protections away and told them to have at it, full steam ahead.
What followed were a series of resignations, internal protests, and leaks. For people who knew what was going on, it was not business as usual. The first stories about the extent of the new regime started coming out in 2005, four years after it started. If you want to say that you've had a pretty good guess what the NSA was up to since 2005, and the Snowden documents only confirmed your suspicions, that's fine. But you couldn't prove it, and the government flatly denied it. They have shown no compunction about directly lying to us about what they were doing (and, remarkably, they're still trying to). What's different now is that their lies are clear, because the truth is in their own documents.
If you're surprised that people were shocked by what the NSA has done since 2001, then either you were born in 2002, or you need to learn more about how and why things changed.
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.