On the Road to Fedora Workstation 31(blogs.gnome.org)
blogs.gnome.org
On the Road to Fedora Workstation 31
https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/
14 comments
Well... interesting if true. Also quite unfortunate, since I rely on xdotool and keynav in my daily workflow. I want to like wayland, but it's rather designed to intentionally break things I'm using.
I presume it could also mean a fork, or someone else taking over X.org, if anyone using the API has an interest in keeping it alive?
I am one of the Fedora 29 users for whom the upgrade to Fedora 30 refuses to run because dependencies of some installed libraries in F29 cannot be obtained for F30. There was a report of this soon after Fedora 30 was released, and someone acknowledged the defect (related somehow to certain library incompatibilities) promptly and said a fix would be out in a few weeks. I don't think that the fix ever came out, but a somewhat inscrutable (to me) workaround was promulgated, which I have chosen not to attempt. Will there be a user-friendly way to upgrade Fedora 29 to Fedora 31 without a full re-install?
All our users are running interactive sessions under X2Go (and it’s far from ideal). Will this still work? Even worse than today? (I could be mistaken but the impression I get from Wayland appears to be a dramatic emphasis on the local desktop with a near-complete disregard of the remote scenario).
CONTEXT: heavy, expensive, licensed EDA tools imposes this usage model and there’s really no way around it.
CONTEXT: heavy, expensive, licensed EDA tools imposes this usage model and there’s really no way around it.
Quite the contrary.
I used to work on a proprietary remote display protocol and the remote X11 protocol is seen as an anti-pattern in that space. X11 requires draw operations to be applied in-order, so every dropped packet means stalling the client draw pipeline.
This is one major reason why other remote protocols use varied strategies that look very different.
Wayland, in many ways, accepts that reality and moves the network-portability away from the core protocol.
Besides, hardly anyone does draw operations on X11 without the Xshm extension now days, so in practice, many apps are not that network portable. The toolkits go through great effort to make it sort of work. Kinda. If you don't look too closely.
That said, you could create a system that supports transparency similar to the old design, but I'm not sure any active contributors are interested in doing so.
One major reason for that is that most applications on Linux take advantage of communication buses while also completely disregarding the idea of supporting multiple sessions by the same user at the same time. So to have an application work over the terminal, get a session (d-bus, seat, etc), and then collide with other apps in a second session by the user doesn't make a lot of sense if at the end of the day the user loses state, or worse, gets corrupted files.
I used to work on a proprietary remote display protocol and the remote X11 protocol is seen as an anti-pattern in that space. X11 requires draw operations to be applied in-order, so every dropped packet means stalling the client draw pipeline.
This is one major reason why other remote protocols use varied strategies that look very different.
Wayland, in many ways, accepts that reality and moves the network-portability away from the core protocol.
Besides, hardly anyone does draw operations on X11 without the Xshm extension now days, so in practice, many apps are not that network portable. The toolkits go through great effort to make it sort of work. Kinda. If you don't look too closely.
That said, you could create a system that supports transparency similar to the old design, but I'm not sure any active contributors are interested in doing so.
One major reason for that is that most applications on Linux take advantage of communication buses while also completely disregarding the idea of supporting multiple sessions by the same user at the same time. So to have an application work over the terminal, get a session (d-bus, seat, etc), and then collide with other apps in a second session by the user doesn't make a lot of sense if at the end of the day the user loses state, or worse, gets corrupted files.
Pipewire is very light on the why. And do not mention Gstreamer. Does it seek to replace it too ?
>GStreamer is intended to be a swiss army knife of multimedia, PipeWire is meant to be much lower level, more like what alsa-lib, JACK or libv4l2 provides.
https://github.com/PipeWire/pipewire/wiki/FAQ#is-pipewire-ju...
>PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It aims to support the usecases currently handled by both PulseAudio and Jack and at the same time provide same level of powerful handling of Video input and output. It also introduces a security model that makes interacting with audio and video devices from containerized applications easy, with supporting Flatpak applications being the primary goal. Alongside Wayland and Flatpak we expect PipeWire to provide a core building block for the future of Linux application development.
https://pipewire.org/
https://github.com/PipeWire/pipewire/wiki/FAQ#is-pipewire-ju...
>PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It aims to support the usecases currently handled by both PulseAudio and Jack and at the same time provide same level of powerful handling of Video input and output. It also introduces a security model that makes interacting with audio and video devices from containerized applications easy, with supporting Flatpak applications being the primary goal. Alongside Wayland and Flatpak we expect PipeWire to provide a core building block for the future of Linux application development.
https://pipewire.org/
I'd be happy if Pipewire doesn't constantly burn CPU the way Pulseaudio likes to, even when no sound is playing. It always annoys me to see Pulseaudio in top, burning 5-10% of the CPU with thousands of hours of CPU time built up.
I've not seen this in the decade of running it on dozens of machines. So chances are there is a bug somewhere related to your hardware or mixer configuration.
Maybe, but nothing I've ever tried has worked and I'm not the only one:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/20...
https://ubuntuforums.org/showthread.php?t=2215353
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/20...
https://ubuntuforums.org/showthread.php?t=2215353
I don't see anyone tracking down what PCM format was written to pulse vs what format the pulse daemon had to write to the driver to determine if format conversion was necessary. Needless to say, the gstreamer->pulse support has changed greatly since 2008.
But as it were, profiling my system (Fedora 30) with Sysprof to look at where time is spent:
But as it were, profiling my system (Fedora 30) with Sysprof to look at where time is spent:
- Roughly about 2% CPU amortized across all cores at idle, but playing an MP3 in rythmbox (so includes shell, rhythmbox, a webbrowser, etc)
- Of that 2%, 7% (so .14%) of that time was spent in the pulse daemon
- .04% (2% of 2%) was spent in libspeexdsp.so and all other samples were negligible
>The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time.
Well, at least it makes it clear how the wind blows these days.