tech-x11 archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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



Home | Main Index | Thread Index | Old Index