/tech/ - Technology

Smithers, eh? First name "Wayland", is it?

What are the advantages? No tearing and programs can't access my clipboard at all times? Wooooooow.

>>22531
Sway is the best Wayland Compositor (= WM but for Wayland).

> Has it gotten better?
Yes:

- Sway works great, like before
- LabWC is mostly usable if you are fine with OpenBox. In the past, Firefox would sometimes randomly segfault when I accessed the bookmarks toolbar but I haven't tested it with labwc 0.6.5. I heard that Chromium is working fine, though.
- Wayfire is used by default on Raspberry Pi OS now. It's very similar to Compiz and also Labwc/OpenBox. In my experience, it's very stable.
- Hyprland also works but there was some drama with the devs but I forgot…
- Cagebreak is a Ratpoison clone that is missing some features (for example, Cagebreak can remove all splits but it can't remove just 1 split).
- Wofi (program launcher or a "run dialog") is dead, but there is bemenu that just works.
- Hikari (CWM clone for Wayland) is also abandoned by the upstream, I think.

You can consult this list for quick overview of Wayland landscape: https://wiki.gentoo.org/wiki/List_of_software_for_Wayland
I haven't tried screen recording (but grim (+ slurp) can take screenshots just fine) or screen sharing/VNC. There is also ydotool (similar to xdotool) but I haven't tested it (apparently, it requires separate daemon running in the background). I'm not aware of any other usable bar except the one that comes with Sway or waybar.

Ultimately, there aren't that many reasons for switching to Wayland and some of the X11 functionality is still missing. But it's better than it was some years ago.

>>22540
>No tearing

You can also get just as good experience on Xorg if you enable TearFree option with a simple config:
cat /etc/X11/xorg.conf.d/42_gfx.conf
Section "Device"
Identifier "no tearing gfx"
Driver "amdgpu"
Option "TearFree" "true"
EndSection
# replace amdgpu with intel if you have intel gpu.

>>22540
I'm considering switching to wayland only because it gets rid of many vulnerabilities inherent to X11.

Wayland is substantially more secure by default. Xorg is an open sieve. This level of vulnerability in X will never be fixed. Ever.

Also if you measure by SLOC you're not going to find a compositor that's more bloated than Xorg combined with an X compositor and an X window manager. I think the lowest full GUI idle memory usage I've seen was some youtuber's Gentoo build. I think I remember saw 90mb? idle. He used musl-c and dwl (wayland based dwm) with urxvt.

the input lag and having to run so many programs through the xwayland layer kinda suck, but i hope kde and collabora/valve can get to that soon

>>22531
>Xorg has a lot of tools of varying usefulness that Wayland didn't back then. Has it gotten better?
Yeah.
https://arewewaylandyet.com/

>>22558
>>No tearing
>You can also get just as good experience on Xorg if you enable TearFree option with a simple config
not true, if i have different mixed refresh rate panels and enable 144hz/freesync on the highest one i will ALWAYS get tearing on the lower refresh rate monitors
sway just werks

>>22558
>>22585
yea trying to remove tearing under xorg is a very luck of the draw thing depending on what hardware you have

>>22585
>>22586
Use compton, or KDE's compositor.

>>22587
when i used it compton didnt work ootb on my computer and had to fiddle with the settings for like 30 minutes lol

>>22587
compton is dead. There is active fork called picom.

Trying out Wayland. Can't decide between Sway (i3 clone, very devleoped) or DWL (dwm clone, made almost by one guy). I hate Sway's manual tiling and it uses more CPU and memory than DWL but it's much more complete too…

>>22609
I'm actually comparing it now and it seems Sway uses less CPU than DWL… but I love dynamic tiling… Augh…

>>22609
Dwl, like most wlroots based compositors still lags behind and currently spits out a bunch of compilation errors if you try to use it. I suppose that's what it gets for being one guy's hobby project.
Sway is quite good but like you say it doesn't come with the ability to open windows in a spiral pattern so I installed a package called autotiling-rs that does it.

>>22566
What about sx from Suckless Tools or xenodm from OpenBSD tho? They minimize the attack surface and disable certain features. Though I agree that startx is insecure.

>>22817
All X servers still have the problem that allows all X clients (programs) to capture input from all other X clients. Only way to stop it is to either use Wayland or run everything in separate Xephyr instances (in other words, use a separate X server for each program).

wayland using like 20% less battery than X was enough to make me switch tbh

>>22876
Or run everything in isolated VMs like in Qubes (which you should be doing anyway).

Wayland is probably a lot better than X, but that doesn't mean I have to like it.

Something I value a lot in software, to a degree that I don't think a lot of others do, is stability and compatibility. In my ideal world, a piece of software written now would continue working on the same operating system until the end of time, with the only major hurdle to getting it running being maybe compiling it.

The shift from X to Wayland means throwing out decades worth of work for the sake of a problem that, quite frankly, didn't really need solving to begin with. I've made some pretty damn cool setups in X, and those setups don't transfer to Wayland.

>>22891
>a problem that, quite frankly, didn't really need solving to begin with
quite a lot of people disagree, especially X developers lol

>>22891
>In my ideal world, a piece of software written now would continue working on the same operating system until the end of time, with the only major hurdle to getting it running being maybe compiling it
Boomers have killed Lisp machines.

>>22531
For me, it's Arcan.

>>22891
backwards compatibility is a reactionary meme
no point in keeping archaic software from decades ago alive
old software isn't like an old musical instrument or an old work of art
it only gets more actively useless and obstructive with time

>>23055
>backwards compatibility is a reactionary meme
All widespread architectures like VAX, X86, PPC and Intel mainframes back until System/360 were compatible with their predecessors, before emulators became commonplace. Apple built an emulator for every architecture transition and Symbolics sold an OpenGenera emulator for X86-64 that is still available. Backwards compatibility has always been a major consideration in systems design, something that is sorely lacking in much of modern software infrastructure, because it is something every user of the system relies on to an extent.
Even the linux kernel takes pains to maintain a reasonable level of backwards compatibility by default and provides compile time options for decade-old configurations. Consequently ELF is a stable format and all statically linked software from the last decade usually continues to run unmolested. Obviously backwards compatibility matters to a lot of people.
The SystemD/Linux ecosystem however has attracted a crowd similar to the 13 layers of dependencies webshit developers. They have no inhibitions about tieing their programs to abominable, hack-of-the-month libraries with backwards-incompatible releases every other month, nor tearing down their own projects and all related infrastructure on a whim.
All that is to say, the broken freedesktop-school of infrastructure takes away the users' freedom to continue using their chosen software, and also causes headaches for any developers naive or desperate enough to link against it. If things weren't as bad as they are, why do you think people would willingly use flatpak? Your justification about software quality reads like pure projection.

>>23035
Is it named after this guy?
https://en.wikipedia.org/wiki/Arkan

>>23055
>backwards compatibility is a reactionary meme
Dialectically speaking, it has both reactionary and progressive aspects. Progressive in a sense that it provides a basic software stack needed for further development that would otherwise not get developed because nobody cares like in the case of PinePhone ("chicken and egg" problem). Reactionary in a sense that some legacy stuff will create more problems over time. The solution is to refresh some components from time to time but not to rewrite the entire operating system from scratch or to provide legacy interfaces and compatibility for new software that do not affect their functionality (XWayland is a good example of this). Or to just follow POSIX for Stallman's sake (which is still reactionary as Emacs and NixOS have demonstrated so its not required… although there's also systemd…).

>>23055
>old software isn't like an old musical instrument or an old work of art
True, many video games for example are unique and stand on their own as pieces of our culture. Software tools and utilities are generic and replaceable like your typical racing or soccer simulator. You want a Libre and Open Source ARMA III? Just make it yourself. Duh. It's hard but it's possible.

>>23055
>>23120
old software is just as difficult to rewrite as old games, and would be done for the same reason, because the newly made stuff is shit

>>23119
Another dialect in software systems trends seems to be monoliths vs "do one thing and do it right" style.

Whatever we choose we go fucking all in and make an incomprehensible cosmic horror that both controls us and terrifies us.

>>23139
Retro games are played not because they were """better""" (at least not necessarily: there are some retro gaming snobs just as there are modern gaming snobs). They're played because they're good games.

If modern software and games are shit it should be treated as a bug just like security holes should.

>>23055
There is definitely point in keeping archaic software alive: it's still useful. And however useless it becomes with time, it's still more useful than something that doesn't exist.

>>23151
emacs is not archaic, it's from the future

>>23152
Genera was the future! Zmacs is to modern emacs what plan9 is to linux.

>>22609
does sway have configurable gaps