Same here, except that I gather all the bibliography entries into a Zotero collection organized by paper and only export that to the latex workspace rather than using JabRef. Works a treat and keeps the size of the .bib file small.
If Zotero, or more appropriately better-bibtex, had a 'make collection from .aux file' option, than that would be fantastic. For some documents there can be such a number of references that doing this manually would be a chore. But having that collection in zotero would be useful by itself as a resource. Maybe I'll head over and make that suggestion...
For me, that's manual—I make sure everything I've cited is in the .bib file, and move papers into another collection if they end up not being relevant for a particular paper.
This is probably an automatable task, but it's generally not too much of a burden to do manually. I add a 'needs-review' tag to papers I've identified in a literature review, and categorize it when I get around to reading it.
There is no concrete concern past "models that can simulate thinking are scary." The risk has always been connecting models to systems which are safety critical, but for some reason the discourse around this issue has been more influenced by Terminator than OSHA.
As a researcher in the field, I believe there's no risk beyond overconfident automation---and we already have analogous legislation for automations, for example in what criteria are allowable and not allowable when deciding whether an individual is eligible for a loan.
This is false. You are dismissing the many concrete concerns people have expressed. Whether you agree with those concerns is immaterial. Feel free to argue against those concerns, but claiming there are no concerns is a false and unsupported assertion.
> but for some reason the discourse around this issue has been more influenced by Terminator than OSHA.
1) Claiming that concerns about AGI are in any way about "Terminator" is dismissive rhetoric that doesn't take the actual concerns seriously.
2) There are also, separately, risks about using models and automation unthinkingly in ways that harm people. Those risk should also be addressed. Those efforts shouldn't subvert or co-opt the efforts to prevent models from getting out of control, which was the point of this bill.
Ok, so based on another comment in this thread, your concrete concern is something like: the math that happens during inference could do some side-channel shenanigans that exploits a hardware-level vulnerability to do something. Where something leads to and existential threat to humanity. To me, there's a lot of hand waving in the something.
It's really hard to argue for or against the merits of a claim of risk, when the leap from what we know today (matrix multiplication on a GPU is generally considered safe) to the hypothetical risk (actually it's not, and it will end civilization) is so wide. I think I really need to see a plausible path from GPU vulnerability to "we're all gonna die" to take a concern like this seriously. Without that, all I see is a sci-fi boogeyman serving only to spook governments into facilitating regulatory capture.
My concern is that people are rapidly attempting to build AGI, while applying lower standards of care and safeguards than we would expect to be applied to "team of humans thinking incredibly quickly", which is a bare minimum necessary-but-not-sufficient lower bound that should be applied to superintelligence.
Among the many ways that could go wrong is the possibility of exploitable security vulnerabilities in literally any surface area handed to an AI, up to and including hardware side channels. At the same time, given the current state of affairs, I expect that that is a less likely path than an AI that was given carte blanche (e.g. "please autonomously write and submit pull requests for me" or "please run shell commands for me"), because many many AIs are being given carte blanche so it is not necessary to break out of stronger isolation.
But that statement should not be taken as "so the only problem is with whatever AI is hooked to". The fundamental problem is building something smarter than us and expecting that we have the slightest hope of controlling it in the absence of extreme care to have proven it safe.
We currently hold frontier AI development to lower standards than we do airplane avionics systems or automotive control systems.
This is not "regulatory capture"; the AI companies are the ones fighting this. The people advocating regulation here are the myriad AI experts saying that this is a critical problem.
Well it's a mix of concerns, the models are general purpose, there are plenty of areas regulation does not exist or is being bypassed. Can't access a prohibited chemical, no need to worry the model can tell you how to synthesize it from other household chemicals etc.
If you're willing to hold your nose a little bit, Plaid[0] might be worth looking into. They have (had?) a testing tier which is more than enough for personal uses (100 linked accounts).
According to this Reddit thread from 10 months ago, some major US banks like Chase won't work even in development mode without production approval, and some people mention obstacles getting approved for OAuth without being a company or otherwise having that level of security posture. (Other people seem to have gotten successfully approved for OAuth.)
I agree this niche needs a better solution than it currently has, although the commercial and regulatory incentives might not be well-aligned to force that. In my family we have important accounts in the US and in the EU (as well as less important accounts in Canada and Mexico), and I don't know of any personal use-friendly solution that lets me pull my data automatically from all of these.
I'd honestly like some nice integration between Plaid and Excel or GSheets to let me track capital gains transactions for my non-euro accounts in the weird way that German tax law requires (over a surprisingly broad range of accounts starting next year at the latest). But nothing turnkey seems to exist right now.
Also in June of this year Plaid decommissioned its development platform but added a (quite) limited free tier of the production platform: https://www.reddit.com/r/fintech/comments/1c8xxet/plaid_prod... This doesn't really invalidate the main point of my comment, but it does affect a few details.
LIME and other post-hoc explanatory techniques (deepshap, etc.) only give an explanation for a singular inference, but aren't helpful for the model as a whole. In other words, you can make a reasonable guess as to why a specific prediction was made but you have no idea how the model will behave in the general case, even on similar inputs.
Is there a study of "smooth"/"stable" "AI" algorithms - i.e. if you feed them input that is "close" then then the output is also "close"? (smooth as in smoothly differentiable/stable as in stable sorted)
Same here. I started my PhD with the full intention of doing most of my research with Julia (via Flux[0]), and while things worked well enough there were a few things which made it challenging:
- Lack of multi-GPU support,
- some other weird bugs related to autograd which i never fully figured out,
- and the killer one: none of my coauthors used Julia, so I decided to just go with PyTorch.
PyTorch has been just fine, and it's nice to not have to reinvent to wheel for every new model architecture.
I like this! I feel like I've written a half-version of this a dozen times, it's nice to see a version which is fully fleshed out.
One feature request: you could likely fully remove the need for an NPM package by accepting POST requests from forms, and staple the API key in with either the URL or an <input type="hidden" value="key"/>—is that in the roadmap?
That's what I did here: https://www.simplecontactform.org
The presentation isn't fleshed out because we mostly use it for our agency clients but it is the most minimal version I could come up with.
I always liked the idea for your service but the pricing didn't work (to be clear: it's not your fault, I'm not sure it is solvable).
I wanted to use it for my personal website which will receive maybe 10 emails through the year (if I'm lucky), but at $5/month I can just spin up my own VPS, which can do way more than sending me emails.
That makes total sense. I set this up for our agency clients to be able to integrate email sending on a static site without having to manage a server or dive into spam filtering. For them the decreased complexity and time saved alone is usually worth the price.
I'd love this service but how are you going to handle bots?
I wanted this for my personal website which will maybe receive an email once per month in the best case scenario, but with lambdas there is always the risk of having a malicious actor coming in and pushing your bill to astronomical levels
I agree, the `dev` extra group should be used for development dependencies. The arguments against it are pretty weak, especially the "i don't want dev dependencies listed as dependencies of the package on pip" line; imo if a package is required to interact with the dev environment it is a de facto dependency regardless of whether it gets installed in a normal installation.
Strongly agree. Plus all the benefits of automated tools like dependabot. Wonder what it would take to get poetry, pdm, and rye to change their behavior.
A lot of the backlash is around the tool downloading and running an arbitrary shell script which could contain anything, and overlooks the fact that that shell script then downloads an opaque binary which could also contain anything. If you're paranoid about security read the code and build it from source, otherwise curl | bash is trusting the authors just as much as any other method.
Probably the biggest problem with the `curl | sh` approach is it bypasses package maintainers. I agree it's really no different than if you compiled malicious code yourself (or pulled in a 3rd party bin repository). However, one of the functions of a package maintainer is finding/being notified of security issues.
I'm thinking of the recent xz attack. Imagine how bad that would have been if xz was commonly installed via `curl | sh`.
All this is to say `curl | sh` is probably fine if the org is reputable, however, you should be having second thoughts if this is a repo ran with a bus factor of 1.
Yet the xz attack specifically targeted the packages and nothing else. And it worked, to a point. All I’m saying package maintainers are human and can’t detect everything.
