
> replacing PulseAudio
Sold!
Ahead of its release next month, the Fedora community has posted details of what is coming in Fedora 34, Red Hat's bleeding-edge Linux distro. Fedora is where Red Hat tries new features that may make their way into Red Hat Enterprise Linux (RHEL) in future. While sponsored by Red Hat, it is also a community project in its own …
Some questions re. Pipewire.
(A) Have they got away from that stupid nonsense about having to reboot if you fiddle around with PulseAudio?
(B) Has the hand of Poettering been involved with Pipewire?
If the answers are yes and no then that can only be a good thing. I'm not so sure about the rest of the changes though.
are we going to need to fork X11 the way we had to fork gnome 2 into Mate ???
NOT wanting 'Wayland'. It breaks the use of the DISPLAY env variable for remote X11 protocol, which _I_ _USE_ _ALL_ _OF_ _THE_ _TIME_ for doing things *LIKE* using a GUI editor on source files on an embedded system that either has too tiny of a screen or is running headless.
And don't even *SUGGEST* that a bloatware like Wayland and a non-solution like "cloud server" would even REMOTELY make it possible to do the same thing...
another good alternative in the X11 world is tigerVNC server, which can implement the entire desktop on a headless system, or allow for a secondary desktop on the SAME system (with vncviewer to display it). But of course, it's X11 protocol.
<snark>
But, then again... we gotta have CHANGE for the SAKE of CHANGE. I forgot.
</snark>
counterarguments: optional. still have X11. [for NOW, yeah]
might I remind you all:
* systemd
* Pulse Audio
* Gnome 3
any questions?
I completely agree with you on the exporting DISPLAY thing in X11. I'm sure that there must be design reasons for Wayland not to have similar functionality. Stuff like VNC, RDP, and even Citrix gubbins can replicate some of the functionality with a fairly small footprint.
I've not looked at tigerVNC. I just use xrdp for my work Citrix -> Linux desktop needs. Thanks for the tip.
At least they're trying to kill Pulseaudio though right?
I love watching the trolls as much as the next man but I cannot overlook this point. On my machine Wayland's package is 0.75MB whereas xorg-server is 3.65MB. Minute differences might exist from computer to computer but clearly X11 is *by far* the bloated one here.
nonono
Even though I've never even looked into wayland I will hate it and spew nonsense in the comments because change is bad right?
*sigh*
The discussion of display protocols is always so stupid, that I prefer to listen at what the developers have to say, and most comments I've heard is that wayland fixes a lot of issues (tearing/performance/latency) at the cost of being very small.
That and apps can't spy on your keyboard inputs even out of focus. Oh and they can't query your cursor position at all times.
Sure, X11 carries lots of baggage – show me Wayland after 35+ years and then we can compare.
Also, one reason why it is smaller (beside X11 containig lots of stuff quite irrelevant nowadays) is that pretty much everything X11 does is against the Wayland philosophy – forwarding, making screenshots, programs positioning their own windows, … Yes, I am aware that many of these things can actualy work in Wayland. The developers are not completely Poettering-level insane. Fortunately. But anyway…
X11/Xorg has shown its strength by integrating lots of things no one even dreamed of in the 80s. Sometimes seamlessly, sometimes less. I am looking forward to its 40 year anniversary.
From what I know xorg is pretty much unmaintained and X11 is even worse, that is the reason that things are changing.
If you want to keep old stuff then you need to have enough competent people to work on the code and ensure it gets fixes and features that allow it to interoperate with the rest of the world.
not downvoting you. You have expressed a discussion-worthy common misconception about Xorg and whether or not it is being maintained or has a future. If necessary, it would be forked like Mate.
My actual *FEAR* here is that (for some reason) Fedora is now RH-beta, and RH seems to carry actual WEIGHT whenever their engineers foist something upon the POSIX OS GUI desktop world.
For normal workstation I use FreeBSD. For Linux I use Devuan, and Raspbian/RaspberryOS when I have to. I reject as much of Poettering's contributions as possible.
Also, keep in mind, that change is NOT always a GOOD thing. Sometimes it's called "going bad" or "rotting". When your primary focus is GETTING WORK DONE, you do NOT need your tools to change shape and/or appearance and/or functionality, requiring you to RE-LEARN for an extended period of time INSTEAD OF DOING PRODUCTIVE THINGS. And the use of DISPLAY is one of those productivity things that means _I_ will _NEVER_ use Wayland until they implement it!!!
For size you need to consider that the modules included with Xorg support many obsolete displays, and drawing code that supports them [example, VGA 4-bit planes] whereas a "modern" display is probably 24-bit or 32-bi RGB or RGBA and the code to manipulate individual color pixels is MUCH simpler than it was for 16-color VGA. That doesn't even mention the myriad of display drivers...
In any case, this Fedora release is probably an indicator of where RH wants to take us. I may not want to go along for the ride... at ALL.
Not really sure that I understand the bloatware accusation. Wayland is far, far closer to the UNIX philosophy of do one thing and do it well. The X11/X.org ecosystem is all encompassing (display, networking, pointing devices, keyboard): it is the king of bloat.
Whereas Wayland is a way to efficiently handle display.
X apps will still be handled through an X11 client and I expect it to eventually become redundant.
The X Window System is very modular - that's why it's lasted so long - so I'd argue it is in line with the Unix philosophy. That modularity starts with the X protocol itself, and it's quite neat how a lot of add on functionality degrades gracefully if a client and server have differing support for extensions.
What X suffers from is that the X protocol is very "chatty". This has been why a lot of extensions try to do as much as possible server side to save on too many messages flying back between client and server. Ironically, that chattiness is not a problem when client apps are on the same host as the X server, and Wayland doesn't support network transparency - my biggest bugbear with it.
Wayland is only replacing one part of the X system, and as at least one other commenter has mentioned it's not really fair to compare binary size when Wayland has only a small subset of the Xorg server's functionality. So to paraphrase a well known saying, I can't help feeling that those who misunderstand the X Window System are condemned to reinvent it poorly.
On the graphical front, many client applications these days use very little of the features that X11 offers and use it merely as a compositor, which is does fairly badly, which I think is what you're hinting at.
Wayland/Weston is trying to produce an implementation that offers what most real clients actually do in the modern world.
Many people are bemoaning the loss of network support etc and although I would admit that it is handy, most Linux users do not use these features and for those that still do, will still be available through an X11 client. That use case is likely to be a bit more involved to set up I grant you.
Something *had* to be done. For n-up displays and games and a variety of other aspects, X is crufty as hell and hinders more then helps.
Ive been using Linux on my workstation and my laptop for 5 years or so now. X11 is *fine*, but PulseAudio is a complete mess. Where X11 falls down is handling multiple GPUs properly and HiDPI support, which I do admit is down to the desktop environment/display manager I am using. Oh and not to mention the whole weird configuration of it all.
I'm currently on 20.04 with Budgie on top of GDM and whilst I can technically use Wayland, it doesn't work quite right outside of Gnome. But with 7 virtual desktops and it all setup right once you go past a certain number of windows the whole thing crawls to a juddering mess on a dual E5-2660 v3 20 Core setup.
Running Gnome with Wayland is super smooth, things seem snappier despite the fact it is the more heavyweight DE. Real world numbers I can't provide but I think given the kind of stack I would be measuring the only metric can be snappiness/responsiveness; super subjective I know. I find X11 just seems to lag or judder at times, no matter what DE/Display Manager you are using. I didnt *feel* this with Wayland until the system was entering swap and was under extremely heavy load, but the juddering wasn't as jarring.
I'm going to try a test move to Fedora 34 using KDE on top of ZFS. PulseAudio on 20.04 is broken and I think Wayland needs the support of people using it for it to get to where it needs to be. As for X11 forwarding, VS Code over SSH is far superior IMHO and NoMachine is superb as well. I imagine Wayland will screw me on NoMachine Virtual Sessions though. Oh and everything over WireGuard keeps it uber secure. Haven't needed X11 forwarding for some time now.
Wayland will make Linux useful for watching videos and playing games without having to choose between tearing or dropped frames. It’s a key part of modernising the stack to compete with Windows 10 (in terms of GUI performance) and macOS (GUI isolation between apps) by providing a solution which combines the best of both worlds. When the GNOME implementation is fully baked without a need for Xwayland, I can see Linux in a strong position to compete with the other industry titans.
Speaking as someone who first used Linux on an Athlon XP 2000+ and who later spent many of his teenage years (and a little beyond) playing Tremulous, I cannot emphasise enough how much of a fundamental improvement the GNOME Wayland implementation is even in an early, lackluster form. Seriously, Xorg was like the aRts of the graphics world, it just got in the way of everything, needed a dedicated key combination to kill itself whenever it had a hissy fit and was prone to full screen lockups (remember using Konqueror as your web browser anybody?). The folks begging to keep it around clearly don’t remember what it was like in its “prime” and only see the kludge-filled workarounds made by GTK and Qt devs which give it the illusion of polish and stability...
No, flatpak apps don't share libraries. Each app is bundled with all it's dependencies, resulting in multiple instances of the same libraries on a machine and a massive increase in memory usage. The security aspects are a nightmare - rather than updating one instance of a shared library installed at OS level, you've got to hope that the maintainer of each flatpak will update in a timely manner. Exactly the problem that DLL hell causes.
You don't know what you're talking about.
DLL hell refers to the way windows used to insist on only one, correct, version of a library being used. You wanted to use 1.2 in one app and 1.1 in another? No way, the OS will only allow one to be installed.
That is dll hell.
What you're talking about is the exact opposite, the solution to dll hell, which is "each app keeps it's own dependencies, separate to every other app". One needs 1.1, it ships with 1.1, another needs 1.2 and ships with 1.2. This was marketed as "xcopy deploy" by MS and promoted as the solution to dll hell.
You're touting a solution that causes dll hell, shared dependencies.
The best solution I've seen so far is how pnpm handles it. That keeps a list of all dependencies and maps them into projects as virtual folders. So you can have four apps sharing a version of 1.1 and another couple of apps using a shared version of 1.2. No wasted disk space but you can still use multiple versions of the same library.
"DLL hell" cuts both ways, apps bundling their own (out of date, insecure) versions of libraries, as well as apps assuming a certain version is installed at system level. That second situation is exacerbated by the poor support for versioning of DLLs.
As for pnpm, looking at how that works it strikes me as a complete clusterfuck. Just as I'd expect from JavaScript.
Pipewire - interesting. I have long standing grumbles about Pulse or Alsa not being able to reliably talk to either external FW/USB interfaces; or even make use of all the features on an internal one.
I'd love a new audio interface but picking one right now for Linux life is painful. 828Mk3 soldiering on for time being.