Looked at it, but as a security person, I have to recommend against it as it requires permissions to act on behalf of repository maintainers. That is asking for trouble, and represents a backdoor into every project that signs up for it.
thanks for bringing this up, and totally understand the concern. we are committed to security, and we never write/access your code without your action--the only reason that setting is necessary is so that you can merge/1-click commit suggestions from the AI directly from the code suggestions it's posted.
We would be happy to try except when it has write/merge permissions .
One click and auto merge are nice to have. Having the bot (and your company) able to deploy any code changes to production (by accident, via hack, etc) is a no go.
Suggest making them optional features and just having code comments/repo read version.
Not sure if it’s possible - but if the permissions could exclude specific branches that would be ok as well.
But needs to be no way a malicious actor could write/merge to main.
> A tool like this for the Fediverse / ActivityPub would be awesome.
Currently not ~~possible~~ that easy, sadly, because the Mastodon spec (which is basically what everyone uses) doesn't have the concept of backdated posts and, more importantly, even if you fudge your server to allow a date in your `Status` when posting[0], it'll still go "oh, this needs sending out to everyone"[1] as if it were a new post and let me tell you, the clients also do not know about backdated posts and things get confused real fast[2].
(I don't think it'd be a huge change to the spec to allow backdated statuses but getting consensus about how that actually works for, e.g., sending out, client handling, etc. would be a lot of work.)
[0] I did this on my Akkoma server to import 15 years of Twitter bot posts.
[1] Sadly my Elixir knowledge didn't extend far enough to be able to figure out how to prevent this for backdated posts.
[2] To the point where I and everyone else had to unsubscribe from the Fedi bot whilst it was doing the backimport.
From a quick glance, this project doesn't seem to use any tool/function calling or streaming or format enforcement or any other "fancy" API features, so all chances are that it may just work, although I have some reservations about the quality, especially with smaller models.
I’ve been having issues parsing the LLM responses using Ollama and llama3.2, deepseek-r1:7b and mistral-small. I think the lack of structured output/schema is hurting it here
Yep, I haven't tried this particular project but that's my overall experience with similar projects as well. Smaller models that can be ran locally in compute-poor environments really need structured outputs and just prompting them to "you can ONLY return a python list of str, WITHOUT any other additional content" (a piece of prompt from this project) is nowhere sufficient for any resemblance of reliability.
If you're feeling adventurous, you can probably refactor the prompt functions in https://github.com/zilliztech/deep-searcher/blob/master/deep... to return additional metadata (required output structure) together with the prompt itself, update all `llm.chat()` calls throughout the codebase to account for this (probably changing the `chat` method API by adding an extra `format` argument and not just `messages`) and implement a custom Ollama-specific handler class that would pass this to the LLM runner. Or maybe task some of those new agentic coding tools to do this, since it looks like a mostly mechanical refactoring that doesn't require a lot of thinking past figuring out the new API contract.
> let’s focus the discussion on the technical aspects of it.
The headline chosen here is already biased: "Dozens of _Hezbollah members_ [..]"
Anyone following this closely can see that plenty other title choices could be used. There are headlines that would be credibly neutral, headlines that favor the IDF, and headlines that favor Hezbollah. HN is currently choosing to go with a non-neutral, non-technical headline for this story. Maybe we should make the headline neutral as well before telling the commenters to focus solely on the technicals?
If you don't understand what I'm referring to, look at some of the downvoted and hidden comments here.
Honestly struggling to comprehend how this one isn't neutral.
As far as we know this was a supply-chain attack specifically on military pagers actively used by Hezbollah, and (right now) it looks like most injured are in fact Hezbollah members (which makes sense, since no one else has any reason to carry such a pager). (With some sad and unfortunate exceptions.)
After I posted my comment the title was updated to be a little bit more neutral.
The previous headline was emphasizing a little too strongly the assumption that this attack was against Hezbollah only, and as you mention there are "exceptions", meaning, civilians and non-militants (including children) were killed and injured.
EDIT: in other words, the headline is/was written with the assumption that whoever was attacked was a member of Hezbollah, but this isn't true.
"Serverless" means there's no stateful application server in your architecture. No instance, just callable code. Shell script, not daemon.
You write narrow business-level functions that take inputs, do their business, and give you the output. They're called, they run, they terminate and carry nothing forward. You deploy them to a hosting platform which will handle making them available, routing requests, and all the other stuff that's incidental to doing the work. The only thing that's your concern is the logic that turns inputs into outputs. At least that's the pitch.
Technically a PHP script that you run as CGI through Nginx is "serverless" that way, though of course it's hosted with a software server running on a hardware server. It's serverless because you write a PHP script and it doesn't care what runs it or what's going on around it. It doesn't need to work within the context of an application server like an endpoint in a Django or a Rails app would.
Someone else could own a bunch of servers running Nginx, you'd give them prettyprint.php, and it would pretty-print your JSON or whatever at the URL they'd give you.
Services that do this are called serverless platforms. The hosting model is called "functions as a service" (FaaS). If you like the architecture but you don't want FaaS from Amazon, Heroku, or some other third party, you can host yourself a mini FaaS with something like Dokku.
heroku is (was?) a platform for hosting web apps with a lot of nice ergonomics, to let you run commands like "heroku up" to get your app running on the web with minimal fuss.
this appears to be a project to give you the niceities of a PAAS, without actually providing the platform.
Heroku is still good for tons of stuff. After Salesforce bought it, it stopped getting much better, they removed part of free quota, some add-ons disappeared, and the like. For example, http2 support just went beta on may. It's a shame.
It's not high on my TODO list for the project, but shouldn't be too much work. I'd give it a try if you're interested. Want me to reply to your comment when I get a Linux version released?
