NVIDIA Shares Wayland Driver Roadmap, Encourages Vulkan Wayland Compositors

[wertigon]

Sure, anything is possible in the land of fairies. And the probabilities of that happening over a political spat such as this one?

Status quo maintained: 75%
Redot actually making a dent: 20%
Both die: 4%
Both successful: 1%

The chance is not zero, but not very big either.

[oiaohm]

Sure, anything is possible in the land of fairies. And the probabilities of that happening over a political spat such as this one?

Status quo maintained: 75%
Redot actually making a dent: 20%
Both die: 4%
Both successful: 1%

The chance is not zero, but not very big either.

https://en.wikipedia.org/wiki/XMMS

This is because you have not looked at the history where equal thing happened. Youki, vs Audacious, Yes this was a case that action of upstream with poticial things interfered with Development. Yes Audacious, is the fork.

Its even bet at this point of Redot replaces godot or not. There are two more options I did not include that is godot die or redot die alone. Yes godot is higher to die because they are the one that the the development distributing action.

Status quo does not have large hold in open source world. Libreoffice replacing Openoffice Libreoffice is the fork. Maradb replacing most places mysql is used Maradb is the fork. There is a long list the fork has the advantage or is equal to the parent project that is the way it is when this stuff happens.

This stuff happens I am referring to action that effects development. A pure political for Like the Gimp one these always fail remember this never disrupted gimp project development chain. Banning users from github because something got tits up on X/Twitter end up effecting development.

Yes without the disruption to development redot chances would look like your numbers. Due to distrupting development and the effects that causes its 1/3 Godot remains dominate. 1/3 redot end up dominate. 1/3 both die. Both equally successful is the rare outcome still. This is why you don't want projects getting political in their source repository mainintainership.

[ssokolow]

https://en.wikipedia.org/wiki/XMMS

This is because you have not looked at the history where equal thing happened. Youki, vs Audacious, Yes this was a case that action of upstream with poticial things interfered with Development. Yes Audacious, is the fork.

I was around during that period.

XMMS got forked because the codebase everyone cared about was stuck on GTK 1.2 while "XMMS2" was more of an MPD clone. (Think Perl 5.x vs. Perl6/Raku) That GTK 2.x fork was called Beep Media Player (BMP or BeepMP for short) and it was horrendously crashy. Audacious forked from Beep Media Player because the Beep devs were incompetent at making a GTK 2.x media player that didn't crash every five minutes.

I'd never heard of Youki back in the day and, judging by the summary I read now, it sounds more like Milosz Derezynski (there's a name with some "tantrum-throwing incompetent" memories behind it) was trying to shed Beep's reputation for crashiness by starting over and keeping nothing but the GStreamer backend... no wonder nobody cared since that would make it Just Another Media Player™ from someone with a not-great track record, with a UI and plugin ecosystem even less related to XMMS than QMMP (an XMMS and now Audacious clone written before Audacious started adding a Qt-based frontend and deprecating the GTK-based one).

It had nothing to do with politics and everything to do with Milosz Derezynski being incapable of meeting market demand on technical grounds. (Hell, I ran XMMS, then BMP, then Audacious, and that's why I switched. Audacious was GTK2-based XMMS without the crashes.)

[wertigon]

Yes without the disruption to development redot chances would look like your numbers. Due to distrupting development and the effects that causes its 1/3 Godot remains dominate. 1/3 redot end up dominate. 1/3 both die. Both equally successful is the rare outcome still. This is why you don't want projects getting political in their source repository mainintainership.

That is your take then. Let's agree to disagree here, it doesn't really matter to me whether the thing I use to make games is called redot or godot in any case. It is a wait and see situation.

Song of the day: I love It by Icona Pop

[oiaohm]

I was around during that period.

So was I.

XMMS got forked because the codebase everyone cared about was stuck on GTK 1.2 while "XMMS2" was more of an MPD clone. (Think Perl 5.x vs. Perl6/Raku) That GTK 2.x fork was called Beep Media Player (BMP or BeepMP for short) and it was horrendously crashy. Audacious forked from Beep Media Player because the Beep devs were incompetent at making a GTK 2.x media player that didn't crash every five minutes.

There are problems with this timeline. Youki predates Audacious and another problem is a Youki early patches is in Audacious code base. So Audacious did not fork from Beep but in fact forked from early Youki.

Yes a lot of people who don't look at the Youki vs Beep vs Audacious code based don't wake up that Audacious not based direct off Beep.

I'd never heard of Youki back in the day and, judging by the summary I read now, it sounds more like Milosz Derezynski (there's a name with some "tantrum-throwing incompetent" memories behind it)

You remember the person right. You can see exactly how he managed to screw up development for the early Audacious developers so creating fork Audacious so creating doom for the Youki project he was managing.. Banning a stack of users from github for no particularly good reason as godot did is tantrum throwing incompetence. Youki forum back in the day did the same thing with some early future Audacious developers who were working on youki at the time for talking about crashes because this could be bad PR....

Youki one simple action lost a large number of it developer core and it marketing core. Yes banning people for talking about the crashing issues.

There are other examples when you go looking where the main project harms development process sometimes its like Youki a fairly fast killing of the organ project (5 years roughly). Other cases it takes a few decades for the long term effects to happen.

Its not wise to presume you can mess up open source project development and not have to pay a price for it.

Yes ssokolow there are a lot of applications that people believe they were developed in project 1 then project 2 that in reality project 2 was developed first and then some issue in development happened resulting in a split with project 2 creating project 1. Yes then project 2 ceases to exist. Since project 1 is the winner they write the history as if they never were fork off the project they defeated. This is major source of the false myth that the main project can do bad things and never loss most of the time when in reality the main project loses more often than wins. in the cases where the actions disrupts development even for less than 2 percent of the developers in the project.

[ssokolow]

So was I.

There are problems with this timeline. Youki predates Audacious and another problem is a Youki early patches is in Audacious code base. So Audacious did not fork from Beep but in fact forked from early Youki.

My memory of things agrees with this snippet that software.fandom.com claims originates in a now-deleted Wikipedia article:

Youki is the current media player of the MPX Project. Previous media players produced by the team were Beep Media Player, BMPx, and the never officially released audiosource. Youki shares virtually no code with the older Beep Media Player or BMPx and was instead written from scratch. The only component kept in its basic outline is the BMPx-originated GStreamer-based playback engine, which has since been rewritten and refactored.

I actually vaguely remember the attempt to supplant Beep Media Player with BMPx (and the name BMPx makes sense as a follow-up to BMP) and I wouldn't have known about Youki because I lost interest during the BMPx era.

So, given that I have my memory and a site agreeing that Youki came later, I'm calling [citation needed] on yours.

[oiaohm]

I actually vaguely remember the attempt to supplant Beep Media Player with BMPx (and the name BMPx makes sense as a follow-up to BMP) and I wouldn't have known about Youki because I lost interest during the BMPx era.

So, given that I have my memory and a site agreeing that Youki came later, I'm calling [citation needed] on yours.

https://software.fandom.com/wiki/Youki

There was a line here you missed.

Youki is the current media player of the MPX Project. Previous media players produced by the team were Beep Media Player, BMPx, and the never officially released audiosource.

Beep media player and BMPx and youki come from the same development team.

That site has a false hood that a person can fall for by the wording.

Youki shares virtually no code with the older Beep Media Player or BMPx and was instead written from scratch.

You can pull the source code to early Youki, Beep and BMPx out of debian snapshots there are 100 percent identical source files between all 3.

Yes the words "sharing virtually no code" is not the same "sharing no code". Most of Youki code was rewritten from scratch but not all of it.

https://de.wikipedia.org/wiki/Beep_Media_Player#/media/Datei:XMMS_family_tree_timeline.svg

Yes old time lime used in the german section of the wikipedia is clear "mostly rewritten" that was the original Wikipedia wording not the later deceptive "virtually no code". Also this timeline was based on what the parties were saying not checking the source code if it matches.

Yes I was getting it wrong its BMPx and audacious are in the same time frame. Looking at the source code files from BMPx appear in audacious that don't appear in the prior beep. So audacious is not 100 percent based off Beep original beep there are fragments of BMPx and these fragments are older than audacious and are authored by one of the developers who started audacious..

My mind was thinking of Beep, BMPx and Youki basically being major revisions of the same thing. What they are in reality thinking they have the same lead developer and they have small amounts of common code. By the files you find in audacious the dispute started with BMPx and this first to appear in BMPx code remains in the early versions of youki at debian.

What MPX Project doing is they were having issues lets so rename the project so users think we are a new project so don't hold prior issues against us or go looking for prior issues. Yes completely renaming the project to mark major versions instead of just bumping a major version number. This does make the history messy.