X.Org Server Development Hit A Decade High For The Number Of Commits In 2024

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • oiaohm
    Senior Member
    • Mar 2017
    • 8397

    Originally posted by anda_skoa View Post
    As it is the established IPC mechanism for for communication between desktop (but also system) components, it made sense to base portals on that as well.
    Maybe it does not make sense to base portals on dbus going forwards. There is something 6-8 years ago that brought dbus usage into question. kdbus and https://github.com/bus1/bus1 Yes the attempt to add dbus as bus1 and kdbus to the Linux kernel as a kernel module.

    AF_UNIX and AF_UNIX.side-channel kept on coming up in the Linux core kernel developers mind every time they looked at what kdbus and bus1 was doing. There is something different about Linux that kept this coming up as well

    Linux also supports an abstract namespace which is independent of the filesystem.
    Yes using AF_UNIX this integrates with the OS security straight off no special handling.

    Component systemd Is your feature request related to a problem? Please describe I cannot transition from dbus to varlink without file-descriptor support, could this be supported as an extention to ...

    Varlink slightly extended can do basically everything dbus use to do without being dependent on a single service/broker.

    Remember anda_skoa AF_UNIX was established IPC before dbus existed yes this includes linux having abstract namespace. Lot of the reason why dbus is the way it is happens to be so it cross platform. Yes the idea of running gnome and kde desktops straight on windows and other insane options is why dbus is the way it is.

    This is the same with X11 server basically being a full OS duplicating everything the OS kernel does these days.

    Yes it would be possible to increase the stability of xdg desktop portals and the like moving over to something that is brokerless.

    Yes trying to force everything though the wayland compositor or x11 server means those items are now being a broker coming a single point to overload. Yes the reason for dbus in the first place was pushing everything though the xfree86/x.org x11 server was causing it to stall out. Yes this was just move the stall out point not eliminate it.

    Some cases the old Unix designs are 99% right.

    Yes calling dbus cancer could be correct but this also means we need to replace it. Removing dbus and running everything though the x11 server or wayland compositor is going to move the reason why dbus plays up to the X11 server or wayland compositor. Varlink displays clearly you can do a brokerless item that does the job of dbus using existing AF_UNIX sockets and AF_UNIX socket side channel.

    Comment

    • Quackdoc
      Senior Member
      • Oct 2020
      • 5053

      Originally posted by anda_skoa View Post
      Not implementing pipewire base capture because of portals makes indeed no sense.

      The portal base capture is the generic Pipewire capture support.
      I.e. the application does not need to know anything other than to consume the given pipewire stream.



      As it is the established IPC mechanism for for communication between desktop (but also system) components, it made sense to base portals on that as well.
      It has basically implementation in all languages and essentially all even remotely significant frameworks already use it for various other things.

      Portals extend on these possibilities and unify others into common APIs.

      It also means they can replace quite elaborate plugin based desktop integration with single code paths , e.g. to get the platform's file dialog.

      As I said, an earlier attempt almost 20 years ago would have taken a similar approach but could gather enough development resources at the time.
      They are late but still a large step forward
      I don't disagree that dbus makes sense for portals. but I do hate this culture of "portals or nothing" that some devs seem to be taking.

      Comment

      • oiaohm
        Senior Member
        • Mar 2017
        • 8397

        Originally posted by Quackdoc View Post
        I don't disagree that dbus makes sense for portals. but I do hate this culture of "portals or nothing" that some devs seem to be taking.
        Except "culture of ""portals or nothing""" is not what has been happening when you look at development. Like weasel example above with automation where all the different options had been built out.

        What is going on many different options get built out and tried with the portal solution being able to survive the testing for stability and security better than the other options .

        Are portals perfect most likely no. But there has to be something to the portal model why it keeps on being the last man standing.

        Yes we also do have people attempting to suggest like put this in Wayland protocol when extension doing that has been build tried and proven not to be good idea.


        Originally posted by Quackdoc
        I mean just look at OBS. OBS refused to implement generic pipewire capture support because "it hole punches portals" or some dumb reason along those lines.
        People developing prototypes for OBS have tried more options.



        Quackdoc remember OBS ships a flatpak version. So your solution need to work when OBS is running in a container.

        Portal deals with the container-ed OBS not having the privilege.

        Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

        This video that about 11 months old Quackdoc covers where pipewire is going. Very quickly you start needing security.

        Comment

        • mangeek
          Senior Member
          • Dec 2012
          • 403

          Originally posted by Weasel View Post
          Lies?

          Show me in a simple bash script how you can position a window on Wayland in absolute terms (or at least, relative to another process). Or how to query the window position.

          It's for automation workflow. You know, stuff that smart people do to automate their work instead of clicking all over the place the same routines like peasants.

          YOU are the one lying. Pathetic lying troll. So prove it or shut it.
          To be honest, 'automating' based on specific pixel locations on the screen seems bonkers. You're the first person I've heard of doing this, and I don't think that makes you a 'power user'. Bluntly, it sounds like a method that's inherently janky/kludgy and esoteric, and I imagine there are more sane ways of accomplishing the same results in more reliable ways, like using APIs or scripts. Mind if I ask for a specific example of what you're automating?

          Comment

          • Quackdoc
            Senior Member
            • Oct 2020
            • 5053

            Originally posted by oiaohm View Post

            Except "culture of ""portals or nothing""" is not what has been happening when you look at development. Like weasel example above with automation where all the different options had been built out.
            I've seen it with multiple projects now. I believe even KDE want's to go this route now.

            What is going on many different options get built out and tried with the portal solution being able to survive the testing for stability and security better than the other options .

            Are portals perfect most likely no. But there has to be something to the portal model why it keeps on being the last man standing.

            Yes we also do have people attempting to suggest like put this in Wayland protocol when extension doing that has been build tried and proven not to be good idea.
            Portals are far from the only good option, for instance with video recording in general, wayland now has screen recording protocols.

            People developing prototypes for OBS have tried more options.

            None of them have been seriously considered for upstream as far as I can tell
            Quackdoc remember OBS ships a flatpak version. So your solution need to work when OBS is running in a container.

            Portal deals with the container-ed OBS not having the privilege.
            The solution does **not** need to work when OBS is in a container, you can easily have compile time optional code.
            Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

            This video that about 11 months old Quackdoc covers where pipewire is going. Very quickly you start needing security.
            Security should never come in the way of use case and convenience. People seem to forget you can have multiple solutions to a problem and let people pick and choose the best one to suit their needs. This in itself is the part of linux that has been so alluring to thousands of users. Want security? Great, then have it, why make everyone else suffer for something you can easily disable?

            This whole attitude of "we shouldn't allow the user to have/do XYZ because I don't need the usecase and you shouldn't either" is bloody bonkers. And I hope everyone pushing this crap leaves the linux ecosystem entirely.

            Comment

            • anda_skoa
              Senior Member
              • Nov 2013
              • 1192

              Originally posted by oiaohm View Post
              Maybe it does not make sense to base portals on dbus going forwards.
              At the moment it is the best choice due to how widely supported it already is.

              There is not even a good contender at the moment and even broker-less D-Bus initiatives have failed, e.g. kdbus never got merged.

              Also probably not a good idea to change yet another IPC channel at the same time the change of the other one (X11 -> Wayland) is still ongoing.
              If you slowly migrate two things at the same time you'll essentially have to support four variations.
              Doubles the complexity.

              Originally posted by oiaohm View Post
              AF_UNIX and AF_UNIX.side-channel kept on coming up in the Linux core kernel developers mind every time they looked at what kdbus and bus1 was doing. There is something different about Linux that kept this coming up as well


              Yes using AF_UNIX this integrates with the OS security straight off no special handling.
              Which is also why D-Bus is using that on every OS other than Windows (where it is not use much at all).

              Originally posted by oiaohm View Post
              Component systemd Is your feature request related to a problem? Please describe I cannot transition from dbus to varlink without file-descriptor support, could this be supported as an extention to ...

              Varlink slightly extended can do basically everything dbus use to do without being dependent on a single service/broker.
              The question is can it do this conceptually or compatibly.
              I.e. how difficult it would be to implement libdbus on top of that?

              This would at least allow most services and applications written in C/C++ to continue to work (and other languages which use that for their implementations instead of implementing it natively).

              Originally posted by oiaohm View Post
              Remember anda_skoa AF_UNIX was established IPC before dbus existed
              D-Bus uses Unix domain sockets as its primary transport on all platforms that support it.
              It only needs TCP on Windows and it is hardly every used there.

              Originally posted by oiaohm View Post
              Lot of the reason why dbus is the way it is happens to be so it cross platform.
              Not really.

              Theoretically yes but it is rarely used by software on Windows or macOS.
              Mostly on Linux and BSDs as they share a lot more FOSS desktop applications.

              Originally posted by oiaohm View Post
              This is the same with X11 server basically being a full OS duplicating everything the OS kernel does these days.
              Very different situation.
              With X11 you have mostly clients talking to a server, with D-Bus you have mostly client talking to each other.

              The X11 server needs to implement all the protocols as it is usually the recipient of calls and the source of data.
              The D-Bus "server" (broker) only implements message passing and has no need for any service protocols other than the one clients use to announce themselves.

              Originally posted by oiaohm View Post
              Yes it would be possible to increase the stability of xdg desktop portals and the like moving over to something that is brokerless.
              Maybe. The D-Bus daemon is rather stable.

              Comment

              • anda_skoa
                Senior Member
                • Nov 2013
                • 1192

                Originally posted by Quackdoc View Post
                I don't disagree that dbus makes sense for portals. but I do hate this culture of "portals or nothing" that some devs seem to be taking.
                That is of course annoying.

                It is somewhat understandable that every extra code path is more work and maintenance burden but sometimes necessary

                Comment

                • oiaohm
                  Senior Member
                  • Mar 2017
                  • 8397

                  Originally posted by Quackdoc View Post
                  I've seen it with multiple projects now. I believe even KDE want's to go this route now.
                  But have you looked at what they tried before they decided to go portals.

                  Originally posted by Quackdoc View Post
                  Portals are far from the only good option, for instance with video recording in general, wayland now has screen recording protocols.
                  Those have not made it to mainline wayland protocol.

                  Originally posted by Quackdoc View Post
                  The solution does **not** need to work when OBS is in a container, you can easily have compile time optional code.
                  That your idea. That is not the OBS core developers idea. OBS core developers want to maintain one set of code. All those compile time optional code makes testing and code maintenance harder. If you want to add it as a third party add on they will not stop you.

                  Originally posted by Quackdoc View Post
                  Security should never come in the way of use case and convenience. People seem to forget you can have multiple solutions to a problem and let people pick and choose the best one to suit their needs. This in itself is the part of linux that has been so alluring to thousands of users. Want security? Great, then have it, why make everyone else suffer for something you can easily disable?
                  Does not work that way. Remember projects have limited resources. Multi solutions normally don't win. The solution that can do most of the roles wins and this comes down to code maintenance. Yes dbus security can easily disable but that part of the point portals can support users who need the security and those don't need the security.

                  Originally posted by Quackdoc View Post
                  This whole attitude of "we shouldn't allow the user to have/do XYZ because I don't need the usecase and you shouldn't either" is bloody bonkers. And I hope everyone pushing this crap leaves the linux ecosystem entirely.
                  No this is you having to wrong from a code maintainer-ship point of view. Why add option XYZ when option abc covers that use case . Quakdoc it happens at the linux kernel as well there were 3 different proposed API for cgroups back in the day and they had to get down to one that covered all use cases.

                  The requirement for security is not something you can just hand wave away. You cannot ignore that be it the kernel or other open source solutions they will always try to implement the least number of options to cover as many users as possible and this is required to keep code maintenance and testing time cost effective.

                  Yes the security bit is where a lot of the alternatives to portals fall flat on face. When a project has to implement portals any how to support the users to that need security and this other options that cannot be setup secure users are 90%+ covered by portals as well why pay the extra code maintenance cost.

                  Quackdoc you are missing the need that options need to have broad user base use to be worth it to upstream projects to include in their code base. This behavior in open source code bases predates portals by the way by decades yes this includes upstream projects only providing sample sysvinit scripts and supporting no other init.
                  Last edited by oiaohm; 07 January 2025, 11:43 AM.

                  Comment

                  • Weasel
                    Senior Member
                    • Feb 2017
                    • 4497

                    Originally posted by mangeek View Post
                    To be honest, 'automating' based on specific pixel locations on the screen seems bonkers. You're the first person I've heard of doing this, and I don't think that makes you a 'power user'. Bluntly, it sounds like a method that's inherently janky/kludgy and esoteric, and I imagine there are more sane ways of accomplishing the same results in more reliable ways, like using APIs or scripts. Mind if I ask for a specific example of what you're automating?
                    https://www.phoronix.com/forums/foru...94#post1516494

                    Also you're basically in the wrong crowd if you never heard of it before. Echo chamber and all that.

                    Go to AutoHotkey communities or forums and find out why it's so popular on Windows and what power users use it for (not just the people who want 1-2 global hotkeys, those are nothing, AHK is a full-blown scripting language for a reason).

                    You don't see those much on Linux especially on Wayland because they're all casuals and you can't even do it, they probably aren't even aware they could do it on X11. And I'm one of those who moved from Windows to Linux decades ago but without shitting on my own experience and convenience so I've always sought to look the same conveniences in Linux. This is one of them.

                    Anyway tl;dr for that one example, the app in question doesn't offer this feature, it has no API, but it displays parameters like frequency (you know like any GUI app with a custom drawn gui). I use it in Wine btw, it's proprietary and not Linux native. Refer to my above point of "not going to inconvenient myself just out of purity of using Linux-specific crap".

                    As if Linux has anything decent for media productivity. With Wayland it's no wonder.

                    Comment

                    • Weasel
                      Senior Member
                      • Feb 2017
                      • 4497

                      Originally posted by anda_skoa View Post
                      Aren't you just locked into another situation of 1?
                      Which other display servers than X11 does your script work with? Do the tools you call have Arcane or Mir support?
                      I mean I didn't say you should choose a different protocol or server, but just a different implementation (i.e. compositor). Any implementation can die or remove a feature in an update, and then what? Protocols rarely do though. Standardization is the whole point of a "specified" protocol.

                      Comment

                      Working...
                      X