Announcement

Collapse
No announcement yet.

System76 Reportedly Developing Their Own Rust-Written Desktop, Not Based On GNOME

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

  • #51
    Originally posted by Aisyk View Post
    I wonder if RUST is a fastest language for the desktop
    Desktops are already written in C or C++, so Rust's speed is a complex thing to discuss. In absolute terms, benchmark contributors seem to have trouble getting it on par with C and C++ but, in real-world terms, Rust tends to be faster because people are willing to leave performance on the table in C or C++ because they don't want to be responsible for debugging and maintaining what would result.

    Originally posted by Aisyk View Post
    what are it's advantages (Wayland, Xorg...) ?
    It's very good at letting you teach the compiler to enforce your invariants for you so a bad night's sleep results in a compiler error rather than an insidious bug. For example, because the ownership-and-borrowing system lets it invalidate previous variable bindings, you can implement what's known as the typestate pattern and teach the compiler to enforce correct use of any API that can be represented as a finite state machine. (eg. the Hyper HTTP library makes it a compile-time error to try to set an HTTP header after you've already started streaming the request body.)

    Comment


    • #52
      Oh nice, another DE for even more fragmentation aka choice.

      Aren't there enough DE, so that contributing to one of them would be the better thing?

      Comment


      • #53
        Originally posted by Anvil View Post
        next you'll see System76 getting into bed with Devaun
        System76 have shown themselves to be competent so… no

        Comment


        • #54
          It was only a matter of time, given how they were evolving these last couple of years.
          Their theming, their Gnome extensions, Pop_OS!, it was clear they are aiming at normal down-to-earth pragmatic users while Gnome is developer-tailored.
          If you want to fulfill your vision, and that vision matches a user-centric approach, you have to try and go your own way rather than have your proposals arrogantly dismissed when trying to influence the Gnome development towards a more realistic vision. Canonical broke his neck trying too. History repeats. Close-mindedness is a dangerous sickness.
          Eventually, Canonical did it with the success we all know (Unity was pure class). Now Solus and their Budgie desktop will part ways with Gnome too, and now System76.
          I hope many more do it, so we can have a lot of different DEs, each possibly quite flexible and adapting to users' workflow rather than trying to force it down their throat.

          Comment


          • #55
            Originally posted by Chugworth View Post
            I wonder just how much do they intend to re-invent the wheel?
            I hope as much as possible.

            Comment


            • #56
              Originally posted by ssokolow View Post
              benchmark contributors seem to have trouble getting it on par with C and C++
              As seen numerous times on Rust subreddit it's a poorly written benchmark in absolute majority of cases, often translated 1 to 1 from C to Rust. For example in the recent versions the aliasing-related optimizations are turned on again by default (after being fixed in LLVM) which should theoretically produce faster code than C/C++ because of strong Rust borrowing rules.

              Comment


              • #57
                Originally posted by evasb View Post

                GTK needs to split from GNOME, IMHO.

                This fragmentation occur (Solus is thinking about using EFL and Solus something else) because GTK is controled by the GNOME Project. I think that except from KDE nobody should use anything else, but the fact GTK is part of the GNOME project brings more fragmentation than it would be needed.

                My suggestion? GTK should to be a freedesktop.org project or an independent project. This way, GTK could be more inclusive and projects can have confidence to use and contribute with the toolkit.
                You do realise that's sort of what the whole thing with libadwaita is about right? They're splitting out the gnome parts and have built a platform library for themselves. GTK and all it's quite complex css theming glory isn't being changed but libadwaita (or the Gnome Parts if you prefer) is making it so that the stylesheet is hard-coded. Whether you like that move or not it's pretty much what you want done with GTK being scaled back to just being a toolkit. S76 are getting salty that Gnome went this particular theme route when they themselves wouldn't come to the table when it was being discussed over the last few years. Solus's situation is similar but also a bit different, they also haven't liked the movement towards libhandy and adaptability and actively banned versions of GTK3 programs that used the library.

                Comment


                • #58
                  Originally posted by dremon_nl View Post

                  As seen numerous times on Rust subreddit it's a poorly written benchmark in absolute majority of cases, often translated 1 to 1 from C to Rust. For example in the recent versions the aliasing-related optimizations are turned on again by default (after being fixed in LLVM) which should theoretically produce faster code than C/C++ because of strong Rust borrowing rules.
                  True, which is why I used the word "seem" and only presented it as a contrast to how, in practice, Rust tends to be faster because benchmarks are inherently disconnected from what people are willing to do in a codebase where maintainability is more of a concern.

                  Originally posted by Myownfriend View Post
                  All I know is that, the fewer of the following a GTK application plays nicely with, the more likely I am to go looking for a replacement on my KDE desktop:
                  • Desktop-wide consistent look and feel via the Qt and GTK versions of KDE's Breeze widget style
                  • GTK apps not deviating from the look and feel of my server-side windeco (including the button customization and rich context menu added by KWin) and not compromising the ability to manipulate windows of applications that are failing to process events promptly. (I already find that, with my one exception... namely Chromium using its own windeco so I can have the top row of pixels direct scroll events to the tabs, moving the window without Alt+Drag is sometimes laggy.)
                  • Open/Save dialogs provided by xdg-desktop-portal-kde
                  They're free to demand the exact UI they want but, if they do, then they're defining me out of their target demographic.

                  The most glaring example would be Flatseal, which looks like a particularly jarring attempt to theme a tablet UI using a desktop widget theme but which I use infrequently enough that it's less bother to tolerate it than to memorize the flatpak permission overrride CLI.

                  (I particularly like xdg-desktop-portal-kde because it provides an uncommonly compelling argument for application developers to support it. I just wish the KDE devs weren't taking so long to re-architect how the "For just this application" checkbox in the Places sidebar's "edit bookmark" dialog determined the identity of the application.)

                  Originally posted by SpyroRyder View Post
                  You do realise that's sort of what the whole thing with libadwaita is about right? They're splitting out the gnome parts and have built a platform library for themselves. GTK and all it's quite complex css theming glory isn't being changed but libadwaita (or the Gnome Parts if you prefer) is making it so that the stylesheet is hard-coded. Whether you like that move or not it's pretty much what you want done with GTK being scaled back to just being a toolkit. S76 are getting salty that Gnome went this particular theme route when they themselves wouldn't come to the table when it was being discussed over the last few years. Solus's situation is similar but also a bit different, they also haven't liked the movement towards libhandy and adaptability and actively banned versions of GTK3 programs that used the library.
                  As long as they don't roll anything too desirable into it. One of the big reasons I preferred Qt for stuff I didn't need to be cross-desktop back in the GTK+ 2.x days was that the core toolkit included things like toolbar customization.

                  Comment


                  • #59
                    As a fervent GNOME user, a new DE is always a good thing in my books.
                    Let's hope they have a new approach to ergonomics and innovative ideas.

                    Comment


                    • #60
                      I had some feelings about this happening, especially with the news of GNOME dev not wanting GNOME DE to be customized anyway for Distros to stand out. I had a feeling that either System76 or Ubuntu would start planning on going, either their own DE or KDE Plasma route. Looks like it is System76. Ubuntu in my opinion would be much better off with KDE Plasma (customized like Unity style, which I currently run that way) than playing cat and mouse game with GNOME and extensions.

                      Comment

                      Working...
                      X