X.Org Server Hit By New Local Privilege Escalation Vulnerability

[You-]

There are X11 extensions that work perfectly on X11 while Wayland currently doesn’t. When the protocols are implemented yes it will be better but not currently.

can you get greater than millisecond level precision on x11?

I would be interested to know which extensions you are referring to.

[WannaBeOCer]

can you get greater than millisecond level precision on x11?

I would be interested to know which extensions you are referring to.

Where are you making this up from? Milliseconds is a terrible way to time visual stimuli. It’s all timed using frames.

[Damian]

I'm still using X11. It works fine and I don't run it as root...

I've tried Wayland based desktops and I've a number of use cases which it is just unable to handle.

It might be that I just don't know enough about Wayland and all its replacement libraries.

However I can't find a nice set of documentation that provides a mapping of Xlib calls to equivalents...

If anyone has knowledge of such a resource could they please share it.

[NobodyXu]

There are ways to bypass it in Rust too. I'm just advocating against blaming C++ when a memory issue is found in C code. There is no C/C++.

In rust, you would habe to explicitly opt-in via the unsafe block/fn, and that doesn't disable the borrow checker, it only allows you to call other unsafe fn and deference pointers.

It separates code that could have UBs (unsafe code) from code that cannot, and the safe code is the norm here and seldom do I need to use unsafe.
Everytime I use unsafe, it is mostly one or two line and it can be justified, combined with miri for UB checking (use after free, concurrent modification) along with sanitizers.

In C++ there isn't unsafe that is opt-in, and without borrow checker it is quite easy to introduce UB.

[NobodyXu]

My claim is that a rewrite from scratch will contain more bugs than the mature code that it is meant to replace. That implicitly excludes all of the historical bugs because the choice is between a mature codebase that has has many bugs squashed and a new code base that had yet to receive the same treatment.

Even with all the test suites, new tooling (better PL, compiler, linters), better code review, better doc and better understanding of the software written from scratch?

[Mario Junior]

2023 and Linux folks can't have a decent display server manager/protocol whatever.

"But Wayland 11!!"

Eerrrr...

[cj.wijtmans]

There are ways to bypass it in Rust too. I'm just advocating against blaming C++ when a memory issue is found in C code. There is no C/C++.

Don't bother. Anyone that conflates "C/C++" in that way has no clue what they are talking about. But i guess that's the side affect of "dummy" proof languages like Rust, it creates generations of programmers that don't have a clue about what they are doing and they will never learn either. Ok so their code is memory safe but they will still produce ugly and trashy code. I have encountered some idiots using C++ as well though, thinking using raw pointers is safe because they know how to handle pointers 🤦🏼♂️.

[NobodyXu]

Don't bother. Anyone that conflates "C/C++" in that way has no clue what they are talking about. But i guess that's the side affect of "dummy" proof languages like Rust, it creates generations of programmers that don't have a clue about what they are doing and they will never learn either. Ok so their code is memory safe but they will still produce ugly and trashy code. I have encountered some idiots using C++ as well though, thinking using raw pointers is safe because they know how to handle pointers 🤦🏼♂️.

Sorry but I start programming with C first, then C++, then Java/Python and finally switch from C++ to Rust because the former is so annoying to use due to its poorly designed language semantics and lack of borrow checker.

And no, just because somebody use Rust doesn't automatically mean they don't understand low-level details, and no, not knowing anything about low-level details does not mean you would produce ugly and trashy code.
There's no such correlation, you are not better than everybody else.

In fact, I would argue my code in Rust is far cleaner because I finally don't have to care about all the constructor/cp/mv assignment/initializer_list stuff in C++ and Rust get generics right in the first place, where as C++20 finally have concept checking in language but still have quirks enforcement and adoption of C++20 is going to be slow.

And Rust also have derive macro that can easily implement serialization/deserialization, where as for C++ you either manually implement it or use some external tools to do it, like Qt's own C++ extension.

[Sergey Podobry]

In rust, you would habe to explicitly opt-in via the unsafe block/fn, and that doesn't disable the borrow checker, it only allows you to call other unsafe fn and deference pointers.

It separates code that could have UBs (unsafe code) from code that cannot, and the safe code is the norm here and seldom do I need to use unsafe.
Everytime I use unsafe, it is mostly one or two line and it can be justified, combined with miri for UB checking (use after free, concurrent modification) along with sanitizers.

In C++ there isn't unsafe that is opt-in, and without borrow checker it is quite easy to introduce UB.

There is no need to describe differences between Rust and C++. Both of them are much safer than C.

[NobodyXu]

There is no need to describe differences between Rust and C++. Both of them are much safer than C.

That's true.