Functionality that has been deprecated in Red Hat Enterprise Linux 9(access.redhat.com)
access.redhat.com
Functionality that has been deprecated in Red Hat Enterprise Linux 9
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/9.0_release_notes/deprecated_functionality
260 comments
This gives your customers nine years to change nothing and one year to panic and die.
Ask how I know.
Ask how I know.
It should be legendary how much better humans are at long term planning than corporations. Yet more heaping mounds of proof. Humans consider their bodies & what might happen with far more realism than corporate naivety and reckless optimism.
We don't reward long term corporate thinking.
Humans can clearly do it, so corporations could too. The organism responds to its environment.
Humans can clearly do it, so corporations could too. The organism responds to its environment.
The problem of modern companies (public or private) is that institutional shareholders demand greater profits even if it affects the companies' long-term prospect. They simply want that line to go up, they don't bother much with the details of the company.
We need to socially rebuke the Friedman doctrine that’s at the root of all of this. It’s not even law but it’s so ingrained at this point people think it is.
We do, but 99.9999% of the people doing the work won't meaningfully experience any benefit from doing so.
So we never do. Nothing will change that other than enfranchising your people, other than upsetting the top-down hierarchy.
So we never do. Nothing will change that other than enfranchising your people, other than upsetting the top-down hierarchy.
> how much better humans are at long term planning than corporations
> Humans consider their bodies & what might happen with far more realism than corporate naivety
Welp, this is how I learn I am not a human, but a corporation...
> Humans consider their bodies & what might happen with far more realism than corporate naivety
Welp, this is how I learn I am not a human, but a corporation...
Well technically, humans are corporations of trillions of cells...
Aye by this logic I am a corp whose only offering is eating donuts all the time.
No regrets, btw.
But to the main point: corporations are humans, and the entire reason for executive positions is to create a human charged to act as empowered decision maker for the organization. They are the human while the rest of the bureaucracy is essentially a cog. That they, the execs, fail so often is a sign we need to GPT them
No regrets, btw.
But to the main point: corporations are humans, and the entire reason for executive positions is to create a human charged to act as empowered decision maker for the organization. They are the human while the rest of the bureaucracy is essentially a cog. That they, the execs, fail so often is a sign we need to GPT them
Well, better doesn't mean good.
>Humans consider their bodies & what might happen with far more realism
I don't think so. I'd say most people disregard to what's happening to them, even when it's apparent that something's wrong. And especially if there seems to be nothing wrong, so that the problem only exists in the form of warning, and forecasts.
I don't think so. I'd say most people disregard to what's happening to them, even when it's apparent that something's wrong. And especially if there seems to be nothing wrong, so that the problem only exists in the form of warning, and forecasts.
But most people are also enwrapped in fantasies & dreams & ideas of where they are going.
What's happening to them famously doesn't incurse upon our dream-selves, is my view. We stick to our dream-selves & our quests, regardless of externals. And sometimes that is foolish. But it also shows I think a pigheadedness that gets it, that picks long wins, that isn't detered.
What's happening to them famously doesn't incurse upon our dream-selves, is my view. We stick to our dream-selves & our quests, regardless of externals. And sometimes that is foolish. But it also shows I think a pigheadedness that gets it, that picks long wins, that isn't detered.
This is the frustrating part of being a linux user. Absolutely massive time periods before changes. Literally no work is done until it eventually changes, everything breaks, and people scramble to fix it. Which more desktop oriented distros would just drop xorg next year and we actually get the last remaining apps updated.
It has nothing to do with being a "Linux user" and everything to do with being an LTS OS user. Not being bowled over by rewrite-the-world changes is why rolling release distros exist.
And before anyone says it, no "rolling release" doesn't mean "unstable".
And before anyone says it, no "rolling release" doesn't mean "unstable".
I'm on Fedora which is pretty up to date and I just have random issues all the time. Currently I can't get xbox controllers to pair. It works on windows, it worked on fedora when I tried a few months ago, absolutely can't get it working now. When I switch audio outputs, they don't work until I kill pipewire a random number of times and then they work.
And these are just the random breakages, not the missing features like fractional scaling and HDR. Obviously these problems don't affect everyone, but they affect me and despite a decade of linux experience, I can't find solutions.
And these are just the random breakages, not the missing features like fractional scaling and HDR. Obviously these problems don't affect everyone, but they affect me and despite a decade of linux experience, I can't find solutions.
Counterpoint: I run Arch Linux on all my machines and I can't remember the last time something broke that wasn't ZFS, and I opted into that one, it's explicitly unsupported. I switch between a Bluetooth headset and my speakers/webcam multiple times a day and it just works (I'm also using pipewire, not pulse).
There's the guy on my team who is steaming mad at Sindre Sorhus for making all his npm packages ESM only.
https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3...
The time line is a little more compressed. I'm somewhat sympathetic. But my heavens, that using the language's official module system is a pain & difficult makes me think we needed to switch harder earlier.
(Also Node simply lacked the courage to try to do what many before them had done, & make cjs/ESM intercompatible: worked great in @std-things/esm but node let themselves get steered into prissily rejecting an obviously fine path for absurd technical minutia).
We gasp & moan the whole time old soggy gross bandaids are being ripped off. We direly need to call shots & make it happen. We need the will.
The time line is a little more compressed. I'm somewhat sympathetic. But my heavens, that using the language's official module system is a pain & difficult makes me think we needed to switch harder earlier.
(Also Node simply lacked the courage to try to do what many before them had done, & make cjs/ESM intercompatible: worked great in @std-things/esm but node let themselves get steered into prissily rejecting an obviously fine path for absurd technical minutia).
We gasp & moan the whole time old soggy gross bandaids are being ripped off. We direly need to call shots & make it happen. We need the will.
& as a shorthand to "and" makes you look like a child, discounting everything you say. Just sayin'.
Is there anything else anywhere that points to this strong bias you have? I have seen one other person bother to comment, in a slightly more sly negative way, counting how many '&'s I used.
I obviously dont seem to share the sensitivity, it seems natural to me, and I'm not sure where these feelings & reactions come from. I feel like there should be some substantiation or discussion, something available, if & for and is so unsettling to folks.
I obviously dont seem to share the sensitivity, it seems natural to me, and I'm not sure where these feelings & reactions come from. I feel like there should be some substantiation or discussion, something available, if & for and is so unsettling to folks.
It hinders readability just to save you two keystrokes, you are effectively telling people "fuck you, I don't care about the effort you'll have to make to parse my gibberish". Plus, of course, I'm sure you know almost no-one else uses it like that, so you come off as begging for attention. Both are very childish approaches, when trying to communicate with peers.
This is the frustrating part of being a user, of any system. Change is risk, and why take risk? In case of Wayland, I see no upsides as a user. At most, it works as well as xorg did, which is to say, in the background, doing its job, for me to not worry about it.
It gives software developers 9 years to receive feedback from early adopters, and fix things if they want to stay relevant. There’s not much point to installing a new server if there’s no software for it.
And it makes it possible to say, well you had 9 years to make the change, now that you’re out of time it’s your problem.
How do you know?
Personal experience, I think. People still complain about python 2.7 even though python 3 has been around for 15 years and python 2 was EOL 3 years ago.
literally to have millions of lines in production code just in our company, untold billions or trillions of production Python2 code that works perfectly fine (well, did work) around the world. guess that will teach us to trust a scripting language for production systems!
So, whats the alternative? Try compiling a decade old java app and get ready for a surprise. Python2 was already dead 2 years ago. If your company did nothing to at least ensure the code runs, thats their problem. All languages go though deprecation and changes, except the dead ones - only if you had used *QBasic, you wouldnt have this problem.
*the choice would be Cobol for most folks, but not only cobol isnt dead, it actually changes and deprecates stuff throughout the years - ex. Cobol77 vs cobol85.
*the choice would be Cobol for most folks, but not only cobol isnt dead, it actually changes and deprecates stuff throughout the years - ex. Cobol77 vs cobol85.
What's the problem? you have the source, nothing is stopping anybody from using python2. In fact from that perspective you could say it is a good thing, once python3 was published, the language python2 became more and more stable. Until we are at this point. The language is super stable. It will never change again. exactly what you wanted.
> nothing is stopping anybody from using python2
Eh... pip+pypi killing support for python2 is kind of a big problem for continuing to use it unless you have zero external dependencies.
Eh... pip+pypi killing support for python2 is kind of a big problem for continuing to use it unless you have zero external dependencies.
This is the main difference between trying to get some ancient code written in C working vs "modern" toolchains - if you have the compiler and the code for C, everything is self-contained; many things like python2 download absolutely tons of support code and libraries to "build" - and when those go offline you can't easily build anymore; and you can't even say "this here VM will build this forever" unless you make sure that it will continue to work (and everything is separately cached/downloaded).
Should have used perl5 i guess? /s
Every single EOL product we’ve ever used has never been a priority issue until long after support has ended. It’s quite aggravating.
Its almost like companies fail to do software maintenance.
Couldn't they also keep supporting that functionality though CentOS or EPEL? And Fedora probably won't drop support as long as unpaid volunteers bother to keep it working....
I'm glad Red Hat is dropping support entirely: they have been footing the bill for this transition for too long. It's time for Ubuntu, NVIDIA, and others to step up their contributions to/support of Wayland.
I'm glad Red Hat is dropping support entirely: they have been footing the bill for this transition for too long. It's time for Ubuntu, NVIDIA, and others to step up their contributions to/support of Wayland.
Support means many things to a company like Red Hat.
"Ship it" in EPEL, sure, but support to Red Hat is a contractual obligation.
"Ship it" in EPEL, sure, but support to Red Hat is a contractual obligation.
Another surprise for me: removal of the `scp` command. I hadn't even realized that `openssh` provided a command named `sftp`; for some reason I always assumed that `scp` was using the `SFTP` protocol under the hood, but maybe I shouldn't take that for granted.
This is only tangentially related, but I'll say this here since people will appreciate knowing:
In practically every situation where you can use scp, you can use rsync instead, which I consider better in every regard. rsync by default works over ssh, so uses its authentication and configuration, like scp would.
If the file(s) do not already exist on the destination, you don't lose anything, but gain better syntax for specifying source and destination, better reporting, and a few other things. If the files or any subset do exist, you get a potentially massive speed up by only transmitting the differences.
It's also very useful to me to specify "-u", which doesn't overwrite newer files. Two-way sync for example is easy that way.
Given the advantages, for me it's just less mental load overall to always type "rsync" instead of "scp", no matter the situation, and only remember that syntax. The only problem is when the destination really does not have an rsync binary (note that you do not need an rsync daemon, just ssh and the rsync binary present on the destination host), which is surprisingly rare actually. Mostly when dealing with embedded, but even then there's often rsync.
In practically every situation where you can use scp, you can use rsync instead, which I consider better in every regard. rsync by default works over ssh, so uses its authentication and configuration, like scp would.
If the file(s) do not already exist on the destination, you don't lose anything, but gain better syntax for specifying source and destination, better reporting, and a few other things. If the files or any subset do exist, you get a potentially massive speed up by only transmitting the differences.
It's also very useful to me to specify "-u", which doesn't overwrite newer files. Two-way sync for example is easy that way.
Given the advantages, for me it's just less mental load overall to always type "rsync" instead of "scp", no matter the situation, and only remember that syntax. The only problem is when the destination really does not have an rsync binary (note that you do not need an rsync daemon, just ssh and the rsync binary present on the destination host), which is surprisingly rare actually. Mostly when dealing with embedded, but even then there's often rsync.
`scp` provides progress etc. by default. I do have muscle memory for `rsync -irP` so it's not a problem, but default `rsync` on my Mac does not provide progress output otherwise.
I've never been able to memorize rsync's syntax such that it handles directory contents the way I want to. If I want to copy the contents of directory foo to directory bar, with cp it's easy:
cp -r foo/* bar
rsync -a foo bar
rsync -a foo/* bar
rsync -a foo/ bar/
rsync -a foo bar/
rsync -a foo/* bar/
> cp -r foo/* bar
Ah, you fell into a trap already! Using foo/* like that is generally "weird", since you let the shell expand. It will, for example, miss files that start with a dot ("."). But not necessarily, it depends on what the shell does!
As for the "trailing /" syntax, I know what you mean, but once you've internalized it, it's easy.
Without trailing slash: Copy the directory (and its contents). With trailing slash: Copy what's in the directory. This makes sense, because with the / you say you want to go "into the directory" and copy then.
And the latter includes files starting with . and all of that, you don't have to worry about it, or about what the shell would do, it's all the directory contents.
So what you want for your example is:
Ah, you fell into a trap already! Using foo/* like that is generally "weird", since you let the shell expand. It will, for example, miss files that start with a dot ("."). But not necessarily, it depends on what the shell does!
As for the "trailing /" syntax, I know what you mean, but once you've internalized it, it's easy.
Without trailing slash: Copy the directory (and its contents). With trailing slash: Copy what's in the directory. This makes sense, because with the / you say you want to go "into the directory" and copy then.
And the latter includes files starting with . and all of that, you don't have to worry about it, or about what the shell would do, it's all the directory contents.
So what you want for your example is:
rsync -a foo/ bar
> Without trailing slash: Copy the directory (and its contents). With trailing slash: Copy what's in the directory. This makes sense, because with the / you say you want to go "into the directory" and copy then.
Semi-related: with other stuff symlinks act the same way, for example "ls foo" will show you the symlink (even if it's to a directory), "ls foo/" will traverse the symlink (and show you what's inside the directory).
Semi-related: with other stuff symlinks act the same way, for example "ls foo" will show you the symlink (even if it's to a directory), "ls foo/" will traverse the symlink (and show you what's inside the directory).
Note that a trailing slash means to copy the contents when using rsync, but not when using cp (which will copy the directory even if there is a trailing slash). For cp, the correct way to copy only the contents is to use `cp -r foo/. bar`. (This also works with rsync.)
[deleted]
The source is the only thing to worry about.
Without a trailing slash it makes a copy of the directory, and fills it.
With a trailing slash, it copies just the *Contents* of the directory.
rsync -avP foo bar # puts foo inside bar so bar/foo/*
rsync -avP foo/ bar # puts the the contents of foo, in bar (without making foo)
It turns out "bar/" is equivalent to "bar/."
That means "bar/" is just a contraction of "bar/."
For some reason I find the presence of the "." makes it much easier to reason about. Probably that because turns it into the same pattern as "rsync foo/x bar/y". Most people know what that does, even if "foo/x" or "foo/y" are directories.
That means "bar/" is just a contraction of "bar/."
For some reason I find the presence of the "." makes it much easier to reason about. Probably that because turns it into the same pattern as "rsync foo/x bar/y". Most people know what that does, even if "foo/x" or "foo/y" are directories.
rsync -aP does, and -aP is what I usually want. -a implies recursive (-r) and preserving permissions (-p), among other things.
I prefer --info=progress2 over --progress - rarely do I care about the progress of individual files but I want an idea of how much longer the whole transfer is going to take.
Also --delay-updates is useful to minimize disruption when copying into a live directory read by a webserver or other program where you want to have a consisten state.
Also --delay-updates is useful to minimize disruption when copying into a live directory read by a webserver or other program where you want to have a consisten state.
That's much better than what I use by default. Now to retrain oneself...
The command hasn't been removed or deprecated; just the protocol. Instead of using the SCP protocol it uses the SFTP protocol. As a user, you basically don't notice outside of some specific cases. OpenSSH has used the SFTP protocol as the default for a year or two.
I remember working on openssh years ago and when I got into scp - I was "WTF are they THINKING?" sort of thing.
Basically scp logged you into the remote system just like ssh and spawned an process through a command pipe.
For one thing, this completely eliminated the ability to separate "user can run program on remote system" from a much more limited "can send/receive a file".
It's like if nfs access to a filesystem required the ability to log into the remote system.
I'm glad this seems to have been sort of addressed. I don't know if it allows more sane filesystem-access-only ssh access to a system.
Basically scp logged you into the remote system just like ssh and spawned an process through a command pipe.
For one thing, this completely eliminated the ability to separate "user can run program on remote system" from a much more limited "can send/receive a file".
It's like if nfs access to a filesystem required the ability to log into the remote system.
I'm glad this seems to have been sort of addressed. I don't know if it allows more sane filesystem-access-only ssh access to a system.
It's one of those "seemed like a good idea at the time" things from when the internet was essentially a bunch of universities and a lot less hostile. Originally this was all just wrappers around telnet.
Some more information on issues with scp: https://lwn.net/Articles/835962/
scp(1) has used the SFTP protocol since OpenSSH 9.0. Before that it used its own protocol.
It doesn't say that the scp command is being removed, but that the protocol is deprecated.
Perhaps use zssh and sz/rz to send files. Much more convenient anyway as it allows you to switch and send files during an interactive session.
Hoe does sftp replace scp?
They both can send and retrieve files, though sftp is usually interactive and scp (aside from the password) not so much.
If you want to retrieve a file without renaming it, sftp url-with-path-where-path-is-an-existing-file will copy that one file, non-interactively.
To rename or put a file (non-interactively), you need to do something like echo 'get/put remote-path local-path' | sftp ...
If you want to retrieve a file without renaming it, sftp url-with-path-where-path-is-an-existing-file will copy that one file, non-interactively.
To rename or put a file (non-interactively), you need to do something like echo 'get/put remote-path local-path' | sftp ...
> The X11 protocol remains fully supported using the XWayland back end.
And they already got rootful xwayland, so if you want to keep using X11 all this means is that you have to replace one X server with another.
And they already got rootful xwayland, so if you want to keep using X11 all this means is that you have to replace one X server with another.
Do XWayland programs still scale incorrectly when using dpi scaling in wayland? This thwarted my last serious attempt to switch to sway.
If your frustration was that x11 apps are really blurry then: Yes, unless you use kwin as your compositor and tell it to let x11 apps scale themselves.
Gnome also supports this; it's how I have it configured.
Only if you have two monitors at different DPI scales which is impossible on x11 iirc.
You can do it with client side scaling in X (which is also the preferred solution on systems like Windows, since an application can scale itself better than a generic compositor anyway).
Hmm, how does that work if you move clients around between displays?
The client is given an XConfigureEvent when it is moved and can compare it against the monitor's bounding boxes (which it caches in between xrandr change notifications) and rescale itself.
Doesn't work with legacy applications... but neither does Wayland so you aren't really behind.
Doesn't work with legacy applications... but neither does Wayland so you aren't really behind.
Wow, not even Debian has done this. What a world in which RHEL is more adventurous than Debian.
So, is Wayland ready? I've been afraid to try it, but maybe it's time to take the plunge. How is gaming on Wayland? I'm afraid many games have been compiled for X.org.
So, is Wayland ready? I've been afraid to try it, but maybe it's time to take the plunge. How is gaming on Wayland? I'm afraid many games have been compiled for X.org.
> So, is Wayland ready?
I'm not that interested in digging into the details of why, but SMPlayer doesn't like Wayland on my system, and SMPlayer is the only video player that I can get to play videos from smb shares without a fuzz. So Xorg it is...
I try to switch every 6 months or so to see if things have improved but, so far the answer is no.
I'm not that interested in digging into the details of why, but SMPlayer doesn't like Wayland on my system, and SMPlayer is the only video player that I can get to play videos from smb shares without a fuzz. So Xorg it is...
I try to switch every 6 months or so to see if things have improved but, so far the answer is no.
I personally use mpv and never had an issue with playing from SMB.
I love mpv on xorg, but there are still have issues on wayland depending on which compositor you are using:
> [vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.
> [vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.
I use VLC to play files on a smb share under Wayland no problem.
On my system VLC just doesn't play the files from shares. No problem if I copy the files locally.
There's something in the error logs, I spent many hours trying to get it work a year ago but I just gave up and went back to SMPlayer on Xorg.
VLC also has issues with audio, apparently VLC doesn't play ball with PulseAudio or something like that, so I get massive audio dropout for quite a while when skipping/jumping in the video file. Yay. Something about clocks going back in time or something. IIRC there's a fix pending, so maybe in a year or two...
There's something in the error logs, I spent many hours trying to get it work a year ago but I just gave up and went back to SMPlayer on Xorg.
VLC also has issues with audio, apparently VLC doesn't play ball with PulseAudio or something like that, so I get massive audio dropout for quite a while when skipping/jumping in the video file. Yay. Something about clocks going back in time or something. IIRC there's a fix pending, so maybe in a year or two...
RHEL has always been more adventurous than Debian. Debian is the pragmatic distro that meets users where they are.
Debian half-heartedly switched to systemd years after it was the only option in RHEL. RHEL switched to firewalld in 7. They dropped docker for podman. They wrote then adopted sssd and relamd. They dropped NIS. Went all in of SELinux and now it "just works."
Debian half-heartedly switched to systemd years after it was the only option in RHEL. RHEL switched to firewalld in 7. They dropped docker for podman. They wrote then adopted sssd and relamd. They dropped NIS. Went all in of SELinux and now it "just works."
Red Hat is adventurous in rapidly adopting and evangelizing projects they control, or at least largely steer, in an effort to make themselves the de facto First Party Vendor for so much of Linux that it's hard to justify going with anyone else for commercial support. They've been openly sparring with Ubuntu over this for more than a decade—and Ubuntu's lost every single point. This is basically the story of the direction of the Linux ecosystem in the modern era.
It really is a shame that the community's last, best hope against a Red Hat monopoly is Ubuntu.
Fortunately in the desktop space there's little reason to care what the big names are doing. There will likely always be a distro out there that does exactly what you want it to, it'll likely always be Gentoo, and there will probably be enough folks interested in the space to bring those solutions to binary distros as well.
It's been especially interesting to me to watch Alpine take over the mindshare that Slackware had back in the day. As long as there's enough people on un-"official" distros to file bug reports with software vendors, there's hope for the users.
Fortunately in the desktop space there's little reason to care what the big names are doing. There will likely always be a distro out there that does exactly what you want it to, it'll likely always be Gentoo, and there will probably be enough folks interested in the space to bring those solutions to binary distros as well.
It's been especially interesting to me to watch Alpine take over the mindshare that Slackware had back in the day. As long as there's enough people on un-"official" distros to file bug reports with software vendors, there's hope for the users.
> It really is a shame that the community's last, best hope against a Red Hat monopoly is Ubuntu.
Oh, strongly agree. It's a "whoever wins, we lose" sort of situation for sure. I think Red Hat's technical... taste, if you will, is consistently terrible, but Ubuntu's gross in its own way, though I feel that way more due to perceived company culture and the owner's statements, admittedly, than their results (though I do think their distro peaked quality-wise some time around '08).
> There will likely always be a distro out there that does exactly what you want it to, it'll likely always be Gentoo, and there will probably be enough folks interested in the space to bring those solutions to binary distros as well.
Hobbyists are kinda safe, to some degree, but the more incompatible choices RH successfully pushes, the more limitations and workarounds hobbyists not running a straight copy of Red Hat's preferred stack will run into.
Oh, strongly agree. It's a "whoever wins, we lose" sort of situation for sure. I think Red Hat's technical... taste, if you will, is consistently terrible, but Ubuntu's gross in its own way, though I feel that way more due to perceived company culture and the owner's statements, admittedly, than their results (though I do think their distro peaked quality-wise some time around '08).
> There will likely always be a distro out there that does exactly what you want it to, it'll likely always be Gentoo, and there will probably be enough folks interested in the space to bring those solutions to binary distros as well.
Hobbyists are kinda safe, to some degree, but the more incompatible choices RH successfully pushes, the more limitations and workarounds hobbyists not running a straight copy of Red Hat's preferred stack will run into.
I'm not sure I get the fear.
Oh no Redhat is making so much high quality OSS that distros adopt makes Redhat commercial support better simply because you can get the engineer that wrote it on the phone? I mean that does happen but I'm not sure it's a bad thing.
They'll never be able to swing an EEE on any of their OSS projects because other distros couldn't adopt them and RHEL only is a death-knell.
Big if for sure, but if IBM continues letting them stay course while they fuck about with Openstack then we'll be better for it. Redhat is the standard for what good stewardship of OSS looks like from a company.
They'll never be able to swing an EEE on any of their OSS projects because other distros couldn't adopt them and RHEL only is a death-knell.
Big if for sure, but if IBM continues letting them stay course while they fuck about with Openstack then we'll be better for it. Redhat is the standard for what good stewardship of OSS looks like from a company.
> It's been especially interesting to me to watch Alpine take over the mindshare that Slackware had back in the day.
Slackware lost its way by trying to compete with Ubuntu when it was never it's niche.
Ever since they required Samba installed just to run SMPlayer, and then said the full install is what is expected in every case (When I always used Slackware with a minimal install), I was out.
Void seemed interesting as well but I ran into too many issues - Alpine has been smooth sailing so far.
Slackware lost its way by trying to compete with Ubuntu when it was never it's niche.
Ever since they required Samba installed just to run SMPlayer, and then said the full install is what is expected in every case (When I always used Slackware with a minimal install), I was out.
Void seemed interesting as well but I ran into too many issues - Alpine has been smooth sailing so far.
Wayland is fine. I haven't run into any problems using it in Fedora. Wayland vs Xorg shouldn't affect gaming.
Fine for some, but for others there are still show-stoppers. I have a laptop with an Nvidia card and my latest attempt to use Wayland, on Fedora 38, didn't last very long at all before being forced to retreat to xorg by the issues.
This has been my every experience with Wayland + Nvidia thus far. Tried Tumbleweed and Fedora both, nothing but display bugs as far as the eye can see.
Lets not even talk about trying to use Wayland in a VM desktop -- Even Firefox/Chrome don't render properly.
Lets not even talk about trying to use Wayland in a VM desktop -- Even Firefox/Chrome don't render properly.
Does your card have proper DRM support (the linux subsystem for managing video buffers)? That’s what wayland builds upon (instead of patching the xorg binary with some proprietary extension).
WTF? I thought NVIDIA had adopted an open-source core? Is this seriously something outsiders can't fix?
They have since started supporting the linux kernel and implemented its APIs more or less. I don’t own any nvidia card, so can’t really speak from first-hand experience though.
Yeah, hybrid laptops with Nvidia is still a no no. Currently I have setup: Arch (EndeavourOS) + KDE Plasma + Xorg, works with minor issues, with a Rog Zephyrus G15, with minor issues; it was/is enough to replace Windows entirely.
I'll try Wayland again this next semester, see if anything has changed.
I'll try Wayland again this next semester, see if anything has changed.
Unfortunately, there is not much Wayland devs can do about Nvidia drivers.
But RHEL didn't even set a date for removing Xorg support so it will probably stick around for a long while.
But RHEL didn't even set a date for removing Xorg support so it will probably stick around for a long while.
An employee in the comments earlier said the next release (RHEL10) will remove it, but that won't be for another 10 years.
Given the status of "certified drivers" in Wayland due to their closed-source nature, either RedHat is giving up their graphic workstation business, or removing xorg won't happen any release soon.
Or they are trying to force the hand of nvidia and see who budges first.
Fair point :)
RHEL 9 will be supported for ~10 years, but RHEL is scheduled to come out in ~3 years. Fedora will probably still support it and I would bet some of the RHEL rebuilds will too.
I am positive on wayland, but am still missing some things I love with Xorg.
For example, I still use pidgin for all my messaging (even with Slack and our own custom protocol). In xorg, I can set my pidgin buddy list as a Utility Window, make it sticky, below all windows by default, and skip the taskbar. This makes the buddy list not show up in my alt-tab or as a running application (doesn't show up in the gnome-shell overview). Then I have a simple script using wnck to raise/lower the window using a hotkey, which gives me really quick access to my buddy list and chats.
_Some_ of this is possible in wayland, but not everything.
I also haven't found a replacement for devilspie for wayland, which I use to set a bunch of default properties on various applications, like size, virtual desktop number, stickyness, and so on.
Both of these things are really essential to my daily flow and are going to be hard to give up.
For example, I still use pidgin for all my messaging (even with Slack and our own custom protocol). In xorg, I can set my pidgin buddy list as a Utility Window, make it sticky, below all windows by default, and skip the taskbar. This makes the buddy list not show up in my alt-tab or as a running application (doesn't show up in the gnome-shell overview). Then I have a simple script using wnck to raise/lower the window using a hotkey, which gives me really quick access to my buddy list and chats.
_Some_ of this is possible in wayland, but not everything.
I also haven't found a replacement for devilspie for wayland, which I use to set a bunch of default properties on various applications, like size, virtual desktop number, stickyness, and so on.
Both of these things are really essential to my daily flow and are going to be hard to give up.
> Wow, not even Debian has done this. What a world in which RHEL is more adventurous than Debian.
Not even Debian has said they would remove it in a future release? I'm not sure what you mean here, Debian has a reputation for being glacial...
> So, is Wayland ready? I've been afraid to try it, but maybe it's time to take the plunge.
Yes, it's increasingly becoming the default on desktop distros, it's pretty good. Some apps still lack support for it I guess. I recently upgraded to a distro where it was enabled and didn't notice any difference except for a screen recording app didn't support recording with sound unless I switched to X.
> How is gaming on Wayland? I'm afraid many games have been compiled for X.org.
AFAIK such things just start under an Xwayland session transparently. Phoronix seems to do a lot of gaming tests of wayland, I don't really know the details but clearly something works for some games at least.
Not even Debian has said they would remove it in a future release? I'm not sure what you mean here, Debian has a reputation for being glacial...
> So, is Wayland ready? I've been afraid to try it, but maybe it's time to take the plunge.
Yes, it's increasingly becoming the default on desktop distros, it's pretty good. Some apps still lack support for it I guess. I recently upgraded to a distro where it was enabled and didn't notice any difference except for a screen recording app didn't support recording with sound unless I switched to X.
> How is gaming on Wayland? I'm afraid many games have been compiled for X.org.
AFAIK such things just start under an Xwayland session transparently. Phoronix seems to do a lot of gaming tests of wayland, I don't really know the details but clearly something works for some games at least.
[deleted]
It’s still missing plenty of features that X has, so no I wouldn’t say that it’s ready.
Not all X features are going to be implemented in wayland, right? If a feature has security implication, chance that it won't be implemented in wayland. It took them years to get screen sharing working, and that with a significant proportion of wayland users begging for it on every release. Chance that other insecure but useful X features won't be implemented in wayland unless they can be implemented with security in mind AND the features somehow got prioritized for development (or some l33t programmers suddenly show up with a patch and got accepted).
Many “insecure” features are implemented on a per compositor-family basis in the meanwhile. Like every wlroots-based one has this protocol, things like that.
Depends on your use case, I've been using it for years now and am yet to run in to missing features. There are a few features x11 is missing like different dpi scales between monitors which Wayland does. Sandboxing with flatpak is another big one as well.
I'm a big Barrier user, which has no Wayland equivalent. I also frequently make use of X tunelling over SSH, which had no Wayland equivalent the last time I checked, although it has been a year or so since the last time I looked into it.
Synergy (the one Barrier forked from) seems to have wayland support on their beta release. It's not free though.
Input Leap has wayland support as well. https://github.com/input-leap/input-leap
It definitely depends on your definition of "ready". Wayland is completely usable for most hardware configurations I've thrown at it, but ymmv. It's pretty much been indistinguishable from X11 for me.
There's still a lack of certain protocols for things that were possible in X11. The one that's bugged me the most is one that would allow authorized applications to track which window is active so tools can swap around hotkeys and macros and stuff. That was super easy to do in X11 but Wayland doesn't yet have a way of doing this afaik.
There's still a lack of certain protocols for things that were possible in X11. The one that's bugged me the most is one that would allow authorized applications to track which window is active so tools can swap around hotkeys and macros and stuff. That was super easy to do in X11 but Wayland doesn't yet have a way of doing this afaik.
There's lots of little things I think. Like I have my trackball scroll by holding down middle click and moving the ball. Not too hard to do in X11, works in all window managers too. I have no idea how to do it Wayland, it seems like it's a different process for every compositor/DE. I think maybe I could do it in GNOME but then I'd have to use GNOME.
So far the only positive thing I've noticed about Wayland is that it plays better with my pen tablet but that's also extremely frustrating because why is better pen support linked to the compositor/window manager in the first place. Everything else is either the same or worse.
So far the only positive thing I've noticed about Wayland is that it plays better with my pen tablet but that's also extremely frustrating because why is better pen support linked to the compositor/window manager in the first place. Everything else is either the same or worse.
That's how thinkpad trackpoint works, right? Hold the middle button and you can scroll horizontally and vertically using the trackpoint. It works on gnome/wayland, so maybe there is a way to configure generic trackball to behave like that too.
https://wiki.archlinux.org/title/TrackPoint
https://wiki.archlinux.org/title/TrackPoint
Just a guess but probably its due to libinput, which is used by default on Wayland. AFAIK it can also be set on X as the default for probably similarly good pen support, but I have never tried - I am more than fine with Wayland.
That isn't a Wayland-level feature, but individual compositors may support it. For example that can be done in sway with `swaymsg -t subscribe -m '["window"]' | ...`
That's one of my biggest problems with Wayland; I rather like being able to swap out the window manager without breaking half my tools.
Since it’s wlroots, most niche window manager will also understand it. There is basically only gnome, plasma, and all the rest.
No, `swaymsg` is specific to sway, not wlroots. It won't work with any other compositor (wlroots-based or not) unless that compositor also binds $SWAYSOCK and serves the i3-ipc protocol.
That's probably true for protocol-level things but still doesn't cover as much as you'd think. For example, with X (possibly just Xorg but at least everyone standardized on that) I could run `setxkbmap` to set keyboard layout. Now as far as I can tell, wlroots does have a proper way to control keyboard layout... but it's up to each and every compositor to hook it up. So naturally, when I went to try a cool new compositor I found, I discovered that it doesn't actually support that. In fact, I couldn't find a way to configure keyboard layout at all in that compositor (don't recall which, but it was wlroots-based). So I threw up my hands and went back to X11, where one command controls the keyboard on literally every window manager I have ever tried.
Screen sharing seems to be a difficult problem to resolve. Zoom only just resolved this recently[1], Webex has been promising a fix for a while[2], and Skype still hasn't done anything[3].
[1] https://support.zoom.us/hc/en-us/articles/6634039380877-Zoom...
[2] https://help.webex.com/en-us/article/9vstcdb/Webex-App-for-L...
[3] https://github.com/flathub/com.skype.Client/issues/142
[1] https://support.zoom.us/hc/en-us/articles/6634039380877-Zoom...
[2] https://help.webex.com/en-us/article/9vstcdb/Webex-App-for-L...
[3] https://github.com/flathub/com.skype.Client/issues/142
I feel that google chat and meet has had screensharing working for a long time on wayland.
> Wow, not even Debian has done this. What a world in which RHEL is more adventurous than Debian.
Adventurous is adding things. Why remove things that work if some people are using them? Debian is less prescriptive than RHEL, and is widely used as the basis for a vast array of different targets. If there are still reasons for people to use Xorg, there are still reasons to have it in Debian, IMO. That doesn’t mean it will be installed and/or used by default.
RHEL is a specific type of target, particularly for things that need some sort of vendor certification, or for fleets who want to depend on RH for LTS and/or use their professional services, use it as part of a larger IBM contract, etc..
Adventurous is adding things. Why remove things that work if some people are using them? Debian is less prescriptive than RHEL, and is widely used as the basis for a vast array of different targets. If there are still reasons for people to use Xorg, there are still reasons to have it in Debian, IMO. That doesn’t mean it will be installed and/or used by default.
RHEL is a specific type of target, particularly for things that need some sort of vendor certification, or for fleets who want to depend on RH for LTS and/or use their professional services, use it as part of a larger IBM contract, etc..
RHEL doesn't really care about supporting desktop users, so they're trimming fat. They don't need X and Wayland to nominally support workstation use, just one of those is enough to sell workstation support contracts to executives who won't even be using it themselves..
Debian on the other hand cares about keeping desktop users happy, so it makes sense to support both.
Debian on the other hand cares about keeping desktop users happy, so it makes sense to support both.
Nonsense. Why am I able to file a bug in Fedora and a Red Hat engineer will work on it then?
The bug affects something a paying customer uses.
So they do care about desktop users?
They care about fulfilling the workstation support contracts. But if they can reduce the scope of what it means to support workstation support contracts, it is in their interest to do so.
They respond to X bugs right now because right now X is still in versions of RHEL they support. When that is no longer true, do you really expect them to continue supporting X on other distros?
They respond to X bugs right now because right now X is still in versions of RHEL they support. When that is no longer true, do you really expect them to continue supporting X on other distros?
[deleted]
Will they continue to do so, on company time, for packages that are no longer in any supported version of RHEL? I think they fix bugs that presently or will effect both Fedora and RHEL, or do more in their free time because they are themselves enthusiasts and not just corporate workers.
because they work on opensource and don't necessary need to have it in rhel to fix for the fedora users?
but if you ask for a bugfix on Xorg needing a large amount of time to spent on it probably not going to be worked on...
but if you ask for a bugfix on Xorg needing a large amount of time to spent on it probably not going to be worked on...
Dave Airlie the guy who maintains the AMD drivers works for Red Hat, on xorg and wayland and the KMS that both use.
Not including xorg in RHEL doesn't prevent people from running xorg on rhel. The question is, why would you ? Red Hat is aiming at the server market and the cloud, not the desktop.
Not including xorg in RHEL doesn't prevent people from running xorg on rhel. The question is, why would you ? Red Hat is aiming at the server market and the cloud, not the desktop.
If that was the case, they'd be picking xorg and not wayland. You see, official certified drivers are closed-source, and they are buggy as hell in wayland. You seem to assume a workstation is a desktop computer with a gui.
Except many important corporate apps like ̶Z̶o̶o̶m̶, WebEx and Skype still don't work on Wayland.
And why would they ever fix it if users can easily switch back to Xorg?
They won't be able to in RHEL10, they're going to remove it entirely. I presume other distros will do the same in time.
So Debian will keep making bug fixes for X?
It's been rock solid as long as you don't use nvidia cards. It's been great on my laptop, but on my desktop with an nvidia card installed there are always minor annoyances every update (fixed an issue but has another issue appear, etc), probably nvidia driver's fault.
> What a world in which RHEL is more adventurous than Debian.
Always been the case. I don't know why people say the only purpose of RHEL is for enterprise support, or for meeting certifications and compliance. They innovate on the technology a lot, too.
Always been the case. I don't know why people say the only purpose of RHEL is for enterprise support, or for meeting certifications and compliance. They innovate on the technology a lot, too.
[deleted]
Hot damn this list is fantastic, I have exactly 0 complaints. All this stuff has been more than a decade in the making for removal.
I was and still am worried about IBM meddling but Fedora/Redhat is still killing it in pushing Linux forward and being the biggest driver for ecosystem wide changes.
🫡 to iptables for being with us so long, but the future of programmable declarative firewall rules is so unbelievably worth it.
I was and still am worried about IBM meddling but Fedora/Redhat is still killing it in pushing Linux forward and being the biggest driver for ecosystem wide changes.
🫡 to iptables for being with us so long, but the future of programmable declarative firewall rules is so unbelievably worth it.
What's the ubiquitous replacement for iptables? Last I checked every distro had a different declarative firewall rule manager.
nftables is the new underlying kernel system, and the (unfortunately named) `nft` cli to manage it seems to be widely available.
And re: declarative, `nft -f foo` loads rules from the file named `foo`, and some distros like Debian define an nftables service that will use this to load `/etc/nftables.conf` etc.
Or if you want to use firewalld you can configure it to use its nftables backend.
Or if you want to use firewalld you can configure it to use its nftables backend.
I'm very happy to see iptables deprecated, that'll force kubernetes and friends to support nftables instead, a win for everyone!
RHEL itself is deprecated for desktop/workstation use. I last used RHEL in that capacity 10 years ago and even then it was apparent that this was a niche it wasn't well suited for.
The target audience for RHEL desktop/workstation use is government employees. Those people are not supposed to use the computer beyond a narrow scope of tasks. Creativity, self-responsibility, individuality and out-of-the-box thinking is discouraged. Wayland is perfectly suited for that.
Will this affect Fedora or other red hat universe distros?
Fedora defaulted to Wayland quite a while ago. But Fedora doesn’t necessarily always follow Red Hat. RHEL deprecated and removed btrfs support, while Fedora now uses it by default.
> RHEL deprecated and removed btrfs support
Wait, what?? Is that true?
Wait, what?? Is that true?
Was deprecated in 7 and removed in 8.
yes, had to stop using CentOS and switch to Debian for my servers because of that
It wouldn't really surprise me if Fedora followed suite soon, but I have no specific information about that. Hopefully OpenSUSE Tumbleweed keeps X, I haven't heard any indication to the contrary.
I'm not entirely sure, but I'm under the impression that my tumbleweed installation lost X11 months ago and is Wayland only now.
X is still in Tumbleweed, maybe it's not the default anymore but it's still here.
Errrr..... what is it replaced with?
Wayland (including XWayland), according to the link. The language is specific that the Xorg server is what's being deprecated, not the ability to run X11 applications via XWayland.
80x25 terminal, amber.
80x25 is DOS. UNIX terminals are 80x24, and i prefer green.
https://github.com/Swordfish90/cool-retro-term
https://github.com/Swordfish90/cool-retro-term
Nothing. You can use wayland, if you have the same hardware configuration as a wayland developer. Wayland's developers have decided it is feature complete, so if it doesn't do something you need it's apparetly your fault now.
I don't know what the future is of OpenBSD's X Window fork, but it looks like I'd better find out. Wayland won't handle multiple GPUs driving a single monitor.
I don't know what the future is of OpenBSD's X Window fork, but it looks like I'd better find out. Wayland won't handle multiple GPUs driving a single monitor.
It sounds like wayland devs are bad guys. Is there a story behind it?
Wayland is a more versatile protocol. OP is misrepresenting a little bit, the base protocol v1 is finalized but desktop use will need and already does use many standard extensions.
Nothing about being assholes, just a bureaucratic design.
Nothing about being assholes, just a bureaucratic design.
My understanding is that Wayland is more versatile in the sense of how a LEGO set is more versatile than a molded toy. Yes you can do a lot with LEGO, but a LEGO brick is just a LEGO brick at the end of the day. Similarly, Wayland lets almost all the "interesting" bits be up to the extension protocols[1].
[1]: https://wayland.app/protocols/
[1]: https://wayland.app/protocols/
Just like X11 uses Xexts and/or toolkit libraries for about anything.
Wayland devs are the X devs, so there is that.
Also, wayland builds only on the pure kernel abstractions for video drivers (DRM+KMS), which is (was) not supported by nvidia (which instead patched your xorg binary with their proprietary code). No sane person wanted to support nvidia’s way for a completely different render path, so it wasn’t initially supported, until nvidia came to their senses and also implemented the necessary linux subsystems in some of their drivers. So pretty much the same old “Linus middle finger” story, nothing specific with wayland.
Also, wayland builds only on the pure kernel abstractions for video drivers (DRM+KMS), which is (was) not supported by nvidia (which instead patched your xorg binary with their proprietary code). No sane person wanted to support nvidia’s way for a completely different render path, so it wasn’t initially supported, until nvidia came to their senses and also implemented the necessary linux subsystems in some of their drivers. So pretty much the same old “Linus middle finger” story, nothing specific with wayland.
Nobody is a "bad guy," even if we may disagree emphatically with their design decisions. Ultimately, however, we may feel we aren't entitled to those providing free labor to do so in such a fashion that their work product meets our specific needs or aligns with our expectations.
That said, having a bare-bones protocol that fails to include standard features, forcing each implementation to meet users' needs differently, is somewhat disappointing. Anything that reduces functionality for the sake of ease of maintainability is going to be unpopular with end users who have everything to lose and nothing much to gain directly.
That said, having a bare-bones protocol that fails to include standard features, forcing each implementation to meet users' needs differently, is somewhat disappointing. Anything that reduces functionality for the sake of ease of maintainability is going to be unpopular with end users who have everything to lose and nothing much to gain directly.
The core is bare-bones, there are numerous standard protocols since, and many other are in standardization. Here is a site to review their state: https://wayland.app/protocols/
Don't you think it more reasonable that features that will definitely be implemented by every desktop environment ought to be core rather than not fully standardizing on it 14 years later?
https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
Attentive designers would have standardized this in the incredibly obvious way of allowing the user to white list specific apps, logically at install time and screenshot apps would then implement a singular standard that works in version 0.1. Instead we force users to confront and understand the difference between x11 xwayland and wayland in order to figure out why their screenshot app doesn't work or doesn't work well.
This doesn't enhance the case for "regular" people to use Linux.
https://gitlab.freedesktop.org/wayland/wayland/-/issues/32
Attentive designers would have standardized this in the incredibly obvious way of allowing the user to white list specific apps, logically at install time and screenshot apps would then implement a singular standard that works in version 0.1. Instead we force users to confront and understand the difference between x11 xwayland and wayland in order to figure out why their screenshot app doesn't work or doesn't work well.
This doesn't enhance the case for "regular" people to use Linux.
You can’t push through a new protocol that’s already huge. Wayland was deliberately made extensible, programs can properly query about its capabilities, it is actually quite great design.
It’s just the negatives of the bazaar style development, it’s not like we ever had a unified approach to desktops (remember a few years ago how tray icons and whatnot were all different between KDE and Gnome?). There is no entity like apple that can just work on the details in the background and release it overnight and say that from now on this is the supported API. An open source one has to live in the open from day 1. Mind you, the standardization will speed up considerably, the first year of that 14 is very different in pace from the last ones.
Also, screenshots are not a trivial task to get right, sure, here is its buffer is easy. But then will you also implement a screen sharing API separately? Will it just repeatedly take screenshots for like 20 FPS? That was the reason for it taking longer time, but it works very well now.
It’s just the negatives of the bazaar style development, it’s not like we ever had a unified approach to desktops (remember a few years ago how tray icons and whatnot were all different between KDE and Gnome?). There is no entity like apple that can just work on the details in the background and release it overnight and say that from now on this is the supported API. An open source one has to live in the open from day 1. Mind you, the standardization will speed up considerably, the first year of that 14 is very different in pace from the last ones.
Also, screenshots are not a trivial task to get right, sure, here is its buffer is easy. But then will you also implement a screen sharing API separately? Will it just repeatedly take screenshots for like 20 FPS? That was the reason for it taking longer time, but it works very well now.
> remember a few years ago how tray icons and whatnot were all different between KDE and Gnome?
Yes, and then tray icons worked across desktop environments for a few years until Gnome decided that this standard should be thrown out and replaced it with nothing.
I think what many people annoys with Gnome and Wayland is that they control the overall trend in Linux desktops and yet couldn't care less about most advanced and experienced Linux users. But what other Linux desktops are there?
Yes, and then tray icons worked across desktop environments for a few years until Gnome decided that this standard should be thrown out and replaced it with nothing.
I think what many people annoys with Gnome and Wayland is that they control the overall trend in Linux desktops and yet couldn't care less about most advanced and experienced Linux users. But what other Linux desktops are there?
It seems like one of those politics things. Focus on PR to get the randoms behind it and get people to switch, doesn't matter the quality, how you talk about it is what matters.
Do we have a name for this yet? We had "Embrace, Extend, Extinguish" for MS' playbook, but Red Hat's run theirs enough times that it seems like we ought to have a name for it (and it's definitely different from Microsoft's EEE)
The wayland devs ARE the Xorg devs. They all decided that Xorg wasn't worth maintaining because it has too much legacy baggage[0]. The rest is just a bunch of entitled whining users that dont like change.
0: https://en.wikipedia.org/wiki/Wayland_(protocol)
0: https://en.wikipedia.org/wiki/Wayland_(protocol)
It's entirely normal for users not to like change less yet when the benefits are nebulous even if justifiable and accrue to the developers while the users bear costs in terms of decreased stability, increased complexity, and fewer features.
There seem to be a lot of users still. But lots of previous CentOS users seem to head to Ubuntu or one of the CentOS continuation candidates (Rocky, Alma etc).
Hopefully EPEL keeps X alive, like they did with KDE after it got axed from RHEL's official repos. Wayland still doesn't have feature parity with X yet, and at the rate things are going, it still won't by the next RHEL release.
No ipset or iptables? Hard pass. There is literally no reason for them to get rid of something that works, and isn't full of security holes.
Edit: while nftables can replace iptables, I don't know of a replacement for ipset.
Edit: while nftables can replace iptables, I don't know of a replacement for ipset.
Interesting, thanks.
Why does the syntax suck? "ipset add blackhole 192.168.3.4" is far easier to remember than "nft add element ip filter blackhole { 192.168.3.4 }"
Why does the syntax suck? "ipset add blackhole 192.168.3.4" is far easier to remember than "nft add element ip filter blackhole { 192.168.3.4 }"
Hope that wayland will have caught up feature wise at that point.
Almost but not really.
They'll announce Wayland is too old and crufty and they're working on it's replacement instead.
Indeed. Wayland will soon be as old as X was when they decided X was too old and started work on Wayland.
1984 -> 2008 (24 years)
2008 -> Present (15 years)
1984 -> 2008 (24 years)
2008 -> Present (15 years)
Expected.
I still run Xorg... for the steam client and some video games.
I will need a dma-buf/drm/vulkan wayland compositor (like the one on the steam deck), but coded reasonably, namely in plain and simple C.
Nowadays, innovation in software means removing and simplifying, not adding and complexifying.
ELF should be decrecated and replace by something way simpler (for instance putting TLS here was a huge mistake).
I still run Xorg... for the steam client and some video games.
I will need a dma-buf/drm/vulkan wayland compositor (like the one on the steam deck), but coded reasonably, namely in plain and simple C.
Nowadays, innovation in software means removing and simplifying, not adding and complexifying.
ELF should be decrecated and replace by something way simpler (for instance putting TLS here was a huge mistake).
After seeing the headline, I decided to try out KDE on Wayland (KDE on X is my daily driver at home). It locked my tty, displaying nothing to my screens, and I had to hard reset my machine.
I guess Wayland doesn't support egpus? Either way, it really doesn't feel ready for primetime to me.
I guess Wayland doesn't support egpus? Either way, it really doesn't feel ready for primetime to me.
KDE’s wayland support was spotty for a long time, only recently has it gotten more stable. Maybe try it with a newer KDE version, but your experience will not yet be that great. But it’s almost there.
Probably kde.
Obviously they are talking about a server case. No one would do it for the desktop where XWayland is still a major dependency.
One thing where it can be useful on the server though is clipboard forwarding. What is the alternative in the end to end Wayland use case?
One thing where it can be useful on the server though is clipboard forwarding. What is the alternative in the end to end Wayland use case?
XWayland is a backwards-compatibility embedded x server for wayland. It’s always been planned with that in mind, it will not be deprecated the same way windows 11 can run windows 98 binaries.
I believe XWayland is not X.org, although I could be wrong about that.
Have I been asleep at the wheel or is this libvirtd change a RHEL only thing? Last few times I spun up libvirt on Ubuntu, there was only libvirtd. Maybe it spins up the non-monolithic services in the background and I didn’t notice?
The work to split into multiple daemons started a few years ago.
https://gitlab.com/libvirt/libvirt/-/blob/9b8bb536ff999fa61e...
On OpenSUSE Tumbleweed I do have the individual daemons' service units (`virtqemud.service` etc from the `libvirt-daemon-driver-qemu` package etc) but I still use the original `libvirtd.service` that runs `/usr/sbin/libvirtd`. I might look into switching over the weekend.
https://gitlab.com/libvirt/libvirt/-/blob/9b8bb536ff999fa61e...
On OpenSUSE Tumbleweed I do have the individual daemons' service units (`virtqemud.service` etc from the `libvirt-daemon-driver-qemu` package etc) but I still use the original `libvirtd.service` that runs `/usr/sbin/libvirtd`. I might look into switching over the weekend.
systemctl stop 'libvirtd*.service'
systemctl disable --now 'libvirtd*.socket'
systemctl enable --now virt{qemu,network,storage,nodedev,log}d.socket
This is extremely ballsy by RHEL so you know what, I am in support of it.
Will it work? Idk their client base. But its cool they're trying it.
Will it work? Idk their client base. But its cool they're trying it.
I want to switch back to Linux but I keep having gpu driver issues. Everything was fine until I got a 165hz monitor then had random crashes. If the fact I am using gnome on xorg vs Wayland was the problem (who knows, I gave up on debugging) then I'm all for it
I'd rather just use windows and run Linux in a vm then not use the features of the monitor that I bought.
I'd rather just use windows and run Linux in a vm then not use the features of the monitor that I bought.
What GPU were you driving, and were your issues with Xorg or Wayland?
I'm running 165hz + 240hz on Xorg with i3vm or KDE Plasma (kwin). OpenGL compositor with Nvidias drivers. Everything works fine.
I'm running 165hz + 240hz on Xorg with i3vm or KDE Plasma (kwin). OpenGL compositor with Nvidias drivers. Everything works fine.
Using a rtx 3070 with the Nvidia drivers. It worked fine until some update but like I said, I gave up on debugging.
It goes to show that I got downvoted for my original comment. I used to use Linux as my main os for about 7 years, but now my free time is more limited. I don't care to debug these type of problems when I am trying to just use my computer.
At work I remote into a Linux vm, so I'll do that at home as well whether my host os is windows or mac. It works for me.
It goes to show that I got downvoted for my original comment. I used to use Linux as my main os for about 7 years, but now my free time is more limited. I don't care to debug these type of problems when I am trying to just use my computer.
At work I remote into a Linux vm, so I'll do that at home as well whether my host os is windows or mac. It works for me.
Weird, i run a bunch of weirdo displays from 25hz to 240hz and never had any issues, even with nvidia drivers. Tbh i have more bugs with AMD although I perfer their approach more.
Laptop at 165 hz, desktop monitor at 144 and second at 260. All work fine on linux mint x11 with nvidia drivers and kde. No hdr but that's fine.
The most fun thing about Linux is that everything seems to work fine for some people and be broken for others.
My experience is if you buy very common hardware, other people have already driven over all landmines.
I have a fairly typical AMD 3600 cpu and 5700xt with a mid tier common mobo. All stuff that's super consumer and a few years old now. And I still encounter tons of random issues. And updates that break stuff that used to work.
Sure, its a lot worse for brand new laptops. But it never entirely works to the level you'd get from macOS.
Sure, its a lot worse for brand new laptops. But it never entirely works to the level you'd get from macOS.
Well, macos only has to support a low-digit number of sanctioned configs, so that’s much easier. For whatever it worth, I found linux’s device support the very best — while windows does likely have some random binary for a given device laying around the internet, it is often borderline malware, and may not work too well on a newer windows version (though credit where its due, windows’ backwards compatibility is phenomenal). Linux has a vast amount of supported devices out of the box, no “windows is looking for a solution”.
That seems to be the case. But on hardware it works it’s awesome.
Windows has the advantage that there is only one desktop environment and display server, and you will use it.
This is also its disadvantage.
This is also its disadvantage.
[deleted]
And this is surprising… how exactly?
One of the major Linux distributions deprecating the standard Unix windowing stack with no compelling replacement is surprising more or less on its own merits.
Wayland works pretty well, much better in some ways and not quite as well in others. I use Wayland on my desktop simply because it works better and the experience is more janky under X.
Except most major distros have been shipping with wayland as the default for a while now. X has been considered deprecated from a long while now (at least 2019) when all the devs went to go work on wayland
"Finished" is likely a better term than "deprecated."
There is obviously a gulf between setting a Wayland compositor as the default DE/WM and actually removing X.org from your distro's package repository.
There is obviously a gulf between setting a Wayland compositor as the default DE/WM and actually removing X.org from your distro's package repository.
This is overstating the issue. Wayland in 2019 was entirely unfit for purpose due to poor hardware support, inability to scale applications which required xwayland properly or at all, being near useless for gaming, and poor screen sharing support.
Possibly your grandma who only uses her laptop to browse facebook could have used it as long as you carefully ensured she didn't have unsupported hardware AND you felt like explaining one more technical detail that no average us should have to learn about to her.
It appears to be mostly acceptable as of just this year and only if you run quite up to date software.
Possibly your grandma who only uses her laptop to browse facebook could have used it as long as you carefully ensured she didn't have unsupported hardware AND you felt like explaining one more technical detail that no average us should have to learn about to her.
It appears to be mostly acceptable as of just this year and only if you run quite up to date software.
That’s a bit of a misrepresentation, while Wayland indeed had quite a bit of development in the last few years (which is the order of things in the bazaar style of development - the more people use it, the more care it gets), it always supported every hardware linux supported, it only builds on that after all. X just had some hacky way of bundling proprietary drivers for better support for nvidia cards.
Also, scaling of wayland applications worked, that was a major factor of the whole protocol change.
Also, scaling of wayland applications worked, that was a major factor of the whole protocol change.
From my own post
> Inability to scale applications which required xwayland properly or at all
Scaling for wayland applications worked however scaling for xwayland apps absolutely did not. The actual reality is a blurry mess and as you go back further you see more and more apps that only run via xwayland.
Due to the scattered way different features are handled on Wayland nonblurry scaled xwayland apps became or will become available at different times. For instance KDE fixed this issue in 5.26 which became part of Kubuntu with 23.04 released last month. For Debian users this day has not yet come and for many who update their software only infrequently to major releases xwayland apps may take years to become a reality.
> Inability to scale applications which required xwayland properly or at all
Scaling for wayland applications worked however scaling for xwayland apps absolutely did not. The actual reality is a blurry mess and as you go back further you see more and more apps that only run via xwayland.
Due to the scattered way different features are handled on Wayland nonblurry scaled xwayland apps became or will become available at different times. For instance KDE fixed this issue in 5.26 which became part of Kubuntu with 23.04 released last month. For Debian users this day has not yet come and for many who update their software only infrequently to major releases xwayland apps may take years to become a reality.
> it always supported every hardware linux supported
That’s more than a bit of a misrepresentation. In practice, people with NVIDIA cards could run Xorg, and could not run Wayland compositors. You can use whatever wordplay you want to pretend otherwise, but Wayland absolutely did not support all the hardware that Xorg on Linux supported.
That’s more than a bit of a misrepresentation. In practice, people with NVIDIA cards could run Xorg, and could not run Wayland compositors. You can use whatever wordplay you want to pretend otherwise, but Wayland absolutely did not support all the hardware that Xorg on Linux supported.
As I mentioned, nvidia didn’t support Linux. That’s an objective fact, the kernel has an abstraction that allows managing buffers independently from the actual drivers. This was for a long time not supported by nvidia proprietary drivers, as they went their own way implementing a different abstraction.
Xorg was deemed a big enough target that nvidia hacked the driver so that it could be binary patched to make better use of their proprietary drivers, but that was never the proper way of the kernel.
Wayland has nothing to do with it, it builds on standard linux kernel systems.
Xorg was deemed a big enough target that nvidia hacked the driver so that it could be binary patched to make better use of their proprietary drivers, but that was never the proper way of the kernel.
Wayland has nothing to do with it, it builds on standard linux kernel systems.
RIP floppies and scp and sha1 and x11.
Just another reason not to run IBM...
Good. Wayland is ready. Any GPU/DE that hasn't fully supported Wayland should be abandoned at this point.
People should be doing whatever works well for them and makes them productive and happy. If that's Wayland then that's Wayland. If that's Xorg then that's Xorg.
People going around the internet telling other people what they should be doing with their spare time and private computer should mind their own business.
People going around the internet telling other people what they should be doing with their spare time and private computer should mind their own business.
There’s more than just KDE and Gnome out there, you know.
There’s dozens of WMs that have no Wayland equivalent, and at this point seems like they never will. I use Xmonad at work. I doubt we’ll ever see a Wayland port of StumpWM.
There’s dozens of WMs that have no Wayland equivalent, and at this point seems like they never will. I use Xmonad at work. I doubt we’ll ever see a Wayland port of StumpWM.
And before anyone suggests Sway, its multihead support is so laughably bad compared to Xmonad that it makes you wonder if anyone ever tried to use it.
That’s interesting, i3 wm has perfectly decent multihead support, and usually Sway matches it at least.
XFCE doesn't even fully support Wayland...
regarding stumpwm: https://github.com/stumpwm/mahogany
also another cool project: https://sr.ht/~shunter/wayflan/
also another cool project: https://sr.ht/~shunter/wayflan/
It seems like they’re in the process of rewriting it into C? That seems like it would defeat what I found to be the most compelling aspect of Stump, but I’ll likely try it out to see for myself.
Rewriting the backend into C. Writing C in 2023 is a weird choice for sure, but the clisp frontend code seems like it's going to be staying.
> Any GPU/DE that hasn't fully supported Wayland should be abandoned at this point.
Sure thing. I'll just send you the bill for the new hardware, shall I?
Sure thing. I'll just send you the bill for the new hardware, shall I?
The only people left I see arguing for X are Linux zealots that hate any sort of change.
I have a bunch of tools that work only on X and don't have clear Wayland equivalent, so I will have to write it. Thus far I couldn't be bothered. I will only have to find "alternative to [..]" for a number of things, and I couldn't be bothered with that either thus far.
If not wanting to spend hours and hours of work replacing a set of tools that work very well for me with another set of tools with identical functionality makes me a "Linux zealot that hates any sort of change" then I will gladly accept that description.
If not wanting to spend hours and hours of work replacing a set of tools that work very well for me with another set of tools with identical functionality makes me a "Linux zealot that hates any sort of change" then I will gladly accept that description.
Which tools?
xbanish, xcape, xdotool, find-cursor, xclip, dmenu, my somewhat specific hacked-up version of dwm, various specific configurations in X.
Some of these have alternatives that work the way I want, some don't. In either case I will have to spend time replicating the environment I've been happy with for many years by finding and configuring existing tools or by writing my own, all for no concrete benefit.
Eventually I'll have to bite the bullet I suppose, but Xorg works well today and I expect it will continue to work well for quite a few more years. As long as it's not needed, I'd rather spend my time elsewhere.
Some of these have alternatives that work the way I want, some don't. In either case I will have to spend time replicating the environment I've been happy with for many years by finding and configuring existing tools or by writing my own, all for no concrete benefit.
Eventually I'll have to bite the bullet I suppose, but Xorg works well today and I expect it will continue to work well for quite a few more years. As long as it's not needed, I'd rather spend my time elsewhere.
Some of those indeed have alternatives already, but okay it seems you're already aware of them.
Barrier, the Synergy replacement.
Apparently Wayland's architecture makes it an actual hard problem. It's the one tool I rely on daily that is stopping me from trying Wayland.
Apparently Wayland's architecture makes it an actual hard problem. It's the one tool I rely on daily that is stopping me from trying Wayland.
Synergy seems to have wayland support on its recent beta release.
A paid proprietary program is not a replacement for a libre+gratis program.
For me, not a tool but a WM: AwesomeWM
I get better performance (longer battery life, higher FPS in games, etc) with X. I'm not opposed to new software, I now use pipewire instead of pulseaudio. Pipewire is newer and I like it a lot because it actually works better for me. Ever since I switched to it, I've never had a single problem connecting my headphones (which was a nightmare under pulseaudio.)
"People who don't like my software just hate all change" is just a cope cliche line from people who can't out-compete old software on the merits which are valued by users. Instead they tell users that their values are wrong ("Why do you need that?") and then accuse them of hating change.
"People who don't like my software just hate all change" is just a cope cliche line from people who can't out-compete old software on the merits which are valued by users. Instead they tell users that their values are wrong ("Why do you need that?") and then accuse them of hating change.
Games usually don’t go through the traditional compositor cycle of Wayland anymore so there shouldn’t be a difference.
For non-gaming usage Wayland should actually be better for battery life as the protocol is less chatty. Though of course it depends on which implementation you use.
For non-gaming usage Wayland should actually be better for battery life as the protocol is less chatty. Though of course it depends on which implementation you use.
> For non-gaming usage Wayland should actually be better for battery life as the protocol is less chatty.
"should" is one thing, but you're responding to someone who appears to have actually observed the opposite in reality, so that's not really helpful
"should" is one thing, but you're responding to someone who appears to have actually observed the opposite in reality, so that's not really helpful
“Though of course it depends on which implementation you use”.
Also, wayland is huge in the embedded sector, e.g. many car display uses it, specifically because they cheap out on hardware, but wayland still runs just fine, unlike X.
Also, wayland is huge in the embedded sector, e.g. many car display uses it, specifically because they cheap out on hardware, but wayland still runs just fine, unlike X.
> specifically because they cheap out on hardware, but wayland still runs just fine, unlike X.
X was born on Unix workstations in the late 80s and had acceptable performance; there has to be more to it than that.
X was born on Unix workstations in the late 80s and had acceptable performance; there has to be more to it than that.
You no longer draw 3 lines as GUI, nor do you have like a 100 pixels on a screen.
"Everyone not doing it my way is a reactionary"
And us Mac users who still like X[1]
1: https://www.xquartz.org
1: https://www.xquartz.org
If you aren't a Linux zealot then why are you even using Linux? Only slightly kidding ;)
[deleted]
Notices like this give our customers a lot of time (literally a decade) to find replacements for anything being deprecated.