Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GloriousEggroll's Proton has been rebased on Proton 11

github.com

Post reply on HN
Print view View original

11–20 of 51 posts

Re: GloriousEggroll's Proton has been rebased on Proton 11

#11

Post by mostlysimilar »

hackingonempty wrote: post #4
yincrash wrote: post #2

It's interesting to read that an entire video streaming rework was done with AI, but likely won't be upstreamed because of the upstream policy on AI gen code. I wonder if that will ever be re-done using the plan GE outlined in the release notes.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

Or it might come to be that rejecting LLM-authored or LLM-assisted contributions becomes a badge of quality, and users gravitate to them to avoid buggy, inconsistent, or non-performant versions of the same software.

Re: GloriousEggroll's Proton has been rebased on Proton 11

#12

Post by simoncion »

dwroberts wrote: post #10
simoncion wrote: post #9

Earlier quoted context omitted.

[flagged]

I have not needed any of these features to use proton on the games I own so I’m still none the wiser as to who the target is for this or what the context of this fork/its possible merging is

> I have not needed any of these features to use proton on the games I own so I’m still none the wiser as to who the target is for this...

...it's people who need these features and fixes? If you don't need them, then you don't need them, and you don't care about this.

With the addition of this comment, it seems like your commentary here boils down to "Why would I need this fork of this project that solves a specific set of problems that I neither have nor have bothered to understand?".

I do agree that it's reasonable to not waste time learning about problems you don't have, aren't really important if you don't have them, and that you're not interested in learning about, so don't make the mistake of believing that I'm throwing scorn your way.

Re: GloriousEggroll's Proton has been rebased on Proton 11

#13

Post by hackingonempty »

worble wrote: post #5
hackingonempty wrote: post #4

Earlier quoted context omitted.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

They very specifically do not accept AI contributions because there is no way to tell if it's just regurgitating parts of the various Windows source code leaks from over the years ad-hoc, which would be a very costly mistake to make if Microsoft were feeling litigious.

More reason to ditch C, C++, and C#!

Re: GloriousEggroll's Proton has been rebased on Proton 11

#14

Post by ThatMedicIsASpy »

yincrash wrote: post #3
yincrash wrote: post #2

It's interesting to read that an entire video streaming rework was done with AI, but likely won't be upstreamed because of the upstream policy on AI gen code. I wonder if that will ever be re-done using the plan GE outlined in the release notes.

Also really excited about this because there are several games that get kind of borked because they get stuck on an intro video before you get to the game menu without doing any winetricks. > With all of that work done, I am happy to say all of the games listed above now have functional video playback with NO winetricks needed and NO dll overrides needed. No quartz,no dshow, no amstream, no lavfilters, no klite, no r…

Yeah the big left 4 dead clone (forgot the name) had video playback issues for me.

Re: GloriousEggroll's Proton has been rebased on Proton 11

#15

Post by Krssst »

hackingonempty wrote: post #4
yincrash wrote: post #2

It's interesting to read that an entire video streaming rework was done with AI, but likely won't be upstreamed because of the upstream policy on AI gen code. I wonder if that will ever be re-done using the plan GE outlined in the release notes.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

Doesn't wine have various rules to remain a white-room implementation?

Not sure using LLMs which have possibly been trained on leaked Windows sources would be compatible with that. But that's just speculation, I wonder if LLMs possibly using leaked sources for training has been looked into. (probably legally difficult as the investigator would have to access the leaked sources too...)

Re: GloriousEggroll's Proton has been rebased on Proton 11

#16

Post by PalmPilotProMax »

mostlysimilar wrote: post #11
hackingonempty wrote: post #4

Earlier quoted context omitted.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

Or it might come to be that rejecting LLM-authored or LLM-assisted contributions becomes a badge of quality, and users gravitate to them to avoid buggy, inconsistent, or non-performant versions of the same software.

The allure of being just good enough where the bling and hype of features outshine hidden bugs may win out socially.

Re: GloriousEggroll's Proton has been rebased on Proton 11

#17

Post by cwillu »

mostlysimilar wrote: post #11
hackingonempty wrote: post #4

Earlier quoted context omitted.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

Or it might come to be that rejecting LLM-authored or LLM-assisted contributions becomes a badge of quality, and users gravitate to them to avoid buggy, inconsistent, or non-performant versions of the same software.

There's no need to guess, the reasoning is clearly laid out:

“Don't use an LLM tool to generate code. There's no guarantee that the training material of that LLM respects our Clean Room Guidelines, or that its output is compatible with the LGPL.”

--https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...

Re: GloriousEggroll's Proton has been rebased on Proton 11

#18

Post by cwillu »

worble wrote: post #5
hackingonempty wrote: post #4

Earlier quoted context omitted.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

They very specifically do not accept AI contributions because there is no way to tell if it's just regurgitating parts of the various Windows source code leaks from over the years ad-hoc, which would be a very costly mistake to make if Microsoft were feeling litigious.

For reference: https://gitlab.winehq.org/wine/wine/-/wikis/Clean-Room-Guide...

Re: GloriousEggroll's Proton has been rebased on Proton 11

#19

Post by cwillu »

hackingonempty wrote: post #13
worble wrote: post #5

Earlier quoted context omitted.

They very specifically do not accept AI contributions because there is no way to tell if it's just regurgitating parts of the various Windows source code leaks from over the years ad-hoc, which would be a very costly mistake to make if Microsoft were feeling litigious.

More reason to ditch C, C++, and C#!

The language wine is written in is irrelevant, the source is still tainted.

Re: GloriousEggroll's Proton has been rebased on Proton 11

#20

Post by cedws »

worble wrote: post #5
hackingonempty wrote: post #4

Earlier quoted context omitted.

It might come to be that maintainers have to begin accepting llm-authored or llm-assisted contributions just to maintain control of the project. Otherwise users will gravitate towards forks that offer the functionality they want.

They very specifically do not accept AI contributions because there is no way to tell if it's just regurgitating parts of the various Windows source code leaks from over the years ad-hoc, which would be a very costly mistake to make if Microsoft were feeling litigious.

Tech companies shouldn’t be able have it both ways and say that copyright doesn’t apply to LLM-generated code only when it benefits them.
Post reply on HN