Announcement

Collapse
No announcement yet.

KDE Now Has Virtual Desktop Support On Wayland

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

  • #41
    Virtual desktops worked just fine on wayland before this, e.g. you could access/view them using the desktop grid, and switch between them using hotkeys. This is really only relevant for the pager widget working on wayland, or is there something else I've missed. Doesn't mean much for me since I have no use for the pager widget.

    Comment


    • #42
      Originally posted by hreindl View Post
      amazing how technically clueless you are on every topic you appear
      Flatpak is shit but *every* process should run as sandboxes as possible - period
      Amazing how technically clueless you are on every topic you appear.
      Flatpak is shit because of the sandbox, and almost *every* process should run as free as possible, unless it's untrusted, to reduce pointless overhead and management. Period.

      You'd have to be a special type of moron to sandbox your trusted productivity software.

      Comment


      • #43
        Originally posted by cybertraveler View Post

        Wayland design advantages:
        • more secure - designed to give less privileges to individual applications. IE your browser won't be able to read key presses going to your text editor and your messenger app can't access all the other visual surfaces of other apps.
        • built around creating tear-free, pixel perfect rendering with zero-copying at the system memory level. In the case of Intel embedded graphics you can potentially even have zero copying at the system and GPU level. IE your program writes a frame that is to be shown to the user to memory and that exact memory region is what the GPU itself refers to when drawing to the screen. Very efficient and conceptually beautifully.
        The problem with keypresses and one app being able to have too much access to others could be fixed with an X extension that would by default restrict apps from accessing anything to do with other apps. Only Window managers, some screen grab utilities and screen readers need special permissions. The tear free thing is also possible with X using extensions and DRI.

        Also, X can be made to work network transparently, with pretty good performance for many kinds of programs, including video. Every X app should always fall back to sending an image to the server over socket if shared memory support is not available.

        Comment


        • #44
          Originally posted by Weasel View Post
          Amazing how technically clueless you are on every topic you appear.
          Flatpak is shit because of the sandbox
          no, because the duplication of libraries

          Originally posted by Weasel View Post
          almost *every* process should run as free as possible, unless it's untrusted, to reduce pointless overhead and management. Period.
          bullshit!

          every - no almost every - every process should have only the permissions it needs to do it's work

          Originally posted by Weasel View Post
          You'd have to be a special type of moron to sandbox your trusted productivity software.
          well, that stupid attitude explains your systemd hate where every process and service is more or less sandboxed
          sandboxing is for the case you trusted software has a security bug to lock down exploits as much as possible


          Comment


          • #45
            Originally posted by Weasel View Post
            You'd have to be a special type of moron to sandbox your trusted productivity software.
            You'd have to be a special type of moron to NOT sandbox your trusted productivity software

            [[email protected]:~]$ su -
            Passwort:

            [[email protected]:~]$ touch /usr
            touch: setting times of '/usr': Read-only file system

            [[email protected]:~]$ cat /etc/systemd/system/display-manager.service.d
            cat: /etc/systemd/system/display-manager.service.d: Is a directory

            [[email protected]:~]$ cat /etc/systemd/system/display-manager.service.d/security.conf
            [Service]
            CapabilityBoundingSet=~CAP_AUDIT_CONTROL CAP_AUDIT_WRITE CAP_SYS_BOOT CAP_SYS_PTRACE
            RestrictAddressFamilies=AF_INET AF_INET6 AF_LOCAL AF_UNIX AF_NETLINK
            [email protected] @cpu-emulation obsolete ReBoot @swap

            PrivateTmp=yes
            ProtectControlGroups=yes
            ProtectKernelTunables=yes
            TasksMax=768

            ProtectSystem=full
            ReadWritePaths=-/etc/mtab
            ReadWritePaths=-/etc/mtab.fuselock
            ReadWritePaths=-/etc/vmware
            ReadWritePaths=-/usr/local/Zend

            ReadOnlyPaths=-/var/lib/dhclient
            ReadOnlyPaths=-/var/lib/dhcpd
            ReadOnlyPaths=-/var/lib/dnf
            ReadOnlyPaths=-/var/lib/dnsmasq
            ReadOnlyPaths=-/var/lib/dovecot
            ReadOnlyPaths=-/var/lib/letsencrypt
            ReadOnlyPaths=-/var/lib/logrotate
            ReadOnlyPaths=-/var/lib/mlocate
            ReadOnlyPaths=-/var/lib/mysql
            ReadOnlyPaths=-/var/lib/nfs
            ReadOnlyPaths=-/var/lib/rkhunter
            ReadOnlyPaths=-/var/lib/rpm
            ReadOnlyPaths=-/var/lib/rpm-state
            ReadOnlyPaths=-/var/lib/rsyslog
            ReadOnlyPaths=-/var/lib/samba
            ReadOnlyPaths=-/var/lib/smokeping
            ReadOnlyPaths=-/var/lib/smokeping-persistent
            ReadOnlyPaths=-/var/lib/vnstat
            ReadOnlyPaths=-/var/www

            ReadOnlyPaths=-/dev/sda
            ReadOnlyPaths=-/dev/sda1
            ReadOnlyPaths=-/dev/sda2
            ReadOnlyPaths=-/dev/sda3

            ReadOnlyPaths=-/dev/sdb
            ReadOnlyPaths=-/dev/sdb1
            ReadOnlyPaths=-/dev/sdb2
            ReadOnlyPaths=-/dev/sdb3

            ReadOnlyPaths=-/dev/sdc
            ReadOnlyPaths=-/dev/sdc1
            ReadOnlyPaths=-/dev/sdc2
            ReadOnlyPaths=-/dev/sdc3

            ReadOnlyPaths=-/dev/sdd
            ReadOnlyPaths=-/dev/sdd1
            ReadOnlyPaths=-/dev/sdd2
            ReadOnlyPaths=-/dev/sdd3

            ReadOnlyPaths=-/dev/md0
            ReadOnlyPaths=-/dev/md1
            ReadOnlyPaths=-/dev/md2

            InaccessiblePaths=-/etc/ssh/ssh_host_dsa_key
            InaccessiblePaths=-/etc/ssh/ssh_host_dsa_key.pub
            InaccessiblePaths=-/etc/ssh/ssh_host_ecdsa_key
            InaccessiblePaths=-/etc/ssh/ssh_host_ecdsa_key.pub
            InaccessiblePaths=-/etc/ssh/ssh_host_ed25519_key
            InaccessiblePaths=-/etc/ssh/ssh_host_ed25519_key.pub
            InaccessiblePaths=-/etc/ssh/ssh_host_rsa_key
            InaccessiblePaths=-/etc/ssh/ssh_host_rsa_key.pub

            Comment


            • #46
              Originally posted by Vistaus View Post

              In-verhicle entertainment consoles are using QNX more and more though, so there's no need anymore for Wayland on them.
              Who said anything about "need"? One could argue that we already had Windows, so there was no need for Linux on PCs.

              Comment


              • #47
                Originally posted by jpg44 View Post
                X11 has had virtual desktops since the 1980s.
                On the contrary – X11 has never had virtual desktops. They're a feature which most window managers provide (just as they do on Wayland), but they're not universal, and they're in no way part of any X11 specification or extension. The closest they come to standardisation are the freedesktop.org EWMH spec from the early 2000s, which aimed at promoting better interoperability between the hundreds of "do it my way" window managers...

                Comment


                • #48
                  The law of Phoronix – "flip through enough pages and every thread shall dissolve into an ugly frame war, regardless of the thread topic".

                  Comment


                  • #49
                    Originally posted by Weasel View Post
                    Amazing how technically clueless you are on every topic you appear.
                    Flatpak is shit because of the sandbox, and almost *every* process should run as free as possible, unless it's untrusted, to reduce pointless overhead and management. Period.

                    You'd have to be a special type of moron to sandbox your trusted productivity software.
                    Amazing how you appear to not know shit about how software is actually deployed and used in the real world. There is no such thing as "trusted process" in the modern world, with modern software complexity.

                    The main point here is that the "trusted productivity software" in actual reality is rarely if ever a paragon of code quality and intelligent design so you lock it down as well as you can to prevent it from screwing up everything else in case it is compromised or blows up on its own.

                    For example, on Windows servers it's extremely common to run each software inside its own VM in a server running VMWare Esxi hypervsor. Which is extremely wasteful and dumb, but hey that's what you can do in Windows land.

                    On Linux there are containers (lxc, Docker and friends), and Flatpak is the "consumer application equivalent" of containers.

                    Comment


                    • #50
                      It's amazing how many security sandbox & container options we have now. Off the top of my head:

                      Desktop app sandboxing:
                      • Flatpak
                      • Snaps
                      General app sandboxing:
                      • Apparmor
                      • SELinux with that MAC stuf
                      • The systemd container and nspawn stuff
                      Guest operating systems in a box:
                      • Docker
                      • LXC & LXD
                      • VirtualBox
                      • VMWare
                      • KVM
                      • Xen
                      With that last category above, it's hard for me to know what to pick when I need a guest VM. At present I tend towards using whichever option has the best documentation for whatever distro I'm using and also has the features I need. Except I wont use VMWare because it's proprietary. I prefer software which isn't shrouded in secrets, threats of violence & restrictions.

                      I think the LXC stuff and the systemd stuff is using largely the same underlying kernel APIs (cgroups, capabilities & namespaces etc).

                      Comment

                      Working...
                      X