>Said to be the replacement of X11. >Removes old cruft no one was using any more

anon that has been gnome since the dawn of time

Mouse acceleration has been the default in every OS forever so if you turn it off it's likely going to be harder to use for a lot of people. That line makes complete sense.

While that's true it doesn't change the fact that it has been the default and turning it off would feel bad for a lot of people.

Yeah, a peer-reviewed study might change the outlook on that. Go do one.

>Mouse acceleration should be the default because it's the default
That's a tautological argument. Yes it would show up in the data for a study taken between 2000-2015.
However, the default *should* be whichever setting is more natural for humans WITHOUT any priming from prior experience.

Honestly mouse acceleration is only usable with a touchpad. I can't fathom how people use it otherwise. It's probably the default because laptops have sort of taken over computing for most people. Even my work machine is a laptop.

>I can't fathom how people use it otherwise.
With shitty old mice, mouse acceleration was necessary (because the only alternatives are either the cursor moves fast and skips pixels, or the cursor moves so slow that the mouse is literally unusable.)

xcb is really good except for the fact that the documentation is horrible (i.e. existent).

Which is we they don't have telemetry.

moron
sysctl -w kernel.yama.ptrace_scope=3

>so the malware can literally just download a maliciously patched version of the compositor somewhere
What about the rest of malware that doesn't specifically target the compositor? Leaving every hole open because you can't stuff one is the most moronic security policy I've ever heard of.

>When you talk to the devs there about how that's “insecure” they'll just say
That's just massive cope for Grub being a massive monolith. Other bootloaders allow locking them down properly.

>ya ok, you're just moronic. If you run shitware unconfined, then obviously you will have issues,
Yes, and that's the only thing Wayland tries to protect you against.
Malware you already run.
Wayland doesn't further protect than X11 against anything that runs outside of your own user account.

>You cannot do this in X, thus the "muh keylogger" shit.
Actually you can. The XSecurity extension exists to give windows in X11 a namespace and on top of that Firejail was able to sandbox X11 using Xpra or Xephyr bridges before Wayland even existed.

But anyone who ever defended Wayland is supremely ignorant and doesn't know what he's talking about so you probably didn't know this

Ever actually tested the performance?
It doesn't seem like the bridge can be a serious bottleneck to me.

But you probably didn't even know it existed, let's be honest.

>xephyr
does it even support hardware acceleration?

>Plugging 99% of holes and leaving 1% open is æquivalent to leaving 100% open.
This is idiotic, the bootloader analogy is even more idiotic. When you reduce attack surface you only need to worry about very specific parts, which makes it much easier to actually secure something. In contrast, when you have a massive attack surface you can't do anything about security at all, you just leave yourself open on every single vector.

Yeah, and it doesn't matter how many are open here. In this case, 1% is the same as 100%.
Do you think attackers use multiple holes at the same time? Of course not, leaving 100% open just means they have the luxury of chosing which, but in the end 1 hole is sufficient to get in.

There's of course a practical difference if the holes not be discovered and not be public knowledge, but in this case they are. They're trivial exploits any attacker should know about so it doesn't matter.

Of course, it's all asinine to begin with since it's trying to protect against malware that already runs as your user.
>Oh noo, this malware can delete and read every file on my system... better worry about it snooping my keypresses!

And again, it can still snoop. Wayland doesn't stop anything about that.

If you don't have root on your machine you've got bigger problems.

>Literally never worked at a company
>Hurr durr, I'll just phone the admin every time I need to fire up a debugger so that he can enable ptracing for the time it takes me.
Yeah no.

And if you have root it doesn't matter anyway, then the malware has root and can enable it too. All it needs to do is overwrite sudo with a malicious version and wait for you to enter your password. Of course, if you try to avoid this by using passwordless sudo then it... can just use it at any point.

It doesn't matter anything, this is why it's a security theatre. “security” for a bunch of idiots who don't realize how real malware works and how you talked about yama.ptrace_scope made it blatantly clear you had no idea what it was and how it worked.

Lolno. Oh my god how dumb are you people.
Literally all you need to do is add a login shell function called “sudo” that shadows the actual “sudo” and calls it then.

In the event it is password configured, it saves the password and now has it.
In the event that it's not password configured, it's not even needed, and it can call sudo at any point.

>Not knowing a basic m.i.t.m. attack.
I repeat, you people who actually believe in this Wayland security theatre are the most ignorant little wankers about security I've ever faced. The protections you come with are absolutely laughably trivial to circumvent. You can dream up holes in them in your sleep.

Did you actually think I was talking about overwriting the actual sudo setuid root binary? Of course not, all it takes is a little wrapper around it which can be installed in 8494894 ways.

And if you think that the root/user distinction even matters on a system where the user has root you're sorrily mistaken. If the user account of an admin that can log in as root with sudo or some other mechanism is compromised then that malware has root as well. The only way to stop this is a severely locked down MAC system where admins can't even edit their own login shell configuration any more. Some highly security sensitive contexts might use this, but no normal company does this because it's impossible to do normal work on such a system. Can you even name but a single desktop distribution that ships like this/

Anon, you add

sudo () {
// malicious code goes here
}

To ~/.profile or ~/.bash_login or whatever

It doesn't require root, and there are 48498984 other ways. /etc/shells is a completely different file and lists what shells users are allowed to select as their login shell and again, they can easily ignore that restriction by simply making
~/.profile contain nothing more than “exec <other shell> -l” and nothing more. That restriction too is a complete security theatre.

>Root is required to do that.
Imagine not knowing about PATH, lmao

If you're paranoid you can also set the immutable file bit on your shells rc files.

None of this is relevant to Wayland though. Wayland assumes your system isn't compromised because it cannot protect you if it's already infected.

It's not security theatre, it does still help against an infected system but your system is still fricked either way.

The fact that clients can't snoop on each other offers some level of protection even though your system is fricked anyway.

>Is there even evidence but a single attacker exists with that specific level of knowledge?
Not that I'm aware of but defence in depth is still a great thing to practice even if there is no evidence that it could be exploited. There's no point weakening software security if you can make it stronger.

So far that hasn't happened. None of the security stuff has broken a users ability to do things. Developers made secure solutions for that like Portals (or in the case of some, relented and weakened security in the form of custom Wayland protocols).

You always could have had it, you just had to manually bind a shortcut to some IPC function.

What we have now is an API to allow applications to set shortcuts themselves instead which is much better.

>cant paste into videogames
> or remote desktop with the only remote desktop that supports audio
so far x is better in every way

>Portals
hacks with dbus lol

>Just use the full path to sudo every time you use it.
Do you do it?
It doesn't matter anyway because that too can easily be circumvented. The attacker can run malware on your user account. It can easily install a patched version of bash and edit your ~/.profile so that it execs into the patched version right away, thata patched version is edited to log your password whether you usse
>sudo
>/sbin/sudo
>/usr/sbin/sudo

Doesn't matter. It will log it either way.

Your protections are kiddie teir and not even things anyone does. It really shows how little you know about security if you think this absolute air protects anyone against anything.

If you're paranoid you can also set the immutable file bit on your shells rc files.

None of this is relevant to Wayland though. Wayland assumes your system isn't compromised because it cannot protect you if it's already infected.

You can add all those things, and the malware can can delete all that again as well because it runs as your user.

The only way to stop the malware fro editing your shell configuration, is to usse a MAC system that stops YOU from editing your own configuration.

So if you want to have a system where you can't add your own custom functions to Bash any more and edit your own configuration, then yes, then, and only then, can you protect against this, which no one does because it's too inconvenient.

Conversely, if your system isn't compromised, Wayland offers no benefits over X11, hence why Wayland is security theater.

Indeed.

The complaints against X11 are asinine. Like Wayland, like every other thing on your system:
>If your user account be compromised, you're lost.
>If it not be, you're protected
That's how X11 works, that's how Wayland works, that's how every other program such as “rm” or your web browser or whatever works. User account compromised means game over and yes, if you be an admin who can log in as root, it's only a matter of time for them to get root.

The attacker can unset that bit.
It has access to your user account. Immutable file bits don't provide security, they protect against accidentally deleting something.

Did you actually think you couldn't just unset that bit? If you couldn't you could never edit it again after setting it.
Besides, the attacker can literlaly unlink the file and install a new one. Unless the immutable bit is set at the parent directory, in which case... you can't make any new files in $HOME any more...

Unless of course you unset it again which as said, you can easily do.

Are you actually this ignorant about how this works? You come across as someone who just googles random things to try to sound smart in a discussion you don't understand. The way you talked about yama.ptrace_scope made it clear you had zero experience with it.

The attacker can unset that bit.
It has access to your user account. Immutable file bits don't provide security, they protect against accidentally deleting something.

Did you actually think you couldn't just unset that bit? If you couldn't you could never edit it again after setting it.
Besides, the attacker can literlaly unlink the file and install a new one. Unless the immutable bit is set at the parent directory, in which case... you can't make any new files in $HOME any more...

Unless of course you unset it again which as said, you can easily do.

Are you actually this ignorant about how this works? You come across as someone who just googles random things to try to sound smart in a discussion you don't understand. The way you talked about yama.ptrace_scope made it clear you had zero experience with it.

$ touch foo
$ chattr +i foo
chattr: Operation not permitted while setting flags on foo
$ sudo !!
$ sudo chattr +i foo
$ lsattr foo
----i---c------------- foo
$ chattr -i foo
chattr: Operation not permitted while setting flags on foo
$ rm -fv foo
rm: cannot remove 'foo': Operation not permitted

So now we're back to:
>The malware can do stuff with root if it already has root

>You can add all those things, and the malware can can delete all that again as well because it runs as your user.
Setting the immutable file bit requires root privileges. Once it's set it can't be removed again (without root).

cloudflare injecting packages into apt that dont match release signatures is way better for a mitm attack tbh

Firstly, you've now entered into territory that absolutely no admin on the planet does to keep your weird theatre alive.

Secondly, it doesn't matter because the tool you checksum with is also potentially compromised, it too can be overwritten and spoofed to provide a false result.

To copy it back, there needs to be some time window wherein it's writable, in that time window the malware can access and ovewrite it, any tool you can use to check that it's not overwrriten can have similarly overwritten to give you a false result so you'd never know.

Of course, this is all extremely theoretical and we've ventured into a non-practical world of things that will never actually happen and what is theoretically possible. The actual reality is that ~/.profile is editable on almost all systems and that no sysadmin takes the kind of care you speak of, because it doesn't matter, because there are 4849884 zillion other ways, as said. THe moment mawlware has access to any account that can login as root, all bets are off and one should assume the attacker gained root, and simply on a hardware level nuke the drives and start over from a backup before that point.

Of course, one should structure one's backups in a way too that it can't be compromised, even with root, which is easy.

you can also just use user namespaces too.
moron.

>So you disable it to run your debugger temporarily.
Ahahahha, you prove your ignorance.
ptrace_scope=3 can't be disabled when set without a reboot. It would be useless if it coud. Furthermore, it needs root-access to change to begin with. If it could be changed without root-access then the malware itself could obviously just temporarily disable it to ptrace anyway.

God you proof you talk about things you don't understand.

>We do not compromise security for the sake of debuggers and a few other applications. These usecases are the exception not the norm.

THen it's a good thing that, as I explained, it doesn't even matter. Even on a ptrace_scope=3 system the compositor can still be commandeered in a myriad of ways and, as said, almost no system ships with setting 2 or 3 because people like their debuggers. Most ship with 0 or 1.

Can you even name a system that isn't a router or something whereupon obviously no one is debugging that ships with 3?

>When you talk to the devs there about how that's “insecure” they'll just say
That's just massive cope for Grub being a massive monolith. Other bootloaders allow locking them down properly.

Grub also allows it. It's simply not set like that by default, like any other bootloader, because it's useless.
Note the keyword “allowed”; it's there for people who have a use case for it. Opposed to Wayland which forces you into it for no benefit but a security theatre.

>It's not even a matter of “breaking Wayland security” but simply ignoring it's entire existence and walking around it.
But that's security in another area that is not Wayland's responsibility nor what it provides. We are taking about "Wayland" not linux as whole.

Yes, and that's why the analogy with the door holds.
The door manufacturer can just as easily say “Well, it's not my responsibility that someone can walk around my door. My door is secure and no one can break in.”
It doesn't help to make oneself more secure all the same, and anyone who advocates putting a door inside of one's living room to help against burglars doesn't know how houses work.

Just like all these Wayland people that actually thought it would make a difference don't know how operating systems work. It's like complaining that rm is not secure because malware can use it to remove one's files once it runs as one's user... well yes, obviously?

It was a stupid idea all around.

Also if you buy a big ass door and a good solid lock and put it in the middle of your bed room, that's on you dude for being a dumb arse. The door and lock work. your brain does not.

Yes, you are an idiot for believing that WAyland will improve your security situation.

The issue is that in this case, the door as in Wayland, is made by a door manufacturer who's actively telling people that putting it in their living room will improve their security situation somehow, not only that, but claims it's “essential” and that doing this will stop their things from being robbed.

Also if you buy a big ass door and a good solid lock and put it in the middle of your bed room, that's on you dude for being a dumb arse. The door and lock work. your brain does not.

>Clients have no business doing that.
Literally most Wine and native games
>There's theoretically nothing preventing an application from calling kscreen-doctor or wlrandr, or whatever GNOME does, etc.
I have no idea why would native Wayland application do that

Sounds like (You) don't understand anything dipshit.
X.org is as everyone said, insecure. Wayland means you can run windows that receive input events in a way that isn't nearly as bad, much like how phones fricking work. You're a dumb moron.

>screen recording, color picking, push-to-talk, drag and drop between programs
you don't NEED to do any of those things

Wayland feels like an active sabotage of the Linux desktop. Things are messier and worse than they've been in decades because of it. The fact that small devs cannot support Wayland in any form kills small DEs. It almost feels like that is the point of Wayland - to be so convoluted and work-heavy so as to destroy small independent efforts.

Yes, and it still takes a tonne more effort than an X11 window manager to do it with all that.

Anon, why do you think only 3 X11 window managers were ported to Wayland and all the other things are fresh projects? Because it's a nontrivial task to port it because now you have to be an entire server, not just a window manager.

I don't think you realize how simple an X11 Window manager is as a piece of software compared to a Wayland compositor. Most of these Window managers were typically used together with an entirely different X11 Compositor.

My setup consists of the picom compositor and the Fluxbox window manager on X11. On top of that I run a huge number of scripts that make organizing windows easily, none of which will work on Wayland, asking me to simply rewrite those scripts is obviously silly. The only reason I was able to write them in the first place was because they incrementally over time grew in functionality as I discovered that I needed it. Now my workflow has become dependent on it in muscle memory and it's not something that can be ported over night if it can be ported at all, and if I manage to port it, they will only work with one wayland compositor's nonstandard interface while these scripts now work with any EWMH-compliant window manager on X11.

>NTA but the only people who use multiple window managers are rice hoppers
Or people who release software to the general public.

The window manager itself in my case is hardly relevant. I use fluxbox because it's lightweight but I don't use it's bar or decorations and purely use it to set EWMH atoms and read them in my scripts and it's hotkey daemon.

>The majority of developers target GNOME and KDE and it has always been that way. It has been the job of the developers of window managers to try and provide support for non-compliant operation that applications use.
No, with X11 the majority of developers don't target anything at all because it's all standardized.
wmctrl works everywhere, xdotool works everywhere, picom works everywhere, redshift works everywhere.
It doesn't matter what your window manager it is. It works, because they provided standardized interfaces to allow this rather than a bunch of incompatible ones exclusive to particular compositors where they all lack some features one might want that the others have.

>Likewise, with wayland, if an application uses environment specific extensions to the protocol, it's up to the developer of a compositor as to whether or not they want to support it. It's not nearly as different as anyone makes it out to be.
Yes, on Wayland basic needs are “environment specific extensions”. On X11 these are standardized and available everywhere and not even provided by the window managers themselves but the standardized tools built upon them that work everywhere.

>Also in reference to this, it depends on how the window manager is written. It was very easy for ex. qtile to provide a wayland backend becauase it's primarily in python, and was already factored in a way that made it much easier to do so. Sway maintains compatibility with i3 configuration but it's not the same thing as a port.

And for most it isn't easy since it works in a very different way and on top of that one also has to be a compositor now.

A window manager is purely concerned with the location and placement of windows and in some cases decorations of them if they be reparenting. Suddenly having to compose the final layout as well, as well as providing a hotkey daemon, a notification daemon, a bar and al that wasn't the scope of many of the projects.

You can write a mostly working x11 WM in a weekend or two. Making your own wayland compositor is a massive undertaking in comparison. This wouldn't be so big of a problem if you actually got your money's worth (or time in this case) out of all the extra manpower, but not so much in this case.

This could have been a believable argument but then you unironically tried to assert that making a compositor with wlroots or smithay was simpler lmao.

To that point, there is literally only one WM I've used that has actually supported basically every part of the protocol effectively and that's awesome. Every other WM doesn't support ex. struts and docks properly, doesn't handle size hinting compliantly, doesn't handle popups properly, and also relies on the abysmal state of picom who's glx back-end has been a disaster since it was first implemented for any kind of compositing effect.

I said "mostly working". I didn't say "bug-free".

Nice LARP but you're just being dishonest at this point and hiding behind vague claims/assertions as typical of wayland advocates. The actual xserver does the vast majority of the heavy lifting for you and is where most of shit you care about is already implemented. An X11 WM is just a special client. In contrast when you make your own wayland compositor, you're designing your own server that also does window management. There are some libraries to ease out some things on you, but this is fundamentally a much more complex task. It is not comparable.

yeah okay concession accepted

To that point, there is literally only one WM I've used that has actually supported basically every part of the protocol effectively and that's awesome. Every other WM doesn't support ex. struts and docks properly, doesn't handle size hinting compliantly, doesn't handle popups properly, and also relies on the abysmal state of picom who's glx back-end has been a disaster since it was first implemented for any kind of compositing effect.

Because these people bought into the GNOME propaganda that X11 cannot possibly be sandboxed.
GNOME really put that on it's website when Firejail already existed and could do it before Wayland even started.
It has been brought to their attention numerous times that that is a lie and they never removed it with some flimsy semantics argument of how it “doesn't count” knowing full well they're deceiving people.

Of course, security was never the real goal.
Its just an excuse to limit functionality, while creating more and more work for themselves, so they can write the program they want.

Needless to say, blocking a few attack vectors one the attacker has RCE is pointless. You need a fully secure VM, which wayland is not.

Limiting flexibility seems to indeed be the actual goal given all the quotes by Alan Day and other GNOMEtards that make it blatantly obvious they think it hurts their “brand identity” if people can configure too much.
They're not wrong; it does hurt their “brand identity” and that's why they do it. Also, that Wayland is far too much effort to implement for a small team opposed to X11 where everyone shares the server and only needs to do minimal work eliminates competitors.

Seems fine on my machine

You're not using the features everyone is missing.

Things not crashing when you move the mouse while an application happens to be busy is a feature of X I enjoy, but I suppose maybe Wayland users just don't mind their apps committing 41% all the time.

firefox was doing this so much when you were downloading anything (including pictures off of IQfy) that they invented a proxy app to keep it alive on wayland
https://www.phoronix.com/news/Wayland-Proxy-Firefox

it can still happen, the size of wl_ring_buffer is only 4k

happens randomly if firefox is busy and you move a 1k Hz mouse quickly

It doesn't happen with a 1ms mouse. It's more like a mouse that polls every 125 microseconds (8kHz).

Why doesn't the server just ignore mouse events that were not received by clients? there is no difference between moving your mouse 50 pixels and then 50 more pixels and moving it by 100 pixels instead

And what decides that?

that's what happens when you use ancient programming language whose advanced data types are only array and linked list.

>what is async
>what is bounded channels
>what is blocking collection

In many cases they simply didn't like it as much.
The F.S.F. assumed that everyone would like v3 more but many people liked v2 more.
The “death penalty” bug of v2 they claim to have fixed and keep insisting exists has also been challenged by many legal experts and there is case law in many courts that shows it's not enforceable.

The issue with the GPL is much more problematic though. GPLv2 and v3 are not compatible with each other. Any code licensed under one cannot be used in the other. This is the big problem with strong copyleft licences, people often phrase it as that one should use strong copyleft so that proprietary software can't get a hold of it, but in practice it means that nothing except software under the exact same licence, including other strong copyleft can use the code.

>hyprland
>troony maintainer
no he's just gay
his mods changed someone's discord pronouns to who/cares

XFCE is tiny. 1 person working on something is par for the course. They're not GNOME or KDE. They do have a codebase though that has abstractions around things like the windowing system and they've already ported these bit to Wayland. It shows that you can port X11 window managers / compositors to Wayland if your code is well designed.

If you don't have any windowing abstraction then you're pretty much fricked and would be better off starting from scratch though.

https://wiki.xfce.org/releng/wayland_roadmap

What article?

>The proper fix would have been to do what win32 does
which is what?

Wayland and X11 as well guarantees that events are never lost or dropped. When the connection buffer gets full on wayland, the compositor aborts the connection and kills the application. On X11, it will realloc the buffer and grow in memory until you OOM (dumb hack but it basically works).

This is a dumb model to begin with however. Wayland had the chance to fix this, but of course they fricked this up and repeated X11's mistake. On windows, events can be dropped, coalesced, reordered, etc. as necessary. Considering moving the mouse a gazillion times like an absolute madman. Almost no application cares about movement 1 out of the 10000000 moves. It's dumb.

>but they arguably set it too small.
I mean it's possible to change this at the compositor level right? Like if I were using wlroots or something I should be able to increase the buffer?

>On X11, it will realloc the buffer and grow in memory until you OOM (dumb hack but it basically works).
It should be noted that since X.org suppresses mouse and keyboard events when a window is non-responsive, this should never happen in theory.

See

>On X11, it will realloc the buffer and grow in memory until you OOM (dumb hack but it basically works).
It should be noted that since X.org suppresses mouse and keyboard events when a window is non-responsive, this should never happen in theory.

>X.org suppresses mouse and keyboard events when a window is non-responsive

It relays events to clients. If the client is blocked, it doesn't get a message, simple as.
Mutter and weston do something similar, except they still have a fixed 4kb message buffer, so if that fills up before the compositor detects that the client is non-responsive, you're fricked. But on Xorg, the buffer is (theoretically) unbounded, so there will always be ample time for the server to simply stop sending messages.

Not him but doesn't mutter do the same thing? I think it still had the problem in the wayland bug report. It was just a lot harder to trigger. So in theory it could happen on xorg too but it would be even harder since the limit is INT_MAX and not whatever the low limit on wayland is.

Yes, but with the caveat mentioned above.

>usecase unclear
>closed wontfix

Arcan won't "win" unless desktops switch to it (and by desktops I mean GNOME or KDE, every other desktop is irrelevant). That's why Wayland has sticking power. As long as GNOME and KDE is behind it then nothing else is going to usurp it.

Also why the terrible language Go actually gained a foothold.
This is not a meritocracy, bad ideas win out all the time if they have a big corporation backing them.

GNOME saved Wayland. Had they not picked it up in 2013 when it was completely dead Mir would've been the argument now.

>GNOME is still an independent community project
GNOME receives a ton of corporate funding. I believe most of the developers are employed by Red Hat.

>Why does everyone talk about portals? They're purely a thing from within a sandbox and there's nothing secure about it.
Portal are great for standardizing basic interactions between desktops.

They standardise the API which is what matters to developers. Developers don't care how a screenshot or screen cast is taken. They do care that they are able to do this via the API.

The biggest support it. If your niche compositor you wrote in a weekend doesn't support it then that's on you.

All the major ones have an implementation.

Shh, you're not supposed to point out that people do non-standard things in X11 too. The protocol is perfect. It has no flaws!

Yeah, X11 is basically an old, rusty coffee machine that's held together by patches and duct-taped, hacked together to grow new functionality as it needed but it has lots of buttons and can make any coffee and mix thereof anyone wants even though even the people that maintain it aren't sure how it works any more.
Wayland is a brand new coffee machine with only two buttons for two tpyes of coffee on it that can't even adjust the size of the cup it fills.
>NOOO, YOU MUST SWITCH TO THIS NEW COFFEE MACHINE; IT'S MODERN

Obviously people who like control over their coffee are going to do that.
Wayland could have been the chance to actually fix the mess that is X11, instead they delivered an unusuably gimped piece of shit.

No, it's legitimately full of crap that no one uses any more like the drawing a.p.i. and the composition things are actually hacks.

Wayland could've been a big improvement if the compositor only did composition and it allowed an external window manager to hook onto it and other things to draw window decorations.

There is no technology originally envisioned in the 80s for 80s needs that is not a mess.

Wayland is also legitimately far cleaner, that part is true, it's simply gimped and it's a sodding phone display server in how limited it is.

Saying that Wayland is automatically “secure” is also nonsense, there are all sorts of issues still with it such as any client being able to inspect the clipboard.

>That's kind of necessary for the core functionality of the clipboard.
Not really, the clipboard could have been designed with a global hotkey for pasting in mind, once pressed, the currently active client gets some kind of signal with the content and can do with it what it wants.

>For what it's worth some compositors have the design decision that only focused surfaces can read the clipboard which is a conscious choice they made.

It mitigates it, but they can still see it without the user intending to paste it.

Wayland drew an arbitrary line in the sand and said “this is where it's secure”; it's not that simple.

> No, it's legitimately full of crap
No it's not.
- The core X11 network protocol is *really* good.
- The IPC mechanisms simple and elegant (unlike abominations like dbus).
- Xlib is not super great but has been fixed with the introduction of xcb.
- ICCCM has problems but has been fixed with EHWM
- XGL is inefficient for local 3D rendering but has been fixed with DRI3
- The original drawing primitives are bad but have been fixed with the introduction of Xrender

The extensibility of X11 has proven to be one of the major strength. Also many unused extensions have been completely dropped. This means there is a healthy cleanup process happening. The reason why the original drawing primitives still exist is backwards compatibility (which in itself is a huge value). A lot of programs use them and they are hardware accelerated as well btw..

The difference is that EWMH is actually standardized and pretty much all window managers support it.
Compositors all offer a very different range of portals they do support.

Let's consider a super basic task:
>I want to raise to the front the newest window that was opened, and make it fullscreen

Is there a standardized script I can write that will work on pretty much all Wayland compositors that I can just dump into ~/.loca/bin and watch it work anywhere?

Yes, but many protals aren't impllemented by all compositors, now answer what I asked.
Is there even a portal that allows what I asked? Are there even portals that allow the reposition and manipulation of window positions?

https://github.com/flatpak/xdg-desktop-portal/issues/304
This is 2019, but they didn't seem interested in providing a portal which allows for such basic information as:
>List all currently open windows.

Yes, that's what they say there.
So how can you claim that these issues are solved in a standardized way then?
That's what I and many people need. I have tonnes of scripts that re-arrange and manipulate window sizes. I have scripts that need to ask for every open window right now and what-now.
Why do you claim these things are solved and standardized?
They are on X11 of course. Moving windows around with EWMH is completely standardized and solved there. xdotool can do it.

People write software and release it anon.
Tools such as xdotool and wmctrl exist, they're supposed to work everywhere.

Also, GNOME scripts are known to break with every release.

But really, that's not the issue, people said it was standardized but I can't find anything and Kwin and GNOME have a scripting engine but Sway seems to lack it.

The other issue is that Kwin and GNOME scripts require that it be in their language. I don't feel like coding in ECMAScript very much. and I generally dislike embedded scripting languages for this reason opposed to simply providing some kind of cli tool or stabilized simple socket or pipe interface that can be called from any language. Many of these things I use are even written in Rust because the latency in Scheme was not acceptable. They had to do significant numeric composition and the problem of:

>tile all windows on the current workspace and arrange them in the least amount of space

Is a computationally expensive one and I anted to keep the latency as low as posible.

>it's a sodding phone display server in how limited it is.
There isn't a single thing I did on X that I haven't been able to do with Wayland. I don't work with application code, or debug GUI shitware, but I still recognize that it's a real issue. Outside of that, I can't think of a single thing that would be different.

Then maybe you can provide an answer to:

So to all those people who said portals solve shit. I just searched around and I literally could not find a portal which can do something as easily as instruct the compositor to resize a window.

Does this actually not exist? I had assumed it would at least for some though I had imagined GNOME would stay away from it. Do you people actually claim portals solved it when this basic thing doesn't exist?

said that it was because Wayland was only part of a fully secure system that would eventually come
that is correct.
we have various methods to isolate and restrict individual programs, starting with apparmor even.
But X always was the gaping hole.

how ever, maybe we can fix X security without gayland.

Anon, no commonly used distribution right now stops you from being keylogged by malware that somehow infiltrated your user account, Wayland or X11.
Apparmor doesn't stop this. It's all theoretically possible that a m.a.c. system stops this all in theory, but no system ships with m.a.c. so refined because it would make the system frustrating and annoying to work with.

We're talking about moving windows here. You know that xdotool and wmctrl and wmuitls exist for that reason right as well as other things?
They don't work on Wayland in a standardized way, it requires a different backend for every compositor which no one is going to code.

Yeah, or people who write xdotool or wmctrl.
Again, people release their software to the public. Many people actually use wmutils you know. It's supposed to work everywhere.

Same with basic things such a dunst which don't even manipulate other windows.

And again, I pointed out that using a script isn't even acceptable in many cases because it might simply be too slow. It was necessary at times to me to write it in Rust opposed to Scheme because the latency was simply too high. I doubt an interpreted Javascript solution will be faster than Scheme, especially for window manipilation, the response needs to be as snappy as possible.

Okay, so it can't be done on Wayland, the typical Freedesktop argument is just
>Wooow, you don't need this, just... abandon your entire workflow and be super unproductive on our GNOME desktop instead.

Xephyr can do hardware accelerated sandboxing btw

I think I read something like that that it was added now but have a source?

I've been using Linux for longer than dwm has existed, sorry, but pretending these features are non-starters for people is just moronic. I guarantee that I have _way_ more experience with the X ecosystem and the autism surrounding wms than you ever will.

What's the point of pretending to be some epic linux greybeard when people point out shortcomings in wayland? You just look silly.

Sway has IPC just like i3

Yes, both of them do. Sway's IPC is very good.

It actually works in sway. Kwin I assume has something but I have no idea how it works there. GNOME dunno.

We're not talking about that.
We're talking about a scripting engine, as in whether the window manager itself actually comes with an interpreter for scripts.

> comes with an interpreter for scripts
Why the frick is this relevant at all? it doesn't change the fact that every damn window manager offers you the ability to position windows and that's what people use in the vast majority of circumstances

>most don't even have that.
Yes they do!
You can control windows with bspc, i3-ipc, you can control windows with an API which of course uses a fricking scripting language (or C++), you can write functionality directly into dwm and compile it (which is what you're supposed to do because it's suckless).
> but for moving windows? No, that can all be done in a standardized way that works everywhere.
No it fricking can't, most tiling wms are not going to handle xdotool positioning windows, the window manager specifically needs to handle that in order to handle layouts. You haven't even used 90% of the offerings you're talking about and are trying to claim it will be standardized.

That doesn't change anything. The vast majority of people will use bspc, i3-ipc, awesome's api and so on to position windows. It's the same shit with any Wayland compositor. Literally nothing changes on that front except for the morons who never learned how to use their wm.

>Anon, only morons would use a specific interface when a standardized one suffices.
In the majority of cases the "standardized" one won't unless it's a very basic wm like blackbox, XFCE or its derivatives. Window managers are generally the thing that needs to position windows, not xdotool.
>Assuming I'm putting together some shell scripts and shit, I would absolutely use wmctrl or whatever instead
Enjoy it not working then.

It works fine for (you), it's not going to work for a huge portion of people that use, frankly, some of the most popular window managers available for X. They all write scripts dedicated to specific interfaces or using specific APIs.

literally any tiling wm is not going to listen to wmctl or xdotool and they are almost entirely useless for them. At most you will move a floating window, or move windows to the front/back of a stack. Even then, it doesn't make sense to not just use the very thing that it expressly built for the purpose of doing that.

Really? wmctl is going to move a window out of a tabbed layout? i3 is going to let that happen and properly handle all of the operations that need to happen in order for the tree to be proper?

Oh, so, in basically any tiling wm it's completely useless and you're just pulling in an extra tool for nothing? So much for working everywhere.

Didn't do shit senpai

>it talks to them
Actually it doesn't talk to the window manager, both of them talk to something else. Do you need a hint on what that is?

>yes it goes through the X11 protocol but what's on the other end is the window manager.
Uh, no, that's totally not how it works lmao. What's on the other side is the server, not the wm.

>The server passes the message from one program (xdotool) to another (the wm
No it doesn't. It doesn't pass it to the wm at all, you buffoon.

It's fricking called "Extended Window Manager Hints". The entire point is for applications to communicate with the window manager. Do you think this all works via magic?

>Hey, you wanna know what's actually universal on X? The actual API. Not some fricking shell tool.
The shell too just uses X's API mate...

Almost seems like you could have just used a proper language because your scripts are apparently SO COMPLEX that you can't port them in a few minutes. Seems like that's a really moronic thing to do with shell scripts.

This is not even a coherent argument. I get that anon's setup apparently enrages you for whatever arbitrary reason but that's entirely irrelevant. Whether he uses his custom set of shell scripts or some window manager IPC that pleases your autism is completely irrelevant. Under the hood, these things all work the same way through a standardized interface (X11). You can't say the same for the wayland versions.

"Something generic" works totally fine in most cases.
>inb4 more incoherent raging about tiling window managers

Bro, just float your windows if you want to move them around. You can do this in one line in your i3 config. It's fine.

To make sure the exact same script also works on another window manager.
>But but but.. sotware shouldn't be portable.

Again, I have no idea why using xdotool makes you so upset but if you want to use i3 ipc instead, go ahead.

It's a generic tool that works on any x11 window manager. It's really not that complicated.
>A window manager does everything xdotool does
I highly doubt that.

It's not about being incapable. It's about whether or not every window manager has implemented all of those commands in a scripting interface or something similar. Again, I highly doubt every window manager exposes all of that functionality in some way. Some might.

Is it the moving windows part? It's probably the moving windows part right? After all that's what anon wrote his script for.

moron

It's a generic tool that works on any x11 window manager. It's really not that complicated.
>A window manager does everything xdotool does
I highly doubt that.

It does, because xdotool literally talks to the window manager and asks it to do it.
But anon here doesn't seem to understand the benefits of standards somehow and that there's literally no reason to write software so that it will only work in one place, opposed to everywhere with no loss of functionality.

>J..jj... just use platform specific interfaces instead of standard ones that work everywhere.
Why ever?

Oh wait, because you don't actually believe this, you can't be that daft, you're simply trying desperately to defend Wayland.

Your argument is basically
>I hate standards
Wow.
Anyway, it's moving the goalpost. Originally we criticized Wayland for not providing various things in a standardized way, then people said Portals did that, and then it turned out they did not and now the argument is simply
>Who need standard lol
Yes, see if you can convince people to use Wayland with
>Shit that was standardized and write-once run everywhere now must be done in platform-specific ways because
>Rewriting code and porting software is fun and not a hassle at all!

Obviously no one will e convinced by this.

Performance is an asinine argument. The performance difference between that part and the actual numerical calculation is is immense and I doubt you can even measure the difference between moving a window by way of EWMH hints and i3-i.p.c.

X has one of the least opinionated APIs I've ever come across. Certainly far, far less than wayland is. You sound like a PTSD victim really.

>Anon, no one is going to talk to a window manager in a specific nonportal way to move a window around okay.
Literally every single person using a tiling wm already did this. Hell everyone on Plasma is using kwin scripts. So it's not even just tiling wms, it's also one of the most common stacking window managers in the entire ecosystem. You are the outlier. There's no getting around that.

>at all because it goes against what they do.
What are you even talking about? Are you implying that you can't move windows around in a tiling layout? Are you moronic? Have you used a tiling wm in your entire life?

>One of the whole points of such a configuration is to stop doing that.
No, the primary point of a tiling window manager is to put windows into a tiling tree or master/slave layout. That idea you came up with is completely subjective and I can tell you that a lot of people move windows around.

If you are writing shell scripts that are non-trivial to port you're doing it wrong.
>Use a floating one.
No, because I want my windows in a tiled layout first. Tiling wms objectively are supposed to layout windows in a tiling stack programmatically. What you decide to do with that is entirely subjective.

Yeah, this is just anon digging a grave and sticking to it.
No one can actually believe that, that's such a moronic argument simply to not have to acknowledge that Wayland has problems.
No standardized interface for
>Move window 5 pixels to the left
ist ein Problem.

>That lack of providing a common implementation is something you b***h about but it's also something that's wonderful for developers
No it isn't lol. This is maybe only good if you're a compositor developer because you can be lazy but it's horrible for everyone else. I mean just imagine if graphics APIs had no standards. It would be a utter nightmare. Yes that probably makes the job of the people writing the hardware drivers harder. sorry I guess?

What is even this schizo argument? So standards are good now if there's a protocol? Help me try to understand your mind.

Like I said, depends on the interface. X is awful to work with precisely because the X methodology is using common implementations of the X protocol. It's no different from the shitty, bloated frameworks that exist inside a bunch of legacy software projects.

Your argument is basically
>I hate standards
Wow.
Anyway, it's moving the goalpost. Originally we criticized Wayland for not providing various things in a standardized way, then people said Portals did that, and then it turned out they did not and now the argument is simply
>Who need standard lol
Yes, see if you can convince people to use Wayland with
>Shit that was standardized and write-once run everywhere now must be done in platform-specific ways because
>Rewriting code and porting software is fun and not a hassle at all!

Obviously no one will e convinced by this.

Performance is an asinine argument. The performance difference between that part and the actual numerical calculation is is immense and I doubt you can even measure the difference between moving a window by way of EWMH hints and i3-i.p.c.

>The performance difference between that part and the actual numerical calculation is is immense and I doubt you can even measure the difference between moving a window by way of EWMH hints and i3-i.p.c.
This isn't even about i3-ipc, this is about how hinting is done in the first place. Also just pointing out that the difference between parsing a string and then reading it inside the event loop instead of just storing and using bits as flags is going to be several orders of magnitude faster. Frankly it's not just a problem with X, it's a problem with a lot of the legacy shitware across the Linux ecosystem derived from muh UNIX philosophy.

No, standards are bad when you're forced into a common implementation, depending on the interface. Frankly, also depending on how good that implementation is. Sadly, X's implementations suck.

Almost seems like you could have just used a proper language because your scripts are apparently SO COMPLEX that you can't port them in a few minutes. Seems like that's a really moronic thing to do with shell scripts.

You don't even know what my setup looks like and how it works, you idiot.

>yes it goes through the X11 protocol but what's on the other end is the window manager.
Uh, no, that's totally not how it works lmao. What's on the other side is the server, not the wm.

No, it passes it through the server to the window manager that reads the hints and then decides what to do.

That doesn't make sense. tTe only a.p.i. I need is to get window positions and being able to set them.
The rest is programming logic. How I get and set the positions isn't relevant to how well it works except that some way are standardized and others aren't.

Can you even give me a window manager that doesn't obey this repositioning?

Even tiling window managers generally obey it, of course it fricks up the layout but that's one's own business and I wouldn't have a need to use them with a tiling window manager, any floating one will obey it.
>Enjoy it not working then.
Do you actually think these window managers are going to ignore EWMH hints but somehow honor their nonstandard ipc asking for the exact same thing/

>no I will not use my window manager who's sole purpose of existence is to position and manage windows to position and manage windows
Is this really what the remaining X users think?

EWMH are a standardized way to communicate with the window manager and ask it to do it.

Do you people even know what they are and how they work? Xdotool doesn't reposition windows itsself, it asks the window manager to do it which then applies it's own logic like moving decorations with it and all that.

It does the same thing as the i.p.c., but standardized.

Of course, some operations can't be standardized because they're window manager-specific by nature, but simply moving windows around isn't one of them.

Window managers have the final say. They can just deny/ignore it. At least that's what i3 does if the window isn't floating which is exactly what I'd expect any tiling window manager to do.

No doubt, and then it will do the same thing regardless of whether it's done with it's own custom i.p.c. or with EWMH hints. The difference is that the latter is standardized and will work everywhere but Freedesktoppers really like their vendor lockin.

Because 95% of the things I want can be standardized and the 5% that are specific, there's obviously no point to take them with me to another window manager because it fundamentally doesn't make sense on them.

The window manager only positions windows, it does not handle intelligent algorithms that automate this by way of common patterns.If I should ever hop to another window manager I'd like to take that with me. Of course many of my friends are also using these things I wrote because they thought it was useful and I could simply give it to them unaltered since it doesn't rely on any fluxbox-specific interfaces as all they do are move windows around.

No it doesn't, and I don't use a tiling window manager to begin with.
This is peak Freedesktop mentality
>Just abandon your own personal workflow that works for you and use something completely differently that works for me, bro.

I don't tile my windows by nature because I think perfect grides are very distracting to work with. This is not uncommon at all that many people perceive perfect regularity to be disorienting.

I think they often still do it then, it simply breaks the layout.

Obviously I don't intend to use window reposition scripts if I should ever jump to a tilong paradigm.

The point is that these scripts sort of turned it into a half-tiling window manager. As in they make it very easy to re-arrange windows so that they don't overlap, but not necessarily in a grid.

>that every damn window manager offers you the ability to position windows
I don't think that's accurate. Some do have their own ipc, whatever for easier user configuration, but it's not a given. Standard X11 tooling will work just about anywhere though.

I've been using Linux for longer than dwm has existed, sorry, but pretending these features are non-starters for people is just moronic. I guarantee that I have _way_ more experience with the X ecosystem and the autism surrounding wms than you ever will.

>Most if not all compositors already gives you the ability to do this.
Do they? I'd be surprised if this was possible to do in mutter in a scripted way

You are aware that X11 could be sandboxed before Wayland even started right?

The situation for both has been the same since WAyland's inception and hasn't changed since:

>Malware runs as your user: you're fricked.
>Malware runs in a sandbox: you're fine.
X11 or Wayland doesn't change that.

So it can be sandboxed. It's simply not hardware accelerated, for which there's no theoretical reason why it couldn't by the way.

>You are aware that X11 could be sandboxed before Wayland even started right?
show me how.
I run firefox, chromium, pidgin. How to disable ability of them all to use X to keylog or read window content of the other ones, assuming they are isolated from touching any files and sockets and memory on the user (besides what is the part of X protocol)

https://firejail.wordpress.com/documentation-2/x11-guide/

>https://firejail.wordpress.com/documentation-2/x11-guide/
wasn't firejail recommending to use gayland?

>The difference is that EWMH is actually standardized and pretty much all window managers support it.
That doesn't matter if it's still dogshit and everyone tries to work around it anyways. The entire reason I loved awesomewm was because it provided a framework for window management (or developing a wm) that abstracted the absolute moronation of X and EWMH. This was after I had already contributed to and poured hours into doing this on other WMs over time. In contrast working with wlroots or a compositor like hyprland is even better because
1. It's not fricking lua
2. it's not fricking shell scripts
3. its plugin system makes it easy to change whatever the hell I want, right down to the most basic functionality, you can't do that in X without forking core components and dealing with the god awful design
I highly doubt whatever the hell you were doing on X is any more complicated than what I did with awesome and 15k lines of lua.

GNOME and KDE has failed to make a sizeable dent to anything for forever.
Meanwhile Android went from literally a broken dried up piece of semen in Andy Rubins sock to dominating. ChromeOS was a funny experiment that carved out a sizeable niche.

The win for Arcan is to find an upcoming niche and be ready for it. A nice gesture would be to support a gradual migration path from Xorg that doesn't require rewriting everything from the ground up. They showed that they have one in their latest release post.

Even better, clients that try to do something through Portal and Wayland breaks Waypipe (that also can't handle Xwayland) so gg network "transparency".

>Are you moronic or what?
This is a question I have to ask of you. Wayland was so lacking in features and so dysfunctional that some guys came up with desktop portals to basically hack around it. Note that wayland is so bad that these things can't even work using wayland's IPC but via other methods. So now your wayland application made suddenly have to depend on non-wayland things if you're looking to do basic things any sane display server provides. Also it's still limited in comparison to every other platform anyway and adds yet another clusterfrick of optional protocols/apis that the compositor may or may not support. Of course, wayland advocates somehow see this are perfectly sane and rational.

>that the compositor may or may not suppor
Compared to the 3000 windowing hints that a window manager may or may not support, as well as ONLY KDE and Gnome supporting a hint like _NET_WM_BYPASS_COMPOSITOR, and their compositing was non-standard to begin with, even their basic implementation of systrays (not that GNOME even supported that at all eventually) is non-standard because the specification for them in X is fricking moronic.

>Yes they are, literally every wm uses the xserver which is an enormous pile of shit.
EWMH isn't implemented in xserver itself obviously, so I don't understand what you're trying to argue. Are you just mad that extensions are implemented in xorg or something? Care to point out which one upsets you so much.