XLibre
Consider Rust migration for X11 modernization #27
Replies: 60 comments 103 replies
-
|
Their strategy now is to brigade and inundate the project with issues such as these. |
Beta Was this translation helpful? Give feedback.
-
|
@morr0ne, who will support Rust sections of the code? When whole zoo prog lang stacks appears, entry threshold for developers increases, as they have to learn Rust to check contributors code for vulnerabilities. If maintainer doesn't know language, it's even easier to suggest vuln or backdoor. |
Beta Was this translation helpful? Give feedback.
-
|
Isn't the linux kernal taking the approach of just replacing one part of the code at a time. Not so much a fork but you pick one small part that benefits the most from Rust. Then rewrite that one part in Rust. Over time, the project will have more and more Rust code. You don't have to worry about maintaining two projects because it is the same project. Your just updating the code one section at a time. |
Beta Was this translation helpful? Give feedback.
-
In the case of the Linux Kernel, it appears that there is CONFIG_RUST, which can be used to opt out of the use of a Rust compiler. Does this remove some kernel features? If so, I have not encountered any kernel code for features I've been interesting in that did not compile without this flag... so far. |
Beta Was this translation helpful? Give feedback.
-
|
This makes me wonder if the the parts rewritten in Rust still have a non Rust version you can fall back on. |
Beta Was this translation helpful? Give feedback.
-
I had the same thought. Seems more likely to me that the code which requires a rust compiler is just code that I don't use, (there's a lot of code I don't use), and that CONFIG_RUST simply hides those options, or that I have misunderstood the CONFIG_RUST flag... or some other, deeper level of misunderstanding on my part. I suppose I'll find out one day, when I get bit by it. |
Beta Was this translation helpful? Give feedback.
-
|
And it has proven to be a nightmare for all involved, with the 'lead Rust maintainer' walking away a few months ago. Multi-language code bases are best avoided. As to porting to Rust: it's just quicker and easier to do it from scratch. That way, you don't need to worry about "keeping people happy", which wastes a huge amount of time for everyone involved. Rust just doesn't sit well with an existing C codebase, because Rusts directly contradicts many of the constructs used in C, which is the whole point of Rust. It is common for evangelists/zealots to try to parasitise an existing project to promote their 'new shiny thing', because they want to co-opt the existing userbase. Sometimes, it's valid and worthwhile and happens on merit. More often-than-not, it is awkward and ultimately a failure that just winds everyone up. For example, if this discussion of Zig, rather than Rust, it would be more valid, because Zig aims to be a 'better C', rather than something opposed to C. |
Beta Was this translation helpful? Give feedback.
-
|
Example zoo langs is modern Linux kernel, where many driver developers cannot support them because they were rewritten to Rust (example DMA), as a result, it is easier to abandon support for this driver, although it may also have vulnerabilities. But developers rewrote DMA, and no one dares to check it, because lang stack is different. |
Beta Was this translation helpful? Give feedback.
-
|
Fair points. I was thinking optional modules, disabled by default, separate maintainers, clear C interfaces. Like how Mesa has different driver backends. Core X11 stays C, Rust stuff would be completely optional plugins. No mixed codebases or forced learning curve. Regarding backdoors, well, malicious code is malicious regardless of language. The difference is Rust prevents entire classes of memory safety bugs that C allows (buffer overflows, use-after-free, etc), so if anything it would be harder to have a vulnerability assuming you are using safe code |
Beta Was this translation helpful? Give feedback.
-
|
Is there a issue with trying to replace different parts of Xorg core with Rust at a pace of one small function at a time? It seems like the best way to do it while not wasting resources on two branches. |
Beta Was this translation helpful? Give feedback.
-
I guess it would only work if there were people committed to long-term maintenance, not just initial implementation. But that goes with any language still, if you want to mantain something in C you need C developers |
Beta Was this translation helpful? Give feedback.
-
|
Rust works better for the kernel as low level device drivers need more stopgap error corrections. Xorg runs on top of what the Linux kernel does already using the DDX and GLX layers as a manager to do drawing. We're perfectly fine with using C because nothing is really added to what the kernel already does. C is easier to maintain for this purpose. |
Beta Was this translation helpful? Give feedback.
-
|
There have been multiple posts here referencing programs written in rust with a history of persistent memory leak issues. It sounds like you are in agreement that rust does not "remove the possibility of exploits". |
Beta Was this translation helpful? Give feedback.
-
I am not experienced enough to talk about this. What I know is the general description of Rust making certain bugs impossible. In a statistical analysis, those categories of bugs were responsible for over 80% of all exploits. It will not remove all vulnerabilities as there is still the other 20% but removing 80% is a pretty major improvement. |
Beta Was this translation helpful? Give feedback.
-
Neither am I. Almost certainly your experience with rust far exceeds mine. but I'm old enough to have seen a great many claims made on theory and model, that did not pan out when empirically measured. I'm skeptical. When I hear extraordinary claims, I look for extraordinary evidence. |
Beta Was this translation helpful? Give feedback.
-
|
BTW, one of my favorite things is the Type-State pattern, which can be done in many langs, but Rust move-semantics ensure that old states cannot be accidentally reused. Thus, move-semantics isn't just for RAII, it can be used for other things |
Beta Was this translation helpful? Give feedback.
-
Leaking is safe. But I do agree that some Rust devs can be a bit careless about memory, but this also happens in any other community. Sometimes the leaks are somewhat outside of the dev's control (see alacritty/alacritty#5438). And the way |
Beta Was this translation helpful? Give feedback.
-
|
see I think a colab would be a wonderful idea. |
Beta Was this translation helpful? Give feedback.
-
Perfect answer to this Issue, I think @metux can be closed. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think X11 needs to be Wayland like. That is the whole reason most people got into open source in the first place. I oppose Rust on principle because of how people act as if anything Rust is somehow superior because it is written in Rust. Horses for courses. If the goal here is to simply implement the same dog crap that they are trying to shovel out, sure waste time reinventing the wheel. |
Beta Was this translation helpful? Give feedback.
-
|
Over 80% of all exploits found would have been stopped if the code was written in Rust. |
Beta Was this translation helpful? Give feedback.
-
Is there some line of reasoning available to me that might allow me to reach that conclusion? |
Beta Was this translation helpful? Give feedback.
-
|
Rust makes certain types of bugs impossible. There was a statistical analysis and it showed that those categories of bugs were responsible for over 80% of exploits. Trying to find the article, I found this. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/
Rust would make it so that memory safety bugs do not happen. |
Beta Was this translation helpful? Give feedback.
-
|
I want to add that, IIRC, Google made another study where they found a "paradox": Writing new code in Rust is better than rewriting. They found that the relative amount of security vulnerabilities decreased more dramatically when implementing new features in Rust (paraphrasing), but rewriting code had negligible improvements. As much as I love Rust, I agree that the codebase must be refactored before any rewrite happens |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, but Rust is like cancer, trying to encroach into everything, just because it isn't Rust. There are surely merits about Rust, if properly implemented. Otherwise I'd suggest to write that thing you want to overtake from scratch yourself. Edit: I just read about that Rxserver implementation. Looks interesting and I wish it best luck. |
Beta Was this translation helpful? Give feedback.
-
|
Does @morr0ne intend on implementing the Rust code? |
Beta Was this translation helpful? Give feedback.
-
|
Rust is nasty, I agree with the comment above ^^ |
Beta Was this translation helpful? Give feedback.
-
|
Rust is really useful for certain types of work, but I think in the mature xserver codebase it would be hard to introduce without quite a bit of pain. Again, I really do understand the ill will that the Rust community and its orbiters have made for the language, but it is an exceptionally productive programming language for writing systems. |
Beta Was this translation helpful? Give feedback.
-
|
Sadly, that is the problem with many open source projects. It is not just a Rust issue. |
Beta Was this translation helpful? Give feedback.
-
ALVR is absolutely glorious https://github.com/alvr-org/ALVR C/C++ are an accident waiting to happen and should only be used when absolutely necessary and even then preferably only by developers with a very large amount of enterprise level experience developing exclusively in C/C++. Rust may indeed be nasty (or not), but for anything outside of that tiny set of use cases it is proving itself to be the best we have. |
Beta Was this translation helpful? Give feedback.
-
The focus needs to stay on cleaning and fixing up the code we have, not rewriting everything to suit a narrative. If one day we get to a point where we can start recoding the DDX drivers in Rust, for example, then we can. For now, focus the efforts into C/C++. |
Beta Was this translation helpful? Give feedback.
-
|
I like the approach of just rewriting one small function at a time in Rust. It doesn't need to be a sprint. Pick one small part of the code, and rewrite it in Rust. |
Beta Was this translation helpful? Give feedback.
-
|
"Toxic community" seems a bit over-the-top considering the author of this discussion just politely explained why Rust would be a nice alternative for X11Libre. And suspicions towards the Rust and LLVM projects is very weird here considering there is no incentive to backdoor a compiler or compiler infrastructure, because it would be found very easily and destroy the reputation of such project. This discussion is more leaning now towards senseless paranoia rather than debate on the topic of how and with what X11 should be rewritten. |
Beta Was this translation helpful? Give feedback.
-
|
I'm really puzzling myself, why all these people who think that Rust is so better than anything, just make their own application instead of trying to do do a parasitic takeover. Oh, I forgot, if you are making your own version of a software, you cannot overtake an already grown community, have to earn trust and merit for yourself. That does not really gel well with their parasitic religious crusade, I guess, also not match well with the need to shout down everything other that is not their holy scripture. For example, https://github.com/x11rs/x11server could use a hand. |
Beta Was this translation helpful? Give feedback.
-
|
Exactly, Don't let them fool you, They have an agenda and always have. |
Beta Was this translation helpful? Give feedback.
-
|
Rewriting the entirety of XOrg in Rust is not a realistic undertaking. At that point you might as well just make a new server. Plus, Rust still doesn't have their ABI situation figured out last I checked. C++ has a lot of standard library components that can make routines easier to keep safe, it's arguably a better Rust than Rust if you go that route, but it's also a very complex language that can introduce ambiguity. Zig is generally a much more sustainable option if we are really looking into modernizing a codebase, as it would integrate directly into an existing C project and toolchain, and avoids nearly all of Rust's most obvious design shortcomings. But then I have to ask if this change is actually worth entertaining. If it isn't broken or problematic why are we fixing it? C is only as dangerous as much as your engineering skills are lacking. If it's necessary, then Rust is one of the the worst possible suggestions, sitting next to more mature standards like Ada. You also need to keep portability in mind because XOrg and by extension XLibre is not just available on x86 Linux. It's on all kinds of CPU architectures and Unix-like operating systems, and there are even forks outside of that for systems like Windows, which are dependencies of software used by thousands of people (example off the top of my head: FontForge). Not just the portability of the language but also the available toolchains. C and C++ are the most pragmatically portable languages to ever exist and that's not gonna change soon. metux had this to say: https://github.com/orgs/X11Libre/discussions/52#discussioncomment-13495804 |
Beta Was this translation helpful? Give feedback.
-
|
If you were to pick a somewhat simpler subset, say 14, you might be onto something for the re-write front. Be a smidge more maintainable and approachable and likely to happen over a Rust move. Moreover, whatever we all do here needs to make sense. I don't see Rust magically fixing everything...I just see a bunch of proponents doing the SAME stupid crap that kept me from bothering about the language in the first place. A bunch of zealots trying to force their pet language down everyone's throats. Wonder what people would think about Forth? |
Beta Was this translation helpful? Give feedback.
-
|
The poor rewrites all to rust while the rich just uses pascal.
|
Beta Was this translation helpful? Give feedback.
-
|
Oh please... Read coders do everything in binary! 1s and 0s as far as rhe eye can see! Mwahahahaha!!! |
Beta Was this translation helpful? Give feedback.
-
|
Absolutely. That's how I wrote my first program. From front panel bat handle switches. |
Beta Was this translation helpful? Give feedback.
-
If you ever dream in binary, pray you never see a 2. You do, wake up immediately. 💀 |
Beta Was this translation helpful? Give feedback.
-
|
you mean an 10? There are two kinds of people in this world: Those who put people into two categories and those who don't. |
Beta Was this translation helpful? Give feedback.
-
|
0011000011110011-0000111011101211 |
Beta Was this translation helpful? Give feedback.
-
|
you had me at 0x30f3ee |
Beta Was this translation helpful? Give feedback.
-
|
The question then leads to...is it appropriate to move to a new version of
the protocol that IS secure without breaking everything?
Wayland was proposed to be a solution and 10 years later it's still not
there...much like PulseAudio was lauded as one and never really got there.
I see what's been done up to this point as throwing out the baby with the
bath water with Wayland. It is more a solution looking for a place to
happen. Has been from day one, really. When you gloss over functional
requirements with glib responses like they have all this time on how it's
supposed to do <X> and then it never really does... In the end, what we
need is something that WORKS. X11, for all of it's warts does work even if
insecure in places. Wayland DOESN'T really.
…On Fri, Jun 27, 2025 at 3:38 PM The Real Edward Cullen < ***@***.***> wrote:
To clear up some misunderstandings/misconceptions about Rust:
Rust only addresses one sub-set of problems, specifically, memory
corruption and thread-safety. It is not a panacea - there is not silver
bullet in software engineering. There are a whole host of *other*
problems that no language can solve. For example, the old way X11 supported
remote connections is inherently insecure and I believe that it is
impossible to fix them, without changes to the protocol.
Further, multi-language code bases are a nightmare. Even mixed C and C++
code (given that C++, definitionally, a super-set of C), become an awful
mess and are more difficult to maintain. Integrating a language like Rust,
which is based on a radically different paradigm and toolchain, into a C
codebase is just nightmare fuel!
From both an X11 ecosystem and a Rust evangelism perspective, it would be
better for a Rust developer(s) to do a ground-up rewrite in Rust, using the
current X server as a template/guide. This would enable them to take an
uncompromising approach to using all the Rust features they like and
gaining all the benefits, without being held-back by chunks of 'legacy'
code.
The result would be 2 competing implementations. 1 which is 'old' and a
known quantity, the other 'new' and 'modern' and perhaps more capable. By
having the alternative to compare to, the Rust team would be able to make
direct comparisons on code size, performance, safety, etc. If Rust is what
it is claimed to be, it would be the obvious choice to switch to and no one
will complain (not even me!)
—
Reply to this email directly, view it on GitHub
<#27 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF6COZ6LFRFJW77F46ROD3FWTVRAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRQGEZDINI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
" And suspicions towards the Rust and LLVM projects is very weird here
considering there is no incentive to backdoor a compiler or compiler
infrastructure, because it would be found very easily and destroy the
reputation of such project."
This naively presumes that the actors in question are all caring about a
reputation of the project.
Subborning of compilers, etc. happens ALL THE TIME.
https://01.me/en/2014/11/insert-backdoor-into-compiler/
C'mon, this is simple black/grey-hat crap folks. You should know better
than to make such remarks. You can't be serious otherwise. Not really.
…On Mon, Jul 7, 2025 at 6:06 AM esther ***@***.***> wrote:
"Toxic community" seems a bit over-the-top considering the author of this
discussion just politely explained why Rust would be a nice alternative for
X11Libre. And suspicions towards the Rust and LLVM projects is very weird
here considering there is no incentive to backdoor a compiler or compiler
infrastructure, because it would be found very easily and destroy the
reputation of such project. This discussion is more leaning now towards
senseless paranoia rather than debate on the topic of how and with what X11
should be rewritten.
—
Reply to this email directly, view it on GitHub
<#27 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF6CK7UJHOUZ7NPJWKEI33HJIEFAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRYGI3DSMA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Rust is probably a good tool for some of this, but as some have
highlighted- it's more than just languages.
Also worth note: Rust evangelism is probably not a good, wise thing to be
doing people- you want it IN the mix, not driven off. Commentary about C
being unacceptable, etc. doesn't help you in the slightest there.
…On Thu, Jul 10, 2025 at 12:31 PM Frank Earl ***@***.***> wrote:
" And suspicions towards the Rust and LLVM projects is very weird here
considering there is no incentive to backdoor a compiler or compiler
infrastructure, because it would be found very easily and destroy the
reputation of such project."
This naively presumes that the actors in question are all caring about a
reputation of the project.
Subborning of compilers, etc. happens ALL THE TIME.
https://01.me/en/2014/11/insert-backdoor-into-compiler/
C'mon, this is simple black/grey-hat crap folks. You should know better
than to make such remarks. You can't be serious otherwise. Not really.
On Mon, Jul 7, 2025 at 6:06 AM esther ***@***.***> wrote:
> "Toxic community" seems a bit over-the-top considering the author of this
> discussion just politely explained why Rust would be a nice alternative for
> X11Libre. And suspicions towards the Rust and LLVM projects is very weird
> here considering there is no incentive to backdoor a compiler or compiler
> infrastructure, because it would be found very easily and destroy the
> reputation of such project. This discussion is more leaning now towards
> senseless paranoia rather than debate on the topic of how and with what X11
> should be rewritten.
>
> —
> Reply to this email directly, view it on GitHub
> <#27 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABKF6CK7UJHOUZ7NPJWKEI33HJIEFAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNRYGI3DSMA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
The idea that a compiler backdoor would be found easily and discredit the project is not born out by history. A compiler backdoor would only exist in the wild in binary form, and written competently, would not be easy to detect. It could be introduced at any point where a binary is copied, and it's origin would therefore be difficult to know with certainty. This is why trust can never be factored out of security, only minimized and managed. Ultimately, each of us must individually decide where to place our trust at any given moment, and reassess at each subsequent moment. Security is always a "cat and mouse" game, and can never be "achieved". |
Beta Was this translation helpful? Give feedback.
-
|
Rust doesn't prevent memory leaks: https://doc.rust-lang.org/book/ch15-06-reference-cycles.html https://nvd.nist.gov/vuln/detail/CVE-2025-1974 is enabled by https://cwe.mitre.org/data/definitions/653.html. The only things that Rust prevents are rookie mistakes like https://cwe.mitre.org/data/definitions/416.html and https://cwe.mitre.org/data/definitions/415.html |
Beta Was this translation helpful? Give feedback.
-
memory leaks are not a cause of CVEs element size being greater than 8 in would. Does it? |
Beta Was this translation helpful? Give feedback.
-
Yes they are. CVE-2025-1634 and CVE-2025-5777 are two I found via Google. |
Beta Was this translation helpful? Give feedback.
-
|
I meant RCEs and one of those isnt a memory leak, its a buffer overrun, which rusts memory protection would have prevented. There is nothing that can be done to prevent memory leaks completely, only make them harder, because applications can always request memory faster than they release it, and most of the time that is actually a desirable situation. |
Beta Was this translation helpful? Give feedback.
-
|
Moot discussion. If running valgrind on unit tests is too much to be arsed there's nothing that can help |
Beta Was this translation helpful? Give feedback.
-
|
Please close this thread. It's flame bait. |
Beta Was this translation helpful? Give feedback.
-
|
Precisely. Security doesn't come from a language or tools.
Locks are to keep the honest and the Stupid, well, HONEST.
You shouldn't be relying on your tools to SAVE you- it's one of the biggest
gripes I have with the proponents of Rust. They delusionally believe that
it's INVINCIBLE to hear them.
It's a good language...maybe...we'll see for real soon enough over time.
But to think it's the best thing since sliced bread and C/C++ is too
dangerous? Yeah, that comes across as the person proposing that needing
serious mental health care.
…On Fri, Jul 11, 2025 at 2:07 PM mSparks ***@***.***> wrote:
*My* concern, was for the likelihood that Rust *is* the compromised tool
chain, given the expressed intent of those creating it and promoting it's
use, and the fact that only Rust can compile Rust.
Sure, however, C definately is, Snowden leaked documentation tools to
exploit them when he defected, aiui NotPetya already abused them
(compromised MSVC).
Rust itself outputs LLVM bitcode which is then compiled to hex, you can
and should use tools like
https://llvm.org/docs/CommandGuide/llvm-bcanalyzer.html
to check that stack isn't compromised. LLVM itself bitcode-> hex could
also hide demons, but that likely applies equally to C/C++ and Rust.
Basic rule of thumb for anything security sensitive is to assume
everything is compromised and layer protections to minimise risk and
exposure.
—
Reply to this email directly, view it on GitHub
<#27 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF6COQRIIEIPBCDBBIN733IADPTAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGNZTGQ4TMOI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
meanwhile, in the real world https://despairlabs.com/blog/posts/2025-07-10-an-openzfs-bug-and-the-humans-that-made-it/ |
Beta Was this translation helpful? Give feedback.
-
That's not a memory bug, it's a logic bug. Rust would have not prevented it. The Rust example gives a compiler bug because the author he made the psize and asize different types, which you can also do it in C, and you're not required to do in Rust. |
Beta Was this translation helpful? Give feedback.
-
And rust isnt just about protected memory access, it's benefits span the entire toolchain, while simultaneously getting performance within the margin of error vs C. And no, C doesn't have anything close to Rust in terms of the type system, C will quite happily let you read and write a million 16 bit ints into a single 32bit int structure, what benefits are you claiming that offers (that aren't ms sharepoint compromise levels of malicious) |
Beta Was this translation helpful? Give feedback.
-
|
I want to add that, since Rust's type-system is similar to Haskell's, the compiler can (in theory) statically check that a program has 0 bugs of any kind (assuming the program is not Turing-Complete at runtime or compile-time). And the existence of Depending on the actual requirements for a particular program to be considered "bug-free", that can be trivial, tricky, or really-hard to communicate to the type-checker. The simplest example being |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for your contribution! We currently restructured the "Ideas" discussions and accordingly this discussion will be moved to the Good Ideas For Later category. |
Beta Was this translation helpful? Give feedback.
-
|
X11's cooked |
Beta Was this translation helpful? Give feedback.
-
|
Are we STILL going on and on about this?
If you want to do it all in Rust...do your own Fork. Seriously. In my
estimation, it will take a TREMENDOUS amount of time to, "redo," all of
it. So, if it's not and all and you'll fix all failings, you should be
able to, in 6 months, right, produce the core of X11 for use and prove your
point. No? Then why are you pitching this?
…On Tue, Jul 22, 2025 at 3:26 AM mSparks ***@***.***> wrote:
meanwhile, in the real world
https://despairlabs.com/blog/posts/2025-07-10-an-openzfs-bug-and-the-humans-that-made-it/
That's not a memory bug, it's a logic bug. Rust would have not prevented
it. The Rust example gives a compiler bug because the author he made the
psize and asize different types, which you can also do it in C, and you're
not required to do in Rust.
And rust isnt just about protected memory access, it's benefits span the
entire toolchain, while simultaneously getting performance within the
margin of error vs C.
And mo, C doesn't have anything close to Rust in terms of the type system,
C will quite happily let you read and write a million 16 bit ints into a
single 32bit int structure, what benefits are you claiming that offers
(that aren't ms sharepoint compromise levels of malicious)
—
Reply to this email directly, view it on GitHub
<#27 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABKF6CIO4V7QZ3P4XL4CDTD3JXYSZAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBUGQZDMNY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
why, when exists. |
Beta Was this translation helpful? Give feedback.
-
So you admit, the the rust zealots, just want to do a parasitic unfriendly takeover of established projects and claim that then their own instead of concentrating proving the merit of their holy language on their own? |
Beta Was this translation helpful? Give feedback.
-
0% chance I write any C for xserver. maybe help test a bit, but I have no interest in being the next. https://m.youtube.com/watch?v=AN_3ps5bl7o If I'm a "zealot" for any language it would be java, but not much room for that here. so no idea wtf you are talking about. Im mostly interested in new xforwarding features, something html/js would be nice, is that something you are saying you are willing to write for me for free? I wouldnt ask, but you seem to be insisting. |
Beta Was this translation helpful? Give feedback.
-
And that makes you a memory management expert?
But you're calling first |
Beta Was this translation helpful? Give feedback.
-
|
Wayland was pitched much in the same manner as y'all are doing for Rust.
Where is it? Oh, wait, that's right- it's not ready for use and we're
looking at picking up the mess made by 10+ years of this with a clean up of
X11 and a bit of modernization so we have an answer all can use.
If you're not going to be there as quickly as I imply there, you're a
never-ran with it.
…On Wed, Jul 23, 2025 at 11:51 PM Frank Earl ***@***.***> wrote:
Are we STILL going on and on about this?
If you want to do it all in Rust...do your own Fork. Seriously. In my
estimation, it will take a TREMENDOUS amount of time to, "redo," all of
it. So, if it's not and all and you'll fix all failings, you should be
able to, in 6 months, right, produce the core of X11 for use and prove your
point. No? Then why are you pitching this?
On Tue, Jul 22, 2025 at 3:26 AM mSparks ***@***.***> wrote:
> meanwhile, in the real world
>
> https://despairlabs.com/blog/posts/2025-07-10-an-openzfs-bug-and-the-humans-that-made-it/
>
> That's not a memory bug, it's a logic bug. Rust would have not prevented
> it. The Rust example gives a compiler bug because the author he made the
> psize and asize different types, which you can also do it in C, and you're
> not required to do in Rust.
>
> And rust isnt just about protected memory access, it's benefits span the
> entire toolchain, while simultaneously getting performance within the
> margin of error vs C.
>
> And mo, C doesn't have anything close to Rust in terms of the type
> system, C will quite happily let you read and write a million 16 bit ints
> into a single 32bit int structure, what benefits are you claiming that
> offers (that aren't ms sharepoint compromise levels of malicious)
>
> —
> Reply to this email directly, view it on GitHub
> <#27 (reply in thread)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABKF6CIO4V7QZ3P4XL4CDTD3JXYSZAVCNFSM6AAAAACAJ44P5SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGOBUGQZDMNY>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
For X being a userspace service and application set, rust is useless. Rust is best suited for low level device drivers where memory access protections work best. For userspace, this is pointless to implement. |
Beta Was this translation helpful? Give feedback.
-
|
The rust helps to develop apps too fast so rust devs have enough time to do an evangelist work across of all the internet. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Has anyone thought about gradually migrating parts of X11 to Rust? Given the goals of this project to revitalize X11, it seems like Rust could offer some compelling benefits:
The Wayland ecosystem already has Rust implementations, so there's precedent for display server tech in Rust.
Obviously this would be a major undertaking, but maybe starting with self-contained modules could be a way to test the waters? Input handling or protocol parsing might be good candidates.
What do people think? Is this worth exploring, or would the migration overhead outweigh the benefits?
Beta Was this translation helpful? Give feedback.
All reactions