I have no intention of ever using Arch myself, but I just had to tell you that your guide here is top notch. You deserve a standing applause for the effort you put into this!
2 Likes
Yes, it is a great guide although I find it frightening for the novice. I think that this: https://itsfoss.com/install-arch-linux/
is simpler although it does not have all the bells and whistles of the above guide.
One more thing: I will not move to Wayland if the Wayland guys and girls insist on not supporting network transparency. Wayland reminds me the Gnome2-to-Gnome3 situation. The Gnome Foundation decided on their own to abandon Gnome2 and have been practically forcing people to follow them to a desktop you could not configure for years. Still, after so many years, window managers like AfterStep have more options than Gnome3.
I understand this is good for small screens (like L5) but on the desktop, mate will stay my No1 choice; on L13 too.
Gnome or not still better than M$-windoze …
1 Like
X11 isn’t network transparent. It is from the application writers perspective, and even that only sorta. On a local machine, a buffer is allocated, and pointers to the buffer are passed around. Over the network, the buffers are copied. Each uses an independent section of the XServer code. Heck, by default Xorg doesn’t even listen on the IP stack anymore due to the lack of use, terrible security implications, and terrible performance of doing so.
Most Wayland compositor teams recommend using a different protocol for networked use, ideally one like VNC which supports h264 encoding the frames, thereby significantly improving bandwidth. That said, a network-aware extension for Wayland would be easy enough, if anyone actually wanted it. It’s also relatively easy to implement a shim, which acts as a Wayland server on the application side and a Wayland client on the display side. This, someone may do, as it would probably be able to outperform vnc, support at least some Wayland extensions, and be pretty easy to do. It would beat X-over-the-network by a wide margin too, as the every-frame-is-perfect promise of Wayland avoids the nasty tearing that networked X has.
1 Like
OK I do not want to get into technicalities. However, I know this: we have labs with many seats for students running LTSP5. The labs work for years now more than 10) with no problem at all. The thin clients are indeed thin and can not become fat (they are dedicated thin clients of Fujitsu). With Wayland around the corner we have to through everything in the garbage and buy fat clients. LTSP has moved to support only fat clients (LTSP2019).
This is just an example of a situation where Wayland is bad unless it becomes network transparent one way or the other.
Actually even fat clients are bad for a lab. Because most students are required to run heavy programs like MatLab which will require a very-fat client if it is to beat our LTSP servers.
Actually we are thinking about financing the continuation of the development of LTSP for thin clients, but this will again require network transparency of some sort.
Hm, that is something of an interesting use case… Normally the limiting factor in remote X connections is the sheer bandwidth required, without intelligent encoding, even with ssh forwarding and gzip compression, at 1080p each frame is 8 megabytes. Even if we assume 90% compression (yeah right, be lucky to get 20%), that means 20fps saturates a 100mb connection. Hence why vnc, rdp, and so on, are so strongly preferred. The require more CPU power to encode and decode the traffic, but can get much better compression, downcode the video stream, and intelligently drop frames as needed.
Sounds like your use case has sufficient network bandwidth that raw streams are acceptable, especially since the actual changed portion of the frame is likely to often be small (and X supports damage tracking), and CPU time is the significant limitation on the decoding (and possibly the encoding) end.
The good news is that, as I said, adding network transparency on-par with Xorg’s to Wayland is pretty straightforward. The simplest way works if you have Xorg running on the client. Just fire up an X-nested wayland session on the server, it’ll paint its window on the client. Of course, that doesn’t intelligently handle using the server’s video card for buffers, so performance and stability are something of a challenge (I can’t even get it to start if the client is running XWayland).
The real solution is a lightweight wayland compositor, running on the server side, which connects to a wayland client running on the client side. Basic functionality is pretty trivial to set up, some advanced things (screen locking/password passing) might need protocol extensions.
Does your common server have a dedicated video device?
Actually on a University lab the only thing you do not care is high resolution video So the 1080 is not an issue. Low resolution is enough, and actually HD is the only thing that does not work. But it doesn’t matter.
Now the thin clients all have Gigabit ethernet, they are connected to a Gigabit switch with the server (which does have a dedicated video card if this is what you asked). On the LTSP side we use DirectX connections which makes everything go faster. We know that this is a security issue but the lab is inside a firewall perimeter and in lab security is not an issue as the labs are used for courses. Everything works nice (except HD), even usb sticks (OK this is ltspfs and not X), sound, the works.
The user just boots the client and s/he is presented with a login of the server (through ldm (which uses ssh)).
Is this possible with wayland? I do not think so. Or if I am wrong tell me.
There isn’t currently a Wayland implementation that can do that. The Wayland protocol itself doesn’t prevent it though, so writing a compositor which can would be relatively straightforward. It isn’t simple, since there are lots of messages that have to be relayed, and while many of them can be simply relayed, some of them will require extra work to emulate shared memory.
It’s actually easier for this sort of use, since the thin client doesn’t need to composite anything itself, it can just get the frames over the network and dump them to the screen. You could have the server side send each client frame individually, and composite them on the thin client, which you would need to do if you also wanted to run local programs on the thin client, but for dedicated fullscreen, it’s quite straightforward. Heck, it should even work with OpenGL and Vulkan programs.
We should probably move this to its own thread…
1 Like
I successfully installed Arch on a Librem laptop as well as a Lenovo following these instructions.
Thank you to the OP.
2 Likes
What is a proper name for a new thread? Wayland over X or LTSP on PureOs? In any case I would love to see an implementation of LTSP for thin clients on a rolling distribution. Currently no such thing exists.