We thought your Rust.NET comment was somewhat in jest. No, Microsoft isn't porting Rust to .NET, they barely try to support anything other than C# on it nowadays, but the article mentions an internal adapter for MSVC codegen.
The project linked above has been posted to HN in the past a few times though.
They've mostly switched to vapes now. It's still annoying, but at least it doesn't leave trash all over the streets.
Seeing the sidewalks / parks outside of the main train station in Prague covered in cigarette butts as an American tourist in 2019 was certainly something.
They are banned in the UK since 2025. I still see vapes littered around in places but not sure if they are from before or technically non-disposable models that people have cast off regardless.
I smoked less in Prague than in the US. I was addicted to nicotine, sure, but I was also addicted to taking a little vacation outside whatever venue, and in Prague (in 2008) you could smoke just about anywhere.
I hate smoke but I wouldn't say vapes are any less bad. It's rare to get a face full of smoke, though, as smokers are generally considerate enough at this point, while vapers seemingly have no qualms with releasing huge clouds of sickly vapour right into crowds of people.
You can't be serious. If someone smokes indoors, you can smell it for hours or days afterward. All your clothes smell like it the next day. Nothing remotely like this happens with vapes. It's far less bad.
How many Americans do you think smoke? (Genuine question, I've never been to the States but did live in South America, and was absolutely shocked by how almost nobody smokes there.)
It has supposedly dropped to below 10% (but higher on average in rural areas than in cities, and of course that's just smoking, not the use of other nicotine products)
It is, but my argument is that better security is not needed! There is only one user. All apps are his/hers.
Linux security inside a user's session is bad in general. It all started in the '90s from the principle that all installed software is FOSS, sources inspected, and compiled distro packages trusted.
- Permissions are per-user, not per-app. If I ever need permissions to something, every app I run gets the same permissions.
- No isolation for personal files. Any app running as me can read all of them. Bookmarks, firefox passwords, everything.
- No per-app firewall mechanisms. Any app can call home and send user's files, including those passwords.
- System events are broadcasted via dbus to any app wanting to listen to them.
So why make the GUI secure if everything else isn't? If anyone wants to have better security (or privacy) in Linux, would have to start with the basic permissions model.
More importantly, adding more security has a real cost because either you just can't do some things or need to punch a bunch of custom-built holes in your security. If you can avoid paying that cost by having only trusted software why wouldn't you.
It’s not about multi-user security. I would not like a compromised video player to be able to see my Signal chats just because both apps are in the same window system.
Does Signal save history? Or does it save your encryption keys in a file? If it does, then a compromized program can just read those files directly. No need for X, no need for a GUI, a simple console app can do it.
More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory, etc. and impersonate you. Also without X.
> Does Signal save history? Or does it save your encryption keys in a file?
Even on Signal Desktop, retrieving things from an outside app is very-hard-to-impossible depending on configuration and what you're after.
There's a reason most Signal bots (even benign ones) hook up an event stream to a specially configured Signal daemon and build an external record of data from Signal by watching for events over time.
> More, a compromized app can execute Signal itself, attach a debugger to it, fake inputs, read outputs, read it's memory...
I think you're missing a lot of the attack surface here. "Local execution is game over" is a technically-true-but-incomplete thought-terminating statement; it's more useful to assess "if I grant local execution, what attackers are likely to be interested in that, and what attacks are they likely to perform?"
Like sure, if you install something containing a full userland rootkit designed to attack a given application, and that application isn't running in a container such that you have to pivot through root to access it, you're screwed.
Those do exist, but there are a ton of local attack vectors that aren't that. Many pieces of malicious code that install with local apps aren't that complex, since complexity begets size and suspicious-behavior detection. Less complex malware would prefer to e.g. read Firefox's sqlite database files rather than try to execute new instances of trusted programs like Signal to get data out of them. We know from analysis of a lot of malware that it overwhelmingly prefers low-hanging fruit that's easy to harvest quickly and without doing much that risks detection. Some malware's scarier, but like Mickens said, most people a) aren't gonna get Mossad'd on, and b) can't do much about it if they are: https://www.usenix.org/system/files/1401_08-12_mickens.pdf
There are also local attack vectors that don't involve installing malware directly. Local programs that run code (browsers) and plenty of other exploits in e.g. decoders are limited enough in what's possible within the exploit chain that they can't calc.exe you and instead rely on info harvesting from speculative execution
Flatpak/Snap/etc., also can assist with a layer of local-app security here.
Put all that together, and you end up at the conclusion that a large volume of data is only practically accessible to a lot of malware by accessing another running app's memory. Two significant ways to do that are 1) reading memory directly (significantly mitigated by hardware permissioning/segmentation/ASLR) and 2) reading data those apps publish to the display system. Wayland makes that second one a lot harder.
Yet Qubes OS demostrates it's possible to run X11 programs isolated from each other. They had the need and will to improve security, and found the way over a decade ago.
Making server side decorations an important part of it. Oh, the irony.
Qubes OS achieves isolation by separating apps into VMs. Wayland does this at the display protocol level. If Qubes OS is serious about security, they should consider Wayland with containerization. It would result in a similar level of isolation with significantly lower resource overhead.
I feel like the sheer volume of OS LPEs and escape CVEs in container runtimes indicates that, at least for now, the security boundary capabilities of containers are inferior to those of VMs.
Which is ironic, given that a lot of the tools that underly a container runtime were originally designed to facilitate security, not ease of deployment.
You're aware of the VM escape issues over the past decade? There's no perfect, and high overhead from running many guests can also create security risks. Wayland with all of its problems remains a logical step forward from the X model.
It's better than the security of pretty much anything physical in your home. Somehow you seem to be OK with your stove letting anyone turn it on and have other solutions to deal with misuse. The same solutions apply to your virtual desktop.
IMO the issue is that the same group stewarding Wayland was also xorg, and intentionally stifled improvement on xorg even when the work just a matter of merging the PR.
Merging a PR by drive-by contributors is far from trivial. As the maintainer, you become responsible for the other person's code for all eternity; it's on you to read it, understand it, update it when stuff around it changes, and fix it when it breaks.
Not a problem for obviously-correct changes of a couple of lines, but most PRs aren't like that.
I understand and that's a fair point. I should have phrased that differently, in that the PRs for features were waiting to be merged. I'm sure merging into a codebase as... storied? as xorg is no small task.
Open source developers are not required to spend their time prioritizing your priorities. You just have to look to Xlibre to see that a lot of contributions are quite bad quality, and in a C codebase of Xorg's complexity and security profile it's not a small job to review things.
Nothing I said in any way implied that freedesktop should be required to do anything. I can't speak to the quality of xlibre merges, only that if whatever is going on over there led to improvements in xorg after a drought, that's a good thing.
If wayland had been sold as a hardened display for those who needed that level of security, I would not have a problem with it.
As it is, the community got constantly browbeat with 'this is the future' and 'it's so much faster!' when recent benchmarks have proven that to be false.
Then go use X. Nobody's stopping you, you can just ignore any brow beating. /ignore is a useful IRC command.
You'll probably find it to be a not great experience, since almost all the people who spend their time actually working on graphics and GUIs in the Linux world prefer to work on Wayland. So X doesn't get much love these days (and you're not entitled to their efforts after all). But it's not like they erased all the old X code from existence.
You may notice issues with some GPU drivers if you have hardware with new drivers, because older GPU drivers contain X-specific workarounds which new drivers may lack (I know this is an issue with the Apple M1 GPU, I suspect it might be an issue with Panthor as well). But that's not really relevant with typical consumer hardware.
Desktop environments have varying levels of X support these days. GNOME hasn't been adding new features to X for a while, and GNOME 50 completely drops X. So if you're a GNOME fan you may not like that. KDE ends X11 support in 6.8. But it's always possible to stay on GNOME 49 or KDE Plasma 6.7 forever, or use an X11 window manager.
The X11 back-end is deprecated in GTK 4, so don't expect a ton of improvements to it, but it'll remain supported for all of GTK 4's life so you probably won't notice anything there immediately. But it means GTK 5 will drop the X11 back-end entirely, so at some point in the coming decade, GTK applications will gradually stop working.
Regardless of GUI toolkit, applications are slowly moving towards the XDG Portal way of doing things instead of the X11 way; which is fine, there's no reason why X systems can't support the portal dbus APIs, but I suspect that there will be more issues there once applications start dropping their X11 implementations of things. This is an area under active development and I would expect X11 to not see much of that development. I have no idea if anyone has implemented a portal for X11. Maybe you'd have to do that yourself eventually to keep new versions of certain programs running, I don't know how the state of portals is on X.
There are other things too that software can do to break X11 support even when their toolkit supports X, and expect that this has started happening to some degree and will slowly continue.
Xorg isn't neglected for "ideological reasons", it's neglected because development is work - and most of the people with knowledge of the problem domain decided they didn't want to work on Xorg anymore, and most of the companies that were paying for it decided they didn't want to pay for it anymore (apart from baseline maintenance, Xwayland and security fixes). And the people who want Xorg support maintained in perpetuity rarely seem interested in maintaining Xorg themselves, at least not properly (see this history of Xlibre introducing bugs and LLM slop).
You are free to spend your own time and resources doing the work, but you don't get to dictate how other people spend theirs.
Modesetting work was done in 2022, but for some reason no one had released a new stable release of the Xserver with this patch included since then. This was one of the reasons Xlibre was created, there was all these improvements to Xorg sitting ready for release but never being released.
Exactly. Just think about how much work it was to move from X to Wayland, how Nvidia didn't want to play ball, how different the architectures are, in a world where ossification is very much a thing. AND STILL there was enough momentum to get all the major players on board. I have never done any X programming but it must have been bad when people would so readily jump ship and put all that work in. Same for systemd.
Wayland was simpler because it was just a compositor. It meant people interested in graphics acceleration could focus on just that, iterating faster without the friction of the rest of the stack. But now that the Wayland ecosystem has to reinvent everything else, it's clearly at least as much work, if not more so. The initial switch moved the tightly knit rendering developers to a better local optimum, at the expense of a worse global optimum.
It forces some kind of modularity. Maybe that is a good thing. We don't have all features of X11 in Wayland but we also have features in Wayland that are missing in X11. I have been on Wayland for a while now and I can't say I am really suffering. There are some tings I'd like improved further but the protocol is evolving all the time. I think we'll get there. Also the decision is already made by the big distros anyways. They seem to be mostly happy.
Wayland is the complete opposite of modular; that's why the compositor has to handle everything. The claimed problem with X11 was it was too modular, easy for different clients to control various aspects of the environment, but perhaps too easy, lacking a security policy framework to limit client access. (Or at least a framework that was fully baked. Wayland put an end to such initiatives.)
The lack of modularity in Wayland has been widening the rift between the desktop environments. It's as-if KDE and GNOME each forked X11 and went their own ways.
Not true. Wayland simply cuts out the middleman. Making the compositor the display server is one of the best things Wayland did. This brings so many advantages, such as true tear-free graphics and lower input latency.
The middle man was there to make sure everyone understood each other. Now simple things like taking a screenshot requires programs to speak multiple different languages.
Again, not true: if you want to take a screenshot in a generic way, you have to go through the XDG portal API, which is generic across all the compositors that support them, i.e. most of them.
The XDG Portal framework is obscenely complex (PipeWire, D-BUS over separate channels, etc), still requires each individual compositor and other components to specifically implement various aspects for things like screen sharing, and there's a ton of broken edges between the myriad interacting components. All-in-all the complete opposite of modular.
And that's the point. X11 provided a framework for all of this. Not perfect, but deliberately extensible. The Wayland alternatives are so much more complicated and brittle, and have to work around the limitations of Wayland. The effort expended by groups like freedesktop.org to architect and standardize new features would have been (and was) so much more productive in the X11 world.
I understand where you're coming from, but there is no turning back at this point. Sure, you could still run dwm on Xorg or Xlibre and pretend Wayland doesn't exist, but the reality is that the vast majority of Linux distributions and desktop environments have already committed to this stack, and application developers are going to target these portals.
There's also talk of D-Bus eventually being replaced with Varlink [0], showing that this whole ecosystem is still very much a moving target. What feels like endless breakage and friction right now is really just the noise of a massive architectural migration in progress. Eventually, the dust will settle, the APIs will stabilize, and the whole stack will become boring, reliable, and really good. That is how I prefer to look at it.
If you want to see things move in a specific direction or address any particular problem, the best path forward is to get involved and participate in the projects that interest you.
> This brings so many advantages, such as true tear-free graphics and lower input latency.
Curiously, people always seem to list the same advantages, and it's a very short list. Fewer (but still non-zero) torn frames are the top of the list pretty much every time, since that was the very first thing its creator listed in his original goals... but that's a pretty small benefit in exchange for breaking entire categories of functionality. Like, it looks smoother when I scroll, but features I rely on heavily every day are forbidden.
As for input latency... that doesn't seem like it was ever a problem. Using X11, I'm able to get 500 to 1000 inputs per second even on a potato PC. That's faster than the frame rate of pretty much any screen, and fast enough even for audio / midi purposes. Reducing input latency from ~1.5ms to ~1.0ms doesn't really matter when the timeslice scheduling has ~6ms of jitter on an average system, a common screen only draws a frame every ~16ms, and many input devices have 50+ ms of their own additional latency.
> if you want to take a screenshot in a generic way, you have to go through the XDG portal API
This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots. Like many things users need, they decided it was someone else's problem, and threw it over the fence for the fragmented ecosystem of downstream projects to solve. So each downstream project came up with their own workarounds for essential features not existing. The solutions had to be built entirely outside of Wayland, and even after years of development, the solutions are still incomplete, unreliable, complex, and full of caveats. It required (and still requires) everyone except Wayland's core devs to write a lot more code for less functionality than they used to get with a couple of simple API calls. They had to architect entire complex infrastructure layers in order to work around a missing feature in the core protocol, since the core devs stubbornly refused to allow it.
Similar situation for input automation and remote control. It's a common thing people need. I use it every day and can't use the notebook at my desk without it... but the Wayland folks refused to solve it, so it had to be done outside of Wayland. For example, one workaround is to give the user direct access to the kernel so they can create fake input devices at a kernel level, and generate the inputs they need, which Wayland then sees as a local physical keyboard or mouse. So... problem solved, from Wayland's point of view. The user gets what they need, sort of, and it's implemented outside of Wayland, so Wayland doesn't have any security issues. But... and this is a big "but"... the solution involves giving users device-level kernel access. Which seems significantly worse than the issue it was originally trying to solve.
> I understand where you're coming from, but there is no turning back at this point.
A position of "sure it has major problems, but it's too late now" is not a position of progress. Much like the situation with pulseaudio being deployed everywhere then replaced with pipewire, it's almost never too late to fix bad software architecture. As you said, this whole ecosystem is still very much a moving target.
The ideal solution would be the creation of a new system which supports the features, protocols, and APIs of the older system(s), in a way which "just works". But that requires a very different mindset from the people behind it. Instead of "not my problem, someone else can deal with it" like the Wayland policy, a proper solution needs people to adopt a "the buck stops here" approach, and take responsibility for making the entire system work. Things like accessibility, network transparency, automation, and legacy support... need to be built in from the ground up, not rejected or treated as an afterthought for someone else to handle.
> Curiously, people always seem to list the same advantages, and it's a very short list.
The things I listed are just the tip of the iceberg. Having studied earlier versions of X like X10, X11, and now Wayland, I could go on and on. What I'm trying to emphasize here is not to look at Wayland through an Xorg lens. I know it's easy to look at Wayland and immediately think it's a rigid protocol that breaks everything, but the reality is that it's a lot more flexible than people realize. Once you understand it, I think the closest thing that comes to mind is "There is no spoon." And just like there is no spoon, there are also no windows, only surfaces, but again, that's only the tip of the iceberg.
If you want an example of what I'm talking about, take a look at projects like p9wl. [0] This is using wlroots to create a proxy between Linux and Plan 9 in order to display windows remotely. Such flexibility is only possible when the protocols are small and composable, which Wayland is.
> As for input latency... that doesn't seem like it was ever a problem.
I never said it's impossible to get acceptable input latency on Xorg. I'm just saying that when your input and graphics go directly through your compositor, the experience is on a completely different level. This is even more true with features like direct scanout, where the compositor steps aside to send graphics directly to the GPU and input directly to the game as it goes fullscreen. It simply makes using your computer so much more pleasant. These input latency issues were exactly what Kristian Høgsberg tried to fix in Xorg, and addressing them was one of the primary motivations behind creating Wayland. [1]
> This is a symptom of what's wrong with Wayland. Wayland doesn't do screenshots.
You're thinking through your Xorg lens again. That's understandable, since you're probably used to it. However, to really understand Wayland, you have to look at it through a different lens. Wayland isn't defective, and it's not trying to be Xorg 2. It's a protocol. It doesn't do your laundry, nor does it take screenshots. It's just there to provide the mechanism for sending buffers to your compositor.
You can think of Wayland as thin building blocks to build compositors, just as you can build window managers on X, except this time, the core protocol does one thing and the libraries already exist. Wayland exists because all the infrastructure is already there in the kernel and in libraries.
The screenshot feature is the job of the compositor. Most compositors already have this feature built in. As I mentioned before, XDG portals exist, and interoperability will only keep getting better.
> Similar situation for input automation and remote control.
I agree input automation and remote desktop are still problematic. GNOME and KDE have their own remote desktop solutions, as do most of the others, but I haven't had a need to use them myself. All in all, Wayland really isn't trying to prevent you from doing things, it's just a protocol.
I'm pretty sure all this will be solved eventually, and I understand the frustration of those who need these features. However, I also understand Wayland and compositor developers taking a careful approach here, and it shows.
> A position of "sure it has major problems, but it's too late now" is not a position of progress.
That's not what I intended to say. The intended message was: the core Wayland protocol is set in stone and won't change, but we can build these things that aren't working and make them work. That is already happening every day. Progress has been steady, it's a lot better than it used to be, and it will only keep getting better. Going from Wayland into a whole different windowing system, I don't see that happening, at least not in the next 60+ years, but I definitely see the whole Wayland ecosystem improving.
So I keep hearing. But hardly anyone ever talks about what's underneath the tip... and when they do, it turns out to be a big mess under there, not a mountain of advantages.
> just like there is no spoon, there are also no windows, only surfaces
Yes, I understand. That's why programs can't position their own windows, or get or set the mouse position. It doesn't even assume the coordinates are 2-dimensional. It's all very futuristic and makes a lot of interesting things possible, like using Minecraft as a compositor, or a Facebook style Metaverse compositor. But you're not hearing what I'm saying:
Wayland is solving the wrong problems. What it can do is pretty neat, but what it does is not what people need. It's good at party tricks, but bad at solving the real needs of daily life. It largely solves problems that nobody had, and to do this, it breaks major features people need. Much like how Facebook's Metaverse failed, nobody really wants to do their spreadsheets in Minecraft.
> It doesn't do your laundry
Yeah, and that's part of the problem. To use your analogy, it's like removing someone's washer and dryer, and replacing them with a box of tools which don't do laundry. It may be a really fancy foundation for building efficient laundry appliances, but that's not what people need. People may have used it to build an entire ecosystem of laundry appliances, but they couldn't agree on basic things so the ecosystem became fragmented, such that P-brand soap doesn't work in Q-brand washers, and clothes washed in Q-brand washers can't be dried in R-brand dryers, and if you use a P-brand washer you need to take fifteen extra steps to prepare it for a drying cycle, and T-brand dryers can only be used for pants, and ... etc etc. It's a big complex mess which, after 18 years of development, still doesn't let me get my socks clean. And most of it doesn't work at all for people who use a wheelchair.
> when your input and graphics go directly through your compositor ... input directly to the game
When they cut out the middleware, the middleware stops working. And when they make it impossible to add middleware, it stops being possible to do all sorts of useful things. Sure, it may be a millisecond faster, but in exchange, all my keys get mapped wrong, or I can't use my notebook without physically touching it (and causing repetitive strain injury), or my autoclicker stops working, or my accessibility tools become impossible to fix, or my automatic time tracker is treated as a security violation, or the solution which works for me suddenly won't work for my friend who uses a different compositor, or ... etc etc etc.
It architecturally eliminates entire categories of useful things... in order to make the simplest case slightly faster. This provides a more pleasant experience for average able-bodied normal people with no uncommon needs or preferences, while making things worse for everyone else. In particular, the complete lack of accessibility in Wayland is very able-ist and makes it unusuable for anyone with disabilities. That sort of thing needs to be built deep into the core, but it was instead rejected outright and left as an afterthought exercise for Someone Else to solve.
> [this] feature is the job of the compositor. Most compositors already have this feature ... GNOME and KDE have their own solutions, as do most of the others
This really gets at the nature of Wayland's biggest problem. A ton of important things are rejected and declared to be Someone Else's Problem. The compositors have attempted to deal with the aftermath of this mistake, but they all do their own thing and refuse to agree on a lot, so instead of one robust solution, we end up with an entire fragmented ecosystem of partial solutions which aren't compatible with each other.
It's even more of a nightmare for application developers. Instead of needing to support Windows, MacOS, and X11, suddenly they need to support Windows, MacOS, X11, GNOME, KDE, Sway, Weston, Hyprland, Enlightenment, Niri, etc. Every time two compositors disagree on something, it means every application must add support for both of the ways of doing it, like how they are now required to optionally draw their own title bar and window frame, depending on which compositor the user has... and good luck getting two programs from two different developers to draw their frames in the same visual style.
> Wayland really isn't trying to prevent you from doing things
I agree with your pain points. But the reality is that GNOME is already Wayland-only, KDE will be dropping the X11 session in 6.8, and GTK has deprecated X11 support, so going back isn't realistic.
> so the ecosystem became fragmented
The current fragmentation is frustrating, but Linux and Unix have gone through this exact phase before. Unix and especially Linux have never been static, they are more like living organisms. Back in the late '80s and early '90s, PC Unix suffered from the same growing pains. Multiple commercial and open-source X servers popped up for different hardware, until things eventually settled around X386 and XFree86. Even X developers in 1987 were saying "old window systems don't die" [0], sounds familiar?
We'll likely see compositors come and go, along with new protocols to address today's pain points. But the core protocol is here to stay, and wider adoption will naturally push the ecosystem toward shared solutions, just like we're seeing with River and wlroots. The fragmentation will fade over time.
In the meantime, anyone who still relies on X11 can simply stay on it until Wayland covers their use cases. Standalone X11 window managers aren't going away anytime soon.
Rather than dwelling on the friction, it's probably best to focus on what you can control: test software, file good bug reports, and help resolve the remaining edge cases.
I sympathize with the headache, but many Wayland developers came straight from X.org and know what they're doing. It's an uncomfortable adjustment period, but we'll get through it.
I don't care about either X, but that guy's name is in this release, and judging purely by the number of commits (since I lack X expertise to judge any other way), he seems to be the top contributor.
Looks like there's no way you can avoid "conspiracy theorists" if you want to use X, including Xwayland, eh?
Metux (Enrico Weigelt) was banned from the Xorg project because his patches kept breaking things, often in ways which demonstrated he didn't even do the bare minimum before pushing commits. Like, adding code which didn't even compile. It's fascinating to look through the huge pile of commits they had to revert after banning him, to see how bad a lot of it is. I picked a few at random, and ... wow.
So he started his own fork.
The ban didn't seem to have any relation to politics or personal behavior. However, he was widely known for being ... how to put it in a way which is acceptable here ... uh, difficult to deal with. Like, after Linus Torvalds made a vow to be nicer, he made an exception just one time... for metux. He was the only person obnoxious enough to get Linus to break his vow. Which, if I recall correctly, was how he ended up focusing on the Xorg project. After getting booted from Linux, he picked a different project.
That's who is in charge of XLibre.
Things didn't get political until he announced the fork. Because, although politics had nothing to do with him getting banned (either time), he framed it as if he was being targeted for political reasons, and used inflammatory political language in the project's documentation. This gained a lot of attention and caused a lot of controversy, and also had the effect of ensuring the contributors all had mostly the same political views.
Anyway, the number of commits doesn't tell much of the story. The content of the commits (especially the reverted ones at Xorg) are far more enlightening.
Wayland is not a "display server", it's a display protocol.
A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I find it quite funny that many of the same people that rag on systemd and say it does too many things, are big fans of Xorg doing a bunch of things that "display server" probably should not be handling.
Even if Wayland was a "display server", it would still "remove existing functionality" if it meant that in any principled sense, because "display server" is only half of what Xorg does.
But sure, the transition was difficult and took a long time.
>Wayland is not a "display server", it's a display protocol.
I, as an end user, do NOT care.
>A lot of the "existing functionality" that it broke has nothing to do with displays, it's stuff that got crammed into Xorg at some point whether it made sense or not.
I also don't care about ivory tower ideals of what is within the dominion of 'display' and what is not. The fact of the matter is their changes broke a ton of functionality, and instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
I have no idea why the community didn't take one look at their proposal and flatly ignore them.
> instead of even trying to provide feature parity, they basically dumped all that responsibility onto the WM/DE devs.
In other words, the Wayland people should perhaps have defined official protocol extensions early on to cover most of what X did, thus preventing all the initial interop issues when Gnome and KDE and Sway tried to reinvent them independently.
In hindsight, it's my opinion that wayland, if it had to exist at all, should have been implemented like this:
1. Add GBM to graphics drivers and start working it up the stack from the bottom, stopping at Xorg. That is, make rootful XWayland the standard Xorg before standalone even is a thing. This reduces maintenance work up front rather than belatedly.
2.a. Implement weston as a standalone compositor.
2.b. Actually make weston fully functional. Figure out everything needed to provide an actual working desktop environment with the features that users expect out of the box. Standardize all the protocols needed for at least a basic XFCE-ish environment rather than hoping someone else will do it.
3. Then, only after these things are done and working, announce to the world that wayland, a quiet project that has until now explicitly suggested nobody use it, is now the future of linux graphical systems and everyone should plan to migrate.
This pretty much. Xorg got almost everything that I care about to have a functionning GUI. You only startx and the only thing you may need are utils programs like a wm, a compositor, a bar… now you have conflicting implementation from gnome, kde, wlroots,… each with its own set of features.
Yeah, instead of the wayland folks leading the effort to fix issues, it's often some individual DE / WM going off, fixing it the way they prefer, and wayland grudgingly adopting it as official because they know the ecosystem is fragmenting bad enough as it is.
The community doesn't really have a say because Xorg is effectively on life support and the Xorg devs are now working on Wayland. There aren't many people in this world who could keep Xorg going. Some distros are sticking to Xorg, but it will become more and more difficult in the coming years.
Not in the short-term, for sure, and probably not even in the mid-term. But hardware keeps changing, and at some point nobody will care enough (or be able) to implement proper support for it in X (or proper support of X in that hardware). Hopefully we still have at least a decade of X though.
And this transition is nowhere near done. Just look at Kicad and pretty much any DAW that loads audio plugins (to name two major usecases where Wayland simply doesn't cut it).
Sure Xwayland exists and mostly (not entirely) works, but that's a band-aid for what is essentially a "we broke it and don't care" approach.
The daw problem is really really bad too. We've got a de facto standard forming right now where you link libwayland.so and hope the structs never ever ever change in the next 30 years.
It may be reasonable when you emulate a completely different platform but not when your are providing a compatibility feature in a supposed successor platform that can be designed to support that use case.
I can't find the benchmarks now, but the ones I recently saw on hacker news, xwayland was notably worse than either wayland native or xorg native. Bad enough to be noticeable by the average user.
It does not matter, X11 is also not a display server it is a protocol. That distinction changes nothing.
For what it's worth Xorg is the display server, before that it was XFree86, there was also Xsgi and Xsun and for mac Xquartz, I even saw a neat project once where the Xserver was in javascript, I am trying to find it again but our modern search engines are a bit shit. The point being all of these can interoperate with one another.
Around computers it is difficult to find the correct unit of time to
measure progress. Some cathedrals took a century to complete. Can you
imagine the grandeur and scope of a program that would take as long?
-- Epigrams in Programming, ACM SIGPLAN Sept. 1982
We have our cathedrals, only we are such barbarians as to call them worthless garbage and unfit for purpose and do our best to tear our legacy down.
> Wayland is not a "display server", it's a display protocol.
This is a huge part of what "user/dev hostile" means in my book; with Wayland, getting a working desktop always someone else's responsibility, all features have to be reimplemented across DEs endlessly (with often-incompatible variations, of course), and they all blame each other and program authors for bugs while the Wayland project refuses to even acknowledge basic features like desktop automation or screen recording.
> But sure, the transition was difficult and took a long time.
And this irks me too, people are convinced they're done but I still don't have xmacro. And flameshot is broken, while the alternatives suck. And support for everything depends on the DE now. And java.awt.Robot is broken with no replacement. And the clipboard randomly misses copies. And OBS screen recording is broken for me. And there's no support for display resolution scaling. And ssh -X is gone, while waypipe doesn't work all programs.
But hey, at least there's HDR now or something! It was definitely worth replacing a functioning stack for this. I'm so glad that Plasma 6.8 removes X support!
People aren't lamenting over Wayland not doing font rendering or audio but they care about display system features like screen recording and input automation that Wayland intentionally hobbles.
Websites already can barely be assed to care about supporting Firefox users, doing adblocking by default is a great way to get websites to start putting up banners that say "our website does not work with your browser, please switch to Chrome" en-masse.
And Mozilla did develop anti-fingerprinting tech, but they can't enable it by default because it breaks lots of websites and when a website doesn't work they're not going to appreciate Mozilla for protecting them, they're going to be pissed that it doesn't work.
It would be executed by anyone who experiences a problem using a site with Firefox and asks for help about it in a forum, or chat AI, or finds a YT video about it, etc.
Non-technical people do follow recommendations like installing an extension to help with a problem. Especially if they see the same recommendation from multiple sources, and testimonials as to its efficacy.
In practice, it'd probably look like switching to chrome for the majority of users. A lot of tech saavy users would install a plugin but that's a lot of friction especially for random sites or even for an important site. Using chrome or edge would be easier for most users.
Brave has native ad-block and anti finger-printing, enabled by default, and the web works excellently as in I don't know of a single site that doesn't work with it.
Brave is based on Chromium and inherits basically all compability, that this brings.
Firefox with Gecko is a different engine entirely and that sometimes causes compatibility issues or different behaviour, that websites have to account for.
Brave's ad block is pretty ineffectual by itself. For example it doesn't block youtube adverts. Recently switched to Firefox with Ublock origin, and loving it. So much more efficient and quick than it was back in the day when we all switched to Chrome.
I don't know what to tell you... It most definitely does not block youtube adverts for me and never had / did... Also, I found Ublock origin updates less reliable / frequent on Brave. Since switching zero issues.
Perhaps you were disabling their adblocker by trying to use ublock? In general there's no reason for additional plugins - they also have native custom filters, scriptlets, and so on.
No... As tech helper for various family and friends, I've been the one to clean install brave on a variety of machines. I typically demonstrate youtube before and after ublock for them, so they can see its effects. Never once not had adverts on a clean brave install. Not a representative sample obviously, but I've installed it for a fair few folks over the years.
Similar experience with firefox and ublock origin. I make the cut early, when chrome was threatening to make the change originally and have had a really good experience. Many, many things just work with the ads stripped out. Youtube and other streaming services - I don't know how people can even use them without proper filtering.
The final death of IE6 was because corporates finally stopped using it⁰ and the reason for that had nothing to do with sites/apps refusing to work. If we'd said "we don't support IE6" they'd either say "the contract we signed years ago somehow says otherwise" or "fair enough, we'll use someone else's solution then".
What killed it was IE6 not supporting TLS1.0 out of the box or TLS1.1+ at all, and that started to make them fail external audits. After years of telling them IE6 was holding us back implementing best-practise security on their instances of our apps¹ and being ignored because doing anything about it their side was too much hassle, external auditors started refusing to give them relevant certificates & such because of their systems not being up to best practise (or even good practise by that point!) and suddenly they made the effort to no longer have anyone in their orgs using IE6.
--------
[0] source: I was working on software serving the banking industry (customer facing & investment sides, not trading) around that time and years either side
[1] Even having annual conversations like:
! The pen test results say you should disable anything below TLS1.0 (and later 1.1), and you haven't. Please do.
? Are you sure? We'd *really* like to, as we've repeatedly mentioned, but that will block your IE6 users.
! Yes! You must follow the recommendations!
? Excellent. Done.
[a short time passes]
! Your application is broken for some of our users!
? Yep. They are using IE6 without TLS enabled.
? Either you need to upgrade their configurations or tell us, in writing please, to break from best practise and reenable the older protocols.
[another short time later]
! Please reenable the older protocols.
Oh that certainly did the trick for home users, but I was having to deal with IE6 for our clients (at least one of them was IE6 only), as were people I knew working in or otherwise supporting other corporate environments, for several years after that.
Some management types might have even seen YouTube potentially blocking IE6 users as an advantage for keeping with IE6 to save bandwidth on their creaking external network links!
With a normal Firefox on desktop on Linux, I get unsolvable recaptchas all the time, especially on cloudflare pages.
Ironically, if I fake instead a chromium to be on Windows (UA and Sec-CH headers), I am allowed most of the time even though my TCP fingerprint must mismatch then.
It's annoying to see what the normal web has become. Can't even read news anymore.
Ironically, all these bot defenses make it easier for bots to scrape their website, but make it harder for actual users to use them.
The only bot defense web app firewall that still works with Firefox seems to be Anubis. Pretty much all others autoflag Linux users as bot users, which feels insane if you think about less web developers must know about how botnets work.
> I get unsolvable recaptchas all the time, especially on cloudflare pages.
If you really mean reCAPTCHA (the one with a “select all squares that have X” kinda challenges), then Cloudflare hasn’t used that for quite a while now. archive.today uses a Cloudflare-looking (old style) page with a reCAPTCHA (and they do serve it quite often), but I don’t think I’ve seen other sites do that.
No you can get literally unsolveable captchas with cloudflare. You tick the box and it just refreshes and displays the unticked box again. Or people it on gateway endpoints that just return plain text errors (Humble does this).
There's code that makes it do something different after 100+ failed retries but you can speed it up by editing the _cf_chl_rc_* cookie (which is just a number). I haven't yet worked out what it does differently.
> I get unsolvable recaptchas all the time, especially on cloudflare pages
Repeated problems with cf and similar like this seem to be more common for users behind CGNAT (most mobile users for example). Presumably all the other hosts sharing the same final outgoing address(es), some of which will be running bots either deliberately or because they've been infiltrated by malware, confuse the heuristics that decide how often checks should be made.
we have clause in deal with clients about browser support (IIRC 5% or something like that). FF was just mismanaged so badly that the usage dropped so far into low single digit % it's not the question of maliciously not supporting it, it's the question of not wasting time on browser barely anyone of actual users use.
So, most sites work, but are never tested on FF, because there is no point, client won't pay for it.
The level of mental gymnastics in this thread denying the extent to which companies like Google (and their puppets like Mozilla) control the internet is too damn high.
Fortunately if projects like Ladybird gain enough momentum, websites might be forced to cater to it. Time will tell.
People on here love to moan about Firefox because Mozilla did one thing at some point in the existence of the company they didn't like. But then just cede the Internet to Google and chromium clones because at some point when they were a crappy junior JS dev, Chrome had some better tooling over Firebug so they just got used to testing in one browser. Maybe they also like to remember how Firefox, a decade ago, couldn't handle 1000 tab sessions.
I hope Firefox keeps up the fight but HN loves to crap all over them for not being perfect.
For starters, they notoriously make configuration a difficult and shifting game of whac-o-mole to do simple things such as disabling the AI that nobody asked for:
It's also become more unstable in recent years, and I'm not even talking about 1000 tab sessions. It will crash with only a handful of tabs fairly regularly on linux.
For more flaws, look at everything LibreWolf, Waterfox, etc do to make up for them.
But you would still be left with all of the other issues pointed out by me and others. Plus, the parent seemed to be referring to FF, not just its core, so I replied accordingly.
It's not modular, for example. You can't just use the Gecko engine in your project. To do so, you have to deal and hack through the whole codebase of the Firefox browser.
It's been many years since Firefox dropped support for XUL extensions and XUL itself. It even lead to Firefox being forked, and Palemoon browser (amongst other forks of it) now carry the legacy of XUL ( https://udn.realityripple.com/ ). Also, that hasn't stopped Firefox from offering stand alone Gecko on Android ( https://mozilla.github.io/geckoview/ ) now, has it? If they can do it for Android, why not all the other desktop platforms? Start redirecting the 300+ million dollars they have earned from Firefox to the developers instead of the CEO et al and maybe we will see some good innovation happening in Firefox ...
Look how few people use it. Do you still want to claim that firefox is perfect? Because if not I suggest to read up on the last 15 years why people stopped using Firefox. Not all of which has to do with Google.
> I hope Firefox keeps up the fight but HN loves to crap all over them for not being perfect.
This shows a total lack of understanding. You assume that Firefox is perfect. It is not. It is a pretty bad browser. There is a reason why adChromium won. I wish it would be different but it is not.
Can’t speak for all users, but at least as of about six months ago, there appears to be a bug in Firefox in NixOS where the shader cache doesn’t appear to be able to write properly, and as such video acceleration doesn’t work. It became most evident when I was trying to watch 360-degree videos in Immich.
Entirely possible that this is an issue specific to NixOS or my machine, but because of that issue I switched over to Brave.
I would like to go back to Firefox at some point. Maybe I’ll see if I can make a patch to fix video acceleration on NixOS.
the obvious thing to do is keep using firefox as your daily driver, and load up the other browser as needed for the video etc.
I'm being tongue-in-cheek here because it seems most people just give up on safari/firefox if one thing doesn't work and go to some chromium-based browser as their default driver. That's sad.
I don't understand it. I do keep an ungoogled chromium install around for the few times when I suspect a site is intentionally breaking itself for firefox, and it's not a big deal to open on occasion. Otherwise, if you value customization at all, you have to use firefox.
I am not going to use two separate browsers purely so that a larger percentage of my time is spent in Firefox. That’s not a solution; the solution is to fix Firefox.
I would rather spend 100% of my time in Firefox but that’s not doable right now.
Thats what I do - that 1 page in 100, if at all, goes to chrome. But basically 100% of pages I ever use work fine.
They will have to pry with significant force firefox with ublock origin from my old dusty finger bones... fuck the rest for selling us all out.
Even if it won't move the needle a bit, I can look at myself in the mirror in this specific regard and be content that I didnt bow my head like bland masses did and didnt work towards massive enshittification of our global society from now on.
Because thats what its all about, nothing less. With our choices, we shape future for our kids and grandkids. Shame on you, all you rich faangs who are directly helping this. Godwin's law is never too far in such cases and history wont be kind to you, no reason to be
> You know you can make a browser based on Firefox's core and don't need to make a new one from scratch that'll never get past Cloudflare?
Under some definitions, the browser IS the core. You are bound at a fundamental level to your parent if you build on someone else's foundations. Firefox is probably a great one to do it but worth knowing that someone else owns the land upon which you stand.
They literally didn't deny that. They made a separate point you appear not to have actually read.
Regardless, I don't want baked-in Firefox adblocking in part because I don't trust Mozilla with that task either. They'd absolutely end up allowing their own "acceptable" telemetry and ads. Even if they didn't, it would be unlikely to ever be as effective as Ublock Origin. Much like how Chromium browsers' built-in adblocking is barely anything in comparison, even on Manifest V2.
And yet, for now, Firefox and Mozilla is by far the lesser evil. I like a few of the Chromium browsers well enough, but they are ultimately at the mercy of Google.
Their separate point was ignored because it was an irrelevant tangent.
> Regardless, I don't want baked-in Firefox adblocking in part because I don't trust Mozilla with that task either.
This is in a thread about how we should be happy that FF is vetting code for us. Do we trust them or don't we?
> And yet, for now, Firefox and Mozilla is by far the lesser evil.
I'm instinctively tempted to agree, but the difference is so negligible at this point that the only sign I would is the fact I'm still using FF due to momentum (as well as Ladybird not being ready from prime time yet).
FF/Mozilla has proven itself to be controlled opposition, so I'm not very interested in games of "lesser-of-two-evils" abuser logic that has infected politics and many other spheres in a race to the bottom.
GP trusts them for reviewing external extension code, and ensure that it does not contain malware, but not for not inserting exception to their own telemetry if they wrote the code themselves.
Or, more likely, they feel that having two independent actors collaborating on the extension (one by writing and the other by reviewing) yields a more trustworthy outcome than either actor on their own.
Mozilla have given us plenty of reasons to not trust them, which makes it hilarious that anybody would think it's noteworthy they're reviewing the code of Raymond Hill of all people.
>> Regardless, I don't want baked-in Firefox adblocking in part because I don't trust Mozilla with that task either.
> This is in a thread about how we should be happy that FF is vetting code for us. Do we trust them or don't we?
Are you joking? You brought the claim to the table, and now that people see the flaws in it you deny them talking about it? You're some mental gymnast..
> Fortunately if projects like Ladybird gain enough momentum, websites might be forced to cater to it. Time will tell.
Ladybird has corporate sponsors too. Sponsorship is influence. Obviously, the more sponsorships you have the less influence an individual one have but it is worth knowing.
True, but it ultimately depends on the terms of the sponsorship.
One would hope that a project like Ladybird (which is motivated to compete with a product which was ruined by Google's sponsorship) would choose those terms carefully.
Everyone complains about the CEO pay but it's not that significant compared to the overall budget. The actual $$ historically goes to spending on high end office space in San Francisco, Paris, and other expensive cities and paying salaries to match the CoL in those areas. Kind of rich for a nonprofit.
But I'm sure people would complain if they moved operations to Brno and Warsaw too.
The fundamental problem with non-profit executive pay is that they earn their keep. Even more directly than CEOs in a for-profit space. The CEO of a non-profit has approximately one job: convince rich people to give the non-profit large amounts of money. It turns out, rich people know other rich people. And rich people who know how to convince other rich people to give them large amounts of money are a scarce resource, that non-profits squabble over.
So you've got a scarce labor pool, with expensive lifestyles, and a very directly obvious ROI. That alone is a recipe for high salaries. Combine that with the inflation that comes from the fact that for-profit executives get to hide a huge portion of their compensation as stock, whereas non-profits pretty much exclusively offer salary, and you end up with apparently bloated non-profit executive salaries.
Outside US, many non-profit organisations, the management gets as much money as most other folks that also contribute their free time. There are no goals and bonus to share, quarter earnings and whatever else.
https://github.com/fractalfir/rustc_codegen_clr
reply