The no future of X.org, FreeBSD becomes headless?

Aminavy said:
I have default configuration in wayland as display server, and some changes in window management things.
But when most of applications is X11 applications, why I should use Wayland?
Click to expand...
Exactly!

I have wayland installed here, along with a bunch of windowing environments I don't use so I can show people what FreeBSD looks like other than the odd looking (to those younger than me) CDE I've used since Tru64, HP-UX, SGI, Solaris, and now FreeBSD. (Been around for a long time and I like CDE. But I digress.)

Wayland feels rough around the edges. The vast majority of Wayland display managers, expect for one , don't support PAM or NSS. Certainly a show stopper for me. The one that does, ly, is text only. Wayland needs a lot of work before it can become mainstream. Though Red Hat uses GDM with Wayland. IIRC GDM does support PAM and NSS. That may be an option but your desktop environments are limited unless you want to use Xwayland.

My take is Wayland needs a lot more work before it's seriously useful.
 
ThomasAdam said:
the forks of xorg in NetBSD and OpenBSD that I've noted are more to do with integrating them to the buildsystem ecosystem.
Click to expand...
That would do a lot for the build system for parts of Xorg to get away from gmake, related utilities and other gpl components. bmake from NetBSD is more advanced than traditional bmakes. OpenBSD's build system is different, but it would benefit portability with basic BSD toolchains. Even if Meson is used, there's still parts of Xorg which rely on GCC parts, and portability for BSD systems is good for compilation with the native base compiler and toolchain.

However, I noticed that NetBSD's goal is to maintain all of Xorg's with all of its legacy options. For an operating system which tends to be ported to every toaster, and legacy hardware that makes sense. Though FreeBSD is meant to support 64bit modern platforms, so the goal there is different and can trim out legacy parts of Xorg.

There's parts where there's common motives between operating systems to have an Xorg where all parts are portable and not dependent on gmake related tools. Then, there's a different motive where it can be made modern by removing legacy components. There could still be a common repository, then different BSD operating system pick and choose whether they want legacy components, or trimmed down modern components. Perhaps staying as one fork, to get the build utilities, then having downstream forks for their differences.
 
Crivens said:
So, what is it then?
Click to expand...
The purpose of Wayland is to be new. ;)

It was a bit of a pun on the FAQ here.

Is Wayland network transparent / does it support remote rendering?

No, that is outside the scope of Wayland. To support remote rendering you need to define a rendering API, which is something I've been very careful to avoid doing. The reason Wayland is so simple and feasible at all is that I'm sidestepping this big task and pushing it to the clients. It's an interesting challenge, a very big task and it's hard to get right, but essentially orthogonal to what Wayland tries to achieve.
Click to expand...

Basically, this reads as. "Turns out to replace a proper display system, there are difficult parts that are too hard for me to solve; so I am not going to and just make up excuses as to why I don't need to do a proper job. Instead I will spend the extra time on marketing".

Remote X11 was never as fast as RDP. But in my experiments, still about 10-100x faster and less bandwith than VNC/pipewire with large resolutions.
 
You must log in or register to reply here.
Back
Top