The only thing to boycott are GNOME dev’s mentality when it comes to things outside their DE (especially Wayland protocol adoption). It’s slowing Wayland development a lot
I agree. I am personally a fan of server side decorations. I use tiling Window managers which means I do not need to have extra buttons (browsers) or bars (looking at you, thunar) to close, minimise of fullscreen an app. Heck, one of the reasons to use a tiling wm is to maximise the usage of screen real estate and with these extra bars and buttons you’re taking some of that away!
They have no intention of sparing a thought for anything that isn’t gnome. It’s a shame considering their corporate funding and influence over the linux desktop.
In the Networkmanager you can set that a connection is either available to all users or just yourself. If you set it to “all users” its configuration will be saved somewhere in /etc/Networkmanager (I’m too lazy to look up the real path) and will therefore be available for Networkmanager on boot. If you just make it available for yourself Networkmanager will only attempt to connect after you log in.
I think the default is to make it only available to yourself, because then you don’t have to enter your sudo password when you set it up or want to change something. The downside is of course what you describe in your post.
The same wayland bait is posted every week from new ban evading accounts which eventually also get banned.
They keep coming and getting shown the door, like Barney here.
Yea, don’t hesitate to report them.
Honestly, I literally couldn’t give a shit that anyone criticizes Wayland itself, but they’re a generally toxic user that’s easily recognizable by their constant hateboner for Wayland (among other things).
I used to be super excited about Wayland but it’s been 15 years, now I’m too old to care.
My favorite distro still runs on xorg and it runs so well that I don’t remember why we needed Wayland in the first place. (I am not saying that there is none)
Tearing videos and games have been fixed on xorg when Wayland was supposed to be the only solution.
I am sure Wayland will eventually make X completely obsolete and will be a much needed modernisation of the Linux desktop stack.
But I can’t help but notice that it is not there yet, is old enough to carry it’s own significant technical debt and might never bring the simplification and streamlining that it once promised.
It is a tiling Wayland compositor that is only a couple of megs in size. On Oasis Linux, I launched into Velox, opened a terminal, and checked the memory usage. It was under 30 MB of RAM. That is for the whole system!
That experience made me think differently about Wayland.
There was only one Xorg. For me, the evidence that it was big and complicated is best expressed by the fact that, over decades, the number of projects that competed to provide X had dwindled to one. There was loads of unhappiness with it and yet, there were no forks. Why?
Now Wayland. There are new Wayland compositors all the time now. I just saw one yesterday—Louvre. The basis for Velox above is SWC. There is Wayfire. There is Weston. There is of course wlroots. And both KDE and GNOME have made their own. I think somebody even wrote one for Haiku! For me, this is evidence in itself that making a Wayland compositor is easier than implementing X.
It also means that all these Wayland compositors can compete with each other and drive each other. It means that I, as the end user, can pick a super stripped down version when that is what I want and an all-singing, all-dancing version when that is what I want instead. In some situations I will be happy with, and thankful for, Velox and in other situations I will want GNOME.
It is taking a long time and the journey has not been smooth. That said, I am becoming quite confident that we are in a much better place. For normal uses, Wayland is in a good place now. The level of innovation is very high. Dev can start to shift from the basics to the extras. I fully expect that we are heading into an exciting time on the Linux desktop.
X has a singular fully functional implementation into which you can slot a wide variety of components. Because everything is a component that slots into the singular X implementation forking has both a low benefit and a high cost.
Wayland is just a protocol everyone must implement with a semi useless reference implementation that nobody would ever use. Nobody forks Wayland they just implement it as they must the X approach isn’t available.
It’s apples to oranges. A meaningless comparison. Its more just churn than innovation on the part of desktops.
That said, everything you said about the Xorg server could be said about wlroots. Nobody has to “implement Wayland because they must” anymore. The X approach is available in Wayland as you can build your window manager on top of wlroots and many do.
Seems fairly apples to apples to me.
Or you can choose a competing compositor library as there are now quite a few available. I think XFCE is looking at using Wayfire. Or you can control more of the stack directly and write your own as GNOME and KDE are doing.
Not only do you not have to implement Wayland to make a window manager, because compositor libraries are available, but people are writing Wayland compositors even though they do not have to. Louvre is a compositor recently released that seems expressly designed to make writing new window managers super easy.
As for innovation, there seems to be lots in Wayland. Valve just added HDR. GTK is looking at using dmabuf. There are already Wayland window managers that are not ports from X. There seems to be innovation at every level.
Building on top of wlroots is still a different scope of problem than writing a window manager for X. Pretending its the same thing doesn’t change the fundamentally different architecture even if it certainly makes it easier.
Out of all the libraries isn’t recent KDE the only fucking one that supports proper scaling of xwayland windows without turning it into a blurry mess? KDE which nice as it is lacks most of the nice tiling features of i3wm or the per monitor workspaces? Let me rip out and throw away a highly functional Nvidia GPU and come on down!
Don’t worry in another fucking 10 years all problems will be solved in the meanwhile I’ll just be fucking using non-beta software. Pardon me if I’m a little annoyed. Wayland has been the future for a while now.
Yeah, I don’t see a reason to use Wayland unless it’s a drop-in replacement for X.
I don’t have any issues with X. I’m glad it works and I don’t even know it’s there.
It doesn’t make sense for me to adopt something newer that works worse when I have something that works without issue right now.
I bet when Wayland reaches the maturity, adoption, and stability of X, people are going to be moving to the next broken thing that will be functional in 15+ years.
Does Wayland allow for the running of a program on a big powerful server (where many users live) and display on a smaller desktop machine that is only providing a screen and keyboard? If not, are they working on that? If it does not and they are not working on it, is it even possible under the way that Wayland works?
Waypipe is not Wayland. Wayland does not natively support this workflow, which is why Waypipe was created. Please don’t confuse the two as being one thing.
You are giving me the impression that Waypipe is an extension to Wayland like XRANDR is to the X11 protocol. I didn’t get that impression from the blogpost. I’m not trying to place value on them being an extension or a separate tool. I’m just trying to figure out if it was a shortheaded response or if Waypipe is an extension to the Wayland protocol.
This may be “moving the goal posts”, if so I apologize in advance. With Waypipe can I have local windows and remote windows on my laptop? Will Waypipe work over a VPN (Tailscale is a VPN right?)
If I remember, there was another display protocol being developed as an answer to Wayland for BSD. I don’t remember what it was called, but that project was basically about an open source MacOS.
I think the predecessors to RavynOS, it was called HelloSystem I think. In that project, they were talking about an alternative display server protocol.
I haven’t used Kali Linux before, but hcxtools is available in the Debian repos so presumably your /etc/apt/sources.list is invalid (probably the LiveUSB has disabled non-iso sources). Can you post what is in that file?
First, make sure your VM has access to the internet, for example with ping 8.8.8.8
Then do sudo nano /etc/apt/sources.list
The file should include a line that is exactly this: deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware
(or it could have kali-last-snapshot in place of kali-rolling)
If not, replace everything in the file with the line above and save the file with Ctrl+O, then close the editor with Ctrl+X
Then run:
I’m very new to the Wayland vs Xorg: could someone tell me why having a compositor work as a compositor, server and client (window manager) is a good idea? Doesn’t this limit customisation? If someone wants to create a window manager, they’re going to have to implement a lot more software than just their product. I thought abstracted software with stable interfaces was king in software, other than having performance issues (I believe Wayland solves some of these problems).
So, if I’m on IceWM/Ratpoison and want to switch, do I manually convert my config, or do I have equivalent WMs in Wayland?
There is nothing stopping a Wayland compositor from exposing an interface that would allow for a choice of “window manager”. In fact, wlroots could almost count as such a compositor - it implements the bulk of a compositor, but none of the bits of a window manager. Of course, Plasma and Gnome also allow window managers to be integrated as plugins, but I presume that is not what you want.
It is not like the X window manager idea is impeccable either: To name one thing, picom or other compositors could display much nicer and context aware animations if only the window manager interface was not like it is.
linux
Oldest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.