Anyone remember Linus saying "I hioe Valve comes and fixes the packaging issue on Linux"? (yeah, from that ancient DebConf)
I hope Valve comes and fixes the very slowness of anything Wayland.
> I hope Valve comes and fixes the very slowness of anything Wayland.
The current state of affairs for Wayland seems like how Linux kernel development would be if nothing except stable (no linux-next, no forks) existed
That's a good point and it makes me think about the idea of developing a Linux-compatible Rust kernel from scratch. Though, in this case, the scale is very different.
Well, it fits my wording, haha. But I was actually referring to the article talking about Rust in Linux kernel.
One of the idea brought up is to make a Linux-compatible kernel or an otherwise separate project, then bring the implementations slowly into Linux kernel, as an alternative to the constant clash (at the time?) between newer Rust-in-Linux contributors vs existing predominantly-C kernel maintainers.
Huh? I was referring to the idea posited at the end of [this blog post](https://drewdevault.com/2024/08/30/2024-08-30-Rust-in-Linux-revisited.html).
As an end-user, I kinda don't really care about the route people take in order to ship softwares that are beneficial to users (me).
I'm not saying whether or not it is right or should be done. But this case reminds me of that idea, which itself reminds me of some posts where people asked, "Why isn't ever just one project in FOSS instead of weird fragmentation," to which I have commented about logistics and politics involved in FOSS (exhibit a: Wayland Protocol) that it's often better to just let projects naturally fragments for devs and users.
What he was complaining of was the difficulty of sharing an executable package "for linux." Not for Debian, not for Ubuntu, not for Arch, just one package that works across all distributions. Since that conference, a lot of stuff has happened, and it's why so many applications provide flatpaks or snaps now: having a package as a flatpak essentially guarantees all of your users can access and use it on Linux.
I disagree. Most people aren’t willing to install Flatpack just to use a handful of applications.
Unless Flatpack ships with your distribution by default, I cannot assume that you are using it.
What are you disagreeing with? I talked about availability, you talked about choice. While those two are related, we are not in conflict: these packages are guaranteed to be available to you unless you can't run these sandboxed packages at all, which is unlikely. Whether you want to use them or not isn't part of what I'm saying.
Every package is guaranteed to be available
There's nothing magical about Flatpak. You can, with not too much additional effort, install an .deb, .rpm, .tar, .nix on any distro you want. It's all the same Linux/glibc ABI...
If binary compatibility between distributions wasn't an issue, nobody would be talking about it being a problem. Even pretending glibc didn't break ABI all the time (which it does, and is why rolling release distros regularly have minor package version bumps that are simply recompiles of the previous version with updated compilers), libraries/dependencies are not synced between different distributions. Dockers didn't start happening because compatibility was easy. Theoretically, sure, any deb package can probably be installed anywhere with enough time and dedication, and many are likely trivial to install anywhere! But a flatpak or snap will just work.
This is a very confused post.
I’m not sure what you mean about recompiling. Flatpak binaries are either statically compiled or dynamically compiled, same as any package manager.
I’m just not sure what magic you think Flatpak is doing. All package managers do is ship libraries and binaries. If you need two versions of the same library, due limitations of the FHS, you’d run into filename conflicts, but these are easy to work around.
Flatpak isn’t the only package manager that does this either, Nix has been doing the same thing for 20 years. The Guix package manager has a function called `pack` that will produce a deb, or a docker, or a squashfs that works anywhere.
Heya, I'm sorry for taking so long to reply. I do not come onto reddit often, and I don't really wanna keep arguing about this topic, but I just don't understand why you think these solutions to compatibility issues are invalid when compatibility is obviously an issue.
Virtual environments are used everywhere to guarantee a working environment for various applications and, whether its a library issue or an ABI issue, flatpak is a solution. If there's anything confused about my post, it's in trying to understand why somebody on Reddit is telling me that issues that have existed for decades don't exist. It's in trying to understand why somebody is telling me I can just repackage something as a \`.deb\`, but trying to pull a package from unstable into stable can break your whole system if you don't know what you're doing.
Moreover lots of people (me) absolutely refuse to use snap or flatpak, because of its absurd size of packages. Frankly I prefer building from source, at least then I know those 10gb for a server program aren't on the main drive (the one I keep for copy on write RAM Linux boots).
In this specific case, SteamOS being immutable(-ish) and adopting Flatpak as their default has done a lot in making developers adopt Flatpak as their default as well, and it also makes people not default to using root as well which helps makes more thing be more distro-agnostic as a side-effect.
From memory he said something about how Valve is not going to go through the usual hoops of making a different package for every distro, but that they would release one standard one.
A few minutes ago I went through overview of this merger request and found a lot of negative feedback from individuals with "Pronouns" which are obviously RedHat employees.
This comment has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
* Your post belongs in r/linuxquestions or r/linux4noobs
* Your post belongs in r/linuxmemes
* Your post is considered "fluff" - things like a Tux plushie or old Linux CDs are an example and, while they may be popular vote wise, they are not considered on topic
* Your post is otherwise deemed not appropriate for the subreddit
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/linux) if you have any questions or concerns.*
Sounds perfectly reasonable to iterate on protocols like this to then eventually gather feedback over time and implement them as an actual Wayland protocol.
Same, I feel like some people here are a bit too worried about potential fragmentation, but sometimes engineering work requires you to build prototypes and demos just to prove something out, find the corner cases and pitfalls and then iterate. If anything, this either becomes the defacto standard or its mistakes will dramatically inform whatever becomes the official Wayland implementation. This is a good thing.
Wayland is, by design, fragmented. There is no way around it, having no official implementation, forcing every project to implement all the features and making it hard or impossible to implement basic features was a stupid move.
How can you say that Wayland is fragmented? It's a protocol!
But I guess you keep comparing Wayland to Xorg and that's a mistake.
Wayland is a protocol, Xorg is a protocol plus the server.
It's obvious that the protocol needs a server and the composers of the various DEs do that, the implementations on the composers are fragmented, because there are many DEs that use different composers. Nothing prevents XFCE (for example) from using Kwin or other compositors.
Which is one of the things that pisses me off about wayland. It puzzles me how the creators just shrugged it off that DEs and WMs can implement certain protocols at their discretion would worsen linux fragmentation
That's because Linux is fragmented in general. The needs of KDE are different from the needs the of someone developing a car infotainment system (a lot of those actually use Wayland under the hood!), which are in turn different from the needs of Valve's gamescope team.
X.org's (and frankly X11's in general) biggest problem is the fact it's a giant monolithic piece of software intended to cover all possible usecases in existence, some of which are mutually incompatible.
Doesn't X11 basically have the same problem and a slightly different organizational model to manage it?
Hell, even Microsoft products routinely re-implemented / work around Microsoft SDKs and APIs. Shit is just hard to get right the first time for everybody.
X was made with a completely different way of computing in mind. It began back when personal computers didn't even exist and is more of a server-client thing.
They had to implement a ton of extensions and thus it became this weird thing where there's patches upon patches and a whole lot of Spaghetti code that nobody wanted to touch.
There were several proposals to fix X and Wayland came out as a supposed replacement. 16 years later it's still not feature complete and has to leverage X to actually work in some cases.
Under the hood I don't think X is Spaghetti code like is often stated. Repeat something enough and people start to believe it. It may be huge but it is still modular and organized, without the dependency hell that Spaghetti code implies. X extensions are a way to add features and APIs just like Wayland has mechanisms to add APIs to the core. There are a ton of extension APIs in Wayland too.
Its really enlightening to peruse all the APIs on [https://wayland.app/protocols/](https://wayland.app/protocols/) Compared to the fairly limited number of X extensions the typical X server runs, xwayland looks like absolute chaos with all the window manager, graphics card, and even client specific APIs creeping into the core APIs. That's how spaghetti code develops. Clients like GTK and QT and whatever else have to be able to support unique window manager stuff? I mean, just look at xdg-decorations. Clients by default have to support drawing their own window decorations? Consistent look and feel is accomplished how? Why is that better than the way X does it?
This is a lie often repeated. Wayland is not developed by volunteers, it's developed by employees of certain companies. They're paid to develop Wayland and not.
The original Wayland developers came from X, sure, but they were just a small part of X' developers. The myth is that the X team grew tired of X and created Wayland which isn't true.
X is mainly maintained by volunteers and receives constant updates, there's even devs working to reimplement it in BSD.
I see. That just makes it worse that these paid employees haven't created a better reference implementation. I mean, they DO have a reference implementation, but I guess it must be pretty bare bones or something, cause nobody really talks about it.
So true. So much free software isn't actually produced by an army of volunteers but payed devs working at companies that many free software devotes love to hate. The irony.
Speaking of irony, I wonder if the Xorg situation were caused by large companies putting out recs for Xorg developers and HR is the one who couldn't find the hires because nobody has Xorg on their resumes. But put out recs for a new technology and no experience needed. If you've worked at a large company before you know how bureaucracy works. :)
Fair enough, that doesn't change the fact that the original maintainers complained about what opinion the asset was to keep supporting it with new features. I still think Valve is making the right choice here, supporting a faster, more iterative approach to Wayland.
When considering Free Software project simplicity or maintainability, look first to developer activity. People actually want to (and do) volunteer Wayland their blood, sweat, and tears. The same can no longer be said for any X project.
IIRC, and before my time, but pre-xorg times some companies that released an X frontend for their UNIX-like OS also had the genius idea of implementing unique extensions that their competitors didn’t have that then went mostly unused because who wants to write code for one specific OS when you could make it more OS agnostic and just not use that feature?
The difference I think there is that windows basically holds a monopoly on the desktop market so the downside isn’t really there for the company doing that. If you have exclusive features but a tiny user share, don’t expect anyone to care about your exclusive features.
Its also hillarious that X, the way it exists currently, is way better suited for secure enclave computing (i.e., PCoIP) than wayland xD...
side note: yet again, in hindsight, history shows that Canonical was way ahead of the curve yet again with Mir....
In theory, it is indeed similar in architecture. In practice, it's a spaghetti of extensions all made with the sole purpose of fixing other extensions, which were created to make it work for things other than 80s mainframe/terminal setups.
Wayland will *eventually* reach that level of headaches, as does any technology,
I'm sure your average Instagram addict has different needs than satellites, yet both run Android without issues. An office has different needs than an ATM but both run Windows. My router has different needs than my laptop and both run the Linux kernel. I have different needs than a Google engineer but both of us run the GNU coreutils.
This just sounds like a weird justification after the fact. Wayland was too busy, too obsessed with their own definition of "pixel-perfect" rendering and their own definition of "security" so they neglected basic features. Wayland has been in development for the same amount of time as Android and yet Android seems to be more useful for more users in more contexts than Wayland.
To me it's astounding how so many things that have been available on PCs for decades are not possible under Wayland and they're instead sidestepped with Pipewire, D-Bus or esoterical nonstandard DE extensions.
I might be mistaken but I believe X had less time of development than Wayland has had until now.
> Wayland has been in development for the same amount of time as Android and yet Android seems to be more useful for more users in more contexts than Wayland.
I don't know if you know, but android is developed by a single, multi-billion organisation.
Irrelevant. Wayland's development is funded by multi-millionaire organizations and they have employees actively working on it.
Canonical had a working alpha in just under two years and Android itself was released to the market with a working compositor back when Wayland was nothing but a bunch of proposals.
It took Wayland over 10 years to add a tearing protocol. A feature sorely needed in several usecases. That's sheer incompetence, plain and simple.
> Irrelevant. Wayland's development is funded by multi-millionaire organizations and they have employees actively working on it.
Relevant. Organizations (plural) versus organization (singular) does affect development speed. At least, that's what I gather from Valve here.
Also, I find it hard to believe that Canonical and RH are not small fish compared to the company that develops what's probably the most widely used OS for personal devices, and has other revenue streams besides tech support.
> It took Wayland over 10 years to add a tearing protocol
Tearing in X was one of the main reasons for me switching to wayland, with its promise of design that more or less eliminates tearing, so I was kind of suprised when I caught wind of this.
Suffice to say, nobody actually wants tearing, even the people that do want a tearing protocol in wayland, so this is all very niche.
Canonical managed to push out a working implementation of Mir in two years with far less developers and less money. By that point Wayland was still vaporware with nothing to show.
Tearing is important in many usecases. The fact that Wayland took over 10 years to add that is preposterous. Then again, copying and pasting is still a mess and things like screen sharing or color picker were not even fixed by them but added by PipeWire.
16 years is far too long. Wayland hasn't even reached feature parity with Windows 7 or even Xorg and never will because its poorly designed.
> Canonical managed to push out a working implementation of Mir in two years with far less developers and less money.
Yeah Mir was an amazing product that probably had all the good features like tearing that wayland lacks. I'm actually not sure if it was ever made default, or even considered close to done by the team. By Ubuntu 16.04 (end of 2016), Mir was [still not the default](https://forum.ubuntu-nl.org/index.php?topic=97565.0), and [guides from that time](https://www.howtoforge.com/tutorial/how-to-test-mir-and-unity-8-on-ubuntu-16-04/) that help users with installing it mention it "being riddled with bugs"
You're straying a bit, as well. My initial point was that comparing wayland development speed with google's android efforts is a stretch. You might be right about Wayland's other problems, but that comparison was silly. I think admitting your wrong about something can be a good mark of character.
Of course it wasn't default, it was an alpha build and not ready for production.
I mean, they could've gone the RedH*t road and push it to users so they beta test for free, but they usually wait until the product is at least usable.
In 2018 (10 years after creation) Wayland still didn't have a working clipboard. Today it still crashes programs if the user moves the mouse too fast, it still relies on D-Bus and DE-specific extensions to do basic stuff like color picking and scaling, it still doesn't allow programs to decide where to draw their windows or to move a window independently from another one (as in settings), drag and stop is still a mess, and it STILL doesn't work properly on Nvidia GPUs (Canonical had the decency to pull the plug on Mir once Intel announced they wouldn't support it.)
My initial point stands: 16 years is far too much. Wayland should have feature parity with their competitors but it doesn't. Whether or not Android is maintained by Google is irrelevant since Wayland is well-funded and has a lot of paid developers working on it.
>I'm sure your average Instagram addict has different needs than satellites, yet both run Android without issues. An office has different needs than an ATM but both run Windows. My router has different needs than my laptop and both run the Linux kernel. I have different needs than a Google engineer but both of us run the GNU coreutils.
I just recently saw a video which said that Pixel use around 8M lines of code from kernel whole PC use around 4M lines of Kernel. They all use codes related to them or sth like that.
Yes the needs of KDE are different from car infotainment, which are different from gnome.
But are they really? In the interest of not having any extra bits not being
Imagine if the kernel was a series of protocols for implementing I/O, networking and drivers, and each distro had to rewrite all of it.
Or if systemd was just a series of protocols and each distro had to implement their own versions of things like systemd-boot or whatever.
> Imagine if the kernel was a series of protocols for implementing I/O, networking and drivers, and each distro had to rewrite all of it.
Congratulations, you invented POSIX standards! They pertain to operating systems rather than kernels, but ultimately they govern how you should design a Unix clone. This is the reason many Linux distros behave fairly similarly, and why you don't need to relearn every single tool if you decide to use FreeBSD instead.
> Or if systemd was just a series of protocols and each distro had to implement their own versions of things like systemd-boot or whatever.
That's how things were done before systemd was introduced, and that's how many distros still do it, for various reasons (you wouldn't want to drag the entirety of systemd on a router, would you?). It's neat when there's a good monolithic piece of tech that solves the issues you have, but systemd is more of an exception than the rule.
> That's how things were done before systemd was introduced, and that's how many distros still do it, for various reasons (you wouldn't want to drag the entirety of systemd on a router, would you?). It's neat when there's a good monolithic piece of tech that solves the issues you have, but systemd is more of an exception than the rule.
Except the entirety of systemd is really just the init system. systemd *isn't* a monolith, you can not-use huge chunks of things regarded as "systemd". What it is an effort to provide sensible default implementations for most of the things most systems need in some level. And my router (Unifi) *does* run systemd...because a router has services and dependencies, and needs an init system which orchestrates those.
The problem with "you wouldn't want all of X" claims is...by what metric? It's not like these things compile to a particularly large amount of binary code.
Which is *really* what Wayland needs: sensible default implementations (and if they're sensible enough, they basically become the standard) of things pretty much everyone running a display needs: i.e. copy and paste is a thing everyone needs. Multiple resolutions and scaling is something everyone needs. I would argue remote desktop is something everyone needs (my car head unit might not strictly need it, but the people developing and debugging apps for it it probably do, and realistically advanced systems are likely to need something like that if they're supporting multiple screens in the same vehicle).
> The needs of KDE are different from the needs the of someone developing a car infotainment system (a lot of those actually use Wayland under the hood!), which are in turn different from the needs of Valve's gamescope team.
Funny you should say this when both Valve and Mercedes use KWin for their respective products.
> X.org's (and frankly X11's in general) biggest problem is the fact it's a giant monolithic piece of software intended to cover all possible usecases in existence, some of which are mutually incompatible.
No, X.org solves very few problems, to the point where you can't make a decent window manager for X.org. You need to bake in a number of X.org extensions, which may or may not be standardized.
Sounds like Wayland has replicated the problem.
On GNU X had a single implementation and the code will behave the same under all DEs.
On Wayland the same code will behave differently in different DEs depending on what features they have added, how do they behave and if there's any nonstandard extensions on top of it.
The only way it wouldn't have been fragmented was if gnome and kde, or kde and sway, or gnome and sway or some other combination were based off the same shared base layer. Just because wayland is protocol centric doesn't mean the implementations had to be.
Something like wlroots should have been the base of what many of them used.
So true. The basic idea of splitting up rendering and composting components is architecturally a good idea and so is taking time to iterate on APIs for a while. But the total lack of a complete, real cross-platform reference implementation and competent governance has resulted in chaos for 16 years. Its all hypothetical what ifs at this point, and I don't think you can even blame the Wayland Devs because I think they were very clear about not wanting to do anything other than the core interface stuff. Steering the ship on a large project is usually the tougher job and I can understand why someone would not want to take that on. But someone has to do it...
I actually wish the replacement to X weren't called "Wayland" because that's just such a tiny part of whats required. "Wayland" deserves only a small amount of credit since they didn't want to take on the hard work.
Canonical managed to push out an alpha for Mir in around 2 years. They were creating both the protocols and the implementation. By that point Wayland had around 5 years of development and nothing to show for it.
Wayland devs have been grossly incompetent. 16 years and it still doesn't have feature parity with Windows. Which, by the way, 16 years was the same amount of time between Windows 3.1 and halfway through W7's life cycle; by that point the entire graphical stack of Windows had been rewritten several times.
Speaking of Canonical, they forked Android's compositor and Wayland and managed to push out something. At this point I'm not even sure if that's an impressive feat or if Wayland's lack of feats is what's really impressive.
That connects some dots. I remember Canonical's brief foray into cell phone operating systems so that must have been where Wayland came in and replaced mir. I also vaguely remember that Wayland started out as an embedded display protocol. I'm starting to see how this random walk might have unfolded.
Im somewhat impressed that the wayland ecosystem works at all. If you can get over the lack of a \*decent\* remote desktop solution or cross platform support, and just stick to say Gnome and modern GTK based Apps, and use only team red GPUs, it works quite well. Very snappy. That's a lot of caveats though and, for a lot of users, it doesn't meet minimum requirements.
Even with that setup if you need fractional scaling, VRR, tearing or screen sharing the experience is subpar.
I can see how Wayland + GNOME works good enough for developers. All they need to actually work is a text editor and a web browser. Anything else and Wayland still has issues.
Sadly Wayland developers are vehemently opposed to official implementation:
[https://gitlab.freedesktop.org/wayland/wayland/-/issues/233](https://gitlab.freedesktop.org/wayland/wayland/-/issues/233)
We've been waiting for protocols to be "merged back" for 10 years. This is just more "unofficial standards" instead of proper protocol engineering.
This will get abandoned soon and someone else will come up with a different protocol that does exactly the same thing, only to also be left to rot in the sidelines.
Wayland community, fix your shit. Give us an actual, usable standard for once. The idea is good, but in practice it's a fragmented shitshow with every compositor playing by their own rules and lesser-known independent ones being incompatible with everything else there's no standardization.
Standards don't matter. What matters is what Mesa does. That's the standard.
This is the Wayland community problem, there are people who will go in circles talking about protocols designing things that only work on paper and not do any actual work.
Someone will come up with a new standard proposal, sure. But it will go absolutely nowhere.
I guess the problem raised by Valve is not so much about the Wayland protocol, but about some features that are not there yet and that continue to be discussed without reaching an implementation.
On this I agree with Valve, it seems that some Wayland developers are stubborn about some things and block their implementation.
But I repeat Valve is not criticizing Wayland and it is stupid to compare Xorg to Wayland, they are different things, conceived differently, Wayland is a protocol, when we talk about Xorg we are referring to two elements, the protocol and the server.
I don't think Valve is nostalgic for Xorg because it is aware of Xorg's problems.
Endless discussion is the Linux way!
Windows and Mac are constantly adding features and improving the OS. But Linux? Endless discussion and constantly reinventing the wheel.
How can anyone say Windows is improving over the last decade or so (being generous here)? It's getting progressively worse. MacOS has taken over 20 years to implement native window tiling, tho it's not getting worse at least.
"Linux" is both of those and everything in between. I don't think people realize how hard it is to over generalize about something created by countless individuals. Its not like we're talking about a centrally controlled project here. Unless you really were referring to the kernel?
The kernel is the best part of Linux. Moving at a steady pace, not wasting too much time, not constantly reinventing the wheel.
It's everything else that's the problem (with a few exceptions).
A meta comment, it's interesting to see the reception to the idea. If it had been any other entity other than Valve, I'm sure the responses would have have been more negative.
That criticism was deserved. Canonical always tries to pull some shit that will give them vendor lock-in to gain advantage.
* Mir was supposed to use Android drivers. Android drivers are often out-of-tree binary blobs. Paired to one exact kernel version, leaving you hopelessly at the mercy of GPU manufacturer, who never updates it ever again.
Imagine the power it would give to Nvidia /s
* Snapd uses hard-coded store endpoint. The store server is proprietary(!).
inb4 "But Red Hat!" Flatpak allows you to use multiple stores (remotes), published by whoever wants it - you only need http server. Even install one-file pre-packaged bundles.
Valve has a reputation of taking forever to do shit but when they do shit it's WILDLY good. They earned our trust and almost never abused it (at least in comparison to the rest of the video game industry). It's because of them working with linux devs that we can even leave windows just before Copilot's about to drop, that's worth a lot. No company is perfect however, I can name 4 fucked up things they have done off the top of my head:
* 25% cut for paid mods (this might have been Bethesda's idea, considering Creation Club) but it lasted like 1 week before getting axed at least.
* Quickly abandoning Artifact when it didn't pan out (to be fair nobody really cares except like 50 people)
* Neglecting Team Fortress 2 for years (and then they came back, kinda)
* Inconsistency in regards to NSFW content approval processes (I don't buy NSFW stuff on steam so I don't really care)
Which should honestly say something about how slow Wayland is progressing when even Valve, the people who take forever to do things, are going "You guys are taking forever to do this."
The paid mods thing was an idea Gabe had, that was quickly abused. He thought it would be cool if members of the community could create content for beloved games and make a career out of it. As a concept it's good.
As a concept, he literally envisioned patreon modders, but wanted to make it integrated to steam years before it was a thing. So technically, he was correct in idea, just bad timing and bad execution made things messier for everyone(as paid modders platforms are fragmented, and you have less users rights, some even adding DRM or force you to keep subscription for mods to be updated for current game patch)
It's the difference 'earned trust' makes. Valve has demonstrated that they can be relied on to do things that are within the Linux community's and Linux ecosystem's best interests, because Valve themselves are heavily part of both and benefit from a strong Linux community and ecosystem. If some corporation like Sony, or Microsoft, or Facebook did this? Yes we'd be justifiably very concerned because those corporations have demonstrated that the only thing they can be relied on, is to put shareholders, corporate profits and personal gain ahead of everything else.
I've been using Linux since 1997. I cannot tell you the last time I had a problem with X. I cannot tell you the last time I *configured* X. I know there are apps that fail in certain ways under Wayland\*, thus I stick with GNOME under X. I have yet to read a compelling reason to switch to Wayland. So much of what I've read seems to me to be, "It's newer, so it's better".
(\* For example, a couple years ago Shotcut wouldn't work under Wayland when using the Chroma green screen filter. I switched to X and it worked immediately.)
You can use X for as long as you want to. There are people still using Windows XP so I don't see why you cannot keep using X for years to come even though it is a dead project and nobody is developing it anymore.
> keep using X for years to come even though it is a dead project and nobody is developing it anymore.
This is false, the X server codebase is constantly receiving work and updates. The standalone X server had a release ~5 months ago (mainly bugfixes) and XWayland gets an almost monthly release - note that these share 99% of the code, the difference between XWayland and the standalone X server is that the former uses Wayland to talk to the display and the latter uses the kernel's DRM APIs.
>This is false, the X server codebase is constantly receiving work and updates.
This is a 2024 quote from Adam Williamson from Red Hat:
>Wayland and X.org are both part of freedesktop. Whatever maintenance is still happening on X.org is mostly being done by people who primarily work on Wayland. AFAIK there isn’t anybody who is actually clamoring to do the work of maintaining X.org upstream.
Yes, the X server is still receiving patches from developers paid by a company that wants it dead and replaced. That's a dead project by my standards. But like I said, if people want to keep using it for years to come then I'm all for it.
> Yes, the X server is still receiving patches from developers paid by a company that wants it dead and replaced.
There are more people than just Red Hat developers contributing to the X server - in fact the standalone X server release maintainer is an independent developer who accepts [patreon](https://www.patreon.com/p12tic) donations to work on the projects he contributes at.
Even if Red Hat wants it to die they aren't really in a position of power to do so, the project is open source. Worst case it gets forked to something else (but there isn't really a need to do so).
> There are more people than just Red Hat developers contributing to the X server
There is not more **people** contributing to the X server other than Red Hat developers, there is a single person doing that AFAIK. Unfortunately this is not the kind of project that can be maintained by a single person.
> Even if Red Hat wants it to die they aren't really in a position of power to do so, the project is open source. Worst case it gets forked to something else (but there isn't really a need to do so).
In theory, yes. In practice, nobody is going to maintain it. This is wishful thinking. It's like saying "if Mozilla stops working on Firefox someone is going to pick it up and it will keep going because it is open source", but everyone knows that if Mozilla stops developing Firefox it will be dead. It's not the kind of project that can be maintained by a couple of guys in their free time, it needs a bunch of people working full time on it.
Have you actually checked the source code for the X server? Because i have and the comparison with Mozilla is *way* out of proportion, the X server is *way* smaller - only around 345k lines of code and that includes the code for XWayland, XQuartz (X for macOS), XWin (X for Windows), a *large* part about device-specific functionality, etc - the X server itself is probably less than 100k lines of code. In addition unlike Mozilla, the X server doesn't have to chase after some Google equivalent adding new crap to the web left and right, its functionality is largely done - which is why most changes these days are bugfixes. There is some functionality that could be added (like support for HDR displays) and perhaps at some point some stuff will need to changed (e.g. some new underlying graphics API) but these are minor compared to the rest of the codebase.
You don't need the good will of a corporation to maintain the X server, if a single person can maintain a Wayland compositor (and many do), then a single person (or, more realistically, a handful of people) can maintain the X server. Hell, wl_roots, which provides a fraction of the functionality of the X server, is already ~70k lines of code but you don't hear anyone claiming that it is impossible to maintain.
The only reason people outside of those who work on it right now haven't picked up the X server is because they don't need to as it already works - and because of XWayland the codebase wont be abandoned any time soon.
>Have you actually checked the source code for the X server?
No.
>Because i have and the comparison with Mozilla is *way* out of proportion, the X server is *way* smaller - only around 345k lines of code and that includes the code for XWayland, XQuartz (X for macOS), XWin (X for Windows), a *large* part about device-specific functionality, etc
I was not comparing code size. In the case of X server the issue seems to be code complexity. I've seen reports of many people saying it is very, very hard to work with all that spaghetti code that was written decades ago. Wasn't this one of the main reasons why X is being replaced by Wayland?
> I was not comparing code size. In the case of X server the issue seems to be code complexity. I've seen reports of many people saying it is very, very hard to work with all that spaghetti code that was written decades ago.
It most likely depends on which aspect one works on, but keep in mind that a bunch of stuff was rewritten over the years - it isn't the exact same code, even if it does have old code. I did check out the code some time ago but it was mainly the modesetting driver (i was looking into making an SDL-based driver so i can run X inside X with fancy effects like CRT shaders :-P) and the code seemed pretty straightforward and readable to me. Perhaps the older parts of the main server are a bit gnarlier but at the same time i think those would be the parts that'd need the least to be touched anyway.
> Wasn't this one of the main reasons why X is being replaced by Wayland?
I think there were more reasons for Wayland to be pushed as an X replacement, though yes, people who worked on X wanting to do their own brand new thing from scratch was also a reason.
Both Electron apps that are barely tested on Linux by their developers and/or deem the time to make them work on Wayland better used elsewhere instead, sadly
It's kind of sad how I'm seeing so much disdain and commercialization of an open source project. I really appreciate what Valve has done, but we can't point the finger at contributors as if they were the antagonists in this story.
We can talk about how to deal with all of this without treating it like a product.
The development model is one of the things that made all of this consistent, and the result of that consistency is what made everyone want to set this as the standard. Now everyone wants to skip processes in the name of commercializing an open source project that is working. Of course there are problems that need to be talked about, but in the midst of all this what I see here is "X company will fix Y" leaving aside contributors who are working on several things at the same time, but of course, it is important to create antagonist for a narrative to have a solution.
If the GNOME devs stopped dragging their ass, shooting down sensable protocols, and refusing to compromise, we wouldn't be in this shit show. They shouldn't have the authority alone to block a protocol adoption.
Its because to a big degree, they are the antagonists and people are getting really sick of it. The entire Linux world was basically told "we're moving to Wayland, gtfo if you don't like it".
Now that move has happened or is happening, people are having to fix a lot of shit to have things actually working. Major DE's and WM's are implementing things on their own and coming up with their own protocols to make thing work, because what we were all told to switch to had badly inferior functionality.
You can't do that and then expect no criticism.
The development model is one of the things that made all of this consistent, and the result of that consistency is what made everyone want to set this as the standard and honestly, nothing you say makes sense, it just sounds like someone resentful of the change from Xorg to Wayland.
But of course, we are here once again in the place where people spit on the plate they eat. They point the finger at contributors who use their free time. You guys are ungrateful.
You mentioned "changes" as something innocuous but this in many popular use cases, meant sending end users back to stone age in terms of desktop technology. No matter how happy some upstream devs may have been with the new protocol adoption model, the users were taken aback by the magnitude of regression in functionality for something that was supposed to be "future".
And it seems the good faith of "it's not Wayland, it's downstream devs that won't move away from X" has run its course now that even "middle stream" is fed up of the glacial pace at which things are progressing.
Granted, it's always easier to spin your own kitchen than work in community so we should be careful about fragmentation and quality issues, but really, is this outcome surprising when one of most opiniated point of Wayland founders is that they don't want to implement and maintain an official display server? That eventually downstream would do as they please when not satisfied with upstream protocol adoption model?
> Applications using FIFO stall when occluded.
Good. I don't want you running your whole application logic at 60 fps even when the application is minimized.
Your application should use zero CPU when minimized (excepting for media players)
Just run the logic to calculate the current state when it's needed. If your game has been minimized for 3 hours and the user brings it up, you should write code to figure out what would have changed in those 3 hours and directly make those changes. You should not be running the whole simulation at 60 fps even when the user is doing another task.
>Good. I don't want you running your whole application logic at 60 fps even when the application is minimized.
Pause the game or suspended the process manually. Problem solved. Many games do this automatically when focus is lost.
>Your application should use zero CPU when minimized (excepting for media players, which you can do in another thread)
Get a CPU with more than 2 threads.
>Just run the logic to calculate the current state when it's needed. If your game has been minimized for 3 hours and the user brings it up, you should write code to figure out what would have changed in those 3 hours and directly make those changes.
This is insane. A lot of games are CPU bound by one of their threads, and usually not the one dedicated to rendering. It might literally take 3 hours to simulate what happened in 3 hours.
>You should not be running the whole simulation at 60 fps using most of a CPU core even when the user is doing another task.
On a half decent modern processor, maxing out a single thread has minimal performance penalties for the rest of the system.
We really should be forcing the wayland-protocols and major compositors' folks to get together and produce an actual usable standard instead of bringing yet another unofficial/unstable protocol to the table and further increasing the fragmentation and reducing interoperability.
Wayland is a nice idea in theory, but a shitshow in practice
We've seen something similar to this happen a few times in other domains: When a committee gets stuck in bureaucracy making a decision, if a product and customer-facing company says "screw that we're moving forward", that committee should be very worried about their legitimacy, and needs to introspect on their behavior.
In the web world: Its actually quite impressive that many of the web standards committees are still around and respected when Google/Chrome has, on multiple occasions, said "we're moving forward with Standard X with or without you". I think having Mozilla and Apple be such big players and (frien)enemies of Google (on some issues) actually helps keep the standards aligned and moderate. One of the very old examples of this is some of the web DRM proposals; many in the open source community were pissed that the web standards committees supported them, but what are they supposed to do? If they don't play ball, Google and Apple ignore the standards, and now there's no standards body and we're back in the dark ages.
Standards bodies serve the implementors, not the other way around. They aren't the police, and companies like Valve, Google, Apple, etc will only listen to you for as long as you are more useful and profitable than charting their own path. The power complex some of these people develop working on their little open source project can be quite unhinged.
Does anybody even respect/care for web standards committees? I've read countless times web devs claiming that Chrome is the standard. The fact is that anything supported by Chrome becomes and standard regardless of anything else.
W3C is like the UN. It pretends to be a democracy, while it's actually ruled by a "dictator".
Chrome "owns" the web, and the W3C is as respected and powerful as an empty puppet can be (and by that I mean: almost zero respect, almost zero power).
My impression of orgs like the W3C is: they are respected in the sense that they represent a foundational baseline into which all the major browser vendors will at least *attempt* to get their prerogatives merged. Evolutions to web standards don't generally start with the web standards body itself; they start with individual members, usually browser manufacturers, and the body serves the purpose of coordinating communication, discussion, arguments, and voting.
Sometimes those changes get rejected and Chrome moves forward anyway, but it doesn't tend to be on really big stuff; put another way, the web is still by-and-large One Web, and website developers 99% of the time don't need to worry about differences between Blink, Gecko, and WebKit (and, most of the remaining 1% are bugs, not intentional differentiation).
One recent point of contention was the Ad Topics API. Both[ Apple/Safari/WebKit](https://github.com/WebKit/standards-positions/issues/111) and [Mozilla/Firefox/Gecko](https://mozilla.github.io/standards-positions/#topics) have publicly announced their intent to not support this API. Google/Chrome/Blink, despite this, has pushed support for it into Chrome, and [have written an unofficial draft](https://patcg-individual-drafts.github.io/topics/); this probably won't be pushed into becoming a standard, because it will get shot down, but that doesn't stop Chrome from shipping it. We'll see if Google continues to support it; but I suspect that given they can do whatever they want with their own browser, the real intent behind Topics was to get Apple & Mozilla to implement it and calm down their "Hyper-Privacy" Crusade; which did not work, and they will continue to do everything they can to protect their users.
Speaking of which, its obviously not only Google that breaks from the standards; Apple Safari, especially on mobile, is another misbehaving piece of tech. Some of it is intentional; Apple very intentionally breaks Safari's compatibility with some web standards in order to protect its users' privacy, battery life, etc. Web App Manifests is another one that might be more sinister, as Apple has a vested interest in stopping web apps from being able to compete on equal footing with the App Store.
I'd follow baseline from now on:
If the last of
- Chrome (desktop and Android)
- Edge (desktop)
- Firefox (desktop and Android)
- Safari (macOS and iOS)
Supports it, it is newly available. 30 months later it's widely available.
Ironically, its been widely reported that Valve has had to spend an enormous amount of time and effort working through their own internal organizational/governance issues in the past decade.
I was referring to issues with their flat corporate structure. It's hard to get products pushed passed the finish line when people can change teams and work on whatever they want at any time.
I did see someone referring to this in a Reddit thread. I guess they use to let projects manifest organically and didn't require approval. They have since gone back to requiring approval which has has improved completion of projects. Apparently, this was explained in their Half-Life: Alyx documentary. I'll have to check it out. Though, if you know of some other resources covering their struggles with their flat corporate structure I'd love to take a look.
I get the sense that this present world order is going to go down not with a bang but with a whimper.
China is moving faster than democracy can support, but with fewer checks and balances. They're headed for an Icarus condition -- they'll fly high and either fly *too high* and fall, or become more powerful than any other country today.
The US can't keep up further for a variety of reasons. Too divided; too beholden to corporate interests for any long-term non-greedy investment. The UK and Western EU, caught in the past. Germany's too rigid; France too chaotic. Russia talks a big game but struggles to crush a far smaller neighbour. Said smaller neighbour and the whole neighbourhood is screwed anyway.
Japan has a bad-to-worse population pyramid. SKorea headed that way too. Taiwan is set for life in economic terms but forever having a Sword of Damocles over its head due to China.
African nations still have a long way to go towards basics like territorial integrity and stability of governance.
India? No. *humse na hua payega.* We can't do it.
So, no. No WW III because no one really has the capacity for it.
If it *does* happen, though, I don't plan on being alive to see its end. Can't live without my pills.
>Russia talks a big game but struggles to crush a much smaller neighbour
Eh, debatable since this neighbor is getting support from 38 countries and has all its expenses being paid by much larger economies.
But overall I agree with your message
I'll put it this way: Equipment is a *necessary but not sufficient* condition for victory and manpower is also *necessary but not sufficient.*
It should be noted that Russia is having equipment failures and other issues far in excess of what is reasonable for a superior attacking force. It's their backyard, ffs.
My point is less about the superiority of the Ukraine coalition over Russia and way more about Russia's clusterf in logistics, equipment quality and decision making.
> I'll put it this way: Equipment is a necessary but not sufficient condition for victory and manpower is also necessary but not sufficient.
Then what is? You can’t win lacking manpower or equipment
> It should be noted that Russia is having equipment failures and other issues far in excess of what is reasonable for a superior attacking force. It's their backyard, ffs.
And what is considered “reasonable”? This is the largest scale near peer conflict since the Korean War with totally new technologies (drones) being used widely that nobody accounted for.
> Russia's clusterf in logistics, equipment quality and decision making.
Wdym by this? They control a territory larger than Iraq with a 1.5k km frontline. Seems like if they had logistics or equipment failures that would be impossible
I remember when Wayland was the new hotness and was going to fix everything. That was over a decade ago. Thank god Valve has been stepping up and fixing things.
It doesn't have to be a huge deal.
Last week Gnome forked and merged an unrelased xdg\_session\_management protocol in Mutter under a different so they could get on with progressing. It was a perfectly reasonable and sensible move, you can't verify something without having an implementation and wayland-protocols wants things to be verified.
This is the basically the same.
They don’t sound the same. GNOME’s implementation is disabled by default and is not meant for end users. The merge request description says that this is meant to ship to “regular users”. It sounds like they are bypassing Wayland protocols process. If this goes forward, we’ll end up with a mishmash of protocols and users will be left confused as why something works on one system but doesn’t on the other.
>If this goes forward, we’ll end up with a mishmash of protocols
Even on wayland protocols, there's core XDG namespaced protocols that some desktops don't implement.
That's because a Wayland compositor has to deal with more than an X window manager / desktop environment ever had. WMs/DEs had no real reason to make their own X server to talk to underlying software, all they had to do was to focus on the thing they were interested about (providing an interface to work with windows), but Wayland compositors need to deal with the lower bits of the stack in addition to whatever upper bits a WM/DE would do.
In theory this could be solved using libraries that provide whatever X did, but in practice since such libraries are not part of the standard (out of scope and all that), different teams have their own ideas about how these libraries should look, what they should provide, in what language they should be written, etc, so you end up with multiple equivalents to whatever level of the stack the X server would be - and thus, fragmentation.
> different teams have their own ideas about how these libraries should look, what they should provide, in what language they should be written, etc
This is the actual problem. If GNOME and KDE shared any of this code then things would have moved on quicker.
>This is the actual problem. If GNOME and KDE shared any of this code then things would have moved on quicker.
Might as well take this further and suggest to co-develop a single compositor and use that one in all Wayland DEs. But this will never happen...
X has two main specs for the desktop things. [Extended Window Manager Hints](https://en.wikipedia.org/wiki/Extended_Window_Manager_Hints) and [Inter-Client Communication Conventions Manual](https://en.wikipedia.org/wiki/Inter-Client_Communication_Conventions_Manual).
The actual implementation of those things in X11 is pretty easy.
Note that there are things like "I want this window to always be on top of that window" (for like "yes/no" buttons, etc.), "I want this window to be resized in steps of n pixels" (so your terminal window doesn't have padding, etc.), and much more. Just read through it, it's interesting.
Wayland needs to have protocols for like 80% of those, and most of those are simple. They are just slow. Wayland is 15 years old. When it first came there was a LOT to do, especially as the kernel drivers and interfaces were made in step with X11.
My example is https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40
KDE, Gnome, etc., all implement their own version and seemingly nobody cares for the official spec. I can only guess why.
Hell, I'd write them myself. But I honestly don't want to deal with some "free"desktop people, not that it would go anywhere. Guess Wlroots and Cosmic protocols are the way to go.
Sure, but this would be worse. It would potentially be bringing the [same kind of mess that exists in text input protocols](https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/39) to any feature that might not be moving fast enough.
The fact that these protocols aren't implemented yet is an enormous problem though. This wayland transition is taking way too long, and it's causing problems.
Valid.
Since we’re sharing anecdotes, I’ve been using sway since 0.11 in 2016 and it’s been many years since I’ve logged into X on a personal computer
Everyone has different needs. I’m very happy to see Valve continue to push the envelope.
> If this goes forward, we’ll end up with a mishmash of protocols and users will be left confused as why something works on one system but doesn’t on the other.
Developers can just not incorporate changes that haven't been marked as stable. They have a vested interest in this not happening to their users.
The end result is that Steam Deck users have a high performant system with HDR while desktop Linux users don’t.
How long do we want to hold back real progress while bike shedding about theoretical designs?
Steam Deck will probably always move faster than desktop Linux. Valve doesn't have to guarantee any Wayland API stability as they're using Proton, has to optimize for a single use case of fullsceen games and can ship whatever they want whenever they want. Desktop Linux has to guarantee API stability, has to cater to multiple use cases and is constrained by typically high OSS review standards and release schedules.
However, that does not mean that the status quo has to remain unchanged. Wayland protocols can move faster by changing the process instead of creating a competing set of protocols. It looks like that's starting to happen going by recent comments on the MR.
Isn’t that the way of Linux and open source in general? Like some distros include all non-free drivers and software, while most mainstream do not, but some include a popup to do those tasks.
This kind of fragmentation leads to a bad user experience. One of the goals of centralizing on things like XDG Desktop Portals and Wayland protocols is to make the situation better, while allowing projects to move at their own pace. There could be charges made to the Wayland protocols process to speed up the process, but this feels like more fragmentation.
Does it? I mean, how many apps on the Linux and/or open source front do we have that started as forks but have stood the test of time? The Gnu project comes to mind. Not really a fork, but the apps have withstood the test of time. KDE, Gnome, XFCE, and their apps or apps that use QT/GTK.
>we’ll end up with a mishmash of protocols and users will be left confused as why something works on one system but doesn’t on the other.
Then let the best one win. That's how it has always been in FOSS. That's what happened to init systems, eventually everyone consolidated with systemD
Are you sure that's the best way to move forward towards quality products ?
I mean, Everyone loves Celine Dion's, taylor swift & Shakira & so on... You could also say that music listeners consolidated their tastes around their music..
But was it because their songs were wow, so super cool and super imaginative ?.. Or was if rather because of the amount of time they aired on popular radios eventually turning them all into earworms ? 🤷🏻♂️ Will we ever know ?
Imagine if systemd came about as a set of protocols that distros have to implement themselves, all the while proclaiming that sysv/upstart/Arch flatfile/openrc are deprecated.
> It sounds like they are bypassing Wayland protocols process. If this goes forward, we’ll end up with a mishmash of protocols and users will be left confused as why something works on one system but doesn’t on the other.
This is already what happens; all wlroots compositors implement their own draft protocols (such as wlr-layer-shell) until (if) they are made official protocols.
Every compositor has their private protocols, but they don't make it into components shared across all desktops like mesa. Shipping a third party protocol by default in a stable version of mesa would be something new.
Just this week i've tripped over the fact that GNOME doesn't implement the wayland protocol that lets sway and KDE listen for clipboard events.
It is already, and will always be, a mishmash of protocols. I'd argue progress is measured in abandoned protocols.
It is a huge deal.
People are moving to Wayland now and they will move back to somewhere else (X11, Windows) because of how awful the Wayland experience is on not-GNOME and not-KDE (and possibly soon not-COSMIC). You mentioned xdg_session_management specifically, but xdg-desktop-portal is a huge issue (along with things like Xwayland and Wine Wayland not being normalized yet) that is not going to be solved any time soon.
I actually transitioned my primary desktop back to Windows (after being on Linux for 5 years, my server still run NixOS) because I cannot stand the current Linux desktop landscape. It is a buggy mess and nobody involved wants to fix it. In the process I also learned that some of the problems I had with xdg-desktop-portal were also on Windows (HELLO Slack + Firefox being fundamentally broken) but not being able to copy from my desktop to paste in a game (something I do every day) as a "security mitigation" on "not KDE" is just not acceptable.
> how awful the Wayland experience* is on not-GNOME and not-KDE (and possibly soon not-COSMIC)
i would argue that most non-GNOME/KDE environments (which effectively means: wlroots) aren't awful, it's just that this is the way Wayland was designed. in my experience all of the limitations of wlroots/sway are intentional, and GNOME and KDE have to take shortcuts and get creative to provide an experience that is as close to X11 as possible.
but that's sort of the point, right? WL devs want to go a certain route but that doesn't always match up with what people want. It's been the biggest single complaint wrt Wayland for well over a decade now.
>*Edit: The initial impressions of Wayland are fantastic "wow look Hyprland is so nice!" but once you get into the nitty gritty and certain edge cases (xdg-desktop-portal, XWayland clipboard issues, lack of Wine Wayland being in any flavor of Proton that's not tkg) that's where people will get frustrated and give up.
1000% agree , but that mentality wount be liked around here
i have said similar stuff in the past mentioned that wayland isnt/wasnt ready and was basically told i was wrong
> but that mentality wont be liked around here
Oh trust me, I know and I don't let people put me down for having a more pragmatic approach to all of this. Software development is a process that can get stuck at 95% for years.
Would you like to elaborate on the topic? Not to be mean or anything, just curious. I've been using Hyprland as an evolution of my old i3 setup for 1/2 a year no, and outside of one hiccup that was my own fault (I was using experimental explicit-sync implementation, and forgot to switch back to main branch after it got merged with 555 drivers) it's been pretty much smooth sailing. Sure the streaming is frustrating cause it doesn't work with the Xorg apps (ergo, f.e. Discord client), but I can live with that, and where I can't I moved to different clients (like WebCord for Discord). Meanwhile I'm loving the portals in general.
So just curious, are there thing that I'm simply not seeing yet?
> streaming
No I use my PC for "real work" like sharing my screen during a Teams or Slack call. When my coworkers say "I can't see your screen, stop using Linux" yea. It's a problem.
> No I use my PC for "real work" like sharing my screen during a Teams or Slack call
Yeah, cause "streaming" definitely doesn't just mean "screen sharing". I'm studying and working part-time, I've used both Teams, Slack and Zoom, never had an issue with \*\*streaming\*\* video over either. Although I've never bothered with installing clients for them, and Firefox is Wayland native, so that might be the difference maker.
Just a side note: if I was a streamer I'd most likely use a secondary setup for the stream itself, too much of proprietary software to bother with setting it up fully on linux.
This is where I'm at. Official Teams client is obviously dead, the third-party "Teams for Linux" client had the screen share issue, but I found success switching over to just using it through Firefox. No issues whatsoever with that.
A friend reported they had no issues with Teams for Linux, but they were on AMD and I'm on Nvidia. No idea if that should make a difference, but Firefox worked for me either way.
I've given up on local clients and just have the brave-browser installed solely to run 1-2 teams tabs. Screen sharing and everything works, though the occasional hiccup is there which appears to be similar to everybody elses occasional teams hiccups.
My zoom will actually share, but when I stop sharing Zoom crashes so I end up having to relaunch and rejoin when I stop sharing. It's a bit of a flow kill.
I'm running Debian with OpenRC and X. I don't feel like I'm missing out on something. I can copy and paste at will, I even can take screenshots, or, in a time when Teams wasn't broken, I could even share my screen on Teams! Even if the release is called "unstable", this is the single most stable setup I've ever had, it does everything I want it to do, and I don't have a single reason to switch anything soon. Doesn't mean I'm not playing around with new trends, though.
This thread is about people living in the year 2020 and not the year 2005. I don't know why you have the obligation to brag about not using Wayland and not using Systemd - it looks like you simply want to act like an ostrich and take your head out of the ground whenever you want to be a contrarian.
Aren't these exactly the sorts of problems Valve is trying to fix by allowing themselves to move faster? If endless Wayland debate stops people from being able to actually ship workable solutions, then forking and moving faster is a totally reasonable response.
In fact, it's a core part of open source: if you don't like how it is, you can fork it and fix it for your use-case.
I think this is a Valve problem, because Valve requires things from Mesa and that is not a very tightly coupled pair of projects.
It's less of a problem if Mutter/GTK or Kwin/kdelibs have custom protocols, because they release in lockstep and can make sure their experimental protocols work with each other.
I agree, to me one of the problem of Wayland is that... there is no Wayland! Wayland is a protocol, unlike Xorg that was a display server. It means that there are in fact multiple Waylands, each one of them implementing things slightly differently.
For example, last week I wanted to automate switching on and off a monitor. Something that with X you could have done with a bash script invoking the xrandr program. Turns out, you can't in Wayland. Every compositor does it differently, on GNOME you have to write on D-bus a message to Mutter to change the display configuration. On KDE, probably another entirely different thing, and so on. It also means that there couldn't be a wrandr program, or well, there could but it must write specific integrations for each compositor that there is on the market.
To me Wayland just adds fragmentation. The concept of Wayland is cool, but I disagree with the fact that they merged the function of the display server and the window manager. Note that I don't disagree integrating the compositor inside the display server, but the fact that the window manager is also the display server is to me bad.
Why KDE shall have a different display server implementation than GNOME that is different than Xfce, when the basic function of the display server (that is, deciding how to draw windows on the screen) is the same? Each then window manager can be different, talking to the display server to position windows how he wants, implementing its own window decorations, etc. like in the X days.
There is too much fragmentation, too much compositors supporting a bunch of different extension protocols, and you as a software developer have to put a big effort to ensure your program works in every possibile configuration. Why? It was already complicated enough, why there is the need to have multiple display server implementations??
The could have made Wayland (the server, that also is the compositor) as a Xorg project successor, a single project, and everyone contributes to it, making it the perfect implementation, rather than have tens of competing implementations.
This is so bad.
I don't see another solution than keeping Xorg.
Maybe something better than Wayland will arises. Or Wayland stabilises and a unique set of protocols is adopted. I just hope Xfce will continue to work.
I believe that Wayland is a good thing (in fact, I use it) but we need a single "server" implementation, like in X. Also the fact that the window manager functionality is in the same executable to me is bad. In X the window manager is just any other program, if it crashes the system continues to work.
In Wayland the window manager is indeed the graphic server: for example in GNOME the "r" shell command, that used to work when you needed to restart the shell, doesn't work on Wayland, and it cannot work as now. This is bad, to the point that you need to logout and log back in just to test out a shell extension...
To quote an old expression..
"Shit or get off the pot"
It was always going to be the case, that if they moved too slow or just refused to do what everyone felt we needed for Wayland, that someone else would eventually get bored of waiting for the committee to get things done and would just do it without them.
If you want to keep everyone on side, and have everyone come with you on a journey like this, you gotta be highly responsive to feedback and willing to compromise and occasionally adopt imperfect solutions to get results in order to keep things moving forward at a pace that everyone is happy with. I don't think the committee realised that people were not going to wait decades for them to figure out and implement 'their perfect solution'.
Wasn't that like a teenager or something? I seem to remember the person who made the breakthrough interface for dx12 to Vulkan being like 17 at the time and how crazy it was.
No, it happened because of some pretty serious technical disagreements on the direction of the project.
vkd3d-proton aims to do whatever is necessary to run D3D12 games at the best possible performance and functionality, and because of that, the devs actively participate in the Vulkan spec to propose extensions that help them. It can run thousands of games and the devs make an effort to support new games as they are released.
vkd3d refuses to use any Vulkan extension (I don't fully understand why), and therefore struggles with an impedance mismatch between D3D12 and Vulkan without extensions. Last I checked, it only supported a few games and at a poor performance. It has no answer to any new D3D12 feature (such as mesh shaders and ray tracing).
It's a bit of both actually.
The main dev of vkd3d was Jozef Kucia. Guy was a complete legend afaik.
When he died, the development of vkd3d stalled to a glacial pace.
A year later, Valve decided to make their own version - vkd3d-proton.
The technical disagreements were like the poster above outlined.
The dev that was hired by Valve was a different guy - it was the maker of DXVK. Later on Valve went on to hire more people that worked on DXVK (among them, the person who put in the proposal for frog protocols).
The frog-protocols act as add ons to the existing Wayland protocols. They are not a replacement of Wayland in its entirety.
At most they will replace a few select Wayland protocols until there are usable official Wayland protocols available or until they become official Wayland protocols themselves.
This reminds me of when UC Berkeley developed their BSD extensions for Unix. BSD ended up becoming the de-facto standard. If the main devs won’t make progress, then somebody else will. History repeats itself.
It does often happen that what becomes popular becomes the "de facto" standard: it happened with popularity of Linux over traditional implementations. For example, new development follows closer to what Linux supports rather than what older standards support.
>It also happened when XFree86 development progressed faster than standard X11, but then things shifted back to X org implementation.
Shifted back? Pretty sure X.Org is only a thing because XFree86 was starting to die very quickly after its license fiasco. X.Org and XFree86 were only relevant at the same time for like 2 or 3 years.
They won’t replace Wayland protocols but will give us the extensions we desire much faster without depending on the Wayland devs to finish their “discussions”. At least in theory
but you dont "use" wayland protocols, they're implemented by compositors like mutter, kwin, wlroots etc; who are all invested in how things are done now, because it gives them a say in how the protocols are designed.
If we're not careful we will have 15 different compositors implementing 20 different versions of 30 different protocols and each application will require some of those and optionally support some others.
And then each of those implementations will have subtle bugs and then Qt 6.16 will be broken on Hyprland but work on Gnome while 6.17 works on Gnome but is broken on Hyprland and 6.18 works on both but is unberably slow on XFCE.
The worst relative thing X11 could have that you could call a "mess" is that some newer APIs had to be introduced to deal with older APIs not being as good as they used to but without removing the latter to preserve backwards compatibility (which is a good thing).
But in both cases this is solved by a document, wiki or whatever about best practices with info like "yes, you could use XYZ API/extensions/whatever but it really is only there to keep existing programs working and you should use ABC instead as that is better because of IJK".
I think the Year of the Linux Desktop will come before Wayland is ready. X11 is old but still works, Wayland is trying to replace it but failing constantly. Time for a 3rd option.
And when one day it’s finally complete, it will be outdated because technology moved forward. And a new system will start to be designed, and we’ll start it all over again.
Come to Linux, we’re almost done implementing features that everyone else implemented 12 years ago.
It is called defacto standard. If Valve makes useful extensions that everybody uses and sticks to, it doesn't matter if they are Wayland approved or not.
Valve could even fork Wayland and rapidly improve it and accept outside contributions without all the bikeshedding. Call it Flywheel. If everybody abandons Wayland for it, Flywheel will be the new standard.
There is no formal obligation to keep following Freedesktop for the display system. Any trustworthy project with favorable licensing for that will do.
Imagine you run a car company. You want to make some new cars, but they'll require a new faster engine. You go to the engine company and say "can you make this engine for us". They say "we'd love to, but we need a documented standard first so we can make sure all the hoses and stuff go in the right place".
You bring the proposal to the standards committee, and they say "sure, we'll come up with a good solution", and they take your proposal and hand it to an intern. You're somewhat suspicious about this, so you follow the intern. The internet walks down a dark hallway, opens a door to a giant drained indoor swimming pool *absolutely full* of proposals, and they throw it on top of the pile and close the door.
You decide to give them the benefit of the doubt, but a year later, the standards committee has done essentially no work - apparently they're bickering about what color Fuse #47 should be.
So you go to the standards committee again, and you say "here's a new proposal: let's make a standard category for Experimental Standards! It will be much more open and easy to get things in! Then we can just make our own engine layout and get a few custom engines fabricated to see if it works in our new car design! Yay!"
Unspoken, is "also, if you *don't* do this, we're going to do it ourselves without you, because we don't *technically* need your permission for this."
The pro is that this means Valve can iterate much faster, without everything needing to go through Wayland. The con is that Valve may end up changing its standards in backwards-incompatible ways and causing more work downstream. But a lot of people would rather have that than the status quo.
Wouldn't that then create a second pool full of other proposals? In the end, aren't all those standards( status quo ones and the experimental ones) gonna have to go through the standards committee to get approved anyway? What makes this committee approve these experimental standards over the other ones from the first pool?
> Wouldn't that then create a second pool full of other proposals?
The idea is that these proposals are less "make sure everyone is the building has signed off on it" and more "get two people to stamp it as 'yeah, sure'". A much lower bar of quality required.
And again, the implicit threat is that Valve is just going to do it without them otherwise. So if `frog-protocols` ends up being just as slow as everything else, Valve will just make `toad-protocols` and manage it themselves.
> In the end, aren't all those standards( status quo ones and the experimental ones) gonna have to go through the standards committee to get approved anyway?
*In the end*, yes - but nothing stops people from implementing protocols that aren't officially fully approved, and the intent is that these will get approved and then tentatively implemented by people trying to test things out on the not-quite-bleeding-edge.
Which also makes it easier to test and polish them for eventual final inclusion.
This is imo. the biggest downside with big FOSS projects is that they all at some point become complacent in their garden and hate any outsider proposing different solutions.
It's happen oh so many times and always becomes the case of that the project gets forked or they start over from scratch and then we see who is actually better.
The most well known example is definitely Mozilla doing the same crap towards Google which prompted Google to feel vindicated to create Chrome (since before they were a heavy contributor towards Firefox).
The only reason why say Linux has survive is just how big it is, but even there the whole Rust drama shows the absurdity of this mentality.
Wayland is a set of protocol definitions. These are implemented by a wayland compositor.
Valve have implemented GameScope
KDE's is called KWin
Gnome's is called Mutter
wlroots is a generic one designed to be used by others (e.g. sway)
Wayland itself has a reference compositor called 'weston'
Valve is suggesting extensions are taking years to upstream due to discussions and reviews Valve is just implementing proposals they need in Gamescope.
So to bring structure to it they will define them as frog protocols so others can see them and implement them. Frog Protocols will be iterative were ideas are deployed and tested and once happy they can be submitted to Wayland to become a real thing.
I suspect KWin and wlroots will pick up a lot of the frog protocols. KDE already has a merge request open to add support for the proposed one.
Basically "You are holding up Steam Deck/VR development, we are no longer asking politely." I suspect KDE/Cosmic will use the tweaks and it'll just become a "games run smoother on Valve hardware/KDE/Cosmic, why does other distros run slower?" issue.
Hug. Its almost like ive said Wayland is stupid due to how slow it seems to be integrated.
Love the concept. Never seen something that was supposed to have such a simplified workflow conversion take so long... Its been like 9 years.
Good on valve as usual for pushing Linux forward!
Wayland's management just does not work. If they don't change their ways or step down it'll never reach feature parity. It's been around for 16 years and it might take just as many more if they keep letting feature-complete requests sit for years (which is what pushed this action).
It has to have been very recently, I was in the gamescope repo within the last few weeks and the releases/commits were still from her old Joshua github handle.
This comment has been removed due to receiving too many reports from users. The mods have been notified and will re-approve if this removal was inappropriate, or leave it removed.
This is most likely because:
* Your post belongs in r/linuxquestions or r/linux4noobs
* Your post belongs in r/linuxmemes
* Your post is considered "fluff" - things like a Tux plushie or old Linux CDs are an example and, while they may be popular vote wise, they are not considered on topic
* Your post is otherwise deemed not appropriate for the subreddit
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/linux) if you have any questions or concerns.*
> Swapchain starvation caused by being required
to stall for the 'frame' event
I raised this years ago and it still wasn't taken care of. Not surprising Valve need to nudge.
I often set reminders with it. Like I'd run `sleep 1800 ; glxgears` for a 30 minute reminder, then minimize the terminal.
Except every once in a while I'd mess up and type glxinfo instead.
Based on https://www.gamingonlinux.com/2021/07/an-interview-with-joshua-ashton-developer-on-the-likes-of-dxvk-vkd3d-proton-and-more/, I suspect that Joshua Ashton works for Valve.
I’ve been trying to use wayland for the last year or so, ignoring all the missing functionality in the interests of progress.
I was busy doing something on a live USB environment which defaulted to Xorg without me realising it, and what a breath of fresh air it was. Select to copy - middle click paste is amazing. Not having focus stolen all the time is amazing. Even just small things like opening Firefox and having the url bar be in focus is great.
As a pure end user, wayland is awful. I’m sure it’s better in some other ways but for a pleb who doesn’t know what he’s talking about, Linux is *fun* with xorg, and it’s stuffy and businesslike with wayland.
Select to copy middle click paste works just fine in kde wayland as does opening firefox url bar is in focus, people harp on about needing a single implementation but then who would control this implementation what would they do if say gnome controlled it and wouldn't implement features people wanted? fork it? o no multiple implementations...
The title is editorialized, it's not really representative of the content. This is a single Wayland protocol (there are many protocols) to tackle a single use case: Native Wayland Vulkan FIFO (First In, First Out) AKA Vsync'ed presentation.
Thank God for Valve, Wayland has been conceptually fucked up for a very long time now. All that effort ex-Xorg developers did with throwing out the baby with the bathwater was terribly harmful to the GNU/Linux ecosystem and we are still paying the consequences of that.
I support Valve and anybody else who manages to ship excellent open source code onto my system.
Talking too much leads to burnout instead of shipping code. This is especially a problem for volunteers, but even for people paid to do it.
Should be interesting to see where this goes in a few years. Will we be stuck with compositors that have to implement eighteen different "leap protocols" like OpenGL extensions and X extensions and browser feature compatibility matricies, or will these actually stabilize out fast enough that application backward compatibility isn't a brutal nightmare inducing hellscape.
I wish them the absolute best of luck in not repeating past mistakes. All existing evidence says they're going to need it.
One advantage to the majority of games going through Proton is that you don't need to update a thousand games to deprecate an old API, you just need to update Proton.
I'm a decent programmer and specialize in automation, but I've never dipped my toes into open source. I'm hell-bent on destroying windows market share though and if someone could point me in the right direction I would love to try and dive into helping out how to help a project or two make progress on stuff like this.
I'm not saying the title is wrong, but it is awfully editorialized. The linked page isn't even [the announcement](https://github.com/misyltoad/frog-protocols), and neither place puts says something like what the title says.
its sad that most of you are sad.
Don't forget that this is also the power of oss; it gives everyone the ability to start a new idea, or fork something and try something.
Don't be sad, be happy that they try stuff to overcome troubles.
There are repos like that for [cosmic](https://github.com/pop-os/cosmic-protocols), [kde](https://github.com/KDE/plasma-wayland-protocols) and [wlroots](https://gitlab.freedesktop.org/wlroots/wlr-protocols) , so this is the same thing for gamescope? (valve wayland compositor)
Seems like how standards are suppose to be developed, have an implementation instead of thinking you can just think about everything upfront without doing "field tests".
sudo dnf install --refresh --advisory=FEDORA-2024-45c8df31f8 \*
update just showed that all packages are "already installed". As far as I understand, no one package uses this protocol
>System packages will be preferred over the wrap if available -- [Arch](https://archlinux.org/packages/extra/any/frog-protocols/), [Fedora 41](https://bodhi.fedoraproject.org/updates/FEDORA-2024-45c8df31f8), [Fedora 40](https://bodhi.fedoraproject.org/updates/FEDORA-2024-3d69c3ec44) currently have packaging for frog-protocols already.
This is a quote from the news. Nobody tried it and they are already downvoting and writing crap? What kind of Linux losers are these?
eh idk, its a neat idea but it remains to be seen if this is just going to end up as gamescopes own custom extensions that don't really get much support, not to mention that it seems to explicitly have a move fast and break things approach which feels like it has the potential to leave us with a lot of redundant/duplicate protocols.
Maybe I'm just alone in thinking that waylands protocol discussions are (at least for most protocols) fine, even if they sometimes drag on for stupid reasons.
If you read the MR you will see they want to adjust the build to allow people to include the frog protocol definitions (or not). KDE has already raised an MR to include them by default.
yes I know, I read it, thats why I said that it remains to be seen.
I know they haven't said "this is for gamescope only" and they'd be fine with other compositors implementing it.
>not to mention that it seems to explicitly have a move fast and break things approach
I get the concern, but Linux desktop does need this approach to reach feature parity with Windows. The sooner things break the sooner they are fixed as well, it's an incremental process with a net positive.
Windows is currently at its worst, very little appeal to the consumer side and to the smartphone addicted younger generation, hanging by enterprise lockdown and legacy support, if I had to bet, not even Microsoft wants to be dealing with Windows anymore and would jump ship to SaaS provider only, while Linux on the desktop is the best it has ever been, peaking for a couple years now, the improvement curve has gone fully exponential across the board, from hardware compatibility to desktop polish.
We live in the age of containers and immutable systems, just because upstream keeps developing at a fast pace, doesn't mean you as the user have to be an early adopter, at least not in critical machines.
347 Comments
murlakatamenka@reddit
Deathcrow@reddit
FengLengshun@reddit
Aeder@reddit
FengLengshun@reddit
3G6A5W338E@reddit
FengLengshun@reddit
Maneatsdog@reddit
zixaphir@reddit
JuJunker52@reddit
zixaphir@reddit
JuJunker52@reddit
zixaphir@reddit
JuJunker52@reddit
zixaphir@reddit
Repulsive-Street-307@reddit
FengLengshun@reddit
murlakatamenka@reddit
Imaginary-Problem914@reddit
hiimjosh0@reddit
Entropy_Bug@reddit
AutoModerator@reddit
nachog2003@reddit
jonkoops@reddit
Synthetic451@reddit
Richard_Masterson@reddit
ccoppa@reddit
jdog320@reddit
spezdrinkspiss@reddit
throwaway490215@reddit
Richard_Masterson@reddit
WallOfKudzu@reddit
Indolent_Bard@reddit
Richard_Masterson@reddit
Indolent_Bard@reddit
WallOfKudzu@reddit
thedward@reddit
Indolent_Bard@reddit
Standard-Potential-6@reddit
Esption@reddit
cloggedsink941@reddit
Esption@reddit
cloggedsink941@reddit
Esption@reddit
combinatorial_quest@reddit
gameoftomes@reddit
spezdrinkspiss@reddit
Business_Reindeer910@reddit
Richard_Masterson@reddit
rien333@reddit
Richard_Masterson@reddit
rien333@reddit
Richard_Masterson@reddit
rien333@reddit
Richard_Masterson@reddit
aphantombeing@reddit
Richard_Masterson@reddit
Business_Reindeer910@reddit
crshbndct@reddit
spezdrinkspiss@reddit
light_trick@reddit
noahdvs@reddit
MissionHairyPosition@reddit
ImYoric@reddit
Richard_Masterson@reddit
scorpio_pt@reddit
Tireseas@reddit
Business_Reindeer910@reddit
WallOfKudzu@reddit
Richard_Masterson@reddit
WallOfKudzu@reddit
Richard_Masterson@reddit
amds1001@reddit
FranticBronchitis@reddit
d_ed@reddit
flukus@reddit
ccoppa@reddit
bighi@reddit
glpm@reddit
gatornatortater@reddit
bighi@reddit
perkited@reddit
satissuperque@reddit
crshbndct@reddit
glpm@reddit
crshbndct@reddit
WretchedRefrigerator@reddit
WMan37@reddit
DYMAXIONman@reddit
WaitingForG2@reddit
grady_vuckovic@reddit
Traditional_Hat3506@reddit
the_j_tizzle@reddit
SwiftSpectralRabbit@reddit
badsectoracula@reddit
SwiftSpectralRabbit@reddit
badsectoracula@reddit
SwiftSpectralRabbit@reddit
badsectoracula@reddit
SwiftSpectralRabbit@reddit
badsectoracula@reddit
Minobull@reddit
damodread@reddit
PenCautious1312@reddit
CleoMenemezis@reddit
conan--aquilonian@reddit (OP)
CleoMenemezis@reddit
mrturret@reddit
ilikedeserts90@reddit
CleoMenemezis@reddit
DarkeoX@reddit
londons_explorer@reddit
mrturret@reddit
ProfessorFakas@reddit
Kos---Mos@reddit
Red_not_Read@reddit
FranticBronchitis@reddit
bighi@reddit
025a@reddit
Richard_Masterson@reddit
bighi@reddit
025a@reddit
torsten_dev@reddit
-not_a_knife@reddit
bighi@reddit
Saxasaurus@reddit
-not_a_knife@reddit
Saxasaurus@reddit
-not_a_knife@reddit
slndmn@reddit
ngoonee@reddit
s_and_s_lite_party@reddit
NatoBoram@reddit
StayingUp4AFeeling@reddit
NatoBoram@reddit
StayingUp4AFeeling@reddit
conan--aquilonian@reddit (OP)
StayingUp4AFeeling@reddit
conan--aquilonian@reddit (OP)
Yweain@reddit
ozzfranta@reddit
NatoBoram@reddit
macOSsequoia@reddit
xezrunner@reddit
Shap6@reddit
-not_a_knife@reddit
Recipe-Jaded@reddit
saucyeggnchee@reddit
d_ed@reddit
viliti@reddit
d_ed@reddit
Absolutebats@reddit
badsectoracula@reddit
Business_Reindeer910@reddit
METAAAAAAAAAAAAAAAAL@reddit
Business_Reindeer910@reddit
anotheruser323@reddit
viliti@reddit
Unboxious@reddit
crshbndct@reddit
Standard-Potential-6@reddit
FranticBronchitis@reddit
Minobull@reddit
conan--aquilonian@reddit (OP)
ImpossibleEdge4961@reddit
Imaginary-Problem914@reddit
viliti@reddit
Ezmiller_2@reddit
viliti@reddit
Ezmiller_2@reddit
viliti@reddit
Coffee_Ops@reddit
PenCautious1312@reddit
gurgelblaster@reddit
rileyrgham@reddit
FeepingCreature@reddit
rileyrgham@reddit
FeepingCreature@reddit
gubasx@reddit
JockstrapCummies@reddit
conan--aquilonian@reddit (OP)
starlevel01@reddit
viliti@reddit
MrHighStreetRoad@reddit
throwaway490215@reddit
79215185-1feb-44c6@reddit
FrostyDiscipline7558@reddit
JackDostoevsky@reddit
allocx@reddit
mrlinkwii@reddit
Business_Reindeer910@reddit
79215185-1feb-44c6@reddit
ModerNew@reddit
79215185-1feb-44c6@reddit
ModerNew@reddit
ProfessorFakas@reddit
Isofruit@reddit
79215185-1feb-44c6@reddit
Irverter@reddit
Flarebear_@reddit
79215185-1feb-44c6@reddit
nschubach@reddit
redd1ch@reddit
79215185-1feb-44c6@reddit
jmaargh@reddit
NightOfTheLivingHam@reddit
PacketAuditor@reddit
LvS@reddit
s_and_s_lite_party@reddit
Remarkable-NPC@reddit
s_and_s_lite_party@reddit
matt_eskes@reddit
DriNeo@reddit
alerighi@reddit
DriNeo@reddit
alerighi@reddit
bighi@reddit
awesumindustrys@reddit
JackDostoevsky@reddit
russianguy@reddit
grady_vuckovic@reddit
blenderbender44@reddit
InstanceTurbulent719@reddit
pipnina@reddit
DYMAXIONman@reddit
deanrihpee@reddit
mitchMurdra@reddit
Shished@reddit
TimurHu@reddit
QuaternionsRoll@reddit
DoctorJunglist@reddit
aekxzz@reddit
TimurHu@reddit
CNR_07@reddit
sqomoa@reddit
ilep@reddit
CNR_07@reddit
conan--aquilonian@reddit (OP)
Misicks0349@reddit
520throwaway@reddit
Misicks0349@reddit
traverseda@reddit
520throwaway@reddit
LvS@reddit
augustofretes@reddit
Imaginary-Problem914@reddit
oursland@reddit
LvS@reddit
draeath@reddit
badsectoracula@reddit
conan--aquilonian@reddit (OP)
Radium@reddit
PenCautious1312@reddit
ElMarkuz@reddit
CCJtheWolf@reddit
ElMarkuz@reddit
constancies@reddit
bighi@reddit
kalzEOS@reddit
ronaldtrip@reddit
ZorbaTHut@reddit
kalzEOS@reddit
ZorbaTHut@reddit
kalzEOS@reddit
Emotional_You_5269@reddit
blvsh@reddit
monkeynator@reddit
bradleypariah@reddit
bedz01@reddit
TiredPanda69@reddit
Jhakuzi@reddit
stevecrox0914@reddit
Jhakuzi@reddit
CorruptDropbear@reddit
KillerX629@reddit
Jhakuzi@reddit
Scout339v2@reddit
ThePineappleInPizza@reddit
Lord_Of_Millipedes@reddit
mitchMurdra@reddit
s_and_s_lite_party@reddit
FinnLiry@reddit
B_bI_L@reddit
CCJtheWolf@reddit
CecilXIII@reddit
like-my-comment@reddit
Minobull@reddit
Embarrassed_Oven_567@reddit
mitchMurdra@reddit
Daharka@reddit
CNR_07@reddit
MisterSheeple@reddit
CNR_07@reddit
Salander27@reddit
CNR_07@reddit
mitchMurdra@reddit
MisterSheeple@reddit
Shark_lifes_Dad@reddit
AutoModerator@reddit
CNR_07@reddit
CumCloggedArteries@reddit
MisterSheeple@reddit
HeavyMetalMachine@reddit
Daharka@reddit
m103@reddit
Daharka@reddit
GrandfatherTrout@reddit
mitchMurdra@reddit
DiscoMilk@reddit
c64z86@reddit
dtfinch@reddit
Richard_Masterson@reddit
daemonpenguin@reddit
lavacano@reddit
poyomannn@reddit
lavacano@reddit
HeadlessChild@reddit
conan--aquilonian@reddit (OP)
CondiMesmer@reddit
Jumper775-2@reddit
FryBoyter@reddit
crshbndct@reddit
HellToupee_nz@reddit
srini10000@reddit
sensitiveCube@reddit
nkamerad@reddit
pm_me_cool_soda@reddit
rebootyourbrainstem@reddit
YamiYukiSenpai@reddit
hackingdreams@reddit
GYN-k4H-Q3z-75B@reddit
ZorbaTHut@reddit
Atem18@reddit
urbrainonnuggs@reddit
visor841@reddit
sbkg0002@reddit
zlice0@reddit
wiki_me@reddit
Appropriate_Net_5393@reddit
ABotelho23@reddit
Appropriate_Net_5393@reddit
Pay08@reddit
nicman24@reddit
Misicks0349@reddit
stevecrox0914@reddit
Misicks0349@reddit
PenCautious1312@reddit