Announcement

Collapse
No announcement yet.

KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • mdedetrich
    replied
    Originally posted by oiaohm View Post
    The horrible part here that is not true.
    https://googleprojectzero.blogspot.c...aping.html?m=1
    Turns out the very features in modern C++ that are meant to prevent use after free can in fact create them. We have real world exploit examples these days. The horrible reality is items like smart pointers were built on the foundation of C that results in them being like quick sand as in looks solid when its not.
    No, it IS TRUE.

    No one is saying that features like smart pointers completely eliminate use after free but they do have an impact on catching a subset of the errors. This is what you said earlier (bold emphasis is mine)

    Originally posted by oiaohm View Post
    The reality Steffo is use after free or memory leak bugs are just as likely with C++ as C. Ok some of the C++ ones instead of being a normal memory leak is a object leak but the result is still the same of memory not being freed when it should have been and the data end up exposed when it should not have been.
    This is blatantly false, misleading and spreading FUD. Yes C++ has plenty of issues, but claiming that modern C++ features are no better than C when it comes to memory safety is being disingenuous (you are literally claiming that smart pointers don't do anything which is laughable). And no, posting single bug reports on C++ where it didn't work is not proving your point because no one claimed that it prevents 100% of cases, in other words you are attacking a strawman (and if you wanted to be objective and honest you would have posted every single case in that project where the compiler did catch such errors, but of course you didn't).

    This is what pisses people off about your posts, you take some point and then you twist it ever/sensationalize to a degree where you deliberately mislead people. Stop doing it please.

    There are legitimate reasons why C++ is not the best suited language for this task (i.e. ABI that breaks much more frequently than C), however this false hill that you are standing on is not one of them.
    Last edited by mdedetrich; 15 June 2021, 04:37 AM.

    Leave a comment:


  • ssokolow
    replied
    Poke poke. Unapproved post.

    Leave a comment:


  • ssokolow
    replied
    Originally posted by oiaohm View Post
    Sorry C++ provides no real protection again use after free or memory leak bugs.
    https://www.zerotier.com/2017/05/05/...ndard-library/
    See also https://alexgaynor.net/2019/apr/21/m...-wont-save-us/

    Leave a comment:


  • polarathene
    replied
    Originally posted by curfew View Post
    Kwinft is developed for KDE so obviously it will maintain compatibility with KDE forever.
    It's designed to be a compositor that works with more than just Plasma, and the README is clear that there is no promises that it will keep parity with kwin over time.

    Activities is already dropped (while kwin recently added Wayland support for it), but there is discussions of a feature for "virtual monitors" similar to virtual desktops but not fixed to a specific display or virtual desktop.

    Originally posted by curfew View Post
    The problem here will be can the sole developer of Kwinft keep up with the upstream in terms of features. Based on his description of changes to Kwin core, merging new features from upstream must not be feasible at all.
    When a new Plasma release happens he syncs kwin git commits over to kwinft where appropriate, but as kwinft is no longer 1:1 as a fork due to replacing parts with wrapland and wlroots, any commits related to that won't be adopted/ported, and certain feature parity will differ. Eg, graphic tablet support (Wacom, Huion), and VR HMD (drm leasing) are two notable features that will differ in implementation, screen casting I think is another one.

    One feature being worked on recently with kwin is interactive real-time multi-touch gestures, which has some kwin effects animations sync to your gesture movement (eg a multi-finger swipe to change virtual desktop), rather than waiting on completion to trigger a transition like a shortcut key or mouse movement would. This requires effects to be updated to support them, and I think relies on libinput integration... however kwinft adopts wlroots for the next release, which shifts the responsibility of libinput there.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Steffo View Post
    C++ is backward compatible and if KWinFT uses C++ 20 and Mir C++ 17, there should be no problem. A library author usually knows about compatibility issues and is cautious regarding raising the requirements.
    No this ignores C++ standard library defects. There can be reason why you are not using particular features.

    Originally posted by Steffo View Post
    It doesn't provide 100% protection, but it makes it less probable than with C.
    You just ignore concepts like RAI and smartpointers which are far superior than goto.
    I have been around the C++ community for a while to hear that raw pointers "are evil" and that they should be avoided as much as possible. While one of the main reasons to use smart pointers over raw


    Sorry to say its not less probable than C. I have not ingored RAI and Smartpointers at all. There are ways you use those that cause object leaks.

    Originally posted by mdedetrich View Post
    This is false, if you modern C++ features then you will have less use after free errors compared to C. Of course you can't completely eliminate such errors, but the occurrence is going to be a lot less frequent. Saying otherwise is misleading.
    The horrible part here that is not true.
    Posted by Mark Brand, Exploit Technique Archaeologist. Introduction After discovering a collection of possible sandbox escape vulnerab...

    Turns out the very features in modern C++ that are meant to prevent use after free can in fact create them. We have real world exploit examples these days. The horrible reality is items like smart pointers were built on the foundation of C that results in them being like quick sand as in looks solid when its not.

    The nightmare here is using C++ modern features a user after free error is normally harder to find. Why harder you have the stdc++ having its own allocator that may or may not be hookable for monitoring for leaks. C is missing the language features to make use after free less but its more compatible with tooling to find them. Yes the tooling added to modern C compilers are more likely to find use after free errors than modern C++ errors.

    The result is a interesting one. There are two percentages here the number of errors programmer makes and the percentage that the compilers detect. C the programmer is likely to code up more use after free errors and the modern compiler c is more likely to error over them result in build errors so end up fixed. C++ the programmer is likely to make less use after free errors in the code but the ones they make the compiler and runtime tools are less likely to detect. The result in final production software of C++ is more likely to be faulty than C with a use after free error.

    There is one feature that totally explains the change "AddressSanitizer" yes this is a feature that google added that has come standard in the common compilers these days. Its really good at pulling out C issues with use after free but its not equal as good at pulling out C++ smartpointer leaks or c++ object leaks resulting in use after free. So C++ modern features have the problem there is lack of tooling in compilers to detect when they have been used wrong this results in flipping the outcome of the final product. Lower detectability makes the modern C++ problems in fact more problematic not less due to being harder to detect.

    mdedetrich is really simple to miss the number of use after free errors in C code bases have dropped and it directly linked to change in the common compilers. This does show the importance of tooling to find defects as well as language features.

    Leave a comment:


  • damentz
    replied
    Originally posted by polarathene View Post

    Going to take a guess that you mixed these two up? kdisplay is the one from KWinFT project, not kscreen which is older.



    I assume that's on X11 not Wayland?
    You're right, I meant to say kdisplay was better over kscreen. Similar names. And yes, X11, not Wayland.

    Leave a comment:


  • Charlie68
    replied
    I am happy that this project is underway, but I do not like to read controversy every time. Also because a user to get an idea should also have the versions of the Kwin maintainers. In life I have learned that you must always listen to both sides in order to form an opinion. These controversies that punctually arrive at each post, do him no honor.

    Leave a comment:


  • ms178
    replied
    Originally posted by seijikun View Post

    I just updated the packages to 5.22. Have not testet them myself yet, though.
    Thanks a lot! Yes, I meant your repo and it is a big plus point for openSUSE vs Kubuntu in my eyes that I can get these packages without a hassle.

    Leave a comment:


  • Vistaus
    replied
    Originally posted by shmerl View Post

    For me it fails Wayland to Wayland, not XWayland even.
    Bug report or it didn't happen. That's how the Phoronix forums work

    Leave a comment:


  • mojo86
    replied
    KWin still crashes and freezes my system. Have the newest Fedora system atm. When you use the KDE Live CD and have a Nvidia card you are fked, the system will freeze, at least you can boot in rescue mode. I switched everything back to X11, VirtualBox is not responding to any input, games are not working, it's a mess.

    Leave a comment:

Working...
X