Re: Xorg vs Wayland (and MIR?) - future for NetBSD X ?

[Swift Griggs <swiftgriggs%gmail.com@localhost>]

On Wed, 28 Dec 2016, David Holland wrote:
> On Tue, Dec 27, 2016 at 03:41:44PM -0700, Swift Griggs wrote:
> > Is NetBSD going to play with Wayland? 'Cause X.org seems to be in a bit
> > shaky and captured by Linux-droids.
> I don't know. But all that stuff is shaky and linuxish.

Good. I'm glad I'm not the only one who got that impression.

> ...you use XDMCP? Anyone uses XDMCP, other than to run some vintage X 
> terminals they found in a skip? Or do you mean "remote X display 
> access"?

I do not use an X chooser or a display manager (much). I do have a fully 
functioning SGI box setup to both, but I rarely use it for anything. I set 
that up years ago for some NCD X terminals and it's still kicking around 
in my home lab. Maybe my nomenclature is a bit off and I shouldn't refer 
to remote X-apps that way. However, I do use remote X displays, and that 
is specifically what will not be supported (I assume along with display 
managers and choosers, too) with Wayland.

> KMS is best thought of as "the linux world finally figures out what 
> everyone else knew by around 1990", that is, you should have device 
> drivers for graphics same as for other hardware, and framebuffer devices 
> exposed to userland that don't require reimplementing drivers in every 
> application (read: X server) wanting to use the framebuffer.

What you say makes technical sense. However, from a logistics standpoint, 
doesn't that also mean that the drivers become specific to choices made in 
kernel-land for whatever OS implements them? I remember the whole Xfree86 
-> Xorg transition and the eventual emergence of KMS. My big fear back 
them was that Linux would just focus on KMS, the X projects would wither, 
and any OS's that didn't have a million monkeys to work on graphics 
drivers would be out in the cold. It turned out that I was pretty much 
right. I used some pretty old hardware until NetBSD 7.x and FreeBSD 10 
came out and had updated their KMS implementations with new drivers. 
Suddenly 80% of my new hardware was viable again. I didn't have to 
continue to use AGP graphics cards and expensive funny mobos that allowed 
newer CPUs with an older graphics bus.

My point is that, though you are probably much more knowledgeable about 
what the "right" architecture is, I did see some advantages to 
centralizing the drivers in "an application" (X) because at least that 
creates a common fountain for FOSS to cooperate. Maybe my perception of 
that whole situation was off and Xfree86 just made it harder. I never 
coded on that project.

> Except they apparently don't have it right yet, because the drmkms2 Xorg 
> binary is still setuid root.

You are probably just making a point about the architecture from earlier. 
Point taken.

However, as an aside, I don't actually care about that particular bit, and 
I know others who would agree with me (not in the majority, I'm sure). X 
doesn't listen to TCP by default anymore and even if it did, it's easily 
firewalled. Most multi-user server systems don't run an X server. So, it 
doesn't really impact local security that much either.

Then again, I'm not a "security guy". If I was, I'd be all high on 
OpenBSD. More power to those guys, they seem to get a helluva lot done. 
However, to me, security is like handrails on a long flight of stairs. You 
absolutely need it, but don't confuse that fact with the point of building 
the stairs, which was to get to the top. You can also add handrails later. 
It's not the smartest or safest way to go, but it's possible.

IRIX was hella inscure and I still use it all the time in a version-locked 
environment behind my firewall. It still does things I can't find better 
anywhere else. I'll probably use them till I'm dead and I have zero fear 
of 37337 h0x0x0rs coming after me.

The point in this context is that I think Unix principles are more 
important and helpful than security principles. Small is beautiful. Simple 
programs that interoperate are good. "Modern X" as Mouse put it, doesn't 
seem hip to any of that, with or without needing SetUID binaries, which is 
an afterthought (though I think you were probably bringing up the point to 
illustrate your architectural critique). At least "crufty X" (my term) 
showed some awareness of that.

> There were some historical reasons that XFree86 ended up using the 
> MS-DOS model for hardware and drivers, but it was wrong then anyway and 
> there just wasn't a critical mass of people who knew better.

Well, having lived through that time, I can tell you that I was a young 
guy who'd just come from MSDOS to UNIX in about 1992 or so. I think there 
were a lot of folks like me who, as you put it, were just too 
inexperienced to get it right. They were my peers. I had tons of respect 
and admiration for the accomplishments of the Unix folks, but they were 
"elite" and very few. It took years to get caught up, by then folks from 
my generation had made a bit of a dog's dinner out of UNIX but also 
invented some great things.

Plus, if you weren't an old guy working at a corporation, you couldn't get 
your hands on Unix easily, since most of the good stuff ran on special 
hardware and cost major $$$.

> As I recall the mindset in the Linux world at the time was that the only 
> alternative to putting all the hardware stuff in the XFree86 binary was 
> to put the entire X server in the kernel.

I remember that debate, too. I didn't follow a lot of what was being said, 
but I thought that sounded crazy. Maybe I just didn't get enough exposure 
to the sluggish micro and exo kernels of the 1980s and 1990s to be scared 
of the idea that X anywhere but in a giant microkernel. I guess that's a 
whole different topic, though.

> The idea of a different lower-level interface in between there was 
> apparently too much to process. :-|

Man, that's exactly what I take away from what I've seen in the end.

> Maybe. The problem is: if we venture off in a different direction, 
> that's signing up for a hell of a lot of work.

I can totally dig that. Since I can't do the work, either all this really 
amounts to is speculation on how things mighta, coulda, shoulda work. I 
realize that the ultimate deciding factor is "who can do this?"

> It's probably a bad idea unless upstream and linux go off in a 
> completely unacceptable direction. Until then it's probably better to 
> dissuade them from doing so. That is: if we (for whatever "we") acquire 
> enough of a stake in *their* project, then project politics won't let 
> them blow us off.

Well, I don't know enough about the current KMS and Xorg guts to make any 
critique besides "Guys this is big, ugly, unmanageable looking, and done 
in what appears to be bad form." Then again, someone could shoot back with 
"Then fix it yourself or roll your own". I totally get how incredibly hard 
that would be these days. I also take your point on the politics. You seem 
more optimistic than I do. I figure the next shoe to drop from Linux will 
be some kind of systemd-ized version of X. At which point I expect 
full-on-hostility to ensue between Linux and everyone-else (read *BSD), 
rather than the current smoldering disrespect and head shaking.

> On the flip side I do feel like a lot of what we get for graphics is 
> crap with an extra order of bleck. If we had infinite resources for 
> development we'd probably do well to design our own thing.

I hereby swear that if I win the lottery or find out that I'm related to 
Larry Ellison after he dies, I'll make that happen. I see the same 
situation.

> Same as if we had inifnite resources for development we'd do well to 
> move Gnome and KDE to the bit bucket and do that right as well. 
> Unfortunately, we don't.

At least there are small/tight alternatives. That's not exactly true for 
X11. :-)

> Yes. Also, there aren't as many of those older non-x86 framebuffers. 
> There's a lot of radeon and nvidia models. (And intelgraphics, and other 
> x86 things before them.)

Yes, good lord there are almost TOO many of them. I go back to the point 
about really wishing hard OpenGraphics wasn't such as slow train wreck. 
That might have given folks an out, had it gained some traction back when 
it started.

-Swift