Do not Switch: The tragedy of suyu (or: How to not handle a fork)

If you have been keeping up with recent emulator news, you surely might know about the yuzu emulator being taken down by the big N company. The reasons for such takedown are, to this day, quite unclear due to the many gray areas traversed by emulators in general. The aftermath for the developers also has remained a mystery.

What is clear is that the yuzu team has decided to keep their heads down and pay the lawsuit. This move will probably set them in debt for the next 20 years, yet I cannot blame them for choosing the path of least resistance with such a vexatious company like big N.

On top of the exorbitant payment requested, the team also had to take down their GPLv3 licensed code off of GitHub and replace their website with a message. This was probably requested by big N to demonstrate, in classic Japanese fashion, how they can bend anybody at their will if you ever have to deal with them.

Because the yuzu source code is open source and under a copyleft license, it is obvious to see how the project could not be killed that easily. Yet, forks could also die, and not by stabbing them with a DMCA.

Let us discuss a bit about the situation of suyu, currently one of the two forks attempting to improve upon the yuzu source code.

The faith of glass-made cutlery

At this point, yuzu forks started appearing out of the blue. Most of them claimed to have the latest checkout of the code. The most notable ones were yuzu-mirror, suyu, nuzu and, later on, sudachi.

yuzu-mirror was, from the beginning, never intended as a development platform for the Switch emulator, and has therefore kept a distance from new pull requests.

Some news outlets started picking up these repos and spun them as “official yuzu continuations”. The person behind nuzu was caught red-handed setting up a Patreon to accept money, regardless of their total lack of skill: this brought utter death and mistrust upon the fork, leading it to be blank shortly after. Having a Patreon for development was also speculated to be one of the core reasons why the lawsuit against yuzu was so effective.

Suyu, instead, was aiming at resolving the legal issues that have been found and weaponized against yuzu. ArsTechnica has a genuinely interesting article on how they would like to achieve that, which I would like to quote on the matter:

After consulting with an unnamed “someone with legal experience” (Sharpie would only say “they claimed three years of law school”), the Suyu development team has decided to avoid “any monetization,” Sharpie said.

Considering this unnamed person might be the only “legal” consultation the suyu team might have access to, I forecast some trouble down the road.

Reinforcing that fragile fork

At this point, suyu started its rebranding process: a Discord server was created, a new W.I.P. website appeared and folks started spamming their GitLab instance with README modifications and name substitutions. Thus far, no new code was added.

While the suyu people were busy modifying their README, a new fork named sudachi came along. The fork was made by an experienced developer for the Apple ecosystem, which also had an interest in emulators.

As of the day of writing, sudachi does not currently accept contributions, but has made some changes that will be found in suyu later on.

Let the crystalline rain commence

Now that there was seemingly a real suyu team and the infrastructure was set up, the repo started seeing a bunch of “contributions”. These were not only README edits or CI scripts additions, but also assets and “code”.

Talk is cheap.

The suyu people seem to have a grudge against clang-format. Other than that, it is very hard to see proper emulator code written and be properly reviewed to take advantage of it.

Let us take a look at the amount of commits against clang-format since yuzu was forked:

9858de7fceedece0715e Run clang-format
de83c5e6a6a1ca6cbb60 fix: clang format
18baf880c4ebd41bdd58 fix: clang format
3037f0b869aa129acb0a Fix clang-format error
2ceae9a0c121fe6f71e2 Nmajkic/clang fix
70d0df5e551aa087b088 fix: Clang fix part 2: Electric bogaloo
94a84f5943e68dce2f28 fix: CLang fix
c433758ed0083071f2a0 Run clang-format
b4163895330259a8d1fb Run clang-format
ab3e51e50d5cc45594ff fixes clang format error in !193
b6ad090424bd770e5e49 try to fix clang again
77e9b7b59bb31bf93e4d try 3 fixing clang omfg its just a space
fd1ec51496917ee656e9 try 2 fix clang
eb306775c616c4ba6db5 fix clong format
...

I have added an ellipsis, not only because I might have missed some, but also because I am sure they will keep going.

Instead, let us take a look at some proper code commits which might take advantage of all the clang-format modifications. We will analyze the two following ones to also understand suyu's coding standards:

Analyzing 7215ac95437dd041fc40

In the first commit, we observe... memset() being used on an std::vector to zero it out? What?

Let us check the author's justification for this code, which was rigorously not given in the commit message but can be found in the git instance's PR body:

nullequal says:
as the title says this fixes issues with NROs not loading at all

the real problem was that out_control was filled with useless junk of instead of being filled with zeros

Well, this does not justify the use of memset() and does not answer why the vector is supposed to be zeroed out.

On top of that, there seems to be a complete misunderstanding about the role that std::vector was supposed to have: std::vector<u8>& out_control is indeed supposed to be filled with “junk”, being just a buffer.

There are many alternative, safer ways to zero out a vector (or maybe even clear it), but this commit does not seem to look at the root of the issue: additionally, both reviewers approved the changes and one of them even complimented the commit author. This brings the number of people who likely did not understand the code to three.

Considering that the query “how to zero out a vector in c++” gives more reasonable, different results on any search engine, I highly suspect that the code has been suggested by some form of LLM, but I will leave that as an exercise to the reader.

Analyzing 8755d2bad429c393d693

This commit seems to aim at requiring both prod.keys and title.keys for the emulator to be usable.

The logic used in the commit's code is absurd: it only checks if both files are present in the required directories without validating the keys.

The most amusing part of this code is that the function it is in, KeyManager::BaseDeriveNecessary(), is called by ContentManager::AreKeysPresent(). Because the code returns true when these files are not found, it implies that the keys are actually present on the system.

Since the GitLab repository has been struck by a DMCA and knowing the author's commit history, it is very likely that this commit was pushed to the repo without being reviewed at all.

Show me the code. Yours.

The most astounding aspect about their entire development is the QA. In fact, you will find loads of commits with nonsensical messages and no bodies, many of whom get reverted.

Let us take this snippet:

444a200eef33193403ab Upload files to "img"
2a672fac30cd3a7b5780 revert 9e223759e0e804514c318f282038fc0e12c8a180
9e223759e0e804514c31 Add img
b5c02fe14a0739add8e7 Update README.md
36ede797f3dd48c85402 Vulkan validation error fix.
ce8f3e802edc216caebf Use proper SPDX-FileCopyrightText for Sudachi. Corrects db647d915d
040893da00a4d42f9737 formatting
876d7f90b60e3fed88b6 Add option to log synchronously, add tooltip to log filter.
db647d915d575a995f9b Including sudachi Emulator Project as a copyright owner.
b3e989343dd0702e302a Added support for Princess Peach: Showtime!
09578d522b203458d819 revert 925ce2fad34aeb890103d52ea50c151a94fdcd1f
9b77efe2b43ef8d93e89 revert eb306775c616c4ba6db5fadafd19b509ae16f709
224cac988e0bd275265f revert fd1ec51496917ee656e9405826d3d26444b2a04c
43c1a4c64349243e9f06 revert 77e9b7b59bb31bf93e4d2156e614f8944cc542af

Keep the sudachi copyright commits in the back of your head for now.

From such commit history, most professional software developers would stay away from such an open source project that is lacking basic standards. There is clearly a complete misuse of git's capabilities that currently make tarballs and a CHANGELOG.md look more attractive.

In addition, this should not be touted by the suyu team as activity to prove that the project is alive and well. If anything, it proves quite the opposite due to many of these daily commits being nothing-burgers.

I cloned it: I own it

Suyu has seen itself in hot water for violating the GPLv3 license that yuzu has long been using. Initially, the entire project got relicensed under MIT without anybody's permission with commit f1e4595ebfa73e3ffb7f ("Initial commit").

Such important change is buried between others that simply add fuel to the fire:

be9cfdc37de8d48c707a try 2 of fixing centering on readme
c53d25fa86cb01754046 try 1 of fix readme centering issues
2562e0248b71a0858104 fixed issue #1, changed to GPL v3
868116c86ad8445bf866 updated metadata of readme
c24e8c27d26c0c1280d6 added logo
6323c345cd79baaf4efb added linux legacy artifacts download
e4bcdb21fb1bc83a7233    deleted:    LICENSE.txt
154cf56b0dfd0d788ee8  On branch master  Changes to be committed:        modified:   README.md
7687666d32dab3cd8249    modified:   README.md
f8eb42e2930bc5da9c8a added legacy artifacts download
f1e4595ebfa73e3ffb7f Initial commit

Even after reverting to GPLv3 (2562e0248b71a0858104 ("fixed issue #1, changed to GPL v3")), the SPDX headers were attacked with a slew of blind s/yuzu/suyu/g, removing the necessary copyright for the yuzu devs.

Somebody on the suyu team was at least smart enough to notice the issue in one of these junk pull requests and has, thankfully, avoided catastrophe. This copyright fiasco might have also affected code imported from sudachi if it was not caught in time.

Disco(a)rding you all

One issue that is plaguing many open source projects by the day, including suyu (and to great extent, LineageOS), is Discord as the sole form of communication between the core team, contributors and regular users.

Discord is not only a well-known proprietary, data-abusive company, but it also gatekeeps users that do not have an account from accessing chat logs that could be essential to them.

While many might see requiring a telephone number for new accounts as a spam protection measure, it is mainly used to track your activity online and sold as personal data. Discord is not the only player in the arena utilizing such tactics to gather user intel.

Those who use only open source software will eventually find themselves unable to contribute, gather help or simply interact with people who share the same interests. It can be considered despicable to use such platform considering the many great alternatives out there (e.g. Matrix, Rocket.chat, XMPP, IRC, etc.).

Since the suyu project was now forced to have its own git instance, they require everybody to have a Discord account. Through it, one must message the developers to obtain permissions for creating repositories, which also covers forking to contribute.

While not mentioned, if you do intend to contribute code but lack a Discord account, you can write to admin atsymbolhereIguess suyu dot dev. As usual, be civil and keep spam away from them.

Fin.

I will quote mikael110 from ArsTechnica's forum to sum up the situation:

If you actually do some research into Suyu it will very quickly become apparent that it is run by kids who have literally no clue what they are doing.

Take their title.keys requirement for example, which is one of the only noteworthy changes from the original Yuzu code. It is implemented using a pure name check. In other words the emulator just requires you to have a file called title.keys. Even a 0 byte file is sufficient. It's apparent that nobody currently on the team seems to have any serious programming skills. Certainly nothing that would enable them to develop an emulator.

The entire project is pretty much a joke, which frankly does not deserve the airtime Ars is giving them.

What they are saying on the forum is true. Sadly, suyu is not only lacking real developers, but is also smearing the source code in ways that make it appalling for external contributors.

At this point in time, suyu would require a hard reset: a force-push with all the commit disasters fixed, actual Pull Request reviews by developers (who know what they are doing) and more open communication without proprietary channels.

There is not much one can currently do for suyu. A force push by somebody might lead us to an xz-like incident of backdoors inside past commits. Yet, considering the dire situation, it is more than possible to pull off a Trojan inside their Pull Requests since there is currently no real understanding of the emulator's source code (and likely source code in general) by most of the team.

I hope the suyu project will, eventually, get somebody on board that has enough expertise to steer everything in the right direction. Otherwise, sudachi or yet another fork of yuzu's code will be required to keep the Switch emulator scene diverse and going.