This is page is a very useful resource, but it misses one important dimension: “with compositor X”.
Take for example the category “Screenshot/screen capture & share tool: grim/slurp, OBS, swappy, wayvnc”. Yes, these programs work, but only (according to Arch’s documentation [1]) with wlroots-based compositors. Other compositors (say, GNOME Shell/Mutter) do not support that extra protocol needed to grab screenshots.
Another issue is that many programs in this list are MVP-like applications or proof-of-concept implementations that lack all the “edge-case” functionalities that make those programs useful in the first place. Take for instance ydotool. Yes, you can use ydotool for basic input simulation, but there is no equivalent of xdotool search --name $TITLE (to find the WID of all windows with a certain title) or xdotool windowactivate $WID (to programmatically focus a specific window).
In many cases, like in ydotool’s case, it can be argued that certain functionalities are lacking because there is no widespread support for the needed extra protocols (or those protocols do not even exist yet). Yeah, that is a reasonable justification, but it does not solve the problems that the end users have.
About the Nvidia caveat at the bottom: if you want to run Linux most of the time, and don’t want to spend 10 to 100% of the time dealing with driver and library issues, you should buy AMD or Intel.
For the past 15 or so years, if you buy something without upstream support you will end up having troubles. Maybe not if you make all the default choices and never upgrade kernels. But if you deviate from the default clean install at any point, you will be in for a world of pain. And don’t even mention mobile graphics or other scenarios which require graphics offloading.
Intel has always had excellent support since they entered the graphics segment (at least since the GMA series), and AMD has had excellent support since they brought their GCN drivers into the mainstream Linux ecosystem.
Nvidia insists on not using anything from the open source ecosystem. They don’t upstream any relevant part of their driver, they are the only vendor not using the Mesa ecosystem for OpenGL & graphics acceleration, and they don’t have upstreamed X11 or Wayland support.
Because of their refusal to integrate into the ecosystem, support for their hardware and libraries is lacking at best, and plain broken most of the time.
I’m not sure what problems you’ve run into, but I’ve had the exact opposite experience - I’ve used Linux for 18 years and at this point I only buy NVIDIA GPUs. I’m able to use hardware accelerated OpenGL, OpenCL, VDPAU, and even CUDA without a problem.
Having the driver included with the kernel would be wonderful, but in the meantime, they do a good job keeping pace with kernel changes, support old hardware for a reasonable amount of time, and maintain legacy drivers for older GPUs.
I actually tried to do that last year and got an eGPU case and an AMD card, only to discover that the features I needed were only available in the pro, non open source driver, which was impossible to install on Fedora. I tried hard but eventually returned the card and got an Nvidia. Installing the drivers was super easy, and things worked pretty much out of the box.
The feature I needed was to use the card as an accelerator for 3d content, and keep the screens plugged into my dock instead of into the eGPU.
I happily used Wayland for years on various Intel and AMD GPUs. I now need an NVIDIA GPU in my main work machine, so that I can verify that machine learning code is working correctly before training on a dedicated machine. Unfortunately, XWayland is unaccelarated when using GNOME on Wayland with NVIDIA. So, I am back to X.org :(.
I hope NVIDIA gets their sh*t together one day. I still have an RX580 on the shelf, but unfortunately ROCm is still very buggy for machine learning.
After two decades of using Linux, I’ve learned that if it doesn’t live upstream, you’re just in for a world of pain as soon as you deviate from “standard everything” choices, at best.
Like you said - running AMD or Intel is almost always painless. I chose to buy from vendords that support my use case, as much as possible.
Like you said - running AMD or Intel is almost always painless. I chose to buy from vendords that support my use case, as much as possible
I know, I have used AMD and Intel prior and still have several machines around the house with Intel. But if you need CUDA, then these are not options (and no, ROCm is not anywhere near reliable yet).
My machine doesn’t have an integrated GPU (Ryzen 3700X). I could place another card, but it looks like it would be quite bad for cooling. First, because one of the GPU’s airflow would be blocked by the other. Secondly, because there is a mainboard fan right besides the second X16 slot, which would be blocked by a GPU. I think it’s probably only practical with water cooling. Also, I’d have to upgrade the PSU.
I’d consider consider putting the NVIDIA GPU in an eGPU case if the mainboard had Thunderbolt support.
It’s a shame that the ROCm ML ecosystem has so many problems, otherwise I’d highly prefer an AMD card.
Okay, so an alternative would be to to not pay all the power costs of running it yourself and putting it in the cloud. A g4dn.xlarge’s spot price is pretty low compared to electricity + cost of ownership: $0.1578 per Hour
You run into the problem of people outbidding you for your instance, but you’re probably training and testing models in batches. For a full reservation it’s 52¢/hour: https://www.ec2instances.info/?selected=g4dn.xlarge (add the gpu columns)
If you needed lower latency or have legal/moral requirements, you could run the same in one of the EU regions.
Do you have an estimate of the duty cycle of the video card?
We run VNC at work and the latency of a Bluetooth keyboard is often higher than the cost of vnc to the nearest Amazon region…
Okay, so an alternative would be to to not pay all the power costs of running it yourself and putting it in the cloud. A g4dn.xlarge’s spot price is pretty low compared to electricity + cost of ownership: $0.1578 per Hour
[…]
We run VNC at work and the latency of a Bluetooth keyboard is often higher than the cost of vnc to the nearest Amazon region…
So, I can jump through a lot of hoops and work with latency. Or I can stay with X11 for a few more months or perhaps a year (until the recent Mesa changes start to percolate) and have very fast local development with nearly no latency and no recurring cost.
Like I said, it’s a shame that I cannot use Wayland currently, but it’s not like X11 is unworkable. As a bonus, screen sharing in Skype works ;).
sway feels snappier than i3 on the same laptop (x220). There is no tearing nor flickering when opening ‘ closing / moving windows, something I have honestly not noticed on i3 particularly. The keyboard latency seems also reduced. All in all, it feels snappy.
Mini;ni;
I have yet to find a terminal that allows for mouse plumbing.
The most missed thing from X for me is a lack of ‘urgency’ support on Wayland. I used to rely on shell apps sending a bell when they needed my attention, and getting a visual notification on i3wm when a workspace had an urgent event like that. But there’s nothing similar that I’ve found using Sway/Wayland (for native Wayland apps), I’ve had to make due with modifying my terminal app to notify-send to mako when a bell happens, and then guess at which workspace the event happened on.
Yes, depending on the sd-bus library sucks. However that’s the only half-decent D-Bus library out there. The plan is to get basu up and running on non-systemd distributions.
It does, indeed, just use dbus. It happens to use the dbus library from systemd’s repository for it. If you forked systemd, deleted everything but the sd-bus bits, it would work.
Having a hard dependency on an init system, or a portion of it, is beyond stupid for something like a notification daemon.
I disagree, it’s part of the operating system for many distributions, a specifc component they want to rely on. There are certainly people who want to use the Linux kernel, but are not interested in systemd, but that is not everyone.
And setting that aside, it’s not a hard dependency, as others have already said. It’s a dependency on an interface, at best.
It is a hard dependency as it is literally required at this point in time.
You can not compile it without having elogind or systemd.
But also I think you’re missing the point.
There are plenty of other notification daemons, that do no require any certain init system or a portion of one. That can do the same, or even more than, Mako can. The only difference is that in regards to Mako there’s not really any major competing software for it.
By requiring elogind/systemd, there’s basically a boundry set in place for people who want to rid themselves of using the garbage known as systemd. And that’s totally fine, it’s their software. But they could probably gain a lot more users by not using a dbus interface tied to any one init system.
Building
Install dependencies:
meson (build-time dependency)
wayland
pango
cairo
systemd or elogind (for the sd-bus library)
gdk-pixbuf (optional, for icons support)
dbus (runtime dependency, user-session support is required)
scdoc (optional, for man pages)
jq (optional, runtime dependency)
Isn’t that nvidia section kinda wrong ? Looking at KDE Link I don’t see how you can label that as completely “nvidia” related nor unessential. Sure you may be able to run stuff on an “Arch Setup” which only runs i3 on bare metal (which is how I’d call it), but looking that the above the link it’s nowhere near ready for a normal user / replacement of x11.
The same seems to be true looking into the gnome page about wayland compatibility requirements.
So all in all wayland is on its way, but to be fair you really shouldn’t use it as your daily driver, if you don’t want to test an alpha/beta that doesn’t work on 50% of the hardware or freezes when drag’n dropping stuff.
This is page is a very useful resource, but it misses one important dimension: “with compositor X”.
Take for example the category “Screenshot/screen capture & share tool: grim/slurp, OBS, swappy, wayvnc”. Yes, these programs work, but only (according to Arch’s documentation [1]) with
wlroots-based compositors. Other compositors (say, GNOME Shell/Mutter) do not support that extra protocol needed to grab screenshots.Another issue is that many programs in this list are MVP-like applications or proof-of-concept implementations that lack all the “edge-case” functionalities that make those programs useful in the first place. Take for instance ydotool. Yes, you can use ydotool for basic input simulation, but there is no equivalent of
xdotool search --name $TITLE(to find the WID of all windows with a certain title) orxdotool windowactivate $WID(to programmatically focus a specific window).In many cases, like in ydotool’s case, it can be argued that certain functionalities are lacking because there is no widespread support for the needed extra protocols (or those protocols do not even exist yet). Yeah, that is a reasonable justification, but it does not solve the problems that the end users have.
[1] https://wiki.archlinux.org/index.php/Screen_capture#Wayland
About the Nvidia caveat at the bottom: if you want to run Linux most of the time, and don’t want to spend 10 to 100% of the time dealing with driver and library issues, you should buy AMD or Intel.
For the past 15 or so years, if you buy something without upstream support you will end up having troubles. Maybe not if you make all the default choices and never upgrade kernels. But if you deviate from the default clean install at any point, you will be in for a world of pain. And don’t even mention mobile graphics or other scenarios which require graphics offloading.
Intel has always had excellent support since they entered the graphics segment (at least since the GMA series), and AMD has had excellent support since they brought their GCN drivers into the mainstream Linux ecosystem.
Nvidia insists on not using anything from the open source ecosystem. They don’t upstream any relevant part of their driver, they are the only vendor not using the Mesa ecosystem for OpenGL & graphics acceleration, and they don’t have upstreamed X11 or Wayland support.
Because of their refusal to integrate into the ecosystem, support for their hardware and libraries is lacking at best, and plain broken most of the time.
If you want to run Linux, don’t buy Nvidia.
I’m not sure what problems you’ve run into, but I’ve had the exact opposite experience - I’ve used Linux for 18 years and at this point I only buy NVIDIA GPUs. I’m able to use hardware accelerated OpenGL, OpenCL, VDPAU, and even CUDA without a problem.
Having the driver included with the kernel would be wonderful, but in the meantime, they do a good job keeping pace with kernel changes, support old hardware for a reasonable amount of time, and maintain legacy drivers for older GPUs.
I actually tried to do that last year and got an eGPU case and an AMD card, only to discover that the features I needed were only available in the pro, non open source driver, which was impossible to install on Fedora. I tried hard but eventually returned the card and got an Nvidia. Installing the drivers was super easy, and things worked pretty much out of the box.
The feature I needed was to use the card as an accelerator for 3d content, and keep the screens plugged into my dock instead of into the eGPU.
Agreed.
At my association, I banned any new purchase of Nvidia products (for that reason) and Intel products (for other reasons).
As long as people accept the deal Nvidia is offering them, nothing will change.
I happily used Wayland for years on various Intel and AMD GPUs. I now need an NVIDIA GPU in my main work machine, so that I can verify that machine learning code is working correctly before training on a dedicated machine. Unfortunately, XWayland is unaccelarated when using GNOME on Wayland with NVIDIA. So, I am back to X.org :(.
I hope NVIDIA gets their sh*t together one day. I still have an RX580 on the shelf, but unfortunately ROCm is still very buggy for machine learning.
I just try not to buy Nvidia anymore.
After two decades of using Linux, I’ve learned that if it doesn’t live upstream, you’re just in for a world of pain as soon as you deviate from “standard everything” choices, at best.
Like you said - running AMD or Intel is almost always painless. I chose to buy from vendords that support my use case, as much as possible.
I know, I have used AMD and Intel prior and still have several machines around the house with Intel. But if you need CUDA, then these are not options (and no, ROCm is not anywhere near reliable yet).
Why do you need to drive your video with the same card you do ML with? Just use the onboard video or another mid range card?
My machine doesn’t have an integrated GPU (Ryzen 3700X). I could place another card, but it looks like it would be quite bad for cooling. First, because one of the GPU’s airflow would be blocked by the other. Secondly, because there is a mainboard fan right besides the second X16 slot, which would be blocked by a GPU. I think it’s probably only practical with water cooling. Also, I’d have to upgrade the PSU.
I’d consider consider putting the NVIDIA GPU in an eGPU case if the mainboard had Thunderbolt support.
It’s a shame that the ROCm ML ecosystem has so many problems, otherwise I’d highly prefer an AMD card.
Why not do an old card like https://www.amazon.com/VisionTek-Radeon-5450-DVI-I-Graphics/dp/B01CN1F1ZM/?
No DisplayPort, no 4K@60Hz (as far as I know), no hardware acceleration of modern codecs. Most passively cooled cards have these properties.
There is a hack for xwayland, somewhere in the Mesa merge requests I think.
Yeah, I read that on Phoronix:
https://www.phoronix.com/scan.php?page=news_item&px=GLX-Delay-Accel-NV-XWayland
Hopefully something like that lands in release versions sometime soon.
Okay, so an alternative would be to to not pay all the power costs of running it yourself and putting it in the cloud. A g4dn.xlarge’s spot price is pretty low compared to electricity + cost of ownership: $0.1578 per Hour
You run into the problem of people outbidding you for your instance, but you’re probably training and testing models in batches. For a full reservation it’s 52¢/hour: https://www.ec2instances.info/?selected=g4dn.xlarge (add the gpu columns)
If you needed lower latency or have legal/moral requirements, you could run the same in one of the EU regions.
Do you have an estimate of the duty cycle of the video card?
We run VNC at work and the latency of a Bluetooth keyboard is often higher than the cost of vnc to the nearest Amazon region…
So, I can jump through a lot of hoops and work with latency. Or I can stay with X11 for a few more months or perhaps a year (until the recent Mesa changes start to percolate) and have very fast local development with nearly no latency and no recurring cost.
Like I said, it’s a shame that I cannot use Wayland currently, but it’s not like X11 is unworkable. As a bonus, screen sharing in Skype works ;).
sway feels snappier than i3 on the same laptop (x220). There is no tearing nor flickering when opening ‘ closing / moving windows, something I have honestly not noticed on i3 particularly. The keyboard latency seems also reduced. All in all, it feels snappy. Mini;ni; I have yet to find a terminal that allows for mouse plumbing.
The most missed thing from X for me is a lack of ‘urgency’ support on Wayland. I used to rely on shell apps sending a bell when they needed my attention, and getting a visual notification on i3wm when a workspace had an urgent event like that. But there’s nothing similar that I’ve found using Sway/Wayland (for native Wayland apps), I’ve had to make due with modifying my terminal app to notify-send to mako when a bell happens, and then guess at which workspace the event happened on.
https://github.com/swaywm/sway/issues/3375
Oof. That sounds awful!
Man I wish I could use Mako, but unfortunately it requires systemd or elogind. Just no. I’d rather just use dunst via XWayland.
Yes, depending on the sd-bus library sucks. However that’s the only half-decent D-Bus library out there. The plan is to get basu up and running on non-systemd distributions.
mako doesn’t require systemd or elogind. It does however require dbus (as does dunst if I’m not mistaken).
Edit: sd-bus is required so you do need libelogind at a minimum. You do not need to be using elogind however.
I don’t want anything from elogind nor systemd on my computer. So I guess for now, whenever I’m in a wayland session I’ll stick to using dunst.
It uses systemd’s dbus library, that is all. But, if that is the line you want to draw, by all means.
It is the line I want to draw, I personally have a no-tolerance policy for systemd, and that extends to elogind.
Why couldn’t it just use dbus without systemd or elogind?
dunst uses dbus but doesn’t haven’t a hard dependency on systemd/elogind,
It does, indeed, just use dbus. It happens to use the dbus library from systemd’s repository for it. If you forked systemd, deleted everything but the
sd-busbits, it would work.That’s exactly my point, that shouldn’t be necessary. dunst can use d-bus on it’s own without elogind/systemd.
Having a hard dependency on an init system, or a portion of it, is beyond stupid for something like a notification daemon.
Okay.
I disagree, it’s part of the operating system for many distributions, a specifc component they want to rely on. There are certainly people who want to use the Linux kernel, but are not interested in systemd, but that is not everyone.
And setting that aside, it’s not a hard dependency, as others have already said. It’s a dependency on an interface, at best.
It is a hard dependency as it is literally required at this point in time.
You can not compile it without having elogind or systemd.
But also I think you’re missing the point.
There are plenty of other notification daemons, that do no require any certain init system or a portion of one. That can do the same, or even more than, Mako can. The only difference is that in regards to Mako there’s not really any major competing software for it.
By requiring elogind/systemd, there’s basically a boundry set in place for people who want to rid themselves of using the garbage known as systemd. And that’s totally fine, it’s their software. But they could probably gain a lot more users by not using a dbus interface tied to any one init system.
Might be pretty easy to change if you make a PR or request for it. There’s other dbus interfaces out there.
I would make a PR, but I am garbage at both reading and writing C.
I can try requesting, but I really doubt they would even consider it.
Wait, why not? Any good writeups I could read about the downfalls of systemd?
I don’t really have any resources but my own list of things that drive me insane about systemd.
Every time I’ve tried to compile it, it fails due to missing systemd/elogind. I can try compiling it again.
Is there some sort of like build-time configuration that I’m missing? I have not found any way to compile it without systemd/elogind.
This is directly from the README.
I will personally never be because my window manager of choice bspwm is X only and I am not willing to switch.
What is your WM?
I dislike wayland, but I certainly dislike Nvidia more!
Isn’t that nvidia section kinda wrong ? Looking at KDE Link I don’t see how you can label that as completely “nvidia” related nor unessential. Sure you may be able to run stuff on an “Arch Setup” which only runs i3 on bare metal (which is how I’d call it), but looking that the above the link it’s nowhere near ready for a normal user / replacement of x11.
The same seems to be true looking into the gnome page about wayland compatibility requirements.
So all in all wayland is on its way, but to be fair you really shouldn’t use it as your daily driver, if you don’t want to test an alpha/beta that doesn’t work on 50% of the hardware or freezes when drag’n dropping stuff.
Useful, but I’d appreciate a line item for display of remote applications.
Submitted an issue: https://github.com/mpsq/arewewaylandyet/issues/31
Nice, thanks. :)
One thing that’s still not supported (as far as I understand) is display mirroring.
GNOME and KDE both support display mirroring.
Ah, I guess you’re right. I am using sway, so I wouldn’t know.