Functionality that has been deprecated in Red Hat Enterprise Linux 9(access.redhat.com) |
Functionality that has been deprecated in Red Hat Enterprise Linux 9(access.redhat.com) |
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 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?
apt depends xwayland
xwayland
Depends: xserver-common
...
But it mostly pulls some extra dependencies like x11-common and xkb-data and etc. So may be it can be split out.
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.
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.
🫸🫨🫷
Or if you want to use firewalld you can configure it to use its nftables backend.
1984 -> 2008 (24 years)
2008 -> Present (15 years)
Wait, what?? Is that true?
> [vo/gpu/wayland] GNOME's wayland compositor lacks support for the idle inhibit protocol. This means the screen can blank during playback.
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...
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.
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.
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.
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.
cp -r foo/* bar
rsync -a foo bar
rsync -a foo/* bar
rsync -a foo/ bar/
rsync -a foo bar/
rsync -a 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:
rsync -a foo/ bar
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).
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)
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.
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.
Doesn't work with legacy applications... but neither does Wayland so you aren't really behind.
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.
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.
Also, scaling of wayland applications worked, that was a major factor of the whole protocol change.
> 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.
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.
"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
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.
X was born on Unix workstations in the late 80s and had acceptable performance; there has to be more to it than that.
Sure, its a lot worse for brand new laptops. But it never entirely works to the level you'd get from macOS.
Humans can clearly do it, so corporations could too. The organism responds to its environment.
So we never do. Nothing will change that other than enfranchising your people, other than upsetting the top-down hierarchy.
> 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...
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
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.
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.
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.
And before anyone says it, no "rolling release" doesn't mean "unstable".
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.
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.
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.
*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.
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?
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...
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.
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.
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.
Lets not even talk about trying to use Wayland in a VM desktop -- Even Firefox/Chrome don't render properly.
I'll try Wayland again this next semester, see if anything has changed.
But RHEL didn't even set a date for removing Xorg support so it will probably stick around for a long while.
Eh... pip+pypi killing support for python2 is kind of a big problem for continuing to use it unless you have zero external dependencies.
Nothing about being assholes, just a bureaucratic design.
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.
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.
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.
I don't believe I, and the many users who share my preference, deserve insults for that.
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.
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?