>Said to be the replacement of X11
>Removes old cruft no one was using any more
>People from the very start said a lot of that olc cruft was used by many people but the “I have no idea what XFCE is or does, sorry” effect was strong
>From the very start people pointed out that the “security improvements” had no practical real life impact and were about as effective as putting a giant door with a big lock in the middle of one's room against burglars who had already broken in who could simply walk around it
>People said that it was because Wayland was only part of a fully secure system that would eventually come
>14 years later, this “more secure system” still isn't there and Wayland's “security benefits” are still not of any practical nature
>X11 is still used by the majority of people
>Wayland still doesn't do what most people need it to do
>Almost no window manager has been ported to it
Kek
Shopping Cart Returner Shirt $21.68 |
I think XFCE is working on Wayland support
I don't really care which one I'm using as long as my software works. Whatever my distro ships I'll use. Same thing I said about systemd and I stand by that.
sooo, will it be called WFCE now?
It will be called LGBTFC
That would be funny but I think they'll stick with the name just to be consistent. It'll probably also run on X for a very long time.
Maybe they'll pick a real name and not this indecipherable acronym.
Fun fact: the X in Xfce doesn't stand for "Xorg" or "X11", it stands for "Xforms" which was the original toolkit they used before GTK even existed.
Since they didn't change the name to "GTKce" after moving to GTK, it's unlikely they'll change it for Wayland or another toolkit in the future.
Bonus fact: the "ce" stands for "Common Environment." Xfce is the Xforms Common Environment.
>Xforms Common Environment
back when CDE was considered the height of Unix user friendliness (aside of NeXT which was its own thing entirely)
Your software won't work, that's the issue.
Looked for Wayland support for XFCE and found this thread:
https://www.reddit.com/r/xfce/comments/10609bg/wayland/
It doesn't seem to be a pretty picture and they're mostly complaining how it's an insane amount of effort for very little gain that small teams can't bring up.
if XFCE goes Wayland first (rather than treating it as a second class citizen), then I'll stop using it. Death to Wayland! Death to GNOME! Death to KDE! Death to Redhat!
Not really, read the thread:
https://www.reddit.com/r/xfce/comments/10609bg/wayland/
Some devs are working on it, progress is minimal, most of the devs don't consider it worth the effort.
At this point it's basically a Debian GNU/kFreeBSD tier meme done for the memes because they can.
good, because any effort spent on Wayland is a waste of time. It's spent how many years shilling itself as superior while it has a subset of features of Xorg while not introducing any new features. It's an abortion of a display server, and never completed projects like Arcan have a better chance of replacing Xorg than it.
A 'superior' replacement you have to force users to adopt is neither superior or a replacement.
never seen a reason to use wayland. just dont see the point. i hope xfce never switches to it.
This gives me hope.
Sure. Expect that migration to finish around 2040
glowie
Gayland is broken at its foundations by principle and will never be ready. It's a bad idea maintained by unskilled, out of touch people.
I'm curious how many years it will take for people to realize that this will not fly.
They're not unskilled but they're definitely out of touch.
I remember talking with the E developers when this just started and the shit they believed and came with was so out of touch.
Rasterman actually believed that video games had streaming built in and had never heard of OBS. He thought games just did it themselves and stuck to that opinion once told he was wrong.
Debating some of the GNOME devs also revealed that they seriously thought there was no need to be able to configure or disable mouse acceleration because all their friends were using it and they never heard of anyone who disabled it.
That's just the general state of affairs of talking with Freedesktop folk; it quickly becomes apparent they're living in a bubble and have an extremely narrow perspective. That the lead dev of GTK once said “I have no idea what Xfce is or does, sorry.” sounds too ridiculous to believe but it's true. He actually never heard of the second largest consumer of his library and purely focuses on GNOME.
I mean, in a world where knowledge is a skill being out of touch IS being unskilled.
Their sole fricking job is to implement into their silly display server things that are needed for people and if they have zero clue how shit works and what things are important or not then yes they are unskilled and not qualified for their jobs.
Have you ever even used GNOME?
I know they added it now after many complaints.
As I said, this was over 10 years back when the libinput dev said there were no plans to add configurable mouse acceleration and a way to disable it and he got flamed so hard that he eventually did.
anon that has been gnome since the dawn of time
Is there any evidence to back up this claim?
Surely they have peer reviewed research to support the claim that mouse acceleration makes the mouse easier to use?
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.
Only because old mice were low-DPI, so your choices were
>turn the sensitivity so low the mouse is unusable
>turn the sensitivity high enough to move the mouse, resulting in the cursor skipping pixels
>use mouse acceleration, resulting in inconsistent mouse movements
This is no longer the case, most mice are high-DPI these days.
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.
A peer reviewed study would be able to account for this.
Early studies by Xerox, Apple, Microsoft (surely they did studies, right?) would not have this issue.
Moreover, a modern study involving zoomers (who only know touchscreens) wouldn't have these issues.
Yeah, a peer-reviewed study might change the outlook on that. Go do one.
Nobody does studies anymore everything is decided by telemetry but naturally GNOME doesn't have that. They have no idea how people are using their desktop.
KDE at least has some telemetry in their desktop (it's optional before any privacy schizos jump on this)
>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.
>However, the default *should* be whichever setting is more natural for humans WITHOUT any priming from prior experience.
Where's your peer-reviewed study proving it?
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.
>. It's probably the default because laptops have sort of taken over computing
It was the default long before laptops were that common.
>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.)
How is it even allowed to be so incompetent and harmful?
XFCE fricked up HARD by falling for the anti-qt propaganda and using GTK. They should just admit that they based their entire project on code from people who hate them, and move on. LXQT fills what xfce used to
They have, many times.
The developers have said many times that they sorrily regret it but of course one can't change this now.
GTK wasn't always this bad before Red Hat took over. — They couldn't have known.
If that be the case then why even say “unskilled and out of touch” and not simply “unskilled” if one supposedly be a subset of the other?
>LXQT fills what xfce used to
it can't even iconify to desktop: it's total shite. xfce isn't just any desktop, it's a modern implementation of CDE. if you're a zoomer xfce's not for you and feel free to stick with lxqt
Wayland is a perfect example of why this industry turned to shit. A bunch of trannies getting their little nubs hard over completely unnecessary software just because it's new.
>completely unnecessary software
X *is bloated*
X *does* lots of moronic shit that is not needed since like 20 years (you need ability for X server to draw a dotted line for you?)
X *is* insecure (see above)
So? None of that refutes the fact that Wayland is unnecessary and doesn't fix anything.
X is insecure in the same way that “rm” is insecure, that cat is insecure and that the “>” operator in the shell is insecure.
It's such an asinine complaint to single out X11 on this.
>nooo, malware that runs as my user can compromise my system.
Wayland doesn't stop it either. The security situation for both X11 and Wayland is identical:
>Malware runs as your user: you're fricked.
>Malware runs in a sandbox: you're fine.
X11 or Wayland doesn't change that.
X is not really bloated in any meaningful sense. The biggest sin on that front is that there are some legacy things in the codebase barely anyone uses but that's hardly anything to lose sleep over.
X's biggest sin is that its API is moronic to work with. It's written with methodologies and designed the way software would have been 2 decades ago. It's shit.
XCB is just fine.
The bare API is far superior to anything Windows or even Macshit has to offer.
xcb is really good except for the fact that the documentation is horrible (i.e. existent).
non-existent*
>X11 is still used by the majority of people
Is this even true? Most distros ship Gnome by default, which has had Wayland as its default mode for a while now. Even KDE is Wayland default now. Those are the two most popular options.
They only use it by default if the distribution is configured to do so. Only Fedora does so I think
https://www.phoronix.com/news/Firefox-Wayland-X11-Stats
This is really the only statistic that's there but it finds that only 10% of FireFox users uses Wayland.
I doesn't mean that 90% of desktop Linux users or even 90% of desktop Linux Firefox users aren't using Wayland, but it's highly unlikely that Wayland is used by the majority of either
The majority are virtual machines or containers doing automation tasks, testing, etc which will skew the results a bit because most of them won't have Wayland available.
This is also very relevant:
>- Some distributions build Firefox with telemetry disabled, which might significantly skew the results.
Most Linux users do not use prebuilt binaries from Mozilla.
Most linux users use whatever tf is in the repos you tool
Which is we they don't have telemetry.
What are you smoking? Firefox has telemetry on first start in every distro.
>the majority are virtual machines doing automation tasks
source? the Firefox telemetry is only reported when you first launch Firefox ui. This doesn't affect automation tools. Also all popular Linux distros use the default telemetry settings for Firefox which includes this reporting.
kde neon does too since the big plasma 6 kerfuffle but picking between them is only a matter of clicking a drop down menu at the login screen.
>>From the very start people pointed out that the “security improvements” had no practical real life impact and were about as effective as putting a giant door with a big lock in the middle of one's room against burglars who had already broken in who could simply walk around it
Going from:
>Everyone can keylog you
To:
>Actually, only the root user can
Was actually a big improvement.
It doesn't lead to that.
Both on Xorg and Wayland, the situation is the same:
>Any software that as runs as your user or privileged can keylog you, other users can't.
How it works is that Wayland offers no specific protocol to keylog, id est, inspect arbitrary keypresses which any push-to-talk application needs or any hotkey daemon of course and then they said “Now you can't be keylogged any more!” Of course, that's not how it works, just because it's not in the protocol doesn't mean software that runs as your user can't simply ptrace the compositor, do an LD_PRELOAD inject, edit your PATH to replace it with a malicious compositor altogether or really anything.
It doesn't change anything from a practical perspective that it's not in the protocol.
> just because it's not in the protocol doesn't mean software that runs as your user can't simply ptrace the compositor, do an LD_PRELOAD inject,
Doesn't matter. Your user physically doesn't have access to the input events. You could try to replace some critical library like glibc but chances are a Linux Security module like AppArmor or SE Linux will block that.
Of course it matters, they can literally inject code into the compositor and make it do whatever they want, which does have access to the input events since it doesn't run as root.
You are aware that you can take over any piece of software on your machine that runs as your user and inspect it's memory and make it do whatever you want right? How do you think strace or DTrace work or any debugger.
moron
sysctl -w kernel.yama.ptrace_scope=3
Almost no system has ptrace_scope=3 enabled because it literally breaks debuggers and a lot of other software.
Most have at 0, some have it at 1. 1 still does nothing in practice because it's trivial to overwrite the PATH or other configuration files to ensure the compositor is tarted by a shallow shim which does nothing more than start the compositor being ptraced by malware the next time you start it and all it's memory is open again.
Puttiing it at 2 or 3 breaks debuggers and much more, so have fun with gdb and strace no longer working if you make your system like that, and it still wouldn't solve anything to begin with because the compositor is open source, so the malware can literally just download a maliciously patched version of the compositor somewhere that keylogs and put it in the PATH ahead of the actual one or somehow edit the configuration so that the malicious one is started again.
People who actually believe in this Wayland security theatre are such idiots with no actual experience with actual systems. Do you actually think there are systems shipped with ptrace_scope=3? It breaks too much, and even if you'd do it, it still, as I outlined, wouldn't help you one bit for this.
>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.
No, it's actually a very common security police because an attacker only needs one hole.
Everything else is a security theatre.
There's a reason Grub by default allows people to edit the kernel command line and simply do the init=/bin/bash trick to gain full access. When you talk to the devs there about how that's “insecure” they'll just say
>Meh, if they can access the bootloader, they can 99% of the time access the hardware itself, they could just screw your case open then or boot it from a USB stick and do whatever they want, it's useless to try to stop it.
That's how actual security works rather than a security theatre. Plugging 99% of holes and leaving 1% open is æquivalent to leaving 100% open.
Especially when plugging 99% of holes, like in this case, inconveniences people and removes features they need. There's obviously no reason not to do it if no one be inconvenienced by it. But Wayland has been a disaster for everyone because of this security theatre.
Doesn't stop it. Again, if they have access to your user account they can simply alter the startup process so that the malware runs in the same user namespace as the compositor again and boom.
If the compositor itself on startup changes namespace or makes itself non-traceable, they can either edit it, or ptrace it before it does that and commandeer it not to.
You have absolutely no clue of how this works.
>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.
>Doesn't stop it. Again, if they have access to your user account they can simply alter the startup process so that the malware runs in the same user namespace as the compositor again and boom.
ya ok, you're just moronic. If you run shitware unconfined, then obviously you will have issues, but you underestimate what LSMs can do, how Linux userns's work and ultimately how wayland works.
Compositor's API surface can be completely separated from the application executing it.
You cannot do this in X, thus the "muh keylogger" shit.
>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
>and on top of that Firejail was able to sandbox X11 using Xpra or Xephyr bridges before Wayland even existed.
Ah yes I too want to run every single application through a xephyr bridge because that's totally a better experience than what wayland offers.
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.
I used to use xephyr to debug window managers and applications so yeah, I know how it can be used. I've been using Linux for 18 years at this point, I probably know a lot more about the entire ecosystem than you do.
>xephyr
does it even support hardware acceleration?
>Plugging 99% of holes and leaving 1% open is æquivalent to leaving 100% open.
Oh no it's moronic
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.
>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.
>All it needs to do is overwrite sudo
Root is required to do that. If malware already has root then you're fricked.
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/
>Literally all you need to do is add a login shell function called “sudo” that shadows the actual “sudo” and calls it then.
This requires root. You can't change that without editing /etc/shells
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.
See:
>Root is required to do that.
Imagine not knowing about PATH, lmao
Use the full path to sudo
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.
Conversely, if your system isn't compromised, Wayland offers no benefits over X11, hence why Wayland is security theater.
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.
It offer protection only against completely ignorant attackers who just happen to know how to snoop on keypresses with the X11 protocol but somehow don't know of all these other attacks.
Is there even evidence but a single attacker exists with that specific level of knowledge?
>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.
>There's no point weakening software security if you can make it stronger.
...until you start hindering the users ability to use the software to get the job done.
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).
+7 years for push-to-talk functionality. Gnome still doesn't have it. KDE barely just got it.
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.
Yeah I hate wayland but the push to talk argument is moronic, that's easily solved.
The real issue is that you're pretty much stuck with whatedver hotkey daemon your compositor gives you which might not suit your tastes or lack functionality.
The Enightnment hotkey functionality for instance doesn't support Key-chaining as far as I know and many standalone hotkey daemons do. The thing with standalone hotkey daemons is that they can focus on doing one thing and doing it well, they're hotkey daemons and nothing more, so they're generally very good as far as hotkey daemons go and allow for some of the wildest things.
>cant paste into videogames
> or remote desktop with the only remote desktop that supports audio
so far x is better in every way
Video games still largely use X11 (XWayland). There's a few native titles in Steam that run with Wayland but you probably don't want to do that because they're all using buggy implementations from old toolkits that haven't been updated in however long.
>Portals
hacks with dbus lol
They're not hacks. They define a well known API and the backend communicates directly with the compositor.
>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.
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.
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 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
Not if you set the immutable file bit.
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.
Not without root they can't.
$ 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
describing all of IQfy
>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).
Doesn't matter, the moment you unset it, with root, to edit it in some way, the malware has access as well and can alter it.
And when you set it again after editing it, you use sudo, and at that point it has your root password.
And again, this is only one of the thouuuuusands of ways that can be used to create a m.i.t.m. attack. The malware can liteerally inject a character stream into a terminal you're not looking at at that moment to give commands to bash and define custom functions and then issue the clear command so that when you come back from your coffee break you don't know that sudo has just been overwritten with a custom function and you use it, and there are 4849894 zillion more ways.
The point is that in this case user convenience and functionality is sacrificed for an extremely theoretical increase in security that in practice should matter 0 because any attacker that knows of that method you close will also know of all the others.
It'd be fine if there were no cost, but the costs are big.
And many wayland compositors have added protocols again for screencasting and getting all that info which malware can just as easily exploit now.
If OBS works on your compositor, then malware can simply claim to be OBS in order to snoop on you and you wouldn't know.
cloudflare injecting packages into apt that dont match release signatures is way better for a mitm attack tbh
>Doesn't matter, the moment you unset it, with root, to edit it in some way, the malware has access as well and can alter it.
So copy it to /root, edit it there and then copy it back and do a checksum before and after to verify it remains unmodified.
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.
>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.
you can also just use user namespaces too.
moron.
>Almost no system has ptrace_scope=3 enabled because it literally breaks debuggers and a lot of other software.
So you disable it to run your debugger temporarily.
We do not compromise security for the sake of debuggers and a few other applications. These usecases are the exception not the norm.
>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?
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.
If you don't have root on your machine you've got bigger problems.
No, it's still
>everyone can keylog you
But they do it through SAFE dbus interfaces and thanks to SAFE flatpak keylog permissions enabled by default.
If there'a a virus in your system actively running, keylogging is not the first thing you should be thinking of. I can think of hundreds of nore efficient attacks than a keylogger. This whole "security" shittalk is like installing a bank safe door on a broken down house with every other place open to intrude. At least people can't break your door and enter amirite?
I like the “door in the middle of the room” analogy more, which is what Wayland is.
It's like putting a door in the middle of one's living room to protect against burglars who already broke in.
Obviously they can simply walk around it and still steal everything, and no one has to deal with a door in the middle of one's living room which is fairly obnoxious.
Once malicious software runs with one's user privileges it's game over. It can read all one's data and yes, it can still easily keylog.
Yeah. I don't know what people are thinking. You can literally hijack the root password with an one liner. Keylogging is the last thing I worry about.
>I like the “door in the middle of the room” analogy more, which is what Wayland is.
>It's like putting a door in the middle of one's living room to protect against burglars who already broke in
I second this but as someone who studied security, it's more accurate to say it's like buying one of those big bike locks form Walmart. It looks secure till some kid picks the lock with a hair pin.
No, I disagree. In that analogy someone actually has to break the lock.
The issue with Wayland is that people don't even have to break the “security” in any way but can simply walk around it and ignore it. But the person who owns the house now has to live with the inconvenience of a giant door in the middle of his living room making his life obnoxious.
It's not even a matter of “breaking Wayland security” but simply ignoring it's entire existence and walking around it.
>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.
That’s the issue. Wayland security doesn’t make an insecure system any more secure, and a secure system doesn’t need Wayland security.
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.
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.
>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
Yes an that's why i said
>I second this.
Is it the door manufacturers responsibility to install your door? No. That's why it's not specific enough.
But that apology can be applied to may things not specific to Wayland's shit security.
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.
>le keylogger meme again.
Wayland is not even able to stop that and just makes using a computer pain in ass because of all it's moronic issues that don't exist on x11.
If "safe but unusable" system is such a fricking win for Failand shills then I have better, quicker and more sure way to do the same - just trash your PC. Pull out hard drives, whack them few times with hammer for good measure and throw everything away and you'll have exactly the same result as with Wayland - absolute safety at price of usability.
And this is what fricking Waylandgays can't understand, it's impossible for them to wrap their heads around idea that safety absolutism is not a way to replace functionality.
My desktop is smoother and more responsive on Wayland.
cause wayland lacks 75% of the functionality xorg has
>cause wayland lacks 75% of the functionality xorg has
>functionality: primitives, font descriptors, indirect rendering, clients that change modeset, moronic compositing
>clients that change modeset
Clients have no business doing that.
They still can though. There's theoretically nothing preventing an application from calling kscreen-doctor or wlrandr, or whatever GNOME does, etc.
>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
Most modern games actually do not modeset anymore. Instead they work by changing the Viewport which is exactly what Wayland also supports with the viewporter extension. Only really old games tend to frick about with modesetting and I'd rather run them in Gamescope than frick up my entire desktops resolution.
I've tried migrating to sway from i3wm so many times, but the mouse latency is so annoying. Xorg just can't be replaced.
i will never ever use sway because the maintainers are trannies
X11 when you resize a mpv window it lags on Wayland it doesnt. On Wayland it's frame perfect and smooth.
I use Wayland just for that.
i just use a tiling wm and it doesn't lag when I resize mpv there
seems like a skill issue
it's the same snake oil security as with flatcrap
>it's fully secure because of sandboxing!!!
>99% of apps won't work unless given access to your home directory, many apps require system wide FS access
but it's sandboxed! it must be secure!
Debating the devs is so weird, they keep maintaining that it's “more secure” and come with the weirdest arguments like one security overview concluded it was “more secure” and addressed the argument that it didn't stop keylogging with “Well, since this keylogger works outside of the scope of the Wayland protocol it's outside of the domain of this comparison.”
This is the problem with open source software, how extremely tribalist many of the developers are in defending their own tribe. All OpenBSD developers use Tmux, all GNU developers use Screen. I doubt that is because they simply happen to like it more.
>“Well, since this keylogger works outside of the scope of the Wayland protocol it's outside of the domain of this comparison.”
He's correct. Wayland can't do anything about the rest of the system but what it can do is make sure that its own affairs are in order which is more than what X11 does where you need an extension just to secure it because it's insecure by default.
Yes they can't, that's the issue and why their efforts are futile.
They fundamentally don't understand it seems how operating systems work and that the security boundary is single users, not because of design flaws, but because one can't do anything about that.
Saying that X11 is “insecure by default” is saying that “rm” is “insecure by default” because it can delete any file the user owns when ran as the user. It's a moronic complaint to single out X11 for. Yes, a user owns any resource owned by that user and can do whatever he wants with it. That's not “insecure”; that's a necessity for operating systems to function and exactly why Wayland does not function.
>NOOOOO, THESE PROGRAMS THAT RUN AS MY USER CAN SNOOP ON THE SURFACES OF OTHER WINDOWS I RUN AS. THIS IS SO MUCH MORE HORRIBLE THAN THAT THEY CAN LITERALLY DELETE AND READ EVERY FILE IN MY HOME DIR!
Asinine complaint.
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.
It's completely irrelevant. If a user is running a malicious program his machine is already compromised. The attacker can still use a keylogger, delete/steal the user's files, spread through the network, etcetera.
In the real world, outside of Wayland dev's sexual fantasies, all Wayland does is prevent normal users from doing normal things like screen recording, color picking, push-to-talk, drag and drop between programs, etc. But it doesn't stop malicious actors from attacking their machines.
The real issue for attackers has always been getting users to run malicious programs and it still is.
What's worse is that users need the features Wayland doesn't allow for sorely, so devs have created mediocre hacks and moronic protocols to make normal functions work on most usecases like dbus or elevating all X programs to root in order to be able to run GUI programs as root. These are actually less safe than the old X way of doing things.
And another thing, X is garbage, we all know that. After 156 fricking years the best thing Wayland devs and shills can do is point to X and claim it was worse. Of course it was, it's a shitty system created for timeshare systems before PCs were even a thing. Making a better system is the bare minimum, not an achievement.
Mir was better in every regard to Wayland.
>screen recording, color picking, push-to-talk, drag and drop between programs
you don't NEED to do any of those things
obs works fine
hyprpicker works fine
oh no you have to add a single bind to a ui or file somewhere and pass the event to a client like discord or obs
drag and drop works just fine
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.
When was the last time you looked at the Wayland ecosystem? I ask because it's now easier than its ever been for small desktops to support Wayland.
You have tons of frameworks to choose from and new ones keep coming out all the time.
https://www.phoronix.com/review/the-compositor-modules-como
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.
>work on any EWMH-compliant window manager on x11
NTA but the only people who use multiple window managers are rice hoppers, who generally rewrite a bunch of scripts and configuration anyways outside of like xrandr and setxkbmap calls anyways. Each window manager on X has its own configuration syntax, and you generally want to manage window positioning, layouts, decorations, so on, using the configuration (or API in the cases of ex. Awesome). I've used X for many years, I've written, in my time, many different scripts. I think you're overrating the difficulty of swapping dramatically. The one thing you do have is that there's really not an alternative to window managers derived from blackbox, the closest you're going to get is hyprland with plugins, and it's a very different paradigm. You'd really have to wait until something like pinnacle-comp reaches maturity if you want to have a chance at replicating that kind of environment, although for shell stuff you could easily recreate a lot of that using aylur's gtk shell.
>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.
>Or people who release software to the general public.
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. 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.
>why do you think only 3 X11 window managers were ported to Wayland
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.
>purely use it to set EWMH atoms and read them in my scripts and it's hotkey daemon.
It doesn't sound like you even have a complicated setup if all you were doing is setting hints. So I was right, you are just over-exaggerating.
>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.
>It doesn't sound like you even have a complicated setup if all you were doing is setting hints. So I was right, you are just over-exaggerating.
No. I have a very high number of scripts that use the EWMH standard which would all need to be ported.
This is ridiculous, simply because my scripts only use the EWMH standard as a backend because it's good enough to realize these things exactly because it's flexible doesn't mean that the code calling it to determine window position and how to re-arrange it is trivial.
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.
>You can write a mostly working x11 WM in a weekend or two.
No you can't. X is huge, there is a huge amount of the protocol/emwh you need to think about and provide support for. Developing a wayland compositor with wlroots or smithay in contrast is way simpler and is way lighter on the cognitive load for developers.
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.
I said "mostly working". I didn't say "bug-free".
>making a compositor with wlroots or smithay was simpler lmao
It literally is. wlroots and smithay are both much simpler to understand and reason about than the X windowing API, in comparison X's API is a fricking disaster built on incredibly dated design philosophies. I'd reckon you've never even developed or contributed to WMs on either platform.
>I said "mostly working"
Mostly working doesn't just mean "spawning windows and moving them around", getting a "mostly working" X WM that supports the majority of its protocol is not a trivial task.
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.
>there are some libraries to ease out some things on you, but this is fundamentally a much more complex task
No it isn't which is why literal kids are capable of making their own compositor, nocoder.
yeah okay concession accepted
>no it's way more complex except if you look at any kind of practical evidence in reality that doesn't hold any water at all
Okay nocoder.
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 like how you ignored everything in that post that showed how it doesn't matter because it can still do all those other things programs can't on a phone.
And if they couldn't then you;d indeed have a phone OS where programs can't do anything. Ever noticed that on a phone you can't install a custom notification server or use screen sharing and all those things?
Literal security theater
If Wayland didn't prevent keylogging then it will hold back any future efforts to sandbox applications.
>any future efforts
how many decades we need to wait for them?
how difficult if would be add permission system to X11 protocol where you could decide which applications are allowed to access what events?
but no, let's redo everything from scratch and break tons of things
Easy and could be backwards compatible. If the app is not allowed, just treat it as if there was no keyboard events.
If you need to run something possibly malicious, you could sandbox it manually right now. Run the program as a different user account and connect it to your current Wayland display with Waypipe.
but then why wayland? you can do it with X
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.
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.
You're not using the features everyone is missing.
>You're not using the features everyone is missing.
I guess so. I'm just using it normally. Browsing, gaming, remote school, screen recording. I think it works great for that, better than X did but I guess if there was some feature missing related to those things that I was missing out on then yeah that'd suck.
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.
I'm sorry but I've just never had that happen. Is there a way for me to replicate this or test this out? I want to know if it has been fixed, doesn't happen on my system or what's up.
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
I guess it's fixed now but tbqh I don't remember it happening before. I've had Firefox as Wayland for a while though
it can still happen, the size of wl_ring_buffer is only 4k
Is there a way I can test it out?
happens randomly if firefox is busy and you move a 1k Hz mouse quickly
I have some turbo cheap mouse so might be because of that I haven't had those issues
It doesn't happen with a 1ms mouse. It's more like a mouse that polls every 125 microseconds (8kHz).
No they are crashing when the dispatch rate of either side exceeds that of the other. It just happens a lot with 'gamer' mice because they are loud (yet still about 1/30th of a PS5 controller). The more event sources and types introduced, the more likely this happens. The heavier load you push on your computer, the more likely this happens. That's what's sick. No other component in your entire system is this fragile or poorly designed. If the Linux kernel would do this on >any single syscall< it'd be laughed out the fricking door. That's how bad Wayland is as an IPC system.
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
(in other words if the buffer is full remove all mouse events except the last one that was in the buffer)
And what decides that?
They use a socket - you don't have visibility into the buffer state until it's too late for you to do anything about it. This is why clever systems use a shared memory ring buffer or sampling MMIO.
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
It has nothing to do with the programming language
Not really. Things like Firejail sandbox with X11 fine, so does subuser.
The weird thing is that people expect the display daemon to somehow be treated differently from all the other daemons. How it works with any other daemon is exactly what Firejail does with X11: You create a m.i.t.m. daemon which decides what information it lets through.
One can argue that the display server needs this built in somehow, but every other daemon that one runs also has to be treated that way in the end.
Actually the XSECURITY extension exists which allows one to create namespaces inside of an X11 server and an application inside of such a namespace can only see the other things inside of the same namespace.
This has existed before Wayland and SSH actually uses it but it has some bugs with it because a lot of software does not expect to be ran in it. Firefox refuses to start in it as far as I know.
For some reason all those “muh security” people didn't jump on that but decided this was the way.
Of course, Sway and KDE all added all sorts of unofficial incompatible protocol extensions to expose all this information again because people needed it so it's all super lel.
But it's actually hilarious to talk with many of those developers about “security”. They're either supremely ignorant or deliberately vague and avoid the issue. The Grsec team also showed how useless “capabilities” were in practice as in 80% of them could be used to construct root anyway on most systems and in many other places only two are needed to et full root back.
Gee, who would have thought that CAP_SYS_PTRACE would basically be the same thing as being given all-capabilities because you can ptrace any setuid binary on the system and make it do anything.
All this shit is such a theatre.
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.
>Of course, Sway and KDE all added all sorts of unofficial incompatible protocol extensions to expose all this information again because people needed it so it's all super lel.
Greenspun's tenth rule for display servers:
Any sufficiently complicated Wayland compositor contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Xorg.
Incidentally, Common Lisp is as big of a piece of shit as Xorg is, but both are better and more feature-complete than what they have been replaced by.
Wayland is the ultimate humiliation ritual
>daily wayland seethe thread
Xchuds are really losing it
Seems fine on my machine
what a shit delusions homosexual thread, this is Qanon type shit.
Then I'm sure you can point out any inaccuracies in what was said.
>almost no window manager has been ported
Pretty sure there's a few dozen WMs that work with Wayland at this point.
wayland and all of it's implementations are a prime example of everything wrong with modern software development
>premature optimization galore
>developers tie their self worth to it
>overly complex mess of barely-defined modules
>post-hoc standard that nobody fully implements anyway
wayland is the sysvinit of display protcols
ironic, since red hat (the main backer of wayland) already knew that sysvinit was a piece of shit and replaced it with a single monolithic implementation (systemd)
X11 is also composed of many independent protocol extensions that implementers are free to implement or not.
The difference is that there is only one implementation of the X server really in use outside of Xephyr-like things that work to create bridges so effort is not reduplicated.
Wayland's idea of:
>Everyone should built his own compositor
Is asinine, I don't get why they thought that was a good idea.
Well, probably because everything that has been coming out ot Freedesktop after 2006 was essentially built on the assumption of
>Hackers and small time programmers working alone, creating something interesting don't exist, everyone is part of at least a 20-man paid team funded by a company like Red-Hat.
What allowed the Unix œcosystem to thrive was the many one-man contributions because it by design frowns upon redoing work. I've known people who spun their own window manager written in perl. One can do that.
>I've known people who spun their own window manager written in perl. One can do that.
I think this is how Wayland ended up so fricked, the devs saw how many WM projects exist and just assumed everyone would want to do that but by making their own compositor instead. What they failed to realize was that there are so many desktops because developing one is fairly easy. Now it's a pain in the ass because you have to do so much of the work yourself unless you use wlroots, and if you want to make an app that doesn't gel with Wayland's security theater design, you have to depend on compositor-specific workarounds. All Wayland has done is create a ton of extra busywork for everyone.
A super common thing with new standards and people severely overestimating how easily they are adopted.
Also, Python3. The minute changes weren't worth breaking backwards compatibility over and the devs really thought everyone would “just update”
>Woow bro, just fix millions of lines of python2 code and make them python3 that you know work now which could introduce regressions and cost your company millions in the worst case
>Why is... no one adopting python3? We thought they would take only 5 years... what's going on?
Also, GPLv3, ahahaha. GNU actually thought everyone would immediately switch to v3 and they were super surprised that many people didn't want to, or couldn't because they had to track down every single copyright-holder to ask for permission for a relicensing.
These people so often lack perspective.
>Also, GPLv3, ahahaha. GNU actually thought everyone would immediately switch to v3 and they were super surprised that many people didn't want to, or couldn't because they had to track down every single copyright-holder to ask for permission for a relicensing.
A lot of projects stuck with GPLv2 because they just didn't care about the problems that v3 was meant to address. I'd even argue that the evolution of the GPL has been perfectly fine, even if it wasn't adopted as quickly as GNU had hoped. Meanwhile, Wayland's been a roadbump at best and an active detriment to GNU/Linux at worst.
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.
>Almost no window manager has been ported to it
You might notice that Enlightenment, GNOME, and KDE are the only ones that were ported. Others are new projects altogether.
And you can bet most of them are beyond useless because they don't support all the multitudes of incompatible extensions needed to do anythig useful.
That's because WMs are literally just wrappers around X. It would take more work to port it vs just making a new wrapper for wlroots.
My point is that they are entirely new projects the original developers had no interest or part in.
They are new window managers “inspired by” something else and they probably don't provide the full featureset of the original which they would have had if ported.
>swaywm
troony maintainers
>hyprland
troony maintainers
>hyprland
>troony maintainer
no he's just gay
his mods changed someone's discord pronouns to who/cares
>his mods changed someone's discord pronouns to who/cares
They still support trannies >though.
Not necessarily. GNOME and KDE had nice abstractions around windowing functions and XFCE does too (they're porting Xfwm to Wayland right now).
If you can't port your window manager it's because your code is shit and doesn't have an abstraction and is hardcoded with X11 assumptions everywhere.
>XFCE are porting xfwm to Wayland right now
If you count 1 person working on it as porting it then yes they are. They are also questioning the point of porting it to wayland given the problems they are encountering and the amount of refactoring of their codebase they will need to do. I doubt a Wayland session being usable let alone default is in XFCE's near term future.
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
sway is basically just i3
wayland still has its own issues that make me use i3 instead though
Wayland isn't in active development, why switch to it now and break everyone's desktops?
Like you're not just going to get random morons to work on it when it's still using X, xorgim and many x features just to work
The only thing you're going to do is fill up an old inactive repo's tickets with garbage until your distro dies, because you crash.
Using linux in the current day is like moving into a neighborhood full of trannies and Black folk and then being shocked that you keep accidentally stepping on used needles.
I gave up, moved everything to i3 from plasma 5.
I'm literally only on linux for the hardware support, encryption and wine. I'd be on openbsd otherwise.
Insane that we've let them destroy an entire operating system but thats what happened.
But I like both Black folk and trannies. I fap on their porn every night, watching them frick each other.
>I gave up, moved everything to i3 from plasma 5.
why? i3 literally just works
I use wayland and have no problems
Open a few application and move your mouse really fast.
X11 works fine. The real problem is KDE trannies blaming their problems on X
>the “security improvements” had no practical real life impact
oboy did they have impact, so much in fact that wayland will remain unusable for the next 5 years still. wayland will be half the age X is now before it will be useable, we can start thinking about a replacement again at this rate
The only reason I use Wayland is because hdmi 2.1 works on it on amd gpus.
Why are you lying?
https://arstechnica.com/gadgets/2024/02/hdmi-forum-to-amd-no-you-cant-make-an-open-source-hdmi-2-1-driver/
I'm not lying, I'm literally using it right now and it works just fine.
Can't wait when you seething jeets are yet again wrong and you're forced to eat ze bugs like everyone else.
Literally no one gives a frick about X11 anymore, that's why development on it ended decades ago. Go jack off to fricking Simpsons porn from 2000 if you care about antique relics that much.
Wayland? More like Strayingland, am I right, fellas? kek
And yet more people use it because it's a new technology unlike X which first came out in 1985, doesn't have proper optimizations for new APIs and window managers, and most major distros have already abandoned or are starting to abandon X. The only advantage X has is Xfce and that's so old fashioned that most people have forgotten it exists, and any problems it might have with Nvidia will be ironed out in the future.
Only 7% of linux desktop users use wayland.
>doesn't have proper optimizations for new APIs
that doesn't make sense, there are no new apis to optimize for. X11 runs just as fast as wayland. Both use the exact same linux drm and mesa gbm functions and map that to opengl the same way. Xorg server and wlroots even use the same pixmap library.
Source on the 7% number?
Not that I doubt it but statistics run far apart. With firefox users it's 10%, on some gaming forum it was 23%.
None of the numbers I saw come higher than 25% after 16 years though. It's safe to say adoptiion has been slow.
with Firefox it's 7%, you should read the article instead of just the title.
What article?
>map that to opengl the same way
wlroots has a vulkran renderer, they also use gles2
You literally don't know how this shit works.
Where the frick is my gamma management?
Compositor specific extension that may or may not work depending on the compositor.
Every X argument falls apart as soon as you start pointing to real-world examples of software. Whenever you argue with someone defending X, you can be sure of two things:
1. they are not a developer, and have never developed anything more complex than a basic shell script
2. they know even less about X than they do about Wayland
>as you start pointing to real-world examples of software
Yes like applications crashing because you move the mouse too much. Oh wait, that only happens on wayland my bad lol
Execution pausing and debuggers are an issue that definitely needs to be resolved, but the rest of the arguments, like it being hard to develop or support, or that compositors are "too complex to develop", or a bunch of other asinine bullshit, aren't real. Any practical evidence points to the contrary.
hyprland is written in C++ and the dev is not a fan of rust
It's just an example of one of many of wayland's fundamental design flaws. They will patch it up eventually with some hack like they do with other wayland flaws. The proper fix would have been to do what win32 does. I don't know why wayland fanboys on the internet can't admit by now that the whole protocol and ecosystem is a giant pile of shit. I would get having stockholm syndrome if you have the misfortune of being a wayland compositor developer, but for everyone else looking at it objectively, it's garbage.
>The proper fix would have been to do what win32 does
which is what?
Win32 will reorder, drop, or coalesce messages as necessary.
In Wayland, doing so will break the entire protocol.
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.
>dumb hack but it basically works
Until it doesn't (OOM is not better than killing applications).
The Wayland devs tried to avoid the OOM by bounding the buffer size but they arguably set it too small.
>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?
I would much rather OOM than have my application killed because I went over 4k or whatever the frick the limit is.
Not yet but presumably they will merge the new api that gives the compositor control over that soon-ish.
>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.
It could still theoretically happen by spamming input events at a rate quicker than it can handle (which is the situation in Wayland right now).
This is only an issue on slow systems but it's still an issue because you can't exactly say to people:
>You're system's too slow, go out and buy 7950Xs and 4090s
See
>X.org suppresses mouse and keyboard events when a window is non-responsive
How does it suppress them? Surely it still has to process the events?
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.
Yes, but with the caveat mentioned above.
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.
>hyprland is written in C++ and the dev is not a fan of rust
this as well. there is basically one Rust compositor I know of and it isn't even released yet: Cosmic DE's
there's niri which is actively developed as opposed to abandonware but I don't know how serious of a project it is
researching into who's behind the push to wayland and hyprland (4 filepickers, without thumbnails or fonts) im finding a lot of baseddevs and rust
1 of the 25 compositors listed on the arch wiki is written in rust. are the rust trannies in the room with us, anon?
https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4359#note_2259586
holy shit you can't even use the clipboard to paste into games
Ah the daily wayland hate thread. Go write a better alternative then anon!
Anyway, I've been using sway for more than 3 years now and the only thing you have to do is set it up correctly once and set a few special ENVs and than never think about wayland again.
>resize window
>it loses track of what file was being selected and scrolls up 100+ pages
>chrome/chromium does the same except fonts bug out
>open nomachine to stream audio from remote desktop
>wayland shits the bed
so this is the power of wayland
>all of this talk about malware and theory but of course nobody is going to take issue with how many apt packages dont match release signatures
Wait what. ubuntu can't actually be that shit right
You should definitely take issue with that. Which packages don't have a valid signature? That means the Apt mirror is doing something it shouldn't or the file is corrupt.
so what is it going to be, did x11 hurt some gaytrannies feelings or is wayland actually better?
they're both shit
It's better if you want a modern desktop.
If you want to do work on your 1990s super computer / data cluster then X11 is still better.
wayland using xorg-im and being compatible with x protocols where they say they aren't is very strange
Don't be so hard on wayland, it's only been around for 16 years. I'm sure they'll fix all those problems eventually, just give them more time.
They will fix them because there's no going back and there's no going forward (what are you going to do? Make a new display server? Nobody wants that).
I could see there being a Wayland 2 at some point. They already have a wishlist / buglist for this in their tracker and this would be the perfect way to fix things without completely breaking compatibility.
>I could see there being a Wayland 2 at some point
As long as freedesktop or redhat are involved, there's literally no point, it'll just be another hacky, bug-riddled mess.
Better file issues then. If they do do that (and I can definitely see it because it wouldn't be that difficult to modify the toolkits and this could potentially be done in a backwards compatible way too) then they need people to point out all of the glaring issues with their design.
>usecase unclear
>closed wontfix
You have to completely break wayland to fix it. Anyways X11 won't go away for at least another 20 years despite all the kicking and screaming of all from waylanders. Maybe pray that Arcan wins in the long run or something.
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.
Wayland has sticking power because it has a bunch of corporate funding behind it. It has nothing directly to do with DEs.
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.
If you think GNOME and KDE didn't play a part then you're lying to yourself.
Nobody cared about Weston. Wayland only started gaining real traction after GNOME adopted it and yes, some of that may have in part been influenced by Red Hat but GNOME is still an independent community project.
GNOME saved Wayland. Had they not picked it up in 2013 when it was completely dead Mir would've been the argument now.
Quite possibly. It was actually Intel that killed Mir though by refusing to add support in their driver for XMir.
>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.
GNOME and GTK is completely owned by Red-Hat in practice at this point and everyone knows it.
Freedesktop in general is simply Red Hat's corporate puppet.
>I'm tired of all this "ugh security theater" bullshit. All the functionality that was considered insecure and missed was implemented in portals in secure way: screenshots, screencasts, remote desktops, global shortcuts.
Why does everyone talk about portals? They're purely a thing from within a sandbox and there's nothing secure about it.
Outside of a sandbox the same issues still apply
Portals don't allow anyone to easily write a good custom screenshot tool. It's still simply asking the compositor “make a screenshot for me” and you hope that it offers the functionality you want for that. My screenshot tool is perfectly capable of screenshotting a single window ignoring any window that's above or under it and removing the semi-traansparent blurred background. There's no standardized portal for that as far as I know, and if there was, most compositors wouldn't implement it.
It's “policy of mechanism” rather than X11's traditional unisex design of “mechanism over policy”.
No, it's i3 but without all the nice things about X11 such as EWMH scripting, xdotools, easily writing your own bar and notification daemons and all that stuff.
>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.
Maybe the way, but they don't solve the security issues, all the same security concerns as with X11 apply to them, and they're less standardized because everything implements a different subset.
X11 standardized this a long time ago and again, does this in mechanism over policy way, there is no “sceenshot a.p.i.”, or “screencast a.p.i.” because it doesn't need it and allows clients to compose it themselves how they see fit.
It's adding a lot of the functionality again that as missing, with all the “security concerns” that existed for X11, but now it's
>less functional
>less standardized
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.
It isn't standardized, that's the issue. Some compositors support it; some don't, and there are often multiple competing ones.
This was all actually standardized on X11.
And again, you ignore the policy over mechanism issue. You can only do that one specific thing that the compositor decided to implement with this solution.
They don't solve the security issue because again, any malware that has access to your username can now use the screenshot portal to spy on you.
>X11 didn't standardized anything in that matter. X11 got shared memory extension and that how you do screenshots and screencasts. Security? Frick it. Sandboxing? Frick it, use dedicated X server instance if you want.
Why do people keep repeating that X11 doesn't have sandboxing or never had.
There are two ways to do it:
>XSECURITY allows the X server to be compartimentalized into different namespaces, clients can only see other clients in the same namespace and simply don't see the other clients.
>Xpra/Xephyr bridges are used to achieve a similar thing, clients again think they're home alone in their own private server while the user gets to see a composed image of all the clients.
The difference is that the standardized EWMH set is enough for basic functionality and far more, whereas Wayland needs noncompatible, nonstandardized extensions to do basic things.
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.
>whereas Wayland needs noncompatible, nonstandardized extensions to do basic things.
Literally what the hell is the difference if everyone started implementing non-compatible, non-standardized ways to do things because EMWH spec and the X API sucked so bad?
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!
>The protocol is perfect. It has no flaws!
Nobody says this (aside from the voices in your head.)
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.
> fix the mess that is X11
X11 is not a mess. The design is very sound.
If you want to replace X11 you'll end up creating something similar to X11.
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.
>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.
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.
>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.
What if you want to paste from a context menu or some other way? The whole idea of securing the clipboard is a fools errand, better to not write sensitive information to it in the first place. I hate the fact that few apps support Secret Service which is why we're stuck writing passwords, etc, to the clipboard in the first place.
> 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..
>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.
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?
Portals are actually standardised too. There is a spec, you can go read it if you want.
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.
>Are there even portals that allow the reposition and manipulation of window positions?
There would never be such portal.
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.
>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?
Genuine question, when has this ever been relevant to anyone but the most autistic ricers who hop wms every time their mood swings. I think most if not all compositors allow you to manipulate windows using scripts. These are not complicated operations either.
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.
Then maybe you can provide an answer to:
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.
>People write software and release it anon.
People create GUI software using toolkits like gkt and qt, either 99% or 100% of that shit is completely abstracted from the developer side. I can't think of a single application that ostensibly went around gtk and qt to use x11.
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.
Well then we'll circle back.
Who does this matter to? Most if not all compositors already gives you the ability to do this. The only people who need shit like this are ricing autists who hop wms every other day.
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.
>or people who write xdotool or wmctrl
Who cares, no one uses this shit except autist ricers who hop to different wms every week anyways.
>Many people actually use wmutils you know.
Really? Where's your statistic on this? Show me the people using wmutils, show me the people using xdotool. Show me your scripts that would be completely non-trivial to port to any compositor, because X somehow makes your magical window positioning script feasible.
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.
I think I read something like that that it was added now but have a source?
>Okay, so it can't be done
Nobody fricking did it on X in the first place. Every WM had their own shitty program or ipc you used to do it anyways, or if they were sensible a proper API and a programming language.
The only thing you've proved is that you're an autistic wm hopper.
What's the point of pretending to be some epic linux greybeard when people point out shortcomings in wayland? You just look silly.
>No one ever used xdotool or wmctrl ever.
https://stackoverflow.com/questions/tagged/xdotool
https://unix.stackexchange.com/questions/tagged/xdotool
Then why are they asking?
Standard Freedesktop response
>NOOO, NO ONE IN MY OWN moronic USER EXPERIENCE BUBBLE USES THIS SO YOU DON'T NEED IT.
Anon, most Window managers don't even have a scripting interface exactly because it can be done like this.
Only Kwin and GNOME provide one I think. Sway doesn't have one either so you're just stuck with it there. People mostly use tools like that or call EWMH directly to do this.
Sway has IPC just like i3
And does it have some kind of protocol to get window positioning and resize windows and all that?
Does i3 even have that/ I don't think i3 ever had that.
And if they do, it's again, non-standardized.
>Woow, writing a different backend for every compositor is... only something autistic wm hoppers hate.
Yes, both of them do. Sway's IPC is very good.
Also i3 is the standard here. Sway is almost a complete drop-in for i3. Its IPC is the same.
It actually works in sway. Kwin I assume has something but I have no idea how it works there. GNOME dunno.
>Only Kwin and GNOME provide one I think.
Dude shut the frick up
Awesome has an api
i3 has i3-ipc
bspwm has bspc
dwm you write what you want in C and do it the suckless way
fvwm has an api
windowmaker has an api
kwin has a scripting interface
I haven't used mutter in years but I'm 99% sure you can do it for that as well
Everything derivative of blackbox has their own toolset
Every single one of the most popular window managers available for X has a goddamn way for you to position windows because, hey, guess what, it's probably a good idea for the window manager to position windows, especially in the context of literally anything that tiles.
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.
Sometimes they have a scripting environment, other times they just have a basic command API and then you don't even need an interpreter, you can use something like execline if you want to be autistic about it
> 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
It isn't relevant, someone just told me I should use that and I said that most don't even have that.
The issue is that it's not standardized. Certainly, for some things specific to a window manager one has to use the window manaer's specific interfaces and that's unavoidable, but for moving windows? No, that can all be done in a standardized way that works everywhere.
It turns out I don't want to rewrite all of this if I should ever go to a different window manager. Having to rewrite it all alone is a reasong or me to never hop to Wayland until an xdotool wrapper comes out that works there.
>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.
literally nobody expects tiled window managers to obey xdotool unless the window is floating.
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.
>Wooow, just use some wm-specific protocol when EWMH completely suffices for asking about the position of every window and changing it, which is all one needs
Anon, only morons would use a specific interface when a standardized one suffices. Who does this? You're an idiotic programmer then.
>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. Did wmctrl give you PTSD or something?
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.
Can you name (1)?
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.
>literally any tiling wm is not going to listen to wmctl
It works in i3
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?
wmctrl isn't for moving windows out of tabbed layouts. It does exactly what it's intended for
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.
You don't seem to get what xdotool is
It's not a tool that moves windows
It's a tool that talks to window managers in a standardized way.
It does the same thing as the i3-ipc but in a standardized way.
Why would you ever want to use a vendor-specific interface when a standardized i.p.c. exists that does the same?
Didn't do shit senpai
Yes because tiling window managers are free to ignore it.
That's the point, it doesn't move it itself, it asks the window manager who is free to ignore it; it talks to them.
>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?
Anon, this is like saying a socket doesn't talk to what's on the other end because it goes through the kernel.
It's an i.p.c. defined on top of the X11 protocol, yes it goes through the X11 protocol but what's on the other end is the window manager.
Yeah, I wouldn't be using these scripts if I ever moved to a tiling window manager.
The reason I have them is because I managed to over the years design my own unique semi-tiling workflow that for my personal needs is the best of both worlds of tiling and floating.
>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.
This is just some pathetic semantic argument. The server passes the message from one program (xdotool) to another (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.
>xdotool
Wayland's xdotool has a 1 second latency. Your argument is invalid and I'm not reading it.
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...
>The shell too just uses X's API mate...
Whoa, so you're saying that your shell tool uses the X API and so does your window manager? Wow, seems like you could have just used your window manager instead of installing an extra dependency for nothing.
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.
>You can't say the same for the wayland versions.
Practically there is no difference for the end user. Using a wm, who's sole purpose is to manage and position windows, is generally a much better option than using something generic. So trying to argue that is some kind of non-starter is ridiculous. All you're b***hing about at this point is that you have to rewrite them, and honestly, that shouldn't take any time at all for shell scripts if you have any kind of competency.
"Something generic" works totally fine in most cases.
>inb4 more incoherent raging about tiling window managers
>in most cases.
Except like any case where there's a tiling wm. I mean shit even kwin has special functionality for its own scripting and positioning that xdotool won't accomodate for.
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.
>You can do this in one line in your i3 config. It's fine.
I can also just move windows with i3-ipc without having to float them? I can use i3-ipc to float and move windows too! Wow. Sorry what did I need xdotool for again?
To make sure the exact same script also works on another window manager.
>But but but.. sotware shouldn't be portable.
>the exact same script also works on another window manager.
Oh, right, so, it's only useful if you're hopping around wms like some autist, got it.
Again, I have no idea why using xdotool makes you so upset but if you want to use i3 ipc instead, go ahead.
Upset? No. I just don't see a reason for it to exist. You install a window manager. A window manager does everything xdotool does. It's just bloat.
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.
which one of these do you think a window manager is incapable of doing?
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.
moron
Is it the moving windows part? It's probably the moving windows part right? After all that's what anon wrote his script for.
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.
I don't see a point in using a tool which accomplishes the existing functionality of a tool you have already installed. Generally, standardized interfaces suck ass. They're inflexible, they can't really handle any kind of specialized way of doing things, if context changes a little bit they become almost entirely useless. I am also, surprise surprise, not a fan of using bloated frameworks with years of bad design behind them are a pain to work with as a developer and enforce a strict way of doing things. Even if that way (like excessive window hinting) is not only slow to parse but also could be handled inside a much faster state if it was just a part of the window manager. It makes it very hard as a developer to achieve what you want, it makes it overly complicated to create new functionality.f I'm also not a fan of writing overly complex shell scripts because that's not what that tool was created for.
>has implemented all of those commands in a scripting interface or something similar
Almost all of them can move windows bud, hate to break it to you. Most of them can also handle every command on that list. Not that you would know because you've already self-admitted you haven't used the vast majority of the ecosystem.
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.
No, standards are okay, what is not okay is having a fricking awfully designed API like XCB that is hard to extend and poorly documented.
> then people said Portals did that
Okay, those people aren't me.
>now must be done in platform-specific ways because
The vast majority of people were doing it in window-manager specific ways anyways. Many window managers broke compliance because there are parts of the protocol, like the system tray specification, that are downright idiotic.
>But not all of them
So it's only useful in the context of a window manager that doesn't support those commands.
>a highly questionable claim at best
No, it's not really questionable but I will say that it does depend on the kind of interface. Obviously you want compilers to have standards. The biggest problem that X has as a kind of interface is that pushing it as the "one true interface" means that everything has to be done the "X way". I've already experienced years of horror in development being stuck behind shitty, poorly maintained, poorly documented interfaces. The other problem is how opinionated something is about how X or Y should be implemented in order to support a specification. Wayland is much less opinionated about implementation than X is, because wayland doesn't attempt to provide a common implementation like X.
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.
>The vast majority of people were doing it in window-manager specific ways anyways. Many window managers broke compliance because there are parts of the protocol, like the system tray specification, that are downright idiotic.
Anon, no one is going to talk to a window manager in a specific nonportal way to move a window around okay.
Anyone who does that is an idiot.
>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.
No, no one is writing anything to move windows around on tiling managers at all because it goes against what they do.
And I sincerely doubt anyone is going to write a kwin script for the simple task of:
>move the currently activated window 5 pixels to the left
>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?
If you are moving windows around often in a tiling layout, you're simply doing it wrong. One of the whole points of such a configuration is to stop doing that.
>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.
I stand by what I said. If you are constantly moving windows around in a tiling window manager, you're simply doing it wrong. Use a floating one.
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.
>Most of them can also handle every command on that list.
But not all of them. So my point stands by your own admission.
>Generally, standardized interfaces suck ass.
a highly questionable claim at best. I mean obviously it would be pretty bad if C compilers didn't follow any standards. It seems more like you have a personal problem.
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.
con't from
That lack of providing a common implementation is something you b***h about but it's also something that's wonderful for developers and it's also healthy for the kind of ecosystem that arises from it. It means we aren't stuck with a common implementation if it's doing something really fricking stupid. If your issue is that you can't hop between 30 different stacking-only WMs with no kind of specialized layout functionality at all and have xdotool there to manage windows on all of them, I think that issue is moronic. That's a wontfix.
>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?
>I mean just imagine if graphics APIs had no standards.
The standards come from the protocol, it should accomplish what is defined by the protocol to a standard. How it does that is what is not opinionated. It is very different from a graphics API like vulkan.
What is even this schizo argument? So standards are good now if there's a protocol? Help me try to understand your mind.
The mind is obviously
>I come with whatever contrived ridiculous argument to defend Wayland now that I worked myself in a corner.
Wayland doesn't standardize this so
>Standards bad
If Wayland did, anon wouldn't be arguing such an inane thing.
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.
>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.
So now we looped back around to "standards are bad".
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.
Nobody is forcing you into a "common implementation". This doesn't even make sense. You get the hint and do your thing.
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.
>is the best of both worlds of tiling and floating.
Yeah and I did the same thing with awesome which is a way better method because you're not shitting out shell script all over the place which is like the worst possible way you could have done that.
You don't even know what my setup looks like and how it works, you idiot.
No, it passes it through the server to the window manager that reads the hints and then decides what to do.
>You don't even know what my setup looks like and how it works, you idiot.
Doesn't matter, I can tell right from the outset that whatever you're doing would have been way better managed in awesome with a good API and a proper language.
Hey, you wanna know what's actually universal on X? The actual API. Not some fricking shell tool.
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.
>DUDE YOUR TILING WINDOW MANAGER DOESN'T MOVE WINDOWS!!!
Are you on drugs? Do you not understand these are orthogonal concepts? The whole point of having a tiling window manager is to have windows locked in place. No fricking shit the windows aren't going to move. Don't tile your windows if you want them to move...
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/
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.
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.
>some operations can't be standardized because they're window manager-specific by nature
So why are you using two different methods to accomplish one task? What is the point of pulling in an extra tool to do something that the window manager you installed already handles?
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.
>intelligent algorithms that automate this
Actually that is exactly what a dynamic tiling window manager is supposed to do. i3 has a complex layout system that will work for anything you are doing.
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.
>The vast majority of people will use bspc, i3-ipc, awesome's api and so on to position windows.
Assuming I'm putting together some shell scripts and shit, I would absolutely use wmctrl or whatever instead.
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.
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.
>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.
>forced troonyware doesn't support [thing]?
>YOU DON'T NEED [thing]!!!
Like clockwork.
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.
I'm not them but these are the Debian statistics:
>Rank 1645
https://qa.debian.org/popcon.php?package=gnome-shell
>Rank 3735 (plasma-workspace-wayland)
https://qa.debian.org/popcon.php?package=plasma-workspace
>Rank 5387
https://qa.debian.org/popcon.php?package=xdotool
>Rank 7969
https://qa.debian.org/popcon.php?package=wmctrl
>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
>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.
but without fixing X security this NEVER will get fixed.
>Wayland is unnecessary and doesn't fix anything.
it fixes the security problem (part of it, rest of it is outside of scope of X-like, it's scope of MAC/RBAC)
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.
It can't be sandboxed. Please stop repeating this lie.
>Just run this nested X server that doesn't support GPU rendering
lol
lmao
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.
https://firejail.wordpress.com/documentation-2/x11-guide/
Xephyr can do hardware accelerated sandboxing btw
>https://firejail.wordpress.com/documentation-2/x11-guide/
wasn't firejail recommending to use gayland?
>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)
>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.
>but they don't solve the security issues
Why?
>all the same security concerns as with X11 apply to them
Elaborate
>X11 standardized this a long time ago and again
X11 didn't standardized anything in that matter. X11 got shared memory extension and that how you do screenshots and screencasts. Security? Frick it. Sandboxing? Frick it, use dedicated X server instance if you want.
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.
>so everyone is still using x for wine/proton/games, it's just broken and you can't copypaste into it, and your mouse resets to the center of the window on click
very cool
wayland security theater is only liked by the kind of tinfoil hat moron who thinks qubes OS isn't secure enough
Qubes actually goes to great lengths to secure X11. Wayland would probably fit their design model better.
I'm tired of all this "ugh security theater" bullshit. All the functionality that was considered insecure and missed was implemented in portals in secure way: screenshots, screencasts, remote desktops, global shortcuts.
Wayland protocols developed by actual compositor developers: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/MEMBERS.md and those people understand more about desktop rendering that average client developer who don't care about efficiency and only want to get the shit on display with minimum efforts.
If software developers refuse to support Wayland I would rather not use that software. Fortunately it's rather an exception because most software developers are smarter than average IQfytard.
>portals
hacks around wayland deficiencies
Calling portals hacks is like calling X extensions hacks.
portals don't even use wayland as their main from of IPC lol. It's a giant hack and clusterfrick.
Even better, clients that try to do something through Portal and Wayland breaks Waypipe (that also can't handle Xwayland) so gg network "transparency".
>portals don't even use wayland as their main from of IPC lol.
Because portals aren't Wayland centric and designed to work on any display paradigm? Are you moronic or what?
>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.
>came up with desktop portals to basically hack around it
That's definitely not why portals were developed.
>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.
EWMH is well defined and communicates purely in X11. Not comparable.
I've always had vsync problems with X11 so I use wayland. But at work, I configure the machines to run Ubuntu 22.04 LTS on X11 if it's gonna be deployed remotely, cause anydesk doesn't work with wayland. Stupid shit, it should work by now.
>bro just run an extra dbus daemon that requires every compositor to run their own backend daemon implementation and pray that it's good enough to let you do the things every other sane display server already lets you do
are you guys serious lmao. portal worship is so bizarre.
They're forcing Wayland on us like they've forced systemd on us.
We just have to get used to how much it sucks.
systemd adoption was actually very fast because systemd's problems were purely that it bundled a lot of functionality together and was super insecure [lol at Wayland “security” advocates also pushing systemd].
But at least it was no actual loss in functionality, far from it, it added a lot of functionality over existing solutions.
Wayland is a thousand times worse, which is why adoption has been terrible in comparaison.
That said, I don't even run a service manager. I have like 4 services running
>NOOO, YOU MUST USE DEPENDENCIES AND A SERVICE MANAGER TO RESTART YOUR SERVICE
>I just do “sudo pkill sshd && sudo sshd -D” to restart it and the world keeps on churning.
>>I just do “sudo pkill sshd && sudo sshd -D” to restart it and the world keeps on churning.
That's how you frick up your CGroup hierarchy (you're probably not even using that though, are you?).
If you used a service manager then that would happen automatically as soon as you kill it, it would respawn.
My scheduler doesn't support cgroups. It provides them as shim but they don't do anything.
Is there a serious use case on a desktop to use cgroups to limit resources to sshd?
>If you used a service manager then that would happen automatically as soon as you kill it, it would respawn.
If you used a supervising one set up to do that, I don't think systemd even does that by default because it's a bad idea.
“self-healing systems” in how Tanenbaum envisioned them are a terrible idea because it hides bugs from the user. sshd should not crash, if it do crash, that means there's probably an issue somewhere that needs to be fixed.
I'd be fine with respawning but being given some immediate and obvious warning that this happened though.
Service managers are of course necessary for highly complex systems with all sorts of dependencies, but I'm on a desktop. What I have running are:
>sshd
>distcc
>dhcpcd
>cron
Do I really need a service manager for that?
Wayland doesn't work on Nvidia. It's a piece of shit.
You mean Nvidia doesn't work. The Wayland developers didn't write their driver's.
Ok it's not consumer ready then. Still a worthless piece of shit.
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.
>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.
>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?
>the average waytroon amdrone
I just can't take amdrones seriously. The waytroon and amdrone bases gerenrally overlap and both are so clueless but act like they're experts on the topic.
These wayland threads are boring but sometimes funny. I come back to them after like 8 hours and there's 200+ replies. 1/3 of them probably from the same guy trying to turn this into the new systemD issue from a decade ago. The problem being that theres far fewer x11 schitzos than init evangelists. There's not even any x11 protest distros as far as in aware.
>There's not even any x11 protest distros as far as in aware.
Because you can just use x11 in every distro and go about your day.
Yeah, you can have both installed and choose.
Systems choose which init you use typically and rarely support multiple.
You parse it once at startup and then it's an int inside program logic; it's not measurable.
>You parse it once at startup and then it's an int inside program logic
Okay thanks for telling me you've never looked at any wm source before.
>Nobody is forcing you into a "common implementation"
Yes they are, literally every wm uses the xserver which is an enormous pile of shit.
>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.