Fedora 25: With Wayland, Linux has never been easier (or more handsome)(arstechnica.com)
arstechnica.com
Fedora 25: With Wayland, Linux has never been easier (or more handsome)
http://arstechnica.com/gadgets/2016/12/fedora-25-review-the-best-linux-distro-of-2016-arrived-at-the-last-moment/
177 comments
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?
> OSX does not support fractional HiDPI scaling
Yes it does. It's right there in the system preferences.
Yes it does. It's right there in the system preferences.
No, it does not. See my reply below.
Because these are all regressions.
It is an entirely new compositor, after 30+ years of X, so there will be things to work out yes, but the fact that Wayland is finally here is huge.
OS X does. So the rest of the question is moot.
I believe it has ever since going Retina. It wasn't always presented up front, but it was an options.
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.
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.
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?
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.
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.
> 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).
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).
>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.
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).
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).
Whatever the mechanism, it does have it and it IS fractional scaling on non-integral multiple of the screen DPI.
Oh, that's right. I'd forgotten about that.
Thanks.
Thanks.
It's even default on the new 2016 pros.
Not sure about on Fedora but I cannot get Hangouts screen sharing working under Wayland/Weston on Arch, though it worked fine under X11.
All screen-sharing and device multiplexing is broken under Wayland, and it's by design. Wayland only lets an application see its own window content and its own input events.
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.
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.
> However it's the lack of network transparency which stops me from using Wayland in the foreseeable future.
X is not network transparent, and hasn't been for a long time. https://www.youtube.com/watch?v=cQoQE_HDG8g
X is not network transparent, and hasn't been for a long time. https://www.youtube.com/watch?v=cQoQE_HDG8g
Whatever, X is network transparent "enough" for me to run all applications I care about remotely, and I do it all the time.
In a Wayland session, ssh -X will connect your remote applications with XWayland and they will run fine, no extra setup needed.
If everything still has to go through an X server, what has Wayland accomplished? Is Xwayland just going to become a more easily maintained substitute for Xorg? I can't imagine writing anything other than a twitch game as a raw Wayland client that's completely unusable except on the one and only small computer under my desk.
> If everything still has to go through an X server, what has Wayland accomplished?
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.
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.
> ssh -X is hardly "everything".
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.
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.
> It's damn close. How many apps do you exclusively use locally? A terminal emulator, maybe a web browser?
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.
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.
IMHO a sane protocol sends command from the app to the GPU under my desk, rather than requiring every computer in the world to have a headless GPU and a fat enough pipe to stream pixels to my framebuffer.
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.
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.
> 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.
The fact that keyloggers exist on Linux is because of X11's security model.
The fact that keyloggers exist on Linux is because of X11's security model.
Unsupported hacks and a feature needed for an uncommon setup don't work, yeah, those are relatively minor issues.
Just wondering, is clipboard an "unsupported hack" or "feature needed for an uncommon setup"? What about video?
This isn't clipboards in general, but a clipboard manager. This is a program that keeps a history of things in your clipboard so you can go back if you accidentally copied something, or sync things between computers even (it's really nice when it works among VMs, copy on one, paste on the other).
Clipboard managers are needed at least on some desktop environments to make copy/paste functional between applications.
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).
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).
Clipboard does work, but I wanted to point out that all of these things are specific to the Wayland session, which is very new, you can still switch to Xorg in GDM and everything will work as expected.
Clipboard managers.
What among desktop icons, proper working clipboard, fractional HiDPI scaling and video playback exactly sounds like a luxury, unsupported hack, or uncommon needs to you?
Perhaps you are just an administrator spending 24/7 on the command line, but I assure none of those are uncommon...
Perhaps you are just an administrator spending 24/7 on the command line, but I assure none of those are uncommon...
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?
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?
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".
Just that rather than manually configure it, it will be automatically (they hope) configured by combo of systemd, polkit and your DE of "choice".
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.
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!
Damn those freedesktop.org people!
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.
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.
> 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.
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.
> 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.
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.
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.
>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_...
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.
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.
Case in point: the core Wayland protocol desktop applications use for creating and handling windows doesn't support basic functionality like minimizing them, because Gnome doesn't think people should be able to minimize windows. So there's a complete duplicate of the Wayland window creation protocol as an extension to add support for features like this. Actually, effectively several complete duplicates since they keep changing the protocol in ways that aren't backwards compatible whenever they need to add new features.
> 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.
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.
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.
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.
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.
Not impossible, just ugly as hell. The first two examples I mentioned (toolkits like Qt or Gtk and the SDL2 libraries) actually do it.
> Yes, we know the Gnome team (and by extension, most of Freedesktop) wants to reimplement macOS on Linux.
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?
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?
improving common uses cases in the process
The whole reason people switch to Linux in the first place is for uncommon use cases.
The whole reason people switch to Linux in the first place is for uncommon use cases.
>The whole reason people switch to Linux in the first place is for uncommon use cases.
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 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 server Linux was basically carried in by LAMP, as it allowed people to spin up websites at only the cost of the hardware (or rent on server space). Never mind that this as the dot-com bust, and thus there was a whole lot of cheap capacity to be had (kinda reminds one of the microcomputer getting a boost from excess capacity of CPUs thanks to the moon race).
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).
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).
Really? So nobody's using Linux as a traditional desktop because they like it better than what Microsoft and Apple have to offer, do they?
Well, I beg to differ.
Well, I beg to differ.
[deleted]
We live in a world of touchscreen laptops, and you consider 'multiple mice' to be an edge case?
Interesting.
Interesting.
I'm not sure I following the reasoning process (or lack thereof) used to make this association.
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.
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.
The edge case isn't multiple mice, it's multiple mice controlling multiple pointers in multiple sessions.
> 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
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?
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 alternative to systemd was not the old init-v, but upstart.
Upstart was being pushed by Ubuntu. Systemd was being pushed by RedHat.
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/
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/
> You can use Xorg as you always did, Wayland is fully optional.
For now...
For now...
Wayland allows for sane graphical rendering pipeline. It's missing in X. A tiny raspberry pi becomes silk smooth by switching to wayland.
I don't dismiss your points at all, just showing wayland is not a subset of X.
I don't dismiss your points at all, just showing wayland is not a subset of X.
Wayland has been around for 4 years, When X was 4 years old, it ran on hardware with 5mhz processors and a few MB RAM.
> Just that rather than manually configure it, it will be automatically
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...
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...
First of all you have systemd-logind that tracks "sessions" (using a different definition to the one found inside the kernel, natch) and "seats", that then polkit talks to via dbus (yay...), and then the DE talks to polkit (again via dbus).
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.
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.
>And quite franky, I see no need for another thing like Wayland to add entropy to the GNU/Linux desktop.
I'm sure the merits can be discussed, but security is a need that Wayland addresses.
I'm sure the merits can be discussed, but security is a need that Wayland addresses.
[deleted]
I know you are making an earnest comment but the idea of having one computer support multiple users each on their own terminal is really really well explored territory. So I chuckled a bit at how even old things can be new again.
It does speak to having way more compute resources than you can consume at a given time.
It does speak to having way more compute resources than you can consume at a given time.
Its old yes, but the Freedesktop boys are doing it in a "new" way. This by using sofware to bundled a random set of devices into a single seat, and assigning said seat to a user on login based on the input device used. The old way was to hang dedicated hardware off serial ports and figure out the "seat" (if such a concept needed to be defined at all back then) that way.
Exactly right, the concept is timeless and the implementation choices change with the times.
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.
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.
With Wayland I can finally dock & undock my thinkpad without having to restart my laptop.
What configuration? Works fine for me with a Skylake ThinkPad on Fedora 24.
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)
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)
> 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.
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.
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...
Wayland, X11, SVGALib, F if i can tell a diff...
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
[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
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.
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?
Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines?
What's so bad about stippled lines? They sound useful for so-called "real work" applications for drawing grids and graphs and marching ants.
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.
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.
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)?
GPU drawing can still be faster than on the CPU, and you can do that with Wayland, by directly opening the DRM device (/dev/dri/render*) and sending the rendering commands directly to the GPU. This is how Mesa implements OpenGL on both X and Wayland. The X way requires you to send XRender commands to the X server first, and then it sends them to the GPU. This was already too slow (hence the already existing bypass for OpenGL) and Wayland just extends that idea to all rendering.
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.
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.
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.
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.
"Rendering everything outside of X" means directly accessing the GPU. Doing GPU stuff through X is slow and for DRI, the X server gets in the way. And X's 2D rendering primitives are obsolete. You want 2D primitives? It's called libcairo. Wayland provides the missing piece, the only bit of X anyone actually uses: providing buffers to clients to render into to be composited on the display.
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.
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.
RAM/DMA transfer is absurdly fast these days. (And "as a compositor" you'll have to do it anyway at 60fps, regardless.)
> Seriously, when's the last time you wrote a program that relied on the ability of the display server to draw stippled lines?
or someone?
or someone?
Then they can implement stippled lines in their application. It seems absurd to expect X to support rarely used extensions simply because "someone" might use them. It's not like stippled lines are no longer allowed on the Linux desktop, you just can't hook into the desktop compositor to get them.
You can usually tell by the very few people willing to maintain the code/feature. Some of it has layers upon layers of duct tape.
The X.org developers decided. The person who started Wayland was an X.org developer, and IIUC many who joined the effort are/were X.org developers, etc.
> 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).
[1] https://www.youtube.com/watch?v=2l7ixRE3OCw
> 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).
[1] https://www.youtube.com/watch?v=2l7ixRE3OCw
xterm and rxvt do.
> good tiling window manager
SirCmpwn is porting i3:
http://swaywm.org/
https://github.com/SirCmpwn/sway
SirCmpwn is porting i3:
http://swaywm.org/
https://github.com/SirCmpwn/sway
> > good tiling window manager
> 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/
> 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/
There are a number of window managers for wayland already. The ArchWiki has a list of them [0].
[0]:https://wiki.archlinux.org/index.php/Wayland#Window_managers...
[0]:https://wiki.archlinux.org/index.php/Wayland#Window_managers...
I'm heavy Awesome user myself. Pretty much refuse to use anything else these days. It works, doesn't get in the way and goes really well with my workflow.
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?
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?
https://phab.enlightenment.org/w/wayland/
https://archive.fosdem.org/2016/schedule/event/enlightenment...
https://en.wikipedia.org/wiki/Wayland_%28display_server_prot...
https://archive.fosdem.org/2016/schedule/event/enlightenment...
https://en.wikipedia.org/wiki/Wayland_%28display_server_prot...
And? Since E17, E has pretty much been a DE in its own right. Fueled in large part because Rasterman ran afoul Gnome and RH office politics during his stay at RH labs.
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.
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.
> Fueled in large part because Rasterman ran afoul Gnome and RH office politics during his stay at RH labs.
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.
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.
It also offloads several of the features of X to the clients. Including inter-process communication and networking. I suppose you can view this as good or bad, but it certainly much smaller and, in some ways, more efficient since I don't need to have the ability to network unless I load up an RDP.
> 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?
Another competing packaging format. Why?
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.
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.
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.
>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.
I'm not a fan of Flatpak (Nix/Guix for the win), but this is completely incorrect.
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».
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».
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.
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.
Take NixOS as an example. When libc gets a security fix, everything is automatically rebuilt and binary cache packages are available for users.
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.
How so? You have a limited option to outsource what you bundle via "frameworks", but that concept only go so deep. You can bet your behind that if the format ever takes off, every flatpak will contain their own copy of libc on up just to be sure. This similar to how every Windows program ship with a VC++ DLL bundle, just to be sure.
I guess I misinterpreted what you meant by "DLL hell" then.
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?
Is it impossible to fix the tearing and smoothness issues of Xorg/X11?
During the last year, I've solved tearing from movie playback on three different systems (nVidia discrete, AMD integrated, Intel integrated) by using the "TearFree" Xorg Driver option.
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.
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.
Add libinput to that list, that currently makes it impossible for me to switch. I just can't reproduce the behavior of synaptics with the options libinput currently offers, and without them my mouse drives me crazy.
Some X drivers can be made to do proper vsync discipline by setting a "NoTearing" option in xorg.conf.
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.
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.
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.
Yes, everything can be solved with more extensions, but that approach is part of why X became unwieldy in the first place.
At least in my case most games crash, though it is likely due to using Bumblebee (Nvidia Optimus) and switching between Integrated Graphics and Dedicated Graphics.
The plus side is that I can log into using either Wayland or Xorg. So switching between the two is almost seamless.
The plus side is that I can log into using either Wayland or Xorg. So switching between the two is almost seamless.
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 :)
> and the latter by not using it unplugged
Or by using PowerTop/TLP
https://fedoramagazine.org/saving-laptop-power-with-powertop...
Or by using PowerTop/TLP
https://fedoramagazine.org/saving-laptop-power-with-powertop...
Yup. Running FC25 right now on 27" iMac and the visual appearance is noticeably better than older distributions I'm running on other hardware.
Edit: FC25
Edit: FC25
Care to explain what you mean with issues regarding media playback?
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.
Ah, I see. Unfortunately this is most likely due to software patents. Bummer.
Thanks though.
Thanks though.
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).
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).
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)
And fedora, last time I tried it, didn't have smooth font by default ! (it was version 23 if I remember correctly)
Fedora doesn't have rgba lcdfilter by default, due to Cleartype patents. It does have antialiasing.
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.
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.
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.
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.
Yeah, caring about fonts when doing "code" sounds like a tell for "i am a web designer doing JS".
It's the kind of thing that's largely up to personal preference, people that spent a long time with Windows font rendering have a hard time adjusting to the old Freetype2. The newest Freetype2 integrated the infinality patches which make the rendering much easier on the eyes for those people.
Distrowatch says Fedora 25 uses an older Freetype2, I think the patches are available to toggle on.
Distrowatch says Fedora 25 uses an older Freetype2, I think the patches are available to toggle on.
[deleted]
Can anyone comment whether this problem with GUI isolation
http://theinvisiblethings.blogspot.de/2011/04/linux-security....
is now solved?
http://theinvisiblethings.blogspot.de/2011/04/linux-security....
is now solved?
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.
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?
What's the draw of Arch over Ubuntu/Fedora/Mint, etc?
Honestly? It's just easier 99% of the time. And I don't mean easier in the sense that you could give Arch to a linux newbie and expect it to work.
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.
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.
> 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.
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.
Debian sure has, but I wasn't talking about Debian.
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.
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.
Why you think you cannot understand Fedora? RPM based distributions are easy to explore. "rpm -qf /path/to/file" to get name of a package, "rpm -ql name" to get list of other files in the package, then RTFM of package.
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.
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.
There are times i wonder if everything that Gnome and Freedesktop has developed in recent years is a response to issues with Fedora, but presented as issues with the larger Linux ecosystem.
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.
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.
This may be the best thing about Arch. Their crowd-sourced documentation model covers a lot of corner cases and unique configuration that many other distributions cathedral model documentation lack. The wiki format also helps it keep up with the rolling nature of Arch. Even the Gentoo wiki links to the Arch wiki in a lot of scenarios.
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...
[1]: https://docs.fedoraproject.org/en-US/Fedora/25/html/System_A...
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.
I personally view Arch as a "poor man's Gentoo." It's a rolling release, which is great considering the never-finished state of free software. Many projects have different release schedules, which means that stable distributions will always miss out on the newest version of X% of their packages. With Arch, those updates get pushed when they're ready, instead of pushing what works by the release deadline.
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.
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.
All of my packages are actually up to date, since Arch is a rolling release. Even on Xenial there are packages that are behind enough that I notice due to missing features/bug fixes.
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.
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.
You hope they're up to date. If you install / depend on very much from AUR, I'd wager you're probably missing a security update or two.
AUR packages:
local/caddy-full-bin 0.9.3-12,
local/kakoune-git r4563.e441295-1,
local/kubectl-bin 1.5.1-1,
local/neofetch 2.0.2-1,
local/package-query 1.8-2,
local/tmuxp 1.2.2-1,
local/yaourt 1.8.1-1
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).
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).
my only gripe with it is the mouse lag. I have a feeling input is not multi-threaded like in Xorg.
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.
Does anyone know if the KDE spin will also be using Wayland by default?
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!
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!
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.
digi_owl(4)
>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...