Fedora 25: With Wayland, Linux has never been easier (or more handsome)
arstechnica.com
arstechnica.com
>There are some things to bear in mind about using Wayland with GNOME, especially since more than a few GNOME hacks won't work anymore. For example, take desktop icons. These aren't really a GNOME 3.x thing, though you could use Gnome Tweak Tools if you can get them, but they are not supported in Wayland and never will be. I've also been unable to find a clipboard manager that works properly under Wayland. The other problem I've run into is that neither of the tint-shifting applications I use work with Wayland. Neither f.lux nor redshift do anything when running under Wayland. Judging by posts from around the Web, video playback is sometimes an issue too, though I have not actually experienced this problem. In terms of hardware support and Wayland, I would definitely suggest sticking with kernel 4.8.x or newer, which is exactly what Fedora 25 ships with. The other major gripe I have with Wayland is that it doesn't appear to support fractional scaling for HiDPI screens. It works great at 2X, which covers most screens, but there are those where 1X is too small, but 2X is too much. If you have a screen that works best at 1.5X, you might want to stick with X for now. Those are, however, relatively minor issues.
So desktop icons, no proper clipboard, no fractional HiDPI scaling, video playback issues, and those are "relatively minor issues"?
The only actually "relatively minor" issue he mentions is the lack of screen-tinting support (a la f.lux). The above seem quite major to me...
OSX uses slightly different trick - it creates a framebuffer that is @2 scale and lets the hardware to scale it down. (iOS goes even further and has @3 scaling).
Which is the right approach - for example, one of the rMBP options is to have 1440x900 (2880x1800) resolution, which to the native 2560x1600 is the ratio 9/8. Nobody is going to track that 9-th pixel for each block of 8 pixels in software. Using hw scaler is simpler, cheaper and has smaller margin for errors.
Frankly, implementing fractional scaling is waste of time, resources and would produce software that is slow, buggy and bloated.
The fact that the framebuffer size is not the same as display resolution is known only to the driver and it is not something that is requested to be implemented for Linux.
Well whatever the case might be, whether it's kernel's fault, GNOME's fault, Wayland's fault or device driver fault, fact of matter is that one can easily get 1920x1200 resolution on Retina Macbook 15" with sharp font and images, and cannot on Fedora. This is why perhaps people are making "a fuss".
OS X CAN do fractional scaling as far as user is concerned (doesn't matter who scales it up or down), while Fedora cannot (with Wayland, at least).
It doesn't matter whether they know it or not, since they work transparently great with the scaling factor. In fact it's even better than having the software stack aware of it (simpler, less room for errors).
The end result is that fractional scaling resolutions works on OS X and not on Wayland (from what I read, haven't checked Wayland myself recently).
Thanks.
Yes it does. It's right there in the system preferences.
On my XFCE 4.12, with clipboard managers, if I copy from, say, Firefox, then close it, the content of the clipboard disappears.
If it's the same with Wayland, then having a functional clipboard manager is a big deal (at least, as much as such copy/paste operations are).
Perhaps you are just an administrator spending 24/7 on the command line, but I assure none of those are uncommon...
On the one hand this is better than the security free-for-all which is X. On the other hand it breaks a number of useful tools, and at the same time I've never (provably) seen an X exploit in the wild.
However it's the lack of network transparency which stops me from using Wayland in the foreseeable future.
The fact that keyloggers exist on Linux is because of X11's security model.
X is not network transparent, and hasn't been for a long time. https://www.youtube.com/watch?v=cQoQE_HDG8g
ssh -X is hardly "everything". Not to mention that in the Wayland model, forwarding will be handled by the compositor (not Wayland) because the compositor knows what is actually happening on the screen -- lobby GNOME and KDE to add support for remote sessions rather than bashing Wayland for no reason.
It's damn close. How many apps do you exclusively use locally? A terminal emulator, maybe a web browser?
There are engineers out there who are expected to never have work product on their laptop. The age of one computer per user ended a long time ago, and I'm worried how Wayland has been handwaving the normal use case.
I mean, I don't use graphical apps enough to care -- ssh/mosh is good enough for me TBH.
> The age of one computer per user ended a long time ago, and I'm worried how Wayland has been handwaving the normal use case.
But it isn't. Implementing "-X" functionality into Wayland wouldn't make any sense -- you want the window manager to implement the forwarding because the window manager knows about the window you want to forward.
The fact that X has this functionality is an accident of history. ssh -X is worse than VNC because at least VNC has some semblance of a sane protocol.
People keep saying some other part of Wayland will implement remoting. As far as I can tell nobody takes it seriously enough to work on it, and without remoting I can't understand why any non-gamer would try to use Wayland.
Even on my current single user machine, I still run multiple X servers (one for my work related stuff and one for non-work. I work remotely so that way, I can just switch X servers at the end of the business day).
Can Wayland support multiple terminals on a single machine in the same way? Can you have two Wayland instances running like you can with X servers?
It does speak to having way more compute resources than you can consume at a given time.
A similar moment of humor occurred when AT&T's U-verse product offering was bragging about sending your video signal to other TVs in your house wirelessly.
So the next engineering question is "How does this make things we want to do, or have done, better or different?" I could imagine you could set up a very interesting pair programming setup that way, especially if you were projecting a common "third" monitor on the wall or something. That common monitor could show current status for both programmers like building/testing, source code state, etc.
Just that rather than manually configure it, it will be automatically (they hope) configured by combo of systemd, polkit and your DE of "choice".
Damn those freedesktop.org people!
The rest of us just want our own systems to run as well or better for our own usecases as they currently do. Wayland is a great opportunity to rearchitect the Linux display system rather than organically grow it as X11 has over decades. But if you don't take into consideration those of us who use our Linux workstations as more than a Facebook machine with SSH preinstalled; you're just going to recreate the problem.
People will start disregarding freedesktop, Wayland and so on and either stay in X or using a Wayland compositor that couldn't care less for standards and short-circuit every single convention and security protocol you have designed as long as it lets them get shit done, because at the end of the day, as beautiful as we like our code to be and our software to be architected; people want their systems to work for them.
Ugh, there actually are people who enjoy the GNOME desktop, so maybe don't present your personal opinion as a collective sentiment. As an owner of a MBP, I can tell you that I prefer GNOME in speed, workflow, look, customizability - you name it. In what way exactly is GNOME like macOS in your opinion?
Well, speak for yourself. Which seems to be the loudest voices in these debates, people speaking for themselves.
Wayland solves real, systemic issues in windowing, most notably around security, that need to be solved. It also allows outsourcing of many of X's most unwieldy features to the clients (IPC, rendering, and networking). In many ways, Wayland is closer to the Unix philosophy of one program/one task than X while also being safer to use.
And, it's not like you need to drop X, just like you don't need to drop init. The beauty is that you can continue to use and maintain whichever you feel are the best tools.
> People will start disregarding freedesktop, Wayland and so on and either stay in X or using a Wayland compositor that couldn't care less for standards...
I feel like the same things were said about systemd a few years ago and here we are, every major distribution uses it out of the box. And every windowing system and graphical toolkit supports Wayland, long before Wayland was a default. Though I'm not an expert in graphical compositing and rendering, I can't imagine this is by accident. Numerous projects must feel the technical advantages of Wayland outweigh the disadvantages of change.
That's exactly my sentiment and I brought it up in the comment. The problem is designing these protocols without regard for how the thing you're replacing is being used. That's only going to result on a pile of hacks. It's just baffling how short-sighted some of the Wayland devs are when the project was born precisely because of these hacks accumulating in X.
> And, it's not like you need to drop X, just like you don't need to drop init. The beauty is that you can continue to use and maintain whichever you feel are the best tools.
Oh yes, because obviously everyone wants to maintain 10 different code paths so it's not like Red Hat is pushing their software with their influence over the ecosystem oh no no. But enjoy maintaining those shims, we sure as hell don't care about standards! Gotta move fast, break things and compatibility is for losers.
>I feel like the same things were said about systemd a few years ago and here we are, every major distribution uses it out of the box.
And it's just been dandy isn't it? We still don't have stable interfaces between its parts (yet they still have the gall to say that systemd isn't monolithic), good effin luck debugging it when it shits the bed... list is long, but pick your poison: http://without-systemd.org/wiki/index.php/Arguments_against_...
Negative points will be awarded on "works for me".
> And every windowing system and graphical toolkit supports Wayland, long before Wayland was a default. Though I'm not an expert in graphical compositing and rendering, I can't imagine this is by accident. Numerous projects must feel the technical advantages of Wayland outweigh the disadvantages of change.
The premise is great, what's not to love about it. The problem is execution. Because of Wayland's model, a lot of applications relying on X's nature are left out in the dirt. Standards are the way to solve this, and some work is being done about this, but the comment I replied on by coldtea simply shat on all this with a message akin to "Don't stop the momentum, you're a minority FUCK YOU we don't care about you get on board or get ran over". This is what I was criticizing.
We need standardization. Ideally we have a single solution that improves on the status quo and we call it a day; but where there's disagreement let's find our middle ground and standardize it. If you don't need 4 mice and 4 keyboards working simultaneously great! But what you find useless and nonsensical can be the greatest fun ever in a 4-player co-op session of Serious Sam 3 for groups of friends around the world; or just as well prove to be one of the most productive formats for groups of people working together in a local application.
Can you really blame X developers for not wanting to maintain something painful?
It's fair for them to focus on things that will please the majority of users. Not everyone are happy with using 40-year-old technology for their daily needs. But this is open-source; contribute if you like it.
> We need standardization. Ideally we have a single solution
X has its own barely readable standard, and Wayland is a separate standard protocol which is unavoidably incompatible. The core X protocol makes assumptions that are no longer valid, and its maintainers have tried patching around it for dozens of years without breaking the standard, but many issues were simply unsolvable.
And I mentioned it plenty of times: But I like the idea behind Wayland, and think it's a great thing that the display system is finally getting rearchitected and rewritten.
My problem isn't "I no longer have X", my problem was the attitude of "Wayland doesn't have to care about non-average users when replacing X" which I was previously responding to.
Say hello to RH fueled code churn. First it was powerkit, then it was powerd, and now most of it is found inside systemd-logind. Want to power down the computer by clicking a button in the DE, you need systemd-logind, powerd as a wrapper (for now), polkit, and dbus to glue it all together.
That or you can forgo building your default distro install around any of the major DEs.
The CADT that JWZ railed against a decade ago have gone supersonic, and heading towards superluminal.
I really fear for the day Torvalds hands off the maintenance of the kernel, as he is likely to hand it to someone that is already very accepting of this churn.
Edit: BTW, it seems the BSDs still rely on hald. Maybe i should bite the "apple" and move on over.
The whole reason people switch to Linux in the first place is for uncommon use cases.
Well, I beg to differ.
On the server, that's not true. People use Linux for the most commonplace use cases (e.g. the LAMP stack) as well.
On the desktop, that's what needs to change, and has been promised to change since 1999 ("next year will be the year of the Linux desktop" which has been endlessly repeated was not about some outliers using it for "uncommon" use cases, but about mass adoption).
But the whole critique is wrong too. When I said about "improving common uses cases" to the detriment of "uncommon uses cases" the former wasn't referring to features different people use. The people who use those "uncommon use cases" ALSO suffered from the crappy implementations and shortcomings of the common use cases like everybody else.
On the desktop Linux have a twofold problem. No prominent presence in stores (observe that Android, being a Linux derivative, have a massive presence, and the rise of ChromeOS) and a lack of commitment to API stability from the major lib devs (again contrast Android, where you have versioned APIs going back to the early days).
Interesting.
First, just because something is common (multitouch laptops), doesn't mean something similar is equally common (multiple mice).
Second, those multiple mice weren't used for a person controlling multiple pointers at the same time, but for multiple people using the same computer in different window sessions. So not like multi-touch at all.
Third, even if multiple mice used at the same time by the same person was what we were talking about, it doesn't follow at all that it would be as convenient and approachable as multi-touch to have it be something more of an edge case.
You can use Xorg as you always did, Wayland is fully optional.
> They did it with systemd
What part of hacky, inconsistent, non-dynamic and hard to maintain InitV shell scrips do you actually miss in systemd? Or do you just hate it because it's cool, like it was with PulseAudio?
The others where just files in some server, used by almost nobody.
Ohh, and in some cases even the files have been lost: http://git.einit.org/
For now...
I don't dismiss your points at all, just showing wayland is not a subset of X.
That's the point. It'already automatic.
I haven't even mistakenly opened xorg.conf in at least five years.
And quite franky, I see no need for another thing like Wayland to add entropy to the GNU/Linux desktop.
> by combo of systemd, polkit and your DE of "choice"
eh...
I'm sure the merits can be discussed, but security is a need that Wayland addresses.
These then try to tie a video output, and at least one input device (mouse, keyboard, whatsnot) to a specific seat (as defined by systemd-logind) so that only associated (systemd-logind defined) sessions can interact with them.
Note that all this happens above the kernel, that (as best i can tell) do not have a concept of a seat, and sessions are tracked on a tty basis.
And ttys used to be physical devices connected to the computer via a serial connection (and still can be even on Linux, nice for getting those early kernel errors onto something that do not go poof the moment the GPU driver code do a belly flop).
Never mind that X was designed to work as a graphical tty of sorts. Thus rather than try to stuff raw bitmaps down the wire, the client code running on the computer would send draw command primitives (line from X,X to Y,Y, square with top left corner at A,A and bottom right at B,B, that sort of stuff) that the X server sitting on a desk somewhere would turn into a GUI.
I think Xscreensaver still use that for drawing the "screen lock" password prompt and launch popup.
If I understand correctly from following the Gnome and KWin blogs, in Wayland it looks like the "window management" job is with the Compositor, which takes on a lot more of the display and input work that was traditionally handled by the X Server. So there's much more complexity to handle there. This would mean that we're unlikely to see the proliferation of WM experiments that X saw.
Is this a correct assessment?
(I'm personally waiting for a good tiling window manager/compositor to show up with Wayland before I make the swtich)
And E has a long history of supporting just about anything under the sun. You could even run its terminal "emulator" as an alternative tty on top of the Linux framebuffer if you so wanted.
I recall Rasterman running afoul of pretty much every organisation he was part of... I recall issues with OpenMoko, an early linuxphone company, as well.
[0]:https://wiki.archlinux.org/index.php/Wayland#Window_managers...
This is basically right. However, you have to remember that the Wayland protocol is at least an order of magnitude (if not two) smaller than X11. It's also defined/specced using a machine-readable XML document which means that an implementation of the protocol can basically be auto-generated from the spec document -- thus making it a lot easier to keep your implementation up to date.
> This would mean that we're unlikely to see the proliferation of WM experiments that X saw.
Remains to be seen, I guess.
Wayland, X11, SVGALib, F if i can tell a diff...
[1] Alright, there might be a few bits and bobs that are missing, but nothing major as witnessed by the very article under discussion.
Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines?
There's no conceivable reason (these days) that you'd want to send a "draw a stippled line from point a to point b" command to an X server or graphics card.
But the major toolkits have taken to rendering everything outside of X and just dumping the result as a bitmap into a box, that is absurd for all but the most local of work. And yet they complain about X being the problem.
X is not the problem. The problem is a generation of devs coming over from MS and Apple platforms and not recognizing that X is different. They just want to dump their eyecandy into the buffer and rely on Moore's Law for things drawing more than 1 pixel an hour.
Just about everyone who has worked seriously on Linux graphics agrees that X is a problem and Wayland is the solution. You might want to look into why they all say the same thing.
Meanwhile, Linux still had blitted windows that left a grey trace for a brief instant when you moved them, and pixelwise window edges, and terrible transparency.
Came along Compiz, which reversed the way clients interacted with X, and which did the slick animations and fancy graphics of the mainstream OSes. What was the only way it found to do that? Rendering everything outside of X. And nobody could do it with the old design. So that design was quickly adopted by KWin and so on.
It turns out that nowadays screens are not lightweight clients over a serial line, and they have more than double the number of pixels of VGA.
Compositors became a necessity for the Linux Desktop to compete, reducing X to an IPC system that it cannot be good at, because it is not the situation it was built for. Wayland is built for the status quo.
or someone?
> I am sure that if you poke around you will find someone still relying on those features being present daily.
Not really. Many of these things have been broken in X.org for years and years... because nobody used them! (Again, see the talk.)
There's also the whole abysmal security record of X11[1], due in large part to the huge API and the fact that all serialization/deserialization of requests is hand-coded (by necessity).
It looks like the Awesome community currently has no plans for a Wayland port -- as it apparently wouldn't be trivial. Though someone mentioned that it might Just Work as a magical legacy X application. Can anyone confirm that?
SirCmpwn is porting i3:
> SirCmpwn is porting i3:
It's not a port, it's a complete rewrite. You can't port i3 just because of all of the differences between X11 and Wayland.
Also, I would recommend anyone who uses SirCmpwn's several projects that they donate to him (he even made a free software project for dontations): https://drewdevault.com/donate/
Another competing packaging format. Why?
If you want to run something without installing it as a distro package the option was always to download it as a tar-ball.
BTW, Flatpak is a Gnom/freedesktop creation. It is a reaction to distro maintainers overriding the "perfect" decisions made by upstream (Gnome devs etc), and is upstreams attempt at taking over control.
Gnome+Freedesktop is aiming to make a singular Linux desktop experience, for all the wrong reasons.
I'm not a fan of Flatpak (Nix/Guix for the win), but this is completely incorrect.
Static bundling predates UNIX. It's long known nightmare. New developers are not familiar with static bundling, so they thinking that they are «moving forward».
Is it impossible to fix the tearing and smoothness issues of Xorg/X11?
The plus side is that I can log into using either Wayland or Xorg. So switching between the two is almost seamless.
Thew basic thing is that different clients can see those inputs because they live inside the same root window. Give each a different root window and the issue "magically" disappears.
I'm not sure if this also affects the desktop environment (looks like it does from the machine I'm using). If so, this mean s that there is a working solution.
Tearing in games is an entirely different beast, as other factors come into play (most notably, latency) - besides, games have specific option[s] for that.
Edit: FC25
Thanks though.
Or by using PowerTop/TLP
https://fedoramagazine.org/saving-laptop-power-with-powertop...
One positive thing I can say is that they seem to have accomplished what they wanted with Wayland -- unlike earlier X-based distros I have tried out, rendering smoothness seems pretty much on par with macOS (unlike Windows, which still flickers and stutters a lot).
And fedora, last time I tried it, didn't have smooth font by default ! (it was version 23 if I remember correctly)
You can resolve that by installing freetype-freeworld package (which has exactly the same freetype library, just with one #define flipped), that is offered by some repositories, or you can get a HiDPI display. Which, if the reading/writing text is important to you, you will want anyway.
Distrowatch says Fedora 25 uses an older Freetype2, I think the patches are available to toggle on.
http://theinvisiblethings.blogspot.de/2011/04/linux-security....
is now solved?
What's the draw of Arch over Ubuntu/Fedora/Mint, etc?
The AUR is a far superior system than PPAs and offers far more software than I've seen "natively" available for any other distribution ever.
They're all completely up-to-date (kakaoune might be an exception because it just builds HEAD since there are no releases).
I regularly observe AUR getting packages before the equivalent PPAs and before ubuntu packages are even updated. Even for security releases.
But you're certainly right, it depends on the given package maintainer. In the rare case that updates take more than a day or two, I just pull the PKGBUILD, edit it, makepkg, pacman -U and I'm done.
On the other hand, I could list hundreds of packages that are a version or two behind in Xenial that are update to date in Arch (not even AUR). Maybe not security fixes, but sometimes important bugfixes, etc. For example, Qemu in Xenial, can't make VHDs for Azure, which is constantly a thorn in my side (qemu takes a long time to build from source, even if you disable all non-x86).
But if something breaks in Arch, I can almost certainly just open up the wiki page and fix it. Ubuntu keeps breaking stuff over and over again that I just don't know how to fix.
EDIT: Thinking about it, a lot of those issues probably also come from the fact that I usually don't reinstall my OS. With Arch is designed for, but Ubuntu/Fedora/etc. not so much.
LOL. Debian has one of the best automatic upgrading procedure long before Arch is born. RedHat/Fedora was not good at automatic upgrading between releases when an conflict happens, but it was doable with third-party Smart package manager. Now Fedora supports upgrade out of the box. I never ever reinstalled any of my Fedora or Debian distro just for upgrade.
Fedora on the other hand just doesn't, or at least not in my typical usage. Maybe third party package managers would help in that regard, but if I'm going to babysit my distro I'd rather have something I can understand, like Arch.
Smart packager is not necessary anymore. Default package manager dnf is smart enough. Smart was good because it is crossplatform (deb/rpm/tgz packages and apt/yum repos were supported), with both console and graphical UI. It also provides smart changesets, like dnf does now.
But really, the documentation is the best of any GNU/Linux distribution, bar none. There are very few things I cannot figure out by going to the arch wiki.
[1]: https://docs.fedoraproject.org/en-US/Fedora/25/html/System_A...
Arch also has the AUR (Arch User's Repository) which provides a lot of software that isn't available through most distributions for various reasons, such as quality, stability, maturity, patent, freedom or packaging/dependency issues. This makes customization a lot easier, at the expense of all the trust, stability, and security expected from using a distribution (I guarantee none of you actually verify the packages aren't malware when installing through AUR)
From my perspective, Arch seems a little expedient. It provides a good Desktop experience, but is not as robust as distributions based on package managers like Portage, APT, or RPM. It is a lot easier to install and set up than Gentoo though, and provides similar benefits in terms of software freshness and builds with a few different configurations - hence my assessment.
They offer two flavors of this distribution-- one meant for end-users with the stable Plasma releases and one with bleeding-edge git builds. The bleeding-edge git build now defaults to Wayland, but the build meant for daily usage does not. AFAIK, they aren't yet recommending that downstream distributions default to wayland. Hopefully it will happen in 2017!