Notices like this give our customers a lot of time (literally a decade) to find replacements for anything being deprecated.
Ask how I know.
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.
"Ship it" in EPEL, sure, but support to Red Hat is a contractual obligation.
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.
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.
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 ...
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.
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.
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.
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."
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.
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.
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.
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.
[1] https://support.zoom.us/hc/en-us/articles/6634039380877-Zoom...
[2] https://help.webex.com/en-us/article/9vstcdb/Webex-App-for-L...
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..
Debian on the other hand cares about keeping desktop users happy, so it makes sense to support both.
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.
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 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.
Edit: while nftables can replace iptables, I don't know of a replacement for ipset.
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 }"
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 guess Wayland doesn't support egpus? Either way, it really doesn't feel ready for primetime to me.
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?
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
Will it work? Idk their client base. But its cool they're trying 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'm running 165hz + 240hz on Xorg with i3vm or KDE Plasma (kwin). OpenGL compositor with Nvidias drivers. Everything works fine.
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.
This is also its disadvantage.
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 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.
also another cool project: https://sr.ht/~shunter/wayflan/
Sure thing. I'll just send you the bill for the new hardware, shall I?
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.
"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.
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.