Was at project Athena mid-80’s at MIT taking a class on X internals and probably ran into those guys. We did all of the work on DEC workstations running saber C as I recall.

This is yet another vague underappreciating video.

I was inside my father's balls in 1984.

When did they stop providing the CLU interface to X?

@@GodEmperorSuperStar I can't really tell you. I left MIT in August 1984. My impression was that Barbara Liskov's group had mostly transitioned to working on Argus roughly at that time, and I am not sure how much new CLU stuff went on after that.

Hi John, I guess it heavily depends on the desktop environment or window manager that you use; for instance, I found very little glitches when using Sway WM, but a whole lot of issues when using KDE + Nvidia proprietary drivers. There are so many layers in our current digital onions that sometimes our experience vary greatly from user to user even when using the same software and hardware stack, but mixed in a different way!

been using fedora with gnome on Wayland and amd igpu for a while now and I've had no issues. I definitely wouldn't call myself a "lightweight home user"

screen sharing is still problematic, but apps are slowly catching up. Colour correction is useless. HDR support is nonexistent.

I'm running KDE Plasma through Wayland on Arch. Only problem I remember from the past year or 2 was an update breaking Kate text editor that was fixed next update.

Same, swaywm has been great i3 replacement for 2 years.

I'm also using a docking setup on two different offices with different external monitor setups. It worked great for me on X11 but on Wayland - which I committed to a couple of months back - the experience is not as smooth: mostly Plasma forgets my desktop configuration every few days, reverting to the default "folder view with default wallpaper". I stopped using widgets on the external monitors because of that.

I'm running KDE Wayland too. Finally Linux is welcome to the 21st century !

The Wayland situation I complained about us apparently a known bug that is being worked on and will hopefully be fixed for 5.27

How did you install Wayland over your x11 setup?

Thanks Simplify I am glad you find them useful

Thanks Weldopedia

haha, thanks David, and I sure will try

Thanks Nicio. Sysadmin? me? naw I'm not smart enough to be one of them. I was a programmer.

Nice, is one thing to read on the subjects and construct visual idea. Another coming from a view of a professional with past experiences. Thanks for your input on each subject. Love the microkernel video, Can't wait for nano.

Thanks Felix

Thanks eznix

@@CyberGizmo Alice in UNIX Land by Lincoln Spector, 1989: [...] Soon Alice came upon a large brown table. The Consultant was there, as was an apparently Mad Hacker, and several creatures that Alice did not recognize. In one corner sat a Dormouse fast asleep. Over the table was a large sign that read "UNIX Conference." Everyone except the Dormouse was holding a paper cup, from which they were sampling what appeared to be custard. "Wrong flavor," they all declared as they passed the cup the cup to the creature on their right and graciously took the one being offered on their left. Alice watched them repeat this ritual three or four times before she approached and sat down. [...] The Mad Hacker handed Alice a cup of custard-like substance and a spoon. "Here," he said, "what do you think of this?" "It looks lovely," said Alice, "very sweet." She tried a spoonful. "Yuck!" she cried. "It's awful. What is it?" "Oh just another graphic interface for UNIX," answered the Hacker.

Wow, thank you Hello World, yeah that show was incredible

Yes. The X Display server was called a server because it provided graphical display services to its clients. Its clients were the X-Windows applications that the user was running.

good point, so both server and client running on the server because those NCD terminals were not able to run anything? or those were running a terminal software?

@@jnslzr the terminology here is awkward, the NCD hardware is running a program called the X Server, it's job is to receive commands (over the network) to draw the UI, sending back information in the form of events. On your workstation, which in that era would have been a Sun or a HP or similar, running some flavor of Unix, you would set your DISPLAY environment variable to include the network address of the NCD. Then when you ran programs such as xterm, xeyes which X Windows refers to as clients, they would connect to and appear on the NCD. So if it was xterm, when that window appeared on the NCD the shell you'd be typing into was running on the Sun or HP. You can do this today fairly easily with two linux boxes. The trickiest part is getting the authentication to work such that the X Server running on the linux box you want your client to appear on to even allow such connections. This is mostly defaulted to "off" these days, when X11 first appeared it was always defaulted to on. Different times. Hope that helps.

@@jnslzr The Wikipedia entry for "X terminal" explains it well: An X terminal runs an 'X server'. In X, the usage of "client" and "server" is from the viewpoint of the programs: the X server supplies a screen, keyboard, mouse and touchscreen to client applications. This connects to an X display manager (introduced in X11R3) running on a central machine, using XDMCP (X Display Manager Control Protocol, introduced in X11R4). ... In the early 1990s, several vendors introduced X terminals including HP, DEC (including the VT1000 series), IBM, Samsung, NCD, Gipsi and Tektronix. It was cheaper to run a server with a bunch of X terminals than to have to buy the same number of Unix Workstations.

that client/server feature had to go because of the change in paradigm. wayland basically is a command-buffer stream for GLES commands going to the GPU, its the GPU that does the heavy lifting, not the wayland, wayland in a way is a "client" of sorts. it should be possible to do region damage on the framebuffer after compositing together while you know about the data-structures of the wayland to compress the video stream. RDP works that way on Windows, it provides a virtual graphics card framebuffer, it knows enough about the tree structure of the windows (I mean, the components, the buttons, and panels and shit, Windows calls everything windows, I guess that's why its called Windows) to reduce the need for "bitmap" transfer. Its kind of unavoidable with modern desktops with lots of bells and whistles. VNC is really, really bad protocol, it is basically dividing the screen in blocks and sending them as JPGs and the algorithm try to detect the blocks that didn't change (I think it can detect if blocks moved, but it is really bad, any MP4 compression algorithm it does better) , its possible to do better because proprietary software do video encoding with good latency, for ex, anydesk, that I'm sure works entirely on the bitmap framebuffer, but I bet it uses the hardware encoding for H.264. probably all of that is too much for your "beater" PC, I consider anything before the SandyBridge as e-waste, except perhaps for the "nehalem i7" those were really good. but if you are thinking about a core-2-quad, that would be a stretch, they would max out the CPU trying to decode and you are going to get latency.

its probably possible to create a client/server command buffer for GLES as a virtual GPU before Wayland and that would work without even changing Wayland. that would be a cool experiment.

@@jeremiahbullfrog9288 yeah, in that way we can have back that feature of client/server, but in a way that makes sense for our current architecture sending the command buffer would totally make more sense than scrapping framebuffers.

@@monad_tcp You have no clue about how the internals of modern graphics actually work. It is far more efficient to send the frame-buffer over instead of all the tinny bitty commands and actually programs and hassling around with compatibility and hardware differences all the time.

@@rosomak8244 no, it's not. I literally spent time optimizing framebuffer transfers the other day because I needed to run some Laplace pyramid transform and it's more efficient to do that on the CPU. The trade off was that the CPU could process the last captured frame while the GPU was generating the next. I implement this for both smartphone SoC and PC . Smartphones have shared memory, so no DMA copy, in this case you might be right. But on PC you have to wait for the async signal from the command queue of the GPU for completeness. In both case you don't need to actually manage any memory. I didn't even need unsafe code or any pointer arithmetic, you get opaque pointers from the driver and you just pin them if you are using a GC language . Or in case of Rust , you create a struct that does simple ref counting , which is trivial to do on Rust. That way you can signal the video driver when you're not using that memory anymore. Anyways, you don't even need to care about memory management, just do triple buffering of the surface, I mean, the pixbuf, framebuffer whatever it's called. Which is even better as allocation of framebuffer and memory allocation in general isn't "free", but just go allocating and calling malloc in the render thread. And I'm the one that doesnt know how to program. Programs should not allocate memory in steady state. All of them could use garbage collectors and you would be none the wiser, alas, the GPU driver has a GC for the FBOs , ironically . Its literally better to leave the framebuffer on the GPU and do everything there , than moving back and forth, DMA calls aren't free. You do hassle with hardware compatibility, it's the price to pay for performance. Otherwise you might as well do everything in Python and let pytorch take care of all that if you need it to be portable. Gezz , you guys are really bad at understating systems at multiple layers of abstraction.

They DO have the role reversed if you think in 1984 terms. Normally, you, on a small computer, send requests to a Server on a big one which do something useful for you and returns the result. If you use X11, you need to start a server, and the big machine sends you requests to draw stuff on the screen.

@@framegrace1 Yes, I was there, in the eighties. But it is still logical that a display server is where the display is, just like a file server is where the files (disks) are. So what really was reversed, the perception people had about client-server in the 1980's or the X11 protocol? Should the X11 protocol have been designed differently (how?) so that people would have had a better grasp of it, but then reality kicked in and it had to be implemented "in reverse"? I really don't understand what DJ Ware is trying to say with "the protocol is reversed because of performance reasons".

I agree with Johan. X provides the "service" of displaying the output of a program (and sending user input back to it), hence "server". The program at the other end is requesting display service, hence "client". The confusion is purely one of terminology, not of functionality. Once you grok to the idea of network transparency that is (was) central to X, everything clicks into place. Think about having many programs running, all on different machines scattered across the world, and calling into your single X server to request display and input management. It would be absurd for those programs to send their output to their own monitor in Timbukwherever, even if they had one.

could you elaborate?

@@mikesoto890 I assume this is referring to how in the original design X11 applications would send commands for lines, shapes, and text to the display server, and the server would then perform the drawing operations from scratch in its own pixel buffers. That design could be really efficient when the application was running on a remote computer and the UI design was simple, but the protocol's drawing commands were designed in the 1980s with little to no support for things like anti-aliasing and color blending, and dealing with fonts was an ordeal because they had to be installed on the display server rather than the machine where the application was actually running. This approach is still used by some applications, especially older ones such as xterm. To get around the graphical limitations in the X11 drawing commands, a lot of modern applications do more of the drawing in the application itself. For example instead of telling the display server "draw the text 'example' at position x,y with the current font and color", they use their own font rendering code and send the characters to the display server as image/pixel data. Some extensions have been added to the X11 protocol over the years to make that work better. The XRender extension provides pixel blending operations which can help with drawing application-rendered text. If an application is going to be drawing the entire window itself, the XShm extension lets the application and display server set up a pixel buffer in shared memory (if they're running on the same machine), so then the application can fill the buffer and tell the server to make it visible, without having to encode the pixels into the X11 protocol or copy them multiple times.

@@dododge9428 Sounds like X11 is well optimized and there is little reason to replace it.

Welcome Michael

Wlroots helps apparently

There is a reference Wayland implementation called “Weston”.

@@kreuner11 Helps to develop new compositors but we have also KDE's KWin, Gnome's Mutter as parallel implementations.

Thanks Sean

Very similar to a security flaw I found in Sun's workstations, in 1988 or 1989, before the days of X, when I was a sysadmin at Ford. We reported it to Sun. I assume they fixed it. I also remember from that time a display windowing system based on Postscript.

Pshhhh what could my threadripper 3970x and asus Nvidia rtx3070 possibly need that a computer in 1986 couldn't do!

Thanks Zer0Hour, yeah would love to do a collab with them

@@CyberGizmo 👍

Had a similar issue with my graphics, turned out to be an issue they fixed later on. So don't you worry. The automation on the other hand I'm not so sure about, since it sounds like an issue with how wayland is meant to work. Could be unfixable. But maybe, I don't know. Screensharing sounded like that too and yet apps are slowly implementing it anyway.

@Certyfikowany Przewracacz Hulajnóg Elektrycznych For what it's worth, GNOME Wayland has been working just fine on my Dell Inspiron 3793, i5 variant.

I know, you missed what I was saying. I said they originally tried to run the X-Clients on the terminal but the performance was terrible so they flipped the it to run the server.

@@CyberGizmo No, the terminology is basic to the architecture. The display is the server, the GUI apps are the clients. It doesn’t work if you flip it around.

My notebook have GeForce MX150 (with optimus tech), and 3D offload doesn't work. My next computer (desktop & notebook) will 100% gonna be ALL-AMD (Ryzen-Radeon)

yeah i want to run wayland on my desktop but nvidia sucks BALLS

I have an Nvidia card as well and yeah I hope the drivers improve for Wayland too, because right now they are terrible.

The NViDiA Open Source thing is an ugly gimmick (hiding the good stuff deeper down in a RISC-V chip on the board - making it even harder to reverse engineer).

@@NitroNilz That's true, but if Nvidia is willing to do some serious work on open source drivers, it would help. Even if they would go so far as to say, "we can do X, but if you want Z, you will need to use our proprietary drivers," that would be OK in my book, if they would just give us good proprietary drivers. They ones they give us now still leave a lot to be desired. They can do better.

I'll add it to the list, Jared. Thanks for the topic suggestion!

There is a program called "waypipe" that does what I think you want Wayland to do. I've used it once or twice, and it works exactly the same as "ssh -X" does, but it works natively with Wayland without requiring Xwayland.

nit picky - but show me please how you can have a protocol without a server. it is both my friend

@@CyberGizmo: It's the difference between specification and implementation. You usually have the specification first, so there's no problem to have a specification without an implementation. In the case of Mir, they had an implementation but not a specification, because you weren't supposed to rely on the DS protocol directly anyway. Most X11 software don't implement X11 directly, but rely on toolkits and such.

They are working on it through a separate project named waypipe if i remember correctly