A response to the "Boycott Wayland" article

Link to article: gist.github.com/…/9feb7c20257af5dd915e3a9f2d1f227…

This OUTDATED article gets posted all the time. The full story is the guy is a massive FreeBSD fan so he is trying to convince more people to keep on using Xorg because he wants to make sure it isn’t abandoned. Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries.

Let’s go through the article point by point:

Wayland is broken by design:
  • A crash in the window manager takes down all running applications: Yes, because the compositor IS the server, window manager AND compositor at the same time.
  • You cannot do a lot of things: What, like allowing Windows to see your keystrokes, which makes developing a keylogger absolutely trivial?
  • There is not /usr/bin/wayland: Yes, because Wayland is a set of protocols, which a bunch of projects can implement as few or as many of, as they see fit, thus avoiding the issue of “unmaintainable mess” that has plagued Xorg for years.
  • It offloads work to the window manager: Again, yes, that’s a part of its structure: do the protocols, then let the compositor implement them. That way, you have multiple implementations running simultaneously that are well integrated with their window managers and thus more efficient and performant. It also means that when a compositor suffers from too much cruft, we can just make a new one, while application developers wouldn’t really have anything to change because if their application works on Wayland, then it works on different compositors (unless it is made specifically for GNOME, or specifically for wlroots, like wlr-randr)

…so what works on DE 1, doesn’t necessarily work on DE 2: True, because oftentimes, it doesn’t need to. Not implementing features can lead to a more lean and streamlined software solution. However, sometimes features are necessary and only implemented in some compositors. This usually happens because the universal solution is not ready. KDE are often known to do this with Plasma and KWin.

  • Wayland breaks screen recording applications: Correction: The following screen recording applications were not built to support Wayland (because Wayland is new to them or they just decided not to, or they were either too busy or too irresponsible enough to realise Wayland is coming, and has been for over 10 years. In defence of the devs, they probably wanted to make sure Wayland will become stable enough, but it has been the default even on Debian for many years now, so…

In terms of the applications, I’m not aware of many of them, and for this sort of application, I’m sire alot of work is required to change the graphical backend, so I understood that some smaller projects gave up, but OBS has been working on Wayland for quite a while. Is it perfect? I don’t think so, but back when Brodie Robertson was using Hyprland, he was recording his videos using OBS. This article is quite outdated.

  • Wayland breaks screen sharing applications:

As the update shows, Jitsi now does work on Wayland.

Zoom only seemed to work on gnome, BUT if you open up the Link to the zoom issue and read through the comments, there is clearly a person that clearly states that they changed /etc/os-release from PureOS to debian and it worked for them, all because of some pointless limitations enforced by the Zoom developers. As the person posting the issue states “Currently, the zoom application has put an arbirtrary restriction on screensharing so it ONLY works on GNOME, when the api being used works on all wayland desktops.” Read that again. It’s a pointless restriction put there by the Zoom team because they couldn’t be bothered to test anything non-GNOME.

And the last issue is a problem with the article writer’s own appimage. I don’t know about that one.

  • Wayland breaks automation software

As stated IN YOUR FACE, it is an application that works on X11 only. Yes, Wayland is not made to use such applications, but it doesn’t mean they can’t exist. Every heard of ydotool (remember that name)? Now you have.

Next up, we have 3 issues about GNOME and KDE global menus (1 for GNOME, 2 for KDE). From the little I know about global menus and using these projects, as well as considering that they are both incredibly stable on Wayland and Fedora KDE will be dropping Xorg completely, I think it’s safe to assume these issues have probably been fixed. Please correct me if I’m wrong.

  • Wayland breaks AppImages that don’t ship a special QT plugin: Great! Just ship the plugins then! Problem solved! Also, quote from the article: “However, there is a workaround: “AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode” (see below).”
  • Wayland breaks Redshift: Once again, a program built for Xorg doesn’t always work on Wayland. Especially if it works with the compositor, like a colour temperature control application, or a wallpaper setter. The article quotes that “Redshift does not support Wayland since it offers no way to adjust the color temperature” which is not true, as proven by Redshift alternatives like Gammastep.
  • Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure, but Hyprland has not allowed that to stop them from implementing a solution where you can choose keys that will be passed on to the application. Boom, problem solved. Unfortunately, it doesn’t seem to be implemented anywhere else, as far as I know.
  • Wayland does not work for XFCE: Come back to me in late 2024 after XFCE 4.20, which will introduce Wayland support, has been released. Also, wiki.xfce.org/releng/wayland_roadmap
  • Wayland does not work properly on Nvidia Hardware: It keeps on getting closer but is not there yet, or so I’ve heard. Apparently, the issue is with the proprietary drivers, as noveau works well. But I use AMD, so I’m only working off rumours and opinions here.
  • Wayland does not work properly on Intel hardware: Again, I’m using AMD, so I can’t confirm or deny this, but considering the Intel drivers are open source, and I’ve heard about many, many improvements made on the Intel side of things, I think it would be reasonable to assume it has been fixed.

Edit: As multiple Intel users have pointed out in the comments, there seem to be no issues on Wayland with Intel hardware.

  • Wayland prevents GUI applications from running as root: This one has been crossed out as the article writer admits there is a solution
  • Wayland is biased towards Linux and breaks BSD: Arguments seem valid, and I’m guessing, are correct. This one is likely true and will remain so for the foreseeable future.

Edit: And yet, it seems that there are Wayland compositors for FreeBSD, so the above might only be true for OpenBSD and others.

  • Wayland complicates server side decorations: From what I’ve heard, this is true, mainly something to do with some GNOME agenda, as the article states. I think that one is true.
  • Wayland breaks windows raising/activating themselves: The linked issue is closed and seems to be resolved. There is a mention of a WIP protocol at the time (2019) that woukd fix this. I had difficulty following the discussion, but I think this has been fixed.
  • Wayland breaks RescueTime: Because RescueTime depends on X11-only tools like xprop.
  • Wayland breaks window manager: What you’re describing is Wayland breaking X11-only tools for doing various tasks in a window manager. They are X11 tools, so of course they don’t work on Wayland. I’m not sure if there are alternatives, but I’d guess there probably are. I know for a fact that Xrandr has alternatives like wlr-randr and kanshi for wlroots.
  • Wayland requires {instert WM here} to implement Xorg-like functionality:Yes, it does.

Quote from article: "As it currently stands minor WMs and DEs do not even intend to support Wayland given the sheer complexity of writing all the code required to support the above features. "

DEs: GNOME, KDE, MATE, XFCE, Cinnamon, Budgie, Enlightenment, and recently even Pantheon have either announced to start work on, have started work on, or already support Wayland.

Window managers: Qtile is doing it. Xmonad wants to hire a dev to do it. Dwm has a spiritual successor called dwl. i3 has a drop-in replacement called sway. Openbox has 2 spiritual successors called labwc and waybox. Now you might notice one of the biggest WMs is missing on here: AwesomeWM, which is such a shame. The Awesome devs have said they would be okay with someone taking on that challenge (which has already been attempted, as evidenced by the existence of way-cooler), but it seems that they wouldn’t do it themselves.

As for the projects mentioned in the article, (JWM, TWM, XDM, IceWM) they are too small and obscure, and will likely fade away with Xorg.

  • Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol I don’t know about that one, ao I’ll assume it is still the case. Edit: Ignoring the fact that the link is broken, it basically just links to a docs change where skipTaskbar is marked as unsupported on Linux. Link: github.com/electron/electron/pull/33226
  • Wayland breaks NoMachine NX The link points to a page that has this marked as “SOLVED, Released in version 8” so I’m guessing it has been solved.
  • Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

Edit: As pointed out by some people in the comments, there are also alternatives to xclip like wl-clipboard.

  • Wayland breaks SUDO_ASKPASS: That link seems to point to the way this issue has been resolved so I don’t see your point.
  • Wayland breaks X11 atoms: I lack knowledge on the topic so will assume this to be a valid argument
  • Wayland break games: I’m 99% sure you can disable Vsync??? But I’m not a gamer. Also, WINE on Wayland is getting better and better. Soon enough, I hope the subpar performance will become better performance (when compared to Xorg)
  • Wayland breaks xdotool: Well, yes. There is ydotool, but you’re looking for a 1-to-1 replacement and I’m not sure if ydotool fits the bill for that.
  • Wayland breaks xkill: Well, yes. Again. It is an X application, so of course it does. Though for some reason I remember it working once on wayland. Must have been an xwayland app, or maybe I’m just misremembering this.
  • Wayland breaks screensavers: Yeah, that seems to be the case.
  • Wayland breaks setting the window position: That is a WIP for Plasma, not sure about any other projects, so assume true for anything else.
  • Wayland breaks color management: Not anymore. That is being actively worked on.
  • Wayland breaks DRM leasing: While not rhat familiar with the issue, my understanding of the topic is the article is correct: not all compositors support it.
  • Wayland breaks in-home streaming: Not familiar with this, so will assume true.
  • Wayland breaks NetWM/EWMH: Yeah, that seems to be the case.
  • Wayland breaks window icons: Yeah, that seems to be the case, as said in the article, when no .desktop files are used.

And that concludes my response to this article based on my fairly limited knowledge on the topic. If I got anything wrong, please, please let me know. As you can see my knowledge is quite limited, and as such, any corrections (preferably backed up with evidence) would be appreciated

rah, (edited )

Wayland … uses some Linux-specific components or libraries

No. Wayland is a protocol, not software.

LeFantome, (edited )

What they are talking about is that some of the Wayland compositors rely on things like libinput and libdrm which are Linux specific.

This is not “Wayland” really but, from the point of view of a regular user, it may as well be. As the OP points out, there is no /usr/bin/Wayland

It is not really a great criticism although it must be frustrating for the BSD folks and others. Of course, the answer like always is to contribute. Nothing stopping anybody from taking wlroots ( or whatever ) and adding abstractions that make it more portable.

Non-Linux operating systems have already added Wayland support ( like Haiku ). If I had the time, I would add it to SerenityOS myself.

Actually, if I had the time, I might write a WaylandServer for X. First, it would be funny. Second, the people that do not want to move could stay on X forever even when everything stops supporting it. I would have to make sure that my WaylandServer could run XWayland of course.

TootSweet, (edited )

Yeah, I was going to ask if the Wayland protocol included some Linux-kernel-specific data structures or something that would make it somehow more awkward to implement on non-Linux kernels or something.

Like if I created a protocol that included sending data encoded using the Python serialization framework called “pickle”, one could say that was a Python-specific protocol in that while it would be possible to use that protocol from other languages, it would be very weird and awkward to do so at best.

Not really knowing much about the specifics of Wayland, I wouldn’t truly know if there could possibly be anything Linux-specific in Wayland. But as far as I know, it’s entirely possible theshatterstone54 knows something I don’t.

sederx,

idk i feel the window manager space its losing a lot with wayland and i didnt have a great experience with any wayland versions of existing WM. without even talking about the nvidia shitshow, does sway still call you a bitch for even trying to run it on nvidia?? imma stick to dwm as long as it works

theshatterstone54,

I didn’t have a great experience

Neither did I. I use Qtile, and I’m waiting for some things on Wayland to improve. It’s close, but not there yet.

r00ty,
@r00ty@kbin.life avatar

I think this is ultimately the answer. I'm not going to judge wayland until I see it as ready and can truly replace X in all use cases.

I sometimes feel like the distros switching now is premature. But, maybe they know something I don't.

kurcatovium,

I believe they try to force it asap to make pressure on applications developers to really speed things up.

When I dumped windows for the first time (maybe about 5-6 years ago) I immediately stumbled upon articles about bad wayland needing decades to mature. And here I am couple years later running linux on wayland quite happily.

theshatterstone54,

Fedora is switching because Fedora is always trying to be first at everything. And because things are very close tp perfect, it means that when Fedora makes the switch, a bunch of users will use Wayland more, helping iron out the last few bugs and issues.

sederx, (edited )

i just tried again, its literally impossibile to compile dwl on ubuntu 22 since libwlroots-dev is too old so youd have to compile that manually… stuff like this is what keeps me away from wayland for now

theshatterstone54,

I tried on Debian 12 a few months ago and failed.

sederx, (edited )

yeah you need wlroots 16 which is not there, trying now to compile from source but you also need to compile wayland manually…

edit

tried anyway and after compiling libdrm wayland-server pixman and other stuff i give up. this is not worth it

RTRedreovic,

No, running sway with the --unsupported-gpu flag launches it without any remarks about your hardware. It’s been like this for a good while.

grue,

Do the Wayland devs care about implementing network transparency yet?

LeFantome,

No, and I do not expect that they will. They consider it a feature independent of the window server. To them, it is a feature, not a bug.

grue,

It’s hardly worthy of being called a “window server” if it isn’t network transparent…

Ullebe1,

I doubt it’s ever going to be a part of the core protocols, but it doesn’t have to be, you can just use Waypipe.

ShittyKopper, (edited )

TLDR of linked gist: wayland is not X therefore it is bad. end of.

Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

also, github.com/bugaevc/wl-clipboard. perhaps all OP (of gist) needs is a simple shim that can convert calls to xclip to wl-copy/paste? that doesn’t seem too hard to make compared to keeping X.org alive I’d say (perhaps they should try making it if it’s that much of a problem)

Wayland breaks screensavers: Yeah, that seems to be the case.

from the dev of xscreensaver at www.jwz.org/blog/…/wayland-and-screen-savers/ :

[…] Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. […]

[…] Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11. […]

other people can comment on the parts they know about, these are two i know of off the top of my head

magic_lobster_party,

Who even uses screensavers these days?

Zak,
@Zak@lemmy.world avatar

Screen locking has obvious use cases.

magic_lobster_party,

Screen locking yes, but that’s not screen saver.

Zak, (edited )
@Zak@lemmy.world avatar

In the modern era, the main purpose of a screen saver is to lock the screen, and has been for most users for a long time. Many of us would also like to have pretty pictures on our locked screens.

It no longer has anything to do with preventing burn-in, so you’re right from a certain point of view.

magic_lobster_party,

But locking the screen is not the purpose of xscreensaver. It’s mostly just an overlay with animations.

Zak,
@Zak@lemmy.world avatar

To quote its author

On X11 systems, XScreenSaver is two things: it is both a large collection of screen savers; and it is also the framework for blanking and locking the screen.

Strit,
@Strit@lemmy.linuxuserspace.show avatar

Screenlocking works just fine. That was not the issue mentioned.

RickyRigatoni,
@RickyRigatoni@lemmy.ml avatar

businesses that want to put their logo or slogan bouncing around on monitors of inactive computers

that’s about it

TimeSquirrel,
@TimeSquirrel@kbin.social avatar

I still install the MatrixGL screensaver every once in a while for shits and giggles on a new install until the gimmick wears out.

RTRedreovic,

Amazing text! I was just commenting how ridiculous the article is this morning and now you have written a more lenghty criticism.

As for the Zoom bit. I will add my 2 years experience of using it on Wayland on Artix as well as Void Linux - I never used Gnome and it worked fine on Sway and River on my iGPU. In between a few updates I did face a few crashes of zoom when rendering on my nvidia gpu but it was still fine. I have not used zoom in over an year so I can’t comment on how it is now.

As for “wayland does not work properly on nvidia.” Solely nvidia is blame. They have been pushing out patches to bring out more support but it’s just nvidia who can fix that in the end. While I would not want to assume what hardware the author uses. Wayland works like butter on my Intel hardware.

Great alternatives for xclip and many other X-tools are already in the market.

The VSync issue on wayland is genuine. Disabling it in-game does not affect anything because it is enforced by the compositor. VSync is an integral part of Wayland Compositioning (acc. to the wlroots dev) but a solution to automatically disable it in full screen applications, etc is down the pipeline and work is ongoing. I have not been following it but I think some fixes were already released, I could be wrong.

As for X11 Atoms: stackoverflow.com/…/x-to-wayland-what-about-atomsJust boils down to the application dev’s willingness to port the app to Wayland. The author of the ‘boycott wayland’ article seems to just want wayland to implement Xorg 1:1 for it to not fail their stupid standard of what-should-be-boycotted. And at that point Wayland is not Wayland but Xorg.

Most of the arguments presented in the ‘Boycott Wayland’ article are either generic issues being worked upon by the devs or things that don’t have much relevance but put down in a manner as if to almost fear-monger that Wayland is the spawn of the devil and must not be used at all.

taladar,

As for “wayland does not work properly on nvidia.” Solely nvidia is blame.

Nobody but Wayland apologists cares who is to blame. If it doesn’t work on their hardware that clearly is an issue with the idea that Wayland should completely replace X11/xorg because out of Wayland and Nvidia if one of those two goes away it will be Wayland, not Nvidia.

RTRedreovic,

You clearly do not know what you are talking about so I have no interest in giving more value to your already worthless comment. It is amusing that you must introduce the term “Wayland Apologist” as if that has any meaning in this sector.

taladar,

So I guess you don’t have anything but insults then to refute that blame is at best a secondary issue and most likely a complete non-issue for people on whose systems Wayland won’t work. Unless all you care about is playing blame games but not about the actual practical issues blame is irrelevant.

russjr08,
@russjr08@outpost.zeuslink.net avatar

I mean, you started your comment by saying “Wayland apologists” - I’m not sure why you thought it would go over just fine.

Which is unfortunate that you did, the Linux community already has quite a bit of hate for Nvidia (for good reason) but comments like these tend to just make people who use Nvidia hardware look bad. I say this as someone who made the exact same position on the argument (so to speak) in a similar thread a few days ago.

InEnduringGrowStrong,
@InEnduringGrowStrong@sh.itjust.works avatar

https://sh.itjust.works/pictrs/image/029702e7-ca14-42cd-9b39-9e35dc47649e.jpeg

theshatterstone54,

???

Please explain

InEnduringGrowStrong,
@InEnduringGrowStrong@sh.itjust.works avatar

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.

theshatterstone54,

Oh ok. That makes sense. Thanks

Rustmilian,
@Rustmilian@lemmy.world avatar

The worst part is that person is using the Wayland bait to push anti-trans propaganda.

InEnduringGrowStrong,
@InEnduringGrowStrong@sh.itjust.works avatar

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

FishFace,

I don’t think a good response to " breaks " is to say "yes, because was designed to work with and hasn’t been updated to use ". Part of the task of replacing something old - onerous though it be - is to provide a smooth route to support old programs and functionality.

Wayland deliberately broke everything, but then was rolled out prematurely at least on some distros, before giving the vast X ecosystem enough time (which was guaranteed to be a long time, due to how large and entrenched it was) to update. Besides which, the “OUTDATED” post has an awful lot of things you acknowledge are still issues!

taladar,

I would argue that promoting Wayland as production ready is still premature considering the number of excuses Wayland proponents have to make who is at fault for Wayland’s shortcomings (Nvidia seems to be a big one but people who have needs the short-sighted protocol design didn’t account for are a close second).

Strit,
@Strit@lemmy.linuxuserspace.show avatar

The problem, as I see it, is that the author of the original Gist does not really want wayland replacements for what he has, but rather what he has to also work on wayland.

Wayland didn’t break everything. It broke what relied on X11 specific stuff, which turned out to be a lot of things. The vast majority of issues still present with Wayland are edge-cases that will only see the light of day when the people with those edge-cases start using wayland. And as long as distros default to X11, that won’t happen. So that distros, like Fedora, started defaulting to Wayland “early” on (yes I put early in quotes, because it’s only perceived as early) is actually a good thing. Makes the compositor developers aware of edge-cases they can’t catch themselves.

I’vge been using Wayland exclusively for over a year and apart from a couple of small bugs, not even missing functions, I haven’t experienced any issues relating to Wayland directly. But that’s for my use case. YMMV as always.

be_excellent_to_each_other,
@be_excellent_to_each_other@kbin.social avatar

The problem, as I see it, is that the author of the original Gist does not really want wayland replacements for what he has, but rather what he has to also work on wayland.

It's like the Windows users expecting to use all the same software on Linux when they move over problem, but in microcosm.

RTRedreovic,

The main issue here is not that some of the issues that are mentioned there are not genuine. They indeed are genuine and have mostly already been notified to the devs working on the protocols and the compositors. The issue here is how those are presented. By creating this almost cultish “battle between the 2 display servers” thing is not productive and demoralizes developers. Making criticism is one thing and productive but “boycotting” is not. And certainly not in the bad faith way the author of that article has done. I myself have both X and WL setups and I alternate between them frequently. I am not sitting here “boycotting” one display server in a prejudiced manner. This is Linux, not Windows or MacOS. Users are free to continue using Xorg and develop it according to them if they do not like something else. And similarly, they are free to use Wayland.

superminerJG,

From a developer’s standpoint, one of the bigger pain points of Wayland is window embedding.

If you want to embed from an external process, the only way to do this is to have your application expose its own Wayland compositor and then have the embedded process use that Wayland compositor. No one has made a library for this as of yet.

If you want to embed from the same process, it shouldn’t be too difficult; you just need a wl_subsurface. However, this doesn’t work too well with most GUI toolkits.

Wayland is just radically different from every other windowing API, and I’m hoping that the GUI toolkits can adapt.

NoLifeGaming,

Although I don’t currently use Wayland I’m excited and look forward to its continued development.

art,
@art@lemmy.world avatar

Boycott Wayland. It breaks everything!

Other should stop just using it because it doesn’t work for you? Wouldn’t it make more sense that those who do work on it keep improving it so it doesn’t break?

ssokolow, (edited )
@ssokolow@lemmy.ml avatar

Lemmy hangs whenever I try to post my response (I suspect it doesn’t like the length), so here’s a link to it on Github Gist:

gist.github.com/…/16c9311573eabc7343ff7ff2cc3513b…

It begins as follows and I’ve tried to hyperlink my sources as often as possible:

I’ll try to fill in some of the knowledge gaps and respond to some of your answers from a more user-centric perspective.

snor10,

I’ll switch to Wayland when XFCE makes the switch. For now, X is sufficient for me.

zjaume,

In what kind of world is a missing feature or a broken feautre due to incomplete migration to a new ecosystem, a reason to boycott that new ecosystem?? Those are simply not valid arguments to me.

They are obviously valid arguments to say, hey, this work is not completed, is not mature enough etc. So, therefore, you stay with previous ecosystem. But to boycott it because of that? That does not make sense to me at all.

jokeyrhyme,
@jokeyrhyme@lemmy.ml avatar

Wayland breaks global hotkeys: I present to you: Hyprland (where you can get global hotkeys). Now, it is normally not allowed by design, as a security measure

Not disagreeing at all, but I’d like to add some information here to support your correction

There’s a GlobalShortcuts portal ( flatpak.github.io/xdg-desktop-portal/docs/-… ), and this is implemented for hyprland in xdg-desktop-portal-hyprland ( github.com/hyprwm/…/hyprland.portal#L3 )

So, technically, there is nothing in the wayland collection of protocols that supports global keyboard shortcuts, but (along with lots of other supporting functionality), this is addressed via the collection of portal APIs

As it happens, KDE already supports the GlobalShortcuts portal: invent.kde.org/plasma/…/kde.portal#L3

Any desktop can provide an implementation of the GlobalShortcuts portal, and any app can adopt it as required (although if it’s implemented within popular toolkits/frameworks, then app developers won’t have to even think about it)

Here are related tracking issues:

crypto,

@theshatterstone54 > "Reason for that being that Wayland is built with Linux in mind and would not work under FreeBSD without a lot of effort bwing put in as it uses some Linux-specific components or libraries."

Not so. FreeBSD is 100% Linux compatible and has Linux Kernel emulation built in. Wayland support is also built in to FreeBSD. FreeBSD is a much superior operating system compared to Linux. But the FreeBSD team only cares about the server aspects and really does not care about a graphical desktop. They tend to use Macs.

FreeBSD Documentation Portal

The state of Linux Desktop interface is a schizophrenic flustercuck with far too many cooks spoiling the stew. They're not just spoiling the stew; they're pooping in it. And a bunch of noveu-riche trust-fund baby nerds think this is cool. They don't give a rat's ass about the end user being able to get work done. They would rather we all waste our time filing bug reports rather than getting things done.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • linux@lemmy.ml
  • localhost
  • All magazines
    •
    Loading…
    Loading the web debug toolbar…
    Attempt #