
Fedora 25: With Wayland, Linux has never been easier (or more handsome) - AdmiralAsshat
http://arstechnica.com/gadgets/2016/12/fedora-25-review-the-best-linux-distro-of-2016-arrived-at-the-last-moment/
======
coldtea
After the author mentions who this is the best/easier Linux distro ever, and
how Wayland mades everything so much better, there's this:

> _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...

~~~
vetinari
OSX does not support fractional HiDPI scaling, but nobody made a fuss, ever.
So I wonder, why is that a bad thing, when Linux doesn't do it either?

~~~
MBCook
I believe it has ever since going Retina. It wasn't always presented up front,
but it was an options.

~~~
vetinari
It's still integer only scaling.

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.

~~~
rcthompson
I'm aware of how OSX implements scaling. It's still rendering at a resolution
that is a non-integer multiple of the screen's native resolution and then
scaling it to the native resolution. How is this not fractional scaling?

~~~
vetinari
User space software stack is not aware of it, the frameworks know only of
scale 1, 2 and 3 (on iOS). Nothing between it. That's why it is integer
scaling.

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.

~~~
some_guy_there
> User space software stack is not aware of it, the frameworks know only of
> scale 1, 2 and 3 (on iOS). Nothing between it. That's why it is integer
> scaling.

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).

------
djsumdog
Xorg doesn't really need a configuration file today; it's good at auto
detecting hardware. But one of the things I really like about X is that you
can have a config file and specify exactly which devices you want. In this
way, you can connect two keyboards, two mice and two video cards to the same
machine and have two totally different login screens. You can essentially have
two people logged into the same machine as if they were using two different
terminals (just do try to plug in a USB device if both users have automounters
running).

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?

~~~
digi_owl
Wayland (or more "correctly" the support plumbing that will surround it, but
developed by the same team) will likely support all that, in time.

Just that rather than manually configure it, it will be automatically (they
hope) configured by combo of systemd, polkit and your DE of "choice".

~~~
jff
So once again freedesktop.org pushes out the new software with the promise
that some day it will meet the capabilities of the current tools, honest, we
pinky swear. They did it with systemd and they'll do it again with Wayland.

~~~
coldtea
Yeah, ignoring those seldom-used edge cases (multiple mice, keyboards, N
people using the same computer at once, etc.) all the while solving several
real issues and improving common uses cases in the process...

Damn those freedesktop.org people!

~~~
mixedCase
Yes, we know the Gnome team (and by extension, most of Freedesktop) wants to
reimplement macOS on Linux. But trust me, Miguel isn't coming back, the best
course would be just going to macOS instead (or hell, Windows, he's a happy
camper now, isn't he?) or do your work downstream.

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_.

~~~
stinkytaco
> The rest of us just want our own systems to run as well or better for our
> own usecases as they currently do.

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.

~~~
mixedCase
>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.

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_...](http://without-
systemd.org/wiki/index.php/Arguments_against_systemd)

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.

~~~
espadrine
> _Oh yes, because obviously everyone wants to maintain 10 different code
> paths_

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.

~~~
mixedCase
I think you misunderstood me. The people I had in mind were those maintaining
code that writes its own windows (toolkits, libraries like SDL2, plenty of
games rolling their own and applications like Steam).

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.

~~~
espadrine
Wouldn't supporting simultaneously the X protocol and the Wayland protocol be
very hard, if not impossible? It's already hard enough to replace the "basics"
of X.

~~~
mixedCase
Not impossible, just ugly as hell. The first two examples I mentioned
(toolkits like Qt or Gtk and the SDL2 libraries) actually do it.

------
AceJohnny2
One of the things I loved in Linux was the ability to swap out the "window
manager", the program that takes app's windows, draws decorations like title
bar and window borders around them, and arranges them on the screen. I had fun
with Compiz, I fiddled with Enlightenment, and I finally settled for Awesome
because I decided Tiling Was The Best (tm).

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)

~~~
lomnakkus
> 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.

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.

~~~
digi_owl
Give W as much time as X11 has had, and it will be of comparable size as X11
is right now. They will perhaps try to play semantic games by putting much of
the additions into support libs that you "don't need", unless you want to run
anything more than a decade old.

Wayland, X11, SVGALib, F if i can tell a diff...

~~~
lomnakkus
No. It's already basically feature-complete as compared to which parts of X11
are _actually used_ these days[1]. X11 is burdened by absurdly obsolete
extensions like drawing stippled lines, a font server, etc. See the talk by
Daniel Stone[2] if you're interested in the kind of crud that's been cleared
out. It's basically the kind of stuff that we will _never_ go back to wanting
in any type of server process. The trade-off between bandwidth and latency has
changed fundamentally in basically all areas of computing, but _especially_
anything to do with graphics.

[1] Alright, there might be a few bits and bobs that are missing, but nothing
major as witnessed by the very article under discussion.

[2]
[https://www.youtube.com/watch?v=RIctzAQOe44](https://www.youtube.com/watch?v=RIctzAQOe44)

~~~
digi_owl
Who gets to declare those things "crud"? I am sure that if you poke around you
will find someone still relying on those features being present daily.

~~~
bitwize
Daniel Stone does. Maybe you get a say in it when you've spent as much time on
the Linux graphics stack as Daniel Stone has.

Seriously, when's the last time _you_ wrote a program that relied on the
ability of the display server to draw stippled lines?

~~~
nitrogen
What's so bad about stippled lines? They sound useful for so-called "real
work" applications for drawing grids and graphs and marching ants.

~~~
lomnakkus
It's not that stippled line are bad per se. It's just that they shouldn't be
baked into a protocol that goes "over the wire" (so to speak). It's much
faster if the program just gets a bitmap to draw on and draw the stippled line
itself. It's important to note here that "itself" could mean that you just
call a (Qt/Gtk/SDL/whatever) library function to do it.

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.

~~~
nitrogen
I haven't done much 2D drawing recently. My intuition is that sending a batch
of line/polygon/stipple/fill commands to a GPU would be more efficient than
occupying a CPU and then using a bunch of memory bandwidth to transfer a
bitmap. But on modern systems, software rendering to a bitmap in RAM is more
efficient than sending a command to a GPU (which probably lacks dedicated 2D
hardware)?

~~~
digi_owl
Bingo. X was in part made for working over network and serial connections. And
for that it works quite well when the clients play nice (async code between
front and back end etc).

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.

~~~
espadrine
Blame is not on toolkits. The history is clear: came a point where MacOS X and
Windows supported flawless animations with no screen tearing, and
transparency, and antialiased rounded corners for windows.

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.

------
dkarapetyan
> This release also brings improved support for Flatpak apps in GNOME
> Software. Flatpak apps are designed to improve the software installation
> process in GNOME and Linux in general by making it easier for developers to
> package, and users to install, software across distributions. With Flatpaks
> you don't need to worry about dependency conflicts or even if your distro of
> choice has the app you want. Flatpaks also offer improved security and
> stability by sandboxing applications.

Another competing packaging format. Why?

~~~
amlib
Because I can finally download the same file and run it on my distro of choice
without installing it as a system package. This is not a replacement for
traditional linux packages. It has it's own set of advantages and
disadvantages. This may lead to a good solution for app support fragmentation
on linux.

~~~
digi_owl
Good? This is the devops container boys recreating Windows' DLL hell and
selling it as an "improvement".

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.

~~~
colemickens
_> This is the devops container boys recreating Windows' DLL hell and selling
it as an "improvement"._

I'm not a fan of Flatpak (Nix/Guix for the win), but this is completely
incorrect.

~~~
lisivka
So how you plan to fix security holes in flatpak aps, please?

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».

~~~
colemickens
The same way you solve this anyway, or the same answer you should hear when
people say "how do you handle security with Docker": Continuous Integration.

~~~
lisivka
CI and maintenance are different things. AFAIK, it's recommended to pin
versions of libraries, not to update libraries at every integration, so
security fixes will be delayed. Moreover, developers never release new version
of an app when a dependency is updated only, while maintainers do. It's called
bit rot.

~~~
colemickens
Take NixOS as an example. When libc gets a security fix, everything is
automatically rebuilt and binary cache packages are available for users.

~~~
lisivka
It's waste of resources. Fedora does mass rebuild once per 3 months at
average. If libc gets a security fix, dnf in Fedora will download just a delta
between packages. Lower consumption of resources mean faster turn-over rate
and is better overall. But I can mimic NixOS behavior with mock (tool for
clean rebuilds) and chroots or containers, if I want.

------
Ace17
I totally agree with the need for eliminating tearing from games (and every
other application, and increasing the overall smoothness of desktop displays).
However, from the article itself, the list of regressions associated with the
switch to Wayland seems to be non-negligible ; especially the lack of fast
drivers for Nvidia graphic adapters, which makes it unlikely for GNU/Linux-
gamers to do the switch.

Is it impossible to fix the tearing and smoothness issues of Xorg/X11?

~~~
ZenoArrow
The problems with X go beyond just screen tearing. For example, it's possible
for Xorg apps to spy on each other, such as reading keypresses when a user is
entering a password.

~~~
digi_owl
Something that could have been eliminated without chucking the whole of X. A
starting point is the Security extension that introduce the concept of trusted
and untrusted X Clients.

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.

~~~
ZenoArrow
Yes, everything can be solved with more extensions, but that approach is part
of why X became unwieldy in the first place.

------
blinkingled
Fedora has really made great progress. The font situation is improved and used
purely as a development/hacker workstation it works great on common hardware.
Media playback, battery life remain big issues but I don't expect those to get
any better soon. You can always fix the former with Rpmfusion packages and the
latter by not using it unplugged :)

~~~
Tharre
Care to explain what you mean with issues regarding media playback?

~~~
vetinari
Fedora does not ship with many popular codecs (mp3 decoding is a new thing in
F25, decoding h.264 was new in F24). Third party repositories do offer the
codecs, but Fedora project itself does not.

~~~
Tharre
Ah, I see. Unfortunately this is most likely due to software patents. Bummer.

Thanks though.

------
atombender
As a Mac user who's considering switching to Linux as a desktop OS, I gave
this a go inside VMware. I sincerely hope this isn't the best Linux distro in
2016, because that was... underwhelming. Not quite a trainwreck, but still
pretty bad. How is Elementary or Mint?

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).

------
0xFFC
As software developer I spend all of my time doing reading/writing code and
text. So the _most_ important aspect of a linux distro is font rendering and
font aliasing for me.

And fedora, last time I tried it, didn't have smooth font by default ! (it was
version 23 if I remember correctly)

~~~
Tharkun
As another software developer, I haven't noticed or cared about fonts in about
20 years. 20 years ago font rendering was sometimes bad. The last 20 years? I
guess not or I would have noticed. Seems like whatever the defaults are on
Fedora+Awesome, they're fine.

~~~
boondaburrah
I've basically only noticed or cared about fonts when I'm on a windows
computer or a poorly configured linux computer. Windows's hinting drives me
nuts.

------
dandelion_lover
Can anyone comment whether this problem with GUI isolation

[http://theinvisiblethings.blogspot.de/2011/04/linux-
security...](http://theinvisiblethings.blogspot.de/2011/04/linux-security..).

is now solved?

~~~
TD-Linux
Yes. Some applications still use the XWayland compatibility layer, so they can
snoop on each other, but not on Wayland apps. I think the only XWayland-using
app that Fedora ships with is Firefox.

------
brightball
He comments in the conclusion that he runs Arch on his main machine. It seems
like I've been seeing a lot of comments like that from people around the web
lately.

What's the draw of Arch over Ubuntu/Fedora/Mint, etc?

~~~
stinkytaco
It's a great way to learn Linux.

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.

~~~
rvern
For every Fedora release, the Documentation Project prepares a new version of
the System Administrator's Guide[1] and of five other high-quality manuals.
These manuals are usually up-to-date, accurate and comprehensive, and since
they are maintained in the DocBook format (which is very superior to
wikimarkup for technical documents), they can be converted into HTML (for the
version on docs.fedoraproject.org), PDF (for printing or viewing in a PDF
reader) and EPUB (so I can put the guides on a e-reader and read them
comfortably). The documentation is even translated in multiple languages.

[1]: [https://docs.fedoraproject.org/en-
US/Fedora/25/html/System_A...](https://docs.fedoraproject.org/en-
US/Fedora/25/html/System_Administrators_Guide/index.html)

~~~
stinkytaco
Fedora is my preferred Linux distro, but when I'm looking for a solution or
how-to on setting up, say MPD or bittorrent, I inevitably end up at the arch
wiki.

------
mangix
my only gripe with it is the mouse lag. I have a feeling input is not multi-
threaded like in Xorg.

------
phkahler
I'm not certain, but I think they're still running Firefox under Xwayland
along with LibreOffice. I'd like to see them run the native Wayland versions
of those apps by default.

------
TallGuyShort
Does anyone know if the KDE spin will also be using Wayland by default?

~~~
nickysielicki
The KDE upstream developers release a distribution called KDE Neon that is
based on Ubuntu, with an extra file in /etc/apt/sources.list.d which provides
significantly newer builds than what Ubuntu / Kubuntu offer.

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!

~~~
sho_hn
I think we're on track for delivering that in 2017. We do already have users
on Wayland; it's not yet a drop-in replacement feature-wise, so it's up to
whether we have the subset you use already in place.

