I think that would be a way more natural way to explore than being stuck on the classic linear output of a LLM.

So, what's the natural language for them?

What's the equivalent for LLMs for tabular or structured data? What makes them grasp the data easily and efficiently?

Comments URL: https://news.ycombinator.com/item?id=49176440

Points: 5

# Comments: 6

Comments URL: https://news.ycombinator.com/item?id=47425274

Points: 4

# Comments: 0

FYI, git-bug doesn't use timestamps to figure out the ordering. It first uses the git DAG topology (it defines ancestors), then Lamport clocks (increment for any changes on any bugs), then order by hash if there is still an ambiguity. Note that the git DAG could also be signed, which would also provide some form of reliance against abuse.

I had an interesting discussion recently about how to handle conflict for bug trackers. In my opinion it's a great use-cases for CRDTs (as it avoids data corruption), as long as all user intents are visibly captured in a timeline and easily fixable. It turned out though that there is an interesting middle ground: as the CRDT captures *when* a concurrent editing happen, it's 100% doable to highlight in the UI which event are concurrent and might need attention.

The plan is to 1) finish the webUI and 2) accept external auth (e.g. github OAuth). Once done, anyone can trivially host publicly their own forge and accept public contribution without any buy-in effort. Then, if user wants to go native they just install git-bug locally.

Remote: Yes (have been 100% remote for 6+ years)

Willing to relocate: No

Technologies: Go, networking, protocols, identity, cryptography, local-first, CRDTs, devops, AWS, kubernetes, IaC, free software, linux

Résumé/CV: see my Github profile for notable and open source work: https://github.com/MichaelMure

Email: on my Github profile

I'm a builder, a backend engineer with strong go proficiency, passionate about local-first and how we can build better software for a better world. Happy to talk about opportunities.

Comments URL: https://news.ycombinator.com/item?id=44306634

Points: 2

# Comments: 1

Or you could just as well plug a generic database there.

[1]: https://github.com/git-bug/git-bug/blob/master/repository/re...

With a single binary deployment, you'd just need a bit of config and a DNS, and you could host a forge-ish for your project.

We are not there yet but it's really not far.

The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.

- git-bug use a form of logical clock (not wall clock) that order an action in relation to other actions in the repo. Clock drifting doesn't matter.

- pushing to git usually require some access to the repo, and therefore abuse can be dealt with socially (aka you get kicked out)

What can happen for example is someone write a comment, shut down the computer and only push the next day, but in that case the comment showing up before yours is the correct merging.

See also https://github.com/git-bug/git-bug/blob/master/doc/design/da... and https://github.com/git-bug/git-bug/blob/master/entity/dag/ex...

I'd love to see this used in the wild for other use cases.

With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.

I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.