[–] 13 points 1 week ago

Canceled subscription after the political statements, but have been putting off moving away from their free tier. Time to buy a domain and go fastmail or mailbox I guess

  • source
  • [–] 4 points 1 week ago*

    Well, yeah. In this day and age all one-person projects with that amount of commits/changes is slop until proven otherwise. That slopcore web page is absolute garbage though. Knowing that it's the bottles dev and that the repo has existed for a year gives it a bit more credibility, even if it is heavily llm assisted

  • source
  • parent
  • context
  • [–] 11 points 1 week ago

    Tried that web page on a few repos, and all it does is check for co-authorship in commit messages. The raven repo started including the assisted by tag three days ago, but the repo itself was created about a year ago. I wouldn't rely on that page for anything useful.

    That said, looking through the codebase and commits a bit, I wouldn't be surprised that LLMs has been used longer than that.

  • source
  • parent
  • context
  • [–] 27 points 1 week ago* (last edited 1 week ago) (6 children)

    How is this different than what wine does though? Looks like it implements the windows apis, just like wine. It was originally implemented in go, with a C++ rewrite started July 31st the original go implementation was removed three days ago .

    By all means, wine is a huge project, probably with a lot of baggage. I'm not pro AI, but I guess translating between apis could be something language models could be good at. Looks pretty sloppy though.

    Edit: based on some twitter posts by the author, looks like the conceptual approach is an NT kernel shim running in user space rather than translating api calls directly. gVisor was mentioned as doing something similar

  • source
  •  

    What are some general recommendations to maintain a set of patches on top of a library distributed as a source tarball? Until now I've been adding the versions to a git repository by deleting previous files and adding the new files in a "upstream" branch, then merging that branch into the main branch which contains my patches. This turned into more work than I expected because they started moving files around and renaming in new releases.

    I should probably be rebasing instead of merging, but are there any other recommendations for this type of situation?

    view more: next ›