Announcement

Collapse
No announcement yet.

Arcan 0.6 Display Server Adds Network Transparency, XWayland Client Isolation

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

  • Arcan 0.6 Display Server Adds Network Transparency, XWayland Client Isolation

    Phoronix: Arcan 0.6 Display Server Adds Network Transparency, XWayland Client Isolation

    For those with some extra time around the US Thanksgiving holiday, the Arcan display server/environment is out with a new release. This is the interesting project that's powered in part by a game engine, offers X11 and Wayland compatibility, ported to BSDs, and more recently has been exploring VR and other desktop innovations...

    http://www.phoronix.com/scan.php?pag...n-0.6-Released

  • #2
    I would like to feel excited about this, but does this have any chance in current Linux?

    Linux in 2020 is very much corporate driven, while this seems mostly a one-man project, with 11 other people in the commit history. Which can be a positive thing, since there is no money incentive, like with Mir. Open Source maintainers can just keep chugging along with building software.

    I do feel it is very refreshing that there is still a grassroots movement in even the big things in the open source community. It seems it ticks off a lot of boxes with support for FreeBSD out of the box, not yet any systemd integration (but wait till Redhat gets their hands in this), Wayland compatibility and X11 compatibility, network transparency. Now all I want to read about is that there are 2 cut-and-paste buffers like in X11
    Last edited by Polleke; 26 November 2020, 06:12 AM.

    Comment


    • #3
      This seems interesting.

      Any chance A11 would inspire Wayland to make a network transparency protocol?

      Comment


      • #4
        Originally posted by timofonic View Post
        This seems interesting.

        Any chance A11 would inspire Wayland to make a network transparency protocol?
        https://mstoeckl.com/notes/gsoc/blog.html

        Waypipe really does say that there is no need for network transparency to be in the wayland protocol itself. Variable refresh rate will help.

        Comment


        • #5
          Because they're the same phonetically, I think of this Arkhan when ever Arcan is brought up which then makes me replay my inner joke about that episode:







          And that's my mental thought process whenever we have an Arcan article.

          Happy Thanksgiving, y'all.

          Comment


          • #6
            Originally posted by Polleke View Post
            I would like to feel excited about this, but does this have any chance in current Linux?

            Linux in 2020 is very much corporate driven, while this seems mostly a one-man project, with 11 other people in the commit history. Which can be a positive thing, since there is no money incentive, like with Mir. Open Source maintainers can just keep chugging along with building software.

            I do feel it is very refreshing that there is still a grassroots movement in even the big things in the open source community. It seems it ticks off a lot of boxes with support for FreeBSD out of the box, not yet any systemd integration (but wait till Redhat gets their hands in this), Wayland compatibility and X11 compatibility, network transparency. Now all I want to read about is that there are 2 cut-and-paste buffers like in X11
            Systemd integrationin kde and gnome is not without very valid reason. There is a fault with the Linux kernel.

            Linux kernel is wacky. When you get to the Linux kernel scheduler it has no concept of what a process is. All the Linux kernel schedulers know is really threads and cgroups/namespaces are. So we have two process under Linux one starts 50 threads and the another starts one the one that starts 50 threads by default gets 50x more CPU/IO... than the one that started 1 thread.

            So no systemd intergration fine but cgroup support has to come from somewhere or resources are going to keep on being allocated fairly between threads. On the desktop for responsiveness there are lots of times you want unfair resource allocation as the the active window application getting more resources than general as well as the core bits like the display server not being staved for CPU/IO.

            There are a set of stall behaviours on the Linux desktop that are purely being too fair.

            Comment


            • #7
              Originally posted by oiaohm View Post
              On the desktop for responsiveness there are lots of times you want unfair resource allocation as the the active window application getting more resources than general as well as the core bits like the display server not being staved for CPU/IO.
              Ain't that the truth.

              Comment


              • #8
                I still wish Arcan was the de facto standard instead of Wayland.

                Comment


                • #9
                  Originally posted by Vistaus View Post
                  I still wish Arcan was the de facto standard instead of Wayland.
                  Why? It would seem Arcan can show Wayland clients.

                  Comment


                  • #10
                    Originally posted by Vistaus View Post
                    I still wish Arcan was the de facto standard instead of Wayland.
                    Not really. It really simple to miss that Arcan is really only possible due to the massive work to get to the possibility of Wayland. Its really simple to forgot attempts like Ywindows that died due to lack of driver support.

                    What made wayland good for future is the fact is a protocol and its demarding drivers be done in a desktop compositor neutral way if possible.

                    Arcan as the defacto we would be looking at the moment Nvidia wanted custom crud for them back in it. Yes Nvidia arguement why they cannot support Xwayland should be seen as a serous threat to future.. People always say Linux kernel should support binary drivers more. Its really simple to miss when you have libglnvd that defines a interface for binary drivers to use how you will have parties like Nvidia making binary drivers who will want to bipass it and when they are blocked from bipassing it go and sulk in the corner and provide no drivers.

                    Comment

                    Working...
                    X