Why don't you propose a protocol to solve the issues you have? If it solves a problem other users have it would get adopted I'm sure (except maybe GNOME).
I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started.
And they are free to continue adding features and maintaining their preferred software choices. Nobody else seems to want to do it. IIRC the X11 maintainers are the same people who started Wayland.
> Once we are done with this we expect X.org to go into hard maintenance mode fairly quickly. The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is.
But we were talking about Wayland here. You're free of course to fantasize about hypothetical scenarios or propose features to software nobody wants to maintain.
One of the problems is that X is effectively being deprecated in favor of something that isn't X 2.0: it has different goals, different targets, different ideologies, and not to mention different architecture.
Eg Wayland is unashamedly Linux-centric (mind you, definitely not the same as Linux exclusive), while X most definitely isn't. One was designed to allow for remote rendering, one wasn't. One integrates the window manager functionality and one doesn't. The list of course goes on.
The things you list have not really been true in the real world for a long time. Modern Xorg uses the same Linux exclusive APIs as Wayland, is not network transparent, relies heavily on window manager and compositor features, etc. Modern Xorg and Wayland are more or less conceptually identical. Wayland just replaces the X server with a UNIX socket and has a clean slate for APIs.
2. Network transparency is still there and I use it everyday. The problem is toolkits (GTK and others) who decided it would be 'simpler' to redo everything themselves in a canvas. Of course the result of not taking advantages of X primitives was a massive slowdown over the network.
3. Wayland sits at an odd place, not having the advantages of being a proper protocol in the sense of X (complete abstraction from the substrate), while at the same time not having the advantages of being a direct API to hardware (simplicity, performance).
Or, in another words, Wayland is the same as the modern X, minus the legacy core that couldn't be removed from X because it is not extension (anyone using stippled unaliased lines yet?) and plus sandboxing.
Yeah, the end game for this seems pretty horrible. Wayland (still) doesn’t work, and is user-hostile (at least for this user). The BSD’s and most applications I use seem to be sticking with x.org.
Maybe this is the end of portable, open source video stacks.
I have found that “OK, why don’t you just do xyz if you think you’re so smart” shuts down interesting discussion, and that’s what you’ve been doing here. Would you be willing to not do that or explain why you think that isn’t the case here?
No, it does not shut down discussion, it shuts down bikeshedding. There's a large peanut gallery with strong opinions how they would do it, but because they never did something similar, they have no idea what they are talking about and what trade-offs are involved.
Unsurprisingly, people who know these things, for example because they develop it, may disagree with the peanut gallery and do it in a way they consider the best.
I would much rather hear a reason why something wouldn’t work than the responses saying “ok, how would you do it” and “ok, well someone would have done that if it was legitimate but they didn’t”.
It's not that simple; explaining one reason why something would not work means re-examing many of the underlying assumptions and not many like to go deeper than that one problem at hand in isolation. The "ok, how would you do it" forces thinking about underlying issues, because the solution you propose has to account for factors you otherwise wouldn't think of.
It is not a new problem either; this video is 9 years old already: https://www.youtube.com/watch?v=ZTdUmlGxVo0. It is almost one hour long, but well worth to watch to see the two different approaches to clash.
I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.
If you don't hate front-end period now, mobile's a hell of a lot easier and I think it still pays better than front-end webdev for some reason. As long as you stay away from the web-tech-on-mobile crap and write actual native code. It's especially easier if you specialize in one of the Big Two, but even working on both isn't that bad. I mean, it's not JS "culture" bad.
iOS is far and away the saner of the two if you wanna pick just one, plus it's an easy gateway to the whole Apple family of devices (watch, TV) including, soon, macOS itself. Android's broadly less pleasant and any devices outside phones that happen to be running it are likely to be batshit insane to work on, but it's still way better than the web, and a ton better than it was back in the 4.x days (let alone the 2.x/3.x split days—oof, it was hot garbage back then)
I don't quite understand this. Since 2013 React has remained a JS framework and introduced 1 new concept(hooks). iOS programming on the other hand(since 2013) has introduced a new language(Swift) and a new paradigm (Swift UI) for writing interfaces. All to target around 25% of the mobile market.
Yeah. It's so annoying how developers open source so much of their work. It's as if they just throw things up on the internet and expect people to use it only if it solves their specific problems. What they fail to consider is how inconvenient it is for their fellow developers who are dazzled by everything that hits front page of HN.
I just left frontend, and I’m the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it’s not for the better.
I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them more complex than they were before, which also happens constantly.
Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.
All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.
I'm aware of that - hence the form of my previous comment.
"This time it's different" though.
The difference being: this here is radically less complex and unlikely to become much more.
All this complexity in frameworks was always added in a vicious cycle, namely:
1. Developer looks at a component - they see complexity.
2. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.
3. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.
4. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.
5. The result is ever increasing complexity.
Enter Svelte(and similar technologies): it's not a framework, but a compiler - it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.
It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.
I don't think it's just because the devs get bored. It's because the users crack the shits if their specific use cases aren't handled, and when it comes to 'frameworks' nobody wants to switch or use anything that's not the most popular, so over time they just get more and more bloated trying to handle more use cases.
It's twice as bad if there's financial incentives for having a userbase (see all the tools not owned by FB/Google etc where the contributors sell training etc) because then it literally pays to add as much crap into your library as possible to try and get as many people using it as you can, regardless of the effect it has on quality. Even if something would make more sense as a fork or alternative, it's getting added in, whether it's good for the library and ecosystem or not.
And when they raise the price to 20x or start doing something shady you can just move everything to a cheaper and more ethical competitor. Except that you can't.
Honest question.
What's stopping Matrix from being adopted by, say, Google or Facebook, and then pulling a XMPPEEE?
Imagine Matrix gets really popular, more even than Discord. So they offer their own "version" but add features like free 250GB on Google Drive or things like that. After they get everybody on board they do what they do best and cease control of it.
We're obviously very aware of this risk, and one approach is to try (as the Foundation) to steer uptake as best we can to ensure that no single 800lb gorilla ends up adopting Matrix and smothering it with love(?), even if they have the best intentions. So if Google did suddenly start using Matrix, we'd do everything we possibly can to ensure that at least one of Microsoft/Facebook/Amazon/Apple/Samsung/etc jumped on board too, to try to balance things out and ensure that the value of participating in open network outweighed the risk of proprietary extensions leaking in.
But in the end, the onus is on us to make sure there's enough stuff of value in the wider open network that the idea of someone using the protocol to try to create a walled garden is laughable and clearly missing the point - much like running a private email network is somewhat missing the point, or for that matter a walled garden like the web content on old-school AOL.
Hopefully we're on the right track to ensure there's enough stuff of value on the public Matrix network to make participation in it a no-brainer.
Very interesting. I wonder if there's a killer feature that would appear when you follow that line of thought. So even if adoption looks like 60~70% users and 30~40% enterprise, if you're indispensable to either of them, it would still prevent a take over because of the network effect. And the fact that you have an API that developers can trust would solidify the position even more.
If that feature ever surfaces I hope it doesn't involve blockchain or machine learning.
Well, the feature might just be one of ubiquitous interoperability, much as email provides today. Particularly in an enterprise context: if you want to do some kind of realtime collaboration with someone, you might just reach them directly via Matrix rather than sending them an Email with a link to Slack/Zoom/whatever.
It'd certainly be more compelling if it was an actual feature though. Joking aside, federated machine learning could be an interesting approach, if the value that Matrix provided included a decentralised search engine which could help you sift through all the available content to find the chatrooms and communities you're interested in (and hide the ones you're not...)
XMPP was not really extended by Google in any way that mattered. Their federation hardly even worked even in the beginning.
XMPP has hardly been extinguished. There are something like 8 server implementations and zillions of client implementations. With OMEMO and Let's Encrypt it has has actually undergone a sort of resurgence lately. There are 100+ public XMPP servers out there. Matrix could only hope to be so extinguished...
So I am not really sure how you could EEE Matrix even if you wanted to do so for some reason. Something like this is hard to extinguish. If the network of servers was functional before it would still be functional after some entity pulled their server. Decentralization is sort of the point here.
My experience with Matrix compared to XMPP, is that Matrix is way ahead in usabiliy. I wanted to get people to use XMPP for years, but I always found too much lacking.
Matrix is not there yet, cross device signing has to land. But the way it is moving is way more promising than XMPP.
(I also remember that federating with Google was always painful)
> I am not really sure how you could EEE Matrix even if you wanted to do so for some reason. Something like this is hard to extinguish. If the network of servers was functional before it would still be functional after some entity pulled their server. Decentralization is sort of the point here.
Yes, though I would say that decentralised MXIDs (and generally being able to transfer users) is an incredibly important part of this. Otherwise users will have immense inertia stopping them from migrating from a big homeserver that is being used to EEE the system. Luckily that is something that's being worked on.
Matrix is an inherently decentralized system. You can run your own fully featured instance on your own property. If the company behind Matrix is acquired, the foundation being announced here today stands in the way of the intellectual property becoming a toxic liability to your own use. This is very good news today.
Furthermore, the openness of the protocol allows free software projects to emerge and exist independent of the matrix company and even the foundation. Such projects can be developed by your contributions and the FOSS community's support until the end of time. One of those projects, for example, is one I started [disclosure] called the Matrix Construct server: https://github.com/matrix-construct/construct and your support of this project is necessary to that end.
One problem I see with XMPP is that there is a lot on isolated use and not a lot of public use.
If a lot of companies would provide XMPP as a way to contact them, then what Google did would be as silly as taking email private.
Instead, most people are completely used to isolated messaging systems.
So I guss for Matrix, the challenge is to make sure that the dominant use of Matrix remains public. To some extent Matrix is ahead due to the bridging with large IRC networks.
But there are also quite a number of people trying to set up non-federated Matrix servers.
Matrix is not as popular as email, again, what prevents Google from taking Matrix and EEE'ing it to death?
As a concerete example; imagine next month Google announces their own Matrix instance. All gmail users are automatically signed in. The instance works with other Matrix instances. A year after that, Google stops federating anything but bare text to other servers, claiming protocol limitations. They continue to make interaction worse for non-google users until the non-google users have no choice but to join google or loose their social network.
What if google offers a better interface than most matrix instances? Given, Riot isn't exactly a high bar to meet so it should be possible with minimal resources.
Though XMPP had to deal with a number of paradigm shifts: images, markup, audio and video calls, persistant history, disconnected operation, security, threading, multi device operation. And I probably forgot a few.
Today messaging is much more established. So the matrix team has many more examples of features that are in common use and how other people designed user interfaces.
So it may be harder for Google to win through engineering. They may just break other matrix clients on android.
We should launch more alternative servers and avoid central big servers as much as possible. There's no reason to buy Matrix if they don't have a lot of users.
Honestly I think that we need implementations with smaller RAM requirements. Last time I've heard that it's recommended to have 2 GB RAM for Matrix. That's a lot. I can run VPN, SMTP, IMAP, HTTP, Tor servers along with operating system in a 256 MB VPS. I can imagine that a lot of folks are employing similar low-power VPS for personal needs. Now if they want to launch Matrix, they have to significantly upgrade their VPS. I see no reason why personal home server with few users should require more than a couple of megabytes. I hope that alternative implementations like Dendrite will be better in that aspect.
These "what if" questions will always be relevant because of the nature of big (and small) tech companies. Creating a monopoly, data mining, and controlling the flow of information are simply irresistible - if not necessary - for tech companies like Google or Facebook. The only real solution is to have educated users that care about their privacy and security. In that case, if Google turns a free, open source protocol into a surveillance machine, the only solution is to step away from it and not use it. We cannot stop big tech companies from creating user-friendly, tempting malware.
Recent new version of Google Mail flat out doesn't work to any usable standard in Firefox. Ten seconds to open a new 'compose mail' window. A context menu does a multi-second HTTP fetch before showing. The previous version worked great.
Either the dev team has just given up on quality or they're intentionally goading me into installing Chrome. I'm not going to play that game -- at this point Thunderbird works better.
Switching email providers is reasonably painless, fwiw. Set up forwarding, migrate mail when you can.
Even better if you set up the majority of your non-security-essential mail to be at your own domain, hosted by Fastmail/etc. Then you can easily change your email provider and your contacts don't even care. I've yet to implement this is in my own life, I just switched to fast mail - so I can't speak from personal experience on the domain portion of it.
NOTE: I mentioned non-security-essential email in reference to things like, your bank login or things that could threaten your life essentials. I say this because theoretically (and has happened before), using your own domain increases the attack surface area. My personal plan is to setup custom domain email with Fastmail, but still use the plain me@fastmail.com for my security focused emails. The majority of my email will still be based on my custom domain for easy portability, but I plan to avoid that for my bank, for example... assuming fast mail lets me.
I can speak from experience regarding FastMail because that's exactly what I did. In fact, I migrated off a grandfathered Google Apps account with my custom domain to FastMail with that same domain. Yeah, it's a bunch of steps, but I'm very comfortable with making DNS changes. My wife and I have an account; it's worth every penny.
Also, FastMail allows for subdomain handling. I use this feature with nearly every site. You can have *@<YourFastMailId>.<YourDomain>.com route to <YourFastMailId>@<YourDomain>.com just as you'd expect. The way this handling works is even configurable.
Another very happy user of FastMail here, with our own domain. I initially was excited by subdomain handling, but switched back to only using my main account.
Using FastMail-specific features will lock you into this specific vendor once again, one of the main reasons to switch in the first place!
To be fair, how FastMail does catch-all delivery like this is standard and easily reproduced st any mail vendor (except Office 365) that supports catch-all, which is most of them. I use a catch-all address with FastMail that is @asubdomainichose.mydomain.org and it is the same subdomain I used with my previous setup before moving to FastMail.
Using a subdomain for catch-all is great because spammers can’t easily discover and flood the subdomain.
I'm in the weird Google Apps for Your Domain limbo right now myself. I've wondered what would happen if I switched to something other than GMail but kept my google account with that email address.
I know a long time ago you could set up a Google account using a non-GMail email address but I'm not sure if that's even a thing anymore. That's what I want though. Keep the email address with my own domain that I've used for 17 years and just have a regular old Google account using that email (and keep all my Google services and purchases associated with it).
Google has been absolutely terrible to Google Apps for Your Domain users (who were often Google's biggest supporters back in the day). They've been shoved into this weird second class status where their Google accounts only partially work with Google services. I completely regret ever setting it up.
I use Google services heavily at work, all on a Google account that was created with my work email address. And we are not a Google shop; my employer's email is self-hosted Exchange.
You can continue using your email address for your Google account even if you've got someone else handling the mail now. You can also sign up for a Google account with an email account from any domain or provider.
I switched to Fastmail years ago and it was the best mail-related thing I ever did. I was dreading the migration but it literally took ten minutes, switch DNS records (I have my own domain), run Fastmail's import, done.
I still can't believe how fast the UI is. It's by far the fastest web app I've ever used, and the same goes for the service in general.
Seriously, just ditch Gmail now, the alternatives are great.
FastMail supports CalDAV. I use my FastMail calendar with Thunderbird (Lightning) and on my iPhone; works great. They also support CardDAV for contacts. /satisfied FM customer since ~2008 or so
Why is jjawssd's (sister) comment dead? Davdroid works great and is free (as in beer and speech), though I would encourage people to donate if it's useful to you.
I use Radicale and find it great, but there's no UI, so you need to use whatever client you want that supports CalDAV (I use Lightning and the calendar on my phone). Lately I've been liking Nextcloud a lot, and that's a one-stop solution for lots of things, so nowadays I would recommend that if you have a home server or want to pay someone to host it.
Yeah, you do. As I said above, Fastmail's calendar is very good too, and you can load your self-hosted/CalDAV calendars into it, so that's a good option.
FastMail is standards-based, so it does not support labels. This is a good thing, and you should stop depending on Google-specific proprietary features. Even when I was on Gmail, I had a lot of issues with labels because the third party mail clients I needed to use didn't support them. The inbox tabs I ended up replacing in Gmail with rules/filters, that moved my social updates, for instance, to an actual social folder which worked properly on third party clients.
That being said, FastMail is also the leading developer/champion of a new mail standard called JMAP, which supports both labels and folders. I suspect, therefore, if it takes off, they may consider supporting labels themselves.
I've recently switched to MacOS's built in mail client with IMAP to Gmail, never have to wait for my UI to do something. So count me in as surprised how far gmail has gone downhill.
That's the thing that gets me. So many optimisations have gone into user interface software over the years. And some of the stories of early Apple work, like 'round rects [0]' are truly inspirational.
I wrote software using Cocoa about a decade ago (so I may be out of touch), and it was clear how much thought and effort had gone into making the user interface responsive. And it generally shows.
The idea that you would just give up on that precedence is baffling. And let's face it, email's important but it's not rocket science.
What version of Firefox are you running? You are either exaggerating greatly or have other issues with your system. I run the latest stable release of Firefox and the performance of Gmail (particularly the features you mention) is fine. I’d be happy to upload a screen recording to verify.
If you experience a reproducible Firefox performance problem, please consider using the Firefox profiler add-on [1] to record a profile and file a bug with "[qf]" to the whiteboard field. These "[qf]" Firefox performance bugs get reviewed by engineers twice a week. Having a profile makes the bugs much easier to diagnose.
I think that Chrome also suffers on this front? But it's better at doing pre-fetching than Firefox is
This could really just be that part. I have a hard time imagining explicit sabotage of FF on the gmail frontend. The likeliest explanation is that perf testing and the like only happens in Chrome
It's tricky to share a screen recording because there's personal information. But I just did two for my own curiosity. From a fresh load, once the "Loading Gmail" screen has gone away, it took 8 seconds and 11 seconds respectively from clicking 'Compose' to having a new window open.
Maybe there is variability. There are a million combinations of factors out there. I suppose as an engineer you make the trade off of "do I hope for the best case" vs "do I make something that works for a broad audience". The previous version shows that they can make something that works for my own anecdatapoint if they want to.
I have a lot of issues with google apps for business.
Sometimes I have to refresh the browser 5-6 times before it will display any email in the primary inbox as well.
It's just horrible to use in firefox (in arch linux) and I'm currently looking for a new provider.
Protonmail is great but doesnt offer custom domains. If you need domains people mostly mention fastmail but i think there are far better choices like mailbox.org and kolabnow. Mailbox does not look like much from their homepage but it has awesome web client and it extremly reliable private provider thats in bussiness from 90s. I had account there for last 5 years without single problem.
I've experienced both very fast and very slow with the new Gmail on the same machine with Firefox on Linux. It's currently faster than Chromium, but maybe tomorrow I'll see ten-second load times. Who knows? For the record, I use uMatrix (and uBlock Origin on easy mode for client-side cleanup), which might be affecting it somewhat.
I’m a little surprised to read this because Google Mail works fine for me in Firefox (ArchLinux). In fact it’s smoother than some of the Electron-based clients I’ve tried and less painful than trying to get push messages on Thunderbird working (sure, there is always IMAP but that requires regular fetches).
FIY, IMAP actually allows "push messages" via the IDLE extension. If you use K9 on android, it's enabled by default. I never used gmail, but I'd be surprised if the gmail imap server didn't support it (and I would dismiss gmail entirely if it didn't).
Is this a new thing? I don't recall seeing an option for that in Thunderbird (desktop version by the way; not the mobile / Android version) the last time I looked (~9 months ago).
I don't use Thunderbird myself - was just following the discussion on from the OP who did use it. However I've yet to find a client I like so genuinely interested in any suggestions you might have.
I'm currently using mutt with "getmail" (which does support IDLE), which I can recommend -- it's an excellent client, but only if you're fine with tweaking.
I used TB until two years ago, but I gave up with it's unfixed bugs and quirks. I do prefer graphical clients, but not if they are clunky or buggy.
I used Silpheed and Claws for years, but Silpheed locks (or used to lock) the UI during fetch (unacceptable IMHO) while Claws has some critical bugs in the filter/rule logic that made me lose mail in several occasions by refiling into the wrong folder while processing a lot of messages. If you arent't a heavy filter user you might be fine with it though, I think Claws gets a lot of things right.
KMail wasn't bad when I used it, but it was too long ago to make an honest comment today.
Same issue here. Mails not loading, poor initial load time. That is with zero extensions enabled.
I am now using mutt/notmuch/mbsync to prevent having to go through their horrendously slow web interface, and eventually move away from Gmail completely (probably to ProtonMail or fastmail).
> A context menu does a multi-second HTTP fetch before showing.
Where? The only one I can trigger that does any kind of network is in the inbox, and that's only to get some icons. The text for the options is already loaded.
When we have time we'll have to trace through what it's doing and what components of RFP are causing the failure. (If anyone wants to do that and report in the bug, we (Mozilla/Tor) would much appreciate the contributions!)
Google has becoming increasingly annoying. Every time I browse from work, where I have to use Internet Explorer, I have to suffer Chrome ads. They also require me to solve a Captcha every time I change the number of results per page via the search settings.
In the past few months all our domestic devices have gradually hit that notional condition with Google Search. All the laptops one by one, and then last night my phone. My wife's phone is the only one that can still use their search without a ten-round Recaptcha challenge.
As each device was locked-out from Google I switched the default over to DDG.
What is especially interesting is that this will allow Google to track you on more pages, but that in this case, you can by definition not block the tracker. I've checked, but reCAPTCHA just falls under the general Google Terms of Service.
I don't believe this to be done with that goal, but it is an unfortunate side-effect.
ReCaptcha is like Cloudflare's free DDoS protection: we like to point at these services and complain how people are "ruining the web" by using them because that's what we do on HN. We ignore the big picture and whine.
But I encourage everyone to consider a darker reality: that centralized services by large companies are becoming more and more necessary in a world where it's becoming easier and easier to be an attacker. The internet is kinda broken. Like how half the ISPs in the world don't filter their egress for spoofed IPs because there's no real incentive. That every networked device in every household could unknowingly be part of a botnet because we aren't billed for externalities.
Yeah, maybe it's kinda spooky that now ReCaptcha v3 wants to be loaded on every page. But is that really the take-away? What about the fact that this is what's necessary to detect the next generation of attacker? That you can either use Google's omniscient neural-network to dynamically identify abuse or you can, what? Roll your own? What exactly is the alternative?
Do HNers think this stuff is a non-issue because nobody has every attacked their Jekyll blog hosted on Github Pages (btw, another free service by a large company)?
That is exactly what I was trying to say with the final line in my comment: I do believe that this is necessary; it's just unfortunate that it comes with the tracking side-effect.
So no: the take-away is that this improves reCAPTCHA. A side remark to that is that it also improves Google's ability to track you, and hampers your ability to fight that.
reCAPTCHA can go frick off into a hole. I've stopped using all websites that use reCaptcha because it takes me sometimes 10 minutes to login to them. I also don't feel right providing free data so Google can help a military drone bomb children on busses one day.
They are such a pain point. Especially if you fill out a form accidentally, and have to go through the re-captcha again, and again and again for the most mundane of services.
> UPDATE - 14 Sep 08:03: Blizzard is investigating and they will be looking to overturn the bans if this is indeed the case. There appears to be at least five reports of bans so far and does indeed seem that the most likely explanation is a false-positive from Blizzard's anti-cheat technology having issue with DXVK.
It's interesting because an emulation layer like that being present definitely would make cheating easier. I'd imagine a few clever modifications to DXVK itself would be all that's necessary to implement a wallhack or similar.
I am guessing that they look for cheating based on actions in addition to scanning the memory looking for known cheats. Aimbots are pretty recognizable to experienced players, and no doubt some machine learning is going on to look for those patterns. This lets them stay ahead of the curve on exploits... if it looks like an aimbot, it doesn't matter that it's some new binary they haven't yet heard of.
True, it's essentially an emulation not of the hardware but of the API. I was using it loosely, but the point is, hijacking Wine's already re-implemented API would be trivial given that limited verification are possible on it and hooking all critical Windows API functions is essentially trivial.
Not really a huge issue - professional cheat developers invest huge amounts of effort in subverting and patching the Windows kernel itself just to get a step ahead of anti-cheat. Thinking about how much fun that kind of thing is really makes me rethink my career choices...
I'm not a Wayland developer but it's what I observed in the issue tracker of my WM. A limitation is often overcome by a protocol and a basic implementation after. If you put the work in, the wlroots and KDE people are always very nice and will help you get started.
https://github.com/wayland-project/wayland-protocols/tree/ma...
https://github.com/wayland-project/wayland-protocols/tree/ma...
https://github.com/swaywm/wlr-protocols/tree/master/unstable