<!DOCTYPE html>
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p dir="auto">I want to start by saying that I am genuinely excited
to see Xfce working on a native Wayland compositor. This is an
essential step for the future of the desktop, and I appreciate the
team's effort on this.</p>
<p dir="auto">However, I have some serious concerns about the
decision to write the new compositor in Rust. I understand the
appeal of memory safety, but I think the practical costs are
significant and conflict with Xfce's core principles.</p>
<p dir="auto">The first concern is compilation time. Rust is well
known for its slow compile times, even for incremental builds.
This is a real productivity hit compared to C, which compiles
almost instantly. For a volunteer driven project, long build times
discourage new contributors and make debugging and iteration much
more tedious. This is especially problematic for users on older or
low power hardware, which makes up a large part of the Xfce
community. The CI infrastructure would also need to be upgraded to
handle the heavier Rust build load.</p>
<p dir="auto">The second concern is the supply chain risk from Cargo
and crates.io. Using Rust means pulling in a large number of
external dependencies, which introduces a significant attack
surface that does not exist in a pure C project. A compromised
crate could execute malicious code during the build process. There
is also the risk of typosquatting or dependency confusion. Xfce
has always been trusted because its codebase is relatively small
and auditable. Adding a sprawling dependency tree makes it very
difficult for the team to vet everything that ends up in the final
binary.</p>
<p dir="auto">Beyond these technical issues, I think this choice
goes against the traditional Xfce philosophy of keeping things
lightweight and independent. Instead of adopting a new language
and ecosystem, I would urge the team to implement the compositor
in C using a custom in house approach, just as Xfce has always
done for its core components. This would give the team total
control over the codebase, keep dependencies minimal, and ensure
the compositor remains lightweight, secure, and easy to audit.
This approach is entirely viable and would preserve the fast,
secure, and lean nature that users expect from Xfce.</p>
<p dir="auto">I respect the decision to look at Rust for safety,
likely via smithay, but I believe the trade offs are too large. I
would kindly ask the team to publicly address these concerns and
reconsider the language choice.</p>
<p dir="auto">Thank you for your work on Xfce, and I look forward to
hearing your thoughts.</p>
<p><br>
</p>
<div class="moz-signature">-- <br>
<hr>
<p><em>"I believe that a sane world is a world with only free
software."</em></p>
<p>
<strong>Theron York</strong><br>
CloudNuke<br>
<a href="https://cloudnuke.org">cloudnuke.org</a><br>
<a href="mailto:theron.york@cloudnuke.org"
class="moz-txt-link-freetext">theron.york@cloudnuke.org</a>
</p>
</div>
</body>
</html>