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
    • 8461

    Originally posted by anda_skoa View Post
    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.
    kdbus was the first attempt bus1 was the second. kdbus was 2013-2014 bus1 was 2014 to 2016.

    Except kdbus and bus1 were not in fact broker-less these were both move the broker into the kernel. With the Linux kernel developers going is this not just duplicating what AF_UNIX + LSM do anyhow.

    Originally posted by anda_skoa View Post
    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.
    systemd is moving to varlink at the moment. Also with how much time X11-> wayland will take we really should not wait that long.

    Originally posted by anda_skoa View Post
    Which is also why D-Bus is using that on every OS other than Windows (where it is not use much at all).
    You missed something
    Yes using AF_UNIX this integrates with the OS security straight off no special handling
    Yes D-bus use AF_Unix but doing a man in the middle equals I need special handling so I integrate with OS security as well as I need the man in the middle running so this works.

    Originally posted by anda_skoa View Post
    The question is can it do this conceptually or compatibly.
    I.e. how difficult it would be to implement libdbus on top of that?
    The changes are unfortunately breaking. Direct protocol like varlink the services are required to handle a percentage of the security side. A dbus broker that can use varlink or some other direct protocol to talk to services is possible. Basically a Xwayland for legacy applications solution for old dbus applications. But you also get proper integration with the LSM.

    Remember dbus broker and dbus daemon has to run special processing code to support linux kernel LSM security control.

    Originally posted by anda_skoa View Post
    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.
    That comes the question why not take full advantage of the full to mostly full implementation of AF_UNIX Linux/BSD has to skip out on having man in middle broker.

    Originally posted by anda_skoa View Post
    Very different situation.
    With X11 you have mostly clients talking to a server, with D-Bus you have mostly client talking to each other.

    Absolutely not different to X11 for X11 IPC use cases. X11 application to windows manager or X11 application to X11 compositor and so on is the same basic diagram.

    Originally posted by anda_skoa View Post
    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.
    This basically put head in sand.
    Originally posted by anda_skoa View Post
    ​Maybe. The D-Bus daemon is rather stable.
    Systemd in early boot has not been finding d-bus daemon stable this is why they are migrating more and more to varlink.

    anda skoa direct sockets like varlink uses it also better for the kernel scheduler to correctly share allocated CPU time. There are lot of issues with portals that happen because CPU time is not being correctly allocated and this is because of dbus broker/deamon hiding from the kernel what dbus service an application needs. This is why I question is dbus the right solution or should we follow systemd lead and start migrating to varlink or something else like it.

    There is a lot of cpu resource sharing code with Linux/BSD with AF_Unix that you cannot use effectively with man in middle like dbus.

    Yes it this stuff where putting a dbus broker in the Linux kernel and made it work right was just going to come implement AF_Unix in Linux kernel twice. Yes one verson normal AF_Unix and the second version AF_Unix for dbus with enough extras to make code maintenance totally evil.

    Varlink goes what can we do if we just work with what AF_Unix provides with no man in middle turns out a hell of a lot. Yes someone decide to make a true brokerless design todo most of the same roles as dbus with varlink. Systemd few extra addons make varlink very much usable as a dbus replacement.

    I somehow think dbus is a mistake caused by attempting to be cross platform back in the day.

    Comment

    • Quackdoc
      Senior Member
      • Oct 2020
      • 5070

      Originally posted by oiaohm View Post
      Those have not made it to mainline wayland protocol.
      Yes they have.
      All those compile time optional code makes testing and code maintenance harder.
      if this is harder they have a massive skill issue and I have to seriously doubt whoever is being paid to work on OBS deserves to be.

      Remember projects have limited resources. Multi solutions normally don't win.
      OBS has 5 sponsors in their diamond tier sponsor list, each of which pays at least $50000 a year. they have many in other tiers too. IF obs can't afford it, that is so bloody laughable.

      The requirement for security is not something you can just hand wave away.
      no one hand waved it away.

      Comment

      • oiaohm
        Senior Member
        • Mar 2017
        • 8461

        Originally posted by Quackdoc View Post
        OBS has 5 sponsors in their diamond tier sponsor list, each of which pays at least $50000 a year. they have many in other tiers too. IF obs can't afford it, that is so bloody laughable.
        Exactly how many full time developers do you think 250000 a year covers. That not many. They have to optimize their workflows like it or not. Lets say you go for india developers to get C/C++ coders of decent skill is 25000USD each so 10 is all that covers. High paying countries that covers less.

        This is not bloody laughable is the reality. Money only goes so far. Projects like OBS simply cannot afford to go feature mad they don't have the resources to support it.

        Quackdoc you have a common problem total failure to see how little funding open source project have and then be asking them to implement rarely required features without being aware they really don't have the resources to.

        Originally posted by Quackdoc View Post
        no one hand waved it away.
        Except you are indirectly. You say why not implement more direct screen capture and so on most of this requires security to cover the most users and comes how are you going to-do it. Yes portals have that security so it wins.

        Remember open source project funding limitation forces developer time limit forcing not adding stacks of different features so picking the options that cover the most users. This is what is the cause of portals and other things in the past as well.

        Comment

        • oiaohm
          Senior Member
          • Mar 2017
          • 8461

          Originally posted by Weasel View Post
          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).
          Weasel I come from KDE community who are use to using kwin scripting. So yes having full blown scripting language.

          Does not change the fact that AHK is a hack. Weasel Windows and X11 and Wayland all have not had full blown automation interfaces.

          Please note AHK under windows is not using the interfaces of the windows compositor. Yes the way AHK is doing that the at-spi interfaces. AT-SPI2 over dbus on Linux.

          Weasel this has been my problem you are asking something to be in Wayland protocol then mention AHK and that says by it design this should be in the at-spi interfaces that are not Wayland. Are you asking for these features to be in the wrong part completely and are asking for it to be in the wrong part because you have been using X11 debugging interfaces.

          Comment

          • anda_skoa
            Senior Member
            • Nov 2013
            • 1202

            Originally posted by Weasel View Post
            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?
            Unfortunately implementations are never equal and if you need to switch to a different one convenience/productivity enhancement like scripts are your least concern.

            But if you are on your preferred implementation, why go into much more effort in creating a solution around third party tools just because you theoretically might need to change many years into the future?

            Generic solutions come at a cost. Usually more complexity, fewer features and the perpetual need to evaluate every change against several targets to verify the change to be still generic enough.

            How many of the AutoHotKey users you've referred to in the other comment have decided that they need to find a solution with using the Windows Cmd Shell because AHKs might die at some point?

            Originally posted by Weasel View Post
            Protocols rarely do though. Standardization is the whole point of a "specified" protocol.
            Protocols never die but their implementations do.

            How many POP3 accounts do you still use? Many providers don't even support that anymore, same for many of the clients created in the last decade.

            Comment

            • Quackdoc
              Senior Member
              • Oct 2020
              • 5070

              Originally posted by oiaohm View Post

              Exactly how many full time developers do you think 250000 a year covers. That not many. They have to optimize their workflows like it or not. Lets say you go for india developers to get C/C++ coders of decent skill is 25000USD each so 10 is all that covers. High paying countries that covers less.

              This is not bloody laughable is the reality. Money only goes so far. Projects like OBS simply cannot afford to go feature mad they don't have the resources to support it.

              Quackdoc you have a common problem total failure to see how little funding open source project have and then be asking them to implement rarely required features without being aware they really don't have the resources to.


              Except you are indirectly. You say why not implement more direct screen capture and so on most of this requires security to cover the most users and comes how are you going to-do it. Yes portals have that security so it wins.

              Remember open source project funding limitation forces developer time limit forcing not adding stacks of different features so picking the options that cover the most users. This is what is the cause of portals and other things in the past as well.
              IF it is too hard for you as a dev to implement a compile time feature of something this simple, again, this is a featue OBS already has under the hood, it's literally just exposing it. Then you are a failure of a dev and 250000USD a year can pay for like, 10 of you.

              Comment

              • anda_skoa
                Senior Member
                • Nov 2013
                • 1202

                Originally posted by oiaohm View Post
                Except kdbus and bus1 were not in fact broker-less these were both move the broker into the kernel.
                And both unfortunately failed to get mainlined.

                Originally posted by oiaohm View Post
                With the Linux kernel developers going is this not just duplicating what AF_UNIX + LSM do anyhow.
                D-Bus developers didn't do that either.
                Using the full capabilities of unix socket is what made it so versatile.

                Several D-Bus APIs, including some of the portals, only work because AF_UNIX has features that AF_INET does not.

                Originally posted by oiaohm View Post
                systemd is moving to varlink at the moment.
                For its internal communication, between its tools/components.

                It's D-Bus based API can only move to varlink if someone finds a way that a D-Bus client can call the new API or all clients have been ported.

                Originally posted by oiaohm View Post
                Also with how much time X11-> wayland will take we really should not wait that long.
                Even if that is done in a couple of years you'll need to consider the point in time when the portal effort was started.

                Originally posted by oiaohm View Post
                The changes are unfortunately breaking.
                So not something existing services or clients can simply switch to.

                Originally posted by oiaohm View Post
                A dbus broker that can use varlink or some other direct protocol to talk to services is possible.
                What would we gain from moving to a varlink based D-Bus broker?
                I thought the whole point was that varlink didn't need a broker?

                Originally posted by oiaohm View Post
                That comes the question why not take full advantage of the full to mostly full implementation of AF_UNIX Linux/BSD has to skip out on having man in middle broker.
                D-Bus does used that on Linux/BSD.
                Extensively.

                Originally posted by oiaohm View Post

                Absolutely not different to X11 for X11 IPC use cases. X11 application to windows manager or X11 application to X11 compositor and so on is the same basic diagram.
                The architecture diagram might look similar but the roles are very different.

                In the X11 setup the server is the service that clients talk to, in a D-Bus setup it just passed along data.
                X11 clients rarely talk to each other, while D-Bus clients rarely talk the the server's service (name registration)

                Originally posted by oiaohm View Post
                This is why I question is dbus the right solution or should we follow systemd lead and start migrating to varlink or something else like it.
                Portals predate systemd's support for varlink so "follow" was not an option.

                At best portals and client frameworks can look into supporting both D-Bus and Varlink.

                In order to be even somewhat feasible this will require tooling to process D-Bus API specification files such that the generate code uses Varlink instead of D-Bus.
                Has the systemd community started to work on these?

                Originally posted by oiaohm View Post
                Yes it this stuff where putting a dbus broker in the Linux kernel and made it work right was just going to come implement AF_Unix in Linux kernel twice.
                That would not need a second implementation.
                Both clients would use the standard socket to talk to the in-kernel broker, just like they currently do with the user land broker.

                Originally posted by oiaohm View Post
                Yes one verson normal AF_Unix and the second version AF_Unix for dbus
                D-Bus doesn't have its own socket implementation.
                It uses standard AF_UNIX sockets on every platform but Windows (where it is not really relevant anyway).

                Originally posted by oiaohm View Post
                Systemd few extra addons make varlink very much usable as a dbus replacement.
                Does that include tools to process the existing API definition files or do they need to respecify all interfaces in a new format?

                Originally posted by oiaohm View Post
                I somehow think dbus is a mistake caused by attempting to be cross platform back in the day.
                Cross platform was never an important goal, TCP was mostly just a proof-of-concept.
                The way it is being used by the FOSS clients and services has already moved beyond that due to reliance on advanced AF_UNIX capabilities.

                Comment

                • oiaohm
                  Senior Member
                  • Mar 2017
                  • 8461

                  Originally posted by Quackdoc View Post
                  IF it is too hard for you as a dev to implement a compile time feature of something this simple, again, this is a featue OBS already has under the hood, it's literally just exposing it. Then you are a failure of a dev and 250000USD a year can pay for like, 10 of you.
                  Its not implement the feature is the cost maintaining the code with the added feature. This is why there is feature pruning.

                  Note I said cannot go feature mad. Not that its hard to implement. This is the cost of maintain the code base. You have to be able to justify how this feature is cost effective to maintain.

                  Open source project cannot just keep on adding features or at some point it just does not have enough people to maintain the code base.

                  Comment

                  • Quackdoc
                    Senior Member
                    • Oct 2020
                    • 5070

                    Originally posted by oiaohm View Post

                    Its not implement the feature is the cost maintaining the code with the added feature. This is why there is feature pruning.

                    Note I said cannot go feature mad. Not that its hard to implement. This is the cost of maintain the code base. You have to be able to justify how this feature is cost effective to maintain.

                    Open source project cannot just keep on adding features or at some point it just does not have enough people to maintain the code base.
                    I dunno, I feel like exposing a feature they already have isn't that hard.

                    Comment

                    • oiaohm
                      Senior Member
                      • Mar 2017
                      • 8461

                      Originally posted by anda_skoa View Post
                      What would we gain from moving to a varlink based D-Bus broker?
                      I thought the whole point was that varlink didn't need a broker?
                      Yes you are right varlink itself does not need a broker. A varlink based dbus broker would way to support the older applications that have not been updated to varlink.

                      Applications that can do varlink would be able to go direct to the varlink service totally bipassing the varlink based D-Bus broker. This would allow picking up the AF_UNIX scheduler boosting correctly.

                      Originally posted by anda_skoa View Post
                      That would not need a second implementation.
                      Both clients would use the standard socket to talk to the in-kernel broker, just like they currently do with the user land broker.
                      You have missed it. AF_UNIX in the Linux kernel is a broker.



                      dbus broker is a extra broker on top of the AF_UNIX broker. This is why Linux kernel developers were against kdbus and bus1 because these are duplicating the already existing broker in the Linux kernel.

                      The standard socket system AF_UNIX has it own broker.

                      Do note

                      Linux also supports an abstract namespace which is independent of the filesystem.
                      You are on Linux you can open AF_UNIX sockets not connect to file system. This is because there is a broker there.

                      anda_skoa this is the problem AF_UNIX has it own broker. Dbus was not designed to take advantage of the AF_UNIX broker. There are ways to be discoverable on the AF_UNIX broker that varlink is using.

                      Yes varlink does not have it own broker because its using the AF_UNIX broker the system provides.

                      anda_skoa AF_UNIX broker that varlink is using is older than dbus.

                      Yes instead of trying to add a dbus broker to the Linux kernel maybe the path should have been extend the AF_UNIX broker packet filtering and add some redirection support.


                      Comment

                      Working...
                      X